4个实用的微服务测试策略
微服务架构并不是一种新的架构模式，但它的不断发展为那些寻求企业级私有云解决方案的公司，带来了诸多好处，将大型一体化架构应用拆分为可组合的微服务，赋予企业独立扩展和维护每个组件的能力以及DevOps能力。
当然，微服务架构的分布式和独立性也带了许多挑战，而本文讲谈谈如何克服测试多个可独立部署组件时可能会遇到的挑战。
单元测试（Unit Testing）
单元测试的范围可以是一组服务（社会性单元测试），也可以是单独的一个服务（独立单元测试）。被测试的单元粒度越小，就越容易确定模块的行为、查明相关collaborators以及对象与依赖之间的交互。由于单元的复杂度较低，QA工程师可以通过单元测试策略来评估单元是否与collaborators隔离。社会性单元测试和独立单元测试经常会在同一个代码库中同时进行，以解决不同的测试问题。
测试domain layer的目的是模拟DML语句并证明所有collaborators都以正确的顺序使用真实的domain objects。在单元测试期间，工程师可以验证用于生成map responses的逻辑或来自外部远程依赖项的其他请求。就资源和服务层而言，验证每个组件是否与collaborators正确交互，将可以可重复且一致的方式监视请求/响应周期。
集成测试（Integration Testing）
集成测试在分段环境中进行，以在分析通信路径的功能和它们之间的交互之后集成各个服务。与单片或SOA不同，微服务架构依赖于进程间通信（IPC）机制来正常运行，这就是为什么必须验证服务之间的交互。
我们需要编写自动化测试，以通过与外部服务和数据存储的集成来映射成功或错误的情况。运行网关集成测试将在协议级别上破坏接口错误，例如不正确的SSL处理和丢失的HTTP标头。持久性集成测试确保每个组件和协议客户端必须在超时和部分失败的情况下作为外部依赖进行响应。
契约测试（Contract Testing）
契约测试是一种用于验证外部服务调用与其API Provider endpoint之间契约的黑盒子。一般有两种契约测试：
- 集成契约测试
- 消费者驱动（consumer-driven）契约测试
在集成契约测试中，每个组件都需要独立调用，并且必须满足消费服务（consumer）预期的契约协议。解决这个问题的最佳方法是对double进行测试。另一方面，定期运行一组单独的测试以确认测试double没有变化至关重要。不过，一单出现测试失败，会降低部署管道的速度并破坏IT基础架构或分布式系统的功能。处理间歇性测试失败的最佳方法之一是更新测试double，同时可能也需要更新代码，以便可以使其恢复到与外部服务一致的状态。
在消费者驱动的契约测试中，消费者将描述他们想要使用服务的方式。消费者契约可以在生产者和消费者之间以相互同意的语言和模式进行。服务提供商将针对各个契约的副本测试服务，然后对该特定服务进行更改，而不会影响其他服务的性质。
End-to-End测试（End-to-End Testing）
End-to-End（E2E）测试用于确定整个系统正常运行以及网络基础设施（负载平衡器、防火墙等）已正确配置。End-to-End测试需要以最精细的粒度运行以测试整个系统的功能。在此，QA工程师验证完全集成过程的行为，并确保系统总体上满足其业务需求，而不管使用的服务组件体系结构如何。在功能测试的帮助下，开发人员可以确定集成系统或应用是否按要求的规定运行。
关于Rainbond
当下，已经有很大一部分公司完成了单体架构向微服务架构的迁移改造，并在疲于应对大量微服务间通信问题时，开始考虑采用Service Mesh微服务架构作为服务与服务直接通信的透明化管理框架，以插件式的方式实现各种业务所需的高级管理功能。
而开源PaaS Rainbond提供了开箱即用的Service Mesh微服务架构，部署在Rainbond上的应用原生即是Service Mesh微服务架构应用。
- Rainbond项目网站
-
试用Rainbond公有云
- 注册或使用Demo账号/密码登录：rainbond-demo/rainbond-demo
- Github
- 码云
- 文档
- 微信群: 添加微信“zqg5258423”并接受邀请入群
