1. 概述

测试数据是测试执行的基石，但在实际项目中，获取高质量、合规且覆盖全面的测试数据从来都是难题。AI合成数据的出现，为这一长期困扰测试团队的痛点提供了一条全新的解决路径。通过大语言模型（LLM）和生成模型，我们可以按需生成结构化、语义合理且隐私安全的测试数据。

1.1 测试数据的核心痛点

• 真实数据获取难：生产数据通常被严格管控，审批流程长、脱敏周期久，测试团队往往在项目启动后数周才能拿到可用数据。
• 隐私合规约束：GDPR、《个人信息保护法》、银保监会规定等法律框架对个人信息使用提出了严格要求，直接使用生产数据测试存在合规风险。
• 数据覆盖不全：生产数据往往是「快乐路径」的聚集地，边界值、异常场景、低频交易等测试关键场景在生产数据中占比极低甚至不存在。
• 数据一致性难以保证：跨表、跨系统的关联数据在脱敏后容易出现引用断裂，导致测试过程中数据不可用。
• 数据刷新成本高：版本迭代导致数据结构变更时，测试数据需要同步更新，手工维护的人力成本居高不下。

1.2 合成数据 vs 真实数据

2. AI合成数据的核心方法

不同数据类型对合成方法的要求截然不同。以下从文本、图像、结构化数据和异常数据四个维度，分别介绍当前最有效的AI合成方法。

2.1 基于LLM的文本数据合成

大语言模型在文本生成领域表现出色，可以用于合成各类测试所需的文本数据。与传统的规则模板方式不同，LLM能理解语义上下文，生成更自然、更多样的文本。

主要应用场景：

• 对话数据：生成多轮客服对话、投诉工单、智能助手问答日志，用于测试NLP系统和对话机器人。
• 业务文档：合成合同条款、授信报告、尽调文件等结构化长文本，用于测试文档解析和信息抽取能力。
• 系统日志：模拟各类格式（JSON、Syslog、Apache）的日志数据，覆盖正常、告警、错误各级别。
• 多语言文本：生成中英混合、方言、Unicode特殊字符等复杂文本，用于国际化测试。

LLM文本合成的Prompt示例：

你是一位银行系统测试数据生成器。请生成10条银行客服对话记录，每条包含用户问题和客服回复。

## 数据要求
- 用户情绪分布：60% 正常咨询 / 20% 抱怨不满 / 10% 紧急挂失 / 10% 投诉
- 对话长度：3-6轮
- 涉及业务：账户查询、转账失败、卡片挂失、理财产品咨询
- 每轮对话需包含：说话人角色、时间戳、消息内容

## 输出格式
JSON数组，每条记录包含：
{
  "session_id": "唯一会话ID",
  "channel": "渠道（手机银行/网银/电话/柜面）",
  "sentiment": "用户情绪标签",
  "turns": [
    {"speaker": "user", "timestamp": "ISO时间", "content": "消息"},
    {"speaker": "agent", "timestamp": "ISO时间", "content": "消息"}
  ]
}

2.2 基于GAN/扩散模型的图像数据合成

对于需要图像测试数据的场景（如UI自动化测试中的截图对比、OCR识别测试、人脸识别测试等），GAN（生成对抗网络）和扩散模型是目前最主流的选择。

2.3 基于规则+AI的结构化数据合成

数据库表、API请求体、配置文件等结构化数据的合成，既需要保证字段级别的格式正确，又需要跨字段、跨表的语义一致性。单纯使用规则模板（如Faker库）可以解决格式问题，但难以处理复杂的业务逻辑；而纯LLM生成又可能产生格式错误。因此「规则+AI」的混合方案是最佳实践。

混合方案的分工：

• 规则引擎（确定性层）：字段格式校验、外键引用完整性、唯一性约束、枚举值范围控制。
• AI模型（语义层）：跨字段的业务逻辑推断（如年龄与职业的合理匹配）、异常数据构造、统计分布控制（如控制男女比例、金额分布）。

LLM生成结构化数据示例（银行交易表）：

请生成50条银行借记卡交易记录，写入以下表结构：

CREATE TABLE transactions (
  txn_id VARCHAR(32) PRIMARY KEY,
  card_no VARCHAR(19),
  txn_type VARCHAR(20),   -- 消费/取现/转账/退款
  amount DECIMAL(12,2),
  currency CHAR(3),        -- CNY/USD
  merchant VARCHAR(100),
  txn_time TIMESTAMP,
  status VARCHAR(10)       -- 成功/失败/处理中/已冲正
);

