译者注：这是国外一篇介绍如何测试云原生利用的文章，云原生利用通常是基于微服务架构格调的分布式应用程序，传统的测试方法和技术已不能满足产品交付的品质要求，只有联合古代测试技术，既增强研发阶段的测试，又引入产品公布后的线上测试，能力有效应对云原生利用在性能、性能、平安、可靠性方面的挑战。这些新的技术包含契约测试，灰度公布，混沌工程，在线监控和日志剖析等。
一、应用程序的“云原生化”
越来越多的公司正将本地部署的利用迁徙（或打算迁徙）到云上，它们的指标是设计、架构并构建的应用程序能够很容易地扩大并部署到云上，并且能够充分利用云平台（如 AWS、Azure，或 GCP）提供的计算模式。
“云原生化”和开发云原生利用指的是设计、架构并构建的分布式软件应用可能齐全利用云服务商提供的 PaaS（Platform-as-a-Service，平台即服务）和 IaaS（Infrastructure-as-a-Server，基础设施即服务）的服务模式。这些利用通常是作为一组微服务（基于微服务架构格调）构建的。
这些松耦合的微服务运行在一个由私有云、公有云和混合云提供的动静环境中的容器化和动静编排平台上（基于 Kubernets、Docker 等技术）。促使企业进行利用的“云原生化”只管有不同方面的起因，但其中包含一些最重要的驱动因素，如：缩短重要的软件应用的宕机工夫、减少利用的弹性能力、依据业务须要动静扩容或缩容，进步利用开发速度、疾速响应用户需要、更专一于翻新从而减少更多的业务价值。
二、云原生利用的测试方法
测试总是帮忙咱们更深刻地开掘问题，并向用户交付高质量的产品。软件测试在帮忙咱们收集产品的状态、可维护性、性能、健壮性和可靠性等大量有用信息方面施展了重要作用。通过对这些信息进行剖析，企业的决策者们能够更有信念地进行产品公布的决策。
相比其它软件应用（例如单体架构的利用）的传统测试方法，云原生利用的测试要更简单。这是因为云原生利用是动静、分布式构建的一组微服务（每个微服务能够独立公布），公布速度更快（通常采纳 CI/CD 和 DevOps 实际），而且存在难以预测和跟踪的故障模式。
这就要求咱们适应这些变动，从新扫视传统的测试技术，并采纳新的、古代的测试方法来预感、检测、响应、调试、剖析和报告问题。
这些测试技术将在许多方面帮忙咱们找到并揭示大量信息，这将有助于进步云原生利用的整体品质。对于这类利用，软件测试已成为软件开发生命周期的所有阶段中不可分割的一部分，并且促使业务剖析人员、开发人员、测试人员、架构师和软件设计人员等进行更多沟通和交换：提出疑难，共享信息，探讨并评估问题和危险。当初就让咱们一起看看针对云原生利用的无效的测试技术。
1）单元测试，集成测试，端到端的测试
通过在微服务架构的云原生利用中测试单个服务组件中的最小可测试单元，能够在开发晚期阶段发现许多缺点。疾速、牢靠、自动化的单元测试不仅能确定服务组件的独立单元 / 模块是否能失常工作，也将有助于开发人员察看单元 / 模块状态的变动，查看对象之间的交互，以及对象之间的依赖，对于组件的状态取得疾速反馈，或者因为代码变更导致了回归缺点等。这些测试让软件代码更具备可测试性并有利于代码的重构。
软件应用的服务组件在集成之后，由继续集成服务器触发的集成测试将有助于测试各个服务组件之间或服务组件与内部服务、零碎、数据存储之间的通信门路和交互。只管测试所有的集成点是艰难的，但团队必须采纳基于危险的测试方法，依据制订的指标、范畴和优先级执行测试。
对于云原生利用来说，执行端到端测试是比拟艰难的，因为这波及到微服务架构中每个独立开发的局部，测试进度会比拟迟缓，而且有时候会十分不稳固，不得不思考到服务组件之间的异步调用和环境因素的影响。这都造成端到端的测试在测试筹备、运行和保护方面的老本较高。尽管如此，研发团队依然须要运行其中的一些端到端的测试，只管不那么频繁，但须要笼罩重要的业务门路，并验证残缺的利用是否满足业务需要。
2）契约测试
既然会波及单个独立的微服务，研发团队也须要对微服务执行契约测试。微服务体系架构由“生产者”服务组件和“消费者”服务组件组成。当消费者组件试图与生产者组件联合并应用它的输入时，一个“服务契约”（由预期的输出和输入组成）就在它们之间造成。
由这些契约测试组成的自动化测试套件能够集成到流水线中，运行这些测试来验证生产者和消费者组件中的任何更改是否合乎二者之间的服务契约。开发和运行契约测试是测试云原生利用的一项重要内容。
3）非功能测试
对于云原生利用来说，功能测试十分重要，能够验证产品是否满足业务需要。然而，当产品公布到生产环境中，功能测试可能提供产品将以预期的形式响应的信念吗？当忽然呈现服务器解体、服务组件宕机或某些依赖服务不可用时，服务是否可能平安降级？产品上线后是否足够平安？该产品是否应酬突发的大量用户申请？
非功能测试对于云原生利用十分重要。对于上述问题，任何缺点或者偏离预期行为的状况都要求咱们以起码的工作量和步骤尽快发现、剖析并修复问题，以防止这些问题再次发生。
为了确保这些问题产生的机率或影响很小，咱们须要借助有用的工具（许多工具是云提供商本人提供的）测试产品的性能（如提早、负载平衡的影响、缓存、产品性能中的危险因素、基于性能指标来比照和提供反馈后果的基准测试等）、可用性、负载（例如在靠近实在负载条件下对产品吞吐量的影响）和安全性（动态和动静），并事后解决任何潜在的危险。
4）混沌工程和生效模式测试
说到品质工程，咱们大多数人都晓得像“FMEA”（生效模式和影响剖析）技术，它能够帮忙咱们辨认产品中的潜在生效模式及其起因和结果。对于单体利用，大多数潜在的故障模式是已知的，能够辨认的，因而能够在代码构造中解决。即便不解决，当缺点产生时也可能疾速修复。
然而对于微服务来说，产品在生产环境中失败的形式是难以计数、不可预测的，因为波及到大量的复杂性。在这些状况下，“混沌工程”会很有帮忙。它是一种辨认在生产环境中产品生效的办法，以建设对系统应答意外或未知操作能力的信念。
“混沌工程”和 FMEA 一起，通过注入可控的故障，帮忙咱们取得一个可靠性和弹性能力更高的产品，让咱们可能检测和剖析这些故障，从而预知产品在哪些方面会出故障。这将帮忙咱们调整现有的流程，以避免故障级联的结果，并提前打算如何缩短 MTTR（Mean Time to Recovery/Restore，故障均匀复原工夫）。
5）可察看性、在线监控和日志剖析
作为软件工程师，对云原生利用咱们既要在上线前进行测试也要在上线后进行测试。如果操作切当，线上测试能够为咱们提供许多有价值的信息，为打算下一个版本的弹性、可伸缩性和灵活性提供重要反馈信息。但必须记住，线上测试的设置和执行很简单，在执行这些测试时必须十分小心，并充分考虑到，如果线上测试没有正确和平安的执行，对业务和用户带来什么样的影响。
“可察看性”是帮忙咱们更好地了解产品中软件行为的办法之一，是指通过观察产品的输入来理解产品外部状态的办法。咱们能够应用一些监控技术和工具收集、存储、保护和查问利用的状态、行为，以及服务之间交互相干的信息。这些日志和指标能够被进一步剖析来获取有价值的发现，或者疾速评估和剖析缺点。一些云服务提供商会提供开箱即用的性能和工具帮忙咱们实现监控、信息收集和剖析。
三、论断
咱们必须明确，无论打算和执行多少功能测试和非功能测试，无论咱们如何努力提高这些云原生利用的品质，最终用户依然会面临问题。咱们的指标是缩小意外事件的危险，疾速剖析和修复故障，从既往事件中学习并将这些常识用于下一个版本。
在生产环境中发现缺点的老本是十分高的，咱们应该在软件的开发生命周期中尽早发现缺点。在生产环境中，咱们能够利用金丝雀部署（把所有性能推送给局部用户），暗启动（把新性能 / 次要性能推送给局部用户），智能性能切换 / 标记 / 位 / 翻转器（容许特定性能的利用被激活或停用）等技术在生产环境中逐步裸露缺点。
但咱们也必须记住，因为各种限度因素，包含估算、团队承接能力、时间表、上市工夫、大量相互依赖 / 独立的服务、环境的可用性等，通过已知的测试策略做详尽的测试是不可能的。因而，团队须要采取基于危险的测试方法，也必须意识到和缺点无关的各种类型的老本，比方检测老本，剖析调试老本，机会成本，修复老本，验证老本和保护老本。
思考到所有本文中探讨的因素，能够必定的是，只管测试云原生利用是艰难和具备挑战性的，但咱们能够让新的测试方联合本身的专业知识、不同的测试技术和策略，向用户交付高质量的产品。
起源：软件品质报道
作者：Sumon Dey
4 月每周四晚 8 点，【冬哥有话说】DevOps 之庖丁解牛，拆解 DevOps 的工具及具体实战。公众号留言“解牛”可获取地址
- 0401《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》
- 0408《继续交付中的版本治理与基于 Azure DevOps 扩大框架的插件开发》
- 0415《微服务，多团队合作中的 API 测试怎么做 – Pact 契约测试》
- 0422《BoatHouse 端到端流水线展现》