自动化工具 一次不算成功的接口自动化测试平台实践--吐槽自己,反思自己,轻喷

萌梓萌爸 · January 16, 2020 · Last by 不吃猫的金鱼 replied at January 22, 2020 · 2180 hits

起始:
2017年6月,从上家公司离职到现在的公司,然后开始做接口自动化测试框架,用Jenkins来调度脚本,然后搭个服务弄个报告平台。此时就我一个人,即维护框架也写用例外加基础的性能测试工作。流程上就是:找业务线QA核对自动化需求,商讨用例,编写用例,然后验收,发布交付部署。效果嘛,其实大家都猜的到,效果不是很好,使用率不高,而且大家基本不是很care结果,在加上当时项目比较少活不多,人员也少,所以后来就不了了之。
2018年后经给领导授权和组内讨论(其实也就三四个人),决定把接口自动化平台化以应对即将到来的项目扩张和人员扩张(2018年从原来的3-4个人,迅速扩张到了90+)。经过多次设计和架构调整,最终在2018上线一个版本,基本可以完成接口测试线上完成,线上逻辑组织,报告在线查看,在线造数据,mock,在线调试等等的功能。但是在使用上还是存在一些不变,这也为后面的推广埋下了第一颗失败的种子。
经过2018年的工具打磨,2019年我们进行了改版,在上半年完成了版本更新,然后进行所谓的大规模使用。但是推行效果很差,基本上大家都不愿意去使用。幸运的是在众多的产品线中,有一个产品线对我们的工具进行了深度使用,也取得了一些显著的效果,让我们还是看到了一丝希望的。后来以此最佳实践为表率,开始了第N次全员推广,从管理层面也施加了一些压力,但结果往往是与预期有所差距的。推广了几个月,效果可以说有,但是基本上都是以完成政治任务为主,真正去深度使用的极少极少。培训做了N次,但是基本上大家都是来走走过场,需求也收集了N次,基本上完成开发后大家也就弃之不用了。有时候真的想到自己和团队小伙伴的付出不能得到大家的认可,很难受,很伤心。
眨眼2020年,我抽空看了下平台的使用情况,目前大概周活用户10+,月活用户40+,从这个数据上看可能还过的去,但是细数里面的收益可能也是差强人意吧,我看了所有的项目,所有的测试计划,我认为真正在发挥价值的可能不到30%,其余的或许我不明白业务吧。所以我也不敢过多评论。
再来说说我所见和我所闻吧。我知道除了我们团队和深度使用我们产品的个别团队外,其他团队可能对我们还是深有误解的吧。我也收到过很多背后的吐槽。“这个平台真的不好用,用户体验太差”,“功能上使用复杂,不止从何下手”等云云,甚至,有一个我们团队的小伙伴,之后去了业务线,也不再继续使用,而且在一次管理会议上说到。“其实我们不建议用界面化的工具,我建议还是以coding为主,这样能很快提升团队的能力,我们组就是,我现在留足够的时间给大家coding”。当然我当时听到很震惊,毕竟此前他也是我们的核心成员,平台部分核心功能也是由他来完成。当然我也很失落,觉得自己很失败。
最近我有时间静下心来好好回顾自己的过去的两年,有收获,收获了一帮志同道合的朋友,收获了一起与平台成长的伙伴,也收到过鼓励和肯定。有失落,失落来自方方面面吧。
反思自动化平台的整个过程,也来小小总结下:平台化需要理性,平台化成功与否,平台本身占30%,平台使用者是否认同占40%,领导是否有决心统一化30%。此是我本次实践含泪总结的三点,想要成功,需要领导极力配合,需要全员有决心,当然需要照顾到平台使用这个的感受,能否成功,绝大原因看平台使用者是否接纳支持这样的模式,毕竟coding对自己的找下家有很大帮助,对自己代码提升有很大帮助。界面化的工具之能在当前公司适用,而框架可以轻易的复制。另外平台化之前还是需要慎重考虑自己团队的现状和情绪,毕竟并不是所有人都那么容易接受新的工具,就算被动接受,后期效果也不会太好。所以还是得视团队,视公司情况而定。
平台化过程中还是需要不断与一线使用的小伙伴保持沟通,加强参与感,平台需要与使用者一起成长。这点也很重要,推广一个平台是需要很长实践,毕竟改变一个人的习惯需要时间去慢慢影响。只有当平台成为习惯,大家才能接纳,使用,喜欢,再到不断去提需求,平台才能不断的进化。
以上都是自己的视角,有什么不对,还请大家轻喷。

