很多人應該都看過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之外，在西雅圖的另外一家公司也是互聯網產品的大哥大，特別是在在線銷售和云計算應用服務類型的產品。

　　關注我：新浪微博：@billliu_seattle 或 twitter: @billliu_seattle