英文原文：How Google Tests Software – Part Five，翻譯：黃利
對於測試範圍的形式，谷歌並沒有使用通用的程式碼測試、整合測試、系統測試這些常用術語來做區分，而是使用小規模測試、中等規模測試、大規模測試這樣的稱呼（譯者注：程式碼測試(code testing), 通常指單元測試和API級別的測試，一般使用XUnit、Gtest框架，但谷歌並沒有使用程式碼級別測試這種說法）。小規模測試就是針對小量程式碼的測試，中等規模測試、大規模測試以此類推。所有的三種工程師角色（譯者注，軟體開發工程師、軟體測試開發工程師、軟體測試工程師，參見本系列第二篇），都會去執行上面的三類測試，可能是自動化的測試，也可能是手動測試。
小規模測試，通常（但也並非所有）是自動化的，一般是針對一個單獨的函式或者模組。這種測試一般由軟體開發工程師（SWE）或者軟體測試開發工程師（SET）來實現，通常在執行的時候會依賴模擬環境，當軟體測試工程師（TEs）需要去診斷定位一個特定錯誤時，會去篩選一些小規模測試集合並執行來驗證特定問題。對於小規模測試，主要集中在常見功能問題驗證上，例如資料損壞、錯誤邊界、發生錯誤時如何結束等。小規模測試嘗試去解決的問題是，程式碼是否按照其假定的方式執行。
中等規模測試，可以是自動化的或者手動的，涉及到2個及以上功能模組，特別是要覆蓋這些功能模組之間互動的地方。有不少軟體測試開發工程師（SET）把這種測試描述成“測試一個函式，以及它最近的鄰居們”（”testing a function and its nearest neighbors.”）。軟體測試開發工程師在獨立的功能模組開發完畢後會驅動進行這種測試，軟體開發工程師是寫這些測試程式碼、並除錯和維護這些測試的主要力量。如果一個測試用例執行失敗或者執行錯誤，相應的開發會自動地跳出來檢視處理。在開發週期的後期，軟體測試工程師會執行這些中等規模測試，可能是手動的方式（如果很難或者需要投入比較大成本去自動化的時候）或者自動化的方式去執行。中等規模測試嘗試去解決的問題是，一些相近的互動功能模組組合在一起是否和預期一致。
大規模測試，涵蓋三個及以上（通常更多）功能模組，描述終端使用者的使用常ò及其可能擴充套件。所有的功能模組整合為一個整體的時候需要去關心許多問題，但在谷歌，對於大規模測試，更傾向於著重結果，例如，這個軟體是使用者期望的那樣麼？所有的工程師都會參與到大規模測試中，無論是使用自動化還是探索性測試方法。大規模測試嘗試去解決的問題是，這個產品執行地是否是終端使用者期望的那樣。
小規模測試、中等規模測試、大規模測試這些術語本身其實並不重要，你可以給它們取任何你想的名稱。對於谷歌的測試人員來說，有了這樣一個統一的稱謂後，就可以使用這些稱謂來討論正在進行什麼樣的測試以及其測試範圍。有一些雄性勃勃的測試人員也會談到第四種測試，被稱為超級大規模測試，公司的其他測試人員可以認為這樣的測試是一個非常大的系統級別的測試，涵蓋到幾乎所有的功能而且會持續很長的時間，其他的解釋都會比較多餘了。
哪些需要被測試及測試範圍的確定，這是一個動態變化的過程，在不同的產品之間會有比較大的差異。谷歌更傾向於頻繁釋出，從產品的外面使用者那裡得到反饋之後再迭代開發。如果谷歌開發了一些產品，或者在已有產品上增加了新功能，會荊┥能早地對外發布並讓外部使用者能使用並從中受益。在這個過程中需要較早地把使用者和外部開發者牽扯進來，並要有一個很好的處理規則來驗證是否滿足釋出條件。
最後，自動化測試和手動測試，對於所有的三種型別測試（小規模、中等規模、大規模測試）來說當然更喜歡前者。如果能夠被自動化，而且不需要任何人智力和直覺判斷，那就應該把它變成自動化的。只有在特別需要人為判斷的時候，例如使用者的介面是否漂亮、或暴漏一些涉及使用者隱私的內容時，在這些情況下應該保留手動測試。
話雖如此，對於谷歌來說非常重要的是仍然使用了大量的手動測試，不管是使用文字記錄的方式還是使用探索性測試，雖然有些已經進入了自動化測試的視線。業界使用的錄製技術將手動測試轉變成自動化測試，可以在每個版本後自動地重複執行，這樣保證了最少的迴歸工作，並把手動測試的重點放在新問題上。而且，谷歌已經將提交BUG的過程和一些手動測試的日常工作也自動化了，例如，如果一個自動化測試執行失敗，系統會自動檢測到最後一次程式碼變更的資訊，一般來說這是引起測試失敗的原因，系統會給這次程式碼提交的作者傳送一封通知郵件同時自動建立一個BUG來記錄這個問題。在測試上，“人類智慧的最後一英寸”體現在測試設計上，谷歌的下一代測試工具也正在這個方向上努力嘗試，將其自動化。
這些工具在以後的文章中會被提及強調。不過，下一篇文章還是會將重點放在軟體測試開發工程師（SET）的工作上。希望能得到你的持續關注。