上个月给一个订单模块加幂等校验逻辑本身不复杂——同一个业务单号在 30 秒内的重复请求只处理第一次。但写到测试用例的时候卡住了正常路径的用例几分钟就列完了边界条件却总觉得漏了什么。补偿失败的场景要不要测并发同时到达但时间戳差几毫秒的情况怎么设计用例Redis 锁超时后的回滚路径该不该覆盖手头的测试用例评审还差两天我决定先让 AI 帮忙把边界条件补一轮自己再做筛选和验证。试了三个模型输出差异比我预想的大得多。为什么同一个任务不同模型给出的答案差这么多我把同一份接口文档和已有的正常路径用例喂给三个模型要求输出“补充的边界条件测试用例格式为表格”。结果是三份风格完全不同的产出。DeepSeek的用例最贴近实际工程场景。它补了 11 条边界用例其中有一条是“Redis 锁写入成功后业务处理超时锁自动过期第二个请求进入——此时幂等键对应的业务状态为处理中”。这个场景我原来确实没想到但线上出过类似的问题。它的中文表达也自然没有明显的直译感。ChatGPT给的用例结构更工整表格里每列的颗粒度很细前置条件、输入参数、预期结果分得很清楚。但它编了一条“验证幂等键过期后再次请求时数据库自增 ID 回退”的用例——这个模块根本没有用数据库自增 ID显然是模型在“合理推断”时假设了实现细节。这就是典型的 API 幻觉它不知道你具体怎么实现的就会用训练数据里的常见模式来补。Claude的覆盖面最广给了 18 条用例包括并发场景、网络超时、数据库死锁回滚等。但有几条用例的前提条件和我们的技术栈不一致比如它假设了分布式锁用的是 ZooKeeper而我们实际用的是 Redis 单实例。这 18 条里真正能直接用的大概 12 条剩下的要么改前置条件要么标记为不适用。三者放在一起看DeepSeek 更适合中文环境下的工程实践补充ChatGPT 擅长结构化输出但要防幻觉Claude 覆盖广但需要人工过滤技术栈不匹配的部分。没有一个模型能“拿来就用”但三者交叉验证后遗漏的边界条件确实少了很多。Prompt 怎么写才能让模型输出可用的测试用例第一轮我用的 Prompt 很随意“帮我补充这个接口的测试用例重点是边界条件”。三个模型的输出都偏通用没什么针对性。第二轮调整后我用的 Prompt 如下角色你是一个有 5 年经验的测试开发工程师熟悉 Java 后端系统和幂等设计方案。 背景一个订单服务的幂等校验接口基于 Redis 实现幂等锁锁过期时间 30 秒。 输入材料 - 接口路径POST /api/order/submit - 请求参数orderId业务单号、userId、amount、timestamp - 幂等逻辑同一 orderId 在 30 秒内只处理第一次请求后续返回“处理中” - 异常处理Redis 不可用时降级为数据库唯一索引兜底 任务补充边界条件测试用例重点关注以下场景 - 并发场景时间差小于 10ms 的重复请求 - Redis 锁超时场景 - 降级路径Redis 不可用时的行为 - 补偿逻辑业务处理失败后的幂等状态回滚 输出格式Markdown 表格列包括“用例编号|场景分类|前置条件|输入参数|预期结果|优先级” 限制条件 - 不要假设数据库使用自增 ID - 不要引入文档中未提到的中间件 - 如果某个场景缺少信息无法设计用例标注“信息不足无法设计” 验证要求每条用例的预期结果必须可以直接用接口返回码或数据库状态来验证不能写“系统行为正常”这类模糊描述。这个 Prompt 里真正起作用的约束有四个一是技术栈限制明确说了“不要假设数据库使用自增 ID”直接堵住了 ChatGPT 上次编造的那类错误。二是降级路径指定说明 Redis 不可用时的兜底方案让模型在有边界条件约束的情况下做推断而不是凭空猜。三是输出可验证性要求强制预期结果必须是可观测的返回码或数据库状态杜绝“行为正常”这种没法测试的描述。四是信息不足时的处理方式要求模型诚实标注“信息不足”而不是硬编。模型的输出怎么验证测试用例这类产出有个特点看起来都对不代表能直接用。我的验证流程是这样第一步技术栈一致性检查。逐条看用例的前置条件把提到文档中没有的中间件、API、数据库特性的条目挑出来。ChatGPT 那批里有 3 条因为这个问题直接打了回去。第二步可执行性核对。预期结果是否可以直接用接口返回码验证是否涉及需要 mock 的外部依赖如果有需要 mock 的场景确认 mock 的成本是否值得。Claude 有一条用例需要模拟 Redis 在写入后的第 29 秒刚好挂掉这个在本地环境基本没法精准构造标记为“暂不纳入本次测试范围”。第三步用另一个模型做反向检查。把筛选后的用例和原始接口文档一起发给 DeepSeek要求它“找出这些测试用例中可能遗漏的场景”。它补了 2 条其中一条是关于降级路径的恢复场景——Redis 恢复后新的请求应该重新走幂等锁逻辑而不是继续走数据库唯一索引。这条确实之前漏了。第四步人工终审。最后把用例表交给模块负责人过一遍确认业务逻辑没有理解偏差。这一步花的时间最少因为前面的筛选已经把大部分明显问题剔掉了。四个步骤走下来从 18 11 15 条原始产出中最终保留了 16 条可用的边界用例另外有 4 条修改前置条件后可用5 条直接排除。这个筛选比例大概 50%比直接手写节省了时间但绝不是“交钥匙”级别的自动化。多模型交叉验证的意义在哪做完这轮之后我的判断是单一模型出测试用例的风险在于你不知道它漏了什么。而用两个以上模型做同一任务差异点往往就是值得人工细看的地方。三个模型的差异集中在这几类对实现细节的假设不同ChatGPT 假设了自增 IDClaude 假设了 ZK对场景优先级的判断不同DeepSeek 倾向高频真实场景Claude 倾向理论上的全覆盖对降级路径的关注程度不同DeepSeek 和 Claude 都提了降级ChatGPT 只提了一条中文表达的可用性不同DeepSeek 和 ChatGPT 可以Claude 偶有直译腔差异最大的那几个点恰恰是最需要人工介入的地方。如果只用了一个模型这些差异你根本看不到。代码示例用例格式校验脚本模型输出的表格格式不一定规范有时多一列少一列或者分隔符没对齐。我写了个简单的 Python 脚本做基础校验避免人工检查格式的低效import re def validate_testcase_table(md_table): 检查测试用例 Markdown 表格的列数和必填字段 lines [l.strip() for l in md_table.split(\n) if | in l] if len(lines) 2: return False, 表格为空或行数不足 # 去掉分隔行 data_lines [l for l in lines if not re.match(r^\|[\s\-:]\|$, l)] if not data_lines: return False, 无数据行 # 校验列数一致性 col_counts [len(l.split(|)) - 2 for l in data_lines] if len(set(col_counts)) 1: return False, f列数不一致: {set(col_counts)} # 校验必填列预期结果列不能为空 for i, line in enumerate(data_lines[1:], start2): # 跳过表头 cells [c.strip() for c in line.split(|)[1:-1]] # 假设预期结果在倒数第二列 if len(cells) 2 and not cells[-2]: return False, f第{i}行预期结果列为空 return True, 格式校验通过 # 示例模型输出的表格粘贴到这里 test_table | 用例编号 | 场景分类 | 前置条件 | 输入参数 | 预期结果 | 优先级 | |----------|----------|----------|----------|----------|--------| | TC-001 | 正常幂等 | Redis正常 | orderIdA001 | 返回200 | P1 | ok, msg validate_testcase_table(test_table) print(f校验结果: {msg})这类脚本逻辑简单、边界清晰交给 AI 生成后跑一遍就能确认属于低风险可信任任务。但即便如此生成后我也会在本地跑一次确认能正常执行。风险边界哪些信息不能给模型测试用例设计涉及接口定义、业务逻辑和异常处理路径这些信息传给模型前必须做脱敏接口路径和参数名保留但真实域名、内网 IP、Token 全部替换业务单号的生成规则不要暴露用模拟格式代替不要贴完整的配置文件和数据库连接信息公司内部的系统架构、部署拓扑、容量数据不能给模型的输出中如果出现了“看起来合理但你没提到过的实现细节”那就是编造的必须删掉或验证后再用还有一个容易忽略的点如果你用模型交叉验证不要把 A 模型的输出原封不动地喂给 B 模型并要求“找出 A 的问题”。这样 B 模型会受 A 的影响相当于两个裁判共享了信息。正确的做法是先让两个模型独立输出再做人工对比。常见误区QAI 生成的测试用例能直接写入测试计划吗不能。需要经过技术栈一致性检查、可执行性核对和人工终审。模型可能编造不存在的 API、假设你用某个特定中间件、或者漏掉业务特有的边界场景。Q一个模型出用例够用吗不够稳。单一模型你不知道它漏了什么。用两个模型独立生成差异点往往就是需要人工重点看的地方。Q怎么避免模型编造 API 和中间件在 Prompt 里明确列出你实际使用的技术栈并加入限制条件“不要引入未在输入材料中提到的中间件或 API”。如果仍然出现编造说明模型在这个领域容易过度推断换一个模型试试。Q技术文档和接口说明能直接发给 AI 吗需要脱敏后再给。IP、域名、Token、密钥、业务数据格式中的敏感信息都要替换内部架构细节也建议抽象化处理。Q多模型交叉验证是不是哪个模型的结果最全就用哪个不是。模型输出一致不代表正确输出冲突也不代表有一个错了。交叉验证的价值是帮你定位需要人工判断的差异点最终决策权在人手里。总结这次用 AI 辅助测试用例设计的经验可以总结成一条把模型当成“边界条件的补充者”而不是“测试方案的起草人”。从最小切口入手——选一个接口整理好正常路径用例和技术栈说明用约束清晰的 Prompt 让模型专注补充边界条件。输出后走一套固定的验证流程技术栈一致性检查、可执行性核对、多模型交叉验证、人工终审。选模型时别想着找一个“全能的”DeepSeek 做中文工程场景的边界补充最实用ChatGPT 做结构化输出但要警惕幻觉Claude 覆盖面广但需要过滤技术栈不匹配的部分。三个模型独立生成后做交叉对比差异最大的地方就是最值得人工细看的地方。所有涉及公司代码、接口、架构的信息都要脱敏模型输出只是候选不是结论。人工判断和安全边界不是限制 AI 的使用而是让 AI 真正融入研发流程的前提。