1）整體來說，這本書到底在談些什麼

Google測試總監James Whittaker介紹了Google是如何進行測試的，介紹了測試解決方案、測試工程師、測試開發工程師、測試經理的角色和職能，應該具有的技術技能。

2）作者細說了什麼，怎麼說的

測試工程師、測試開發工程師的角色和職能，應該具有的技術技能。

3）這本書說的有道理嗎？哪些有道理

首先Google公司名氣在外，每天對外發布很多原始碼，如何對這些程式碼的質量進行把控肯定有Google的方法在，值得學習，吸取經驗。Google對測試相關角色的定義也值得各公司學習，避免測試成為只會點點點的低技術含量的角色。

4）這本書跟你有什麼關係？

本書在測試界頗有名氣，而本人作為一枚測試攻城獅，需要多想大公司的經驗學習，提高自己。

第1章 Google軟體測試介紹

在Google，軟體測試團隊歸屬於“工程生產力（Engineering Productivity）”部門。

隨著軟體逐漸由桌面應用遷移到網路雲端，Google的測試模式很有可能會逐漸成為測試行業的主流模式。

在整個公司，我們只有非常少的專職測試人員。Google成功的關鍵是什麼，（作者的建議）不要招聘太多的測試。

開發人員也承擔了質量的重任。質量從來就不僅僅是一些測試人員的問題。在Google，每個寫程式碼的開發者本身就是測試者。不關注開發測試人員比例。

如果你是一名工程師，那麼你同時也是一名測試人員。如果在你的職位頭銜上有測試的字樣，你的任務就是怎樣使那些頭銜上沒有測試的人可以更好地去做測試。

1.1 質量不等於測試

開發人員寫一段程式碼就立刻測試一段程式碼。如果產品出了問題，第一個跳出來的肯定是導致這個問題發生的開發人員，而不是測試人員。當把開發過程和測試過程放到一起，就得到了質量。

1.2 角色

SWE	軟體開發工程師	實現功能性程式碼。編寫測試程式碼。 關注增加功能或提高效能。
SET	軟體測試開發工程師	確保開發人員的測試程式碼具有可測試性和編寫通用測試框架。 關注質量提升和測試覆蓋率。（寫程式碼的目的是可以讓SWE測試自己的功能）	關注物件是開發人員
TE	測試工程師	TE把使用者放在第一位來思考。TE組織整體質量實踐，分析解釋測試執行結果，驅動測試執行，構建端到端的自動化測試。	關注物件是使用者

1.3 組織結構

模式之一：開發人員與測試人員隸屬於同一個工程生產團隊。彙報給同一個產品團隊的管理者。在產品釋出時，優先考慮的是功能的完備性和易用性，卻很少考慮質量問題。作為同一個團隊，測試總是在為開發讓路。我們這個行業裡總是有各種有缺陷的的產品，或許這就是問題所在。

在Google中，測試是獨立存在的部門，是與專注領域部門平行的部門，稱為工程生產力團隊。測試人員以租借的方式進入產品團隊。測試人員有自己選擇決定的優先順序，在可靠性、安全性等問題上都不會妥協。

好處：

1、保持數量較少的測試人員，一個產品團隊不能任意降低測試人員招聘的技術要求，從而僱傭更多的測試人員。與功能有關的髒活累活本來就是開發人員的工作。

2、測試人員在不同專案之間的借調模式，可以讓SET和TE時刻保持新鮮感，還能保證一個好的測試想法可以快速在公司內部蔓延。

Google的特殊規定：測試人員如果在某個產品中工作滿18個月，可以無理由地自願轉崗到其他產品。可以增強測試人員對各個產品與技術的理解。

1.4 產品釋出

金絲雀版本：每日都要構建的版本，只有這個產品的工程師才會使用。

開發版本：開發人員日常使用的版本，一般每週釋出一個。

測試版本：通過了持續測試的版本，基本上是最近一個月內的最佳版本。

beta或釋出版本：由穩定的測試版本演變而來，對外發布的第一個版本。

1.5 測試型別

