系统测试计划.docx

上传人:b****8 文档编号:11273655 上传时间:2023-02-26 格式:DOCX 页数:15 大小:22.52KB
下载 相关 举报
系统测试计划.docx_第1页
第1页 / 共15页
系统测试计划.docx_第2页
第2页 / 共15页
系统测试计划.docx_第3页
第3页 / 共15页
系统测试计划.docx_第4页
第4页 / 共15页
系统测试计划.docx_第5页
第5页 / 共15页
点击查看更多>>
下载资源
资源描述

系统测试计划.docx

《系统测试计划.docx》由会员分享,可在线阅读,更多相关《系统测试计划.docx(15页珍藏版)》请在冰豆网上搜索。

系统测试计划.docx

系统测试计划

CRM4.3系统测试计划

【CRM4.3程序mysql数据库】

 

 

XXXX有限公司

2012-04-28

文档说明

文档变更

版本

描述

修订人

修订日期

审核人

审核日期

V0.1

初稿

XXX

2012-03-28

1引言

1.1编写目的

本文档是针对CRM4.3系统功能、性能测试所作的测试计划,其中主要包括功能测试、用户界面测试。

文档有助于实现以下目标:

•明确系统功能、范围和测试策略;

•明确测试的目标、内容、方法、环境和标准;

•明确硬件环境和访问地址;

•确定所需的资源,并对测试的工作量进行了评估。

1.2背景

CRM4.3系统功能模块是在原来crm4.2系统的基础上,对导入、导出、查重、我的工作台、自定义报表、ipcc固定报表功能做了修改,以和要求单表数据量为千万级。

DellR710测试环境访问地址:

IPCC后台配置地址:

http:

//192.168.40.168:

8080/ipcc

CRM4.3地址:

http:

//192.168.40.168:

8080/crm4.3

DellT110测试环境访问地址:

IPCC后台配置地址:

http:

//192.168.10.214:

8080/ipcc

CRM4.3地址:

http:

//192.168.10.214:

8080/crm4.3

以实际分配的地址为主。

1.3参考资料

序号

文档名称

设计者

1

《CRM43需求设计》

牛兴华

2

《IPCC初始报表》

牛兴华

3

《CRM4.3研发计划》

李长伟

4

《CRM43性能测试_指标建议》

牛兴华

2测试范围

2.1CRM4.3系统测试功能清单

序号

功能模块

1

导出

2

导入

3

查重

4

合并

5

报表

6

我的工作台

3测试准则

3.1测试启用标准

1、系统待测版本定版;

2、测试环境准备完毕,包括:

1)系统安装并调试成功,并经过相应优化,初始数据量满足测试要求;

2)应用服务器安装成功,待测试版本已正确部署;

3)测试客户端机器到位,系统软件安装完毕;

4)网络配置正确,连接通畅,可以满足测试需求;

3、测试计划审核、批准完毕。

3.2暂停标准和恢复需求

暂停准则:

1、系统在进行系统测试时,发现5级错误(大于等于1)、4级错误(阻碍性的问题大于等于3)暂停测试返回开发。

2、测试中发现问题,需要对系统进行代码修改、调优或需要更换、调整硬件资源等;

3、测试环境受到干扰,比如服务器被临时征用,或服务器的其它使用会对测试结果造成干扰。

再启动准则:

1、测试中发现的软、硬件问题得到解决;

2、测试环境恢复正常。

3.3测试通过的标准

1、在推荐测试环境下,软件功能能够正常走通与需求一致。

2、没有严重影响系统运行的问题。

3、在系统测试中发现的错误已经得到修改,各级缺陷修复率达到标准。

4、测试计划中的测试项目已经得到全部测试通过并且得到确认的。

3.4BUG修复标准

各类测试合格BUG须符合以下标准:

5级错误

4级错误

3级错误

2级错误

1级建议

<5%

<10%

以上比例为bug占总测试模块的比例,具体视实际情况而定。

若有延期问题,必须由研发、测试各部门领导讨论后决定。

3.5覆盖率标准

1、所有4.3范围内的功能,可点击、访问的操作必须100%执行

2、所有4.3范围内的功能,可配置项,选择项,状态控制等100%组合测试

3、若有海量操作,是否全部执行(比如所有类型属性的查询,是否需要执行完整个矩阵),需报批测试部经理,做出符合实际的调整。

4、需求中有明确业务流程要求的功能,必须协调多方,进行业务模拟测试。

4测试策略

4.1测试方式说明

1.开发单个模块功能完成后就进入单个功能模块测试,最后再做系统测试,单元测试和系统测试阶段都要分别做如下测试:

先进行功能测试,然后再做性能测试。

2.按照开发计划陆续接到提交测试模块,进入单元测试阶段,人员和任务安排见如下文档:

4.2功能测试

测试对象的功能测试侧重于可以被直接追踪到用例或业务功能和业务规则的所有测试需求。

