如何测试云原生应用系统?

有充分的理由相信，向云原生迁移和采取架构/设计方法来创建云原生应用是当今大势所趋，而且这种趋势不会很快放缓。这与云计算对软件行业产生的巨大影响有很大关系，也与众多公司采用这种方法并不断向用户提供非常高质量的产品、在停机和其他问题上对用户影响最小的著名成功案例有很大关系✅。

更多的时候，我们只听到了成功的故事，而对数百个同样采用云原生架构而失败的故事却不甚了了。对于那些想在云原生战略和实践中大获全胜的公司来说，如果云原生应用系统的测试只是被视为一个可有可无的辅助活动，而不是被视为一个重要的、有价值的和综合的部分，那么就很有可能提供一个质量低下的产品，而客户/消费者体验也很差，这将导致客户流失率增加，新客户的流入减少，从而造成业务的损失。简而言之，将会是另一个失败的故事❌

在深入探讨如何有效地测试云原生应用系统的不同方法之前，让我们首先尝试理解 "云原生 "一词，以及当我们说一个公司 "走向云原生 "时，它意味着什么⛅。

1. 走向云原生

随着越来越多的公司从企业内部迁移（或计划迁移）到云端，他们的重点是设计、架构和构建可以轻松扩展、部署到云端的应用程序，并有能力完全利用云平台（如AWS、Azure或GCP）提供的计算模型的优势。

走向 "云原生" 和创建云原生应用程序是指设计、架构和构建分布式软件应用程序的方式，使其能够完全利用云服务提供商提供的底层PaaS（平台即服务）和IaaS（基础设施即服务）服务模式。大多数情况下，这些应用被构建为一套小型的微服务（基于微服务架构风格）。

这些松散耦合的微服务在公有云、私有云和混合云提供的动态环境中，运行在一个容器化和动态协调的平台上（借助于Kubernetes、Docker等技术）。尽管企业走向云原生的原因很多，但其中一些最重要的驱动因素是大幅减少应用程序的停机时间、高弹性、根据业务需求动态扩大/缩小云资源的利用率、提高开发速度、拥有高度响应用户需求的应用程序、更加注重创新，从而增加更多业务价值。

（微服务架构示意图）

2. 测试云原生应用程序的方法

测试一直在帮助我们深入挖掘，揭示问题，并向用户提供高质量的产品。它在帮助我们收集关于产品的状态、可维护性、性能、稳健性和可靠性的大量有用信息方面发挥着重要作用。经过分析，这些收集到的信息可以让决策者更有信心地决定产品的发布????。

当涉及到测试云原生应用系统时，与人们用来测试其他应用系统（如单片机）的传统方法相比，事情变得复杂。这是因为云原生应用程序更加动态、分布式建立在微服务上（可以有独立的版本），以更快的速度发布（通常有CI/CD和DevOps实践），并且存在难以预测和跟踪的故障模式。这就要求我们适应变化，审查传统的测试技术，并包括一些新的和现代的方法来预见、检测、响应、调试、分析和报告问题。

这些测试技术将在很多方面帮助我们发现和揭示很多信息，这将有助于提高云原生应用程序的整体质量。因此，对于这样的应用程序，测试应该是软件开发生命周期的所有阶段（包括生产前和生产后）的一个组成部分，它有望引发业务分析师（BAs）/开发人员/测试人员/架构师/设计师之间的更多对话，在这些对话中，问题将被提出，信息将被收集/共享，问题/风险将被讨论和评估。

现在让我们来看看可以用来有效测试云原生应用程序的技术????

3. 单元测试、集成测试、端到端测试

在云原生应用程序的微服务架构设置中，通过测试各个可测试服务组件的小颗粒部分，可以在开发生命周期的早期发现许多问题（bug）。这些快速、可靠和自动化的单元测试不仅可以确定服务组件的各个单元/模块是否正常工作，还可以帮助开发者观察单元/模块状态的变化，检查其中的对象之间的交互，以及它们的依赖关系，快速获得关于这些组件状态的反馈/信息，或者某些东西是否由于某些代码变更而退步。这些测试将使应用程序代码更具有可测试性并易于重构。

一旦服务组件被集成，由CI服务器触发的集成测试将有助于测试各个服务组件之间或服务组件与一些外部服务/系统/数据存储之间的通信路径和互动。虽然很难测试所有的集成点，但团队必须采取基于风险的方法，在确定的目标、范围和权衡下进行测试。

对云原生应用执行和运行相对较大的端到端测试（end-to-end testing）是很困难的，因为它涉及到测试微服务架构的每一个移动部分，速度很慢，有时还很不稳定，必须考虑到服务组件和环境之间的异步性，因此在设置、运行和维护方面可能会变成一种昂贵的活动。尽管如此，团队仍然需要运行一些这样的测试，尽管频率较低，以涵盖一些重要的用户旅程，并验证完整的应用程序是否满足业务需求。

4. 契约测试

由于会涉及个别独立的微服务，团队也需要进行契约测试。微服务架构由 "生产者/提供者" 服务组件和 "消费者 "服务组件组成。当消费者试图与服务提供者的接口耦合以使用其输出时，将在它们之间创建一个 "服务契约"（由预期输入和输出组成）。

