軟件測試中建立單元測試標(biāo)準(zhǔn)-1

第第頁軟件測試中建立單元測試標(biāo)準(zhǔn)軟件測試中建立單元測試標(biāo)準(zhǔn)

發(fā)表于：2023-11-19來源：：點(diǎn)擊數(shù)：標(biāo)簽：軟件測試單元

軟件測試中建立單元測試標(biāo)準(zhǔn)是時候出新版本了。那么應(yīng)該把什么包括進(jìn)來？顯然，它應(yīng)該包括每個模塊的最新的最好的版本。對吧？“最新的和最好的”基于一個假設(shè)：最新的版本就是最好的版本。最新的版本添加了特性，糾正了問題，簡而言之，改進(jìn)了之前的版本

軟件測試中建立單元測試標(biāo)準(zhǔn)

是時候出新版本了。那么應(yīng)該把什么包括進(jìn)來？顯然，它應(yīng)該包括每個模塊的最新的最好的版本。對吧？

“最新的和最好的”基于一個假設(shè)：最新的版本就是最好的版本。最新的版本添加了特性，糾正了問題，簡而言之，改進(jìn)了之前的版本。怎么會不是最好的呢？

但是，實(shí)際上，事情并不是你想象的那么簡單。那些新的特性可能與其它現(xiàn)有的功能不兼容。用戶依賴的東西可能消失了。新的特性可能削弱了可用性（尤其是對新用戶來說）。還有，那些bug總是在這些新的改變的代碼中出現(xiàn)。

因此，我們?nèi)绾尾拍芘卸ㄗ钚碌木褪亲詈玫?？我們?nèi)绾沃来a真的準(zhǔn)備好了被包括到下一個build中？很多開發(fā)組通過建立升級標(biāo)準(zhǔn)來解決這個問題。升級標(biāo)準(zhǔn)是關(guān)于某個模塊是否準(zhǔn)備好包括在一個build版本中的判定策略。

單元測試標(biāo)準(zhǔn)

雖然可以把很多別的東西包括到你的升級標(biāo)準(zhǔn)中來，但是單元測試是所有這些標(biāo)準(zhǔn)的基礎(chǔ)。幾乎每個組織都假設(shè)軟件開發(fā)人員在做適當(dāng)?shù)膯卧獪y試。但是不幸的是，不同的人對“適當(dāng)”的測試傾向于采用非常不一樣的理解。

好的實(shí)踐要求開發(fā)人員文檔化它們的測試，并且對那些測試進(jìn)行同行評審以確保有適當(dāng)?shù)母采w率。如果使用自動化測試，那么開發(fā)人員能簡單地為開發(fā)工具創(chuàng)建測試腳本，并且提交那些腳本用于評審。

當(dāng)然，對于什么應(yīng)該包括在單元測試中必須建立一個小組的標(biāo)準(zhǔn)。作為一個開發(fā)組，關(guān)于應(yīng)該做什么測試要達(dá)成一致的共識需要花費(fèi)一些時間和做出一些權(quán)衡，但是花在這里的時間會從正確的構(gòu)建過程中得到加倍的回報！讓我們看看一些單元測試期望的例子。

功能

當(dāng)然，每個模塊必須被測試以確保它滿足設(shè)計的要求，并且確保它做了真正應(yīng)該做的正確的事情。它應(yīng)該處理什么樣的輸入？必須完成什么工作？會提供什么服務(wù)？它應(yīng)該產(chǎn)生怎樣的輸出？它必須管理什么數(shù)據(jù),應(yīng)該怎樣使用那些數(shù)據(jù)？我們必須確保這個模塊真正做了它需要做的事情。

負(fù)面測試

然后是錯誤處理。當(dāng)出現(xiàn)錯誤時這個模塊會做“正確”的事情嗎？當(dāng)它處理某些特殊的輸入時會出現(xiàn)什么情況？缺乏數(shù)據(jù)組成或數(shù)據(jù)輸入的順序被打亂的時候會怎樣？當(dāng)需要輸入數(shù)值數(shù)據(jù)時給它非數(shù)值數(shù)據(jù)會怎樣？數(shù)據(jù)溢出？如果它接收到一個從數(shù)據(jù)庫或網(wǎng)路接口返回的錯誤狀態(tài)時會怎樣？它會如何處理？一個模塊在被認(rèn)為完成之前，必須正確地處理所有錯誤條件。

