Google是如何測試的（全）

（一）

g oogle在公司的大層面組織上有很多的 Focus Area ，search, apps, ads, mobile, operating system這些都是不同的FA。測試隸屬於其中的一個FA，這個FA的名字叫Engineering Productivity。這個FA由很多縱向的橫向的學科構成，測試是其中最大的一個學科。Eng Prod這個FA由下面的部分組成：

1. product team。公司內部使用的工具還有開源工具都由它來生產，這些都是提高生產率的工具，包括代碼分析工具、IDE、case管理工具、自動化測試工具、編譯工具、編譯系統、代碼版本控制工具、code review工具、bug database。
2. services team。給上面的product team的各種工具的提供使用經驗，包括工具本身、文檔、測試、發布管理、培訓等，這些經驗涵蓋可靠性、安全性、國際化等方面。每個FA都共享這些經驗。
3. Embedded engineers。被按照具體的需求外借到不同的產品團隊（FA）。有的呆在同一個產品團隊好多年，有的則輪換多個產品團隊。google鼓勵工程師做這種輪換，因為這樣可以保持新鮮感、濃厚的興趣、立場的客觀。測試工程也一樣，不過這種輪換的平率則取決於個人。有測試工程師在Chrome上做了好幾年有的只有18個月。在新鮮感和領域知識中間做好一個平衡是作為一個測試人員要特別關注的事情。

從上面的表述可以看出來，測試工程師在google其實就是Eng Prod這個部門下面的Embedded engineers，他們要向Eng Prod的匯報，但是卻工作生活在別的產品團隊，比如Search、gmail等。可是他們不向產品團隊的人匯報，這種“分開匯報”方式的好處是他提供了一個forum，可以讓測試工程師分享他們的知識。在 Eng Prod 中Good testing ideas可以很容易產生。

把項目線和匯報線分開有它的挑戰。目前最大的挑戰是：測試是（產品團隊的）外部資源。產品團隊不能指望測試工程師保證質量，而是要自己來確保。在Google產品質量是產品團隊自己的事情，不是測試工程師的事情。每個開發工程師要自己來做測試。測試工程師的任務是確保他們有測試的自動化框架，另外還要建立一種有利於“自依賴”（開發依賴自己的測試來保證質量）的流程。總結起來就是：測試工程師讓開發工程師更舒服的來測試自己的代碼。

我（James）之所以喜歡這種方式，在於他把開發和測試人員放到了相同的位置（不存在上下游關系）。他讓測試開發成為伙伴，並且把最大的質量任務給了開發，致力於讓產品正確運行的開發自己。另外一個副效應就是做到一個很高的開發測試比。產品團隊應當以此為榮！

上面這種策略的弊病在於開發通常自己不能確保自己的質量，在Google我們解決這個問題的方法是建立兩種類型的測試角色，來解決兩種完全不同的測試問題，這個划分是：

（二）

1. SWE or Software Engineer。寫功能代碼，並發布到終端用戶。他們寫設計文檔、設計數據結構，並且花大量的時間write和review代碼。他們要寫大量的測試，包括測試驅動設計、單元測試、參與小、中、大的測試。他們對任何他們碰過的代碼質量負責，包括寫的、修復的、修改的。
2. SET or Software Engineer in Test。也是一個開發者，但是他的側重點在於可測性。他們review設計，並且審閱代碼的質量、風險。他們重構代碼並且使他們具備更好的可測性。他們編寫單元測試框架、自動化測試框架。從寫代碼這個角度來看，他們是SWE的伙伴，但是他們關心的是如何從代碼層面上提高質量、測試覆蓋率，而不是添加功能和提高性能。
3. TE or Test Engineer。他們是SET的補充（上文提到的“兩種類型的測試角色”的后者）。相比開發，他們更側重測試（注意不是說他們不寫代碼）。他們要花大量的時間寫代碼，這些代碼一般會是：自動化測試腳本、驅動、模擬用戶場景的代碼。他們同樣要組織好SWE和TE的測試產出，理解他們的測試結果，並且一起運行他們，特別是到了項目的后期當發布的壓力變大的時候。TE是產品專家、質量顧問和風險分析師。

