【饭谈】中台概念最近被骂的很惨,那我们测开还要不要搞测试组的中台了?

    记得大概六七年前吧,中台概念非常火,是阿里带头提出来的,而我也是那时候第一次有了想在测试组搞中台的想法,当时的中台有两种,一种是业务型中台,一种是技术型中台。

    说实话,那时候的我其实很崇拜开发圈子的中台概念。一来听起来就很帅,二来也确实能解决我们测试组很多问题。比如新人熟悉成本,比如业务算法复用,比如新测试平台的开发成本门槛等等问题。

    于是,我便策划起来了第一个测试组的中台。但是在选择做业务中台还是做技术中台上我泛起了选择困难症。

    做业务中台的原因:我当时负责打造好几种测试平台,业务上确实有麻烦的,其中最麻烦的就是用户系统,每个平台都要单独做一套注册登录忘记密码这些,烦都烦死了。其他的各种功能更不必说,轮子重复造了一遍又一遍。一有点什么更新,就要按个平台改底层代码,血压飙升。

    做技术中台的原因:还有一些例如验签算法,json格式化,在线日志,帮助引导,时间计算,定时任务,在线抓包等等比较偏技术类的,也是个麻烦事,每个新人都要到处去问,到处去抄。当然,大部分还是要来麻烦我,于是我想做技术中台也可以?

    后来我仔细想了一下,发现我们测试组内的问题相比较开发圈的问题并不突出,也没有那么多那么严重。什么意思呢?就是压根就不要考虑做什么类型的中台,直接做一个中台完事了,什么技术什么业务,都混一起吧。

    然后就开始着手做了起来,大部分功能都是用Http协议接口来传输。于是那时候确实加快了各种测试平台和工具的研发速度。毕竟在此之前,每一个测试平台都有若干个微服务、支撑服务。其中大部分都是和其他平台重复了。

    开发阶段:

    于是,一开始的中台,就是简单的把这些微服务支撑服务和各种组件直接放到了一个服务器的项目上,这个项目是django做的,没有界面纯后台。别说,这样的好处立竿见影,在中台创建了数据库,用来管理这些服务,做好日志记录,整个测试流程都瞬间上了档次。领导也是开心的很。

    但马上,问题也随之而来,那就是各个测试平台或者脚本工具的,总是有各种各样的需求发给中台,以前都是散养,责任下发,自己的问题自己解决,高度集成的测试平台,想怎么改底层服务就怎么改。现在呢,每一个都要申请发送到中台,由我来做决定怎么改。

    好改么?肯定不好改啊,每一个简单的需求,我都要考虑会不会破坏其他各个平台,必须要搞定向下兼容。那感觉就好像是你app有好多用户,你app需要不断的更新迭代版本,但是别的用户却总也不更新,永远都用着自己最初的那个版本,你app的每次迭代,就要考虑到各个旧版本,不但开发难度巨大,测试也要了命了。

    尤其是到了数据层,一旦因为谁的需求更改了表结构,那带来的后果就是毁灭性的。

    说到底,当时中台给我的感觉就是,违背了高内聚,低耦合的思想。虽然开发成本降低,但维护成本增高。

    但是已经走到了这一步,也不能摧毁中台了,虽然那时候业内已经有人开始放弃中台,贬低中台了,而且愈演愈烈。连我测试组的一些不明所以的同事都跟风开始冷嘲热讽组内的测试中台起来。

    我意识到,必须要再次进行技术改革了!

    于是,我在中台服务器上,进行了定制化的服务策略,什么意思呢?就是同样一个服务,比如说最简单的测试平台用户系统。你可以定制一些具体的字段,虽然全公司的测试平台依然用着测试中台这一套数据库用户表,但你可以定制,比如有的人要用户记录时间和状态,有的要用户的最近动作轨迹,有的要用户的头像、性别、职务这些,而有的要用户的权限分组。

    ok,我全部满足,字段只加不减。但是具体接口返回的数据都有哪些字段呢?可以定制。

    于是,我在中台搞了个页面,上面可以配置自己测试平台所需要服务的具体请求、返回字段。中台的django项目的视图逻辑层和业务层分开,更有效的处理这些五花八门的需求,要什么字段我就给你返回什么字段,没有的我就立马给你新创建可为空的新字段。有时候一个业务函数处理不了太多平台的内容,我就多写一个业务函数。有时候一个数据表搞不定,那就再新建一个表。

    于是,一个看似完美的中台诞生了,同事们可以在上面任意配置。不但减少了一开始的开发成本,后续的维护成本也降低了。

    但其实,在这个背后,是我人力在维护着,轮子仍然在重复造着...微服务也一大堆重复的部署,只不过,全都堆到中台一个服务器罢了.... 但我仍然要保持一个轻松满意的状态,毕竟要维持住中台的神奇一面。

    当时满脑子就一个想法,领导可千万别看我清闲裁员我,裁了我,可要房倒屋塌了....

    时至今日,我早已辞职三年了,全身心的投入到了培训事业里。就好像从一名海盗被招安进了七武海一样,之前的悬赏金额是....

图片

    说句实话,公司待我不薄啊,估计上面也是看到了我天天偷摸的去维护人力运维中台吧?怕我跑了可能,平时没奖金就是三万多到手,有点奖金就是五六万,有年终奖就是六位数。对于一个普通测试来说,我确实是非常幸运了。当然了,主要还是天马行空的点子。

    关于中台,我觉得,测试圈完全没必要被开发圈牵着鼻子走,不能人云亦云,人家说中台好,咱们测试组也跟着搞,人家开始骂中台了,我们测试组就要着急取消中台。

    毕竟,开发圈和测试圈本质上并不同,数量规模也差距太大,量变引起了质变,而中台的优点和缺点,在开发圈都会被放大很多,优点特别舒服,而缺点也要人老命。但是在测试圈,就没有那么大的说道,想搞就搞吧,我现在的培训学习平台里,其实就有个服务中台在,前段时间还有同学要我中台的一些算法,我都直接给了。没啥藏着掖着的。

    如果大家对测试圈的中台感兴趣,那我确实可以做一个测试圈的中台教程。当然,现在如果讲,那就一步到位:业务+算法+数据  三合一的中台哦~

    服务的平台嘛,当然不是公众号写的那俩个半简单的测试平台教程,而是培训内容的十几套测试平台。

     不过最近我欠下的课程内容比较多,公众号更新的也不太及时了,大家可以先关注,养肥再看!放心吧,这种技术,三五年内都不会过时,不用太心急了哈~ 

    你的关注和留言,点赞和分享,都对作者而言至关重要,这才是有效催更哦~ 

  • 4
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我去热饭

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值