持续测试

为什么需要做持续测试？

现如今，整个行业的变化要求测试更多，同时使自动化测试更难实现（至少使用传统工具和方法）：

• 应用程序体系结构越来越分散和复杂，包含云，API，微服务等，并在单个业务事务中创建几乎无限的不同协议和技术组合。

• 由于敏捷，DevOps和持续交付，许多应用程序现在每两周发布一次，每天发布数千次。因此，可用于测试设计，维护和特别是执行的时间大大减少。

• 既然软件是业务的主要接口，那么应用程序故障就是业务失败 - 如果它影响用户体验，即使是看似微不足道的小故障也会产生严重后果。因此，与应用相关的风险已成为即使是非技术性商业领袖的主要关注点。

• 软件测试人员面临日益复杂的应用程序，他们被期望给新的商业模式提供更值得信赖的是否可用的决策。传统的测试方法不会使我们成功。我们在转变开发模式的同时也需要将测试过程转换为更加显性，这需要更多有效的自动化测试。它需要一种不同的方法，称为持续测试。

什么是持续测试？

持续测试是一个将自动化测试作为软件交付管道的一部分的过程。目的是为在软件快速发布时及时获取到与之相关的业务风险的反馈。

 

持续测试不需要任何特定类型的测试方法（例如左移，右移...）或测试工具。但是，它需要：

• 在正确的时机将可行的反馈意见提供给正确的利益相关
• 测试发生在软件交付管道的所有

自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败数据的检查点，另一方面，持续测试侧重于业务风险并提供有关软件是否可以发布的见解。 要想达到这个转变，我们得停止问：“我们是否完成了测试？”而是专注于，“发布版本是否达到了一个可接受的商业风险水平？“

持续测试与自动化测试有何不同？

持续测试和自动化测试之间的主要区别可分为三大类：风险，广度和时间。

风险

今天的企业不仅向最终用户展示了他们的许多内部应用程序，他们还开发了大量额外的软件，可以扩展和补充这些应用程序。例如，航空公司远远超出了飞机预订系统。他们现在让客户计划和预订完整的假期，包括酒店，租车和游玩活动。向用户展示越来越多的创新功能现在是竞争优势 - 但它也增加了潜在故障点的数量，种类和复杂性。

大规模的“软件失败”产生了如此严重的业务影响，以至于与应用相关的风险现在成为企业公共财务报告的重要组成部分。鉴于[值得注意的软件故障导致股票价格平均下跌-4.06％]（相当于平均25.5亿美元的市值损失），企业领导人正在注意并期望IT领导者采取行动并不奇怪。

如果您的测试用例没有考虑到业务风险，那么您的测试结果将无法提供评估风险所需的洞察力。大多数测试旨在提供有关用户故事是否正确实现要求的低级详细信息，而不是高级别评估发布版本是否风险太高而无法发布。你会根据测试结果立即停止发布吗？如果没有，您的测试与业务风险不一致。

需要明确的是：我们并不是说低粒度测试没有价值; 我们要说的是，需要更多的措施来阻止高风险的版本失去控制。

广度

即使一家企业设法避开大型软件失败成为头条新闻，即使是看似微不足道的故障仍然可能会造成麻烦。如果用户体验的任何部分未能满足他的期望，您不仅有可能将该客户丢失给竞争对手 - 如果该用户决定将他的问题带到社交媒体上，您还可能面临品牌损害风险。

只知道单元测试失败或通过UI测试并不能告诉您最近的软件更改是否会影响整体用户体验。为了保护最终用户体验，您需要足够广泛的测试来检测软件更改何时无意中影响用户所依赖的功能。

时间

现在组织发布软件的速度已经成为绝大多数竞争优势，大部分的组织正在转向敏捷和DevOps来加速他们的交付流程。

当自动化测试出现时，它专注于测试根据瀑布式开发过程构建和更新的内部系统。系统都在组织的控制之下，在测试阶段准备好开始之前，一切都已完成并准备好进行测试。既然敏捷流程正在成为常态，那么测试必须与开发并行开始; 否则，用户故事不太可能在极度压缩的迭代时间范围内（通常是两周）进行测试并被视为“完成”。

