摘要：原則具體包括自動(dòng)化獨(dú)立性可重復(fù)簡單的解釋一下三個(gè)原則單元測(cè)試應(yīng)該是全自動(dòng)執(zhí)行的。為了保證單元測(cè)試穩(wěn)定可靠且便于維護(hù)，需要保證其獨(dú)立性。原則編寫單元測(cè)試用例時(shí)為了保證被測(cè)模塊的交付質(zhì)量需要符合原則。與設(shè)計(jì)文檔相結(jié)合來編寫單元測(cè)試。

本文首發(fā)于泊浮目的專欄：https://segmentfault.com/blog...

最近項(xiàng)目在測(cè)試階段陸陸續(xù)續(xù)的測(cè)出了一些bug.這個(gè)情況剛出現(xiàn)的時(shí)候,讓筆者很困惑——平時(shí)我們的每個(gè)feature代碼都是跟隨著大量看起來考慮很周全的case進(jìn)入代碼倉庫的,然而事實(shí)還是打了我們的臉.故在本文,筆者將會(huì)從最近的所學(xué)所想來談?wù)劸帉憸y(cè)試的時(shí)候我們應(yīng)該注意什么.

前陣子看了一本書,里面提到了單元測(cè)試的一些原則:

宏觀上,單元測(cè)試要符合AIR原則

微觀上,單元測(cè)試的代碼層面要符合BCDE原則

AIR即空氣,單元測(cè)試亦是如此。當(dāng)業(yè)務(wù)代碼在線上運(yùn)行時(shí),可能感覺不到測(cè)試用例的存在和價(jià)值,但在代碼質(zhì)量的保障上,卻是非常關(guān)鍵的。新增代碼應(yīng)該同步增加測(cè)試用例,修改代碼邏輯時(shí)也應(yīng)該同步保證測(cè)試用例成功執(zhí)行。AIR原則具體包括:

A: Automatic (自動(dòng)化)

I: Independent (獨(dú)立性)

R: Repeatable (可重復(fù))

簡單的解釋一下三個(gè)原則:

單元測(cè)試應(yīng)該是全自動(dòng)執(zhí)行的。測(cè)試用例通常會(huì)被頻繁地觸發(fā)執(zhí)行,執(zhí)行過程必須完全自動(dòng)化才有意義。

如果單元測(cè)試的輸出結(jié)果需要人工介入檢查,那么它一定是不合格的。單元測(cè)試中不允許使用System.out等方法來進(jìn)行人工驗(yàn)證,而必須使用斷言來驗(yàn)證。

為了保證單元測(cè)試穩(wěn)定可靠且便于維護(hù)，需要保證其獨(dú)立性。用例之間不允許互相調(diào)用,也不允許出現(xiàn)執(zhí)行次序的先后依賴。

編寫單元測(cè)試用例時(shí),為了保證被測(cè)模塊的交付質(zhì)量,需要符合BCDE原則。

B: Border,邊界值測(cè)試,包括循環(huán)邊界、特殊取值、特殊時(shí)間點(diǎn)、數(shù)據(jù)順序等。

C: Correct,正確的輸入,并得到預(yù)期的結(jié)果。

D: Design,與設(shè)計(jì)文檔相結(jié)合,來編寫單元測(cè)試。

E: Error,單元測(cè)試的目標(biāo)是證明程序有錯(cuò),而不是程序無錯(cuò)。為了發(fā)現(xiàn)代碼中潛在的錯(cuò)誤,我們需要在編寫測(cè)試用例時(shí)有一些強(qiáng)制的錯(cuò)誤輸入(如非法數(shù)據(jù)、異常流程、非業(yè)務(wù)允許輸入等)來得到預(yù)期的錯(cuò)誤結(jié)果。

之前提到的原則是基于單元測(cè)試的,但在ZStack的白盒測(cè)試中也可以作為有價(jià)值的參考.

