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

測試組織架構(gòu)

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

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

職責(zé)：負(fù)責(zé)可測試性和測試自動化體系的長期有效性。

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

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

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

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

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

測試工程師

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

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

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

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

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

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

開發(fā)可以做測試讳苦，測試可以寫代碼，Google其實(shí)還沒有完全做到這一點(diǎn)

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

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

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

有外包測試人員

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

測試質(zhì)量理念

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

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

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

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

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

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

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

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

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

簡單統(tǒng)一

測試類型

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

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

測試成熟度等級

測試成熟度，就是剛剛提到的：測試認(rèn)證入挣。個(gè)人看法：在敏捷團(tuán)隊(duì)亿乳，如果研發(fā)小組得到成熟度認(rèn)證，可以區(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%.

測試流程

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

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

測試分大中小測試勋拟，大中小范圍勋磕、執(zhí)行人、時(shí)間和要求不一樣指黎；

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

版本劃分

先會爬所计，再會走柠辞，最后跑起來，版本劃分短頻快三個(gè)要點(diǎn)主胧。

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

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

測試版本（Test Channel）肝陪，是給內(nèi)部的狗食驳庭，如果能夠有持續(xù)不錯(cuò)的性能表現(xiàn)的話，也可能會是 beta 版本的候選氯窍∪侣樱【譯者注，dog food荞驴，一般指自己團(tuán)隊(duì)的產(chǎn)品不皆，給自己或者公司內(nèi)部的人嘗試使用的中間產(chǎn)品】

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

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

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

Google流程中的致命缺陷

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

質(zhì)量需要每一個(gè)人的貢獻(xiàn)，而不專屬于“測試”工程師淘衙。我們越不讓開發(fā)考慮測試的事情传藏，把測試變得越簡單，開發(fā)就越來越不會去做測試彤守。測試在Google是一個(gè)獨(dú)立的部門毯侦，讓這個(gè)問題更嚴(yán)重。保證質(zhì)量不但是別人的問題具垫，它甚至還屬于另一個(gè)部門侈离。責(zé)任方很容易確定，出問題的時(shí)候也很容易就把責(zé)任推卸給質(zhì)量部門做修。

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

測試人員更關(guān)注自己的角色霍狰，而不是他們的產(chǎn)品抡草，每一個(gè)工程師的角色都是為總體產(chǎn)品服務(wù)的，而角色本身是次要的蔗坯。

如果產(chǎn)品不被關(guān)注康震，它就好不了。畢竟宾濒，軟件開發(fā)的最終目的不是編碼腿短，不是測試，不是文檔绘梦，而是完成一個(gè)產(chǎn)品橘忱。每一個(gè)工程師的角色都是為總體產(chǎn)品服務(wù)的，而角色本身是次要的卸奉。健康的組織一個(gè)標(biāo)志是钝诚，人們會說“我在為Chrome工作”，而不是“我是測試”榄棵。

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

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

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

測試的價(jià)值是在于測試的動作袱饭，而不是測試產(chǎn)物。相對于被測代碼來說瓢喉，測試工程師生成的測試產(chǎn)物都是次要的：測試用例是次要的宁赤；測試計(jì)劃是次要的；bug報(bào)告是次要的栓票。這些產(chǎn)物都需要通過測試活動才能體現(xiàn)價(jià)值。所有測試產(chǎn)物的價(jià)值愕够，在于他們對代碼的影響走贪，進(jìn)而通過產(chǎn)品來體現(xiàn)。

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

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

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

Google軟件測試成長歷程

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

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

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