（下面的這幾段分析比較深入）

從質量的角度來看，SWE要分別對產品的功能和他的質量負責。他們要做到容錯的設計、故障恢復、測試驅動開發、單元測試，並且還要和在SET的協助下編寫代碼測試他們的功能。（feature就是用戶可以用到的功能，而這里作者列舉的容錯等都算是產品的質量維度。）

 

SET也是開發者，他們提供的產品功能（feature）是供測試使用的。例如：一個通過使用“待實現代碼”（原文是stubs，我理解是code stub）模擬依賴的框架，從而能把新開發的代碼分離出系統來測試（其實就是mock框架，gmock的功能）。簡言之，SET編寫的代碼是為了能讓SWE更方便的測試自己的功能。真正的測試工作是由SWE來做的。SET只確保SWE完成的功能是可測試的，SWE自己來完成寫test case的工作。SET的關注的是SWE。具體功能的質量是最終目標，怎么讓SWE能夠容易的測試自己的代碼是SET首要側重點。這里有一個明顯的質量漏洞，功能的使用者——終端用戶呢？

 

在Google用戶體驗的測試是TE的事情。假設SWE和SET做的模塊、功能測試都足夠充分了，后面的任務就是這些程序和數據能不能有效的來滿足用戶的需求了。TE在這里是一個double-check。任何明顯的bug說明SWE的測試不充分馬虎。當這種bug難覓的時候，TE就可以轉向他們最重要的任務了，這些任務有：確保軟件完成了用戶場景，性能上、安全上、國際化上都OK。TE要做很多的測試和測試協調工作，這種協調工作牽扯的角色很多，有：TE, contract testers, crowd sourced testers, dog fooders, beta users, early adopters（這里不直譯了，contract表示契約，可以當做需求來理解；sourced指的是外包，可見google也有外包的產品；dog fooders是說公司的產品都要在公司內部先開展試用，公司鼓勵每個人都試用自己的產品，這就叫eating your own dog food，dog fooder值得就是使用過自己產品的員工；beta用戶是公測用戶；early adopter就是嘗鮮者，可以理解為發布后首先使用的人員。總之就是從產品）。他們要跟各種團體溝通的事情很多，包括：設計上固有的風險、功能的復雜性、避免故障的方法。一旦當TE介入，他們的工作沒有盡頭。（感覺TE更像是涵蓋了產品的運營任務，不是運維哦）。

（三）

首先明確，質量是測試不出來的。有個比喻很有意思：不能通過反復測試來提高質量，這就好像你不能通過反復稱重來減肥一樣。

在Google，質量不等於測試，有些公司則不然。“質量不能通過測試而植入”這個是老生常談了，我們不必去懷疑他的正確性。從手機到軟件，如果你沒有在一開始就把它構建好，那么他永遠不會正確的工作。如果你不知道一開始不重視質量的代價，那么去問問陷入“召回門”的汽車廠吧。

 

“質量不能通過測試而植入”這話本身並不通俗，它也不是一個准確的描述。可是為什么這么說？因為顯然，如果沒有測試你不可能開發出什么高質量的東西。對啊，如果你不測試，你怎么知道你開發出來的東西就是高質量的呢？

 

解決這個問題的簡單方法就是不要把開發和測試當做兩個單獨的學科。測試和開發應該是起頭並進的——寫一點、測一點；寫一坨，測一坨。更好的方法是，在你寫代碼的時候就准備如何測試，甚至是在寫代碼之前。測試並不是一類單獨實踐藝術，他是開發過程的一個部分。質量不等於測試，好的質量是通過把開發和測試有機粘合在一起來實現的，以致你不能區分出對方。

 

上面的描述就是我們在Google的目標：合並開發和測試直到你不能在沒有其中一個的時候完成另外一個。構建一尺，測試一尺；構建一丈，測試一丈。這里的關鍵問題是：誰來做這個測試。鑒於Google中全職的測試工程師從比例上來講少得可憐，那么答案自然是開發工程師。有誰比代碼的編寫者自己來做測試更合適呢？有誰比他自己來發現bug更合適呢？誰會對能在第一時間避免bug更振奮呢？Google之所以能夠在測試工程師這么少的情況下還能這么得瑟，就是因為開發對質量負責。事實上，堅持保留一個大量測試的團隊通常被認為是在犯錯。保有一個大型測試團隊是“開發工作/測試工作”嚴重失衡的標志，增加更多的專職測試人員是不會解決問題的。

 

