大模型驱动的自然语言转测试脚本：无代码测试落地实践

我在前东家带测试自动化项目那几年，一直有个执念：让业务同学也能写自动化用例。为了这个目标，我试过录制回放工具、关键字驱动框架、BDD（行为驱动开发）那一套Gherkin语法，结果无一例外都死在同一个地方——业务同学写完第一版之后，再也不想碰第二次。直到去年开始把大模型引入到用例转脚本这条链路里，我才真正感觉到，AI把自然语言变成测试脚本这件事，不是简单的“旧活新干”。它解决的是无代码测试发展这么多年一直没跨过去的那道坎：让机器理解业务语言，而不是让业务人员迁就机器语言。这篇文章把我们从原型验证到小范围落地的完整经历拆开讲讲，包括原理、选型、踩坑和团队分工变化，希望能给同样在观望的测试团队一点参考。

别误会，我不是来推销什么“万能AI测试神器”的。相反，你会发现我对AI生成脚本的态度谨慎得很。因为真正跑过之后才知道，自然语言转测试脚本最核心的价值不在“生成代码”那一步，而在上下文理解、元素定位、结果解释这一连串看起来不起眼的环节。这些才是决定它能不能从玩具变成生产力的关键。

1. 折腾过几年“低代码测试”的我，为什么这次觉得AI真的不一样

1.1 录制回放和关键字驱动，当年都卡在同一个地方

先说说老办法。录制回放大概是不少团队第一次接触“无代码测试”的入口，工具记录你在页面上的操作，自动生成一段脚本。听起来很美好，业务同学只需要像平时操作一样点点点。但凡是维护过这种脚本的人都知道，页面结构稍微调一下，按钮位置挪一挪，脚本就全线阵亡。更糟的是，录制产生的脚本充斥着大量无意义的坐标、层级和等待时间，一个简单操作能生成几十行代码，出了问题根本不知道从哪看起。

后来行业里开始推关键字驱动，把“输入用户名”“点击登录”这类动作抽象成关键字，业务同学通过填表格的方式拼装测试步骤。这个思路比录制回放进步了不少，因为至少动作是语义化的，可读性提高了。但问题也很快暴露：关键字库的维护变成了新的技术债，每新增一个复杂组件，都得找测试开发去封装新的关键字。业务同学看似在“填表写用例”，实际上仍然是在一套受限的编程语言里表达，自由度很低。折腾到最后，写用例的依然是测试人员自己，所谓无代码只是把代码换成了另一种难用的配置。

BDD是另一条路。用Given When Then的格式写场景，让产品、开发、测试都能读。说实话，这个表达方式比关键字驱动更贴近自然语言。但落到具体执行时，每一句自然语言背后还是要有一层step definition去映射到代码。维护这套映射的人还是测试开发，而且Gherkin写久了，大家都会发现它变成了“半自然语言、半代码”的奇怪混合体：为了能被步骤定义匹配，语序、词汇都不能随便换，等于换了一种方式写代码。

这些工具之所以都没能真正普及到业务侧，归根到底是一个原因：它们都缺一个能够把自由语义转换成可执行步骤的智能解释层。业务人员输入的是“人话”，但工具希望输入的是“半结构化的人话”，这个要求本身就是巨大的心智负担。

1.2 AI补上的其实是“从业务语言到代码语言”的翻译层

大模型出现后，我第一次感觉到这个翻译层终于有了着落。你直接写“用户使用管理员账号登录，进入客户管理页，点击新增客户，保存成功后列表出现刚才的客户”，模型拿到这句话，能够主动把句式拆分、补充动作缺失的上下文、映射到页面元素，然后生成一条可以执行的测试脚本。它不需要你按照某个固定模板去说话，也不需要你理解CSS选择器是什么，更不需要你去维护一个关键字库。

为什么这次的体验和以前完全不一样？因为以前我们是在“穷举表达方式”，让用户从我们预先定义好的几种说法里选；现在模型是在“理解表达方式”，理论上它能接受无穷多种合法句式，甚至能处理指代和省略。打个比方，录制回放像让一个不懂业务的演员照着剧本笨拙地演，关键字驱动像让业务人员填一份审批表，而AI转脚本像是请了一个懂业务也懂代码的中间人，听完需求后自己把分镜画好、台词写清楚。

