软件测试规范管理V11

软件测试规范管理
（V1.1）
修订历史记录
目录
1.概要 (3)
1.1.目的 (3)
1.2适用范围 (3)
1.3术语、名词定义 (3)
2.测试职责 (3)
3.测试流程图 (4)
4.测试申请 (4)
4.1项目初期 (4)
4.2迭代功能开发 (4)
5.测试准备 (5)
5.1文档分析 (5)
5.2测试计划 (5)
5.3测试用例 (6)
5.4测试软/硬件环境 (6)
5.5测试数据准备 (6)
6.测试执行 (6)
6.1测试准入条件 (6)
6.2项目测试阶段 (7)
6.3测试退出标准 (7)
6.4测试变更 (7)
7.缺陷管理 (8)
7.1缺陷管理流程 (8)
7.2提交缺陷 (8)
7.3分配缺陷 (8)
7.4修改缺陷 (8)
7.5关闭缺陷 (9)
7.6保留缺陷 (9)
8.测试结果分析 (9)
9.约定 (9)
10.标准文档 (10)
1.概要
1.1.目的
本文档是测试和开发团队的日常工作规范，主要侧重测试工作流程的控制，明确软件工程的各阶段测试应完成的工作以及开发应提供的文档。

1.2适用范围
本过程适用于软件测试过程中所有活动，即适用于参与项目的所有开发和测试人员。

1.3 术语、名词定义
1.3.1 开发文档
开发人员提供给测试人员的开发文档至少包括以下几种：需求文档，概要设计，详细设计，用户手册等。

1.3.2 测试文档
测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。

测试文档由测试人员编写并维护。

1.3.3 缺陷等级说明
1）A类：致命缺陷，最严重的等级，缺陷会导致网站任何一个主要功能完全丧失，用户数据受到破坏、系统崩溃、死机等。

2）B类：严重缺陷，系统的主要功能部分丧失、数据不能完整保存，系统的次要功能完全丧失，系统所提供的服务和功能受到明显的影响
3）C类：一般缺陷，系统的次要功能没有完全实现，但不影响用户的正常使用
4）D类：较小缺陷，界面错误、菜单布局不合理，提示不准确等，在使用过程中跟用户带来一定的不方便和操作难度
5）E类：建议缺陷，对网站使用的友好性有影响，如拼写错误、界面布局、文档的可读性、操作的一致性等
2.测试职责
测试是软件开发过程中的重要组成部分，肩负着如下责任：
•在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。

•编写合理的测试计划，并与项目整体计划有机地整合在一起。

•编写覆盖率高的测试用例。

•针对测试需求进行相关测试技术的研究。

•认真仔细地实施测试工作，并提交测试报告供项目组参考。

3.测试流程图
4.测试申请
开发组向测试负责人提交《测试申请表》，该文档要说明：申请测试人员数量，进行哪些功能的测试，需要提交哪些测试文档，测试周期，测试环境要求。

4.1项目初期
项目立项初期时需提交《需求文档》、《概要设计》、《详细设计》、《开发进度表》
4.2 迭代功能开发
开发组提交《送测表》，其中包括可测试内容和测试注意事项
迭代功能测试流程图
5.测试准备
5.1文档分析
测试人员和开发人员均应参加需求评审、设计评审。

对《需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审查，与产品经理、项目经理沟通，根据系统功能复杂度，系统业务复杂度估算开发时间和有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。

通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。

5.2测试计划
根据需求文档和项目计划制定测试计划。

测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。

测试计划在策略和方法方面说明如何计划、组织和管理测试项目。

测试计划完成后应该在项目组内进行评审。

5.3测试用例
测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

解决要测什么、怎么测和如何衡量的问题。

依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发现需求与设计中的问题后，与需求作者及时沟通确认。

5.3.1测试用例设计方法
测试用例的设计方法有等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试。

在设计测试用例时常用的设计方法有等价类测试、边界值分析两种方法。

5.3.2测试用例操作步骤
1、在设计编写测试用例时，首先要从测试用例库中选择相应功能的测试用例，在原有
测试用例的基础上依据系统需求文档对测试用例的进行修改、更新，评审通过后将
使用该测试用例测试被测系统。

