3、大型项目的接口自动化实践记录----开放API练习
开始做实际项目前,先拿个网上的简单API练下手
一、API说明:
接口信息
接口名:京东获取单个商品价格
入参:skuids=J_商品ID&type=1
接口返回:[{"cbf":"","id":"","m":"","op":"","p":""}]
skuids说明:可通过具体页面查看,如http://item.jd.com/954086.html,页面中商品ID为954086
浏览器访问接口
我们在浏览器访问URL:http://p.3.cn/prices/mgets?skuIds=954086&type=1
可以看到,结果为[{"cbf":"0","id":"J_954086","m":"859.00","op":"459.00","p":"-1.00"}]
二、robotframework实现
首先先建一个测试用例:
右键suite,弹窗点击New Test Case
输入测试用例名,点击OK:
按照上一篇提过的,要先跟服务器打个招呼
1、跟服务端打招呼:Create Session
如下就是跟http://p.3.cn打招呼,而headers可以理解为外表及打招呼的方式
2、打完招呼,服务器会给予回应,收到回应后,则开始请求对方做具体的事情:Get Request
如下就是跟对方说,我想看一下商品ID为J_95046的价格信息。
3、以上就完成了与服务器的交互,执行用例看一下结果
可以看到,返回的是<Response[200]>,好像不是我们预期的文本,那是因为它是一个对象
4、上一步获取到的结果${resp}是个对象,而一般我们会想要接口返回的编码、json串内容或文本,那要怎么解析它呢。
${resp.status_code}:返回的编码
${resp.text}:返回的文本
To Json ${resp.content}:把内容转为json串
结果如上图,编码、文本等都是resp的属性,更多resp对象属性说明见下图:
5、获取到了实际结果,作为测试用例,还少一个跟预期结果对比:
①简单对比:返回的编码为指定值,返回的文本包含指定key
如果不等会怎样呢,我们把上面预期结果的状态码改成201,则会报如下错
②对比返回的文本中指定key的具体值,如p的值
${result}是一个list
${result[0]}取到第一个值,即{"cbf":"0","id":"J_954086","m":"859.00","op":"459.00","p":"-1.00"}
${result[0]['p']}则取到的是p的值
③全文本对比,这种方式数据稍微有变化,就不可用
就如这个案例中,用上述的方式对比,结果会报错
看上去两个数据明明一样,结果它却报不等
获取两者长度对比,才发现,前者比后者多一个字段,发现是文本的最后多了个空格。
④返回的json与预期的json对比
通过To Json,把content转为json格式,然后自己构造一个完全一样格式的变量,然后对比
⑤全文本与数据库查询结果对比
从数据库中查询出对应的值,然后类似④中构造出一个格式一样的变量,然后对比
④、⑤中对比,都有个问题,如果两者不相等,需要肉眼观察不等的原因,如果两个json串数据量很大,则比较难找到错误的原因
两者使用递归对比,实现难度会高点,好处是更准确、后续定位错误容易、维护工作量极低,具体后面再说。
作者:慢慢走的测试
出处:https://www.cnblogs.com/walkingtester/
交流群:636090586(备注博客园)
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
如果喜欢我的文章,请关注我的公众号