《google軟體測試之道》，一直聽朋友講起這本書，出於瑣事太多，一直沒機會拜讀，最近部門架構覺得我們it部門的技術太low，就給我們挑選了一些書籍，讓我們多看看。。。
個人的一種學習習慣吧，就做了筆記，將自己的學習理解感觸寫下來。。。
預計會分為五部分寫這些學習筆記，分別是google軟體測試基礎介紹、軟體測試開發工程師、軟體測試工程師、測試經理以及附錄其他部分。。。
快樂閱讀，快樂測試，祝願你總能發現（並修復）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更多時間去完成**編寫。
其扮演乙個雙重確認角色：一方面確認開發人員早起的測試工作是否存在不足，另一方面參與到常見使用者場景中，測試應用是否滿足效能期望，在安全性、
國際化、易用性、訪問許可權等方面是否滿足使用者需求，以及和參與到軟體各個階段的人員溝通交流，討論設計帶來的風險、功能邏輯複雜性和錯誤避免的方法。
三、組織結構
一般情況下，開發和測試人員一般都隸屬於乙個部門、團隊，工作匯報給同乙個領導者，看起來做到了平等相處患難與共；
然而實際上，團隊的領導者一般來自產品或者開發經理，在產品發布時，優先考慮的功能是否完整和易用性方面是否足夠簡單，缺很少考慮質量：測試總在為開發讓路！！！
這就導致了市場上存在很多有缺陷的產品，出問題再發乙個補丁包就行；還有就是，很多測試人員說的，公司不注重測試，測試沒地位的原因！！！
在類似於google等這樣的大型網際網路公司裡面，測試團隊是乙個獨立的部門，會根據不同軟體產品的優先順序、複雜度等因素決定分配測試人員；測試人員對產品進行一系列
提高軟體質量的工作，但並不向產品開發團隊匯報負責，而是對缺陷進行管理、發布，可以說測試和開發人員是相輔相成的一種並存關係。
做到較好的質量和成本控制（雖然會犯錯，但會保持在一定的平衡範圍內），還可以使測試人員保持專案產品新鮮感，以及新的有效的測試技術的推廣。
個人感觸：在國內的大部分網際網路或者有it部門的企業中，測試的地位相對來說還是比較低的，相比於產品和開發而言。原因就是：很多公司產品只要實現了功能就會急於發布使用，使用者使用**現問題，發布乙個
補丁包，解燃眉之急；以及產品從設計初始的業務邏輯不明確，開發測試時間緊急，需求變更頻繁，開發測試人員的技術水平、整個生產流程、管理以及上線發布的決定權等很多因素造成。
google解決辦法：在最初版本只包含基本功能，然後在後續的快速迭代中通過各種途徑得到內部和外部使用者的使用反饋，後續迭代每次都注重產品質量，一般軟體應用正式與使用者見面之前都要經歷下面幾個版本。。。
四、版本
乙個產品最終上線給予使用者使用，一般都要經歷一系列的內部各種驗證，各版本如下：
1、每日構建版本
即金絲雀版本：對產品的**每天都進行構建，用來排除一些不適宜的版本。
金絲雀：17世紀，英國人將金絲雀放到煤礦井中檢測空氣質素，如果金絲雀死了，則證明礦井中空氣達到了令人中毒的水平；可以理解為一種預警機制。
如果每日構建**失敗，則表明流程的某個地方出問題了，需要進行複查，這個版本需要極強的容忍度。
2、開發版本
開發人員使用的版本，一般都是定期發布，讓該產品下的所有工程師安裝使用，一般它會包含一定的功能並通過了一定的測試，如果該版本不能滿足日常真實工作需要，則需要打回金絲雀版本，重新進行評估。
3、測試版本
通過了持續測試的版本，一般為乙個階段裡面的最佳版本，可以作為內部評測的乙個版本，如果這個版本有持續的良好表現，可以作為下一階段的發布版本候選版本。
4、發布版本
即beta版本，是個非常穩定的測試版本，可以作為對外發布上線的版本。
上面的幾種產品版本可以作為開發一款軟體應用產品的參考，實際情況需要結合實際需求來界定！！！
五、測試型別
一般我們常說的測試階段型別有**測試（單元測試）、整合測試（介面測試）、系統測試等這些命名方式，而google則採用小型測試、中型測試、大型測試等術語，其強調的是測試的範疇而不是形式
1、小型測試
一般來說都是自動化實現的，其意味著涵蓋叫少量的**，用於驗證乙個單獨函式或獨立功能模組**是否按照預期工作，著重於典型的功能性問題、資料損壞、錯誤條件和大小差異錯誤等驗證。
小型測試一般有swe實現，也會有少量的set參與，小型測試主要嘗試解決的問題是：這些**是否會按照預期的方式進行。
2、中型測試
中型測試一般也是自動化實現的，一般會涉及兩個或兩個以上甚至更多模組之間的互動，測試重點在於驗證有互動的模組之間彼此呼叫時的功能是否正確。
一般在獨立功能模組開發完畢後，set會驅動這些測試的實現及執行，swe會參與，一起編碼、除錯和維護這些測試。中型測試主要嘗試解決的問題是：一系列有互動的模組互相呼叫時候，是否如我們預期的那樣工作
3、大型測試
大型測試嘗試去解決的問題是：產品的操作執行方式是否和使用者期望相同，並產生預期的結果（端到端的使用場景以及整體產品或服務之上的操作）
測試的重點，應該注重測試的範疇、內容、結果，而不是這個階段的術語；
專注，才是做技術該有的品質。。。
只有很努力，才能毫不費力。。。
《Google軟體測試之道》有感
如他們的招聘要求，有很多想法，並且有能力去實現。印象深刻的是，有一位為了實現自己的想法，週末的時間在咖啡館也在努力，並且最終取得了成功。以前的我覺得有些不可思議，為什麼要占用自己的休息時間來完成工作。這大概就是熱愛吧。我們好像總是淹沒在版本不停的交付中，沒有停下來思考，如何提高效率，並去實踐。創新，...
《Google 測試之道》有感（一）
作為乙個測試人員，這本書我讀的中文版，看了一部分，感覺有些受益，特此記錄！本書中把軟體的測試角色分為三種 軟體開發工程師 swe 軟體測試開發工程師 set 測試工程師 te swe和set都是必須要編寫 的，差別是wet是開發工程師，側重點是開發功能 提高系統效能 set是測試開發工程師，側重點是...
《Google軟體測試之道》讀書筆記 第二章
第乙個融合開發角色和質量意識於一身的角色，即set。1.工程師團隊的交付物就是即將要發布的 的組織形式 開發過程 維護是日常的工作重點。2.google在平台方面有特定的目標，就是保持簡單且統一。開發工作機和生產環境的機器都保持統一的linux發行版本 一套集中控制的通用核心庫 一套統一的通用 構建...