推荐四种实用的微服务测试策略将现代化架构的应用拆分成可组合的微服务，让企业能够独立扩展和维护每个组件和DevOps能力。当然，微服务架构的分布式和独立性也带来了很多挑战，本文将讲述如何克服在测试多个可独立部署的组件时可能遇到的挑战。单元测试（UnitTesting）单元测试的范围可以是一组服务（社会单元测试），也可以是单个服务（独立单元测试）。被测单元的粒度越小，就越容易确定模块的行为，查明相关的协作者，以及对象和依赖项之间的交互。由于单元的复杂性较低，QA工程师可以使用单元测试策略来评估单元是否与协作者隔离。社交单元测试和独立单元测试通常在同一代码库中同时运行，以解决不同的测试问题。测试域层的目的是模拟DML语句并证明所有协作者都以正确的顺序使用真实的域对象。在单元测试期间，工程师可以验证用于生成地图响应或来自外部远程依赖项的其他请求的逻辑。就资源和服务层而言，验证每个组件是否与协作者正确交互将允许以可重复和一致的方式监控请求/响应周期。集成测试集成测试在分析通信路径的功能及其之间的交互之后，在暂存环境中执行以集成各个服务。与单体或SOA不同，微服务架构依赖于进程间通信(IPC)机制才能正常运行，这就是必须验证服务之间的交互的原因。我们需要编写自动化测试，通过与外部服务和数据存储的集成来映射成功或错误案例。运行网关集成测试将破坏协议级别的接口错误，例如不正确的SSL处理和缺少HTTP标头。持久性集成测试确保每个组件和协议客户端必须在超时和部分故障的情况下作为外部依赖项进行响应。契约测试（ContractTesting）契约测试是一个黑盒，用于验证外部服务调用与其APIProvider端点之间的契约。契约测试一般有两种：集成契约测试消费者驱动契约测试在集成契约测试中，每个组件都需要独立调用，并且必须满足消费者服务（consumer）所期望的契约约定。解决这个问题的唯一办法就是对double进行测试。另一方面，定期运行一组单独的测试以确认测试替身没有改变是至关重要的。但是，单个测试失败可能会减慢部署管道的速度并破坏IT基础架构或分布式系统的功能。处理间歇性测试失败的最佳方法之一是更新测试替身，可能还有代码，以便它可以恢复到与外部服务一致的状态。在消费者驱动的契约测试中，消费者描述他们想要如何使用服务。消费者合同可以在生产者和消费者之间以共同商定的语言和模式进行。服务提供商将根据每个合同的副本测试服务，然后在不影响其他服务性质的情况下对该特定服务进行更改。端到端测试（End-to-EndTesting）端到端（E2E）测试用于确定整个系统是否正常运行以及网络基础设施（负载均衡器、防火墙等）是否正常配置。端到端测试需要以最精细的粒度运行，以测试整个系统的功能。在这里，QA工程师验证完全集成流程的行为，并确保系统作为一个整体满足其业务需求，无论使用何种服务组件架构。在功能测试的帮助下，开发人员可以确定集成系统或应用程序是否按要求运行。