換句話說：質量保證是重預防而不是重檢測。質量保證是一個開發問題，而不是一個測試問題。通過“把測試簽入到開發中”，我們建立了一個“超增量”的過程，能做到“當一個改動導致錯誤太多，那么就會自動回滾”。我們不單是避免了很多用戶問題，而且大幅降低了用來確保“沒有recall-class bug”的測試工程師的數量。在Google，測試的目的就是發現這種“避免問題”的方式是不是做的足夠好。TE時刻會關注SWE-SET的這種組合是不是能達到“避免用戶問題”的目的，一旦流程出現了問題TE就會發出警告。

 

團隊的各種跡象都能體現這種測試和開發的融合，從code review中的“你的測試呢”到廁所中大幅海報提醒開發者采納最佳的測試實踐——臭名昭著的“Testing On The Toilet”提示。測試必須成為開發不可回避的一面，開發和測試的聯姻的那天就是質量能夠得到保證的那天。SWE是測試工程師，SET是測試工程師，TE也是測試工程師。

 

如果你的組織也在做這種融合，何不分享你的成功和挑戰呢？如果你們的組織不在嘗試這種融合，那么這是你們組織可以嘗試的一個變化：讓開發工程師全權承擔起質量的任務。有句諺語說得好chickens are happy to contribute to a bacon and egg breakfast but the pig is fully committed（意思是說，雞願意為“雞蛋咸肉”早餐貢獻一份力量，而豬不願意。因為雞只是提供了雞蛋，自己毫發無損，而豬卻把自己都押上了。其實就是說要把開發置於死地而后生，讓他們自己測）。這樣一來你如果發現你的開發工程師發出豬的叫聲這就ok了，如果他們發出雞的叫聲那就有問題了。

 

（四）

 

匍匐、步行、跑步向前

 

之所以Google的測試人員相比其他公司非常少但是卻還可以保持較好的質量，一個首要的原因就是：我們很少試圖一次性發布很多功能。事實上，我們做的恰恰相反：首先構建一個產品的核心部分，並在他能惠及盡量一個大群體客戶的時候就發布他，然后收集反饋意見並且迭代改進。我們就是這么來開發Gmail的，以至於beta標簽在這個產品上呆了4年。這個標簽也讓我們的用戶知道這是一個在不斷完善的產品。直到我們能夠保證用戶email數據達到99.99%的可用性的時候我們才把這個beta標簽取消。看到了沒，質量的改善貫穿整個工作當中。

 

通過這個過程（確保質量）並不是一個很冒險的過程。事實上，為了能到達beta階段，一個產品必須經過很多的其他階段並證明它的價值。比如Chrome（我才開始來的時候在這個產品上做了2年），我們會依據我們在產品上的信心和反饋的程度不同來確定我們要引入多少個階段。例如：

 

Canary Channel。這個階段適用於那些不適合發布的代碼。就好像是煤礦中的金絲雀，如果它不能活下來，我們還要努力。這個階段構建的程序只能提供給那些具有超強耐受度的用戶，讓他們拿它來做實驗，不指望它能完成真正的工作。

 

Dev Chanel。提供給開發者在日常工作中來使用。我們鼓勵產品線上的每個工程師都把它拿來並應用到真正的工作當中。

 

Test Channel。這個階段構建好的程序會提供給公司內部所有的員工來使用，如果那性能也足夠好的話他也代表了一個准Beta版。

 

The  Beta Channel  or  Release Channel。這個階段構建出來的程序將成為首次對外公開的程序。一個產品只有在上面的各階段呆夠了足夠的時間后，他才能最終贏得一個在“槍林彈雨搬的測試和真實使用”下露面的機會。

 

這種“匍匐、不行、跑步向前”的方式讓我們能夠盡早的在我們的產品上測試、做實驗，並從用戶真實使用和每個階段的自動化測試中收集各種反饋信息。

 

