衡量缺陷描述不清，可以围绕“因信息不全被打回、要求补充、反复澄清”建立一组可复算的比率指标：缺陷打回率、补充信息请求率、平均澄清轮次、澄清耗时占比和一次通过率。计算时统一以时间窗内进入评审或受理的缺陷单为分母，以发生对应事件的缺陷单为分子，并预先明确打回原因分类、缺失字段判定和重复计数规则。这组指标反映缺陷记录质量与沟通成本，适合用于改进评审流程和提交规范。
要点总览（TL;DR）
- 衡量缺陷描述不清，核心是围绕“因信息不全被打回、要求补充、反复澄清”建立五类比率指标：缺陷打回率、补充信息请求率、平均澄清轮次、澄清耗时占比和一次通过率。
- 计算时统一以时间窗内首次进入评审的缺陷单为分母，以发生对应事件的缺陷单为分子；同一缺陷多次打回在打回率中只计一次，在澄清轮次中按实际轮次累计。
- 分母为零的窗口标记为“无样本”，不用0%代替；统计字段缺失的缺陷单从对应指标中剔除，并单独报告剔除数量。
- 打回原因需预先分类（复现步骤缺失、环境信息缺失、预期结果不明、日志缺失等），缺失字段判定写入评审清单，减少主观判断。
- 指标反映记录质量与沟通成本，受评审严格度和流程成熟度影响，适合作为改进提交模板与评审流程的输入，不宜作为个人绩效考核的唯一依据。
评估目标：把“描述不清”拆成可观测的事件
评估对象是缺陷单的记录完整性，即一张缺陷单是否包含复现所需的环境、步骤、预期结果、实际结果、日志或截图等关键信息。描述不清表现为评审人无法据此判断或复现问题，需要退回补充。它与缺陷严重程度判定属于不同问题：严重程度回答“问题影响多大”，描述完整性回答“记录是否足以支撑处理”。它也与服务事件受理不同，后者关注用户请求是否被正确接单和分派。
评估目标可以表述为：降低因信息缺失导致的打回次数和澄清往返，让缺陷单在首次提交时具备可处理条件。指标服务于流程改进，用于发现哪类字段最常缺失、哪个提交环节最需要提示，不直接用于给个人打分。把评估对象限定在记录质量上，后续的分子、分母和原因分类才有稳定边界。
指标与范围：五类核心指标及适用场景
五类指标从不同角度观察同一类事件，单独看一个指标容易得出片面结论，组合使用才能同时看到发生频率、沟通强度和一次提交质量。
| 指标 | 定义 | 回答的问题 |
|---|---|---|
| 缺陷打回率 | 时间窗内因信息不全被打回的缺陷单数 ÷ 同期进入评审的缺陷单数 | 有多大比例的缺陷单无法直接进入处理 |
| 补充信息请求率 | 时间窗内至少发出一次补充信息请求的缺陷单数 ÷ 同期进入评审的缺陷单数 | 评审过程中有多少缺陷单需要额外索取信息 |
| 平均澄清轮次 | 时间窗内澄清事件总次数 ÷ 发生澄清的缺陷单数 | 一张需要澄清的缺陷单平均要往返几轮 |
| 澄清耗时占比 | 缺陷单从首次提交到信息满足可处理条件所耗时间 ÷ 该缺陷单从提交到关闭的总时长 | 澄清在缺陷处理周期中占用了多少时间 |
| 一次通过率 | 首次评审即通过、未发生打回或补充请求的缺陷单数 ÷ 同期进入评审的缺陷单数 | 首次提交的记录有多大比例可以直接处理 |
打回率适合观察评审入口的拦截情况；补充信息请求率覆盖评审中口头或评论里索要信息的情形，二者可能重叠，需要在口径上约定是否互斥。平均澄清轮次衡量沟通强度，澄清耗时占比衡量时间成本，一次通过率则从正面反映提交质量。评审与打回统计场景中，建议以打回率和一次通过率作为主指标，澄清轮次和耗时占比作为解释性指标。
数据口径：分子、分母、时间窗与缺失值处理
口径统一的关键是固定三件事：分母取哪个时间窗内进入评审的缺陷单，分子取同一批缺陷单中发生对应事件的数量，事件按缺陷单去重还是按次数累计。推荐以“缺陷单”为统计单位，时间窗按周或按迭代设定，事件发生时间落在窗口内即计入。
| 指标 | 分子 | 分母 | 单位与计数规则 |
|---|---|---|---|
| 缺陷打回率 | 窗口内至少被打回一次且原因为信息不全的缺陷单数 | 窗口内首次进入评审的缺陷单数 | 百分比；同一缺陷多次打回只计一次 |
| 补充信息请求率 | 窗口内至少发出一次补充信息请求的缺陷单数 | 同上 | 百分比；与打回事件按缺陷单去重合并 |
| 平均澄清轮次 | 窗口内澄清事件总次数 | 窗口内发生澄清的缺陷单数 | 轮/单；按事件次数累计，同一轮多次留言合并为一轮 |
| 澄清耗时占比 | 各缺陷单澄清时长之和 | 各缺陷单从提交到关闭的总时长之和 | 百分比；按缺陷单汇总后相除，避免短周期单据权重失真 |
| 一次通过率 | 首次评审通过且无补充请求的缺陷单数 | 窗口内首次进入评审的缺陷单数 | 百分比；与打回率互为补充，不要求相加等于100% |
分母为零时，该时间窗不计算比率，报表中显示“无样本”，不用0%代替，避免把没有评审活动误读为质量很好。字段缺失分两种处理：缺陷单本身缺少环境、步骤等必填信息，按缺失字段标记计入打回原因；统计字段（如打回时间、澄清次数）未记录，则该缺陷单从对应指标中剔除，并单独报告剔除数量。同一缺陷多次打回时，打回率按缺陷单计一次，平均澄清轮次按实际轮次累计，两个口径分开存储，避免混用。
计算与评估步骤：从打回原因到指标产出
落地时先把“描述不清”变成评审人可勾选的原因项，再按固定流程取数和复核。步骤如下：
- 定义打回原因分类。建议至少包含复现步骤缺失、环境或版本信息缺失、预期结果不明、实际结果描述模糊、日志或截图缺失、其他。每类对应一个可判定的缺失字段，写入评审清单。
- 在缺陷单上标记缺失字段。评审人打回时选择原因分类，并记录打回时间；补充信息请求同样记录时间和轮次。标记动作与评审动作同步完成，避免事后补录。
- 按时间窗取数。以缺陷单首次进入评审的时间确定归属窗口，导出窗口内缺陷单清单及打回、补充请求、澄清、关闭等事件记录。
- 计算五项指标。先算分母，再按缺陷单去重计算分子；平均澄清轮次和澄清耗时占比按事件和时长汇总。分母为零的窗口标记为无样本。
- 交叉验证与抽样复核。抽取一定数量的打回单，核对原因分类与缺失字段是否一致；将打回率与一次通过率对照，两者趋势应大致互补，出现明显矛盾时回查事件记录。
如果团队使用研发管理工具承载缺陷流程，可以把缺陷单作为工作项，在状态流转中设置“待补充信息”状态，并用自定义字段记录打回原因和缺失字段。ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代并跟踪修复情况，也可统计缺陷状态分布；ONES TestCase 中未通过的用例可快速创建缺陷任务，并在测试与研发团队间流转。将打回原因和澄清轮次作为字段沉淀后，再用报表按项目、迭代或提交人维度汇总，指标取数就能与日常评审动作保持一致。具体字段配置和报表可计算维度需在实际环境中核验。
例子：一个迭代周期的打回率与澄清轮次计算
假设某迭代内共有120张缺陷单首次进入评审，其中18张因信息不全被打回，打回原因分布为：复现步骤缺失7张、环境信息缺失5张、日志缺失4张、预期结果不明2张。另有6张未被打回但收到补充信息请求，其中2张与打回单重叠。澄清事件共记录30次，发生在20张缺陷单上。首次评审直接通过且无补充请求的缺陷单为96张。
按口径计算：打回率 = 18 ÷ 120 = 15.0%；补充信息请求率按去重后的缺陷单计算，(18 + 6 − 2) ÷ 120 = 22 ÷ 120 ≈ 18.3%；平均澄清轮次 = 30 ÷ 20 = 1.5轮/单；一次通过率 = 96 ÷ 120 = 80.0%。澄清耗时方面，假设20张澄清单的澄清时长合计为46小时，这些单据从提交到关闭的总时长合计为230小时，则澄清耗时占比 = 46 ÷ 230 = 20.0%。
再假设下一个统计窗口没有缺陷单进入评审，分母为0，此时五项指标均显示“无样本”，不输出0%。结果解读上，15%的打回率说明每六七张缺陷单就有一张需要退回补充，其中复现步骤和环境信息是主要缺口；1.5轮的平均澄清轮次说明多数澄清在一次往返内完成，沟通成本集中在少数单据；20%的澄清耗时占比提示澄清占用了约五分之一的处理周期，值得优先在提交模板中补齐环境与步骤字段。
解读与限制：指标能说明什么、不能说明什么
这组指标说明的是缺陷记录在评审入口的完整程度和澄清沟通的强度。打回率上升，可能意味着提交质量下降，也可能意味着评审标准变严或新增了必填字段；一次通过率提高，可能来自模板改进，也可能来自评审人放宽了判定。解读时应结合打回原因分布和评审清单版本一起看，避免把比率变化直接归因于某一方。
指标受流程成熟度和评审严格度影响，不同项目、不同迭代之间可比性有限。跨团队比较前，应确认打回原因分类、缺失字段判定和统计时间窗一致。平均澄清轮次对事件记录方式敏感，如果评论留言未按轮次合并，数值会偏高；澄清耗时占比依赖提交和关闭时间的准确性，补录时间会扭曲结果。
使用上，建议把这组指标作为改进记录质量和评审流程的输入，用于定位高频缺失字段、优化提交模板和评审清单。单指标不宜作为个人绩效考核的唯一依据，也不宜据此推断缺陷本身的严重程度或产品质量。将打回率、一次通过率与澄清轮次、耗时占比结合观察，并定期抽样复核原因分类，才能让指标持续反映真实的描述质量问题。
常见问题
打回率和补充信息请求率有重叠，统计时应该合并还是分开？
两种口径都可以，关键是提前约定并保持稳定。如果希望观察“评审入口拦截”的整体情况，可以把打回和补充信息请求按缺陷单去重合并，得到一张缺陷单是否发生过信息索取的比例；如果希望区分“正式退回”和“评审中口头索要”两种处理方式，则分开统计，并在报表中注明两者存在重叠。无论选哪种，都应在同一时间窗、同一分母下计算，避免跨期比较时口径漂移。
团队刚开始记录打回原因，历史数据不完整，指标还能用吗？
可以先用起来，但要区分数据质量。建议从启用原因分类的时间点开始计算，把之前的缺陷单标记为“未分类”并单独列出数量，不混入打回率分子。运行一段时间后，用抽样复核检查原因分类与缺失字段是否一致；如果未分类占比过高，先补录或缩小统计范围，再对外发布比率。指标的价值在于持续观察趋势，起步阶段样本少、分类粗是正常现象。
平均澄清轮次偏高，应该先改提交模板还是先改评审流程？
先看澄清事件的分布。如果澄清集中在少数缺陷单上，且原因多为复现步骤或环境信息缺失，优先优化提交模板和必填字段提示；如果澄清普遍发生、轮次分散，可能是评审清单不明确或评审人判定标准不一致，应先统一评审清单和打回原因分类。两种动作可以并行，但建议每次只改一个变量，观察一到两个统计窗口后再判断效果。
这些指标能不能直接用来考核提交缺陷的测试人员？
不建议单独用于个人考核。打回率受评审严格度、缺陷类型分布和提交人经验影响，同一团队内不同模块的缺陷复杂度差异也会扭曲比较。更稳妥的做法是把指标用于流程改进：定位高频缺失字段、优化模板、组织评审标准对齐。如果确实需要与个人关联，应结合缺陷单抽样复核和多人评审结果，并明确指标只反映记录完整性，不反映缺陷发现能力或工作投入。
澄清耗时占比计算时，提交到关闭的总时长包含等待修复的时间，会不会失真？
会包含，这正是该指标的定义方式：它衡量澄清在完整处理周期中的时间占比，而不是澄清本身的绝对耗时。如果希望排除等待修复、排队等非澄清时间，可以另设一个“澄清时长占活跃处理时长”的辅助口径，但需要额外记录状态停留时间。两种口径用途不同，前者适合看整体周期影响，后者适合定位澄清环节本身的效率，报表中应标明使用的是哪一种。
