RPA元素定位怎么做，页面一改版自动化就全停了
运营把后台按钮挪了个位置，脚本第二天就趴窝。这类问题多数出在元素定位写得太死，跟流程逻辑没关系。这篇讲清定位失效的四种原因，坐标、路径、语义三种做法的取舍，怎么给每个交互点配一条兜底链，把定位从流程代码里拆出来单独管，以及哪些活儿本来就不该做自动化。
周三下午两点，财务在群里发了一句「昨天的对账没跑」。运营把后台页面上的一排按钮从上面挪到了下面，顺手把「导出」改成了「导出明细」。流程逻辑一个字没动，脚本却卡在第一步不动了。
做自动化的人听到这种消息，第一反应通常是流程写错了。这次流程逻辑一个字没动，问题出在我们当初写的那行「点哪儿」。
那行字叫元素定位。RPA元素定位这件事平时不响，一坏就全线停工。脚本跑得好好的没人看它，等页面改版，十来条流程一起趴窝，业务那边只会得到一个印象，自动化那个东西不稳定。
元素定位到底在定什么
机器人要点击一个按钮，它得有一行字告诉它按钮在哪儿。这一行字写得越具体，机器找得越准，也越容易在明天失效。
麻烦就麻烦在这类东西属于后台。平时跑着不出声，出事的时候往往正好赶上有人在等结果。
定位失效的四种原因
把原因分开看，处理办法完全不一样。
一，元素挪了位置。按钮从上面挪到下面，表格从左边挪到右边。响应式布局、窗口尺寸变化、系统缩放不是百分之百，都会造成同样的结果。
二，文字改了。「导出」改成「导出明细」，「提交」改成「提交申请」。这类改动对开发是顺手的事，对脚本是断线。
三，层级变了。页面多包了一层容器，中间插了个运营位，或者表格从原生表格换成了用 div 画出来。原来看得见的那条路径断了。
四，加载方式变了。原来一个页面直接打开，现在改成弹层、iframe、或者翻页懒加载。元素明明在，人眼也看得见，脚本就是够不着。
前两种最常见，第三种最费眼睛，第四种最容易被误判成脚本没跑。RPA元素定位写得越依赖具体位置，这四种原因就越容易撞上。
坐标、路径、语义，三种做法的取舍
定位方式大体三种，按稳不稳排一下。
绝对坐标。点屏幕第 400 个像素、第 250 个像素。写起来最快，换一台显示器就废，分辨率一变全废。远程桌面和虚拟机里分辨率不定的时候，这招基本等于每周重录一遍。日常业务系统很少适合用。
DOM 路径。找页面上第几个 div 的第几个 span 的第几个按钮。精度够用，也够脆。开发加一层容器，路径末尾的编号就得改。一条流程几十个定位，全改一遍是几小时的事。
语义定位。按按钮上的文字、控件的角色类型、或者旁边那句说明去找。「导出明细」这几个字改不改都无所谓，只要它还是那一个按钮。这层最稳，代价是速度慢一些，同一个页面上真有重名元素时，还得靠别的条件再筛一次。
成熟的做法是三层叠着用。主力用语义，语义对不上时退到稳定属性，比如元素上没被前端框架改掉过的 data 属性，或者它绑定的业务编号，再对不上才用图像匹配兜底，最后一层留给人工。
给每个元素配一条兜底链
这一节大概是全文最值钱的地方。RPA元素定位做得好不好，不看单条定位写得多妙，看每个交互点有没有配套的兜底链。
链子长这样。目标元素找不到，先换一种定位方式再找。两种都不行，切图像匹配。图像也匹配不上，就把这条流程挂起，记下时间、页面、屏幕截图和原本打算做的动作，交给人。
最后一步经常被当成失败，其实它是设计的一部分。人接过来看一眼截图，点一下，两分钟解决，比让流程硬撞到超时然后报一堆看不懂的错强得多。异常处理写到这里，流程才是能长期跑的，而不是演示那天能跑。
图像匹配这一层要格外小心。找不到元素，流程会停下来等人；图像匹配错了，流程会点到一个看起来很像的地方去。前者只是耽误事，后者可能把数据填进错的单子。所以图像模板要跟着系统主题和分辨率一起管，匹配时加上置信度门槛，宁可判失败也别赌。
挂起之后还有两件事得做。一是把失败攒成一张表，哪天哪个元素失效、失败几次、最后是人工点的还是压根没做，一目了然。二是这条元素得有人认领，改版的人得知道有东西在依赖他。
定位器要单独管起来
再讲一件直接影响自动化脚本维护成本的事。把定位从流程代码里拆出来。
拆出来之后，一个元素的定位就是一条记录。元素叫什么名字，目标在哪个页面，主定位怎么写，备定位怎么写，最近一次确认能用是哪天。
好处很直接。改版的时候改一处，不是在几百行流程代码里逐个找。间接好处更大，页面改版自动化失效的时候，你知道该看哪张表，而不是去翻日志里那句元素未找到到底指的是哪个元素。
还有一点容易漏。定位表要跟着代码一起版本管理，谁改的、为什么改、什么时候改，都留痕。不然半年后没人知道当初为什么把这个定位换掉，改回去还是不改，两边都有理。
改这张表的人应该是流程负责人。页面是业务在用，改版也是业务提的需求，让写流程的人去猜他们打算改成什么样，多半猜错。流程负责人手里有业务那边的信息，他知道这次改版动了哪几个按钮，也知道哪些按钮暂时不会动。
改版来了先止损
页面改版是必然会来的，早来晚来而已。来了之后处理顺序建议这样。
先跑一遍全量，把失效的元素一次找齐。零散修很容易陷入修一个冒一个的循环。
然后分清两类失效。页面挪了位置，属于定位要改。流程本身变了，比如原来导出的是明细现在是汇总，属于业务变了。两种混在一起处理最容易出错。
接着把确实要改的定位，按兜底链从最语义的一层开始补，别一上来就用图像匹配。图像匹配能把流程救回来，下次改版还会再救一次，只是把它推后。
页面改版自动化失效很少在一天之内全部暴露。前几天往往零星报错，被当成偶发问题忽略了，等成片停下来，已经过去两天。
所以值得每天做一次巡检。挑两三条关键流程，每天空跑一遍，只看它能不能走到第二步，花不了几分钟。改版带来的失效通常第一天就露了头，当时被当成偶发问题放过去，等到成片停下来，已经过去两天。
最后把这次改版的信息同步给上游。以后页面要动，先看一眼哪些流程依赖它。改版通知这件事做起来比想的有用，它比事后修便宜得多。
什么情况下别做自动化
写到这儿得说几句反面的话。有些活儿自动化是错的，投入产出算不过来。
界面三个月换一次、每次都换结构的业务，维护成本会高到离谱。这种时候人工点两下的花费，比养一支队伍去追着改定位便宜。自动化脚本维护成本压过省下来的时间，这条流程就不该做。
一次性、偶尔才干一次的活，不值得写流程。写流程的时间比手工做一次还长。
判断标准里掺着主观感受的界面，交给机器人会出问题。它不判断，只执行，看到按钮就点，点完把不该点的也点了。
还有一种情况，系统明明有接口，但没人愿意给。这种时候拿界面自动化绕过去，短期能跑，长期一定出事，接口会变，会限权限，会有人来管。
反过来，如果一个流程天天跑、界面半年不动、判断规则又清楚，它就是自动化的好料。剩下的就是找到对的方式把它做扎实。
元素定位这件事没什么高深的技术，就是一层层往下找，找到最稳的那一层，然后把不稳的那些兜住。
延伸阅读