谷歌是如何做測試的
在所有我被問及的問題中，最多的就是關于谷歌是如何測試的。盡管在博客中(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，linkhttp://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測試用戶、早期最終用戶之間做很多溝通交流的工作，他們會和基礎設計、功能復雜度、避免錯誤的方法等方面遇到問題的人做確認。一旦軟件測試工程師開始介入，總是會沒完沒了。
留言列表
