接口测试二三事

cover

公众号名片作者名片

本文主要介绍测试小团队在接口测试实践过程中遇到的一些事，如有雷同纯属巧合😊。

从 0 到 0.1——引入 HttpRunner

对于一个几乎是从零开始做接口测试的人来说，最简单的方法当然是要站在巨人的肩膀上了。于是我找了测试童鞋经常访问的网站 TesterHome，在为数不多的项目里看到了点赞数最多的 HttpRunner，大致浏览过后决定开干😂。

TesterHome

HttpRunner 项目结构简洁明了，对于初学者来说十分友好。

├── .env
├── .gitignore
├── debugtalk.py
├── data
├── reports
└── testcases
    ├── demo_testcase1.yml
    └── demo_testcase2.yml

大致安装使用步骤如下：

执行 pip 安装命令 pip3 install httprunner；
查看 HttpRunner 版本：hrun -V；
使用脚手架快速创建项目：httprunner startproject PROJECT_NAME；
根据自己的项目修改快速创建的 demo；
执行 hrun 命令，查看报告。

下图粘贴的是我们项目的结构图和之前运行过的报告。

这里附上官方文档，大家的疑问几乎都能查阅官方文档解决。

安装好工具，搭好项目框架，就得着手自身项目了。大部分接口我们都可以通过抓包工具获得，参数也很好处理，但是对一些有时效性的、需要加密、解密的参数来说，就需要我们和开发童鞋多沟通学习了。等了解清楚参数含义、参数作用域以及如何取得等问题后，我们就可以好好利用 HttpRunner 的 hook 机制来处理我们需要的参数：

setup_hooks: 在整个用例开始执行前触发 hook 函数，主要用于准备工作，如参数加密；
teardown_hooks: 在整个用例结束执行后触发 hook 函数，主要用于测试后的清理工作，如 token 保存。

下面截取的是我们项目中登录接口的一条用例，在 setup_hooks 中调用了 set_signatures 函数进行参数加密、验签处理；在 teardown_hooks 中调用了 save_token 函数进行登录之后的 token 保存，这样在之后的接口中可以直接使用，不用重复调用登录接口。

-   name: /xxxx/xxx/v1/codeLogin --验证码登录
    request:
        headers:
            signature: ??????
            aaaaaaaaa: ??????
            bbbbbbbbb: ??????            
        json:
            CCCCCCCCC: ??????
            DDDDDDDDD: ??????
            phone: $phone
        method: POST
        url: xxxx/xxx/v1/codeLogin
    setup_hooks:
        - ${set_signatures($request)}
    teardown_hooks:
        - ${save_token($response)}

至此，我们的接口测试算是开始了。

0.1 到 1.0——HttpRunner V3.x

随着时间的推进，大家觉得上面的工作越来越枯燥。每次新增接口就是反反复复的——抓包、抓包数据导出、yml 文件生成、testcase 文件修改、运行。重复且无成长的工作让团队的成员都不太愿意做这个事。

后来团队小伙伴组织学习 python 的过程中了解了 pytest 框架，于是乎我们的接口测试迎来了一次迭代更新。我们了解到 HttpRunner 3.x 完美支持 pytest 框架，就把之前的框架进行了升级。而且因为大家正处于学习 python 的阶段，每个测试小伙伴都积极地参与了这次改造工作，提高了大家的工作热情，同时也帮大家巩固了学到的知识。

下图是改造过程中 yml 文件和 py 文件并存的情况（此处感谢开发童鞋铁柱帮我们根据模板批量处理 yml 文件转化 py 文件❤️）。

也是在本次改造过程中，我们发现了之前疏忽的问题。由于测试小组全员参与，各个童鞋负责不同的模块，大家只是添加了自己负责的接口而忽略了接口间的依赖关系，导致新模块添加完毕后一执行就出现大量报错。

这也是官方文档中提醒大家注意的一个问题——测试用例（testcase）和测试用例集（testsuite）。每一条测试用例都应该是完整且可以独立运行的，而测试用例集的出现是为了方便大家定期地批量执行。 大家一定记得在初期设计的时候就划分好各自的功能模块。

（👆🏼上图来自官方文档）

整个 0.1 到 1.0 的迭代也使我们明白了一个道理，无论是搭建测试框架还是做接口测试这件事情，不要纠结于用什么语言、或者是用什么框架比较好，应该利用团队成员熟悉的、易上手的“工具”来实现。说到底，工具只是辅助我们更高效地工作，不能本末倒置。

1.0 到 2.0——Apifox

为什么引入 Apifox 就变成了 1.0 到 2.0 呢——项目人员不足但项目任务艰巨的困难真实存在，刚刚好开发童鞋引入 Apifox 工具，解决了测试、前后端开发一起高效协作的问题。下面一段话摘自 Apifox 在 github 项目中的介绍，我认为是毫不夸张的。

Apifox 是 API 文档、调试、Mock、测试一体化协作平台，定位 Postman + Swagger + Mock + JMeter。通过一套系统、一份数据，解决多个系统之间的数据同步问题。只要定义好 API 文档，API 调试、API 数据 Mock、API 自动化测试就可以直接使用，无需再次定义；API 文档和 API 开发调试使用同一个工具，API 调试完成后即可保证和 API 文档定义完全一致。高效、及时、准确！

下面简单介绍一下 Apifox 的使用：

项目设置：项目设置➡️导入数据➡️修改配置➡️立即导入。每次运行之前都刷新一下数据，再也不用担心跟不上开发童鞋的脚步了。
全局变量配置、环境配置：

公共脚本配置，包含前置操作和后置操作：

截取部分前置操作代码：

var sign = createSignatureJson(pm.request.method, req);
// 把请求的入参替换掉
pm.request.body.raw = JSON.stringify(sign.sortData);
// 把sign设置到headers中
pm.request.headers.add({ key: 'signature', value: sign.signature });

截取部分后置操作代码：

// 获取 JSON 格式的请求返回数据
var jsonData = pm.response.json();
var data = JSON.parse(jsonData.data)
// 将 jsonData.token 的值写入变量
pm.globals.set('token', data.token);
pm.globals.set('member_id', data.member_id);

新增接口：接口管理➡️新建分组➡️新建接口。如果接口开发已经添加了，直接用就好。如果没有的话，快捷方法就是直接在抓包工具复制整条 URL，粘贴在接口路径（2）的位置，Apifox 会自动填充 params，其他标红的字段要手动添加、保存。运行之后的用例也记得及时保存。
新建接口测试用例：自动化测试➡️测试用例➡️新建分组➡️新建用例（如果前期的开发 mock、联调做的好的话，这里可以自动导入大部分用例）。
运行用例，查看报告：