国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

再談自動化測試——我們在編寫測試時,應該注意什么

My_Oh_My / 1293人閱讀

摘要：原則具體包括自動化獨立性可重復簡單的解釋一下三個原則單元測試應該是全自動執行的。為了保證單元測試穩定可靠且便于維護，需要保證其獨立性。原則編寫單元測試用例時為了保證被測模塊的交付質量需要符合原則。與設計文檔相結合來編寫單元測試。

本文首發于泊浮目的專欄：https://segmentfault.com/blog...
背景

最近項目在測試階段陸陸續續的測出了一些bug.這個情況剛出現的時候,讓筆者很困惑——平時我們的每個feature代碼都是跟隨著大量看起來考慮很周全的case進入代碼倉庫的,然而事實還是打了我們的臉.故在本文,筆者將會從最近的所學所想來談談編寫測試的時候我們應該注意什么.

AIR原則與BCDE原則

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

宏觀上,單元測試要符合AIR原則

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

AIR原則

AIR即空氣,單元測試亦是如此。當業務代碼在線上運行時,可能感覺不到測試用例的存在和價值,但在代碼質量的保障上,卻是非常關鍵的。新增代碼應該同步增加測試用例,修改代碼邏輯時也應該同步保證測試用例成功執行。AIR原則具體包括:

A: Automatic (自動化)

I: Independent (獨立性)

R: Repeatable (可重復)

簡單的解釋一下三個原則:

單元測試應該是全自動執行的。測試用例通常會被頻繁地觸發執行,執行過程必須完全自動化才有意義。

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

為了保證單元測試穩定可靠且便于維護，需要保證其獨立性。用例之間不允許互相調用,也不允許出現執行次序的先后依賴。

BCDE原則

編寫單元測試用例時,為了保證被測模塊的交付質量,需要符合BCDE原則。

B: Border,邊界值測試,包括循環邊界、特殊取值、特殊時間點、數據順序等。

C: Correct,正確的輸入,并得到預期的結果。

D: Design,與設計文檔相結合,來編寫單元測試。

E: Error,單元測試的目標是證明程序有錯,而不是程序無錯。為了發現代碼中潛在的錯誤,我們需要在編寫測試用例時有一些強制的錯誤輸入(如非法數據、異常流程、非業務允許輸入等)來得到預期的錯誤結果。

在ZStack白盒集成測試中實踐原則

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

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

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

I: 如果上一個測試沒有清理干凈狀態,則會影響下一個測試

R: 基于上面提到的I,很有可能導致可重復性大打折扣

當然,出現這些問題時則表示當前的代碼中有bug.但單元測試則不會受到這樣的影響——它能測出bug,AIR原則也得以保證.

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

Border Test && Error Test

邊界測試是用來探測和驗證代碼在處理極端的情況下會發生什么.而錯誤測試為了保證ZStack在一些錯誤的狀態下做出我們所期待的行為.

那么我們該如何編寫這樣的測試呢?我們先來簡單的理一下創建Vm的流程:

VmImageSelectBackupStorageFlow

VmAllocateHostFlow

VmAllocatePrimaryStorageFlow

VmAllocateVolumeFlow

VmAllocateNicFlow

VmInstantiateResourcePreFlow

VmCreateOnHypervisorFlow

VmInstantiateResourcePostFlow

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

我們可以看到,根據不同的策略,allocateHost里還會有好幾個flow.而由于松耦合架構,我們可以在測試中輕易的模擬極端問題的出現,如:

找不到合適的BackupStorage

HostCapacity的不夠

Agent返回的回復在某一個時刻與管理節點的狀態不同

.......

以此類推,以上創建vm的8個flow都可以輕易模擬各種邊界條件及錯誤情況.

Correct Test && Design Test

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

在編寫正確性測試時,我們可以考慮額外關注以下幾點:

APIParam在各個Flow間中轉時是否如預期

關注管理節點內的服務:

Flow之間調用的時序是否符合預期

Flow之間流轉時,業務目標狀態是否符合預期

關注管理節點外的服務:

對于agent的請求是否符合預期

在API調用完后,相關資源的目標狀態是否符合預期

而與文檔結合的測試用例,則應當由團隊的測試人員來定義.可以確定的是,這類的測試更加關注于API(即輸入輸出),而不是內部的狀態.

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/77462.html

相關文章

  • 再談移動端適配和點5像素的由來

    摘要：再談移動端適配百分比解決方案的缺點在我們的項目中大量的使用百分比來解決頁面在寬度上的自適應，其實在高度上并沒有很好的自適應。 前言 這篇文章的內容如題目一樣，主要分為兩個部分， 談談業內主流的移動端適配解決方案 點5像素的由來和實現方法 建議在讀這篇文章的時候先讀下這篇文章《高清屏概念解析與檢測設備像素比的方法_20161005》，因為這些文章涉及的很多概念在這篇文章中都會提到。 ...

    lordharrd 評論0 收藏0

  • CI Weekly #6 | 再談 Docker / CI / CD 實踐經驗

    摘要：阿里云效平臺基于理念的私有平臺實踐本文將系統的從個方面，分享互娛運維團隊對于運維平臺實踐經驗及未來展望，希望對大家有一些參考意義。 CI Weekly 圍繞『 軟件工程效率提升』 進行一系列技術內容分享，包括國內外持續集成、持續交付，持續部署、自動化測試、 DevOps 等實踐教程、工具與資源，以及一些工程師文化相關的程序員 Tips 。同步于 flow.ci Blog、微信公眾號、官...

    justCoding 評論0 收藏0

  • 再談C++中的構造函數，深入理解構造函數(上篇)

    摘要：注意這種只能發生在單參數構造函數中舉個例子創建一個類，類該類如下，有個單參數的構造函數。默認構造函數當構造函數不帶參數時，我們就把這個構造函數叫做默認構造函數。 前...

    fantix 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<