RPA设计实施、开发和单元测试

RPA设计、开发和单元测试

RPA的设计、开发和单元测试是RPA项目实施的核心阶段。这个实施过程并非是遵循传统的瀑布式软件开发方法，而是遵循敏捷方法论，采用冲刺Sprint和迭代增量Scrum相结合的方法。Sprint指的是一次冲刺迭代，通常是以最快的速度完成一次开发任务的时间周期。Scrum包括一系列最佳实践和预定义角色的管理过程，是一种更高效开发软件的管理方法。

设计过程

在RPA流程的设计阶段，通常每个流程都需要产出一个独立的方案设计文档（SolutionDesignDocument，SDD），这样就保证该流程实施的独立性，包括后续的开发、测试、部署上线工作。

虽然，目前在业内仍没有一套标准格式的SDD文档，但基于之前一些项目的最佳实践，我们可以大致罗列出RPA设计文档中的主要内容。

【1】流程概述：定义该流程的基本描述和运行情况、PDD中的业务用户需求，明确流程的业务负责人和沟通接口人，以及RPA设计的前提假定、技术约束、环境依赖和所要求的服务水平协议等。

【2】涉及的应用系统/工具：描述该流程需要操作的应用系统、工具、技术。例如，是B/S架构还是C/S架构。

【3】描述流程中所涉及系统的用户登录方式，如哪些系统需要业务用户登录，如果需要，在开发或测试环境下所使用的用户名和口令是什么。

【4】现状业务流程：内容主要来自PDD中对于业务流程的描述。与SDD的区别是，SDD中所描述的业务流程必须是能够被RPA设计人员所理解的。

【5】目标业务流程：主要目的是清晰地告诉业务人员，引入RPA之后的业务流程是如何运行的，其中包含机器人处理的环节、人工处理的环节，以及双方的协作环节。那么，设计人员就需要收集汇总该流程在业务层面的优化点，以及由于引入机器人之后所带来的流程改进点，并将这些统一体现在目标业务流程的定义中。

【6】机器人处理流：目标业务流程是面向业务人员的，而机器人处理流是面向技术人员的。机器人处理流可以拆分出该流程需要几个机器人、几个自动化任务，以及这些自动化任务的执行时间是什么，任务之间是如何编排的。

【7】文件目录结构：为了区分不同业务流程的处理过程，机器人通常需要拥有专属的文件目录。SDD中应清晰地定义出机器人程序的存储目录和所需处理的文件的存储目录，避免出现不同流程输入、输出文件混用的问题。

【8】机器人设计要点：体现机器人程序之间的依赖关系，包括所需要复用的代码库、配置文件、机器人的控制方式、数据安全和数据管理、业务连续性处理手段等一切需要重点说明的设计内容。

开发过程

RPA的开发过程通常是依据SDD中的设计成果，在整体架构设计的要求下，一步一步将业务流程步骤转化为自动化脚本、流程图或者自动化程序。

在RPA实际开发过程中，开发人员经常会遇到之前流程分析过程中所没有考虑到的情况，比如某个界面元素抓取不到，或是自动化操作不成功（手动操作成功），这就需要RPA开发人员临时转换思路，换一种技术手段来实现自动化处理。这些技术手段通常与RPA程序运行的稳定性有关，通常我们需要在开发过程中尝试那些稳定性更高的技术。如果按照自动化程序运行稳定性排序，由强到弱依次为捕获界面控件、快捷键操作、界面图像比对、界面坐标定位。如果各种自动化技术手段都无法解决这个技术障碍，那么就需要与该流程的负责人沟通，寻求业务层面的解决方案。

开发实践

第一步，搭建整个RPA程序框架。编写代码前，先开发主辅程序的调用方式、配置文件的读取方式、预处理、中间处理和后续处理等环节，并预留异常处理和程序补偿机制的处理环节。

第二步，以流程中某个业务实例的正常处理过程为基础来开发RPA程序。将业务数据以常量的方式来表达，这样可以快速发现该流程中所需要的自动化技术，以及存在的技术障碍点，便于尽快寻找解决方案。

第三步，当正常处理流程可以自动化运行之后，按照业务处理要求，再在RPA中加入必要的循环处理、分支处理，并将原来程序中的业务数据常量转换为参数变量。这样，多个业务流程就可以实现自动化了。

