Google質(zhì)量保證體系

1、大家都知道，公司運作情況首先要看員工素質(zhì)。在 很多人印象當中，Google很多高管都是怪人，是一家 技術(shù)驅(qū)動的公司，每創(chuàng)造一個技術(shù)點帶來的PV提升都可能帶來現(xiàn)金。google走精英化路線，從微博可以看到，經(jīng)常有 業(yè)界大牛加盟。招應屆生的時候，喜歡招名校頂尖學 生。雖然這個公司工程師達到6000多，但是它能夠保 持一個很好的效率，通過項目來運作，十來個人或者 幾個人做一個項目，這種方式保持一種“小公司”氛 圍。工作分配是“ 80/20”原則，忙完工作之余，有 20%的時間是可自由支配的，做你喜歡做的事情?，F(xiàn) 實沒有那么美好，因為工作往往飽和的，加班也不少。整個組織里面，研發(fā)跟測試比例是 10:

2、1,大家 可能吃驚，會覺得我們這邊 QA這邊加班很多了，他 們這么高比例的時候還能運轉(zhuǎn)很好呢？事實上Google里面大概有50%項目不用測試人員 測試，而是開發(fā)人員去保證質(zhì)量。google內(nèi)部經(jīng)常開 產(chǎn)品推廣會鼓勵用Google產(chǎn)品。產(chǎn)品推廣會經(jīng)常安排 在星期五，中午吃飯的大家邊吃飯邊聽。網(wǎng)站經(jīng)常會 看到Beta版本，通過快速發(fā)布快速修復也降低測試強度。各位將來過幾年可能也會做到主管，對人的重要 性理解會更深一點。google招聘特點，第一是只招聰 明人，第二是精英化路線，第三輕技能重技術(shù)，看中 能力勝于經(jīng)驗。第三點很顯著，很多在社會上打拼很 多年的人進不了 Google,但是有可能一個毛頭小

3、伙子 可以進Google。google很看中數(shù)理基礎(chǔ)，很喜歡找業(yè)界名人去做 技術(shù)布道，還有招聘頂尖應屆生，從這些角度印證招 聰明人的哲學。Google員工有幾個核心能力，第一個是數(shù)理邏輯, 要求每個人有很好的邏輯思維能力，第二強的開發(fā)能 九第三和 Google文化匹配度高，稱 Googly”， google首頁文章有Google文化詳細介紹。并不是只有阿里巴巴強調(diào)文化，強調(diào)做事各方面 習慣匹配度，Google其實也很關(guān)注這一塊。大量聰 明人存在，整個組織好運作機制都是高度自我驅(qū)動的， 因此它的管理成本比較低。在中國應聘的話，很有可能被美國工程師面試的。 Google招測試需要經(jīng)過研發(fā)工程師面試

4、，招研發(fā)也會 讓Google測試經(jīng)理幫面，所以說進去Google的同學, 不僅僅coding能力強，測試能力也是可以的，因為他 數(shù)理能力強，做測試也不遜色的。再看看Google里面的角色，Google里面有PM, 這跟阿里的PM不太一樣，有點類似于阿里的PD。工 程師沒有嚴格區(qū)分研發(fā)或者測試，工程師包括testlead開發(fā)、以及測試、專業(yè)安全測試團隊等等。UED團隊包括WEB靜態(tài)頁面開發(fā)、交互設計師、 用戶體驗。管理者其實跟我們 B2B還不太一樣，管理 者本身是技術(shù)能力很強的人，他的下屬碰到問題，他 能夠幫忙解決。另外管理跟搞技術(shù)的人比例大概是 1: 10左右。Google沒有項目管理、SQA

5、、SCM、RA。大家可 能比較詫異，這些角色由誰擔當了，事實上這些角色 都是由小團隊里面做項目的人，每個人都分擔一點， 就分掉了。我們再細看一下常見的那幾種角色職責。軟件工 程師主要是創(chuàng)建產(chǎn)品，保證質(zhì)量，寫測試代碼?？梢?看到作為研發(fā)工程師，強調(diào)寫測試代碼的。測試工程 師有幾塊職責，第一個是支持研發(fā)，做一些測試咨詢， 第二是給研發(fā)提供一些基礎(chǔ)工具或者框架。可靠性方 面的工程師，保證整個系統(tǒng)在運作。Google中國區(qū)測試有十多個正式員工，還有十 多個外包，分工側(cè)重不同。正式員工，他們基本上不做手工測試的。外包做手工測試以及部分 UI自動化, 非常明確。外包在一進入google便被告知他們沒有機

