测试数据准备可以按“定场景—定数据画像—选生成方式—脱敏与校验—入库登记—按需发放与回收”六步推进。每一步都明确输入、动作、输出和完成标志，测试人员拿到的是可追溯、可复用的数据，临时手工改库的情况会明显减少。下面给出可直接照做的流程、角色分工、订单场景示例和交付前检查清单。
要点总览（TL;DR）
- 测试数据准备按“定场景—定数据画像—选生成方式—脱敏与校验—入库登记—按需发放与回收”六步推进，前四步串行，登记与发放准备可并行，回收在测试结束后统一执行。
- 数据场景从测试用例的前置条件反推，字段清单要写清字段名、类型、取值范围、约束和关联关系，场景清单在用例评审通过后冻结。
- 造数方式按数据量、真实性要求和合规限制选择：少量简单用手工，大批量用脚本，需要真实分布用脱敏复制，需走业务校验用接口生成，也可组合使用。
- 角色按“谁定义、谁生产、谁校验、谁使用”分工，测试负责人、数据管理员、开发或DBA、测试执行人各有明确交付物和交接时点。
- 交付前逐项核对完整性、准确性、合规性、可重复使用、环境隔离和登记闭环，任一项不通过即暂停发放。
测试数据准备的核心步骤与操作顺序
六步流程的依赖关系是：场景决定数据画像，数据画像决定造数方式，造数完成后必须经过脱敏与校验才能入库，入库登记之后才允许发放。前四步串行，入库登记可与发放准备并行，回收在测试结束后统一执行。跳过任何一步，后续环节都会返工。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定场景 | 本轮测试用例、需求说明 | 测试负责人圈定用例涉及的数据场景，标注正常、边界、异常三类 | 数据场景清单 | 场景清单经评审并冻结 |
| 2. 定数据画像 | 数据场景清单 | 数据管理员按场景拆出字段名、类型、取值范围、约束和关联关系 | 字段清单 | 字段清单与用例逐条对应，无遗漏字段 |
| 3. 选生成方式 | 字段清单、数据量、合规要求 | 确定手工、脚本、脱敏复制或接口生成，或组合方案 | 造数方案说明 | 方案写明方式、责任人、预计产出时间 |
| 4. 脱敏与校验 | 原始数据或生成数据、脱敏规则 | 开发或DBA执行脱敏，测试人员按字段清单抽样校验 | 脱敏后的数据集、校验记录 | 敏感字段全部处理，抽样校验通过 |
| 5. 入库登记 | 校验通过的数据集 | 数据管理员将数据放入指定测试库或数据池，登记来源、版本、有效期 | 数据登记记录 | 登记信息完整，可凭记录定位到具体数据集 |
| 6. 发放与回收 | 测试人员的领取申请 | 按需分配数据，测试结束后统一回收或清理 | 领用记录、回收记录 | 领用与回收记录一一对应，无遗留数据 |
小团队可以把第1、2步合并为一次半小时的用例走查，由测试负责人直接产出场景与字段合一的清单。多项目并行时，各项目独立走第1至4步，第5步入库登记集中到共享数据池，由数据管理员统一编号，避免同一份数据被两个项目同时修改。回收环节按项目分别登记，防止互相覆盖。
数据场景与字段清单怎么定
数据场景从测试用例反推：逐条阅读用例的前置条件和操作步骤，把“需要已存在的某类记录”提取出来，归并重复项，形成场景清单。例如一条“验证订单超时自动关闭”的用例，反推出的场景是“存在一笔超过支付时限且未支付的订单”。场景描述用业务语言，不写字段。
字段清单把每个场景翻译成可核对的数据画像，建议包含以下要素：
- 字段名与所属表或对象，标明主键与外键；
- 数据类型与长度，例如金额保留两位小数；
- 取值范围与枚举值，例如订单状态限定为待支付、已支付、已关闭；
- 约束条件，例如必填、唯一、格式校验；
- 关联关系，例如订单关联用户、商品、支付流水，并注明关联数量。
覆盖方式上，正常值保证主流程可跑通；边界值按字段约束取上下限，如金额取0.01和单笔上限；异常值覆盖空值、超长、非法格式和状态冲突；批量数据按性能或分页测试的需要确定量级，例如列表页测试准备略多于单页条数的记录。场景清单在用例评审通过后冻结，冻结后新增场景走变更记录，避免测试中途反复改口径。
造数方式怎么选：手工、脚本、脱敏复制与接口生成
选择造数方式主要看三个条件：数据量、对真实性的要求、合规限制。数据量小且结构简单时手工构造最快；需要成百上千条且结构固定时脚本批量生成更可控；需要贴近真实分布时用生产数据脱敏复制；系统提供稳定写入接口时，接口生成能保证数据经过业务校验。
| 方式 | 适用条件 | 数据量 | 真实性 | 可重复性 | 合规风险 |
|---|---|---|---|---|---|
| 手工构造 | 少量、结构简单、临时验证 | 小 | 中 | 低，依赖个人操作 | 低 |
| 脚本批量生成 | 大批量、字段规则明确 | 大 | 中，需自行设计分布 | 高，脚本可版本化 | 低 |
| 生产数据脱敏复制 | 需要真实分布、关联复杂 | 大 | 高 | 中，依赖脱敏流程 | 中高，须先脱敏 |
| 接口调用生成 | 系统有稳定写入接口、需通过业务校验 | 中到大 | 高 | 高，可脚本化调用 | 低 |
组合使用的常见优先级是：先用脱敏复制获取一批基础数据，再用脚本在其上补充边界和异常记录，接口生成用于需要走完整业务链路的场景。脱敏规则的基本要求是：姓名、手机号、身份证号、地址、银行卡号等直接标识信息做替换或掩码；金额、日期等业务字段在保持分布特征的前提下做扰动；关联字段的脱敏结果保持一致，避免订单与用户对不上。校验方式是抽取样本比对脱敏前后记录数、关联完整性和字段格式，确认无原始敏感值残留。
角色分工与交付物
数据准备涉及四类角色，职责边界按“谁定义、谁生产、谁校验、谁使用”划分，交接物必须可查。
| 角色 | 职责边界 | 交付物 | 交接时点 |
|---|---|---|---|
| 测试负责人 | 定义数据场景，确认覆盖范围，冻结清单 | 数据场景清单 | 用例评审通过后 |
| 数据管理员 | 编制字段清单，组织造数，执行入库登记与发放回收 | 字段清单、登记记录、领用与回收记录 | 造数前、入库时、测试结束后 |
| 开发或DBA | 提供造数脚本、执行脱敏、处理数据冲突 | 造数脚本、脱敏规则与执行记录 | 造数方案确定后、校验前 |
| 测试执行人 | 领取数据、按用例使用、反馈数据问题、配合回收 | 校验反馈、领用确认 | 领取时、测试结束时 |
数据申请与审批的流转方式是：测试执行人提交申请，写明场景编号、所需数据量和用途；数据管理员核对字段清单后审批；涉及生产数据复制的申请增加合规或安全负责人审批。跨团队协作时，数据归属方指定一名数据管理员作为唯一对接人，其他团队的需求统一经此人流转，责任归属落在数据归属方，使用方对使用范围和回收负责。
示例：一个订单场景的数据准备全过程
以下为演示情景，用于说明流程落地形态。某电商系统本轮要测试订单支付、超时关闭和退款三个功能。
场景与字段。测试负责人从用例反推出三个场景：待支付订单、已超时未支付订单、已支付待退款订单。数据管理员编制字段清单，包含订单号、用户ID、商品ID、订单金额、订单状态、创建时间、支付时间、支付流水号，并注明订单关联一个用户和一到三个商品。
造数方式。基础订单采用生产数据脱敏复制，保留真实的状态分布；超时订单用脚本把创建时间回拨到支付时限之前；退款订单通过接口调用生成，确保支付流水真实存在。脱敏规则对用户姓名和手机号做掩码，订单号做不可逆替换，金额保持原分布。
校验。测试人员抽取20条记录，核对订单与用户、商品的关联完整，状态与时间字段逻辑一致，确认无原始手机号残留，校验记录附在数据集说明中。
登记与发放。数据管理员将数据集编号为“订单-2024-06-A”，登记来源、脱敏规则版本、有效期两周，放入测试库。测试执行人凭申请领取，领用记录写明领取人、场景编号、数据量。测试结束后回收，记录清理时间和清理方式，与领用记录对应关闭。
完成检查：数据准备是否可交付
数据准备交付前逐项核对，任一项不通过即视为阻断，修复后重新检查。
- 完整性：场景清单中的每个场景都有对应数据集，字段清单中的必填字段无缺失。
- 准确性：抽样数据与字段清单的取值范围、约束、关联关系一致，边界值和异常值已覆盖。
- 合规性：敏感字段全部按规则处理，抽样确认无原始敏感值，脱敏规则版本有记录。
- 可重复使用：数据集有编号和版本，重新生成时能凭脚本或规则复现。
- 环境隔离：数据只进入指定测试环境，未混入其他项目正在使用的数据集。
- 登记闭环：入库登记信息完整，领用记录与回收记录一一对应，无未回收数据。
放行条件是上述六项全部通过，且测试负责人确认场景覆盖无遗漏。出现字段缺失、敏感值残留或数据未登记时，暂停发放，由对应责任人补齐后再走检查。
把数据准备纳入研发协作流程
数据申请、审批、登记和回收如果只靠聊天记录流转，追溯成本很高。可以把数据申请做成工作项：字段包含场景编号、数据量、用途、期望交付时间、合规审批人；状态按“待审批—造数中—待校验—已入库—已发放—已回收”流转，每次状态变更留下操作人和时间。
场景清单和字段清单用文档承载，与对应测试用例关联，评审意见直接留在文档中，冻结后新增场景走变更记录。交接与评审记录随工作项和文档留存，回收环节由数据管理员在测试结束后核对领用记录，逐条关闭。
ONES 的测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，可以把数据申请工作项挂到对应迭代和测试计划下，让数据准备进度与测试执行进度在同一视图里可见；用例属性可自定义，便于标注每条用例所需的数据场景编号。权限方面，ONES 支持为不同用户组配置不同权限，也可为用例库、测试计划单独配置权限，适合把数据相关记录限定在测试与数据管理角色范围内。测试结束后，效能管理可对系统中的数据进行多维度分析，并把仪表盘共享给相关角色，用于查看数据准备与回收的完成情况。数据本身的生成、脱敏和发放仍由团队既有的脚本、脱敏流程和数据池承担，协作工具负责把申请、审批、登记和回收串成可追溯的流程。
常见问题
测试数据准备一定要走完六步吗，小团队能不能简化？
六步是完整流程，小团队可以合并执行，但合并的是动作形式，不是省略环节。常见做法是把“定场景”和“定数据画像”合并为一次用例走查，由测试负责人当场产出场景与字段合一的清单；脱敏与校验、入库登记仍要保留，因为这两步决定了数据能不能被追溯和复用。如果本轮只验证一两个简单功能、数据量很小，手工构造后同样要登记来源和有效期，否则后续无法判断数据是否过期。
没有生产数据可用时，怎么保证造出来的数据足够真实？
可以从三个方向补足真实性：一是按业务规则设计字段分布，例如订单状态按真实比例分配，而不是全部设为同一种状态；二是通过接口调用生成数据，让数据经过系统自身的业务校验，避免出现数据库里存在但业务上不可能出现的组合；三是请业务方提供一批脱敏后的样本作为参照，脚本按样本的分布特征生成。需要说明的是，生成数据的真实性以覆盖测试场景为准，不必追求与生产数据完全一致。
数据脱敏做到什么程度算合格，校验时看什么？
合格的标准是敏感字段无法还原到具体个人，同时关联关系保持完整。校验时抽取样本比对脱敏前后的记录数是否一致、订单与用户和商品的关联是否对得上、字段格式是否符合规则，并确认样本中不存在原始手机号、身份证号等敏感值。脱敏规则要有版本记录，规则调整后重新校验。涉及生产数据复制的申请，建议增加合规或安全负责人审批，审批记录与数据集说明一并留存。
多个项目同时测试时，数据怎么避免互相覆盖？
各项目独立完成场景、字段和造数，入库登记集中到共享数据池，由数据管理员统一编号，同一份数据不分配给两个项目同时修改。需要共用基础数据时，可以复制出项目专属副本，副本单独编号并注明来源。回收按项目分别登记，清理前核对领用记录，确认该项目的数据已全部归还或删除，再释放编号。这样即使两个项目测试时间重叠，也能凭编号定位到具体数据集和责任人。
数据申请和回收在协作工具里怎么落地，需要配置哪些内容？
把数据申请做成工作项，字段包含场景编号、数据量、用途、期望交付时间和合规审批人，状态按“待审批—造数中—待校验—已入库—已发放—已回收”流转，每次变更留下操作人和时间。场景清单和字段清单用文档承载，与测试用例关联，评审意见留在文档中。ONES 的测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，可以把数据申请工作项挂到对应迭代和测试计划下；用例属性可自定义，便于标注每条用例所需的数据场景编号；权限可按用户组配置，也可为用例库、测试计划单独配置。数据本身的生成、脱敏和发放仍由团队既有的脚本和脱敏流程承担。
