领导叫我做接口测试，我好慌！
Posted Python测试社区
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了领导叫我做接口测试，我好慌！相关的知识，希望对你有一定的参考价值。
不要慌，问题不大! 此文主要献给在工作中接触接口测试，在群里咨询，公司叫我测试接口我该怎么去进行？测试用例怎么设计呢？还有我都不知道该怎么下手。我们来从做接口测试的前提以及接口测试必要的基础去分析分析。
这里个人作为接口小兵，简单整理几点，如果要进行系统的接口测试以下几点个人觉得是很有必要的：
3.自己至少有基础的接口测试功底(至少要会使用工具进行单/多接口)
5.后期接口框架的搭建
基于代码层去实现接口自动化最好，也是最体现价值的，现热python语言去做接口自动化，简易
下面是无涯大佬写的一本python自动化实战数据，里面包含基于python语言的接口自动化如何进行，写的很不错，大家可选择性购买，在《Python自动化测试实战》的书籍里面系统的介绍了基于Python语言的接口自动化测试实战和基于Python语言的UI自动化测试实战，特别是接口测试部分，详细的介绍了HTTP的协议原理，序列化与反序列化，主流测试工具(Postman和JMeter)在接口测试实战中的应用，
以及Requests的接口测试实战，和接口测试框架的设计，但是总觉得缺少一些维度没说明白，到书校验的后期一直想加，但是由于时间的紧张，就没继续添加新的内容。虽然我们很清晰的测试“测试金字塔”的模型，也系统完善的介绍了API的知识体系。但是接口测试的维度到底是什么，在UI和API的测试之间选择什么，如何选择？
我建议尽量做API的自动化测试，一方面做API的测试比较简单，第二是执行效率高，在维护成本上需要看具体设计的框架，但是比起UI的框架维护成本还是比较低的。接口测试从大的维度来说，
分为两类，一个是单接口的测试，另外一个是多接口的测试（基于业务场景的测试），单接口的在微服务和开放平台测试中比较常见，比如提供了一个接口给合作伙伴，但是需要测试来测试下这个接口的功能和它的稳定性，那么只需要在如下几个维度来具体测试：
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自动化测试实战》它不是一本讲理论的是，它更加看重问题的解决思路，和案例的实战。
在实践中学习，在学习中实践的思考模式，把理论知识与实际应用相结合，举出真实的案例，让读者学会举一反三。
也欢迎需要的同学购买。