文档介绍：测试体系建设 与
软件测试流程 (初稿
北京天阳宏业软件技术有限公司
修改历史
“更改请求号”为文档正式发布后需要变更时的编号,编号方法待定。 正式批准
1. 目的 ..........................陷的状态, 直至缺陷的验证关闭。 在测试执行过程中发现的 遗漏测试用例必须补充至测试用例,保证测试用例与实际测试的一致性。 开发人员:对于测试人员提交的缺陷进行确认、修复。
开发经理:对测试人员与实际开发人员意见不一的问题进行裁决。
测试用例编写完成 且 用例评审完成
输入:功能测试用例
输出:功能测试缺陷
为集成测试提供测试依据,记录并保证集成测试覆盖度;
依据 《测试计划》 及性能指标制定性能测试计划、 性能测试用例设计、 性能测试脚本开 发,保证性能测试有序进行。
测试人员:以整个软件为对象, 确保新功能、 老功能、 新老功能接口正确进行用例设计; 依据性能指标及测试计划对性能测试进行计划、 以及性能测试用例 /脚本的开 发。
功能测试完成 且 软件功能无中断
输入:《功能测试用例》 、功能测试缺陷、 《测试计划》 、性能指标
输出:《集成测试用例》 、 《性能测试计划》 、 《性能测试用例》 、性能测试脚本
《集成测试用例》实际内容参见《集成测试用例模版》 ;
《性能测试计划》实际内容参见《性能测试计划模版》 。
以整个软件为对象, 以测试计划为指导, 按照集成测试测试用例对新功能、 老功能、 新
老功能接口进行测试和性能测试,保证测试的全面性和完整性。
测试人员:以整个软件为对象,以测试计划为指导,按照集成测试测试用例对新功能、 老功能、 新老功能接口进行测试, 并依据性能测试计划对软件性能进行测试。
集成 /性能测试设计完成
输入:《集成测试用例》 、 《测试计划》之集成测试事项、 《性能测试计划》 、 《性能测试用 例》
输出:集成测试缺陷
测试执行过程需按照《测试行为规范》进行,缺陷管理需按照《缺陷管理规范》进行。
保证对客户的指导与实际系统的使用状况相一致。
测试人员:对《用户操作手册》及在线帮助进行测试,记录文档描述缺陷,并跟踪直至 缺陷的验证关闭。
需求人员:对测试人员提出的文档描述缺陷进行修正。
《用户操作手册》或在线帮助编写完成
输入:《用户操作手册》 、在线帮助 输出:文档缺陷
参见《文档测试指南》
真实、客观反映测试过程中各测试阶段、测试项的情况,并将结果进行数字化 /图像化 进行分析,真实反映软件质量实际情况。
测试负责人:真实、客观地对测试过程中各测试阶段、测试项的情况,并以数字 /图像 的形式对实际情况进行分析,真实反映软件实际测试状况。
集成测试完成
输入:各测试阶段、测试项实际测试情况
输出:《项目测试报告》
项目测试报告实际内容参见《项目测试报告模版》
5. 缺陷管理
概述
适用于功能测试有关工作,功能测试中的缺陷要求全部采用 QC 进行管理。
QC :QC (Quality Center ,也被称为 MQC (Mercury Quality Center 。不仅可以在一 个项目组内进行质量控制和管理,也可以在跨地域的不同项目组内部进行质量控制和管理, 从而可以保证应用系统的质量。 通过在整个应用系统中提供并集成了测试的需求管理、 案例 管理、缺陷管理等, QC 可以地加速测试过程执行。
缺陷状态关系示意图
缺陷流转的过程及处理
参与缺陷流转的角色有三个:测试经理、测试人员和开发人员。
缺陷的处理步骤如下:
北京天阳宏业软件技术有限公司 缺陷严重程度：是指因缺陷引起的故障对系统的影响程度。由提出人初步指定，开发人 员负责确认。 包括：严重、一般、轻微 缺陷紧急程度：指缺陷必须被修复的紧急程度。由提出人指定。各测试小组可以项目组 具体协商约定紧急程度的具体含义。 包括：高、中、低 缺陷起源：指引起缺陷的起因。 包括：需求、架构、设计、编码、测试、环境、数据、拒绝 缺陷起 含义 源类型 需求 由于需求定义或需求分析引起的缺陷 架构 由于企业架构设计的问题引起的缺陷 设计 由于本系统设计原因引起的缺陷 编码 由于编码的问题引起的缺陷 测试 由于测试人员在测试设计、测试操作或理解有误等原因引起的缺陷 环境 由于测试环境的问题引起的缺陷 数据 由于测试数据的问题引起的缺陷 重复。表示该缺陷已经被其它提交人找出来了（‘纯粹’重复），或者开发认为原因是相同的 （但从测