來源：HuangLi@SDET
導讀：本文譯自 James Whittaker 在 Google 測試官方部落格發表的文章《How Google Tests Software 》。
在所有我被問及的問題中，最多的就是關於谷歌是如何測試的。儘管在部落格中（google testing blog）中有過零碎的解釋說明，但還是需要更多的系統闡述。雖然谷歌的技術路線在執行的過程中不斷地進化，但公司的測試策略卻從來沒有變化過。谷歌現在 是一家擁有搜尋、應用、廣告、移動、作業系統等產品的公司，我們在這些涉及到的產品領域裡發揮著非常有意義的作用。當我們涉及到一些新的領域或者在舊領域 裡快速成長的時候，必須要求我們的測試也在同步的擴張和改進。在這個系列文章中提及的測試技術，多數是我們當前正在使用的，還有一些是希望以後在不久的將 來可以用到。
首先，先介紹一下組織結構，這一部分也可能會讓你感到驚奇。其實在谷歌沒有真正的測試部門，測試依託在各個產品領域部門裡，我們稱之為“工程生產 力”（Engineering Productivity）。工程生產力部門擁有數量不等的水平或者垂直的工程學科，測試是其中的大頭。簡單地說，工程生產力部門由以下幾部分構成：
1. 一個工具產品團隊（a product team），負責內部和外部開源的促進生產力的工具開發與維護，這些工具會被公司範圍內的各種工程師使用。這些工具包括程式碼分析工具、IDE、測試用例管 理系統、自動化測試工具、Build系統、原始碼管理系統、程式碼稽核排程系統、缺陷管理系統等等。 這些工具的都是為了提高工程師效率的，並且這些工具在策略上的目標多數是為了防止問題的發生，而不是發現問題本身。
2. 一個服務團隊（a services team），給產品部門（注：這裡的產品部門團隊是和工程生產力部門平級的，例如Search、Gamil、Chrome等產品部門）提供一些專業的建 議，包括一系列工具、文件、測試、釋出管理、培訓等方面，這些專家建議涵蓋可靠性、安全、國際化等，甚至包括產品團隊面對的功能問題。所有的其他產品領域 也都會得到這樣的建議指導。
3. 嵌入式的工程師（Embedded engineers），在需要的時候被產品部門高效地“借”去使用，這些工程師有些會和產品部門的團隊坐在一起工作數年，另外一些當他們被需要的時候會被 借調到其他的產品團隊。谷歌鼓勵所有他們的工程師更換產品團隊，用以保持團隊忙綠且不斷有新面孔，並如實地不帶有任何偏見與政治。測試人員也是這樣，但是 可以有節奏地選擇更換產品團隊的頻率。我的下屬裡，有測試人員已經在Chrome團隊工作了好幾年，也有一些待了一年半後就換到了其他團隊。對於測試經理 來說，必須在團隊的產品經驗和新鮮度上做出很好的平衡。
所以這意味著測試同學向工程生產力部門的經理彙報，但是他們會把自己看成產品部門團隊的一員，像搜尋、郵箱、和Chrome部門。從組織架構上看， 測試都是兩個團隊的一部分。測試和產品團隊坐在一起，參與計劃，一起吃飯，共享獎金，享受像全職的產品團隊成員一樣的待遇。這種單獨的組織彙報關係的好處 是可以給測試人員之間提供良好的共享資訊的討論機會，好的測試思路可以很容易的在工程生產力部門內部蔓延，無論公司內的哪條產品線，都可以很快地使用這些 最好的測試技術。
測試人員的這種專案分離和彙報組織結構也有它的缺點，目前來看，最大的問題是測試人員被看做外部資源。產品部門團隊不能對測試人員有太多的依賴，他 們自己必須要合理地控制產品質量。是的，沒錯，在谷歌，是產品部門團隊對產品質量負責，而不是測試人員。每個產品部門的開發人員都需要做測試工作，測試人 員的任務是為產品部門團隊搭建自動化測試基礎設施和流程，測試人員讓開發可以自給自足地、獨立地做完成測試工作。
在這種模式下，我比較喜歡的是，開發和測試將有相同的地位。在質量方面，開發和測試成為了真正的夥伴，最大的質量重擔交給本應屬於的開發人員，開發 的職責就是正確地實現產品功能。另外這樣可以保持多對一的開發測試比率，開發人員在數量上遠超測試人員，並且測試工作做的越多，開發測試比率就會越大。產 品部門團隊也會對這樣的高開發測試比率而感到驕傲。
好，現在好像大家都是好朋友了，對吧？ 相信你已經看到這種模式的一個問題，開發人員不能很好地驅動缺陷（Bug）的運轉，開發不會測試。難道我要否認這一點麼？不管怎樣，我都不會否認，特別是 去年在GTAC talk （GTAC 2010: Turning Quality on its Head，link http://www.youtube.com/watch?v=cqwXUTjcabs） 上做了一個開發和測試對抗的遊戲後。（友情提示：測試贏了遊戲）（這裡感覺翻譯的不好，原文是： No amount of corporate kool-aid could get me to deny it, especially coming off my GTAC talk last year where I pretty much made a game of developer vs. tester (spoiler alert: the tester wins).）
在谷歌，解決這個問題的辦法是將角色再細分，我們通過設立不同的測試角色來解決這兩種不同的測試問題。在下一篇文章裡，我將詳細闡述這些測試角色和谷歌是怎樣將測試問題分成兩部分來分別解決的。
為了實現”誰的屁股誰自己擦”這句名言所說的那樣，在傳統的軟體開發人員的之上，有必要增加了幾個角色，特別是需要工程技術方面的特殊角色，這種角 色可以讓開發更高效低做測試。在谷歌，這樣角色的職責是讓其他人工作的更有效率，這樣的工程師通常會把自己當做測試人員，但他們真正的使命是提高生產力/ 生產率。他們的存在是為了讓開發人員效率提升，特別是在質量方面的提升，因為產品質量是生產率中最重要的一部分。這裡是這些角色的總結：
（譯註：“you build it, you break it”， you build it ,you break it , you fix it, 原意指在Build Lab的人永遠不會去修復build break的問題，只有開發人員自己才能修復。這裡的意思是開發人員自己要對自己寫的程式碼負責，比專職的測試人員更適合做測試工作。這裡意譯為”誰拉的 shi，誰的屁股誰自己擦”）
軟體開發工程師（SWE，Software Engineer）， 就是傳統的開發人員。軟體工程師實現一些功能程式碼並把最終產品提供給使用者使用，他們建立設計文件、設計資料結構和總體的架構搭建，他們大多數時間都在寫代 碼和評審程式碼。同時，他們也會寫很多的測試程式碼，包括測試驅動設計，單元測試，並參與後面的文章會講到的小、中、大型測試的建立工作。軟體工程師需要對他 們自己寫的程式碼、修復缺陷的程式碼、改進的程式碼，只要是他們接觸過的程式碼的質量負責。
軟體測試開發工程師（SET or Software Engineer in Test），和軟體開發工程師一樣是開發工程師，主要負責軟體的可測試性。他們參與設計評審，近距離地關注程式碼質量和風險，對程式碼做重構為了系統有更好的 可測試性，同時他們負責寫單元測試框架和自動化測試的框架。在程式碼級別上他們和軟體開發工程師是合作伙伴，但如果和增加新功能或提升效能相比較，他們更關 心產品的質量和測試覆蓋率的提升。
軟體測試工程師（Test Engineer），和軟體測試開發工程師（SET）恰恰相反，他得主要工作是做測試而不是開發。許多谷歌的軟體測試工程師會花很多的時間在寫測試程式碼 上，包括自動化指令碼、使用場景的程式碼、甚至模擬終端使用者的操作方面的程式碼。他們對軟體開發工程師和軟體測試開發工程師的測試工作做一些組織安排，解釋測試 結果、驅動測試的執行，特別是在專案即將釋出的後期將起到非常重要的作用。軟體測試工程師既是產品專家也是質量顧問更是風險分析師。
從質量的角度來看，軟體開發工程師對功能開發和質量負有全責。同時，他們還負責容錯設計、故障恢復、TDD、單元測試、和在軟體測試開發工程師的幫助下寫測試程式碼，這些測試程式碼會驗證開發的功能。
軟體測試開發工程師是提供測試支援的開發人員。他們提供一種能夠將新新增的程式碼通過模擬其依賴的方式做功能驗證的技術框架，並應用在程式碼提交之前的 提交佇列管理之中（注，這樣可以在程式碼check in 的時候保證新程式碼的功能完備）。可以這樣說，軟體測試開發工程師就是為了讓軟體工程師可以測試他們的功能程式碼，所有真正的測試都是軟體開發工程師完成的， 軟體測試開發工程師是保證這些功能有很好的可測試性，這樣可以讓軟體開發工程師很積極地參與到測試用例程式碼的編寫中去。
現在所有的一切很清楚了，軟體測試開發工程師就是服務人員，他們的主要職責就讓開發人員很方便簡單的做測試並保證模組級別的產品質量。讀者可能已經意識到一個問題，在這樣的研發流程下，使用軟體的終端使用者會怎樣？
在谷歌，軟體測試工程師的職責就是終端使用者級別的測試。如果軟體開發工程師和軟體測試開發工程師很好地做了模組級別的功能測試，下一個工作就是看許 多功能整合和資料的組合是否能夠滿足終端使用者的使用需求。軟體測試工程師在這裡就是扮演一個雙重確認開發工程師測試工作的角色，任何明顯的缺陷都會說明之 前一輪的開發自測不夠或比較草率，如果沒有出現這種情況之後，軟體測試工程師會將注意力轉移到普通使用者的使用場景測試上，保證效能、安全、國際化等方面沒 有問題。軟體測試工程師們需要做大量的測試工作，並在測試工程師、測試合同工、吃狗糧的嚐鮮者、beta測試使用者、早期終端使用者之間做很多溝通交流的工 作，他們會和基礎設計、功能複雜度、避免錯誤的方法等方面遇到問題的人做確認。一旦軟體測試工程師開始介入，總是會沒完沒了。
英文出自：googletesting