很多人應該都看過James whittaker的博客或新書 《How Google test software》，在這里我不想重復他的內容，而是從另外一個角度來分析對比Google是如何保障它的產(chǎn)品質量的。

　　首先申明的是本人并沒有在Google工作過，所以沒有第一手的經(jīng)驗，僅以一個旁觀者的身份來分析Google的質量控制實踐。主要信息來源于google測試博客，在西雅圖Google工作的朋友聊天和項目上合作，以及James的新書《How Google test software》。不過旁觀者有旁觀的優(yōu)勢，可以看見整個森林；相比較許多在大公司工作的工程師往往專注于一個產(chǎn)品或者一個團隊，只看見了一顆樹木J。不管如何，個人觀點僅供參考。

　　我們前面在微軟的質量控制實踐中談到，因為微軟大部分的產(chǎn)品還是以桌面型產(chǎn)品為主，比如Windows, Office, SQL Server等等。桌面型產(chǎn)品的最大特定就是產(chǎn)品召回或發(fā)布熱修復的成本太大，而且運行很多關鍵業(yè)務，這就迫使微軟必須在產(chǎn)品發(fā)布之前投入大量人力物力來充分測試產(chǎn)品用以保障產(chǎn)品的高質量。與微軟不同的是，google采用不同的策略來保證軟件質量。在理解分析google的質量策略之前，我們必須了解google的采取該策略的根源：

　　1、Google質量文化：Google起源于校園。在有限的資金下，那時候創(chuàng)始人只能使用廉價的機器，把多個廉價的機器放在一起來提高處理能力。這些廉價的機器最大的問題是經(jīng)常死機或報廢，所以Google在起始階段就必須有很強的容錯能力。也就是說在系統(tǒng)在部分機器死機或報廢的情況下仍然可以提供服務。

　　或者說，系統(tǒng)部分可以出錯但是整個系統(tǒng)不可以宕機 （Graceful Degradation）。Google這個從一開始因為被迫置入的高容錯能力反而成就了現(xiàn)在他們運行在數(shù)據(jù)中心上的服務的巨大優(yōu)勢。我們知道通常硬件的出錯概率大概在萬分之一，如果有一萬臺機器，其中一臺出錯概率就達到百分之百。在現(xiàn)在的數(shù)據(jù)中心里少則幾萬臺，多者幾十萬臺的機器。所以產(chǎn)品的容錯能力已經(jīng)不是可有可無，而是必須有的功能。所以Google信奉的原則是單個模塊可以出錯可以有bug，它通過系統(tǒng)強大的容錯能力來保障系統(tǒng)的整體高質量。

　　2、互聯(lián)網(wǎng)產(chǎn)品：Google是互聯(lián)網(wǎng)公司成功的代表。互聯(lián)網(wǎng)產(chǎn)品的最大特點就是“快”：產(chǎn)品定義快，開發(fā)快，反饋快，死掉的也快。所以為了有效利用有限的測試資源，Google信奉的另外一個原則是：build the right it before you build it right. 也就是說只有確認了產(chǎn)品的確是用戶需要的產(chǎn)品(build the right it)之后才開始提高它的質量(build it right)。道理很簡單，如果未知產(chǎn)品是否正確的情況下，沒有必要浪費資源來提高它的質量。所以Google的大部分產(chǎn)品測試人員介入較晚，開發(fā)人員不得不自己先測試以保障基本質量。

　　在理解了Goolge對產(chǎn)品質量認識這兩個根本出發(fā)點后，就不難理解Google采用什么樣的測試策略了：

　　1. Dev owns quality

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

　　2. Tester is to enable developer to test effectively

　　這個是對傳統(tǒng)意義上的測試人員的職責非常大的改變。傳統(tǒng)意義上的測試人員的主要職責是尋找產(chǎn)品中的bug。既然Google要求開發(fā)人員對質量負責，當然就不太需要傳統(tǒng)意義上的測試人員了。所以Google中的測試更多時間是在開發(fā)測試自動化，開發(fā)測試工具，開發(fā)基礎設施。相對花很少的時間做真正意義上的測試了。所以后來干脆把測試部門從原來的“Test Service”改名子為“engineering productivity”。測試人員的主要職責是讓開發(fā)人員更為容易地做測試。