这个变化对测试团队的意义不是“省了几个写脚本的人力”，而是把自动化测试的入口从测试工程团队扩展到了整个业务团队。需求说清楚的那一刻，执行脚本已经有了草稿。后面的章节我会具体讲这条链路里模型是怎么运作的，以及哪些环节需要人来兜底。

2. 一句“登录后点击保存”背后，AI到底做了什么

2.1 它不是翻译，是一层层重构：意图识别先于代码生成

很多人以为自然语言转测试脚本就是把中文句子塞给大模型，让它直接输出一段Python或者JS代码。实际工程里这样做非常容易失控，因为代码生成是结果，而不是过程。我们第一版原型就是这么干的，模型输出脚本的质量完全取决于句子长度、复杂度和模型当天的心情。

后来我们把转换过程拆成了两步：先做意图识别与动作序列化，再做代码生成。第一步，模型把自然语言解析成一个结构化的动作列表，每个动作包含操作类型、操作对象、输入数据、预期结果；第二步，基于这个动作列表去生成对应平台的执行代码。这个中间层非常重要，原因有两点：一是可控，如果模型把动作理解错了，我们在看到代码之前就能发现；二是可解释，业务同学确认的是一步步的动作描述，而不是扑面而来的代码块。

举一个实际例子，输入“用测试账号登录，打开订单列表，把第一笔订单的状态改为已发货”。模型输出的中间表示大概是这样的：

[ { "action": "open_url", "target": "登录页面", "data": {} }, { "action": "input", "target": "用户名输入框", "data": {"value": "test_account"} }, { "action": "input", "target": "密码输入框", "data": {"value": "test_pwd"} }, { "action": "click", "target": "登录按钮", "data": {} }, { "action": "click", "target": "订单列表菜单", "data": {} }, { "action": "click", "target": "第一笔订单的状态列", "data": {} }, { "action": "select_option", "target": "状态下拉框", "data": {"value": "已发货"} }, { "action": "verify_text", "target": "页面提示区域", "data": {"value": "操作成功"} } ]

这一步看着平平无奇，却是整个流程的灵魂。因为一旦有了结构化动作列表，后面不管是生成代码、生成报告还是让人工审核，都变得异常轻松。模型出错的地方也会集中暴露在动作层，方便我们针对性修正。

2.2 上下文补全：AI是怎么看懂“它”指的是哪个按钮

自然语言和编程语言最大的差异在于，人说话时会大量使用指代、省略和依赖常识。业务同学写的完整用例还好，一旦写得不严谨，比如“点击保存后，它提示成功”，这个“它”可能是提交按钮，也可能是页面里的某条记录，还可能是弹窗。如果模型不理解上下文，生成出来的脚本就是随缘点击。

我们在系统里做了两层上下文补充。第一层是会话上下文，把当前用例之前的操作步骤、当前页面路径、页面内可见的按钮和输入框清单都作为背景信息喂给模型。这样当出现“它”的时候，模型可以通过最近的锚点名词推断出指代对象。第二层是页面DOM结构上下文，在生成脚本时，模型会先读取页面里可交互元素的语义属性列表，把它当作“候选人池”，再让模型从池子里挑选与自然语言描述匹配的目标。

举个例子，用户输入“在上一步打开的弹窗里点击确认”。“弹窗里的确认按钮”和页面底部工具栏的“确认保存”按钮是两个完全不同的元素，如果模型手里有DOM结构信息，就不会选错。这套机制在落地时非常依赖页面语义属性的质量。如果开发团队完全没有测试标识，模型就只能靠按钮文字猜，准头会差很多。后面讲选型和坑的时候，我还会详细展开。

2.3 元素定位与自动修复：脚本能跑的关键不是语法而是找得对

