現(xiàn)代軟件工程講義之單元測(cè)試和回歸測(cè)試

作者：SoftwareTeacher Powe 2011-12-01 09:20:41

本文將給大家談?wù)勯_發(fā)過程中的單元測(cè)試和回歸測(cè)試，這屬于現(xiàn)代軟件工程中的一部分。

　　1單元測(cè)試

　　你的RP是由你的程序質(zhì)量決定的。

　　——阿超

　　這一章講的是兩人合作，既然程序是兩個(gè)人寫的，那就會(huì)出現(xiàn)一個(gè)人寫的模塊被另一個(gè)人寫的模塊調(diào)用的情況。很多誤解、疏忽都發(fā)生在兩個(gè)模塊之間。如何能讓自己寫的模塊盡量無懈可擊？單元測(cè)試就是一個(gè)很有效的解決方案。

　　1.1 用VSTS寫單元測(cè)試

　　例子：我們寫一個(gè)比較常用的類型，看看它的單元測(cè)試應(yīng)該怎么寫？比如在各種網(wǎng)站應(yīng)用程序中都會(huì)用到的“用戶”這一類型。誰自告奮勇上來表演一下寫代碼？小飛，好，請(qǐng)上臺(tái)。

　　小飛創(chuàng)建了一個(gè)C#的類庫（Class Library），并寫了如代碼清單11-1的代碼：

　　代碼清單11-1

　　namespace DemoUser  
　　{  
　　public class User  
　　{  
　　public User(string userEmail)  
　　{  
　　m_email = userEmail;  
　　}  
　　private string m_email; //user email as user id  
　　}  
　　}

　　好，現(xiàn)在右鍵選中User，就可以看到“Create Unit Tests”的菜單，這樣就可以創(chuàng)建新的單元測(cè)試（如圖11-2所示）。

　　圖11-2 創(chuàng)建單元測(cè)試項(xiàng)目

　　創(chuàng)建單元測(cè)試后，注意到在Solution Explorer中出現(xiàn)了三個(gè)新的文件（如圖11-3所示）。

　　圖11-3 新的單元測(cè)試文件

　　Class1.cs是程序的文件，而Class1Test.cs是與之對(duì)應(yīng)的單元測(cè)試文件。

　　DemoUser.vsmdi：測(cè)試管理文件。

　　Localtestrun.testrunconfig：本地測(cè)試運(yùn)行設(shè)置文件。

　　如何管理設(shè)置文件呢？右鍵再選屬性（Property）并不對(duì)。你得雙擊文件才能進(jìn)入管理及設(shè)置界面。在設(shè)置界面中，你可以讓單元測(cè)試產(chǎn)生“demouser.dll”的代碼覆蓋報(bào)告。

　　注意在單元測(cè)試中，VSTS自動(dòng)為你生成了測(cè)試的骨架，但是你還是要自己做不少事情，最起碼要把那些//TODO的事情給做了（如代碼清單11-2所示）。在這個(gè)時(shí)候，單元測(cè)試還都是用的Assert. Inconclusive，表明這是一個(gè)未經(jīng)驗(yàn)證的單元測(cè)試。

　　代碼清單11-2

　　/// <summary> 
　　///A test for User (string)  
　　///</summary> 
　　[TestMethod()]  
　　public void ConstructorTest()  
　　{  
　　string userEmail = null; // TODO: Initialize to an appropriate  
　　// value  
　　User target = new User(userEmail);  
　　// TODO: Implement code to verify target  
　　Assert.Inconclusive("TODO: Implement code to verify target");  
　　}

　　進(jìn)行簡單的修改后，我們得到了一個(gè)如代碼清單11-3正式的單元測(cè)試：

　　代碼清單11-3

　　[TestMethod()]  
　　public void ConstructorTest()  
　　{  
　　string userEmail = "someone@somewhere.com";  
　　User target = new User(userEmail);  
　　Assert.IsTrue(target != null);  
　　}

