單元測試標準

建立單元測試原則是時候出新版本了。那么應(yīng)當把什么包括進來？顯然，它應(yīng)當包括每個模塊的最新的最佳的版本。對吧？“最新的和最佳的”基于一種假設(shè)：最新的版本就是最佳的版本。最新的版本添加了特性，糾正了問題，簡而言之，改善了之前的版本。怎么會不是最佳的呢？不過，實際上，事情并不是你想象的那么簡樸。那些新的特性也許與其他既有的功能不兼容。顧客依賴的東西也許消失了。新的特性也許減弱了可用性（尤其是對新顧客來說）。尚有，那些bug總是在這些新的變化的代碼中出現(xiàn)。因此，我們怎樣才能鑒定最新的就是最佳的？我們怎樣懂得代碼真的準備好了被包括到下一種build中？諸多開發(fā)組通過建立升級原則來處理這個問題。升級原則是有關(guān)某個模塊與否準備好包括在一種build版本中的鑒定方略。單元測試原則雖然可以把諸多別的東西包括到你的升級原則中來，不過單元測試是所有這些原則的基礎(chǔ)。幾乎每個組織都假設(shè)軟件開發(fā)人員在做合適的單元測試。不過不幸的是，不一樣的人對“合適”的測試傾向于采用非常不一樣樣的理解。好的實踐規(guī)定開發(fā)人員文檔化它們的測試，并且對那些測試進行同行評審以保證有合適的覆蓋率。假如使用自動化測試，那么開發(fā)人員能簡樸地為開發(fā)工具創(chuàng)立測試腳本，并且提交那些腳本用于評審。當然，對于什么應(yīng)當包括在單元測試中必須建立一種小組的原則。作為一種開發(fā)組，有關(guān)應(yīng)當做什么測試要到達一致的共識需要花費某些時間和做出某些權(quán)衡，不過花在這里的時間會從對的的構(gòu)建過程中得到加倍的回報！讓我們看看某些單元測試期望的例子。功能當然，每個模塊必須被測試以保證它滿足設(shè)計的規(guī)定，并且保證它做了真正應(yīng)當做的對的的事情。它應(yīng)當處理什么樣的輸入？必須完畢什么工作？會提供什么服務(wù)？它應(yīng)當產(chǎn)生怎樣的輸出？它必須管理什么數(shù)據(jù),應(yīng)當怎樣使用那些數(shù)據(jù)？我們必須保證這個模塊真正做了它需要做的事情。負面測試然后是錯誤處理。當出現(xiàn)錯誤時這個模塊會做“對的”的事情嗎？當它處理某些特殊的輸入時會出現(xiàn)什么狀況？缺乏數(shù)據(jù)構(gòu)成或數(shù)據(jù)輸入的次序被打亂的時候會怎樣？當需要輸入數(shù)值數(shù)據(jù)時給它非數(shù)值數(shù)據(jù)會怎樣？數(shù)據(jù)溢出？假如它接受到一種從數(shù)據(jù)庫或網(wǎng)路接口返回的錯誤狀態(tài)時會怎樣？它會怎樣處理？一種模塊在被認為完畢之前，必須對的地處理所有錯誤條件。覆蓋我們都懂得完全的測試不是軟件測試的一種合理目的。太多的輸入組合，事件的發(fā)生有太多的也許次序，太多不一樣的出錯方式，因此完整地測試所有東西，雖然是一種很小的程序，也是不也許的。不過代碼和途徑覆蓋是單元測試可到達的一種目的。實際上，單元測試階段是把完整覆蓋代碼和途徑作為一種合理的目的的唯一時間。-代碼覆蓋在單元測試過程中，規(guī)定代碼的每一行都被執(zhí)行到，這一點都不過度（并且有諸多分析工具可以協(xié)助我們保證這點）。某些代碼（尤其是錯誤處理）是不能被測試到的，除非采用額外的環(huán)節(jié)（例如編寫一種傳遞壞數(shù)據(jù)的函數(shù)，或者把錯誤代碼注入到內(nèi)存中），不過這些不僅僅是適合做的，并且對于保證程序可以處理多種應(yīng)當處理的狀況來說非常關(guān)鍵的！-途徑覆蓋除了代碼行覆蓋，測試代碼的每一種途徑也是非常合理的。例如，我們可以保證每一種“if”的分支都通過了，并且保證每一種“case”的所有分支都得到了執(zhí)行。我們還可以保證每一種循環(huán)途徑的初始化和終止條件都是對的的。回歸測試這些都是“新鮮出爐”的代碼應(yīng)當測試的內(nèi)容，不過假如變化了一點點的代碼模塊應(yīng)當做多少測試呢？在單元級別，應(yīng)當做多少回歸測試呢？這是很輕易誤解的地方：由于只是很小的變化，因此不值得花費諸多的時間去測試它。確實，對于每次一小行的代碼的變化我們不能進行完整的測試。不過，同步，這些“很小”的改動一般帶來潛在的、重大的、非預期的影響。最佳的措施是恰當?shù)卦u估回歸測試：結(jié)合基于風險的測試和區(qū)域影響測試?；陲L險的測試基于風險的測試指基于缺陷的風險來選擇測試。對于風險有兩個方面：也許性和影響程度。也許性是判斷更改會導致某些問題的機會。我們應(yīng)當測試那些也許出現(xiàn)問題的地方。評估代碼變化的地方是其中一種判斷的方式，此外一種是尋找曾經(jīng)出現(xiàn)的類似變化。影響程度是有關(guān)程序出現(xiàn)錯誤時導致的損失程度（不管出現(xiàn)的也許性）。那些高影響程度的地方應(yīng)當被重現(xiàn)測試。例如，程序常常被使用到的關(guān)鍵功能、影響安全的地方。區(qū)域影響測試區(qū)域影響測試是指專注于發(fā)生變化的代碼區(qū)域的測試。例如：-開發(fā)人員應(yīng)當完全覆蓋測試增長的或變化的代碼模塊。-對應(yīng)地，他應(yīng)當測試所有受變化影響的途徑。-并且，開發(fā)人員應(yīng)當對那些與所修改的代碼關(guān)聯(lián)的地方做某些相對沒有那么嚴格的測試。例如:假如代碼變化的是參數(shù)的集合，那么應(yīng)當測試那些參數(shù)被用到的地方。單元測試的客觀證據(jù)計劃所有這些測試都是好的，不過也需要某些客觀的方式來驗證測試被真正執(zhí)行了。應(yīng)當搜集和保留什么證據(jù)來表明開發(fā)人員已經(jīng)執(zhí)行了那些測試？并且測試得到期待的成果？我們怎樣懂得所有我們決定要做的這些