软件项目测试管理规范.docVIP

软件测试规范管理V1.1

PAGE

第PAGE6页共NUMPAGES10页

软件项目测试规范管理V1.1

软件项目测试管理规范

（V1.1）

修订历史记录

日期

版本

作者

审核者

说明

2023-3-6

V1.1

**

初稿

目录

TOC\o1-2\h\z\u1. 概要 3

1.1. 目的 3

1.2适用范围 3

1.3术语、名词定义 3

2. 测试职责 3

3. 测试流程图 4

4. 测试申请 4

4.1项目初期 4

4.2迭代功能开发 5

5. 测试准备 5

5.1文档分析 5

5.2测试计划 5

5.3测试用例 6

5.4测试软/硬件环境 6

5.5测试数据准备 6

6. 测试执行 7

6.1测试准入条件 7

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.2适用范围

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

1.3术语、名词定义

1.3.1开发文档

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

1.3.2测试文档

测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护。

1.3.3缺陷等级说明

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

2）B类：严重缺陷，系统的主要功能部分丧失、数据不能完整保存，系统的次要功能完全丧失，系统所提供的服务和功能受到明显的影响

3）C类：一般缺陷，系统的次要功能没有完全实现，但不影响用户的正常使用

4）D类：较小缺陷，界面错误、菜单布局不合理，提示不准确等，在使用过程中跟用户带来一定的不方便和操作难度

5）E类：建议缺陷，对网站使用的友好性有影响，如拼写错误、界面布局、文档的可读性、操作的一致性等

测试职责

测试是软件开发过程中的重要组成部分，肩负着如下责任：

在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。

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

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

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

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

测试流程图

参与需求分析，了解项目需求内容

参与需求分析，了解项目需求内容

制定项目计划

制定项目计划

制定测试计划

制定测试计划

编写测试用例

编写测试用例

回归问题单

回归问题单

执行测试用例

执行测试用例

提交bug

提交bug，开发进行修改

修改补充测试用例

修改补充测试用例

提交测试总结报告

提交测试总结报告

测试申请

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

4.1项目初期

项目立项初期时需提交《需求文档》、《概要设计》、《详细设计》、《开发进度表》

4.2迭代功能开发

开发组提交《送测表》，其中包括可测试内容和测试注意事项

研发人员提交送测表

研发人员提交送测表

测试人员根据测试表以及关键用例进行冒烟测试

测试人员根据测试表以及关键用例进行冒烟测试

返回开发进行修改冒烟测试是否通过

返回开发进行修改

冒烟测试是否通过

否

正式进入测试，执行测试用例，编写测试报告，提交bug至缺陷库

正式进入测试，执行测试用例，编写测试报告，提交bug至缺陷库

测试完毕提交报告给开发

测试完毕提交报告给开发

开发人员修改bug

开发人员修改bug，更新缺陷库，重新送测

测试回归问题单

测试回归问题单

迭代功能测试流程图

测试准备

5.1文档分析

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