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

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

在线帮助手册：

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

作为研发管理者，有几个头疼的地方：

1. 难以评估修复缺陷的质量，如果被多次激活，目前没有办法统计；
2. 送测的版本缺陷修复通过率不高，特别是一些很明显的问题，开发人员都没有自己好好检查就送测了。甚至被测试团队多次激活，送测质量没保障。导致缺陷的关闭周期过长，从而版本发布的周期过长。

结合实战案例，提出一个解决方案：增加一个“自检环节”：开发人员修复缺陷后，可以安排自检，自检通过后的才安排送测。自检的任务可以由开发人员交叉检查，也可以安排额外的测试人员进行。这样有个好处，自检可以机动的每日检查（配合每日持续集成效果更佳），昨天开发人员修复的缺陷，自动部署到验证环境，今天就有自检人员去检查，有问题可以激活重新安排修复。持续大概2周时间后，就安排送测版本。这个送测版本的质量不会差。

如下是传统的送测流程：

缺点是：一般都是修复的缺陷积累到一定数量后，才会正式送测 。时间周期长，如果缺陷被重新激活，开发人员修改后还需要从记忆中努力“还原案发现场”，花费的时间较多。

如下是改良后的流程：

好处是：及时检查开发人员已经修复的缺陷。送测时再做一次完整的回归，通过率大大提升。可以调动开发内部进行交叉检查，漏检查的能在线被统计出来。

特点

1. 不需要改变开发人员和测试人员的原来的测试流程，还是按禅道原来的方式。插入的“自检环节”更多是辅助开发，测试人员可以忽略，可以另外安排其他团队来进行。
2. 加快缺陷修复的验证，加快缺陷的修复速度。
3. 提高送测版本的质量，加快版本发布的周期。
4. 支持开源版、专业版、企业版安装此插件。

操作手册

自检结论的填写

缺陷列表（测试-Bug）上增加了“自检状态”一列，如果这条缺陷还没进行过自检，状态为空。

进入缺陷详情页面，可以见到下发的按钮上新增了“自检”按钮（注意，只有已解决状态下的缺陷才会显示此按钮）

点击自检，弹出填写表单。如果自检不通过，会自动激活。激活后，重新修复，会重新出现自检的按钮，再进行一次自检。如此重复下去。

填写提交后，将处理的内容登记到缺陷备注列表里，如下，

同时，自检状态会更新在缺陷列表上

自检的搜索

查询条件上增加了“自检状态”、“自检者”、“自检时间”三个字段的检索。可以结合缺陷状态，过滤出哪些缺陷需要安排自检。

导出增加自检状态

导出时的默认字段就带有“自检状态”、“自检者”、“自检时间”

统计

按自检次数统计

作用

1. 为了统计所有的自检次数中，不通过率，来评估开发人员的开发质量如何
2. 为了统计所有自检次数中，复检后还是不通过的占比，来评估自检的质量如何

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

2 ）过滤条件：

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

3 ）统计字段：

自检总数

自检通过数量

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

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

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

复测总数

复测通过数量

复测不通过数量

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

18.4+以后调整成这样了：

点击数字可以查看明细，

按缺陷数量统计

作用

1. 为了分析已经解决的缺陷，还有多少还没安排自检的。

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

2 ）过滤条件：

产品、解决方案、严重级别、解决时间、解决者、自检者、自检时间

3 ）统计字段：

已解决数量

通过自检数量。注意，没通过自检的，已经重新激活。

未自检数量

18.4+调整成这样了：

点击数字可以查看明细，

权限设置

18.4+调整成这样了：

如上的“增加缺陷自检”、“修改缺陷自检”将会影响到如下“自检”按钮的显示。

统计报表的权限这样设置，

18.4+的权限调整成这样了：