生产数据进入测试环境后，往往会被多个测试团队反复复制、导出和转存，泄露风险随之放大。本文给出一套可交接的脱敏流程设计：从需求登记、字段分级、规则评审，到执行留痕、共享授权和校验销毁，每个环节都明确输入、负责人和输出物，并用字段清单、规则表与校验记录把口径固定下来。
要点总览（TL;DR）
- 把脱敏流程拆成六个可交接环节：需求登记、字段识别与分级、规则制定与评审、执行与留痕、共享分发与权限控制、校验与退出销毁，前一环节的输出作为后一环节的输入。
- 先按业务对象逐表建立敏感字段清单并划分高、中、低三级，由字段负责人确认；新增字段在确认前默认按高敏感处理。
- 规则表要写清规则类型、参数和关联映射键，评审重点看高敏感字段是否不可逆处理、关联字段映射是否一致、规则能否覆盖需求范围。
- 多团队共享采用集中存放、按权限访问，申请与授权一一对应，并约定使用范围与禁止再扩散条款；校验覆盖残留敏感值、关联一致性和可用性，不通过则回退重做。
- 上线前用检查清单确认各环节就绪，运行中按月复查授权回收、校验回退和违规使用情况，表结构或业务变更时触发规则更新。
脱敏流程的整体框架与六个环节
测试数据脱敏要解决的核心问题是：生产数据在离开生产库之后，经过哪些处理、由谁处理、处理结果如何被证明是安全的。把这条链路拆成六个可交接的环节，每个环节都有明确的输入、动作、输出和完成标志，流程才能从个人经验变成团队可执行的机制。
六个环节按顺序衔接：数据需求登记 → 敏感字段识别与分级 → 脱敏规则制定与评审 → 脱敏执行与留痕 → 共享分发与权限控制 → 校验与退出销毁。前一环节的输出是后一环节的输入，任一环节缺少交付物，后续环节就无法启动。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 数据需求登记 | 测试场景说明、所需业务对象与数据范围 | 登记用途、使用团队、数据范围、使用期限 | 数据需求单 | 需求单经测试负责人确认，范围可对应到具体表 |
| 敏感字段识别与分级 | 数据需求单、源表结构 | 按业务对象逐表梳理字段，标注敏感级别 | 敏感字段清单与分级表 | 字段负责人逐项确认签字 |
| 脱敏规则制定与评审 | 敏感字段清单与分级表 | 为每个字段选择规则类型，填写规则表并评审 | 脱敏规则表、评审记录 | 评审通过，规则表版本冻结 |
| 脱敏执行与留痕 | 规则表、源数据抽取范围 | 在受控环境执行脱敏，记录执行参数与结果 | 脱敏数据集、执行记录 | 执行记录完整，产物带版本标识 |
| 共享分发与权限控制 | 脱敏数据集、使用申请 | 按团队分发，配置访问权限与使用约定 | 授权记录、分发清单 | 申请与授权一一对应，权限已生效 |
| 校验与退出销毁 | 脱敏数据集、校验标准 | 抽样或全量校验，到期回收销毁 | 校验记录、销毁记录 | 校验通过并归档，销毁有凭证 |
流程中需要留痕的节点有四处：需求单的确认记录、字段分级表的确认记录、规则评审结论、执行与校验记录。这四类记录构成事后追溯的依据，也是审计时最先被调取的证据。留痕方式可以放在协作平台的工作项和文档中，让每次变更都有时间、责任人和版本。
敏感字段识别与分级：先定清单再定规则
规则制定之前必须先有字段清单。没有清单，脱敏就变成凭经验挑字段，遗漏往往发生在新增表或新增字段上。清单的建立方式是按业务对象逐表梳理：以客户、订单、账户、地址等业务对象为单位，列出其涉及的每张表、每个字段，标注字段含义、示例值和是否属于敏感信息。
敏感级别建议分为三级，对应不同处置强度：
- 高敏感：可直接识别自然人身份或造成直接损失的信息，如身份证号、银行卡号、手机号、详细住址、密码类字段。处置要求为不可逆脱敏，测试环境不保留原值。
- 中敏感：与其他信息组合后可识别个人或反映业务机密的信息，如姓名、邮箱、客户编号、交易金额。处置要求为替换或泛化，保留格式与统计特征。
- 低敏感：单独使用时识别风险低的字段，如城市、产品类别、状态码。处置要求为按需处理，通常保留原值以维持测试可用性。
分级结果需要字段负责人确认。字段负责人通常是该业务对象的开发负责人或数据负责人，由其确认字段含义、级别判断和处置要求，确认动作以清单签字或系统审批的形式留下记录。字段负责人对级别判断负责，安全与合规角色对分级标准的执行一致性负责。
识别结果要随表结构变化维护。触发维护的条件包括：新增表或新增字段、字段含义变更、业务系统上线新功能。维护动作是更新清单并重新确认受影响字段，未确认的新字段在清单中标记为待定，待定字段默认按高敏感处理，直到完成确认。
| 业务对象 | 表名 | 字段 | 字段含义 | 敏感级别 | 处置要求 | 字段负责人 | 确认状态 |
|---|---|---|---|---|---|---|---|
| 客户 | customer | cust_name | 客户姓名 | 中 | 替换 | 待填写 | 待确认 |
| 客户 | customer | id_card | 身份证号 | 高 | 不可逆脱敏 | 待填写 | 待确认 |
| 客户 | customer | mobile | 手机号 | 高 | 不可逆脱敏 | 待填写 | 待确认 |
| 订单 | order_main | amount | 订单金额 | 中 | 泛化 | 待填写 | 待确认 |
脱敏规则怎么制定与评审
规则表是脱敏流程的核心交付物，它把字段分级翻译成可执行的处理方式。规则类型主要有五类，选择时以字段级别和测试用途为依据：
- 替换：用同类型假值替换原值，如姓名替换为随机中文姓名。适用于需要真实感但不需要真实值的字段。
- 遮蔽：保留部分字符，其余用固定符号覆盖，如手机号保留前三位和后四位。适用于需要展示格式的场景。
- 泛化：降低数据精度，如精确金额改为区间、详细地址改为城市。适用于统计分析类测试。
- 随机化：在合法取值范围内生成随机值，如随机日期、随机编号。适用于对取值分布有要求的字段。
- 置空：直接清空字段值。适用于测试中不需要该字段、且清空不影响业务逻辑的情况。
规则选择要兼顾数据可用性，重点约束三项：关联一致性，同一实体在多张表中的标识字段必须映射到同一个假值，否则关联查询会断裂；格式与长度，脱敏后的值要满足字段类型、长度和校验规则，避免测试因格式错误失败；业务分布，金额、日期等字段的取值分布应接近真实数据，否则基于数据的测试结论会失真。
规则表建议包含以下字段：字段所属表、字段名、敏感级别、规则类型、规则参数（如遮蔽位数、泛化区间）、关联映射键、规则版本、评审状态。规则参数要写具体，避免只写“脱敏处理”这类无法执行的描述。
| 表.字段 | 级别 | 规则类型 | 规则参数 | 关联映射键 | 评审状态 |
|---|---|---|---|---|---|
| customer.id_card | 高 | 替换 | 生成合法格式的假身份证号，校验位正确 | cust_id | 待评审 |
| customer.mobile | 高 | 遮蔽 | 保留前3后4，中间4位掩码 | cust_id | 待评审 |
| customer.cust_name | 中 | 替换 | 随机中文姓名，同cust_id保持一致 | cust_id | 待评审 |
| order_main.amount | 中 | 泛化 | 按100元区间取整 | — | 待评审 |
评审由数据管理员组织，参与角色包括安全与合规、测试负责人和字段负责人。评审要点有四项：高敏感字段是否全部采用不可逆处理；关联字段的映射键是否一致；规则参数是否可执行、是否保留必要格式；规则是否覆盖需求单中的全部数据范围。评审结论和修改意见记入评审记录，规则表冻结版本后才可进入执行环节。
执行、共享分发与权限控制
脱敏执行要在受控环境中完成，执行账号与生产库日常运维账号分离，执行过程记录抽取范围、规则表版本、执行时间、执行人和产物存放位置。执行记录的作用是回答“这份测试数据是用哪版规则、从哪个范围生成的”，当规则更新或数据范围调整时，能定位受影响的产物并决定是否重做。
脱敏产物要有版本与标识。建议采用“数据集名称+规则表版本+生成日期”的命名方式，产物清单中登记每个版本对应的规则版本和适用范围。旧版本产物在新版本生效后进入待回收状态，避免多版本混用导致测试结论不一致。
多团队共享时，分发方式与申请流程要绑定。使用团队提交共享申请，写明使用场景、所需数据集版本、使用期限和存放位置；数据管理员核对申请与已有授权，确认无重复分发后发放访问权限。共享优先采用集中存放、按权限访问的方式，减少数据被复制到个人环境的机会。
| 申请团队 | 数据集与版本 | 使用场景 | 使用期限 | 授权范围 | 审批人 | 授权状态 |
|---|---|---|---|---|---|---|
| 待填写 | 待填写 | 待填写 | 待填写 | 只读/可导出 | 数据管理员 | 待审批 |
授权时要同时约定使用范围与禁止再扩散条款：数据仅限申请场景使用，不得转存到个人设备或公共网盘，不得用于演示、培训等申请之外的用途，不得与外部人员共享。约定写入授权记录，由申请团队负责人确认。在协作平台中承载这类流程时，可以把共享申请做成工作项，审批结论、授权范围和期限随工作项留痕；ONES TestCase 支持为不同用户组配置不同权限，也支持为用例库、测试计划单独配置权限，适合把测试资产与数据使用权限分开管理。脱敏执行与数据扫描本身属于独立工具能力，选型时需单独核验。
校验要求与泄露防控检查
脱敏结果必须经过校验才能交付使用。校验方式在抽样校验与全量扫描之间取舍：数据量小或字段结构简单时采用全量扫描，逐字段比对是否残留原值；数据量大时采用抽样校验加关键字段全量扫描的组合，高敏感字段全量检查，中低敏感字段按比例抽样。
校验项覆盖三个方面：
- 残留敏感值：检查高敏感字段是否还存在可匹配生产原值的记录，包括自由文本字段中夹带的号码、地址等信息。
- 关联一致性：抽取若干实体，验证其在多张表中的标识映射是否一致，关联查询能否正常返回结果。
- 可用性：验证字段格式、长度、非空约束是否满足测试要求，核心测试场景能否跑通。
校验不通过时执行回退：定位问题字段与规则，修正规则表并重新评审，重新执行脱敏并再次校验，问题产物标记作废并回收。回退过程同样留痕，记录问题原因和处理结果，作为规则优化的输入。
| 校验项 | 校验方式 | 通过标准 | 校验人 | 结论 |
|---|---|---|---|---|
| 高敏感字段残留 | 全量扫描 | 无记录可匹配生产原值 | 待填写 | 通过/不通过 |
| 关联一致性 | 抽样比对 | 抽样实体跨表映射一致 | 待填写 | 通过/不通过 |
| 可用性 | 场景试跑 | 核心测试场景执行成功 | 待填写 | 通过/不通过 |
审计日志与定期复查是泄露防控的兜底手段。日志记录数据集的申请、授权、访问和销毁动作；定期复查按月或按季度核对授权是否仍在有效期内、产物是否按约定存放、有无超范围使用迹象。复查发现的问题进入整改清单，跟踪到关闭。
角色分工与各环节交付物
流程能否落地，取决于每个环节是否有明确的责任人。四类角色的职责边界如下：
- 数据管理员：负责需求登记受理、字段清单维护、规则表组织评审、执行调度、共享审批和产物回收，是流程的主要推动者。
- 安全与合规：负责分级标准、规则底线（如高敏感字段必须不可逆）、校验标准和审计复查，对例外申请出具意见。
- 测试负责人：负责确认数据需求的真实性与范围、指定使用团队、确认使用约定，对本团队的使用行为负责。
- 平台管理员：负责执行环境、访问权限的技术配置和日志采集，保障权限变更及时生效。
| 环节 | 主责角色 | 配合角色 | 交付物 | 交接方式 |
|---|---|---|---|---|
| 数据需求登记 | 数据管理员 | 测试负责人 | 数据需求单 | 工作项流转至字段识别 |
| 敏感字段识别与分级 | 数据管理员 | 字段负责人、安全与合规 | 敏感字段清单与分级表 | 清单确认后附入需求单 |
| 规则制定与评审 | 数据管理员 | 安全与合规、测试负责人、字段负责人 | 脱敏规则表、评审记录 | 评审通过后冻结版本 |
| 执行与留痕 | 平台管理员 | 数据管理员 | 脱敏数据集、执行记录 | 产物登记入清单 |
| 共享分发与权限 | 数据管理员 | 平台管理员、测试负责人 | 授权记录、分发清单 | 权限生效后通知申请团队 |
| 校验与销毁 | 安全与合规 | 数据管理员、平台管理员 | 校验记录、销毁记录 | 校验通过归档，到期回收 |
审批与例外处理要有明确责任人。常规共享由数据管理员审批；涉及高敏感字段扩大范围、延长使用期限或导出到受限环境的申请，由安全与合规复核；例外放行必须由安全与合规与测试负责人共同确认，并记录理由和补偿措施。审批记录与工作项关联，便于复查时追溯。
示例：一条客户信息数据从生产到共享的脱敏过程
以下为演示情景，用于说明各环节如何衔接。某测试团队需要验证客户注册与订单查询功能，申请从生产侧抽取客户表和订单表各一万条记录。
字段构成与级别。客户表包含客户编号、姓名、身份证号、手机号、注册城市；订单表包含订单号、客户编号、订单金额、下单时间。其中身份证号、手机号为高敏感，姓名为中敏感，订单金额为中敏感，客户编号作为关联键保留原值但仅限测试环境使用，城市、时间等为低敏感。
规则选择理由。身份证号采用替换，生成校验位正确的假号码，保证依赖身份证校验的注册流程可测；手机号采用遮蔽，保留前三位后四位，满足页面展示和短信格式校验；姓名采用替换，同一客户编号映射到同一假姓名，保证跨表查询一致；订单金额采用按百元区间泛化，保留金额分布用于统计类断言；客户编号作为映射键不做变换，确保客户表与订单表关联不断裂。
执行与校验结果。执行记录登记规则表版本、抽取范围和执行时间，产物命名为“客户订单数据集-v1.2-生成日期”。校验阶段对身份证号、手机号做全量扫描，未发现可匹配生产原值的记录；抽取五百个客户编号验证跨表映射，关联查询全部返回；注册与订单查询场景试跑通过。校验结论为通过，记录归档。
共享时的权限差异。团队A负责功能测试，授予只读访问，允许在测试环境内查询但不可导出；团队B负责数据分析类测试，授予只读加受限导出权限，导出文件需加密存放并在使用期限结束时删除。两个团队的授权记录分别登记使用场景和期限，到期由数据管理员发起回收。
流程落地检查与持续维护
流程上线前，用一份检查清单确认各环节已具备执行条件：
- 数据需求单模板已发布，登记入口可用，测试负责人知道如何提交。
- 敏感字段清单覆盖当前测试涉及的全部业务对象，字段负责人已确认。
- 脱敏规则表已按分级标准填写，高敏感字段全部采用不可逆处理，评审记录完整。
- 执行环境与账号已就绪，执行记录模板可用，产物命名规则已通知相关团队。
- 共享申请与授权记录模板已发布，使用范围与禁止再扩散条款已写入。
- 校验标准与校验记录表已明确，回退处理流程已演练。
- 角色分工表已确认到人，例外处理责任人明确。
- 审计日志采集已开启，定期复查的周期和负责人已确定。
运行中的复查围绕三类指标：授权到期未回收的数量、校验不通过后回退的次数、超范围使用或违规存放的发现数。前两类反映流程执行质量，第三类反映防控有效性。指标按月汇总，异常项进入整改清单。
规则更新由明确条件触发：表结构新增或变更字段、业务系统上线涉及客户信息的新功能、分级标准调整、校验中发现规则遗漏。触发后更新字段清单和规则表，重新评审并生成新版本产物，旧版本进入回收流程。
流程文档本身也要版本管理。字段清单、规则表、责任矩阵和检查清单分别记录版本号、修订日期和修订人，重大调整保留变更说明。文档版本与产物版本对应，确保任何时候都能回答“这批测试数据依据的是哪一版规则”。在协作平台中，可以把需求单、评审记录、授权记录和校验记录放在同一工作项下流转，让流程文档与执行记录保持同步，减少文档与实际操作脱节的情况。
常见问题
测试环境里已经有一批历史数据，新流程上线后要怎么处理？
建议先把存量数据纳入同一套字段清单和分级标准，按当前规则重新评估。对仍在使用期限内的数据集，补做一次校验，确认高敏感字段没有残留原值；对来源不明、无法对应到需求单和规则版本的数据集，标记为待回收并安排销毁。存量清理与新流程并行推进，避免新旧两套口径长期并存。
多个测试团队同时使用同一份脱敏数据，出现数据被改动的情况怎么办？
共享时优先采用集中存放、按权限访问的方式，默认授予只读权限，从机制上减少数据被改动或复制到个人环境的机会。确有导出需求的团队单独申请受限导出权限，导出文件加密存放并在期限内删除。如果测试场景需要写入，建议为每个团队分配独立的数据副本，并在授权记录中登记副本归属，避免互相覆盖影响测试结论。
脱敏规则评审通过后，业务表结构发生变化，规则表要怎么更新？
表结构新增或变更字段、业务上线涉及个人信息的新功能、分级标准调整、校验中发现规则遗漏，这几类情况都应触发规则更新。更新动作是先改字段清单并确认新字段级别，再补充或修改规则表，重新走评审并冻结新版本，然后生成新版本产物，旧版本进入回收流程。未完成确认的新字段在清单中标记为待定，按高敏感处理。
校验时抽样比例怎么定，抽少了会不会漏掉残留敏感值？
抽样比例取决于字段级别和数据量。高敏感字段建议全量扫描，包括自由文本中可能夹带的号码、地址等信息；中低敏感字段可以按比例抽样，比例根据数据规模和风险承受度确定，并在校验标准中写清楚。数据量小或结构简单时直接全量扫描更省事。抽样方案一旦确定就固定下来，后续复查沿用同一口径，便于比较不同批次的结果。
脱敏流程中的需求单、评审记录和授权记录，适合放在什么工具里管理？
关键要求是这些记录能互相关联、带时间和责任人、可追溯版本。可以用协作平台的工作项承载需求登记和共享申请，把评审结论、授权范围和期限附在同一工作项下；字段清单和规则表用文档管理并记录版本。ONES TestCase 支持为不同用户组配置不同权限，也支持为用例库、测试计划单独配置权限，适合把测试资产与数据使用权限分开管理。脱敏执行和数据扫描属于独立工具能力，选型时需要单独核验。
使用期限到了但团队还在测试，能不能直接延期？
延期应当走一次新的授权确认，而不是默认续期。申请团队说明继续使用的理由和预计结束时间，数据管理员核对数据集版本是否仍为当前有效版本，安全与合规对涉及高敏感字段或扩大范围的延期出具意见。延期记录更新到原授权记录中，保留原期限和延期后的期限，便于复查时看清授权历史。
