缺陷管理流程_V01.doc

文件编号： 修改履历 修改编号 版本 修改条款及内容 修改日期  目录 1. 概述 4 1.1 目的 4 1.2 适用范围 4 1.3 角色职责 4 1.4 入口标准 4 1.5 输入 4 1.6 输出 4 1.7 出口标准 4 2. 流程 5 2.1 流程图 5 2.2 流程说明 5 2.2.1 提交问题 5 2.2.2 分析定位缺陷 6 2.2.3 修改缺陷 6 2.2.4 验证缺陷 6 2.2.5 统计数据 6 2.2.6 测试监控 6 3. 缺陷定义 7 3.1.1 缺陷状态 7 3.1.2 缺陷类型 7 3.1.3 缺陷严重级别 7 3.1.4 缺陷优先级别 8 4. 度量指标 8 5. 沟通机制 9 概述 目的 本文为缺陷管理模块缺陷跟踪处理流程介绍及操作指南，目的是对测试室在进行缺陷管理的过程中提供参考。 适用范围 本流程适用于银行测试缺陷管理工作。 角色职责 角色（岗位） 职责 测试执行岗 执行测试工作，负责提出新问题，并对开发岗已修改的问题进行验证 开发岗 负责对待修改的问题进行修复 需求分析岗 分析缺陷，并为测试方和开发方在缺陷有效性的分歧上，进行仲裁 测试主管岗 测试执行过程中，对缺陷提交情况、修复情况进行监控 入口标准 正式执行测试，测试方发现问题 输入 输出出口标准 流程说明 提交问题 测试执行岗在执行测试中，若发现问题，登录缺陷管理系统进行新问题的提交，描述问题时必须详细（必要时需附上截图），确保内容正确，定位准确。（有没有对缺陷处理时间的要求？） 分析定位缺陷 提交问题后，测试执行岗同开发岗对该问题进行进一步确认是否为开发方的缺陷。结果一般会出现以下两种情况： 如果双方发生分歧异议，测试执行岗提交问题给需求分析岗进行分析定位并仲裁： 若仲裁为开发方的缺陷，那开发岗需进行下一步的修复； 若定位为需求缺陷，进行修改确认通过，为有效缺陷；（那便是closed的状态，后续还需要进行其他方式的跟进吗？） 若是测试岗对需求理解错误等，关闭该问题，为无效缺陷； 如果确认为开发方的缺陷，那开发岗需进行下一步的修复。 如果确认中，该问题经开发或需求方等确认不纳入本测试任务的修改范围，作遗留处理，为有效缺陷。（如何定义哪些是遗留，是指缺陷难以重现、技术问题暂时无法解决的情况吗？） 修改缺陷 确认为程序缺陷后，测试执行岗打开问题，开发岗对待修改的缺陷进行修复。在进行修改时，开发岗需对缺陷做原因分析等注释。 验证缺陷 开发岗修复完缺陷后提交给测试执行岗进行回归测试，结果一般会出现以下两种情况： 如果该缺陷经验证不通过，测试执行岗退回修改给开发岗，开发岗需对待修改的缺陷进行修复并提交给测试执行岗进行重新验证，直至验证通过。 如果通过测试验证，则该问题便是修改确认通过。 如果验证中，该缺陷经开发或需求方等确认不纳入本测试任务的修改范围，作遗留处理，为有效缺陷。（如何详细定义遗留问题？后续如何跟进？） 如果验证中，测试方和开发方对该缺陷是否有效未能达成一致意见，问题提交需求分析岗进行仲裁。 统计数据 测试任务完成后，由相关人员整理缺陷相关数据，并进行分析处理。 测试监控 测试主管岗在测试执行中需对缺陷提交情况、修复情况进行监控，保证按质按时完成任务。 缺陷定义 缺陷状态 待确认：测试方认为该问题是一个缺陷，待与需求或开发进一步确认（中间过程状态，未确定是否为有效缺陷） 待修改：开发修改中（有效缺陷） 验证中：该缺陷开发已修复，测试方正对该问题进行回归测试中（有效缺陷） 退回修改：该缺陷回归测试不通过，重新退回给开发修改（有效缺陷） 仲裁：测试方和需求方或开发方对该缺陷是否有效未能达成一致意见，问题已提交相关人员进行仲裁中。（中间过程状态，未确定是否为有效缺陷） 修改确认通过：开发已修复，且测试方已回归测试通过（有效缺陷） 关闭：经确认或仲裁为无效缺陷 遗留：有效缺陷，但经开发或需求方等确认不纳入本测试任务的修改范围，作遗留处理 注:测试完成后，只允许修改确认通过、关闭、遗留这三种状态存在。 缺陷类型 需求缺陷：业务需求错误。包含需求功能流程错误、需求不完整、不一致、有遗漏、不可行、描述不清晰等。 开发缺陷：开发修改引起的问题。 历史遗留：不属于此测试任务的问题,属于历史遗留问题,如果对此问题修改后出现其它问题的话,衍生的问题应填相应的其它缺陷类型。 建议改善：易用性、界面风格等建议改善。 操作错误：测试人员操作错误或理解错误,属于无效缺陷。 环境问题：本测试任务的环境问题。 跑批问题：本测试任务的跑批问题。 缺陷严重级别 严重级别 描述 详细说明 致命 不能执行正常工作或重要功能、导致系统崩溃或资源严重不足、造成数据丢失 功能未实现或实现错误