软件测试工作规范
1 目的
统一公司所有项目的软件测试流程；
提供一套适合公司所有项目并可裁减的软件测试工具；
2 范围
本规范中单元测试适用于所有的JAVA项目；
本规范中集成测试、系统测试和性能测试适用于所有项目。

3 测试阶段与软件开发阶段的对应关系
1 过程描述
1.1 单元测试活动
该活动包括以下环节：
● 编写单元测试计划；
● 设计单元测试用例；
● 执行单元测试过程；
● 记录单元测试缺陷；
● 编写单元测试报告；
1.1.1 活动目的
验证软件系统模块内功能、容错、界面和报表测试和桩模块、子模块之间的接口测试。

1.1.2 角色与职责
1.1.3 测试范围
● 单元模块的功能性测试
● 单元模块内和模块之间的接口测试
● 单元模块的容错性测试
● 单元模块的界面测试
● 单元模块内的权限
1.1.4 进入条件
已经完成被测模块的编码工作
1.1.5 输入
《详细设计说明书》
1.1.6 活动说明
对于结构化的编程语言，程序单元指程序中定义的函数或子程序。

单元测试是指对
函数或子程序所进行的测试。

对于面向对象的编程语言，程序单元指特定的一个具体的类或相关的多个类。

单元模块之间的接口等。

（1）开发人员依据详细设计编写单元测试计划和和单元测试用例，《详见junit使用说明》和《jprobe使用说明》，需详细描述该用例的输入、输出和预期结
果等相关内容；
（2）开发人员编写程序代码；
（3）开发人员执行单元测试用例，并记录执行结果；
（4）开发人员执行测试用例过程中发现的缺陷，必须提交到缺陷跟踪工具中；
（5）开发组长完成单元测试后，编写单元测试分析报告，项目经理审核《单元测试分析报告》。

1.1.7 输出
已通过回归测试、打标签单元级的代码
《单元测试分析报告》
1.1.8 退出条件
● 被测代码语句覆盖率满足单元测试计划中制定的代码覆盖率要求；
● 测试用例执行覆盖率应达100%；
● 《单元测试分析报告》通过评审；
● A类缺陷、B类缺陷、C类缺陷为零，D类缺陷少于10％，E类缺陷少
于15％。

1.1.9 工具与方法
● JAVA项目
Junit 3.7以上版本：利用Junit提供的组件测试代码的功能逻辑；
Jprobe 5.0以上版本：使用Coverage 组件检查代码覆盖率。

● 工具使用
参见《Junit使用简明手册》，《Jprobe使用简明手册》。

1.2 集成测试活动
该活动包括以下环节：
● 编写集成测试计划；
● 设计集成测试用例；
● 执行集成测试过程；
● 记录集成测试缺陷；
● 编写集成测试分析报告；
1.2.1 活动目的
1.2.2 角色与职责
1.2.3 测试范围
● 系统集成后的功能性测试；
● 系统集成后的容错性测试；
● 系统集成后的界面测试；
● 系统集成后的安全（权限）测试；
● 系统集成后的系统的内部接口测试；
● 系统集成后的可用性测试；
● 系统集成后的数据完整性测试。

1.2.4 进入条件
《概要设计说明书》通过评审
1.2.5 输入
《概要设计说明书》
1.2.6 活动说明
（1）测试组长制定《集成测试计划》；
（2）测试人员负责组织编写集成测试用例，编写测试脚本，编写测试用例。

（3）测试人员执行测试用例。

（4）测试过程中发现缺陷提交到缺陷跟踪系统；
（5）架构师对缺陷进行评估并分发，若判断是缺陷则指定相关开发人员进行修改；
（6）开发人员修改完缺陷后，由测试人员进行回归测试，测试通过则缺陷关闭，检验未通过，则转给开发人员，继续修改；
（7）测试人员编写集成测试分析报告。

1.2.7 输出
● 已通过回归测试、打标签系统级的代码；
● 《集成测试分析报告》；
● A类缺陷、B类缺陷、C类缺陷为零，D类缺陷少于5％，E类缺陷
少于10％。

1.2.8 退出条件
《集成测试分析报告》通过评审
代码基线化
1.2.9 工具与方法
因具体项目而定
1.3 系统测试
该活动包括以下环节：
● 编写系统测试计划；
● 设计系统测试用例；
● 执行系统测试过程；
● 记录系统测试缺陷；
● 编写系统测试分析报告；
1.3.1 活动目的
通过与系统的需求规格作比较，从功能和非功能两方面，发现软件与系统需求规格不相符合或与之矛盾之处。

1.3.2 角色与职责
1.3.3 系统测试范围
● 系统的功能性测试；
● 系统的初始化测试；
● 系统的（负载，性能，并发）测试；
● 系统的配置测试；
● 系统的安全性测试（防火墙，TLS,SSL安全机制，加密）；
● 系统的外部接口测试；
● 系统的数据完整性测试；
● 系统的可用性测试；
● 系统的安装部署测试；
● 系统的恢复性测试；
● 系统的可移植性测试
● 系统的文档测试。

1.3.4 进入条件
● 《需求说明书》经过评审；
1.3.5 活动说明
（1）测试组长制定《系统测试计划》；
（2）测试组长负责组织编写系统测试用例、编写测试脚本，编写测试用例；（3）测试组长在架构师的协助下搭建与用户需求一致的测试环境，质量管理部配合确认测试环境，参见《系统环境确认单》；
（4）测试人员执行测试用例；
（5）测试过程中发现缺陷提交到缺陷跟踪系统；
（4）架构师对缺陷进行评估，若判断是缺陷则指定相关开发人员进行修改；（5）开发人员修改完问题后，由问题提出人进行回归测试，测试通过则缺陷关闭，检验未通过，则转给开发人员，继续修改；
（6）测试组长编写《系统测试分析报告》。

1.3.6 输出
已通过回归测试、打标签系统级的代码
《系统测试分析报告》
1.3.7 退出条件
● 系统测试报告通过评审；
● 代码基线化；
● A类缺陷、B类缺陷、C类缺陷为零，D类缺陷少于3％，E类缺陷少
于6％。

1.3.8 工具与方法
因项目的需求而定。

1.4 性能测试
该活动包括以下环节：
● 编写性能测试计划；
● 设计性能测试用例；
● 搭建性能测试环境；
● 执行性能测试过程；
● 记录性能测试缺陷；
● 编写性能测试报告；
1.4.1 活动目的
检查系统是否满足在需求说明书中规定的性能要求。

1.4.2 角色与职责
1.4.3 测试范围
性能测试的主要是范围：
● 系统的大用户压力；
● 系统的并发用户压力；
● 系统的数据库压力；
● 系统的稳定性等。

1.4.4 进入条件
《需求规格说明书》通过评审；
1.4.5 输入
《需求规格说明书》
1.4.6 活动说明
（1）测试组长根据《需求规格说明书》了解系统性能需求，编写《性能测试计划》；（2）测试人员在架构师的协助下搭建与用户需求一致的测试环境，质量管理部配合确认测试环境，参见《系统环境确认单》；
（3）测试人员根据系统的实际情况和使用的测试工具，制定《性能测试方案》，用以确定本次测试的具体方法和策略；
（4）当修改软件以纠正发现的问题时，测试人员需要进行回归测试以保证这些修改是否已经解决，是否带来新的问题；
1.4.7 输出
《性能测试分析报告》
1.4.8 退出条件
● 《性能测试分析报告》通过评审；
● 性能指标（平均响应速度、吞吐量、系统用户的压力等）满足用户需求。

1.4.9 工具与方法。