这些测试的目标在于核实能否正确地接受、处理和检索数据以和业务规则是否正确实施。

这种类型的测试基于黑盒方法,即通过图形用户界面(GUI)与应用程序交互并分析输出结果来验证应用程序和其内部进程。

以下列出的是每个应用程序推荐的测试方法概要:

测试目标:

确保测试对象的功能正常,其中包括导航、数据输入、处理和检索等。

方法:

利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:

∙在使用有效数据时得到预期的结果。

∙在使用无效数据时显示相应的错误消息或警告消息。

∙各业务规则都得到了正确的应用。

完成标准:

∙所计划的测试已全部执行。

∙所发现的缺陷已全部解决。

∙迫于项目进度要求,存在1、2、3等级缺陷被迫测试结束。

需考虑的特殊事项:

确定或说明哪些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)

4.3用户界面测试

通过用户界面(UI)测试来核实用户与软件的交互。

UI测试的目标在于确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。

除此之外,UI测试还要确保UI功能内部的对象符合预期要求。

测试目标:

核实以下内容:

∙通过浏览测试对象可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以和各种访问方法(Tab健、鼠标移动和快捷键)的使用。

∙窗口的对象和特征(例如:

菜单、大小、位置、状态和中心)都符合标准。

方法:

为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。

完成标准:

∙证实各个窗口都与基准版本保持一致,或符合可接受标准

∙迫于项目进度要求,存在1、2、3等级缺陷被迫测试结束

需考虑的特殊事项:

并不是所有定制或第三方对象的特征都可访问(例如邮件正文对信纸的支持)。

4.4性能测试

4.4.1术语

1、压力测试:

确定系统的瓶颈或者不能接收的性能点,获得系统能提供的最大的服务级别的测试。

2、事务:

所定义的单一功能的操作动作。

3、吞吐量:

单位时间内成功地传送数据的数量。

4、集合点:

用于设定并发操作的触发节点。

5、响应时间:

程序所要完成单一功能动作所耗费的时间。

4.4.2性能需求调查

用LoadRunner测试要求如下:

1、用户使用数:

在线用户500个,并发数5%。

2、所需操作事务:

登录、打开列表、打开查看页、打开编辑页。

3、事务响应时间:

打开列表、打开查看页、打开编辑页速度不能超过7秒。

4、事务成功率:

99%。

5、数据量:

单表1000万条。

6、列表布局中,布“引用类型”属性个数要求:

1000万条数据,进入列表响应时间7秒以内时,所能达到的最多引用属性个数。

(owner、创建人、部门、引用有1000万数据实体的属性)。

7、打开查看页,相关实体和相关实体列表布局使用初始库中的缺省设置,相关记录数不宜过多500以下。

场景要求:

1.单表1000万条数据7秒内所达到的最大用户数。

2.单表1000万条数据500个用户事物响应的时间多少,系统资源占用情况。

单个用户手动执行测试要求如下:

1、导入最大数据量:

10万,同时执行5个任务时不出错。

1)、检验数据合法性时:

每秒4条。

2)、导入时:

每秒2条以上。

2、导出最大数据量:

10万导出,同时执行5个任务时不出错。

3、单个用户运行报表:

响应时间不超过30秒,分组条件个数和统计字段个数以ipcc的14个报表为主。

(此项测试待crm4.1.1升级到crm4.3后用人瑞或公司的数据做报表运行情况分析)

4.4.3测试方法

步骤1、利用LoadRunner性能测试工具中的Generator应用,录制性能测试执行脚本。

步骤2、修改、调试并保存测试脚本。

步骤3、利用LoadRunner性能测试工具的Controller应用,虚拟用户数执行设计场景并保存场景执行结果。

步骤4、利用LoadRunner性能测试工具监测被测环境下服务器CPU,内存、磁盘、网络带宽等系统资源的使用情况。

步骤5、利用LoadRunner性能测试工具中的Analysis应用,分析场景执行后的结果。

步骤6、根据监控结果对系统性能进行分析。

步骤7、根据并发测试执行结果,分析结果是否满足用户需求并生成性能测试报告

4.4.3测试模拟的操作

脚本操作步骤:

ScriptA:

1.登录、2.在线、3.退出。

ScriptC:

1.登录、2.客户列表、3.查看客户、4.编辑客户、5.退出。

ScriptB:

1.登录、2.联系人列表、3.查看联系人、4.编辑联系人、5.退出。

ScriptD:

1.登录、2.自定义实体列表、3.查看自定义实体、4.编辑自定义实体、5.退出。

4.4.4测试模拟的场景

场景1:

475个用户在线无并发运行

序号

脚本名称

用户数

运行方式

集合点策略

备注

1

ScriptA

175

每5秒钟启动50个用户同时启动,持续运行4小时,自动运行完毕

2

ScriptB

100

3

ScriptC

100

4

ScriptD

100

场景2:

25个用户在线并发运行

序号

脚本名称

用户数

