How Google Test Software讀書筆記(二)

第三章 The Test Engineer

這章主要介紹Google的TE，就是傳統測試工程師每天到底都做些什嗎？羅馬不是一天建成的，曾經的Google也是幾乎沒有測試的，但一直擁有最優秀的一批工程師，以技術為導向的這麼一個公司，技術厲害的人才是一等公民。但是隨著互連網時代的爆發和變遷，他們也逐漸意識到，品質的保障和測試的意識、手段、思維方式也是一門藝術，是值得尊重的一門技能。Google可以說把SE（測試工程師）這個角色的定義挖掘發揮到了極致。

毫無疑問TE角色是應該專註在系統真正的使用者上的，同時他們也需要相當的技術，Google衡量一個優秀的SE提出了以下幾條標準：能否評價系統存在的漏洞？能否在安全性、私密性、效能、可用易用性、相容性、國際化全球化上給出準確的分析？能否與其他系統或者硬體輕易的整合？當問題出現了，有哪些有效時候來診斷調試收集必要的反饋資料提供給開發工程師更迅速的定位並解決問題。Google很看中的是SE是否能成為產品的專家，能否具有很強的溝通合作能力，跨部門的利用所有Google的資源來解決各種問題。

關於Test Plan，Google裡也存在一個很常見的問題。Test Plan總是建立得很早很早，然後就一直被擱置在一邊，沒有其他人會有意願主動去看它。Google解決這個問題的方式是：需求會快速變更，所以Test Plan也應該時刻保持更新，它應該描述了產品的核心競爭力，包含了產品的架構和元件圖表，清晰的描述了產品的職責是什麼。其實這也是一種Agile裡提到的團隊共同的願景，當大家時刻可以看到一份同樣的描述產品最重要訊息的文檔，樹立起同樣的願景為之努力時，這就是一份優秀的Test
Plan了。（不要寫成散文，不要寫成銷售推廣，它要確切的描述了測試對象和測試最終的目標）曾經Google內部嘗試過一種時間叫10分鐘Test Plan，目的不是為了真的逼大家只用10分鐘寫出一份Test Plan，而是督促大家只把必要的最重要的資訊放在Test Plan中，保持大家都願意開啟來它的一種意願。

那麼Google的Test Case又是如何產生的呢？這一套流程也很有意思。他們首先會把產品的職責定義出來用一個個名詞來表示，稱做“Component”，然後會用一系列形容詞描述產品的特點，稱作”Attribute”，接著當某個Component結合了一個Attribute之時，就產生了一個能代表具體情境的”Capability”，意味著產品的某個功能可以做什麼，在這個情境的基礎上，就可以衍生出一個或者多個測試案例。舉個例子：Google+的Profile,
Stream, Circles(圈子)都是Component，Google+的Attribute包含有Social, Easy, Relevant, Private，將二者關聯起來可以產生的Capability舉例：

• Profile(使用者檔案) should be Easy，so Easy to enter and update and have it propagate. 
• People（Google+使用者）should be social，so Users can connect with user’s friends, coworkers and families.

基於這樣的情境Capability，每一個都可以設計數個測試案例出來。Google的測試案例就是由這種二維的Component+Attribute，關聯組合出的Capability衍生出來的。

Google的TE還非常注重Risk Analysis，主要從兩個方面：出現的頻率和所造成的影響。測試工程師有責任去對產品的任何缺陷做風險分析，甚至將結果主動遞交給最應該關心它的人。當然風險分析不只是針對Bug，還包括對產品的測試覆蓋比較薄弱的沒有觸及的地區的描述，而不是簡單的回覆一個產品品質還行、不錯之類的話。任何產品直到Release出去也不可能盡善盡美，不管你做再多的測試，也無法產生完美無缺，所以風險分析能對產品面世之後的品質跟蹤和反饋分析提供許多參考。

由於TE更加關注可視化的東西，對人員的挑選，在面試中看中的點就跟SET不一樣。一般Google會給定你一個測試情境，希望你充分發揮主觀能動性，在交流中讓情境模糊的部分越加清晰，設計出儘可能全面覆蓋的測試案例，並提出情境直觀上需要改進的部分，哪怕是字型、顏色、布局等使用者體驗的改進意見。當然基於Google產品的背景，面試者肯定還要在效能、國際化、雲端服務等方面提出對情境的看法。

