組織架構

經(jīng)常有人問“谷歌如何測試？” 本博之前有零零碎碎的介紹，現(xiàn)在我們來做一個系統(tǒng)的介紹。 在谷歌測試策略從來沒有改變，但在戰(zhàn)術方面隨著公司也不斷發(fā)展而發(fā)展。我們現(xiàn)在有搜索，應用服務，廣告，手機，操作系統(tǒng)等業(yè)務。 這些特定領域有我們必須解決相關的問題。當我們添加新的業(yè)務或壯大現(xiàn)有的業(yè)務時，我們的測試也得到了擴大和提高。 這個系列文章記錄是我們今天所做的和在可預見的未來前進的方向。

我們從組織結構開始講起，它可能會讓你大吃一驚。 在谷歌沒有實際的測試部門。測試存在于關注區(qū)域，稱為工程效率。工程效率擁有很多縱向和橫向的工程部門，測試是其中最大的。概括地說，工程效率的組成如下：

• 產(chǎn)品團隊：開發(fā)內(nèi)部和開源工具，供公司所有工程師使用。我們建立和維護的代碼分析器，集成開發(fā)環(huán)境，測試用例管理系統(tǒng)，自動化測試工具，編譯系統(tǒng)，源代碼控制系統(tǒng)，代碼審查系統(tǒng)，bug數(shù)據(jù)庫。旨在通過工具使工程更加有效率，工具是防止錯誤戰(zhàn)略目標非常大的一部分。

• 服務團隊，為產(chǎn)品團隊提供專業(yè)知識，包括工具，文檔，測試，發(fā)布管理，培訓等等。 我們的專長包括可靠性，安全，國際化等，以及產(chǎn)品的具體功能問題。

• 嵌入工程師，進駐到谷歌產(chǎn)品團隊提供支持。有些工程師可能會伴隨同一產(chǎn)品團隊多年，有些則在最需要他們的地方周轉。谷歌鼓勵其所有工程師改變產(chǎn)品團隊以保持新鮮、忙碌和有目標。產(chǎn)品知識和新鮮事業(yè)的平衡是測試經(jīng)理必須密切關注的。

因此，這意味著測試人員要向工程效率經(jīng)理匯報，同時還要關注自己的產(chǎn)品團隊，例如搜索，Gmail或瀏覽器。 在組織上，他們是兩支球隊的一部分。他們和產(chǎn)品團隊一起，參與其規(guī)劃，與他們共進午餐，分享獎金并得到產(chǎn)品團隊正式成員對待。 該獨立報告結構的好處是，它提供了分享信息測試環(huán)境。良好的測試理念易于在工程效率的所有測試時人員中傳播，不管他們的從事什么產(chǎn)品，都獲得了公司內(nèi)最好的技術。

項目和匯報結構的分離也有其挑戰(zhàn)。迄今為止最大的是，測試人員是外部資源。產(chǎn)品團隊不能過分依賴測試，必須自己保證質量。是的，這是正確的：在谷歌的團隊把握自己的產(chǎn)品質量，而不是測試人員。每一個開發(fā)應該做自己的測試。測試人員的職責是確保他們有自動化平臺和可靠的流程，使開發(fā)可以自力更生進行測試。

我喜歡這個策略，它使開發(fā)和測試像兩只平衡的腳。它使開發(fā)和測試稱為真正的伙伴，質量應該由開發(fā)來負責。它讓我們可以開發(fā)多于測試。開發(fā)越擅長測試，人員就比測試更多。 產(chǎn)品團隊應該為一個高開發(fā)測試比例自豪！

以上內(nèi)容節(jié)選自：https://googletesting.blogspot.com/2011/01/how-google-tests-software.html

角色

為了做到“you build it, you break it”這句名言所說的那樣，有必要在傳統(tǒng)的開發(fā)人員之上再增加幾個工作角色。因為懂技術，開發(fā)人員做測試工作就更合適、更有效。在Google，我們新增的工作角色是來讓技術人員負責去提高其他人的效率。這些技術人員通常把自己看作是測試人員，但他們真正的使命是提高生產(chǎn)率。他們的存在可以使開發(fā)人員更高效，產(chǎn)品更有質量，這些都是生產(chǎn)率最重要的部分。下面是對這些角色的一些概述：

