云原生应用的测试指南 | IDCF

译者注：这是国外一篇介绍如何测试云原生应用的文章，云原生应用一般是基于微服务架构风格的分布式应用程序，传统的测试方法和技术已不能知足产品交付的质量要求，只有结合现代测试技术，既增强研发阶段的测试，又引入产品发布后的线上测试，才能有效应对云原生应用在功能、性能、安全、可靠性方面的挑战。这些新的技术包括契约测试，灰度发布，混沌工程，在线监控和日志分析等。

1、应用程序的“云原生化”

愈来愈多的公司正将本地部署的应用迁移（或计划迁移）到云上，它们的目标是设计、架构并构建的应用程序能够很容易地扩展并部署到云上，而且能够充分利用云平台（如AWS、Azure，或GCP）提供的计算模式。

“云原生化”和开发云原生应用指的是设计、架构并构建的分布式软件应用可以彻底利用云服务商提供的PaaS（Platform-as-a-Service，平台即服务）和IaaS（Infrastructure-as-a-Server，基础设施即服务）的服务模式。这些应用一般是做为一组微服务（基于微服务架构风格）构建的。

这些松耦合的微服务运行在一个由公有云、私有云和混合云提供的动态环境中的容器化和动态编排平台上（基于Kubernets、Docker等技术）。促使企业进行应用的“云原生化”尽管有不一样方面的缘由，但其中包括一些最重要的驱动因素，如：缩短重要的软件应用的宕机时间、增长应用的弹性能力、根据业务须要动态扩容或缩容，提升应用开发速度、快速响应用户需求、更专一于创新从而增长更多的业务价值。

2、云原生应用的测试方法

测试老是帮助咱们更深刻地挖掘问题，并向用户交付高质量的产品。软件测试在帮助咱们收集产品的状态、可维护性、性能、健壮性和可靠性等大量有用信息方面发挥了重要做用。经过对这些信息进行分析，企业的决策者们能够更有信心地进行产品发布的决策。

相比其它软件应用（例如单体架构的应用）的传统测试方法，云原生应用的测试要更复杂。这是由于云原生应用是动态、分布式构建的一组微服务（每一个微服务能够独立发布），发布速度更快（一般采用CI/CD和DevOps实践），并且存在难以预测和跟踪的故障模式。

这就要求咱们适应这些变化，从新审视传统的测试技术，并采用新的、现代的测试方法来预见、检测、响应、调试、分析和报告问题。

这些测试技术将在许多方面帮助咱们找到并揭示大量信息，这将有助于提升云原生应用的总体质量。对于这类应用，软件测试已成为软件开发生命周期的全部阶段中不可分割的一部分，而且促使业务分析人员、开发人员、测试人员、架构师和软件设计人员等进行更多沟通和交流：提出疑问，共享信息，讨论并评估问题和风险。如今就让咱们一块儿看看针对云原生应用的有效的测试技术。

2.1 单元测试，集成测试，端到端的测试

经过在微服务架构的云原生应用中测试单个服务组件中的最小可测试单元，能够在开发早期阶段发现许多缺陷。快速、可靠、自动化的单元测试不只能肯定服务组件的独立单元/模块是否能正常工做，也将有助于开发人员观察单元/模块状态的变化，检查对象之间的交互，以及对象之间的依赖，对于组件的状态得到快速反馈，或者因为代码变动致使了回归缺陷等。这些测试让软件代码更具备可测试性并有利于代码的重构。

软件应用的服务组件在集成以后，由持续集成服务器触发的集成测试将有助于测试各个服务组件之间或服务组件与外部服务、系统、数据存储之间的通讯路径和交互。尽管测试全部的集成点是困难的，但团队必须采用基于风险的测试方法，根据制定的目标、范围和优先级执行测试。
对于云原生应用来讲，执行端到端测试是比较困难的，由于这涉及到微服务架构中每一个独立开发的部分，测试进度会比较缓慢，并且有时候会很是不稳定，不得不考虑到服务组件之间的异步调用和环境因素的影响。这都形成端到端的测试在测试准备、运行和维护方面的成本较高。尽管如此，研发团队仍然须要运行其中的一些端到端的测试，尽管不那么频繁，但须要覆盖重要的业务路径，并验证完整的应用是否知足业务需求。

2.2 契约测试

既然会涉及单个独立的微服务，研发团队也须要对微服务执行契约测试。微服务体系架构由“生产者”服务组件和“消费者”服务组件组成。当消费者组件试图与生产者组件结合并使用它的输出时，一个“服务契约”（由预期的输入和输出组成）就在它们之间造成。

由这些契约测试组成的自动化测试套件能够集成到流水线中，运行这些测试来验证生产者和消费者组件中的任何更改是否符合两者之间的服务契约。开发和运行契约测试是测试云原生应用的一项重要内容。

