构建弹性机器人

本文提供了建筑弹性的指导原则机器人过程自动化从一开始就有效地处理应用程序和环境在运行后发生变化 1.挑战 扩展RPA的挑战通常表现为ROI的下降，特别是组织超越RPA采用的初始阶段，我们称之为“自动化蜜月”：你越自动化，越多的自动化就会开始失败，你就会越被抓住因此，扩展RPA的挑战本质上是维护RPA的挑战。 根据我们的调查，涉及2300多家企业客户，有三个主要RPA故障的原因：应用程序更改、环境更改和自动化问题。应用程序更改是技术更改或对软件业务逻辑进行的更改应用程序，而环境变化需要依赖第三方服务，数据- 相关问题，或由系统更新引起的问题，如安全补丁、防病毒更新、或浏览器更新。自动化问题，如同步问题、对象识别issues, or no or missing recovery handling are the third category. These problems shape the节省您的RPA，使它们遵循上面显示的红线。 虽然RPA团队可以控制自动化问题，但他们仅限于无法控制更改对软件应用程序和环境进行更改，因为这些更改通常由软件开发团队和IT运营。有趣的是，72%的RPA故障源于RPA团队无法控制的变化，导致我们称之为“破碎的机器人综合症”。 2.方法 我们应对挑战的方法是双重的。在第3.1,我们提供建议为您的RPA设计健壮的RPA和自动化测试用例。这将解决自动化在RPA部署到生产之前，在设计阶段就有问题。 构成大多数这些建议基础的前5个核心原则是： 1. Single Responsibility Principle (SRP). Each component in your automation should专注于特定任务，这意味着它应该有一个单一的责任。这确保你的自动化保持专注、可维护和适应性。 2.关注点分离(SoC)。您的自动化中的不同关注点应该是分离成不同的组件。这促进了模块化设计，改进了代码组织，并使其更容易理解和修改单个零件。 3.不要重复自己（DRY）。避免重复您的自动化。相反，争取通过将公共功能提取到可重用的组件中来实现可重用性。这减少冗余并增强自动化的可维护性。 4. You Ain 't Gonna Need It (YAGNI). Implement features that are necessary now. Avoid根据潜在的未来需求为您的自动化添加推测性功能。这样可以防止过度管理，降低复杂性，并节省开发时间。 5.保持简单，愚蠢（KISS）。旨在简化自动化设计。简单优于复杂的自动化。简单的自动化更容易理解，调试和维护，它降低了引入错误的可能性。 在章节3.2,我们提供有关如何快速响应两者的更改的建议可能破坏机器人过程自动化的环境和软件应用程序在RPA部署到生产中之后的执行阶段。 我们将保持我们的建议尽可能简洁，为您提供一个简单的清单要遵循。记住这些建议应该被视为指导原则是至关重要的而不是严格的规则。尽管每个建议可能看起来很小或微不足道当整体考虑时，它们的意义会被放大。这对于对细节的关注至关重要的大型RPA计划。请注意，本指南仅划痕The surface of the multimediately challenges involved in scaling RPA. For a more strategic guide涵盖角色、职责、治理和基础架构管理等主题您的RPA计划，我们建议咨询UiPath自动化操作模型。 3.建议 3.1设计阶段 在本节中，我们提供有关创建弹性RPA和自动测试的建议RPA的案例，旨在解决本章中概述的自动化问题1. 3.1. 1机器人过程自动化 •组织。利用UiPath机器人企业框架作为起点自动化业务流程的点。它包含建议的做法用于日志记录、异常处理、应用程序初始化和其他活动。 •模块化。避免在一个过程中创建冗长/复杂的自动化业务流程单个工作流文件。将复杂流程分解为多个较小的可测试流程process组件。此处的关键字是'extract as workflow'和'invoke工作流'。想象每个流程组件作为一个独立的模块。有明确定义的输入和输出参数，以便修改一个模块不会影响其他模块。这不仅增加了可读性，RPA的可维护性和可测试性，还允许在其他流程。所以,保持你的流程组件简单。如果你的自动化业务流程很难解释，它可能过于复杂和/或复杂。 •封装。创建库以封装重复的活动用于其他自动化业务流程。将这些库视为自contained units of logic. Maintain these libraries at one central location to enable你的队友，以加快他们的自动化努力，让他们include these libraries into their automated business processes. This might包括实用程序功能（如登录/注销，登录/注销），导航功能，错误处理函数或恢复处理函数。 •可重用性。利用对象存储库来构造和维护对象(例如，屏幕，控件）位于一个中心位置的应用程序。将它们另存为库在其他RPA项目中重复使用它们，以最大限度地减少维护。 •分离。避免混合自动化任务。逐个自动化应用程序一个。在处理用户界面之前读取文件数据，同样用于电子邮件或API。每个部分都应该关注一个独特的问题。流程通常可以 使用队列进行划分。如果进程组件与队列项不相关，则考虑为其创建新的流程组件。在序列增强了清晰度。不需要的依赖关系增加了复杂性。如果你的进程组件与Excel无关，请删除Excel依赖项。相同所有依赖项都适用，因为最终需要更新。简而言之，应用SoC在您的自动化业务流程的每一个级别，以驯服复杂性。 •命名。为变量、参数、工作流提供一致的命名系统文件、项目文件和库。使用描述性名称，如用户名对于a变量，用于存储用户的名称。例如，在camel case, write arguments in title case. Activity names should describe theaction（例如，“Click Save Button”）。除项目文件外，请使用类似动词的短语用于精确而简洁地描述其目的的工作流文件的名称(例如, '获取交易数据')。 •范围界定。将变量保留在最内部的作用域中，以减少变量面板，并了解哪些变量与工作流文件。请记住，当存在具有相同名称的两个变量时，在最内部范围中定义的具有优先级。 •初始化。使用静态默认值初始化变量和输入参数。这使得测试单个工作流文件非常方便。 •评论。注释您的RPA。使用注释活动和注释让你的队友更好地了解你的自动化方法。 •嵌套。通过避免嵌套的if - then - else语句，使工作流文件保持简单改用流程图。使用程序开关活动和/或流量开关元素来简化if - then - else - if级联。 •同步。让您的自动化业务流程与您的应用程序。使用动态等待活动，如元素存在，图像存在，文本存在，查找元素，查找文本，等待元素消失，等待图像消失而不是静态等待活动，如延迟活动。 •错误处理。将敏感的、有问题的活动放在try - catch块中，并提供简洁但精确的异常消息。使用retry scope活动潜在的脆弱活动，使您的自动化业务流程更强大的应对意外情况。 •安全。使用Orchestrator或我们的开源凭据活动包加载来自安全位置（如Windows凭据管理器）的凭据，而不是在测试用例中对凭据进行硬编码。 •清理。关闭软件应用程序（例如浏览器）以释放内存，删除未引用的变量，删除临时输出（例如日志），删除禁用活动，检查您的命名约定，并删除不必要的容器在发布机器人流程自动化之前。 •分析。使用我们的分析功能来识别和解决性能设计时机器人过程自动化中的问题。 •必要性。仅根据需要开发自动化。避免先发制人未遇到的问题。复杂、复杂、通用的解决方案通常会导致heavy maintenance. Do not create these automations unless necessary. They需要相当长的时间在设计和未来的修改。 •Review.在将RPA发布和/或签入到之前执行代码审查促进整个团队的知识共享，指导RPA新手，改进您的代码，或查找您忽略的错误。使用UiPath Workflow Analyzer使用预定义规则执行自动代码审查，以获得更高的质量。 有关更多详细信息，请参阅UiPath设计最佳实践。 3.1. 2 RPA测试用例自动化 您可以在下面找到一些建议，这些建议将帮助您创建强大，灵活，易于维护，和易于阅读的自动化测试用例为您的RPA。 •目标。我们建议将您的自动化业务流程分为多个，更小，可测试的工作流文件（aka process components）。这不仅有助于RPA的可管理性，但也允许更高效和有针对性因此，避免只为整个过程创建自动化测试用例。相反，专注于为每个流程组件创建自动化测试用例（aka 'component testing'）。重要的是要注意，如果您发现自己无法要为您的流程组件创建自动化测试用例，这可能表明你的RPA没有充分模块化。遵循关键设计原则如单一责任原则(SRP)和关注点分离(SoC)可以帮助创建更易于管理和可测试的组件。请记住，良好的模块化RPA更易于测试（自动）和维护。 •结构。考虑构造自动化测试用例。例如，使用Given - When - Then样式。这提供了一个清晰和逻辑的格式来框架你的自动化测试用例。“给定”阶段为流程设置初始条件（组件）您正在测试。它在任何之前建立了系统的状态过程（组件）被调用-本质上是测试用例的前提条件。“何时”阶段是您制定要测试的特定操作的阶段，通常是调用正在检查的进程（组件）。最后，“Then”阶段描绘了预期的结果，应该观察的变化在系统的状态中，由于执行的操作。它为测试用例，为测试的成功提供了明确的标准。结构化方法将增强自动化测试用例的清晰度。它是也值得使用测试用例模板，它为所有自动化测试用例，简化其创建和管理。 •专注。定义一个清晰的测试焦点。通过测试中的验证来反映该焦点案例中指定这些验证然后测试用例的一部分。测试用例没有任何验证（例如，评估条件，评估输出）不是一个测试用例，它是一组指令，它是一个没有目标的计划。利用我们的testing activities to perform these verifications. Keep the number of verifications每个测试用例尽可能小。 •场景。首先为您的“快乐路径”创建自动测试用例自动化业务流程。这些“快乐路径”代表了最常见的使用场景，并且通常是RPA中大多数风险所在的地方。 优先考虑这些允许您以有限的数量实现高测试覆盖率自动化测试用例。同时将测试重点放在不太常见的使用场景上(例如，边界案例)很重要，避免过分强调它而牺牲常见的使用场景。值得记住的是，你的目标不是实现100%的测试覆盖率。有效的测试自动化策略不仅仅是大量的测试用例，但它是关于智能的、基于风险的覆盖，优先考虑您的机器人流程自动化的最关键和最常见的用例。 •清理。在测试用例结束时关闭应用程序（例如，浏览器窗口）以释放内存。删除未引用的变量，删除临时写入行输出，删除禁用的代码，检查您的命名约定，并删除在发布测试用例之前不必要的容器。使用我们的执行模板为多个测试用例定义这些操作一次。 •独立性。保持测试用例彼此独立。避免测试用例彼此依赖。不要期望一个测试用例的输出在另一个测试用例的输入。Oth •解耦。将测试用例与测试数据分离。打开测试用例到数据驱动的测试用例中。不要将测试数据硬编码到测试用例中。用动态变量替换测试用例中的硬编码测试数据引用您的测试数据。将测试数据存储在测试用例之外。获取测试来自外部来源的数据(例如，excel文件、测试数据队列、数据服务实体）并将这些数据源附加到