软件缺陷主要包含哪些要素？

缺陷管理软件：BUGFree、JIRA、Bugtags、禅道、Quality Center、TAPD…

这些系统提供软件缺陷报告要素是大同小异的，我们需要掌握的是如何把软件缺陷要素怎样描述清楚，并提供准确有效的信息。

quality center包含的软件缺陷元素：缺陷标题、项目名称、所属模块、缺陷状态、缺陷等级、责任人、引入阶段、缺陷类型、优先级、能否重现、测试人员、发现日期、测试轮次、缺陷描述、预期结果、实际结果、重现步骤、附件

1.缺陷标题

缺陷标题通常是开发最先看到的部分，是对缺陷概括性描述，通常采用“在什么情况下发生了什么问题”的模式。
缺陷标题不能过长，需要对缺陷有更详细描述放在“缺陷概述”。

2.缺陷描述

缺陷描述是标题的细化，能提供更多概括性缺陷信息和以及描述缺陷本质。缺陷描述还可以包括其他延展部分，譬如列出同一类型缺陷有哪些场景、在之前哪个版本不会出现这种情况。
概述要尽量避免写缺陷重新步骤，而是概括性的描述，让开发人员聚焦问题本质。

3.缺陷状态

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

• 新建：测试人员新提交的bug、优化或者建议的状态
• 进行中：开发人员确认是bug，在修复bug过程的状态
• 已解决：开发人员已修复bug的状态
• 已关闭：测试人员验证修复的bug，去诶定解决问题的状态
• 不解决：开发人员认为不是bug，拒绝解决问题的状态或者无法解决问题的状态
• 重开：测试人员验证修复的bug，发现没有完全修复好bug，重新打回给开发人员的状态
• 暂缓：开发人员认为该bug不急于修复，可以放置一段时间在修复的状态
• 重复：与什么bug 重复

4.缺陷类型

缺陷类型：安全、功能、性能
引入阶段：开发、设计、需求、其他
能正确分清缺陷类型需要测试工程师对需求和业务有深入的了解，能考验测试工程师业务知识。
bug：测试人员通过测试发现的问题能成为bug
需求：需要产品经理对需求进一步梳理
建议：是软件产品改进建议
优化：功能已实现，需要优化的问题。可以是用户体验优化、性能优化

5.前置条件

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

6.重现步骤

缺陷步骤重现是整个缺陷报告中最核心的内容，用简洁语言向开发人员展示如何重现缺陷。
在写缺陷重现步骤前需要做到如下：
• 确保缺陷的可重现性
• 找到最短重现路径，过滤非必要步骤
• 对测试数据进行相关描述

7.期望结果和实际结果

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

8.严重性

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

严重：系统崩溃、数据丢失、数据毁坏、安全性被破坏
较大：操作性错误、结果错误、功能遗漏
一般：小问题、拼写错误、UI布局、罕见错误
轻微：文字拼写错误、排版错位；软件提示语前后不一致或与文档要求不符。
建议：对产品的改进建议

9.优先级

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

紧急：影响进一步测试，需要立即修复
高：必须在版本发布前修复
中：必须要修复，不一定马上修复，可以讨论确定在某个时间点修好
低：对产品影响比较小，不修复也不影响产品的发布在时间不允许的情况下夏可以暂时不修复。

10.附件

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

11.责任人

12.发现日期

13.测试人员

14.测试轮次

15.项目名称、所属模块

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