关于测试:接口测试二三事

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

从 0 到 0.1——引入 HttpRunner

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

HttpRunner 我的项目构造简洁明了，对于初学者来说非常敌对。

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

大抵装置应用步骤如下：

1. 执行 pip 装置命令 pip3 install httprunner；
2. 查看 HttpRunner 版本：hrun -V；
3. 应用脚手架疾速创立我的项目：httprunner startproject PROJECT_NAME；
4. 依据本人的我的项目批改疾速创立的 demo；
5. 执行 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 的应用：

1. 我的项目设置：我的项目设置➡️导入数据➡️批改配置➡️立刻导入。每次运行之前都刷新一下数据，再也不必放心跟不上开发童鞋的脚步了。

2. 全局变量配置、环境配置：

3. 公共脚本配置，蕴含前置操作和后置操作：

   截取局部前置操作代码：

   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);

4. 新增接口：接口治理➡️新建分组➡️新建接口。如果接口开发曾经增加了，间接用就好。如果没有的话，快捷办法就是间接在抓包工具复制整条 URL，粘贴在接口门路（2）的地位，Apifox 会主动填充 params，其余标红的字段要手动增加、保留。运行之后的用例也记得及时保留。

5. 新建接口测试用例：自动化测试➡️测试用例➡️新建分组➡️新建用例（如果后期的开发 mock、联调做的好的话，这里能够主动导入大部分用例）。

6. 运行用例，查看报告：

总结

至此本篇文章就要完结啦，心愿文中介绍的办法可能为大家提供一点小小的帮忙，不足之处大家也能够在评论区留言。最初还是揭示一句——不要自觉的跟风抉择，在某一阶段 适宜的才是最好的。

更多精彩请关注咱们的公众号「百瓶技术」，有不定期福利呦！