《How Google Test Software》閱讀體會

How Google Test Software 之 軟件測試開發工程師

本文是課程《軟件測試》的項目之一：Project #1: Reading a book，來自小組：Developer is tester

成員：吳家榮 景 濤 陳兆鵬 郭路文 樑華淇 何金嶽

展示PPT：http://slides.com/wujiarong/deck-1#/

Part 1: Summary of content

全書總分爲三個部分，五個章節

第一部分：簡單介紹了Google軟件測試的概念，角色，組織機構，流程以及測試類型。

第一章：Google軟件測試介紹

1. 在Google，軟件測試團隊屬於“工程生產力”的中心組織部門，其測試方法很可能是其他公司的模仿榜樣。測試與開發有時交織在一起有時又完全分離，這個Google有非常少的專職測試人員質量不僅僅是測試人員的問題，代碼的開發者本身就是測試者。停止開發與測試的隔離，質量不等於測試。
2. 角色，Google將開發過程與測試結合起來，並且創建了這些角色，包括：軟件開發工程師（SWE），軟件測試開發工程師（SET），測試工程師（TE），並且簡要的介紹了一下這些角色。
3. 組織機構，在Google，測試是獨立存在的部門，以租借的方式加入產品團隊。
4. 爬走跑，Google最初的版本只包括最基本的使用功能，然後不斷收集用戶反饋迭代升級的方式提高產品質量。分爲金絲雀版本（最基本的，用來篩掉明顯不適宜功能的版本）、開發版本（開發人員日常使用的版本）、測試版本（通過了持續測試的版本，可用作內部嚐鮮）和beta或發佈版本（對外發布的第一個版本），爲我們提供了一個測試驗證的良好機會。
5. 測試類型，分爲：小型測試（能自動化實現）、中型測試（自動化實現，會涉及到模塊間的交互）和大型測試（涉及更多的模塊，使用真實用戶使用場景和實際用戶數據）。

第二部分：分別介紹軟件測試中涉及的角色以及他們的主要作用

第二章：軟件測試開發工程師（SET）

1. 軟件測試開發工程師的相關工作內容，在單元測試方面給予開發人員支持，爲開發人員提供測試框架等。詳細介紹了SET的工作任務以及測試工作的流程，說明SET首先是工程師的角色，而且是軟件工程師，測試是應用產品的另一種功能，SET是這個功能的負責人；項目早期，Google不會讓測試過早介入；團隊結構，設計文檔，SET在推進項目的同時也簡化相關項目成員的工作；接口與協議，爲了儘早可以運行集成測試，SET提供了mock與fake；自動化計劃；可測試性，Google把代碼審查作爲開發流程的中心，SET成爲源碼的擁有者之一；並且通過一個實例真正介紹了軟件測試的流程；測試大小的定義，包括小型測試，中型測試和大型測試，介紹了不同規模的軟件測試在共享測試平臺的使用情況以及其優缺點。
2. 講述了推行測試工作所採用的“測試認證”方法–通過完成測試任務獲得“認證”標識，從而激勵開發人員參與到測試工作中；與測試認證創始人的訪談。
3. 關於SET招聘的一些描述，面試重點在考察候選人如何思索問題的解決方案，一個優秀的SET會自然的去考慮測試代碼。
4. 最後記錄了與工具開發工程師Ted Maori和Web Driver的創建者Simon Stewart的訪談，他們方便開發出優秀的測試框架與測試工具。

第三章：測試工程師（TE）

1. 測試工程師（TE）的重點在於評估產品對用戶的影響以及軟件產品整體目標上的風險。TE的不僅有軟件技術的開發能力，更重要的是TE還有以用戶爲中心檢查軟件質量而對開發者產生一定製約的能力。
2. 測試工程師是一種面向用戶的測試角色，TE首先是以某種最合適的方式發現軟件風險最大的地方並且嘗試減少或者消除。
3. 測試工程師的工作，研發的早期階段，TE的工作並沒有多少，TE進入產品，SWE和SET已經在測試技術和質量方面做了大量的工作，可以作爲TE的起點，TE會介入項目的各個階段，TE通常是團隊裏面最出名的人，需要敏銳的洞察力和領導力。一般來說，TE的職責有測試計劃和風險分析、評審需求,設計,代碼和測試、探索式測試、用戶場景、編寫/執行測試用例和使用統計/用戶反饋，TE更主要的工作是暴露風險.如果不能全測,就測試最重要的,這是一個原則。
   測試計劃是最早出現最先被遺忘的測試產物，ACC（Attribute Component Capability，特質，組件，能力）是測試計劃的替代方法。風險包括風險分析與風險緩解十分鐘測試計劃（The 10-Minute Test Plan by James Whittaker）和衆包（Crowd-Sourcing）；測試用例以及bug 的生命週期，Google對bug的管理獨一無二，bug的數據庫完全開放，通過比作小孩介紹了bug的一生；介紹了TE的招聘以及Google測試領導和管理工作；通過Google Desktop的事例介紹了維護模式的測試還介紹了質量機器人實驗與BITE實驗，還有Google Test Analytic和零成本測試流程以及外部供應商。