自然语言转测试脚本的过程中，代码生成不是难点，元素定位才是。因为代码语法错了编译器会告诉你，但脚本跑挂大概率是被测页面某个按钮找不到，或者定位到了错误的元素。最早的模型输出脚本，特别喜欢生成这种定位器：html > body > div:nth-child(3) > div > div.col-lg-6 > button。这种选择器在生成的当下是能跑的，但页面任何一个前序节点变化，它就崩了。

我们把元素定位策略从“生成固定选择器”改成了“生成语义描述+兜底定位策略”。也就是模型为每个待操作元素生成一组候选定位方式，按优先级排列：首先是data-testid，其次是aria-label或placeholder，再是按钮文本和元素类型组合，最后是视觉坐标。执行器拿到这组候选后依次尝试，一旦匹配成功就锁定。如果全部失败，才判定为脚本需要维护。

真正的杀手锏是自愈机制。脚本执行失败后，我们不是直接报错，而是把当前的DOM可交互元素列表、失败元素的语义描述、页面截图一起交给模型，让它重新推测目标元素现在在哪里，然后自动修正定位器再跑一次。这个功能看起来很玄学，但实际成功率相当可观，对于页面文案调整、按钮位置移动这类常见变更，AI能准确重新找到目标。当然，自愈也不是万能的，如果页面彻底重构，模型也救不回来，那时它会诚实告诉我们：找不到对应元素，需要人工介入。这套机制让无代码测试第一次有了一点“越跑越稳”的底气。

3. 小团队一周上线“白话测试”流程，我踩过的选型和落地方案

3.1 我最终选的技术组合与理由

先交代一下背景：我们的被测系统是某公司一个跨多个端的业务平台，前端组件库内部统一，页面结构相对规范，但业务规则复杂，回归测试量大。团队里除了我和另一名测试开发，其余测试同学基本只会写SQL和手工用例。

因为大模型生成代码的环节非常关键，我一开始就在商业服务和开源模型之间纠结。商业模型的效果确实更好，但我们会把业务描述和页面结构送到外部服务，这在很多公司过不了信息安全评审。最后选了本地部署的开源模型，效果略逊一筹，但胜在可控，且可以把整个测试数据上下文放在内网里流转。

执行层我们用了开源生态里的浏览器自动化框架，但没用它的默认调用方式，而是自己做了一层语义化执行器。这层执行器接收的输入不是普通代码，而是刚才提到的结构化JSON动作列表。这么设计主要是为了屏蔽底层差异：模型换版本、框架换API，我们只需要调整映射层，不用重写一套用例生成逻辑。整体架构分三块：用例管理与需求描述模块、转译服务、执行器与报告模块。用例管理和报告模块都是现成平台改造出来的，真正自研的只有转译服务这条线。

3.2 一条中文用例从输入到报告的全过程

讲一个我们跑通的最小闭环。业务同学在用例管理平台里新建一条用例，标题叫“管理员能够新增普通客户”，前置条件写“已使用管理员账号登录系统”，步骤里写：“点击左侧客户管理，点击新增客户，填写客户名称为测试公司A，联系人小张，手机号13800000000，点击保存，页面出现客户列表中包含测试公司A。”

这条用例被提交后，转译服务会先做预处理，把它拆成前置条件和操作步骤；然后组装页面上下文，调用本地模型生成动作列表；动作列表经过规则校验后，映射成浏览器自动化脚本并开始执行。执行过程中每个操作都会截图留痕，最终报告会显示每一步的操作描述和实际结果，而不是一堆日志。

下面是我们提示词模板里很关键的一段，模型能不能稳定输出，主要看这里：

你是测试用例执行器。根据给定的自然语言测试步骤，输出JSON数组。 要求： 1. 每个动作必须有action、target、data三个字段。 2. 操作对象必须是页面真实存在的可交互元素。 3. 如果描述中有输入值，data.value必须写成具体值，不得写“正确账号密码”这类模糊描述。 4. 预期结果用verify动作表示。 5. 不确定的元素优先标记为need_human_confirm，严禁编造。 输入步骤：{user_input} 页面可见元素列表：{dom_context} 输出：

