Google軟體測試介紹

軟體測試團隊->工程生產力(Engineering Productivity)

http://googletesting.blogspot.com/2011/01/how-google-tests-software.html

1.1 質量不等於測試

質量不是被測試出來的，質量不等於測試，每寫完一段程式碼立刻測試這段程式碼，當完成更多的程式碼時做更多的測試，直到開發和測試融為一體，才能得到質量。

1.2 角色

"You build it, you break it, you fix it"

軟體開發工程師(SWE: Software Engineer)

增加功能性的程式碼或提高效能的程式碼

對容錯設計、故障恢復、測試驅動設計、單元測試負責

軟體測試開發工程師(SET: Software Engineer in Test)

關注於質量的提升和測試覆蓋率的增加，增加可測試性，甚至進行程式碼重構，編寫單元測試框架和自動化測試框架

提供測試支援

軟體測試工程師(TE: Test Engineer)

專注於使用者角度的測試，模擬使用者使用場景、編寫自動化指令碼或程式碼，組織各種型別的測試，分析、解釋測試執行結果，驅動測試執行

模組級別和功能級別的測試應有SWE和SET完成

TE需要確認開發人員的測試工作是否到位，任何明顯的bug都表明早期開發人員的測試工作存在不足或比較馬虎

TE應更注意常見使用者使用場景，是否滿足效能期望，在安全性、國際化、訪問許可權等方面是否滿足使用者需求

與各方討論基本設計帶來的風險、功能邏輯複雜性和錯誤避免的方法

1.3 組織結構

一般，測試和開發人員隸屬於同一個工程產品團隊，管理者通常來自產品經理或開發經理，測試總是給開發讓路

SET和TE沒有遵循這個模式，測試成為一個獨立的部門，平行於各個產品部門，測試人員以租借的方式進入產品團隊，不直接向產品團隊彙報

1.4 爬、走、跑

Google在一個產品的核心功能實現後立即釋出，然後根據使用者反饋再進行迭代

Chrome開發過程中的版本：

金絲雀版本：每日構建，排除明顯不適宜的版本，這個版本可能無法使用應有的基本功能

開發版本：開發人員日常使用的版本，每週一個。具備一定的功能並通過了一系列的測試。所有相關的工程師都需安裝，在日常使用，如不滿足日常工作的需求，會被打回金絲雀版本

測試版本：通過了持續測試的版本，是最近一個月裡最好的版本，也是工程師在日常使用中最穩定最信任的版本。可作為內部嚐鮮(dog food)版本，若變現持續優良，可作為beta版本的候選

beta版本或釋出版本：有非常穩定的版本演變而來，經歷了內部使用和通過了所有質量考核

1.5 測試型別

小型測試

一般都是自動化實現的，用來驗證一個單獨函式或獨立功能的程式碼是否按照預期工作，著重於典型功能性問題、資料損壞、錯誤條件和大小差一(off-by-one)等錯誤

執行時間短，通常在幾秒或更短的時間內完成

由SWE來實現，少量有SET參與，TE幾乎不參與，但TE會執行這些測試

測試一般需使用mock和fake才能執行

mock物件是指對外面依賴系統的模擬，在執行時刻可以根據假設的需求提供期望的結果

fake物件是一種虛假的實現，內部使用來固定的資料和邏輯，只能返回特定的結果

中型測試

一般也都是自動化實現的，會涉及兩個或兩個以上的模組之間的互動

測試重點在於驗證這些“功能近鄰區”之間的互動，以及彼此呼叫時功能是否正確

SET會驅動這些測試的實現和執行，SWE會深度參與，編碼、除錯和維護這些測試，開發後期，TE會通過手動或自動的形式執行這些測試

大型測試

涵蓋三個或以上的模組，使用真是使用者使用場景和實際使用者資料

一般需消耗數小時或更長時間才能執行完成

SWE、SET、TE都會參與其中

關注端到端的使用場景以及在整個產品或服務之上的操作行為

小中大型測試，相當於單元測試、整合測試和系統測試

能夠自動化的應以自動化的方式實現，包括日常工作

迴歸測試中手動部分可通過定點點選或錄製技術實現自動化，手動測試更傾向於關注新功能