缺陷自检是指提交给测试人员测试之前，由开发团队组织自检。对于自检不通过的缺陷会自动重新激活。对于自检通过的缺陷才提交给测试团队来测试，能有效地提高送测版本的质量，减低修复成本。

缺陷自检是指提交给测试人员测试之前，由开发团队组织自检。对于自检不通过的缺陷会自动重新激活。对于自检通过的缺陷才提交给测试团队来测试，能有效地提高送测版本的质量，减低修复成本。

在线帮助手册：

https://www.yuque.com/books/share/2211c34d-4c6e-442d-9785-8d490c0f8863/gb0rmy

管理思想：

按照经验，软件功能如果必须返工（包括缺陷修复），返工点所处于的软件生命周期越是靠后，成本越高。例如缺陷在测试团队发现后并解决的成本，比在开发团队能发现并解决的成本高。所以很多时候，在提交测试时，要求开发团队对解决缺陷进行进行一轮自检。

另外，对于送测的版本的质量，一般情况测试团队对开发团队也是有要求的，例如缺陷被重新激活的占比如果过高就会打回不测；如果重新被激活数量过高，也会影响开发团队的士气。所以，在提交测试时，要保证送测版本的质量，有利于提高士气，节约成本。

对于在自检不通过时被开发团队自己激活的缺陷，需要登记，作为开发人员的考核。对于自检通过但是送测后被测试团队激活的缺陷，也需要登记，作为送测版本质量的考核。都需要有报表统计。

1. 记录每次自检和复检的轨迹

包括：缺陷 id 、测试人、测试时间、测试版本、解决人、解决时间、解决版本、解决方案、自检人、自检时间（以它做顺序排序）、自检状态、自检过程、测试复检结论（关闭、激活）、测试复检人、测试复检时间。支持查看这些自检的结果。

2. 开发人员解决或重新解决缺陷后，提示开发团队重新自检

对于缺陷状态发生过如下调整的缺陷（激活 -> 已解决），自检的状态清零，表示需要开发团队重新自检。

3. 开发团队安排进行自检，自检不通过自动激活打回给开发人员

3.1 填写自检内容，包括：自检状态（通过、不通过）、自检过程。填写的这些内容自动作为缺陷的备注，在缺陷历史记录可以查看。如果发现填写有误，可以修改。

3.2 记录最新的自检状态、最新的自检人、最新的自检时间。

3.3 自检不通过时，如果发现缺陷状态为“已解决”，系统自动建缺陷的状态改为“激活”、自动重新指派给原开发人员。

3.4 对于自检误判导致缺陷被激活，开发团队可以修改自检的内容，包括状态、自检过程的描述。对于误判的情况，做了特别的处理，不影响开发人员自检通过率的统计。

4. 测试团队对自检通过的缺陷才进行测试（即复检），记录复测结果

4.1 测试人员将缺陷状态从“已解决”调整为“激活”时，如果当前的自检状态为“通过”，那么更新这条自检记录中的“测试复检结论”（激活）、“测试复检人”、“测试复测时间”。同时缺陷表中自检的状态不清零。这样可以对比了解开发人员自检的结果。

4.2 测试人员将缺陷状态从“已解决”调整为“关闭”时，如果当前的自检状态为“通过”，那么更新这条自检记录中的“测试复检结论”（关闭）、“测试复检人”、“测试复测时间”。

5. 为管理人提供统计数据，评估开发人员缺陷修复质量及送测版本的整体质量

1 ）统计维度：产品、解决版本、解决者、自检者

2 ）过滤条件：

产品、解决时间、解决者、自检者

3 ）统计字段：

自检总数

自检通过数量

自检不通过数量（注意：同一个缺陷可能多次不通过）

自检通过率 = 自检通过数量 /( 自检通过数量 + 自检不通过数量）。

自检不通过率 = 自检不通过数量 /( 自检通过数量 + 不通过数量 ) 。

复测总数

复测通过数量

复测不通过数量

复测通过率 = 复测通过数量 /( 复测通过数量 + 复测不通过次数 )

6.安装插件后，注意分配权限才能使用

6.1分配自检权限

点击所有权限，找到“缺陷自检管理”，如下图：

6.2分配统计报表权限

6.3分配缺陷明细和导出权限