用 AI 写测试用例：把需求拆成能跑的自动化测试
测试的本质是"翻译需求"
一个功能需求写的是"用户输错密码三次锁定"。落到测试上，得拆成：输错一次怎样、两次怎样、三次怎样、第四次是不是真锁了、锁多久、管理员能解锁吗。这种"把一句话拆成 N 个可验证状态"的活，AI 很在行。
我一般先给 AI 原始需求，让它列"正常路径 / 边界 / 异常"三类的测试点，确认覆盖全了，再让它写具体断言。先定清单再写代码，比直接让它吐测试稳，不容易漏掉关键分支。
给它看真实的代码接口
用例要能跑，前提是调对函数、传对参数。所以我把被测函数的签名和现有测试文件一起贴给它，让它沿用项目里已有的测试框架和写法，不要自己发明一套风格。
比如项目用 pytest，我就说"用 pytest 写，沿用 conftest 里的 fixture，不要引入新依赖"。它产出的代码我几乎不用改结构，直接能进仓库。风格统一这事儿看着小，但团队里最烦测试文件各写各的。
让用例带说明，别只写断言
我要求每条用例上方用注释写清：测的是什么场景、预期是什么。半年后有人改逻辑，对着注释就知道这条测试当初防的是啥，不会随手删掉。断言本身看不出"为什么防这个"，注释补上意图才完整。
另外让 AI 同时产出"测试数据怎么造"。很多测试挂掉不是逻辑错，是前置数据没准备好。让它把 arrange 步骤写清楚，比光给一个 assert 实用得多。数据构造对了，测试才真能反映行为，不然测的就是一组凑巧能过的假数据。
它写的，你得补三类
AI 容易漏的是：第一，并发和竞态，它默认按单线程想；第二，特别大的输入、特别长的字符串这种压力边界；第三，和别的模块串起来时的集成问题，它通常只看单个函数。
所以 AI 出的用例我当"基础盘"，自己再补并发、性能、集成三块。基础盘能挡住大部分回归，补的这三块挡住最容易线上翻车的那部分。这部分偷不得懒，因为恰恰是它想不到的地方最容易出事，一旦漏了就是线上故障。
跑起来才算数
最后一步最关键：让 AI 写的用例真的在 CI 里跑一遍，看通过率。挂了的我不是马上改测试，而是先看是测试写错了还是代码真有 bug——后者才是金子。
我还会让 AI 顺着失败用例反推：如果它写的测试暴露了真实缺陷，让它顺手给个修复建议，我审过再改。用下来感受是，AI 把"从需求到第一版用例"的时间压缩了六七成，而且它列的边界用例，经常比我拍脑袋想的更全。
把它当起点，不是终点
说清楚一个心态：AI 出的用例是草图，不是成品。你拿到的是"可能已经覆盖六七成"的第一版，剩下的靠你补边界、补集成。省下的时间，正好拿去想那些它想不到的极端情况。
测试这活，人定方向、AI 填砖，配合最顺。别指望一键出完美测试，但一键出能跑的底子，已经值回票价。把它接进 CI，每次改完代码自动跑，才是它真正的价值落点。
