从一个过气考渣的角度看LLM智能化测试用例生成

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

之前写过一篇《为什么测试智能化推荐从"用例续写"开始》，建议读者在考虑LLM+测试的场景时，可以考虑从测试点-->测试用例-->自动化测试用例这条线开始，因为从 业务需求-->测试点 这个环节相对而言还是比较难的。

当然也有同学会说，这有什么难的，需求文档往XXX大模型一丢，写一句“生成测试用例”的咒语，不就成了吗。有这种想法的同学，可以看一下笔者另外一篇文章《为什么说只发送接口说明给LLM要求生成单接口用例是在“耍流氓”？》

趁着劳动节，简要思考了一下如果真的要碰一碰业务需求-->测试点 ，可能会要考虑哪些问题。欢迎读者留言拍砖。

根据业务需求生成测试用例，会涉及到相关上下文的召回、用例生成等场景。除了用例生成之外，也可以考虑应用LLM进行用例评审。因此，本文将涉及以下内容。

1 整个需求文档进行召回 VS 拆分/关键字召回

这是一个关于topK的问题。在前面提到的考试当中，通常会有类似如下的题目。

请问，要完成某某业务，应该提交以下哪些材料

A, B, C, D, E,F,G

看到此类题目，通常可以闭着眼睛直接把所有选项都选上。而在LLM答题时，往往也能正确回答这类问题，因为在RAG召回时，这些选项涉及到的内容往往都在一个分片(segment)中，也就是将上述内容全部召回。那么，考虑另外一种类型的题目，

请问，以下哪些说法是正确的？

A, B, C, D, E,F,G

这种题目往往是很难的，因为其中大概率是埋着1，2个错误答案。而LLM想要回答正确，也依赖于RAG能正确且完整地召回题干+上述7个选项中所涉及到的私有领域知识。假设上述内容分散在8个分片中，那么，如果RAG召回数量topK默认设置为5，也就是最多召回5个分片的内容，必然会导致答案选择错误。

类似的， 一个需求往往会涉及到不少领域知识。如果直接将需求文档整篇进行召回，受限于topK的问题，会导致召回内容显著少于应该召回的内容。

所以，这时候可以有以下的2种方案

第一种是将topK设置为一个较大的数字，或者设置一个较低的相似度score值，以召回尽可能多的内容。但是这种方案可能会召回相似度很低的内容，反而对任务的推理产生误导。

另外一种是多次/分路召回的策略。通过对需求的拆分或者是关键字提取获得一个清单，然后按照清单来分别、多次进行召回。由于召回的内容更精简，可以召回更为精准，数量也更多的关联内容。当然也可以借助这样的思路，在用例生成时形成下面的多次生成的方案。

2 单个需求文档 VS 提供相关联的既有需求

区分新手和资深的业务测试人员的一个标志是后者往往对业务有着更为全面、深刻的理解，对系统的历史变迁也了如指掌如数家珍。虽然LLM精通各种测试设计方法，也具有相当多行业的common sense，但是对于公司的很多私域知识、系统实现等是没有认知的。如果只给LLM一个需求文档要求生成完整全面的测试用例，无异于是 “你猜你猜你猜猜猜”。

而将关联需求作为上下文提供给 LLM 生成测试用例，可显著提升准确性与完整性。一方面，关联需求能让 LLM 理解功能全貌，精准把握边界条件，避免因孤立理解需求导致的偏差，使生成的测试用例更贴合实际；另一方面，它有助于 LLM 覆盖不同功能模块间的交互场景，挖掘易被忽略的测试点，防止出现测试遗漏，确保测试用例能全方位验证系统功能的稳定性和正确性 。

那么如何获取到这些关联的需求文档来补充形成这个需求的上下文呢？ 

