摘要：
大多数组织都知道测试自动化对于现代应用程序交付过程至关重要。他们只是不确定如何在没有高昂的开销和大规模破坏的情况下在企业环境中实现它。企业组织通常取得小的胜利，但是由于五个主要领域的挑战，该过程最终会恶化。了解这些挑战将帮助我们克服挑战。
在传统的瀑布式开发模型中，仅靠手动测试就可完成所有测试. 虽然自动化测试的成本很高,但是好处也很明显; 但是，手动测试的低廉成本使其在控制期内的工作时间长于预期。借助触手可及的高性价比手动测试选项，组织推迟了构建和扩展测试自动化的计划。
甚至在五年前，根据第六版《世界质量报告》中的调查反馈，只有30％的企业软件测试是在内部完全执行的，并且绝大部分测试不是自动化的。今天，根据最新的《敏捷状态报告》中的响应，有97％的组织在某种程度上正在实践敏捷，而73％的组织已经在积极或计划中进行DevOps计划。通过这种根本的转变，测试自动化达到了一个临界点。预计测试人员将嵌入团队中，以便可以“在sprint中”完成测试。
为什么向敏捷和DevOps的转变使测试自动化势在必行？
l 可用的时间更少了：现代应用程序开发涉及在越来越紧迫的时间表上发布越来越复杂和分布式的应用程序。如果没有高度的自动化，就不可能完成“ in sprint”测试所需的范围和复杂性。手动测试周期需要数周。这与当今的节奏不一致，在这种节奏中，两周的冲刺和（至少）每天的构建已成为常态-现在趋势正在朝着连续交付的方向发展。
l 团队期望持续不断的即时反馈：敏捷团队和DevOps团队期望在整个发布周期内不断传递反馈。即使您雇用了一整队手动测试人员，这对于手动测试是不可能的（顺便说一句，这将是非常昂贵的）。在没有快速反馈有关最新更改如何影响核心端到端交易的情况下，加速交付会使每次发布的用户体验面临风险。
l 业务期望有很大的不同：随着公司优先考虑数字化转型计划，“速度，成本，质量-选择两个”这一古老格言不再适用。在稳定（甚至降低）成本的压力下，现在期望IT领导者比以往更快地交付更多创新的应用程序。如今，从CEO到下层的每个人都意识到，无视质量不可避免地会导致品牌侵蚀以及客户流失。在受监管的行业中，质量欠佳的影响更为严重。
大多数组织已经知道，测试自动化对于现代应用程序交付过程至关重要。他们只是不确定如何在没有高昂的开销和大规模破坏的情况下在企业环境中实现它。
你不能真正责怪他们。尽管在软件测试会议，网络研讨会和出版物上不乏测试自动化成功案例，但它们主要针对开发人员和技术测试人员，这些人员包括：
1）专注于测试简单的Web UI；
2）拥有构建其应用程序的奢侈性；以及在过去几年中从头开始进行测试过程。
他们的故事引人入胜-但对于具有异构架构，合规性要求和质量流程的典型Global 2000公司而言，这些公司在过去数十年中发展缓慢。
测试自动化现实与目标
在深入测试自动化之前，让我们澄清一下我们在这里谈论的内容。
许多类型的测试可以（并且应该）自动化：
l 单独检查功能或类（编程单元）的单元测试
l 组件测试，在应用程序上下文中检查几个单元的交互
l 确定是否满足特定要求的功能验证测试
l 端到端功能测试，从用户角度（UI或API层）在多个组件和应用程序之间进行端到端业务交易
l 性能测试，可以衡量上述任何级别的应用程序在负载下的可靠性，可伸缩性和可用性
本文重点介绍功能验证和端到端功能测试，但是大多数有关“测试自动化率”的报告都包括所有类型的测试自动化，包括开发人员通常实践的单元测试自动化。
根据Tricentis从2015年到2018年进行的研究，我们发现公司最初报告说，他们已经自动化了大约18％的设计并添加到其测试套件中的端到端功能测试。当您考虑定期运行多少测试时，它实际上要低得多。而且，当您关注全球2000强企业时，该数字甚至进一步下降至8％。
《2018-19年度世界质量报告》基于1,600名受访者的访谈，这些访谈主要来自拥有10,000名及以上员工的公司，该报告还报告了测试自动化率低于20％：
“测试活动的自动化水平仍然很低（不同活动之间在14％至18％之间）。自动化程度低是企业成熟测试的第一瓶颈。”
无论选择哪种来源，其底线都是相同的：我们所处的位置与我们需要成为的位置之间存在巨大差距。
我们应该在哪里？连续测试要求测试自动化率要更高。这导致了我所说的持续测试彩虹：
为了实现连续测试，自动化率需要超过整个测试活动的85％。剩下的唯一手动测试应该是探索性测试，并且自动化的类型也应该改变。自动化应主要集中在API或消息级别，要求服务虚拟化以模拟许多不连续的API或其他组件，而这些组件对于自动化的端到端测试不是连续可用或不可访问的。UI测试自动化不会消失，但将不再是自动化的焦点。
在探讨达到理想状态所需的条件之前，让我们先来看一下为什么会出现这种差距。
许多企业（例如，Global 2000）组织已经进行了测试自动化的试验，通常是使一些UI测试自动化并将其执行集成到持续集成过程中。他们取得并庆祝了小的胜利，但是过程并没有扩大。实际上，它最终会衰减。
通常可以归结为以下五类的障碍：
l 时间和资源
l 复杂
l 相信
l 利益相关者的统一
l 规模
时间和资源
团队严重低估了可持续测试自动化所需的时间和资源。是的，让一些基本的UI测试自动运行是一个很好的开始。但是，您还需要计划以下时间和资源：
l 确定要测试的内容以及如何对其进行测试
l 建立一个支持重用和数据驱动测试的测试框架，这两者对于使自动化长期可持续发展至关重要
l 使更广泛的测试框架与不断发展的应用程序保持同步
l 执行测试套件-尤其是当您尝试频繁运行大型且用户界面繁重的测试套件时
l 检查并排除测试失败，其中许多是“误报”（失败并不表示应用程序有问题）
l 确定每个误报是否源自测试数据问题，测试环境问题或“脆弱”脚本（例如，对预期的应用程序更改过于敏感的测试，例如动态名称和日期元素）
l 随着应用程序的发展，添加，更新或扩展测试-测试套件“膨胀”得越多（例如，冗余度高，重用性低），更新就越困难
l 确定如何自动化更多高级用例，并使它们在连续测试环境中保持一致运行
l 查看并解释测试结果的数量
复杂
在Web应用程序中自动化对一个简单的“创建”操作的测试是一回事，例如注册一个新帐户并从头开始完成一个简单的交易。这是自动化最关键业务的事务的另一种方法，这些事务通常通过多种技术（移动设备，API，SAP，大型机等）进行，并且需要复杂的设置和流程。
为了切实评估预生产环境中的端到端用户体验，您需要确保：
l 您的测试资源了解如何自动化所有不同技术的测试，以及如何将数据和结果从一种技术连接到另一种技术
l 您拥有建立真实的测试以及通过一系列复杂的步骤（每次以及每次执行测试）进行测试所需的状态，安全且合规的测试数据
l 您可以可靠，持续且经济高效地访问测试所需的所有相关系统（包括API，第三方应用程序等），这些系统可能不稳定，在不断发展或仅在有限的时间访问
相信
带有测试结果的最常见的投诉是需要检查和解决的绝大多数误报。当您刚开始使用测试自动化时，处理误报可能是可行的。但是，随着测试套件的增加和测试频率的增加，迅速解决误报成为一项不可克服的任务。
一旦您开始忽略误报，您将处于滑坡。开发人员开始假设测试暴露的每个问题都是假阳性，测试人员需要更加努力地工作才能解决关键问题。此外，如果利益相关者不信任测试结果，那么他们就不会根据测试结果进行判断。
利益相关者一致
持续测试就是在正确的时间向正确的利益相关者提供正确的反馈。在冲刺期间，这可能意味着在“小调整”实际上对更广泛的用户体验产生重大影响时提醒开发人员。随着发行的临近，这可能意味着帮助产品所有者了解已测试和通过应用程序风险的百分比。
但是，大多数团队都专注于测量不可操作的“计数”指标，例如测试数量，这些指标在任何时候都不是任何利益相关者的正确反馈。
规模
大多数测试自动化计划都始于组织中绩效最高的团队。这是有道理的-他们通常最渴望接受新挑战，也为推动新项目取得成功做好了最充分的准备。很有可能，如果您查看拥有成功的自动化测试能力的任何组织，就会发现他们的精英团队可以实现这一目标。
这是一个很好的开始，但是它必须在整个组织中扩展，以实现当今加速的高度自动化软件交付流程所需的速度，准确性和可见性。
突破企业测试自动化的障碍
具有复杂系统的成熟公司如何才能达到现代交付计划和流程所需的测试自动化水平？有四种策略已帮助许多组织最终突破了测试自动化的障碍：简化整个技术体系的自动化，结束测试维护的噩梦，转向API测试以及选择适合您需求的工具。