讀Google是如何做軟體測試的

來自專欄測試進階11 人贊了文章

網上有《What Test Engineers do at Google》的原文翻譯，以及相關中文書籍《google軟體測試之道》。今天不會在這裡搬內容，寫一些讀書筆記和感悟。

測試組織架構

測試團隊成敗，組織架構也是影響因素之一。Google的組織彙報關係被劃分為不同的專註領域，包括：客戶端、地理、廣告、Apps、移動等等，所有工程師都彙報給這些專註領域的管理者、總監或副總裁。而測試是獨立存在的部門，測試依託在各個產品領域部門內，稱之為工程生產力團隊。

• 軟體測試開發工程師

職責：負責可測試性和測試自動化體系的長期有效性。

扮演質量顧問的角色

在單元測試方面給予開發人員支持

為開發人員提供測試框架，方便開發提高測試效率

參與設計評審、重構代碼增加可測試性，編寫單元測試框架和自動化測試框架

更加關注於質量提升和測試覆蓋率的增加，SET寫代碼的目的是可以讓SWE測試自己的功能

• 測試工程師

職責：評估對用戶的影響以及軟體產品整體目標上的風險

從用戶的角度來思考質量方面各種問題

從開發角度來看，他們編寫用戶使用場景方面的自動化用例代碼

從產品角度來看，他們評估整體測試覆蓋度，並驗證其他工程師角色在測試方面合作的有效性

產品專家、質量顧問和風險分析師

其中，幾個重要信息：

開發可以做測試，測試可以寫代碼，Google其實還沒有完全做到這一點

SET需要編碼，熟悉系統設計，個人覺得更像測試架構師的角色

沒有測試開發比例，開發同時也兼顧測試，專職測試讓開發更加有效且高效地做測試

測試開發同工同酬

有外包測試人員

曾經介紹過傳統軟體測試人員以黑盒測試為主，在團隊轉型中，我們已經做出了改變，優先解決單一端的全棧測試，並且把單元測試作為一個關注點分水嶺。

測試質量理念

質量不是被測試出來的，這句看似陳詞濫調的話卻包含著一定的道理。

從汽車行業到軟體行業，如果在最開始設計創建的時候就是錯的，那它永遠不會變成正確的。試問一下汽車行業的公司，大量召回事實上有質量問題的產品，代價是多麼的昂貴。因此，從最初的創建階段就要做正確，否則即便質檢發現了質量問題，也將會陷入混亂的萬劫深淵。

然而，這句話也並不像聽起來那樣的簡單和準確。雖然質量不是被測出來的，但同樣有證據可以表明，未經測試也不可能開發出有質量的軟體。如果連測試都沒有做，如何保證你的軟體具有很高的質量呢？

有一個簡單的辦法可以解決這個難題，那就是停止開發與測試的隔離對立。開發和測試應該並肩齊趨。你的每一段代碼寫完後都要立刻測試這段代碼，當完成了更多的代碼時就做更多的測試。測試不是獨立隔離的活動，它本身就是開發過程的一部分。質量不等於測試，當你把開發過程和測試放到一起，就像在攪拌機里混合攪拌那樣，直到不能區分彼此的時候，你就得到了質量。

質量不等於測試，測試不能保證質量，質量是內建的，不是外加的

質量是開發過程的問題，而不是測試問題

開發對質量負責

開發、測試相融合

寫一段代碼就立刻測試這段代碼，完成更多的代碼就做更多的測試，開發完成。

簡單統一

測試類型

測試類型劃分：小型測試（70%）、中型測試（20%）、大型測試（10%），其實就是分層理念。棄用令人疑惑的測試類型術語：單元測試、代碼級別測試、白盒測試、集成測試、系統測試、端到端測試。

其中一個亮點， Google在2007年，15個試點團隊在不同級別運行：測試認證。開發人員遵循一些特定的測試實踐，拿到期望結果，則通過認證。

測試成熟度等級

測試成熟度，就是剛剛提到的：測試認證。個人看法：在敏捷團隊，如果研發小組得到成熟度認證，可以區分不同程度測試資源投入。

• Level 1

Set up test coverage bundles.

Set up a continuous build.

Classify your tests as Small, Medium, and Large.

Identify nondeterministic tests.

Create a smoke test suite.

• Level 2

No releases with red tests.

Require a smoke test suite to pass before a submit.

Incremental coverage by all tests >= 50%.

Incremental coverage by small tests >= 10%.

At least one feature tested by an integration test.

• Level 3

Require tests for all nontrivial changes.

Incremental coverage by small tests >= 50%.

New significant features are tested by integration tests.

• Level 4

Automate running of smoke tests before submitting new code.

Smoke tests should take less than 30 minutes to run.

No nondeterministic tests.

Total test coverage should be at least 40%.

Test coverage from small tests alone should be at least 25%.

All significant features are tested by integration tests.

• Level 5

Add a test for each nontrivial bug fix.

Actively use available analysis tools.

Total test coverage should be at least 60%.

測試流程