第四步，在满足了正常情况的自动化处理之后，开发人员需要在RPA程序中增加必要的日志跟踪和异常处理。异常处理需要覆盖可能出现的业务异常情况和系统异常情况，并设计相应的RPA补偿机制。这样，当机器人重启后，不会影响之前的操作成果。虽然这些异常在实际运行中很少出现，但在RPA开发过程中却要花费大量的精力去设计。也就是说，我们不得不利用80%的开发时间来处理那些只有20%概率发生的异常情况

第五步，当RPA程序开发完成之后，开发人员就需要为将来可能存在的横向扩展、环境变更等定义项配置文件，将程序中的部分参数改为读取配置文件的方式，为下一步最终用户的UAT测试做准备。这个过程和传统的自动化测试开发非常相似。

最终用户的UAT测试

最终用户的UAT测试过程与前面开发人员的单元测试过程是基本相似的，即给出一些符合真实场景的业务数据样例，让机器人来运行，由业务人员校验运行成果是否满足业务要求。虽然这是一种黑盒测试，但在测试数据中必须要同时考虑正例和反例的存在，以保障机器人运行的可靠性。

UAT测试可以让一线的业务人员真正感受到机器人的处理方式，对未来RPA上线后的运行效率和人机协作方式的改进都会有帮助。

机器人的部署上线

有别于传统应用系统的部署上线，RPA的部署上线不受某个特定的时间窗口限制，也不会牵扯后台数据库的迁移和切换等工作，只是替代了一线业务人员的手工操作，所以对传统的数据中心运维人员来说，通常是无感的。而且，RPA可以分批次部署上线，所以对原有系统和业务运行的冲击和影响很小。在RPA部署上线前，开发人员需要协助运营人员同步完成RPA运营手册，比如配置文件、机器人启停时间或计划表、运行异常时的解决方案等，相当于开发团队到运营团队的工作成果确认和工作交接过程。

环境配置的参数调整：最理想的情况是RPA的测试环境和生产环境完全是一样的。如果不能满足，RPA通常采用读取配置文件的方式来适应运行环境的调整，不只是输入输出文件的目录改变，还包括不同环境下的浏览器版本、应用版本等。

RPA机器人的监控和维护

由于RPA机器人运行时会出现异常、中断、故障、业务数据非标准、案件超权限范围、规则未考虑到等情况，所以，运营人员需要既具备系统管理员、业务监督员的角色特征，又需具有能及时响应问题的速度。企业并不需要为RPA重新建立一套运维体系，而应当基于企业原有的运维体系，再结合RPA特性，进行优化改良。这套运维体系应当具有对运行问题和风险主动监控的能力和被动响应的能力

RPA设计异常处理

为了保证RPA机器人的稳定运行，设计人员在RPA设计时需要重点考虑两方面的内容，即异常处理和日志记录。在自动化流程运行中，异常情况主要包括三类：业务异常、应用异常和机器人异常。

1. 业务异常业务办理过程中可能存在一些数据异常或者超越既定业务规则的情况。通常，业务人员需要采用特别的手段进行处理。在RPA中，通常采用拟定新的业务解决方案或流程规则判断、分支条件以及人机交互（将错误的数据交给人类员工处理，机器人只处理正常的数据）的方式来解决。

1. 应用异常例如，RPA运行时会出现某个应用程序中断、网站的某个页面打不开、应用出现异常报错的情况，而在设计中设计人员通常很难预测到这类异常。所以，设计人员需要在RPA程序中引入错误捕捉和处理机制。例如，ErrorHandling或TryCatch，即通过错误捕捉技术抓取自动化程序中的运行错误，做一些特殊处理，而不中断RPA机器人的运行。这些处理手段包括截取界面的错误信息、触发某种补偿任务、发送邮件通知相关人、记录错误日志等。

（3）机器人异常例如，RPA平台中的某个机器人运行错误，导致自动化处理流程中断。那么，我们可以采用负载均衡和机器人动态控制机制，将自动化任务分配给其他没有问题的机器人来处理。即便整个RPA平台出现了问题，我们也可以通过高可用（HighAvailability，HA）和灾备（DisasterRecovery，DR）机制来解决这类异常问题。记录机器人运行的日志信息是非常有必要的。运维人员可以根据之前记录的日志信息分析出导致异常现象出现的原因。技术人员也可以根据日志信息快速定位到自动化程序中的Bug，通过修改自动化程序，增加分支处理流程，增加异常处理手段，不断增强自动化流程的稳定性。在自动化流程运行中，通常需要记录三类日志信息：正常的执行过程记录、警告信息、错误信息。

