提高軟體品質實踐: google 篇

　　很多人應該都看過James whittaker的部落格或新書 《how google test software》，在這裡我不想重複他的內容，而是從另外一個角度來分析對比google是如何保障它的產品品質的。

　　首先申明的是本人並沒有在google工作過所以沒有第一手的經驗，僅以一個旁觀者的身份來分析google的品質控制實踐。主要資訊來源於google測試部落格，在西雅圖google工作的朋友聊天和項目上合作，以及James的新書<<how google tests software>>。不過旁觀者有旁觀的優勢，可以看見整個森林；相比較許多在大公司工作的工程師往往專註於一個產品或者一個團隊，只看見了一顆樹木J。不管如何，個人觀點僅供參考。

　　我們前面在微軟的品質控制實踐中談到，因為微軟大部分的產品還是以案頭型產品為主，比如windows, office,sql server等等。案頭型產品的最大特定就是產品召回或發布熱修複的成本太大，而且運行很多關鍵業務，這就迫使微軟必須在產品發布之前投入大量人力物力來充分測試產品用以保障產品的高品質。與微軟不同的是，google採用不同的策略來保證軟體品質。在理解分析google的品質策略之前，我們必須瞭解google的採取該策略的根源：

1. Google品質文化：google起源於校園。在有限的資金下，那時候創始人只能使用廉價的機器，把多個廉價的機器放在一起來提高處理能力。這些廉價的機器最大的問題是經常死機或報廢，所以google在起始階段就必須有很強的容錯能力。也就是說在系統在部分機器死機或報廢的情況下仍然可以提供服務。或者說，系統部分可以出錯但是整個系統不可以宕機 （Graceful Degradation）。Google這個從一開始因為被迫置入的高容錯能力反而成就了現在他們運行在資料中心上的服務的巨大優勢。我們知道通常硬體的出錯機率大概在萬分之一，如果有一萬台機器，其中一台出錯機率就達到百分之百。在現在的資料中心裡少則幾萬台，多者幾十萬台的機器。所以產品的容錯能力已經不是可有可無，而是必須有的功能。所以google信奉的原則是單個模組可以出錯可以有bug，它通過系統強大的容錯能力來保障系統的整體高品質。
2. 互連網產品：google是互連網公司成功的代表。互連網產品的最大特點就是“快”：產品定義快，開發快，反饋快，死掉的也快。所以為了有效利用有限的測試資源，google信奉的另外一個原則是：build the right it before you build it right.也就就是說只有確認了產品的確是使用者需要的產品(build the right it)之後才開始提高它的品質(build it right)。道理很簡單如果未知產品是否正確的情況下，沒有必要浪費資源來提高它的品質。所以google的大部分產品測試人員介入較晚，開發人員不得不自己先測試以保障基本品質。

 在理解了goolge對產品品質認識這兩個根本出發點後，就不難理解google採用什麼樣的測試策略了：

1. Dev owns quality

Google認為：誰寫的的代碼誰負責，誰開發的模組誰負責品質。所以開發在寫代碼的同時也要花很多時間測試，主要是單元測試和模組測試。Google堅信軟體品質是先天就建立出來的，而不是通過後天測試測出來的。讓開發做測試對產品品質負責不是件容易的事情，google通過主要三個途徑：一是減少測試人員數量，所以開發不得不做測試；而是通過一些活動比如test certificate program來正面影響開發做測試；最重要的第三點是通過建立強大的完善的基礎設施，使得開發很容易地寫測試自動化很容易地運行測試。

 

2. Tester is to enable developer to test effectively

這個是對傳統意義上的測試人員的職責非常大的改變。傳統意義上的測試人員的主要職責是尋找產品中的bug。既然google要求開發對品質負責，當然就不太需要傳統意義上的測試人員了。所以google中的測試更多時間是在開發測試自動化，開發測試載入器，開發基礎設施。相對花很少的時間做真正意義上的測試了。所以後來乾脆把測試部門從原來的“Test Service”改名子為“engineering productivity”。測試的主要職責是讓開發更為容易地做測試。

 但是最近兩年，隨著它的產品的日趨成熟和越來越複雜，google開始加強產品的後期測試。主要原因是雖然開發可以做很多單元和模組測試來保障模組的品質，但是很多bug是在和其它模組整合的時候才被發現。所以google把測試工程師分成兩種：一種是和開發一起負責，最要做單元測試，測試載入器等。另外一種是面向使用者的測試工程師，主要做面向使用者的整合情境測試。

 

3.Continuous Integration

這個就不用多介紹了，搞互連網或基於服務的產品的項目組，如果不使用持續整合的話有點太out了。Google的持續整合是行業的領先者，一方面有強大的測試自動化和完善的基礎設施做為保障，使得開發測試工程師不用在如何部署，如何運行，如何分析結果等等上浪費時間，而是專註於開發與測試自動化。代碼提交後會有成千上萬個測試案例自動運行，並且很快返回結果以供進一步分析之用。另一方面，google繼續最佳化現有的工具和基礎設施來進一步提過持續整合的效率。比如在做持續整合中最為頭疼的一個問題是運行那些測試案例？運行多了當然會延長已耗用時間從而降低了效率，運行少了又有漏測的風險。Google開發了一套測試案例分析工具用以分析代碼和測試案例的依賴關係。如果修改了某行代碼後，該工具決定哪些測試案例必須運行，也就是說不多不少。微軟也有類似的工具在協助測試人員決定運行測試案例的優先權，但是個人感覺效果不太好。所以我也對google的工具到底效果如何應用情況高度興趣。

另外一點就是持續整合是以自動化做為基本保障的。測試自動化不是萬能的，但是沒有測試自動化是萬萬不能的。注意的是測試自動化不僅僅解放了人，也不僅僅是為了迴歸，更為重要的一點是逼迫開發在設計的時候就考慮到如何自動化的測試該模組從而大大提高模組的可測試性（我們知道這是提高軟體品質的一個重要指標）。當然除了測試自動化外，google開發了許許多多的工具和平台來大大提高測試效率。

 

4. Measure everything

客觀上說以上幾點我都覺得沒什麼特殊之處，但是下面這個絕對讓我受益匪淺：measure everything。從最底層的硬體磁碟機，到作業系統的CPU, memory,  disk IO, 再到每個API的調用， 最後到最高層的使用者體驗，Google監控和衡量所有的這些活動。然後對監控和衡量的資料進行資料採礦和分析，從而對整個系統的運行情況了如指掌。一方面，如果有bug的話，它可以在最短的時間內發現並根據監控的資料很快找到bug的根源加以修複；另一方面根據詳細的監控資料清楚地表明哪些地方需要改進，尤其是在系統效能方面；再一方面就是瞭解使用者的使用方式和規律從而為產品功能的改進提供精確的資料和預測。Google認為： If you can’t measure your product/component, don’t build it。

 

小結，google是互連網公司成功的代表，他在互連網產品上的品質控制實踐和經驗對於廣大的互連網公司有值得借鑒意義。在產品發布速度和產品發布品質的權衡和取捨中，google選擇發布速度。在保障基本產品品質的前提下，用最快的速度把產品推到市場中，然後通過豐富的反饋渠道和工具再不斷演變。這樣即控制了使用者又保障了品質，而且也做到了對沒有使用者的產品：fail fast, fail cheap。除了google之外，在西雅圖的另外一家公司也是互連網產品的大哥大，特別是在線上銷售和雲端運算應用服務類型的產品。所以下一次和大家探討：提高軟體品質實踐――Amazon 篇。

---------------

原文： 連結

---------------