有赞崔玉松：借有赞测试团队出书谈谈我们的思考

这是 贝塔来信 的第 3 封信

过完年，有一天我突然收到同事的消息，说有赞测试团队准备出版一些东西，让我写个序。

当时非常意外，在此之前我完全没有听说过测试团队的同学在做这个事情，惊讶的一部分也来自于我从未写过序；虽然有赞技术博客在 2019 年输出了 100 多篇干货，但有赞技术团队之前从未出版过任何长篇的专题。

我仔细阅读了一下这本电子书，内容非常完整。我原来预期可能是一些实践分享，但是实际上里面还有很多行业中最新理论，以及基于这个理论下的有赞实践。当时一口气看了四五章，我还是挺震惊的，有赞的工作并不轻松，尤其是 2019 年团队面临很大的业务压力，系统扩容了一轮又一轮，几十轮的线上真实环境的压力测试，都是在半夜进行的。在这样背景下，测试团队还有如此高品质的内容产出，非常不容易，不得不让人感叹这些年有赞测试团队成长非常快。

今天的有赞测试团队，99.999% 都是靠团队同学自己的努力，作为一个过去为这个团队做了 0.001% 的事情的人还是挺自豪的。

有赞早期没有测试这一工种

有赞是相对比较晚才有测试团队，有赞第一行代码是 2012 年 11 月写下的，而测试团队到 2014 年下半年才开始筹建，那时候有赞技术团队已经超过五十人了，只有前端和后端两个工种。

可能今天很多人都觉得不可思议，为什么当时这么大的技术团队没有测试，按照行业常规，大约 5~8 个工程师就会配一个测试。按照道理，当时有赞技术团队应该有 5 名以上的测试了。

有赞是一家在很多方面都追求极致的公司，包括在测试这个岗位。其实一直到现在，我们在技术新人必修课上都会讲一个道理：「bug 是写出来的，不是测试弄出来的。」所以第一责任人是 coding 的人，并非是测试，当然，测试有负责检查出 bug 的责任。我们经常在内部宣传的一句话「自己的屁股自己擦。」

也正是因为这种理念，我们一开始组建有赞测试团队时，就要求招聘会写代码的测试。当时整个行业里其实还以功能测试居多。当时做出这样的选择其实是不容易的，会写代码的测试在当时在市面上很少，尤其是杭州这样的城市。当然，价格也贵，我们那是还处在创业早期，没有一毛钱收入。

有赞只招会写代码的测试

其实当时业务并不算很复杂，如果纯粹从满足业务需求角度出发（以线上不出大问题为目标），我们可以选择招聘少量的懂代码的测试（今天叫测试开发工程师），而更多的选择偏业务层的功能测试人员。之所以没有这样选择的原因是我觉得站在未来的 5~10 年的角度，纯功能测试的职业空间会很小，招聘大量的这样人过来，将来再换掉，对于这些人不太负责任，同时对于效率的提升没有帮助。我始终觉得，一个优秀的工程师是一个普通工程师效率的 10 倍，而且更具有扩展性。

事实也证明了我当时的想法：有赞测试团队组建大约一年到一年半的时间，渐渐获得了杭州技术圈子的认可。测试同学开始走出去和同行去分享有赞的测试实践和思考。

测试团队也逐步成为了有赞技术内部非常强悍的力量存在，主要表现在几个方面：

第一，在组建后的一年左右时间里就能做到梯队是最完整的；

第二，因为职业的天然优势，测试要跟很多项目、测很多业务，所以对业务和场景非常熟悉，从测试团队成长出来很多偏业务的技术负责人，甚至纯业务的负责人；

第三，因为我们坚持只招聘会写代码的测试工程师，也让很多原来由多个角色承担的事情收敛到一个角色，比如基础安全（攻防、渗透等）、早期的开发效能体系建设（CI、CD 等）、稳定性保障（全链路压测、性能分析）等。正是因为补位和角色收敛，让我们在角色专业化之前节省了大量的时间精力和金钱成本，测试团队因为他们的能力优秀，主动承担了更多的事情。

追求长期价值

类似这样的选择和思考，在有赞过去的发展史上有很多很多的案例，不仅仅是测试团队这一个。比如，最早我们在对于人的选择上；比如，我们对于入职新人的培训安排上；比如，我们对于运维体系的组建上；比如，我们对于全民服务的实施上……太多太多了，测试团队的整个发展过程是有赞在这些事情上的一个缩影。

如果把目光聚焦在当下，解决当下的问题，很多事情是不值得的，如果把眼光放到 5 年甚至更长的周期里，两三年以后就会发现过去的「投资」慢慢开始在产生「利润」了。

有赞测试团队今天能有这样产出，能在行业里有一些影响力，也正是过去的「投资」和积累。这次的测试出版内容里，几乎 100% 都是来自有赞的真实实践，里面提到了大量关于如何做的细节，甚至包括团队搭建。

可能有些人会觉得有广告的嫌疑，其实要做广告有一万种方式，每种都比写本书要轻松，如果为了广告做这个事情，那真是蠢到家了。在我看来原汁原味的还原，才是真正有用的东西，这个世界从来不缺少理论，缺的是理论背后的实践。

小平同志说：「实践是检验真理的唯一方式。」但是我觉得，实践也未必能够检验真理。毕竟真理是普适性的，而任何实践是有限的。

所以最后，我还是希望提醒所有的读者，请你一定要注意前因后果，不要照搬硬套，有赞适合的，未必适合每个团队，有赞的实践只是提供了一个思路和可能，大家还是要根据自己的业务进行适度的改良和适配。

能和这样的测试团队一起并肩战斗，是我毕生的荣幸，他们做的远比我让他们做的要多得多，是一支令人骄傲的团队。

感谢所有人对于有赞测试团队的支持，欢迎所有人对于内容提出疑问和建议，欢迎任何形式直接交流。 

崔玉松

有赞产品技术负责人

2020-3-17