现今互联网产品的测试策略采用菱形结构,即重量级API测试,轻量级GUI测试,轻量级单元测试,API测试可谓非常重要。
一、API测试的基本步骤
API测试的基本步骤主要包括以下三大步骤:
- 准备测试数据
- 通过API测试工具,发起对被测API的request
- 验证返回结果的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已经是独立的应用了。
具体的操作,主要包括:
- 发起API调用
- 添加结果验证
- 保存测试用例
- 基于Postman的测试代码自动生成
A、发起API调用
对Account API做测试,需要选择Postmant的Request模块。进入相应界面后,执行以下三步操作,发起Account API的调用。
- 在endpoint输入框中输入http://127.0.0.1:8080/account/ID_008
- 选择GET方法
- 点击Send按钮发起API调用
完成以上步骤后,看到返回的response默认以JSON文件的形式显示在Body中
这样就完成了一次Account API的调用,但这只是一个API调用,并没有对调用结果进行自动化验证。
B、添加结果验证
在Postman中添加结果验证也非常方便,假定在Account API测试过程中有以下四个验证点:
- 请求的返回状态码(Status Code)应该是200
- 请求的响应时间应该小于200ms
- 请求返回的response header中应该包含Content-Type参数
- 请求返回的response body中,type的值应该是friends
首先打开Tests界面,然后在右下角的SNIPPETS中依次点击:
- Status code: Code is 200
- Response time is less than 200 ms
- Response headers:Content-Type header check
- 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的测试主要分为两个部分:一是,测试异步调用是否成功,二是,测试异步调用的业务逻辑处理是否正确。