微服务模式下API测试

来自茹炳晟

session和cookie的区别

如果后端工程师使用 session 记录使用者登入信息，那么后端通常会传一个 session ID 给前端。之后，前端在发给后端的 requests 的 header 中就需要设置此 session ID，后端便会以此 session ID 识别出前端是属于具体哪个 session
如果是使用 cookie，在认证成功后，后端会返回 cookie 给前端，前端可以把该 cookie 保存成为文件，当需要再次使用该 cookie 时，再用“-b cookie_File” 的方式在 request 中植入 cookie 即可正常使用

如何应对复杂场景的 API 测试？

测试场景一：被测业务操作是由多个 API 调用协作完成
一个单一的前端操作可能会触发后端一系列的 API 调用
如何才能高效地获取单个前端操作所触发的 API 调用序列。解决这个问题的核心思路是，通过网络监控的手段，捕获单个前端操作所触发的 API 调用序列。比如，通过类似于 Fiddler 之类的网络抓包工具，获取这个调用序列；又比如，目前很多互联网公司还在考虑基于用户行为日志，通过大数据手段来获取这个序列。
测试场景二：API 测试过程中的第三方依赖
启用 Mock Server 来代替真实的 API
测试场景三：异步 API 的测试
异步 API 是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API。
对异步 API 的测试主要分为两个部分：一是，测试异步调用是否成功，二是，测试异步调用的业务逻辑处理是否正确。

单体架构

单体架构是早期的架构模式，并且存在了很长时间。单体架构是将所有的业务场景的表示层、业务逻辑层和数据访问层放在同一个工程中，最终经过编译、打包，并部署在服务器上。

缺点：灵活性差，可扩展性差，可维护性差，稳定性差

微服务架构

微服务是一种架构风格。在微服务架构下，一个大型复杂软件系统不再由一个单体组成，而是由一系列相互独立的微服务组成。其中，各个微服务运行在自己的进程中，开发和部署都没有依赖。

微服务架构具有以下特点：

每个服务运行在其独立的进程中，开发采用的技术栈也是独立的；

服务间采用轻量级通信机制进行沟通，通常是基于 HTTP 协议的 RESTful API；

每个服务都围绕着具体的业务进行构建，并且能够被独立开发、独立部署、独立发布；

对运维提出了非常高的要求，促进了 CI/CD 的发展与落地。

微服务架构下的测试挑战

过于庞大的测试用例数量；

解决方法：基于消费者契约的API测试

微服务之间的耦合关系。

如服务T依赖于X和Y，但当X和Y不可用时，T也无法测试。

方法：

解耦的方式通常就是实现 Mock Service 来代替被依赖的真实 Service。实现这个 Mock Service 的关键点就是要能够模拟真实 Service 的 Request 和 Response。

后续的，没看懂。