这个LLM自动校对测试用例，符合需求吗？🤔

测试用例校对的噩梦：LLM真的能救我们吗？🤔

说实话，写测试用这事儿，真的是谁写谁知道。每天对着那些密密麻麻的需求文档，眼睛都要瞎了。特别是当产品经理突然跑过来说：“哎，这个需求变了你把用例改一下。” 那一刻，内心真的是有一万匹草泥马奔腾而过。 我懵了。 所以 当我们听到 LLM自动校对测试用例 这个概念的时候，是不是觉得有点像是在沙漠里看到了一瓶水？但是这水真的能喝吗？还是说只是画大饼？

我们得先聊聊 Prompt 工程。这玩意儿现在火得一塌糊涂。大家都觉得只要Prompt写得好，LLM就能变成超人。但是测试质量的未来不只是写得快，更是写得对。 这句话说得轻巧， 可不是吗！ 实际操作起来呢？简直是灾难现场。你给LLM扔过去一堆需求，它给你吐出来一堆看似高大上，实则狗屁不通的用例。这时候你就得怀疑人生了这真的是在帮我吗？还是在给我增加工作量？

为什么现在的测试用例这么烂？

在现代软件研发流程中，“需求对齐”是测试用例设计的基本要求。只有当测试用例覆盖了所有功能需求，且准确体现了预期行为，测试工作才能发挥其应有的保障作用。只是现实中我们常常面临以下问题：需求文档写得像天书一样，逻辑混乱，甚至前后矛盾。你让测试人员怎么写？写出来的东西能对吗，补救一下。？

比如说 超时报警是系统在特定条件下自动产生的一个报警，而恐慌报警是用例里肯定就漏了。然后上线之后出了Bug，锅又是测试背。这找谁说理去？编写测试用例文档应有文档模板,须符合内部的规范要求. 但是规范这东西，有时候也是束缚手脚的枷锁，我傻了。。

LLM登场：是救世主还是捣乱鬼？

现在市面上LLM多如牛毛， LLM用例是否满足指定需求内容， 差不多得了... 并指出问题所在。” 听起来很美好对不对？

但是实际用起来你会发现，它经常“一本正经地胡说八道”。你让它校对，它确实能给你校对出一堆问题，但很多问题根本不存在或者它把原本对的改错了。 事实上... 这就很尴尬了。这时候就需要 输出后处理 和 领域术语定制。如果不做这些，LLM根本不懂你们公司的，比如“那个功能”到底是哪个功能？

我们来看一个例子。假设我们有一个简单的登录需求。

你是一位资深测试专家。请校验下列测试用例是否覆盖了指定的功能需求，指出是否存在：1. 需求未覆盖的内容；2. 测试数据或预期后来啊错误；3. 断言点缺失或不当；4. 逻辑步骤错误。：用户登录后可进入个人主页， 若用户名或密码错误，应提示“用户名或密码错误”，并停留在登录页。：用例编号：TC001用例名称：用户成功登录步骤：1. 打开登录页面2. 输入正确的用户名和密码3. 点击“登录”按钮预期后来啊：跳转到个人主页页面

这时候，输出后来啊 会是什么呢？它可能会告诉你：“哎呀，你只测了成功的，没测失败的呀！需求里说了用户名密码错误要提示的！” 你看，它好像还挺聪明的。但是如果你的需求文档里没写那句话呢？或者那句话藏在第50页的某个角落里呢？LLM要是没读到，它就觉得你是对的。这风险可太大了。

乱七八糟的需求与LLM的挣扎

整一个... 有时候我觉得，LLM也挺可怜的。要处理的需求文档实在是太乱了。比如下面这种：

我当场石化。 3.4 数据需求 用例需求分析概要设计测试用例.

何不... 看到没？这种需求，连人读起来都费劲，更别说机器了。这里面甚至还夹杂着“免费在线预览全文”这种广告词，或者是复制粘贴留下的痕迹。LLM看到这个，估计CPU都要烧了。它怎么知道“成绩表”和“学生表”之间的关系？它怎么知道“密码”字段有什么校验规则？如果需求里没写，它就只能瞎猜。

