什么是持续测试？

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

开发实用的 DevOps 方法的基本原则之一，就是在快速交付软件和确保可靠的用户体验之间取得平衡。

然而，在每个软件开发阶段（例如项目设计、编码、测试、部署和维护）手动获取反馈的传统方式，导致未能充分以及无效利用组织的资源，最终导致集成周期延长和产品更新延迟。

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

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

如果自动测试失败，开发团队会在开发的各个阶段得到通知，这样他们就可以对源代码进行必要的调整，以免影响到处于 SDLC 不同阶段的其他团队。

如果自动化测试通过检查，项目将自动传递到 SDLC 的下一阶段，使组织能够创建可持续的交付模型，最大限度地提高生产力并改善部门间协调。

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

更高的效率和更高质量的部署：持续测试可以提供一种自动化方法，用于管理 SDLC 每个阶段的工作流之间的质量保证和质量互操作。

通过将持续的反馈循环集成到用户和单元测试模块中，开发人员可以在部署之前获得切实可行的洞察，从而提高代码兼容性和性能。这种效率解决了多个 DevOps 团队成员之间的脱节问题，并支持加速软件交付计划。

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

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

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

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

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

左移测试：这种方法优先在 SDLC 的早期阶段进行软件和系统测试，以帮助减少或防止出现重大的调试问题。

右移测试：这种方法优先考虑在 SDLC 快结束时进行测试，重点是改善用户体验、整体性能、容错能力和功能。

冒烟测试：这些测试可以是手动的，也可以是自动的，可以初步粗略地筛选出软件中的明显缺陷。尽管冒烟测试的构造并不复杂，但它仍然为消除软件中的严重错误提供了一种快速且便宜的解决方案。

单元测试：这些测试非常适合在构建过程中进行小规模的压力、负载、容量或内存泄漏检查，以识别早期开发阶段的降级问题。

整合和消息传递测试：当软件模块相互协作时，检查是否存在错误。持续测试将缺失的依赖关系虚拟化，这样团队就能测试端到端流程和方案的整体性能。然后，将对复合代码进行编译并在运行时启动，以测试它们是否按预期执行。

性能测试：只测试应用软件本身的性能可能不会考虑到最终生产环境中的硬件和中间件。需要集成系统测试来有效评估解决方案的整体性能。

功能测试：这种形式的测试检查用户体验是否符合预期，以及功能工作流程是否在整个软件系统中按需启动。例如，供应链软件应能在库存可供装运时提醒卡车到达工厂。

相比之下，非功能测试侧重于性能、可用性、可靠性、响应时间、加载时间和可扩展性。它衡量软件是否准备好提供所需的客户体验。

回归测试：此测试检查在任何依赖软件中纠正错误后，性能、功能或依赖关系是否有任何变化，以及系统是否按之前的方式运行。

用户验收测试：也称为应用程序测试或最终用户测试，即由部分目标用户在真实情况下测试应用程序。Beta 测试是用户验收测试的一个例子。

由于以下特征，IT 系统和应用程序出现错误的风险更大：

它们越来越多地与云计算、物联网 (IoT)、软件定义的网络和增强现实 (AR) 等许多新兴技术整合在一起。

它们越来越多地分布在多个区域，核心和边缘保持无缝互连。智能城市、自动驾驶汽车和智能公用事业的应用程序都是这种架构的受益者。

在这些情况下，持续测试的要求更高，因为开发不是在单一地点或单个公司进行。第三方（包括远程团队）可能会提供系统的某些元素。

该系统可以与应用程序编程接口 (API) 集成。每个开发团队都在不同的 IT 环境（包括旧版软件）中运行。每个团队的实际环境都不可能重现，无法进行持续测试。

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

在开发运维环境中，持续测试在整个 SDLC 中自动执行，并与持续集成紧密结合，以自动验证集成到应用程序中的任何新代码。

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

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

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

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

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

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

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