現(xiàn)代軟件工程講義之單元測試和回歸測試
1單元測試
你的RP是由你的程序質(zhì)量決定的。
——阿超
這一章講的是兩人合作，既然程序是兩個人寫的，那就會出現(xiàn)一個人寫的模塊被另一個人寫的模塊調(diào)用的情況。很多誤解、疏忽都發(fā)生在兩個模塊之間。如何能讓自己寫的模塊盡量無懈可擊？單元測試就是一個很有效的解決方案。
1.1 用VSTS寫單元測試
例子：我們寫一個比較常用的類型，看看它的單元測試應(yīng)該怎么寫？比如在各種網(wǎng)站應(yīng)用程序中都會用到的“用戶”這一類型。誰自告奮勇上來表演一下寫代碼？小飛，好，請上臺。
小飛創(chuàng)建了一個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)建新的單元測試（如圖11-2所示）。
圖11-2 創(chuàng)建單元測試項目
創(chuàng)建單元測試后，注意到在Solution Explorer中出現(xiàn)了三個新的文件（如圖11-3所示）。
圖11-3 新的單元測試文件
Class1.cs是程序的文件，而Class1Test.cs是與之對應(yīng)的單元測試文件。
DemoUser.vsmdi：測試管理文件。
Localtestrun.testrunconfig：本地測試運行設(shè)置文件。
如何管理設(shè)置文件呢？右鍵再選屬性（Property）并不對。你得雙擊文件才能進(jìn)入管理及設(shè)置界面。在設(shè)置界面中，你可以讓單元測試產(chǎn)生“demouser.dll”的代碼覆蓋報告。
注意在單元測試中，VSTS自動為你生成了測試的骨架，但是你還是要自己做不少事情，最起碼要把那些//TODO的事情給做了（如代碼清單11-2所示）。在這個時候，單元測試還都是用的Assert. Inconclusive，表明這是一個未經(jīng)驗證的單元測試。
代碼清單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)行簡單的修改后，我們得到了一個如代碼清單11-3正式的單元測試：
代碼清單11-3
- [TestMethod()]
- public void ConstructorTest()
- {
- string userEmail = "someone@somewhere.com";
- User target = new User(userEmail);
- Assert.IsTrue(target != null);
- }
//我們還可以進(jìn)一步測試E-mail是否的確是保存在User類型中。
解釋單元測試的結(jié)構(gòu)
從上面這個例子可以看到創(chuàng)建單元測試函數(shù)的主要步驟：
（1）設(shè)置數(shù)據(jù)（一個假想的正確的E-mail地址）；
（2）使用被測試類型的功能（用E-mail地址來創(chuàng)建一個User類的實體）；
（3）比較實際結(jié)果和預(yù)期的結(jié)果（Assert.IsTrue(target!= null);）。
現(xiàn)在可以運行單元測試了，同時可以看看代碼覆蓋報告“code coverage report”，代碼***地都被覆蓋了。
當(dāng)然這時候的代碼還有很多情況沒有處理，同學(xué)們在臺下雜曰——
處理空的字符串，長度為零的字符串，都是空格的串……
小飛熟練地用Copy/Paste又寫了下面的三個測試，如代碼清單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(" ");
- }
如果不修改類庫中的代碼，單元測試會報告這三個新的測試都失敗了。
小飛對代碼做了相應(yīng)的修改。結(jié)果出了這樣的錯誤，見代碼清單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();
- }
這時，代碼覆蓋測試就會報告代碼覆蓋率是85%左右。那還得加上新的單元測試以保證所有的代碼都得到了基本的測試。
二柱：現(xiàn)在我知道為什么有些軟件寫了好幾年都沒有發(fā)布了，敢情他們都忙著寫單元測試了。
阿超：也許因為他們沒有在一開始就寫單元測試，所以后來有很多小強(qiáng)要處理。很多調(diào)查顯示，在軟件開發(fā)后期發(fā)現(xiàn)的Bug，修復(fù)起來要花更多的時間。
蕓蕓：這對我們設(shè)計人員有什么用呢？好像都是一些細(xì)節(jié)的東西。
阿超：在我們寫規(guī)格說明書（specification）的時候，要越詳細(xì)越好，***你的各項要求都可以表達(dá)成單元測試的一個測試用例。
蕓蕓：如果不能表示為一個單元測試呢？
二柱：那就是你寫得還不夠細(xì)。
小飛：我大膽地說一句。如果是一個人寫寫程序玩玩，單元測試似乎不那么重要。
二柱：你可以大膽地對你的女朋友說：“我們只是玩一玩……”看看效果如何。
阿超：如果玩一玩，什么都不太重要。如果你寫的模塊會有不同的人，在不同的時間使用，那你***把你這一“單元”要做的事，以及它不能做的事，用單元測試清晰地表達(dá)出來。
1.2 好的單元測試的標(biāo)準(zhǔn)
下面我們講講怎樣才算一個好的單元測試。
單元測試應(yīng)該準(zhǔn)確、快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標(biāo)準(zhǔn)：
單元測試應(yīng)該在***的功能/參數(shù)上驗證程序的正確性。
單元測試應(yīng)該測試程序中最基本的單元——如在C++/C#/Java中的類，在此基礎(chǔ)上，可以測試一些系統(tǒng)中最基本的功能點（這些功能點由幾個基本類組成），從面向?qū)ο蟮脑O(shè)計原理出發(fā)，系統(tǒng)中最基本的功能點也應(yīng)該由一個類及其方法來表現(xiàn)。單元測試要測試API中的每一個方法及每一個參數(shù)。
單元測試必須由最熟悉代碼的人（程序的作者）來寫。
代碼的作者最了解代碼的目的、特點和實現(xiàn)的局限性。所以，寫單元測試沒有比作者更適合的人選了。
問：如果我很忙，能不能讓別人代勞做單元測試？
答：如果忙到連單元測試都沒有時間做，那么你也沒有時間寫好這個功能。在一些極限編程的方法中，是可以考慮讓別人來做單元測試的，但是，程序的作者還是要對單元測試負(fù)責(zé)。
***是在設(shè)計的時候就寫好單元測試，這樣單元測試就能體現(xiàn)API的語義，如果沒有單元測試，語義的準(zhǔn)確性就不能得到保障，以后會產(chǎn)生歧義。
單元測試過后，機(jī)器狀態(tài)保持不變。
這樣就可以不斷地運行單元測試，如果單元測試創(chuàng)建了臨時的文件或目錄，應(yīng)該在Teardown階段把這些臨時的文件或目錄刪除。
如果單元測試在數(shù)據(jù)庫中創(chuàng)建或修改了記錄，那么也許要刪除這些記錄，或者每一個單元測試使用一個新的數(shù)據(jù)庫，這樣可以保證單元測試不受以前單元測試實例的干擾。
單元測試要快（一個測試運行時間是幾秒鐘，而不是幾分鐘）。
快，才能保證效率。因為一個軟件中有幾十個基本模塊（類），每個模塊又有幾個方法，基本上我們要求一個類的測試要在幾秒鐘內(nèi)完成。如果軟件有相互獨立的幾個層次，那么在測試組中可以分類，如數(shù)據(jù)庫層次、網(wǎng)絡(luò)通信層次、客戶邏輯層次和用戶界面層次，可以分類運行測試，比如只修改了“用戶界面”的代碼，則只需運行“用戶界面”的單元測試。
單元測試應(yīng)該產(chǎn)生可重復(fù)、一致的結(jié)果。
如果單元測試的結(jié)果是錯的，那一定是程序出了問題，而且這個錯誤一定是可以重復(fù)的。
問：如果用隨機(jī)數(shù)以增加測試的真實性，好么？
答：一般情況下不好，如果某個隨機(jī)數(shù)導(dǎo)致程序出錯，但是下一次運行又不能重復(fù)這一錯誤，于事無補(bǔ)。要注意我們還是要用隨機(jī)數(shù)等辦法“增加測試的真實性”，但是不是在單元測試中。單元測試不能解決所有問題，所以也不必期望它會發(fā)現(xiàn)所有的缺陷。
獨立性，單元測試的運行/通過/失敗不依賴于別的測試，可以人為構(gòu)造數(shù)據(jù)，以保持單元測試的獨立性。
程序中的各個模塊都是互相依賴的，否則它們就不會出現(xiàn)在一個程序中。一般情況下，單元測試中的模塊可以直接引用其他的模塊，并期待其他的模塊能返回正確的結(jié)果。
如果其他的模塊很不穩(wěn)定，或者其他模塊運行比較費時（如進(jìn)行網(wǎng)絡(luò)操作），而且對于本模塊的正確性并不起關(guān)鍵的作用，這時可以人為地構(gòu)造數(shù)據(jù)以保證這個單元測試的獨立性。
單元測試應(yīng)該覆蓋所有代碼路徑，包括錯誤處理路徑，為了保證單元測試的代碼覆蓋率，單元測試必須測試公開的和私有的函數(shù)/方法。
單元測試必須覆蓋所測單元的所有代碼路徑。
問：啊！這樣豈不是要寫很多啰里啰唆的測試方法？
答：對，因為程序中很多缺陷都是從這些啰里啰唆的錯誤處理中產(chǎn)生的。如果你的模塊中某個錯誤處理路徑很難到達(dá)，那你也許要想想是否可以把這個錯誤處理拿掉。
大栓：這對于那些愛寫復(fù)雜代碼的人是一個很好的懲罰，不對，是一個很好的鍛煉。
阿超：對，把單元測試的責(zé)任和代碼作者綁定在一起后，代碼作者就能更真切地體會到復(fù)雜代碼的副作用，因為驗證復(fù)雜代碼的正確性要困難得多。要注意的一點是：100%的代碼覆蓋率并不等同于100%的正確性。
單元測試應(yīng)該集成到自動測試的框架中。
另一個重要的措施是要把單元測試自動化，這樣每個人都能很容易地運行它，并且可以使單元測試每天都運行。每個人都可以隨時在自己的機(jī)器上運行。團(tuán)隊一般是在每日構(gòu)建中運行單元測試的，這樣每個單元測試的錯誤就能及時被發(fā)現(xiàn)并得到修改。
單元測試必須和產(chǎn)品代碼一起保存和維護(hù)。
單元測試必須和代碼一起進(jìn)行版本維護(hù)。如果不是這樣，過了一陣，代碼和單元測試就會出現(xiàn)不一致，而且所有代碼的作者要花時間來確認(rèn)哪些是程序出現(xiàn)的錯誤，哪些是由于單元測試更新滯后造成的錯誤。這樣就失去了單元測試的意義，同時又給大家增加了負(fù)擔(dān)。如此折騰多次以后，大家就會覺得維護(hù)單元測試是一件很費時費力的事。
1.3回歸測試
在單元測試的基礎(chǔ)上, 我們就能夠建立關(guān)于這一模塊的回歸測試 (Regression Test).
Regress 的英語定義是： return to a worse or less developed state。是倒退、退化、退步的意思。
在軟件項目中，如果一個模塊或功能以前是正常工作的，但是在一個新的構(gòu)建中出了問題，那這個模塊就出現(xiàn)了一個“退步”（Regression），從正常工作的穩(wěn)定狀態(tài)退化到不正常工作的不穩(wěn)定狀態(tài)。
在一個模塊的功能逐步完成的同時，與此功能有關(guān)的測試用例也同樣在完善中。一旦有關(guān)的測試用例通過，我們就得到了此模塊的功能基準(zhǔn) (Baseline) , 一個模塊的所有單元測試就是這個模塊最初的Baseline。
假如，在3.1.5版本，模塊A的測試用例125是通過的，但是測試人員發(fā)現(xiàn)在新的版本3.1.6，這個測試用例卻失敗了，這就是一個“倒退”。在新版本上運行所有已通過的測試用例以驗證有沒有“退化”情況發(fā)生，這個過程就是一個“Regression Test”。如果這樣的“倒退”是由于模塊的功能發(fā)生了正常變化（由于設(shè)計變更的原因）引起的，那么測試用例的基準(zhǔn)就要修改，以便和新的功能保持一致。
針對一個Bug Fix, 我們也要作Regression Test。
（1）驗證新的代碼的確把缺陷改正了。
（2）同時要驗證新的代碼沒有把模塊的現(xiàn)有功能破壞，沒有Regression。
所以對于“回歸測試”中的“回歸”，我們可以理解為“回歸到以前不正常的狀態(tài)”。
回歸測試***要自動化，因為這樣就可以對于每一個構(gòu)建快速運行所有回歸測試，以保證盡早發(fā)現(xiàn)問題。單元測試是回歸測試的基礎(chǔ).
在專注于模塊基本功能的單元測試之外, 還有功能測試 – 從用戶的角度檢查功能完成得怎么樣。 在微軟的實踐中，在一個項目的***穩(wěn)定階段，所有人都要參加全面的測試工作，把所有以前發(fā)現(xiàn)并修復(fù)的bug 找出來, 一個一個驗證, 以保證所有已經(jīng)修復(fù)過的Bug的確得到了修復(fù)，并且沒有在***一個版本中“復(fù)發(fā)”, 這是一個大規(guī)模的、全面的“回歸測試”。
原文鏈接：http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html
【編輯推薦】
