外文翻译 | 企业测试自动化突破重重障碍的四种途径

作者：Wolfgang Platz

日期：2020年4月13日

原文链接：

https://www.stickyminds.com/article/enterprise-test-automation-4-ways-break-through-top-barriers

 

摘要：

拥有复杂系统的成熟企业如何达到新的交付计划和流程所要求的测试自动化水平？有四种策略帮助许多企业最终突破了测试自动化的障碍：简化整个技术栈的自动化，结束测试维护的噩梦，改用API测试方向，并选择合适自己需求的工具。

 

在软件测试会议、网络研讨会和各类书籍上有很多测试自动化的成功案例。但这些案例主要是以开发人员和技术测试人员为主。他们专注于测试简单的Web UIs。在过去几年中，他们从头开始参与构建应用程序和测试流程。案例很有说服力。但对于具有异构架构、合规性要求和质量流程发展缓慢的典型公司来说，这并不完全适用。

 

拥有复杂系统的成熟公司如何实现新的交付计划和流程要求的测试自动化水平？最快的答案是：这要看情况而定。

 

让我们来看看帮助许多组织在多年的尝试后终于突破测试自动化障碍的四大策略：

 

• 简化整个技术栈的自动化

 

• 结束测试维护噩梦

 

• 在可行的情况下改用API测试

 

• 根据需求选择合适的工具

 

但是看完这四大策略，你应该会发现，没有任何一种正确的方法适合每个企业中的每个部门。这一点至关重要。对于每个策略，我将指出一些可能会影响策略在企业中重要性的关键考虑因素。

 

 

策略一

简化整个技术栈的自动化

 

传统的测试自动化方法依赖于基于脚本的技术。在开始自动化之前，必须开发一个测试自动化框架。一旦框架最终实现、测试和调试完毕，就可以添加测试脚本来利用这个框架。随着应用程序的发展，这些测试脚本和测试自动化框架本身也需要进行审查、更新与调试。

 

通常情况下，针对单一技术（例如，Web UI或移动接口）的自动化测试需要大量的资源。这可能包括对现有的测试人员进行特定脚本方法的培训，将开发资源重新分配给测试，或者雇佣已经掌握了基于脚本的测试自动化的特定方法的新资源。

 

即使是精通脚本编写的测试人员也会发现，构建、扩展和维护测试自动化是一项繁琐、耗时的任务。这通常会分散测试人员的核心能力：应用他们的领域专业知识来识别影响用户体验和引入业务风险的问题。

 

如果要测试异构应用程序堆栈（例如SAP、Salesforce、ServiceNow或Oracle EBS等打包的应用程序，再加上API、ESB、主机、数据库、Web和移动前端）。那么需要学习、构建和链接多个框架，以实现端到端测试用例的自动化。Selenium是迄今为止所有现代测试自动化框架中最受欢迎的。它专门关注于自动化Web UIs。对于移动UI，您需要一个与Appium类似的框架，还要测试API、数据、打包的应用程序等。这意味着需要获取、配置、学习和链接更多的工具和框架。

 

现在，回到刚开始，记住自动化的最终目标：加快测试速度，以便能够根据需求快速、频繁地执行测试。为了实现这个目标，你需要一种测试自动化的方法，使得测试团队能够快速地为你的应用程序构建端到端的测试自动化。

 

如果您的测试团队由脚本专家组成，并且您的应用程序是一个简单的Web应用程序，那么Selenium或基于Selenium的免费工具可能非常适合您。如果您的团队由业务领域专家主导，并且您的应用程序依赖于更广泛的技术组合，那么您可能需要一种测试自动化的方法来简化企业应用测试的复杂性，使典型的企业用户能够以最小的学习曲线提高工作效率。

 

您可能会发现组织的不同部分喜欢不同的方法。例如，从事面向客户的界面（如移动应用程序）的团队可能不希望与从事后端处理系统的团队使用相同的测试方法。这很好，只要确保所有方法和技术都以促进协作和复用的方式连接起来，同时提供集中的可见性就行。

 

关键考虑因素

 

简化整个技术栈的自动化对于涉及多种技术的复杂企业环境中的测试来说是最重要的。多种技术如：打包的应用程序加上API、ESBs、Web和移动设备。测试的接口越不同，就越应该优先考虑这个问题。如果您是一个测试单个接口的小型团队，这对您来说可能不是问题。

 

 

策略二

结束测试维护噩梦

 

如果您的测试难以维护，那么您的测试自动化举措将会失败。如果您真正致力于控制脆弱的脚本，那么您将在测试维护中投入大量的时间和资源。这就消弱了测试自动化能节省时间的承诺，并使测试（再次）成为流程瓶颈。

 

如果您没有100%的决心去维护测试，那么您的测试结果将会被误报（和漏报）所困扰，以至于测试结果不再可信。

 

测试维护瓶颈源于两个核心问题：

 

• 不稳定的测试

 

• 难以更新的测试

 

解决不稳定性问题的关键是找到一种更稳健的测试表达方式。如果你的自动测试在你的应用程序没有改变的时候开始失败，那测试就有稳定性的问题了。

 

当出现这种情况时，有一些技术解决方案可以解决（例如，使用更稳定的标识符）。掌握这些策略很重要。然而，从测试自动化计划一开始就考虑测试稳定性也是至关重要。在评估测试自动化解决方案时，要密切关注工具如何对可接受的和预期的变化做出响应，以及需要多少工作来保持工具与不断演变的应用同步。另外要认识到，即使是最稳定的测试，如果使用不适当的测试数据运行，或在不稳定/不完整的测试环境中运行，也会遇到问题。

 

