现在的软件交付周期是变得越来越短了的, 测试团队经常就碰到了那种搞不定的麻烦事儿, 那就是需求文档老是来更新的, 回归测试的用例呢维护起来特别贵而且费劲, 另外写自动化脚本也是花时间的费精力的, 同时呢大语言模型的那个能力正在飞快地往开发链路里面渗进去。

对于测试工程师来说, 有一个问题是很值得去思考的, 那就是, 我们是不是可以把大模型这个本来只用来聊天的工具, 变成一种能够提高生产力的工具, 让它来帮助我们生成测试用例, 编写自动化的脚本, 甚至去维护那些测试资产。

答案是完全正确的。可是想要真正地实现, 需要依赖的不是仅仅提出问题, 而是必须借助一个具有整体结构性的操作方式。

一、大模型生成测试用例的三条路径

从本质上来讲, 测试用例它是对软件行为的一种预期的描述。那么大模型去生成这些用例的质量到底怎么样呢? 这个在很大程度上它是取决于我们提供给它的上下文信息是不是足够精确, 够不够准确。那么根据输入源的具体不同情况, 我们可以把这个事情归纳为三条实践路径出来。

第一条这个路径是基于需求文档来生成的, 这也是最直接的途径。测试人员会把用户故事或者需求说明输入给模型, 然后要求它输出结构化的测试用例。关键的地方在于, 你必须要在提示词里明确验收标准, 并且约束输出的格式。

比如, 你可以要求模型按照“前置条件”、“操作步骤”、“预期结果”这种三段式的方式来输出内容, 同时也要覆盖正向场景、反向场景还有边界条件。

模型这种事儿, 它很擅长从自然语言里头去挖掘那些隐藏的、不那么明摆着的逻辑关系, 不过呢, 对于你压根儿就没有提到过的规则方面, 它是绝对无法进行猜测操作的。所以说, 如果你想要获得高质量的那些用例的话, 作为前提条件来看待的, 提供完整的需求上下文这一举动是必须的, 这一点大家得知道清楚。

第二条路径是利用代码生成来产生单元测试, 当你需要去为遗留代码补全测试的时候, 又或者是你要去验证新实现的分支覆盖情况的时候, 你可以把函数的源码提交给模型, 然后要求它去生成对应的单元测试代码, 这里有一个比较实用的技巧, 就是在提示词里面要求模型先去分析代码的逻辑分支, 然后再针对每一个分支去生成测试, 这种方式不仅仅是能得到脚本, 还能够帮你发现代码中可能遗漏的边界条件。

第三条路径是基于接口定义来生成 API 测试用例。如果你手里有规范文件或者接口文档, 可以让模型把它们转化成具体的测试场景。拿用户注册接口来说, 模型能够自动生成参数缺失、格式非法、重复注册以及数据库异常等多种场景的用例方式。这种方式比人工枚举更加高效, 也更不容易漏掉组合场景的情况。。

二、从自然语言到可执行脚本

生成测试用例这个事情, 充其量也就是迈出了第一步而已。大家必须得看清楚, 大模型之所以拥有更大的价值体现在什么地方, 那就是它能够把用自然语言进行描述的信息内容, 直接地转换成那些可以立刻去执行的自动化脚本代码。

在 UI 自动化领域, 以往的做法往往是先通过人工去编写定位器内容, 随后再将操作流程进行组装, 而现在依托大模型的能力, 你仅需直接描述具体的业务步骤, 大模型即可自行输出相应脚本或者代码文本, 举个例子来说明, 当你向模型传达“必须在登录页面里分别填入手机号信息以及验证码数据, 接着执行点击登录按钮这个动作, 并最终确认系统是不是正常跳转到了那个首页上”这样的语句时, 大模型不仅仅可以生成最基础的运行脚本, 还能够完全根据你所提出的具体要求, 在生成的流程里强行加入显式等待的时间判断逻辑, 同时配备异常情况的捕获处理机制, 并且还会自动开启截图作为证据保存功能。

你要是能把那个页面的HTML这一块的内容给提供出来, 让模型把它当作是参考的东西, 那么模型甚至都能够在你的基础上帮助你把这个定位的策略给它弄得更稳定一些。

