HTTP API自动化测试

重构：发现测试的价值回到起点，测试要解决什么问题，为什么要做API自动化测试平台？做这个平台，不是为了满足老板的提倡全民自动化的口号，也不是为了浮夸的KPI，更不是宣传自动化可以解决一切问题，发现所有bug。叔本华说过一句话：由于频繁地重复，许多起初在我们看来重要的事情逐渐变得毫无价值。如果API测试仅仅依靠纯手工的执行，很快将会面临瓶颈，因为每一个功能几乎都不能是第一次提交测试后就测试通过的

贾诩是也

5046人浏览 · 2017-08-04 23:01:55

贾诩是也 · 2017-08-04 23:01:55 发布

重构：发现测试的价值

回到起点，测试要解决什么问题，为什么要做API自动化测试平台？做这个平台，不是为了满足老板的提倡全民自动化的口号，也不是为了浮夸的KPI，更不是宣传自动化可以解决一切问题，发现所有bug。叔本华说过一句话：由于频繁地重复，许多起初在我们看来重要的事情逐渐变得毫无价值。如果API测试仅仅依靠纯手工的执行，很快将会面临瓶颈，因为每一个功能几乎都不能是第一次提交测试后就测试通过的，所以就需要反复bug修复、验证，以及回归的过程。另外，很多的API测试工作手工做起来非常的繁琐，甚至不便，比如针对接口协议的验证、针对返回数据格式的验证，这些都依赖于测试自动化的开展。因此，真正的目的是解放测试人员重复的手工生产力，加速回归测试效率，同时让研发人员在开发过程及早参与测试（自测、冒烟测试），驱动编码质量的提升。

回顾以往，重新梳理头绪，更加清晰的展现：

(点击放大图像)

图-8-HTTP API自动化测试图解

HTTP API传统手工测试

重复请求参数基础校验、正确参数查询返回数据校验，测试工程师没有新的创造价值，不断重复工作，甚至可能压缩其中的测试环节，勉强交付；

HTTP API自动化测试

重复步骤（请求接口是否有效、参数校验可以作为冒烟测试，研发参与自测）用自动化解决，关键业务步骤数据对比人工参与和schema自动化校验；

最大的收益，重复步骤自动化后，不管是研发人员自测，还是执行功能回归测试，成本可以很快收回（前提是你这个项目周期长，构建频繁；如果仅仅是跑几个月的项目，真没那个必要凑热闹去自动化，当然有平台的另当别论），测试的关注点会落实到更加关键的业务环节去；

总体规划如下：

(点击放大图像)

图-9-HTTP API重构规划

技术选型
由于原来的测试平台使用Python编写，为了保持风格一致，从界面录入到文件生成处理依然采用Python、Django，去掉了全对偶组合算法，改为根据测试人员思维去产生用例；去掉了后台RobotFramework框架，采用Python的HTTP类库封装请求。
HTTP API项目管理Web前台
使用Python+Django+MySQL进行开发，分为项目首页、项目配置、API配置、全局配置四大部分

(点击放大图像)

图-10-管理Web

> 项目首页

介绍：列出API规范、API测试用例、定时任务数量，以及某段时间内的测试结果趋势图形。

(点击放大图像)

图-11-项目首页
项目配置
重点介绍：全局变量、常用方法、验证器。

>全局变量

设计思路：在API测试过程中，可以切换生产、测试环境进行对比校验，如果写两套测试用例是冗余，全局变量功能，是一种在执行测试用例时动态改变用例属性的方法。

作用范围：当前项目内

使用方法：{变量名}

能在以下测试用例属性中使用：URL、请求头、请求参数

(点击放大图像)

图-12-全局变量配置页

在API用例库的URL可以直接填写：{host}/reportdata/monitor/getChannelIDsByUserName；当运行测试用例的时候，可以选择不同的参数套件，后台代码执行会直接替换，这样子可以分别快速验证生产环境和测试环境的API接口执行结果的差异。

(点击放大图像)

图-13-用例执行页

>常用方法

(点击放大图像)