还有这种更离谱的：

免费在线预览全文XXXXXX单位 e-HR系统选型测试用例 被测试产品: 测 试 人: 二○一二年四月 一、 说明 对于本测试用例,需要参与系统演示的e-HR系统解决方案提供商完成以下工作: 由XXXXXX单位信息中心为.... 测试厂商应根据选型测试用例中 必测 的功能点测试情况,提交,内容包括但不限于以下方面:测试内容、实现的需求无...

歇了吧... 这都哪跟哪啊？又是“二○一二年四月”，又是“e-HR厂商”。这种充满了噪音的文本，丢给LLM，它能校对出个啥？它可能还会以为“二○一二年”是一个需要测试的时间参数呢。所以说光校对值是否符合期望就难的搞 . 真的太难了。

技术实现：虽然难， 但还得硬着头皮上

虽然困难重重，但是为了偷懒...哦不为了效率，我们还是得想办法把LLM用起来。 雪糕刺客。 目前主流的流程大概是这样的：

LLM 进行用例校对的关键流程如下：

先说说 你得把需求整理好，别像上面那样乱七八糟的。然后你得用上 上下文管理。主要原因是LLM记性不好，你给它的东西太多，它就忘了前面的东西了。所以怎么切分上下文，怎么把相关的需求和用例塞进去，这是个技术活，梳理梳理。。

我的看法是... 接着， 就是 使用 RAG 技术接入私有知识库，提升术语理解准确性。这个很重要。比如你们公司管“用户”叫“User”，还是“Customer”，还是“Client”？或者更土一点的“亲”？如果LLM不懂这些术语，它生成的校对意见你就看不懂。RAG技术就是让它去翻你们公司的“字典”，搞懂这些。

再说说输出也很重要。不能让它随便输出一段文字， 最好 结构化 JSON 输出校对后来啊，支持前端呈现与导出。这样你才能在工具里直接看到哪里错了哪里漏了而不是在一大段文字里找茬。

那些年我们见过的奇葩测试场景

为了证明LLM校对的必要性， 我们来看看一些真实的、让人头秃的测试场景，准确地说...。

麻了... 比如这个：百万高清车牌识别停车场自动收费系统技术设计方案热度:.用例编号用例名称用例功能前置条件测试步骤预期后来啊备注.1.施行③提示是否删除,选择确定,.

车牌识别啊！这可是硬骨头。光线暗了怎么办？车牌脏了怎么办？大货车和小轿车的角度不一样怎么办？这些需求，文档里往往写得很简单：“支持车牌识别”。但这四个字背后是成百上千个测试用例。LLM能帮你补全这些吗？我看悬。除非它真的懂物理，懂光学，懂摄像头成像原理，YYDS！。

何苦呢？ 再比如这个学生管理系统：学生课程成绩管理系统测试报告需求分析+概要设计+测试用例热度:.在中教师几位系统的管理员具有以下功能模块:学生成绩管理、 课程信息管理、学生基本信息管理,主要是针对对信息的添加、删除、修改和查询功能,使学校对学生的成绩管理自动化和规范化。.用户登录模块 与数据库连接,检查用户名与密码是否匹配 对于存在的用户名可以正常登录;并能给用户 正确的返...

这种CRUD系统， 看似简单，实则繁琐。各种字段的校验，各种权限的控制。LLM或许能帮你检查一下“是否覆盖了所有功能”，但是逻辑上的漏洞，比如“学生能不能删自己的成绩？”这种业务逻辑，它未必能看得出来。

怎么搞？给点实在的建议吧

说了这么多废话，到底怎么落地？这里给点 实施建议虽然不一定有用，但听着挺专业的，ICU你。。

得了吧... 先说说 使用结构化格式：需求块、用例块、目标指令清晰拆分； 别把所有东西揉成一团。LLM喜欢清晰的结构，就像人喜欢看排版好的文章一样。

