缺陷管理流程_V0.1.doc

文件编号： 缺陷管理流程 修修 改改 履履 历历 修修 改改 编编 号号版版 本本修修 改改 条条 款款 及及 内内 容容修修 改改 日日 期期 1V0.1初稿 目录 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 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 流程说明流程说明 2.2.12.2.1提交问题提交问题 测试执行岗在执行测试中，若发现问题，登录缺陷管理系统进行新问题 的提交，描述问题时必须详细（必要时需附上截图） ，确保内容正确，定位 准确。 （有没有对缺陷处理时间的要求？） 2.2.22.2.2分析定位缺陷分析定位缺陷 1) 提交问题后，测试执行岗同开发岗对该问题进行进一步确认是否为开发 方的缺陷。结果一般会出现以下两种情况： 如果双方发生分歧异议，测试执行岗提交问题给需求分析岗进行分析定 位并仲裁： 若仲裁为开发方的缺陷，那开发岗需进行下一步的修复； 若定位为需求缺陷，进行修改确认通过，为有效缺陷；（那便是 closed 的状态，后续还需要进行其他方式的跟进吗？） 若是测试岗对需求理解错误等，关闭该问题，为无效缺陷； 如果确认为开发方的缺陷，那开发岗需进行下一步的修复。 2) 如果确认中，该问题经开发或需求方等确认不纳入本测试任务的修改范 围，作遗留处理，为有效缺陷。 （如何定义哪些是遗留，是指缺陷难以 重现、技术问题暂时无法解决的情况吗？） 2.2.32.2.3修改缺陷修改缺陷 确认为程序缺陷后，测试执行岗打开问题，开发岗对待修改的缺陷进行 修复。在进行修改时，开发岗需对缺陷做原因分析等注释。 2.2.42.2.4验证缺陷验证缺陷 1) 开发岗修复完缺陷后提交给测试执行岗进行回归测试，结果一般会出现 以下两种情况： 如果该缺陷经验证不通过，测试执行岗退回修改给开发岗，开发岗 需对待修改的缺陷进行修复并提交给测试执行岗进行重新验证，直 至验证通过。 如果通过测试验证，则该问题便是修改确认通过。 2) 如果验证中，该缺陷经开发或需求方等确认不纳入本测试任务的修改范 围，作遗留处理，为有效缺陷。 （如何详细定义遗留问题？后续如何跟 进？） 3) 如果验证中，测试方和开发方对该缺陷是否有效未能达成一致意见，问 题提交需求分析岗进行仲裁。 2.2.52.2.5统计数据统计数据 测试任务完成后，由相关人员整理缺陷相关数据，并进行分析处理。 2.2.62.2.6测试监控测试监控 测试主管岗在测试执行中需对缺陷提交情况、修复情况进行监控，保证按 质按时完成任务。 3. 缺陷缺陷定义定义 3.1.13.1.1缺陷状态缺陷状态 待确认：待确认：测试方认为该问题是一个缺陷，待与需求或开发进一步确认 （中间过程状态，未确定是否为有效缺陷） 待修改：待修改：开发修改中（有效缺陷） 验证中：验证中：该缺陷开发已修复，测试方正对该问题进行回归测试中（有效 缺陷） 退回修改：退回修改：该缺陷回归测试不通过，重新退回给开发修改（有效缺陷） 仲裁：仲裁：测试方和需求方或开发方对该缺陷是否有效未能达成一致意见， 问题已提交相关人员进行仲裁中。 （中间过程状态，未确定是否为有效 缺陷） 修改确认通过：修改确认通过：开发已修复，且测试方已回归测试通过（有效缺陷） 关闭：关闭：经确认或仲裁为无效缺陷 遗留：遗留：有效缺陷，但经开发或需求方等确认不纳入本测试任务的修改范 围，作遗留处理 注注: :测试完成后，只允许修改确认通过、关闭、遗留这三种状态存在。测试完成后，只允许修改确认通过、关闭、遗留这三种状态存在。 3.1.23.1.2缺陷类型缺陷类型 需求缺陷：需求缺陷：业务需求错误。包含需求功能流程错误、需求不完整、不一 致、有遗漏、不可行、描述不清晰等。 开发缺陷：开发缺陷：开发修改引起的问题。 历史遗留：历史遗留：不属于此测试任务的问题,属于历史遗留问题,如果对此问题 修改后出现其它问题的话,衍生的问题应填相应的其它缺陷类型。 建议改善：建议改善：易用性、界面风格等建议改善。 操作错误：操作错误：测试人员操作错误或理解错误,属于无效缺陷。 环境问题：环境问题：本测试任务的环境问题。 跑批问题：跑批问题：本测试任务的跑批问题。 3.1.33.1.3缺陷严重级别缺陷严重级别 严重 级别 描述详细说明 功能未实现或实现错误 数据计算错误、产生错误结果 程序死循环、数据库发生死锁 致命 不能执行正常工作或重 要功能、导致系统崩溃 或资源严重不足、造成 数据丢失 因错误操作导致的程序中断 功能未实现或实现错误 数据计算错误、产生错误结果 数据通讯错误、程序接口错误 需求功能流程错误或需求缺失 数据约束错误、数据输入输出错误 财务错误 严重 严重影响系统要求或基 本功能实现、且不存在 可替代的解决方法或方 式 交易报错(交易报错导致交易无法继 续等) 打印内容、格式错误 简单的输入限制未放在前台进行控 制 删除操作未给出提示 操作界面信息错误（包括数据窗口 内列名定义、含义是否一致） 一般 影响系统要求或基本功 能实现，但存在可替代 的解决方法或方式 数据库表中有过多的空字段 界面不规范,域控制不规范 辅助说明描述不清楚、提示窗口文 字未采用行业术语 输入输出不规范 长时间操作未给用户提示 可输入区域和只读区域没有明显的 区分标志 控件没有对齐、标点符号丢失或不 正确 轻微 操作不便或遇到麻烦， 但不影响执行工作或使 用重要功能 需求瑕疵包括需求错别字等 3.1.43.1.4缺陷优先级别缺陷优先级别 表明缺陷需要被解决的紧急程度，包括四个级别： 紧急：要求在 4 工时内解决，对系统大部分功能、或主要功能有影响 高：要求在一个工作日内解决，影响了系统的部分功能 中：要求在两个工作日内解决，对其它功能模块影响较小 低：要求在当前版本解决，对其它功能模块无影响 4. 度量指标度量指标 收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 指标含义计算公式 缺陷总数本月发现的总有效缺陷数 缺陷密度 反映测试小组发现缺陷的能 力和开发质量 有效缺陷数执行用例数 缺陷有效率 反映测试小组发现缺陷的能 力和开发质量 有效缺陷数总缺陷数 缺陷严重程度 说明缺陷给最终交付的系统 或产品可能造成的影响程度 缺陷修复质量缺陷的问题验证通过次数 缺陷修复速度缺陷修复延误天数 缺陷修复程度 遗留缺陷为有效而未修复的 缺陷 遗留率=