原文：https://www.tricentis.com/wp-content/
作者：Wayne Ariola
碎碎念：本来想写一下有关持续测试的概念，结果找到这篇以后发现想说的都被写了，于是直接翻译过来造福大家吧。
面对现实吧。企业不希望或者不需要完美的系统。他们希望尽快提供有着不同业务价值的新系统。为此，我们需要快速反馈最新的创意点子在实际环境中能按预期工作还是崩溃掉。我们还需要以某种方式知道这些变化是如何打破了客户想使用的核心功能，这是业务重心所在。
持续测试为此应运而生。持续测试是一个将自动化测试作为软件交付管道中一部分的过程，以能在软件发布和业务风险间建立快速的反馈。
自动化测试对于连续测试至关重要，但它并非全部。自动化测试旨在生成一组与用户故事或应用需求相关的通过/失败数据检查点。而持续测试侧重于业务风险并提供有关软件是否可以被发布的决策基础。除了将测试用例自动化，持续测试还包括了诸如验证业务风险，应用服务虚拟化和状态化测试数据管理以稳定持续测试；在每个迭代中使用探索性测试来尽早发现阻碍性问题等实践。它不单是意味着使用更多的不同的工具。它要求的是包括技术在内的人和流程的深度转变。
本文探讨了持续测试真正涉及的内容，以及关于为什么它对敏捷和DevOps如此重要的新研究，同时给出一些帮助您在自己的团队和组织中实现这一目标的建议。
持续测试 vs 测试自动化
像露西和埃塞尔努力跟上巧克力工厂的步伐一样，许多软件测试人员一直都在努力地跟上流程加速的步伐，伴随着主管不停的说，“你做得非常好！加快速度吧！”
随着与测试相关的期望正在发生变化，传统测试平台并没有跟上。传统测试平台运行的是重型的测试方法。它们依赖于脆弱的脚本，提供缓慢的端到端回归测试执行，并产生大量的不稳定性的误报。 结果，他们从自动化测试上只取得了有限的成功。 整体自动化测试率为18％（企业为8％）。 在一个行业的民意调查问题网络研讨会和贸易展览，受访者压倒性的报道到目前为止，自动化测试的结果一直是“马马虎虎”。
传统测试不起作用
整个行业最近的变化要求更多的测试，同时也使自动化测试更难以实现。
有几个原因：
•应用程序架构越来越分散和复杂，包括云，API，微服务等。在同一个单一的业务交易中几乎同时创建了无穷无尽的协议组合。
•感谢Agile，DevOps和持续交付，很多应用程序现在可以从每两周的一次版本发布进化到一天上千次。结果，留给用于测试设计，维护，特别是执行的时间大幅下降。
•现在软件是业务的主要接口，应用程序故障既是业务故障。即使是一个看似微不足道的小故障，如果它影响用户体验，那也可能是严重的结果。甚至是非技术性的商业领袖也开始把与应用相关的风险作为主要关注的问题。
鉴于软件测试人员面临日益复杂的应用程序，他们被期望给新的商业模式提供更值得信赖的是否可用的决策。传统的测试方法不会使我们成功。我们在转变开发模式的同时也需要将测试过程转换为更加显性，这需要更多有效的自动化测试。它需要一种不同的方法，称为持续测试。
什么是持续测试？
如前所述，持续测试是一个将自动化测试作为软件交付管道的一部分的过程。目的是为在软件快速发布时及时获取到与之相关的业务风险的反馈。
持续测试不需要任何特定类型的测试方法（例如左移，右移...）或测试工具。
但是，它确实需要：
•在正确的时机将可行的反馈意见提供给正确的利益相关者
•测试发生在软件交付管道的所有阶段。
自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败数据的检查点，另一方面，持续测试侧重于业务风险并提供有关软件是否可以发布的见解。 要想达到这个转变，我们得停止问：“我们是否完成了测试？”而是专注于，“发布版本是否达到了一个可接受的商业风险水平？“
持续测试有五个关键属性：
1.评估业务风险覆盖率是其主要目标。
2.建立一个帮助团队保护用户体验的安全网。
3.需要一个稳定的测试环境，以便按需提供。
4.无缝集成到软件交付管道和DevOps工具链。
5.提供适合每个交付管道阶段的可操作反馈。
持续测试 VS 自动化测试
持续测试和自动化测试之间的主要区别可分为三大类：风险，广度和时间。
风险
今天的企业不仅会把很多内部的应用暴露给最终用户;他们也开发了大量的软件来扩展和补充这些应用。例如，航空公司已经远远超出了曾经内部的预订系统。他们现在让客户计划和预订完整的假期，包括酒店，租车和旅游活动。拥有越来越多的创新用户功能是现在的竞争优势 - 但是它也增加了潜在失败点的数量，种类和复杂性。
大规模的“软件失败”有如此严峻的业务反响，与应用相关的风险变成企业公共财务报告的组成部分。鉴于这一点，重大的软件故障会导致平均下降了-4.06％股票价格（相当于平均25.5亿美元的市值),这就不难理解为什么业务领导开始希望IT领导能采取行动去降低这一风险。
如果你的测试用例没有考虑到业务风险，那么您的测试结果不会提供评估风险所需的洞察力。大多数的测试设计都是基于是否用户故事被正确实现的细节部分， 而不是对发布版本是否风险太大的高级评估。根据测试结果你会自动停止发布么？如果没有，您的测试没有正确对齐商业风险。
要明确：我们并不是说低粒度测试没有价值;我们是呼吁需要更多的努力来阻止高风险的版本被发布。
以下是测试人员可以识别风险的一些方法：
•了解和完整的应用组合相关的风险。
•将风险映射到应用程序组件和要求（然后映射到测试）。
•使用固定的测试套件，其包含尽可能少的测试用例来覆盖最高风险的场景。
•始终能监控显示业务，技术，性能和合规性方面的风险。
宽度
即使企业能设法避开让系统失败成为头条新闻，看似微不足道的故障仍然会引起麻烦。如果用户体验的任何部分
没有达到预期，就会冒着失去客户的风险。如果该用户决定向社交媒体揭露问题，您还可能面临品牌损害风险。
只知道单元测试失败或UI测试通过并不能说明最近的变更是否会影响整体的用户体验。要保护最终的用户体验，请全面开展测试，以检测应用程序更改无意中影响了用户所依赖的功能。
以下是一些解决测试广度的方法：
- 从用户的角度来看应用程序定义并执行完整的端到端测试
- 为所涉及的所有技术提供综合支持包括关键的用户交易（网络，移动，消息/ API层，
SAP和打包的应用程序等）。 - 模拟相关组件的服务虚拟化以用来执行完整的端到端交易（此类测试无重用性也不可配置）
- 确保测试和服务虚拟化资产每次都填充实际有效的数据测试执行。
•执行探索性测试以查找用户体验超出自动化测试范围的问题（例如易用性问题）。
时间
现在组织发布软件的速度已经成为绝大多数竞争优势，大部分的组织正在转向敏捷和DevOps来加速他们的交付流程。
当自动化测试出现时，它专注于测试依据瀑布开发模式来开发和变更的内部系统，系统都在组织的控制之下，一切都已完成，并按时准备好进行测试。现在敏捷开发模式正在成为常态，测试必须与开发并行，否则，用户故事不太可能被测试或在极度压缩的迭代时间内被视为“完成”。
如果你的组织已采用DevOps并且正在执行持续交付，系统可能每小时发布 - 甚至更频繁。在这种情况下，在过程的每个阶段进行反馈不能只是“快” - 它必须几乎是瞬间的。如果质量不是你系统 的头号关注点（比如，在生产环境中发现问题以后有最小版本的回滚），进行一些快速的单元测试和冒烟测试在每个版本上可能就足够了。但是，如果企业想要软件到达最终用户之前最小化风险，你需要一些方法来达到必要的风险承保水平和测试广度 - 快速。
对于测试，有几个重要影响：
- 测试必须成为开发过程的一部分（而不是在开发时加上“卫生任务”完成了）。
•测试必须准备好可以随时运行在相关的功能实现时。
•组织必须有办法确定在交付管道的不同阶段执行不同的测试（check-in以后的冒烟测试，集成以后的API /消息层测试，系统层的端到端测试）
•每组测试必须足够快，而不会在软件的交付通道的不同阶段造成瓶颈。
•需要一种稳定测试环境的方法来防止经常变化导致绝大多数误报。
以下是测试人员需要解决时间压力的一些方法：
- 确定哪些测试用例对于解决关键的商业风险。
- 随着应用程序的不断变化，持续改进和发展测试。
- 重新平衡测试金字塔，以便执行大多数测试，在API层，这比UI快至少100倍。
- 将测试集成到持续交付自动化流程中。
- 跨多个VM，网络或者云上分布式的运行测试用例
- 争取服务虚拟化和合成数据生成/TDM使测试不需要等待数据或环境供应。
持续测试和 敏捷+ DevOps成功
Forrester最新研究（最终软件质量指标）敏捷+ DevOps）表明，实施正确的持续测试是一个DevOps和敏捷精英者和落后者之间的关键区别。
快速提供高质量的软件已经不再是奢侈品了。数字化成功的先决条件是客户的完全忠诚和认可。我们正处在一个客户有权选择为他提供更好的体验和最低成本的公司的时代。无法跟上客户需求的组织会发现他们自己会失去客户，并把业务给到竞争对手。
企业如何以最快的速度提供质量？实施敏捷和DevOps最佳实践，质量建设是第一步 - 这是非常重要的。自动化是开发团队可以高速前进的杠杆。但是，如果管理不当，自动化可以危及质量并增加风险。确保质量问题和不可接受的风险不会否定自动化的速度优势，公司必须确保他们对于整个开发测试和部署的质量，正在跟踪衡量的正确指标。为了探索这个主题上，Forrester进行了一次全球603家企业的在线调查，企业受访者负责其公司的敏捷和/或DevOps策略。
主要发现
五个核心实践来自在Agile和DevOps中更成熟的公司：
1.分配适当的测试预算，并专注于升级他们的测试技巧。
2.实施持续测试以满足需求发布频率并支持持续交付。
3.将测试人员作为其综合交付团队的一部分。
4.自动化端到端功能测试。
5.将测试左移到到开发生命周期的早期阶段。
（就CC先生的经验来说，道理老大们都知道，问题是一涉及到部门墙的问题就没辙）
对于遵循这五种最佳实践的公司而言，测试是一种获得速度和效率的方式而不是成为快速交付的瓶颈。
虽然大多数敏捷和/或DevOps公司已经实施这五种核心测试实践的一些，很少有真正完全实际实现的企业-其中只有约四分之一的受访者表示他们有点或完全同意所有五个最佳实践陈述。这是个重要的区别。虽然许多CXO和高层决策者认为他们处于领先地位，但我们的研究表明只有完全遵循这些最佳实践的公司-与同行相比，拥有更先进的敏捷和DevOps实践 - 他们的行为和态度支持这种说法。
商业风险必须准确无误
管理
无法准确地自动交付软件而去衡量软件质量是危险的。公司必须了解到商业风险 - 用户体验负面的可能性 -
每个软件应用程序在决定是否发布时进行。不幸的是，今天大多数公司承认对于能够准确评估和管理测试中的业务风险他们的差距很大。
领导者强力推动端到端测试自动化
通过更好地指示风险的测试指标，DevOps领导者可以不懈地追求自动化发展，同时兼顾质量和效率。他们通过优先考虑端到端自动化来实现业务流程测试用例。它们使测试设计和测试执行自动化，他们协调整个dev-test-deploy过程的自动化。
主要建议
实际评估并提升您的敏捷和DevOps的实践中关于持续测试水平。虽然许多CXO相信他们的公司在DevOps上处于领先地位，我们的研究表明，只有约四分之一的公司正在关注测试最佳实践。
确保您的公司将持续测试实施作为其DevOps战略的一部分。
使业务风险成为您的指标的驱动因素
大多数公司承认他们正确度量和管理业务的能力存在差距，但是对风险管理，仍然乐观。这对于完全自动化来说是危险的 - 而且会随着交付速度和体积的增加而恶化。首先你必须明确界定风险。其次，你必须不断衡量你的暴露与风险。接下来，使用这种理解去促进发布。通过将聚焦于高风险业务的流程和交易进行自动化测试，你降低了将严重缺陷引入生产环境的可能性。
强力推行端到端的自动化测试和QA过程
如果您的目标是更快地提供高质量的软件（它的确应该是）那么，你需要自动化你的软件开发流水线。 更成熟的敏捷和DevOps公司非常重视这一点：自动化对于提高释放速度至关重要。 自动化端到端测试是关键步骤。实施持续测试，应该是考虑敏捷和DevOps领导者的优先考虑。
依据商业风险进行测试执行的排序
了解哪些测试可以守护最大的风险范围是决定速度时的显著优势。 测试执行优先排序的能力取决于开发模型中开发和测试的协作和业务利益相关方的各种合作。
持续测试的最大障碍
正如前面的研究所指出的那样，进行持续测试的占比率极低（26％），即使在积极实施敏捷和Devops的组织中也是如此。这一开始看起来令人震惊，但是它在你探索了多数组织以后变得合理。团队通常会通过尝试界面测试或者集成测试来开始他们的持续测试旅程。他们会实现和庆祝小胜利，但这个过程并没有扩大。事实上，它在衰减。为什么？它通常归结为
以下三类障碍：
1.时间和资源
2.复杂性
3.结果
时间和资源
团队严重低估了自动化测试所需的时间和资源，通过跑一些UI测试式一个好的开端，但是，随后你需要计划所需的时间和资源：
- 为了测试异常而保持冗长的脆弱性测试脚本。
- 为每个新的/修改的要求创建测试（或确定在哪里集中精力以及你可以跳过的内容）。
•建立支持重用和数据驱动测试的测试框架 - 这两者对于支持长期的自动化测试都是必不可少的。
当您刚刚开始测试自动化时，处理误报可能是可行的。 但是，当你的测试套件增长，测试频率增加，解决错误积极因素很快成为一项不可逾越的任务。最终，许多团队要么开始忽视误报（这会被侵蚀信任测试结果和持续测试计划）或给予
完全依靠测试自动化。
当DevOps和持续交付计划发挥作用时，结果出现了另一个关键问题：他们没有基于风险的洞察力提供需要做出的快速决定。 如果你曾经看过测试结果，你可能看到过这样的事情：
这个真正的告诉你什么？你可以看到......
•共有53,274个测试用例。
•几乎80％的测试通过。
•超过19％的人失败了。
•约1％未执行。
但是你愿意基于以上的结果来决定是否发布一次版本么？也许测试失败与一些微不足道的事情有关功能。也许它们是最关键的功能， 系统的“引擎”。或者也许是您最关键的功能甚至没有经过彻底的测试。试图追查这一点，信息需要大量的人工调查工作。产生延迟的，通常不准确的答案。
在敏捷和DevOps时代，需要迅速的做出发布决策 - 甚至自动和及时。测试结果专注于测试用例的数量会给你留下巨大的盲点。这变得非常关键，而且非常危险。你正在以敏捷和DevOps的速度前进。
如果您的结果没有表明您的业务关键程度的功能经过测试和运行，您不能依赖它们推动自动化的交付管道。会被要求需要人工审查和评估......这不可避免地会延迟每一次交付。
达到持续测试的途径
根据我们指导企业测试团队的经验，避开常见的实现成熟持续测试的障碍对DevOps和敏捷成功至关重要，Tricentis
开发了持续测试成熟度模型。我们发现了这是推出连续测试的最有效途径。这是一种对团队来说可持续的方式 - 对领导者来说很有价值，旨在加速交付而不会产生不可接受的商业风险。
您可以使用此模型来评估您今天所处的位置，了解从一个级别进入下一个级别所需的内容
第1级：典型的起点
在此初始级别，关键指标是测试用例的数量。
所有测试用例都是根据测试人员的直觉设计的。测试是使用基于脚本的手动或部分自动执行方法（导致误报率很高，需要不断的维护）。测试人员必须手动确保测试合理的数据。（例如通过本地化和改进测试数据）并要在测试环境中等待配置的依赖项。任何API测试是开发人员的领域。
第2级：对齐
风险评估已经完成，测试用例定义和执行的关键指标已经变成风险守护。测试自动化仍然专注于UI，但现在使用基于模型的测试自动化（MBTA），显着降低误报率和维护工作。由于仍然没有全面的测试数据管理到位，自动化主要关注新数据对象创建而不是复杂的用例管理。
第3级：管理
引入基于会话的探索性测试来揭示风险。基于规范的测试无法找到（例如在功能方面已经超出规范的范围实施）。有额外的测试用例被定义，通过组合测试用例设计。。如果功能是通过API来暴露，则API测试在测试人员级别引入。 MBTA驱动的UI测试在API测试不适用或者无效的领域。自动化测试通过与构建和部署工具的初始集成，被引入持续集成中。
第4级：成熟
测试数据管理现在能提供所需的测试数据，可以实现连续，一致的测试自动化。服务虚拟化确保即使依赖不稳定或者不确定的组件也可以继续进行测试。TDM和服务虚拟化都能实现更复杂的功能、API和端到端的测试。
持续测试的执行现在可以作为软件持续交付渠道的一部分。- 提供与发布版本相关的有关业务风险的即时反馈。
第5级：优化
已经建立了全面的自动化测试。有复杂的有状态服务虚拟化和支持测试数据生成/配置。度量标准已到位以进行监控
并不断提高软件的有效性和测试过程。持续测试完全集成到持续集成和持续交付管道。通过流程，人员和产品转变，“DevTestOps”的转型已完成。
结论
随着软件成为创造竞争优势的关键，在所有市场中，企业不再享受在交付软件时有选择“效率”或“质量”的权力。这两者都至关重要。现在，敏捷实践已经成熟，DevOps计划已连续进入企业议程，持续集成，持续测试和持续交付成为提高质量的关键催化剂。持续测试是迄今为止最具挑战性的。
虽然持续集成主要是工具驱动的活动，持续交付是一种工具和团队驱动的活动，持续测试是涉及到工具，团队，个人和服务的多个方面。构建并集成代码更改当然很重要。但是，如果自动交付流程无法识别变更的影响，商业风险或扰乱终端用户体验，持续集成和持续交付频率和速度的加快可能变成一种负债而非资产。
正确的执行持续测试应该是作为敏捷落地流程的核心部分 - 执行自动化测试作为软件交付管道的一部分，以提供基于风险的反馈尽快。在日益复杂的现代应用的快速交付过程中，掌握持续测试对于控制业务风险至关重要。
CC先生的预测：在CI/CD的概念被爆炒后，CT的概念会持续走强。毕竟牺牲质量的发布和交付不仅是厂商的损失也是客户不愿承担的升级之痛。