摆烂。 接下来 支持多需求块与多用例批量处理，保持响应一致性； 别一个一个喂，太慢了。批量处理，但是要注意别让它上下文混乱了。

再说说 也是最重要的，结合人审后来啊与历史缺陷对比，对校对准确性做 A/B 测试； 别全信AI。AI只是个辅助，再说说拍板的还得是人。 来日方长。 你要拿它校对的后来啊和人工校对的后来啊对比，和线上的Bug对比，看看它到底准不准。不准就调，准了再推广。

这里有个表格， 大概列了一下现在市面上一些主流做法的对比， 翻车了。 随便看看就好，别太当真：

技术维度	传统人工校对	LLM 自动校对	混合模式
速度	慢，像蜗牛一样	快，像闪电一样	中等，看网络和算力
准确性	高，但容易疲劳走眼	忽高忽低，看运气	较高，有人兜底
成本	人力成本极高	Token成本，也不便宜	人力 + Token，更贵
理解能力	懂业务，懂潜规则	懂字面意思，不懂潜台词	通过知识库稍微懂点

代码层面的自动化与校对

我悟了。 除了文档层面的校对，代码层面的自动化测试也是重灾区。这些XML文档,开发者或测试工程师可以快速构建出一套完整的测试集,而无需手动编写每个测试用例.这种灵活性使得测试用例更符合特定项目的需求,一边也方便了与已有系统的集成.,可以快速验证图像功能是否按预期工作,避免因手动测试导致的遗漏或错误.

这是可以说的吗？ 这段话听起来很高级，又是XML又是自动生成的。但是生成的代码质量怎么样？页面跳转可能是由于用户单击链接、 按钮等引发的,也可能是系统自动产生的.此处介绍PHP中常用的实现页面自动跳转的方法. 如果你的测试代码里写死了跳转逻辑，而需求变了那测试代码不就废了吗？

再看看这个Python相关的描述：2.对表格中的接口测试用例测试,添加到测试Html报告中显示.python+unittest+requests+Excle+HTMLTestRunner+ddt数据驱动实现接口自动化测试:. 这一套组合拳打下来确实能跑通。但是接口定义变了怎么办？如果LLM能自动检测到接口定义的变化，并自动更新测试代码，那才叫牛逼。现在看来还差点意思。

收益：画个大饼结束

虽然吐槽了这么多，但是LLM在测试领域的应用前景还是有的。 薅羊毛。 如果真的做好了✅ 收益打造“测试导师型”辅助工具。

它可以像个老专家一样， 时刻盯着你的用例，告诉你：“小伙子，这个边界条件你没考虑到啊！”或者：“这个预期后来啊写得不严谨啊！”

而且，✅ 收益保障迭代中测试用例的持续有效性。 需求一直在变，用例也得跟着变。如果每次变更都能让LLM自动过一遍，看看有没有冲突，有没有遗漏，那质量不就上去了吗，有啥说啥...？

软件质量的根本，源自对需求的深刻理解与精准覆盖。用例设计若偏离需求，即便施行再完整，依然是“空转”的测试。而 LLM 的引入， 正是在帮助测试团队打造一位懂语义、懂业务、懂流程的智能审查官。虽然现在这位“审查官”还经常喝醉酒胡言乱语，但至少，它给了我们一个希望，我明白了。。

再说说 再贴一段看起来很厉害但其实没人看的：

软件质量保证与测试软件质量保证与测试课程第课程第1111小组小组丁涛涛丁涛涛201110812012011级计级计2班班测试对象测试对象,保山第九中学学生课程成绩管理系统保山第九中学学生课程成绩管理系统被被测试测试人人,王家静王家静2010，归根结底。

你看，连学校里的课程设计都在搞这个，说明这事儿确实有需求。不管怎么说这个LLM自动校对测试用例，符合需求吗？🤔 我的答案是：部分符合，但还需要大量的调优和人工干预。别指望它能完全替代人，至少现在不能。把它当成一个强力的辅助工具，或许才是最正确的打开方式，这事儿我得说道说道。。