我受够了Appium Inspector,于是自己做了一个更狠的

最近一年 AI 自动化比较流行。

你在输入框里写一句自然语言：打开 App，登录，输入账号密码，点登录，确认首页出现。

AI 把这句话翻成 Appium 能执行的点击、输入、等待指令，手机自己动起来。

演示的时候确实很顺。

问题是，今天跑通了，明天同一句用例再跑，可能就挂了。页面看起来没改，手机没换，你甚至没动那条用例。

结果就是不一样。

所以当我拿出 EchoBench 时，最常被问的一句话是：市面上类似工具这么多，为什么还要再做一个？

这个问题很实在。重复造轮子没有意义。

先说结论：EchoBench 把精力放在执行链路的可解释和可复现上。

用大白话讲，它像一个专门记录手机操作的本子。

人先在 Android 或 iOS 设备上手动走一遍，点哪里、输入什么、滑多远、什么时候返回，工具都记成步骤。

录完以后，每次回放的是同一份操作记录。

— 先把设备画面放进浏览器，人和工具看到的是同一块屏幕。

本文看点

我最近一直在想，这种不稳定到底从哪来。

自然语言很适合描述人的意图，测试执行需要的是确定路径。

很多方案会在执行的时候，才让 AI 把自然语言翻译成动作。每次翻译，它都可能重新选定位器、重排步骤、调整等待。

模型每次理解得不太一样，页面每次加载得也不太一样。两个小波动叠在一起，结果就是时而成功，时而失败。

这种失败最难受的地方，是你很难复现。它可能连着跑 10 次都过，第 11 次突然挂。

测试最怕这种不确定性。

写用例的人可以先把流程想清楚，再在设备上走一遍。

录下来的内容很具体：点击哪个控件，输入什么值，等待哪段文本出现，页面稳定后再执行下一步。

每一步还可以配置超时、重试、候选定位器和失败策略。流程能保存成 YAML，也能导出成 WebdriverIO、Python 或 Java 脚本。

回放的时候，工具执行的是这份固定记录。它不需要每次重新猜一遍“这句话大概是什么意思”。

测试执行需要同一份输入，得到可以解释的结果。

— 录制步骤、断言和候选定位器。

手机页面里经常有一堆长得差不多的控件。

两个叫「确定」的按钮，一个在弹窗里，一个在页面底部。一排商品卡片，文字一样，顺序却会变。

如果定位器由模型临场生成，它往往只能根据当下页面猜一个。页面一刷新，可能就点到别的地方。

EchoBench 每次录制点击，都会同时生成几套候选定位方式，再当场问设备：这个定位到底命中了几个控件，命中的范围是不是刚才点的那个。

如果候选同时匹配多个元素，或者唯一命中却落在别的控件上，它会降级，也会把风险标记亮出来。

主定位失效时，工具只会在唯一安全候选里降级。遇到多个同名控件，它不会为了把流程跑完，就随便点第一个。

讲道理，这个细节很枯燥。可测试脚本的命，很多时候就卡在这里。

工具不能承诺页面永远不变。它至少应该告诉你，哪一步已经站在薄冰上。

— 元素树可以展开原生控件层级，也能按节点精确生成定位器。

移动端测试还有一类问题，单看代码永远看不出来。

同一个按钮，在这台手机上露出来了，在那台手机上被键盘挡住。同一个输入框，Android 正常，iOS 的焦点却跑了。

EchoBench 的多端同步，可以让你在一台设备上操作，其他参与同步的设备一起执行。每台设备的实时画面和同步开关都能单独控制。

它使用相对坐标广播，适合快速复现同一操作，做尺寸、系统版本和输入法的对比。跨平台布局差异很大时，它也会明确提醒风险。

服务默认只监听本机地址，设备、日志、草稿和 AI 配置都留在电脑上。测试数据和设备控制不需要先经过一朵云。

代价也有。你得自己准备 Node.js 22.12+、Android SDK 或 Xcode，iOS 还只能在 macOS 上跑。第一次配环境并不轻松。

换来的是，排查问题的时候，东西都在手边。

— 操作一台，其他设备一起执行。

市面上的产品大致分几类，各自都有很成熟的强项。

图像识别类工具更适合游戏、Canvas 和强视觉页面，EchoBench 当前不做视觉识别。Katalon 这类商业套件在报告、对象库和测试治理上更完整。

单个能力都不算绝对独家。EchoBench 的差异，是把本地录制、定位器实时校验、多端复现、脚本导出和可选 AI 放进同一条执行链路。

你可以先看设备画面，再录一条步骤。每一步都能看到候选定位器和风险，跑不动时能回到现场，需要离开工具时还能把 YAML 和脚本带走。

边界越清楚，越不像重复造轮子。

EchoBench 里也有 AI，但我把它放在一个很克制的位置。

当前时间线里的步骤和断言，可以交给 AI 整理成 CSV 测试用例。标题需要人填，接口和 Key 由用户自己配，也支持本地模型。

AI 不碰设备，不执行回放，也不做所谓的自愈。

这个选择听起来不够热闹。

一旦让 AI 接入每一次执行，失败原因就会多出几层：页面变了，定位器错了，模型这次理解偏了，还是等待时间又不一样了。

自动化最怕的，是在该确定的地方塞进不确定性。

把 AI 放在生成阶段，把执行阶段做得可解释、可回放、可审阅，出了问题才知道该修哪里。

— AI 只整理当前步骤和断言，不接管设备操作。

AI 把“写一句用例”的门槛打下来了，也把“为什么这次又挂了”的问题放大了。

生成能力可以很快，执行稳定性只能一点点工程化。

我以前写一条自动化脚本要半天，现在 AI 十分钟能写一套。真正麻烦的事挪到了后面：哪条能跑，为什么挂，明天还能不能跑。

我是真的觉得，接下来自动化工具的分水岭，会落在可验证性上。

你能不能看见这次点了哪个控件，能不能知道为什么降级，能不能复现失败，能不能把流程带走。

这些事没有那么像未来，却决定了自动化能不能真的落地。

EchoBench 想做的，就是把这些东西摊开。

它不承诺页面永远不变，也不假装每一次都能自动救回来。它把每次点击、每个候选、每次降级和失败原因摆到台面上，让你自己决定下一步。

AI 可以帮你写第一版。

稳定性，还是得靠工程。

项目地址：

https://github.com/Echoxiawan/echobench

Apache 2.0 开源，欢迎从一条能回放的流程开始。