共收到 32 条回复 时间 点赞

我最开始也想做个接口测试平台,功能一大堆,结果用不起来,后面闲着就做了很多devops的工具放在平台上,比如批量推送,根据jira自动推送,自动搭建环境等等都是些小玩意,结果用的人很多,再后来改进了下原来的接口测试功能,把它变成了个执行shell命令的东西,就变得很火热了,因为测试经常要使用curl来调接口,这个平台能保存命令就比xshell方便。总结下来我觉着只有解决了别人的需求,工具才能得到推广。

Vanessa 回复

是的呢,我现在也在思考后续的方向,感觉还是需要去一线多了解,多接触才能看到对方的痛点是什么,然后针对性的解决,我们现在基本属于闭门造车,是我的失职,需要反思。同时感谢你的回复,谢谢!

看LZ写这么多我也说下感受吧,其实我转行过来没多久,之前想着做开发无奈准备不足,再加上生活压力先入了测试的坑。虽然没做多久,但是通过这一年多来的工作也对测试岗位有不少感触。现身处某公司,规模较大IT部门管理混乱,每个部门都有自己测试的管理方式,这让我在一家公司就感受到了不同测试管理的差异。第一,附和LZ的关于测试平台这块先说,LZ其实不止你,我目前所处的测试团队也做了相关的测试平台,从19年初就已经在投入使用,然而如楼主一样,团队内没有人愿意使用,尽管你吹的天花乱转也很少有成员愿意去学习,到了第二季度的时候,部门老大坐不住了,招了几个测试开发造出来的东西没人用多尴尬,于是强行推行让每个成员编写脚本使用,并纳入到绩效考核中去,于是组里每个人不得不为了绩效去使用这个平台,但是每个人也是为了迎合一下只是写几个脚本跑起来交个差就行,对外宣称自动化平台多牛逼...说下来是不是和LZ情况差不多?这种情况我们不得不去深度思考一下这背后的问题。

😂 原来孤单的不是我一个

接上面,我们深入下以下问题:测试平台有必要吗?这些很难去回答,但我们可以从以下角色去研究下;

  1. 测试人员,平台上线后最终交付给的是负责业务线的测试人员,这些同事每天忙于业务的梳理,需求的跟进测试,在没有测试平台前,有很多工具供他们选择,接口JMETER,POSTMAN等等,这些都是主流开源的工具也都是官方开发的,做的相对完善也容易上手,对一般工作需求 来讲还是可以满足的;现在做一个测试平台来替换这些工具,换谁谁都不愿意,所以他们觉得你这个东西不好用且没必要,哪天跳槽了对自己也没啥积累。
  2. 测试经理,测试平台推进的人,身处管理职位,不得不考虑如何建立高效的测试流程。因此凡是市面上正在推行的技术方案都会尽力在公司内部推行。但是不乏有不少管理人员水平低,没有分析去盲目推行技术的。
  3. 测试开发,总算不再点点点了,听上去也和开发平齐,相信没有代码搞不定的自动化,你们天天点点点有啥意思?点也点不出bug来,感觉用我们新开发出来的平台吧。

最开始我也遇到过这种困扰,做出来的东西没人用,用着用着就放弃了。后面发现确实是自己没做到痛点,配置复杂,使用繁琐。

然后我就先做一堆“一键”就能用的小工具,有不爽的就盯着改,最终整合到一起,大家用的相当开心。