如果您的组织已采用DevOps并且正在执行持续交付，则可能每小时或甚至更频繁地发布软件。在这种情况下，过程每个阶段的反馈不能只是“快速”; 它必须几乎是瞬间完成的。如果质量不是您软件开发的首要考虑因素（例如，如果在生产中发现缺陷时进行回滚的影响很小），则在每个版本上运行一些快速单元测试和冒烟测试可能就足够了。但是，如果企业想要软件到达最终用户之前最小化风险，则需要一些方法来实现必要的风险覆盖水平和快速测试。

对于测试，有几个重大影响：

• 测试必须成为开发过程的一部分（而不是在开发时加上“XX任务”完成了）。

• 实现完相关功能后测试必须马上准备好运行

• 组织必须有办法确定在交付管道的不同阶段执行不同的测试（check-in以后的冒烟测试，集成以后的API /消息层测试，系统层的端到端测试）

• 每组测试必须足够快地执行，以免在软件交付管道的相关阶段产生瓶颈

• 需要一种稳定测试环境的方法来防止频繁更改导致大量误报

持续测试的最大障碍

持续测试的占比率极低（26％），即使在积极实施敏捷和Devops的组织中也是如此。这一开始看起来令人震惊，但是它在你探索了多数组织以后变得合理。团队通常会通过尝试界面测试或者集成测试来开始他们的持续测试流程。他们会实现和庆祝小胜利，但这个过程并没有扩大。事实上，它在衰减。为什么？它通常归结为以下三类障碍：1.时间和资源2.复杂性3.结果

时间和资源
团队严重低估了自动化测试所需的时间和资源，通过跑一些UI测试式一个好的开端，但是，随后你需要计划所需的时间和资源：

• 为了测试异常而保持冗长的脆弱性测试脚本。
• 为每个新的/修改的要求创建测试（或确定在哪里集中精力以及你可以跳过的内容）。
  •建立支持重用和数据驱动测试的测试框架 - 这两者对于支持长期的自动化测试都是必不可少的。

当您刚刚开始测试自动化时，处理误报可能是可行的。 但是，当你的测试套件增长，测试频率增加，解决错误积极因素很快成为一项不可逾越的任务。最终，许多团队要么开始忽视误报（这会被侵蚀信任测试结果和持续测试计划）或给予完全依靠测试自动化。
当DevOps和持续交付计划发挥作用时，结果出现了另一个关键问题：他们没有基于风险的洞察力提供需要做出的快速决定。 如果你曾经看过测试结果，你可能看到过这样的事情：

 

测试结果

这个真正的告诉你什么？你可以看到......
•共有53,274个测试用例。
•几乎80％的测试通过。
•超过19％的人失败了。
•约1％未执行。

但是你愿意基于以上的结果来决定是否发布一次版本么？也许测试失败与一些微不足道的事情有关功能。也许它们是最关键的功能， 系统的“引擎”。或者也许是您最关键的功能甚至没有经过彻底的测试。试图追查这一点，信息需要大量的人工调查工作。产生延迟的，通常不准确的答案。
在敏捷和DevOps时代，需要迅速的做出发布决策 - 甚至自动和及时。测试结果专注于测试用例的数量会给你留下巨大的盲点。这变得非常关键，而且非常危险。你正在以敏捷和DevOps的速度前进。
如果您的结果没有表明您的业务关键程度的功能经过测试和运行，您不能依赖它们推动自动化的交付管道。会被要求需要人工审查和评估......这不可避免地会延迟每一次交付。

实施持续测试步骤

1.尽早定义测试，甚至在编写代码之前！

缺乏明确的要求或不正确的解释会导致返工和延迟。诸如行为驱动开发（BDD），验收测试驱动开发（ATDD）和基于模型的测试之类的技术使用了诸如Cucumber / Gerkin之类的工具以及CA Agile Requirements Designer（ARD），从而使业务涉众，产品经理，开发人员和测试人员旨在确保清楚地记录和传达需求，明确定义测试用例以及提前创建测试脚本以快速进行代码测试。

2.优化测试和覆盖范围。