6、會成為正式員工。不像阿里，在阿里努力一下，還是 有機會成為正式員工。像Google中國測試也接了很多大型項目測試任 務，因為他們蠻希望跟google主流接軌。測試會開發(fā) 測試框架以及搭建測試系統(tǒng)，做性能測試，深入到項 目里面挖掘一些可以重構(gòu)的點，讓整個測試系統(tǒng)變得 更好，更方便測試。跟傳統(tǒng)測試很不一樣，需要能夠 深入代碼，找到能夠幫測試系統(tǒng)運作更好的做法。他們都是一幫非常喜歡測試驅(qū)動的狂熱愛好者。測試工程師在項目里面的角色分幾塊：第一塊，測試顧問，能夠指導研發(fā)怎么樣寫好代 碼,怎么樣做好code view,你要比普通開發(fā)更清楚 質(zhì)量保證是怎么回事。第二點，是一個測試方面的軟件工程師，要求能 夠

7、寫代碼，支持研發(fā)做一些事情，能夠?qū)懸恍┗A(chǔ)測 試框架。比如我們做某個項目，可能很多研發(fā)用到的 測試工具、方法是由測試工程師來寫的，提供給研發(fā) 用。另外說一下Google里面的晉升。目前晉升由“晉升委員會”決定，晉升委員會有一票否決權(quán)，晉升有兩種途徑，一種是自己寫簡歷給 委員會，第二個是你的經(jīng)理推薦。像晉升不是說你簡單寫寫文字就行了，委員會會 從內(nèi)部系統(tǒng)拿很多數(shù)據(jù)，包括你做過的項目、寫過的 代碼、寫的文檔，也需要跟你合作的人給評價。導致他 們內(nèi)部工程師非常喜歡用內(nèi)部系統(tǒng)，很簡單，你不用 內(nèi)部系統(tǒng)，很多業(yè)績數(shù)據(jù)是看不到的，沒有說服力。 Google里面直接老板對你的晉升影響比較小。在淘寶晉升機制與

8、google有些類似。淘寶有委員會, 高P當委員會成員，晉升還是蠻看能力的，因為會提 很多問題。Google嚴格來說沒有開發(fā)流程，合適的就拿過 來用，總體來看比較偏敏捷，整個項目不一定要有測 試工程師，50%沒有測試工程師。項目本身是自行組 建，有一個idea,誘惑很多人跟你一起做就可以，在 整個項目里面，研發(fā)跟測試邊界非常模糊，測試如果 有能力的話，也會寫很多產(chǎn)品代碼，他們工作平臺這 兩年全部不用windows 了。代碼機制方面，有一個明確的產(chǎn)品 owner,每次 有代碼commit進去的話，產(chǎn)品owner把代碼每一行都 coding view過。Google有編程規(guī)范，coding vie

9、w必須確保兩個以上， coding view有內(nèi)部工具支持。google應用主干開發(fā)，為什么要主干開發(fā)，就是 為了方便持續(xù)集成，如果有沖突，立馬能夠檢測到。 主干開發(fā)有一個好處，能夠盡早的、非常頻繁的提交 代碼。少量分支開發(fā)應用在緊急發(fā)布，及 bug fixed。令人驚訝的是Google這么大一個公司，只有一個 代碼中心，對于Google內(nèi)部員工來說都是可見的，你 要是對哪塊代碼感興趣，都可以看，你覺得有疑問， 有什么BUG要修，也可以 commit, commit完之后， 有人 coding view。測試之前應了解這個被測試系統(tǒng)的系統(tǒng)架構(gòu)及業(yè) 務架構(gòu)。Google很多技術(shù)都是非常有傳奇色彩

