谷歌如何測試（五）（六）

　　How Google Tests Software – Part Five
　　How Google Tests Software – Part Six

【五】

　　對于測試范圍的形式，谷歌并沒有使用通用的代碼測試、集成測試、系統測試這些常用術語來做區分，而是使用小規模測試、中等規模測試、大規模測試這樣的稱呼【譯者注：代碼測試(code testing)， 通常指單元測試和 API 級別的測試，一般使用 XUnit、Gtest 框架，但谷歌并沒有使用代碼級別測試這種說法】。小規模測試就是針對小量代碼的測試，中等規模測試、大規模測試以此類推。所有的三種工程師角色【譯者注，軟件開發工程師、軟件測試開發工程師、軟件測試工程師，參見本系列第二篇】，都會去執行上面的三類測試，可能是自動化的測試，也可能是手動測試。

　　小規模測試，通常（但也并非所有）是自動化的，一般是針對一個單獨的函數或者模塊。這種測試一般由軟件開發工程師【SWE】或者軟件測試開發工程師【SET】來實現，通常在運行的時候會依賴模擬環境，當軟件測試工程師【TEs】需要去診斷定位一個特定錯誤時，會去篩選一些小規模測試集合并運行來驗證特定問題。對于小規模測試，主要集中在常見功能問題驗證上，例如數據損壞、錯誤邊界、發生錯誤時如何結束等。小規模測試嘗試去解決的問題是，代碼是否按照其假定的方式運行。

　　中等規模測試，可以是自動化的或者手動的，涉及到 2 個及以上功能模塊，特別是要覆蓋這些功能模塊之間交互的地方。有不少軟件測試開發工程師【SET】把這種測試描述成“測試一個函數，以及它最近的鄰居們” 【”testing a function and its nearest neighbors.”】。軟件測試開發工程師在獨立的功能模塊開發完畢后會驅動進行這種測試，軟件開發工程師是寫這些測試代碼、并調試和維護這些測試的主要力量。如果一個測試用例運行失敗或者運行錯誤，相應的開發會自動地跳出來查看處理。在開發周期的后期，軟件測試工程師會運行這些中等規模測試，可能是手動的方式（如果很難或者需要投入比較大成本去自動化的時候）或者自動化的方式去運行。中等規模測試嘗試去解決的問題是，一些相近的交互功能模塊組合在一起是否和預期一致。

　　大規模測試，涵蓋三個及以上（通常更多）功能模塊，描述最終用戶的使用場景及其可能擴展。所有的功能模塊集成為一個整體的時候需要去關心許多問題，但在谷歌，對于大規模測試，更傾向于著重結果，例如，這個軟件是用戶期望的那樣么？所有的工程師都會參與到大規模測試中，無論是使用自動化還是探索性測試方法。大規模測試嘗試去解決的問題是，這個產品運行地是否是最終用戶期望的那樣。

　　小規模測試、中等規模測試、大規模測試這些術語本身其實并不重要，你可以給它們取任何你想的名稱。對于谷歌的測試人員來說，有了這樣一個統一的稱謂后，就可以使用這些稱謂來討論正在進行什么樣的測試以及其測試范圍。有一些雄性勃勃的測試人員也會談到第四種測試，被稱為超級大規模測試，公司的其他測試人員可以認為這樣的測試是一個非常大的系統級別的測試，涵蓋到幾乎所有的功能而且會持續很長的時間，其他的解釋都會比較多余了。

　　哪些需要被測試及測試范圍的確定，這是一個動態變化的過程，在不同的產品之間會有比較大的差異。谷歌更傾向于頻繁發布，從產品的外面用戶那里得到反饋之后再迭代開發。如果谷歌開發了一些產品，或者在已有產品上增加了新功能，會盡可能早地對外發布并讓外部用戶能使用并從中受益。在這個過程中需要較早地把用戶和外部開發者牽扯進來，并要有一個很好的處理規則來驗證是否滿足發布條件。

　　最后，自動化測試和手動測試，對于所有的三種類型測試【小規模、中等規模、大規模測試】來說當然更喜歡前者。如果能夠被自動化，而且不需要任何人智力和直覺判斷，那就應該把它變成自動化的。只有在特別需要人為判斷的時候，例如用戶的界面是否漂亮、或暴漏一些涉及用戶隱私的內容時，在這些情況下應該保留手動測試。

