使用 RPA 进行软件测试：“技术黑客”？

无效的软件测试自动化因延迟发布而消耗大量资源而臭名昭著。

每隔一段时间，我的新闻提要就会刊登一篇文章，提供“十大生活小窍门”。这些是关于如何以意想不到的方式使用普通家居用品来改善生活的技巧和窍门——“……技巧 7 会让你大吃一惊！！！”

诚然，我被吸引打开这个点击诱饵。老实说，有时候我很惊喜。例如，谁知道你可以用开罐器切开烦人的塑料泡罩包装，或者用卫生纸卷防止包装纸展开？

我尝试了上面的两个“黑客”，你猜怎么着？他们“有点”工作了……一段时间。开罐器切开塑料熔合的接缝，但未能切开包装的长度。卫生纸卷住了包装纸一段时间，但最终纸板变软了，包装纸散开了。毫不奇怪，塑料泡罩包装用剪刀，包装纸用一小块胶带效果好得多。

与此类似，许多组织现在正在考虑使用 RPA 来自动化软件测试：一种用于软件测试的“技术黑客”。然而，正如卫生纸卷没有提供防止包装纸展开的可持续解决方案一样，RPA 也不是软件测试自动化的可持续解决方案……以及使 RPA 工具可持续完成软件测试任务所需的修改自动化将是一种黑客行为。

如果您的组织中已经拥有 RPA 工具，并且您希望开始使用测试自动化，那么您的 RPA 工具似乎是一个合乎逻辑的选择。自动化一些基本测试场景（例如，创建新用户并完成交易）、添加验证并相信您正在实现测试自动化通常相对容易。

然而，重要的是要认识到成功且可持续的测试自动化需要的不仅仅是点击应用程序路径的能力。为了超越低于 20% 的行业平均测试自动化率，团队还必须能够构建和稳定有效的自动化测试套件。 RPA 工具通常不是为了实现这一点而设计的。结果，您将遇到测试自动化障碍，例如延迟等待所需的测试数据和测试环境，不一致的结果会削弱对自动化计划的信任，以及“臃肿”的测试套件会消耗大量资源但无法交付清晰，可操作的反馈。

要快速了解 RPA 工具和测试自动化工具之间的范围差异，请比较 Gartner 的以下定义：

RPA 工具“对结构化数据执行‘if,then,else’语句，通常使用用户界面 (UI) 交互的组合，或通过连接到 API 来驱动客户端服务器、大型机或 HTML 代码。 RPA 工具通过将流程映射到 RPA 工具语言中以供软件“机器人”遵循，并分配运行时以通过控制仪表板执行脚本来运行。”

测试自动化工具“使组织能够设计、开发、维护、管理、执行和分析自动化功能测试……它们在整个软件开发生命周期 (SDLC) 中提供产品和功能的广度和深度。这包括测试设计和开发；测试用例维护和重用；和测试管理、测试数据管理、自动化测试和集成，重点是支持持续测试。”

当您考虑以下之间的一些核心差异时，对这些额外测试功能的需求变得清晰：

• 在生产环境中自动执行一系列任务，以成功地通过流程执行明确定义的路径，从而更快地完成工作，以及
• 在测试环境以查看应用程序在哪里失败，以便您可以就应用程序是否太冒险而无法发布做出明智的决定

这些差异对软件测试意味着什么？

• 自动化必须在通常不完整、不断发展和受限制的测试环境中执行
• 管理有状态、安全、合规的测试数据成为一项巨大挑战
• 有效的测试用例设计对于成功至关重要
• 失败需要提供对业务风险的洞察

更具体地说，让我们考虑测试在线旅游服务的例子。假设您要检查允许用户延长其预付酒店预订的功能。首先，您需要确定彻底执行应用程序逻辑需要多少测试，以及每个测试需要使用哪些数据组合。

然后，您需要获取和配置将应用程序设置为可以执行测试场景的状态所需的所有数据。在这种情况下，您需要（至少）一个现有的用户帐户，并且在未来某个日期具有现有的预付费预订 - 由于 GDPR 等隐私法规，您无法使用实际的生产数据。

接下来，您需要一种方法从连接的酒店预订系统（房间可用/不可用）、信用卡（交易批准/拒绝）等调用所需的响应范围——但无需实际预订房间或收取费用。信用卡。

当然，您需要自动化该过程。这包括登录、检索现有预留、指示您要修改它，然后指定扩展的长度。

完成整个过程自动化后，您需要在不同的检查点配置许多验证。是否以适当的消息格式向酒店发送了适当的详细信息？您的用户数据库中的预订是否已更新？支付数据是否正确发送给信用卡提供商？是否应用了任何帐户信用？如果无法延长预订，用户是否收到了适当的消息？如果信用卡被拒怎么办？如果信用卡被拒绝，您的系统是否会恢复到原来的预订时长，而不是添加实际未支付的额外晚数？

现在想象一下，您的公司决定为所有预付费预订增加 10 美元的改签费。您能否轻松地将这一新要求纳入您现有的自动化测试中，或者您是否必须对每个测试进行大量返工以适应这种微小的变化？

即使是这个简单的示例也暴露了 RPA 工具无法解决的许多软件测试复杂性。 RPA 工具旨在自动执行序列中的特定任务。软件测试自动化工具旨在衡量更广泛的任务序列的弹性。坦率地说：RPA 工具的架构是为了使流程正常工作。但是对于软件测试，您需要一些工具来帮助您确定流程可能会如何中断。

无效的软件测试自动化因延迟发布而消耗大量资源而臭名昭著。随着 CIO 越来越多地投资于通过更快的软件交付来改善客户体验的数字化转型计划，对软件测试的吝啬会适得其反。为工作选择合适的工具将在加速交付、降低业务风险和投入更多资源用于创新方面获得显着回报。

Wayne Ariola，是《面向 IT 领导者的持续测试》一书的作者，也是 DevOps 和应用开发领域的知名主题演讲者。