测试数据清单用来登记测试过程中需要准备、使用和清理的数据项，让测试人员知道数据在哪里、由谁负责、何时失效。一张可用的清单通常按“一行一个数据项”组织，覆盖数据项名称与用途、来源与生成方式、字段结构与关键值、脱敏与合规要求、存放位置与访问方式、责任人与有效期、状态与清理方式等信息。下面提供可直接复制的空白表格、逐字段填写口径、必填与选填规则、一条完整示例，以及清单随项目更新的维护方法。
要点总览（TL;DR）
- 测试数据清单按“一行一个数据项”登记，核心覆盖八类信息：名称与用途、所属模块与场景、来源与生成方式、字段结构与关键值、脱敏与合规、存放与访问、责任人与有效期、状态与清理方式。
- 最低可用字段建议先收敛到六项：数据项名称、用途与测试场景、数据来源、存放位置、责任人、状态；其余字段按冒烟、回归、性能等阶段逐步补齐。
- 填写时脱敏要求写到字段级，访问权限写角色范围而非账号密码，有效期与清理时间分开记录，变更记录保留调整原因。
- 维护按迭代节奏核对状态，新增字段由具体触发条件驱动，更新责任按数据项归属划分，并与用例、缺陷建立引用关系。
可直接复制的测试数据清单空白表
下面的表格可以直接复制到 Excel、在线表格或文档中。每一行登记一个数据项，例如一个测试账号、一组订单记录、一份批量导入文件。表头按信息类别排列，填写时从左到右推进，先确认数据项是什么、做什么用，再补充来源、结构、权限和清理安排。
| 序号 | 数据项名称 | 数据项标识 | 用途与测试场景 | 所属业务模块 | 数据来源 | 生成方式 | 字段结构与关键值 | 数据量 | 敏感级别 | 脱敏要求 | 合规依据 | 存放位置 | 访问方式 | 访问权限 | 责任人 | 关联用例 | 生效日期 | 有效期至 | 状态 | 清理方式 | 清理时间 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||||||||||||||
| 2 | ||||||||||||||||||||||
| 3 |
如果团队习惯用文档而不是表格，可以把上表转成“数据项卡片”：每个数据项一个小节，小节标题写数据项名称，正文按字段逐条列出。卡片形态适合数据项少、说明文字多的场景，例如需要详细描述脱敏规则或生成脚本；表格形态适合数据项多、需要横向对比和筛选的场景。两种形态的字段保持一致，便于互相转换。
表格中的“状态”建议使用固定取值，例如“待准备、可用、冻结、已失效、已清理”，避免每个人写不同的描述。“变更记录”可以简写为“日期＋修改人＋修改内容”，数据项较多时也可以单独维护一张变更日志表。
每个字段记录什么：清单字段说明
字段说明的作用是统一填写口径，让不同测试人员填出来的清单可以互相对照。下表按信息类别解释每个字段的含义、填写方式和示例值，示例值仅用于说明写法。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 数据项名称 | 这项数据的业务称呼 | 用业务语言命名，避免只写“测试数据1” | 华东区普通会员订单 |
| 数据项标识 | 清单内的唯一编号或系统主键 | 编号规则由团队约定，保持唯一 | TD-ORDER-001 |
| 用途与测试场景 | 这项数据支撑什么测试 | 写清验证目标和触发场景 | 验证满减优惠在跨店订单中的计算 |
| 所属业务模块 | 数据归属的功能域 | 与需求或用例的模块划分保持一致 | 订单结算 |
| 数据来源 | 数据从哪来 | 注明生产脱敏导出、测试库造数、手工构造、第三方模拟等 | 测试库造数 |
| 生成方式 | 具体如何产生 | 写脚本名、SQL 文件、导入文件或操作步骤的位置 | 脚本 order_seed_v3.sql |
| 字段结构与关键值 | 数据包含哪些字段、哪些值决定测试结果 | 列出关键字段及取值，不必罗列全部字段 | 订单金额 299、优惠券面额 50、会员等级 普通 |
| 数据量 | 记录条数或文件大小 | 写数量和单位 | 200 条订单、1 个 CSV 文件 |
| 敏感级别 | 数据涉及的个人信息或业务敏感程度 | 按团队分级标准填写，如公开、内部、敏感 | 敏感 |
| 脱敏要求 | 哪些字段需要脱敏、脱敏到什么程度 | 写字段名和脱敏规则 | 手机号中间四位掩码，收货地址保留到区 |
| 合规依据 | 脱敏和使用所依据的制度或约定 | 写制度名称或审批记录编号 | 测试数据使用规范第 3 条 |
| 存放位置 | 数据实际存放的地方 | 写库名、表名、文件路径或环境地址 | 测试库 order 库 t_order 表 |
| 访问方式 | 如何取用这项数据 | 写查询语句、接口、导入入口或账号申请方式 | 通过测试环境订单查询页按订单号检索 |
| 访问权限 | 哪些角色可以读写 | 写角色或人员范围，不写具体密码 | 订单测试组可读，数据管理员可写 |
| 责任人 | 谁对这项数据的准备和准确性负责 | 写姓名或角色，确保可联系 | 订单测试负责人 |
| 关联用例 | 使用这项数据的用例编号 | 写用例编号，多个用逗号分隔 | TC-ORDER-012、TC-ORDER-015 |
| 生效日期 | 数据可开始使用的时间 | 写日期，配合版本或迭代 | 2025-03-10 |
| 有效期至 | 数据失效的时间 | 写日期或“随迭代结束” | 2025-04-10 |
| 状态 | 数据当前可用情况 | 使用固定取值 | 可用 |
| 清理方式 | 数据如何删除或回收 | 写删除脚本、归档位置或回收流程 | 执行 cleanup_order.sql 并确认条数归零 |
| 清理时间 | 计划或实际清理的时间 | 写日期，清理后补记实际时间 | 2025-04-11 |
| 变更记录 | 这项数据被修改的历史 | 写日期、修改人和修改内容 | 2025-03-15 张三 调整优惠券面额 |
填写“字段结构与关键值”时，重点放在会影响断言结果的字段上。订单金额、状态、时间、会员等级这类字段决定测试是否通过，应当写清楚；创建时间、更新时间等系统自动生成的字段可以省略。脱敏字段与合规依据要相邻填写，便于评审时一起检查。
必填与选填：哪些字段不能空
清单刚建立时不必追求所有字段填满。建议先保证六项最低可用信息：数据项名称、用途与测试场景、数据来源、存放位置、责任人、状态。这六项决定了别人能否找到数据、判断数据是否可用、知道找谁确认。缺少其中任何一项，清单就会退化成一份无法执行的名单。
| 字段 | 建议 | 理由或适用场景 |
|---|---|---|
| 数据项名称 | 必填 | 没有名称无法引用和沟通 |
| 用途与测试场景 | 必填 | 决定数据是否值得准备，避免囤积无用数据 |
| 数据来源 | 必填 | 影响数据可信度和复现方式 |
| 存放位置 | 必填 | 没有位置就无法取用 |
| 责任人 | 必填 | 数据过期或出错时需要有人处理 |
| 状态 | 必填 | 防止使用已失效数据 |
| 字段结构与关键值 | 回归、性能阶段必填 | 冒烟阶段可先写关键值，回归时补齐断言相关字段 |
| 脱敏要求、合规依据 | 涉及个人信息时必填 | 使用生产脱敏数据或含用户信息的数据时必须填写 |
| 访问权限 | 多人共用时必填 | 单人独占的临时数据可先写责任人 |
| 有效期至、清理方式 | 回归、性能阶段必填 | 冒烟数据可随环境重建，长期数据必须约定失效和清理 |
| 数据项标识、所属模块、数据量 | 选填 | 数据项多、需要筛选和统计时补充 |
| 关联用例、变更记录 | 选填 | 需要追溯数据与用例关系时补充 |
不同测试阶段的取舍可以这样处理：冒烟测试以快速验证主流程为目标，清单保留名称、用途、来源、位置、责任人、状态六项即可，数据量写“少量”也能接受；回归测试需要覆盖边界和组合条件，应补齐字段结构与关键值、关联用例、有效期至；性能测试涉及大批量数据和长时间占用，数据量、生成方式、清理方式、清理时间必须写清楚，否则容易留下占用存储的残留数据。
字段缺失的风险很具体：没有责任人，数据过期后无人处理；没有有效期，旧数据被误当成当前版本使用；没有脱敏要求，生产数据可能被直接复制到测试环境；没有清理方式，测试库会逐渐积累无法判断用途的数据。清单评审时可以按这几项逐一检查。
填写示例：一条订单测试数据的完整登记
下面用一条订单测试数据演示完整填写。场景设定为：订单结算模块需要验证“普通会员使用满减券跨店下单”的计算结果，测试在独立测试环境进行，数据由测试库脚本生成。这是一个演示情景，字段值用于说明写法。
| 字段 | 填写内容 |
|---|---|
| 序号 | 1 |
| 数据项名称 | 华东区普通会员跨店满减订单 |
| 数据项标识 | TD-ORDER-001 |
| 用途与测试场景 | 验证普通会员在两家店铺合并结算时，满 299 减 50 优惠券只抵扣一次且分摊到各店铺 |
| 所属业务模块 | 订单结算 |
| 数据来源 | 测试库造数 |
| 生成方式 | 执行脚本 order_seed_v3.sql，脚本存放于测试库脚本目录 |
| 字段结构与关键值 | 订单金额 320、商品分属 2 家店铺、优惠券面额 50、会员等级 普通、订单状态 待支付 |
| 数据量 | 1 条主订单、2 条子订单 |
| 敏感级别 | 内部 |
| 脱敏要求 | 收货人手机号中间四位掩码，收货地址保留到区，收件人姓名使用虚构姓名 |
| 合规依据 | 测试数据使用规范第 3 条，造数脚本经测试负责人确认 |
| 存放位置 | 测试环境 order 库 t_order、t_order_item 表 |
| 访问方式 | 通过测试环境订单查询页按订单号检索，或使用只读账号查询 |
| 访问权限 | 订单测试组可读，数据管理员可写，其他角色不可见 |
| 责任人 | 订单测试负责人 |
| 关联用例 | TC-ORDER-012、TC-ORDER-015 |
| 生效日期 | 2025-03-10 |
| 有效期至 | 2025-04-10 |
| 状态 | 可用 |
| 清理方式 | 执行 cleanup_order.sql 删除该订单及子订单，核对查询结果为空 |
| 清理时间 | 计划 2025-04-11，实际清理后补记 |
| 变更记录 | 2025-03-15 张三 将订单金额从 280 调整为 320，覆盖满减门槛 |
这条示例中有几个写法值得注意。脱敏要求写到字段级，评审时能直接判断是否满足规范；访问权限写角色范围，不写账号密码；有效期与清理时间分开写，有效期表示数据可以用于测试的截止时间，清理时间表示实际删除的安排；变更记录保留调整原因，方便后续判断数据是否仍匹配用例。
如果同一场景需要多组金额组合，建议拆成多行登记，例如“订单金额 299 的临界订单”“订单金额 298 的不满足门槛订单”，而不是在一行里堆叠多个值。一行一个数据项，后续关联用例和清理时更容易对应。
清单的调整与维护方法
测试数据清单容易在项目初期建立、在迭代中被遗忘。维护的目标是让清单始终能回答三个问题：这项数据现在还能不能用、谁在负责、什么时候该清理。可以从新增字段、定期核对、关联维护和协作分工四个方面建立规则。
新增字段的触发条件应当具体。出现新的敏感数据类型时，补充敏感级别和脱敏要求；测试环境开始按迭代重建时，补充生效日期和有效期至；数据被多个小组共用时，补充访问权限和访问方式；出现数据被误删或误用的事故时，补充变更记录和清理确认人。字段增加后，同步更新字段说明表，避免模板和说明脱节。
定期核对建议按迭代节奏执行。每个迭代结束前，责任人逐行确认状态：仍在使用中的数据改为“可用”并延长有效期；已不再使用的改为“已失效”，进入清理队列；已删除的改为“已清理”并补记清理时间。核对结果可以只记录变化行，减少重复劳动。
与用例、缺陷的关联维护决定清单的追溯价值。数据项关联用例编号后，用例变更时能快速找到受影响的数据；缺陷涉及特定数据时，在缺陷记录中引用数据项标识，修复验证时可以直接复用同一组数据。关联关系不必追求全覆盖，优先覆盖回归用例和反复出现的缺陷场景。
多人协作时，建议明确三类角色：数据责任人负责本模块数据项的准确性和有效期；清单维护人负责表头、取值规范和整体核对节奏；评审人负责检查脱敏与权限字段。更新责任按数据项归属划分，谁准备数据谁更新对应行，避免所有人都能改、最后没人负责。
当清单需要与用例、执行记录一起管理时，可以把清单作为项目文档维护，并与测试工作项建立关联。ONES Wiki 支持文档关联项目任务，页面树可以按模块组织清单和填写规范；版本记录支持查看和回滚页面历史，便于追踪字段调整。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，用例也可以从 Excel 批量导入，适合把清单中的关联用例编号与用例库对应起来。具体模板形态和权限配置以实际产品为准。
常见问题
测试数据清单和测试用例库需要分开维护吗？
建议分开维护，但保留引用关系。清单关注数据本身的来源、位置、权限和有效期，用例库关注验证步骤和预期结果，两者字段口径不同。在清单中记录关联用例编号，在用例中引用数据项标识，就能在用例变更时快速定位受影响的数据。如果团队规模小、数据项少，也可以把清单作为用例库的附属文档，但数据项标识仍需保持唯一。
生产脱敏数据导入测试环境时，清单里要额外记录什么？
除常规字段外，建议补充脱敏执行记录和审批依据。具体包括：脱敏脚本或工具的名称与版本、脱敏执行的日期和执行人、审批记录编号、脱敏后数据的校验方式（如抽样比对字段格式）。如果脱敏规则发生变更，在变更记录中写明调整的字段和原因。这些信息与敏感级别、脱敏要求相邻填写，便于评审时一并检查。
数据项很多时，清单按什么维度拆分更便于使用？
常见拆分维度有三个：按业务模块拆，适合模块边界清晰、责任人按模块划分的团队；按测试阶段拆，把冒烟专用数据和回归、性能数据分开，避免阶段间互相干扰；按数据敏感级别拆，把含个人信息的数据单独管理，便于权限控制和合规检查。拆分后每个子清单保留相同的表头结构，并用数据项标识前缀区分来源，汇总时仍可合并统计。
清单中的有效期到了但测试还没结束，应该怎么处理？
先由数据责任人确认数据是否仍匹配当前用例和版本。如果仍然可用，更新有效期至并记录延期原因；如果数据已随版本变化失效，将状态改为“已失效”，按清理方式处理，并通知关联用例的负责人准备替代数据。延期操作应保留在变更记录中，避免有效期被反复延长却无人复核。对于性能测试等长期占用的数据，建议在延期时同步评估存储占用和清理计划。
多人协作更新清单时，如何避免字段填写口径不一致？
把字段说明表作为清单的配套文档一起维护，新增或调整字段时同步更新说明。对状态、敏感级别这类枚举字段，在表格中设置固定取值或数据验证，减少自由填写。指定一名清单维护人负责表头结构和取值规范，数据责任人只更新自己负责的行。定期核对时抽查若干行，检查脱敏要求、访问权限等字段是否按口径填写，发现偏差在变更记录中注明修正。