（五）

在測試層級的划分方面我們沒有采用代碼級、集成級、系統級這樣的分類方式，取而代之的小測試、中測試、大測試，這樣做是為了強調測試的規模而不是外在形式。小測試只會覆蓋一小撮代碼，然后是中、大測試。不論是SWE、SET、還是TE，都會執行這三類的測試，可能是通過自動化的方式開展也可能是手工的方式。

 

小測試通常（但不總是）通過自動化的方式來運行，它只會運行一個函數或一個模塊的代碼。通常他們都是由SWE或SET來完成編寫的，他們的運行可能會需要mock環境，TE通常會在需要診斷一個具體問題的時候直接拿過來運行。對於小測試來說他們關注的是些典型的問題，如數據損壞、錯誤條件或一個錯誤。一個小測試要回答的問題是：代碼是不是完成了它應有的功能。

 

中測試可以被自動化也可以是手工的，他們通常包含兩個或多個功能，並特別的關注功能之間的交互。曾經有SET把這種測試描述成“測試一個功能和它的近鄰”。對於一個產品的周期中，在單獨的各功能的實現過程這個階段，SET會驅動這種測試的開發（為了讓SWE能方便的編寫“中測試”做准備）；這種測試的大量編寫、調試、維護工作則是SWE的事情。如果測試失敗，工程師會自己去搞定它。在開發階段的后期，TE會手工執行（當這個測試不容易自動化，或者自動化的代價太大時）或自動化的執行他們。中測試要回答的問題是一組鄰居功能是不是能完成他們應有交互任務。

Large Tests。大測試覆蓋三個或更多的功能，並且要盡可能的代表真實的用戶場景。怎么來對一個集成了所有功能的場景來設計case這個或許有疑問，大師大測試都是結果導向的，比如軟件是不是能有滿足用戶的預期？三個角色都會參與大測試的編寫，從自動化測試到探索性測試所有的事情都要完成。大測試要回答的問題是：產品是不是完成了用戶預期的功能。

 

語言上的稱謂具並不重要，重要的是Google的測試人員有這么個共同語言並且知道他們每個測試代表的范圍。當一些激進測試人員談論第四類測試的時候，他們值得實際上是一種能夠涵蓋所有功能的系統測試，而且這個測試要跑很長的時間。

 

我們要測試什么以及測試多少，這后面的驅動力量是動態變化的，而且產品之間也有不同。Google更傾向於頻繁的發布，把產品推向用戶，然后從用戶收集反饋並迭代。基本想法就是一旦我們開發了一個產品或一個現有產品的新功能，就立即把他推向用戶，這樣用戶就能第一時間從中受益。這就需要我們把用戶和外部開發者在前期就納入進來，這樣我們就能清楚我們做的東西是不是已經達到目的了。

最后，對自動化和手工測試的混合來說，自動化毫無疑問是最推崇的，不管是在大中小的測試中。如果它能夠被自動化，並且過程中不需要人的智慧和靈感的介入，它理所當然要被自動化。只有在需要人來做判斷的情況下才考慮手工來做，比如：UI的美觀性、暴露一些數據會構成隱私問題。

 

盡管說了這么多，你必須要曉得Google要做大量的手工測試的，可能是寫腳本方式也可能是探索性方式，但即便如此這些測試也是在自動化的監視下完成的——工業化的腳本錄制技術可以把手工測試轉換成自動化測試腳本，這些腳本就可以在每次構建后來執行，以此來最小化回歸測試的開銷，並且把人力集中到那些新問題上。我們也自動化了bug的提交和手工測試任務指派。比如：如果有個自動化測試失敗了，系統會確定最后的代碼更改位置（這里最可能是出現問題的地方），然后發郵件給其作者並記錄一個bug。The ongoing effort to automate to within the “last inch of the human mind” is currently the design spec for the next generation of test engineering tools Google is building.（within在這里應做動詞“把XX融入”來講，大概意思是：正在努力的方向是“自動化人類的每個想法”，也就是人只要一想出來怎么測試，然后就可以立即把這個想法自動化，這是Google在建設的下一代測試工具）

 

下一篇將是關於SET的工作的。

 

