隨著敏捷和微服務(wù)架構(gòu)的引入，CI/CD成為構(gòu)建和部署的標(biāo)準(zhǔn)，即使在沒(méi)有采用微服務(wù)架構(gòu)的項(xiàng)目中也是如此。為了保證已定義的流程和事務(wù)按照預(yù)期運(yùn)行，測(cè)試必不可少。而在應(yīng)對(duì)現(xiàn)代軟件產(chǎn)品頻繁的變化和發(fā)布上，傳統(tǒng)的手工測(cè)試方式在人員和效率上都存在嚴(yán)重不足，因此自動(dòng)化測(cè)試已經(jīng)成為現(xiàn)代軟件研發(fā)過(guò)程中一個(gè)關(guān)鍵組成部分。自動(dòng)化測(cè)試是打通持續(xù)集成和持續(xù)交付的核心，沒(méi)有有效的自動(dòng)化測(cè)試保證，持續(xù)集成和持續(xù)交付就僅僅是一個(gè)沒(méi)有靈魂的軀殼。

2.1 測(cè)試分類

測(cè)試按照不同的維度可以進(jìn)行多種分類。

• 按測(cè)試手段是否手工，可劃分為自動(dòng)化測(cè)試和人工測(cè)試； 

• 按照測(cè)試目的劃分，可分為功能測(cè)試、性能測(cè)試、負(fù)載測(cè)試等。

本文采用Martin Fowler按照層級(jí)分類的方式對(duì)測(cè)試進(jìn)行分類。

Martin Fowler描述測(cè)試金字塔分為單元、服務(wù)和UI三個(gè)層級(jí)。盡管大家對(duì)此的具體描述各不相同（有人將三層分別定義為單元、接口、集成測(cè)試；也有人將整個(gè)金字塔劃分為4-5個(gè)層級(jí)），但金字塔自底向上的結(jié)構(gòu)是大家公認(rèn)和遵循的。

1)單元測(cè)試

單元測(cè)試是針對(duì)代碼單元（通常是類/方法）的測(cè)試，單元測(cè)試的價(jià)值在于能提供快速的反饋，在開發(fā)過(guò)程中就可以對(duì)邏輯單元進(jìn)行驗(yàn)證。好的單元測(cè)試可以幫助改善既有設(shè)計(jì)，在團(tuán)隊(duì)掌握 TDD的前提下，單元測(cè)試能輔助重構(gòu)，幫助提升代碼整潔度。

2)接口（服務(wù)/API）測(cè)試

接口測(cè)試是針對(duì)業(yè)務(wù)接口進(jìn)行的測(cè)試，主要測(cè)試內(nèi)部接口功能實(shí)現(xiàn)是否完整。比如內(nèi)部邏輯是否正常、異常處理是否正確。接口測(cè)試的主要價(jià)值在于接口定義相對(duì)穩(wěn)定，不像界面或底層代碼會(huì)經(jīng)常發(fā)生變化，所以接口測(cè)試比較容易編寫，用例的維護(hù)成本也相對(duì)較低。在接口層面準(zhǔn)備測(cè)試的性價(jià)比相對(duì)較高。

3)集成（UI）測(cè)試

集成測(cè)試從用戶的角度驗(yàn)證產(chǎn)品功能的正確性，測(cè)的是端到端的流程，并且加入用戶場(chǎng)景和數(shù)據(jù)，驗(yàn)證整個(gè)過(guò)程是否健康流暢。集成測(cè)試的業(yè)務(wù)價(jià)值最高，它驗(yàn)證的是一個(gè)完整的流程，但因?yàn)樾枰?yàn)證完整流程，在環(huán)境部署、準(zhǔn)備用例及實(shí)施等方面成本較高，實(shí)施起來(lái)并不容易。

2.2 微服務(wù)架構(gòu)為測(cè)試帶來(lái)的挑戰(zhàn)

微服務(wù)架構(gòu)在解決了應(yīng)用大小、應(yīng)用開發(fā)規(guī)模等問(wèn)題之后也帶來(lái)了一些新的問(wèn)題，比較突出的有微服務(wù)數(shù)量增多、服務(wù)間調(diào)用關(guān)系復(fù)雜等等。復(fù)雜的依賴導(dǎo)致即使項(xiàng)目資深開發(fā)人員也不能一下子梳理出所有關(guān)系。

微服務(wù)和傳統(tǒng)的單體應(yīng)用相比，在測(cè)試策略上會(huì)有一些不太一樣的地方。簡(jiǎn)單來(lái)說(shuō)，在微服務(wù)架構(gòu)中，測(cè)試的層次變得更多，需要測(cè)試的服務(wù)和應(yīng)用也會(huì)變得更多。手動(dòng)執(zhí)行所有的測(cè)試是低效的，無(wú)法跟上互聯(lián)網(wǎng)快速迭代的要求。這時(shí)有必要引入自動(dòng)化測(cè)試來(lái)減輕測(cè)試團(tuán)隊(duì)的壓力，提高測(cè)試效率和測(cè)試質(zhì)量。

2.3 自動(dòng)化測(cè)試

