整体测试方案文档格式.docx
《整体测试方案文档格式.docx》由会员分享,可在线阅读,更多相关《整体测试方案文档格式.docx(15页珍藏版)》请在冰豆网上搜索。
作者
说明
V1.0
C
2016年9月5日
罗晨
说明:
类型-创建(C)、修改(U)、删除(D)、增加(A);
评审记录
角色
签名
第1章概述
1.1编写目的
编写本测试方案的目的是为客户、项目经理、开发人员、测试工程师、维护人员等项目相关人员提供海关信息数据采集与数据应用与平台测试项目整体系统测试指导。
1.2读者对象
本测试方案可能的合法读者对象为客户、项目经理、开发人员、测试人员、维护人员。
1.3项目背景
随着经济环境、执法环境的变化,海关大监管、关警融合、分类通关等各项业务的不断深入,加快通关速度和大通关对缉私工作提出了更高的要求,情报工作在海关各工作特别是缉私工作中的地位和作用日益凸显,所担负的职责更加繁重,任务更加艰巨,海关人力资源与监管要求直接的矛盾突出。
为了提升海关大监管的综合执法能力及海关缉私办案能力,必须借助现代化情报工作机制及计算机情报信息系统支持,完善情报机制,体现情报信息服务,增强对全国海关情报业务的掌控能力。
第2章测试方案概述
2.1测试目标
(1)系统界面操作无明显异常,符合业务需求规定;
(2)根据需求规格说明书,总体设计、详细设计文档实现整体功能测试;
(3)系统主要流程,无异常,符合需求;
(4)根据需求进行性能测试、稳定性、健全性及安全测试;
(5)所有测试用例100%执行;
(6)所有缺陷处于Closed、Rejected、Pending状态;
(7)缺陷修改要求:
High级缺陷修复率应达到100%;
Medium级缺陷修复率应达到95%以上;
Low级缺陷修复率应达到60%以上。
2.2测试范围
本次测试主要针对海关信息数据采集与数据应用平台项目的软件需求规格说明书中涉及的要求进行完整性测试,包括界面、功能和流程的全面测试,以及性能测试、稳定性、健全性及安全测试等。
本次测试采用黑盒测试的方法为主,辅助进行代码审查。
2.3参考资料
《海关信息数据采集与数据应用平台测试项目需求规格说明书》
《海关信息数据采集与数据应用平台测试项目合同》
公司软件测试规范。
第3章测试环境
测试环境分类
测试环境名称
硬件环境
软件环境
客户端
PC机1
(172.17.9.106)
Pentium(R)DCPU3.00GHZ2.99GHZ,
1.99GB内存
WindowsXPProfessionalSP2
PC机2
(172.17.9.123)
服务器端
应用服务器
待定
数据库服务器
企业端(172.16.1.108):
IBMXDERIES_366Intel(R)Xeon(7M)MPCUP3.16GHz3.17GHz3.25GB 内存
中心端(172.17.16.22):
SystemModel:
IBM,7040-671
NumberOfProcessors:
16
ProcessorClockSpeed:
1500MHz
CPUType:
64-bit
MemorySize:
16384MB
HardDisk:
109200MB
企业端:
Windows2003ServerEnterpriseEditionSP2
中心端:
AIXVersion5.3
MQ服务器
(企业端:
172.17.16.14;
中心端172.17.16.13)
IBM,7026-6M1
8
752MHz
8192MB
36400MB
MQ6.0
其它
加M机
(172.17.8.250)
分中心(邮箱客户端)
同PC机1和PC机2
浏览器
IE6
表4.1测试环境
第4章测试方案
4.1测试依据
在本项目实施过程中编写的需求、设计、计划、测试方案、测试报告等产出物,需要通过客户、项目经理、QA、测试经理等该项目相关人员审核。
4.2功能测试
测试人员根据通过审核的需求、设计、测试方案等文档编写测试用例,要求测试用例的功能覆盖率要达到100%,测试过程中测试人员严格执行测试用例并记录测试结果,验证系统的功能实现是否达到需求、设计要求,是否满足客户目标。
测试用例执行率达到100%。
测试过程中所有问题提交BugFree。
4.3性能测试
应用系统经过系统测试后形成相对稳定版本,测试组在稳定版本的基础上选择性能测试点进行性能测试,测试组负责编写性能测试方案,对系统进行压力测试、并发测试、稳定性测试。
测试过程中使用性能测试工具LoadRunner。
执行性能测试时,同时填写《性能测试记录表》、《性能测试调优过程记录表》。
4.4内部测试
4.4.1测试策略
测试过程按三个步骤进行,即单元测试、集成测试、系统测试,根据不同阶段测试的测重点不同。
4.4.1.1单元测试
首先按照系统、子系统和模块进行划分,但最终的单元必须是功能模块,或面向对象过程中的若干个类。
单元测试是对功能模块进行正确性检验的测试工作,也是后续测试的基础。
目的是在于发现各模块内部可能存在的各种差错,因此需要从程序的内部结构出发设计测试用例,着重考虑以下五个方面:
1)模块接口:
对所测模块的数据流进行测试。
2)局部数据结构:
检查不正确或不一致的数据类型说明、使用尚未赋值或尚未初始化的变量、错误的初始值或缺省值。
3)路径:
虽然不可能做到穷举测试,但要设计测试用例查找由于不正确的计算(包括算法错、表达式的符号表示不正确、运算精度不够等)、不正确的比较或不正常的控制流(包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等)而导致的错误。
4)错误处理:
检查模块有没有对预见错误的条件设计比较完善的错误处理功能,保证其逻辑上的正确性。
5)边界:
注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。
4.4.1.2集成测试
集成测试也叫组装测试或联合测试(接口联调测试)。
通常,在单元测试的基础上需要将所有的模块按照设计要求组装成系统,这时需要考虑的问题:
1)在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失。
2)一个模块的功能是否会对另一个模块的功能产生不利的影响。
3)各个子功能组合起来,能否达到预期要求的父功能。
4)全局数据结构是否有问题。
5)单元模块的误差累积起来,是否会放大,从而达到不能接受的程度。
4.4.1.3系统测试
系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一致,主要是下列类型的测试:
1)用户界面测试:
测试用户界面是否具有导航性、美观性、行业或公司的规范性、是否满足设计中要求的执行功能。
2)功能测试:
验证功能实现是否满足客户需求。
3)性能测试:
测试相应时间、事务处理效率和其他时间敏感的问题。
4)可靠性测试:
测试系统对数据有效性检查能力和抵御误操作的能力。
5)容量测试:
测试大量数据对系统的影响。
6)容错性测试:
测试软件系统克服软件、硬件故障的能力。
7)数据安全测试:
测试系统在出现异常情况下,是否可以保护数据不丢失;
测试系统能否可以进行数据库的备份和恢复。
8)易用性测试:
重点关注系统的易理解性、易操作性、易学性。
9)安装部署测试:
确保软件系统在所有可能情况下的安装效果和一旦安装部署之后必须保证正确运行的质量。
4.4.2测试管理
4.4.2.1组织机构
测试经理
测试人员
项目经理
项目负责人
开发人员
4.4.2.2角色职责
职责
-负责与项目经理沟通,进行测试的整体策划、制定测试计划、组织测试实施、分析测试结果,控制测试进度和Bug清除率。
测试员
-负责检查测试环境、测试版本、编写并执行测试大纲、测试用例、报告缺陷、验证修改结果,进行测试数据统计,提交测试报告。
-负责与测试经理沟通,参与测试的整体策划、提供测试依据等相关材料;
介绍系统功能,负责测试组与开发组间协调。
程序员
-按时部署测试环境、数据,提交可测试的软件版本,协助测试员编写用例,及时修改缺陷、填写修改记录。
QA工程师
-对测试过程、测试结果进行规范性检查
-评价测试结果
4.4.2.3测试安排
总体测试时间:
2016年9月1日—2016年11月13日。
第一阶段测试:
2016年9月1日—2016年10月9日,开发人员编写代码,完成系统功能开发,并对完成的功能模块进行单元测试、集成测试;
第二阶段测试:
2016年10月10日—2016年10月25日,测试组对项目的软件系统进行功能测试,由开发人员完成所有问题的修改。
第三阶段测试:
2016年10月26日—2016年11月4日,测试组进行性能测试并完成问题修改。
4.4.2.4测试步骤
具体测试步骤:
1、对整体流程进行测试,保证系统整体业务流程可以走通。
2、对整体业务流程中的分支流程进行测试,保证系统业务分支流程可以走通。
3、各业务系统流程测试
4、各子系统功能点测试。
5、覆盖性测试。
6、系统性能测试。
回归测试贯穿每个测试阶段。
系统整体流程如下说明:
1、基础数据由数据采集系统从进出口相关执法部门采集,包括涉毒信息、旅客信息、航班信息等,形成基础数据。
2、系统进行数据收集存储、数据加工处理、主题数据建立等处理,进行主数据转换加载与业务数据转换加载,产生中间过程数据,具有时间戳和更新标记。
3、对集成数据进行分析,满足实时查询与统计需要,形成统计报表。
4、动态数据仓库存放风险数据、预警数据。
5、对预警数据进行评分、排名并设置消息推送。
4.4.2.5测试管理工具
工具名称:
Bugfree3.0
来源:
官方网站
功能:
测试用例、缺陷管理,自动统计测试结果
4.4.2.6缺陷处理流程
Bugfree3.0规定缺陷有三种状态(见[表-1])、七种解决方案(见[表-2])。
[表-1]缺陷有三种状态
缺陷状态
Active(激活)
Bug的初始状态。
任何新建的Bug状态都是Active。
可以通过编辑功能修改Bug的内容,并指派给合适的人员解决。
Resolved(解决)
解决中或解决完毕状态。
Closed(关闭)
已修复Bug、或解决方案(见[表