　　但是最近兩年，隨著它的產(chǎn)品的日趨成熟和越來越復雜，Google開始加強產(chǎn)品的后期測試。主要原因是雖然開發(fā)人員可以做很多單元和模塊測試來保障模塊的質量，但是很多bug是在和其它模塊集成的時候才被發(fā)現(xiàn)。所以Google把測試工程師分成兩種：一種是和開發(fā)人員一起負責開發(fā)的，主要做單元測試，測試工具等。另外一種是面向用戶的測試工程師，主要做面向用戶的集成場景測試。

　　3. Continuous Integration

　　這個就不用多介紹了，搞互聯(lián)網(wǎng)或基于服務的產(chǎn)品的項目組，如果不使用持續(xù)集成的話有點太out了。Google的持續(xù)集成是行業(yè)的領先者，一方面有強大的測試自動化和完善的基礎設施做為保障，使得開發(fā)測試工程師不用在如何部署，如何運行，如何分析結果等等上浪費時間，而是專注于開發(fā)和測試自動化。代碼提交后會有成千上萬個測試用例自動運行，并且很快返回結果以供進一步分析之用。

　　另一方面，Google繼續(xù)優(yōu)化現(xiàn)有的工具和基礎設施來進一步提過持續(xù)集成的效率。比如在做持續(xù)集成中最為頭疼的一個問題是運行哪些測試用例？運行多了當然會延長運行時間從而降低了效率，運行少了又有漏測的風險。Google開發(fā)了一套測試用例分析工具用以分析代碼和測試用例的依賴關系。如果修改了某行代碼后，該工具決定哪些測試用例必須運行，也就是說不多不少。微軟也有類似的工具在幫助測試人員決定運行測試用例的優(yōu)先權，但是個人感覺效果不太好。所以我也對Google的工具到底效果如何、應用情況很感興趣。

　　另外一點就是持續(xù)集成是以自動化做為基本保障的。測試自動化不是萬能的，但是沒有測試自動化是萬萬不能的。注意的是測試自動化不僅僅解放了人，也不僅僅是為了回歸，更為重要的一點是逼迫開發(fā)人員在設計的時候就考慮到如何自動測試該模塊從而大大提高模塊的可測試性（我們知道這是提高軟件質量的一個重要指標）。當然除了測試自動化外，Google開發(fā)了許許多多的工具和平臺來大大提高測試效率。

　　4. Measure everything

　　客觀上說以上幾點我都覺得沒什么特殊之處，但是下面這個絕對讓我受益匪淺：measure everything。從最底層的硬件驅動器，到操作系統(tǒng)的CPU, memory, disk IO, 再到每個API的調用， 最后到最高層的用戶體驗，Google監(jiān)控和衡量所有的這些活動。然后對監(jiān)控和衡量的數(shù)據(jù)進行數(shù)據(jù)挖掘和分析，從而對整個系統(tǒng)的運行情況了如指掌。一方面，如果有bug的話，它可以在最短的時間內發(fā)現(xiàn)并根據(jù)監(jiān)控的數(shù)據(jù)很快找到bug的根源加以修復；另一方面根據(jù)詳細的監(jiān)控數(shù)據(jù)清楚地表明哪些地方需要改進，尤其是在系統(tǒng)性能方面；再一方面就是了解用戶的使用情況和規(guī)律，從而為產(chǎn)品功能的改進提供精確的數(shù)據(jù)和預測。Google認為： If you can’t measure your product/component, don’t build it。

　　小結

　　Google是互聯(lián)網(wǎng)公司成功的代表，他在互聯(lián)網(wǎng)產(chǎn)品上的質量控制實踐和經(jīng)驗對于廣大的互聯(lián)網(wǎng)公司有值得借鑒意義。在產(chǎn)品發(fā)布速度和產(chǎn)品發(fā)布質量的權衡和取舍中，Google選擇發(fā)布速度。在保障基本產(chǎn)品質量的前提下，用最快的速度把產(chǎn)品推到市場中，然后通過豐富的反饋渠道和工具再不斷演變。

　　這樣既控制了用戶又保障了質量，而且也做到了對沒有用戶的產(chǎn)品：fail fast, fail cheap。除了Google之外，在西雅圖的另外一家公司也是互聯(lián)網(wǎng)產(chǎn)品的大哥大，特別是在在線銷售和云計算應用服務類型的產(chǎn)品。

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

it知識庫：提高軟件質量實踐――Google篇，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。