测试执行中遇到数据不可用，先要分清是数据缺失、数据错误、数据被占用，还是写入失败，再确认影响了哪些用例和业务流程。排查时按“数据本身—数据供给链路—环境与配置—权限与依赖”四层逐项验证，用证据排除假设；恢复阶段优先选择低风险动作，涉及覆盖或重置数据时先备份并约定停止点。本文给出一条从症状登记到恢复验证的处置路径，并在数据准备与问题追踪的管理环节说明如何借助 ONES 留下可查记录。
要点总览（TL;DR）
- 先把“数据不可用”拆成数据缺失、数据错误、数据被占用或状态不符、数据无法写入四类症状，登记影响用例、发生时间和近期变更，确定排查优先级。
- 按数据本身、供给链路、环境与配置、权限与依赖四层逐项验证，每层写出假设并保留验证证据，未验证的假设不提前关闭。
- 处置按风险从低到高：先重跑造数或同步任务、补齐缺失数据；需要重置或覆盖时先备份、通知共享环境人员并设停止点；短时间无法恢复则切换备用数据集或隔离受影响用例。
- 恢复后用原先失败的用例连续回归两轮，确认结果稳定；再把造数任务监控、数据前置检查和根因记录纳入预防措施。
先界定症状：哪类测试数据不可用、影响多大
“数据不可用”是一个笼统描述，直接进入排查容易在多条线索之间反复。第一步应把现象拆成可判断的具体症状，并登记影响范围。症状登记至少包含四项：现象描述、影响范围、发生时间、近期变更。这份登记既是排查起点，也是后续判断恢复是否完成的依据。
现象描述要写到可复现的程度。同样是“查不到数据”，可能是基础数据被清理后确实不存在，可能是查询条件或配置指向了另一套库，也可能是数据存在但状态不符合用例预期。常见表现可以归为四类：
- 数据缺失：用例依赖的账号、订单、商品或配置项查不到，接口返回空结果或记录不存在。
- 数据错误：数据存在但字段值、金额、状态与预期不符，断言失败。
- 数据被占用或状态不符：数据被其他用例或人员修改、锁定，处于不可再用的状态。
- 数据无法写入：新增、更新操作报错或被拒绝，写入链路中断。
影响范围要落到具体对象：哪些用例失败、涉及哪些接口或业务流程、是否阻塞发版或关键回归。优先级由此确定——阻塞发版和核心链路回归的问题先处理，边缘用例可以隔离后继续执行。发生时间用于对齐变更窗口，例如首次出现时间是否紧邻一次数据清理、脚本发布或环境切换。把这些信息记录完整，后面的分层排查才有明确对象。
按四层假设排查：从数据本身到环境依赖
排查的核心是把猜测变成可验证的假设。建议按数据层、供给层、环境层、权限与依赖层的顺序推进，因为越靠前的层越容易验证，也越常见。每一层都先写出假设，再说明用什么证据支持或排除，避免凭印象下结论。
数据层：数据是否被清理、过期、覆盖或未按规则生成
先确认数据当前的真实状态。直接查询目标记录是否存在、字段值是否符合预期、状态是否满足用例前置条件。如果数据不存在，追查是否被定时清理任务删除、是否超过有效期、是否被其他用例覆盖。如果数据存在但值不对，对照造数规则检查生成逻辑是否按预期执行。验证证据是查询结果与预期值的逐项比对，而不是“看起来没问题”。
供给层：造数脚本、同步任务、脱敏或导入流程是否失败或延迟
数据缺失或错误经常源于供给链路。检查造数脚本最近一次执行记录与退出状态，检查数据同步任务、脱敏流程、批量导入是否有失败、跳过或延迟。重点看任务日志中的报错行和完成时间，与症状首次出现时间对齐。如果任务显示成功但数据未到位，继续核对任务实际写入的目标库和表是否与用例读取的一致。验证证据是任务执行记录、日志报错和写入结果三者的对照。
环境层：数据库连接、配置项、版本差异是否导致读取到错误数据
当数据在源头存在、用例却读不到时，问题可能出在环境。核对用例运行环境连接的数据库地址、库名、schema 与配置项是否指向预期环境；检查近期是否有配置变更、版本发布或环境切换。多套环境并存时，常见情况是测试环境读取了另一套库的数据。验证方式是打印或查看实际连接配置，并在目标库中直接执行同一查询，比较结果差异。
权限与依赖层：账号权限、外部依赖服务或上下游系统是否变化
写入失败或读取被拒时，优先检查权限。确认执行账号的角色、数据访问范围和近期权限调整，检查是否因权限收紧导致部分表或接口不可访问。同时核对上下游依赖服务是否可用、接口契约是否变更、第三方 mock 或桩服务是否失效。验证证据包括权限配置截图或记录、依赖服务的健康状态与调用日志。
| 排查层 | 典型假设 | 验证证据 | 排除结论示例 |
|---|---|---|---|
| 数据层 | 数据被清理、过期、覆盖或未按规则生成 | 目标记录查询结果与预期值比对 | 记录存在且字段正确，排除数据本身问题 |
| 供给层 | 造数、同步、脱敏或导入任务失败或延迟 | 任务执行记录、日志报错、写入结果 | 任务按时成功且写入目标正确，转向环境层 |
| 环境层 | 连接配置、库名或版本差异导致读错数据 | 实际连接配置、目标库直接查询结果 | 配置指向正确且查询一致，转向权限层 |
| 权限与依赖层 | 账号权限收紧、依赖服务或接口契约变化 | 权限记录、依赖服务状态与调用日志 | 权限与依赖均正常，回到供给层复核时序 |
排查顺序可以按证据获取成本调整：如果症状明显指向写入失败，先查权限比先查数据更高效。关键要求不变——每个结论都要有对应证据，未验证的假设继续保留在清单中，不提前关闭。
处置步骤：按影响面选择补数、重置或切换
确认原因后，处置动作按风险从低到高排列，先做可逆、影响面小的操作。原因不同，首选动作也不同：供给任务失败优先重跑，数据被误删优先补齐，数据被污染且无法逐条修复时考虑重置，短时间无法恢复时切换备用数据集或隔离用例。
第一步：低风险动作，重跑任务与补齐数据
如果根因是造数脚本、同步任务或导入流程失败，修复失败点后重跑任务，并核对写入结果。如果只是少量记录缺失，按造数规则补齐缺失数据，补齐后立即用原失败用例验证。这类动作影响面可控，通常不需要停机或通知全员。重跑前确认任务幂等性，避免重复写入造成新的数据错误。
第二步：需要重置或覆盖数据时，先备份、再通知、设停止点
重置或覆盖属于破坏性操作，执行前必须满足三个条件：对受影响数据进行备份或导出；通知共享该环境的测试人员和相关开发，说明操作窗口与影响范围；设定停止点，例如重置后核心用例仍失败则停止继续覆盖，转为切换方案。操作过程保留变更记录，包括操作人、时间、影响的数据范围和回滚方式。
第三步：无法快速恢复时，切换备用数据集或隔离受影响用例
当修复时间不可控，优先保障测试进度。可以切换到备用数据集或另一套可用环境，让不受影响的用例继续执行；对强依赖问题数据的用例做隔离标记，待数据恢复后补跑。隔离不是放弃验证，而是把阻塞范围控制在已知清单内，避免整个测试计划停摆。
共享环境中的协调与记录
共享测试环境的数据变更会影响多人，处置时明确一名协调人负责操作排期和通知，所有变更记入同一份记录。数据准备和问题处置如果分散在聊天工具里，事后很难追溯。在 ONES 中，测试用例可以与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，使“哪个用例因数据问题失败、由谁处置、何时恢复”形成可追踪的工作项记录；用例库和测试计划也支持单独配置权限，便于区分数据操作与用例维护的职责边界。
验证恢复与防止复发
数据恢复后不能只看“能查到数据”，要用原先失败的用例回归验证，确认数据可用且结果稳定。建议连续执行两轮：第一轮确认失败用例转为通过，第二轮确认结果可重复，排除偶发因素。如果用例仍失败，回到排查清单核对是否还有未关闭的假设，而不是直接判定恢复完成。
恢复验证通过后，把本次问题转化为预防措施，重点覆盖三个环节：
- 监控与告警：为造数脚本、数据同步任务和导入流程增加执行状态监控与失败告警，任务失败或延迟时第一时间通知责任人，而不是等用例失败才发现。
- 前置检查：把数据准备纳入测试前置检查项，明确检查内容（关键基础数据是否存在、任务是否成功、环境配置是否指向正确库）、责任人和检查时点，例如每轮回归开始前由环境负责人确认。
- 根因记录：记录本次根因、验证证据、处置过程和回滚方式，形成可复用的排查条目。同类问题再次出现时，可以直接对照历史记录缩短定位时间。
根因记录和排查经验适合沉淀为团队共享文档。ONES 企业知识库支持多人实时协同编辑、页面共享和页面模板，以页面树组织内容，成员看到的是最新版本，适合把数据准备检查清单、常见故障处置步骤和维护责任人集中维护，减少同类问题重复排查的成本。
常见问题
测试数据不可用时，怎么快速判断是数据本身的问题还是环境配置的问题？
先查数据层：直接在用例读取的目标库中查询目标记录是否存在、字段值是否符合预期。如果记录存在且字段正确，再核对用例实际连接的数据库地址、库名和 schema 是否指向这套库。两边查询结果不一致，通常说明环境配置或连接指向有问题；两边一致但用例仍失败，继续往权限与依赖层排查。
共享测试环境里重置数据，需要提前做哪些协调？
重置前至少完成三件事：对受影响数据做备份或导出；通知共享该环境的测试人员和相关开发，说明操作窗口与影响范围；设定停止点，例如重置后核心用例仍失败就停止继续覆盖，转为切换方案。操作过程保留变更记录，包括操作人、时间、影响范围和回滚方式，避免多人同时操作造成新的数据冲突。
造数任务显示成功，但用例仍然读不到数据，应该查什么？
重点核对任务实际写入的目标库和表是否与用例读取的一致。任务成功只代表执行过程没有报错，不代表写到了正确位置。可以对照任务配置中的目标连接信息、任务日志中的写入记录，以及用例实际查询的库表，三者对齐后再判断数据是否真正到位。如果写入目标正确但数据仍缺失，检查任务是否因幂等或去重逻辑跳过了部分记录。
数据恢复后，怎么确认可以继续执行测试而不是暂时看起来正常？
用原先失败的用例连续执行两轮：第一轮确认失败用例转为通过，第二轮确认结果可重复。两轮都通过，再检查同一批数据是否被其他用例或任务再次修改。如果只有第一轮通过、第二轮失败，说明数据状态不稳定或存在并发覆盖，需要回到供给层或环境层继续排查，不能直接判定恢复完成。
怎么把这次数据不可用的处置过程沉淀下来，减少下次排查时间？
记录根因、验证证据、处置步骤和回滚方式，形成可复用的排查条目。同时把数据准备检查项写入测试前置清单，明确检查内容、责任人和检查时点。团队可以将这些内容集中维护在共享文档中，ONES 企业知识库支持多人实时协同编辑和页面模板，以页面树组织内容，成员看到的是最新版本，便于后续对照使用。