解決的問題	特點	參與者
小型測試	程式碼是否按照預期 方式執行	一般是自動化實現的 執行時間比較短 一般需要使用mock和fake	由SWE實現，也會有少量的SET參與，TE幾乎不參與。
中型測試	一系列模組相互互動的時候，是否按照預期工作	通常也是自動化實現的 重點關注模組之間的互動	SET驅動測試的實現及執行，SWE深度參與，TE可能會通過手動的方式參與
大型測試	這個產品操作執行方式是否和使用者的期望相同，併產生預期的結果	使用真實使用者的場景和資料，耗時較長 傾向於結果驅動，驗證軟體是否滿足終端使用者的需求	SWE、SET、TE都會參與

Google沒有使用程式碼測試、整合測試、系統測試這些命名方式。著重強調測試的範疇規模而非形式。

相對於手動測試，傾向於自動化測試。

Fake: a class that implements an interface but containsfixed data and no logic. Simply returns "good" or "bad"data depending on the implementation.

Mock: a class that implements an interface and allows theability to dynamically set the values to return/exceptions to throw fromparticular methods and provides the ability to check if particular methods havebeen called/not called.

Stub: Like a mock class, except that it doesn't providethe ability to verify that methods have been called/not called.

Mocks and stubs can be handgenerated or generated by a mocking framework. Fake classes are generated byhand. I use mocks primarily to verify interactions between my class anddependent classes. I use stubs once I have verified the interactions and am testingalternate paths through my code. I use fake classes primarily to abstract outdata dependencies or when mocks/stubs are too tedious to set up each time.

第2章軟體測試開發工程師

編寫功能程式碼和編寫測試程式碼在思維方式上有很大的不同。對於功能程式碼而言，思維模式是建立，重點考慮使用者、使用場景和資料流程上；對於測試程式碼，主要思路是去破壞，寫程式碼用以分離使用者及其資料。

2.1 SET的工作

SET會參與到許多測試目標的構建中，並指出哪些地方需要小型測試。同時編寫許多mock和fake工具，甚至編寫中大型整合測試。

SET究竟是誰：測試是應用產品的另外一種功能，而SET就是這個功能的負責人。

面試SET的時候，在程式碼要求標準上與SWE的招聘要求是一樣的，而且增加了——SET需要了解如何去測試他們編寫的程式碼。

在專案概念階段，測試人員不會參與進來，而專案一旦真正立項，需要測試人員參與。

SET如何審閱設計文件：

1）完整性

2）正確性

3）一致性

4）設計

5）介面與協議：是否對所使用的協議有清晰的定義

6）測試：可測試性如何

自動化計劃：

常見的錯誤：試圖在一個測試套件中自動化所有端到端的測試用例，在端到端的自動化測試上投入過度，常常會與產品的特定功能設計繫結在一起，這部分測試在整個產品穩定之前都不會特別有用。

端到端測試，英文是End to EndTesting。類似於系統測試，測試級的“巨集大”的端點，涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。

Google的方法：

首先，將容易出錯的介面做隔離，針對它們建立mock和fake。

其次，構建一個輕量級的自動化框架，控制mock系統的建立和執行。

測試大小的定義：

小型測試：驗證一個程式碼單元的功能。不需要外部依賴，外部服務需通過模擬或虛假實現（mock&fake）。（通常為“單元測試”）

中型測試：驗證兩個或多個模組應用之間的互動。鼓勵使用模擬技術（mock）來解決外部服務的依賴問題。（通常稱為“整合測試”）

大型測試：驗證整個系統作為一個整體是如何工作的。依賴外部系統資源。（通常為“系統測試”或“端到端測試”）

測試規模的優缺點：

優點	缺點
小型測試	確保程式碼清晰乾淨、函式規模較小且重點集中； 可以隨時執行，較早的發現缺陷； 測試範圍小，容易做邊界場景與錯誤條件的測試； 容易隔離錯誤； 使用mock或fake環境，可以不依賴真實的環境
中型測試	執行速度相對較快，可以頻繁的執行；	依賴外部系統，本身具有不確定性； 執行速度比小型測試慢。
大型測試	依賴外部系統，本身具有不確定性； 測試範疇比較寬，如果執行失敗，尋找精準失敗根源會比較困難； 測試資料的準備工作會非常耗時；

