小米大树part2:测试之痛
痛点太多，竟无从下笔。–题记
缘起
一直想写一系列的笔记，记录整个小米六年的研发工作中实际遇到的困难，以及这一大群人如何不可避免的走向大公司氛围，又如何慢慢打破定势，苦于自己拖延症影响，现在才开始总结。
共分三个部分：基础架构之痛、测试之痛、产品进度之痛。本篇是第二部分。
测
2010年，来自各大公司的ABCD君，都拥有良好的软件工程习惯，测试代码行行见血。即便如此，依旧不能耽搁产品的节奏，于是开始找来专门的测试人员。
E君从事开发测试多年，测试经验丰富，开发只要给个连接服务的框架就可以开工，属于给了原子弹就能上天型。
F君则一直专注在手工测试上，产生一些稀奇古怪的作方法来帮助找出问题。
A:“我们可以放弃单元测试，只搞好冒烟测试bvt，每日对线上和测试环境发起测试。”
E:“没问题，给我们测试时间，一定可以完成覆盖。”
然后一直时间不够，就在缺少开发测试和覆盖不全的矛盾中度过了两三年。
经常会出现一种情况，新功能上线了，忘记通知测试……或者通知了测试没有人力来写测试代码…
不测
测试工程师一直被赶着，本身招聘价位低于开发，再加上稍微能力强一点的测试工程师就想着转为开发，测试这个活就越来越没有动力了，从而矛盾开始加剧了，直到有一天，暴发。
D:“开发的屁股要自己擦！”
E:“测试只提供测试框架技术支持！”
F:“手工测试要提前预约！”
A:“MD现在真大公司！”
于是很多项目，急于上线，没有测试，这些项目都由开发打了保票，所以可以直接上线，当然了，开发也不是万能的，同时也不乏上去线就挂了的。
不能测
A:“为啥这个项目上线就挂了？”
B:“因为有个逻辑有瓶颈，线上压力一大就挂了，测试环境没压力看不出来。”
C:“为啥没考虑做压力测试？”
D:“项目太杂乱，模块太多，关系不清，很难做压力测试的环境。”
E:“给我们两个月时间搭环境，做压力测试！”
两个月过去了，压力测试环境卡在了某个基础环境上，迟迟不能解决。算了，不能测不测了。反正我们灰度上线也是一种压测办法…
就这样，度过了一天又一天。
不测
四五年后，并没有发生实质性变化。每当开发工程师回头看自己的代码时，经常会被自己吓到，真的有一种刀尖上跳舞的感觉。
一旦大家被自己吓到，想到需要测试的时候，还没开始想办法立马会被错综复杂的服务吓退。
就这样在胆颤心惊中度过一年又一年。
测
改变这一切的都是细节。
在上一篇( https://www.54chen.com/blog/2016/07/29/mi/ )里提到的基础设施的改进后，模块之间服务之间抽象的很简单，只关心超时-被调用方承诺的最大服务时长，超过为不可用。
在超时确立后，压力测试变得简单，要压测一个服务，只需要将下游服务全部故意超时掉（办法有很多种，比如调度到一个不存在的地方去等超时），此时可以得到此服务的最差表现下的压力情况，这个数据完全可以供线上参考使用。
解决了压力测试的问题之后，我们延用了原来bvt的思路，依旧对服务进行最外围的功能覆盖测试，每次上线前，都依赖bvt的结果进行判断能否上线，不同在于，我们对整体服务的接入逻辑进行了分类，重要的地方提前准备用例，后期加的地方可以慢一点跟进。
一切在向好的方向变化，虽然测试资源也是时不时紧张一下。
一句话概括：测试工作不能省也不能推。测试没做好，开发占六成因素，测试占四成。
原创文章如转载，请注明：转载自五四陈科学院[http://www.54chen.com]
Posted by 54chen 测试