持续测试是在软件开发生命周期 (SDLC) 的不同阶段纳入自动反馈的过程，有助于提高管理部署的速度和效率。

持续测试是 CI/CD（持续集成/持续交付）流程取得成效的关键驱动因素，通过提高代码质量、避免代价高昂的瓶颈和加快 DevOps 流程，在加快 SDLC 时间表方面发挥着至关重要的作用。

开发实用的 DevOps 方法的基本原则之一，就是在快速交付软件和确保可靠的用户体验之间取得平衡。然而，在每个软件开发阶段（即项目设计、编码、测试、部署和维护）手动获取反馈的传统方式，导致未能充分以及无效利用组织的资源，最终导致集成周期延长和产品更新延迟。

持续测试通过帮助 DevOps 团队“左移”来解决这些低效率问题，在 SDLC 的早期为他们提供有价值的反馈，同时自动化手动测试流程并最大限度地减少人为错误。

持续测试的工作原理是使用自动化工具在生产的各个阶段加载预定义的 QA 脚本。在运行质量保证测试时，这些自动脚本消除了常规人工干预的需要，并按顺序验证源代码的效率，同时确保立即向相关团队提供任何相关反馈。

如果自动测试失败，开发团队会在开发的各个阶段得到通知，这样他们就可以对源代码进行必要的调整，以免影响到处于 SDLC 不同阶段的其他团队。如果自动化测试通过检查，项目将自动传递到 SDLC 的下一阶段，使组织能够创建可持续的交付模型，最大限度地提高生产力并改善部门间协调。

在下面的视频中，Eric Minick 进一步探讨了这个主题：

将持续测试纳入 DevOps 流程可为成长型企业带来多种好处。

更高的效率和更高质量的部署。持续测试提供了一种自动化方法，用于在软件开发生命周期 (SDLC) 的每个阶段管理质量保证和工作流程之间的质量互操作。通过将持续的反馈循环集成到用户和单元测试模块中，开发人员可以在部署之前获得切实可行的洞察，从而提高代码兼容性和性能。这种效率解决了多个 DevOps 团队成员之间的脱节问题，并支持加速软件交付计划。

分布式项目的快速错误发现和修复。当今的现代开发体系结构是多方面和多层次的。持续测试通过采用可扩展的自动测试解决方案，帮助开发团队打破这些复杂性，从而显著改善错误发现和修复的时间线。

改善用户体验。先进的持续测试方法可以模拟各种独特的用例和故障诊断场景，并观察用户如何响应。从这些模拟中获得的洞察力使开发人员能够及早消除用户界面中的低效问题，避免在实际产品部署后出现不必要的意外。

由于与开发相关的业务中断而降低了成本。特别是在大型互连系统中，只要应用程序中的一个模块出现错误，就会产生连锁反应，从而导致不必要的停机，对生产率和利润造成负面影响。

例如，云提供商经常报告一个端点发生故障，导致整个地区瘫痪，造成长达数小时的中断。对于依赖高服务可用性的组织来说，这可能尤其具有破坏性。精细化的持续测试可以识别大型软件系统中可能不可见的错误，并有助于避免业务中断的成本。

持续测试涉及一系列确保系统可靠性、安全性、操作性能和可用性的测试。谱系测试包括以下内容：