图-14-常用方法列表页

√ 设计思路：常用方法是一个Python函数，对入参进行处理并且返回结果，例如：

gen_md5 作用是生成MD5，对应代码直接填写：
```
import hashlib
def gen_md5(raw_str):
    m = hashlib.md5()
    m.update(raw_str)
    md5_str = m.hexdigest()
    return md5_str
```
√ 应用场景：

在API请求中，有些参数例如pass需要加密处理，可以通过引入[常用方法]来解决。

在参数pass的值中直接填写：
```
{{get_apipwd("{123456}","ChinaCache")}}
```
(点击放大图像)

图-15-接口配置页

> 验证器

(点击放大图像)

图-16-验证器配置页

√ 设计思路

验证器是一个Python函数，如果函数返回True，则测试通过；返回False，则测试失败。平台默认提供一个默认验证器。

默认验证器是验证期望结果与实际结果（response body）是否完全一致。如果结果不一致则判断为失败，默认验证器只适用于静态的响应结果对比。

自义定验证器，如果默认验证器不能满足某些特殊的测试需求，用户可以在“项目配置-验证器”中添加自定义的验证器。

√ 应用场景：在API测试的返回结果中，可以添加自定义验证器对数据进行校验，判断测试是否通过。

(点击放大图像)

图-17-测试用例验证展示页
API配置
重点介绍：通用响应配置、API依赖库、API用例库、定时任务、测试报告

> 通用响应配置

(点击放大图像)

图-18-通用响应配置列表页

√ 设计思路

在合理的API设计中，存在通用的错误响应码，[用户名错误，返回期望响应内容]，如果所有API的响应结果中都需要重复写是相当繁琐的，作为共同配置调用即可。

(点击放大图像)

√ 应用场景

查询接口遇到用户名密码为空，可以自定义写返回内容，以及选择[通用响应配置]下的相关错误类型，例如：用户名密码为空(计费单元)，自动填充期望的返回值：
```
<BillingIDs>
  <Result>fail</Result>
  <DetailInfo>invalid userName or password</DetailInfo>
</BillingIDs>
```
(点击放大图像)

图-19-期望返回值校验页

> API依赖库

√ 设计思路&应用场景

API-A的参数r_id依赖与API-B返回结果的某个参数（多个参数同样道理），这里登记API-B，并且提取返回参数。除了特有的变量提取器，基本信息与请求，与后面提到的API接口一致的

填写方式：

(点击放大图像)

图-20-变量提取器展示页

该接口返回数据如下；
```
{
  "r_id": "567bbc3f2b8a683f7e2e9436"
}
```
通过[变量提取器]，可以获取r_id的值，以供依赖API-A作为参数使用。

(点击放大图像)

图-21-用例中参数包含r_id变量展示页

其中请求参数的获取如下：

(点击放大图像)

图-22-请求参数变量提取设置

测试结果：

1-显示依赖接口；2-显示为需要测试的接口，依赖接口返回的r_id会传入作为测试接口的参数；

(点击放大图像)

图-23-测试结果中展示运行时变量提取结果
API用例库
(点击放大图像)

图-24-用例库设计脑图

√ 设计思路

通过自助配置：请求头、请求参数，响应头、响应结果校验，来聚合测试人员日常思考产生的测试用例。

√ 应用场景

支持HTTP1.1协议的7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。最常用的方法是GET和POST：
1. 支持query（问号后）带参数、path的GET|POST请求
  Query:http://192.168.1.11/internal/refresh?username=ChinaCache&password=123456
  
  Path:http://192.168.1.11/internal/refresh/username/password
2. POST请求支持application/json、text/xml
  示例如下：
```
请求头设置：Content-Type:application/json
           请求体设置：保存为JSON格式
{
    "username": "ChinaCache", 
    "password": "123456", 
    "task": {
        "dirs": [
            ""
        ], 
        "callback": {
            "url": "", 
            "email": []
        }, 
        "urls": [
            "http://www.chinacache.com/news/test.html"
        ]
    }
}
```
  结果如下：
  
  (点击放大图像)
  
  图-25-body参数展示页
