API 测试的具体实现

目录

• API 测试的具体实现
  • 基于 Spring Boot 构建的 API
  • 使用 cURL 命令行工具进行测试
  • 使用图形界面工具 Postman 进行测试
  • 如何应对复杂场景的 API 测试？
  • 总结

API 测试的具体实现

基于 Spring Boot 构建的 API

由于基于 Spring Boot 从 0 到 1 构建一个 API，并非本文的重点，为了避免影响你对文章主要内容的把握，我直接采用了一个预先开发好的 Account API 为例展开讲解。你能够从https://github.com/SpectoLabs/spring-cloud-contract-blog下载完整的代码。

这个 Account API 的功能很是简单，就是基于你提供的 ID 值建立一个 Account 对象，并返回这个新建立 Account 对象。

好比，若是你的请求是“account/ID008”，那么返回的 response 就应该是“{“id”:“ID008”,“type”:“friends”,“email”:“robin@api.io”}”。

这个 Account API 的功能逻辑实现很是简单，图 1 和图 2 列出了主要的代码逻辑。

图 1 中，代码的第 21 行说明了 API 的 endpoint 以及对应的操做是 GET 方法，第 22 行明确说明了 GET 方法具体的业务逻辑是由 accountService.getById() 方法实现的。

图 1 RestController 的实现

图 2 中，代码的第 8 行实现了 accountService.getById() 方法，具体逻辑就是返回一个以传入 ID 为 ID 的 Account 对象。

图 2 具体业务逻辑的实现

我推荐使用 IntelliJ 打开这个下载的项目，而后直接启动其中的 account-service。启动成功后，account-service 会运行在本地机器的 8080 端口。启动成功后的界面如图 3 所示。

图 3 成功启动基于 Spring Boot 的 Account API

使用 cURL 命令行工具进行测试

首先，你须要下载安装 cURL，而后就能够经过如下命令发起 Account API 的调用。调用结束后的界面如图 4 所示。

curl -i -H "Accept: application/json" -X GET "http://127.0.0.1:8080/account/ID008"
复制代码

图 4 使用 cURL 测试 Account 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 文件的路径。

须要注意的是这些参数都是大小写敏感的。

了解了这几个最经常使用的参数后，我再来分析一些最经常使用的 cURL 命令以及使用的场景，包括 Session 的场景和 Cookie 的场景。

第一，Session 的场景

若是后端工程师使用 session 记录使用者登入信息，那么后端一般会传一个 session ID 给前端。以后，前端在发给后端的 requests 的 header 中就须要设置此 session ID，后端便会以此 session ID 识别出前端是属于具体哪一个 session，此时 cURL 的命令行以下所示：

curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"
复制代码

第二，Cookie 的场景

若是是使用 cookie，在认证成功后，后端会返回 cookie 给前端，前端能够把该 cookie 保存成为文件，当须要再次使用该 cookie 时，再用“-b cookie_File” 的方式在 request 中植入 cookie 便可正常使用。具体的 cURL 的命令行以下所示：

// 将 cookie 保存为文件
curl -i -X POST -d username=robin -d password=password123 -c ~/cookie.txt "http://XXX/auth"
 
// 载入 cookie 到 request 中
curl -i -H "Accept:application/json" -X GET -b ~/cookie.txt "http://XXX/api/demoAPI"

最后，须要特别说明的是，cURL 只能发起 API 调用，而其自己并不具有结果验证能力（结果验证由人完成），因此严格意义上说 cURL 并不属于测试工具的范畴。可是因为 cURL 足够轻量级，常常被不少开发人员和测试人员使用，因此我在这里作了简单的介绍。

接下来，咱们再来看看如何使用目前主流的 Postman 完成 API 测试。

使用图形界面工具 Postman 进行测试

Postman 是目前使用最普遍的 Http 请求模拟工具之一，经常被用于 Web Service API 的测试。

早期的 Postman，是以 Chrome 浏览器的插件（plugin）形式存在的，最新版本的 Postman 已是独立的应用了。我猜测是由于这个工具的应用日益普遍，因此才有了今天的独立版本。

你能够经过官方网站下载对应于 Mac、Windows 和 Linux 操做系统的不一样版本，截止文章写做完成时，最新的 Mac 版本是 6.2.2。

接下来，我就会以 Mac 6.2.2 版本为例，跟你分享如何用 Postman 完成你的 API 测试。若是你使用浏览器的 plugin 版本，或者是基于其余操做系统的版本，这都没问题，基本的操做和步骤都是同样的。

具体的操做，主要包括：

1. 发起 API 调用；
2. 添加结果验证；
3. 保存测试用例；
4. 基于 Postman 的测试代码自动生成。

第一步，发起 API 调用

咱们的目标是对 Account API 作测试，因此这里你须要选择 Postmant 的“Request”模块。进入相应界面后，你须要按照图 5 的提示依次执行如下三步操做，发起 Account API 的调用。

1. 在 endpoint 输入框中输入“http://127.0.0.1:8080/account/ID_008”；
2. 选择“GET”方法；
3. 点击“Send”按钮发起 API 调用。

图 5 Postman 发起 Account API 的测试

完成以上步骤后，界面如图 6 所示。咱们看到返回的 response 默认以 JSON 文件的形式显示在下面的 Body 中。

