脚本跑得好好的，某天早上突然报错。查了半天代码没发现问题，最后发现是 App 更新了一版，把某个按钮挪了地方。
这件事在有脚本的团队里几乎必然发生。理由很简单：App 是别人在维护的，它们的改版节奏不受你控制。
改版到底破坏了什么
先把问题说准。改版破坏的不是你的业务逻辑，是你的脚本用来找目标的那套坐标。
脚本定位元素通常靠两样东西：位置和标识。
位置就是「第几行第几列」。截图上量出来的坐标，写死在脚本里。界面一动，坐标全废。
标识是控件 ID 或者控件路径。理论上比坐标稳，但 App 改版经常顺手把这些也重新生成一遍——尤其是前端框架升级的时候，控件 ID 会成批变化。
所以失效的表现往往很突然：昨天还好好的，今天全挂。中间没有人改过脚本，但是运行环境变了。
一个更隐蔽的问题：静默更新
比「你知道它改版了」更麻烦的是「你不知道」。
很多 App 是静默更新的，手机连上 WiFi 的晚上就自动升级了。第二天你照常跑脚本，报错，然后花时间排查一个你根本不知道发生过的变化。
这在校验上有实际影响：你没法靠「最近有没有更新」来判断问题来源。 只能从报错反推。
换成看屏幕判断，变化就消化掉了
iEasyRun 的定位方式不一样：它不记录坐标，而是看屏幕上有什么。
具体来说，执行每一步之前，它先读当前页面上的内容——有哪些元素、各自写着什么字，然后判断哪一个是目标，再点下去。
这个差别在改版场景里的体现很直接：
| 变化类型 | 写死坐标的脚本 | 看屏幕判断 |
|---|---|---|
| 按钮挪位置 | 失效，要重配 | 正常 |
| 菜单层级变了 | 失效，要重配 | 正常 |
| 控件 ID 重新生成 | 失效，要重配 | 正常 |
| 页面多了一个弹窗 | 大概率卡住 | 通常能自己关掉 |
| 按钮文案改了 | 不受影响 | 要补一句描述 |
| 流程本身多了一步 | 失效 | 要改流程 |
前四行是改版最常见的形态，正好是它的强项。后两行是真正需要你介入的，而它们的频率远低于前四行。
什么情况下还是得动手
诚实地说，有两种。
- 文案变了：按钮从「导出」改成「下载」，或者菜单从「我的」改成「个人中心」。这种变化它认不出来，因为它就是按文字找的。改法很简单：在描述里把新说法加进去，比如「点导出（有些版本叫下载）」。
- 流程本身变了：原来点了导出直接下载，现在多了一个「选择格式」的确认步骤。这种不是识别问题，是业务逻辑变了，需要你在描述里补上这一段。
这两种都属于明确的、一次性的修改。改完就完事，不会像坐标那样每改一版界面就要重来一轮。
还有一个提醒：升级之后建议主动跑一次验证。虽然大概率不用改，但跑一次能确认。低频任务尤其要这么做——它可能两个月才跑一次，你不验证的话，问题会在最不方便的时候暴露出来。
那原来的脚本要不要扔
不用扔。
判断标准是变化频率：
- 每天都跑、流程两年没变、对速度敏感 → 脚本更省资源，继续用
- 界面版本迭代快、或者你懒得维护 → 用描述跑
- 介于两者之间 → 先留着，等它下一次失效的时候再决定
实际用下来，很多团队是混着用的：核心的高频流程用脚本，外围的、容易变的、低频的活用描述跑。两种方式在同一台手机上并存，不冲突。
减少改版带来的返工
两条习惯，能挡掉大部分维护工作。
- 把入口描述成「做什么」，不是「在哪里」：「打开我的订单」比「点右下角那个图标」稳得多。前者说的是目的，后者说的是位置——而位置正是会变的东西。
- 把容易变的部分做成参数：句式、关键词、目标店铺这些每次都可能不一样，做成调用时能填的参数，而不是写在流程里。改版的时候你只需要改动的那一处，不用通读整个流程。
出问题了怎么查
先看 执行历史 里那一步的截图。
这一条比读报错文字有用得多。报错通常只写「找不到元素」，但截图会告诉你当时停在了哪个页面。改版导致的问题，十次里有八次的形态是一样的：停在一个你从来没见过的新页面上。
看到那个页面，你就知道该补哪一句描述了——加一个「如果出现 XX 页面，先点跳过」。
软件完全免费，装在自己电脑就能跑。脚本失效这件事不会消失，但可以从「每次改版都要重新调一遍」变成「偶尔补一句话」。想看更多场景做法，可以读 移动端 UI 自动化测试 或 不会写代码怎么做手机自动化。
常见问题
- 脚本失效最常见的原因是什么？
- 界面改版占了大多数。按钮挪了位置、菜单层级变了、弹窗多了一步、控件 ID 重新生成——这些都不影响业务逻辑，但会让写死坐标和控件路径的脚本找不到目标。
- 为什么看屏幕决定的做法不受影响？
- 因为它判断的依据是语义而不是位置。脚本认的是「第 320 行 65 列的像素」，它认的是「写着导出两个字的那个按钮」。按钮换到哪儿，语义没变，它就还找得到。
- 什么情况下它也会失效？
- 两种情况：一是文案变了，比如按钮从「导出」改叫「下载」；二是流程本身变了，比如多了一个确认步骤。前一种补一句描述就行，后一种要改流程。
- 改版之后要重新跑一遍验证吗？
- 建议跑一次。虽然大概率不用改，但跑一次确认比等业务出问题再发现要好。低频任务尤其要注意，因为它可能两个月才跑一次。
- 原来的脚本要不要全删掉？
- 不用。高频、流程完全稳定、对速度敏感的活，脚本依然更省资源。两种方式可以并存，同一台手机上都能用。
- 错误提示只写「找不到元素」，怎么定位？
- 先看执行历史里那一步的截图。界面对不对、是不是停在了意料之外的页面，看一眼就知道。改版导致的问题基本都是「停在了新出现的页面」这种形态。
- App 自动更新也会影响吗？
- 会。很多 App 是静默更新的，你不一定知道改了。这恰恰是靠位置定位最吃亏的地方：变化发生在你没注意的时候。
- 怎么减少改版带来的维护工作？
- 两条：把入口描述成「做什么」而不是「在哪里」；把容易变的部分做成可填的参数。做到这两点，一次改版通常只需要改一两句描述。