欢迎来到
缺陷报告
定义
编辑
缺陷：总的来说就是软件系统不满足用户需求，功能实现错误，功能实现遗漏，功能实现多余，测试人员认为难以理解，影响用户体验等问题。
缺陷报告：测试缺陷报告也叫Bug单，在执行测试用例时，发现软件缺陷之后就需要输出此文档，属于测试工作的重要内容，一般会用缺陷管理工具进行Bug的追踪和管理。
实践出处
编辑
出处不详，欢迎补充！
为什么
编辑
报告软件的缺陷非常重要。这是因为要启动缺陷修复流程，开发人员就需要了解出现了问题，并且还要了解问题是什么。如果开发团队不了解这些，那么问题存在的时间会更长。
报告缺陷还可以防止将来出现更严重的问题。通过让开发团队了解一个小错误，就可以帮助防止出现其他相关问题。
何时使用
编辑
发现缺陷后一般要先分析缺陷，排除干扰因素，确认复现缺陷的准确步骤，记录缺陷产生的环境和条件等，最后输出缺陷报告。
如何使用
编辑
缺陷报告主要由以下部分组成：
-
缺陷ID： 唯一标识缺陷的字段，一般缺陷管理工具自动分配。
标题： 简短、准确，提供缺陷的本质信息，尽量使用关键词，便于搜索。
基本描述：-
测试环境
-
测试数据
-
操作步骤
-
期望结果
-
实际结果
-
-
严重性： 致命、严重、一般、微小
-
缺陷类型： 如功能、UI、性能、文档
-
缺陷产生可能性： 可再现的概率
-
缺陷来源： 需求、设计、编码
-
产品模块： 缺陷出现在产品的哪个模块中
-
版本： 缺陷出现在产品的哪个版本中
-
缺陷原因： 数据格式、计算错误、接口参数、变量定义与引用等
-
附加信息： Trace log、图片、操作过程的视频等
-
缺陷状态： 缺陷的活动状态
-
新提交的（New）
-
已分配的（Assigned）
-
待解决的（Open）
-
已修改的（Fixed）
-
问题未解决的（Reopened）
-
已归档的（Closed）
-
缺陷的严重性：衡量缺陷对客户满意度的影响程度
-
致命的/fatal： 致命错误，死机、丢失数据，数据溢出错误
-
严重的/critical： 严重错误，较大的功能问题。
-
一般的/major： 一般的错误，不影响基本功能的使用。
-
微小的/minor： 界面美观等等比较小的问题。
缺陷修复优先级：缺陷被修复的紧急程度
-
立即解决（P1）： 缺陷导致系统几乎不能使用或测试不能继续，需立即修复；
-
高优先级（P2）： 缺陷严重，影响测试，需要优先考虑；
-
正常排队（P3）： 缺陷需要正常排队等待修复；
-
低优先级（P4）： 缺陷可以在开发人员有时间的时候被修正。
这些是bug单比较重要的部分，当然还有其他部分，如发现人、发现时间、指派给等，一般公司都会有具体的模板和要求，不同的缺陷管理 工具对于缺陷的严重程度和优先级定义略有不同。
输出物
编辑
缺陷报告单
参考资料
编辑
-
朱少民《软件测试方法和技术》第3版 P297
关键词
编辑
软件测试,缺陷报告,BUG,BugList,缺陷
我们非常重视知识产权，我们在非常努力地寻找最初的出处来源并注明出处。但因为互联网信息浩瀚，难免会有疏漏。如果您觉得有侵犯您的权益，请联系我们。
导出缺陷报告.pdf
导出缺陷报告.docx
导出缺陷报告.pptx分享