• SWE(Software Engineer)

軟件工程師是傳統(tǒng)的開發(fā)角色。SWE編寫需要提交給客戶使用的程序功能代碼。他們編寫設計文檔，設計數(shù)據(jù)結構，以及整個架構，他們主要的時間是花在開發(fā)和檢查程序代碼。SWE會寫出大量的測試程序，包括測試驅動設計，單元測試，以及我在下一部分里將會提到的整個開發(fā)工程中的小規(guī)模(small)，中等(medium)，大規(guī)模(large)的測試程序。SWE對他動過的任何程序的質量負責 —— 不論是自己開發(fā)的、還是改過bug的，或完善過的程序。

• SET(Software Engineer in Test)

測試開發(fā)工程師同樣也是開發(fā)人員，只不過他們更側重于測試相關的東西。他們審查設計，發(fā)現(xiàn)里面的代碼質量問題和風險。他們精煉代碼，讓程序更容易測試。SET編寫單元測試/自動化測試框架。他們是SWE開發(fā)的程序的共同創(chuàng)造者，但更關注于提高質量和測試覆蓋率，而不是增加新功能和提高程序性能。

• TE(Test Engineer)

TE正好和SET反過來。這個角色是以測試第一，開發(fā)放在第二。很多Google的測試工程師的大部分時間都是在寫自動化測試腳本之類的代碼，用來驅動測試用例或模擬一個用戶。他們同時也負責組織SWE和SET的測試工作，解釋測試結果和驅動測試執(zhí)行，特別是在項目開發(fā)的晚期推動產(chǎn)品正式發(fā)布的重要角色。測試工程師是產(chǎn)品專家，質量顧問，風險分析師。

從質量的角度看，軟件工程師對產(chǎn)品功能和產(chǎn)品質量負有完全獨立的職責。他們負責產(chǎn)品對錯誤的忍耐度的設計，錯誤恢復，測試驅動設計，單元測試，以及和SET開發(fā)那些用來測試這些程序的測試代碼。

測試軟件工程師是編寫測試功能的開發(fā)人員。他們提供一種框架，通過模擬器（樁、mock、fake）來模擬程序依賴，使開發(fā)出的新代碼單獨運行并測試他們的特性。負責管理代碼的提交(check-in)。換句話說，測試軟件工程師編寫編碼以便軟件工程師可以大部分的實際的測試活動都是軟件工程師執(zhí)行的，測試開發(fā)工程師只是來確保程序的各項功能都可測試，軟工實際參與測試用例的編寫。

很顯然，測試開發(fā)工程師主要是為開發(fā)人員服務的。確保每個功能的質量是他們的目標，他們使開發(fā)人員能夠容易的測試自己開發(fā)出的程序。我相信有人肯定已經(jīng)看出，在這個開發(fā)過程中，存在一個巨大的漏洞：怎么沒有用戶？

用戶測試是Google的測試工程師的工作。假設SＷＥ和SET的測試充分的話，下一步的工作就是看看這一堆的可執(zhí)行代碼和數(shù)據(jù)集成起來是否滿足用戶的需求。測試工程師在開發(fā)人員的工作基礎上做雙重檢查。任何明顯的bug的存在都會說明前期開發(fā)測試工作的不充分或者草率。當這種問題很少時，工程師會將主要精力放在軟件在用戶場景中運行時的性能效率、安全性、國際化等問題上。測試工程部要做大量的測試，并且要在工程師和簽約測試人員，目標集體測試者，crowd sourced testers，beta用戶，前期用戶之間配合測試。他們會同遇到基礎設計上、功能復雜度和錯誤避免方法上的問題的用戶進行交流。測試工程部一旦插手，事情就永遠沒個完了。

