第三课 软件测试过程管理办法.doc

软件测试过程管理办法 （V0.2） 修订历史记录 日期 版本 作者 审核者 说明 2012-2-17 V0.1 卢宇 初稿 2012-2-28 V0.2 卢宇 增加了考核内容 目 录 1. 概要 3 1.1. 目的 3 1.2. 适用范围 3 2. 职责 4 3. 测试准备 4 3.1. 文档分析 4 3.2. 测试计划 4 3.3. 测试用例 4 3.3.1. 测试用例设计方法 5 3.4. 测试软/硬件环境 5 3.5. 测试数据准备 5 4. 测试执行 5 4.1. 项目测试周期 5 4.2. 项目测试启动 6 4.3. 项目测试阶段 6 4.4. 项目测试结束 6 5. 测试变更 6 6. 缺陷管理 6 6.1. 缺陷管理流程 6 6.2. 问题提交 7 6.3. 问题分配 7 6.4. 问题修改 7 6.5. 问题关闭 7 7. 回归测试 7 7.1. 回归测试策略 7 7.2. 回归测试基本过程 7 8. 测试结果分析 8 概要 目的 本过程规范软件测试过程中的各项活动，通过测试活动及早发现软件系统中的缺陷，并确保缺陷被有效的标识、跟踪、和修改，保证软件系统能够达到要求的质量，符合客户的要求。 适用范围 本过程适用于软件生命周期中的集成测试、系统测试、性能测试活动和缺陷管理活动。 职责 测试组长可以由测试经理或项目经理指定项目组成员其他人员担任。测试组长负责： 制定测试计划 参与、跟踪测试过程 对测试活动和结果进行分析，撰写测试分析报告 测试人员，由项目组成员担任，负责： 根据测试计划编写测试用例 搭建测试环境，准备测试脚本 执行测试，记录测试结果和缺陷 执行回归测试 测试准备 文档分析 测试人员应参加需求评审、设计评审。对《用户需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审查，与需求经理、项目经理沟通，根据系统功能复杂度，系统业务复杂度进行估算有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。 通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。 测试计划 根据测试的种类，测试计划分为功能测试和性能测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、工作规范等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。测试计划不包括测试用例的细节和系统功能的详细信息。测试计划的制定请参阅《测试计划》模板。测试计划应附有测试功能点矩阵、测试性能点矩阵。 测试计划应在项目组内进行评审。参与测试计划评审的人员包括：项目经理、测试组长、开发组长、测试组员。 测试用例 测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合解决要测什么、怎么测和如何衡量的问题。用例准则测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等；测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。已修改需求变更，功能变化， 提交缺陷 测试人员将缺陷填写到管理工具中，选择指派人为开发组长或相应的开发人员。 分配缺陷 开发人员分别对自己收到的缺陷进行评审。评审后如果对提交的缺陷有疑问，可以与提交人协商。对未能达成一致的缺陷由项目经理组织项目组成员评审。评审人员可以是项目组人员。 如果缺陷初次分配的开发人员无法修改该缺陷，初次分配的开发人员可以将缺陷再次分配给其他开发人员。但为避免缺陷被多次分配，项目经理应跟踪3天以上未修改的缺陷。 修改缺陷 开发人员对已确认的缺陷进行修改，填写修改记录，修改缺陷状态为“已修改”或其他状态。 关闭缺陷 测试人员对已修改的缺陷进行验证。如果已修改完成，测试人员将缺陷状态设置为关闭。如果没有修改或引起回归问题，将修改缺陷状态为“重新开启”或新增缺陷，由开发工程师继续修改。 保留缺陷 对于有争议的缺陷进行，将有项目经理最终决定是否修改。如果缺陷是由于技术原因、版本原因不能修改，则保留该缺陷。 测试结果分析 测试结果分析是对测试结果的一个综合评估，主要描述有测试中各个等级的缺陷数量，缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量，性能测试指标情况。 测试报告由测试组长编写并提交给项目经理。测试报告需要经项目组评审通过。 软件测试过程指导书V0.2 第 8 页 共 9 页 合肥康樱科技有限公司