願和我一樣讀過這本書的人有所共鳴或者啟發，願沒讀過這本書的人，能獲得一點點收獲。。。
說到軟件測試工程師，首先我們需要明白一個問題，軟件測試工程師的職責是什么？
關於這個話題，不同的人有不同的定義；拋開這個話題，說說Google是怎么定義以及Google的TE是如何工作的。
軟件測試工程師（Test Engineer）：簡稱TE，評估軟件應用對用戶的影響以及軟件產品整體目標上的風險的一種面向用戶的測試角色。
1、TE何時進入項目
首先需要明確一點：並不是所有的項目都需要TE的介入；比如：
①試驗性階段、尚無明確目標或需求的早期產品，TE很少參與，甚至不參與；
②產品有很大可能被取消，項目被終止（只有一個概念或沒做通過最終立項），或者功能還沒定型等；
③即使已經確定要發布某個產品、項目，在研發的早起階段，功能需求還在不斷變更，最終功能列表和范疇還沒確定，TE一般也沒有太多工作需要進行；
因此，選擇合適的階段測試進入項目，很重要！一般來講，給一個項目配備多少TE，以及何時介入，取決於項目風險、重要程度以及投資回報率。
2、當TE進入項目時，需要考慮什么
①當前軟件的薄弱點在哪兒；
②有沒有安全、隱私、性能、可靠性、可用性、兼容性以及其他的問題；
③主要用戶場景是否正常？對用戶來講是否都是這樣？
④這個產品可以和其他平台、產品（軟件硬件）互操作嗎？--個人理解：上下兼容，跨平台甚至更廣闊的領域
⑤如果出現問題，能否容易找出問題所在並且快速解決？--個人理解：風險預估和防范機制
這幾點只是不完整的幾點，TE也並不需要自己去解決這些問題，但必須保證這些問題被解決！！！
TE的根本使命：保護用戶和業務的利益，使之不受糟糕的設計、令人困惑的用戶體驗、功能BUG、安全和隱私等問題的困擾。
3、TE的職責描述
①測試計划和風險分析
②評審需求、設計、代碼和測試--個人理解：目前來講，國內大部分的測試接觸代碼還是很少的，但代碼是測試發展的一個必然趨勢
③探索式測試
④用戶場景
⑤編寫測試用例
⑥執行測試用例（包括提交BUG、跟蹤、協助溝通修復以及回歸等等）
⑦使用統計（測試每個階段的版本迭代、BUG數量、質量指標、用時等等數據信息）
⑧用戶反饋（這對於優化產品，提供更好的服務很重要）
4、測試計划
在每個項目中，最重要的產物，是代碼！因此，每個技術項目團隊，都需要對編碼保持敬意。
測試計划的意義：在項目執行中發揮核心作用，在軟件的生命周期內持續有效，時刻代表最新的產品功能，指導項目進展，可以幫助新加入的工程師快速跟上項目進展等。
優秀的測試計划應該有的一些特性：
①及時的更新
②描述軟件產品的目標和賣點
③描述軟件的結構、各種組件和功能特性的名稱
④描述了軟件的功能和操作簡介
⑤描述了必須執行的測試點
⑥對測試工作提供有用的信息，幫助確定進展以及覆蓋率的不足
ACC分析方法：即Attribute Component Capability,特質、組件、能力。這是從Google眾多測試團隊實踐中總結的一個優秀流程，受眾較多，搜索“Google Test Analytics”即可找到。
ACC指導原則如下：
①避免散漫的文字，使用簡明的列表
②不必推銷（測試計划的受眾是工程師）
③盡量簡潔（測試計划的大小和測試問題的規模有關，和作者的寫作欲望無關）
④漸進式的描述（make it flow）：測試計划的每個部分應該是前面部分的延伸
⑤指導者的思路（一個好的計划過程可以幫助計划者思考產品功能及其測試需求，有條不紊的從概念過度到直接實現的低層細節）
⑥最終結果應該是測試用例（測試計划最直接的體現就是可以清楚的指導測試用例的編寫）
A：代表特質（Attribute）
在設計測試計划或者做ACC分析時，必須先確定該產品對用戶、對業務的意義；比如：為什么開發它？能帶來什么價值？怎樣吸引客戶？核心競爭力是什么？等等
特質代表了產品的品質和特色，是區別於競爭對手的關鍵。
C:代表組件（Component）
組件是構成待建系統的模塊，在特質被識別后確定，組件是使一個軟件之所以如此的關鍵代碼塊；實際上，它們是測試人員所要測試的對象。
C：代表能力（capability）
能力（功能點）代表系統在用戶指令下完成的動作。它們是對輸入的響應、對查詢的應答、以及代表用戶完成的活動。
能力一般是面向用戶的，表達用戶眼里系統的行為，它最重要的一個特點是它的可測試性。
關於能力點分析的一種方法：
上圖是一個以特質為X軸、以組件為Y軸的表格，通過這種方法將功能點映射到特質和組件上。其中有很多空格，它表示：只有部分組件對該特質有影響（不是每個組件都對特質有影響）；
能力表的每一行或列表示按某種方式相關聯一個功能點切片，這樣可以將應用功能分解為多個可測試點的好辦法；單元格中的數字表示該組件滿足此特質能力的數量，數字越大，該交叉點需要
測試的測試點越多，這些能力點可以方便指定組件/特質對的需要的測試；可以以這些功能點直接涉及測試用例，或將它們組合成更大的用例或測試場景。
注意以下幾點：
①每個功能點至少對應一個用例
②重要的功能點對應多個用例
③並非所有的功能點都是同等重要的，區分優先級很重要
PS：你能想象到的一個軟件產品的特質、組件、能力點，都有什么？下面列舉一些Google+的ACC分析例子：
Google+特質：--（通過經理層等管理層討論即可決定）
Social（社交）：支持用戶分享信息和狀態 --分享
Easy（輕松）：用戶憑直覺即可完成各種操作 --操作習慣
Relevant（相關）：只顯示用戶感興趣的信息 --用戶關注點
Extensible（可擴展）：能否與其他類似平台、第三方服務和應用集成 --擴展性
Private（隱私）：不能泄露用戶數據 --安全隱私性
Google+的組件：（通過閱讀設計文檔即可確定）
Profile（個人資料）：已登錄用戶的個人信息和偏好設置 --我的，個人中心模塊
People（好友）：用戶已經添加的好友
Stream（信息流）：帖子、評論、通知、照片等組成的信息流 --動態
Circles（圈子）：將聯系人按照朋友、嫁人、同事等進行分組
Notifications（通知）：推送消息、轉發、艾特等有關於用戶本身的消息
Posts（帖子）：來自用戶及其聯系人的文章、隨筆等
Comments（評論）：帖子、文章、照片、視頻等的評論
Photos（照片）：用戶及其聯系人上傳的照片等 --上傳下載等功能
Google+能力點（功能點）：
關聯上面的Google組件模塊，其中包含的功能點有很多，下面就每個組件列舉一下：
profile：個人設置、創建、信息更新、分享、個性化、個人數據安全隱私、權限等
people：社交圈子、可擴展性、過濾、篩選、授權等
stream：信息服務的上下層、圈子分層、增刪改查等動作
other：按鈕、鏈接、文件等上傳下載分享等功能點（功能點太多，這里只是簡單列舉。。。）
5、風險分析
△沒有完美的軟件產品應用，風險無處無時不在！
定義：確認風險的過程稱之為風險分析；
常識性的關於風險的一些因素：
①哪些事件需要擔心
②這些時間發生的可能性、概率有多大
③一旦發生，對客戶、業務、公司有什么影響
④有什么緩解防范機制
⑤緩解措施有多大的成功率
⑥處理這些失敗的成本消耗
⑦恢復過程的難易程度
⑧事件是一次性問題還是會再次發生......
總結：影響風險的因素很多，關鍵性的有兩個因素：失敗頻率（frequency of failure）和影響（impact）;風險是一個定性的相對值，而不是一個定量的絕對值。
GTA（Google test analytics：Google測試分析，一個方便數據輸入和風險可視化的web應用，感興趣的可以去搜索看看）中風險發生頻率有4個預定義值：
罕見（rarely）：發生故障的可能性極小，發生后恢復也很容易
少見（seldom）：少數情況下會發生故障，但在使用場景復雜度不高（或使用頻率較低）的情況下，發生的可能性非常小
偶爾（occasionally）：故障情形容易想象、場景有點復雜，該功能點比較常用
常見（often）：該能力所屬的特性使用量大、復雜度高、問題頻發
關於一些風險分級說明：
最小（minimal）：用戶甚至不會注意到這個問題
一些（some）：可能會影響用戶的一些問題；一旦發生，重試或恢復機制即可解決問題
較大（considerable）：故障導致組件使用受阻
最大（maximal）：發生的故障會永久性損害產品、公司聲譽，並造成無法挽回的損失（用戶流失等嚴重問題）
關於風險分析的一個行之有效的辦法：
基於TE的輸入以及上面提到的關於特質和組件的一組列表，可以生成一個風險區域的熱圖：
表中的單元格以紅色、黃色、綠色高亮顯示，分別表示響應組件在各交叉點的風險級別；風險級別是TE已經輸入的值的一個簡單判斷。
該表格代表了該產品可測試能力以及風險，他們的風險級別一般是由開發人員、PM、測試甚至經理總監一起來評定審核（不同角色評判角度不同），一旦認同，接下來就是風險預防和緩解。
6、風險緩解
首先需要明白一點：風險永遠不可能徹底消除！如何預防緩解風險，可以參考如下幾點：
①可以圍繞風險等級高的能力點編寫測試用例，從中拆分、確定風險等級低的使用場景，然后反饋到開發團隊，有針對性的增加約束、提示；
②對風險按照等級高低做記錄，設計回歸測試用例，以確保問題重現時可以被捕捉到；
③設計和運行會引發故障的用例，以便推動開發團隊實現實時恢復和版本回滾；
④對風險組件或者場景進行監聽、報警，以便更早的檢測到故障；
PS:具體的緩解措施取決於應用本身以及對於安全性的期望值。TE的主要職責就是主動去暴露風險，根據風險等級，按照從高到低測試，如果時間不夠，先測試風險最大的。
還有一點：按照項目類型和進度給出是否可以發布的建議，這是TE的責任，這一點完全可以利用風險熱圖來完成。
△TE與風險
①對於任何在GTA（前面有提到）矩陣中顯示為紅色高風險的能力點和特質的一組件對，一定要設計一些列的測試用例或有針對性的場景去主動發現、暴露風險；--責任、職責
②認真了解分析SET和SWE已經完成的測試工作，評估這些測試對GTA所暴露風險級別的影響（測試力度是否足夠？是否需要增加額外的測試？）；--評估力度並給出是否進行下一步建議
③分析每個高風險的特質--能力對的相關BUG，保證回歸測試用例的存在和有效性（BUG傾向於在代碼發生變更時重現）--做好記錄，回歸
④仔細思考高風險的區域，考慮可能的版本回滾和恢復機制；
⑤盡可能多的引入相關各方，學會利用團隊的力量；
⑥如果時間范圍內還沒有足夠的測試或者緩解措施，經常出問題，那么應該考慮努力去說服相關同事，做好備用措施！
PS：對於風險級別較低的點，可以嘗試探索性測試。。。
7、測試用例
基於我們前面的諸多分析准備工作， 其結果都是輸出一個可行的有效的測試用例。
Google比較常見的用例管理工具：GTCM（Google Test Case Manager）
設計測試用例的目的是什么呢？→→發現缺陷，主動暴露風險，也就是我們俗稱的BUG；
8、bug的組成和生命周期（其中很少有必選的項，可以根據自身及團隊需要抉擇）
Assigned to（Assignee，被指派者）：負責采取下一步動作的人 --可選項
CC（抄送）：當一個問題被創建或修改，需要通知的一個或多個人 --可選項
Attachments（附件）：關於某個問題，相關的描述文件 --可選項
Blocking（阻塞）：該bug被修復后才能被修復的其他bug的ID --可選項
Depends On（依賴）：該bug依賴其他的bug的ID→→其他bug被修復前，該bug無法修復 --可選項
Change（變化）：該bug最后的修改日期和時間 --只讀
Changelists（變更列表）：處理該問題的一個或多個變更列表（CL）編號 --可選項
Component（組件）：與此bug有關的或者有需求的實體（創建時需要指向組件的完整路徑） --必選項：准確的描述
Created（創建於）：該bug的創建日期 --只讀
Found In（發現於）：發現問題時的軟件版本號等 --可選項
Last modified（最后修改）：該問題的任一一堆被修改的最后日期 --只讀
Notes（備注）：問題本身及其處理過程中的注解的詳細描述 --可選項
Priority（優先級）：bug的重要程度 --必填
Reportde by（Reporter：報告者）：誰發現或者誰提出的這個bug --只讀
Resolution（解決方案）：驗證者最終決定的解決方案 --可選項
Severity（嚴重性）：該bug在多大程度上影響產品的正常使用 --必填（一般分為導致系統無法使用、高、中、低、對系統無影響五個等級）
Status（狀態）：bug的當前狀態 --必填（新建、已指派、已接受、不修復、已修復、以后修復、已確定、已驗證、已關閉等狀態）
Summary（摘要）：關於該bug描述性的摘要 --必填（盡量做到准確概括）
Targeted To（目標）：該bug在哪個版本號被修復 --可選項
Type（類型）：問題的來源類型 --必填（缺陷、需求、客戶問題、內部問題、流程等）
Verified In（驗證於）：問題修復被驗證的軟件版本號 --可選項
Google最常用的BUG管理工具：Buganizer，可以將其理解為一個典型的bug數據庫。
說到這里，有個問題；測試最重要的一面是什么？是確認！！！
軟件產品是否達到用戶預期和需求設計，很重要！！！
△TE的未來
最近聽到看到很多人說軟件測試的工作越來越不好找，主要表現在於學歷要求越來越高，經驗要求越來越多，以及個人技能和綜合能力；其實優秀測試工程師的需求之大，前所未有。
我們現在所從事的測試工作，或國內大環境下的測試工作，都是傳統意義上的測試，常規性的基本都是設計用例、執行、回歸等工作，他們實際上已經有了更為全面且更為低成本的形式。
這種機會很大程度來源於軟件交付領域技術上的進步。在過去，軟件每周或每月構建一次並需要經過痛苦的集成過程，其中TE都是在發現bug以及盡量模仿用戶操作，交付上線后直接
面對的可能是幾萬甚至幾百上千萬的用戶，一旦發生問題，那么這種我們俗稱的生產事故會帶來比較嚴重的后果，可現在已經不這樣了。
通過互聯網交付，意味着我們可以選擇某一部分用戶進行發布（PS：說到這里想起某個群里的Nero大佬之前說過一種發布方式：灰度發布；感興趣的可以搜索了解一下），可以迅速
響應這部分用戶的反饋，並及時解決更新，bug壽命縮短到了幾十分鍾甚至幾分鍾！研發團隊可以快速構建快速交付、修改、重新迭代交付，讓很多可能會發生在用戶層的問題在用戶接觸到
之前就已經被解決；這也是一種更好的軟件交付和用戶反饋機制。
問題的關鍵就在於：企業希望用哪種方式測試自己的軟件應用？
高薪聘請資深測試專家，盡力模仿用戶場景？還是激勵大量的真實用戶發現並報告實際的BUG？隨着互聯網不斷發展和平民化，允許真實用戶更早訪問軟件，激發用戶報告問題的時機和
成本越來越低，也越來越容易；而且，每日更新甚至小時級別的更新，已經不是什么太困難的事情。這種可以預見到的環境下， 作為一個TE，是該思考自己的職業規划了。
如果按照本書來說，未來可能TE會變成這種樣子：
轉變成測試設計，少量的測試設計師快速的規划處測試范圍、風險熱圖和應用程序邏輯路線等，然后內部試用者、可信賴的測試者、早期用戶或者其他外包測試人員提交反饋，由測試
設計師來評估覆蓋率，計算風險影響，確保出現的問題不斷減少，並相應的作出調整。。。
當然，這需要很多的專業技能以及經驗：比如安全性隱私性、性能、探索式測試，設計開發對應的工具來統計收集這些數據，但實際工作中並沒有設計用例、執行用例的測試行為。。。
一些題外話：
在看到TE的未來這段內容之前，個人感覺，Google的測試領先的，更多的是技術上的創新、新技術的運用、流程標准化、模塊化等方面，但我看到這里，有種彗星撞地球的感覺，腦海里
仿佛整個世界都被重新設計一樣。
可能在國內這種大環境下時間久了，失去了想象和更大的思考能力，可能現在作為一個TE，短時間內無法改變所處的環境，但抱有期待，並為之努力，做好准備，永遠是必須的。
寫在博客內的文字，永遠無法表達看紙質書看到這些內容的震撼；希望看到這里的人，都能有所收獲。。。