2. 异常处理
2.1 概述
在流程开发中，进行异常处理是非常关键的一部分。一个流程的异常处理框架的好坏直接影响到整个项目的代码质量以及后期维护成本和难度。
2.2 常用异常处理控件
2.2.1 常用异常处理控件
2.2.1.1 Rethrow
只能在Try/Catch块的Catch块中使用，显式的抛出之前在异常处理块中捕获的异常，并且可以保持异常的原始源
2.2.1.2 Terminate Workflow
终止正在运行的工作流实例，并报告错误信息。使用此控件中止流程，一旦流程终止，它就不能被恢复。
2.2.1.3 Throw
抛出异常信息
2.2.1.4 Try Catch
在Sequence或FlowChart中捕获指定的异常类型，并做相应的处理动作。
在此控件中包含三个分块：
Try：用来包围可能会出现异常的逻辑代码，它单独无法使用，必须配合catch/finally使用；
Catch：在此控件中，可以指定多种可能存在的异常类型，在有多个catch块的时候，是按照catch块的先后顺序进行匹配的，一旦异常类型被一个catch块匹配，则不会与后面的catch块进行匹配。
Finally： 同其他语言的异常处理块一样，在Finally里，不管是否发生错误，此块的内容是一定被执行的，可以在此块中时下关闭文件流、数据库连接等操作
2.2.1.5 Retry Scope
只要不满足条件或抛出错误，就重试所包含的活动。仅适用于查找元素，不利于逻辑重试
Retry Scope控件必须放在Try/Catch控件的Try块中，这样是为了保证在Retry Scope中重试N次之后，都可能存在异常而做的保护处理。如果Retry Scope中重试N次无果，则在Catch中抛出异常信息。
2.3 流程中异常分类
2.3.1 业务处理异常
在关键用户和业务分析人员在流程评估时，需要将流程中的异常分为两种：已知和未知异常两种。
- 已知异常
即在之前有遇到过此种异常信息，并且有明确的处理方式。如果机器人在执行过程中遇到此类的异常，则需要设置相应的处理机制，并且保证机器人执行不中断。
- 未知异常
即在这之前从未遇到过的异常。这种异常可能是由多种因素引起，并且无法准确的预知，如果发生这种情况，则需要发送邮件获取通过其他方式通知到相应的用户。
2.3.2 系统错误或应用程序异常
系统错误和应用程序引起的异常在自动化流程中还是比较常见，通常会通过多次重试的机制以保证流程的正常。举个例子：
登录系统：在登录某个使用用户名、密码进入的系统时，有可能会由于某些不可描述的原因导致一次登录失败。在尝试失败之后，机器人需要关闭该系统，重新打开，再次输入凭证，再去判断登录成功标志。
2.4 异常处理和设计
2.4.1 在有必要使用异常的地方使用，不要在流程的任何地方都用
谨慎地使用异常，异常捕获的代价非常高昂，异常使用过多会严重影响程序的性能。如果在程序中能够用if语句和Boolean变量来进行逻辑判断，那么尽量减少异常的使用，从而避免不必要的异常捕获和处理。
2.4.2 不要使用空的Catch块
在捕获了异常之后什么都不做，相当于忽略了这个异常。千万不要使用空的catch块，空的catch块意味着你在程序中隐藏了错误和异常，并且很可能导致程序出现不可控的执行结果。如果你非常肯定捕获到的异常不会以任何方式对程序造成影响，最好用Log日志将该异常进行记录，以便日后方便更新和维护。
2.4.3 注意catch块的顺序
按照C#中异常继承的关系，不要把最上层的异常放在最前面的Catch块中，尽可能的缩小异常类型的范围。
2.4.4 不要将给用户的提示信息和代码混在一起
为了把给用户的提示信息和代码分开，可以将用户提示信息放在配置文件中统一管理。
同时也不要把流程中代码报错信息直接抛出给用户，会大大降低用户的体验效果。
2.4.5 尽量将异常抛给上层处理
如果在每个出现异常的地方都直接进行处理，会导致程序异常处理流程混乱，不利于后期维护和异常错误排查。由上层统一进行处理会使得整个程序的流程清晰易懂。
2.4.6 在Finally中释放资源
如果有使用文件读取、网络操作以及数据库操作等，记得在finally中释放资源。这样不仅会使得程序占用更少的资源，也会避免不必要的由于资源未释放而发生的异常情况。
3. 测试场景模板
3.1 概述
主要用于测试RPA流程功能实现、业务逻辑、异常处理机制是否完善
RPA实施人员代码开发完毕后根据用户提供的测试用例去模拟用户在使用软件时的各种场景：
主要模拟两种情景：
1、模拟用户正确的业务操作过程—验证的是功能是否正确
2、模拟用户错误的业务操作过程—验证的是程序的异常处理能力（健壮性）
根据以下测试场景模板，测试流程各项功能。若用户提供测试模板，以用户为准
测试编号 流程名称 场景描述 必要测试数据 预期结果 重要性 状态 测试执行者 测试日期 错误信息 错误出现原因 错误解决方案
TS01 Main.xaml 机器人获取发票信息 滴滴电子发票.pdf 取到开票日期及金额 中 未通过 张三 2020/1/11 Read PDF File: One or more errors occurred. 未判断PDF文件是否存在 使用Path Exists判断文件是否存在，结果为True则执行读取PDF文件操作
4. 用户交流
同用户沟通时，业务需求变更或需代码进行调整等讨论沟通后都要进行文档化，邮件等方式发予同用户进行确认，避免后期用户及自身遗忘。
网友评论