软件测试规范管理V11.docx

软件测试规范管理V11.docx

《软件测试规范管理V11.docx》由会员分享，可在线阅读，更多相关《软件测试规范管理V11.docx（9页珍藏版）》请在冰豆网上搜索。

软件测试规范管理V11

软件测试规范管理

（V1.1）

修订历史记录

日期

版本

作者

审核者

说明

20123-3-6

V1.1

**

初稿

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.标准文档

《测试申请单》

《送测表》

《测试计划》

《测试用例》

《测试报告》