Update API测试.md

API测试.md

-# 一、HTTP请求方式
+# 一、HTTP请求方式
@@ -112,4 +112,36 @@ JSON具有一些特点及优势：
 * 验证返回结果的response。  
 
 对我们现在的情况来说，使用postman解决一般的手工接口测试已经能够满足，而进行到自动化阶段更多会选择Jmeter；具体测试工具的使用就不详细介绍了。   
-**需要注意的是接口测试与功能测试的区别。进行接口测试时，主要的关注点是接口，主要验证的也是功能的接口，而不是功能本身。**
\ No newline at end of file
+**需要注意的是接口测试与功能测试的区别。进行接口测试时，主要的关注点是接口，主要验证的也是功能的接口，而不是功能本身。**  
+## 如何应对复杂场景的API测试？  
+在实际工作中，面对单个API的调用并完成测试是比较少见的。更普遍的情况下，我们会遇到一些复杂的测试场景。  
+
+### 测试场景一：被测业务操作是由多个API调用协作完成
+
+很多情况下，一个单一的前端操作可能会触发后端一系列的API调用，由于前端测试的相对不稳定性，或者由于性能测试的要求，你必须直接从后端通过模拟API的顺序调用来模拟测试过程。   
+
+这时，API的测试用例就不再是简单的单个API调用了，而是一系列API的调用，并且经常存在后一个API需要使用前一个API返回结果的情况，以及需要根据前一个API的返回结果决定后面应该调用哪个API的情况。  
+
+好在，我们已经实现了API的调用和结果解析的代码化，这也就意味着我们可以很灵活地直接用代码来处理这些场景了。 比如，通过代码将上个API调用返回的response中的某个值传递给下一个API，再比如根据上一个API的返回结果决定下一个应该调用哪个API等。  
+
+除此之外，我们还需要迫切解决的一个问题是：如何才能高效地获取单个前端操作所触发的API调用序列。解决这个问题的核心思路是，通过网络监控的手段，捕获单个前端操作所触发的API调用序列。比如，通过类似于Fiddler之类的网络抓包工具，获取这个调用序列；又比如，目前很多互联网公司还在考虑基于用户行为日志，通过大数据手段来获取这个序列。   
+ 
+### 测试场景二：API测试过程中的第三方依赖  
+
+API之间是存在依赖关系的，比如你的被测对象是API A，但是API A的内部调用了API B，此时如果由于某种原因，API B在被测环境中处于不可用状态，那么API A的测试就会受到影响。  
+
+在单体架构下，通常只会在涉及到第三方API集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API间相互耦合的依赖问题就会非常严重。  
+
+解决这个问题的核心思路是，启用Mock Server来代替真实的API。  
+
+### 测试场景三：异步API的测试  
+
+异步API是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的API。  
+
+一直以来，异步API测试都是API测试中比较困难的部分。在我看来，对异步API的测试主要分为两个部分：一是，测试异步调用是否成功，二是，测试异步调用的业务逻辑处理是否正确。 
+ 
+异步调用是否成功，这个还比较简单，主要检查返回值和后台工作线程是否被创建两个方面就可以了。 
+ 
+但是，对异步调用业务逻辑的测试就比较复杂了，因为异步API通常发生在一些比较慢的操作上，比如数据库I/O、消息队列I/O等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。  
+
+在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求API测试框架中包含对应的工具类去访问和操作数据库或者消息队
\ No newline at end of file