可以考虑通过数字化的方式来实现空间和时间上的上下文查询。首先，从业务视角来看，需求通常是一种条目化的结构，如epic-feature-story这样的三层结构。当我们拿到一个Story来进行测试分析时，通常也必定会去回溯这个story对应的epic-feature以更为全面地理解这个需求的空间领域的上下文。

其次，从技术实现上来看，系统也往往是有着模块-功能点等划分。如果某个story已经指定了与某个模块-功能点相关，也可以通过这些关键字来查询到历史上针对这些模块-功能点改造的其它相关需求，进而拿到一个更为完整的时间领域上的关联需求清单。

当然，我们也可以通过现在的RAG技术，通过向量数据库来召回与本次需求相似的历史需求文档，作为补充。当然，这个方案的精准度与前面的数字化方式相比可能会更差一些，也可以作为一种兜底或者扩展的方式，或者说得难听一点是一种数字化水平比较低的情况下的补救措施。当然在笔者看来，这种方式其实有着另外一个更为重要的使用场景。

3 裸考 VS 《3 年高考 2 年模拟》

相信本号的读者大部分都上过大学，有过参加大学期末考试的经历。从笔者自身的考试经验来看，能否在期末考试前几天拿到（女同学的）笔记以及去年的考试卷，是这门考试及格和优秀的重要差异项！类似的案例还有著名的《3 年高考 2 年模拟》

对于LLM来说也是类似的，当仅仅只有一份需求的时候，它所有的答题都是一种裸考，即使是给足了前面提到的种种所谓的上下文信息，对于LLM来说这还是一种全新的尝试，某种程度上来说是一种”创造“行为。 而如果能够给与LLM一张甚至若干张”历年考卷“，则会将任务在某种程度上变成了一种“仿写”，大幅度降低LLM生成测试用例的难度，提高结果的准确性。

因此，在之前提到的上下文之外，如果能将这些上下文所关联的测试用例也一并召回并提供给LLM作为参考案例，那么用例生成的结果将更符合实际情况，步骤描述、数据使用上也更为准确。

4 整个需求文档一次性生成 vs 拆分需求后分块分别生成

笔者曾经在内部做过一个测验，让LLM进行业务规则的考试，在裸考的情况下，LLM能考到80/100,这着实让笔者吃惊不少，因为并没有提供给LLM任何的私有知识。不过笔者也发现，当一次性给LLM 10道/20道题目要求作答的话，LLM的答题结果有一定概率会答错，导致总得分会少于80分。而如果是单题回答的话，结果始终是一致的。

在传统的测试需求分析过程中，往往会将需求文档拆分为若干部分内容，如需求自身涉及的业务逻辑算法、与其它既有功能的交互、接口、非功能要求等部分，然后分别为这些部分来设计测试用例。大语言模型（LLM）处理信息时，小块需求的语义相对更简单、清晰，它能更精准地理解每个部分的具体要求。例如，在一个复杂的电商系统需求中，包含商品展示、购物车、订单结算等多个功能模块。如果将其拆分为单独的模块来生成测试用例，LLM 可以更聚焦于每个模块的细节，减少因需求过于繁杂而产生的理解偏差。

也有同学向笔者展示过在DevOps平台上，允许用户通过自我选择需求文档中的部分内容来按需生成测试用例的案例。这也是分块生成的一个案例，只不过这个拆分是人工完成而不是由算法完成。

在考试前，老师和家长都会提醒考生一件事情，那就是在做完题目后，一定不要立马交卷，而是要检查一下。

类似的，除了根据需求生成测试用例这样的方案之外，其实也可以变通一下，变成“用例评审”的场景。无论时LLM生成的（并经过人调整/补充过的）用例，或者是完全由测试人员书写的测试用例，都可以经由LLM来做一次用例评审，并根据用例的完备性来补充或者修改测试用例。类似于前面提到的 “创造”与“仿写”的问题，用例生成的难度要显著地大于用例评审。测试团队也可以优先考虑引入LLM进行用例评审，作为人工评审的查漏补缺。 

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​

​​​