這三種測試規模的比例，70/20/10原則：70%是小型測試，20%是中型測試，10%是大型測試。

如果專案是面向使用者的，應該有更多的中型或大型測試；如果是基礎平臺或者面向資料的專案，最好有大量的小型測試。

Google的特殊規定：

20%的時間是Google的一種制度，每週可以拿出一天時間，或者一週工作時間的20%來做自己選擇的專案。可以參加不同的專案，提升技能，激發和保持了工作熱情。通常，Google不使用商業性工具，高度重視工具的文化，鼓勵員工自己開發工具。

2.2 測試認證

從低到高分為1-5級。目的是提高開發人員進行測試的積極性。

P55，測試認證的分級

（使用訪談的方式介紹測試認證在Google中的發展過程）

初期開展比較難，尋找如下的開發團隊：①對測試足夠感興趣；②沒有太多冗餘的程式碼；③在團隊中有一個測試戰神。

2.3 SET的招聘

一個優秀的SET候選人不應該被告知要去測試程式碼，這應該是SET自然要考慮的地方。

2.4 與工具開發工程師Ted Mao的訪談

建立Buganizer和Matrix產品，建立心得，對於開發測試工具的建議。

2.5 與Web Driver的建立者Simon Stewart的對話

介紹Selenium和WebDriver的由來和區別，以及以後的發展。

第3章測試工程師

3.1 一種面向使用者的測試角色

Google的TE綜合了開發者仰慕的技術能力和以使用者為中心檢查軟體質量而對開發者產生一定製約的能力。

TE的職位描述是最難定義的，因為其職責範圍很廣而且不確定。

3.2 測試工程師的工作

在研發的早期階段，功能還在不斷變化，最終功能列表和範疇還沒有確定，TE通常沒有太多的工作可做。

TE在進入產品時，需考慮如下問題：

當前軟體的薄弱點在哪裡？

有沒有安全、隱私、效能、可靠性、可用性等問題？

主要使用者場景是否功能正常？

這個產品能與其他產品互操作嗎？

當發生問題的時候，是否容易診斷問題所在？

TE的根本使命是保護使用者和業務的利益，使之不受到糟糕的設計、令人困惑的使用者體驗、功能bug、安全和隱私等問題的困擾。這個角色需要敏銳的洞察力和領導力。

TE職責：

測試計劃和風險分析

評審需求、設計、程式碼和測試

探索式測試

使用者場景

編寫測試用例

執行測試用例

外包

使用統計

使用者反饋

3.2.1 測試計劃

測試計劃需要具有如下特性：

及時地更新

描述了軟體的目標和賣點

描述了軟體的結構、各種元件和功能特性的名稱

描述了軟體的功能和操作簡介

不必花過多的時間去撰寫，必須隨時可以被修改

描述必測點

能在測試中提供有用的資訊，從而幫助確定進展以及覆蓋率上的不足。

ACC（Attribute Componet Capability，特質、元件、能力）  P82

Google使用ACC作為一種測試計劃的替代方法。

A代表特質：

代表產品的品質和特色，是區別競爭對手的關鍵。產品經理或者開發人員已經確定了產品的特質，測試人員只需將特質記錄下來，以備使用。

C代表元件：

元件是構成待建系統的模組。元件容易識別，經常出現在設計文件中。

對於特質和元件來說，花幾分鐘的時間來理清就足夠了。

C代表能力：

元件（Componet）執行某種功能（function）來滿足產品的一個特質（Attribute），這個活動的結果是向用戶提供某種能力（Capability）。P86

能力最重要的一個特點是它的可測試性。

TE需要將能力轉化為測試用例。

ACC的完成，意味著所有可測試的特性都被定義好了。

P90，Google+的案例分析

3.2.2 風險

風險的要素：發生頻率和影響。

發生頻率：罕見、少見、偶爾、常見

3.2.3 測試用例的生命週期

