我正在参与掘金创作者训练营第4期，点击了解活动详情，一起学习吧！
刚来公司两个月，老大说我们要把测试自动化做起来。
内心OS：接口自动化好做，把之前公司做过的的搬过来改一改就好了。
我：那么我们就做接口自动化吧！
老大：为啥选接口自动化而不是UI自动化呢？
我：测试金字塔balabala，接口自动化的投入产出比比UI自动化的投入产出比高；而且我们现在UI每个迭代UI变动还比较多，最核心功能UI也在迭代，并不适合做UI自动化。
老大：那兼容性测试可以通过UI自动化完成么？
我：很多屏幕比例类的兼容性问题是一些类似展示不下、元素重叠的问题，这类用UI自动化需要投入很多，却不一定可以发现问题；还有一些系统兼容性问题，我们在手工兼容性测试时验证每个系统基本就够了。
自动化脚本重点还是测试用例，人所能想到的用例才可能被机器断言出来。但是实际上，很多兼容性问题都是人没有想到的。
目前我们的兼容性测试可以满足我们的版本要求，我们也允许线上出现某个机型的兼容性问题，没有软件可以做到100%兼容所有机器。
老大：好，那就做接口自动化吧！
我：好的，我先调研下我们选什么工具、框架。然后我们一起开会讨论决定下。
。。。。。三个月过去了，每天忙于迭代功能的测试，只能见缝插针的抽时间调研。
以上是背景。
以下是调研过程。
之前想的简单了，本来是想拿之前的Java+Httpclient+TestNG改一改很快就可以落地了。经过了解同事的想法和面试的时候接触了很多用python的面试者，所以倾向于这次用Python。
18年用过Httprunner2.x，当时可能了解不深入且这个框架还不是足够成熟，所有只是尝试用了下就放弃了。这次看了下3.x的官网文档，认为很适合快速落地。所以倾向用Httprunner。
于是结合官方文档写了自己项目的Demo，包括不同类型入参的参数化、登陆token的处理等。接口自动化重点是入参和断言，接口的调用其实是最简单的，Httprunner很好的处理了这个问题，直接Fiddler/Charles导出接口后生成测试用例，然后去做参数化和断言。
同时，我也在git上找了一些现成的轮子，借鉴整合攒出了一套框架python+requests+pytest，需要自己封装请求。
我把目前主流的几个接口自动化的工具框架做了对比：
| 工具 | 优点 | 缺点 |
|---|---|---|
| Jmeter | 低编码，上手快 | 协同较弱，不易维护 |
| YApi | 低编码，上手快 | 需要开发团队在YApi维护接口文档 |
| python+pytest+requests | 协同强，易维护 | 需python基础 |
| Httprunner（pytest、YAML、JSON） | 协同强，易维护， | 需python基础 |
| Java + testng | 协同强，易维护 | 需java基础 |
| 接口自动化测试平台 | 低编码 | 需专人维护 |
。。。。。又一个月过去了。依然每天忙于版本迭代。
趁着开发周，拉着老大和测试团队开会讨论确定下框架就开干了。
讲完了这几个工具框架，同事都倾向于第二个，而没有选择Httprunner。大家还是希望通过python+pytest+requests框架提升下编程能力，那就少数服从多数，我们定下了这个框架。
老大给了我们核心的两大块儿，我列出了这两大块儿的三十多个接口，做了分工，我们四个人就开干了。
集成了Jenkins和Allure，算是一期接口自动化完成了。
在这个过程中，也遇到了一些问题，也有了一些新的收获。
本以为照搬原来的框架交差，也没有什么成长。实际上，深入使用了Httprunner，也阅读了几个git上较好的轮子，受益很多。
本以为大家会和我一样选简单的Httprunner，实际上，同事对Httprunner担心会有局限也有一定道理，所以选了自研的框架。所以还是要多听取大家的建议。
本以为处理登陆提取token很简单，实际上，登陆由用户中心维护且有加密，单凭测试没办法获取token，这是后话了。
所以，做一件事之前不能先下结论，也不能轻视。还是要严谨认真的对待。
个人拙见，如有误望指正。
end。