软件测试管理规范

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件测试工作规范

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 性能测试

相关文档
最新文档