資訊專欄INFORMATION COLUMN
摘要：原則具體包括自動化獨立性可重復(fù)簡單的解釋一下三個原則單元測試應(yīng)該是全自動執(zhí)行的。為了保證單元測試穩(wěn)定可靠且便于維護(hù)，需要保證其獨立性。原則編寫單元測試用例時為了保證被測模塊的交付質(zhì)量需要符合原則。與設(shè)計文檔相結(jié)合來編寫單元測試。
本文首發(fā)于泊浮目的專欄：https://segmentfault.com/blog...背景
最近項目在測試階段陸陸續(xù)續(xù)的測出了一些bug.這個情況剛出現(xiàn)的時候,讓筆者很困惑——平時我們的每個feature代碼都是跟隨著大量看起來考慮很周全的case進(jìn)入代碼倉庫的,然而事實還是打了我們的臉.故在本文,筆者將會從最近的所學(xué)所想來談?wù)劸帉憸y試的時候我們應(yīng)該注意什么.
AIR原則與BCDE原則前陣子看了一本書,里面提到了單元測試的一些原則:
宏觀上,單元測試要符合AIR原則
微觀上,單元測試的代碼層面要符合BCDE原則
AIR原則AIR即空氣,單元測試亦是如此。當(dāng)業(yè)務(wù)代碼在線上運行時,可能感覺不到測試用例的存在和價值,但在代碼質(zhì)量的保障上,卻是非常關(guān)鍵的。新增代碼應(yīng)該同步增加測試用例,修改代碼邏輯時也應(yīng)該同步保證測試用例成功執(zhí)行。AIR原則具體包括:
A: Automatic (自動化)
I: Independent (獨立性)
R: Repeatable (可重復(fù))
簡單的解釋一下三個原則:
單元測試應(yīng)該是全自動執(zhí)行的。測試用例通常會被頻繁地觸發(fā)執(zhí)行,執(zhí)行過程必須完全自動化才有意義。
如果單元測試的輸出結(jié)果需要人工介入檢查,那么它一定是不合格的。單元測試中不允許使用System.out等方法來進(jìn)行人工驗證,而必須使用斷言來驗證。
為了保證單元測試穩(wěn)定可靠且便于維護(hù)，需要保證其獨立性。用例之間不允許互相調(diào)用,也不允許出現(xiàn)執(zhí)行次序的先后依賴。
BCDE原則編寫單元測試用例時,為了保證被測模塊的交付質(zhì)量,需要符合BCDE原則。
B: Border,邊界值測試,包括循環(huán)邊界、特殊取值、特殊時間點、數(shù)據(jù)順序等。
C: Correct,正確的輸入,并得到預(yù)期的結(jié)果。
D: Design,與設(shè)計文檔相結(jié)合,來編寫單元測試。
E: Error,單元測試的目標(biāo)是證明程序有錯,而不是程序無錯。為了發(fā)現(xiàn)代碼中潛在的錯誤,我們需要在編寫測試用例時有一些強制的錯誤輸入(如非法數(shù)據(jù)、異常流程、非業(yè)務(wù)允許輸入等)來得到預(yù)期的錯誤結(jié)果。
在ZStack白盒集成測試中實踐原則之前提到的原則是基于單元測試的,但在ZStack的白盒測試中也可以作為有價值的參考.
戳此了解ZStack的白盒集成測試:https://segmentfault.com/a/11...
由于ZStack的整套測試框架也是基于Junit擴展而來,因此也是一定程度上遵循了上面提到的AIR原則.除了A原則,I和R原則在一定程度上打了折扣:
I: 如果上一個測試沒有清理干凈狀態(tài),則會影響下一個測試
R: 基于上面提到的I,很有可能導(dǎo)致可重復(fù)性大打折扣
當(dāng)然,出現(xiàn)這些問題時則表示當(dāng)前的代碼中有bug.但單元測試則不會受到這樣的影響——它能測出bug,AIR原則也得以保證.
在本次示例中,我們將以VmInstance的創(chuàng)建API即——APICreateVmInstacneMsg作為測試對象.如果讀者不是很了解上下文,也可以簡單的看一下這個Case:OneVmBasicLifeCycleCase
Border Test && Error Test邊界測試是用來探測和驗證代碼在處理極端的情況下會發(fā)生什么.而錯誤測試為了保證ZStack在一些錯誤的狀態(tài)下做出我們所期待的行為.
那么我們該如何編寫這樣的測試呢?我們先來簡單的理一下創(chuàng)建Vm的流程:
VmImageSelectBackupStorageFlow
VmAllocateHostFlow
VmAllocatePrimaryStorageFlow
VmAllocateVolumeFlow
VmAllocateNicFlow
VmInstantiateResourcePreFlow
VmCreateOnHypervisorFlow
VmInstantiateResourcePostFlow
而其中每一個步驟可以分成好幾個小步驟,以VmAllocateHostFlow為例:
我們可以看到,根據(jù)不同的策略,allocateHost里還會有好幾個flow.而由于松耦合架構(gòu),我們可以在測試中輕易的模擬極端問題的出現(xiàn),如:
找不到合適的BackupStorage
HostCapacity的不夠
Agent返回的回復(fù)在某一個時刻與管理節(jié)點的狀態(tài)不同
.......
以此類推,以上創(chuàng)建vm的8個flow都可以輕易模擬各種邊界條件及錯誤情況.
Correct Test && Design Test正確性測試聽起來應(yīng)該會很簡單,(比如調(diào)用一個API,然后看結(jié)果返回是否正確)但如果放到集成測試中,我們還是可以拓展出一些額外的關(guān)注點的.還是以上面提到的createVm為例子,我們看到了8個flow,然后里面可能還嵌套著好幾個子flow.如圖所示:
在編寫正確性測試時,我們可以考慮額外關(guān)注以下幾點:
APIParam在各個Flow間中轉(zhuǎn)時是否如預(yù)期
關(guān)注管理節(jié)點內(nèi)的服務(wù):
Flow之間調(diào)用的時序是否符合預(yù)期
Flow之間流轉(zhuǎn)時,業(yè)務(wù)目標(biāo)狀態(tài)是否符合預(yù)期
關(guān)注管理節(jié)點外的服務(wù):
對于agent的請求是否符合預(yù)期
在API調(diào)用完后,相關(guān)資源的目標(biāo)狀態(tài)是否符合預(yù)期
而與文檔結(jié)合的測試用例,則應(yīng)當(dāng)由團(tuán)隊的測試人員來定義.可以確定的是,這類的測試更加關(guān)注于API(即輸入輸出),而不是內(nèi)部的狀態(tài).
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/77462.html
摘要：再談移動端適配百分比解決方案的缺點在我們的項目中大量的使用百分比來解決頁面在寬度上的自適應(yīng)，其實在高度上并沒有很好的自適應(yīng)。 前言 這篇文章的內(nèi)容如題目一樣，主要分為兩個部分， 談?wù)剺I(yè)內(nèi)主流的移動端適配解決方案 點5像素的由來和實現(xiàn)方法 建議在讀這篇文章的時候先讀下這篇文章《高清屏概念解析與檢測設(shè)備像素比的方法_20161005》，因為這些文章涉及的很多概念在這篇文章中都會提到。 ...
摘要：阿里云效平臺基于理念的私有平臺實踐本文將系統(tǒng)的從個方面，分享互娛運維團(tuán)隊對于運維平臺實踐經(jīng)驗及未來展望，希望對大家有一些參考意義。 CI Weekly 圍繞『 軟件工程效率提升』 進(jìn)行一系列技術(shù)內(nèi)容分享，包括國內(nèi)外持續(xù)集成、持續(xù)交付，持續(xù)部署、自動化測試、 DevOps 等實踐教程、工具與資源，以及一些工程師文化相關(guān)的程序員 Tips 。同步于 flow.ci Blog、微信公眾號、官...
摘要：注意這種只能發(fā)生在單參數(shù)構(gòu)造函數(shù)中舉個例子創(chuàng)建一個類，類該類如下，有個單參數(shù)的構(gòu)造函數(shù)。默認(rèn)構(gòu)造函數(shù)當(dāng)構(gòu)造函數(shù)不帶參數(shù)時，我們就把這個構(gòu)造函數(shù)叫做默認(rèn)構(gòu)造函數(shù)。 前...
閱讀 864·2021-11-19 11:29
閱讀 3357·2021-09-26 10:15
閱讀 2867·2021-09-22 10:02
閱讀 2442·2021-09-02 15:15
閱讀 1979·2019-08-30 15:56
閱讀 2415·2019-08-30 15:54
閱讀 2914·2019-08-29 16:59
閱讀 642·2019-08-29 16:20
