? ? 測試不能成為導致創新和開發過程變慢的阻礙。質量從來不僅僅是測試人員的問題，在Google，每個寫代碼的開發者本身就是測試者。

? ? 1）質量不等于測試

? ? 質量更像是一種預防行為，而不是檢測。質量是開發過程的問題，而不是測試問題。當開發過程和測試一起攜手聯姻時，即是質量達成之時。

? ? 2）角色

? ? 軟件開發工程師（Software Engineer, SWE）,他們的工作是實現最終用戶所使用的功能代碼。SWE會對他們編寫、修復以及修改的代碼承擔質量責任。

? ? 軟件測試開發工程師（Software Engineer in Test，SET），他們的工作重心在可測試性和通用測試基礎框架上。

? ? SWE關注于功能性或性能性代碼，而SET關注于質量提升和測試覆蓋率的增加。SET寫代碼的目的是可以讓SWE測試自己的功能。測試工程師（Test Engineer,TE）把用戶放在第一位來思考，代表用戶的利益。他們會把SWE和SET編寫的測試進行組織、分析、解釋、測試運行結果，推進產品發布。TE是真正的產品專家、質量顧問和風險分析師。

? ? SWE和SET主要是模塊級別與功能級別的測試。TE則關注于用戶角度的測試，另外確認開發在測試方面的工作是否到位。

? ? 3）組織結構

? ? 測試團隊是獨立存在的部門，是與專注領域部門平行的部門。測試團隊，會根據不同產品團隊的優先級、復雜度等進行比較后，分配測試人員。這樣可以保證測試人員方便在各個團隊推廣測試技術，并讓產品團隊無權降低測試人員的招聘要求。另外，Google對于在某個產品中工作滿18個月后的測試人員，可無理由自愿轉崗到其他產品。

4）爬、走、跑

? ? Google從來不會在一次產品發布中包含大量的功能，實際上，在一個產品的基本核心功能實現之后，就立即對外發布使用，然后從用戶那里得到真實反饋，再進行迭代開發。為了發布beta版本，一個產品要經歷一系列的內部版本驗證。

? ? 金絲雀版本：每日構建，產品相關的人才會安裝這個版本。

? ? 開發版本：每周構建，該版本具有一定的功能并通過了一系列的測試，該產品下的所有人會要求安裝這個版本。

? ? 測試版本：差不多每月構建，該版本通過了持續測試，比較穩定，公司內部可使用，一些想早合作的外部合作伙伴也會使用這個版本。

? ? beta或發布版本：對外發布的第一個版本，通過了內部使用和所有質量考核的一個版本。

? ? 5）測試類型

? ? 小型測試，用于驗證一個單獨函數或獨立功能模塊的代碼是否按照預期工作。主要是SWE實現，也會有少量的SET參與。

? ? 中型測試，一般會涉及兩個或兩個以上模塊的交互，嘗試解決的問題是，一系列臨近的模塊互相交互時，是否如預期那樣。在開發早期，主要是SET驅動這些測試的實現，SWE深度參與；在開發后期，TE會通過手動方式或自動化執行這些用例。

? ? 大型測試，涵蓋三個或更多功能模塊，使用真實用戶使用場景和實際用戶數據，一般可能需要消耗數小時或更長的時間才能運行完成。關注點在于所有模塊的集成，更傾向于結果驅動。三種工程師均會參與到大型測試中。

? ? 關于自動化與手動測試，當然更傾向于前者。如果能夠自動化，并不需要人腦的睿智與直覺來判斷，那就應該自動化。Google甚至把開bug和日常的手動工作都自動化實現了，例如，如果自動化用例運行失敗，會直接找到最后一個Commit的人，并給此人發一封郵件，并開一個bug來記錄。

? ? 總而言之，看完第一章，對文章中的一些理念與操作所震驚到了~