接口测试的维度

Posted Python自动化测试

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了接口测试的维度相关的知识,希望对你有一定的参考价值。

    在《Python自动化测试实战》的书籍里面系统的介绍了基于Python语言的接口自动化测试实战和基于Python语言的UI自动化测试实战,特别是接口测试部分,详细的介绍了HTTP的协议原理,序列化与反序列化,主流测试工具(Postman和JMeter)在接口测试实战中的应用,以及Requests的接口测试实战,和接口测试框架的设计,但是总觉得缺少一些维度没说明白,到书校验的后期一直想加,但是由于时间的紧张,就没继续添加新的内容。虽然我们很清晰的测试“测试金字塔”的模型,也系统完善的介绍了API的知识体系。但是接口测试的维度到底是什么,在UI和API的测试之间选择什么,如何选择?

     我建议尽量做API的自动化测试,一方面做API的测试比较简单,第二是执行效率高,在维护成本上需要看具体设计的框架,但是比起UI的框架维护成本还是比较低的。接口测试从大的维度来说,分为两类,一个是单接口的测试,另外一个是多接口的测试(基于业务场景的测试),单接口的在微服务和开放平台测试中比较常见,比如提供了一个接口给合作伙伴,但是需要测试来测试下这个接口的功能和它的稳定性,那么只需要在如下几个维度来具体测试:

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

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

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

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

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

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