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

測(cè)試組織架構(gòu)

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

? ? ?

• 軟件測(cè)試開(kāi)發(fā)工程師

職責(zé)：負(fù)責(zé)可測(cè)試性和測(cè)試自動(dòng)化體系的長(zhǎng)期有效性。

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

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

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

參與設(shè)計(jì)評(píng)審、重構(gòu)代碼增加可測(cè)試性，編寫(xiě)單元測(cè)試框架和自動(dòng)化測(cè)試框架

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

• 測(cè)試工程師

職責(zé)：評(píng)估對(duì)用戶的影響以及軟件產(chǎn)品整體目標(biāo)上的風(fēng)險(xiǎn)

從用戶的角度來(lái)思考質(zhì)量方面各種問(wèn)題

從開(kāi)發(fā)角度來(lái)看，他們編寫(xiě)用戶使用場(chǎng)景方面的自動(dòng)化用例代碼

從產(chǎn)品角度來(lái)看，他們?cè)u(píng)估整體測(cè)試覆蓋度，并驗(yàn)證其他工程師角色在測(cè)試方面合作的有效性

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

其中，幾個(gè)重要信息：

開(kāi)發(fā)可以做測(cè)試，測(cè)試可以寫(xiě)代碼，Google其實(shí)還沒(méi)有完全做到這一點(diǎn)

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

沒(méi)有測(cè)試開(kāi)發(fā)比例，開(kāi)發(fā)同時(shí)也兼顧測(cè)試，專(zhuān)職測(cè)試讓開(kāi)發(fā)更加有效且高效地做測(cè)試

測(cè)試開(kāi)發(fā)同工同酬

有外包測(cè)試人員

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

? ? ?

? ? ?

測(cè)試質(zhì)量理念

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

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

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

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

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

質(zhì)量是開(kāi)發(fā)過(guò)程的問(wèn)題，而不是測(cè)試問(wèn)題

開(kāi)發(fā)對(duì)質(zhì)量負(fù)責(zé)

開(kāi)發(fā)、測(cè)試相融合

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

簡(jiǎn)單統(tǒng)一

測(cè)試類(lèi)型

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

? ? ?

其中一個(gè)亮點(diǎn)， Google在2007年，15個(gè)試點(diǎn)團(tuán)隊(duì)在不同級(jí)別運(yùn)行：測(cè)試認(rèn)證。開(kāi)發(fā)人員遵循一些特定的測(cè)試實(shí)踐，拿到期望結(jié)果，則通過(guò)認(rèn)證。

測(cè)試成熟度等級(jí)

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

? ? ?

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

測(cè)試流程

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

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

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

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

版本劃分

先會(huì)爬，再會(huì)走，最后跑起來(lái)，版本劃分短頻×××個(gè)要點(diǎn)。

? ? ?

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

開(kāi)發(fā)版本（Dev Channel)，是開(kāi)發(fā)工程師們?nèi)粘９ぷ髦惺褂玫陌姹?。所有的同一產(chǎn)品組的工程師都需要去安裝這個(gè)版本，并在真正的工作中使用他們。

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

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

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

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

Google流程中的致命缺陷

? ? ?

• 測(cè)試成了開(kāi)發(fā)的拐杖

質(zhì)量需要每一個(gè)人的貢獻(xiàn)，而不專(zhuān)屬于“測(cè)試”工程師。我們?cè)讲蛔岄_(kāi)發(fā)考慮測(cè)試的事情，把測(cè)試變得越簡(jiǎn)單，開(kāi)發(fā)就越來(lái)越不會(huì)去做測(cè)試。測(cè)試在Google是一個(gè)獨(dú)立的部門(mén)，讓這個(gè)問(wèn)題更嚴(yán)重。保證質(zhì)量不但是別人的問(wèn)題，它甚至還屬于另一個(gè)部門(mén)。責(zé)任方很容易確定，出問(wèn)題的時(shí)候也很容易就把責(zé)任推卸給質(zhì)量部門(mén)。

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

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

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

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

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

測(cè)試的價(jià)值是在于測(cè)試的動(dòng)作，而不是測(cè)試產(chǎn)物。相對(duì)于被測(cè)代碼來(lái)說(shuō)，測(cè)試工程師生成的測(cè)試產(chǎn)物都是次要的：測(cè)試用例是次要的；測(cè)試計(jì)劃是次要的；bug報(bào)告是次要的。這些產(chǎn)物都需要通過(guò)測(cè)試活動(dòng)才能體現(xiàn)價(jià)值。所有測(cè)試產(chǎn)物的價(jià)值，在于他們對(duì)代碼的影響，進(jìn)而通過(guò)產(chǎn)品來(lái)體現(xiàn)。

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

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

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

Google軟件測(cè)試成長(zhǎng)歷程

? ? ?

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

? ? ?

移動(dòng)互聯(lián)網(wǎng)APP團(tuán)隊(duì)測(cè)試技術(shù)棧

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

? ? ?

總結(jié)

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

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