說(shuō)起自動(dòng)化測(cè)試，功能測(cè)試人員可能會(huì)將其想得很高端復(fù)雜。

先來(lái)看一般的功能測(cè)試如何進(jìn)行：設(shè)計(jì)并編寫用例文檔，描述測(cè)試步驟和預(yù)期結(jié)果；測(cè)試人員根據(jù)測(cè)試用例描述按步驟操作，然后判斷實(shí)際結(jié)果與預(yù)期是否一致。如果一致，測(cè)試通過(guò)；如果不符，測(cè)試失敗。

自動(dòng)化測(cè)試要做的事情與功能測(cè)試是一致的。分層理論和自動(dòng)化測(cè)試方法結(jié)合，出現(xiàn)了三個(gè)層面的自動(dòng)化：單元測(cè)試自動(dòng)化、接口測(cè)試自動(dòng)化和UI測(cè)試自動(dòng)化。當(dāng)然，不同層面的自動(dòng)化關(guān)注點(diǎn)是不一樣的。所以，從測(cè)試的行為本質(zhì)上來(lái)看，功能測(cè)試與單元自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試和UI自動(dòng)化測(cè)試并沒(méi)有區(qū)別。唯一的區(qū)別是，一個(gè)由人來(lái)執(zhí)行，一個(gè)由代碼或工具執(zhí)行。

2.4 自動(dòng)化測(cè)試分層

1)單元自動(dòng)化測(cè)試

單元測(cè)試自動(dòng)化，指對(duì)軟件中最小的可測(cè)試單元進(jìn)行檢查和驗(yàn)證，調(diào)用被測(cè)服務(wù)的類或方法，根據(jù)類或方法的參數(shù)，傳入相應(yīng)的數(shù)據(jù)，得到一個(gè)返回結(jié)果，最終斷言返回的結(jié)果是否符合預(yù)期。如果相等，測(cè)試通過(guò)；如果不相等，測(cè)試失敗。

所以，單元測(cè)試關(guān)注的是代碼的實(shí)現(xiàn)與邏輯。單元測(cè)試是最基本的測(cè)試，也是測(cè)試中的最小單元，它的對(duì)象是函數(shù)對(duì)象，也可以包含輸入輸出，針對(duì)的是函數(shù)功能或者函數(shù)內(nèi)部的代碼邏輯，并不包含業(yè)務(wù)邏輯。

該類測(cè)試一般由研發(fā)人員完成，需要借助單元測(cè)試框架，如java的Junit、TestNG，python的unittest等。

2)接口自動(dòng)化測(cè)試

接口自動(dòng)化測(cè)試，主要驗(yàn)證模塊間的調(diào)用返回以及不同系統(tǒng)、服務(wù)間的數(shù)據(jù)交換。接口測(cè)試自動(dòng)化一般在業(yè)務(wù)邏輯層進(jìn)行測(cè)試。根據(jù)接口文檔是RESTful還是RPC？調(diào)用被測(cè)試的接口，構(gòu)造相應(yīng)的請(qǐng)求數(shù)據(jù)，得到返回值，是成功或者失敗。不管輸入的參數(shù)是怎樣的，我們都將得到一個(gè)結(jié)果，最終斷言返回的結(jié)果是否等于預(yù)期結(jié)果。如果相等，測(cè)試通過(guò)；如果不相等，測(cè)試失敗。

所以，接口測(cè)試關(guān)注的是數(shù)據(jù)。只要數(shù)據(jù)正確了，功能就做成大半，剩下的無(wú)非是如何把這些數(shù)據(jù)展示在頁(yè)面上。

常見的接口測(cè)試工具有postman、jmeter、loadrunner等。

3)集成（UI）自動(dòng)化測(cè)試

UI層是用戶使用產(chǎn)品的入口，所有功能通過(guò)這一層提供給用戶，目前測(cè)試工作大多集中在這一層，這種測(cè)試更貼近用戶的行為，模擬用戶點(diǎn)擊了某個(gè)按鈕、在輸入框里輸入了某些指令。有時(shí)可能用戶看到登錄成功了，但UI自動(dòng)化并不知道它剛才的點(diǎn)擊有沒(méi)有生效。所以要找“證據(jù)”，比如登錄成功后頁(yè)面右上角會(huì)顯示“歡迎，xxx”，這就是登錄成功的有力“證據(jù)”。當(dāng)UI自動(dòng)化登錄成功后，就去獲取這個(gè)數(shù)據(jù)進(jìn)行斷言，斷言如果相等，測(cè)試通過(guò)；如果不相等，測(cè)試失敗。

所以，UI自動(dòng)化的關(guān)注點(diǎn)用戶操作形為，以及UI上各種組件是否可用。常見的測(cè)試工具有UFT、Robot Framework、Selenium、Appium等。

4)分層占比實(shí)踐

每種自動(dòng)化測(cè)試都有自己的側(cè)重和優(yōu)劣勢(shì)，在實(shí)際工作中不可能做到均分，因此我們需要制定合理的測(cè)試策略對(duì)其進(jìn)行組織和分配，包括每部分測(cè)試投入多少、測(cè)試用例比例是多少等。

測(cè)試金字塔還有另一個(gè)維度的信息，如上圖所示。

