最近才知道「中台」的概念是阿里马云最早引入的,话说一个不懂技术的引入了一个技术的概念,做技术的同学们会不会很惭愧?
言归正传,下面我说说基于「中台」概念引发我对于软件测试的一些思考。
一
有时候有些事情很奇怪,在没有人给总结成一条很简短的理论时,推行和落实起来很困难,需要给每个需要配合推进的人反复提醒,就这样也不一定能达到预期效果。
比如我们项目在推进公共库(公共库就是把经常使用到的重复的功能实现,提取成公共接口的库文件)使用时,有部分开发就很难推动,给的理由是,如果出现问题,自己维护的代码可以快速、准确、直接修改,如果找别人改,就得求着人家,不能及时有效的保证效果。
对技术人员来说,确实会这样,反正是能减少沟通的绝不愿意多说一句话(逃~~~)。
但是对测试同学来说,这样造成的问题就是,同样的逻辑,我们需要重复测试。
有些是直接拷贝的代码还好,可以简单回归,但是拷贝代码又会带来维护的问题,一旦这个公共逻辑需要更新,那么所有拷贝代码的地方都需要修改(哭~~~)。
另一些不是拷贝代码的,就得完全重新测试了,反正每个技术人员都觉得自己的代码实现是最好的呗,就好比「PHP 是世界上最好的语言」。
唉,愁死了,本来需要开发推动公共库的使用,反而成了测试人员去大力推进落实的事情了。
二
之所以说到这个,我觉得和「中台」的设立也有关系。
比如前面说的这种公共库维护,为什么会有人抱怨公共库修改还得求人?主要是公共库维护是一个附属的活,每个人抗的都是业务目标,公共库维护的再好,只会让其他开发更好的进行业务实现,但是维护者并不一定能有更好的成绩产出。
那么这时候的公共库维护真的可以说是良心活了。你愿意就用,不用拉倒,你愿意提取公共功能到公共库就提取,不提取拉倒,有人提出来可以用公共库我就用,没人提拉倒,反正也没有这个考核指标。
现在有了「中台」的概念,我理解就是应该有专人去维护这个「中台」,那么就有了专属职责和目标,就有专人负责去推进和改进中台,主动去让更多人接入,主动去提供更好的服务,主动去改进维护,嗯,确实是个好事情。
这也许也解答了我上面关于没有概念前没法推进的疑惑吧。
对测试人员来说,中台的设立就要求测试人员更多的关注接口测试了。
三
这里的接口测试,是通用接口的测试,不仅仅是单业务直接关联的接口功能的测试,还要考虑接口兼容性和接口实现的测试。
接口兼容性是指同一个接口针对不同调用者的兼容支持。
业务场景是多变的,一个标准接口吃遍天是不可能的,同一个接口适应各个不同业务是必然的,这就要求设计接口的人提前考虑兼容处理,当然,测试人员也要尽早提出合理性建议。
接口实现是指接口和业务的关联关系,我曾经不止一次听说过,单个接口测试都没问题,但是在业务场景跑通的情况下却出现各种各样的问题。
主要是因为接口在业务场景下都不是孤立的存在。
接口和接口之间都是相互调用,或者数据共用的,很多特殊场景在非生产环境是构造不出来的,就算构造也是有限的,所以测试人员要提前考虑怎么尽可能早的发现这一类的问题,而不是说接口测试就真的只是关心接口本身而已。
以上,个人理解广义上的中台就是技术上合并同类项后,集中优势资源统一处理,快速、准确、稳定的给予通用实现的最好支持,从技术角度看,这是绝对的好事。
基于中台的概念,我又发散了一下和测试人员的关系,不知道你是否有其他见解,欢迎留言和我讨论。