3. 支持返回结果的schema验证
  在返回大量数据的场景下，把数据格式的正确性交给程序去判断，通过之后进行人工干预的数据对比，假如返回几百K的数据，你不知道格式是否正确，就开始去做数据对比，这个方向是不对的。
```
{
  "r_id": "567cfce22b8a683f802e944b"
}
      Schema验证如下：
{
    "$schema": "http://json-schema.org/draft-04/schema#", 
    "required": [
        "r_id"
    ], 
    "type": "object", 
    "id": "http://jsonschema.net", 
    "properties": {
        "r_id": {
            "type": "string", 
            "id": "http://jsonschema.net/r_id"
        }
    }
}
```
定时任务
√ 设计思路&应用场景

定时任务是在计划好的时间点自动执行指定的测试用例。一个项目支持多个定时任务，如果同一时间点有多个测试任务，将依次执行。定时任务有两种类型：定时、循环（间隔：秒，

分钟，小时，天，周）。通过定时任务，可以做到晚上运行，早上查看结果报告分析。

(点击放大图像)

图-26-添加定时任务
测试报告&邮件通知
√ 设计思路&应用场景

每次执行测试用例（包括手动执行和定时任务）之后，都会生成一份测试报告。

报告会详细列出每个接口的基本信息（名称，请求方法，验证器等），请求信息（URL和body参数），响应信息包括headers, body, schema, content type, status code 5部分的测试结果，每一部分都有实际结果、期望结果（失败时显示）以及DIFF对比（失败时显示），当在

执行测试时出现错误，也会把错误信息显示出来。

(点击放大图像)

图-27-测试报告列表页

(点击放大图像)

图-28-邮件通知

API实战：324个用例（包括GET|POST请求，参数有加密、依赖场景，返回结果有简单验证数据、错误码验证、schema验证），运行耗时：8min，猜想下，如果人工去跑，需要多久呢？

提速：研发测试流程改进

(点击放大图像)

图-29-使用HTTP API平台改进API研发测试过程

改进前：传统手工测试
测试用例掌握在测试人员手里，研发人员无法运行，修复bug之后，只能等待测试人员验证，交付过程繁琐、效率低；
改进后：HTTP API自动化测试
研发、测试协作同步，研发人员可以及早通过平台执行用例，验证功能可用性、正确性，测试人员可以释放部分劳动力，重点关注业务数据正确性；修复bug之后，研发人员无需等待，可以自助配置用例执行、查看结果，驱动过程质量的提升，同时做到夜间构建、邮件通知，工作时间review、bug fix。
问题：何时收回投入成本？
API项目周期不超过半年的，不建议做自动化，有自动化平台基础的另当别论，因为在最初API测试用例编写需要投入大量的时间；这种投入，只有不断进行回归验证、多次运行，成本才可以回收，往后都是收益，这个道理浅显易懂。

总结

“由于频繁地重复，许多起初在我们看来重要的事情逐渐变得毫无价值”，在提测过程有个重要环节：冒烟测试，但是频繁的去做的话，就是重复性的工作了。

那HTTP API接口测试痛点是什么？研发人员提测之后，需要等待测试人员进行验证；测试人员发现bug，需要等待研发人员bug fix；这里就产生大量的等待成本（当然，测试人员可以切换到其他项目中去，但是这种上下文的切换成本很高）。通过HTTP API自动化测试平台，研发人员在提测之前，首先进行一轮冒烟测试，根据自动化测试用例检查结果，提升提测之前的功能质量；一旦提测之后，测试人员的关注重点落到返回结果对比上，这种研发测试过程的效率会得到很大的提升，或许有人要问，到底提升多少呢？这个每个团队的痛点不同，研发、测试人员磨合程度不同，不能一概而论，大胆迈出一步去尝试，就会发现价值；当然，往深处去想，下一步可以接入性能的自动化测试，喝杯咖啡的时间，等到自动化运行结果报告产出，是有可能的场景。