4. 收錄了與Google Docs測試工程師Lindsay Webster和YouTube測試工程師Apple Chow 談話記錄。

第四章：測試工程經理（TEM）

1. 測試工程經理的工作，TEM負責所有的支持團隊之間的聯絡，把TE和SET聯繫起來，要擁有技術能力，領導能力以及協調能力，是相關項目中最強的產品專家。TEM要了解自己的產品並且知人善用，優化項目工程。
2. 獲得項目和人員，管理着資源配置的流程，獲得新的項目。
3. 影響力，測試工程經理要讓團隊具有影響力，要幫助工程師發揮自身相應的影響力，處理跨團隊的溝通；
4. Gmail的測試經驗和.Android測試經驗還有Chrome的測試經理的訪談都告訴我們了測試工程經理的重要性以及開發測試中的捷徑和開發測試的動力所在。還收錄了與搜索地理信息測試總監，工程工具總監以及印度Google測試總監和工程經理等人的訪談

第三部分：簡要介紹Google的測試缺陷以及改進的方向

第五章：Google軟件測試改進

1. Google流程中的致命缺陷，測試成了開發的柺杖，開發與測試的組織結構分離測試人員崇拜測試產物勝過軟件本身。最深刻的致命缺陷就是最嚴格的測試發佈之後，用戶還是必然會發現測試遺漏的問題。
2. SET這個角色最終會和軟件開發工程師變爲一個角色；TE這個角色的工作已經有了更爲全面且低成本的替代形式；相應的測試總監和經理的數量將會大幅減少。
3. 未來Google的測試基礎設施將會使用更加開放、基於雲計算的方式進行測試更加經濟。
4. 集中測試部門的工程師經理和總監分散到各個更加關注項目的團隊和職責崗位之上，更少關注測試流程，更多關注產品本身，熟知和喜愛的測試方式即將終結。

附錄

介紹了Chrome OS 的測試計劃 和Chrome 的漫遊測試以及相關工具和代碼的博客文章還有術語表。

Part 2: Educational value of material

對我們來說，本書介紹的三種角色是最讓人印象深刻的。
分別是：軟件開發工程師（SWE，Software Engineer），軟件測試開發工程師（SET，Software Engineer in Test）和測試工程師（TE，Test Engineer）。
在學習測試和閱讀《How Google Test Software》以前，對我們來說，軟件產業只有一種工程師，那就是開發工程師。
這種想法不免幼稚和無知，但我們確實存在過這樣的想法。

從本書的組織來看，本書的主線就是分別介紹幾種不同的角色：軟件測試開發工程師、測試工程師、測試工程經理。

爲了決定我們小組在這一部分要寫什麼內容。我們先看看這些角色都在負責那些內容的工作。

軟件開發工程師（SWE）
《HGTS》：軟件開發工程師是一個傳統上的開發角色，他們的工作室實現最終用戶所使用的功能代碼。

軟件測試開發工程師（SET）
《HGTS》：軟件測試開發工程師，也是一個開發角色，只是工作重心在可測試性和通用測試基礎框架上。

測試工程師（TE）
《HGTS》：測試工程師是一個和SET關係密切的角色，有自己不同的關注點—把用戶放在第一位來思考，代表用戶的利益。

測試工程經理（TEM，Test Engineering Manager）
《HGTS》：測試工程師和測試開發工程師分別致力於支持用戶和開發工程師。另外還有一種角色可以把這兩者聯繫起來，那就是測試工程經理（TEM）。測試工程經理是作爲獨立貢獻者的一個技術崗位，負責所有的支持團隊（開發、產品管理、產品發佈、文檔等）之間的聯絡。

介紹完這幾種角色，要是粗暴地總結一下本書講了什麼內容，我可以說，就講了上面的內容。
再次說明，本書的組織架構就是這幾種不同的角色是如何在Google的代碼生產上發揮作用的。

跨越多種角色的東西或人對我們來說吸引力是最大的，也很容易讓人產生某些困惑。
就像本書所介紹的陌生的角色：SET，軟件測試開發工程師。