Google管理測試用例的工具，初期用Test Scribe。後期被GTCM（Google Test CaseManager）取代。這個小章節介紹了GTCM的特點。

3.2.4 bug的生命週期

 介紹Google管理bug的工具——Buganizer。

許多團隊在bug到達的速度超過了其修復能力的時候，乾脆不再進行新功能的開發。強烈推薦這種實踐，反對那種只盯著特性或者程式碼完成的里程碑的做法。

3.2.5  TE的招聘

TE的招聘非常困難，因為他們需要擅長很多事情。

面試TE的意圖：

對事物結構、對於變數和配置的組合的各種可能性和意義的好奇心。關於事物應該如何工作的強烈感覺，以及清晰表達的能力。很強的人格魅力。

3.2.6 Google的測試領導和管理工作

Google的測試管理更多的是激勵，而非強悍的管理；更多的是戰略指引，而非頻繁的督促檢查（每天、每週等）。

通常，過度的管理和組織會帶來緊張的氣氛。

作為測試領導層，經常需要妥協，並能尊重個體SET和TE的聰明才智。Google領導和管理的一個標誌是輔導和指導下屬工作，而不是直接下命令。

3.2.7 維護模式的測試

儘量淘汰手工測試，使用自動化測試。

3.2.9 BITE實驗

問題：測試人員花了很多時間在上下文切換和分析大量資料上，經常需要切換多種工具，影響效率。

解決方法：使用BITE工具，將盡可能多的測試活動、測試工具和測試資料集中到瀏覽器和雲裡，並在上下文中呈現相關資訊，從而減少分散操作的麻煩，使得工作更加高效。

本節介紹了BITE（Browser Integrated Test Enviroment）的由來、功能以及如何使用。

BITE的逆天功能：

1、在網頁上提bug時，自動獲取瀏覽器資訊；

2、開啟頁面，自動顯示此頁面的bug；

3、可以進行錄製和回放；

4、自動分配任務，做得快的會自動收到更多的測試任務，暫停的人的任務會自動分給其他人；

3.2.11 零成本測試流程

• 免費測試特徵的想法：

成本幾乎為零；

瞬間可得的測試結果；

極少或者無需人工干預；

非常靈活。

• Google的免費測試模型——bot流程：

1）通過GTA進行測試計劃；

2）測試覆蓋度：bot自動抓取網站內容，發現有所變化立刻提交人工去判斷；

3）bug評審：BITE提供現有的bug和豐富的測試上下文資訊；

4）探索式測試

5）bug提交：基於BITE，很容易提交bug

6）bug檢視和除錯：開發或測試經理可以看到實時的bug趨勢圖。

7）部署新版本並回到步驟1）。

價值在於：測試人員無需為了少數幾個可能發生迴歸的特性變化，而去手工執行成百上千的迴歸測試。bot可以幾分鐘內完成一個測試周期，從產品新版本的部署到bug的發現之間的間隔很短。

3.3 與Google Docs測試工程師Lindsay Webster的訪談

• 參與一個新專案時，首先去做哪些工作：

首先了解這個產品；包括所有文件；關注專案的狀態，特別是質量狀態，瞭解bug的情況；檢查應用的程式碼庫，檢視執行對應的單元測試是否通過。評審自動化測試，是否有自動化測試，檢查程式碼；關注團隊，瞭解他們的溝通方式和期望，加入他們的通訊組裡。

開始進行測試工作，將應用分解為合理的功能模組，排列測試的優先順序。建立測試集合，維護和更新：更新測試用例，增加新特性的文件，更新變化了的模組的截圖或視訊。

最後，觀察哪些bug遺漏到了生產環境，來告訴我們測試覆蓋上的不足。

• 與開發的關係：

當我坦誠地指出某些元件或領域的測試不應該由我負責，而應該由他們自己負責的時候，開發反而更加看重我的工作了。

很多測試人員試圖避免自我宣傳，避免公開討論他們不會測試的東西，擔心這樣做會使人輕看測試的價值。但在我的經驗裡，事實卻恰恰相反，開發會因此而尊敬你。

