做测试这行最烦的事情之一就是评审测试用例。我一度以为“评审”两个字天生自带催泪效果直到我真的把一堆密密麻麻的用例表格扔给LLM去查一致性才发现原来崩溃也可以很安静——机器不哭但它会一条一条列出你写过的所有自相矛盾。先说背景。我所在的团队维护着一个中等规模的项目光核心模块就有上千条测试用例分散在十几个Excel文档里。以前每次发版前评审会基本就是修罗场A同学写的前置条件是“用户已登录”B同学在后续用例里把同一个场景写成“游客状态”C同学用例第一步说“点击保存按钮”预期结果却写着“页面跳转到首页”最离谱的一次同一个接口在两条用例里对同一参数的取值居然完全相反愣是没人发现。人工评审的问题不是态度而是大脑在处理“跨文档、跨人员、大量细节比对”这种任务时天然会选择性失明。所以我开始琢磨能不能让LLM来做这件事。这篇文章不是科普文也不是什么团队管理鸡汤就是一个完整的实操记录怎么拆解一致性问题怎么设计审查流程怎么写Prompt才能让LLM稳定输出以及踩过的各种坑。适合手里有大量测试用例、打算引入AI辅助评审的测试工程师、测试开发、技术负责人参考。1. 先搞清楚一件事测试用例一致性到底指什么很多人一听“一致性”就以为只是“格式统一、命名规范”真拿去让LLM检查LLM回了一堆“建议使用英文命名”“建议统一缩进”之类不痛不痒的话搞得人很失望。原因很简单需求描述得太模糊模型只能往通用方向上猜。我在动手之前先把“一致性”拆成了五个可执行的维度每个维度有明确的判断标准。1.1 用例内部的自洽性一条用例内部前置条件、操作步骤、测试数据、预期结果之间不能互相矛盾。举个例子前置条件写着“用户未登录”步骤却是“点击个人中心的订单列表”预期结果还写“正确展示订单数据”——这就明显不自洽因为未登录状态下根本进不了个人中心。这类问题人工评审时最容易漏因为人会默认“大概能猜到作者想测什么”但LLM不会它只会机械比对语义冲突。1.2 用例之间的互斥与冲突不同用例之间的前置条件、输入数据、预期行为不能互相打架。最常见的场景就是共享接口参数一条用例说该字段传空字符串会返回“参数错误”另一条用例却说传空字符串会“静默忽略并返回成功”。这两条用例不可能同时正确至少有一条写错了或者写模糊了。跨用例冲突是人工评审的重灾区因为需要记住A文档第3节的内容才能发现B文档第7节的问题。1.3 与需求文档的覆盖一致性每条用例都应该能在需求里找到对应依据。我要求LLM判断一条用例时会同时把该模块的需求条目也喂给它让它检查用例的输入条件、业务规则是否和需求描述一致需求里明确写了的规则用例里不能绕开或者反着写。这个维度有点像“需求追踪”但粒度更细不只查“有没有覆盖”还查“描述是否一致”。1.4 数据和口径的一致性测试数据里经常出现魔法值比如“用户等级为6能享受85折”另一条用例写“用户等级为6享受9折”比如“优惠券有效期30天”另一条用例把有效期写成“3天”。这些数据的冲突往往不是业务逻辑问题纯粹是复制粘贴时改漏了但影响很恶劣因为用错数据跑出来的结果没人敢信。1.5 表达规范的一致性这是最表层的一层同样的操作不能用“点击”“单击”“点一下”混着写同样的页面名称不能一会儿“登录页”一会儿“登录页面”预期结果里必须包含明确的断言标准不能只写“正常”。我的经验是LLM在前四个维度上的表现要明显好于第五个维度因为前四个属于语义矛盾大模型天然擅长第五个属于风格规范反而需要靠few-shot示例来约束。所以如果你要自动审查优先盯住前四个维度别把重点放在格式美不美上。2. 整体方案设计不是把文档扔给ChatGPT就行我最早也试过“暴力法”把整个Excel的内容复制粘贴给LLM让它直接给意见。结果惨不忍睹——上下文被塞爆模型开始胡言乱语输出了一大堆“部分用例存在潜在问题”这种正确的废话甚至还会因为中间截断而漏掉后半部分的关键用例。后来我重新设计了方案思路总结成一句话别让LLM当阅读者让它当审查员。阅读者需要记住全文审查员只需要拿着被拆出来的具体对象对照明确的规则去挑毛病。2.1 先梳理流程再谈技术整个自动化评审流程分四步解析读取测试用例文档Excel、Word、JSON格式均可按用例拆分出“编号、模块、前置条件、操作步骤、测试数据、预期结果、优先级”等结构化字段。分组按模块、接口或业务场景把用例分组组内用例控制在可比较的范围内避免一次塞太多导致LLM上下文溢出。调LLM审查对每一组用例调用LLM执行多个审查子任务自洽性、跨用例冲突、需求一致性等每个子任务返回结构化结果。汇总与复核把LLM返回的问题列表汇总成报告按严重级别排序再路由给人复核。这里面最关键的设计决策是审查单元是“用例组”而不是“全部用例”。因为LLM的注意力是有上限的塞1000条用例进去它连前面写了什么都会忘。每个用例组控制在20-50条之间既可以做组内互查又能保证单次调用的信息密度。2.2 为什么用“分而治之”而不是“一次问完”有人可能会说那跨组的一致性不就没法查了吗我一开始也担心这个问题实际跑了几个版本后发现跨组冲突的根源通常是公共业务规则被不同的人写歪了而这类规则一定会在每个组的用例里反复出现。只要我在审查时把该模块的“公共规则摘要”作为上下文附加在每一组里LLM就能在组内识别出“这组的写法是否偏离了规则”跨组冲突实际上被提前消解了。2.3 Prompt设计的两种模式我给LLM设计了两类审查Prompt单条用例审查自洽性输入一条用例的完整字段输出“通过/不通过具体问题问题类型建议修改方向”。多条例交叉审查一致性输入同模块的一组用例 公共规则摘要输出“冲突用例编号对冲突原因涉及的数据/步骤差异”。这样做的好处是单条审查可以大量并发多条例审查的调用频率较低但每次信息量大。我在实际部署时把单条审查按并发跑多条例审查用一个消息队列串行排队整体吞吐完全够一个中型团队使用。3. 核心实现Llama也没那么玄关键在Prompt和结构化输出我知道很多人想看代码。这个环节我给出一个精简但可直接改造的Python调用示例以及设计Prompt时的几个关键细节。3.1 环境与依赖准备我用的LLM服务是某大厂开放平台的API模型版本是当前主流的对话模型。如果你有自己的私有化部署或者用其他家的开源模型API整体思路一样只需要改endpoint和认证方式。import json import pandas as pd import openai # 该SDK兼容多数兼容OpenAI接口格式的服务 client openai.OpenAI( api_keyyour-llm-api-key, base_urlhttps://your-llm-endpoint/v1 ) def llm_review(prompt: str, temperature: float 0.1) - str: resp client.chat.completions.create( modelllm-model-name, messages[ {role: system, content: 你是资深的软件测试评审专家擅长发现测试用例中的逻辑矛盾和规范偏差。}, {role: user, content: prompt} ], temperaturetemperature, max_tokens2000, ) return resp.choices[0].message.content细节说明这里的temperature务必调低我用的是0.1甚至0。审查任务的输出需要高确定性不需要模型发挥创造性。如果模型回答飘忽先怀疑temperature太高而不是怀疑模型笨。3.2 单条用例自洽性审查Prompt这个Prompt我前前后后改了六版最终稳定在下面这个结构。核心是给规则给负面例子给输出格式。你是一名测试用例评审专家。下面是一条待审查的测试用例。请检查该用例是否存在“内部自相矛盾”的问题。 判断规则 1. 前置条件中描述的系统/用户状态是否与操作步骤中的实际操作对象冲突 2. 操作步骤中的每个动作是否能在“当前前置条件下”被执行 3. 预期结果是否与操作步骤指向的行为一致例如步骤是“提交空表单”预期不能是“成功进入下一页”。 4. 测试数据中的枚举值、边界值是否与业务规则冲突 如果存在矛盾请以JSON格式输出 { pass: false, issue_type: self_conflict | data_conflict | precond_conflict | expectation_conflict, problem: 一句话描述问题, suggest: 给出具体修改建议 } 如果不存在矛盾输出 { pass: true } 测试用例内容 编号TC-1001 模块订单结算 前置条件用户已登录且购物车中有2件商品 步骤 1. 进入结算页 2. 选择优惠券满100减20 3. 提交订单 测试数据购物车金额合计80元 预期结果订单提交成功实付60元这条用例是我故意放的陷阱满100减20的优惠券但购物车金额只有80元根本不满足使用门槛预期结果却按优惠后金额算。如果模型输出pass说明规则解析没生效实际跑下来所有主流模型都能识别这个问题说明只要规则说清楚LLM在“数据与规则冲突”上相当可靠。再强调一个技巧负面示例比正面示例重要。我在第一个版本只给了判断规则没有给示例模型输出的问题五花八门还喜欢提“建议补充冒烟测试”之类的无关建议。加了负面示例后输出立刻收敛到了我想要的问题类型上。3.3 多条例交叉一致性审查Prompt对于一组用例我把它拼接后交给LLM并且在开头给出“公共业务规则”作为参照系。def build_cross_review_prompt(cases: list, rules: str) - str: case_list \n.join( [ f用例编号{c[id]}\n前置条件{c.get(precond, )}\n步骤{c.get(steps, )}\n预期结果{c.get(expected, )}\n for c in cases ] ) return f 你是测试用例一致性审查专家。下面给出同一个模块的多条测试用例以及该模块的公共业务规则。 公共业务规则 {rules} 测试用例列表 {case_list} 请重点检查 1. 在不同用例中同一接口/同一业务场景的前置条件、输入数据是否一致 2. 是否存在两条用例对同一参数的预期结果互相矛盾 3. 是否存在两条用例的前置条件互斥例如一条要求“已登录”另一条要求“未登录”且它们测的是同一场景。 4. 不同用例对同一按钮/页面元素的命名是否保持一致如果不一致列出具体差异。 只输出确定存在的冲突不要输出猜测。对每处冲突输出 {{ conflict_cases: [TC-1001, TC-1002], conflict_reason: 具体冲突内容描述, suggest: 建议修改用例编号及修改方向 }} 注意这里有一个微妙的用语“只输出确定存在的冲突”。如果不加这句话LLM会把“看起来有点像”的问题也罗列出来误报率飙升。加了之后虽然会漏掉一些边缘case但保住精确率更重要——人工复核最怕的就是狼来了。3.4 审查结果落库与分级LLM返回的JSON不能直接当作“权威结论”我把结果按严重级别分了三档P0必须修改。两条用例对同一行为给出相反预期或前置条件与步骤明显互斥。P1建议修改。数据口径不一致、命名不统一、缺少状态描述。P2仅记录。LLM发现“可疑但不完全确定”的问题信息等待人工确认。这个分级很重要。如果不分级LLM一次性抛出的50个问题会让人彻底不想看分级之后评审人先看P0再看P1心里有数很多。同时对P0问题我要求LLM必须给出“冲突双方用例编号”方便人工直接跳转。4. 避坑实录我被LLM坑过的几个经典瞬间这一part最干货。我踩过的坑很多是看官方文档看不出来的必须真实跑一遍才会遇到。4.1 幻觉式问题凭空捏造不存在的冲突第一次全量跑完我拿到报告发现LLM把两条用例标记为“预期结果互相矛盾”。我打开原文一看两条用例预期结果几乎一模一样只是措辞不同。模型把“订单提交成功”和“提交订单成功”当成两个不同结果了纯属幻觉。排查后确认问题出在Prompt里没有明确“语义等价而措辞不同不算冲突”。修正方法是在规则里补了一句如果两条用例的预期结果在语义上等价例如“订单提交成功”与“提交订单成功”则不算冲突。加完之后这类误报立刻下降。这个坑给到的教训是LLM对“文字差异”极其敏感会放大措辞层面的不同到逻辑层面对立必须提前打预防针。4.2 Prompt被用例“反向带偏”也有过一次非常有意思的失败。当时我用了一条“很差劲”的用例作为few-shot示例放在Prompt里示例本身存在一个隐含问题结果模型学着示例的语气开始把更多正常用例也挑出“问题”来。后来我才意识到模型会把few-shot示例当成“潜在问题密度”的参考——示例里头有3处问题它就会倾向于每条用例都要挑出3处问题来迎合这个“预设”。解决办法few-shot示例必须严格使用“通过”和“不通过”各一条并且“不通过”的示例要干净利落不要在一个例子里堆多个问题。给模型一个“正常用例应该大多数通过”的基线它就不会神经质地到处挑刺。4.3 上下文被无用信息占满Excel解析出来之后字段很多我一开始图省事把“创建人”“创建时间”“最近执行结果”这些元字段也一起喂给LLM结果token消耗暴增而且这些字段本身还会干扰判断——模型看到“最近执行结果失败”就开始脑补这条用例有问题实际上人家只是环境挂了。后来我做了解析字段白名单只保留用例编号、模块、前置条件、操作步骤、测试数据、预期结果、优先级、关联需求编号这八个字段。token成本直接降了四成误报率也降了。4.4 并发与限流的坑单个用例审查是纯CPU密集型等待我一开始用了线程池并发调用结果一口气发太多被API限流一批任务全部失败。后来加上信号量控制并发在8以内并且对每个调用做指数退避重试基本稳定。import threading import time sem threading.Semaphore(8) def bounded_review(prompt: str): with sem: for attempt in range(3): try: return llm_review(prompt) except Exception as e: time.sleep(2 ** attempt) return None这个改动很小但对跑批场景是救命级别的。建议所有准备批量调LLM的同学都提前写好重试不要等到线上跑崩了再补。4.5 结果复核机制千万别让机器直接下结论我见过一些团队把AI审查结果直接抄送给业务负责人这是非常危险的做法。LLM的审查结果是“建议”不是“事实”。哪怕它标注了P0也要有人去看一眼原用例。我在系统里加了一个规则P0问题必须由人工二次确认后才能进入缺陷单流转。这个“人机复核点”是整套流程的信任基石去掉它整个项目迟早要翻车。5. 实际效果与评估“看起来好用”不算数我想重点讲一讲投入产出比和怎么证明这套东西真的有用。5.1 一组真实跑批数据拿我们某个核心模块做试点共1226条用例分成52个用例组。跑一轮完整审查的耗时约40分钟包含并发限制和网络延迟调用约500次LLM接口总token消耗折算成本在可接受范围内。人工复核后最终确认的有效问题有87个。按问题的原始来源拆解用例内部自相矛盾21处这是以前人工评审几乎发现不了的因为没人会一条用例反复读三遍。跨用例数据冲突33处大多数集中在优惠规则、用户状态、权限配置这几类公共数据上。需求规则与用例不一致19处这些是需求变更后用例没同步更新的漏网之鱼。命名/格式不统一14处这类价值最低但胜在数量稳定。对比上一轮全靠人工评审的记录同一个模块团队当时只找出了12个问题。不是说我们的人工评审真的那么糟糕而是人工处理跨用例比对的场景本身就难以扩展——10条用例人脑还能两两比较1200条用例靠人眼对比就是不现实。5.2 准确率与漏报率怎么评估我们用了一套简单的双层评估法第一层从1226条里随机抽取200条由两位资深测试工程师分别做独立人工评审作为“基准答案”然后和LLM的结果做比对。第二层把LLM召回的87个问题全部交给专家判定统计“有效问题占比”。结果数字是精确率接近82%87个里约71个被确认为真实问题召回率没有极端精密。这个精确率对我的场景完全够用因为每个P0都有人复核误报并不会产生太恶劣的影响。但如果你是做全自动止损比如自动拦截上线那精确率必须继续往上提甚至要做到99%以上否则误报的代价会高得离谱。这里我想额外说一句不要神话LLM的召回率。我后来把漏掉的16个有效问题拉出来复盘发现它们中有一半是因为分开调用时上下文确实不包含相关信息——LLM根本不是漏了是“看不到”。这种结构性短板靠prompt工程解决不了只能靠调整审查单元划分或者引入向量检索先做“相关用例召回”。5.3 人工评审员角色的变化这套流程上线后评审重点没有变成“研究LLM的输出”而是变成“为什么这条用例会被判成冲突”。这其实是个很大的变化过去评审是为了找人脑的漏洞现在评审变成了“监督机器的判断”。我个人的感受是AI并没有取代评审员而是把评审员从“逐字阅读”中解放出来让他们有精力去思考真正复杂的业务规则边界。6. 后续可以怎么扩展这套方案改一改完全可以推广到其他文档一致性场景。我自己已经在计划做两件后续的事。一个是需求文档与用例的双向一致性检查。目前只是单向的“用需求审用例”反过来我可以把已修改的用例集合喂给LLM让它反向检查需求文档里是否有描述已经被实现行为“悄悄改动掉”但需求没同步的场景。这样能避免那种“实现先走了需求文档还停在旧版本”的经典脱节问题。另一个是把审查结果沉淀为组织级缺陷模式库。每次人工确认过的P0问题都作为新的few-shot示例记录到Prompt模板库里。这样随着系统用得越久模型对这个团队特有写作习惯的适配会越来越好误报率会持续下降。这算是一个低成本、能持续见效的迭代方向。这轮改造做下来我自己最大的感受是所谓“一致性”本质上是个规模问题。规模小的时候人脑完全够用规模一旦上去谁来查都会漏。LLM未必真的“理解”业务但它提供了另一种能力——用一种不带人情味、也不带疲倦感的方式把每一处细节差异都摆到桌面上来。你要做的只是搭好一个让它稳定发挥的框架以及保留一个人类拍板的最后环节。