统计缺陷因信息不全被打回的比例，核心是把“因信息不全被打回”定义成一个可识别的事件，再用同一时间窗内的缺陷数做分母。常见公式是：统计期内因信息不全被打回的缺陷数 ÷ 同期进入评审环节的缺陷总数，结果用百分比表示。要让这个数字可复算、可比较，需要先定好打回原因归类、按缺陷去重、跨期归属和分母为零的处理规则。
要点总览（TL;DR）
- 主指标公式：统计期内因信息不全被打回的缺陷数 ÷ 同期进入评审环节的缺陷总数 × 100%，分子按缺陷去重，同一缺陷多次打回只计一次。
- 打回原因要用必填枚举字段记录，把描述缺失、复现步骤缺失、环境信息缺失、预期结果缺失归入信息不全类，重复缺陷、非缺陷、优先级争议单列不计入。
- 反复澄清程度用辅助指标衡量：要求补充信息次数 ÷ 进入评审缺陷数，以及澄清轮次总和 ÷ 发生澄清的缺陷数。
- 时间窗按打回事件发生时间归属，分母为零时比例记为不适用而非0%，分母过小时只记录绝对数不解读百分比。
- 该指标反映缺陷记录完整度对流转的影响，适合同口径趋势观察，不宜直接用于跨团队排名或个人绩效。
这个比例要回答什么问题
这个指标衡量的是缺陷记录本身的信息完整度对流转的影响：一条缺陷提交后，有多少因为描述、复现步骤、环境、预期结果等信息缺失，在评审或受理环节被退回补充，导致流转中断或延后。它关注的对象是缺陷记录的质量，以及由此产生的打回和澄清动作。
它不回答缺陷数量多不多，也不判断缺陷严重程度是否定得准。缺陷数量属于提交量或发现效率的度量，严重程度属于分级判定，两者与信息完整度是不同维度。一个团队缺陷很多但记录规范，打回比例可能很低；另一个团队缺陷不多但描述粗糙，打回比例可能偏高。把这三类指标混在一起看，容易得出错误结论。
因此，使用这个指标前要先明确评估目的：是观察提交规范执行情况、定位澄清成本，还是评估某次模板或培训改动的效果。目的不同，统计范围和观察周期也应相应调整。
分子分母怎么定：指标与统计范围
主指标回答“有多大比例的缺陷因信息不全被打回”，辅助指标回答“反复澄清的程度有多深”。两者配合使用，可以避免只看比例而忽略同一缺陷被多次打回的情况。
| 指标 | 公式 | 单位 | 统计对象 | 时间窗 |
|---|---|---|---|---|
| 因信息不全被打回比例 | 因信息不全被打回的缺陷数 ÷ 进入评审环节的缺陷总数 × 100% | 百分比 | 进入评审环节的缺陷，分子按缺陷去重 | 按打回事件发生时间归属统计期 |
| 要求补充信息次数/缺陷数 | 要求补充信息的次数 ÷ 进入评审环节的缺陷数 | 次/条 | 同上 | 同上 |
| 平均澄清轮次 | 澄清轮次总和 ÷ 发生澄清的缺陷数 | 轮/条 | 发生过至少一次澄清的缺陷 | 同上 |
分母限定为“进入评审环节的缺陷”，而不是全部新建缺陷。尚未提交评审或仍在草稿状态的缺陷没有机会被打回，放进分母会稀释比例。评审环节的具体边界要在团队内写清楚，例如“提交后进入待评审状态”算进入评审，“评审通过进入修复”算离开评审。
时间窗按打回事件发生时间归属，而不是按缺陷创建时间归属。一条缺陷上周创建、本周被打回，应计入本周的分子，同时其对应的评审进入事件也应在同一窗口内统计，避免分子分母错配。跨期缺陷的处理规则要在统计前固定下来，中途不随意切换。
打回原因怎么归类才算数
“信息不全”能否统计准确，取决于打回原因是否用统一枚举记录。建议在缺陷流转中设置必填的“打回原因”字段，用下拉选项约束，避免自由文本造成同一原因多种写法。
可参考以下分类，把前四项计入信息不全类：
- 描述缺失：问题现象、影响范围描述不清或缺失。
- 复现步骤缺失：无法按记录步骤复现问题。
- 环境信息缺失：版本、设备、配置、数据条件等未说明。
- 预期结果缺失：未说明正确表现是什么，无法判断是否为缺陷。
- 重复缺陷：与已有缺陷重复，属于查重问题，单列不计入。
- 非缺陷：需求理解偏差或预期本身有误，单列不计入。
- 优先级或归属争议：信息基本完整，属于流程协调问题，单列不计入。
归类有争议时，由评审人复核并在记录中注明最终归类，必要时保留原始打回说明。定期抽查一批打回记录，核对原因字段与实际退回理由是否一致，发现系统性偏差就调整枚举项或补充填写指引。原因字段必填、枚举受控、争议可复核，这三点做到，比例才具备跨团队比较的基础。
在工具层面，ONES Project 支持缺陷跟踪与缺陷状态分布统计，并提供可自定义数据范围和维度的报表；ONES TestCase 支持未通过用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可以借助工作项状态流转和字段配置，把打回动作、打回原因和澄清记录固定为可统计的数据，再按上述口径汇总。具体字段与报表的配置方式需结合实际使用版本确认。
取数与计算步骤
以下步骤以导出的缺陷流转记录为基础，按顺序执行即可复算。
- 确定统计窗口，例如某月1日至14日，并记录窗口起止时间。
- 导出缺陷数据，至少包含缺陷ID、创建时间、进入评审时间、打回时间、打回原因、当前状态、澄清记录或评论数。
- 筛选分母：取进入评审时间落在统计窗口内的缺陷，按缺陷ID去重，得到分母缺陷集合。
- 筛选分子：在分母集合中，取打回时间落在统计窗口内、且打回原因属于信息不全类的记录，按缺陷ID去重，同一缺陷多次打回只计一次，得到分子缺陷数。
- 计算主指标：分子缺陷数 ÷ 分母缺陷数 × 100%。
- 计算辅助指标：统计要求补充信息的次数，除以分母缺陷数，得到次/条；统计澄清轮次总和，除以发生澄清的缺陷数，得到平均轮次。
- 处理异常：分母为零时，比例记为“不适用”，同时记录该窗口的评审量，不写成0%；打回原因缺失的记录单独列出，不默认计入分子，待补录或复核后再纳入。
去重规则要写进统计说明：主指标按缺陷去重，辅助指标中的次数和轮次按事件计数。这样同一份数据既能回答“多少缺陷受影响”，也能回答“澄清有多频繁”，两个口径不互相替代。
算一个例子：两周窗口的实际计算
假设某团队统计两周窗口内的缺陷数据，设定如下：窗口内进入评审环节的缺陷共120条；其中因信息不全被打回的缺陷有18条，这18条中有5条在窗口内被打回两次；窗口内要求补充信息的总次数为27次；发生澄清的缺陷共15条，澄清轮次合计24轮。
主指标计算：分子按缺陷去重为18条，分母为120条，18 ÷ 120 × 100% = 15%。含义是这两周进入评审的缺陷中，有15%因信息不全被退回补充。
辅助指标计算：要求补充信息次数/缺陷数为27 ÷ 120 = 0.225次/条，说明平均每条进入评审的缺陷产生约0.23次补充要求；平均澄清轮次为24 ÷ 15 = 1.6轮/条，说明发生澄清的缺陷平均需要1.6轮沟通才能补齐信息。
结果解读时要注意：15%说明信息不全造成的打回在评审缺陷中占有一定比例，配合0.225次/条可以看出反复要求补充的程度。但这些数字不能推出“缺陷真实质量差”或“某个人提交不规范”的结论，它只反映记录完整度对流转的影响。若该窗口分母只有8条，比例即使为25%，也因样本过小而不足以说明趋势。
结果怎么读：可比性与局限
这个比例适合做同口径下的趋势观察，不适合直接横向排名。不同团队的业务类型、缺陷来源和评审严格程度不同，同样的比例含义可能不同；手工测试缺陷与线上问题记录的信息要求也有差异，混在一起统计会削弱可比性。需要跨团队比较时，先统一打回原因枚举、评审环节边界和时间窗口径。
小样本要谨慎处理。分母过小时，比例波动大，建议设定最小样本量，低于阈值只记录绝对数和评审量，不解读百分比。分母为零的窗口标记为不适用，避免把“没有评审”误读为“没有打回”。
指标与缺陷真实质量要分开看。打回比例低，可能说明记录规范执行得好，也可能说明评审把关宽松；打回比例高，可能说明提交信息不足，也可能说明评审标准刚收紧。解读时应结合原因分布、澄清轮次和评审规则变化一起判断。
建议按周或按迭代持续跟踪，观察趋势而不是单点数值，并在模板、提交指引或评审规则调整后对比前后几个窗口的变化。把该指标作为缺陷记录质量的观察信号之一，与缺陷数量、严重程度分布等指标并列使用，不单独作为个人绩效依据。
常见问题
缺陷在评审前就被提交人自己撤回修改，算不算因信息不全被打回？
一般不计入分子。主指标统计的是评审或受理环节发生的打回事件，提交人主动撤回属于提交前的自我修正，没有形成打回记录。如果团队希望观察这类情况，可以单独统计“提交后撤回修改”的次数，作为辅助信号，与打回比例并列看，不混入同一分子。
同一个缺陷在统计窗口内被打回三次，分子应该计几次？
主指标按缺陷去重，只计一次，这样比例回答的是“多少缺陷受影响”。三次打回反映的是反复程度，应通过辅助指标体现：把每次要求补充信息都计入“要求补充信息次数”，再除以分母缺陷数得到次/条；澄清轮次按实际沟通轮次累计，除以发生澄清的缺陷数得到平均轮次。两个口径分开统计，避免主指标被重复计数放大。
打回原因字段是自由文本，历史数据写法五花八门，怎么统计？
先做一次归类映射：把历史自由文本按语义归并到描述缺失、复现步骤缺失、环境信息缺失、预期结果缺失、重复缺陷、非缺陷、优先级争议等类别，无法判断的单独列为“待复核”，不默认计入分子。映射规则写成文档并保留原始文本，便于追溯。此后把打回原因改为必填枚举字段，新数据按统一口径记录，历史数据与新增数据在报表中分开标注，避免口径混用。
缺陷创建在上一周期、打回发生在当前周期，应该计入哪一期？
按打回事件发生时间归属当前周期，计入当前周期的分子。同时分母要取同一窗口内进入评审环节的缺陷，保证分子分母的时间口径一致。如果一条缺陷的评审进入事件在上一周期、打回在当前周期，需要在统计说明中明确处理方式，常见做法是分子按打回时间、分母按评审进入时间分别归属各自窗口，并在跨期缺陷清单中留痕，避免同一事件被两个窗口重复统计或漏计。
这个比例算出来之后，能不能直接用来考核提交缺陷的测试人员？
不建议直接作为个人考核依据。比例受评审严格程度、缺陷类型分布、模板变更等因素影响，同一个人在不同项目上的数值未必可比；评审把关收紧时比例会整体上升，与个人提交质量关系不大。更稳妥的用法是作为团队层面的记录质量观察信号，结合原因分布和澄清轮次看趋势，在模板或提交指引调整后对比前后几个窗口的变化，个人层面以具体打回记录的复盘代替排名。