　　話雖如此，對于谷歌來說非常重要的是仍然使用了大量的手動測試，不管是使用文本記錄的方式還是使用探索性測試，雖然有些已經進入了自動化測試的視線。業界使用的錄制技術將手動測試轉變成自動化測試，可以在每個版本后自動地重復運行，這樣保證了最少的回歸工作，并把手動測試的重點放在新問題上。而且，谷歌已經將提交 BUG 的過程和一些手動測試的日常工作也自動化了，例如，如果一個自動化測試運行失敗，系統會自動檢測到最后一次代碼變更的信息，一般來說這是引起測試失敗的原因，系統會給這次代碼提交的作者發送一封通知郵件同時自動創建一個 BUG 來記錄這個問題。在測試上，“人類智慧的最后一英寸”體現在測試設計上，谷歌的下一代測試工具也正在這個方向上努力嘗試，將其自動化。

　　這些工具在以后的文章中會被提及強調。不過，下一篇文章還是會將重點放在軟件測試開發工程師【SET】的工作上。希望能得到你的持續關注。

【六】

　　軟件測試開發工程師【SET】的生命

　　軟件測試開發工程師【Software Engineers in Test】是軟件工程師，專注在測試實現。首先，軟件測試開發工程師是開發角色，在招聘和內部晉升資料中被我們奉為 100% 的編碼角色。當在招聘面試軟件測試開發工程師的時候，對于編碼的要求幾乎和對軟件開發工程師的要求是一模一樣的，而且更強調如何去測試自己寫的代碼。換句話說，軟件開發工程師和軟件測試開發工程師都需要回答編碼問題，而且軟件測試開發工程師會被問到一系列測試相關的問題。

　　正如你可能想到的，這是一個很難滿足的角色。軟件測試開發工程師的數量如此之少的最有可能的原因是，事實具備軟件測試開發工程師所需技能的人非常難找，而不是我們刻意使用了什么神奇的生產率公式【譯注，開發測試比率公式】， 這也是我們適應當前工程實踐的一個必然結果。我們還在優化我們的工程實踐–這是一個非常重要的任務，并且為所有參與的人構建一些流程。

　　通常來說，軟件測試開發工程師不會在早期設計階段就介入。不是故意這樣做，而是和多數谷歌的產品是如何誕生的有關。一個常見的新產品誕生的場景是這樣，已有的谷歌產品的員工會投入 20% 時間來開始新的產品。Gmail 和 Chrome OS 這 2 個產品，從一個簡單的想法開始，并非正式地由谷歌授權去做的，慢慢地隨著時間的推移，越來越多的開發和測試加入進來并把產品發布。在這種情況下，早期的開發要關注的重心并不是質量，更關注提供一些理念，在解決了擴展性和性能的問題之后，再更多地關注質量。如果你創建了一個 web service，但是不具有可擴展性時，測試這時候還并不是你最大的問題。

　　一旦這個產品已經明確未來可以發布的時候，研發團隊就開始尋求測試的介入了。

　　你可以想象這樣一個過程，某個人有了一個好主意，他開始思考并寫了一些試驗性質的代碼，從其他人那里獲取一些建議然后對這些代碼做了改進，并勸說更多的人加入，寫了越來越多的代碼，然后意識到他們做的事情很重要，通過更多的代碼把這個想法變成可以呈現給他人并得到反饋的模型…  這個項目在谷歌的項目庫中就創建了，這個項目慢慢地變成了一個真實的項目，測試也只有在項目變成真實的項目之后才會介入進來。

　　所有真實的項目都有專職的測試人員么？ 默認情況下是沒有的。小型項目和只有受限用戶使用的項目一般是開發人員自己做測試。其他的一些對個人或者企業用戶有潛在風險的項目，測試會介入。

　　當開發團隊尋求測試團隊參與并幫助他們時，他們有責任使測試人員相信他們的項目是令人興奮并充滿潛力的。開發總監會給測試總監解釋他們的項目、進度、發布計劃，一起討論測試工作如何劃分，并就開發需要滿足的單元測試水平及開發參與測試工作程度上達成一致，發布流程中開發與測試的責任也需要明確。軟件測試開發工程師在項目初期可能不會參與進來，一旦項目變成真實的項目后，測試人員將在軟件開發過程中發揮巨大的影響力。

　　當我說“測試”時，并不是僅僅意味著單純的檢查驗證代碼路徑。測試人員不是從開始就參與進來的，但“測試”卻至始至終都有。實際上，一個開發嘗試去 check in 代碼的時，測試人員的影響力在這個時刻可能就已經顯現出來了。【譯，這里指軟件測試開發工程師會對開發人員的測試程度做一些要求，開發人員在 check in code 的時候需要想一下自己是否滿足這些要求，這就是測試人員的影響力】。歡迎繼續收聽并嘗試理解我所說的這些東西。