API测试

API 测试的基本步骤通常来讲，无论采用什么 API 测试工具，
API 测试的基本步骤主要包括以下三大步骤：

  • 准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）；
  • 通过 API 测试工具，发起对被测 API 的 request；
  • 验证返回结果的 response。

测试工具

对 API 的测试往往是使用 API 测试工具，比如常见的命令行工具 
cURL、图形界面工具 Postman 或者 SoapUI、API 性能测试的 JMeter 等。

curl

curl可以发起API调用

apifox 测试restTemplate 如何测试api_消息队列

第一个参数“-i”，说明需要显示 response 的 header 信息；

第二个参数“-H”，用于设定 request 中的 header；

第三个参数“-X”，用于指定执行的方法，这里使用了 GET 方法，其他常见的方法还有 POST、PUT 和 DELETE 等，如果不指定“-X”，那么默认的方法就是 GET。最后“ http://127.0.0.1:8080/account/ID008 ”，指明了被测 API 的 endpoint 以及具体的 ID 值是“ID008”。当使用 cURL 进行 API 测试时，常用参数还有两个：

“-d”：用于设定 http 参数，http 参数可以直接加在 URL 的 query string，也可以用“-d”带入参数。参数之间可以用“&”串接，或使用多个“-d”。

“-b”：当需要传递 cookie 时，用于指定 cookie 文件的路径。 

postman

Postman 常常被用于 Web Service API 的测试具体的操作

测试流程主要包括：

发起 API 调用
添加结果验证、 postman-断言（后置脚本）_东方不败之鸭梨的测试笔记的博客 

保存测试用例

 “Save As”按钮，在弹出的对话框中可以建立 Collection，并且可以命名测试 request 并将其保存到 Collection 中

基于 Postman 的测试代码自动生成

1、将 Postman 中的测试 request 用自动化的方式直接转换成 API 测试的代码。 目前 Postman 已经支持这个功能了，可以将保存的测试 request 自动化转换成常见测试框架直接支持的代码，而且支持多语言。

2、利用 Newman 工具直接执行 Postman 的 Collection

newman run examples/sample-collection.json;

postman可以批量执行，Newman的目的是为了可以从命令行发起测试，的确是为了持续集成 

很多比较大的工程实践并不会基于postman来做，下一篇文章会给出解决方案，就是用代码级的api测试框架。 

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

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

通过代码将上个 API 调用返回的 response 中的某个值传递给下一个 API，再比如根据上一个 API 的返回结果决定下一个应该调用哪个 API 等。

如何才能高效地获取单个前端操作所触发的 API 调用序列？

通过类似于 Fiddler 之类的网络抓包工具，获取这个调用序列；又比如，目前很多互联网公司还在考虑基于用户行为日志，通过大数据手段来获取这个序列。

测试场景二：API 测试过程中的第三方依赖

在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。解决这个问题的核心思路是，启用 Mock Server 来代替真实的 API

测试场景三：异步 API 的测试

异步 API 是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API。

一直以来，异步 API 测试都是 API 测试中比较困难的部分。在我看来，对异步 API 的测试主要分为两个部分：

一是，测试异步调用是否成功，

二是，测试异步调用的业务逻辑处理是否正确。异步调用是否成功，这个还比较简单，主要检查返回值和后台工作线程是否被创建两个方面就可以了。但是，对异步调用业务逻辑的测试就比较复杂了，因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等。

问题

 单个 API 测试是比较简单的，但在实际项目中，往往存在按时序的 API 调用以及异步 API 调用，这类 API 你是如何测试的？遇到过什么难题，又是如何解决的？

Postman 的 Pre-request Script 功能，可以支持变量的传入，应该也可以解决 API 调用的时序问题，比如前一个接口的返回值作为当前接口的入参。

底层就是封装了python的requests，然后通过写配置而不是写代码来完成api测试，其中就可以处理时序，传参数等问题，但是异步api还是没有太好的方法

说到异步，我现在的项目刚好有个场景，我使用jmeter压API，需要调用异步API创建一个东西，然后后台线程进行一系列操作后，更新这个东西的状态，我前端要等到他的状态变化后，再做下一步操作。具体做法是jmeter发起了创建操作后，循环执行一个查询状态操作，等到发现状态正常后再进行后续操作，或者状态异常/超时后报错。有意思的是，如果后端数据库是个集群，这样测试，还能经常发现数据库集群的node间数据不同步的问题。

不知道有没有听过lisa，CA。 我们在用这个做中间件测试。 测试各种API。 包含了消息队列。 SOAP。 各种不同的call。。 要自己建立stub来连接中间件之后做自动化测试。。。。 也是遇到了很多挑战

推荐pinpoint来进行服务链路调用追踪