这个模板看起来简单，但每一项约束都是踩过坑换回来的。比如第3条是为了防止模型把“正确账号密码”真的生成一个叫“正确账号密码”的字符串；第5条是为了避免模型找不到元素时硬编一个假的选择器，导致执行过程中才失败，反馈极慢。

3.3 反馈闭环：确认按钮、失败截图和语义化报告

自动生成的脚本直接扔去跑是没有意义的，因为业务同学根本不信任机器。我们做的第一件事，是在用例提交后增加一个“AI理解确认”环节。系统把模型生成的动作列表渲染成一个可勾选的步骤清单，业务同学看到的是“打开客户管理页面”“填写客户名称为XXX”“点击保存”这些可读文本，如果某个步骤理解错了，可以直接修改，然后让模型基于修改后的动作列表重新生成脚本。

这个环节看起来多了一步人工操作，但对整个流程的信任建立非常关键。我们把确认过的动作列表存成历史记录，相当于每次执行都有一份人类和机器都认可的需求语义快照。测试同学在排查失败时，不再需要从代码开始译，而是从动作列表对比实际情况，问题到底出在需求描述、AI理解、定位策略还是产品Bug，一眼就能分清。

报告端我们也做了改造。以前自动化测试报告是红红绿绿的通过失败列表，业务同学基本不看。现在每个失败点都会附上当时的页面截图、模型定位目标的语义描述、实际匹配到的元素信息。比如报告会写“需要点击目标：保存按钮；实际找到：页面底部一个文字为‘暂存’的按钮；候选定位方式全部失败”。这种语义化报告让产品、开发、业务都能参与进来判断缺陷归属，而不是只有测试看得懂。

4. 真实项目里翻过的车：能跑但不敢信，是最要命的阶段

4.1 生成脚本有随机性：同一句话跑出两种写法

第一个让我们非常头疼的问题是随机性。同一个用户、同一条用例、同一个模型，上午和下午生成的脚本可能完全不一样。上午用的是按文本找按钮，下午就变成了按data-testid找按钮。两种写法本身都能跑，但造成了一个很现实的问题：测试同学在Review代码时，发现这条用例昨天审过了，今天又冒出一个完全不同的实现，审也不是，不审也不是。

我们摸索出来的解决方案是组合拳。一是把模型的采样温度调到很低，让输出尽可能稳定；二是给模型固定few-shot示例，让它模仿示例的格式和风格；三是在转译服务里加一层结构化输出校验，要求模型必须输出合法的JSON，且字段必须符合schema。这样做了之后，同一句话在绝大多数情况下会产出同一个动作列表。偶尔还会变，但已经从“全句重写”缩小到“个别措辞差异”，Review成本下降了一个量级。

更稳妥的做法，是把每次确认过的动作列表缓存起来。同一用例在落库时就直接读取缓存的版本，只有需求描述变更时才重新调用模型。这相当于把AI当成一次性翻译官，而不是每次执行都重复翻译。说实话，生产环境里跑得很稳定的那条路径，最后基本都是这么处理的。

4.2 页面文案改动，按钮就找不到了

如果说随机性是“能跑但烦人”，那么元素定位失败就是“直接卡死”。有一次我们的页面上有个“批量导入”按钮，开发为了业务需要改成了“导入数据”，就一个词的差别，当天AI生成的脚本全部挂掉。原因很简单，模型的定位策略还是以文本匹配为主，语义描述里写的是“批量导入按钮”，页面上找不到完全匹配的文本，于是败给了自己之前的理解。

这件事给我们上了重要一课：语义定位不能做成文本完全匹配，要支持文本包含、同义词、功能描述匹配。后来我们会给模型提供更丰富的页面上下文，比如元素的title属性、附近文本、所在表单区域，并且要求模型在写语义描述时多写几个角度：“打开客户列表的按钮”“导航菜单中名字包含‘客户管理’的链接”“工具栏上旁边有‘新增’文字的按钮”。这样即使主方案崩了，备选方案还有机会命中。