再说个在群里发生的小故事吧,有小伙儿伴在群里说要找人一起做测试平台,一是练练技术,二是找工作也能撑下台面。于是大家开始讨论,A说我们差个技术架构,找个做架构的来指导下我们;B说我会写Python,前端不太好再招个前端帮我们写写页面吧。C说我们还差个产品,没有需求我们做的也是瞎做。恩,这就是来自一个真实的测试群里的对话。这也让我发现一个问题,想要做好测试平台远没有想象中的那么简单,就像做一个产品一样需要测试开发产品。测试平台开发好了,大家说难用那说明需求没想好,测试平台有BUG,因为没有人测试啊。。

看来大家都差不多,目前我的还只是自动化框架,利用jenkins构成ci(编译打包,接口自动化测试)。但整个CI流程推不动。。好累。

每次分支上线开发都不跑,其实就是一键操作而已。。等个10来分钟就收到报告了。后来测试组内推广,提测时跑CI,跑下静态分析(静态分析没集成到CI)。

但有一个业务组,就很充分利用,有时还提需求给我,现在jenkins上各种类型job很多,也算是价值提现吧😂

有一种情况就特别心累的,CI每天会定时构建(master分支), 当有用例失败时,就各种蛋疼,为什么master分支出问题😂 (说明没推广好),要么服务有问题,要么用例有问题,然后各种问人,查看合并master的代码,然后用例维护。。真的累。。

之前还想,jenkins的job越来越多,是不是开发个测试平台代替jenkins触发,感觉高上大,看到各位的现状,看来是没这个必要了😂

很难叫醒一个装睡的人,不排除部分人不想去学习去接触新事物,但往往大部分情况下是做的东西达不到使用者预期。
以前有团队推广UI和接口自动化测试平台,自己也是没有很好地应用起来,主要原因并不是不好用,而是投入成本和产出不成正比。
现在轮到自己去推广自动化测试平台,也是谨而慎之,因为自己知道还不能达到很好的效果,不能给效率和质量带来帮助。更多时候会从一些小需求出发,比如做一些数据处理、tts等辅助工具,大家的反响更好。

Ouroboros 回复

让所有的测试变成测试开发,测试开发为自己服务。两者合一的产出大家都看得见。测开的产出,自己能感受到。
老哥,看你其他帖子的回复,我也觉的以后还有测试岗位趋势也正如你所说的那样,测试开发不分家。我若是管理我也会往这块儿去做,目前我还是觉的测试平台对于大多数公司是非必要的,测试深入技术去保证质量这是最应该去做到的,但是现在人员水平参差不齐,能力强的同学需要突出自己于是有了测试开发岗位,所以初期阶段测试开发经验的不足加上管理水平差,才会导致了开发平台没有人的囧事!

立方 回复

兄弟,没人会装睡,希望你借前车之鉴做好,测试行业需要正确的方向推动。

立方 回复

我也觉得小工具好,这是实在,并能够解决当前他们遇到问题,效率的地方😀 ,用得顺手的话,还会告诉其他人有这个东西,自己推广都不用

重来看雨 回复

你的问题不在做不做平台上,而是没有人帮你推动,在保证CI没问题的情况下,如果是用例或者代码出了问题,就让相关负责业务的人员自己去排查,想进一步完善流程,自己去带一个产线,和业务人员一样去使用,这样才能避免闭门造车~

推不动。。与研发leader会议也开过几次,说好的这样这样,但一到落地,就打回原形。😂 ,目前只能推动测试组内了。哎

重来看雨 回复

那就很难办,开发发布分支你可以做个钩子回调自动去跑用例,完了测试同事看到问题再让开发改

目前依赖测试组内同学,提测时,去跑下,有问题反馈