10、的，發(fā) 明的一些技術(shù)，比如 GFS, Map-Reduce很多技術(shù)思 想都被其他公司拿過去用。他們比較牛逼的地方還有 數(shù)據(jù)中心管理。開發(fā)平臺基于 LINUX平臺，用的編程語言為 C/C+、JAVA、python,每個領(lǐng)域都會有很頂尖的人。 LINUX OS做很多定制。JAVA領(lǐng)域有一個很厲害的 老頭也在 Google,python創(chuàng)始人在google。多個角度 印證Google非常重視技術(shù)的。Google內(nèi)部有專門的項目管理工具，叫做 P系 統(tǒng)，這個P系統(tǒng)比b2b的AONE簡單多，它只是簡 單的做一些項目管理，沒有什么流程，和代碼管理工 具preforce是打通的，可以非常容易的拿到文檔和代

11、碼。google晉升從P系統(tǒng)里面拿數(shù)據(jù)，有利益驅(qū)動讓 大家喜歡用P系統(tǒng)。沒有什么統(tǒng)一的需求管理平臺，寫文檔也很簡單, 寫文檔也不是分角色寫的，在項目里面有必要就寫， 這些文檔都是經(jīng)過非常充分的討論。有專門的代碼管 理，工具叫perforce,是Google內(nèi)部少有的商業(yè)工具， Google大部分工具都是自產(chǎn)自銷的，以及用了很多開 源軟件Rietveld這個code review工具非常好用,web上 可看到兩個版本之間的變更，也可以從上面直接添加 注釋。接下來介紹Google的測試策略。第一非常強調(diào)可測性，最近兩屆Google軟件測試 大會，主題都是圍繞“自動化、可測性” ,GTAC是 Goo

12、gle組織的測試大會，邀請業(yè)界名人分享?？梢钥?一下Google的東西，了解未來幾年發(fā)展方向。第二關(guān)注代碼跟BUG之間的關(guān)聯(lián)關(guān)系。第三點是測試工具方面優(yōu)先用開源的，其次開發(fā) 很多內(nèi)部工具。只有極少數(shù)商業(yè)工具，如perforce。第四點是他們內(nèi)部性能測試技術(shù)非常成熟，只要把腳本放放在云端上，告訴它要做的性能測試，隨后 云端就把整個性能測試結(jié)果跑出來了。第五點，測試運行是依賴測試代碼的。只有運行 的比較快的測試代碼才會放到平臺里面去，運行很慢 的話，盡可能不放到集成平臺。第六點是手工測試、瀏覽器測試都是由外包執(zhí)行， 項目是不是要測試，是靠協(xié)商的，并沒有所謂流程。Google測試的內(nèi)部形態(tài)，它分為大

13、、中、小三個 力度，所謂“小”是在單元顆粒里面，測試往往用xunit, 中等規(guī)模測試屬于幾個小模塊交互，也是用xunit 一套 工具。系統(tǒng)集成的用 xunit+selenium, selenium是web ui自動化框架。再細看一下所謂大中小還有什么不一樣的地方， 越小的，隔離程度越好，找問題非常容易，大的話， 定位問題難度大很多。大的形態(tài)更看重端對端測試、 關(guān)注系統(tǒng)級別行為以及跟外部交互行為。還有自動化 測試運行時間，對于一些小的測試級能夠在幾分鐘運 彳了完，對于中等規(guī)模的，放到集成平臺里面去；對于可 能要運行好幾天規(guī)模的自動化測試是按需執(zhí)行。B2B測試代碼，還沒有嚴格區(qū)分大中小。實踐當中靜

14、態(tài)檢查，作用并不是非常顯著， 靜態(tài) 檢查工具多局限在記語法、寫法方面的問題。據(jù)infoq 報道,Google工程師findbugs,能夠找到七千多個BUG, 其中有75%需要修復。C+是用Cpplint做靜態(tài)檢查。 B2B這邊很多JAVA 工程師findbugs, C+是用 cppcheck再說一下功能自動化測試，C+單元級別他們有 Gtest框架，gmock框架,內(nèi)存檢測方面是用 valgrind。 Google內(nèi)部很多測試工具是沒有界面的，Google工程 師覺得點圖形界面太麻煩，更喜歡用腳本表達，這跟 我們工程師不一樣，阿里系同學很喜歡造一些圖形化 界面，降低使用難度。java 單元級另