爲了讓本部分的內容產生深度上的價值，而不是廣度地泛泛而談，我們打算圍繞《HGTS》詳細介紹一下軟件測試開發工程師這個角色。

Google的開發發佈模式
在瞭解Google是如何做測試之前，我覺得先要了解Google是如何做開發的。

《HGTS》介紹，Google有一種“爬、走、跑”的開發發佈模式。

也就是說，Google從來不會再一次產品中發佈大量的功能，實質上，在一個產品的基本核心功能實現之後，就立刻對外發布使用，然後從用戶哪裏得到真實反饋，再進行迭代開發。

實質上這個模式能加速迭代開發的流程，而且對於開發的新功能來說，很快能得到用戶的反饋，如果受到用戶的歡迎，就根據用戶的反饋進行改進，如果用戶覺得功能多於，就能馬上拋棄掉，並且停止進行這個方向或者支路的開發。這實質上能使Google的開發效率得到很大的提高。

Google這樣的開發模式，形成了Google風格的各種開發過程的版本。

金絲雀版本：這是每日都要構建的版本，用來排除過濾一些明顯不適宜的版本。
開發版本：這是開發人員日常使用的版本，一般是每週發佈一個。
測試版本：這是和次序測試的版本。
Beta或發佈版本：這個版本是由非常穩定的測試版本演變而來，經歷了內部使用和通過所有質量考覈的一個版本，也是對外發布的第一個版本。

毫無疑問，軟件開發工程師（SWE）在以上的版本構建和開發過程中，扮演的是一個功能開發者的角色。這是一個很重要的角色，因爲用戶需求的功能，都要由他們來實現。

那麼，軟件測試開發工程師在其中擔任了什麼任務呢？爲什麼他們和軟件開發工程師的地位是一樣的？爲什麼招聘SET比招聘SWE更難呢？

軟件測試開發工程師（SET）

SET描述

先來引用《HGTS》一句關於SET的描述的話。

“SET首先是工程師的角色，他使得測試存活於先前討論的所有Google開發過程之中。SET是軟禁啊測試開發工程師。最重要的一點，SET是軟件工程師，正如我們招聘宣傳海報和內部晉升體系中所說的那樣，是一個100%的編碼角色。“
“測試時應用產品的另一種功能，而SET就是這個功能的負責人。”

既然把測試頁歸類爲應用產品的一種功能特性，那毫無疑問，用一句話概括SET就是，懂開發的測試工程師，SET開發的是測試產品，是與產品本身息息相關的測試相關的功能產品。

項目的早期階段

Google內部有一種文化氛圍：公司鼓勵內部員工利用自己的20%的工作時間來做一些富有創造性的工作。
實質上，Google的很多產品，都源於員工的20%的工作，它們很多是由是被證明了有價值，然後由業餘產品轉變成爲公司的業務型產品。

但是，在這個轉變的過程中，是否需要保證產品的質量呢？

《HGTS》說，在這個階段，功能遠比質量重要。

“一個產品如果在概念上還沒有完全確定成型時就去關心質量，這是優先級混亂的表現。許多來源於Google20%努力的產品原型，在其以後的dogfood或beta版本發佈時，還有經歷重新設計，原始代碼保留的概率幾乎爲零。很明顯，在實驗初期階段強調測試是一件非常愚蠢的事情。”

這個思想很重要，因爲在明確這樣的產品是否有價值之前，投入大量的精力去關心質量問題，就浪費很多資源。

從主觀的角度來看，則是，產品被證明有價值之前，難以吸引SET的關注。

自動化計劃

SET需要做的東西很多，讓項目進行自動化測試的計劃是他們的目標。

有一個原則是，自動化計劃必須合情合理且有影響力。

爲了實現自動化測試，SET遵循的原則是：

首先，吧容易出錯的接口做個裏，並針對他們創建mock和fake（mock失職對外面依賴系統的模擬，在運行時刻可以根據假設的需求提供期望的結果；fake對象是一種虛假的實現，內部使用了固定的數據或邏輯，只能返回特定的結果）

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

可測試性

可測試性的構建是把SWE和SET緊密聯繫起來的任務。

可以這樣簡單地理解SWE和SET對項目的可測試性的貢獻。SET的目標是，對於項目產品每一次修改，對代碼的每一次提交，對於SWE的每一次努力和嘗試，都能快速對更改進行檢查，構建，驗證更改是否存在問題，代碼是否存在bug。然後以一種最高效的方式，把相應的反饋信息發送給代碼的變更者。

測試大小的定義

