微服务模式下API测试，但是我们很少去研究什么叫微服务。
1.微服务架构、单体架构的概念
单体架构（Monolithic Architecture）:将所有的业务场景的表示层、业务逻辑层、数据访问层放在同一个工程中，最终经过编译、打包、并部署在服务器上。比如经典的J2EE工程，就是将表示层的JSP、业务逻辑层的Service、Controller、数据访问层的DAO(Data Access Objects)，打包成war文件，然后部署在Tomcat、Jetty或者其他Servlet容器中运行。
微服务架构（Microservice Architecture）:架构风格，在微服务架构下，一个大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成。不同服务之间通过一些轻量级交互机制进行通信，比如RPC、HTTP等，服务可独立扩展伸缩，每个服务定义了明确的边界。
单体架构VS微服务架构
2.API测试
1.单体架构API测试的测试策略
- 1.根据被测API输入参数的各种组合调用API，并验证相关结果的正确性
- 2.衡量测试过程的代码覆盖率
- 3.根据代码覆盖进一步找出遗漏的测试用例
- 4.以代码覆盖率达标作为API测试成功完成的标志
比如单体架构开发了一个系统，对外提供了3个Restful API接口，测试策略如下： - 1.针对这3个接口，分别基于边界值和等价类方法设计测试用例并执行
- 2.在测试执行过程中，启用代码覆盖率统计
- 3.保证覆盖率达到100%，完成API测试
2.微服务架构
微服务架构时，原本的单体应用会被拆分成多个独立模块，也就是很多个独立的service,全局功能将会由这些拆分得到的API共同协作完成。
比如微服务架构，系统被拆分成了10个独立的service,如果每个service平均对外暴露3个API接口，总共需要API的数量达到30个。
3.基于消费者契约的API测试
消费者契约的核心思想：只测试那些真正被实际使用到的API调用，如果没有被使用到的，就不去测试。
契约的本质：request和response的组合，具体的表现文件是JSON文件。
Mock Service的关键：能够模拟被替代Service的Request和response。
