Google上海如何測試搜索產品

　　James Whittaker在Google Testing Blog上連載了How Google Tests Software，How Google Tests Software，James 是前Google西雅圖的技術總監(目前回到微軟工作)，主要參與Gmail、Chrome和內部工具特別是測試工具開發等產品，不過Google如何測試這個題目太大了，Google除了常規的產品，每年還會新立項很多產品同時也殺死很多產品，每個產品的團隊會根據自身情況制定有針對性的測試策略。

　　本文我們來談談Google上海是怎么測試搜索產品的?？赡芎芏嗳私洺Ｊ褂玫氖荊oogle的網頁搜索，但在Google首頁的Onegoogle bar上還提供了很多搜索的子頻道，例如圖片搜索、地圖搜索、資訊搜索、視頻搜索等，見下圖。以下介紹的就是這些子頻道的測試。

　　一、人員結構

　　從上圖我們可以看出搜索產品團隊是一個扁平化的組織

　　工程師經理：負責多個項目/產品(一般2個)的預算管理，工程師人員管理，Team Building

　　產品經理：負責多個項目/產品(一般2個)，產品特性定義設計和確定發展方向，競爭對手產品分析，主導產品創新討論，確定新功能發布優先級

　　技術組長：制定和跟蹤項目進度表，統籌開發人員

　　開發人員：設計開發文檔，開發功能，單元測試，code review，提交發布

　　測試人員：建立產品質量流程，設計自動化測試框架，推動開發人員對質量的認知度，提高開發測試覆蓋率

　　UX：可選，在某些功能上提供用戶體驗分析，前臺UI設計

　　基本上每個搜索子頻道都是這個結構，不到10人的團隊，充分發揮每個成員的主動性，積極的溝通，產品經理引領產品走向，每個成員通過頭腦風暴提供創意排好優先級來實現自己的想法。

　　OKRs

　　Objectives and Key Results的簡稱，Google特有的考核指標，分為Team的OKR和個人的OKR。每個季度，各個產品團隊會根據自身產品的需求設定目標，是一個結果導向的考核。制定出團隊的OKR后，團隊成員根據它制定自己的OKR，指標是需要能具體量化或實際看到成果的，同時分享給團隊成員讓其他人知道你的目標和這個季度想要做的事情，季度結束時根據結果打分。具體可以參考這篇文章，OKR的解說

　　二、環境

　　已經上線運行的搜索產品一般會有以下四種環境，每個環境都會加入測試過程。

　　Local Demo

　　當開發人員開發好某個新功能，會在他本機起一個本地的服務用來做前期的驗證，測試人員也可以通過這個demo看到初步的設計，為編寫測試計劃和測試用例做準備，形成初步的測試大綱或測試要點，同時可以提前和開發溝通，了解他是如何設計這個功能塊，使用哪些技術評估風險，代碼可測試性如何，單元測試覆蓋率是否達到一定程度。在這個階段，開發人員會在Buganizer(bugzilla/' target='_blank'>Bugzilla二次開發版，google內部使用的bug管理工具)為他開發的這個新功能建一個Hotlist，測試人員和開發人員將bug、feature request、improvement等提交進去便于跟蹤。測試人員和開發人員在這個環節會有很多OneOne溝通(Google talk、Gmail、面對面)，需要發揮測試的主動性，特別是需求的理解，雙方要達成共識，有異議的地方提交給產品經理來確認。

　　Dev Env(corp)

　　這是整個開發團隊的環境，所有開發提交的功能會部署到這個環境中，測試人員可以在上面做集成測試，發現的任何問題，包括用戶體驗，需求改進都要提交到Bug庫中，重大的問題可以放到周會上來討論，這個階段Tech leader會起主導作用。

　　Test Env/RC(borg)

　　正式的測試環境，搜索產品的發布周期現在各個子產品基本都達到了一周一發布的頻率，Google有一個borg環境，由成千上萬的服務器組成，各個產品申請獲得某臺服務器，之后這個產品的測試環境就部署在這臺borg機器上，團隊的每個工程師輪流來擔任發布工程師，在每周的某一天先做代碼凍結，之后發布產品，當這個版本通過sanity check/smoke test，就可以通知測試人員來做正式的新功能測試和回歸測試。

　　Production

　　搜索產品自身不產生內容的特點，在之前的環境，數據和生產環境上是一致的，但是生產環境上有成千上萬臺服務器，為了避免環境差異的問題，需要 Testing in Production，當每周RC測試通過且sign off后，測試人員需要到生產環境上跑一圈(go through)，看看是否有遺漏的嚴重問題，如果有，及時的回滾到上一版本，這個版本廢棄同時研究為什么會有嚴重問題遺漏，記錄下來防止今后再出現類似問題，如果沒有，。

　　DogFood

　　"吃狗食"，產品做大改版或一個新立項的產品經常會有這個環境，一般是個相對穩定的版本，用途是在內部推廣，產品經理會邀請其他團隊人員來使用并提供反饋，內部員工就是第一批用戶。如果公司內部不認可，發布的幾率會大大降低，因此，整個團隊很關注這個版本。

　　Experiment

　　試驗功能版，互聯網的特點決定了需要不斷的試錯，很多創意在內部通過后會采用這種方式發布。根據不同地理位置不同IP不同平臺不同瀏覽器等等，選取一些特殊的用戶來試用，產品經理收集反饋后在周會上整個團隊來評估這個試驗效果是否可以全部推廣。

　　三、測試

　　在講測試內容之前先談下測試人資源，哪些人來做測試，從第一部分的人員結構圖可以看到產品團隊的全職測試人員一般只有一個，即使算上全球版和本地版 (Global和Local，常用Google搜索的應該會知道搜索除了google.com還會有各個國家的版本，比如CN/HK/TW)也不會超過3 個人，所以測試人員需要盡早測試，同時測試需要推動開發測試、培養開發的質量意識，讓開發也承擔一部分測試任務，所以外面都說Google的開發和測試比例是10:1，而我覺得確切的說應該是10:11，開發和產品經理也參與了很多測試工作，全員測試，全員對質量負有責任。

原文轉自：http://www.kjueaiud.com