爲了測試方便，Google自己定義了一套測試命名規則。
小型測試：驗證代碼單元的功能，通常是單元測試。
中型測試：驗證兩個或者多個模塊應用之間的交互。
大型測試：驗證系統作爲一個整體是如何工作的。

測試大小定義的應用

測試工程師的招聘

一言以蔽之：既要動開發，也要懂測試。

閱讀最大的收穫

做每一件事情，都應該是有一定的目的，否則便是毫無方向感。每一次經歷，都應該能察覺經歷給自己帶來了什麼。

對此書的閱讀，我們覺得，給我們帶來的有兩點非常深刻的體會和收穫。

其一，提交隊列與持續集成

最近參與了一個項目。扮演的是一個web架構師和技術負責人的角色。

我們使用gitlab作爲遠程倉庫，使用git進行版本管理，使用git的分支來實現協同開發。

項目剛開始不久，web服務部分我們還沒有比較強烈的測試意識，都是功能導向性的開發，以完成一個具體的功能爲開發階段性標準。

我們控制代碼質量和每次提交的功能完整性的方式就是，直接人工檢查。

應該說，這樣的開發流程是比較原始的。沒有實現自動化構建和自動化測試。沒有充分利用gitlab的自動化構建和持續集成的功能。

可能這次閱讀帶來的影響就是，讓我們團隊有一種傾向和意識，去實現這樣的一種構建和集成。

其二，web自動化測試

作爲一名web前端開發工程師，之前沒有嘗試過在前端方面的測試。按照之前的開發經歷，覺得web前端好像沒法進行自動化測試。因爲基本上都是UI操作，很難確定輸入和輸出。只能進行人機交互，人工確定邏輯的正確性和流程的正確性。

直到閱讀了本書的一個關於webdriver項目創始人的一個訪談。才知道原來web前端的自動化測試並不是不可能的，而是已經有了具體的嘗試和實現了！

這個認知對於我來說確實是一個巨大的驚喜。

我將會嘗試去學習webdriver並且努力把web自動化測試應用到具體的項目當中。

Part 3: Recommendation

《Google軟件測試之道》是極有價值的一本書，因此我認爲值得向大家推薦這本書。很久以來，軟件測試的理論和實踐的發展一直處於資源和人力相對不足，工作內容的邊界也很模糊的狀態。其他關於軟件測試的書籍往往存在的的問題是，站的位置不是太高就是太低。以學術口吻寫就、工程人員一看就感覺與己無關者有之；以自己的實際工作經驗爲基礎，但是並未形成有效的理論者有之；泛泛而談的理論家憑藉相當的想象寫就，但是既沒有實例也沒有工具者有之——一言以蔽之，光說了一堆測試這件事應該怎麼做，但是並沒有看到測得什麼優秀的產品，也沒有在這個過程中發展出工具、理論和文化來。

而《Google軟件測試之道》的不同之處首先在於，IT巨頭已經生產出來的軟件產品，其成功是婦孺皆知的。那麼，以這些產品的生產過程作爲軟件開發生命週期中的模範，應該是不僅比較正確，而且也是更有溝通基礎的，因而也是更有價值的。軟件測試作爲軟件開發生命週期中接觸點最多的一環，通過這本書，可以看到這些IT巨頭們是怎麼做的——它們怎樣設計配套的公司組織結構、怎樣處理軟件測試和其他生命週期環節的關係、基於怎樣的思想來實施工程實務、開發了怎樣的支撐環境和工程工具……這一系列的問題，看看微軟和Google給出的答案，讀者就可以知道，在目前的軟件和硬件條件下，理想的，或者說是最高水平的軟件測試已經達到了一種怎樣的程度，從而在規劃自己軟件測試相關的團隊配置和工程技術實務時，有了非常重要的參考。

讀完《Google軟件測試之道》又讓我看到了一些新的東西，這主要是軟件交付模式從盒裝變爲在線帶來的，因而時間特性從離散變爲持續、空間特性從單一變爲多元，軟件測試爲了適應這些變化，必須一方面在概念上變得更靈活，另一方面卻要在執行上卻要變得更簡單有效。這兩個相互矛盾的要求，對軟件測試的管理和執行人員都提出了極大的挑戰。毫不意外地，我看到這本書在基礎層面上與傳統的盒裝軟件測試有着同樣的測試目標：高可用性、高性能、優化的用戶體驗，但是在概念和技術上卻發生了鉅變，我誠摯地請讀者們重點關注一下這本書對於測試規模的論述，以及性能測試工具的設計思想，信息量很大。另外，認真研習一下附錄的兩份測試計劃，也會有不小的收穫。

最後，真誠地向大家推薦《Google軟件測試之道》，這絕對會使你受益匪淺。