UI 自动化测试最难处理的往往不是“点击按钮”，而是怎样稳定找到按钮、判断页面何时真正就绪，以及失败后快速确认问题属于界面、接口还是数据。腾讯 APIJSON 生态项目 AutoUI 试图把这些环节连起来：零代码录制与回放、像素级定位、自动等待、UI 与数据双重断言、前后端问题归因，以及将完整场景导出为接口用例。
项目介绍给出了“3 像素内自动精准定位”和“2 毫秒内自动精准等待”等指标。工程团队在采用前，仍应结合设备分辨率、系统动画、网络条件和测试样本验证这些数字，不宜直接把宣传指标等同于所有环境下的服务等级承诺。
稳定性不只取决于元素定位
传统 UI 自动化通常依赖控件 ID、XPath、可访问性树或固定坐标。它们各有明显边界：
- 控件 ID 可能随版本调整，跨端页面也未必提供一致标识。
- XPath 对层级变化敏感，一个无关容器就可能让路径失效。
- 固定坐标容易受到分辨率、DPI、横竖屏和安全区域影响。
- 只做截图匹配，又可能被字体渲染、主题和动态内容干扰。
AutoUI 强调像素范围内的自动精准定位，其价值不只是把点击误差缩小到几个像素，更重要的是减少录制环境与回放环境之间的偏移。实际落地时，仍应固定测试设备基线，包括系统版本、分辨率、字体缩放、语言、主题和动画设置。否则，再精确的定位算法也要面对不断变化的输入画面。
等待机制同样决定稳定性。固定执行 sleep(3) 会让快速页面白白等待，也可能在慢速网络下提前结束。更合理的模型是等待一个可观察条件，例如目标区域出现、加载指示器消失、接口返回成功，或者页面数据与接口数据达到一致。
从“页面看起来正确”升级为双重断言
只验证按钮能点击、文字能出现，并不能证明业务结果正确。一个订单页面可能展示了“提交成功”，但后端并未落库；也可能接口已经返回正确数据，前端却读取了错误字段。
AutoUI 将 UI 断言和数据断言放在同一场景中，这使失败结果更容易分类：
| UI 结果 | 接口或数据结果 | 优先排查方向 |
|---|---|---|
| 正确 | 正确 | 场景通过 |
| 错误 | 正确 | 前端渲染、状态管理或字段映射 |
| 正确 | 错误 | UI 可能展示缓存或伪成功状态 |
| 错误 | 错误 | 后端、测试数据或上游依赖 |
这种归因不是数学证明。例如网关缓存、异步任务和最终一致性都会改变判断结果。但它可以缩短初次排查路径，让开发者先查看更可能出错的一侧。
可以这样组织一条可迁移的测试场景
下面是一个可改造的伪项目示例，用于表达录制场景应保存哪些信息。这不是 AutoUI 官方文件格式；实际字段需要替换为项目支持的配置或导入格式。
name: create-order-and-verify
environment:
base_url: http://127.0.0.1:8080
device: android-emulator-1080x2400
locale: zh-CN
steps:
- action: open
target: app://orders/new
- action: input
target:
visual_anchor: 商品名称
fallback_accessibility_id: product-name
value: mechanical-keyboard
- action: tap
target:
text: 提交订单
tolerance_px: 3
- action: wait
until:
text_visible: 提交成功
timeout_ms: 5000
assertions:
- type: ui_text
expected: 提交成功
- type: api_json
request:
method: GET
path: /orders/latest
expected:
product: mechanical-keyboard
status: created
export:
api_case: build/create-order.http
这个场景将视觉锚点、备用可访问性标识、最长等待时间和数据断言放在一起。tolerance_px 可以表达像素容差，但是否支持该字段、如何计算误差，应以实际工具能力为准。
如果平台导出了接口场景，可以先用 curl 在 CI 中独立复核后端结果。运行前需要把地址、令牌和请求体字段改成测试环境的真实值：
export BASE_URL="http://127.0.0.1:8080"
export TOKEN="replace-with-test-token"
curl --fail-with-body --silent --show-error \
-X POST "$BASE_URL/orders" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"product":"mechanical-keyboard","quantity":1}'
curl --fail-with-body --silent --show-error \
"$BASE_URL/orders/latest" \
-H "Authorization: Bearer $TOKEN"
在 APIJSON 环境中，请求结构可能采用查询对象而不是传统 REST 路径。可以这样实践，但必须按照目标服务的 APIJSON 表结构和权限规则修改：
curl --fail-with-body --silent --show-error \
-X POST "http://127.0.0.1:8080/get" \
-H "Content-Type: application/json" \
-d '{
"Order": {
"product": "mechanical-keyboard",
"status": "created"
}
}'
把导出的接口用例放到 UI 回归之前运行，可以提前发现服务不可用、鉴权失效或测试数据缺失。接口检查通过而 UI 场景失败时，再集中检查渲染、交互和客户端状态，排查范围会明显缩小。
接入流水线时要保留证据
一条可维护的 UI 测试不应只输出“通过”或“失败”。每次失败至少应保留：
- 操作前后截图，以及实际点击坐标和匹配区域。
- 等待条件、实际等待时间和超时原因。
- 关键接口的请求、状态码和脱敏响应。
- 设备型号、分辨率、DPI、系统版本和应用版本。
- UI 断言与数据断言各自的结果。
涉及用户数据、令牌和订单信息时，日志与截图需要脱敏，并设置访问权限和保留周期。录制测试还可能捕获输入法建议、通知栏内容或其他应用信息，不能直接把原始产物上传到公共制品库。
采用前的验证清单
建议先选择 5 到 10 条高价值流程做小规模验证，覆盖登录、列表加载、表单提交、异常提示和数据回查。重点记录定位成功率、平均回放时间、误报率，以及失败归因是否真的减少了人工排查时间。
同时要分别测试不同分辨率、深浅主题、弱网、接口超时和页面动画。若团队准备依赖“3 像素定位”或“2 毫秒等待”等能力，应要求可复现的基准条件，并在自己的设备池中重新测量。AutoUI 更值得关注的并不是单个速度数字，而是它是否能把录制、等待、双重断言、问题归因和接口用例导出组成一条可审计、可进入 CI 的测试链路。