我说说我用的接口自动化平台。
1.先是创建项目,再创建模块,然后创建case时要去选择项目,再选择模块。。。。。啊啊啊啊啊,差评啊,这个项目和模块多的时候,一个个选择贼烦!!
2.创建case时,一个个输入框里填写post/get,url,header,params(这个有时候还n个key和value的框),慢死了,根本没有直接coding的时候爽,这样东西都是在一块的啊。后续维护的时候也是,需要一个个点开进去修改。唉贼烦
终上:于我而言,不愿意去用这样的自动化平台的直接愿意,就是编写case和维护的时候,太麻烦,一条case,要在十几个输入框里加东西,至少要花3分钟,还容易出错,写代码的花,可以直接复制粘贴,20s左右。鬼才愿意用尼。
理想的愿意用的自动化平台,是类似于swagger这种的。当然swagger只适合单个接口调用,不是个接口自动化平台。

基于接口自动化测试平台,做一个造数据的工具,这样用的人就多了。
测试过程中总要造数据吧,造数据一般就是调接口,插数据库,这样你的接口自动化测试平台的基础能力就用上了

同样待在测试开发团队3年,这些和业务脱节导致做出来的平台不大受欢迎的事情也遇到过。

我们是通过定期轮岗业务解决的。每过半年左右,和业务同学一起去参与实际业务项目的测试。一方面是拉近和业务团队的关系,另一方面也能熟悉业务,同时自己去亲身感受团队的痛点,挖掘有价值的提升点。

另外,根据痛点做出来的工具,也会先找和这个痛点有关的个项目试点,确认有效并修正一些小问题后再考虑推广。而且推广的时候也要考虑被推广团队是否合适,不强推。团队大了需求自然有差异,如果发现别的团队用不起来,先了解确认是不是不适合他们业务。

PS:
我们接口测试目前也没做成平台,而是以框架形式提供。因为整体团队都有一定的编码基础,也希望通过写脚本更熟悉 java 语言,便于去熟悉开发写出来的程序。
而基于流程自动化用例做得造数据就做成了平台。只需要增加一些接口定义的信息,就能变成造数据平台的界面。平台化更方便研发、产品使用,学习成本低且无需搭建环境。

陈恒捷 回复

😂 是的,每个团队的情况都不一样,就算一个测试部门,小的测试业务团队的情况也各有差别,有得用平台做得有声有色,有的框架用得溜溜的,有些怎么做都做不起自动化。所以很多情况下,自动化还是小团队自治这样子得。所以现在真的很想申请去业务团队亲子体验下。。。

按着我的经验,平台这个东西,对外(默认)暴露的内容越简单越好,理解成本最低,使用成本也最低
而在做平台的时候往往觉得配置越多越牛逼,越强大,但这样做完了往往反人类,再加上业务里本身有些名词理解上就有歧义,最终导致没人用
可以想一下,如果百度、谷歌在搜索框下面加一堆选项,你都选了才能搜东西,那能叫好用么

平台只是辅助嘛,没必要纠结。任何东西别人适合,自己这里不一定适合。不过近几年业界应该会对测试人员提出更高的要求了。。。应了那句,天下苦秦久矣,自己不争气,逼得外部力量介入了。

你们缺合格的产品经理和运营吧,不好用肯定大家都不用了

如果你领导推跟监控,你负责培训,执行,收集,反馈,那这个一定会成功~

自研是信仰,不要轻易尝试。

其实只要保证就算只有自己一个人用平台也用的开心,保证使用平台的测试效率比自己写代码还要高,就不亏。

不过能做好的太少了,不建议走这条信仰之路。

首先要确认创建自动化平台的目的是什么?面向哪些群体?可以解决哪些问题?
目前我的理解目的有两点:一个是系统性回归验证;二是提高测试效率
面向群体:可以面向测试、开发、产品:可用于测试验证、开发调试、产品验收等
解决问题:保证系统性稳定,发现因回归策略不严谨导致的问题;提供测试效率、间接提高开发提测质量(降低开发调试门槛)、提高产品的实际验收率(降低产品验收门槛)

