软件缺陷报告是测试工程师和开发工程师的重要桥梁，能把软件缺陷准确无误地表述清楚是一门绝学技能。

“准确无误”是意味着，开发工程师能根据缺陷报告能快速理解缺陷，能精确定位问题。而项目经理通过该缺陷报告能迅速判断修复缺陷重要性和优先级。缺陷报告质量影响到开发人员修复问题时间和效率，也能侧面反应测试工程师对缺陷认知水平。

现在有很多缺陷管理系统，比如BugFree、JIRA、Bugtags等等。这些系统提供软件缺陷报告要素是大同小异，我们需要掌握的是如何把软件缺陷要素怎样描述清楚，并提供准确有效信息。

接下来，来讲解软件缺陷报告主要包含有哪些的要素。

1.缺陷标题

缺陷标题通常是开发人员最先看到的部分，是对缺陷概括性描述，通常采用“在什么情况下发生了什么问题”的模式。

如果用笼统语言来描述缺陷标题，容易遭到开发工程师的反感和抵触情绪。如下是笼统概括标题：用户不能正常登录、输入查询条件不能匹配结果。如果把这些缺陷提交给开发人员，有种让人摸不着头脑感觉。

“用户不能正常登录”可以改成“输入正确用户名、正确密码且用户状态正常却不能正常登录”；“输入查询条件不能匹配结果”改成“用户名搜索框不支持模糊查询”。这样相对清晰易理解。

最后，缺陷标题不能过长，需要对缺陷有更详细描述放在“缺陷概述”。

2.缺陷概述

缺陷概述是标题细化，能提供更多概括性缺陷信息和以及描述缺陷本质。缺陷概述还可以包括其他延展部分，譬如列出同一类型缺陷有哪些场景、在之前哪个版本会出现这种情况。

概述要尽量避免写缺陷重现步骤，而是概括性的描述，让开发人员聚焦问题本质。

3.状态

主要描述缺陷当前的状态。状态如下：

新建：测试人员新提交的bug、优化或者建议的状态。

进行中：开发人员确认是bug，在修复bug过程的状态。

已解决：开发人员已修复bug的状态。

已关闭：测试人员验证修复的bug，确定已解决问题的状态。

不解决：开发人员认为不是bug，拒绝解决问题的状态或者无法解决问题的状态

重开：测试人员验证修复的bug，发现没有完全修复好bug，重新打回开发人员的状态。

暂缓：开发人员认为该bug不急于修复，可以放置一段时间再修复的状态。

4.缺陷类型

能正确分清缺陷类型需要测试工程师对需求和业务有深入了解，能考验测试工程师业务知识。

bug：测试人员通过测试发现的问题能称为bug。

需求：需要产品经理对需求进一步梳理。

建议：是软件产品改进建议

优化：功能已实现，需要优化问题。可以是用户体现优化、性能优化。

5.前置条件

前置条件是指测试步骤开始前系统应该处在的状态，目的为了减少缺陷重现步骤描述。

比如，某个业务操作需要先完成用户登录，在重现步骤无须描述登录操作的步骤，因为在前置条件写明：用户已完成登录。

6.重现步骤

缺陷重现步骤是整个缺陷报告中最核心的内容，用简洁语言向开发人员展示如何重现缺陷。

在写缺陷重现步骤前需要做到如下：1.确保缺陷的可重现性。2.找到最短重现路径，过滤非必要步骤。3.对测试数据进行相关描述。

7.期望结果和实际结果

期望结果和实际结果通常和缺陷重现步骤绑定一起，在描述重现步骤的过程中，需要明确说明期待结果和实际结果。期待结果是对需求理解，实际结果来自于执行用例的结果。

8.严重性

严重性表示软件缺陷影响使用程度。

致命：系统崩溃、数据丢失、数据毁坏、安全性被破坏。

严重：操作性错误、结果错误、功能遗漏。

一般：小问题、拼写错误、UI布局、罕见错误。

建议：对产品的改进建议。

9.优先级

优先级表示修复缺陷的重要程度和紧迫程度。

紧急：影响进一步测试，需要立即修复。

高：必须在版本发布前修复。

中：必须要修复，不一定马上修复，可以讨论确定在某个时间节点修复好。

低：对产品影响比较少，不修复也不影响产品的发布。在时间不允许的情况下可以暂时不修复。

10.附件

附件通常是为缺陷的存在提供必要的证据支持。对于某些文字很难表达清楚的缺陷，使用附件有助于开发人员更快修复缺陷。常见附件有界面截图、操作视频。

上面列出软件缺陷包含元素是最常见，不同公司使用不同缺陷管理工具，会在这基础上会增加或减少个别要素。我们需要想办法打磨描述好软件缺陷报告，让开发人员聚焦问题本质，减少沟通成本，提高工作效率。