🔐 测试数据脱敏与生成
核心定位银行测试数据管理的首要目标是保障客户隐私安全与合规，同时确保测试数据的真实性和可用性。测试数据脱敏与生成是银行测试基础设施建设中最关键的环节，直接关系到测试有效性与法律合规风险。
📋 敏感数据识别与分级
银行系统中存储着大量受法律保护的敏感信息，需要在测试数据准备阶段进行准确识别和分级处理：
1. 敏感数据分类
| 数据类别 | 典型字段 | 敏感等级 | 监管依据 |
|---|---|---|---|
| 个人身份信息 | 姓名、身份证号、手机号、地址、生日 | ⭐⭐⭐ 高 | 《个人信息保护法》《数据安全法》 |
| 账户信息 | 卡号/账号、账户余额、交易密码 | ⭐⭐⭐ 高 | 《个人金融信息保护规范》 |
| 交易信息 | 交易金额、交易对手、交易时间、流水号 | ⭐⭐ 中 | 《金融机构客户尽职调查办法》 |
| 信用信息 | 征信评分、授信额度、逾期记录、五级分类 | ⭐⭐⭐ 高 | 《征信业管理条例》 |
| 企业信息 | 企业名称、统一社会信用代码、法人代表、注册资本 | ⭐⭐ 中 | 《企业信息公示条例》 |
| 监管报送数据 | 1104报表、反洗钱大额/可疑交易、CRS申报 | ⭐⭐⭐ 高 | 《银行业金融机构监管数据管理办法》 |
2. 敏感数据识别方法
- 元数据分析：扫描数据库表结构，通过字段名称（如 name、id_card、phone、balance）匹配敏感字段
- 数据内容扫描：正则表达式匹配身份证号（18位）、手机号（11位）、银行卡号（Luhn校验）等已知模式
- 数据血缘追踪：通过ETL链路追踪数据来源，标记从敏感源表派生的字段
- 人工标注补充：对无法自动识别的业务敏感字段（如客户经理备注、授信审批意见），由业务人员人工标注
合规红线生产数据未经脱敏直接导入测试环境，即使仅内部使用也属于违规行为。根据《个人信息保护法》，违规处理个人信息最高可处五千万元或上一年度营业额百分之五的罚款。
🔒 数据脱敏算法体系
1. 替换脱敏（Substitution）
将敏感数据替换为虚构但格式一致的数据。例如将真实姓名替换为从姓名库中随机抽取的姓名，保持姓氏和名字的长度分布特征。
- 适用场景：姓名、地址、企业名称等需要保持可读性和业务含义的字段
- 优点：数据看起来真实，业务人员可正常阅读和验证
- 缺点：需要维护替换词库，跨表关联可能断裂
2. 加密脱敏（Encryption）
使用加密算法（AES-256、SM4国密）对敏感字段进行加密，仅授权人员可解密还原。
- 适用场景：需要可逆恢复的场景，如数据迁移验证、生产问题复现
- 优点：可逆性强，密文安全性高
- 缺点：密文不可读，无法用于业务验证；需管理密钥
3. 掩码脱敏（Masking）
部分遮盖敏感数据，仅保留必要部分。如手机号显示 138****1234，身份证号显示 310***199001011234。
- 适用场景：日志输出、测试报告、屏幕展示等仅需部分信息的场景
- 优点：实现简单，保留部分可辨识信息
- 缺点：信息量损失大，不适合需要完整数据的测试场景
4. 偏移脱敏（Shifting）
将数值型数据按固定规则偏移，如账户余额统一加/减随机数，日期统一偏移N天。
- 适用场景：交易金额、账户余额、日期等数值型字段
- 优点：保持数值分布特征和排序关系
- 缺点：可能破坏业务规则（如余额不能为负、日期不能跨越业务周期）
5. 哈希脱敏（Hashing）
使用SHA-256/SM3等哈希算法将敏感字段转为固定长度的哈希值，不可逆。
- 适用场景：仅需数据关联不关心原文的场景，如脱敏后仍需要按证件号关联多表
- 优点：不可逆，安全性高，保持关联性（加盐哈希可实现一致性映射）
- 缺点：哈希碰撞风险（虽极低），无法还原原文
脱敏算法对比
| 算法 | 可逆性 | 数据可用性 | 关联保持 | 性能 | 推荐场景 |
|---|---|---|---|---|---|
| 替换 | 否 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | 姓名、地址 |
| 加密 | 是 | ⭐ | ⭐⭐⭐ | ⭐⭐ | 需恢复场景 |
| 掩码 | 否 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | 日志、报告 |
| 偏移 | 是 | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 金额、日期 |
| 哈希 | 否 | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 跨表关联 |
📊 测试数据生成策略
1. 基于生产数据脱敏生成（推荐主策略）
从生产环境导出数据子集，经过脱敏处理后导入测试环境。数据真实、分布符合生产，是最理想的测试数据来源。
- 步骤：数据子集化 → 敏感字段识别 → 脱敏算法应用 → 数据质量校验 → 导入测试环境
- 注意事项：子集需覆盖各类业务场景（正常、边界、异常），脱敏后需验证关联一致性
2. 规则驱动生成
根据业务规则和字段定义，自动生成符合格式要求的测试数据。适用于新功能测试、边界值测试和异常场景构造。
- 身份证号生成：按GB 11643标准生成，含地区码、生日、顺序码、校验位，覆盖不同省份和年龄段
- 银行卡号生成：按ISO 7812标准生成，正确填充BIN码和Luhn校验位
- 交易流水构造：模拟真实交易模式，构造连续流水、跨日交易、异常大额交易
3. 组合场景生成
基于测试场景定义，批量构造跨表关联的测试数据集。例如：
- 客户360场景：生成包含客户基本信息、多账户、历史交易、授信记录的完整数据集
- 日终场景：生成包含当日交易流水、积数变动、利息计提的批量处理数据集
- 异常场景：构造透支账户、冻结账户、久悬账户、错误交易流水等边界和异常数据
4. 数据生成参数控制
| 参数 | 说明 | 示例 |
|---|---|---|
| 数据量 | 按测试规模控制生成记录数 | 功能测试 1万条，性能测试 1000万条 |
| 分布特征 | 模拟生产的比例分布 | 活期:定期:通知 = 70:25:5 |
| 时间跨度 | 数据覆盖的时间范围 | 覆盖3年历史数据，含闰年 |
| 异常比例 | 注入异常数据的比例 | 5%账户为异常状态（冻结、销户） |
| 关联深度 | 跨表关联的层级深度 | 客户→账户→交易→流水，4层关联 |
🔍 功能测试要点
脱敏算法正确性
- 格式保持验证：脱敏后字段格式与原始数据一致——身份证号仍为18位、手机号仍为11位、银行卡号通过Luhn校验
- 唯一性保持：同一原始值经过一致性脱敏后，在所有表中映射为相同的脱敏值，确保跨表关联不断裂
- 不可逆验证：对不可逆脱敏算法，验证无法从脱敏数据反推出原始数据（尤其是替换和掩码算法）
- 业务规则保持：偏移脱敏后数据仍满足业务约束——余额不为负、日期在合理范围、金额精度不变
- 加密密钥管理：验证加密密钥的存储安全性、轮转机制、密钥泄露后的应急处理流程
敏感数据识别覆盖
- 全表扫描覆盖：对数据库中所有表和字段进行扫描，确保无遗漏的敏感字段（特别关注新增字段和临时表）
- 复合敏感识别：组合字段可能泄露敏感信息——如"性别+出生日期+邮编"可唯一标识大部分个人
- 半结构化数据：JSON/XML字段、CLOB大字段中嵌入的敏感信息识别，如交易备注中的身份证号
- 日志文件扫描：应用日志、数据库日志、中间件日志中可能包含明文敏感信息
- 增量识别机制：系统迭代后新增的敏感字段自动识别和告警，避免脱敏策略遗漏
数据生成质量
- 分布一致性：生成数据的统计分布（均值、方差、分位数）与生产数据一致，确保测试结果有参考意义
- 关联完整性：客户-账户-交易的多层关联完整，无孤儿记录；参照完整性约束全部满足
- 边界覆盖：生成数据覆盖所有业务场景——正常值、边界值（最大/最小金额）、异常值（负数、零值）
- 时间连续：交易数据按时间序列生成，确保日终处理、季度结息等批处理场景可正常执行
- 状态一致性：账户状态（正常/冻结/销户/久悬）与实际数据一致——冻结账户不应产生新交易
合规审计
- 脱敏审计日志：每次脱敏操作记录详细日志：操作时间、操作人、数据范围、脱敏算法、处理记录数
- 数据流向追踪：生产→脱敏→测试的数据流转全过程可追溯，任一环节可审计
- 权限控制验证：脱敏工具的使用权限、数据导出权限、测试环境访问权限均需最小化授权
- 残留检测：定期扫描测试环境，检测是否存在未脱敏的敏感信息（如测试人员手工导入的生产数据）
- 合规报告：自动生成脱敏处理报告，满足监管检查和内部审计要求
⚡ 性能测试要点
数据生成吞吐量
- 场景：千万至亿级账户数据的脱敏和生成，覆盖全量账户主表、交易流水表、客户信息表
- 目标：亿级数据脱敏生成完成时间 ≤ 8小时，单表吞吐量 ≥ 10万行/秒
- 验证点：数据库写入性能、脱敏算法CPU消耗、跨表关联一致性校验的IO开销
- 策略：按分库分表策略并行生成，每个分片独立处理，最后合并校验
脱敏工具执行效率
- 场景：日常回归测试的数据刷新——每日/每周从生产拉取增量数据脱敏后导入测试环境
- 目标：增量脱敏（日增百万级交易）完成时间 ≤ 30分钟，全量刷新 ≤ 4小时
- 验证点：脱敏脚本的SQL执行效率、索引利用率、大字段（CLOB/BLOB）处理性能
- 优化措施：批量提交（batch commit）、并行游标读取、数据库连接池配置调优
大表脱敏耗时
- 场景：交易流水表（百亿级记录）、账户历史表等超大表的全量脱敏
- 目标：单表百亿级脱敏完成时间 ≤ 48小时，支持断点续跑和增量追加
- 验证点：分区表并行处理、大表全表扫描IO、数据库归档日志生成速度
- 策略：按日期分区并行脱敏，支持从上次中断点继续处理，避免全量重跑