项目测试规范流程.docVIP

软件工程测试标准流程

奥尊公司测试部

2012年9月

修订历史记录

日期

变更版本

变更描述

作者

2012/9/13

新增

王志芳

目录

TOC\o1-3\h\z1．概述 4

1．1软件测试的目的 4

1．2软件测试的原那么 4

1．3对软件测试的错误认识 4

2．软件测试过程 6

2．1测试过程 6

2．2角色与职责 9

3．关键活动定义 11

3．1测试准备 11

3．2测试方法设计 11

3．3测试方案 11

3．4方案评审 1211

3．5文档评审 12

3．6测试用例及评审 12

3．7环境准备 12

3．8测试执行 1312

3．9缺陷汇报/分析 13

3．10回归测试 13

3．11随机/异常测试 1413

3．12阶段报告 1413

3．13测试报告 14

4．测试文档简述 14

4．1开发转测试确认表 1514

4．2需求变更控制文档 15

4．3问题修复清单 1615

4．4测试方案 1615

4．5测试脚本〔用例〕 1615

4．6问题报告 1615

4．7缺陷分析文档 16

4．8测试报告文档 16

概述

软件测试的目的

软件测试是为了发现错误而执行程序的过程

测试是为了证明程序有错误，而不是证明程序无错误

一个好的测试用例是在于它能发现至今未发现的错误

一个成功的测试是发现了至今未发现的错误的测试

软件测试的原那么

软件测试的原那么之一：GoodEnough

这是一种权衡投入／产出比的原那么，测试既不要不充分，也不要过分。不充分和过分都是一种不负责任的表现。

Zero-bug是一种理想，Good-enough是我们的原那么。

软件测试的原那么之二：EarlyBest

越早发现错误，因错误而导致的损失就越小；所以测试工作必须贯穿软件开发的整个生命周期，以期尽早发现软件中的错误。那些认为只需在软件开发完成后再进行系统测试的观点是错误的。

软件测试的原那么之三：bug的80%原那么

一般情况下，在分析、设计、实验阶段的复审和测试工作能够发现和防止80%的bug，而系统的软件测试能够找出其余bug中的80%。最后约5%的bug只有在用户大范围、长时间的使用后才会暴露出来。

因此测试只能保证尽可能多地发现错误，不能保证发现所有的错误。

对软件测试的错误认识

对测试的错误认识〔一〕：完整的测试是可能的

——在实际操作中，完整的测试是不可能的。

——从理论上说，完整的测试也是不可能的。

对测试的错误认识〔二〕：存在一个可以定义的测试终结点

——测试通常是在时间用完时结束

——测试是一份令人厌倦的工作

对测试的错误认识〔三〕：测试和调试没有什么区别，除了支持调试外，测试没有别的目的

——测试是查找潜在的错误，调试是定位的错误

——测试贯穿于整个软件生存期，调试主要是在软件开发过程中

——测试是发现问题，调试解决问题

——测试与调试不能相互替代，但可相互支持，相辅相成

对测试的错误认识〔四〕：测试是件很简单的工作，无需设计

——测试是一项具有很大创造性的工作，其工作量一点也不比代码设计小

——测试是需要设计的，一个好的测试方案或方案往往能到达事半功倍的效果

——测试设计可以是自动的，半自动的或手工编写

软件测试过程

测试过程

对需要测试的任何产品，都需要有一个测试的进入标准、测试执行的开始标准、测试执行的结束标准以及测试执行好坏的评价标准。本文所定义的测试流程，也遵循这么一条根本主线，其过程主要包括测试的进入、执行、报告、分析、结束。测试的进入往往是在需求分析即将结束时进行的，这样测试过程与开发过程根本同步，有助于尽早发现系统设计的问题；这样做的另一好处还在于测试准备充分，开发结束可立即进入测试阶段，有助于缩短工程进度。测试执行前的准备工作对于测试来说是至关重要的，这些准备工作主要包括从系统需求分析报告和概要设计文档里面获取产品信息及产品功能特点，并对此进行相关的分析、总结，然后进行测试设计：包括选择测试方法，确定测试内容、测试工具，结合产品特点确定是否进行性能、负载、压力、平安等方面内容的测试；制定测试方案；制定详细测试执行方案及设计测试案例。

下列图是测试过程的结构层次图，通过这个图，我们可以看到整个产品从需求到产品交付的过程中，测试和开发之间的关系以及对应的测试过程。

开发过程

开发过程

需求分析

需求分析

系统设计

系统设计

编码

编码

单元测试

集成测试

测试用例

测试用例

测试用例及评审文档评审环境准备

测试用例及评审

文档评审

环境准备