由这些契约测试组成的自动化测试套件可以被集成到集成管道中，一旦运行，它们将验证提供者或消费者组件的任何变化是否符合它们之间的服务契约。创建和运行契约测试是测试云原生应用程序的重要活动。

（契约测试示意图）

5. 非功能测试

对云原生应用程序进行功能测试是很重要的，因为它们可以确保产品满足业务需求。但是，他们能否确保并提供信心，使产品在投入生产时能以预期的方式作出反应？当服务器突然崩溃或服务组件瘫痪或一些依赖性服务不可用时，产品能否优雅地退化？产品在投入生产时是否足够安全？产品能否处理用户请求的突然激增？

在为云计算构建产品时，测试这些非功能质量方面也是非常重要的。在这些方面的任何问题或偏离预期的行为，都需要以最小的努力尽快检测、调试和修复，并且需要采取措施使这些情况不再发生。为了确保这些情况在生产中发生的几率较小或影响最小，在良好和有用的工具（许多是由云计算供应商自己提供的）的帮助下，我们必须测试产品的性能（如 延迟、负载平衡/缓存/风险条件对产品性能的影响、基准测试，以便根据商定的性能指标对性能结果进行比较并提供反馈）、可用性、负载（例如，在接近真实的负载条件下对产品吞吐量的影响）和安全性（包括静态和动态），并事先解决任何潜在的风险。

6. 混沌工程和失效模式测试

说到质量工程，我们大多数人都知道像 "FMEA"（故障模式和影响分析）这样的技术，它可以帮助我们识别产品中的潜在故障模式及其原因和影响。对于单体应用来说，大多数潜在的故障模式是已知的，可以被识别出来，因此可以在代码结构中处理，如果不处理的话，也可以迅速修复。

但是对于微服务来说，由于涉及到大量的复杂性，产品在生产中失败的方式可能是无限的，也是不可预测的。在这种情况下，"混沌工程 "可以提供很多帮助。它是一种识别生产中故障的方法，以建立对系统应对意外情况或未知行动的能力的信心。

（执行混沌工程的10个步骤）

与FMEA一起，它可以帮助我们有一个更可靠和有弹性的产品，通过注入小的受控故障，使我们有可能检测和分析这些故障，从而为我们提供一个可能出错的感觉。这将有助于我们调整现有的流程，以防止连带的后果，并及早计划在发生故障时缩短产品的MTTR（平均恢复/恢复时间）。

7. 可观察性、监控和日志分析

作为软件工程师，我们必须对云原生应用程序进行上线前和上线后的测试。如果操作得当，生产中的测试可以为我们揭示很多有价值的信息，这些信息在规划下一个版本的弹性、可扩展性和灵活性时可以作为重要的反馈。但我们必须记住，这些测试的设置/执行是很复杂的，我们在执行这些测试时必须小心，并注意到如果这些测试没有正确和安全地进行，会对业务和用户产生影响。

帮助我们更好地理解生产中的软件行为的方法之一是 "可观察性"（Observability）。它被定义为通过观察产品的输出来了解产品内部状态的能力的方法。还有 "监控 "技术和工具，利用这些技术和工具，我们可以收集/存储/维护/查询与生产中的应用状态/行为/服务之间的交互有关的信息，利用度量和日志来解释和显示它们。这些日志和指标可以进一步分析，以获得有价值的见解或快速评估和调试问题。一些云供应商提供开箱即用的功能和工具来帮助这些活动。

结论

我们必须明白，无论我们计划和做多少功能和非功能测试，无论我们如何努力提高这些云原生应用程序的质量，终端用户仍然会面临问题。我们的目标将是减少意外事件的风险，快速分析、调试和修复问题，从事件中学习并将这些知识用于下一个版本。

在生产中发现问题可能是非常昂贵的，我们应该在开发生命周期中尽可能早地发现问题。在生产中，我们可以利用金丝雀部署（Canary Deployments，  一种灰度发布，向一部分用户推出所有功能作为初始测试）、黑暗发布（Dark launch，一种灰度发布，向一部分用户推出新的/主要的功能作为初始测试）、智能功能切换/标志/位/翻转器（smart Feature Toggles/Flags/Bits/Flippers ，允许应用程序的特定功能被随意激活或停用）来继续查找问题。

但我们也必须记住，由于与预算、生产力、时间表、上市时间、大量的依赖/独立服务、环境可用性等相关的各种限制因素，通过应用所有已知的测试策略进行详尽的测试是不可能的。因此，团队需要采取基于风险的测试方法，他们还必须意识到，如果用户在生产中发现问题，所涉及的各种类型的成本，如检测成本、调试成本、机会成本、修复成本、验证成本和维护成本。

考虑到在这篇文章中讨论的所有因素，可以得出这样的结论--尽管测试云原生应用程序是困难和具有挑战性的，但我们可以利用我们的专业知识和不同的测试技术和策略的知识，并将它们与新的和现代的方法相结合，以帮助向用户提供高质量的产品????。