• 越往上，越接近QA、業(yè)務(wù)/最終用戶，越往下，越接近開發(fā)； 

• 越往上，測(cè)試執(zhí)行越慢，越往下，測(cè)試執(zhí)行越快； 

• 越往上，測(cè)試成本越高（越耗時(shí)，失敗時(shí)的信息越模糊，越難跟蹤），越往下，測(cè)試成本越低。

按照測(cè)試金字塔模型以及投入/產(chǎn)出比，我們得知越向下回報(bào)率越高，所以應(yīng)該使用大量的單元測(cè)試和全面的接口測(cè)試來(lái)覆蓋產(chǎn)品提供的基本邏輯和功能，使用少量的集成（UI）測(cè)試來(lái)進(jìn)行前端界面的功能驗(yàn)證。

都說(shuō)業(yè)內(nèi)最佳實(shí)踐看Google，Google的自動(dòng)化分層投入占比是：單元測(cè)試（Unit）：占比70%；接口測(cè)試（Service）：占比20%；集成測(cè)試（UI）：占比10%。

對(duì)現(xiàn)階段公司大部分團(tuán)隊(duì)來(lái)說(shuō)，更符合實(shí)際測(cè)試模式是紡錘模型。新項(xiàng)目中，可能由于時(shí)限原因或者開發(fā)人員習(xí)慣問(wèn)題，一開始并沒(méi)有把單元測(cè)試準(zhǔn)備得很完善；而某些遺留老項(xiàng)目，可能原本就沒(méi)有多少單元測(cè)試。

在上述情況下，一般的做法是先將重心放在中間層的測(cè)試上，原因有以下兩點(diǎn)：

• 第一，中間層投入產(chǎn)出比較高，可以實(shí)現(xiàn)較高的自動(dòng)化率； 

• 第二，可以幫助加強(qiáng)開發(fā)跟測(cè)試人員之間的協(xié)作，提高測(cè)試質(zhì)量。這一層需要開發(fā)跟測(cè)試人員共同定義，因?yàn)殚_發(fā)知道內(nèi)部實(shí)現(xiàn)的細(xì)節(jié)，測(cè)試掌握業(yè)務(wù)場(chǎng)景。

3.1 紡錘型向金字塔型過(guò)渡

當(dāng)項(xiàng)目進(jìn)行一段時(shí)間以后，各層測(cè)試占比有必要向理想型的金字塔型過(guò)渡，這時(shí)需要關(guān)注以下三個(gè)方面：

• 開發(fā)與測(cè)試互相傳遞能力； 

• 全員關(guān)注產(chǎn)品設(shè)計(jì)跟代碼的質(zhì)量； 

• 讓用例逐步下沉，最后逐步過(guò)渡到理想型。

3.2 測(cè)試質(zhì)量評(píng)估

關(guān)于度量，不要用單一的指標(biāo)去評(píng)估測(cè)試和產(chǎn)品質(zhì)量，比如用例通過(guò)率、代碼覆蓋率等都無(wú)法獨(dú)立地評(píng)估產(chǎn)品質(zhì)量。

評(píng)估測(cè)試質(zhì)量時(shí)要關(guān)心以下幾個(gè)方面：

• 第一是用例比例，即每一層的用例比例是多少。 

• 第二是測(cè)試覆蓋率。 

• 第三是測(cè)試總運(yùn)行時(shí)間，因?yàn)榻?jīng)過(guò)優(yōu)化以后，總運(yùn)行時(shí)間一定是越來(lái)越少。 

• 第四是代碼質(zhì)量指標(biāo)，反映代碼的質(zhì)量和整潔度。

引入自動(dòng)化測(cè)試可以為團(tuán)隊(duì)帶來(lái)很多好處，當(dāng)然自動(dòng)化測(cè)試也有其自身的缺點(diǎn)和挑戰(zhàn)。面臨的最大挑戰(zhàn)就是變化，因?yàn)樽兓瘯?huì)導(dǎo)致測(cè)試用例運(yùn)行失敗，所以需要對(duì)自動(dòng)化腳本不斷debug。如何控制成本、降低成本是對(duì)自動(dòng)化測(cè)試工具以及人員能力的挑戰(zhàn)。

另一個(gè)值得注意的是，自動(dòng)化測(cè)試不能完全代替人工測(cè)試，一定的人工探索測(cè)試也是必不可少的。我們一直在不懈努力和探索，本文為自動(dòng)化測(cè)試最佳實(shí)踐系列文章的第一篇，重點(diǎn)介紹了自動(dòng)化測(cè)試的現(xiàn)狀和金字塔模型，接下來(lái)的系列文章中會(huì)繼續(xù)為大家介紹我們的自動(dòng)化測(cè)試實(shí)踐，包括自動(dòng)化測(cè)試平臺(tái)的核心功能、持續(xù)測(cè)試的方法與工具等。

【本文是51CTO專欄機(jī)構(gòu)宜信技術(shù)學(xué)院的原創(chuàng)文章，微信公眾號(hào)“宜信技術(shù)學(xué)院( id: CE_TECH)”】

戳這里，看該作者更多好文