接口测试工具_「测试」 - 代码 & 接口测试工具 - 未完成

现今互联网产品的测试策略采用菱形结构，即重量级API测试，轻量级GUI测试，轻量级单元测试，API测试可谓非常重要。

一、API测试的基本步骤

API测试的基本步骤主要包括以下三大步骤：

1. 准备测试数据
2. 通过API测试工具，发起对被测API的request
3. 验证返回结果的response

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

二、基于Spring Boot构建API

基于Spring Boot开发的Account API功能非常简单，基于提供的ID值创建一个Account对象，并返回这个新创建Account对象。

Account API的功能逻辑实现非常简单，以下代码列出了主要的逻辑。

@RestController

使用IntelliJ打开项目，启动成功后，account-service会运行在本地机器的8080端口。

三、cURL

通过cURL以下命令发起Account API的调用。

"Accept: application/json" -X GET 

这行命令中参数的含义如下：

• 第一个参数-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文件的路径

TIPS：参数大小写敏感。

A、使用Session的场景

curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"

B、使用Cookie的场景

前端可以把cookie保存成为文件，当需要再次使用cookie时，再用-b cookie_file的方式在request中植入cookie即可正常使用。

username

最后，cURL只能发起API调用，其本身并不具备结果验证能力（结果验证由人完成），所以严格意义上说cURL并不属于测试工具的范畴。

但由于cURL足够轻量级，经常被很多开发人员和测试人员使用。

四、Postman

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

早期的Postman，是以Chrome浏览器的插件（plugin）形式存在的，最新版本的Postman已经是独立的应用了。

具体的操作，主要包括：

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

A、发起API调用

对Account API做测试，需要选择Postmant的Request模块。进入相应界面后，执行以下三步操作，发起Account API的调用。

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

完成以上步骤后，看到返回的response默认以JSON文件的形式显示在Body中

这样就完成了一次Account API的调用，但这只是一个API调用，并没有对调用结果进行自动化验证。

B、添加结果验证

在Postman中添加结果验证也非常方便，假定在Account API测试过程中有以下四个验证点：

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

首先打开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按钮发起测试。

C、保存测试用例

测试通过后，往往希望可以把这个测试request保存下来，以方便后续使用，为此Postman提供了保存测试request的功能，并提供了Collection来分类管理保存多个测试request。

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

以后再要使用这个测试request时，直接在Collection中打开它，即可使用。

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

将测试request作为回归测试用例集成到CI/CD的流程中，要求可以通过命令行的方式执行的测试。

为了达到这个目的，目前有两种做法：

1.将Postman中的测试request用自动化的方式直接转换成API测试的代码。

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

比如，基于Java的OKHTTP和Unirest，基于Python的http.client和requests，基于NodeJS的Native Request和Unirest，基于JavaScript的JQuery AJAX和XHR等等。

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

需要先将Postman中的Collection导出为JSON文件，然后执行以下命令行。

newman run examples/sample-collection.json;

五、复杂场景的API测试

在实际项目中，除了单个API的测试场景外，还有很多复杂场景的API测试。

A、多个API调用协作完成

很多情况下，一个单一的前端操作可能会触发后端一系列的API调用，由于前端测试的相对不稳定性，或者由于性能测试的要求，必须直接从后端通过模拟API的顺序调用来模拟测试过程。

这时，API的测试用例就不再是简单的单个API调用，而是一系列API的调用，并且经常存在后一个API需要使用前一个API返回结果的情况，以及需要根据前一个API的返回结果决定后面应该调用哪个API的情况。

之前已经实现了API的调用和结果解析的代码化，这也就意味着可以很灵活的直接用代码来处理这些场景。

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

B、API测试过程中的第三方依赖

API之间是存在依赖关系的，比如被测对象是API A，但是API A的内部调用了API B，此时如果由于某种原因，API B在被测环境中处于不可用状态，那么API A的测试就会受到影响。

在单体架构下，通常只会在涉及到第三方API集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API间相互耦合的依赖问题就会非常严重。

解决这个问题的核心思路是，启用Mock Server来代替真实的API。

C、异步API的测试

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

对异步API的测试主要分为两个部分：一是，测试异步调用是否成功，二是，测试异步调用的业务逻辑处理是否正确。