微服务架构图：
微服务-API测试
1、单个API功能正确
第1步：数据准备
第2步：调接口ABC获取数（如token获取） 将数据传递给其他接口
第3步：测试API接口调用
请求验证、response验证、数据验证（如数据库、redis、es等）、日志验证、全局配置变更验证、..
2、多个API组合调用时序正确性
3、保证BFF层功能逻辑正确性
测试分析：
流量录制和回放 ： 在线上环境，通过网络流量抓包，就能知道前端调用了后端哪些接口、以及接口之间的时序 。即纵向调用链路
抓包工具抓取HAR包
API调用链路追踪： 即横向调用链路
调用链路可视化工具：
如何测试？
1、postman等图形界面工具功能薄弱，测试数据准备需人工、复杂结果不能检查、数据传递体验差等等
2、代码测试API接口，可以CI（测试集成） 。如java的REST-assured ， python 的requests模块测试API
postman等工具的接口用例如何转换成代码的用例？
1、postman的code功能 ， 但会丢失断言。且一个一个code比较慢
2、写个解析json文件的程序
API 接口功能测试核心就是调用参数的组合 。如何自动化生成API测试数据呢？
自动化工具不能理解业务，参数多时，参数组合指数增长，检查结果也指数增长，很多组合在真实业务中无此场景
那怎么生成测试数据呢？
1、从生产环境提取接口调用的数据组合
2、开发自动化数据生成器：用于扫描API接口，判断入参的类型，根据类型生成对应的数据，如string类型，就生成数字、null等数据，使用数据调用接口
3、引入test data service生成测试数据
4、并发测试：只是测试在并发场景下的功能是否正确，不属于性能测试。 测试关键：触发更多的并发 thinktime=0，并发用户数一般不超过3位数。
5、API性能测试：尽可能模拟真实的场景的thinktime，尽可能接近生产环境的并用户数。 工具：如Jmeter的负载集群。
性能基准测试
容量测试
压力测试
....
6、API测试过程中的后向兼容性测试
被测系统版本变更 ，如1.1 - > 1.2（请求：可能新增或尖山必填参数 ； reponse: 删除了某些结果或修改了某些字段名等，而这个结果下游要使用 ）， 测试用例是基于1.2版本设计和执行的。
而线上可能还存在某些系统在调用时依旧按1.1的接口来调用，此时就可能出现问题。
解决办法：
低版本1.1用例 在被测系统1.2上执行，全部通过，则就测试了请求的向后兼容性。但没测到响应的向后兼容性。
对每个api的Response的每个字段断言工作量巨大，
引入结果存储，1.1的结果和1.2的结果进行对比，发现不同则报警，然后人工排查
7、微服务的环境治理
8、
