缺陷管理流程_V0.1.docxVIP

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