AI生成测试数据翻车后，我改用Faker脚本

开发新用户资料 API 时，测试数据的准备成了拦路虎。我们需要的是真实、多样且充满边界情况的数据，而不是千篇一律的 john.doe@example.com 和 password123。作为 2026 年的开发者，第一反应自然是让 AI 来搞定——结果却陷入了一场长达 15 小时的拉锯战。

AI 生成测试数据的三个坑

起初的提示词很直接：“生成 20 个社交媒体用户 JSON 资料，包含多样的姓名、邮箱、简介和粉丝数。”返回的 JSON 格式完全正确，但内容寡淡得令人失望：简介全是通用句式，粉丝数集中在几百，邮箱清一色是 firstname.lastname@example.com。这种“过于完美”的数据对寻找真实 bug 毫无帮助。

当我把要求细化到边界情况时，问题变得更棘手。AI 要么重复（每个缺失邮箱都是 "email": null，每个长简介都是同一段复制粘贴），要么类型不一致（is_verified 本应是布尔值，却返回字符串 "true"，导致 API 校验直接报错），要么抓不住重点（“无效邮箱”只给出 "notanemail"，而不是 user@domain@domain.com 这种能绕过简单正则却会在更严格校验中失败的样本）。

据原文作者描述，他花了整整 15 个小时，横跨三天，主要在反复调整 ChatGPT 4.0 的提示词，试图让 AI 理解“边界情况”的细微之处。结果就像在和一个非常礼貌、非常字面化的机器人搏斗——输出格式无可挑剔，但就是不符合特定需求。

破局思路：AI 当顾问，Faker 干活

转机来自一个认知转变：不要指望 AI 直接生成数据，而是让它帮你定义问题。AI 擅长理解 schema 和发散思维，但在生成真正随机、刻意损坏或高度特定的数据方面，它并不是一个完美的直接生成器。

第一步：让 AI 头脑风暴边界情况

作者给 ChatGPT 提供了 API 的基本 schema，然后要求：“列出 15 个不同的边界情况用于测试。对每种情况，描述场景并指出哪些字段会异常或错误，说明原因。要具体到数据类型或预期值。”

这一步效果显著。AI 给出了高质量的描述，例如：“姓名包含国际字符：name 字段包含非 ASCII 字符如 'Björn'、'你好'。”或“好友列表为空数组：friends 字段是 [] 而非 null 或填充数组。”这些描述构成了一份清晰的测试路线图。

边界情况（edge case）测试是软件质量保障中的核心方法之一，指专门针对输入域的极端值、临界值或异常组合设计测试用例。对于 JSON 用户资料这类结构化数据，典型边界包括：字段缺失或为 null、类型错误（如布尔字段传入字符串）、长度超限（超长字符串或空数组）、特殊字符（Unicode、emoji、控制字符）、格式畸形（邮箱、日期、UUID 的非法变体）以及逻辑矛盾（如 is_verified 为 true 但 email 无效）。边界测试的目标不是验证正常路径，而是探测系统在“非预期但可能发生”的输入下是否仍能正确报错、降级或拒绝，从而避免线上出现静默失败或安全漏洞。

第二步：用 Faker 精确实现

拿到 AI 的建议后，作者用 Python 的 Faker 库（版本 18.10.1）编写脚本。思路是先通过 Faker 生成真实的基础数据，再根据 AI 描述的边界情况，程序化地覆盖特定字段。

例如，生成无效邮箱时，脚本会先让 Faker 生成一个有效邮箱，然后将其变形为 foo@bar 或 user@@domain.com 这类“更恶劣”的样本。长简介则用 faker.paragraph(nb_sentences=15) 生成。核心代码结构如下：

from faker import Faker
import random

faker = Faker()

def generate_base_profile():
    return {
        "id": faker.uuid4(),
        "name": faker.name(),
        "email": faker.email(),
        "bio": faker.paragraph(nb_sentences=3),
        "followers_count": random.randint(0, 100000),
        "is_verified": faker.boolean(),
        "privacy_level": random.choice(["public", "private", "friends_only"]),
        "last_login_at": faker.iso8601(),
        "tags": faker.words(nb=random.randint(0, 5))
    }

def generate_invalid_email_profile():
    profile = generate_base_profile()
    profile["email"] = faker.word() + "@" + faker.word()
    if random.random() < 0.5:
        profile["email"] = faker.word() + "@@" + faker.domain_name()
    return profile

def generate_long_bio_profile():
    profile = generate_base_profile()
    profile["bio"] = faker.paragraph(nb_sentences=15, variable_nb_sentences=True)
    return profile

最终，约 150 行的脚本成了主力工具。作者可以混合搭配不同函数，确保“好”数据和“坏”数据真正随机分布，底层结构始终正确——而这正是 AI 从零生成时难以保证的。

Faker 是一个 Python 第三方库，专门用于生成看起来逼真的假数据，涵盖姓名、地址、邮箱、电话、日期、文本段落等数十种数据类型。它的核心价值在于“可控的随机性”：每次调用返回的值都不同，但格式始终符合现实世界的约定（如邮箱带 @ 和域名、日期为 ISO 8601 格式）。与 AI 生成不同，Faker 的输出不会出现字段类型漂移，开发者可以精确指定生成规则（如 nb_sentences=15 控制段落长度），并支持通过 seed 固定随机种子以复现结果。在测试数据场景中，Faker 能稳定产出大量结构正确的基础样本，再配合少量程序化覆盖即可构造出多样化的边界数据，这是它比“反复提示 AI”更可靠的根本原因。

核心启示：把 AI 当咨询师，而非编码员

这个案例的价值不在于“AI 不行”，而在于分工的错位。AI 在头脑风暴、大纲梳理甚至代码片段生成上表现出色，但在需要精确控制、程序化校验的测试数据生成场景中，它更适合扮演顾问角色：定义问题、提出方案，然后由传统编码工具（如 Faker）以精确可控的方式实现。

这种组合策略不仅省去了手动构造数百个 JSON 对象的麻烦，还获得了比单纯“反复提示”更健壮的测试覆盖率。对任何需要为 API 构建复杂测试数据集的团队来说，这都是一条值得复用的路径：让 AI 告诉你该测什么，让脚本决定怎么造。