一些公司默认使用“一直运行所有测试”以确保代码覆盖。这浪费了资源并延长了测试周期，而实际上并未确保足够的代码覆盖率。仅测试您需要测试的内容，以节省时间，金钱和资源。可视模型允许探索和优化各种路径，使用最少的测试用例提供最大的覆盖范围。还可以在现有工具（例如Rally，Jira，HP ALM，JIRA等）中导入测试用例，删除重复项以及分发和分配优化的测试用例。

3.左移。

为了实现“ in-sprint”测试，请向左移动测试-以便可以在开发周期的早期运行测试。开发人员在进行测试。CoE提供专业知识，专门的系统和服务。测试自动化涵盖UI，功能，性能和安全性。团队一起工作，并专注于交付给客户的业务价值。这需要开发友好的工具以及文化转变。 

4.提供完整的测试环境。

测试环境对于实现持续测试至关重要。通过使用工具（如代码，CI / CD集成，受支持的开放源代码）按需提供完整的测试环境，从而消除了块并减少了等待时间。这些环境应包括：

• 虚拟服务–为不可用，无法访问或仍在开发中的服务提供强大的模拟。通过使用虚拟服务来模拟实际服务的响应，开发人员和测试人员可以继续并行工作。
• 测试数据–帮助确保团队可以使用此类数据执行全面的测试。
• 临时环境–按需准备，使用后删除。

5.获取正确的测试数据。

无法获得可靠的测试数据会导致许多应用程序发布周期中的重大延迟。为了准确地测试新功能，测试数据应尽可能接近应用程序在生产环境中会遇到的情况。如果测试数据缺乏某些真实世界的特征（即实际字段，数据规范，否定方案等），则测试不太可能发现许多潜在问题或在存在薄弱环节的情况下破坏应用程序。理解数据模型以提取正确的数据本身就是一项特殊技能。尽管生产数据显然是用于测试的最现实的数据，但数据隐私法规通常会限制其使用。解决这一难题的方法是使用强大的测试数据管理工具，例如CA Test Data Manager。TDM允许您复制生产数据并对其进行掩盖以保护敏感信息，同时保持使生产数据适合进行测试的特征：跨行的实际数据和参照完整的数据。当完全无法使用生产数据时，也可以使用TDM从头开始综合生成测试数据。

6.别忘了右移！

向右移动以使用开发周期和生产周期中的数据来优化测试周期，调整测试并构造最佳回归测试。右移技术包括实际和综合用户监视，金丝雀部署(canary deployments)，A / B测试，混乱的工程等等。例如，通过右移，您可以确定生产中使用的功能，并确保回归测试涵盖这些功能。同样，您可以向一小部分用户（内部或外部）发布新功能，了解该功能在生产中的影响，并根据需要进行调整。

FaceBook和Netflix 等许多最灵活的公司严重依赖于右移测试。Gartner最近发布了有关右移测试的报告，称其为采用DevOps实践的“必须”。 

7.使用数据和指标不断改进。

建立跨团队的协作，并通过可行的分析和反馈循环不断改进。持续交付和持续测试是一段过程。确保您所有的团队都有KPI，并且可以访问数据以进行进一步的优化。不要仅仅收集易于收集的数据，还要收集和报告数据，这些数据将为不断改进提供实际说明。

结论

随着软件成为创造竞争优势的关键，在所有市场中，企业不再享受在交付软件时有选择“效率”或“质量”的权力。这两者都至关重要。现在，敏捷实践已经成熟，DevOps计划已连续进入企业议程，持续集成，持续测试和持续交付成为提高质量的关键催化剂。持续测试是迄今为止最具挑战性的。

虽然持续集成主要是工具驱动的活动，持续交付是一种工具和团队驱动的活动，持续测试是涉及到工具，团队，个人和服务的多个方面。构建并集成代码更改当然很重要。但是，如果自动交付流程无法识别变更的影响，商业风险或扰乱终端用户体验，持续集成和持续交付频率和速度的加快可能变成一种负债而非资产。

正确的执行持续测试应该是作为敏捷落地流程的核心部分 - 执行自动化测试作为软件交付管道的一部分，以提供基于风险的反馈尽快。在日益复杂的现代应用的快速交付过程中，掌握持续测试对于控制业务风险至关重要。