测试数据清单是一张按测试用例逐条登记数据需求的表格，用来回答“这条用例要什么数据、数据在哪里、是否已脱敏、由谁准备、现在能不能用”。本文给出一张可直接复制到表格工具的空白清单，并逐字段说明填写口径、必填与选填的划分，再用一条完整记录演示正常数据与边界数据的写法，最后说明清单在迭代中的更新与归档规则。字段名称与示例为演示性质，组织可按自身业务与合规要求增删。
要点总览（TL;DR）
- 测试数据清单按“一条用例一行”登记，同一用例需要多份数据时拆行，用数据编号区分；共用数据在关联用例列写多个用例编号。
- 核心字段为数据编号、关联用例、数据类别、数据内容、构造方式、存放位置、脱敏要求、准备状态、责任人、备注；前六项与责任人构成最小可用清单。
- 数据内容写数据长什么样，构造方式写数据怎么产生；两者分开填写，环境重置后可按构造方式快速恢复。
- 必填字段暂不清楚时填“待确认”，选填字段不适用时填“无”，评审时先扫必填列空值，再核对状态与实际环境是否一致。
- 状态按待准备、准备中、已就绪、已失效流转，失效行归档保留编号，避免编号复用后指向错误数据。
可复制空白测试数据清单模板
清单按“一条用例一行”组织：同一用例需要多份数据时拆成多行，用数据编号区分；同一份数据被多条用例共用时，在关联用例列写多个用例编号，避免重复登记造成状态不一致。下表可直接复制到 Excel、在线表格或文档表格中，先保留表头，再按行填写。
| 数据编号 | 关联用例 | 数据类别 | 数据内容 | 构造方式 | 存放位置 | 脱敏要求 | 准备状态 | 责任人 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
复制后建议先冻结表头，并把“准备状态”设为下拉选项（如待准备、准备中、已就绪、已失效），减少手写造成的口径差异。若团队已有用例管理工具，清单编号可与用例编号保持同一命名规则，便于双向查找。
每个字段记录什么：字段说明
字段说明的作用是让不同人填出来的清单能互相对照。下表逐字段给出含义、填写口径和常见写法，模板、说明与后文示例使用同一套字段名称。
| 字段 | 记录什么 | 填写口径与常见写法 |
|---|---|---|
| 数据编号 | 这份数据在清单中的唯一标识 | 建议“模块缩写-序号”，如 PAY-001；新增行只追加不跳号，删除的行保留编号并标记失效，避免编号被复用后指向错误数据 |
| 关联用例 | 这份数据服务于哪条或哪几条测试用例 | 写用例编号，多条用逗号分隔；只写用例标题不写编号，后续用例改名就对不上 |
| 数据类别 | 数据在测试中的角色 | 常用取值：正常数据、边界数据、异常数据、历史存量数据；类别决定后续构造方式和校验重点 |
| 数据内容 | 数据本身是什么，即期望存在的具体值或记录 | 写关键字段值即可，如“账户余额 0.00 元、状态为冻结”；涉及多条记录时写清条数与区分条件 |
| 构造方式 | 这份数据怎么来的 | 常用取值：手工录入、脚本生成、从生产脱敏导出、调用接口创建、复用已有数据；写清方式便于他人复现 |
| 存放位置 | 数据实际所在的环境与位置 | 写到可定位的粒度，如“测试环境 A 库 user 表”“测试账号 test_pay_03”“共享目录/测试数据/支付”；只写“测试环境”无法定位 |
| 脱敏要求 | 数据使用前需要做什么处理 | 写“需脱敏”并注明处理项（如手机号、身份证号、银行卡号），或写“无需脱敏”；来自生产的数据必须在此列明确处理结论 |
| 准备状态 | 数据当前可用程度 | 统一使用待准备、准备中、已就绪、已失效四个值；状态变化时更新并保留更新日期 |
| 责任人 | 谁负责把这份数据准备到位并保持可用 | 写具体人名而非团队名；跨团队提供的数据，写对接人姓名 |
| 备注 | 补充约束 | 记录有效期、依赖的其他数据编号、使用注意事项等；无内容时留空 |
“数据内容”和“构造方式”容易混写：前者描述数据长什么样，后者描述数据怎么产生。例如“余额为 0 的账户”是内容，“通过脚本把测试账户余额置零”是构造方式。分开填写后，数据被环境重置时，按构造方式就能快速恢复。
必填与选填：哪些字段不能空
最小可用清单只需要保证“能定位、能判断可用性、能找到人”。据此把字段分为必填与选填两类，其余字段按场景补充。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 数据编号 | 必填 | 没有编号就无法在沟通、缺陷单和其他文档中引用这份数据 |
| 关联用例 | 必填 | 清单的价值在于对应用例；无归属的数据无法判断何时可以清理 |
| 数据类别 | 必填 | 决定校验重点，边界数据与正常数据的验收标准不同 |
| 数据内容 | 必填 | 不写内容，执行人无法判断拿到的数据是否正确 |
| 准备状态 | 必填 | 测试排期的直接输入，状态不明会导致误判可执行 |
| 责任人 | 必填 | 数据未就绪时需要有人跟进 |
| 构造方式 | 选填（建议填） | 数据可能被反复重建时填写；一次性手工数据可暂不填 |
| 存放位置 | 选填（建议填） | 数据由执行人自行创建时可后补；跨环境共享的数据必须填写 |
| 脱敏要求 | 选填（有条件必填） | 数据来源涉及生产或真实用户信息时必须填写处理结论；纯造数据可写“无需脱敏” |
| 备注 | 选填 | 用于有效期、依赖关系等补充信息 |
留空规则建议统一为：必填字段不允许空，暂不清楚时填“待确认”并同步给责任人；选填字段确实不适用时填“无”，与“忘了填”区分开。评审清单时先扫一遍必填列是否有空值或“待确认”，再检查状态是否与实际环境一致。
填写示例：一条完整记录
下面用支付模块的一条用例演示完整填写。同一用例分别需要正常数据和边界数据，拆成两行登记，其余字段保持同一口径。
| 数据编号 | 关联用例 | 数据类别 | 数据内容 | 构造方式 | 存放位置 | 脱敏要求 | 准备状态 | 责任人 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| PAY-001 | TC-PAY-012 | 正常数据 | 账户余额 500.00 元、状态正常的测试账户 | 调用测试环境开户接口创建 | 测试环境 A 库 account 表，账号 test_pay_03 | 无需脱敏（纯造数据） | 已就绪 | 李明 | 每次回归前核对余额 |
| PAY-002 | TC-PAY-012 | 边界数据 | 账户余额 0.00 元、状态正常的测试账户 | 脚本将测试账户余额置零 | 测试环境 A 库 account 表，账号 test_pay_04 | 无需脱敏（纯造数据） | 准备中 | 李明 | 依赖 PAY-001 的账户创建流程 |
两行的差异集中在“数据类别”“数据内容”和“构造方式”：正常数据验证主流程，边界数据验证余额为零时的处理逻辑，因此内容要写到具体数值，构造方式要写清如何把账户置到该状态。状态列上，已就绪表示执行人可直接使用；准备中表示数据尚未到位，排期时不能默认可执行。责任人写具体姓名，便于状态停滞时直接跟进。若数据来自生产脱敏导出，脱敏要求列应写明处理了哪些字段，而不是笼统写“已处理”。
调整与维护：让清单跟上测试进度
清单建好后，主要风险是状态与实际环境脱节、旧数据无人清理。维护规则围绕状态流转、更新时点和归档三件事展开。
- 状态流转：待准备 → 准备中 → 已就绪 → 已失效。只有责任人可以把自己负责的行推进到“已就绪”；环境重置、数据被覆盖或用例下线时，改为“已失效”并注明原因，不直接删除行。
- 更新时点：用例评审通过后补登新增数据需求；测试计划排期前核对一遍状态；每轮回归开始前由责任人确认“已就绪”行仍可用；环境重置后统一把受影响的行回退为“待准备”。
- 责任分工：清单整体由测试负责人维护字段口径和编号规则，每行数据的准备与状态更新由该行责任人负责，跨团队数据由对接人确认。
- 归档与复用：迭代结束后，把已失效行移入归档区或归档表，保留编号与关联用例，避免编号复用；可复用的基础数据（如固定测试账户）单独标记为公共数据，供后续用例引用。
- 评审检查：定期抽查必填列是否为空、状态是否与环境一致、脱敏结论是否齐全，把发现的问题记回备注列跟进。
当清单需要多人协作维护时，可以把清单作为团队文档承载，并借助 ONES Wiki 的页面模板库一键创建制式化文档模板，让各迭代的清单保持同一表头；文档实时同步并记录页面版本，支持随时查看与回滚，便于追溯某次状态变更。按角色配置读写权限，可以把脱敏结论等敏感列的编辑范围收窄到对应责任人。若希望数据需求与用例、迭代形成闭环，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；用例本身支持从 Excel 批量导入和导出备份，清单可沿用同一套编号规则与用例对照使用。具体可用能力以实际开通的版本与权限为准。
常见问题
同一份数据被多条用例共用，清单里要登记几行？
登记一行即可，在“关联用例”列写多个用例编号，用逗号分隔。这样这份数据只有一条状态和一个责任人，不会出现同一份数据在两行里状态不一致的情况。反过来，一条用例需要多份数据时按数据拆行，用数据编号区分，例如正常数据和边界数据各占一行。
测试数据来自生产环境时，脱敏要求一栏怎么写才算清楚？
写“需脱敏”并列出具体处理项，例如手机号、身份证号、银行卡号分别做了什么处理；处理完成后再把状态推进到“已就绪”。只写“已处理”无法让执行人判断哪些字段还能用、哪些字段已被替换，后续排查数据问题时也缺少依据。纯造数据可以写“无需脱敏”，与“忘了填”区分开。
环境重置后，清单里的状态要不要全部改回待准备？
只回退受影响的行，不必整表重置。环境重置前先按“存放位置”筛出落在该环境的记录，把这些行改为“待准备”并在备注里注明重置日期和原因；存放在其他环境或由执行人本地创建的数据不受影响。回退后由各行责任人重新确认，再逐行推进到“已就绪”。
清单和用例库分开维护，怎么避免两边对不上？
关键是编号规则统一：清单的数据编号与用例编号使用同一套命名规则，关联用例列只写编号不写标题，用例改名后仍能对上。用例评审通过后补登新增的数据需求，用例下线时把对应数据行改为“已失效”。如果团队使用 ONES 测试管理，用例支持从 Excel 批量导入和导出备份，清单可以沿用同一套编号与用例对照使用；具体可用能力以实际开通的版本与权限为准。
小团队只有一两个人做测试，还需要这么完整的清单吗？
可以先用最小版本：保留数据编号、关联用例、数据类别、数据内容、准备状态、责任人六列，其余字段按需补充。人少时清单的主要作用是防止回归前忘记核对数据状态，以及换人接手时能快速找到数据在哪里。等出现跨环境共享数据或生产脱敏数据时，再补上存放位置和脱敏要求两列。
