讀Google是如何作測試的

網上有《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團隊測試技術棧

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