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

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

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

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

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

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

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

　　1. Dev owns quality

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

　　2. Tester is to enable developer to test effectively

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

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

　　3. Continuous Integration

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

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

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

　　4. Measure everything

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

　　小結(jié)

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

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

　　關(guān)注我：新浪微博：@billliu_seattle 或 twitter: @billliu_seattle

it知識(shí)庫(kù)：提高軟件質(zhì)量實(shí)踐――Google篇，轉(zhuǎn)載需保留來(lái)源！

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