微服务 测试
微服务测试设计和实践 - 图1
由于微服务有内部的依赖，也有外部的依赖，有些依赖可能还不在团队的控制之下，这样带来的测试条件就更加困难。针对这种复杂性，可以采用分而治之的策略，先针对每个微服务进行隔离测试，在对每个微服务测试时要进行分层测试。测试过程中采用Mock技术来隔离依赖简化测试。再确保每个微服务通过测试以后再测试每个微服务端到端的集成测试。

微服务测试分类和技术

根据分而治之的策略，为了测试整个微服务系统，先要实现对每个微服务进行测试，为了对每个微服务进行测试，先要理解每个微服务的结构，每个微服务的结构如下：
微服务测试设计和实践 - 图2

单元测试

微服务测试设计和实践 - 图3

单元测试常用工具

Junit5

https://junit.org/junit5/

Mockito

https://site.mockito.org/

集成测试（Integration Test）

单元测试即使有充分的覆盖度，但是他不能保证每个层次之间协作逻辑的执行，不能保证整个系统的正确性。所以仍然需要其他的测试手段。
微服务测试设计和实践 - 图4

组件测试（Component Test）~内部Mock

微服务测试设计和实践 - 图5

WireMock

http://wiremock.org/

MockBean（Spring提供）

https://www.baeldung.com/java-spring-mockito-mock-mockbean
image.png

组件测试（Component Test）~外部Mock

微服务测试设计和实践 - 图7

Hoverfly

https://hoverfly.io/

Mbtest

http://www.mbtest.org/
image.png

契约驱动测试

契约测试（Contract Test）

微服务测试设计和实践 - 图9

PACT

https://docs.pact.io/
summary.png

Spring Cloud Contract

https://spring.io/projects/spring-cloud-contract

契约驱动测试

微服务测试设计和实践 - 图11
采用描述性契约以后，即可作为服务提供方Mock Provider的输入，来驱动消费者端的契约测试。又可以作为服务消费方Mock Consumer的输入，来驱动生产端的契约测试。所以这种方式比较灵活，覆盖面比较完善。
契约测试需要跨团队协调配合，开发和维护工作量比较大，系统化采用的话成本比较高。

端到端测试（End-to-End Test）

微服务测试设计和实践 - 图12
端到端测试将整个系统看作一个黑盒子，通过测试接口，对系统整体进行功能测试以及非功能测试。

Selenium WebDriver（UI 测试常用）

https://www.selenium.dev/
image.png

Rest-assured（Java API测试常用）

https://rest-assured.io/
image.png

端到端测试实践

  1. 80/20，聚焦核心业务服务
  2. 用户使用场景驱动
  3. 适当Mock不稳定测试点
  4. 规范测试环境和环境自动化
  5. 测试数据管理
  6. 灰度测试+生产监控

    测试方式总结

    | 分类 | 功能 | | —- | —- | | 单元测试 | 确保类、模块功能正确 | | 集成测试 | 确保组件间接口、交互和链路正确 | | 组件测试 | 确保微服务作为独立整体、接口功能正确 | | 契约测试 | 确保服务提供方和消费方都遵循契约规范 | | 端到端测试 | 确保整个应用满足用户需求 | | 探索测试 | 手工探索学习系统功能，改进自动化测试 |

一致性>具体定义

测试金字塔

微服务测试设计和实践 - 图15
测试金字塔建议多做单元测试。

测试补充

Mock VS Spy

对接口进行Mock测试是比较方便的。Spy主要针对的是类的场景（比如来自第三方提供的一些类）。

BDD行为驱动测试（了解）

行为测试主要是面向用户的。

性能测试

JMeter（有UI操作界面）

Gatling（偏脚本编程、可集成CI/CD）

https://gatling.io/open-source/
image.png