企业官网建设流程全解析

写自动化测试这行的人，应该都有过被前端改版逼疯的经历：早晨还在跑的通宵回归，第二天一上班就红成一整片，跑过去一看，原来是按钮的class从btn-primary改成了btn-new-primary。你维护的不是被测系统，而是这个系统前端的情绪。我最近因为手上的模拟项目X被迫重新评估链路，开始把Midscene.js引入原有测试流程，才发现“AI视觉自动化”不是营销词，它是真的能把“写脚本”这件事，变成“写期望”。这篇文章不会跟你聊概念，只讲实际到手怎么用、坑在哪、替代了哪些原有工作，以及什么时候你不该用它。

1. 为什么传统UI测试会让你抓狂

我先花点时间把问题讲透，因为你不理解旧方案为什么痛，就不会明白Midscene.js那套思路到底在解决什么。

1.1 三个最让人头疼的痛点

第一个痛点是选择器脆弱。无论是早期基于坐标的工具，还是现在主流的DOM选择器方案，本质上都在做一件事：告诉工具“你要点的那个元素长什么样、在哪个层级”。于是你写出来的代码里全是#root > div.container > div.row > button.submit-btn这种长表达式。有人会说你用># 环境变量示例 export MIDSCENE_MODEL_API_KEY="你的密钥"

如果你是在本地开发机调试，也可以先把页面起在一个本地端口上，然后在脚本里指定目标地址。这里有一个关键点：视觉模型和文本模型是两回事，你最好选一个视觉理解能力强的模型服务，否则在识别复杂页面元素时会经常理解错。我实测下来的感受是：模型能力的下限决定了框架好不好用，选择能力足够的模型，测试稳定性才有保证。

2.2 浏览器驱动的连接方式与调试端口

Midscene.js支持无头浏览器和真实有头浏览器两种模式。做本地调试时，我强烈建议你用有头模式，因为你能实时看到Agent在页面上做了什么操作，这对于观察意图理解是否正确非常有帮助。它通过远程调试协议与浏览器通信，所以你需要在启动浏览器时带上调试端口参数。

实际启动一个带调试端口的浏览器时，我一般用命令行指定--remote-debugging-port，具体端口号只要不冲突就行，比如9222。启动之后，你可以先在这个浏览器里手动打开你的目标页面，再执行Midscene.js脚本，这样它就会直接接管当前这个已经打开着页面的浏览器实例。

# 启动带调试端口的浏览器（这里以常见内核浏览器为例） 浏览器可执行文件路径 --remote-debugging-port=9222

这个操作看起来不起眼，但对调试体验的提升是决定性的。因为传统E2E测试跑挂了，你只能去看日志和截图，而这种方式下你能直接在浏览器里回放Agent的每一步动作，甚至中途手动干预页面状态。我后来很多难复现的问题，都是靠这个有头模式调试解决的。

2.3 最小用例跑通与目录组织

写一个完整的最小用例很简单。打开浏览器、导航到目标页面、执行动作、断言结果。这里我把目录组织推荐为：tests/放用例，helpers/放公共初始化代码，这样后续用例多起来不会挤在一起。跑通之后，你会看到终端里输出每一步Agent的执行过程，包括它理解到的页面内容、它准备点击的坐标区域、执行后的页面截图。这一段输出对理解工具到底“看到了什么”特别重要。

注意：第一次跑通后不要急着写复杂用例。先用一个简单页面摸清模型在什么情况下会误判，这是你后续所有稳定性的基础。

3. 从“写脚本”到“写意图”：核心API实战

Midscene.js最有价值的部分是它提供了一套用自然语言驱动的API，让你真正把测试意图直接说出来。

3.1 用自然语言执行交互动作

核心方法是agent.action，你可以把一段行为描述直接传进去。比如我想做一个“填写用户名和密码，然后点击登录按钮”的操作，传统写法你需要定位三个元素，而这里的写法就是一句中文描述。

await agent.action('在用户名字段输入admin，在密码字段输入123456，点击登录按钮');

这句描述看起来是在跟人说话，但Midscene.js会把它变成浏览器行为。它能识别“用户名字段”是哪个输入框，识别“登录按钮”是哪个按钮，然后执行点击、键盘输入等真实操作。眼尖的读者可能已经发现，这里不再有selector了，你描述的是业务含义而不是技术路径。

实际用的时候我常犯一个错误：把描述写得太模糊。比如一个页面上有多个“确定”按钮，你直接说“点击确定”，模型会困惑。你需要稍微补充一点上下文，比如“点击弹窗底部的确定按钮”或“点击表单右上角的确定按钮”。这不是框架的问题，是意图本身的歧义问题——你跟人说话时不也会带上上下文吗？多写一两个限定词，稳定性提升非常明显。

除了action，你还可以配合agent.openPage这类方法控制页面导航，组合起来就是一个完整的操作流程。执行过程中，Agent每做一个动作前，都会先截取当前页面状态，再由模型预测动作结果，这一步保证了操作不是盲目的，它会根据页面反馈调整自己的行为。

