5.6缺陷管理

因为发现缺陷是测试目的之一，所以应该记录测试过程中发现的缺陷。基于测试组件或系统的上下文、测试级别和软件开发生命周期模型的不同，记录缺陷的方式会有所不同。任何识别的缺陷都应该被调查，并跟踪从发现和分类到解决问题的过程（例如：修复缺陷和成功验证解决方案，推迟到后续的发布，接受为永久性产品限制等）。为了解决所有缺陷，组织应建立缺陷管理过程，其中包括工作流和分类规则。这个过程必须与参与缺陷管理的所有人达成一致，包括设计人员、开发人员、测试人员和产品所有者。在一些组织中，缺陷记录和跟踪可能是非常不正式的。
在缺陷管理过程中，有些报告可能被描述了假阳性（误报缺陷），而不是由于缺陷造成的实际失效。例如：当网络连接中断或超时时，测试可能失败。这种行为不是由测试对象中的缺陷造成的，而是需要研究的异常。测试人员应尽量减少被报告为假阳性缺陷的数量。
在编码、静态分析、评审、动态测试或使用软件产品时，都可以报告缺陷。代码或工作系统，或任何类型的文档，包括需求、用户故事和验收准则、开发文档、测试文档、用户手册或安装指南，都可以报告缺陷。为了构建有效和高效的缺陷管理过程，组织可以定义缺陷的属性、分类和工作流的标准。
典型的缺陷报告有以下目标：
• 向开发人员和其他当事方提供关于所发生的任何不利事件的信息，使他们能够识别具体影响，用最小的重现测试步骤将问题分离出来，并纠正潜在的缺陷，根据需要或以其他方式解决问题
• 向测试管理人员提供一种手段，以跟踪工作产品的质量及其对测试的影响（例如：如果报告了大量缺陷，测试人员将花费大量时间报告这些缺陷，而不是进行测试，同时需要更多的确认测试）
• 为改进开发和测试过程提供思路
在动态测试期间提交的缺陷报告通常包括：
• 标识符
• 标题和所报告缺陷的简短摘要
• 缺陷报告日期、发现的组织和作者
• 测试项(被测试的配置项)和环境的标识
• 发现缺陷的开发生命周期阶段
• 缺陷描述以便能够复现和修复，包括日志、数据库转储截图或录音(如果在测试执行期间发现)
• 预期和实际结果
• 缺陷对利益相关者的的影响范围或程度(严重程度)
• 修复的紧急程度/优先级
• 缺陷报告的状态(例如：打开、推迟、重复、等待修复、等待确认测试、重新打开、关闭)
• 结论、建议和核准
• 全局性问题，例如可能受到缺陷所引起的变更影响的其他领域
• 变更历史，如项目小组成员采取的行动顺序，从缺陷隔离、修复和到确认缺陷已修复
• 参考资料，包括发现问题的测试用例
在使用缺陷管理工具时，上述细节中的一些内容可以自动包含和/或得到管理，例如工作过程中自动分配标识符、分配和更新缺陷报告状态等。静态测试中发现的缺陷，特别是评审，通常会以不同的方式记录，例如在评审会议记录中。
缺陷报告内容的示例可在ISO标准（ISO/IEC/IEEE 29119-3）中找到（该标准将缺陷报告称为事件报告）。