缺陷分类报告格式

缺陷分类会议通常被称为解决和修复缺陷。重要的参与者包括测试负责人，项目经理，技术负责人和开发团队负责人。没有他们，就无法做出决定，会议也无法完成。在三个不同的阶段，即会议前，会议期间和会议后，缺陷分类会议得以完成。

会议结束后，将生成分类报告，其中包含会议期间发生的所有事情的完整描述和详细信息。该分类报告包含从识别缺陷到缺陷的根本原因的所有信息。该报告与所有会议参与者共享。样本报告格式如下所示：

缺陷分类报告中的各个字段：

1. 缺陷ID：
   缺陷ID是通常用于验证或识别缺陷的身份证明文件。缺陷ID基本上是唯一的标识号，赋予每个缺陷以区别它们。
2. 缺陷描述：
   缺陷描述通常包括缺陷的详细描述。它还包括有关识别出缺陷的模块的信息。它还包括缺陷原因及其对系统工作的影响。
3. 创建日期 ：
   创建日期是发现，发现或提出缺陷的日期。在创建日期，第一次报告了缺陷。
4. 创建者：
   创建者是提出或发现缺陷的测试人员。创建者可能包括已报告缺陷的测试人员的姓名或ID。
5. 严重程度：
   严重程度从根本上解释了缺陷对系统或应用程序的影响。它包括缺陷如何影响系统。它只是测量严重程度，即严重程度的缺陷。
6. 优先事项 ：
   优先级基本上与解决或修复缺陷有关。优先级代码仅指示特定缺陷对系统的影响。优先级代码可以是高，中或低。
   • 高的 –
     如果优先级代码很高，则意味着需要立即解决或修复缺陷。如果不解决此特定缺陷，项目将无法成功。
   • 中等的 –
     如果优先级代码适中，则意味着不需要立即解决或修复特定的缺陷。由于它不需要立即采取任何措施，因此以后可以解决。缺陷对系统的影响较小。
   • 低的 –
     如果优先级代码较低，则意味着不需要解决或修复缺陷。它可能会或可能不会解决。缺陷对系统的影响很小，可以忽略不计。
7. 地位 ：
   这表明缺陷的当前状态，即缺陷是新的，正在进行的还是已完成的。

8. 作业日期：
   分配日期是进一步修复或解决缺陷的日期。在此日期，缺陷已分配给特定的团队或个人以解决。
9. 分配给/开发人员：
   开发人员是具有固定或已解决缺陷的测试人员。开发人员可能会包含已修复缺陷的测试人员的姓名或ID。
10. 解析度 ：
    解决方案通常包括有关如何解决缺陷的详细说明。它包括解决缺陷的所有步骤。
11. 解决日期：
    解决日期是指解决缺陷的日期，即开发人员将解决或完全修复缺陷的日期。
12. 预计的时间 ：
    估计时间基本上是完成解决方案所需的工作小时数表示的值，即修复或解决缺陷所需的估计时间。
13. 实际时间 ：
    实际时间基本上是指开发人员完成解决方案所花费的工作时间所表示的价值，即修复或解决缺陷所花费的实际时间。
14. 根本原因描述：
    该字段说明了引起缺陷的主要原因。它解释了为什么出现缺陷并引发缺陷。