來源：Bill Liu
很多人應該都看過James whittaker的部落格或新書 《How Google test software》，在這裡我不想重複他的內容，而是從另外一個角度來分析對比google是如何保障它的產品質量的。
首先申明的是本人並沒有在google工作過所以沒有第一手的經驗，僅以一個旁觀者的身份來分析google的質量控制實踐。主要資訊來源於google測試部落格，在西雅圖google工作的朋友聊天和專案上合作，以及James的新書《How Google test 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 篇。
—————————————-
關注我：新浪微博：@billliu_seattle http://www.weibo.com/windowsazure 或twitter: @billliu_seattle