运行方式

集合点策略

备注

1

ScriptA

每5秒钟启动50个用户同时启动,持续运行4小时,自动运行完毕

10个用户并发

2

ScriptB

5个用户并发

3

ScriptC

5个用户并发

4

ScriptD

5个用户并发

5系统测试任务和进度

5.1测试任务安排

5.1.1CRM4.3测试任务分工

具体测试任务分工,见如下文档。

(双击打开)

系统功能测试计划时间为:

第一轮测试:

2012-05-14~2012-05-15

打包日期以实际时间为准

第二轮连续回归测试:

2012-05-17~2012-05-18

随时打包随时验证,可能会频繁打包,打包日期以实际时间为准

系统性能测试计划时间为:

脚本准备:

2012-05-21~2012-05-21

场景设计:

2012-05-22~2012-05-22

性能测试:

2012-05-23~2012-05-25

5.2角色

角色

姓名

具体职责或注释

测试经理

XXX

部门工作协调

获取适当的资源

提供管理报告

执行、监控测试

记录测试结果

从错误中恢复

记录变更请求

测试监控和测试人员

XXX

设计测试大纲

评估测试工作的有效性

测试环境搭建、维护

提供技术指导

测试思路整理

执行、监控测试

记录测试结果

从错误中恢复

记录变更请求

编写测试报告

测试人员

XXX

执行测试

测试思路整理

记录结果

从错误中恢复

记录变更请求

测试人员

XXX

测试思路整理

执行测试

记录结果

从错误中恢复

记录变更请求

测试人员

XXX

测试思路整理

执行测试

记录结果

从错误中恢复

记录变更请求

6测试环境

6.1初始测试环境

1.应用程序、数据库服务器

序号

名称

硬件配置

软件配置

数量

1

web服务器(192.168.40.168

192.168.10.214

DELLR710:

CPU:

XeonE560664位4核2.13GHz

硬盘:

1TB

Mem:

4GDDR3

DELLT110:

CPU:

InterXeonX34302.4GHZ

内存:

2G

硬盘:

250GB

1、系统:

Linux

2、web服务器:

apache-tomcat-6.0.20

3、jdk1.6

4、数据库:

Mysql5.0

2台

2

数据库服务器(192.168.40.168

192.168.10.214)

单元测试时按实际情况再具有调整(预设3台)

6.2测试工具

工具

厂商/自行研制

版本

测试管理

QC(QualityCenter)10

HP

10

项目管理

SVN

性能测试工具

LoadRunner11

HP

11

7开发提供程序包和数据库包

7.1文件命名规则要求:

文件包名由:

软件名称+发布版本号+文件类型+打包时间组成,例如2012-03-28编译提供测试的。

1.程序包名称为:

crm4.3.war、ipcc4.3.war

2.数据库包名称为:

crm43.sql

压缩后:

包名应为如:

程序包和库2012-03-28.rar

说明:

rar代表是压缩包后缀

war代表完整程序包,可以完整安装。

sql代表数据库文件的后缀。

7.2提交测试程序包和数据库包统一存放:

1.开发负责人将测试的程序包和数据库包统一存放到SVN\...\CRM4.3\Docs\Test\程序forCRM4.3中,禁止文件发送。

特殊要求:

首次测试和最后一轮测试的时候,开发应提供干净的(只有基础数据的)数据库包。

2.测试负责人到SVN的\...\CRM4.3\Docs\Test\程序forCRM4.3中取程序包和数据库,搭建测试环境。

8风险分析

序号

风险描述

级别

规避措施

1

测试环境与用户实际应用的环境不一致,在用户实际应用中可能会出现一些在本测试环境下未发现的问题。

了解客户实际应用环境与测试环境的差别,分析由此差别对测试结果影响程度,并尽量模拟用户实际应用环境。

2

项目进度安排十分紧张,导致测试不全面。

向项目负责人申请增加测试时间。

3

测试人员对业务理解不透彻,导致测试结果不准确

测试人员通过跟开发人员的交流和需求文档等资料对软件加深了解。

4

开发缺少单元测试,导致3、4级bug很多无法进一步测试,测试版本被退回,影响项目整体进度。

开发人员完成单元模块开发后,参照需求功能进行代码、程序功能走查。

5

测试结果不能满足封板要求,增加测试轮次

1.确保功能实现完整后,整体提交系统测试;

2.提交完整系统程序包和只有基础数据的干净数据库;

3.在下一轮开始测试之前,应解决全部open、reopen的bug后提交测试;

4.测试环境和开发环境独立开,确保测试环境与开发环境一致性;

5.开发修复bug时,应保证修复bug的质量,尽量避免再次打开和测试通过的功能再次出现问题的情况。

9测试归档文件

序号

文档名称

提交人

1

《CRM4.3系统测试计划》文档

XXX

2

《CRM4.3系统测试报告》文档

3

最终测试结束的程序包和数据库

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 初中教育

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1