　　//我們還可以進(jìn)一步測(cè)試E-mail是否的確是保存在User類型中。

　　解釋單元測(cè)試的結(jié)構(gòu)

　　從上面這個(gè)例子可以看到創(chuàng)建單元測(cè)試函數(shù)的主要步驟：

　　（1）設(shè)置數(shù)據(jù)（一個(gè)假想的正確的E-mail地址）；

　　（2）使用被測(cè)試類型的功能（用E-mail地址來創(chuàng)建一個(gè)User類的實(shí)體）；

　　（3）比較實(shí)際結(jié)果和預(yù)期的結(jié)果（Assert.IsTrue(target!= null);）。

　　現(xiàn)在可以運(yùn)行單元測(cè)試了，同時(shí)可以看看代碼覆蓋報(bào)告“code coverage report”，代碼***地都被覆蓋了。

　　當(dāng)然這時(shí)候的代碼還有很多情況沒有處理，同學(xué)們?cè)谂_(tái)下雜曰——

　　處理空的字符串，長度為零的字符串，都是空格的串……

　　小飛熟練地用Copy/Paste又寫了下面的三個(gè)測(cè)試，如代碼清單11-4所示。

　　代碼清單11-4

　　[TestMethod()]  
　　[ExpectedException(typeof (ArgumentNullException))]  
　　public void ConstructorTestNull()  
　　{  
　　User target = new User(null);  
　　}  
　[TestMethod()]  
　　[ExpectedException(typeof(ArgumentException))]  
　　public void ConstructorTestEmpty()  
　　{  
　　User target = new User("");  
　　}  
　　[TestMethod()]  
　　[ExpectedException(typeof(ArgumentNullException))]  
　　public void ConstructorTestBlank()  
　　{  
　　User target = new User(" ");  
　　}

　　如果不修改類庫中的代碼，單元測(cè)試會(huì)報(bào)告這三個(gè)新的測(cè)試都失敗了。

　　小飛對(duì)代碼做了相應(yīng)的修改。結(jié)果出了這樣的錯(cuò)誤，見代碼清單11-5：

　　代碼清單11-5

　　Test method UserTest.UserTest.ConstructorTestBlank threw exception System.ArgumentException, but exception System. ArgumentNull- Exception was expected. Exception message: System.Argument- Exception: Value does not fall within the expected range.

　　大家定睛一看，原來小飛的Copy/Paste用了原來的ArgumentNullExcep- tion，而不是ArgumentException。

　　如果有人加了下面的代碼：

　if (!m_email.Contains("@"))  
　　{  
　　throw new ArgumentException();  
　　}

　　這時(shí)，代碼覆蓋測(cè)試就會(huì)報(bào)告代碼覆蓋率是85%左右。那還得加上新的單元測(cè)試以保證所有的代碼都得到了基本的測(cè)試。

　　二柱：現(xiàn)在我知道為什么有些軟件寫了好幾年都沒有發(fā)布了，敢情他們都忙著寫單元測(cè)試了。

　　阿超：也許因?yàn)樗麄儧]有在一開始就寫單元測(cè)試，所以后來有很多小強(qiáng)要處理。很多調(diào)查顯示，在軟件開發(fā)后期發(fā)現(xiàn)的Bug，修復(fù)起來要花更多的時(shí)間。

　　蕓蕓：這對(duì)我們?cè)O(shè)計(jì)人員有什么用呢？好像都是一些細(xì)節(jié)的東西。

　　阿超：在我們寫規(guī)格說明書（specification）的時(shí)候，要越詳細(xì)越好，***你的各項(xiàng)要求都可以表達(dá)成單元測(cè)試的一個(gè)測(cè)試用例。

　　蕓蕓：如果不能表示為一個(gè)單元測(cè)試呢？

　　二柱：那就是你寫得還不夠細(xì)。

　　小飛：我大膽地說一句。如果是一個(gè)人寫寫程序玩玩，單元測(cè)試似乎不那么重要。

