三，智能WebUI自动化最佳实践

虽然现在大模型在测试领域使用的很多，但是真正大幅度提高测试效率的不多，也就是没有想象中的那么厉害。举个例子来说吧，大模型生成手工测试用例，不少公司从这方面入手，也做出相应的产品和工具，但是真正在使用过程中，会遇到各种各样的问题。例如：需求文档描述不明确，没有上下文信息；需求文档中有大量的图片，公式或是引入第三方文档；需求以表格形式说明，并没有相互关系等等。要想取得较好的效果，需要需求是独立的功能，或是进行拆分再生成用例。

由此可以得出，不要总想着用大模型一站式解决遇到的问题，要分段来部分替换相应的工作。如果一个需求产品讲之前，测试都看不懂，你能希望大模型能生成覆盖全面的测试用例，这显然不现实的。

3.1 需求生成WebUI用例设想

在分析了业界的WebUI自动化产品和方案，结合公司相关的AI生成手工用例，AI生成接口自动化方案的前提下，产生如下AI生成WebUI自动化的设想方案。

方案解析：

1，一个新的需求产生后，先查询本需求是否有对应的手工测试用例，如果有，就可以拿来使用。如果没有，就拆分需求文档，按功能模块生成对应功能模块的手工测试用例。

2，有了手工测试用例后，经过大模型可以转化成相应的WebUI自动化用例，此时便有两个方案。

3，在经费比较足的前提下，可以使用Browser-use来拼接出一个个自动化测试用例，用例执行的时候，解析用例内容，自动执行用例。但是存在用例理解不足，反复执行，耗费大模型token的情况。同时需要开发汇总生成测试报告的功能。

4，第二种方案，就是通过大模型将手工测试用例，转化成单步可智能优化的playwright测试用例。生成用例后，再用playwright来执行，同时将优化后的测试用例保存，再次执行时就可以直接执行优化后的用例。执行速度快，所有的用例解析，报告均可用playright原生的。

5，第二种方案正在尝试实施中，目前效果还可以。但是也存在着，大模型不理解业务逻辑的情况下，生成的用例通过率较低的问题，后续考虑引用业务地图，来提高用例生成通过率。

3.2 智能可优化用例生成方案

现有的playwright-mcp(https://github.com/microsoft/playwright-mcp)可通过交互模式生成WebUI自动化测试用例，但是通过分析它生成用例的逻辑：根据用户输入，用例执行效果，结果返回等信息，生成或是优化测试用例。这就存在着，如果某一步执行失败，用例就会全部重新生成，结果再次生成的还不如前一次，其他的步骤又执行失败，如此反复优化，消耗大量的大模型token，也没有生成可执行的用例。

为了防止上面的情况发生，设计出单步执行，可智能优化测试用例，方案如下：

方案解析：

1，首先需要有如下几个功能模块：获取当前页面指定元素结构的功能，获取输出结果和日志功能，调用大模型优化用例操作步骤功能和兼容用例执行功能，上图中蓝色模块。

2，大模型生成用例时，要对用例的每个步骤添加上监控，实现用例的单步执行和分析执行结果。如果用例执行失败， 则调用大模型优化用例操作步骤，并能控制优化次数和执行优化后的用例。

3，智能优化用例大模型，要给大模型指定优化规则，优化示例，处理返回结果等。这个根据不同的业务指定不同的策略，同时，要及时反馈优化效果，提高优化效率。

4，对每个步骤都添加上监控，就能根据测试对象的变化，自动优化测试用例，同时又避免了playwright-mcp的问题。当所有用例步骤都执行完成后，将优化后的用例保存，下次直接执行优化后的用例。

5，上面的方案是一个简化版本，在公司中根据不同的业务，有非常多的处理逻辑，此处就不放那么复杂的方案了。

3.3 封装框架方案

上面的方案是基于原生的playwright框架的基础上实现的，其实还有一种方案：针对特定的业务，先封装一个基于Playwright的自动化测试框架，提取业务操作函数，特殊需求处理：如抓包，读取日志，mock数据等，再加上大模型优化用例，图像识别等功能。后续的用例，在此框架基础上进行生成，减少用例操作步骤，提高用例通过率。

框架封装规则：

1，减少用例操作，如果需要多个步骤实现的操作，可以封装成一个函数，作为基础的函数库。如拖动操作，点击需要hover之后才出现的元素等。

2，划分业务功能模块，按功能模块封装函数。比如，登录，搜索，发布消息等，以后的用例直接调用相应的函数，组装测试用例，添加断言即可。当然复杂的断言也可以封装成函数，如检测返回数据的完整性，图片对比，图片搜索等。

3，特殊需求的封装，如抓取接口返回，验证数据；上报日志，mock数据，等等；

4，大模型增强效果，如页面元素搜索，失败用例自动优化，手工用例生成自动化用例，页面遍历等等，在业务层增加相关效果，对用例影响最小。

5，平台化生成基于框架的用例，无论是录制用例，还是大模型生成用例，基于封装后的框架，测试用例步骤最少，通过率也最高。遇到统一出现的问题，可以从框架级别进行优化，降低用例维护成本。

缺点：

1，兼容性不足，由于需要针对业务进行封装，如果公司或是部门产品比较多，则封装的内容较多，前期投入成本较高。

2，必须有一定的编码能力，对业务足够了解，才能实现完美的封装，否则就做不到以最少的代码，对业务实现最大的覆盖。

3.4 实践中的思考

我们是直接通过需求文档生成测试用例，再将测试用例生成对应可智能优化的测试用例，目前全流程执行没有问题，不过生成用例的质量还不高，通过率比较低，需要逐步调整一下AI Agent，提高生成用例的效果。但是以下问题还是很难解决：

1，需求与被测对象不一致。早期的需求文档拿出来评了一下，中间有变化或是开发过程中有变化，需求文档没有及时维护，相应功能的逻辑已经变化，或是交互变化，或者功能已经删除等等，大模型再牛也无法预判这样的情况，只能根据需求文档进行处理。

2，页面交互描述不清楚。比如，有些功能如删除，编辑按钮，需要将鼠标移动到相应的项目上，才能显示出来。需要文档中不会描述的这样详情的，结果大模型生成的用例，无法找到编辑或是删除按钮，也是无法生成可通过的用例的。