上一篇我讲了，为什么 Android 测试值得先把 ADB 这层基础能力打好。这一篇继续往下走，不再讨论“该不该做”，而是直接讨论一个更现实的问题： 测试里最常用的 ADB 命令，到底应该怎么组织，才能真的变成可复用能力，而不是一堆散乱脚本。 一开始接触 ADB，容易走两个极端： 一种是把 ADB 当命令手册，谁要用就自己搜命令 另一种是过早封装成很重的平台，但底层动作根本没梳理清楚 这两个方向最后都会出问题。 前者的问题是复用差、排障...
一提到 Android 自动化，第一反应就是 Appium、UI 框架、云真机平台，或者直接想到“移动端自动化门槛很高”。但如果从真实项目落地来看，更应该先把 ADB 讲清楚。 因为 ADB 不是一个零散命令集合，而是一套移动端测试最底层、最稳定、最容易被低估的工程能力。它解决的不是“高阶自动化炫技”，而是下面这些高频、反复出现的问题： APK 怎么批量安装和卸载 测试前怎么把设备状态拉齐 崩溃、闪退、无响应到底怎么快速留证 多台设备怎...
UI 自动化结果如果只剩一句 passed / failed，那它的价值通常非常有限。因为 UI 自动化和接口自动化最大的不同，是它的关键信息大量存在于“现场”里： 页面当时长什么样 卡在第几步 当前 URL 是什么 异常更像环境问题还是业务问题 如果这些信息没有被组织进结果展示里，维护者最终还是只能回到最原始的方式：本地重跑、边跑边看、猜到底发生了什么。 所以我一直把结果可视化看成 UI 自动化体系的一部分，而不是跑完之后顺手做个报告...
生产环境 UI 巡检和测试环境回归，表面上都在点页面，实际上是两套完全不同的系统设计题。 回归更关注： 覆盖率 变更验证 多路径组合 而生产巡检更关注： 是否低侵入 是否高信号 是否低噪声 是否能在失败后快速给出方向 如果把测试环境一整套 UI 回归直接搬去线上，通常只会得到两个结果： 巡检对线上形成扰动 大量告警没有决策价值 所以 UI 巡检的思路一直需要保持克制。不是不能测更多，而是必须先想清楚：哪些路径值得在生产环境里长期、自动、...
UI 自动化平台这个词很容易被做虚。说要做平台，最后做出来的其实只是一个页面： 选环境 点执行 跳 Jenkins 下载报告 这种东西当然有一点入口价值，但它解决不了 UI 自动化真正痛的地方。真实项目里，UI 自动化难的从来不是“怎么跑一次”，而是下面这些长期问题： 多环境、多角色怎么管 同一套脚本怎么支撑 smoke、回归、巡检 执行器怎么调度 截图、视频、trace 怎么统一沉淀 哪些 case 是高噪声脚本，哪些是真问题 哪些页...
UI 自动化最常见的标签就是“脆”。围绕这个词，最常见的判断是： UI 本来就不适合自动化 浏览器脚本天然不稳定 页面一改就没法维护 这些话不算全错，但也不够准确。治理过程里更容易看到另一件事：UI 自动化之所以脆，通常不是单一工具的问题，而是一组系统性波动源一起叠加的结果。 也正因为如此，它不是“修某条脚本”就能解决的问题，而要从定位、等待、数据、环境、场景选择、失败留痕等多个方面一起收敛。 一、UI 自动化为什么会脆通常把根因分成六...
如果要只挑一个最容易把 UI 自动化拖垮的问题，更可能选等待机制。因为很多脚本不是不能执行，而是执行结果随机。 最典型的症状是： 本地能过，CI 上偶尔失败 同一条脚本上午过、下午挂 多跑几次又好了 这种问题看起来像“环境抖动”，但真实根因很多时候是：脚本根本没有定义清楚“什么时候页面真的准备好了”。 所以等待机制不是语法细节，而是稳定性设计。 一、我为什么把等待看成状态建模，而不是时间控制把等待写成固定时间时，本质上是在赌时间： 点完...
UI 自动化里，最容易被低估、但又最直接影响稳定性的一个问题，就是定位。很多脚本之所以不可信，不是业务流程太难，也不是工具太差，而是定位策略从一开始就建在了不稳定的东西上。 定位判断可以先抓一条很简单的原则： 依赖样式和层级，脚本一定越来越脆 依赖业务语义和稳定标识，脚本才有长期可维护性 所以定位从来不是“会不会 XPath”的技巧题，而是测试资产到底建立在什么稳定性上的设计题。 一、我在真实项目里的定位优先级如果页面可以配合自动化治理...
如果从“完整 UI 回归框架”的角度看，chromedp 很难和 Playwright 正面对打，因为它本来就不是同类产品。它更像是一层浏览器控制能力，让你用 Go 直接驱动 Chrome DevTools Protocol。 这种定位很容易让它被低估。但如果你的主技术栈已经是 Go，或者你要解决的不是“做一整套 E2E 回归”，而是： 浏览器化探针 页面截图服务 登录可用性检查 内部工具里的页面控制 那 chromedp 反而会非常顺...
如果只是写一两条页面脚本，Selenium、Playwright 甚至录制回放工具都能把页面点起来。真正拉开差距的，不是“能不能点”，而是当 UI 自动化进入下面这些真实场景之后，谁更容易被做成一个长期可维护系统： 每个版本都要跑 smoke 每天凌晨跑回归 同一套系统要覆盖多个角色 失败后希望不重跑也能先判断大概问题 后续还要进 Jenkins、进平台、进告警链路 我真正开始偏向 Playwright，不是在它“新”的时候，而是在我越...