　　二柱：你可以大膽地對(duì)你的女朋友說：“我們只是玩一玩……”看看效果如何。

　　阿超：如果玩一玩，什么都不太重要。如果你寫的模塊會(huì)有不同的人，在不同的時(shí)間使用，那你***把你這一“單元”要做的事，以及它不能做的事，用單元測(cè)試清晰地表達(dá)出來。

　　1.2 好的單元測(cè)試的標(biāo)準(zhǔn)

　　下面我們講講怎樣才算一個(gè)好的單元測(cè)試。

　　單元測(cè)試應(yīng)該準(zhǔn)確、快速地保證程序基本模塊的正確性。下面是驗(yàn)證單元測(cè)試好壞的一系列標(biāo)準(zhǔn)：

　　單元測(cè)試應(yīng)該在***的功能/參數(shù)上驗(yàn)證程序的正確性。

　　單元測(cè)試應(yīng)該測(cè)試程序中最基本的單元——如在C++/C#/Java中的類，在此基礎(chǔ)上，可以測(cè)試一些系統(tǒng)中最基本的功能點(diǎn)（這些功能點(diǎn)由幾個(gè)基本類組成），從面向?qū)ο蟮脑O(shè)計(jì)原理出發(fā)，系統(tǒng)中最基本的功能點(diǎn)也應(yīng)該由一個(gè)類及其方法來表現(xiàn)。單元測(cè)試要測(cè)試API中的每一個(gè)方法及每一個(gè)參數(shù)。

　　單元測(cè)試必須由最熟悉代碼的人（程序的作者）來寫。

　　代碼的作者最了解代碼的目的、特點(diǎn)和實(shí)現(xiàn)的局限性。所以，寫單元測(cè)試沒有比作者更適合的人選了。

　　問：如果我很忙，能不能讓別人代勞做單元測(cè)試？

　　答：如果忙到連單元測(cè)試都沒有時(shí)間做，那么你也沒有時(shí)間寫好這個(gè)功能。在一些極限編程的方法中，是可以考慮讓別人來做單元測(cè)試的，但是，程序的作者還是要對(duì)單元測(cè)試負(fù)責(zé)。

　　***是在設(shè)計(jì)的時(shí)候就寫好單元測(cè)試，這樣單元測(cè)試就能體現(xiàn)API的語義，如果沒有單元測(cè)試，語義的準(zhǔn)確性就不能得到保障，以后會(huì)產(chǎn)生歧義。

　　單元測(cè)試過后，機(jī)器狀態(tài)保持不變。

　　這樣就可以不斷地運(yùn)行單元測(cè)試，如果單元測(cè)試創(chuàng)建了臨時(shí)的文件或目錄，應(yīng)該在Teardown階段把這些臨時(shí)的文件或目錄刪除。

　　如果單元測(cè)試在數(shù)據(jù)庫中創(chuàng)建或修改了記錄，那么也許要?jiǎng)h除這些記錄，或者每一個(gè)單元測(cè)試使用一個(gè)新的數(shù)據(jù)庫，這樣可以保證單元測(cè)試不受以前單元測(cè)試實(shí)例的干擾。

　　單元測(cè)試要快（一個(gè)測(cè)試運(yùn)行時(shí)間是幾秒鐘，而不是幾分鐘）。

　　快，才能保證效率。因?yàn)橐粋€(gè)軟件中有幾十個(gè)基本模塊（類），每個(gè)模塊又有幾個(gè)方法，基本上我們要求一個(gè)類的測(cè)試要在幾秒鐘內(nèi)完成。如果軟件有相互獨(dú)立的幾個(gè)層次，那么在測(cè)試組中可以分類，如數(shù)據(jù)庫層次、網(wǎng)絡(luò)通信層次、客戶邏輯層次和用戶界面層次，可以分類運(yùn)行測(cè)試，比如只修改了“用戶界面”的代碼，則只需運(yùn)行“用戶界面”的單元測(cè)試。