（六）SET的工作方式

 

SET是專注於測試的軟件工程師。他們是樂於編寫測試功能的軟件工程師。首先說，SET是開發者，在招聘的時候我們就會說這個工作是100%的編碼工作，晉升階梯中的描述也是如此。當我們面試SET的時候，對於寫代碼能力的要求跟SWE幾近相同，之外我們還會強調SET要懂得如何測試他們自己的代碼。換句話說，SWE和SET都要回答編碼問題，但是SET要面對更多的測試問題。

 

你應該猜到了，這個角色很難做，而且造成Google的SET數量很少的原因，可能完全不是因為我們有針對生產率的一套魔法公式，而在於：把我們的工程實踐應用到SET技能的人真的很難找。我們優化這項重要的工作並且圍繞這些人建立流程。

 

SET不會參加到前期的設計當中，之所以如此不是我們有一這樣的，這是由我們的項目誕生方式來決定的。一個典型的新項目誕生情況就是：員工的20%非正式時間的投入變成了Google自己品牌的項目。Gmail和Chrome OS都是這樣在一開始沒有自上而下的一個任務指派，但是最終成長為由很多開發和測試工程師組成的團隊來共同構建的產品。在這樣的一種情況下，一開始的開發是不在乎質量的，其目的在於驗證一個概念，或者是專注可擴展性、性能等一些在質量成為問題之前必須正確的東西。簡單來說，如果你不能夠使你的web service能夠有擴展性，那么測試問題就顯然不是一個最大問題（擴展性才是）。

一旦確定一個產品能做、要做的時候，那么開發團隊就要開始尋求測試的介入了。

 

關於這個流程你可以這么來想象：某人有了一個想法，首先要對其思考，然后寫一下實驗代碼，去征求其他人的想法，再寫代碼改進，找其他人一起來做，再寫更多的代碼，之后他們意識到他們的這個想法非常有價值，進而寫更多的代碼來實現他們的想法並把實現出來的效果給更多的人看，並收集反饋，這個時候這個項目其實就已經放入了Google的項目數據庫了，項目也變成了真正的項目。一個項目在沒到達這個階段前，是不會有測試人員介入的。

 

所有的項目都會有測試人員么？默認不會。小項目還有那些只對有限的一些用戶有用的項目都是由開發那些項目的工程師自己來測試的。其他那些對用戶和公司更具風險的才會引起測試的注意。

 

開發團隊任務是向測試人員尋求幫助，向測試人員證明他們的項目是多么的刺激和充滿潛力。開發的負責人向測試負責人講解項目的想法、進展和發布計划，測試負責人則要就“測試工作如何分擔”“SWE參與測試”“預期的單元測試級別”“發布中的責任如何分擔”等問題展開商討。SET可以在項目一開始不介入，但是一旦正式立項，在項目如何來實施這個問題上，則有巨大的影響力。

當我說“testing”這個詞的時候，我指的不單單是運行代碼，覆蓋代碼路徑。測試人員不一定從一開始就介入，但測試（testing）卻是（作者的意思是測試其實是無處不在，從項目一開始的各種工作都會與測試有多多少少的聯系，比如后面說的提交代碼，這里testing如果換成QA可能更有利於國內的一些業內人來理解）。事實上，（請注意）一個開發即便是在提交代碼的時候都會感覺到SET的存在。

 

（七） TE的工作

 

相比SWE和SET，TE在Google是一類新職位。因此，這個職位的角色定義還在進行中。當前Google的這代TE正在為這個職位開辟一條道路，這樣就能更好的指導后面招聘進來的TE來開展工作。我們這里描述的是在Google新興起來的一個最好過程（It is the process that is emerging as the best within Google that we present here）。

 

並不是每個項目都需要TE。那些在產品初期的實驗性嘗試，沒有良好定義的任務或用戶場景的項目勢必不會引起很TE的注意。如果一個產品看起來沒什么希望（作為一個概念他不能通過審核）或者尚未能吸引用戶注意或者沒有清晰的功能定義（原文是have a well defined set of features，懷疑是作者落下了not，從上下文判斷應該是not have a well defined set of features），測試工作就應該是開發他的人自己來做。

 