图 6 Postman 执行 GET 后的界面

这样就完成了一次 Account API 的调用，是否是很是简单。但问题是，这只是一个 API 调用，并无对调用结果进行自动化验证。接下来，咱们就加上结果验证的部分，一块儿看看会有什么效果。

第二步，添加结果验证

在 Postman 中添加结果验证也很是方便，假定咱们在 Account API 测试过程当中有如下四个验证点：

1. 请求的返回状态码（Status Code）应该是 200；
2. 请求的响应时间应该小于 200 ms；
3. 请求返回的 response header 中应该包含“Content-Type”参数；
4. 请求返回的 response body 中，“type”的值应该是“friends”；

那么，接下来咱们一块儿来看看如何使用 Postman 来添加这四个验证点。

为此，咱们首先打开“Tests”界面，而后在右下角的“SNIPPETS”中依次点击：

1. “Status code: Code is 200”
2. “Response time is less than 200 ms”
3. “Response headers：Content-Type header check”
4. “Response body: JSON value check”

完成以上操做后，“Tests”中会自动生成验证代码，接着只要按照具体的测试要求，对这些生成的代码进行一些小修改就能够了。

在这个例子中，你只需修改须要验证的 JSON 键值对便可，即代码的第 15 行。修改完成后咱们能够再次点击“Send”按钮发起测试。测试经过的界面如图 7 所示，最下面的“Test Results”显示四个测试所有经过。

图 7 测试经过的界面

第三步，保存测试用例

测试经过后，咱们每每但愿能够把这个测试 request 保存下来，以方便后续使用，为此 Postman 提供了保存测试 request 的功能，并提供了 Collection 来分类管理保存多个测试 request。

Collection 是用来保存测试 request 的一个集合，Collection 内部还能够创建目录结构以方便进一步的分类和管理。

这里咱们点击“Save As”按钮，在弹出的对话框中能够创建 Collection，而且能够命名测试 request 并将其保存到 Collection 中。

我创建了“API Test Demo”的 Collection，而且将刚才的测试 request 命名为“AccountAPI”保存到这个 Collection 中。

之后再要使用这个测试 request 时，直接在 Collection 中打开它，便可使用。同时你若是申请注册了一个 Postman 帐号，就能够很方便地在多个环境中共享这个 Collection 了。

第四步，基于 Postman 的测试代码自动生成

至此，你已经掌握了 Postman 最基本的使用方法，但还有一个问题没有解决。不少时候，你但愿将你的测试 request 做为回归测试用例集成到 CI/CD 的流程中，这就要求能够经过命令行的方式执行你的测试。为了达到这个目的，目前有两种作法：

1. 将 Postman 中的测试 request 用自动化的方式直接转换成 API 测试的代码。 目前 Postman 已经支持这个功能了，能够将保存的测试 request 自动化转换成常见测试框架直接支持的代码，并且支持多语言。
   好比，基于 Java 的“OK HTTP”和“Unirest”，基于 Python 的“http.client”和“Requests”，基于 NodeJS 的“Native”“Request”和“Unirest”，基于 JavaScript 的“JQuery AJAX”和“XHR”等等。你能够点击如图 8 所示的“Code”按钮进入代码生成界面。

图 8 自动生成 API 测试代码

1. 利用 Newman 工具直接执行 Postman 的 Collection。 你须要先将 Postman 中的 Collection 导出为 JSON 文件，而后执行如下命令行。

newman run examples/sample-collection.json;
复制代码

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

我在前面分享的 Restful API 测试案例中，只涉及到了最基本的 API 的测试方法，并且测试场景也很比较简单（只是单个 API 的调用）。

但在实际项目中，除了这种单个 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。那么，Mock Server 怎么才能真实有效地模拟被替代的 API 呢？这个问题，我会在分享《紧跟时代步伐：微服务模式下 API 测试要怎么作？》这个主题时，和你详细探讨。

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

异步 API 是指，调用后会当即返回，可是实际任务并无真正完成，而是须要稍后去查询或者回调（Callback）的 API。

一直以来，异步 API 测试都是 API 测试中比较困难的部分。在我看来，对异步 API 的测试主要分为两个部分：一是，测试异步调用是否成功，二是，测试异步调用的业务逻辑处理是否正确。

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

总结

一般状况下，不管你采用什么 API 测试工具，基本的测试步骤每每都是三步，即准备测试数据（并非全部的 API 测试都须要这一步）、经过 API 测试工具发起对被测 API 的 request、验证返回结果的 response。

接下来，我经过一个简单的 Restful API 测试为例，和你分享了 cURL 和 Postman 这两个经常使用 API 测试工具的使用。

其中，cURL 只具有发起 API 调用的功能，而不具有结果验证能力，因此严格地说它并不属于测试工具的范畴。Postman 经常被用于 Web Service API 的测试具体的操做，测试流程主要包括：发起 API 调用、添加结果验证、保存测试用例、基于 Postman 的测试代码自动生成。

最后，为了帮你应对实际工程项目中复杂的 API 测试场景，我分享了被测业务操做是由多个 API 调用协做完成、API 测试过程当中的第三方依赖、异步 API 的测试，这三个复杂场景下的测试思路和方法。