[移山之道 第11章]

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)建單元測試項(xiàng)目

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

圖11-3? 新的單元測試文件

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

DemoUser.vsmdi：測試管理文件。

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

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

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

代碼清單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類的實(shí)體）；

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

現(xiàn)在可以運(yùn)行單元測試了，同時可以看看代碼覆蓋報(bào)告“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("???? ");

??????? }

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

小飛對代碼做了相應(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();

}

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

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

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

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

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

蕓蕓：如果不能表示為一個單元測試呢？

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

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

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

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

?

?

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

下面我們講講怎樣才算一個好的單元測試。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

???? a) 代碼中并沒有處理錯誤情況。 例如代碼打開了文件，但是并沒有處理一些異常情況，例如文件不存在，權(quán)限有問題，等等

???? b) 代碼中有效能問題，雖然代碼執(zhí)行了，并且也正確地返回了。但是代碼執(zhí)行得也許非常慢。

???? c) 多線程環(huán)境中的同步問題, 這個問題和本地代碼執(zhí)行與否關(guān)系不大。

???? d) 其它和外部條件相關(guān)的問題 (例如和設(shè)備相關(guān)，和網(wǎng)絡(luò)相關(guān)的問題)

????

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

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

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

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

很多開發(fā)人員有這樣那樣的借口不去提高單元測試的覆蓋率, 其中一個就是: 這一部分代碼永遠(yuǎn)測不到! 請看 MSDN 的視頻講解:

http://channel9.msdn.com/Events/Build/2012/3-015

?

1.3 回歸測試

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

?

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

?

在軟件項(xiàng)目中，如果一個模塊或功能以前是正常工作的，但是在一個新的構(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，這個測試用例卻失敗了，這就是一個“倒退”。在新版本上運(yùn)行所有已通過的測試用例以驗(yàn)證有沒有“退化”情況發(fā)生，這個過程就是一個“Regression Test”。如果這樣的“倒退”是由于模塊的功能發(fā)生了正常變化（由于設(shè)計(jì)變更的原因）引起的，那么測試用例的基準(zhǔn)就要修改，以便和新的功能保持一致。

?

針對一個Bug Fix, 我們也要作Regression Test。

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

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

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

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

?

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

總結(jié)

以上是生活随笔為你收集整理的现代软件工程讲义 2 开发技术 - 单元测试 amp; 回归测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。