以上內(nèi)容節(jié)選自：https://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html

開發(fā)和測試融合

在Google，質量并不等于測試。我相信在任何一個地方都是如此。“質量不是被測試出來的”這句老話是再正確不過了。從汽車到軟件，如果它們起初制造的就有問題，那它們永遠都不會沒問題。試問任何一個曾經(jīng)被迫大量召回的汽車公司，掩蓋質量問題的代價有多大。

然而，事實情況并不是像這句話那樣既簡單又精確。雖然質量并不是測試出來的，但我們有同樣的證據(jù)表明，沒有測試，你不可能開發(fā)出任何有質量的東西。一個人怎么可能在沒有測試的情況下認定你的構建具有高質量？

對于這種難題，最簡單的解決辦法就是：不要分隔開發(fā)和測試。開發(fā)和測試攜手合作。編寫一點，測試一點。再編寫一點，再測試一點。更好的方法是制定測試計劃，或者你開發(fā)之前先把計劃做好。測試并不是一個獨立的工作，它是開發(fā)工作的一部分，伴隨著整個開發(fā)過程。質量不等于測試；為了質量，需要你把開發(fā)工作和測試結合到一起，攪拌它們，直到分不清你我為止。

在Google，這是我們明確的目標：把開發(fā)和測試融合，你不能單獨進行任何一項工作。做一點，測試一點。再做一點，再測試一點。關鍵就是看誰在做測試。因為在Google，專職測試人員是出奇的少，所以唯一可行的方法就是使用開發(fā)人員。還有比這些實際開發(fā)了這些程序的人員更合適做測試的嗎？還有比程序的作者更適合去發(fā)現(xiàn)bug的嗎？是誰具有更多的愿望在程序第一次寫出時避免bug？Google之所以安排這么少的專職測試人員的原因就是，開發(fā)者負責質量。事實上，堅持使用大型測試機構的團隊通常會開發(fā)出有問題的東西。測試機構龐大，這是一個信號表明編碼/測試工作的融和有問題。增加測試人員并不能解決任何問題。

這就是說相對于檢測，質量措施更多的應該是一種預防行為。質量屬于開發(fā)問題，而不是測試問題。通過把測試工作一定程度的融合到開發(fā)過程中，我們創(chuàng)建了一個漸進的流程：如果增加bug過多，可以回滾。我們不僅避免了大量的客戶方的問題，也減少了處理找回bug的測試人員的數(shù)量。在Google，測試工作的目標就是檢查這些預防工作是否在有效的運行。測試工程師一直在尋找這種作為bug創(chuàng)造者的軟件工程師和作為bug預防者的測試軟件工程師之間的聯(lián)合能達到的效果的證據(jù)，一旦這個方法出現(xiàn)問題，他們就會拉響警笛。

這種開發(fā)和測試的結合隨處可見，從代碼審查注釋上寫的“你的測試呢？”到廁所里的給開發(fā)者的最好的測試實踐方法的宣傳畫——這是我們臭名昭著的廁所測試指導方針。測試是開發(fā)工作中是必不可少的，開發(fā)和測試的聯(lián)姻是孕育質量的過程。SWE就是測試者，測試開發(fā)就是測試者，測試工程師就是測試者。

如果你的企業(yè)也有這種類型的結合，請分享出你們成功的經(jīng)驗與挑戰(zhàn)。如果沒有，那么這是一個給你的企業(yè)帶來好處的機會：在開發(fā)人員和質量之間畫上全等號。你們都聽過這樣一個老故事：小雞很高興能為一頓咸豬腿加雞蛋早餐奉獻自己的力量，可豬究竟做錯了什么？的確是 … 去對你的開發(fā)人員哼哼兩聲，看能不能得到他們哼哼回應。如果他們發(fā)出的是咯咯噠的聲音，那說明你們之間存在問題。

以上內(nèi)容節(jié)選自：https://googletesting.blogspot.com/2011/02/how-google-tests-software-part-three.html

版本管理

