软件测试流程规范

软件测试流程规范

一、通读项目需求设计文档

1.测试的准备阶段；

2.仔细阅读《软件需求规格说明书》；

3.根据测试手册，做前期的测试准备；

二、明确测试任务的范围

⑴功能测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试；

⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试；

⑾恢复测试；⑿文档测试；⒀可用性测试；

三、学习理解被测试软件

由开发人员组织讲解所要执行测试的软件或者产品，测试人员必须认真理解拿到手中待测试的软件或者产品。

四、制定测试计划

“工欲善其事，必先利其器”。软件测试必须以一个好的测试计划作为基础。作为测试的起始步骤和重要环节。测试计划应包括：产品基本情况调研、测试策略、测试大纲（功能模块的测试、详细测试、高级测试）、测试内容（界面测试、测试需求说明）、测试人力资源配置、测试计划的变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪报告、测试通过准则、测试计划的评审意见等。另外还包括测试计划的目的、测试对象信息、测试计划使用的范围及测试参考文档。

1.项目简介；

对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。

2.测试背景；

产品在那种情况下开始研发，执行测试，交待为何而测试产品的背景。

4.测试类型（方法）；（黑盒测试）

⑴功能测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试；

⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试；

⑾恢复测试；⑿文档测试；⒀可用性测试；

5.测试资源；

6.测试策略\测试需求\测试任务\测试点；

针对测试需求定义测试类型、测试方法以及需求的测试工具等。

①对于每种测试，都应提供测试说明，并解释其实施的原因。

②制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。

③下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已

知的、有控制的数据库来执行。

④不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如，“将不实施该测试。

该测试本项目不适用”。

7.测试工作计划表；

No工作内容开始时间结束时间责任人提交的结果备注

五、设计测试用例

测试用例的主要来源为：1）需求说明书及相关文档2）相关的设计说明（概要设计，详细设计等）3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）4）已经基本成型的UI（可以有针对性地补充一些用例）

从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。

项目名称程序版本功能模块名用例编号编制人编制时间

论坛

功能特性

测试目的

参考信息

预置条件特殊规程说

明

参考信息

测试用例

基本流

序号名称说明1

2

备选流

序号名称说明1

2

相关的用例无

测试场景

序号名称说明

六、确定软件测试软硬件环境

七、搭建测试环境

记录下配置环境，常用软件均要安装，

八、执行测试（集成测试、系统测试、验收测试）与优先级的控制

集成测试：也叫或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独

地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的

问题，在全局上很可能暴露出来，影响功能的实现。

集成测试应该考虑以下问题：

1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

2、各个子功能组合起来，能否达到预期要求的父功能；

3、一个模块的功能是否会对另一个模块的功能产生不利的影响；

4、全局数据结构是否有问题；

5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。

因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。对子系统，集成测试也叫部件测试。

任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。

九、提交缺陷报告

BUG优先级：

BUG概要：

BUG详情

测试路径导航：

操作描述：1. 2. ……

结果描述：

修改建议：

附件：（可选）

备注：

(以上内容由具体测试人员填写)

BUG状态:BUG结论:

BUG原因:处理人员:

处理方法:处理日期:

BUG处理意见: (以上由BUG的修复人员填写，通常是具体的研发人员)

Bug单附表环境

CPU：内存：

硬盘：数据库：

IE/版本：服务器：

平台：操作系统/版本：

Bug状态说明：

新建：测试人员报告bug的状态

已指派：测试人员分配bug的状态

已解决：修改人员修改bug的状态，在解决bug界面准确标注bug的完成度

已确认：修改人员对暂时不能、以后修改的bug进行确认的状态

反馈：测试人员对开发人员认为不修改、但测试人员需要修改的bug的反馈给经理的状态

公认：经理查看反馈的bug后认为需要修改，则标示bug的状态为公认，认为不做修改，直接关闭此bug，注明原因

已关闭：测试人员对修正后的bug进行回归测试后，确认bug已修正即可关闭bug状态

注：BUG级别说明

A（严重级）：操作系统或者网络瘫痪；

B（中等级）：应用程序崩溃、非法退出或功能模块无法实现。

C（一般级）：篡改设计；功能实现错误或功能不完善，容错失败、数据逻辑关系错。

D（允许级）：界面布局；操作不方便；建议性修改。

职责：

测试人员：准确定位bug，新建bug，指派bug与开发人员

1.对修正后的bug进行验证，确认修正后将其关闭

2.通过验证，bug仍然存在，重新指派给开发人员

3.对修改人员认为不需要修改，而测试人员认为要修改的bug，反馈与经理

4.对已关闭的bug以后又浮现，将其重新打开，指派与原开发人员

研发人员：查看指派给自己的bug，准确选择bug的完成度，添加bug注释，将其状态置为已解决