戳此了解ZStack的白盒集成測(cè)試:https://segmentfault.com/a/11...

由于ZStack的整套測(cè)試框架也是基于Junit擴(kuò)展而來,因此也是一定程度上遵循了上面提到的AIR原則.除了A原則,I和R原則在一定程度上打了折扣:

I: 如果上一個(gè)測(cè)試沒有清理干凈狀態(tài),則會(huì)影響下一個(gè)測(cè)試

R: 基于上面提到的I,很有可能導(dǎo)致可重復(fù)性大打折扣

當(dāng)然,出現(xiàn)這些問題時(shí)則表示當(dāng)前的代碼中有bug.但單元測(cè)試則不會(huì)受到這樣的影響——它能測(cè)出bug,AIR原則也得以保證.

在本次示例中,我們將以VmInstance的創(chuàng)建API即——APICreateVmInstacneMsg作為測(cè)試對(duì)象.如果讀者不是很了解上下文,也可以簡單的看一下這個(gè)Case:OneVmBasicLifeCycleCase

邊界測(cè)試是用來探測(cè)和驗(yàn)證代碼在處理極端的情況下會(huì)發(fā)生什么.而錯(cuò)誤測(cè)試為了保證ZStack在一些錯(cuò)誤的狀態(tài)下做出我們所期待的行為.

那么我們?cè)撊绾尉帉戇@樣的測(cè)試呢?我們先來簡單的理一下創(chuàng)建Vm的流程:

VmImageSelectBackupStorageFlow

VmAllocateHostFlow

VmAllocatePrimaryStorageFlow

VmAllocateVolumeFlow

VmAllocateNicFlow

VmInstantiateResourcePreFlow

VmCreateOnHypervisorFlow

VmInstantiateResourcePostFlow

而其中每一個(gè)步驟可以分成好幾個(gè)小步驟,以VmAllocateHostFlow為例:

我們可以看到,根據(jù)不同的策略,allocateHost里還會(huì)有好幾個(gè)flow.而由于松耦合架構(gòu),我們可以在測(cè)試中輕易的模擬極端問題的出現(xiàn),如:

找不到合適的BackupStorage

HostCapacity的不夠

Agent返回的回復(fù)在某一個(gè)時(shí)刻與管理節(jié)點(diǎn)的狀態(tài)不同

.......

以此類推,以上創(chuàng)建vm的8個(gè)flow都可以輕易模擬各種邊界條件及錯(cuò)誤情況.

正確性測(cè)試聽起來應(yīng)該會(huì)很簡單,(比如調(diào)用一個(gè)API,然后看結(jié)果返回是否正確)但如果放到集成測(cè)試中,我們還是可以拓展出一些額外的關(guān)注點(diǎn)的.還是以上面提到的createVm為例子,我們看到了8個(gè)flow,然后里面可能還嵌套著好幾個(gè)子flow.如圖所示:

在編寫正確性測(cè)試時(shí),我們可以考慮額外關(guān)注以下幾點(diǎn):

APIParam在各個(gè)Flow間中轉(zhuǎn)時(shí)是否如預(yù)期

關(guān)注管理節(jié)點(diǎn)內(nèi)的服務(wù):

Flow之間調(diào)用的時(shí)序是否符合預(yù)期

Flow之間流轉(zhuǎn)時(shí),業(yè)務(wù)目標(biāo)狀態(tài)是否符合預(yù)期

關(guān)注管理節(jié)點(diǎn)外的服務(wù):

對(duì)于agent的請(qǐng)求是否符合預(yù)期

在API調(diào)用完后,相關(guān)資源的目標(biāo)狀態(tài)是否符合預(yù)期

而與文檔結(jié)合的測(cè)試用例,則應(yīng)當(dāng)由團(tuán)隊(duì)的測(cè)試人員來定義.可以確定的是,這類的測(cè)試更加關(guān)注于API(即輸入輸出),而不是內(nèi)部的狀態(tài).