软件测试|老大说要自动化测试,我是怎么做的可以看看

刚来公司两个月,老大说我们要把测试自动化做起来。
内心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 低编码,上手快 协同较弱,不易维护
YAp 低编码,上手快 需要开发团队在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,这是后话了。
所以,做一件事之前不能先下结论,也不能轻视。还是要严谨认真的对待。
个人拙见,如有误望指正。
再次我还整理了一些资料需要的自己领取gzh【清零0】


    推荐阅读