自愈机制在这里也有贡献。当某个元素定位不到时，执行器会把当前页面上可交互元素的文本清单交给模型，让模型重新判断哪个才是当初描述的目标。有一次某个按钮从“立即保存”改成了“确认提交”，AI通过旁边的图标和表单结构猜到了对应的还是那个保存按钮，自动更新了定位方式，那一次我们没有人工干预，它自己修好了。但我也得提醒一句：自愈成功不代表用例可以完全放任不管，还是要有Review机制盯着，防止它把错误的元素当作正确目标。

4.3 人际语境和机器语境的差距：有些话AI真的接不住

自然语言转测试脚本，最大的讽刺在于：自然语言本身往往不够“自然”。业务同学写“正确登录”，我们和同事沟通时都懂这是用有效账号密码登录，但模型不知道什么叫“正确的账号密码”，它只会按字面理解，然后编造一个占位符。更离谱的例子是“点击确定”，业务同学觉得表单填写完了，这时候点“确定”保存，但页面上可能存在弹窗的确定、页面的确定、甚至一个不起眼的“OK”按钮，模型经常选错。

还有一类问题出在口语化省略上。人写用例时会写“输入金额，然后点击计算，检查税额对不对”。这里的“金额”没有具体值，“税额对不对”也没有明确预期。这种用例让同事手工测没有任何问题，但让AI转成脚本就是送命题。一开始我以为是模型能力不够，后来发现是我们的输入规范没有跟上，不能要求模型理解连人都没把前提说清楚的需求。

为了解决这个问题，我们总结了一套面向业务同学的“AI测试用例写作规范”，重点不是让他们学技术，而是学会把模糊的词换成具体的可验证表达。具体下面展开。

4.4 我们总结的“AI测试用例写作规范”

这份规范不是给测试开发看的，而是给业务同学和测试执行人员用的。它不需要句句完美，但需要满足几个基本条件。我把关键规则和示例对比放在一起：

有人会问，这不又变成结构化表达了？和关键字驱动有什么区别？区别在于这套规范只是“尽量遵守”，不是“必须遵守”。模型能容忍一定程度的偏离，实在写得不规范也能生成候选步骤，只是会标出不确定项，让人工确认。这比老办法那种“不符合格式就跑不起来”的模式宽松太多。

5. 测试团队的分工被重构了：不写脚本之后，我们干什么

5.1 需求澄清变成了最高优先级的测试活动

无代码测试跑起来之后，团队里第一个变化是：写脚本的时间大幅缩水，但需求讨论的时间明显变长。因为AI生成的测试脚本质量，直接取决于自然语言用例所描述的业务预期是否完整。以前需求有歧义，测试同学在写脚本的时候还能自己脑补补全；现在AI不会脑补，或者脑补得不对，最后跑挂了拉一群人来看，效率反而更低。

于是我们干脆把测试活动往前移，测试同学在需求评审阶段就要把验收场景写成自然语言用例。那些平时藏在测试工程师脑子里的边界条件、异常分支、数据前置，都被迫变成显性文字。这一步刚开始很痛苦，因为很多隐性知识说出来才发现漏洞百出，但坚持两个月后，开发和产品都开始习惯拿这份用例清单来对照实现，需求澄清的质量肉眼可见地提升。

这个转变的本质是：测试人员从“写代码的人”重新变回了“设计测试的人”。AI接管了代码生成和元素定位的体力活，人终于可以把注意力放回测试最有价值的环节——判断什么样的场景值得测，什么样的预期才算合理。

5.2 Review机制：AI生成脚本必须经过“用例转译评审”

团队一开始面对AI生成的脚本，内部有很大分歧。有人觉得既然模型都写好了，直接跑就行了，不用看代码；有人觉得不审不放心，万一模型生成了一段“看起来能跑、实际在乱点”的脚本，回归结果全是绿的，反而埋了大雷。最后我们定下的流程是：不审代码，但审转译结果。

