测试场景一：被测业务操作是由多个API调用协作完成

　　背景：一个单一的前端操作可能会触发后端一系列的API调用，此时API的测试用例就不再是简单的单个API调用，而是一系列API的调用

　　存在的情况：存在后一个API需要使用前一个API返回结果的情况;需要根据前一个API的返回结果决定后面应该调用哪个API

　　存在问题：如何高效地获取单个前端操作所触发的API调用顺序

　　解决上述问题思路：通过网络监控手段，捕获单个前端操作时所触发的API调用顺序，譬如Fiddler、Charles等抓包工具。也可以通过用户行为日志，通过大数据手段来获取调用顺序

　　

　　​

　　测试场景二：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 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等

　　如需了解更多测试技术信息请关注：深圳多测师软件与技术服务有限公司