08、紧跟时代步伐：微服务模式下API测试要怎么做？
一、单体架构和微服务架构
1、单体架构的特点
1.1、灵活性差：每次进行改动，都需要进行打包发布整个应用，由于所有代码都在一起，所以每次编译打包都要花费很长时间。
自己补充说名：代码都在一起的时候每次打包发布，相关的测试活动都会受到影响。
1.2、可扩展性差：在高并发场景下，无法以模块为单位灵活扩展容量，不利于应用的横向扩展。
1.3、稳定性差：当单体应用中任何一个模块有问题时，都可能会造成应用整体的不可用，缺乏容错机制。
1.4、可维护性差：随着业务复杂的提升，代码的复杂性也是直线上升，当业务规模比较庞大时，整体项目的可维 护性会大打折扣。
2、微服务架构的特点
2.1、每个服务运行在独立的进程中，开发采用的技术栈也是独立的;
2.2、服务间采用轻量级通信机制进行沟通，通常是基于HTTP协议的RESTful API;
2.3、每个服务都围绕这具体的业务进行构建，并且能够被独立开发、独立部署、独立发布;
2.4、对运维提出了非常高的要求，促进了CI/CD的发展与落地
自己补充说明：项目使用微服务架构后，进行CI/CD集成，在进行打包时每个服务相互依赖时，需要理清打 包顺序。
二、微服务下的测试挑战
1、过于庞大的测试用例数量
1.1、传统API的测试策略：
- 根据被测API输入参数的各种组合调用API，并验证相关结果的正确性；
- 衡量上述测试过程的代码覆盖率；
- 根据代码覆盖率进一步找出遗漏的测试用例；
- 以代码覆盖率达标作为API测试成功完成的标志
1.2、当采用微服务架构时，原本的单体应用会被拆分成多个独立模块，也就是很多个独立的service，这样原来的工作量就会增加很多，在互联网现在的模式下，往往都是推行"敏捷"化，所以对测试发起的挑战是巨大的，这时就会迫切需要找到一种既能保证API质量，又能减少测试用例数量的测试策略，(作者后面要分享的是：基于消费者契约的API测试)。【备注：对原文进行了简化】
2、微服务之间的耦合关系
2.1、上面有提到契约测试，契约的本质就是Request和Response的组合，具体的表现形式往往是JSON文件，此时我们就可以用该契约的JSON文件作为Mock Service的依据，也就是在收到什么Request的时候应该回复什么Response。
补充：教程中的示例和图解没有就没有这这里记录啦！
三、代码实例及文档中涉及的名词解读
1、代码实例：https://github.com/SpectoLabs/spring-cloud-contract-blog
1.1、实例说明：
基于Spring Boot实现了两个微服务：订阅服务(subscription-service)和账户服务(account-service)，其中订阅服务会调用账户服务。
2、详细代码解读：https://specto.io/blog/2016/11/16/spring-cloud-contract/
3、名词解读
a、API Gateway 的组件，用于记录所有 API 之间相互调用关系的日志
评论摘选： api gateway一般是作为整个微服务的入口，做一些权限校验，路由功能，服务间的内部调 用不走api gateway。spring cloud的例子 zuul作为api gateway，load balancer是 ribbon。要去抓取调用记录在被测服务记录访问日志。这个作为audit log本来就是要记录 的。我们的契约测试是调用放手写在被调用服务，拥有者是调用方。以此来确保api的兼 容。
b、代码级覆盖率统计工具：Java语言使用jacoco，
参考地址：https://www.jacoco.org/jacoco/trunk/index.html
https://cloud.tencent.com/developer/article/1038055
c、mock工具：
Mockito：官网： http://mockito.org
API文档：http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html
项目源码：https://github.com/mockito/mockito
接口测试Mock工具：Yapi: https://hellosean1025.github.io/yapi/
说明：教程来源极客时间--软件测试52讲，作者：茹炳晟
喜欢的朋友可以去订阅学习，我这里的仅作为学习记录，跟着教程记录主要内容
