软件测试作业流程标准规范.docx

软件测试步骤规范
一、 通读项目需求设计文档
1. 测试准备阶段；
2. 仔细阅读《软件需求规格说明书》；
3. 依据测试手册，做前期测试准备；
二、 明确测试任务范围
⑴功效测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试；
⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试；
⑾恢复测试；⑿文档测试；⒀可用性测试；
三、 学习了解被测试软件
由开发人员组织讲解所要实施测试软件或产品，测试人员必需认真了解拿到手中待测试软件或产品。
四、 制订测试计划
“工欲善其事，必先利其器”。软件测试必需以一个好测试计划作为基础。作为测试起始步骤和关键步骤。测试计划应包含：产品基础情况调研、测试策略、测试纲领（功效模块测试、具体测试、高级测试）、测试内容（界面测试、测试需求说明）、测试人力资源配置、测试计划变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪汇报、测试经过准则、测试计划评审意见等。另外还包含测试计划目标、测试对象信息、测试计划使用范围及测试参考文档。
1. 项目介绍；
对产品（项目）一个了解和概述，关键对产品（项目）功效简述。
2. 测试背景；
产品在那种情况下开始研发，实施测试，交待为何而测试产品背景。
3. 测试手段\环境；（手工和自动化工具）
测试环境

测试辅助工具

4. 测试类型（方法）；（黑盒测试）
⑴功效测试；⑵界面测试；⑶接口测试；⑷容错测试；⑸负载测试；
⑹安全测试；⑺性能测试；⑻稳定性测试；⑼配置测试；⑽安装测试；
⑾恢复测试；⑿文档测试；⒀可用性测试；
5. 测试资源；
⑴人力资源⑵系统资源
人员
角色
职责、任务
时间

6. 测试策略\测试需求\测试任务\测试点；
针对测试需求定义测试类型、测试方法和需求测试工具等。
①对于每种测试，全部应提供测试说明，并解释其实施原因。
②制订测试策略时所考虑关键事项有：将要使用技术和判定测试何时完成标准。
③下面列出了在进行每项测试时需考虑事项，除此之外，测试还只应在安全环境中使用已知、有控制数据库来实施。
④不实施某种测试，则应该用一句话加以说明，并陈说这么理由。比如，“将不实施该测试。该测试本项目不适用”。

7. 测试工作计划表；
No
工作内容
开始时间
结束时间
责任人
提交结果
备注

五、 设计测试用例
测试用例关键起源为：1）需求说明书及相关文档2）相关设计说明（概要设计，具体设计等）3）和开发组交流对需求了解统计（能够是开发人员一个解释）4）已经基础成型UI（能够有针对性地补充部分用例）
从所得到资料中，分解出若干小“功效点”，了解“功效点”，编写对应测试用例。
l 测试用例模板（Excel）：
项目名称
程序版本
功效模块名
用例编号
编制人
编制时间
论坛

功效特征

测试目标

参考信息

预置条件

特殊规程说明

参考信息

测试用例
基础流
序号
名称
说明
1

2

备选流
序号
名称
说明
1

2

相关用例
无
测试场景

序号
名称
说明

测试数据

测试数据集1：
序号
操作描述
数据
预期输出
实际输出
测试状态（P/F）
1

P
2

P
测试人员

开发人员

项目责任人

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

内存：

硬盘：

数据库：

IE/版本：

服务器：

平台：

操作系统/版本：

七、 搭建测试环境
统计下配置环境，常见软件均要安装，
八、 实施测试（集成测试、系统测试、验收测试）和优先级控制
集成测试：也叫组装测试或联合测试。在单元测试基础上，将全部模块根据设计要求（如依据结构图〕组装成为子系统或系统，进行集成测试。实践表明，部分模块即使能够单独地工作，但并不能确保连接起来也能正常工作。程序在一些局部反应不出来问题，在全局上很可能暴露出来，影响功效实现。
集成测试应该考虑以下问题：
　　1、在把各个模块连接起来时候，穿越模块接口数据是否会丢失；
　　2、各个子功效组合起来，能否达成预期要求父功效；
　　3、一个模块功效是否会对另一个模块功效产生不利影响；
　　4、全局数据结构是否有问题；
　　5、单个模块误差积累起来，是否会放大，从而达成不可接收程度。
　　所以，单元测试后，有必需进行集成测试，发觉并排除在模块连接中可能发生上述问题，最终组成要求软件子系统或系统。对子系统，集成测试也叫部件测试。
任何合理地组织集成测试，即选择什么方法把模块组装起来形成一个可运行系统,直接影响到模块测试用例形式、所用测试工具类型、模块编号和测试次序、生成测试用例和调试费用。通常，有两种不一样组装方法：一次性组装方法和增值式组装方法。
九、 提交缺点汇报
BUG单模板简版主表
BUG编号：
被测系统名称：

被测系统版本号：

被测模块：

测试阶段：

BUG类型：

测试人员：

BUG严重性：

测试日期：

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注释，将其状态置为已处理
1. 查看bug，确定是bug，进行修正，并注明原因
2. 对不属于自己模块bug指派其它人修改
3. 对延迟处理bug标注确定
4. 需要讨论bug，将其状态置为公认
经理：查看测试人员提交bug，确定要修改，添加注释，指派和修改人员
1. 需要讨论bug，将其状态置为公认
2. 对不做修改bug，将其关闭
管理员： 对项目、人员进行管理维护，定时备份数据库
1. 对于反复汇报bug，查看汇报时间，将汇报晚删除
2. 对因为配置、数据库未更新将其删除
十、 测试退出准则
1. 系统满足需求规格说明书要求
2. 根据测试计划完成了系统测试
3. 测试用例实施覆盖率达成100%
4. 测试需求覆盖率达成100%
5. Block，Crash，Major级缺点修复率达成100%
6. Minor，Trivial级缺点修复率达成80%
7. Text，Suggestion， Feature级缺点修复率达成75%
8. 程序能够处理要求负载
9. 系统在要求硬件和软件平台上工作正常。

十一、 编制测试汇报
测试汇报是把测试过程和结果写成文档，并对发觉问题和缺点进行分析，为纠正软件存在质量问题提供依据，同时为软件验收和交付打下基础。测试汇报基于测试中数据采集和对最终测试结果分析。包含：测试实施情况（测试组织、测试时间、测试版本）、覆盖分析（需求覆盖、测试覆盖）、缺点统计图表（测试管理工具自动生成多种图表）和分析（缺点汇总、缺点分析、残留缺点和未处理问题）、测试结论及提议、测试环境和配置、测试工具、测试汇报评审意见等。另外还包含测试汇报目标、测试对象信息、测试汇报使用范围及测试参考文档。
十二、 测试评审
项目经理审批意见：

签字
日期
出示一份《测试评审汇报》
十三、 编写用户手册
《用户手册》编写，是直接指导用户进行使用软件产品向导，所以《用户手册》编写必需规范，简练，易懂。使用户在很短时间内了解和使用我们产品。