引子
一年前，在一次客户(老外)的演讲中，晕晕乎乎的在一大段英文中听到了RPA这个词，当时大概查了一下，了解到RPA是机器人流程自动化（Robotic Process Automation)的简称，跟自动化有些关系，但是当时也没搞太明白。
半年前，听说客户的IT部门开始培训大家用RPA工具UiPath来做自动化测试，但是遇到了一些麻烦，问我们这边是否有相关经验。还真不好意思，没有接触过，于是决定研究一下RPA到底是个什么玩意。
RPA初印象
首先看到的是埃森哲的《Getting Robots Right》文章，介绍了RPA的常见误区、案例分享，以及RPA的关键成功因素等，都是高大上的介绍，对于我这个没有接触过的人来讲还是有些云里雾里，只是对RPA有了大概的认识。
文章提到RPA是使用软件来完成重复的、结构化的、基于规则的任务，从而大规模地自动化业务流程，最终实现企业级智能自动化，它是基于办公室的等效生产线机器人，基础技术是机器学习和人工智能。
简而言之，RPA就是用机器人（软件）来取代人完成工作任务。
文章还介绍了RPA可以做的事情，有处理事务、操纵数据、触发响应，以及与其他数字系统通信。其实就是像人工作那样操作不同的系统，处理不同的任务。
理想的可以用RPA工具来操作的应用程序可以在财务、人力资源、采购、供应链管理、客户服务/经验和数百个行业特定业务流程（例如保险索赔处理）中找到。
到此为止，感觉还是很抽象，了解到RPA主要是用来自动化业务流程的，但是不清楚RPA具体是什么样的。
因此，还是先体验一下RPA工具吧。
RPA工具初体验
下载了目前市场占比最大的工具UiPath试用版，尝试使用它提供的录制回放功能录制了一个简单的步骤，的确可以工作，但发现对于复杂的、有条件跳转的还不能这么简单的实现。
通过研究入门手册，琢磨着编写了几个程序实例：一个是猜数字游戏，有两个版本；另一个是从网站查询指定城市的实时天气。它们长这样：
左边的游戏是序列（sequence）形式，右边两个是流程图（Flow chart），跟平时画的流程图非常的类似，很直观可读。好像有点意思！
这是怎么做到的呢？麻烦吗？
UIPath工具提供一个图形化的编程界面UIPath Studio，由三个主要部分组成，Activities（默认在左边）、Properties（默认在右边）、中间是编辑和展示上图中那样的序列或者流程图的地方。
Activities里有各种活动的控件，比如：Input Dialog、Write Line等输入输出控件，以及If、While/Do While等条件/循环判断控件。将活动控件拖拽到中间编辑区域，设置跟其他已有控件的关系。FlowChart里可以通过箭头连接不同控件来设置其相应关系，而Sequence里则是按照控件摆放的上下顺序为先后顺序。
然后，选中编辑区域的控件，可以在右侧的Properties里设置对应的控件属性，比如：猜数字游戏，判断输入的数字跟实际数字的大小以确定弹出不同的消息内容，这些都可以在Properties里对应的设置。
同时，还支持设置相应的变量，比如猜数字游戏中的实际数字和输入数字都可以用变量代替，方便多次使用做比较。
因此，在UiPath里通过拖拽和相应的属性设置，全部在图形化界面上完成，就可以实现一个程序的编制，并不需要有编码工作，对编程技能没有什么要求。对于普通的业务工作人员来说，也是非常简单的。
这个简单实现业务流程自动化的工具似乎跟传统的UI自动化很有相似之处，是不是真的可以像我们客户那样用来做自动化测试呢？
RPA与UI自动化
研究了一阵UiPath的用法后，我给团队做了一个分享，用前面做的程序给大家演示UiPath的使用的时候，本来工作的好好的获取天气程序竟然挂了...原因是网页上的元素有了变化，重新修改获取新的元素路径才得以通过。
由此可见，RPA工具也跟UI自动化工具一样受到UI元素影响较大。
UiPath提供的图形化编程界面，对于没有编码技能的人来说，新建一个工作流拖拖拽拽就能完成，的确很方便。
但是，UI自动化测试都会随着UI的变化需要做相应的修改，通过图形化界面修改流程感觉还是有些麻烦的（或许是因为我还不够熟练使用这工具），作为QA，我更喜欢通过代码的方式来修改。而UiPath后台存储的是Xaml格式，可读性一般般，要改代码也没那么容易的感觉。
另一方面，UI自动化测试最好跟持续集成工具集成起来，而主流的RPA工具都是不能在CI pipeline上运行的。
不像UI自动化工具那样运行于测试环境，RPA工具主要是适用于生产环境，基于相对稳定的系统来实现流程自动化。
当然，开源RPA工具TagUI，可以编程，也支持命令行运行，但是这个工具不太像是RPA工具，更像是被RPA耽误的UI自动化工具。
RPA工具用于UI自动化测试不仅没有太多的优势，反而带来很多不便，有杀鸡用牛刀之嫌，不合适。
对于自动化测试还是要基于测试分层理念，考虑尽可能把UI层自动化测试下移，对于必要的UI自动化测试也可以用更轻量级更适合的工具来做。
由于各种不适，我们客户用RPA工具做自动化测试的事情当然是无疾而终。
既然RPA不适合做自动化测试，我们来看看它的真正用途吧。
RPA技术的真正用途
RPA技术可以模仿各种基于规则而不需要实时创意或判断的重复流程，在电脑上不间断地执行基于规则的各种工作流程，它不仅比人类更快，还可以减少错误和欺诈的机会。简言之，就是“像人类一样工作”，“把人类进一步从机械劳动中解放出来”，让人类自由地开展更高价值的工作。这是RPA技术的初衷，是RPA技术的真正用途。
基于上述特点，RPA技术目前在财务领域应用比较成熟。财务是一个强规则领域，财务领域内的很多事务流程和报告流程大多是可重复、有规律可循的，因此也最易于实现流程自动化。在财务决策过程中相对标准化、有清晰的规则和可重复的活动，也可以应用RPA技术。
把财务相关的输入- 处理 - 决策 - 输出的流程进行分析、拆解，再用机器人软件模拟人的操作，把原本要在各种软件平台——包括会计软件、ERP软件、报表软件，甚至是CRM软件和税务软件上需要很多人力完成的填写、报送、执行命令、菜单点击、输出报表等动作，交由机器人来完成。这就是RPA技术在财务领域的应用场景。
其他基于规则的结构化的业务流程，也可以应用RPA技术，比如HR领域、保险报销流程等。目前，国内外已经有不少成功应用案例，例如：四大会计师事务所的财税机器人、阿里云RPA等。
(图片来源：[http://t.cn/EINC7hk]
RPA，需谨慎前行
RPA技术可以用于结构化的基于规则的业务流程自动化，因此被认为是可以把人类从重复劳动中解放出来的技术，是一个完美的、高效的、低成本的数字化转型方案，被众多企业所青睐。
但是，RPA技术尽管颇具吸引力，目前的RPA产品仍存在明显的技术局限性，阻碍RPA项目发挥完全价值。 这些挑战包括：
- 非数字流程输入的转换
- 识别非结构化文档格式中目标数据字段的能力
- 相对轻松地适应不断变化的规则或业务逻辑的能力
- 从自动化流程的事务性数据中生成洞察的能力
- 根据上下文解释和理解机器活动上游指令集的能力
RPA技术要跟AI技术结合，利用认知和智能识别技术来应对这些挑战，才能较好应用于数字化转型。
另一方面，仅从业务层去考虑利用RPA技术来实现数字化，容易忽略底层支撑系统的技术改造，并不利于整个IT环境的改造与企业的彻底数字化转型。2018年11月ThoughtWorks发布的第19期技术雷达，RPA第一次上榜，但是被置于“暂缓”环，正是这个原因。
技术雷达建议：
RPA这种仅关注自动化业务流程而不解决底层软件系统或功能的方法的问题在于，引入额外的耦合会使底层系统更改起来更加麻烦。这也会让未来任何解决遗留IT环境的尝试都变得更加困难。 很少有系统能够忽视变化，因此RPA的进展需要与适当的遗留系统现代化战略相结合。
同时，也有德勤、安永等咨询专家表示，就许多企业客户的流程管理与系统的基础能力现状来看，仍存在着大量的基础建设工作有待开展。不用着急实现RPA，首要的还是把自身的流程管理和系统构建好。
因此，RPA生态还不够成熟，暂不能作为理想的数字化工具。RPA要怎么用还是要根据企业自身特点和具体需求，谨慎前行，不可冒进。
文/ThoughtWorks 林冰玉
更多精彩洞见，请关注微信公众号：ThoughtWorks洞见