## 生成约束
- amount分布：70% 在 1-500 元，20% 在 500-5000 元，8% 在 5000-50000 元，2% 在 50000 元以上
- 失败交易占比约5%，包含：余额不足、卡片冻结、超限额、网络超时
- 退款交易占比约8%，对应之前的消费交易
- 时间范围：最近90天内，工作时间(9-18点)占比60%
- card_no去敏：前6位+后4位为真实BIN格式，中间用*号替代

以INSERT语句格式输出，并在每条后加注释说明该条数据的测试目的。

2.4 异常数据生成

异常数据是测试数据合集中最容易被忽视但又最关键的部分。AI在生成异常数据方面有天然优势——它可以从海量已知漏洞和错误模式中学习，系统性地构造各种破坏性输入。

AI擅长生成的异常数据类型：

• 边界值攻击：针对数值字段，生成最小值-1、最大值+1、零值、负数、浮点精度溢出等。
• 格式破坏：对日期、邮箱、手机号、身份证号等有格式约束的字段，生成格式错误、长度异常、非法字符的数据。
• 安全攻击Payload：SQL注入（Union/timing/blind）、XSS跨站脚本、命令注入、XXE实体注入、路径遍历等。
• Unicode混淆：同形字符（homoglyph）、从右到左覆盖（RLO）、零宽字符等利用Unicode特性的攻击。
• 并发冲突数据：生成同一时刻对同一资源的多条竞争请求数据，用于测试锁机制和幂等性。

2.5 数据增强：从少量真实数据扩展

当已有少量真实数据样本时，数据增强可以成倍扩展测试数据集。AI增强超越了传统的「复制+扰动」，能够在语义层面进行变换。

常用的增强技术：

• 回译增强（Back Translation）：将中文文本翻译成英文再翻译回中文，产生语义相同但表达不同的变体。
• 同义替换：利用LLM识别和替换文本中的同义表达，保持语义不变。
• 结构变形：对JSON/XML数据，在不改变语义的前提下调整字段顺序、添加可选字段、改变缩进格式。
• 噪声注入：在真实数据中注入可控比例的随机噪声（拼写错误、格式扰动），用于鲁棒性测试。
• 约束性采样：从真实分布中学习，按指定约束条件（如某字段取特定值）进行采样扩展。

3. 数据质量保障

合成数据并非「生成即用」，其质量直接影响测试结果的可信度。以下是合成数据质量保障的核心维度。

3.1 数据真实性评估

合成数据需要在「像真实数据」和「不是真实数据」之间找到平衡——既要足够真实以触发实际业务逻辑，又不能是真实数据的简单复制。

评估维度：

• 字段级真实性：每个字段的值域、格式、长度是否符合业务定义。例如合成身份证号是否符合校验规则，手机号是否属于合法号段。
• 跨字段合理性：字段间的关联关系是否符合业务逻辑。例如年龄与收入的正相关性、职业与交易金额的关联。
• 统计保真度（Statistical Fidelity）：合成数据的字段分布、相关系数矩阵是否与真实数据分布一致（通过KL散度、Wasserstein距离等指标衡量）。

3.2 数据多样性评估

多样性的缺失会导致测试遗漏。好的合成数据应该覆盖真实数据中不常见的「长尾场景」。

• 类别覆盖：枚举字段是否覆盖了所有合法取值组合。
• 数值分布：是否包含极端值、零值、负数等边缘情况。
• 组合多样性：多条记录之间是否存在足够的字段组合差异，避免生成大量雷同数据。
• 时序多样性：时间字段是否合理分布在目标时间范围内，而非集中在某几个时间点。

3.3 数据覆盖度评估

覆盖度评估回答的核心问题是：合成数据集是否提供了足够的「测试弹药」。

3.4 偏差检测

AI模型在训练过程中可能吸收了训练数据的固有偏见，这些偏见可能通过合成数据「悄无声息」地传递到测试环节。偏差检测需要关注的维度包括：

• 人口统计偏差：合成数据中是否存在性别、年龄、地域的不合理倾斜。例如银行交易数据中某性别用户的交易金额系统性偏低。
• 类别不平衡：某些业务类别被过度生成或缺失。例如LLM偏好生成「登录」「查询」类数据，而忽略「销户」「挂失」类。
• 时间模式偏差：合成数据的时间分布与实际业务节律不符。例如周末交易量和工作日无差异。
• 语义偏见：文本合成中，模型可能对特定表述产生倾向性生成。例如将「高风险」与特定地区/职业关联。

3.5 隐私保护

虽然合成数据天然不需要直接使用真实数据，但仍需防范模型「记忆」训练数据导致的隐私泄露风险。

