在小米六年的研發工程師講述：小米大樹之測試之痛

緣起

一直想寫一系列的筆記，記錄整個小米六年的研發工作中實際遇到的困難，以及這一大群人如何不可避免的走向大公司氛圍，又如何慢慢打破定勢，苦于自己拖延癥影響，現在才開始總結。

共分三個部分：基礎架構之痛、測試之痛、產品進度之痛。本篇是第二部分。

測

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://2014.54chen.com/blog/2016/08/06/mi2/