领导叫我做接口测试,我好慌!

不要慌,问题不大! 此文主要献给在工作中接触接口测试,在群里咨询,公司叫我测试接口我该怎么去进行?测试用例怎么设计呢?还有我都不知道该怎么下手。我们来从做接口测试的前提以及接口测试必要的基础去分析分析。

这里个人作为接口小兵,简单整理几点,如果要进行系统的接口测试以下几点个人觉得是很有必要的:

1.被测对象业务充分熟悉

2.完备的接口文档/对象模型

3.自己至少有基础的接口测试功底(至少要会使用工具进行单/多接口)

个人使用postman:

Postman之设置环境变量

postman日记之断言篇

Postman日记之多个Json如何断言

4.熟悉HTTP/HTTPS请求;会使用抓包工具

HTTP详解 HTTPS原理详解

个人使用Fiddler:

Fiddler不会用,在公司经常被打脸吧?

5.后期接口框架的搭建

基于代码层去实现接口自动化最好,也是最体现价值的,现热python语言去做接口自动化,简易Python接口测试之Requests

下面是无涯大佬写的一本python自动化实战数据,里面包含基于python语言的接口自动化如何进行,写的很不错,大家可选择性购买,在《Python自动化测试实战》的书籍里面系统的介绍了基于Python语言的接口自动化测试实战和基于Python语言的UI自动化测试实战,特别是接口测试部分,详细的介绍了HTTP的协议原理,序列化与反序列化,主流测试工具(Postman和JMeter)在接口测试实战中的应用,

以及Requests的接口测试实战,和接口测试框架的设计,但是总觉得缺少一些维度没说明白,到书校验的后期一直想加,但是由于时间的紧张,就没继续添加新的内容。虽然我们很清晰的测试“测试金字塔”的模型,也系统完善的介绍了API的知识体系。但是接口测试的维度到底是什么,在UI和API的测试之间选择什么,如何选择?

我建议尽量做API的自动化测试,一方面做API的测试比较简单,第二是执行效率高,在维护成本上需要看具体设计的框架,但是比起UI的框架维护成本还是比较低的。接口测试从大的维度来说,

分为两类,一个是单接口的测试,另外一个是多接口的测试(基于业务场景的测试),单接口的在微服务和开放平台测试中比较常见,比如提供了一个接口给合作伙伴,但是需要测试来测试下这个接口的功能和它的稳定性,那么只需要在如下几个维度来具体测试:

1、接口的请求参数它的数据类型后台是否做了校验

2、接口的请求参数必填的参数后台是否做了处理

3、接口的请求参数长度是否做了处理 4、提供的接口是否实现了对应的业务场景和业务功能

5、这里个人补充一点接口的健壮性

在这里还是重点来看前面几点,关于后面的在多接口的测试来逐步的总结。

先简单的写一个接口,实现的源码如下:

#!/usr/bin/env python# -*-coding:utf-8 -*-from flask import  *from flask_restful import  Api,Resource,reqparse
app=Flask(__name__)api=Api(app=app)
class WuYaView(Resource):   def get(self):      return jsonify({'index':'无涯课堂'})
   def post(self):      parser=reqparse.RequestParser()      parser.add_argument('author',type=str,help='作者名称不能为空',required=True)      parser.add_argument('count',type=int,help='书的印刷数量为正整数')      parser.add_argument('sex',choices=['1','0'])      return jsonify({'status':0,'msg':'ok','data':parser.parse_args()})
api.add_resource(WuYaView,'/api/v1/book')
if __name__ == '__main__':    app.run(debug=True)

上面的一个简单的API,这个接口它有GET请求和POST请求的方法,在POST请求的方法中,auhtor字段是必须填写的,count字段类型是int,sex的参数只能只能填写'1'和'0',如果请求参数不符合规范,后台都会返回错误的提示信息,先看author为空,错误信息如下图所示:

当请求参数count为字符串的时候,见返回的错误信息,如下图所示:

请求参数sex不是指定的特定参数,见返回的错误信息,如下图所示:

最后来看一完整的请求,也就是说接口的请求参数是正确的,如下图所示:

从如上的角度来看,做单个接口测试是很有必要的,而且是必须的,但是我一般建议做单个接口测试的维度,只需要校验下接口是否可以正常的请求,以及请求后响应数据是否正确,至于请求参数这一层,依据情况来做,怎么说了,很多公司给测试接口的API文档都不提供,更别说去修改这些本应该判断的问题了,也从某些维度说,不是所有的事都是必须做的,依据情况进取舍。

多接口的测试,也就是基于业务场景的测试,这部分测试起来难度还是大的,但是这也是接口测试必须要做的部分,如果单纯的验证一个接口是否请求OK是没有多大意义的,更多的应该站在业务场景来设计接口测试用例,那么也就意味着中间需要处理很多的业务场景,动态参数的处理和业务逻辑的处理,关于这些在《Python自动化测试实战》的书里面都有对应的案例实战。

比如一个XX管理模块,使用接口自动化测试实现它的添加,查询,修改,删除,中间第一个需要处理的是添加成功后用户的ID需要获取到,并传给下一个接口,这中间就会使用到函数的返回值的知识体系,以及动态参数的处理思路,

另外一个业务逻辑是当添加用户的时候,实际XX用户已经存在(不能重复添加),那么也就需要在对象层对添加用户的接口进行判断,当添加用户存在的时候,怎么处理,不存在当然是继续添加和走业务场景,这中间也许有人反驳说我执行添加前看一下,如果存在手动删除,这样不智能,

另外一个观点是每次执行后都会删除,这是必须的,但是我们无法保证每次测试用例执行创建的用户就删除,比如某次执行的时候,删除的接口出了问题,导致没删除,在这中间,程序不能有太多的假设,用例必须考虑到各个业务场景和逻辑,然后在对象层进行处理。

这个案例的代码我就不写了,感兴趣的同学可以购买我的书籍看看,里面有案例代码。我不喜欢讲里理论,成年人的学习方式更加看重解决问题的思路和对问题的认知维度,理论是需要的,但是理论更多应该是我们经过实践总结起来,这样更加有意思。

《Python自动化测试实战》它不是一本讲理论的是,它更加看重问题的解决思路,和案例的实战。在实践中学习,在学习中实践的思考模式,把理论知识与实际应用相结合,举出真实的案例,让读者学会举一反三。也欢迎需要的同学购买。

脚本:无涯

图片:无涯

来源:无涯


/ END.

原文发布于微信公众号 - 猪圈子(Tester-sc)

原文发表时间:2019-09-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券