• 差分隐私（Differential Privacy）：在模型训练过程中注入噪声，确保任何单条训练数据对模型输出的影响在数学上可控。这是目前最严谨的隐私保护框架。
• 数据脱敏验证：对已合成数据进行二次扫描，检查是否意外包含真实个人标识（如真实姓名、身份证号、手机号）。
• 成员推理攻击防御：检验攻击者是否能通过合成数据反推某条真实数据是否在训练集中（Membership Inference Attack）。
• 最小数据原则：用于训练合成模型的真实数据量应控制在必要范围内，避免「为了合成1000条数据而使用了100万条真实数据」的本末倒置。

4. 银行业合成数据实践

银行业是测试数据合成需求最强、要求也最高的行业之一。监管合规的高压线、业务数据的敏感性、以及复杂的数据模型，使得银行测试数据合成成为一个极具挑战但也价值巨大的实践领域。

4.1 银行测试数据的特殊要求

4.2 AI生成合规的银行交易数据

银行交易数据的合成需要在「逼真」和「合规」之间取得精妙平衡。以下是经实践验证的合成策略：

• 卡号/BIN码合规：使用AI生成符合银联/各发卡行BIN规则的测试卡号，通过Luhn算法校验，而非使用真实卡号的前N位。
• 交易流水号：按银行编码规则生成，包含机构号、日期、顺序号等结构化组件。
• 会计分录完整性：每笔交易生成对应的借贷分录数据，确保借贷平衡（「有借必有贷，借贷必相等」）。
• 利率计算：生成覆盖不同计息方式（单利/复利、按日/按月/按季）的利率场景数据。

4.3 信贷审批场景的测试数据生成

信贷审批是银行核心业务中最复杂的流程之一，也是测试数据合成价值最高的场景。AI可以系统性生成覆盖各类客户画像和审批路径的测试数据。

• 客户画像合成：生成不同信用评分、收入水平、负债比例、职业类型的客户数据，覆盖通过/拒绝/人工审核的不同审批结果。
• 申请材料模拟：合成贷款申请表、收入证明、征信报告摘要、抵押物评估等文书数据。
• 审批路径遍历：构造能触发不同审批节点（如自动通过、转人工一审、转人工二审、退回补充材料）的数据组合。
• 贷后场景：生成还款计划、逾期催收、展期申请、不良资产处置等贷后全生命周期的测试数据。

4.4 客户信息合成与隐私保护平衡

客户信息是测试中最敏感的数据类型。在银行场景下，AI客户信息合成需要满足以下「既要……又要……」的要求：

• 既要格式正确，又不可追溯真人：身份证号须符合编码规则但不对应任何真实公民；手机号须为合法号段但无法接通。
• 既要覆盖面广，又需符合人口统计：年龄分布需合理（如不能出现20岁拥有百万年薪的默认画像），地域分布需反映实际业务区域。
• 既要保留业务语义，又要切断关联链路：如同一客户在不同系统中的记录需保持一致性（关联），但不能通过数据片段还原出真实个人（保护）。

4.5 与现有数据脱敏流程的结合

目前已有成熟的生产数据脱敏流程，AI合成数据并非要替代它，而是作为有力的补充和增强。

结合策略建议：

• 分工协作：脱敏后的生产数据用于回归测试和性能测试（保证数据量与真实一致）；AI合成数据用于新功能测试和异常场景测试（保证覆盖全面）。
• 脱敏质量验证：用AI生成的数据作为「基准」，验证脱敏流程的有效性——将AI合成数据注入脱敏后数据集，检查是否能被识别为「合成」而非「真实」。如果脱敏流程无法区分合成数据和真实数据，说明脱敏效果良好。
• 脱敏规则增强：利用LLM分析脱敏后的数据是否存在语义级别的关联泄漏（如脱敏后仍可通过消费模式推断个人身份），反馈优化脱敏规则。
• 数据补齐：脱敏后的数据可能因脱敏算法导致某些字段失去业务语义（如姓名全部变为「张*」），AI合成数据可以为这些字段生成语义合理的填充值。

5. 工具链

5.1 主流数据合成工具对比

5.2 提示词模板：生成特定格式的测试数据

以下是几个经过验证的Prompt模板，可直接用于生成常见测试数据类型。使用前请根据具体项目的字段定义和业务规则进行调整。

模板一：数据库Insert语句生成

你是一个数据库测试数据生成器。根据以下表结构生成用于测试的INSERT语句。

## 表结构
[在此粘贴 DDL CREATE TABLE 语句]

## 生成要求
- 生成 [N] 条记录
- 主键/唯一键不能重复
- 外键关联的数据需在对应的父表中存在
- 包含5%的边界值和异常数据（如空字符串、超长字符串、NULL等）
- 金额类字段使用DECIMAL(12,2)精度
- 时间为DDL中定义的合理范围
- 输出格式：纯SQL INSERT语句，每行一条