• 測試儘早參與，各個環節參與，多Review文檔，代碼，架構。Code Review 是專門有一套Submit的流程；
• 高度自動化，強調持續集成；
• 測試分大中小測試，大中小範圍、執行人、時間和要求不一樣；

及早參與測試，畢竟質量不是測試出來的，整個研發過程的第一行編碼已經決定了質量的高低，過程中反饋風險，利用有效測試策略消除質量障礙，確保檢驗處有問題的地方及時修改，避免遺漏上線。

版本劃分

先會爬，再會走，最後跑起來，版本劃分短頻快三個要點。

金絲雀版本（Canary Channel），不太可靠的版本，並不適用於發布。就像一隻金絲雀在煤堆里一樣，如果不幸身亡，那說明還有工作要去做。只有超強容忍能力的用戶才有可能使用金絲雀版本來試驗運行，你不能依賴這樣的應用能把實際工作完成。

開發版本（Dev Channel)，是開發工程師們日常工作中使用的版本。所有的同一產品組的工程師都需要去安裝這個版本，並在真正的工作中使用他們。

測試版本（Test Channel），是給內部的狗食，如果能夠有持續不錯的性能表現的話，也可能會是 beta 版本的候選。【譯者注，dog food，一般指自己團隊的產品，給自己或者公司內部的人嘗試使用的中間產品】

Beta 版本或發布版本(The Beta Channel or Release Channel)，是給外部用戶使用的第一個版本。只有在之前的各種版本歷程中通過了測試和真實用戶的槍林彈雨般的驗證後，才會成為 beta 版。

上述的這種從爬到走、走到跑的模式，讓我們在運行一些測試同時又可以對我們的應用系統做一些試驗調整，並從真實用戶和每個版本的每日自動化測試那裡得到及時的反饋。

對於這樣的過程，還有一些分析角度的益處。例如，發現了一個 bug，測試人員可以根據這個 bug 創建一個測試用例，並針對所有的每一個版本都運行這個測試用例，從而可以驗證這個 bug fix 是否在所有的版本中都真正得到了修復。

Google流程中的致命缺陷

• 測試成了開發的拐杖

質量需要每一個人的貢獻，而不專屬於「測試」工程師。我們越不讓開發考慮測試的事情，把測試變得越簡單，開發就越來越不會去做測試。測試在Google是一個獨立的部門，讓這個問題更嚴重。保證質量不但是別人的問題，它甚至還屬於另一個部門。責任方很容易確定，出問題的時候也很容易就把責任推卸給質量部門。

• 開發和測試的組織結構分離有關

測試人員更關注自己的角色，而不是他們的產品，每一個工程師的角色都是為總體產品服務的，而角色本身是次要的。 如果產品不被關注，它就好不了。畢竟，軟體開發的最終目的不是編碼，不是測試，不是文檔，而是完成一個產品。每一個工程師的角色都是為總體產品服務的，而角色本身是次要的。健康的組織一個標誌是，人們會說「我在為Chrome工作」，而不是「我是測試」。

任何角色都不應被過分強調。團隊的每個人都是在為產品工作，而不是為了開發過程中的某個部分。開發過程本身就是為產品服務的。用戶愛上的是產品，而不是開發產品的流程。

在Google，開發與測試的分離造成了基於角色的關聯，阻礙了測試人員對產品的關注。

• 測試人員往往崇拜測試產物勝過軟體本身

測試的價值是在於測試的動作，而不是測試產物。相對於被測代碼來說，測試工程師生成的測試產物都是次要的：測試用例是次要的；測試計劃是次要的；bug報告是次要的。這些產物都需要通過測試活動才能體現價值。所有測試產物的價值，在於他們對代碼的影響，進而通過產品來體現。

獨立的測試團隊，傾向於把重點放在建設和維護測試產物上。如果把測試的目標定位在產品的源碼上，整個產品都將受益。因此，測試人員必須把產品方在第一位。

• 產品經過最嚴格的測試發布以後，用戶幾乎必然發現測試中遺漏的問題

產品經過最嚴格的測試發布以後，用戶有多大可能仍然能發現測試中的遺漏的問題？答案是：幾乎必然發現。是誰在做測試不重要，關鍵是進行了測試。內部試用者、可信賴的測試者、眾包測試者，以及早期用戶都可能比測試工程師更容易發現bug。實際上，TE做的測試越少，支持其他人做的測試越多，效果就越好。

Google軟體測試成長曆程

軟體測試團隊的發展，也是圍繞著質量閉環活動而壯大的，不同的質量活動環節，需要不同的人。剛開始創業的時候，可能一人多職能，到了後面可能是專人專職，分工細化，不管怎麼分，都離不開質量閉環活動。

移動互聯網APP團隊測試技術棧

隨著團隊不斷壯大，技能集合也在擴大，下圖是整理的測試技術棧，通過分層來展示每個方面的覆蓋策略和工具，可以在此基礎上建立梯隊能力。

微信公號搜索：樂少的黑板板

推薦閱讀：