★ FEATURED ARTICLE 1. 先说清楚为什么要做“智能生成WebUI自动化用例”很多人听到“智能生成WebUI自动化用例”这个标题第一反应是“让AI帮我写脚本那我是不是可以躺平了”。我先把话说在前面不是这么回事至少现阶段不是。这个事真正解决的是自动化测试里最耗人、最枯燥、最容易被低估的那一段——把人从“对着页面反复手敲定位符、憋断言”的体力活里解放出来让人把精力留到更重要的地方判断测什么、怎么设计场景、怎么维护用例资产。我做过一段时间测试开发带过团队也亲手写了不少WebUI自动化用例。坦白说每天花两三个小时处理那些页面元素定位、等待策略、数据构造日复一日真的会倦。更要命的是业务一迭代用例就碎一片维护成本直接淹没人效收益。所以两年前我决定认真走一遍“智能生成”这条路从最基础的需求文本、页面结构信息出发用大模型能力把用例草稿批量生成出来人只做审校和兜底。这篇文章是“上部”聚焦思路、架构和生成链路前半段——从页面信息采集、Prompt设计到用例文本生成执行环境、调度框架、CI接入这些“后段”内容放在下部讲。这篇文章适合三类人一是被手工写用例折磨到怀疑人生的功能测试/自动化测试工程师二是想在团队里推广AI辅助测试但不知道怎么下手的测试负责人三是对大模型应用感兴趣想找个真实落地场景练手的技术人。我会尽量把每一步的取舍逻辑都讲透不藏着掖着。2. 整体思路生成链路是怎么设计出来的2.1 先拆解“写一条用例”这件事到底发生了什么要想让机器替人干活得先搞清楚人干活的每个环节。我拆过自己手写一条WebUI用例的完整过程大致是五个步骤理解需求从需求文档、缺陷单、业务口头描述里提取出“用户角色、前置条件、操作路径、预期结果”定位页面元素打开浏览器查看DOM结构找到输入框、按钮、复选框对应的id/name/XPath等设计操作步骤按业务顺序编排点击、输入、选择、拖拽等动作并考虑等待条件编写断言判断操作后页面状态是否符合预期可能是文案出现、元素可见、接口返回、数据落库组织用例结构设置前置数据、清理数据、用例分组、优先级标记等。这五步里最花时间的是第2步和第4步其次是第1步。但最有“技术含量”的其实是第1步和第4步因为它们依赖对业务逻辑的理解——AI恰恰在这两步能发挥优势因为大模型对自然语言的理解能力已经很强了它能读懂“用户在没有登录的情况下访问购物车页面应该跳转登录页”这种描述然后转化成结构化的用例。所以我的核心设计思路是不追求全自动端到端而是把第1步到第5步拆成若干个原子能力再串成流水线。每段流水线里AI负责“生成”规则和代码负责“校验”人负责“决策”。2.2 生成流程四个阶段整个生成链路我分成四个阶段第一阶段采集与结构化。把被测页面的信息抽出来包括但不限于页面URL、页面标题、关键元素列表定位符、元素类型、占位文本、已有的接口信息、页面跳转关系等。这一步决定了后面生成用例的“素材”质量素材越干净生成的用例越靠谱。第二阶段场景理解与用例规划。把需求描述、页面信息、历史缺陷数据打包喂给大模型让它输出“测试场景列表”每个场景包含用户角色、操作路径、预期结果。这个阶段产出的是用例骨架。第三阶段用例细化与代码生成。把场景列表继续下钻让模型按既定模板生成逐条用例文本再到对应的自动化脚本代码我以代码形式落地而不是Gherkin后面会解释原因。第四阶段校验与入库。生成的结果不能直接信要做语法、定位符存在性、断言合理性、重复度等多层校验通过之后进入用例管理库。校验不通过的打回重新生成或人工介入。这四个阶段一、四阶段是工程侧确定性高靠写代码完成二三阶段是智能侧交给模型。这个分工很重要不要指望模型去做精确的DOM检查和代码编译那属于“确定性世界”规则代码比大模型可靠一百倍。2.3 工具选型对比与取舍环节选型备选理由页面信息采集Playwright脚本 自研DOM解析器Selenium、浏览器插件录制DOM信息全量导出更可控录制工具噪音多生成模型商用大模型API 私有化小模型兜底纯开源模型、纯人写质量与数据安全的折中用例形态直接生成Python代码Pytest PlaywrightGherkin 框架解释执行减少一层翻译调试直观存储与去重自研用例元数据表 向量检索纯数据库查重语义级去重能力强于字符串匹配执行编排自研轻量调度模块Jenkins、平台级执行引擎初期灵活迭代后期可平滑迁移选型逻辑我不想展开太多只补一个点为什么不用Selenium不是它不行是Playwright在页面信息采集时给了很多便利比如内置的page.locator枚举能力、ariaSnapshot之类的接口能一次性拿到页面可交互元素的语义树这对生成用例是质的提升。如果你团队还在Selenium栈上也没关系链路设计是解耦的采集层单独替换即可。3. 页面信息采集与结构化素材决定生成质量3.1 采集什么不采集什么刚开始做的时候我想得很简单把整个DOM都抓下来字符串拼进Prompt里让模型自己找元素。结果生成出来的用例要么定位符用的是随机动态id要么选中的根本不是用户真正会操作的元素错得离谱。后来我反思明白了大模型不是人它没法“看一眼页面知道该点什么”。它需要的是经过清洗的语义化结构而不是一堆div嵌套div的原始HTML。所以采集层要做的事情有三个第一抽取可交互元素。通过选择器规则a[href]、button、input、select、textarea、[rolebutton]等把真正能点的、能输入的、能选中的元素筛出来同时给它做分类导航类、提交类、输入类、链接类。第二提取业务属性。每个元素要附带它的稳定定位策略优先id、name、>{ page: { title: 用户登录 - 某某系统, url: https://example.com/login, description: 用户登录页面支持账号密码登录 }, elements: [ { id: el_1, type: input_text, label: 用户名, placeholder: 请输入用户名, locator: { id: username, test_id: login-username, xpath: //input[idusername] }, required: true, visible: true }, { id: el_2, type: button, label: 登录, locator: { test_id: login-submit }, visible: true } ], relations: [ { from: el_2, to: el_1, type: adjacent } ] }这个JSON有两个关键设计点一是label字段不直接用页面文本而是把元素可见文本、placeholder、关联的label标签做了优先级合并让模型容易理解这个控件是干什么的二是relations数组目前我只放了简单的邻接关系其实还可以做“点击后出现”“校验失败提示归属”这类行为关系但行为关系比较难静态推断需要运行时插桩配合我放在下部讲。给模型输入时我不会把完整JSON直接丢进去而是转成一种“伪代码”形式的文本块。原因很简单大模型的Token窗口虽然越来越大但JSON里很多key名是重复的浪费Token而且模型对JSON的理解能力其实弱于对自然语言文本的理解。实测下来转成类似下面的描述生成的用例质量更稳定页面用户登录 - 输入框用户名IDusername - 输入框密码IDpassword - 按钮登录test_idlogin-submit - 链接忘记密码href/forgot-password 校验提示用户名不能为空classerror-tip3.3 采集层踩过的三个坑采集这块我遇到的坑不少挑三个最典型的说。第一个坑是懒加载。页面滚动前和滚动后叉出来的元素数量差很多尤其是列表页、无限流页面。如果不处理生成的用例会漏掉大量可操作元素。解决办法上面说了逐步滚动并配合waitForTimeout等待渲染必要时直接用曝光检测。第二个坑是弹窗和iframe。登录弹窗、广告浮层、iframe内嵌内容这些在纯DOM遍历里很容易漏但实际又是业务测试的重点。目前我的方案是单独捕获dialog元素和iframe把iframe的contentDocument也纳入遍历并生成“进入iframe”的前置步骤注入到用例里。这个细节手工写用例的人经常忽略智能生成如果不处理就会被归为“不智能”。第三个坑是纯视觉元素。有些可以点的东西是div做的没有语义标签没有role属性。这种元素不采集会漏场景采集了又容易误抓一堆装饰性块。我的折中方案是只保留“绑定了事件监听器”的div通过CDP获取元素上的事件回调再结合元素大小、位置过滤筛选出的量会小很多可用性也高很多。4. Prompt设计生成质量的核心变量4.1 Prompt不是写一段话是写一套约束系统很多人以为Prompt就是“帮我生成一下测试用例”这理解太浅了。实际做下来Prompt的设计要精细到“标题、角色、输入结构、输出结构、示例、负面约束、边界条件”七个层面缺一个都会出幺蛾子。我自己维护了一套模板核心结构如下你是一名资深测试工程师负责为Web系统编写UI自动化测试用例。 请你根据以下页面信息和业务需求生成符合标准的自动化测试用例。 【页面信息】 {采集到的结构化页面描述} 【业务需求】 {需求描述或缺陷描述} 【生成要求】 1. 请按“场景清单-用例详情-代码实现”三层结构输出 2. 场景清单只列场景名和优先级不超过8条 3. 用例详情包含前置条件、数据构造、操作步骤、预期结果 4. 代码实现使用Python Pytest Playwright框架 5. 定位符必须使用页面信息中提供的locator不允许猜测或新增 6. 断言必须包含至少一个状态断言和一个行为断言 7. 不要生成与页面信息矛盾的步骤 8. 每条用例代码行数不超过60行可读性优先。 【输出格式示例】 这里贴一段我精心构造的参考输出让模型模仿格式注意最后一条给示例。大模型是“示例驱动”的尤其当你有明确格式要求时不给示例就等于让模型自由发挥。我的经验是示例要给2-3个不同形态的一条正向主流程、一条异常分支、一条边界值场景模型才能学会“在不同场景下采用不同写法”。4.2 三类Prompt的专项设计通用模板搞定之后我发现不同场景需要不一样的生成策略于是拆成三个Prompt场景规划Prompt。输入是需求和页面信息输出是场景清单。这个Prompt主要约束“覆盖维度”正常流程、异常输入、权限控制、数据边界、并发操作等相当于一个检查单。模型生成的场景如果漏维度我会在下一轮反馈里指出来让它补全。用例细化Prompt。输入是场景清单上一步产出输出是逐条用例详情。这个Prompt主要约束“步骤的可执行性”每步操作都要能找到对应元素不能出现“输入有效用户名”这种抽象指令要具体到“在用户名字段输入值zhangsan”。代码生成Prompt。输入是用例详情输出是代码。这个Prompt主要约束技术规范包括等待策略默认wait_for_selector、元素交互方式优先locator.fill而不是click后再填、断言写法expect系列断言、异常处理失败时截图等。三层Prompt的好处是每一层的产出物都可审查中间出了问题可以直接定位到某一层修正而不是反复整段重来。很多团队做AI生成失败就是一口吃个胖子让模型一次生成完整成品出错了都不知道是哪一步的问题。4.3 Prompt调优的实测经验调Prompt的过程中几个细节让我印象很深。第一让模型“看不到”就不要“想”。Prompt里明确写“只使用提供的信息不要补充页面信息中不存在的元素”能显著减少幻觉。第二负面约束比正面约束重要。比如“不要使用索引型定位符”“不要生成sleep等待”这些一刀切规则比“尽量使用稳定定位符”有效得多。第三温度参数要调低。生成用例这种事温度设0.1-0.3比较合适太高会产出各种“创意写法”反而添乱。关于模型选择我比较过商用大模型API和几个开源模型的实测效果。结论是如果不涉及敏感数据商用模型在理解页面语义、写代码规范度上有明显优势如果必须私有化部署那么至少要13B-70B级别的模型才堪用小模型在长指令遵循和代码生成上会频繁“偷工减料”。下面是同一个页面信息下温度0.1和温度0.9生成的定位符对比差距一目了然温度定位符写法结论0.1page.get_by_test_id(login-submit)符合项目规范稳定0.9page.locator(div.form button:last-child)结构耦合强页面微调即碎5. 生成用例的落地实操一次完整的登录场景5.1 前置输入用到的素材是三样页面信息用户登录页 - 输入框用户名IDusername - 输入框密码IDpassword - 按钮登录test_idlogin-submit - 链接忘记密码href/forgot-password - 提示框登录错误提示classlogin-error 需求描述用户在登录页输入正确的用户名和密码后点击登录按钮应该跳转到首页输入错误时应显示错误提示文案“用户名或密码错误”。这个例子非常简单但恰好能讲清楚完整链路。真实项目里页面信息比这复杂几十倍但原理一样。5.2 场景规划Prompt的输出我给场景规划模型下的指令里有一条至少覆盖正常流程、异常流程、边界情况、数据恢复四类。它输出的场景清单是P1-正确凭据登录成功 P1-错误密码登录失败并提示 P1-空用户名登录失败并提示 P2-密码框输入内容掩码显示 P2-用户名前后带空格自动去除后登录成功 P3-登录成功后跳转首页且显示用户名这里有个细节模型主动生成了“用户名前后带空格自动去除”这个用例但页面信息里并没有任何关于“自动去除空格”的说明。这就是幻觉风险。我的规则层做了一个拦截如果用例里的行为描述没有对应的页面证据自动标记为“低置信度”需要人工确认。最终确认后这个功能确实是系统支持的模型是对的但流程上这个确认不能省。5.3 用例细化与代码生成场景规划通过后进入细化阶段。我给模型提供详细用例模板它输出的其中一条长这样用例编号TC-LOGIN-002 优先级P1 用例名称错误密码登录失败并提示 前置条件无 数据构造 - 用户名validuser - 密码wrongpass 操作步骤 1. 打开登录页 2. 在用户名输入框IDusername输入 validuser 3. 在密码输入框IDpassword输入 wrongpass 4. 点击登录按钮test_idlogin-submit 5. 等待1-2秒 预期结果 - 页面显示错误提示“用户名或密码错误” - 登录按钮可再次点击这个结构已经很接近成品了。接下来进入代码生成我用代码生成Prompt把它转成Pythondef test_error_password_login_fails(page: Page): # 前置打开登录页 page.goto(https://example.com/login) page.wait_for_selector(#username) # 输入用户名和密码 page.locator(#username).fill(validuser) page.locator(#password).fill(wrongpass) # 点击登录 page.get_by_test_id(login-submit).click() # 断言错误提示可见 expect(page.locator(.login-error)).to_be_visible() expect(page.locator(.login-error)).to_contain_text(用户名或密码错误)整体生成质量在我可接受范围但直接入库还不够——因为页面是动态的等待策略、数据清理、失败截图这些工程细节模板里没有体现。所以我在代码生成之后加了一个“工程化增强”的后处理脚本统一补充截图装饰器、统一等待策略、把硬编码URL替换为环境配置变量。也就是说大模型生成的是“主逻辑”工程外壳由代码后处理负责两者各司其职。5.4 校验规则与人工介入生成的用例要通过四轮检查才能入库我的检查规则如下检查项方式拦截示例语法编译对生成的Python代码做ast.parse括号不全、缩进错误定位符存在性在测试环境实际执行一次元素查找locator写错、页面未渲染用例重复检测向量化语义相似度 路径字符串相似度同一场景被不同描述生成两条业务一致性人工抽检 需求对照表断言结果与实际业务规则冲突前三项是自动的最后一项保留人工。我始终觉得AI辅助工程落地最忌讳“无人看守的自动化”。人必须保持在环路里只是从“写代码的人”变成了“审代码的人”。6. 常见问题与排查技巧实录6.1 生成结果“看似合理、实则废话”怎么办这是最典型的问题模型写出来的用例步骤齐全断言写得也像回事但仔细一看没有实际价值比如断言“页面存在div标签”这种废话断言或者步骤里全是“等待元素出现”而没有业务操作。我排查的思路是先看Prompt里的“断言要求”是否具体。如果你只写“生成断言”模型就会自由发挥如果你写“断言必须包含文案断言、元素状态断言、URL状态断言三选二”情况会好很多。其次加“逆向示范”在负面约束里写“禁止断言页面标题为空、禁止断言某个标签存在”。给模型看反例是纠正这类问题的有效手段。6.2 生成的用例“同质化严重”另一个高频问题是给2个不同页面生成用例产出的结构一模一样看不出页面差异。比如给登录页和商品列表页都生成“点击按钮看结果”的用例这等于没智能。这个问题的根源是页面信息没起到约束作用。解决思路是我在页面信息里额外增加了一个“关键行为描述”字段用一句话描述这个页面的核心用户行为。例如登录页填“用户提交凭据以换取会话”商品列表页填“用户浏览并筛选可购买商品”。模型在两个页面生成的用例会因为关键行为的差异化描述而走向不同的设计方向。6.3 定位符生成正确却执行失败定位符在页面信息里明明存在生成到用例里也是一模一样的但跑起来就是找不到元素。这类问题多半出在“渲染时机”上尤其SPA应用元素是否存在和是否可见是两回事。我们的后处理脚本里有一个强制方案所有交互前统一调用expect(locator).to_be_attached()等价于一个前置等待闸门不能说彻底解决但能把偶发失败率降一个数量级。还有一个场景是元素被遮挡比如顶部浮层盖住了按钮点击时报intercepted。这种情况后处理脚本会尝试在元素不可交互时自动退回到“强制点击”方案并打标签提示人工确认该步骤与真实用户行为是否一致。6.4 模型输出不稳定同一输入两次结果不同大模型API本身有随机性即使温度固定为0.1也难免有微小波动。如果两次生成结果差异很大多半是输入侧的问题页面信息顺序变了、Prompt里带了时间戳、或者系统pormpt里有多余内容。我的做法是把输入内容全部序列化成一个确定性的文本哈希请求时加上固定种子参数部分API支持不支持的就在生成之后对比关键字段的相似度低于阈值自动重新生成一次选质量高的那个。稳定性问题不彻底解决后面做“存量用例的自动更新”会很痛苦。6.5 数据准备与清理的自动推导这个是生成用例时最容易漏的一块。模型往往只会写“输入用户名”不会想“这个用户名是否存在、测试完要不要删除”。目前我采用规则引导在场景规划Prompt里对每一条场景强制要求填写“数据依赖”字段并在代码生成时自动套用脱敏数据工厂的接口调用示例。至于真正的数据工厂怎么与生成代码联动属于执行层的范畴下部再展开。6.6 快速排查速查表现象优先排查项解决方案用例生成后定位符不存在页面采集是否包含动态节点过滤二次采样过滤动态属性断言明显无效Prompt断言约束是否具体增加三选二断言规则场景覆盖缺维度场景规划是否带检查单增加检查单Prompt元素点击被拦截是否使用强制点击兜底增加to_be_attached检查生成结果波动温度和输入稳定性设低温度、序列化输入哈希两条用例高度相似去重向量库是否覆盖语义向量检索去重写在最后的一点体会把智能生成从想法推到可用的链路过程里最大的感受是这个事80%的功夫不在AI而在AI外围的数据工程和规则工程。采集层不够细生成再强也是无米之炊校验层不够硬生成再快也让人不敢信。大模型在这里更像一个能力超强但“很不靠谱”的实习生你需要给它最清晰的任务书给它最干净的输入材料再让一套严格的质检流程站在它背后产出才能真正被业务接纳。另外我越来越觉得不要把“智能生成”理解成一次性生成一堆用例然后收工。更实用的形态是从存量用例、历史缺陷里反推出业务规则再让模型基于规则去生成增量用例实现用例资产的自我进化。围绕这个方向我已经在尝试做反馈回路——把执行结果失败的用例、人工修改过的用例重新喂给模型做微调准确性在逐步抬升、幻觉在明显减少。这个方向值得持续投入。上面讲的是前半条链路。下半部分包括执行调度、失败重试、与CI流水线集成、覆盖率统计与用例资产度量我后续再接着整理。
阅读完成 · 觉得有帮助？