15、U是用 junit, jmock、 easymock mockito. Mock應用場合包括，解除外部系統(tǒng)依賴，提 高它的運行速度，減少測試環(huán)境等。web UI 自動化是用 web driver 或者 selenium? 我們B2B用pwaitroselenium開發(fā)者目前也是在 Google 的，有兩到三個人維護這套東西。Google內(nèi)部性能測試非常成熟，真正最難的是背 后運作的分布式系統(tǒng)。工具層面有Google performance tools,它能夠生成很多圖片，可以看得 到某一些方法調(diào)用時間、調(diào)用次數(shù)。系統(tǒng)級別性能測試用jmeter的，b2b是慢慢把 loadrunner趕下歷史舞臺

16、。前端性能工具 pagespeed 和雅虎yslow很像，可看到頁面渲染時間以及是否符 合一些標準規(guī)范。性能數(shù)據(jù)中心是Google性能測試方面的精華所 在，將整個性能測試數(shù)據(jù)存放到中央數(shù)據(jù)庫，這個數(shù) 據(jù)庫包含了文件的安裝環(huán)境等等。你只要把腳本做好， 告訴它要做性能測試，過一會兒，性能測試執(zhí)行會把 性能結(jié)果數(shù)據(jù)存到中央數(shù)據(jù)庫，性能測試報告直接給 你了，這是它的神奇所在。Google內(nèi)部審計工具，叫 ratproxy。會做一些 fuzzing測試，隨機發(fā)起請求給服務器，如果有錯誤或 崩潰，能被fuzzing系統(tǒng)捕捉到。還有一個工具叫 Lemon,從動態(tài)和靜態(tài)來做測試 的.目前B2B也很少做fuzz

17、ing測試.我們說代碼可測性，確實不是很好度量。Testablity explorer這個工具，看起來界面很漂亮，但是功能非常 弱的，根據(jù)顏色不同，能標識出這個程序代碼是好的 還是優(yōu)秀的。你可以拿這個可測性結(jié)果做一個基準， 以后代碼可測性不能比以前的差，做一個趨勢跟蹤。代碼覆蓋率方面，Google也是用開源工具，是集成 到框架里面去，另外他們也沒有約定項目需要什么樣 的覆蓋率。研發(fā)、測試，角色是沒有嚴格區(qū)分的。沒有所謂的提測標準，跟B2B也不一樣。Google BUG管理系統(tǒng)，沒有開源，BUG作為 需求來源之一，內(nèi)部非常重視BUG,而針對這個BUG, 衍生出很多需求。他們填BUG的時候，需要能

18、將BUG ID以及變更列表填進去，想做到代碼跟 BUG之間的 關(guān)聯(lián)，作為這個代碼質(zhì)量指標。其實我們也是可以嘗 試做起來的，如果說代碼 BUG很多，那這塊代碼風 險度是比較高的。持續(xù)集成系統(tǒng)也不開源，里面有很多數(shù)據(jù)，有紅的、 綠的指示器。有一個比較有趣的事情，如果項目失敗 的話變紅燈，如果這個區(qū)域的燈亮，嗡嗡叫的話，那 就說明出問題了。為什么這么干？比較符合人類心理 學，因為我想沒有誰希望整天頭上的燈亮著。內(nèi)部測試系統(tǒng)非常龐大的，簡單說一組數(shù)據(jù)， 每天都有65k的build,每年有20兆的build,基于code bas防面有 120k test suite每天有運行 7.5 M test suite 然后1400個持續(xù)集成，這個數(shù)據(jù)還是幾年前的數(shù)據(jù)， 現(xiàn)在還在上升趨勢。B2B目前沒有統(tǒng)計過這方面數(shù)據(jù)， 很多團隊用hudsono再說一下發(fā)布，大家看到Google產(chǎn)品頁面上很多 都是beta版本的，為什么它可以寫beta版本，阿里巴 巴不可以，因為我們是收費的，別人不是收費的，它的發(fā)布過程是由項目自行組織的，他不大可能找一個 人做SCM的工作，每次build都是主干取代碼。他們這邊發(fā)布完之后，是所有產(chǎn)品立馬讓全球都 看到，而是少部分人先看到，然后根據(jù)少部分人反饋 再來改進產(chǎn)品，