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