利用RPA进行软件测试：战略性方法

无效的软件测试自动化以延迟发布、消耗惊人资源而臭名昭著。

时不时，新闻推送推送“十大生活窍门”文章。这些关于如何用普通家用品意想不到方式改善生活的技巧——“第7条会让你大开眼界！！！”

承认，我被诱导点击这标题党。诚实说，有时惊喜。例如，谁知开罐器能切烦人塑料泡罩包装，卫生纸筒能防礼品纸展开？

我试了上述两“窍门”，结果？它们“勉强”管用……一阵子。开罐器切开塑料熔合缝，但切不开包装长度。卫生纸筒暂时固住礼品纸，但纸板最终弱化、礼品纸散开。不出所料，剪刀剪塑料泡罩包装、小胶带固礼品纸好得多。

非常相似地，许多组织考虑用RPA自动化软件测试：软件测试的“技术窍门”。然而，正如卫生纸筒非防礼品纸展开可持续方案，RPA非软件测试自动化可持续方案……让RPA工具可持续用于软件测试自动化所需修改，嘛，是个窍门。

若组织已有RPA工具想起步测试自动化，RPA工具似合乎逻辑选择。通常相对易自动化基本测试场景（如创建新用户、完成交易）、添加验证，信踏上测试自动化正途。

然而，重要的是认识到成功且可持续的测试自动化需要远超点击通过应用路径的能力。为超越惨淡行业平均<20%测试自动化率，团队还必须能构建和稳定有效自动化测试套件。RPA工具通常非为此设计。结果，你将撞上测试自动化路障：等待所需测试数据和测试环境的延迟、侵蚀自动化计划信任的不一致结果、消耗大量资源却不提供清晰可行反馈的“臃肿”测试套件。

为快速概览RPA工具与测试自动化工具范围差异，对比Gartner定义：

RPA工具“在结构化数据上执行‘如果、那么、否则’语句，典型用UI交互组合或连接API驱动客户端服务器、大型机或HTML代码。RPA工具用RPA工具语言映射流程供软件‘机器人’遵循，控制仪表板分配运行时执行脚本。”

测试自动化工具“使组织能设计、开发、维护、管理、执行和分析自动化功能测试……跨软件开发生命周期（SDLC）提供广度和深度产品功能。含测试设计开发；测试用例维护复用；测试管理、测试数据管理、自动化测试和集成，强聚焦持续测试支持。”

考虑核心差异时，这些额外测试能力需求变清晰：

• 在生产环境自动化任务序列以成功执行清晰定义流程路径、更快完成工作，和
• 在测试环境自动化真实业务流程以查看应用哪里失败、从而就应用是否风险太大而不能发布做明智决策

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

• 自动化必须在典型不完整、演变中、受限的测试环境执行
• 管理有状态、安全、合规测试数据成巨大挑战
• 有效测试用例设计对成功至关重要
• 失败需提供业务风险洞察

具体化，考虑测试在线旅游服务例子。假设要检查允许用户延长预付酒店预订功能。首先，决定需多少测试彻底验证应用逻辑——每个需何种数据组合。

然后，获取并配置所有数据，将应用设为可执行测试场景状态。此例需（至少）现有用户账户含未来某日期现有预付预订——不可用实际生产数据，因GDPR等隐私法规。

接着，需方法调用连接酒店预订系统（有房/无房）、信用卡（交易批准/拒绝）等所需响应范围——但不实际订房或扣款。

需自动化流程：登录、检索现有预订、指示修改、指定延长长度。

完成完整流程自动化后，需在不同检查点配置多个验证。适当详情是否以适当消息格式发送给酒店？预订是否在用户数据库更新？支付数据是否妥善发送给信用卡提供商？账户积分是否应用？预订无法延长时用户是否收到适当消息？信用卡被拒呢？若信用卡被拒，系统是否恢复原预订长度而非添加未实际支付的额外夜数？

现在想象公司决定对所有预付预订加收$10变更费。能轻松将新需求植入现有自动化测试——还是须大幅重工每个测试适配此微小变更？

即使这个简单例子也暴露RPA工具根本未设计应对的众多软件测试复杂性。RPA工具构建用于自动化序列中特定任务。软件测试自动化工具设计用于衡量更广任务序列韧性。直白说：RPA工具架构为让流程跑通。但软件测试需工具帮你确定流程如何可能崩溃。

无效软件测试自动化以延迟发布、消耗惊人资源臭名昭著。CIOs在改善客户体验、加速软件交付的数字化转型计划投入越来越多，在软件测试上吝啬适得其反。为工作选对工具将在加速交付、降低业务风险、释放更多资源创新上显著回报。

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