谷歌實現(xiàn)比許多公司更少的測試人員而達到良好的結果關鍵方法之一是，我們很少嘗試一次組裝大量的功能。事實上，目標往往正好相反，我們打造產(chǎn)品的核心并立即發(fā)給盡可能多的用戶，然后得到他們的反饋并進行迭代。Gmail就是這樣開發(fā)的，它Beta了四年。我們?nèi)サ袅薭eta的標記當我們達到了可以99.99％的處理一個真實的用戶的電子郵件數(shù)據(jù)。顯然，質量是一項正在進行的工作！

事實上為了達到測試channel，產(chǎn)品必須經(jīng)過其他一些channel，以證明它的價值。比如Chrome，我剛進goolge 2年工作的產(chǎn)品，使用了多種channel，并最大限度利用了用戶反饋。具體過程如下：

• 金絲雀Channel是用于我們懷疑是不適合發(fā)布的代碼。 就像在煤礦的金絲雀，如果它不能再生存下去，我們有工作要做。金絲雀通道適用于超寬容的實驗性用戶，而不是靠應用來完成實際工作的用戶。－類似大陸所稱的冒煙測試。

• 開發(fā)Channel是開發(fā)人員的每天都要使用。產(chǎn)品的所有工程師，把這個版本使用實際工作中。

• 測試Channel適用于內(nèi)部。

• Beta Channel或發(fā)布Channel版本是首次對外曝光。

這種爬行，走路，跑步的方式除了可以使用自動化每一輪channel外，還可以使我們有機會來更早的執(zhí)行測試和實驗應用以及收集用戶反饋。

該過程也利于分析。如果現(xiàn)場發(fā)現(xiàn)bug，測試人員可以在每個channel執(zhí)行來檢驗是否修復。

https://googletesting.blogspot.com/2011/03/how-google-tests-software-part-four.html

測試規(guī)模

Google不使用代碼，集成和系統(tǒng)測試等概念，谷歌使用了小型，中型和大型等強調(diào)范圍的概念。

• 小型測試

通常是自動化了的針對單個函數(shù)或者模塊的測試。一般由軟件工程師或者測試軟件工程師書寫，需要mocks和faked的環(huán)境。測試工程師診斷特定的故障時也可以使用到這些測試。 小型測試一般關注典型的功能問題，如數(shù)據(jù)損壞，錯誤條件等，它檢驗了代碼是否做了該做的事情。

• 中型測試

以自動化或者手工方式執(zhí)行，一般包含了2個或者多個特性以及特性間的交互。一些測試開發(fā)工程師這樣描述中型測試：測試一個功能及其最近的功能。當產(chǎn)品開發(fā)早期單個特性完成的時候，測試開發(fā)工程師驅動開發(fā)這些測試，開發(fā)工程師書寫，調(diào)試和維護測試。如果測試失敗或者終端，開發(fā)獨立處理。產(chǎn)品開發(fā)后期，測試工程師可能執(zhí)行中型測試。中型測試試圖解答：相鄰特性寫作是否正常。

• 大型測試

包括三個大型以上（通常更多）功能并且盡可能接近用戶場景。這涉及所有特性的集成，不過大型測試更傾向于結果導向，即軟件是否是用戶希望的？

小型，中型和大型的表達方式并不重要。 重要的是，谷歌測試人員都有一個共同的語言。要盡量多使用自動化，涉及到主觀判斷和隱私的，可以不自動化。

以上內(nèi)容節(jié)選自：https://googletesting.blogspot.com/2011/03/how-google-tests-software-part-five.html

SET的職業(yè)生涯

SET是測試方面的軟件工程師，他書寫測試功能。首先SET是開發(fā)，在招聘和內(nèi)部晉升資料中被我們奉為100%的編碼角色。當在招聘面試軟件測試開發(fā)工程師的時候，對于編碼的要求幾乎和對軟件開發(fā)工程師的要求是一模一樣的，而且更強調(diào)如何去測試自己寫的代碼。換句話說，軟件開發(fā)工程師和SET都需要回答編碼問題，而且SET會被問到一系列測試相關的問題。