2、在测试的执行过程中和进行回归测试后，对已设计的测试用例进行维护更新。

5.3.3测试用例选择准则
测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等；
测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的；
测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。

5.4测试软/硬件环境
根据需求文档提供的内容，和开发部沟通确定测试项目所需的软硬件环境，完成对测试项目所需软硬件资源的准备工作，使软硬件资源得到满足。

5.5测试数据准备
完成对测试项目基本数据的准备操作，包括数据库连接、用户信息、用户角色权限、单位组织等信息和测试相关的测试数据。

6.测试执行
6.1测试准入条件
1、不接受无详细需求文档和开发说明的项目
2、需要测试的项目至少提前2个工作日提交测试进行需求分析
3、开发人员经过自测通过，至少保证程序可以正常运行；对应的功能在正常流程下是
可以正常使用
6.2 项目测试阶段
测试人员依据测试计划和测试用例进行测试活动。

测试一般分为两个阶段：
1、测试执行阶段：该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。

2、回归问题单：开发修改完bug之后，测试进行验证回归。

6.3 测试退出标准
1、测试对可回归缺陷的回归率达到100%。

2、全部的测试用例集执行完毕。

3、缺陷处理达到100%。

6.4测试变更
当需求变更，功能变化，测试人员根据变更情况，评估测试变更所需时间，提出变更风险。

如变更情况被项目组通过，测试人员将按上述流程进行变更测试。

7.缺陷管理
7.1缺陷管理流程
7.2提交缺陷
测试人员将缺陷填写到缺陷管理库中，将缺陷分配给为开发组长或相应的开发人员。

7.3分配缺陷
开发人员分别对自己收到的缺陷进行评审。

评审后如果对提交的缺陷有疑问，可以与提交人协商。

对未能达成一致的缺陷由项目经理组织项目组成员评审。

评审人员可以是项目组人员。

如果缺陷初次分配的开发人员无法修改该缺陷，初次分配的开发人员可以将缺陷再次分配给其他开发人员。

如果开发对测试提出的bug不理解或者不能重现时，可以要求测试复现bug。

7.4修改缺陷
开发人员对已确认的缺陷进行修改，填写修改记录，修改缺陷状态为“已修改”或其他状态。

修改完后开发应对修改后会影响的其他功能模块做个说明，还需对缺陷产生的原因
和解决方法做个备注，以便日后追溯。

开发人员认为该缺陷可以不予修改或者不是缺陷的，可与测试人员协商后将状态改为“已否决”或由测试人员直接关闭缺陷。

并要注明原因。

7.5关闭缺陷
测试人员对已修改的缺陷进行验证。

如果已修改完成，测试人员将缺陷状态设置为关闭。

如果没有修改或引起回归问题，将修改缺陷状态为“重新打开”或新增缺陷，由开发人员继续修改。

7.6保留缺陷
对于有争议的缺陷进行，将有项目经理最终决定是否修改。

如果缺陷是由于技术原因、版本原因等不能修改，则保留该缺陷并加以注释。

8.测试结果分析
测试结果分析是对测试结果的一个综合评估，主要描述有测试中各个等级的缺陷数量，缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量等情况。

测试报告由测试人员编写并提交给项目经理。

测试报告需要经项目组评审通过。

9.约定
就测试与开发人员就测试过程中的交互，约定如下：
1.每次迭代开发后的正式送测必须编写送测表。

2.如送测后的功能执行关键测试用例不能通过，则测试人员有权利中止测试。

待开发修改
完并自测确定无阻塞性问题后再提交测试。

3.测试人员测试过程中，必须依据所有的BUG都体现在测试报告中的原则，保证所发现的
BUG都已添加到测试报告中。

4.测试人员测试完毕后，必须通知相关的负责人及程序人员。

5.开发人员必须明确写明BUG引起的原因及解决方法，以方便以后做追溯。

6.开发人员如对测试人员所填写的BUG不理解或不能重现，可请求测试人员解释或重现，
而不能直接拒绝修改。

7.在修改送测功能时，开发人员做的任何代码上的改动（非针对明确写出的BUG时），都
必须同时通知测试人员，以便进行针对性的回归测试。

10.标准文档
《测试申请单》
《送测表》
《测试计划》
《测试用例》
《测试报告》。