第一章
1.本書的核心：作為一個google的測試人員究竟意味著什麼，Google是如何解決軟體在擴充套件性，複雜性和大併發方面的我問題。
2.測試這個行業，如何做測試，從而保證可以開發出可靠的值得信賴的軟體，是最重要的。
3.不要招聘太多測試人員，開發提升自測能力，向測試開發工程師轉變。
4.開發和測試必須同時開展，寫一段程式碼立刻測試這段程式碼。
5.金絲雀版本-》開發版本-〉測試版本-》beta或者釋出版本
6.要確定測試大中小型。
7. eg：自動化用例失敗。系統會自動檢查到最後一次程式碼的變更，這些內容極有可能是原因，系統會自動給程式碼變更的提交者傳送一封郵件，並新開一個bug來記錄這個問題。

第二章
1.思維方式的不同：對功能程式碼而言，思維模式是建立，重點在考慮使用者，使用場景和資料流程上。而對於測試程式碼來說，主要思路是去破壞，怎樣寫測試程式碼以擾亂分離使用者及其資料。
2.測試開發人員的作用：通過使用測試工具與框架幫助功能開發人員解決特定的單元測試的問題。
3.SET測試開發人員，SWE功能開發人員，TE使用者開發人員 ，我們目前還處於TE的邊緣，那麼怎樣才能一步步像SET靠近呢？
4.google在平臺方面有特定的目標，就是保持簡單統一。開發工作機和生產環境的機器都保持統一的LINUX發行版本，一套集中控制的通用核心庫，一套統一的通用程式碼，構建和測試基礎設施，每個核心語言只有一個編譯器，與語言無關的通用打包規範，文化上對這些共享資源的維護表示尊重且有激勵。
5.介面需要在專案的早期確定下來。
6.使測試人員能儘早的介入到開發流程中去，通過參與設計和程式碼開發的方式。
7.只有在軟體產品變得重要的時候質量才顯得重要。
8.第一件事：設計文件，動態文件，及時更新，類似APIcloud，所有人看到的文件一樣。連結的方式
9.儘早的提供一個可實施的自動化測試計劃：先把容易出錯的介面隔離，並針對他們建立mock和fake，接下來構建一個輕量級的自動化框架，控制mock系統的建立和執行。
10.提交佇列。
11.自動化測試：不僅僅是程式編寫，還要考慮如何編譯測試程式，執行，分析，儲存和報告所有測試執行結果。
12.測試程式的構建檔案包括測試名稱，原始碼檔案，依賴庫及資料，還要指明其規模大小。
13.小型測試：驗證一個程式碼單元的功能，單元測試。 中型測試：驗證兩個或多個模組應用之間的互動。大型測試：驗證整個系統作為一個整體如何工作。
標記大中小的原因：排程器已經知道每個任務需要執行的時間，這樣可以優化任務佇列，達到合理利用的目的。
小型測試帶來優秀的程式碼質量，良好的異常處理，優雅的錯誤報告。大中型測試會帶來整體產品質量和資料驗證。
14.重點學會思考問題的解決方案，而不是解決方案本身的實現上有多麼高雅。T63

分享會：
自己寫單元測試
測試用例與模組的關係
依賴圖
sql注入測試

第三章
1.google的TE綜合了開發者的技術能力和以使用者為中心檢查軟體質量的能力
2.TE的工作都與分享有關：TE以對某種特定的產品最合適的方式發現軟體中風險最大的地方並嘗試減少或消除它。set 程式碼審查 測試工具
3.TE在產品定型的時候再加入
目前的情況就是，我們需要在產品一開始就開始瞭解產品的具體功能和細節，這樣後續的功能測試工作才會比較順利
所以我們不能照著別人學，而是瞭解別人的工作方式，從中找到一些可借鑑的點
4.TE加入產品的時候需要考慮的問題,不完全列表的風險概要，不需要自己去解決這些問題，但是要保證這些問題被解決掉。必須快速評估專案，程式碼，設計和使用者的當前狀態。
1.當前軟體的薄弱點在哪裡
2.有沒有安全，隱私，效能，可靠性，可用性，相容性，全球化，和其他方面的問題。
3.主要使用者場景和功能是否正常。
4.當發生問題時，是否容易診斷問題所在。
5.TE是整個團隊中全職的負責從整體角度發現產品或服務弱點的唯一角色。
6.做一個能直接指導測試的測試計劃，把測試用例該怎麼編寫 執行描述的足夠詳細。
7.元件執行某種功能來滿足產品的一個特質，這個活動的結果是向用戶提供某種能力（可測試性）
8.什麼時候加入一個產品我覺得是一個很難界定的點，比如我們現在的專案，我們現在的工作流動性很大。每次加入一個新公司，需要從頭開始看，這個時候我就覺得站在整體的角度來把握確實是非常重要的，同時為退出團隊做好準備，就像開發寫註釋一樣，把文件做好註釋。
9.根據模組分類測試用例。
10.做測試之前先整體考慮，除了邊界值等分析方法外的考慮，例如介面，安全性，可複製貼上？，能夠提出反駁和質疑。
11.如何參與一個新專案：
首先站在使用者的角度瞭解產品，有可能的話，作為一個使用者，以自己的賬戶和資料去使用產品，因為一旦有自己真真實的資料在裡面，你對一個產品的期待會徹底改變。
從頭到尾理解一個產品，不管是整體的設計文件還是功能設計文件，只要是文件就瞭解。
消化文件之後，關注專案狀態，特別是質量狀態，去了解bug數量，問題分組形式，已經報告的bug型別，最長時間未處理的bug，最近一些bug的型別。
對每一個大一點的類，尋找關聯的單元測試，並且執行，看是否有效，完整，有沒有整合端到端，歷史通過率，覆蓋場景，邊界情況，程式碼庫的包變化情況，長時間未變更的，開發對測試文件的滿意度。
評審所有自動化測試，檢查程式碼，理解測試步驟。
瞭解團隊的溝通方式和對測試人員的期望，幫助開發團隊測試沒有測試過的內容。
把應用分解為合理的功能模組，細緻到可以羅列子模組的功能，排列測試優先順序，風險大小。
檢查bug庫，按照模組對bug分組。
按照優先順序順序遍歷所有模組，建立使用者故事。
測試退出的標準：你有足夠的信心，剩下的bug都屬於使用率極低，出問題後對使用者影響也較低的模組

第四章：
1.測試工程經理：負責所有的支援團隊（開發，產品經理，產品釋出，文件）之間的聯絡。需要同時具備TE和SET的功能，以及管理技能(技術 領導 協調)。
2.相關專案中最強的產品專家
假如是google瀏覽器測試工程經理：如何安裝擴充套件程式，更換瀏覽器外觀，設定同步關係，更改代理伺服器設定，檢視dom，查詢cookie的存放位置，如何以及何時版本更新，從使用者介面到後臺資料中心實現。