正如你可能想到的，這是一個很難滿足的角色。SET的數(shù)量如此之少的最有可能的原因是具備所需技能的人非常難找。

通常SET不會在早期設計階段就介入。不是故意這樣做，而是和多數(shù)谷歌的產(chǎn)品是如何誕生的有關。一個常見的新產(chǎn)品誕生是已有的谷歌產(chǎn)品的員工會投入20%時間來開始新的產(chǎn)品。Gmail和Chrome OS這2個產(chǎn)品，從一個簡單的想法開始，并非正式地由谷歌授權去做的，慢慢地隨著時間的推移，越來越多的開發(fā)和測試加入進來并把產(chǎn)品發(fā)布。在這種情況下，早期的開發(fā)要關注的重心并不是質量，更關注提供一些理念，在解決了擴展性和性能的問題之后，再更多地關注質量。如果你還不能創(chuàng)建可擴展的web servic時，測試并不是你最大的問題。

你可以想象這樣一個過程，某人有了一個好主意，他開始思考并寫了一些試驗性質的代碼，從其他人那里獲取一些建議然后對這些代碼做了改進，并勸說更多的人加入，寫了越來越多的代碼，然后意識到他們做的事情很重要，通過更多的代碼把這個想法變成可以呈現(xiàn)給他人并得到反饋的模型… ?這個項目在谷歌的項目庫中就創(chuàng)建了，這個項目慢慢地轉正。

所有正式項目都有專職的測試人員么？ 默認是沒有的。小型項軟件測試開發(fā)工程師目和用戶數(shù)有限的項目一般由開發(fā)人員自試。其他的一些對個人或者企業(yè)用戶有潛在風險的項目測試才會介入。

當開發(fā)團隊尋求測試團隊參與并幫助他們時，他們有責任使測試人員相信他們的項目是令人興奮并充滿潛力的。開發(fā)總監(jiān)會給測試總監(jiān)解釋他們的項目、進度、發(fā)布計劃，一起討論測試工作如何劃分，并就開發(fā)需要滿足的單元測試水平及開發(fā)參與測試工作程度上達成一致，發(fā)布流程中開發(fā)與測試的責任也需要明確。SET在項目初期可能不會參與進來，但項目轉正后他會對運作發(fā)揮巨大的影響力。

當我說“測試”時，并不是僅僅意味著單純的檢查驗證代碼路徑。測試人員不是從開始就參與進來的，但“測試”卻至始至終都有。實際上開發(fā)上傳代碼或者之前，SET的影響力已經(jīng)顯現(xiàn)。

參考資料：

https://googletesting.blogspot.com/2011/05/how-google-tests-software-part-six.html

https://googletesting.blogspot.com/2011/04/set-career-path.html

軟件測試工程師的職業(yè)生涯

相比SWE和SET而言，軟件測試工程師(Software Test Engineer TE)是一個較新的角色，甚至這個角色本身目前還在定義完善之中。當前谷歌測試工程師們正在對未來這一角色的定義上進行 實踐嘗試中。在這里，我們講述的這個角色的定義過程，是正在進行中的，也是我們認為最適宜谷歌的。

策略上講，項目配備多少測試資源，是和項目風險、投資回報率息息相關的。如果對用戶（不管是個人還是企業(yè)用戶）的風險較大，則意味著在測試上 要投入較多的資源，需要更多的測試工程師。但投入的資源需要和其潛在的回報成正比。我們需要在合適的時間，投入合適數(shù)量的測試工程師，并得到合適的收益。

當測試工程師，進入產(chǎn)品的時候，并不需要一切重頭開始。在項目最開始的時候，開發(fā)工程師和測試開發(fā)工程師已經(jīng)在測試工程和質量方面做了大量工作。測試工程師在進入產(chǎn)品時，需要考慮以下一些問題：

