《Google軟件測試之道》，一直聽朋友講起這本書，出於瑣事太多，一直沒機會拜讀，最近部門架構覺得我們IT部門的技術太low，就給我們挑選了一些書籍，讓我們多看看。。。
個人的一種學習習慣吧，就做了筆記，將自己的學習理解感觸寫下來。。。
快樂閱讀，快樂測試，祝願你總能發現（並修復）BUG。。。
————James Whittaker、Jason Arbon、Jeff Carollo（本書作者）
一、質量不等於測試
軟件質量是所有人的事，而不僅僅只是測試團隊的事！！！
質量不是被測試出來的，而應該從設計之初就考慮到軟件應用的業務邏輯、代碼code規范、測試流程安排方法、以及在開發過程中不斷變更需求的應對方案。
但不經過測試的產品，也不可能擁有好的質量。
軟件質量是一種預防行為，而不是測試行為。
測試是開發過程中必不可少的一部分。
開發也應該對自己編寫的代碼負責。
二、角色
1、軟件開發工程師
software enginner，簡稱SWE，是一個傳統上的開發角色，工作職責是實現最終用戶所使用的功能代碼。
開發工程師，創建設計文檔、選擇最優的數據結構和整體架構，並且進行代碼實現和代碼審核，開發工程師幾乎所有時間花在代碼實現上面。
2、軟件測試開發工程師
software enginner in test，簡稱SET，也是一個開發角色，工作重心在可測試性（對開發工程師編寫的代碼質量和正確性的驗證。
即：單元測試）和通用測試基礎框架（為后續快速測試、持續集成以及自動化等測試設計測試框架、環境、工具等）。
開發測試工程師，參與設計評審，近距離觀察代碼質量和風險；為了增加可測試性，會對代碼進行重構，並編寫單元測試以及自動化測試框架。
開發測試工程師和開發工程師可以說是一體兩面：SWE主要職責在於增加功能性代碼或提高性能的代碼，而SET更加關注質量提升和測試覆蓋率增加。
相比於SWE更關注客戶使用的功能的開發實現，SET更注重質量服務，其編寫的代碼是為了讓SWE測試自己的功能。
3、測試工程師
test enginner，簡稱TE，和SET類似，但是把用戶放在第一位，站在用戶角度思考。
測試工程師把用戶放在第一位來思考，將SWE和SET編寫的代碼分類組裝，組織整體的質量實踐、測試，分析解釋測試運行結果，驅動測試執行，以及推動產品發布等。
4、三者的區別於關聯
SWE：負責功能實現和這些獨立功能的質量，對容錯設計、故障恢復、測試驅動設計、單元測試負責，並和SET一起測試代碼。
SET：也是開發人員，不過提供測試支持，主要是編寫測試框架，將最新開發的代碼隔離，在測試環境（或模擬用戶真實環境）管理代碼提交等；
SET編寫代碼，通過這些代碼提供的功能讓SWE能夠自測；SET的目的是保證這些功能模塊具有可測性，讓SWE更多時間去完成代碼編寫。
TE： 專注用戶角度的測試，由於單元測試的獨立功能經過SWE和SET的測試，TE更多的是驗證代碼數據集成后是否可以滿足最終用戶需求；
其扮演一個雙重確認角色：一方面確認開發人員早起的測試工作是否存在不足，另一方面參與到常見用戶場景中，測試應用是否滿足性能期望；
在安全性、國際化、易用性、訪問權限等方面是否滿足用戶需求，以及和參與到軟件各個階段的人員溝通交流，討論設計帶來的風險、功能邏輯復雜性和錯誤避免的方法。
三、組織結構
一般情況下，開發和測試人員一般都隸屬於一個部門、團隊，工作匯報給同一個領導者，看起來做到了平等相處患難與共；
然而實際上，團隊的領導者一般來自產品或者開發經理，在產品發布時，優先考慮的功能是否完整和易用性方面是否足夠簡單，缺很少考慮質量：測試總在為開發讓路！！！
這就導致了市場上存在很多有缺陷的產品，出問題再發一個補丁包就行；還有就是，很多測試人員說的，公司不注重測試，測試沒地位的原因！！！
在類似於Google等這樣的大型互聯網公司里面，測試團隊是一個獨立的部門，會根據不同軟件產品的優先級、復雜度等因素決定分配測試人員；
測試人員對產品進行一系列提高軟件質量的工作，但並不向產品開發團隊匯報負責，而是對缺陷進行管理、發布，可以說測試和開發人員是相輔相成的一種並存關系。
這樣的好處在於：產品質量能得到更有效控制，不用招聘更多測試人員去做一些本來應該開發應該做的事情，
做到較好的質量和成本控制（雖然會犯錯，但會保持在一定的平衡范圍內），還可以使測試人員保持項目產品新鮮感，以及新的有效的測試技術的推廣。
個人感觸：在國內的大部分互聯網或者有IT部門的企業中，測試地位相對來說還是比較低，相比於產品和開發而言。原因就是：很多公司產品只要實現功能就會急於發布使用，
用戶使用中出現問題，發布一個補丁包，解燃眉之急；以及產品從設計初始的業務邏輯不明確，開發測試時間緊急，需求變更頻繁，開發測試人員的技術水平、整個生產流程、
管理以及上線發布的決定權等很多因素造成。
Google解決辦法：在最初版本只包含基本功能，然后在后續快速迭代中通過各種途徑得到內部和外部用戶使用反饋，后續迭代每次都注重產品質量，一般軟件應用正式與用戶
見面之前都要經歷下面幾個版本。。。
四、版本
一個產品最終上線給予用戶使用，一般都要經歷一系列的內部各種驗證，各版本如下：
1、每日構建版本
即金絲雀版本：對產品的代碼每天都進行構建，用來排除一些不適宜的版本。
金絲雀：17世紀，英國人將金絲雀放到煤礦井中檢測空氣質量，如果金絲雀死了，則證明礦井中空氣達到了令人中毒的水平；可以理解為一種預警機制。
如果每日構建代碼失敗，則表明流程的某個地方出問題了，需要進行復查，這個版本需要極強的容忍度。
2、開發版本
開發人員使用的版本，一般都是定期發布，讓該產品下的所有工程師安裝使用，一般它會包含一定的功能並通過了一定的測試，如果該版本不能滿足日常真實工作需要，則需要打回
金絲雀版本，重新進行評估。
3、測試版本
通過了持續測試的版本，一般為一個階段里面的最佳版本，可以作為內部評測的一個版本，如果這個版本有持續的良好表現，可以作為下一階段的發布版本候選版本。
4、發布版本
即beta版本，是個非常穩定的測試版本，可以作為對外發布上線的版本。
上面的幾種產品版本可以作為開發一款軟件應用產品的參考，實際情況需要結合實際需求來界定！！！
五、測試類型
一般常說的測試階段有代碼測試（單元測試）、集成測試（接口測試）、系統測試等這些命名方式，而Google則采用小型測試、中型測試、大型測試等術語，其強調的是測試范疇而不是形式
1、小型測試
一般來說都是自動化實現的，其意味着涵蓋叫少量的代碼，用於驗證一個單獨函數或獨立功能模塊代碼是否按照預期工作，着重於典型的功能性問題、數據損壞、錯誤條件和大小差異錯誤等驗證。
小型測試一般由SWE實現，也會有少量的SET參與，小型測試主要嘗試解決的問題是：這些代碼是否會按照預期的方式進行。
2、中型測試
中型測試一般也是自動化實現的，一般會涉及兩個或兩個以上甚至更多模塊之間的交互，測試重點在於驗證有交互的模塊之間彼此調用時的功能是否正確。
一般在獨立功能模塊開發完畢后，SET會驅動這些測試的實現及運行，SWE會參與，一起編碼、調試和維護這些測試。
中型測試主要嘗試解決的問題是：一系列有交互的模塊互相調用時候，是否如我們預期的那樣工作
3、大型測試
涵蓋三個或更多的功能模塊，使用真實用戶場景和實際用戶數據，其關注的是所有模塊的集成，更傾向於結果驅動，驗證軟件是否滿足最終用戶的需求。
大型測試嘗試去解決的問題是：產品的操作運行方式是否和用戶期望相同，並產生預期的結果（端到端的使用場景以及整體產品或服務之上的操作）
測試的重點，應該注重測試的范疇、內容、結果，而不是這個階段的術語；
專注，才是做技術該有的品質。。。