Google軟體測試介紹3測試工程師
測試工程師
軟體測試開發工程師（SET）負責可測試性和測試自動化體系的長期有效性。測試工程師（Test Engineer，後文簡寫TE）的職責與之有所不同，TE的重點在於評估對使用者的影響以及軟體產品整體目標上的風險。與Google的其他大多數技術崗位一樣，TE的工作涉及到一些程式設計，但程式設計只是一小部分，實際上，在所有工程師中他們的職責範圍堪稱最廣。TE對產品的貢獻很大，但他們承擔的很多工不需要程式設計（注：這只是通常的說法。許多TE所從事的工作與SET非常類似，需要編寫大量的程式碼，而另外一些TE的職責更類似釋出工程師，只需要編寫很少量的程式碼）。
Google的TE綜合了開發者仰慕的技術能力和以使用者為中心檢查軟體質量而對開發者產生一定製約的能力。
TE的職位描述是最難定義的，因為其職責範圍很廣而且不確定。人們期望TE在各種各樣的構建物的完成、整合、最終形成完整的產品過程中監督所有產物的質量。因此，大多數的TE都會從事一些基礎技術層的、需要另外一種視角和較強的專業技術能力的工作。這一切都與風險有關：TE以對某種特定的產品最合適的方式發現軟體中風險最大的地方並嘗試減少或消除它。如果需要做SET的工作，TE就去做；如果需要程式碼審查，那就只管去做。如果缺少測試工具，那就花一些時間在上面。
接下來，同一個人還會在專案的其他時段去領導探索式測試，或者管理內部試用版（或beta版）的測試工作。在不同的專案階段，SET和TE的重點不同，早期的工作涉及到更多的面向SET的任務，而專案後期才是面向TE的任務。還有一些情況是TE的個人選擇，他們可以在不同的角色間切換。但凡事沒有絕對，我們在下面所做的描述，只是代表了理想的情況。
在研發的早期階段，功能還在不斷變化，最終功能列表和範疇還沒有確定，TE通常沒有太多的工作可做。
當TE進入產品的時候，並不需要從零開始。SWE和SET已經在測試技術和質量方面做了大量的工作，可以作為TE的起點。TE在進入產品時，需要考慮以下一些問題。
- 當前軟體的薄弱點在哪裡？
- 有沒有安全、隱私、效能、可靠性、可用性、相容性、全球化和其他方面的問題？
- 主要使用者場景是否功能正常？對於全世界不同國家的使用者都是這樣麼？
- 這個產品能與其他產品（軟體和硬體）互操作嗎？
- 當發生問題的時候，是否容易診斷問題所在？
當然這只是一個不完全列表。所有這些加起來，構成釋出待評估軟體的風險概要。TE並不需要自己去解決所有這些問題，但必須保證這些問題被解決掉，他們可以請其他人幫忙評估還有多少工作需要去做。TE的根本使命是保護使用者和業務的利益，使之不受到糟糕的設計、令人困惑的使用者體驗、功能bug、安全和隱私等問題的困擾。在Google，TE是一個團隊中全職地負責從整體角度發現產品或服務弱點的唯一角色。因此，與SET相比，TE的工作並不是那麼確定。TE會介入專案的各個階段：從產品的構思階段到第8個版本，甚至是照看一個已經下線的專案。一個TE同時參與幾個專案也很常見，尤其是那些具備安全、隱私或全球化等專門技能的TE。
這個角色需要敏銳的洞察力和領導力，因此很多Google的高階測試經理們都來自於TE。
TE的工作經常需要去打破常規流程。TE可以在任何時間進入專案，必須迅速評估專案、程式碼、設計和使用者的當前狀態，然後決定首要的關注點。如果專案剛剛開始，測試計劃是第一優先順序。有時，TE在產品後期被拉進來幫助評估專案是否可以釋出，或者在beta版本釋出之前確認還有哪些主要的問題。當TE進入了一個新被收購的應用或缺少相關應用經驗的時候，他們經常會先去做一些不怎麼需要計劃的探索式測試。有時，專案已經很久沒有釋出了，只是需要去做一些修飾、安全補丁或介面更新，這需要迥然不同的方法。
在Google，TE需要在不同的專案中做不同的事情。我們經常將TE的工作描述為"從中間開始（starting in the middle）"，因為TE必須保持足夠的靈活，能夠迅速融入一個產品團隊的文化和現狀。如果做測試計劃已經來不及了，那就乾脆不做了。如果一個專案最需要的是測試，那就做一個簡單夠用的指導性計劃。一些測試教條所倡導的從頭就介入的模式，在Google並不適用。
下面是我們關於TE職責的一般性描述。
- 測試計劃和風險分析；
- 評審需求、設計、程式碼和測試；
- 探索式測試；
- 使用者場景；
- 編寫測試用例；
- 執行測試用例；
- 眾包（譯註：crowdsourcing，是網際網路帶來的新的生產組織形式。一個公司或機構把過去由員工執行的工作任務，以自由自願的形式外包給非特定的（通常是大型的）大眾網路的做法）；
- 使用統計；
- 使用者反饋。
測試人員要處理的是真正的文件和其他臨時性的事物。在專案的早期階段，測試人員編寫測試計劃；然後，他們建立和執行測試用例，編寫bug報告；接下來是準備覆蓋度報告，收集使用者滿意度和軟體質量資料。在軟體成功釋出（或失敗）之後，很少有人會問及測試產物是什麼。如果軟體深受人們喜愛，大家就會認為測試所作所為是理所應當的；如果軟體很糟糕，人們可能就會質疑測試工作。但其實也沒人真正想去了解測試到底做了什麼。
測試計劃是最早出現、最先被遺忘的測試產物。
下面是我們希望測試計劃具有的一些特性。
- 及時地更新。
- 描述了軟體的目標和賣點。
- 描述了軟體的結構、各種元件和功能特性的名稱。
- 描述了軟體的功能和操作簡介。
從純粹測試的角度看，我們擔心的是測試計劃的投入和價值產出是否匹配。
- 不必花過多的時間去撰寫，必須隨時可以被修改。
- 應該描述必測點。
- 應該能在測試中提供有用的資訊，從而幫助確定進展以及覆蓋率上的不足。
ACC（Attribute Component Capability，即特質、元件、能力。這是一種測試計劃的替代方法，參見ofollow,noindex">http://googletesting.blogspot.com/2011/10/google-test-analytics-now-in-open.html ）可以做測試計劃的替代。
特質是系統的形容詞，代表了產品的品質和特色，是區別於競爭對手的關鍵。
原始碼工具：一系列用於簡化建立工作環境、提交程式碼變更、程式碼風格檢查的工具。可以用工具瀏覽數億萬行的程式碼，發現並預防重複的程式碼。還有用於建立大規模索引和程式碼重構的工具。 開發工具：整合開的發環境的一些外掛，讓其他各種工具適應google的程式碼並連線後端的雲服務。程式碼審查工具，通過在審查階段嵌入相關的訊號，來快速完成高質量的程式碼審查。 構建框架：構建系統支援自動式，互動式，可以把原本需要數小時的任務縮短到數秒 測試基礎架構：規模化的持續整合，開發人員的每次程式碼提交都會引發自動測試；另一方面是規模化的web測試，每個google產品都會啟動數十萬個瀏覽器會話，對各種不同的瀏覽器平臺組合進行測試。 本地化工具 度量，視覺化和報表：管理所有產品的bug，跟蹤所有研發活動中工程師的各項指標。 技能、稀缺性、自動化和迭代整合。
參考資料
- 討論 釘釘群21745728 qq群144081101 567351477
- 本文最新版本地址
- 本文英文原版書籍
- 本文原始碼地址
- 本文涉及的python測試開發庫 謝謝點贊！
- 本文相關海量書籍下載
- 谷歌測試之道