模板二：API测试报文生成

根据以下OpenAPI/Swagger接口定义，生成接口测试所需的JSON请求报文。

## 接口定义
[在此粘贴 OpenAPI 片段或接口描述]

## 生成场景
1. 成功场景：所有必填字段提供合法值
2. 参数缺失：逐一省略必填字段
3. 参数类型错误：将数字字段传入字符串，字符串传入数字等
4. 参数越界：数值超出范围、字符串超长、枚举值非法
5. 安全场景：在字符串字段中注入SQL/XSS Payload

## 输出格式
```json
[
  {
    "scenario": "场景名称",
    "method": "POST",
    "path": "/api/xxx",
    "headers": {"Content-Type": "application/json"},
    "body": { ... },
    "expected_status": 200,
    "expected_check": "断言描述"
  }
]
```

模板三：压力测试数据批量生成

生成用于性能压测的批量交易数据。数据量：[10万条]，切分为 [10] 个文件。

## 数据规格
- 交易类型分布：70% 查询 / 20% 转账 / 8% 缴费 / 2% 外汇
- 交易金额：符合长尾分布（Pareto分布），大部分为小额，少量大额
- 账户数量：[5000] 个，20%为活跃账户（高频交易），80%为普通账户
- 并发时段：模拟上午9-11点和下午2-4点的交易高峰

## 文件要求
- CSV格式，UTF-8 with BOM
- 每个文件1万条
- 不同文件之间的账户可以复用（模拟同一账户的多次交易）

6. 常见坑点

基于行业实践总结，以下是AI测试数据合成中最常见的陷阱及其应对策略。

6.1 合成数据偏见转移到被测系统

AI合成数据中如果存在系统性偏见，这些偏见会通过测试过程「传染」给被测系统的评估体系。

• 现象：用性别/地域有偏的客户数据测试信贷审批系统，测试报告可能显示「某类客户审批通过率更低」，但这是数据偏见而非系统问题。
• 对策：在数据生成环节引入公平性约束；在质量评估环节增加偏差检测checkpoint；对敏感的决策类测试使用「盲测」方案——让审核者不知道数据的生成来源。

6.2 过拟合到真实数据分布

AI模型可能过度记忆训练数据的特定模式，导致合成数据缺乏泛化性。

• 现象：合成数据在统计层面与真实数据几乎完全一致，但实际上只是训练数据的「轻微扰动版」，没有增加新的测试价值。
• 对策：使用Hold-out验证集检测过拟合（如果合成数据在验证集上的表现显著差于训练集，说明存在过拟合）；在生成时注入「可控扰动」增加多样性；定期更换合成模型的训练数据来源。

6.3 数据一致性问题

跨表、跨系统的关联数据一致性是合成数据最大的工程挑战之一。

• 现象：核心交易表中引用的账户ID在账户主表中不存在；贷款申请表中的客户信息与客户主表不一致；会计分录表中借贷不平衡。
• 对策：
  • 优先生成主表数据，再以主表的键值为约束生成从表数据（「自上而下」的生成顺序）。
  • 在Prompt中明确声明外键依赖关系和引用范围。
  • 生成后运行一致性校验脚本（如外键存在性检查、借贷平衡检查、流水号连续性检查）。
  • 对复杂的数据模型，使用有向无环图（DAG）描述表间依赖，按拓扑序生成。

6.4 评估数据质量的难度

「合成数据质量好」本身就是一条难以量化的评估准则。实践中常见以下评估误区：

• 只看统计不看语义：字段分布与真实数据一致，但字段组合语义不合理（如「年龄80岁，职业程序员」）。
• 只跑程序不跑业务：数据通过了格式校验和引用完整性检查，但在实际业务流程中走不通（如生成了一个「已销户」状态的账户进行转账操作）。
• 只看样子不看价值：数据「看起来像真的」，但并未提供新的测试覆盖（所有合成的交易都是10元转账，没有触达风控阈值）。

应对策略：

• 建立「数据质量看板」：格式正确率、引用完整率、业务可执行率、新增覆盖率四个维度可视化。
• 引入「业务穿越测试」：将合成数据实际输入业务流程（自动化脚本或人工走查），统计成功率。
• 结合测试用例评审：将合成数据与测试用例一起评审，确保数据能支撑用例所描述的场景。

6.5 坑点速查表

🛠️ 实战演练

以下三个实战任务覆盖测试数据合成的核心场景，建议按顺序完成。每个任务均提供完整的场景背景、操作步骤和评估标准。