在 API 自动化领域, 效率提升变得更为明显。把接口的请求方法、URL、参数结构和业务规则告知模型, 它可以一次性生成包含请求构造、断言判断以及数据驱动逻辑的完整脚本。更进一层, 如果你要求模型以结合库的方式来输出代码, 那么得到的代码往往可以直接集成到 CI 流水线当中去运行。

三、 工程：决定输出质量的关键

这本质上是一门工程, 跟大模型一起合作去把测试用的资产给弄出来。经过实践检验之后, 有几个原则是这样的:

提供那些少样本示例。在提示词那里附带好你希望得到的输出样例, 这样模型就会去模仿你的那种格式还有风格, 从而让解析成本显著降低下来。

分阶段生成, 而非一步到位。对于复杂需求, 先让模型分析测试点, 再生成用例, 最后转化为脚本。这种链式思考方式能减少模型的“幻觉”, 提升准确性。

你要把那个约束条件给明确清楚。你得告诉他, 他输出的那个东西得是什么语言, 还得是用的什么框架, 另外呢也得说说需不需要进行异常处理, 或者说需不需要加上注释之类的这些事情。所以说吧这个约束, 如果写得越就是那么清晰的话, 那最后出来的结果呢也就越能用得上, 越好使。

进行迭代并且不断优化。要把这个模型看作是负责撰写初稿的写手, 而不是负责最终审核和编辑的法官。首先得生成一个基础版本的成果, 之后再让去补充那些边界的情况, 或者去优化定位器方面的稳定性, 还有也可以要求将其重构为所谓的 Page 模式的内容。

四、一个完整的实战示例

我们在讨论一个具体的场景, 这个场景里用户想要进入系统, 那么他们就需要使用手机号去接收验证码, 然后通过填入验证码来完成登录这一操作。

第一步, 我们把需求这个东西给输入到模型里面去, 要求那个模型把输出的东西变成测试分析。

"请分析以下登录功能的测试点：手机号需为11位且1开头，验证码为6位数字，有效期5分钟，错误3次锁定账号。"

这个模型会把你需要做的事情都列出来, 具体来说, 它会把功能方面的测试点, 边界情况的测试点, 还有出现异常时的测试点, 以及安全问题方面的测试点等这些完整的关于各种测试点的列表返回给你。

到了第二步的时候, 需要先从测试点里面挑选出一部分来, 然后根据这个选择结果去生成相应的测试脚本。

"请使用 Playwright + Python，针对'验证码错误提示'这一场景生成脚本。

页面元素：手机号输入框 id='phone'，验证码输入框 id='code'，登录按钮包含文本'登录'，错误提示 xpath='//div[@class='error-tip']'。

要求使用 Page Object 模式，失败时截图。"

在最终的时候, 你会得到一个结构是很清晰的那个情况, 这个自动化脚本是能够在电脑上直接运行起来的, 并且整个这么一个操作过程下来, 说不定只用花上几分钟的时间就搞定了。

五、理性看待：局限与应对

大模型这个东西, 它并不是什么都能搞定的万能钥匙。当业务规则复杂到极点的时候, 或者是有特定领域的合规要求需要严格满足的时候, 又或者是场景特别复杂、必须和私有的测试框架进行深度集成的时候, 这种情况下, 依然离不开人工去介入把关, 还需要人工去做校验。

另外还有一点值得注意, 就是模型生成的那种页面定位器玩意儿, 一旦页面的整体结构发生了变更, 它很可能会失效。同时, 由模 型生成的那些断言语句, 往往也可能过于宽松, 不够严谨。

所以, 目前公认的最佳做法是人机协同模式。这种模式要求我们把重复性的编码任务和枚举工作交给大模型去处理。与此同时,测试工程师应该把主要精力放在策略的设计上。他们还需要对各个场景进行仔细审视。

最后, 要做好质量的把关工作。要把生成的那些用例和脚本放入代码审查流程里去检查。要结合实际执行得到的结果来持续地进行反馈和优化。只有这样做才能充分发挥大模型真正有价值的地方。

结语

现在的大模型正在重新定义测试工作的边界。它本来就不是要取代测试工程师的岗位, 但是它会显著改变我们的工作方式是什么, 也就是说, 工作模式不再是手工去编写每一行脚本了, 而是要转变为如何设计更好的提示词, 并且要审阅那些自动生成出来的资产, 还要把控最终的质量情况。

掌握这一种从需求一直到脚本的 AI 协作流程, 将会成为下一代测试工程师的核心竞争力之一。