正常执行过程的日志记录信息通常用于后续的合规和审计处理，以及对机器人处理过程的追踪和监控。

警告日志信息可以尽早为RPA运维人员提示运行风险，使运维团队及时采取适当的手段避免异常发生。

错误日志信息描述了自动化流程运行中已经发生的问题。机器人运维人员可通过监控系统捕获这些异常，并及时修复和处理这些异常情况。

安全风险控制管理

风险控制也是RPA领域最为重要的一环，而安全问题却常常被管理者和开发者所忽视。风险控制之所以重要的原因主要来自以下几个方面。

【1】赋予机器人访问应用系统的权限。因为机器人需要像员工一样输入用户名和口令，才能进入某个应用系统。而且，需要机器人做的事情越多，赋予机器人的用户权限也越多。通常，用户权限在企业中被严格控制，因为职责权限隔离是企业运营的基本思路。另外，机器人没有办法像正式员工一样具有入职证明、身份证等证明材料，按照原有流程，如果缺少这些证明文件，后台系统的维护部门将无法给机器人申请对应的账户及权限。

【2】惩罚机制。原来，企业领导是通过管理员工来管理流程和业务成果的。如果某个员工的业务操作出现问题，会存在相应的控制和处罚机制。而且经过若干年的积累，一些大企业已经形成了一套行之有效的操作风险管理制度和规范。如果用RPA机器人替代人工操作，出现问题后就不能再用原有的规范和手段去处理了，需要制定一套面向机器人的人机协作体系下的规范和管控手段。

【3】要避免有人恶意建造机器人，模拟某个终端真实用户的行为来危害企业的业务流程或者应用系统，这种模拟方式在传统应用系统的后台是难以被察觉的。

【4】由于机器人掌握的敏感信息包括人类用户的用户名和口令，原来这些用户名和口令是由业务用户自己来保管的，现在交由机器人来保管，这样就会带来两个方面的风险。一方面，机器人的开发者和管理者是否会利用这些信息做一些超出自己权力范围的事情。另一方面，企业外部的信息窃取者是否会盗取这部分用户名和口令。特别是在欧洲这种对GDPR规范要求严格的地区，机器人对于用户名和口令更多只是拥有使用权，而管理权仍然归用户所有。如果用户想收回或变更用户名和口令，RPA系统平台只能无条件满足要求。

【5】RPA机器人在操作业务的时候通常会用显性的方式来操作应用系统的界面，导致所处理的一些隐私数据或者机密信息，特别是员工薪资、客户账户金额等，很容易被泄露。因此，业务运营部门希望最大限度地保证数据安全。

【6】如果是前台机器人，开发者或者业务人员可能偷偷记录机器人所操作的业务数据，存在数据泄露或盗用的风险。

备注：这其中特别需要注意的就是RPA设计过程中的日志输出数据的安全处理和防止泄露处理。

【7】RPA系统虽然是模拟人类的操作，但终究是IT系统。传统IT系统所遇到的问题，RPA也一样会遇到，比如网络攻击、系统入侵、代码注入、数据传输安全等。

机器人运行效率管理

【1】在设计RPA机器人时，不能一味的按照原始业务流程来处理，可以根据实际情况做合理的优化。完成同样业务目的的两个自动化任务的效率差异来自RPA机器人是否模拟了人的某种最高效的操作方式，以及是否采用了最高效的技术实现方式。比如，当我们要搜索Excel表中的某个数据时，可以让RPA程序在数据中一行一行地搜索，也可以让RPA程序直接在Excel里写个VLOOKUP函数，二者之间的效率可能会相差百倍。这就需要RPA的开发人员不能只是个单纯的技术人员，完全被动地接收业务人员的操作需求，而是需要自己多想一想，业务操作的目的是什么？有没有更好的处理手段？

【2】在任务较为繁多的某个时段，一个机器人的处理能力就无法满足处理要求，则需要几个机器人组成一个工作小组（机器人资源池）来并行处理。这些任务通过负载均衡机制，动态地分配到此时空闲的某个机器人手里，这样可以最大化利用机器人。

【3】在任务不能完全实现自动化的时候，就需要人和机器人来配合工作。所以，更好的任务编排应该是人的任务和机器人的任务可以无缝地编排在一起。