软件不同部分之间的交互接口。通常就是所谓的 API――应用程序编程接口,其表现的形式是源代码。 —— [ 百度百科 ]
我们常说的接口一般指两种:
这里我们所说的接口特指 API 接口。API 接口定义:对协议进行定义的引用类型。
好多公司开发人员分前后端,他们之间如何配合工作的,就是其中一方定义接口,另一方来调用接口,以实现预期功能。
WebService 接口是走 soap 协议,请求报文和返回报文都是 xml 格式,通过 SoapUI 工具进行测试;
HTTP API 接口走 HTTP 协议,通过路径来区分调用的方法,请求报文入参有多种形式,返回报文一般为 json 串,最常见的是 get 和 post 方法。
当今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,所以就要做接口测试。
同时,接口测试相对容易实现自动化持续集成,且相对 UI 自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。
接口持续集成是为什么能低成本高收益的根源。现在很多系统前后端架构是分离的,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。
前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端再接收应答的一个过程。
接口的功能、性能、安全性。重点关注数据的交换,传递和控制管理过程,还包括处理的次数。
接口测试对象是接口,但随着系统复杂度越来越高,接口越来越多,完全覆盖是一件很困难的事情。
通常情况下主要测试最外层的两类接口:数据进入系统的接口(调用外部系统的参数为本系统使用)、数据流出系统接口(验证系统处理后的数据是否正常)
2. 示例
注:上图接口文档工具为 ShowDoc
Postman 侧边栏允许你查找、管理请求和集合。侧边栏分为两个主要的选项卡,包括历史和集合选项卡。可以拖动右边的边来调整侧边栏的宽度。侧边栏也可以隐藏到小屏幕(标题栏 view—>toggle side bar)。
(1)历史选项卡
通过 Postman 应用程序发送的每个请求都保存在侧边栏的 History 选项卡中。
(2)集合选项卡
在侧栏中创建和管理集合选项卡的集合。
Postman 的顶部工具栏包含以下选项:
Postman 通过选项卡布局,用于在构建器中发送和管理 API 请求。上半部分是请求构建器,下半部分是响应查看器。
Postman 有两个控制台,可以帮助我们了解系统后台到底发生了什么。
(1)Get 请求
https://postman-echo.com/get?foo1=bar1&foo2=bar2
HTTP GET 请求方法是从服务器检索数据。数据由惟一 URI(统一资源标识符) 标识。GET 请求可以使用 “查询字符串参数” 将参数传递给服务器。例如,在下列请求中,http://example.com/hi/there?hand=wave,参数 “hand” 的值等于 “wave”。
(2)POST:URI 传参
(3)POST:Form-data 传参
(4)POST:x-www-form-urlencoded 传参
(5)POST:raw 传参
(6)POST:binary 传参
(7)Authentication Method——权限认证方法
(8)Headers——添加 header
示例 API:https://developers.douban.com/wiki/?title=book_v2#get_book
步骤一:使用 Postman 工具发送该 Get 请求,如下图。
步骤二:添加测试。
上图针对该 API 添加了 3 个测试:
注:当然你还可以增加更多的测试点。
(1)安装 Newman 工具
(2)部署 Jenkins
点击 Save 按钮,将接口保存到一个集合(可以保存到一个现有集合中或者新建一个集合),如下图:
将集合保存到本地,文件为 .json 格式,如下图:
(1)打开命令行窗口,运行如下命令:
D:\git-local>newman run MyCollection1.postman_collection.json -g globals.postman_globals1.json
(2)执行结果如下:
可以看到,其中两条断言 passed,一条断言 failed,失败的原因是,我们期望接口响应时间小于 200 ms,但是本次接口请求响应时间是 270 ms。
执行一次构建,构建失败(上面的断言失败,我们并未修复),查看构建失败原因。
接口响应时间减少了,我们需要回归测试。(我们将断言响应小于 200 ms,修改成 1000 ms,让断言 passed)
我这里有一个集合,3 个接口,第一个接口为登录接口,第二个接口为获取登录用户信息接口,第三个接口为修改密码接口。登录接口如下:
测试脚本如下:
参数化 json 文件内容如下:
[{
"loginName": "duzl", "password": "admin123", "verifyCode": "adf", "value": "/index"
}, { "loginName": "duzl", "password": "admin", "verifyCode": "adf", "value": " 账号或密码错误 "
}, { "loginName": "duzl", "password": "", "verifyCode": "adf", "value": " 参数 password 不能为空 "
}]
(1)好我们调用 json 文件,执行下集合,结果如下:
结果还不错,执行了 3 次,参数都是取自用例文件(json 文件),断言也取自用例文件。
美中不足的是,第二个和第三个接口也跟着迭代了 3 次(这并不是我们期望的结果),这是因为集合运行器中的迭代次数是针对所有接口的设置。
(2)那如果,我们想第一个接口运行 3 遍,第二、三个接口只运行一遍,该如何做呢?Postman 给我们提供了一个内置方法,设置接口运行顺序postman.setNextRequest('');
。
注意:迭代次数从 0 开始。
当迭代次数 !==0 时,就停止本次迭代(意思就是,第一次迭代全运行,第二次迭代开始就不执行第二、三个接口了),好,再次运行集合,看看结果:
很好,第一次迭代,执行了 3 个接口;第二、三次迭代只执行了第一个接口。
本文由 小马哥 创作,采用 知识共享署名4.0 国际许可协议进行许可 本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名 最后编辑时间为: 2022/04/01 21:27