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