谷歌如何測試軟體1Google軟體測試介紹

測試技術 · 發表 2018-10-09 23:14:50

摘要：組織架構經常有人問“谷歌如何測試？” 本博之前有零零碎碎的介紹，現在我們來做一個系統的介紹。在谷歌測試策略從來沒有改變，但在戰術方面隨著公司也不斷髮展而發展。我們現在有搜尋，應用服務，廣告，手機，作業系統等業務。這些特定領域有我們必須解決相關的問題。當我們新增新的業務或壯大現...

組織架構

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

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

產品團隊：開發內部和開源工具，供公司所有工程師使用。我們建立和維護的程式碼分析器，整合開發環境，測試用例管理系統，自動化測試工具，編譯系統，原始碼控制系統，程式碼審查系統，bug資料庫。旨在通過工具使工程更加有效率，工具是防止錯誤戰略目標非常大的一部分。
服務團隊，為產品團隊提供專業知識，包括工具，文件，測試，釋出管理，培訓等等。我們的專長包括可靠性，安全，國際化等，以及產品的具體功能問題。
嵌入工程師，進駐到谷歌產品團隊提供支援。有些工程師可能會伴隨同一產品團隊多年，有些則在最需要他們的地方週轉。谷歌鼓勵其所有工程師改變產品團隊以保持新鮮、忙碌和有目標。產品知識和新鮮事業的平衡是測試經理必須密切關注的。

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

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

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

以上內容節選自：ofollow,noindex">https://googletesting.blogspot.com/2011/01/how-google-tests-software.html

角色

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

SWE(Software Engineer)

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

SET(Software Engineer in Test)

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

TE(Test Engineer)

TE正好和SET反過來。這個角色是以測試第一，開發放在第二。很多Google的測試工程師的大部分時間都是在寫自動化測試指令碼之類的程式碼，用來驅動測試用例或模擬一個使用者。他們同時也負責組織SWE和SET的測試工作，解釋測試結果和驅動測試執行，特別是在專案開發的晚期推動產品正式釋出的重要角色。測試工程師是產品專家，質量顧問，風險分析師。

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

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

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

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

以上內容節選自：https://googletesting.blogspot.com/2011/02/how-google-tests-software-part-two.html## 開發和測試融合

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

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

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

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

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

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

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

以上內容節選自：https://googletesting.blogspot.com/2011/02/how-google-tests-software-part-three.html

版本管理

谷歌實現比許多公司更少的測試人員而達到良好的結果關鍵方法之一是，我們很少嘗試一次組裝大量的功能。事實上，目標往往正好相反，我們打造產品的核心並立即發給儘可能多的使用者，然後得到他們的反饋並進行迭代。Gmail就是這樣開發的，它Beta了四年。我們去掉了beta的標記當我們達到了可以99.99％的處理一個真實的使用者的電子郵件資料。顯然，質量是一項正在進行的工作！

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

金絲雀Channel是用於我們懷疑是不適合釋出的程式碼。就像在煤礦的金絲雀，如果它不能再生存下去，我們有工作要做。金絲雀通道適用於超寬容的實驗性使用者，而不是靠應用來完成實際工作的使用者。－類似大陸所稱的冒煙測試。
開發Channel是開發人員的每天都要使用。產品的所有工程師，把這個版本使用實際工作中。
測試Channel適用於內部。
Beta Channel或釋出Channel版本是首次對外曝光。

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

該過程也利於分析。如果現場發現bug，測試人員可以在每個channel執行來檢驗是否修復。

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

測試規模

Google不使用程式碼，整合和系統測試等概念，谷歌使用了小型，中型和大型等強調範圍的概念。

小型測試

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

中型測試

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

大型測試

包括三個大型以上（通常更多）功能並且儘可能接近使用者場景。這涉及所有特性的整合，不過大型測試更傾向於結果導向，即軟體是否是使用者希望的？

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

以上內容節選自：https://googletesting.blogspot.com/2011/03/how-google-tests-software-part-five.html

SET的職業生涯

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

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

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

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

所有正式專案都有專職的測試人員麼？預設是沒有的。小型項軟體測試開發工程師目和使用者數有限的專案一般由開發人員自試。其他的一些對個人或者企業使用者有潛在風險的專案測試才會介入。

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

當我說“測試”時，並不是僅僅意味著單純的檢查驗證程式碼路徑。測試人員不是從開始就參與進來的，但“測試”卻至始至終都有。實際上開發上傳程式碼或者之前，SET的影響力已經顯現。

參考資料：

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

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

軟體測試工程師的職業生涯

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

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

當測試工程師，進入產品的時候，並不需要一切重頭開始。在專案最開始的時候，開發工程師和測試開發工程師已經在測試工程和質量方面做了大量工作。測試工程師在進入產品時，需要考慮以下一些問題：

當前軟體的薄弱點在哪裡？
從安全、隱私、效能、穩定性這幾個角度出發都關注哪些內容？
對於主流使用者來說，是否可以滿足他們的預期？對於全球所有的使用者也是這樣麼？
這個產品是否需要和其他產品互動（軟體和硬體上）？
當發生問題的時候，診斷工具是否很好地使用？

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

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

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

測試工程師的工作經常需要去打破常規。在任何時刻，一旦測試工程師進入專案，他就需要去評估專案、程式碼、設計、使用者的當前狀態，並決定當前需要去首先關注些什麼。如果進入專案的時候，專案剛剛開始，這個時候測試計劃會是第一優先順序要解決的問題。有些時候測試在產品的晚期才進入，這個時候需要去評估這個專案是否已久為產品釋出做好了準備，或者在“beta”版本釋出之前還需要解決哪些主要的問題。如果測試工程師進入了一個新的產品，或者他對這樣產品中有較少經驗的時候，通常情況下會先去做一些不需要測試計劃的探索性測試工作。在另外一些時候，專案已經很久沒有釋出了，只是需要去做一些修飾或者安全方面的修復，或者使用者互動方面的更新，這需要測試工程師針對不同階段的專案使用不同的方法。谷歌的測試工程師需要在不同的專案做不同的事情，並且他們很少做相同的事情。

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

後記

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

How Google Tests Software - 2012.pdf