【接口工具ApiPost】断言详解(6)-阅读本章需要编程基础(最好是JavaScript)
使用流程
- 定义测试用例
- 验证测试用例
以示例接口 新闻列表为例,新闻列表返回响应数据如下:
{
"code": 10000,
"msg": "success",
"data": {
"cur_page": "1",
"last_page": 2,
"page_size": "20",
"total": 30,
"list": [
{
"id": 3,
"title": "前后仅用了4分钟,16枚洲际导弹应声而出,美航母也不敢轻举妄动",
"author": "烽火杂志",
"url": "https://open.apipost.cn/",
"content": "世界上哪个国家可与美军抗衡?国际社会上关于这一问题的答案千奇百怪,但有一个国家用行动让美军闭嘴,短短4分钟连续发射16枚洲际导弹,场面十分壮观,让西方国家畏惧不已,即便是美航母也不敢轻举妄动。"
}
]
}
}
一、定义测试用例
定义入口在后执行脚本里;
特别注意:每个测试用例是一行,不能换行。
通用和常用的测试用例定义如下:
apt.assert('response.raw.responseText=="test"');
apt.assert('response.raw.status==200');
apt.assert('response.raw.type=="json"');
apt.assert('response.raw.responseTime>=100');
apt.assert('response.json.errcode==1');
apt.assert('response.json.errcode!=1');
apt.assert('response.json.errcode>=1');
apt.assert('response.json.errcode==null');
apt.assert('response.json.errcode!=null');
apt.assert('response.headers["server"] == "nginx"');
apt.assert('response.headers["content-encoding"] == "gzip"');
apt.globals.set("key", "value");
apt.globals.get("key");
apt.globals.delete("key");
apt.globals.clear();
apt.variables.set("key", "value");
apt.variables.get("key");
apt.variables.delete("key");
apt.variables.clear();
$.ajax({
"url":"https://echo.apipost.cn/token.php",
"method":"POST",
"async":false,
"content-type":"appicateion-json",
"data":JSON.stringify({
"email":"admin@admin.com",
"password":"密码"
}),
"success":function(response){
response = typeof response == "object" ? response : JSON.parse(response);
console.log(response);
apt.variables.set("token", response.token);
}
});
针对新闻列表这个接口测试用例定义如下:
apt.assert('response.raw.status==200');
apt.assert('response.raw.type=="json"');
apt.assert('response.raw.responseTime>=100');
apt.assert('response.json.code==10000');
apt.assert('response.json.msg=="success"');
apt.assert('response.raw.responseText.indexOf("data") > -1'); // 检查响应文本是否含有data字符串
apt.assert('response.json.hasOwnProperty("data")'); // 检测返回json对象的是否含有data字段
apt.assert('response.json.data.cur_page=="1"');
apt.assert('response.json.data.last_page==2');
apt.assert('response.json.data.page_size=="20"');
apt.assert('response.json.data.total==30');
下图为运行效果图
二、验证测试用例
绿色表示测试通过,红色表示测试不通过
再加一个明显不通过的定义:apt.assert(‘response.raw.responseText==“test”’);
apt.assert('response.raw.responseText=="test"');
apt.assert('response.raw.status==200');
apt.assert('response.raw.type=="json"');
apt.assert('response.raw.responseTime>=100');
apt.assert('response.json.code==10000');
apt.assert('response.json.msg=="success"');
apt.assert('response.raw.responseText.indexOf("data") > -1'); // 检查响应文本是否含有data字符串
apt.assert('response.json.hasOwnProperty("data")'); // 检测返回json对象的是否含有data字段
apt.assert('response.json.data.cur_page=="1"');
apt.assert('response.json.data.last_page==2');
apt.assert('response.json.data.page_size=="20"');
apt.assert('response.json.data.total==30');
结果如图:
三、集合(list)验证(官网里并没有这个示例,笔者是结合js语法特点然后一点点调试出来的,如有不足请谅解)
定义如下:
//验证集合list测试用例定义;
// 笔者暂时还没有找到添加断言业务描述的参数方法,一般断言有断言描述和断言表达式。但这个语法上好像不支持。
// 后期如果找到一并补充上
if(response.json.hasOwnProperty("data")){
// apt.assert('response.raw.responseText=="test"');
if(response.json.data.hasOwnProperty("list")
&& response.json.data.list.length>0){
// apt.assert('response.raw.responseText=="test"');
for(var i=0;i<response.json.data.list.length;i++){
apt.assert(true,"i="+i);
var item=response.json.data.list[i];
response.json.data.item=item;
apt.assert('response.json.data.item.hasOwnProperty("id")');
apt.assert('response.json.data.item.hasOwnProperty("title")');
apt.assert('response.json.data.item.hasOwnProperty("author")');
apt.assert('response.json.data.item.hasOwnProperty("url")');
apt.assert('response.json.data.item.hasOwnProperty("content")');
}
}
}
结果见下图:
笔者暂时还没有找到添加断言业务描述的参数方法,一般断言有断言描述和断言表达式。但这个语法上好像不支持。后期如果找到一并补充上
四、断言扩展体会
示例接口由于是动态环境,所以数据值会发生变化,不利于进行原始数据与后期接口获取的数据进行数据文件上的验证。
如不理解没有关系,这个属于业务数据驱动接口测试的一种测试理念。一般在大型且各种资源比较充沛的团队才进行这样的从服务环境、数据库、业务数据添加,修改,删除等一系列流程上完全被定义可预测且能验证的整体可测的测试设计。
不过笔者搞开发十多年也没有见过这样的大手笔。可能大厂有吧!一般几十刚过百人的研发团队就算了。没那必要性。
不过如果是支撑大流量且需要在高速奔跑火车上换换轮子的极端情况,搞这么一个十个人左右的小的数据驱动一切可测设计的测试团队还是有比较可观的收益的。这样可评估线上生产环境的风险范围以及当前研发团队的研发质量和风险意识。
期待扩展出使用json等格式文件进行数据断言的版本
五、番外
搞开发这些年见过很多给开发打绩效的方案:
比如:按代码量的,按工时的,按编码时长的,按提交数量的等等方式。只能说有比没有好吧!在表面搞搞人力绩效还是很能让老板满意的,于是各种加班996,007就出现了。
其实开发质量是可以从API接口测试里体现出来的能兼容的场景参数越多,服务越稳定。技术当然会比较好。当然笔者的观点估计不好理解和接受。这种用单元测试来衡量开发质量的还得是开发自己人来搞。不过接口工具的出现到提供了非开发人员来量化开发人员质量,也许是不错的方式。
以上言论纯属个人观念。如认同请点个赞,如不认同也不必留言反驳,因为留言也不一定被通过哈!
自研产品推荐
历时一年半多开发终于smartApi-v1.0.0版本在2023-09-15晚十点正式上线
smartApi是一款对标国外的postman的api调试开发工具,由于开发人力就作者一个所以人力有限,因此v1.0.0版本功能进行精简,大功能项有:
- api参数填写
- api请求响应数据展示
- PDF形式的分享文档
- Mock本地化解决方案
- api列表数据本地化处理
- 再加上UI方面的打磨
为了更好服务大家把之前的公众号和软件激活结合,如有疑问请大家反馈到公众号即可,下个版本30%以上的更新会来自公众号的反馈。
嗯!先解释不上服务端原因,API调试工具的绝大多数时候就是一个数据模型、数据处理、数据模型理解共识的问题解决工具,所以作者结合自己十多年开发使用的一些痛点来打造的,再加上服务端开发一般是面向企业的,作者目前没有精力和时间去打造企业服务。再加上没有资金投入所以服务端开发会滞后,至于什么时候会进行开发,这个要看募资情况和用户反馈综合考虑。虽然目前国内有些比较知名的api工具了,但作者使用后还是觉得和实际使用场景不符。如果有相关吐槽也可以在作者的公众号里反馈蛤!
下面是一段smartApi使用介绍: