1、在Google，軟件測試團隊歸屬於一個被稱為“工程生產力”(Engineering Productivity，工程效率或工程生產率)的中心組織部門，這個部門的職責橫跨開發測試人員使用工具的研發、產品發布和各種級別的測試，從單元級別的測試到探索性級別的測試。Google擁有大量針對互聯網產品的共享工具與測試基礎框架，服務於包括搜索、廣告、Apps、YouTube視頻和其他我們在Web上提供的產品。

2、Google是一家以創新和速度為基礎的公司，快速地發布有用的代碼(如果失敗，也只有少數早期用戶會失望)、叠代地增加早期用戶希望使用的功能(最大化用戶反饋)。在這樣的環境下，測試不得不變得異常靈活，並且在技能上要做許多前期的規劃，只是不停地簡單維護並不能真正解決問題。有時，測試和開發互相交織在一起，達到了無法區分彼此的程度，而在另外一些時候，測試和開發又是完全分離，甚至開發人員都不知道測試在做些什麽。

3、當有人來問我，Google成功的關鍵是什麽，我的第一個建議就是，不要招聘太多的測試人員。

4、質量不等於測試，當你把開發過程和測試過程放到一起，就像在攪拌機裏混合攪拌那樣，知道不能區分彼此的時候，你就得到了質量。

5、測試時開發過程中必不可少的一部分，當開發過程和測試一起攜手聯姻時，既是質量達成之時。

6、角色

(1)軟件開發工程師(SWE)：工作是實現最終用戶所使用的功能代碼。他們創建設計文檔、選擇最優的數據結構和整體架構，並且花費大量時間在代碼實現與代碼審核上。SWE需要編寫與測試代碼，包括測試驅動的設計、單元測試、參與構建各種大小規模的測試等。SWE會對他們編寫、修復以及修改的代碼承擔質量責任。

(2)軟件測試開發工程師(SET)：工作中心在ke‘ce‘shi‘xing 和通用測試基礎框架上。他們參與設計評審，非常近距離的觀察代碼質量和風險。為了增加可測試性，他們甚至會對代碼進行重構，並編寫單元測試框架和自動化測試框架。SET是SWE在代碼庫上的合作夥伴，相比較SWE是在增加功能性代碼或是提高性能的代碼，SET更加關註於質量提升和測試覆蓋率的增加。

(3)測試工程師(TE)：是一個和SET關系密切的角色，有自己不同的關註點——把用戶放在第一位來思考，代表用戶的利益。一些Google的TE會花費大量時間在模擬用戶的使用場景和自動化腳本或代碼的編寫上。同時，他們會把SWE和SET編寫的測試分門別類地組織起來，分析、解釋、測試運行結果，驅動測試執行，特別是在項目的最後階段，推進產品發布。TE是真正的產品專家、質量顧問和風險分析師。

7、組織結構

(1)Google的組織匯報關系被劃分為不同的專註領域(Focus Areas)。這些專註領域包括客戶端(Chrome、Google工具欄等、地理(地圖，Google Earth等)、廣告、Apps、移動等等。所有的開發工程師都匯報給這些專註領域的管理者、總監或副總裁。

(2)測試是獨立存在的部門，是與專註領域部門平行的部門(橫跨各個產品專註領域)，我們稱為工程生產力團隊。測試人員基本上以租借的方式進入產品團隊，去做提高質量相關的事情，尋找一些測試不足的地方，或者公開一些不可接受的缺陷率數據。由於測試人員並不是直接向產品團隊進行匯報，因此我們並不是簡單地被告知某個項目急需發布就可以通過測試。我們有自己選擇決定的優先級，在可靠性、安全性等問題上都不會妥協，除非碰到更重要的事情。工程生產力團隊會根據不同產品團隊的優先級、復雜度，並與其他產品實際比較之後，再來分配測試人員。

8、爬，走，跑

(1)Google經常在最初的版本裏只包含最基本的可用功能，然後再後繼的快速叠代的過程中得到內部和外部用戶的反饋，而且在每次叠代地過程中都非常註重質量。一個產品在發布給用戶使用之前，一般都要經歷金絲雀版本、開發版本、測試版本、beta或正式發布版本。

(2)金絲雀版本：這是每日都要構建的版本，用來排除過濾一些明顯不適宜的版本。一般來說，只有這個產品的工程師(開發或測試人員)和管理人員才會安裝使用金絲雀版本。

(3)開發版本：這是開發人員日常使用的版本，一般是每周發布一個。該版本具有一定的功能並通過了一系列的測試。所有這個產品下的開發人員都會被要求去安裝這個版本，並在日常工作中真正使用它，這樣可以持續對這個版本進行測試。如果一個開發版本不能滿足日常真實工作的需求，那麽它將會被打回為金絲雀版本。

(4)測試版本：只是一個通過了持續測試的版本。這個版本基本上是最近一個月裏的最佳版本了，也是工程師在日常生活中使用的最穩定最信任的一個版本。測試版本可以被挑選作為內部嘗鮮版本，如果該版本有比較持續的優良表現，也是作為beta測試的候選版本。

(5)beta或發布版本：這個版本是由非常穩定的測試版本演變而來，並經歷了內部使用和通過所有質量考核的一個版本，也是對外發布的第一個版本。

9、測試類型

(1)小型測試一般來說都是自動化實現的，用於驗證一個單獨函數或獨立模塊的代碼是否按照預期工作，著重於典型功能性問題、數據損壞、錯誤條件和大小差一錯誤(off-by-one錯誤是一種常見的程序設計錯誤)等方面的驗證。小型測試的運行時間一般較短，通常是在幾秒或更短的時間內就可以運行完畢。通常，小型測試是由SWE實現，也會有少量的SET參與，TE幾乎不參與小型測試。小型測試一般需要使用mock和fake(mock對象是指對外面以來系統的模擬，在運行時刻可以根據假設的需求提供期望的結果，fake對象是一種虛假的實現，內部使用了固定的數據或邏輯，只能返回特定的結果)才能運行。TE幾乎不編寫小型測試代碼，但會參與運行這些測試，來診斷一些特定錯誤。小型測試主要嘗試解決的問題是“這些代碼是否按照預期的方式運行”。

(2)中性測試通常也都是自動化實現的。該測試一般會涉及兩個或兩個以上，甚至更多模塊之間的交互。測試重點在於驗證這些“功能近鄰區”之間的交互，以及彼此調用時的功能是否正確(我們城功能交互區域為"功能近鄰區")。在產品早期開發過程中，在獨立模塊功能被開發完畢之後，SET會驅動這些測試的實現及運行，SWE會深度參與，一起編碼、調試和維護這些測試。如果一個中型測試運行失敗，SWE會自覺地去查看分析原因。在開發過程的後期，TE會通過手動的方式(如果比較難去實現自動化或實現的代價較大時)，或者自動化地去執行這些用例。中型測試嘗試去解決的問題是，一系列鄰近的模塊互相交互的時候，是否如我們預期的那樣工作。

(3)大型測試涵蓋三個或三個以上(通常更多)的功能模塊，使用真實用戶使用場景和實際用戶數據，一般可能需要消耗數個小時或更長的時間才能運行完成。大型測試關註的是所有模塊的集成，但更傾向於結果驅動，驗收軟件是否滿足最終用戶的需求。所有的三中工程師角色都會參與到大型測試之中，或是通過自動化測試，或是探索式測試。大型測試嘗試去解決的問題是，這個產品操作運行方式是否和用戶的期望相同，並產生預期的結果。這種端到端的使用場景以及在整體產品或服務之上的操作行為，即是大型測試關註的重點。

第一章 Google軟件測試介紹