最後要說的是，Google對TE的管理方式是：Pirate Leadership。也就是像海賊王裡的海賊一樣，自由的選擇自己想上的船想去的海域。每個TE都可以追求自己覺得刺激、自由的生活，如果對本項目不感興趣，可以主動申請加入自己最感興趣的項目組。事實上Google也鼓勵TE在各個項目之間換來換去吸取不同的經驗增長見識。

第四章 The Test Engineer Manager

這章主要介紹在Google，測試團隊是如何被管理的。從之前沒有測試，到測試團隊組建，到現在的穩定成熟，都經曆了哪些變遷和產生的新的文化。

本章主要是採訪了許多Google不同項目的測試主管，詢問他們的經驗和經曆的困境等等。比如Gmail的測試經理談到Gmail的測試過程劃分為20%的探索性測試，30%由TE主導來進行定向的功能覆蓋測試，還有50%是由SET研發的自動化測試覆蓋。他們還會根據使用者的類型建立使用者模型，反饋在測試過程使用的資料中。Android測試經理談到他們的測試很大一部分都需要TE，因為要覆蓋大量的裝置型號和硬體部署，他們總結出探索性測試要帶著一定的目的性去做，而不是簡單的漫遊測試走到哪算哪，而這種目的性往往來自於對源碼改動的部分和對關聯部分的理解能力，所以TE也需要閱讀許多代碼的。

這裡還想提到的是，Google的許多產品都使用到一種叫做”Free Testing”，即讓真實的使用者來協助測試。這也是現在許多產品都直接發布beta版的原因，讓全世界使用互連網的使用者都用起來，產生反饋，發現一些難以發現的Bug，並給予一定的獎勵。到目前為止，Google的許多產品並不是都還活著，像Wave、Buzz這種，都是在市場的反饋和使用者的使用中逐漸消亡被Google+給取代了。試想如果當初盲目投入大量的測試到Wave和Buzz中，但真正上線後卻發現並不是使用者最想要的東西，損失將會是多麼大。當然直接放到市場上讓使用者去做免費的測試還有一個前提，就是有強大的反饋系統來保障問題發生時，所有需要診斷和修複的資料全都能自動認可到開發工程師面前，而且還要避免收集使用者的隱私資料。這一點，由於Google長期堅持的工具文化，已經誕生了許許多多很棒的線上智慧型工具，所以對於Google來說可以做得很好，其他互連網公司就不知道了！

第五章 Improving How Google Test Software

沒有最好，只有更好嘛，這一章基本是一個發散思維的雜談未來的軟體行業需要怎樣的Test人才，現在最優秀的Test Engineer還有哪些方面可以做得更好。

對於SET來說，其實最終的趨勢是跟SWE不分彼此，因為本身對他們的技能要求也是完全一致的。讓所有的工程師都帶著保障品質的責任心來編程，就是一種完美的狀態。當然，客觀上來說，工具文化還是需要有相當一部分工程師為了提高Bug追蹤，自動化流程、代碼缺陷這些目的而專註在效率工具的研製上。而對於TE來說，他們必須扮演使用者的角色，更好的利用探索性測試發現產品內在和外在的缺陷，他們更多的要專註的是Test
Design，快速的構建出產品的function map, risk map和tours，以使用者的角度來將產品最清晰的詮釋出來，所以他們必然是一批Google產品的專家。

未來的世界依然是互連網的世界，Native的東西會越來越少。無論是SET還是TE，都必須明白測試的構建、未來的趨勢一定是以Web為中心的，用最少的人利用Web的資源做最多的事情。

Ending 總結

看完這本書，讓筆者反思了許多以往工作中所犯的錯誤，誠然Google聚集了許多世界上最優秀的工程師，它的模式也未必適用於國內的許多公司。國內的測試行業也是亂象叢生，老闆注重的永遠是結果而不是過程，但是作為在一線奮鬥者的工程師們，都應該反思我們如何提高團隊的工作效率，利用各自擅長的技術優勢簡化軟體開發中可以讓機器和網路來做的流程，將人思維的價值儘可能放大，並積極的分享經驗交流，共同促進整個行業水平的提升。筆者只是一個不知名的小小工程師，但也會盡自己的一份微薄之力。

Resource 書中優秀資源（大部分需要翻牆）

• Google Protocol語言：https://developers.google.com/protocol-buffers/
• Google C++ Style Guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• Chromium自動化架構pyauto： http://www.chromium.org/developers/testing/pyauto
• Native Driver: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html
• Google Test Blog:http://googletesting.blogspot.com/

聲明：轉載請註明原文出處。