制定测试数据脱敏规则，核心是把“哪些字段敏感、怎么处理、谁来执行、如何验证”写成可执行的约定。适用于数据从生产侧进入测试环境、并供多个测试团队共用的场景：先按字段分级，再为每级选定脱敏方式，随后固化为抽取、脱敏、分发流程，最后用抽样比对和关联校验确认结果安全且可用。规则还需写明责任人、例外审批和更新机制。
要点总览（TL;DR）
- 脱敏规则先交付敏感字段分级表：按身份标识、联系方式、账户与金额、地址、自由文本分类，逐字段写明级别、脱敏方式、保留用途和责任人。
- 脱敏方式按安全性与测试可用性共同选择：遮蔽、替换、假名化、泛化、随机化、加密各有适用条件，需保持格式、唯一性和关联关系的字段要单独标注约束。
- 执行流程覆盖申请审批、按规则抽取、受控环境脱敏、分发授权与到期回收，每个环节记录规则版本和执行日志，并明确数据Owner、测试负责人、安全审核人和平台运维的职责。
- 校验从安全性和可用性两个方向进行：抽样比对确认敏感字段已处理，唯一性与关联查询确认数据未失真，全部通过后由测试负责人和安全审核人共同放行。
- 规则随生产表结构和业务变化更新，保留版本历史，例外使用真实数据需限定范围、期限和补偿措施，落地完成以分级覆盖、流程留痕、校验通过、访问回收、版本可追溯为检查标准。
先定规则骨架：敏感字段分级与脱敏方式选择
脱敏规则的第一步交付物是一张敏感字段清单，而不是先选工具。做法是从生产库的表结构出发，逐表逐字段判断：该字段泄露后会造成什么影响，测试又需要它保留什么特征。分级通常按影响程度划分，例如高敏感（可直接识别个人身份或造成资金风险）、中敏感（联系方式、地址等可定位到个人的信息）、低敏感（业务属性、统计维度）。分级结果决定处理强度，测试用途决定保留程度，两者共同约束脱敏方式的选择。
按字段类别识别时，可参考以下常见划分：身份标识类（身份证号、护照号、员工编号）、联系方式类（手机号、邮箱、座机）、账户与金额类（银行卡号、账户余额、交易金额）、地址类（收货地址、注册地）、自由文本类（备注、工单描述、日志消息）。自由文本最容易被忽略，其中可能夹带姓名、电话或证件号，需要单独标注并采用识别加处理的方式。
脱敏方式的选择依据是“安全强度”与“测试可用性”的平衡，常用方式及适用条件如下：
| 脱敏方式 | 适用条件 | 典型字段 |
|---|---|---|
| 遮蔽 | 测试只需确认字段存在或展示效果，无需真实值 | 身份证号中间位、银行卡号 |
| 替换 | 需要保持格式与长度，值可整体换为虚构内容 | 姓名、邮箱、地址 |
| 假名化 | 需要保持唯一性和关联关系，同一原值映射到同一假值 | 用户标识、手机号 |
| 泛化 | 测试关注区间或分布，无需精确值 | 年龄、金额区间、地区 |
| 随机化 | 需要生成符合格式的随机值，且不要求与原值对应 | 测试用手机号、订单号 |
| 加密 | 需要在受控条件下还原原值，如特定验证场景 | 需授权访问的账户字段 |
选择时要特别标注三类字段：需要保持格式的（如手机号必须11位，否则前端校验用例失败）、需要保持唯一性的（如用户ID，重复会导致关联查询错乱）、需要保持关联关系的（订单表的用户标识必须与用户表一致）。这三类字段优先使用假名化或格式保持替换，并在规则表中注明约束。
规则表建议包含以下列，逐字段填写，作为后续执行和校验的依据：
- 字段名与所属表：定位到具体列，避免同名歧义。
- 敏感级别：高、中、低，对应不同审批与处理要求。
- 脱敏方式：从上述方式中选择，并写明参数（如遮蔽位数、泛化区间）。
- 保留用途：说明测试为何需要该字段，以及需要保留的格式、唯一性或关联特征。
- 责任人：该字段所属业务或数据Owner，负责确认分级与方式。
从生产到测试环境的执行流程与角色分工
规则写完后要落到一条可重复执行的流程上。每个环节都应有明确的输入、动作、输出和负责人，避免“谁都能取数、谁都不负责”的局面。
申请与审批。测试团队提出数据需求，说明用途、涉及的表与字段范围、使用期限和访问人员。审批人依据规则表判断申请字段的敏感级别：低敏感可按标准流程放行，高敏感需安全或合规审核人复核。输出是一份带范围与期限的数据使用申请单。
抽取。按申请范围限定字段与数据量，只取测试所需的最小集合，避免整库搬运。抽取脚本应引用规则表中的字段清单，字段增减通过修改规则而非临时改脚本。输出是待脱敏的原始数据集及其来源标识。
脱敏执行。在受控环境中运行脱敏作业，作业需记录规则版本、执行时间、处理字段和记录数。执行日志是后续追溯的依据，不能只保留结果不留过程。输出是脱敏后的数据集与执行日志。
分发与共享。面向多个测试团队时，按团队和用途划分数据集，分别授权访问，并设定使用期限。到期后回收访问权限并清理副本，避免数据在多个环境长期滞留。输出是授权记录与回收记录。
角色分工可按下表落实，同一人可兼任多个角色，但职责要写清：
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 数据Owner | 确认字段分级与脱敏方式，审批高敏感数据使用 | 规则表确认记录、审批意见 |
| 测试负责人 | 提出数据需求，说明用途与期限，组织校验 | 数据使用申请单、校验记录 |
| 安全或合规审核人 | 复核高敏感字段处理方式与例外申请 | 审核结论、例外审批记录 |
| 平台运维 | 执行抽取与脱敏作业，维护环境与访问控制 | 执行日志、授权与回收记录 |
这条流程涉及申请单、审批意见、执行日志和校验记录在多团队之间流转。若团队已在用研发管理平台，可以把数据使用申请建成工作项，把规则表和校验记录放入项目文档，让审批状态、规则版本和放行结论在同一处可查。ONES 提供工作项与文档管理能力，可用于承载这类流程记录；脱敏作业本身仍在数据平台侧执行。
校验要求：怎么确认脱敏结果既安全又可用
脱敏完成后不能直接分发，需要从安全性和可用性两个方向校验，两者都通过才放行。
安全性校验关注敏感信息是否已按规则处理。做法是抽样比对原始数据与脱敏数据：抽取一定比例记录，逐字段核对高敏感字段是否已遮蔽、替换或假名化，检查是否存在规则未覆盖的字段仍保留原值。抽样应覆盖每张表和每个敏感级别，自由文本字段要单独抽查，确认其中夹带的姓名、电话、证件号已被识别处理。日志、附件、导出文件等位置同样要检查，这些地方常因不在主表范围内而被遗漏。
可用性校验关注测试是否还能正常进行。检查唯一性：假名化后的用户标识是否仍一一对应，有无重复或空值。检查关联关系：订单表与用户表按用户标识关联查询，结果是否与脱敏前一致。检查格式：手机号长度、邮箱格式、金额精度是否满足前端校验和业务规则用例的要求。若测试用例依赖特定数据分布，还需确认泛化或随机化后分布未严重偏离。
校验结果要留痕，形成放行依据。校验清单可包含以下条目：
- 高敏感字段抽样比对通过，无原值残留。
- 自由文本、日志、附件抽查无敏感信息残留。
- 唯一性检查通过，关键标识无重复、无空值。
- 关联查询结果与脱敏前一致。
- 格式与精度满足测试用例要求。
- 校验人、校验时间、规则版本记录完整。
全部条目通过后由测试负责人和安全审核人共同确认放行；任一条目不通过，退回脱敏环节修正并重新校验。
示例：一张用户表与一张订单表的规则落地
以下为演示情景，用两张常见表说明规则如何填写，读者可对照自己的表结构迁移。
用户表包含姓名、手机号、身份证号、邮箱、注册地址。姓名属中敏感，测试需要展示真实感，采用替换为虚构姓名，保持长度；手机号属高敏感且需保持格式与唯一性，采用假名化，生成11位虚构号码并保证同一用户映射一致；身份证号属高敏感，测试只需验证校验位逻辑，采用遮蔽中间位并保留首尾；邮箱属中敏感，采用替换为虚构域名邮箱，保持格式；注册地址属中敏感，测试关注地区分布，采用泛化到城市级别。
订单表包含订单号、用户标识、金额、收货地址。订单号属低敏感，测试需要唯一订单用于查询，保留原值或按规则重新生成均可，本例保留原值；用户标识需与用户表关联，采用与用户表相同的假名化映射，确保两表关联一致；金额属中敏感，测试关注区间与统计，采用泛化到百元区间；收货地址属中敏感，采用泛化到城市级别，与用户表口径一致。
规则填写时要在“保留用途”列写明原因：手机号保留格式是为了通过前端校验用例，用户标识假名化是为了关联查询，金额泛化是为了统计类测试。校验时，抽样比对用户表手机号与身份证号确认已处理；执行订单表与用户表的关联查询，确认关联记录数与脱敏前一致；抽查收货地址确认已泛化到城市。校验记录连同规则版本一并归档，作为本次分发的放行依据。
规则维护与完成检查
脱敏规则不是一次写完就固定不变。生产表结构新增字段、业务新增敏感信息类型、测试用途变化时，都应触发规则更新。触发条件建议写进规则文档：新增表或字段、字段含义变化、出现新的敏感类别、校验发现遗漏。每张表指定一名责任人，负责在变更发生时评估是否需要调整分级和脱敏方式，并在规则表中更新版本号。
规则版本要可追溯。每次修改记录变更内容、修改人、生效时间和影响的表字段，历史版本保留，便于回溯某次分发使用的是哪版规则。例外审批要有条件约束：确需使用真实数据的场景，应说明理由、限定使用范围和期限、指定访问人员，并采取补偿措施，如限制在隔离环境、禁止导出、到期强制清理。例外记录与常规审批分开归档，便于审计。
落地完成可按以下检查表逐项核对：
- 分级覆盖：所有含敏感信息的表和字段已纳入规则表，无遗漏字段。
- 流程留痕：申请、审批、执行日志、分发授权均有记录，可追溯到人和时间。
- 校验通过：安全性与可用性校验清单全部通过，记录完整。
- 访问回收：使用期限到期的数据集已回收权限并清理副本。
- 规则版本可追溯：当前版本号、变更记录和历史版本齐全。
- 责任人明确：每张表有指定责任人，例外审批有补偿措施记录。
以上检查项全部满足，说明这套脱敏规则已具备执行、校验和维护的闭环，可以支撑多个测试团队共用生产侧数据。
常见问题
测试团队临时需要某个未纳入规则表的新字段，应该怎么处理？
先暂停该字段的数据分发，由该表责任人判断字段是否含敏感信息并补充分级，再按级别选择脱敏方式，更新规则表并记录版本变更。若测试时间紧迫，可先按高敏感级别处理并走例外审批，待规则正式更新后再恢复标准流程。关键是不要让未分级字段以原值进入测试环境。
多个测试团队共用同一批脱敏数据时，如何避免权限扩散？
按团队和用途划分数据集，分别授权，每个团队只拿到与其测试范围对应的数据子集。授权记录写明使用人员、用途和期限，到期后回收权限并清理各环境副本。共用数据集时，建议指定一名数据管理员统一维护授权清单，定期核对实际访问人员与授权是否一致。
脱敏后测试用例仍然失败，怎么判断是数据问题还是代码问题？
先核对校验记录：确认该用例依赖的字段格式、唯一性和关联关系是否在脱敏后保留。若格式或关联被破坏，属于脱敏方式选择问题，应调整规则并重新生成数据；若数据特征与脱敏前一致，则按常规缺陷流程排查代码。建议在规则表的“保留用途”列写清每个字段支撑的测试类型，便于快速定位。
例外审批允许使用真实数据时，需要哪些补偿措施？
例外申请应说明理由、限定使用范围和期限、指定访问人员，并采取补偿措施，例如限制在隔离环境使用、禁止导出和截屏、到期强制清理。例外记录与常规审批分开归档，便于审计时单独核查。例外到期后应确认数据已清理，再关闭申请。
规则表由谁维护，生产表结构变化时怎么保证同步？
每张表指定一名责任人，通常由该表所属业务的数据Owner担任，负责在新增表或字段、字段含义变化、出现新敏感类别时评估并更新规则。变更时记录修改内容、修改人、生效时间和影响的字段，保留历史版本。可把规则更新设为表结构变更流程中的一个检查项，避免遗漏。
