企业测试自动化：突破顶级障碍的4种方法

lsekfe

摘要：
　　具有复杂系统的成熟公司如何才能达到现代交付计划和流程所要求的测试自动化水平？有四种策略已帮助许多组织最终突破了测试自动化的障碍：简化整个技术体系的自动化，结束测试维护的噩梦，转向API测试，并选择适合您需求的工具。
　　尽管在软件测试会议、网络研讨会和出版物上不乏测试自动化成功案例，但它们主要针对开发人员和技术测试人员，这些人员包括：1）专注于测试简单的Web UI；以及2）拥有构建其应用程序的极大体验，以及在过去的几年中从头开始测试流程。他们的故事引人入胜——但与具有数十年缓慢发展的异构体系结构，合规性要求和质量流程的典型公司并不完全相关。
　　具有复杂系统的成熟公司如何才能达到现代交付计划和流程所要求的测试自动化水平？快速的答案是：这不一定。
　　让我们看看在多年的尝试之后，已经帮助许多组织最终突破了测试自动化障碍的四大策略：?
　　1.简化整个技术体系的自动化
　　2.结束测试维护的噩梦
　　3.在可行的情况下转向API测试
　　4.选择适合您需求的工具
　　在阅读它们时，至关重要的是要认识到没有适合每个组织中每个部门的单一正确方法。对于每种高级策略，我都会指出一些可能影响它在你的组织中的重要性的关键考虑因素。
　　简化整个技术体系的自动化
　　测试自动化的传统方法依赖于基于脚本的技术。在开始自动化之前，必须先开发一个测试自动化框架。一旦最终实现，测试和调试了框架，就可以添加测试脚本以利用该框架。随着应用程序的发展，还需要检查，可能更新和调试这些测试脚本以及测试自动化框架本身。
　　通常，仅使用一项技术（例如Web UI或移动界面）就需要大量资源来进行测试自动化。这可能包括对现有测试人员进行关于您选择的特定脚本编制方法的培训，将开发资源重新分配给测试，或雇用已经掌握了该特定方法的基于脚本的测试自动化的新资源。
　　即使是精通脚本的测试人员也发现，构建、扩展和维护测试自动化是一项繁琐且耗时的任务。这通常会分散测试人员的核心能力：利用他们的领域专业知识来确定会损害用户体验并带来业务风险的问题。
　　如果您具有要测试的异构应用程序堆栈（例如打包的应用程序，例如SAP、Salesforce、ServiceNow或Oracle EBS以及API、ESB、大型机、数据库以及Web和移动前端），则需要学习多个框架，构建和链接以自动化端到端测试用例。Selenium是迄今为止所有现代测试自动化框架中最受欢迎的框架，它专门专注于自动化Web UI。对于移动用户界面，您需要类似的框架Appium。还测试API、数据、打包的应用程序等吗？这意味着需要获取、配置、学习和链接更多的工具和框架。
　　现在，让我们退后一步，记住自动化的最终目标：加快测试速度，以便可以根据需要快速而频繁地执行测试。为此，你需要一种测试自动化方法，使您的测试团队能够为您的应用程序快速构建端到端测试自动化。
　　如果您的测试团队由脚本专家组成，并且你的应用程序是一个简单的Web应用程序，那么Selenium或基于Selenium的免费工具可能更适合你。如果你的团队由业务领域专家主导，并且你的应用程序依赖于广泛的技术组合，那么你可能需要一种测试自动化方法，该方法可以简化测试企业应用程序的复杂性，并使典型的企业用户能够通过最小的学习曲线。?
　　你可能会发现组织的不同部门喜欢不同的方法（例如面向客户界面（如移动应用程序）的团队可能不希望与后端处理系统的团队使用相同的测试方法。只需确保所有方法和技术以促进协作和重用的方式连接，同时提供集中的可见性即可。
　　重要注意事项
　　这对于在涉及多种技术的复杂企业环境中进行测试最为重要，例如打包的应用程序以及API、ESB、Web和移动设备。你要测试的接口越多，你应该对它们进行优先级排序。如果你是测试单个界面的小型团队，那么这可能对你来说不是问题。
　　结束测试维护噩梦
　　如果你的测试难以维护，则测试自动化计划将失败。如果你真正致力于检查脆弱的脚本，那么你将在测试维护中投入大量时间和资源——侵蚀了测试自动化所承诺的节省时间，并使测试（再次）成为过程瓶颈。
　　如果你不是100％致力于维护测试，则测试结果将被误报（和误报）困扰，以至于测试结果不再受信任。
　　维护问题源于两个核心问题：
　　测试不稳定
　　难以更新的测试
　　解决不稳定问题的关键是找到一种表达测试的更可靠的方法。如果在未更改应用程序的情况下自动化测试开始失败，则说明你遇到了稳定性问题。
　　有很多技术解决方案可以解决此问题（例如使用更稳定的标识符）。这些策略对于掌握至关重要。但是，从测试自动化计划的一开始就考虑测试稳定性也很重要。在评估测试自动化解决方案时，请密切注意该工具如何响应可接受和预期的变化以及需要多少工作才能使该工具与不断发展的应用程序保持同步。此外，请注意，即使是最稳定的测试，如果它们使用不合适的测试数据或在不稳定或不完整的测试环境中运行，也会遇到问题。
　　为了解决更新问题，模块化和重用是关键。开发团队每次改进或扩展现有功能时（现在可以每天、每小时甚至更频繁地进行），你都负担不起更新每个受影响的测试的费用。为了使测试与开发保持同步所需的效率和“精简性”，应从易于更新的模块构建测试，这些模块可在整个测试套件中重复使用。当业务流程更改时，你希望能够更新单个模块并自动同步受影响的测试。
　　重要注意事项
　　对于希望实现高度自动化水平的团队和积极开发应用程序的团队而言，此策略至关重要。如果要针对相对静态的应用程序自动化一些基本测试，则可能有足够的时间和资源来解决所需的维护。但是，构建的测试自动化程度越高或应用程序更改的频率越高，越早进行测试维护将成为一个噩梦。
　　此外，快速增长和高周转的团队更容易受到“测试膨胀”的影响：大量的冗余测试在风险覆盖率方面没有任何价值，但仍需要执行，检查和更新的资源。专注于重用和应用良好的测试设计策略将使膨胀降至最低。
　　转向API测试
　　如今，UI测试占据了功能测试自动化的绝大多数，只有一小部分的测试是在API级别上进行的。但是，对持续测试Rainbow的第二次观察表明，我们需要达到一种实质上相反的状态：
　　为什么？API测试被广泛认为更适合现代开发流程，因为：

