網(wǎng)上有《What Test Engineers do at Google》的原文翻譯，以及相關(guān)中文書籍《google軟件測試之道》。今天不會在這里搬內(nèi)容，寫一些讀書筆記和感悟。

測試組織架構(gòu)

測試團隊成敗，組織架構(gòu)也是影響因素之一。Google的組織匯報關(guān)系被劃分為不同的專注領(lǐng)域，包括：客戶端、地理、廣告、Apps、移動等等，所有工程師都匯報給這些專注領(lǐng)域的管理者、總監(jiān)或副總裁。而測試是獨立存在的部門，測試依托在各個產(chǎn)品領(lǐng)域部門內(nèi)，稱之為工程生產(chǎn)力團隊。

? ? ?

• 軟件測試開發(fā)工程師

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

扮演質(zhì)量顧問的角色

在單元測試方面給予開發(fā)人員支持

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

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

更加關(guān)注于質(zhì)量提升和測試覆蓋率的增加，SET寫代碼的目的是可以讓SWE測試自己的功能

• 測試工程師

職責：評估對用戶的影響以及軟件產(chǎn)品整體目標上的風(fēng)險

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

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

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

產(chǎn)品專家、質(zhì)量顧問和風(fēng)險分析師

其中，幾個重要信息：

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

SET需要編碼，熟悉系統(tǒng)設(shè)計，個人覺得更像測試架構(gòu)師的角色

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

測試開發(fā)同工同酬

有外包測試人員

曾經(jīng)介紹過傳統(tǒng)軟件測試人員以黑盒測試為主，在團隊轉(zhuǎn)型中，我們已經(jīng)做出了改變，優(yōu)先解決單一端的全棧測試，并且把單元測試作為一個關(guān)注點分水嶺。

? ? ?

? ? ?

測試質(zhì)量理念

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

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

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

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

質(zhì)量不等于測試，測試不能保證質(zhì)量，質(zhì)量是內(nèi)建的，不是外加的

質(zhì)量是開發(fā)過程的問題，而不是測試問題

開發(fā)對質(zhì)量負責

開發(fā)、測試相融合

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

簡單統(tǒng)一

測試類型

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

? ? ?

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

測試成熟度等級

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

? ? ?

• 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%.

測試流程

• 測試盡早參與，各個環(huán)節(jié)參與，多Review文檔，代碼，架構(gòu)。Code Review 是專門有一套Submit的流程；

• 高度自動化，強調(diào)持續(xù)集成；

• 測試分大中小測試，大中小范圍、執(zhí)行人、時間和要求不一樣；

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

版本劃分

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

? ? ?

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

開發(fā)版本（Dev Channel)，是開發(fā)工程師們?nèi)粘９ぷ髦惺褂玫陌姹尽Ｋ械耐划a(chǎn)品組的工程師都需要去安裝這個版本，并在真正的工作中使用他們。

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

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

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

對于這樣的過程，還有一些分析角度的益處。例如，發(fā)現(xiàn)了一個 bug，測試人員可以根據(jù)這個 bug 創(chuàng)建一個測試用例，并針對所有的每一個版本都運行這個測試用例，從而可以驗證這個 bug fix 是否在所有的版本中都真正得到了修復(fù)。

Google流程中的致命缺陷

? ? ?

• 測試成了開發(fā)的拐杖

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

• 開發(fā)和測試的組織結(jié)構(gòu)分離有關(guān)

測試人員更關(guān)注自己的角色，而不是他們的產(chǎn)品，每一個工程師的角色都是為總體產(chǎn)品服務(wù)的，而角色本身是次要的。 ? 如果產(chǎn)品不被關(guān)注，它就好不了。畢竟，軟件開發(fā)的最終目的不是編碼，不是測試，不是文檔，而是完成一個產(chǎn)品。每一個工程師的角色都是為總體產(chǎn)品服務(wù)的，而角色本身是次要的。健康的組織一個標志是，人們會說“我在為Chrome工作”，而不是“我是測試”。

任何角色都不應(yīng)被過分強調(diào)。團隊的每個人都是在為產(chǎn)品工作，而不是為了開發(fā)過程中的某個部分。開發(fā)過程本身就是為產(chǎn)品服務(wù)的。用戶愛上的是產(chǎn)品，而不是開發(fā)產(chǎn)品的流程。

在Google，開發(fā)與測試的分離造成了基于角色的關(guān)聯(lián)，阻礙了測試人員對產(chǎn)品的關(guān)注。

• 測試人員往往崇拜測試產(chǎn)物勝過軟件本身

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

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

• 產(chǎn)品經(jīng)過最嚴格的測試發(fā)布以后，用戶幾乎必然發(fā)現(xiàn)測試中遺漏的問題

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

Google軟件測試成長歷程

? ? ?

軟件測試團隊的發(fā)展，也是圍繞著質(zhì)量閉環(huán)活動而壯大的，不同的質(zhì)量活動環(huán)節(jié)，需要不同的人。剛開始創(chuàng)業(yè)的時候，可能一人多職能，到了后面可能是專人專職，分工喜歡，不管怎么分，都離不開質(zhì)量閉環(huán)活動。

? ? ?

移動互聯(lián)網(wǎng)APP團隊測試技術(shù)棧

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

? ? ?

總結(jié)

以上是生活随笔為你收集整理的读Google是如何做测试的的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。