利用單元測試框架進(jìn)行自動(dòng)化測試

最近參與的一個(gè)項目里我把單元測試放到很重要的位置并且也發(fā)現了一些問(wèn)題。順便介紹一下單元測試框架進(jìn)行自動(dòng)化測試的方面

這不是一篇嚴謹的技術(shù)文章。只是一些個(gè)人不成熟的感想。

在實(shí)際開(kāi)發(fā)過(guò)程中，我發(fā)現在單元測試代碼中經(jīng)常會(huì )出現兩種情況：第一種就是在測試代碼中炫耀編程技巧，第二種就是敷衍了事，你不是讓我通過(guò)測試么？好，我就寫(xiě)一個(gè)用例，一定能通過(guò)的那種，然后告訴你，OK，我的測試通過(guò)了。我覺(jué)得，這就是對單元測試的意義沒(méi)有真正理解的表現。

到底單元測試是做什么用的？我想，在說(shuō)明這個(gè)問(wèn)題之前，我先說(shuō)說(shuō)我所理解的測試到底是做什么用的。

所謂的測試，是一種產(chǎn)品質(zhì)量保證的手段。我按照需求規格說(shuō)明書(shū)制造了一件產(chǎn)品，那么誰(shuí)來(lái)確保這個(gè)產(chǎn)品符合了需求規格的要求呢？就是測試。它會(huì )根據需求規格說(shuō)明書(shū)設計一系列的場(chǎng)景和用例，來(lái)對產(chǎn)品進(jìn)行測試，看看產(chǎn)品是不是真的符合所期望的需求。

要達到這個(gè)目標，其實(shí)并不十分的容易，因為一個(gè)真正的系統，情況十分復雜，里面充滿(mǎn)了數不清的分支、異常、邊界條件，甚至運行環(huán)境，將這些東西組合起來(lái)，產(chǎn)生的需要測試的點(diǎn)將會(huì )是一個(gè)天文數字，在有限的時(shí)間內做完一個(gè)充分而可靠的測試，是不可能的。

為了將充分測試變得可能，一個(gè)比較好的途徑就是分層測試。我在做運行測試或性能測試的時(shí)候，有一個(gè)前提，就是假設整個(gè)系統的集成運行已經(jīng)沒(méi)有問(wèn)題了，在運行測試或性能測試時(shí)，我將不再考慮“系統無(wú)法正常運行”這種場(chǎng)景。那么如何保證集成運行沒(méi)問(wèn)題呢？我們用集成測試來(lái)檢驗。但是在做集成測試的時(shí)候，我們同樣要基于一個(gè)假定，就是各個(gè)模塊的功能都能夠如期正常工作。而這一點(diǎn)，又是通過(guò)模塊自身的功能測試來(lái)完成的�！�…這樣一層層往下推，每個(gè)層次就假設它所依賴(lài)的層次沒(méi)有問(wèn)題，這樣就可以減少很多場(chǎng)景以及由這些場(chǎng)景引出的額外的分支。將原先一個(gè)幾何級數的測試用例分解成可以接受的若干層次的算術(shù)級數的用例。這樣一來(lái)測試就變得有可能做好了。

而單元測試，正是這些測試的最低層次——保證每個(gè)函數/方法，或者說(shuō)最小功能模塊的正確性的一種測試。

通過(guò)上面的描述，我們至少清楚了這樣幾件事情：
1. 單元測試是一種測試，它不是代碼的一部分；
2. 單元測試是最低層級的測試，它只保證函數的可靠性，不保證其它；
3. 單元測試應該能保證每一個(gè)函數的可靠性。

單元測試是一種測試，所以，我們應該以一種測試的眼光去面對它——我們要測試正常情況，邊界條件，要對它的測試目標——函數做黑盒分析，白盒分析，選擇合適的測試數據，構建測試場(chǎng)景和測試環(huán)境——總之，一切測試應該做的事情，單元測試都不應該省略。

理論上來(lái)說(shuō)，單元測試和其他測試一樣，也是可以純手工完成的：我們可以寫(xiě)一段某函數的測試代碼，然后輸入我們的測試輸入，觀(guān)察測試輸出，并跟期望值做比較——事實(shí)上這種人工測試，寫(xiě)了一段時(shí)間代碼的人應該都不會(huì )陌生。但是，單元測試有一點(diǎn)特殊性，就是在一個(gè)系統中，函數會(huì )非常非常的多，變化也比軟件的功能頻繁的多。面對這么多的函數，這么頻繁的變化，純手工測試是不現實(shí)的。所以，我們必須要引入單元測試框架進(jìn)行自動(dòng)化測試。注意，這里的單元測試框架只是實(shí)現自動(dòng)化測試的一個(gè)手段，對單元測試本身并不產(chǎn)生任何影響——沒(méi)有單元測試框架，單元測試一樣也是可以進(jìn)行的，只是會(huì )痛苦很多。