由于API（“交易层”）被认为是与被测系统最稳定的接口，因此与UI测试相比，API测试不那么脆弱并且更易于维护
　　API测试可以在每个sprint中比UI测试更早地实现和执行（此外，通过服务虚拟化模拟尚未完成的API，你可以使用TDD方法向左移动测试）
　　API测试通常可以验证UI测试范围之外的详细“幕后”功能
　　API测试执行起来要快得多，因此适合检查每个新版本是否会影响现有的用户体验
　　实际上，Tricentis的最新研究已经量化了使用API??测试相对于UI测试自动化的一些关键优势：



金字塔的红色尖端表明了手动测试（通常通过探索性测试）最适合在现代开发过程中发挥的作用。绿线表示我们已被视为UI测试自动化的“最佳地点”。API测试涵盖了三角形的绝大部分，它基于开发级单元测试。

　　顺便提一下，重要的是要认识到，随着时间的流逝，测试金字塔实际上会腐蚀成钻石。底部掉出，使金字塔变得不稳定，但是你可以采取一些措施来防止这种情况的发生。

　　从实际的角度来看，你如何确定应该在API层进行哪些测试以及应该在UI层进行哪些测试？一般的经验法则是，你希望尽可能接近业务逻辑。如果业务逻辑是通过API公开的，请使用API??测试来验证该逻辑。然后，在需要验证可能会在设备，浏览器等之间变化的UI元素或功能的存在和位置的情况下，保留UI测试。同时，开发人员应在单元级别测试API的基础代码以暴露一旦引入实施错误。

　　重要注意事项

　　显然，如果你承担的测试功能没有通过API公开，那么这对你来说不是可行的策略。例如，如果要测试未利用API的SAP应用程序，则根本无法选择API测试。你需要以其他方式确保测试的可重复性和稳定性。

　　选择适合你需求的工具

　　市场上不乏开源和免费测试自动化工具。如果你要将测试自动化引入一个测试单个Web或移动界面或隔离的API的小型团队中，则可能会找到一个免费工具，该工具将帮助你入门并获得可观的测试自动化收益。

　　另一方面，如果你是一家大型企业，负责测试通过SAP、API、大型机、Web、移动设备等进行的业务交易，则需要一个测试自动化工具，该工具可以简化所有这些技术的测试——使团队成员能够有效地重用并基于彼此的工作。

　　但是，在专注于选择工具之前，请考虑以下问题：组织在测试自动化计划中犯下的最大错误是，认为获取测试自动化工具是采用测试自动化的最重要步骤。不幸的是，这并不容易。无论选择哪种工具，都必须将其视为涉及流程、人员和技术的更广泛的转换的一个组成部分，这一点至关重要。

　　重要注意事项

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

　　另外，请认识到让不同的团队使用不同的工具是完全可行的（并且通常很有价值）。一个为年度公司活动创建移动应用程序的小型团队不需要使用与测试频繁升级如何影响基于SAP的业务关键交易的团队相同的工具。“单一窗口”报告提供集中的可见性，同时允许每个团队和部门选择适合其需求的最佳工具。