即便對於一個確定要對外發布的產品，TE在開發階段的初期也沒什么事情可做，因為在這些階段功能在不斷變動，最終的功能和邊界也不確定。在測試方面太早的投入過多就會導致很多工作被丟棄（因為產品的功能可能后來就變了）。同理，一開始做測試計划需要的TE數量比后期做探索性測試TE數量少很多，因為，到了后期產品幾近成型，這個時候尋找遺漏bug顯得非常緊急。

 

在一個項目中配備TE跟風險和ROI息息相關。對於客戶和企業來說這意味着要花更多的測試精力同時需要更多TE。但是這種努力需要和回報成比例。我們需要正確數量的TE在正確的時間並起到正確的作用。

一旦介入，TE並不是一切從頭開始來。因為已經有SWE和SET做了大量的測試工程化和面向質量的工作，這些工作都是TE后續工作的基礎。TE的初期介入要做的事情有：

• 軟件什么地方最薄弱？
• 安全、隱私、性能、可靠性方面都有哪些考量？
• 對於國際的各種用戶，是不是所有的首要用戶場景都能按照既定的方式工作？
• 產品會和其他產品（包括硬件和軟件）交互嗎？
• 一旦出了問題，問題的診斷是不是容易做到？

所有的這些都在質疑要發布軟件的風險輪廓。TE並不需要親自做所有的這些工作，但是他要確保這些事情都做了，並利用別人的工作來評估是不是還有更多需要做的事情。總的來說，TE對企業的價值體現在他保護用戶和公司免受一系列問題的侵擾，比如壞的設計、令人困惑的UI、功能bug、安全和隱私問題等。在Google，TE是一個團隊中唯一個全職的從整體上來關注產品和服務弱點的人。因此，TE的職業路線相比SET來說遠沒有規則和格式可循。在項目的任何階段都有可能需要TE的協助，從創意階段到好幾個版本發布，甚至是監視一些過時的、封存的項目。通常，一個TE會同時服務於多個項目，特別是那些有特殊技術（比如安全）TE。

 

顯然，不同項目中TE要做的事情可能差別蠻大的。有些TE要花大量的時間寫代碼，有點像SET，只不過重心是關注終端用戶的使用場景。還有些TE針對現有的代碼和設計從中尋找故障失敗模式和導致故障的原因，這種情況下，TE可能會修改代碼但是不會從頭寫。TE在做測試計划的時候必須更系統、全面，並在真正使用（系統）和系統經驗方面兼顧完整性。TE擅長處理需求中的模糊性，並且善於推理和表達邏輯問題。

 

成功的TE在敏感的、有時候個性很強開發、產品團隊之間游走過程中完整所有任務。每當他發現漏洞，TE高興的攻破系統，並驅動SWE、PM、SET去解決這些問題。

這樣的一個職位描述可能讓他的前景有點嚇人，他需要各種知識的融合包括技術方面的、領導力方面的、產品理解方面的，如果沒有合適的指導，這個職位很可能會失敗。但在Google，強大的TE社區已經出現來對付這種情況。在所有的職位中，TE可能是最注重支持（peer supported）的這么一個角色，做好TE這個職位需要的洞察力和領導力通常意味着很多的測試經理都是從TE這個職位里走出來的。

 

Google的TE工作的流動性掩蓋了各種程式化的介入過程（言外之意就是TE的工作很靈活不確定，原文是：belies any prescriptive process for engagement）。TE可以在任何時間點介入項目，並且必須要迅速的評估項目的狀態、代碼、設計和用戶，還要確定什么是首要關注的東西。如果項目是剛開始啟動，測試計划通常首要考慮的事情。有的時候TE會在項目的末尾階段被拉來評估項目是不是適合發布，或者一個早期的Beta版被放出的話會不會有問題。如果TE來到的是一個新應用或者是一個他之前沒有任何經驗的應用，他們就會從一些探索性測試開始做起，基本沒有什么規划。還有的情況是項目很久沒有發布了僅需要一些（安全）修復，或者界面交互的調整，這對TE來說就需要一些不同的策略。總之一句話，在Google中TE的工作沒有定式可循。