　　單元測(cè)試應(yīng)該產(chǎn)生可重復(fù)、一致的結(jié)果。

　　如果單元測(cè)試的結(jié)果是錯(cuò)的，那一定是程序出了問題，而且這個(gè)錯(cuò)誤一定是可以重復(fù)的。

　　問：如果用隨機(jī)數(shù)以增加測(cè)試的真實(shí)性，好么？

　　答：一般情況下不好，如果某個(gè)隨機(jī)數(shù)導(dǎo)致程序出錯(cuò)，但是下一次運(yùn)行又不能重復(fù)這一錯(cuò)誤，于事無補(bǔ)。要注意我們還是要用隨機(jī)數(shù)等辦法“增加測(cè)試的真實(shí)性”，但是不是在單元測(cè)試中。單元測(cè)試不能解決所有問題，所以也不必期望它會(huì)發(fā)現(xiàn)所有的缺陷。

　　獨(dú)立性，單元測(cè)試的運(yùn)行/通過/失敗不依賴于別的測(cè)試，可以人為構(gòu)造數(shù)據(jù)，以保持單元測(cè)試的獨(dú)立性。

　　程序中的各個(gè)模塊都是互相依賴的，否則它們就不會(huì)出現(xiàn)在一個(gè)程序中。一般情況下，單元測(cè)試中的模塊可以直接引用其他的模塊，并期待其他的模塊能返回正確的結(jié)果。

　　如果其他的模塊很不穩(wěn)定，或者其他模塊運(yùn)行比較費(fèi)時(shí)（如進(jìn)行網(wǎng)絡(luò)操作），而且對(duì)于本模塊的正確性并不起關(guān)鍵的作用，這時(shí)可以人為地構(gòu)造數(shù)據(jù)以保證這個(gè)單元測(cè)試的獨(dú)立性。

　　單元測(cè)試應(yīng)該覆蓋所有代碼路徑，包括錯(cuò)誤處理路徑，為了保證單元測(cè)試的代碼覆蓋率，單元測(cè)試必須測(cè)試公開的和私有的函數(shù)/方法。

　　單元測(cè)試必須覆蓋所測(cè)單元的所有代碼路徑。

　　問：啊！這樣豈不是要寫很多啰里啰唆的測(cè)試方法？

　　答：對(duì)，因?yàn)槌绦蛑泻芏嗳毕荻际菑倪@些啰里啰唆的錯(cuò)誤處理中產(chǎn)生的。如果你的模塊中某個(gè)錯(cuò)誤處理路徑很難到達(dá)，那你也許要想想是否可以把這個(gè)錯(cuò)誤處理拿掉。

　　大栓：這對(duì)于那些愛寫復(fù)雜代碼的人是一個(gè)很好的懲罰，不對(duì)，是一個(gè)很好的鍛煉。

　　阿超：對(duì)，把單元測(cè)試的責(zé)任和代碼作者綁定在一起后，代碼作者就能更真切地體會(huì)到復(fù)雜代碼的副作用，因?yàn)轵?yàn)證復(fù)雜代碼的正確性要困難得多。要注意的一點(diǎn)是：100%的代碼覆蓋率并不等同于100%的正確性。

　　單元測(cè)試應(yīng)該集成到自動(dòng)測(cè)試的框架中。

　　另一個(gè)重要的措施是要把單元測(cè)試自動(dòng)化，這樣每個(gè)人都能很容易地運(yùn)行它，并且可以使單元測(cè)試每天都運(yùn)行。每個(gè)人都可以隨時(shí)在自己的機(jī)器上運(yùn)行。團(tuán)隊(duì)一般是在每日構(gòu)建中運(yùn)行單元測(cè)試的，這樣每個(gè)單元測(cè)試的錯(cuò)誤就能及時(shí)被發(fā)現(xiàn)并得到修改。

　　單元測(cè)試必須和產(chǎn)品代碼一起保存和維護(hù)。