3.2 智能断言的三个层次

断言是测试里最核心的部分。Midscene.js提供了agent.assert方法，你直接描述“页面上应该出现什么”“某个区域的文字应该是什么”，剩下的事交给模型判断。

我从实操中总结出来，它的断言能力可以分三个层次。第一层是最简单的存在性断言，比如“页面上出现了购买成功四个字”，这种断言覆盖了绝大多数传统UI断言场景。第二层是语义化断言，比如“购物车数量增加了1”，这就比较有意思了，因为它需要模型对页面前后状态做理解。第三层是状态一致性断言，比如“登录后用户名显示在页面右上角”，这种断言往往能发现跨模块的数据对接问题，而传统选择器方式写起来非常复杂，涉及跨层级取数。

await agent.assert('页面中央出现提示文字：保存成功');

这里要注意，视觉断言是一个概率判断，不会100%准确。所以不要把所有断言都丢给模型，能通过接口层或者DOM快速验证的强断言，依然建议用传统方式。视觉断言最适合的是那些“人眼一眼就能看出来”的UI正确性验证，比如某个提示是否出现、布局是否错位、按钮文案是否正确。说白了，视觉断言是给你省力的，不是给你甩锅的。

3.3 观察与报告：让测试结果可阅读

传统测试框架的报告，无非就是通过、失败、日志、截图。Midscene.js的观察接口agent.inspect会让你对“测试资产”有新的认识。这个接口可以在执行过程中随时记录当前页面的理解结果，输出一种结构化的页面描述。你可以把它当作测试过程中的业务快照。

我现在的习惯是，在每个主流程的关键节点都会调用一次观察，把这些快照收集起来作为测试报告的一部分。比如在下单流程中，确认订单页、支付成功页、支付回调页各观察一次。跑完测试后，你不光知道“通过了”，还能顺着这个业务快照序列，看到每一页当时的关键数据是否正确。这类报告对测试人员分析问题、开发人员定位Bug都有很大帮助。

和截图不同，观察输出是机器可读的，这意味着你甚至可以在流水线里把多个用例的观察结果合并，生成一份真正的业务校验报告，而不只是简单的“通过了”三个字。这个能力用熟了之后，你会发现测试结果本身变成了一种可追溯的业务数据。

4. 在真实项目里如何落地：我踩过也验证过的玩法

方案能不能落地，不是看单个API多好用，而是看它在真实约束下怎么存活。

4.1 回归测试中的典型玩法

我接手手里的模拟项目X时，最迫切需要解决的就是回归测试。项目里优化了一个查询列表页的加载逻辑，涉及页面结构调整，原有12条用例全部需要修选择器。用Midscene.js重构后，我做的第一步不是把用例全量翻译过来，而是把高频的5条主流程用例用自然语言重写，跑通后拿线上版本对比。

重写过程中，我发现视觉自动化的一个关键心理变化：以前改版怕的是改完测试崩，现在改版怕的是改完后“用户真的看不清按钮”。两类恐惧的对象不太一样，后者更接近产品本来该关心的事情。重构后的回归用例稳定跑了一周，只在一次前端把信息提示改为弹窗展示时失败，而那次失败恰好是真实交互变化，测试抓得很准，没有误报。

4.2 数据驱动与批量执行的组合方式

视觉自动化能不能做数据驱动？能，而且做法很自然。因为你的用例主体是一段自然语言描述，数据只是填充进去的变量。我在登录用例里做了三组不同账号的批量执行，每组只是往描述里拼不同用户名。关键是把执行结果分类收集：登录成功走一个断言分支，登录失败走另一个提示校验分支。

const accounts = ['正常账号', '冻结账号', '密码错误账号']; for (const account of accounts) { await agent.action(`输入${account}相关信息，点击登录`); await agent.assert('页面出现与本次状态匹配的提示'); }

这里有个细节，不同状态的断言因为页面表现差异较大，模型反而容易区分，不太会误判。让我印象更深的是，这类数据驱动场景下，传统工具每个账号都要写一遍完整的选择器链路，而这里核心逻辑几乎可以复用，只换描述里的关键信息即可。

4.3 多端与多环境适配

跨浏览器兼容是很多团队的痛点，但Midscene.js目前的主要形态还是接在有调试能力的浏览器内核上，所以如果你要严格验证WebKit、Gecko等多引擎的兼容，它不是万能药。我的建议是：经典的兼容性矩阵测试，你继续用原来的工具；但那些“用户核心流程在主流浏览器上能正常走通”的高频验证，它完全能胜任。

多环境适配方面，我在开发、测试、预发三个环境跑同一套用例时，发现一个现象：不同环境下同一按钮的文案可能有细微差别，比如预发环境多了“测试”两个字。以前这种差异会让断言直接失败，现在自然语言断言可以灵活处理。但要注意，灵活是双刃剑，如果你对文案有完全精确的要求，还是得用传统精确匹配。具体怎么取舍，取决于你是“验证UI应正确显示”还是“验证数据链路是否正确”。