• 當前軟件的薄弱點在哪里？
• 從安全、隱私、性能、穩(wěn)定性這幾個角度出發(fā)都關注哪些內(nèi)容？
• 對于主流用戶來說，是否可以滿足他們的預期？對于全球所有的用戶也是這樣么？
• 這個產(chǎn)品是否需要和其他產(chǎn)品交互（軟件和硬件上）？
• 當發(fā)生問題的時候，診斷工具是否很好地使用？

上面所有問題，都會被當做軟件發(fā)布過程中的風險進行討論。測試工程師并不需要自己去解決所有這些問題，但必須保證這些問題被解決掉，這就需要去評估 其他人的工作來看還有多少工作需要去做。其實，測試工程師之所以被雇傭，就是為了保護軟件的最終個人企業(yè)用戶的利益，使之不受糟糕的設計、令人疑惑的用戶交互界面、功能缺陷、安全和隱私等問題帶來的不良影響。在谷歌，測試工程師是團隊中唯一全職對整體產(chǎn)品弱點關注的角色。和SET相比， TE的工作并不是那么清晰和一致。測試工程師會被要求在項目的各個階段都提供援助，無論產(chǎn)品是一個想法的時候，還是產(chǎn)品已經(jīng)到了第八個版本，甚至需要為一些已經(jīng)過時封存已久的項目提供支持。有些測試工程師，比如在安全的，通常會同時負責多個項目。

顯然，不同項目中的測試工程師的工作內(nèi)容也會不同。一些TE像SET一樣編碼為主，但更多關注端對端的用戶使用場景。其他TE利用已有的代碼和設計來驗證失敗的場景。TE必須對測試計劃及測試完成做系統(tǒng)全面的考慮， 特別是在真實使用方式和系統(tǒng)體驗上。在需求不明確的情況下，測試工程師善于對一些說不清的問題上做原因分析和溝通處理。

考慮到測試工程師需要的技術技能、領導力、對產(chǎn)品的深厚理解力等多方面要求，其職位描述會是令人恐懼的，如果沒有正確的指導，這個角色會很難去做。 幸運的是，在谷歌，一個由測試工程師們組成的強大社區(qū)的出現(xiàn)解決了這個問題。在所有的工作角色中，測試工程師可能是最好可以相互提供幫助的角色，這個角色需要敏銳的洞察力和領導力，因此谷歌的許多高級測試經(jīng)理從測試工程師起步的。

測試工程師的工作經(jīng)常需要去打破常規(guī)。在任何時刻，一旦測試工程師進入項目，他就需要去評估項目、代碼、設計、用戶的當前狀態(tài)，并決定當前需要去首 先關注些什么。如果進入項目的時候，項目剛剛開始，這個時候測試計劃會是第一優(yōu)先級要解決的問題。有些時候測試在產(chǎn)品的晚期才進入，這個時候需要去評估這 個項目是否已久為產(chǎn)品發(fā)布做好了準備，或者在“beta”版本發(fā)布之前還需要解決哪些主要的問題。如果測試工程師進入了一個新的產(chǎn)品，或者他對這樣產(chǎn)品中 有較少經(jīng)驗的時候，通常情況下會先去做一些不需要測試計劃的探索性測試工作。在另外一些時候，項目已經(jīng)很久沒有發(fā)布了，只是需要去做一些修飾或者安全方面 的修復，或者用戶交互方面的更新，這需要測試工程師針對不同階段的項目使用不同的方法。谷歌的測試工程師需要在不同的項目做不同的事情，并且他們很少做相同的事情。

參考資料：https://googletesting.blogspot.com/2011/05/how-google-tests-software-part-seven.html

后記

谷歌的測試方式成為業(yè)界的標桿之一，上述文章很受歡迎。為此谷歌相關測試人員后面整理了一本書：

How Google Tests Software - 2012.pdf

參考資料

• 討論 釘釘群21745728 qq群144081101 567351477
• 本文最新版本地址
• Google軟件測試之道 書籍下載
• 本文源碼地址
• 本文涉及的python測試開發(fā)庫 謝謝點贊！
• 本文相關海量書籍下載