2.3 非功能测试

对于云原生应用来讲，功能测试很是重要，能够验证产品是否知足业务需求。可是，当产品发布到生产环境中，功能测试可以提供产品将以预期的方式响应的信心吗？当忽然出现服务器崩溃、服务组件宕机或某些依赖服务不可用时，服务是否可以安全降级？产品上线后是否足够安全？该产品可否应付突发的大量用户请求？

非功能测试对于云原生应用很是重要。对于上述问题，任何缺陷或者偏离预期行为的状况都要求咱们以最少的工做量和步骤尽快发现、分析并修复问题，以免这些问题再次发生。

为了确保这些问题发生的机率或影响很小，咱们须要借助有用的工具（许多工具是云提供商本身提供的）测试产品的性能（如延迟、负载平衡的影响、缓存、产品性能中的风险因素、基于性能指标来对比和提供反馈结果的基准测试等）、可用性、负载（例如在接近真实负载条件下对产品吞吐量的影响）和安全性（静态和动态），并预先处理任何潜在的风险。

2.4 混沌工程和失效模式测试

说到质量工程，咱们大多数人都知道像“FMEA”（失效模式和影响分析）技术，它能够帮助咱们识别产品中的潜在失效模式及其缘由和后果。对于单体应用，大多数潜在的故障模式是已知的，能够识别的，所以能够在代码结构中处理。即便不处理，当缺陷发生时也可以快速修复。

可是对于微服务来讲，产品在生产环境中失败的方式是难以计数、不可预测的，由于涉及到大量的复杂性。在这些状况下，“混沌工程”会颇有帮助。它是一种识别在生产环境中产品失效的方法，以创建对系统应对意外或未知操做能力的信心。

“混沌工程”和FMEA一块儿，经过注入可控的故障，帮助咱们得到一个可靠性和弹性能力更高的产品，让咱们可以检测和分析这些故障，从而预知产品在哪些方面会出故障。这将帮助咱们调整现有的流程，以防止故障级联的后果，并提早计划如何缩短MTTR（Mean Time to Recovery/Restore，故障平均恢复时间）。

2.5 可观察性、在线监控和日志分析

做为软件工程师，对云原生应用咱们既要在上线前进行测试也要在上线后进行测试。若是操做得当，线上测试能够为咱们提供许多有价值的信息，为计划下一个版本的弹性、可伸缩性和灵活性提供重要反馈信息。但必须记住，线上测试的设置和执行很复杂，在执行这些测试时必须很是当心，并充分考虑到，若是线上测试没有正确和安全的执行，对业务和用户带来什么样的影响。
“可观察性”是帮助咱们更好地理解产品中软件行为的方法之一，是指经过观察产品的输出来了解产品内部状态的方法。咱们可使用一些监控技术和工具收集、存储、维护和查询应用的状态、行为，以及服务之间交互相关的信息。这些日志和指标能够被进一步分析来获取有价值的发现，或者快速评估和分析缺陷。一些云服务提供商会提供开箱即用的功能和工具帮助咱们实现监控、信息收集和分析。

3、结论

咱们必须明白，不管计划和执行多少功能测试和非功能测试，不管咱们如何努力提升这些云原生应用的质量，最终用户仍然会面临问题。咱们的目标是减小意外事件的风险，快速分析和修复故障，从既往事件中学习并将这些知识用于下一个版本。

在生产环境中发现缺陷的成本是很是高的，咱们应该在软件的开发生命周期中尽早发现缺陷。在生产环境中，咱们能够利用金丝雀部署（把全部功能推送给部分用户），暗启动（把新功能/主要功能推送给部分用户），智能功能切换/标志/位/翻转器（容许特定功能的应用被激活或停用）等技术在生产环境中逐渐暴露缺陷。

但咱们也必须记住，因为各类限制因素，包括预算、团队承接能力、时间表、上市时间、大量互相依赖/独立的服务、环境的可用性等，经过已知的测试策略作详尽的测试是不可能的。所以，团队须要采起基于风险的测试方法，也必须意识到和缺陷有关的各类类型的成本，好比检测成本，分析调试成本，机会成本，修复成本，验证成本和维护成本。

考虑到全部本文中讨论的因素，能够确定的是，尽管测试云原生应用是困难和具备挑战性的，但咱们可让新的测试方结合自身的专业知识、不一样的测试技术和策略，向用户交付高质量的产品。

来源：软件质量报道
做者：Sumon Dey

5月每周四晚8点，【冬哥有话说】质量与测试专场。公众号留言“质量”可获取地址

• 0506 朱少民 《如何最大化软件测试效能》
• 0513 陈琦 《数据驱动测试》
• 0520 陈霁 《没错，去QA是提升质量最有效的方法！》
• 0527 施慧斌 《DevOps实践之持续测试》