系统性回归测试大多是政治任务,暂且不谈,说一下效率问题:
自动化平台将接口页面化,面向不同的用户,参数的默认值一般是没有的,参数多达10多个20个的时候,因为要多次使用,用起来就会很麻烦。
场景一:如果是一般性接口(不涉及接口签名和加密)暂无代码基础的人,测试人员在postman上大多都会整理好的接口,并保存有一套测试数据,每次请求只要改一下关心的参数即可,每次不用逐一填写。

场景二:如果是涉及到签名和加密的,因为每次签名数据不一致,这时候用postman就没有那么便捷,暂无代码基础的人这时就会使用自动化平台完成测试,但是每次(至少是首次)打开页面都要逐一填写参数,使用起来不够便捷,也不利于开发调试、产品验收;而有代码能力的人一般都会自己开发,自己维护一套测试数据,使用时也是只修改关心参数即可。

总的来说,如果用户使用自动化平台,效率没有明显提高或没有为使用者提供便利,一般使用率都不高。

我司今年也搞了一个自动化平台,因政治任务需要对部分接口添加用例,完成用例定时自动执行。因自动化平台对请求参数格式做了规定,然后为了添加用例,我需要另外写了一段代码来获取到自动化平台规定的请求格式,才能添加用例。而费时费力添加的用例也是之前在上线前不会去验证的东西,这里也不是说不该去回归验证这些功能,是考虑到自动化用例维护的投入产出比。

我理解的自动化平台设计原型,尽可能还原*原本接口的功能,如果对原接口有做封装,因尽量减少对原接口的影响,同时提供某种便利(比如可以将请求格式定义为josn、可以隐藏签名和加密、其他参数的整合关联等)。

设计可以分两块:一模块用于用户系统功能性回归,二模块用于测试过程中数据构造。
一、系统性回归测试,由相关测试人员负责添加用例,需要对测试数据做合理的拆分,数据和账号的解耦,保障同一接口的数据可以应对测试环境和生产环境的不同账号
二、测试数据构造,对接口参数设定默认值,尽可能减少不必要参数输入,传入关键/关心的参数(进行覆盖),即可进行请求,一键请求,可以方便测试验证功能、开发进行调试、产品进行验收。根据业务需求针对高频操作的业务场景再做封装(上下依赖接口一起执行)等
同时备以详细的日志,展示请求接口的真实数据和接口返回的原始响应等。

看了楼主说的这些,其实也结合自己前两年的一些工作经验感觉,如果没有部门领导的推崇,推起来确实十分费劲。原先那家公司 大家都忙于需求根本没空去你平台上一条条写,后来到了这家公司,领导的大力支持, 私下里也经常去找大家挨个去问一下 去调研痛点,其实我们在做平台的时候大部分都是自己觉得做得特别方便特别好用,但是我收到的反馈就是各种不明白不会用,包括批量导入的格式这些。其实我觉得我们老大有一句话说的特别好就是我不需要你做出来技术多么顶尖,多么炫酷的平台,只要是能解决大家实际问题的就可以。

像接口测试这种平台,本来做的目的是简化使用,提高效率,但是随着需求的增加,为了适应各种不同情况,往往会越做越复杂,有时候可能为了10的特殊情况,增加了90%的代码量和配置项,但这些配置项可能很少用到,但是做成了个巨复杂的系统,比起一般测试人员使用postman或者jemeter要复杂很多,所以人家不愿意用也情有可原。要想做好一个平台,一个优秀产品尤为重要,技术并不是成败的关键

以我的经验一个自动化测试平台的定位很重要,尤其是你需要“破局”的时候。首先,不要大而全,找准自己的定位,然后切进去,比如接口自动化平台最大的收益在于回归、监控、巡检,相比传统的coding,可维护性高、传承性好,劣势也很明显:编写用例、迁移成本高。其次,明确劣势了就要最大可能的消除这种门槛提供一种平滑的过度,要立标杆看价值。

一个平台有多NB不是功能有多么厉害多么全,而是说平台本身的包容性、无缝对接的能力能让用户真正的“爽”。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up