所谓转译评审，就是评审第二节提到的结构化动作列表。测试同学看的是AI把自然语言拆成了哪些动作、动作顺序是否正确、目标元素是否对应、数据值是否合理。这个评审几乎不需要懂代码，但确实能抓住绝大多数模型理解偏差。每次评审通过后，动作列表会被锁存，后续执行都用这个确认版本，直到需求描述有更新。

有一个容易被忽略的细节：模型生成的脚本里可能会包含超出用例描述的动作，比如自动添加了一个“等待5秒”或“滚动到页面底部”。这类动作多半是为了执行稳定性加进去的，没有坏处，但评审页上必须明确展示，让团队知道模型做了什么额外决策。否则有一天脚本里混进了一个“等待60秒”，没人发现，用例执行时间就会悄悄失控。

5.3 无代码释放的是长期维护成本，而不是执行人力

关于无代码测试，我一直有个观点：它真正解决的不是“让业务同学也能跑自动化”这个面子问题，而是“脚本维护成本失控”这个里子问题。传统自动化测试里，需求一变，用例文本和脚本代码双份维护，改动成本极高；而现在用例文本本身就能生成脚本，机器理解的是最新语义，人维护的只有一份自然语言描述。

我们最直观的收益是回归用例的周转周期。以前一个版本迭代完成，测试团队花一周补脚本、调定位器是常事，现在大部分时间花在需求澄清和用例描述上，生成脚本变成分钟级。人力释放出来之后，我们开始安排测试同学去做探索性测试、竞品分析和线上问题复盘，这些活动产生的价值比维护一堆脆弱的XPath高得多。

但这不代表测试开发岗位会消失，恰恰相反，团队里最缺的反而是能把自然语言用例高效“喂”给AI、并设计Review兜底机制的人。这个角色要懂测试设计、懂一点模型边界、还得能跟业务顺畅沟通，比单纯写脚本要难得多。

6. 半年实践后的边界感：哪些场景值得上AI无代码，哪些别硬上

6.1 我认为值得用和不该用的场景对比

用了半年后，我对这套技术路线的边界有了比较清晰的感觉。不是所有测试都适合交给AI转脚本，硬上的后果往往不是效率提升，而是团队对AI失去信任。我把适合和不适合的场景做了个对比，供参考：

我特别想强调“页面频繁重构”这个场景。如果一个前端团队正处于组件库替换期，今天改一个按钮文案、明天换一个布局，这时候让AI去生成脚本，相当于让翻译员去翻译一本每天都在改写的书。你修好一个定位器，页面又变了，体验会非常挫败。这种时候更适合先把页面稳定下来，再谈AI自动化，不然挫败感会让业务同学觉得“AI也没有比老办法强多少”。

6.2 下一步：从单条用例生成走向场景编排和回归策略

目前我们的落地还停留在单条用例的转换和执行，下一步我想往场景编排方向走。因为真实业务很少是单个操作，更多是一个连贯的用户旅程，比如“登录-创建订单-关联客户-提交审核-查看状态”。AI如果能把整条旅程理解成一个带数据流转的场景，自动把前一步的输出接到后一步的输入，那才是真正的端到端无代码测试。

现在已经有了一些探索。我们把自然语言描述里的业务对象抽出来，比如“创建客户后拿到客户编号，再用这个编号去发起订单”，AI可以理解需要保存一个中间变量。这会比简单的动作序列化更进一步，也给测试设计带来了更大的想象空间。回归策略也可以交给AI，在需求变更时让它对比新旧用例描述，圈出受影响范围，进而建议本轮回归要跑哪些路径。这些方向还不成熟，但至少让我看到这条路还有不少延伸空间。

最后分享一个我们团队内部的小习惯：每周把AI生成失败、自愈失败、人工修正过的用例集中收回来，挑出典型样本，扩充到模型的few-shot示例库里。这个动作看起来不起眼，但坚持几个月后，模型对团队业务术语的理解明显变好，比如“客商”到底指的是客户还是供应商，双击还是单击，表单校验的提示文案长什么样，它都越来越有数。我觉得这才是AI时代测试团队真正的核心资产——不是脚本库，而是经过持续清洗和验证的“业务语义语料库”。