　　單元測(cè)試必須和代碼一起進(jìn)行版本維護(hù)。如果不是這樣，過了一陣，代碼和單元測(cè)試就會(huì)出現(xiàn)不一致，而且所有代碼的作者要花時(shí)間來確認(rèn)哪些是程序出現(xiàn)的錯(cuò)誤，哪些是由于單元測(cè)試更新滯后造成的錯(cuò)誤。這樣就失去了單元測(cè)試的意義，同時(shí)又給大家增加了負(fù)擔(dān)。如此折騰多次以后，大家就會(huì)覺得維護(hù)單元測(cè)試是一件很費(fèi)時(shí)費(fèi)力的事。

　　1.3回歸測(cè)試

　　在單元測(cè)試的基礎(chǔ)上, 我們就能夠建立關(guān)于這一模塊的回歸測(cè)試 (Regression Test).

　　Regress 的英語定義是： return to a worse or less developed state。是倒退、退化、退步的意思。

　　在軟件項(xiàng)目中，如果一個(gè)模塊或功能以前是正常工作的，但是在一個(gè)新的構(gòu)建中出了問題，那這個(gè)模塊就出現(xiàn)了一個(gè)“退步”（Regression），從正常工作的穩(wěn)定狀態(tài)退化到不正常工作的不穩(wěn)定狀態(tài)。

　　在一個(gè)模塊的功能逐步完成的同時(shí)，與此功能有關(guān)的測(cè)試用例也同樣在完善中。一旦有關(guān)的測(cè)試用例通過，我們就得到了此模塊的功能基準(zhǔn) (Baseline) , 一個(gè)模塊的所有單元測(cè)試就是這個(gè)模塊最初的Baseline。

　　假如，在3.1.5版本，模塊A的測(cè)試用例125是通過的，但是測(cè)試人員發(fā)現(xiàn)在新的版本3.1.6，這個(gè)測(cè)試用例卻失敗了，這就是一個(gè)“倒退”。在新版本上運(yùn)行所有已通過的測(cè)試用例以驗(yàn)證有沒有“退化”情況發(fā)生，這個(gè)過程就是一個(gè)“Regression Test”。如果這樣的“倒退”是由于模塊的功能發(fā)生了正常變化（由于設(shè)計(jì)變更的原因）引起的，那么測(cè)試用例的基準(zhǔn)就要修改，以便和新的功能保持一致。

　　針對(duì)一個(gè)Bug Fix, 我們也要作Regression Test。

　　（1）驗(yàn)證新的代碼的確把缺陷改正了。

　　（2）同時(shí)要驗(yàn)證新的代碼沒有把模塊的現(xiàn)有功能破壞，沒有Regression。

　　所以對(duì)于“回歸測(cè)試”中的“回歸”，我們可以理解為“回歸到以前不正常的狀態(tài)”。

　　回歸測(cè)試***要自動(dòng)化，因?yàn)檫@樣就可以對(duì)于每一個(gè)構(gòu)建快速運(yùn)行所有回歸測(cè)試，以保證盡早發(fā)現(xiàn)問題。單元測(cè)試是回歸測(cè)試的基礎(chǔ).

　　在專注于模塊基本功能的單元測(cè)試之外, 還有功能測(cè)試 – 從用戶的角度檢查功能完成得怎么樣。在微軟的實(shí)踐中，在一個(gè)項(xiàng)目的***穩(wěn)定階段，所有人都要參加全面的測(cè)試工作，把所有以前發(fā)現(xiàn)并修復(fù)的bug 找出來, 一個(gè)一個(gè)驗(yàn)證, 以保證所有已經(jīng)修復(fù)過的Bug的確得到了修復(fù)，并且沒有在***一個(gè)版本中“復(fù)發(fā)”, 這是一個(gè)大規(guī)模的、全面的“回歸測(cè)試”。

原文鏈接：http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html

【編輯推薦】