4.4 与传统自动化框架的共存策略

这是我最想说的一部分。蓝图固然美好，但现实是一个团队往往已经有大量存量自动化资产，不可能为了引入新技术把资产全部推倒。

我的共存策略很简单：把Midscene.js定位成“智能UI验证层”，传统工具定位成“接口与数据校验层”。比如下单流程中，商品选择、地址填写这些涉及复杂DOM结构的UI操作交给视觉自动化；而价格计算、库存扣减这类精确数据校验，继续用接口层直接验证。这样既降低了UI操作部分的维护量，又保证了数据校验的绝对精确。两套体系之间通过同一个测试报告平台汇总结果，互不干扰。

从执行管理的角度看，也不建议把两种方案的用例混跑在同一个调度任务里，因为失败原因的分类会变得很混乱。你可以让传统用例跑接口、核心流程冒烟，让视觉用例跑页面交互、UI反馈，两个任务独立调度，各自维护。这样，任何一次失败，团队都能马上知道是哪一层出了问题，不至于对着日志猜半天。

5. 常见问题与排查实录

再好的工具，在实际使用中也一定会遇到各种问题。这一节我把实际碰到的典型坑都列出来，每个都带排查思路。

5.1 识别失败集中爆发

最典型的失败场景是：页面稍复杂时，Agent会对目标元素理解不准。比如页面同时存在一个侧边导航栏和一个顶部工具栏，你描述“点击用户头像”时，模型可能把侧边栏上一个相似图标误认为目标。遇到这种情况，我的排查步骤是：先开启有头模式把执行过程录像回放，看模型到底把鼠标点到了哪里；如果经常点偏，就说明你的描述缺少空间限定，加上“右上角”“弹窗内”这类位置词，往往立刻就好。

另一个常见原因是页面尚未完全加载，Agent就抢跑。虽然它能理解视觉内容，但页面元素都没渲染出来时，它也巧妇难为无米之炊。我的处理方式是在关键跳转后加一个视觉等待条件，Midscene.js本身支持你描述一个等待条件让它先确认页面状态，这是比传统sleep更优雅的方案，但需要你主动使用。

5.2 大模型输出不稳定的应对

同样的描述，模型每次识别出来的细微动作可能不完全一致。比如它的点击坐标每一次有若干像素的浮动，这在大多数场景没影响，但在某些需要精确拖拽、精确缩放的操作里，就可能出问题。我开始也担心这个，但实践下来看，日常业务动作点击、输入、勾选这些，浮动几乎没有影响，因为真实用户操作本身就是有一定容错范围的。

如果真遇到对精确度要求极高的操作，我的建议是别硬用自然语言，直接在描述里加上像素级坐标，或者干脆把这一步改成传统代码。大模型是来解决复杂场景的，不是来包办一切的。你的工具链里永远应该给精确控制留一个位置，跟你要不要用它没有关系。

5.3 执行速度慢与成本控制

视觉自动化因为要对每一步操作进行截图加模型推理，速度天然比传统选择器方案慢。我实测一个包含20步操作的主流程，跑完大概需要一到两分钟，这在回归场景能接受，但在全量冒烟里会显得慢。

成本控制是更要重视的部分。模型的token消耗和你的操作步数成正比，用例越多、执行越频繁，账单增长越快。我给团队定了三个原则：第一，只在UI操作易变、且视觉验证价值高的场景使用；第二，建立用例分级，高频回归跑精简集，全量只跑每日流水线；第三，充分利用观察接口复用页面理解结果，减少重复推理。按这个原则跑下来，月度成本完全在可控范围内。

5.4 网络与环境的坑

视觉自动化方案的模型访问是需要网络服务的，这部分跟本地测试环境之间的连通性，经常成为隐性坑。我建议把API请求的超时时间设置得合理一点，同时做好失败重试。另外一个很容易被忽略的环境坑是：CI上跑的浏览器默认是在无头模式下的，页面渲染结果可能与有头模式存在差异，比如某些字体加载不全、某些动画性能不同。首次在CI上跑全量用例时，一定要先拉通几条典型用例做渲染对比，确认没有环境差异导致的误报，再放心上量。

写在最后：一个关于取舍的心里话

这套方案我连续用了差不多两个月，我最大的感触不是“AI真厉害”，而是“原来我们应该站在用户视角来写测试”。我们以前花了太多精力去理解页面的技术结构，却忘了用户根本不关心你用的是哪个框架、哪个类名。Midscene.js给我最大的帮助，是让我把注意力从“工具怎么定位元素”收回到了“业务流程到底是什么”。但我也会认真提醒你：它不是万能药，尤其那些对精确性要求极高的校验场景，该交给精确代码的时候别犹豫。如果你准备引入，不要一上来就全量替换，挑一条你最痛的主流程，先写成视觉用例，跟原有脚本并存跑两周，看看维护成本差异，你会有一个很直观的判断。