自动化测试与持续测试的区别

测试人员多年来一直在与自动化测试进行斗争，但大多数团队对他们当前的自动化测试水平或维护它所需的开销不满。此外，在过去几年中，软件的架构，开发和使用方式也发生了翻天覆地的变化 - 增加了测试的复杂性和软件故障的业务影响。

鉴于软件交付的复杂性和速度的增加，软件测试专业人​​员如何帮助控制业务风险呢？
你需要的是持续测试。

持续测试

什么是持续测试？

持续测试是一个过程，它将自动化测试作为软件交付通道中内嵌的一部分，以尽快获得软件发布后业务风险的反馈。

持续测试与自动化测试的侧重点

• 自动化测试旨在生成一组与用户故事或应用程序要求相关的通过/失败的数据点。
• 持续测试侧重于业务风险，并提供有关软件是否可以发布的判断。要实现这一转变，我们需要停止询问“我们是否已完成测试？”而是集中精力在“发布版本是否具有可接受的业务风险级别？”

持续测试的重要性

为什么我们需要持续测试？

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

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

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

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

持续测试和自动化测试的区别

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

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

风险

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

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

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

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

广度

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

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

时间

现在，组织运送软件的速度已成为竞争优势，绝大多数组织正在转向敏捷和DevOps以加速其交付流程。

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

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

测试的重要性

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

• 测试必须成为开发过程的一部分（而不是在开发完成时加上“保健”任务）
• 实现完相关功能后测试必须马上准备好运行
  -组织必须有办法确定在交付管道的不同阶段执行的正确测试（签入时的冒烟测试，集成后的API /消息层测试，系统级别的端到端测试，…）
• 每组测试必须足够快地执行，以免在软件交付管道的相关阶段产生瓶颈
• 需要一种稳定测试环境的方法来防止频繁更改导致大量误报
• 持续测试>测试自动化

而以上内容，都能透出一个重点：

• 自动化测试≠连续测试

• 持续测试>自动化测试

即使是使用传统测试自动化工具取得了相当成功的团队，当他们的组织采用现代架构和交付方法时，也会遇到严重的障碍：

• 他们不能足够快或足够频繁地创建和执行真实的测试
• 持续的软件更改会导致大量的误报，并且需要看似永无止境的测试维护量
• 他们无法提供关于发布版本是否风险太大而无法通过交付渠道的即时洞察
• 重要的是要认识到没有任何工具或技术可以立即给你持续测试。
  与Agile和DevOps一样，持续测试需要在整个人员，流程和技术方面进行变革。然而，当你的技术无法完成任务时，尝试启动人员和流程的相关变化，从一开始就是一场艰苦的战斗…最终会失败。

如果您的组织正在开始或扩展您的持续测试自动化工作，我们建议您查看Forrester和Gartner的两项新研究。这两份报告都提供了对持续测试和测试自动化趋势的深入了解，以及顶级持续测试工具的比较。

CC先生说，持续的名词模式已经成为现在企业转型的一个热度词汇。

不管是精益中提倡的 持续改善，还是Devops里提倡的CI（持续集成） --> CD(持续部署) --> CT（持续测试） --> CD（持续交付）

持续进化终归是演进的一个大前提。

备注：
集成是指软件个人研发的部分向软件整体部分交付，以便尽早发现个人开发部分的问题；
部署是代码尽快向可运行的开发/测试节交付，以便尽早测试；
交付是指研发尽快向客户交付，以便尽早发现生产环境中存在的问题。

传统测试、敏捷测试和持续测试有何不同

传统测试以手工测试为主，对代码级别的测试投入较少，整体呈倒三角模式, 侧重于发现缺陷并修复；敏捷的出现增大了自动化测试的比例，以底层运行速度快、消耗小的单元测试为主，整体呈正三角模式，相比传统测试反馈更及时，修复缺陷的成本低；持续测试在敏捷测试的基础上，强调测试持续进行，通过各部门的协同工作，持续发现缺陷并迅速修复。

DevOps时代的测试应该怎么做

Laurent曾经从测试左移、右移的角度描述了当软件开发模式从瀑布到敏捷、再到DevOps转型时，测试应该如何相应变化。

测试左移
是指测试人员更早地参与到软件项目前期的各项活动中，在功能开发之前定义好相关的测试用例，提前发现质量问题。早期引入测试过程有助于防止缺陷，并为开发人员提供了在整个开发阶段应用动态变更的灵活性。

测试右移
就是直接在生产环境中监控，并且实时获取用户反馈。在这种方法中，从用户侧收集反馈，根据用户反馈持续改进产品的用户体验满意度，提高产品质量。测试右移有助于更好的响应意外情况。

传统测试主要集中在软件开发周期的最后，产品发布之前。为了迎合不断加快的交付频率，越来越多团队的测试活动开始向左右两侧移动。
一般问题修复成本较高和面向企业收费的软件，一旦生产环境中出现了问题会造成比较大的损失，通常采取测试左移的方式；对于具有展示功能的软件产品，更容易在生产环境中发现问题，通常采取测试右移的方式。面对测试左右摇摆的问题，
以下几个阶段阐述了DevOps中的测试具体应该如何实现。