《Google軟體測試之道》這本書想必很多做測試的人都聽過，但不一定看過，今天小編轉載了一篇該書的讀書筆記大綱，方便沒讀過的人對該書有個大概的了解。
少則清晰，測試人員的稀缺導致測試資源很昂貴。（不要招聘太多的測試人員）
開發對質量負責（預防，不行為是檢測）
衛生間張貼著最佳測試實踐
- 100%時間在編寫代碼，SET和SWE是合作夥伴
- 工作重心在可測試性和通用測試基礎框架
- 參與設計評審
- 為了增加可測試性，甚至會對代碼重構
- 關注質量提升和測試覆蓋率增加
- 產品專家，質量顧問和風險分析師
- 大量時間在模擬用戶的使用場景的代碼上。
測試是獨立的部門（工程生產力團隊），以租借的方式進入產品
不同項目組的借調，時刻保持新鮮感，也方便好的測試想法快速蔓延。
推廣創新技術，直接借調創新的發明者是一個很好的辦法
金絲雀版本（每日構建）
開發版本（每周）
測試版本（每月最佳）
發布版本（穩定的測試版本）
Google用小型，中型，大型測試（對應我們的單元，集成，系統測試）
小型測試
函數或模塊，需要使用mock、fake
中型測試
模塊之間的交互
大型測試
真實用戶場景和數據
理想的軟體世界，有test harness， test infrastructure，mock and fake任你使用（如，模擬的資料庫）
測試代碼的主要思路是去破壞，怎樣寫測試代碼以擾亂分離用戶及其數據
公共庫，共享代碼。可復用性大於功能複雜性和設計巧妙性
公共模塊必須經過審核
開發人員有編寫出乾淨代碼的記錄，會被授予「良好可讀性」證書
每種語言都有統一的編譯器（類似我們的統一開發伺服器）
構建系統使用統一的打包規範（和語言無關，Linux rpm）
一個產品有多個服務組成，服務之間並行開發，項目早期定下服務之間的接口。早期測試，接口都是虛假的實現
SET非常難招聘（又懂開發又懂測試）
「只有軟體產品變的重要的時候質量才顯得重要」
產品早期一般不投入測試（可能重新設計），正式批准後，才會尋求測試資源。
項目初期，設計文檔(動態更新)
SET有一個巨大的優勢，就是產品方面最寬廣的視野
SET審核初期階段的設計文檔
接口、協議，採用protocol buffer
可測試性如何，是否需要新增testing hook（為了測試增加接口，顯示系統內部狀態）
protocol buffer定義的接口和協議由SET實現（SET第一個實現所有的接口和協議），集成測試的運行依賴這些接口，因此SET針對各個模塊的依賴提供了mock和fake
試圖自動化所有端到端的測試用例，是一個常見的錯誤（SWE也不會感興趣）
自動化投入越多，維護成本越大。自動化計劃，應該規模更小，目的性更強
端到端的自動化測試投入過度，會把產品特定功能綁定在一起，產品穩定之前都不會特別有用。SET應該投入到提高質量，而不是維護不穩定的測試套件上。
SET第一要務是可測試性，提供程序結構和代碼風格建議給開發人員
代碼審查需要工具和文化的支持，google將代碼審查作為開發流程的中心，代碼審查比編寫代碼更值得炫耀。
只有被證明是值得信賴的開發者，才有往代碼庫提交代碼的資格。用「可讀性」區分有資格的提交者和新開發人員。
CL（change list），持續提交優秀的CL，獲得「可讀性」的代碼審查資格。
自動化檢查代碼風格是否符合要求
在與外部公共庫（或框架）有交互的地方需要依賴集成測試
項目成員輪流做「構建警察」(我們可以借鑑，每人輪流跟蹤jenkins的輸出）
TAP(Test Automation Program)
google可以做到修改一個代碼，只跑這個模塊關聯的單元測試
（基於googletest，樣例中，將_test後置xxxx.cc（正式文件），xxxx_test.cc（測試文件））
只有能加速開發過程的自動化測試才有意義，測試不應拖慢開發的速度
新增測試程序，會創建一個構建說明文件（測試名稱，源碼文件，依賴庫及數據，規模大小）。工程師通過一條指令即可觸發構建、運行自動化和展示結果
小型測試，外部服務（文件系統，資料庫，網絡）必須通過mock和fake裡實現
中型測試，主要目標是驗證指定模塊之間的交互
測試規模在共享測試平臺的使用
資源
小型測試
中型測試
網絡服務
模擬
僅本地
資料庫
模擬
是
訪問文件系統
模擬
是
訪問用戶界面系統
模擬
不鼓勵
系統調用
否
不鼓勵
多線程
不鼓勵
是
睡眠狀態
否
是
系統屬性
否
是
強制時間限制
1分鐘
5分鐘
google維護著不同測試類型之間的健康比例，全部使用大型的端到端自動化測試是錯誤；全部使用小型的單元測試也是錯誤的
不同類型的測試都有覆蓋率報告（命令行加一個選項即可在瀏覽器查看覆蓋率）
經驗法則：70%是小型；20%是中型；10%是大型
如果面向用戶，集成度高，用戶接口複雜，增加中大型測試比例
基礎平臺或面向數據，增加小型測試比例
(google的Harvester是一個可視化工具）
可以設置一個標記以隨機順序執行用例（任意順序也意味著可以並發）
google的持續集成做了優化，利用依賴分析技術，一個代碼變更只運行影響模塊的測試
對開發人員做測試這個文化有巨大的幫助
測試認證是一個富有聲望的事情，從1級到5級（有徽章，可以炫耀）
（1-5級對應的內容在書的Page55,56）
級別1：基本操作，還有去除所有非確定性測試（結果不確定的測試），挑選冒煙測試；
級別2：提高增量覆蓋率
級別3：測試新增代碼
級別4：測試歷史遺留代碼（針對可測試性做重構）
級別5：更高的覆蓋率，每個缺陷對應增加測試用例
通過ToTT（Testing on the Toilet）和其他活動把測試搞得充滿激情、趣味和吸引力，包括fixit
針對沒有」測試時間」的狀況，尋找下面的團隊：有興趣；沒有太多冗餘代碼；有測試戰神
試點項目，測試教練幫助團隊，各種宣傳，積分系統等
團隊的測試認證級別代表提高測試的重視程度，是工程生產團隊決定是否投入有限測試資源的重要參考指標
最困難的一步「所有的重要代碼變更，都需要測試」，遺留代碼缺少可測試性（長遠角度就是重構增加可測試性）
如何用acount(void *s)返回字符串中』A』的次數，有詳細的區分普通、更好、優秀的候選人的方法（Page63-67）（這個可以借鑑，嚴）
TE starting from middle（從頭介入不適用於google，因為早期功能不斷變化，TE沒有太多工作可做）
配備多少測試人員，取決於項目風險和投資回報率
Google只有少數團隊採用word文檔通過郵件來傳遞（很老派）
google的文化是分布式和自我管理（大政府理念會受到嘲弄）
ACC（AttributeComponent Capability）是測試計劃的替代方法
Attribute是區別於競爭對手的關鍵。測試用例關聯到這些標籤，就知道哪些Attribute已經完成多少測試。
Attribute和Component要求簡潔，Capability描述完整的功能
能力最重要的一個特點就是可測試性
Attribute作為行，Component作為列，形成的表格，每個單元格裡都是不同的能力（多條）。
用戶故事可以用一系列能力來描述
採用風險分析，將單元格附上顏色
風險分析需要不同人的意見。有個方法很給力，先完成一份，然後發給不同的人，他們發現偏差就會提出意見（樹個靶子）
google使用buganizer管理bug，分為P0到P5（P0最糟）
當bug到達的速度超過團隊修復的能力時，不進行新功能的開發（google強烈推薦這種實踐），有助於控制住bug
尋找正面的價值觀：用不那麼極端的輸入，一遍又一遍的測試用以模擬真實使用場景，保證通用情況下，軟體的運行不會出錯
海盜領導力：船員武裝到牙齒，才能卓著，不愁去處，船長怎麼管理這些人？（無法通過強力和恐懼，船員的動力在於劫掠的生活方式和下一次收成的興奮感）
要靠技術洞察力，令人興奮的技術冒險，有趣的停靠港口來領導團隊
谷歌領導和管理：mentoring and guiding, not dictating
（已經開源）
Go-to tester（有困難就找她）
從頭到尾理解產品，包括各種文檔
代表客戶
坦誠某個組件或領域不由自己負責，開發反而尊敬你
測試工程經理具備TE和SET技能，並具有足夠的管理技能
獨立貢獻者向測試經理（manager）匯報，資深工程師和技術負責人直接向總監（director）匯報
google特別強調影響力
進入一個新項目，頭幾個星期都是在傾聽（無法接受醫生觀察我不到5分鐘就開出抗生素的藥）
問為什麼要做這個測試，很多開發不思考，只做他們知道怎麼做的東西或看別人怎麼做就怎麼做。應該是能提高產品質量，提高工程師開發效率的東西
團隊的文化和氛圍很大程度來自團隊那個資深的人
管理的同時保持技術敏銳
- 留下一部分工作自己做
- 排除幹擾（去了另外一個地方工作，幹擾少，產能很高）
只選用最好的人，絕不動搖
經驗：
- 測試和開發採用相同的語言
- 關注測試基礎設施建設，讓測試更容易
- 20%的用例覆蓋了80%的使用場景（自動化這些）
年輕的測試工程師可能一上來就幹，沒有思考為什麼要寫這些測試
如果自動化不能帶來明確的價值，我們就廢棄它
Shelton Mar
測試技術必須融入項目團隊，需要非常強的工程師
Brad Green
google聘用的都是極端自我驅動力的傢伙，「按我說的做」用多了，這群聰明的傢伙就會不理你而去做他們覺得最該做的事情（google style，表面上答應你，後面幹自己的事情）
James Whittaker
我發現沒有比開發工具更能激發測試人員的創造性和團隊士氣了
我對google最滿意的兩件事：測試人員向測試人員匯報；測試人員自己決定自己的發展
Google測試的秘方：技能（測試人員的技術能力）、稀缺性（獲得開發人員的幫助）、自動化、迭代集成
google的測試流程概況：讓每個工程師都注重質量
SET的未來就是開發
測試代碼要成為一等公民，由PM管理，由SWE編寫
測試功能特性開發應有團隊的新成員負責（必須學習產品的所有東西，包括內部設計），是一個非常理想、最佳的熱身項目。
軟體開發的問題已經徹底改變，繼續死守數十年之久的測試教條無異於刻舟求劍
集中測試部門逐漸下發到項目，讓他們更敏捷，更少關注測試流程，更多關注產品本身。
測試工程經理是最強的產品專家