测试数据在测试执行阶段才暴露不可用，往往意味着准备环节缺少可核验的评估标准。本文给出一套可在执行前使用的指标设计方法：把数据可用性拆成就绪及时性、完整性、合规与脱敏、可复用与一致性四个维度，用“执行前数据可用率”和“临期未就绪率”两个主指标驱动预警，并说明分子分母、时间窗、阈值分级和计算示例。
要点总览（TL;DR）
- 把测试数据可用性拆成就绪及时性、完整性、合规与脱敏、可复用与一致性四个维度，每个维度配一个可复算的指标。
- 主指标只保留两个：执行前数据可用率用于准入判断，临期未就绪率用于提前预警；缺失字段率、脱敏覆盖率、数据版本不一致数作为诊断指标。
- 以测试数据需求单为分母基准，固定分子、分母、统计单位和时间窗；分母为零记为“无数据”，需求变更重新登记，部分可用按不可用计入分子。
- 阈值先采集2至3个迭代的自身基线，再设提醒、预警、阻断三档，并随版本节奏和数据复杂度复核调整。
- 指标反映准备阶段状态，不直接等同于缺陷率或产品质量，跨期比较需排除需求口径、环境和统计范围变化。
评估目标：把“执行阶段才暴露”提前到准备阶段
测试数据可用性评估要回答三个问题：数据是否在约定时间前就绪；就绪的数据是否满足用例对字段、数量、状态和关联关系的要求；数据是否完成脱敏并符合使用范围要求。三个问题分别对应时间、内容与合规，任何一项未通过，数据在执行阶段都可能表现为阻塞、结果失真或合规风险。
评估时点需要前移到测试执行前的准备与准入环节。具体做法是在测试计划进入执行状态之前设置一次核验节点，由数据准备方或测试负责人按数据需求单逐项确认，并记录核验结果。执行阶段出现的报错可以作为事后补充信息，用于修正需求登记和核验项，不作为主指标的统计入口。
评估对象包括四类：测试数据集本身（含基础数据与业务数据）、从生产数据生成的脱敏副本、用于生成数据的造数脚本及其执行结果、以及数据所依赖的环境数据（如配置参数、字典表、第三方模拟服务的数据）。服务器资源、网络状态等运维对象不在本文评估范围内，它们属于环境可用性，需要单独度量。
指标与范围：四个维度与主指标选择
指标框架按四个维度组织，每个维度设置一个主指标或诊断指标。主指标用于驱动预警和准入判断，数量控制在两个，避免口径维护成本过高；诊断指标用于定位问题原因，在预警触发后辅助分析。
| 维度 | 指标 | 类型 | 用途 |
|---|---|---|---|
| 就绪及时性 | 执行前数据可用率 | 主指标 | 衡量准备阶段结束时，需求单中数据可用的比例，作为准入依据 |
| 就绪及时性 | 临期未就绪率 | 主指标 | 衡量临近执行时间仍未就绪的需求占比，用于提前触发预警 |
| 完整性 | 缺失字段率 | 诊断指标 | 定位数据内容不满足用例要求的具体原因 |
| 合规与脱敏 | 脱敏覆盖率 | 诊断指标 | 衡量应脱敏数据实际完成脱敏的比例 |
| 可复用与一致性 | 数据版本不一致数 | 诊断指标 | 统计同一数据集在不同环境或不同需求单之间版本不一致的数量 |
两个主指标覆盖的风险不同：执行前数据可用率回答“准备阶段结束时能不能开始执行”，临期未就绪率回答“是否需要在执行前介入协调”。前者用于准入，后者用于预警，两者结合可以区分“整体准备良好但个别需求拖到最后”和“整体准备不足”两种情形。
诊断指标不单独设定阻断阈值，而是作为预警触发后的分析维度。例如执行前可用率低于阈值时，查看缺失字段率和脱敏覆盖率，判断问题集中在数据内容还是合规处理，从而把处置动作指向具体环节。
数据口径：分子分母、时间窗与缺失值处理
每个指标需要固定分子、分母、统计单位和时间窗，保证不同人复算结果一致。下表给出建议口径，组织可根据自身需求单模板调整字段名称，但计算逻辑应保持稳定。
| 指标 | 分子 | 分母 | 统计单位 | 时间窗 |
|---|---|---|---|---|
| 执行前数据可用率 | 核验结果为“可用”的需求单数 | 时间窗内应完成核验的需求单总数 | 需求单（一条需求单对应一个数据集或一次造数请求） | 单个测试计划执行开始前，或按迭代统计 |
| 临期未就绪率 | 距要求就绪时间不足约定提前量、且状态仍为“未就绪”的需求单数 | 同一时间窗内全部未关闭的需求单数 | 需求单 | 按日或按执行前固定提前量（如执行前1个工作日）统计 |
| 缺失字段率 | 核验中发现缺失或不符合要求的字段数 | 需求单声明的必需字段总数 | 字段 | 与对应需求单核验时点一致 |
| 脱敏覆盖率 | 已完成脱敏的敏感字段数 | 识别出的敏感字段总数 | 字段 | 按数据集版本统计 |
| 数据版本不一致数 | — | — | 数据集 | 按迭代或按环境同步周期统计 |
分母以测试数据需求单为基准登记单元。需求单在执行前准备阶段登记，登记内容包括数据集名称、关联用例或测试计划、要求就绪时间、必需字段清单、敏感字段清单和数据版本。需求发生变更时，重新登记并标注变更时间，原需求单标记为已变更，不参与变更后的统计，避免同一需求跨口径重复计数。
边界情况需要事先约定处理规则：分母为零时，该时间窗指标记为“无数据”，不按0%或100%处理，并在报表中注明；需求单在统计窗口内被取消且未产生执行依赖的，从分母中剔除并记录原因；核验结果为“部分可用”的需求单，在可用率中按不可用计入分子，同时在诊断指标中记录部分可用的具体项，便于区分“完全缺失”和“部分满足”。
计算与评估步骤：从需求登记到执行前核验
评估流程分为四步，每步都有明确的输入、动作和产出，保证核验结果可以追溯到具体需求单。
步骤一：需求登记与分级。测试人员在准备阶段提交数据需求单，填写关联用例、要求就绪时间、必需字段、敏感字段和数据量级。数据准备方确认需求单后，按对执行的影响程度分级，例如“阻断执行”“影响部分用例”“可延后”。分级结果决定后续预警的处置力度。
步骤二：执行前逐项核验。在测试计划进入执行状态前，按需求单逐项核验并记录。核验记录建议包含以下字段：需求单编号、数据集名称、关联用例或测试计划、要求就绪时间、实际核验时间、核验结果（可用/部分可用/不可用）、缺失项说明、脱敏状态、数据版本、核验人。核验结果以记录为准，口头确认不计入统计。
步骤三：按公式计算并汇总。以测试计划或迭代为统计单元，汇总需求单核验结果，计算执行前数据可用率和临期未就绪率，同时汇总诊断指标。计算时点固定在执行开始前，避免执行过程中数据状态变化影响结果。
步骤四：对照阈值触发预警与处置。将计算结果与分级阈值比对，触发对应动作。预警信息应包含未就绪需求单清单、影响用例范围和责任人，处置完成后更新核验记录，形成闭环。
在核验记录和预警流转环节，可以借助研发管理平台承载。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可分配执行人并多维度概览进度。将数据需求单作为工作项登记、把核验结果记录在关联文档或字段中，可以让预警清单与测试计划保持同一套对象和状态，减少线下表格与计划脱节的情况。具体字段配置和报表能力需结合版本向厂商确认。
预警阈值怎么设：分级与触发规则
阈值应基于自身历史基线确定，不采用行业通用达标线。建议先采集2至3个迭代的执行前数据可用率和临期未就绪率，观察均值和波动范围，再按分位数或均值加减波动区间设定三档阈值。数据复杂度高、依赖外部系统的团队，基线本身会偏低，阈值应反映自身可改善的空间。
| 档位 | 触发条件（示例口径） | 对应动作 |
|---|---|---|
| 提醒 | 临期未就绪率高于基线均值，但未超过预警线 | 通知数据准备方和测试负责人，要求在执行前一个工作日内反馈预计就绪时间 |
| 预警 | 执行前数据可用率低于基线下限，或临期未就绪率超过预警线 | 组织执行前协调，评估是否调整测试计划顺序，优先执行数据已就绪的用例 |
| 阻断 | 阻断级需求单在执行开始前仍未就绪，或可用率低于阻断线 | 暂停相关测试计划进入执行状态，升级至项目负责人，明确恢复条件后再放行 |
阈值需要随版本节奏和数据复杂度调整。大版本或涉及数据迁移的迭代，数据准备周期更长，可在迭代开始前临时上调预警容忍度，并在迭代结束后复核是否恢复；连续多个迭代稳定优于阈值的，可以收紧阈值以推动改进。调整记录应保留，避免阈值频繁变动导致跨期比较失真。
例子：一个迭代周期的指标计算
以下为演示情景，数字仅用于说明公式和计算过程，不代表任何组织的实际水平。
某迭代共有20条测试数据需求单，其中2条在执行前因用例调整被取消并确认无执行依赖，从分母中剔除，实际参与统计的需求单为18条。执行开始前核验结果为：可用13条，部分可用3条，不可用2条。
执行前数据可用率 = 13 ÷ 18 ≈ 72.2%。部分可用的3条按不可用计入分子，但在诊断记录中标注具体缺失项。
临期未就绪率按执行前1个工作日统计：18条需求单中，距要求就绪时间不足1个工作日且状态仍为未就绪的有4条，临期未就绪率 = 4 ÷ 18 ≈ 22.2%。
假设该团队历史基线为可用率均值85%、下限80%，临期未就绪率预警线为15%，阻断线为可用率低于70%。本次可用率72.2%低于预警线但高于阻断线，临期未就绪率22.2%超过预警线，触发“预警”档：组织执行前协调，确认4条未就绪需求单中2条为阻断级，调整测试计划顺序，先执行数据已就绪的用例，并要求数据准备方在当日内反馈剩余数据的就绪时间。若次日阻断级需求单仍未就绪，则升级为阻断，暂停相关计划执行。
诊断指标同步记录：3条部分可用需求单共缺失7个必需字段，缺失字段率为7 ÷ 该3条需求单声明字段总数；脱敏覆盖率为已脱敏敏感字段数 ÷ 识别出的敏感字段总数。两项数据用于判断问题集中在数据内容还是脱敏处理，指导后续改进。
解读与限制：指标能说明什么、不能说明什么
这组指标反映的是测试数据在准备阶段的就绪状态和流程执行情况，能够帮助团队在执行前识别风险、定位问题环节。它不直接等同于缺陷率或产品质量结果：数据可用率高，说明准备环节执行到位，不能推断测试覆盖充分或版本质量良好；数据可用率低，也不必然意味着产品质量差，可能只是准备周期安排不合理。
以下情形会导致数据不可比，跨期比较时应暂停或标注：需求口径变更，例如必需字段清单调整导致分母变化；环境差异，例如不同环境的脱敏规则或数据量级不同；统计范围调整，例如需求单登记规则变化或取消规则变化。出现这些情况时，应重新采集基线后再设定阈值。
指标适合用于流程改进和风险预警，不适合作为个人或团队的单一考核依据。需求单数量、数据复杂度和依赖关系在不同团队之间差异较大，直接横向排名会掩盖条件差异。使用时建议结合诊断指标和具体核验记录一起解读，把指标作为发现问题的入口，把处置动作和改进措施作为评估的落点。
常见问题
需求单在执行前被临时取消，指标里怎么处理？
先确认该需求单是否已产生执行依赖。没有执行依赖的，从分母中剔除并记录取消原因和取消时间；已经产生依赖的，保留在分母中，核验结果按实际状态计入。取消规则应在统计前固定下来，同一时间窗内不要中途改变剔除标准，否则前后口径不一致，指标无法复算。
数据只满足部分用例要求，算可用还是不可用？
在执行前数据可用率中按不可用计入分子，这样准入判断不会因为“部分满足”而放宽。同时在核验记录里标注部分可用的具体缺失项，并计入缺失字段率等诊断指标。这样处理可以区分“完全缺失”和“部分满足”两种情形，预警触发后能直接定位到是字段内容问题还是数据整体未就绪。
团队刚开始做这项评估，没有历史基线怎么设阈值？
先不设阻断线，用2至3个迭代采集执行前数据可用率和临期未就绪率的实际分布，观察均值和波动范围，再按分位数或均值加减波动区间确定提醒和预警两档。基线稳定后再补阻断档。初期可以把阈值设得宽一些，重点是把核验记录和需求单登记跑顺，避免阈值过严导致预警频繁触发、团队对预警失去反应。
核验记录放在线下表格里可以吗？
可以运行，但要注意与测试计划的状态同步。线下表格容易和测试计划脱节，出现计划已进入执行、核验记录还停留在准备状态的情况。把数据需求单作为工作项登记、核验结果记录在关联字段或文档中，可以让预警清单和测试计划使用同一套对象与状态。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，可作为承载核验记录和预警流转的平台；数据可用性维度的专门字段与报表需结合版本向厂商确认。
指标连续几个迭代都达标，阈值要不要收紧？
可以收紧，但要保留调整记录。建议连续三个迭代稳定优于阈值后再调整，每次调整幅度控制在基线波动范围内，避免阈值频繁变动导致跨期比较失真。大版本或涉及数据迁移的迭代，数据准备周期更长，可在迭代开始前临时上调容忍度，迭代结束后复核是否恢复。
