这个文章主题在我自己的看板里面躺了很久了，其实并不是不想写，而是一直没有勇气来写。最近鼓起勇气，为当今测试技术的持续高温浇浇水，文章中如果有些不妥当那么请你看看一乐，切莫对号入座。
测试技术和团队、业务成熟度是相互依存不可分割的
故事: 公司内部开始推行容器平台，这对于测试来说是一个很好的技术变革。DevOps流水线的支持更容易让测试工程师掌握测试的主动权，更容易实现持续测试。当我们容器平台基本可以在测试环境投入使用的时候，团队内部一个技术负责人不知道用何种方法说服老板要进行一次故障演练，要把阿里巴巴的chaosblade在内部用起来，要实现老板一个电话，系统就可以制造一个故障然，来看看全部团队从发现故障到恢复服务的速度。这个时候整个容器平台上都没有一套可以顺利走通全套业务的一套测试环境。为了迎合老板的要求，我们加班加点完成了测试环境业务服务的部署和调试，又投入了7天的人力为故障演练做好的技术支持，最后因为技术部的自研APM无法ready而搁浅。
故事就是故事，但是故事中的问题却体现了当今很多人为了在工作中为了表现自己的独到见解而浪费了大量的公司资源做了一些过度的测试。当今测试技术发展快速，有很多传统的测试技术进步神速，比如性能测试逐渐发展到了全链路行压测，自动化测试技术发展的测试平台。除此之外还有很多新的测试技术，混沌工程、云真机平台、智能化测试等待，我相信每一个测试人看到一个新技术都想上手试一试，那种手痒心痒的感觉是每一个技术人都无法控制的。但是并不是每一个先进的测试技术都是适合你的团队的，上面的故事2就是这个问题，我们叫故障演练也好、叫军演也好，但是这么好的技术、方案并不是随时都可以用的，而是需要团队、项目、技术都到了一定的成熟的才能发挥对应的价值，太早的将这些技术投入工程制品流程中无异于拔苗助长。
任何一个团队的成熟，都会经历无序最后走向持续的过程，那么我把团队的成熟度和技术投入之间的关系做了一个粗略的总结，这也是我个人从业经历的一些总结。
每个团队都是从混乱无序开始的，这个时候环境滥用、研发技术混乱、业务不断变化，没有版本控制、没有测试流程，团队中的小伙伴都是救火队员的角色，灭火和创造任务并重。在这个阶段，任何测试技术的应用都不是必要的，也不能快速的解决问题，建立一套大家统一遵守的流程规范，解决无序的混乱状态比任何一个测试技术的投入都行之有效。
当我们建立起了内部的研发流程、测试流程、版本迭代规范等一系列的行为规范和流程后，我们就进入环境稳定、技术统一、稳定持续交付业务需求的阶段。这个时候，测试技术最应该解决的就是提高效率的问题，自动化测试可以降低回归测试工作量，已经固化下的业务逻辑越来越多，自动化测试逐渐占据了回归测试的主导地位。性能测试、兼容性测试逐渐的推广开，不断地推动业务系统的稳定和持续发展。
当我们建立起一套行之有效的测试效率解决方案的时候，我们会逐渐的迎来产研技术的普遍升级，这里包含了容器、devops的广发推广，这也为持续测试提供了前提条件，这个时候测试技术会面向稳定、高效的方向发展。全链路压测、混沌工程、云真机平台等开始大面积落地应用。
由此可见，团队、业务的成熟度是决定合适应用更对的测试技术的重要的参照物。
测试技术要站在业务之上做选取
故事:那是眼看着就快要过年前的几个星期的一个周五，突然就被拉进一个wx群。群还没来得及修改名字，里面就一顿消息刷屏。在我第一次进入群里，就看见有人再说年底集团年会会有抢购类业务需要性能测试。当我看浏览完我收到的消息后，我发现群名也修改成“XXXX年会性能测试”。既然有性能测试需求，作为质量负责人的我一定要第一时间跟紧，马上组织内部成立性能测试支持小组，并且按照群里给出的业务梳理场景，安排下赶紧找业务方获取并发量的一些输入信息。一个小时候，兄弟们都回来了每个人都懵X的说，业务说没有抢购场景。当我找到性能测试发起人一顿XXYY后，无奈对方手握上方宝剑，无力反驳。为了支持，我们还是按照所有设计业务入口Nigx最大访问量放大了一倍的方式，进行了性能测试，小伙伴们周么全部加班，周一给出了性能测试报告以及是否需要性能优化的结论。实际年会那天，全部系统超级稳定，性能如丝般顺滑，资源特没有超过20%的数值出现。
故事中无疑就是一次过度测试的典型故事，性能测试的发起人根本对业务完全不了解就擅自决定测试，测试过程中我们投入了大量的人力、物力完成了一个性能测试，最后测试完成后对实际业务并无价值。
总结
故事就是为了讲清内容，那么在当前测试技术火热的时期，测试技术本身并没有错，使用技术的人、时机却让测试技术变成了既能提质量效能也能阻碍质量效能的一把双刃剑。
