测试数据的量级、分布和真实性直接决定性能测试结果的有效性——用百万级数据测出的TPS，上线面对百亿数据量可能完全不成立。银行业还需在数据真实性与数据安全之间取得平衡，脱敏是刚性需求。
做法：从生产环境导出数据→经脱敏工具处理后→导入测试库。这是银行性能测试最推荐的方式，因为数据分布、关联关系和业务逻辑与生产一致。
优势：数据真实性最高，索引效率和SQL执行计划与生产接近。代价：脱敏过程复杂，数据量大时导出导入耗时长。
做法：分析生产数据的统计特征（账号分布、金额分布、交易频率），用数据构造工具生成符合相同分布的模拟数据。
优势：灵活控制数据量、无需脱敏流程。代价：关联关系难还原，无法完全模拟真实业务场景。
做法：用随机函数生成完全没有业务含义的测试数据。仅适用于功能验证阶段的冒烟测试，不应用于正式性能测试。
| 数据类型 | 示例 | 脱敏要求 |
|---|---|---|
| 个人身份信息 | 姓名、身份证号、手机号、地址 | 不可逆脱敏，无法还原为原始值 |
| 账户信息 | 银行卡号、账号、客户号 | 格式一致性脱敏（保持卡BIN和校验位） |
| 交易信息 | 交易金额、余额、密码、CVV | 数值偏移或替换，保持数值范围和分布 |
| 企业信息 | 企业名称、统一社会信用代码 | 脱敏后保持企业类型的业务特征 |
| 数据层级 | 最低要求 | 推荐要求 | 说明 |
|---|---|---|---|
| 核心业务表 | ≥生产80% | ≥生产100% | 账户表、交易流水表 |
| 历史数据表 | ≥近3个月 | ≥近12个月 | 用于范围查询性能验证 |
| 关联/字典表 | 100%同步 | 100%同步 | 确保关联查询能正确执行 |
操作：分别用100万、1000万、1亿条数据量测试同一条SQL，对比执行计划和响应时间差异。记录数据量翻倍时索引效率的衰减曲线。
操作：脱敏完成后运行业务连通性测试——用脱敏数据执行核心业务场景（开户、转账、查询），确保所有交易能正常完成而不因数据格式问题报错。