• 介紹如何開展Google Sites的測試。

3.4 與YouTube測試工程師Apple Chow的訪談

為什麼加入Google：大量使用自動化，重視工具的開發；開發負責質量，以測試為中心的SWE文化。

如何在YouTube中應用探索式測試和Selenium自動化測試；

第四章測試工程經理

4.1 測試工程經理的工作

測試工程經理可能是Google裡最具挑戰的一個職位，不僅需要同時具備TE和SET的技能，還需要擁有足夠的管理技能來負責下屬的職業發展。

測試工程經理彙報給測試總監。

要求：

1、瞭解你的產品，相關專案中最強的產品專家。

2、知人善用；沒用的自動化會被拋棄

4.2 獲得專案和人員

 員工可以根據內部條件（滿18個月）自由選擇專案，專案經理也可以自己選擇。

4.3 影響力

晉升取決於員工對專案的影響力。組建測試團隊的目的就是讓他們發揮影響力。

4.4 Gmail測試工程經理Ankit Mehta的訪談

• 談論如何管理Gmail團隊；
• 管理下屬的同時，如何確保自己在技術上有所貢獻：

留一部分工作自己來完成，在設計階段會積極地參與，持續地跟進專案並且自己也編寫測試；

最關鍵的部分，每週都花一兩天的時間做自己的工作。

• 人員配備問題：絕不妥協。選用不合適的人來填充名額永遠要比等待合適的人員要糟糕。

• 經驗：

使用與應用程式開發語言相同的程式語言來編寫測試；

20%的用例覆蓋了80%的使用場景，把20%自動化而別管剩下的。把那些測試通過手工完成。

• TE和SET常會犯哪些錯誤；
• 在測試領域什麼東西會引發你的激情？快速建立一個高質量的產品。

4.5 Android測試工程經理Huang Dang的訪談

• Android專案最初的經歷；
• 團隊基調：創造價值。做的每一件事都要創造價值，並且能夠持續地創造價值。
• 團隊的組成以及對手工測試、自動化測試的分配。

4.6 Chrome測試工程經理Joel Hynoski的訪談

• 如何與瀏覽器關聯的各種外掛涉及的開發團隊進行溝通；
• Chrome如何進行測試；
• 面臨的最大的挑戰：變化多端的網際網路；
• Chrome測試的難點：相容性和UI自動化。
• 如何招聘以及對測試的理解。

4.7 測試總監

測試總監的自由度很高，管理方式也不盡相同。

總監負責批准招聘和轉崗，全面掌控測試團隊人事方面的各種問題。

發揮領導才能:建設強大的團隊，足夠的技術素養，具備創新意識，對Google的各項工具和基礎架構瞭如指掌。

以下采訪5位測試總監。

4.8搜尋和地理資訊測試總監Shelton Mar的訪談

• Google早期如何進行測試，如何轉型
• Google搜尋測試最難的部分是什麼？理解索引和搜尋演算法，理解整套系統是如何運作的。
• 接手一個新專案時，通常會怎麼做？

讓團隊思考：對被測系統來說，什麼是最重要的。

• 對自動化測試的理解以及如何進行測試。

4.9  工程工具總監Ashish Kumar的訪談

• 介紹工程工具團隊。工具集分為如下：

原始碼工具，管理原始碼，檢查程式碼風格；

開發工具；

構建框架，構建程式碼，分發到各語言開發的專案；

測試基礎架構；

本地化工具；

度量、視覺化和報表。

• 什麼工具想法是一開始不看好但最後成功的？大規模的持續整合。
• 什麼工具想法是一開始看好但最後失敗的？遠端結對程式設計。
• 如何宣傳工具：每週主持一次工程生產力工具播報的活動，展示我們工具。
• 對工具的理解。

4.10 印度Google測試總監SujaySahni訪談

• 印度在Google測試中的作用，以及目前參與了哪些專案；
• 對全球各地的軟體公司提供測試工程支援，有哪些經驗。

4.11 工程經理Brad Green訪談

• 對Google測試的看法，在Google做測試經理的感受；
• 介紹Feedback；

