软件缺陷报告是测试工程师和开发工程师的重要桥梁，能把软件缺陷准确无误地表述清楚是一门绝学技能。
“准确无误”是意味着，开发工程师能根据缺陷报告能快速理解缺陷，能精确定位问题。而项目经理通过该缺陷报告能迅速判断修复缺陷重要性和优先级。缺陷报告质量影响到开发人员修复问题时间和效率，也能侧面反应测试工程师对缺陷认知水平。
现在有很多缺陷管理系统，比如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.附件
附件通常是为缺陷的存在提供必要的证据支持。对于某些文字很难表达清楚的缺陷，使用附件有助于开发人员更快修复缺陷。常见附件有界面截图、操作视频。
上面列出软件缺陷包含元素是最常见，不同公司使用不同缺陷管理工具，会在这基础上会增加或减少个别要素。我们需要想办法打磨描述好软件缺陷报告，让开发人员聚焦问题本质，减少沟通成本，提高工作效率。
网友评论