测试工程师之接口测试及自动化

前言

• 测试人员除了功能业务测试点点点外还需要掌握偏向技术方面的接口功能和自动化测试，工作这么久经历了不少公司蹭了不少项目，主要就是记录一下个人对接口测试的看法和理解，捡主要的说没用的直接略过

接口是什么

• 这个自行百度吧，有很多专业的解答，

接口测试工具

• 最最最常用的有：postman、jmeter、fiddler

接口测试需要自身会什么

• json和xml格式报文的拼写，接口功能业务(增删改查)的了解，简单工具使用，了解接口鉴权请求头

接口测试目的

• 分三个维度
  1.提升测试效率
  2.接口质量提升
  3.接口全量回归

• 分三个维度详解
  1.在接口还未开发好先拿着研发提供的接口文档写接口脚本，等研发把接口发到测试环境后第一时间跑脚本快速定位问题，难度在于json或xml格式报文的拼写，如果接口文档比较规范还好，如果入参示例都没有在遇到多层嵌套对象里有数组又有对象这样的非常难写，也非常考验细心度接口地址写错了入参字段少字母格式上少逗号请求方法写错了等等
  2.已有的功能接口抓包获取入参报文就容易多了，接口层面的校验限制是很容易被忽略的也是问题最多的地方，应该进行参数覆盖(为空、边界值、超边界值、整型、浮点、字符串等)，对数据类型不熟的第一反应会觉得接口测试不分数据类型，都带双引号整型和字符串咋分，其实到了后台sql上不加双引号才会体现出这两类不兼容的情况，还有就是违规参数比如前端自动计算金额然后传给后端，这时候传个错的看接口是否有和前端一样算法并且判断校验相等
  3.这个和前面1和2是有因果关系的，因为之前已经有写了只要批量去执行去跑就是在回归功能了，日积月累接口场景脚本写的越来越多后期收益就会越来越大，都已经完全被遗忘的每一个小角落都被接口脚本焊死有不符合预期直接抛出来，

接口具体测试范围

• 功能自动化每个公司都有要求以核心业务功能为主，自己用工具或编码实现，或者有自研的平台维护接口用例批量执行，参数场景根据每一个公司领导硬性要求或如果某一个场景没测试有bug会不会有风险，造成脏数据或报错能不能hold得住，根据具体情况个人经验判断下优先级或者要不要测试有问题抛出来研发会不会把你怼回来，好像除了有开发者平台的会专项实打实严格测试接口其他应该都没那么严，

开发者平台

• 说直白点就是负责的业务线里的某一个功能接口测试完成以后会挂到开发者平台，为什么呢？，因为用户不单单是从前端页面去操作某一个功能，可以理解为这个用户脑子有病又或者是他是另一个程序员要利用你的接口在进行二次开发，所以要严格的按照提前订好的规则来写接口文档以及测试接口，有开发者平台的网站不多，

• 通过开发者平台测试接口可以理解为再用之前的方法从新测试一遍因为底层之前已经测试过了，优先级就是连通性，到底什么怎么挂到开发者平台的呢？就是在原接口之上在包一层，经过一系列复杂的算法绕来绕去最后生成新的接口地址然后入参报文还是那个报文，总称SDK，这个一般研发会提供，自己要是有能力也可以问下规则自己封装

接口测试简单示例

• 接口是类似注册功能，一共三个字段【姓名】【账号】【密码】，规则是账号不可以出现重复的，账号密码必须大于等于8位姓名必须大于2位，暂且就这么多假象一下这个是产品文档里的规则，然后拿着产品文档和研发提供的接口文档去写接口场景脚本，

• 接口地址：/api/test_01
  name 姓名不能小2位必填
  username 账号不能小于8位必填全表唯一
  password1 密码不能小于8位必填
  {
  “name”:"",
  “username”:"",
  “password1”:""
  }

• 根据每一个字段的规则设计参数，必填、小于边界、边界值、大于边界值、例如name为空其他两个字段username和password1正常业务参数，反正劈里啪啦能写出一大堆混合的参数场景，什么样的参数接口是否成功失败具体的返回提示语都要验证

数据库表

接口代码

• 代码写的比较渣这不是重点，主要就是刨析一下后台更为直观的理解，主要就是判断条件，什么样的数据能成功插入表中，以及什么样的场景返回的提示语

import pymysql
import flask
import hashlib


server = flask.Flask(__name__)

@server.route('/api/test_01',methods=['post'])
def index():
    name = flask.request.json.get('name')
    username = flask.request.json.get('username')
    passwoed1 = flask.request.json.get('password1')
    if username and passwoed1 and name:
        if len(username) >= 8 and len(passwoed1) >= 8 and len(name) >= 2:
            if not select(username):
                if insert(name,username,MD5(passwoed1)[13::]) == True:
                    return {
     'msg':'添加成功','code':200}
                return {
     'msg':'添加失败','code':202}
            return {
     'msg':'用户名已存在','code':222}
        else:
            if len(username) < 8:
                return {
     'msg':'用户名不能小于8位','code':444}
            elif len(passwoed1) < 8:
                return {
     'msg':'密码不行小于8位','code':444}
            else:
                return {
     'msg':'姓名不能小于2位','code':444}
    else:
        if not name and not username and not passwoed1:
            return {
     'msg':'必填项不能为空','code':444}
        elif not name:
            return {
     'msg':'姓名不能为空','code':444}
        elif not username:
            return {
     'msg':'用户名不能为空','code':444}
        elif not passwoed1:
            return {
     'msg':'密码不能为空','code':444}

```bash
在这里插入代码片

工具调用使用

• postman、jmeter，要看一下接口具体请求头都需要什么，一般情况下都是{“Content-Type”:“application/json”},还有就是接口权限认证也就是区分是谁哪个用户调的，

• 只要场景覆盖的全，其实已经在测试接口的代码逻辑了，比如规则明确说明账号不能出现重复的表里唯一，那就找个已存在的试一下看一下接口返回结果，应用层实现的就是拿到账号去数据库里查如果查到了代码就跳到已存在的分支，要是没查到就进到不存在的分支进行向表里插入的动作

• 为什么说有时候研发比较烦测试人员，主要功能实现了接口健壮性提升质量少写好多代码，而且研发是最知道自己写的代码场景哪里不能测试，测试用例评审时候测试人员没提到的地方他是绝对不会说的，或者评审时测试人员提到的地方研发一直否决叨逼叨那绝对是这里也没做更是懒得做，

接口自动化

• 单个的接口场景(不同的入参)批量跑就是自动化，多接口业务链路串起来AB的也是自动化，如果要是工具postman应该也行没研究过，jmeter的话就是正则表达式，先调接口A拿到接口返回结果在调B接口把提取放到B接口入参某一个字段V处，能串起来跑就行了,而且jmeter的功能真的很强大，自带的断言或者会JAVA能写beanshell，连接数据库，尤其一些接口查询动态值的直接和数据库查询结果对比很方便，