复杂场景的接口测试
测试场景一：被测业务操作是由多个API调用协作完成背景：一个单一的前端操作可能会触发后端一系列的API调用，此时API的测试用例就不再是简单的单个API调用，而是一系列API的调用
存在的情况：存在后一个API需要使用前一个API返回结果的情况;需要根据前一个API的返回结果决定后面应该调用哪个API
存在问题：如何高效地获取单个前端操作所触发的API调用顺序
解决上述问题思路：通过网络监控手段，捕获单个前端操作时所触发的API调用顺序，譬如Fiddler、Charles等抓包工具。也可以通过用户行为日志，通过大数据手段来获取调用顺序
https://pic1.zhimg.com/80/v2-0f000c39c87e00983631c22124af3ff0_720w.jpeg
测试场景二：API 测试过程中的第三方依赖
背景：API 之间是存在依赖关系的，比如你的被测对象是 API A，但是 API A 的内部调用了 API B，此时如果由于某种原因，API B 在被测环境中处于不可用状态，那么 API A 的测试就会受到影响。
在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。
解决问题的核心思路：启用 Mock Server 来代替真实的 API
测试场景三：异步 API 的测试
什么是异步API：调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调(Callback)的 API
对异步 API 的测试主要分为两个部分：
测试异步调用是否成功：检查返回值和后台工作线程是否被创建两个方面就可以了
测试异步调用的业务逻辑处理是否正确
测试异步调用的业务逻辑复杂性：因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等
页:
[1]