覆蓋

我們都知道完全的測試不是軟件測試的一個合理目標(biāo)。太多的輸入組合，事件的發(fā)生有太多的可能順序，太多不同的出錯方式，因此完整地測試所有東西，即使是一個很小的程序，也是不可能的。

但是代碼和路徑覆蓋是單元測試可達(dá)到的一個目標(biāo)。事實(shí)上，單元測試階段是把完整覆蓋代碼和路徑作為一個合理的目標(biāo)的唯一時間。

-代碼覆蓋

在單元測試過程中，要求代碼的每一行都被執(zhí)行到，這一點(diǎn)都不過分（并且有很多分析工具可以幫助我們確保這點(diǎn)）。一些代碼（尤其是錯誤處理）是不能被測試到的，除非采用額外的步驟（例如編寫一個傳遞壞數(shù)據(jù)的函數(shù)，或者把錯誤代碼注入到內(nèi)存中），但是這些不僅僅是適合做的，而且對于確保程序可以處理各種應(yīng)該處理的情況來說非常關(guān)鍵的！

-路徑覆蓋

除了代碼行覆蓋，測試代碼的每一個路徑也是非常合理的。例如，我們可以確保每一個“if”的分支都經(jīng)過了，并且確保每一個“case”的所有分支都得到了執(zhí)行。我們還可以確保每一個循環(huán)路徑的初始化和終止條件都是正確的。

回歸測試

這些都是“新鮮出爐”的代碼應(yīng)該測試的內(nèi)容，但是如果改變了一點(diǎn)點(diǎn)的代碼模塊應(yīng)該做多少測試呢？在單元級別，應(yīng)該做多少回歸測試呢？這是很容易誤解的地方：因?yàn)橹皇呛苄〉母淖?，所以不值得花費(fèi)很多的時間去測試它。

確實(shí)，對于每次一小行的代碼的改變我們不能進(jìn)行完整的測試。但是，同時，這些“很小”的改動通常帶來潛在的、重大的、非預(yù)期的影響。最好的方法是恰當(dāng)?shù)卦u估回歸測試：結(jié)合基于風(fēng)險的測試和區(qū)域影響測試。

基于風(fēng)險的測試

基于風(fēng)險的測試指基于缺陷的風(fēng)險來選擇測試。對于風(fēng)險有兩個方面：可能性和影響程度。

可能性是判斷更改會造成某些問題的機(jī)會。我們應(yīng)該測試那些可能出現(xiàn)問題的地方。評估代碼改變的地方是其中一個判斷的方式，另外一個是尋找曾經(jīng)出現(xiàn)的類似改變。

影響程度是關(guān)于程序出現(xiàn)錯誤時造成的損失程度（不管出現(xiàn)的可能性）。那些高影響程度的地方應(yīng)該被重現(xiàn)測試。例如，程序經(jīng)常被使用到的核心功能、影響安全的地方。

區(qū)域影響測試

區(qū)域影響測試是指專注于發(fā)生改變的代碼區(qū)域的測試。例如：

-一個開發(fā)人員應(yīng)該完全覆蓋測試增加的或改變的代碼模塊。

-相應(yīng)地，他應(yīng)該測試所有受改變影響的路徑。

-并且，開發(fā)人員應(yīng)該對那些與所修改的代碼關(guān)聯(lián)的地方做一些相對沒有那么嚴(yán)格的測試。例如，如果代碼改變的是參數(shù)的集合，那么應(yīng)該測試那些參數(shù)被用到的地方。

單元測試的客觀證據(jù)

計劃所有這些測試都是好的，但是也需要一些客觀的方式來驗(yàn)證測試被真正執(zhí)行了。應(yīng)該收集和保存什么證據(jù)來表明開發(fā)人員已經(jīng)執(zhí)行了那些測試？并且測試得到期待的結(jié)果？我們?nèi)绾沃浪形覀儧Q定要做的