软件测试最新软件测试缺陷报告详解_软件缺陷统计，2024年最新一招彻底弄懂

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

5）优先级

6）截图

7）编号

8）指派人

二、“5C”原则

内容准确（Correct）：每个组成部分的描述准确，不会引起误解

步骤简洁（Concise）：只包含必不可少的信息，不包括任何多余的内容

内容清晰（Clear）：每个组成部分的描述清晰，易于理解

结构完整（Complete）：包含复现该缺陷的完整步骤和其他本质信息

风格一致（Consistent）：按照一致的格式书写全部缺陷报告

三、二八定理

在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出 其余缺陷中的80%，最后的4%的缺陷可能只有在用户大范围、长时间使用后才会暴露出来。

四、缺陷报告的组成

1、缺陷编号（Defect ID）：提交缺陷的顺序

2、缺陷的标题（summary）：简明扼要的描述缺陷

3、缺陷的发现者（Defected By）：测试人员

4、缺陷发现的日期（date）：一般为当天

5、缺陷所属的模块（subject）：在测试那个功能模块时发现的bug

6、发现缺陷的版本（Defected in release）：开发的软件的版本

7、指派给谁处理（Assigned to）：测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员

8、缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况

（1）测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为new（新）

（2）开发经理验证提交的bug，如果是bug，把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug，把状态改为rejected（拒绝的bug）

（3）开发人员看到指派给自己解决的bug，进行缺陷修复，修改完后，把缺陷状态fixed（已经修复的bug，可以返测的bug）

（4）测试人员对修复的bug进行反测，若返测成功，将状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）

五、缺陷报告的深度理解

1、缺陷的严重程度和优先级是不是成正比关系？

界面问题的严重程度一般比较低，担优先级可能很高————立即修复

某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低————在发布之前修复

2、缺陷的严重程度和优先级确定好后，还能修改吗？

严重成度不允许改，优先级可能修复。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！