• 左移测试：这种方法优先考虑在软件开发生命周期 (SDLC) 的早期阶段进行软件和系统测试，以帮助减少或防止出现重大的调试问题。
  
  
• 右移测试：这种方法优先考虑在 SDLC 结束时进行测试，重点是改善用户体验、整体性能、容错能力和功能。
  
  
• 冒烟测试：这些测试可以是手动的，也可以是自动的，可以初步粗略地筛选出软件中的明显缺陷。虽然冒烟测试的结构并不复杂，但它仍然为消除软件中的重大错误提供了一种快速而成本低廉的解决方案。
  
  
• 单元测试：这些测试非常适合在整个构建过程中进行小规模的压力、负载、容量或内存泄漏检查，以便在早期开发阶段识别性能下降问题。
  
  
• 集成和消息传递测试：当软件模块相互配合工作时，它们会检查是否存在错误。持续测试将缺失的依赖关系虚拟化，这样团队就能测试端到端流程和方案的整体性能。然后在运行时编译并执行复合代码，以测试它们是否按预期执行。
  
  
• 性能测试：测试应用软件的性能本身可能没有考虑到最终生产环境中的硬件和中间件。需要集成系统测试来有效评估解决方案的整体性能。
  
  
• 功能测试：这种形式的测试检查用户体验是否符合预期，以及功能工作流是否在软件系统中按需执行。例如，供应链软件应能在库存可供装运时提醒卡车到达工厂。（相比之下，非功能测试侧重于性能、可用性、可靠性、响应时间、加载时间、可扩展性等，并衡量软件是否准备好提供所需的客户体验。）
  
  
• 回归测试：此测试检查在任何依赖软件中的错误得到纠正后，性能、功能或依赖性是否有任何变化，以及系统是否能像以前一样运行。
  
  
• 用户接受测试：这也称为应用测试或最终用户测试，是指在现实情况下由某些预期用户子集对应用程序进行测试。Beta 测试是用户接受测试的一个例子。

信息技术系统和应用程序具有以下特点，因此出现错误的风险更大：

• 它们越来越多地与许多新兴技术集成，例如云计算、物联网 (IoT)、软件定义网络、增强现实 (AR)
  
  
• 它们越来越多地分布在多个区域，具有无缝互连的核心和边缘。智能城市、自动驾驶汽车和智能公用事业的应用程序都是这种体系结构的受益者

在这些情况下，持续测试的要求更高，因为开发不是在单一地点或单个公司进行。第三方（包括远程团队）可能会提供系统的某些元素。该系统可以与应用程序编程接口 (API) 集成。每个开发团队都在不同的 IT 环境（包括原有软件）中运行。每个团队的实际环境都不可能重现，无法进行持续测试。

幸运的是，可以对持续测试进行虚拟化，从而创建一个测试环境，可以在单个界面中虚拟复制整个系统。可轻松重新配置虚拟化环境，以测试不同的 IT 系统或为纠正错误而更改的系统

在 DevOps 环境中，持续测试在整个软件开发生命周期 (SDLC) 中自动执行，并与持续集成紧密结合，自动验证集成到应用程序中的任何新代码。

测试工具预装入了测试脚本，每当新代码集成到应用程序中时，测试脚本就会自动执行。通常情况下，测试从集成测试开始，自动转入系统测试、回归测试和用户接受测试。

测试从每个应用程序模块生成数据源，并对这些源进行分析，以确保受新代码影响的所有模块均按预期运行。如果测试失败，代码将返回开发团队进行修正；然后重新集成并重新开始测试周期。

如果所有测试都通过，应用程序或项目就会进入 SDLC 的下一阶段，通常是持续交付。

请参阅 Andrea Crawford 对 DevOps 的解释，了解相关背景：

测试集需要一个持续测试框架，以确保它们在应用程序中的各个模块、连接器（或 API 和容器）、平台、基础架构以及定义其需求的场景中保持一致。

测试集可以是连续的（例如，单元测试后进行回归测试），也可以是并发的（例如，一个模块的新迭代伴随着一个测试和针对其依赖关系的相应测试）。

持续测试框架为测试集提供了一个包装器，使它们的应用保持一致，并为自动化做好准备。开发人员希望确保他们为某个模块所采取的方法与相关模块所采取的方法没有什么不同。当模块演进时，相互关联软件的各种测试也会随之变化。

框架提供了一种标准方法，来方便地修改脚本和功能以进行测试。如果能消除测试中的不一致性，自动化就会有所收获，否则就会产生一系列误导性的测试结果。