测试数据在测试执行阶段才暴露不可用，往往意味着准备环节缺少可观测的预警信号。可行的做法是先把“数据不可用”拆成数据缺失、数据过期、数据被占用、生成失败、依赖服务不可达五类信号，为每类定义指标口径；再按测试计划开始时间倒排预警窗口，设置提示、预警、阻断三级阈值；预警触发后由数据负责人确认并给出可用结论，未通过确认的用例不进入执行队列。阈值应先用历史故障记录校准，先宽后紧，并保留人工复核。
要点总览（TL;DR）
- 把“数据不可用”拆成数据缺失、数据过期、数据被占用、生成失败、依赖服务不可达五类信号，为每类写清统计对象、计算方式、采集时点和数据来源，阈值才有计算基础。
- 按数据准备耗时与重试次数从测试计划开始时间倒排预警窗口，设置提示、预警、阻断三级阈值；初始值用近3个月故障记录回测校准，先宽后紧，按月复盘误报与漏报。
- 预警触发后由数据负责人确认并给出可用结论，测试负责人调整执行队列，环境管理员处理占用与服务恢复，开发接口人处理生成失败；未确认可用的用例保持待确认状态，不进入执行队列。
- 阈值判断要结合剩余修复窗口：同样的缺失率，距执行还有一天和只剩两小时，处置结论不同。
- 机制上线前完成指标可采集、阈值回测、预警触达、升级路径和执行准入联动五项检查，试运行期间保留人工复核。
先定义“数据不可用”的五类信号与指标口径
阈值要能起作用，前提是“不可用”可以被计算。建议在测试数据准备环节固定五类信号，每类信号对应一个可采集的指标，避免用“数据有问题”这类笼统描述触发预警。
指标口径需要写清四件事：统计对象是什么、分子分母如何计算、在什么时点采集、数据从哪里来。口径一旦确定，后续阈值调整才有可比性。
| 信号类型 | 统计对象 | 计算方式 | 采集时点 | 数据来源 |
|---|---|---|---|---|
| 数据缺失 | 测试计划所需的数据集或数据记录 | 缺失记录数 ÷ 计划所需记录数 | 数据准备完成后、执行前检查点 | 数据准备清单、数据集比对结果 |
| 数据过期 | 数据集或关键字段 | 超过有效期或版本落后的数据集数 ÷ 计划使用数据集总数 | 执行前检查点，每日刷新一次 | 数据版本记录、有效期字段 |
| 数据被占用或锁定 | 计划使用的数据记录或账号 | 被其他任务占用或锁定的记录数 ÷ 计划使用记录数 | 执行前检查点，临近执行时加密采集 | 数据占用登记、锁状态查询 |
| 数据生成失败 | 本批次数据生成任务 | 失败任务数 ÷ 本批次生成任务总数 | 生成任务结束后立即采集 | 生成任务日志、任务状态 |
| 依赖服务不可达 | 测试数据所依赖的服务或接口 | 不可达服务数 ÷ 依赖服务总数 | 执行前检查点，执行前1小时复测 | 健康检查结果、接口探测记录 |
指标还要与测试用例或测试集建立关联。做法是在测试计划中为每个用例标注所需数据集、数据版本和依赖服务，指标按测试集汇总，再下钻到用例。这样预警发出时，测试负责人能直接看到受影响的用例范围，而不是只知道“某类数据有问题”。
按测试计划倒排预警窗口与分级阈值
预警窗口从测试计划开始时间往前推，推算依据是数据准备耗时和允许的重试次数。例如某类数据平均准备耗时4小时、最多重试2次、每次重试约1小时，则至少应在执行前6小时完成首次检查，在执行前2小时保留最后一次复测机会。窗口过短，预警发出后没有修复余地；窗口过长，数据状态可能再次变化。
分级阈值建议设三级，每级对应不同的处置力度：
| 级别 | 触发条件（示例口径） | 初始值建议 | 校准依据 | 调整周期 |
|---|---|---|---|---|
| 提示 | 任一信号指标超过基线但仍有修复时间 | 数据缺失率≥5%，过期率≥10% | 近3个月执行前发现的问题记录 | 每月复盘一次 |
| 预警 | 指标持续恶化或已接近影响执行的程度 | 数据缺失率≥15%，生成失败率≥10%，占用率≥20% | 历史故障中导致用例延期或返工的取值分布 | 每月复盘，连续两月误报则放宽 |
| 阻断 | 关键数据集缺失、依赖服务不可达或修复窗口不足 | 关键数据集缺失率>0，依赖服务不可达数>0，且距执行不足2小时 | 历史阻断事件与执行取消记录 | 每季度校准一次 |
初始值不要一次定得过紧。先用历史故障记录回测：把过去若干次执行前暴露的数据问题代入指标，看阈值能否在问题影响执行前触发。若多数问题在提示级就被发现，说明阈值偏宽；若提示频繁触发但很少演变为真实阻断，说明阈值偏紧或口径不清。调整节奏建议按月复盘误报与漏报，按季度校准阻断阈值，每次调整保留变更记录，避免阈值随人员变动而漂移。
预警触发后的处置流程与角色分工
预警只有落到人和时限上才会影响执行准入。建议明确四类角色：数据负责人负责确认数据状态并给出可用结论；测试负责人判断受影响用例是否调整执行顺序；环境管理员处理依赖服务与数据占用冲突；开发接口人处理生成失败或数据逻辑问题。
| 角色 | 主要动作 | 时限 | 输出 |
|---|---|---|---|
| 数据负责人 | 核对指标、确认不可用范围、决定修复或重生成 | 提示级4小时内，预警级2小时内，阻断级30分钟内 | 数据可用结论与影响用例清单 |
| 测试负责人 | 调整执行顺序、标记暂缓用例、通知相关测试人员 | 收到结论后1小时内 | 更新后的执行队列 |
| 环境管理员 | 释放被占用数据、恢复依赖服务、协调环境资源 | 预警级2小时内，阻断级1小时内 | 环境与占用状态恢复记录 |
| 开发接口人 | 排查生成失败原因、修复数据逻辑或接口问题 | 按预警级别约定，阻断级优先处理 | 修复说明或替代方案 |
预警状态要与用例执行准入联动：数据负责人未给出“可用”结论的用例，状态保持“待确认”，不进入执行队列；确认可用后再转为“可执行”。若阻断级预警在时限内未解除，升级到测试负责人和项目负责人共同判定，可选择延期执行、改用降级替代数据或缩小执行范围。降级替代数据需要记录替代范围和限制，避免后续把降级结果当作完整验证结论。
在工具承载上，可以把预警状态作为测试计划或测试用例工作项的一个状态字段，把数据可用结论、影响范围和处置记录挂在同一工作项下。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持用例分配执行人和未通过用例快速创建缺陷任务，便于把预警确认、缺陷流转和执行状态放在同一条流程里；阈值配置与自动告警的具体实现方式需按实际产品配置核验。
一个完整示例：从预警触发到执行准入
以下为演示情景，用于说明阈值如何生效，数值可按项目实际调整。
某测试计划定于周三10:00开始，涉及订单模块120条用例，所需数据集3个，依赖支付模拟服务1个。按准备耗时倒排，周二16:00做首次检查，周三8:00做执行前复测。
周二16:00检查结果：订单主数据集缺失8条，缺失率约6.7%，触发提示级；数据过期率为0；占用率为5%；生成任务全部成功；依赖服务可达。数据负责人4小时内确认缺失记录为非关键字段，安排补充生成，测试负责人暂不调整队列。
周三8:00复测：缺失记录仍有3条未补齐，缺失率约2.5%，但支付模拟服务健康检查失败，依赖服务不可达数为1，且距执行不足2小时，触发阻断级。数据负责人30分钟内确认支付相关用例无法执行，影响用例28条；环境管理员1小时内恢复服务；测试负责人将28条用例标记为暂缓，其余92条按计划执行。9:40服务恢复并经复测通过，数据负责人给出可用结论，28条用例转入可执行，最终按调整后的队列执行。
这个例子说明两点：提示级预警给了修复时间，阻断级预警则直接改变了执行队列；阈值判断必须结合剩余修复窗口，而不能只看指标数值。
上线前的完成检查
机制投入使用前，建议逐项核对以下内容，确认预警能在执行前触达责任人并形成闭环。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 指标口径可采集 | 五类信号均有明确统计对象、计算方式和采集时点，且能按测试集下钻到用例 | 数据负责人 |
| 阈值经过历史回测 | 用近3个月故障记录回测，提示、预警、阻断三级均能覆盖已知问题，误报率在可接受范围 | 测试负责人 |
| 预警可在执行前触达 | 按倒排窗口完成至少一次演练，责任人能在时限内收到并确认预警 | 测试负责人、数据负责人 |
| 处置时限与升级路径明确 | 四类角色的动作、时限、输出已书面确认，阻断未解除时有明确升级对象 | 环境管理员 |
| 执行准入联动有效 | 未确认可用的用例不会进入执行队列，确认后可正常流转 | 测试负责人 |
| 误报与漏报有复盘记录 | 每次阈值调整都有依据和变更记录，复盘结论可追溯到具体事件 | 数据负责人 |
完成以上检查后，阈值机制可以进入试运行。试运行期间保留人工复核，待误报和漏报趋于稳定，再逐步收紧阈值或扩大自动阻断范围。
常见问题
测试数据准备周期很短，倒排不出足够的预警窗口怎么办？
准备周期短时，把预警重心前移到数据生成环节，而不是压缩执行前检查。具体做法是：在生成任务结束时立即采集生成失败率，生成失败即触发预警，把修复时间留在生成阶段；执行前检查只保留依赖服务可达性和数据占用两项轻量复测。若某类数据确实无法提前准备，可在测试计划中标注为“执行时生成”，并为这类用例单独设置更短的复测间隔和更严格的阻断条件，避免它们拖累整个计划的准入判断。
提示级预警频繁触发但很少真正影响执行，阈值应该怎么调？
先区分是阈值偏紧还是口径不清。如果提示级触发集中在某一类信号，检查该类指标的统计对象是否过宽，例如把整个数据集算作缺失单位，导致少量记录缺失就触发提示。口径澄清后仍频繁误报，再放宽该级阈值，并记录调整前后的触发次数与真实影响次数。调整时保留变更记录，观察一个完整复盘周期再决定是否继续放宽，避免一次调得过松导致漏报。
关键数据集缺失和普通数据集缺失，阈值需要分开设置吗？
建议分开。关键数据集直接决定核心用例能否执行，缺失率大于零即可进入阻断级判断，并同时看距执行的剩余时间；普通数据集缺失可以按比例设提示和预警两级，留出补充生成的时间。分开设置的前提是在测试计划中标注每个数据集的关键程度，否则预警发出后无法快速判断影响范围。标注工作可以在测试计划编制时随用例关联一起完成。
预警状态如何与测试用例的执行准入联动？
把数据可用结论作为用例进入执行队列的前置条件：数据负责人未确认可用的用例保持“待确认”状态，测试负责人不将其排入执行队列；确认可用后转为“可执行”。阻断级预警未在时限内解除时，由测试负责人和项目负责人共同判定延期、改用降级替代数据或缩小执行范围。降级替代数据要记录替代范围和限制，后续不能把降级结果当作完整验证结论。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持用例分配执行人和未通过用例快速创建缺陷任务，可把预警确认、缺陷流转和执行状态放在同一条流程里；阈值配置与自动告警的具体实现方式需按实际产品配置核验。
阈值机制试运行多久可以转为正式使用？
没有统一时长，判断依据是误报和漏报是否趋于稳定。建议至少覆盖一个完整的测试周期，期间记录每次预警的触发级别、真实影响和处置结果。当提示级预警多数能在影响执行前被发现、阻断级预警没有出现漏报、处置时限基本能守住时，可以转为正式使用并逐步收紧阈值。试运行期间保留人工复核，正式使用后仍按月复盘，按季度校准阻断阈值。