要解决更新问题，模块化和重用是关键。开发团队每次改进或扩展现有功能时，都无法更新每个受影响的测试。为了保持测试与开发同步所需的效率和“精益”，测试应该从易于更新的模块构建。这些模块可以在测试套件中重复使用。当业务流程发生更改时，能够更新单个模块并使受影响的测试自动同步。

 

关键考虑因素

 

这个策略对于希望实现高度自动化的团队和积极演进应用程序的团队来说是最重要的。如果您试图为一个相对静态的应用程序自动化一些基本测试，那么您可能有足够的时间和资源来处理所需的维护。然而，您构建的测试自动化程度越高，或应用程序更改的频率越频繁，测试维护就越早成为一个令人望而却步的噩梦。

 

此外，快速增长和高周转的团队更容易受到“测试膨胀”的影响：冗余测试的累积在风险覆盖方面没有增加任何价值，但仍然需要资源来执行、审查和更新。专注于复用和应用好的测试设计策略，可以使膨胀控制到最低。

 

 

策略三

转向API测试

 

如今，UI测试占据了功能测试自动化的绝大多数，只有一小部分测试是在API层面进行的。然而，持续测试彩虹图表明，我们需要达到一种本质上相反的状态。

 

 

显示了探索测试、自动化UI和API测试占比的持续测试彩虹图

 

为什么API测试被广泛认为更适合现代开发过程，因为：

 

• 由于API（“事务层”）被认为是被测系统最稳定的接口，所以API测试比UI测试更容易维护，也不那么脆弱

 

• 与UI测试相比，API测试可以在每个迭代中更早地实现和执行（而且，通过服务虚拟化模拟尚未完成的API，您可以使用TDD方法将测试进一步左移）

 

• API测试通常可以验证超出UI测试范围的详细的“底层”功能

 

• API测试的执行速度要快得多，因此适合于检查每个新构建是否影响现有的用户体验

 

事实上，Tricentis最近的研究量化了使用API测试相对于UI测试自动化的一些关键优势：

 

这就引出了我对测试金字塔的建议：

 

金字塔的红色顶端表示手工测试（通常通过探索性测试）最适合在现代开发过程中发挥的作用。绿带代表了我们发现的UI测试自动化的“最佳点”。这个三角形的绝大多数都被API测试所覆盖。API测试建立在开发级单元测试的基础上。

 

随着时间的推移，测试金字塔实际上会侵蚀成菱形。底部脱落，使金字塔不稳定，但你可以做一些事情来防止这种情况。

 

从实际的角度来看，如何确定哪些测试应该在API层进行，哪些测试应该保留在UI层？一般经验法则是要尽可能的接近业务逻辑。如果业务逻辑通过API披露，则使用API测试来验证该逻辑。然后，将UI测试保留给你想要验证UI元素或功能的存在和位置的情况，这些元素或功能预计会在不同设备、不同浏览器上方面发生变化。同时，开发人员应在单元级别测试API的底层代码，以便在引入实现错误时尽快将其暴露出来。

 

关键考虑因素

 

显然，如果您负责测试的功能没有通过API公开，这对您来说不是一个可行的策略。例如，如果您正在测试一个不利用API的SAP应用程序，那么API测试就不是一个选择。您需要以另一种方式确保测试的重复性和稳定性。

 

 

策略四

根据需求选择合适的工具

 

市场上有很多开源和免费的测试自动化工具。如果您将测试自动化引入到一个测试单个web，移动接口或独立API的小型团队中，您可能会找到一个免费工具，帮助您开始并获得一些令人印象深刻的测试自动化成果。

 

另一方面，如果您是一个大型企业，测试通过SAP、API、主机、Web、移动等多种形式的业务事务，则需要一个测试自动化工具来简化所有这些技术的测试，使团队成员能够有效地复用和构建彼此的工作。

 

然而，在专注于选择工具之前，请考虑以下问题：组织在测试自动化计划中犯的最大错误是认为获取测试自动化工具是采用测试自动化的最重要步骤。无论你选择哪种工具，都必须把它看作是更广泛的转型中的一个组成部分，它涉及到流程、人员和技术。

 

关键考虑因素

 

不可否认，成本是每个工具采购决策的一个因素。一定要考虑总体拥有成本，包括培训和增加现有资源（或雇佣其他资源）、构建测试框架以及构建和维护测试所需的成本。

 

另外，要认识到让不同的团队使用不同的工具是完全可行的（往往也是有价值的）。一个为您的年度企业活动创建移动应用的小团队不需要和测试基于SAP的业务关键事务如何受到频繁升级影响的团队使用相同的工具。“单一窗格”报告提供集中的可视性，同时允许每个团队和部门选择最适合自己需求的工具。

 

标签：企业级，维护，测试自动化，测试管理、测试技术、测试、工具

 

关于作者——Wolfgang Platz

 

Wolfgang Platz是Tricentis公司的创始人兼首席战略官。Wolfgang是基于模型的自动化和线性扩展测试设计方法等创新技术的幕后推手。他开发的技术推动了Tricentis持续测试平台，该平台被所有顶级分析师公认为业界第一大解决方案。如今，他负责推进Tricentis的愿景，使弹性企业自动化在全球2000家企业中成为现实。他的最新著作是《企业持续测试》。企业持续测试：为敏捷和DevOps转型测试。"

 

智联联盟秘书处翻译，如有需调整、需提高等，欢迎反馈！