單元測試框架引入的目的只是為了自動(dòng)化單元測試，簡(jiǎn)化單元測試的步驟。所以，對于測試代碼的編寫(xiě)，我們的重點(diǎn)應該是：1、如何搭建測試環(huán)境、測試場(chǎng)景；2、如何選擇測試用例；3、如何校驗測試結果。對于測試代碼本身，應該盡可能的簡(jiǎn)單，能不要使用技巧盡量不要使用，我們的目的在于測試，如果測試本身過(guò)于復雜，我們不能保證測試的正確性，測試這個(gè)工作就白做了。

另外，剛剛提到單元測試是對函數的測試，因此，測試必須是以函數為單位的。每個(gè)函數應該擁有自己?jiǎn)为毜囊粋�(gè)測試，但是在這個(gè)測試中，我們應該針對這個(gè)函數的各個(gè)方面：正常的、異常的、邊界的……等等，各個(gè)方面進(jìn)行完善的測試，這樣我們才能保證這個(gè)函數的功能是如我們所愿的。但是單元測試不需要負責函數的組合工作情況。那應該是(低層次)功能測試的工作，而不是單元測試的工作。這個(gè)功能測試就是在假定所有函數都工作正常的基礎之上，對這些函數組合形成的功能模塊進(jìn)行測試。這種測試，視情況而定，可以使用單元測試框架，也可以使用其他自動(dòng)化測試方法或者甚至是使用純人工測試。

另外，我還想討論一下單元測試的編寫(xiě)和運行。

絕大部分時(shí)候，單元測試的編寫(xiě)，是由開(kāi)發(fā)人員做的。我們在以前某次對單元測試的討論中，甚至有人認為，單元測試必須由開(kāi)發(fā)人員完成，而不應該由獨立的測試人員完成。對于這個(gè)問(wèn)題，我是這樣看的：測試是一種針對需求的驗證工作。如果這個(gè)需求非常清晰，清晰到開(kāi)發(fā)人員之外的人都可以輕易掌握（有些日本外包發(fā)出來(lái)的函數說(shuō)明書(shū)就能達到這一點(diǎn)），這時(shí)單元測試可以由獨立的測試人員完成。但是大部分情況下對于函數級別，做不到這一點(diǎn)。這時(shí)最清楚函數需求的人就是開(kāi)發(fā)人員本人，在這種情況下當然就應該是開(kāi)發(fā)人員自己編寫(xiě)測試用例。但是開(kāi)發(fā)人員必須搞清楚自己身兼兩個(gè)不同的角色：運動(dòng)員（實(shí)現代碼）和裁判員（檢驗代碼），在編寫(xiě)測試用例的時(shí)候絕不能假定任何函數的實(shí)現，而應該完全按照它應該有的需求來(lái)做。這樣才能做好單元測試這件事。很多時(shí)候單元測試形同虛設，就是因為開(kāi)發(fā)人員沒(méi)有很好的轉換自己的角色造成的。

單元測試的運行，目前我們這個(gè)Python的項目比較容易，直接運行模塊就是該模塊的單元測試，而以模塊形式import就是實(shí)際使用。對于像C++或者其他的一些語(yǔ)言來(lái)說(shuō)，可能沒(méi)有這樣方便的形式。我們可以把測試寫(xiě)在獨立的文件中，然后用makefile組合不同的項目和主函數來(lái)做到這一點(diǎn)。另外還有一點(diǎn)就是，實(shí)際運行過(guò)程中可能會(huì )有一些環(huán)境，這些環(huán)境在測試時(shí)難以獲得，或者增加上去之后，就難以測試（比如網(wǎng)絡(luò )環(huán)境、數據庫環(huán)境等等），這時(shí)我們可以采用一些虛擬的環(huán)境來(lái)做到。我們把運行時(shí)需要的環(huán)境做一個(gè)簡(jiǎn)化的虛擬版本，然后以這個(gè)版本作為測試環(huán)境進(jìn)行測試，對于Python來(lái)說(shuō)，我們可以實(shí)現這樣的一個(gè)庫在測試時(shí)import進(jìn)來(lái)并且同時(shí)做一些環(huán)境初始化工作，在C++里，我們可以專(zhuān)門(mén)為測試寫(xiě)一些運行庫，在實(shí)際運行編譯和測試編譯時(shí)，鏈接不同的庫。這在自動(dòng)化測試技術(shù)中有個(gè)專(zhuān)門(mén)的名稱(chēng)叫做 Mock Object。關(guān)于這個(gè)，我就不再深入了。