4.12 James Whittaker訪談

• 加入Google的過程，為Google帶來的變化，對Google的組織結構的感受；
• James所理解的Google成功的祕訣：技能、稀缺性4、自動化和迭代整合。
• 寫書的計劃；

第5章 Google軟體測試改進

5.1 Google流程中的致命缺陷

 第一個致命缺陷：測試成了開發的柺杖。

我們越不讓開發考慮測試的問題，把測試變得簡單，開發就越來越不會去做測試。

第二個致命缺陷：開發與測試的組織結構分離。

測試人員更關注自己的角色，而不是他們的產品。健康的組織的一個標誌是，人們會說“我在為Chrome工作”，而不是“我是測試”。

任何角色都不應該被過分強調。團隊的每個人都是在為產品工作，而不是為了開發過程中的某個部分。

第三個致命缺陷：測試人員往往崇拜測試產物勝過軟體本身。

測試的價值在於測試的動作，而不是測試產物。

測試人員必須把產品放在第一位。

第四個致命缺陷：產品經過最嚴格的測試釋出後，使用者有多大可能仍然發現測試中遺漏的問題？幾乎必然發現。

5.2 SET的未來

作者認為SET沒有未來。SET就是開發，與開發的待遇一致。

測試特性應該由團隊的新成員負責，特別是那些資歷尚淺的員工。

5.3 TE的未來

TE的需求量會越來越少。

測試工程會轉型成測試設計。少量的測試設計師快速地規劃出測試範圍、風險熱圖和應用程式的漫遊路線。可以識別需要專業技能的地方，比如安全性、隱私、效能和探索式測試。

5.4 測試總監和經理的未來

數量大幅減少。他們將作為思想領袖，為維繫鬆散的測試工程師和負責質量的軟體工程師的關係而存在，但不會最終為某個特別專案的質量或管理負責。

5.5 未來的測試基礎設施

目前Google的測試基礎設施是基於客戶端的，在測試建立和執行上花費昂貴的人工和機器建設成本。

測試基礎設施會最終整體遷移到雲端，使用更加開放、基於雲端計算的方式。測試用例庫、測試程式碼的編輯、錄製和執行等都將在一個網站或通過瀏覽器外掛完成。

附錄A Chrome OS測試計劃

附錄B Chrome的漫遊測試

附錄C 有關工具和程式碼的部落格文章

使用BITE從bug和冗餘的工作中解脫出來

釋出QualityBot

RPF：Google的錄製回放框架

Google測試分析系統（Google Test Analytics）

評論此書：

本書首先介紹了Google如何進行軟體測試，然後從軟體測試開發（SET）、軟體測試（TE）、測試經理的角度分別介紹。章節分配非常有條理，重點的句子作者會單獨標記出來，便於加深理解。有幾個觀點印象特別深。

首先，質量不僅僅是測試的事兒，開發也需要為質量負責任，這樣開發就會在測試過程中富有責任心。國內的軟體公司缺少這樣的想法，開發對質量完全不負責，不僅僅造成了產品質量差，還會加深開發與測試的矛盾。

測試人員如果在某個產品中工作滿18個月，可以無理由地自願轉崗到其他產品。給員工足夠的自由，體現民主精神。

Google對開發工具、進行自動化十分痴狂，一切工作都試圖使用自動化來完成。20%的時間是Google的一種制度，每週可以拿出一天時間，或者一週工作時間的20%來做自己選擇的專案，鼓勵員工進行創新、自己開發工具。Google之所以成為全球知名的公司，跟它對技術與創新的追求是分不開的。

訪談，本書分別對比較優秀的SET、TE和測試經理進行訪談，與他們談談對測試的想法、如何開展測試等等，從這點也可以看出Google很注重聽取大家的意見，與一般的技術類書籍相比，本書中訪談內容佔了很多篇幅，各個員工各抒己見，值得學習。

本書最後作者預測了下軟體測試的未來，普通的TE會越來越少，SET也會消失，由開發取代，測試會向測試設計和測試決策的方向發展。

綜上，推薦所有軟體從業人員讀一讀。