小米大树part2:测试之痛

痛点太多,竟无从下笔。–题记

缘起

一直想写一系列的笔记,记录整个小米六年的研发工作中实际遇到的困难,以及这一大群人如何不可避免的走向大公司氛围,又如何慢慢打破定势,苦于自己拖延症影响,现在才开始总结。

共分三个部分:基础架构之痛、测试之痛、产品进度之痛。本篇是第二部分。

2010年,来自各大公司的ABCD君,都拥有良好的软件工程习惯,测试代码行行见血。即便如此,依旧不能耽搁产品的节奏,于是开始找来专门的测试人员。

E君从事开发测试多年,测试经验丰富,开发只要给个连接服务的框架就可以开工,属于给了原子弹就能上天型。

F君则一直专注在手工测试上,产生一些稀奇古怪的操作方法来帮助找出问题。

A:“我们可以放弃单元测试,只搞好冒烟测试bvt,每日对线上和测试环境发起测试。”

E:“没问题,给我们测试时间,一定可以完成覆盖。”

然后一直时间不够,就在缺少开发测试和覆盖不全的矛盾中度过了两三年。

经常会出现一种情况,新功能上线了,忘记通知测试……或者通知了测试没有人力来写测试代码…

不测

测试工程师一直被赶着,本身招聘价位低于开发,再加上稍微能力强一点的测试工程师就想着转为开发,测试这个活就越来越没有动力了,从而矛盾开始加剧了,直到有一天,暴发。

D:“开发的屁股要自己擦!”

E:“测试只提供测试框架技术支持!”

F:“手工测试要提前预约!”

A:“MD现在真大公司!”

于是很多项目,急于上线,没有测试,这些项目都由开发打了保票,所以可以直接上线,当然了,开发也不是万能的,同时也不乏上去线就挂了的。

不能测

A:“为啥这个项目上线就挂了?”

B:“因为有个逻辑有瓶颈,线上压力一大就挂了,测试环境没压力看不出来。”

C:“为啥没考虑做压力测试?”

D:“项目太杂乱,模块太多,关系不清,很难做压力测试的环境。”

E:“给我们两个月时间搭环境,做压力测试!”

两个月过去了,压力测试环境卡在了某个基础环境上,迟迟不能解决。算了,不能测不测了。反正我们灰度上线也是一种压测办法…

就这样,度过了一天又一天。

不测

四五年后,并没有发生实质性变化。每当开发工程师回头看自己的代码时,经常会被自己吓到,真的有一种刀尖上跳舞的感觉。

一旦大家被自己吓到,想到需要测试的时候,还没开始想办法立马会被错综复杂的服务吓退。

就这样在胆颤心惊中度过一年又一年。

改变这一切的都是细节。

在上一篇( http://2014.54chen.com/blog/2016/07/29/mi/ )里提到的基础设施的改进后,模块之间服务之间抽象的很简单,只关心超时-被调用方承诺的最大服务时长,超过为不可用。

在超时确立后,压力测试变得简单,要压测一个服务,只需要将下游服务全部故意超时掉(办法有很多种,比如调度到一个不存在的地方去等超时),此时可以得到此服务的最差表现下的压力情况,这个数据完全可以供线上参考使用。

解决了压力测试的问题之后,我们延用了原来bvt的思路,依旧对服务进行最外围的功能覆盖测试,每次上线前,都依赖bvt的结果进行判断能否上线,不同在于,我们对整体服务的接入逻辑进行了分类,重要的地方提前准备用例,后期加的地方可以慢一点跟进。

一切在向好的方向变化,虽然测试资源也是时不时紧张一下。

一句话概括:测试工作不能省也不能推。测试没做好,开发占六成因素,测试占四成。


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]

捐款订阅54chen
捐赠说明

Comments