單元測試大揭密
Author: Vince 來(lái)源:http://blog.csdn.net/vincetest
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】
-
它太浪費時(shí)間了，現在要趕進(jìn)度，時(shí)間上根本不允許，或者隨便做做應付領(lǐng)導。
-
我是一個(gè)很棒的程序員，我寫(xiě)的代碼肯定是沒(méi)有問(wèn)題的。
-
做單元測試太煩了，直接集成，到時(shí)有問(wèn)題在集成測試時(shí)肯定能發(fā)現的，實(shí)在不行在系統測試總該能發(fā)現吧。
-
它僅僅是證明這些代碼做了什么。
對于以上錯誤認識的產(chǎn)生歸根結底還是由于對單元測試的理解還是不夠，沒(méi)有真正認識到單元測試的重要性。
單元測試是軟件測試的基礎，因此單元測試的效果會(huì )直接影響到軟件的后期測試，最終在很大程度上影響到產(chǎn)品的質(zhì)量。從如下幾個(gè)方面就可以看出單元測試的重要性在何處。
-
時(shí) 間方面：如果認真的做好了單元測試，在系統集成聯(lián)調時(shí)非常順利，因此會(huì )節約很多時(shí)間，反之那些由于因為時(shí)間原因不做單元測試或隨便做做的則在集成時(shí)總會(huì )遇 到那些本應該在單元測試就能發(fā)現的問(wèn)題，而這種問(wèn)題在集成時(shí)遇到往往很難讓開(kāi)發(fā)人員預料到，最后在苦苦尋覓中才發(fā)現這是個(gè)很低級的錯誤而在悔恨自己時(shí)已經(jīng) 浪費了很多時(shí)間，這種時(shí)間上的浪費一點(diǎn)都不值得，正所謂得不償失。
-
測 試效果：根據以往的測試經(jīng)驗來(lái)看，單元測試的效果是非常明顯的，首先它是測試階段的基礎，做好了單元測試，在做后期的集成測試和系統測試時(shí)就很順利。其次 在單元測試過(guò)程中能發(fā)現一些很深層次的問(wèn)題，同時(shí)還會(huì )發(fā)現一些很容易發(fā)現而在集成測試和系統測試很難發(fā)現的問(wèn)題。再次單元測試關(guān)注的范圍也特殊，它不僅僅 是證明這些代碼做了什么，最重要的是代碼是如何做的，是否做了它該做的事情而沒(méi)有做不該做的事情。
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】 -
測 試成本：在單元測試時(shí)某些問(wèn)題就很容易發(fā)現，如果在后期的測試中發(fā)現問(wèn)題所花的成本將成倍數上升。比如在單元測試時(shí)發(fā)現1個(gè)問(wèn)題需要1個(gè)小時(shí)，則在集成測 試時(shí)發(fā)現該問(wèn)題需要2個(gè)小時(shí)，在系統測試時(shí)發(fā)現則需要3個(gè)小時(shí)，同理還有定位問(wèn)題和解決問(wèn)題的費用也是成倍數上升的，這就是我們要盡可能早的排除盡可能多 的bug來(lái)減少后期成本的因素之一。
-
產(chǎn)品質(zhì)量：?jiǎn)卧獪y試的好與壞直接影響到產(chǎn)品的質(zhì)量，可能就是由于代碼中的某一個(gè)小錯誤就導致了整個(gè)產(chǎn)品的質(zhì)量降低一個(gè)指標，或者導致更嚴重的后果，如果我們做好了單元測試這種情況是可以完全避免的。
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】
綜上所述，單元測試是構筑產(chǎn)品質(zhì)量的基石，我們不要因為節約單元測試的時(shí)間不做單元測試或隨便做而讓我們在后期浪費太多的不值得的時(shí)間，我們也不愿意因為由于節約那些時(shí)間導致開(kāi)發(fā)出來(lái)的整個(gè)產(chǎn)品失敗或重來(lái)！
1. 它是一種驗證行為。
程序中的每一項功能都是測試來(lái)驗證它的正確性，為以后的開(kāi)發(fā)提供支緩。就算是開(kāi)發(fā)后期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個(gè)過(guò)程中會(huì )破壞重要的東西。而且它為代碼的重構提供了保障，這樣，我們就可以更自由的對程序進(jìn)行改進(jìn)。
2.它是一種設計行為。
編寫(xiě)單元測試將使我們從調用者觀(guān)察、思考，特別是先寫(xiě)測試（test-first），迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合。另外還可以使編碼人員在編碼時(shí)產(chǎn)生預測試，將程序的缺陷降低到最小。
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】3.它是一種編寫(xiě)文檔的行為。
單元測試是一種無(wú)價(jià)的文檔，它是展示函數或類(lèi)如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。
4.它具有回歸性。
自動(dòng)化的單元測試避免了代碼出現回歸，編寫(xiě)完成之后，可以隨時(shí)隨地的快速運行測試。
1. 單元測試：?jiǎn)卧獪y試又稱(chēng)模塊測試，屬于白盒測試，是最小單位的測試。模塊分為程序模塊和功能模塊。功能模塊指實(shí)現了一個(gè)完整功能的模塊（單元），一個(gè)完整的程序單元具備輸入、加工和輸出三個(gè)環(huán)節。而且每個(gè)程序單元都應該有正規的規格說(shuō)明，使之對其輸入、加工和輸出的關(guān)系做出名明確的描述。
2.測試驅動(dòng)：驅動(dòng)被測試模塊正常運行起來(lái)的實(shí)體
3.測試樁：代替被測模塊調用的子模塊的實(shí)體，該實(shí)體一般為樁函數。
4. 測試覆蓋：評測測試過(guò)程中已經(jīng)執行的代碼的多少。
5.覆蓋率：代碼的覆蓋程度，一種度量方式。針對代碼的測試覆蓋率有許多種度量方式，定義如下：
-
-
判 定覆蓋（DecisionCoverage）：也被稱(chēng)為分支覆蓋（branchcoverage），所有邊界覆蓋（all- edgescoverage），基本路徑覆蓋（basispathcoverage），判定路徑覆蓋（decision-decision-path或 DDPtesting）。它度量是否每個(gè)B
OO型的表達式取值true和false在控制結構中都被測試到了。L
-
-
-
單元測試的對象是軟件設計的最小單位——模塊或函數，單元測試的依據是詳細設描述。測試者要根據詳細設計說(shuō)明書(shū)和源程序清單，了解模塊的I/O條件和模塊的邏輯結構。主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理和不合理的輸入都能鑒別和響應。要求對所有的局部和全局的數據結構、外部接口和程序代碼的關(guān)鍵部分進(jìn)行桌面檢查和代碼審查。在單元測試中，需要對下面5個(gè)方面的內容進(jìn)行測試，也是構造測試用例的基礎。
1) 模塊接口：測試模塊的數據流。如果數據不能正確地輸入和輸出，就談不上進(jìn)行其他測試。因此，對于模塊接口需要如下的測試項目：
-
調用所測模塊時(shí)的輸入參數與模塊的形式參數在個(gè)數、屬性、順序上是否匹配；
-
所測模塊調用子模塊時(shí)，它輸入個(gè)子模塊的參數與子模塊的形式參數在個(gè)數、屬性、順序上是否匹配；
-
是否修改了只做輸入用的形式參數；
-
輸出給標準函數的參數在個(gè)數、屬性、順序上是否匹配；
-
全局變量的定義在各模塊中是否一致；
-
限制是否通過(guò)形式參數來(lái)傳送。
2) 局部數據結構測試：模塊的局部數據結構是最常見(jiàn)的錯誤來(lái)源，應設計測試用例以檢查以下各種錯誤：
3)路徑測試：對基本執行路徑和循環(huán)進(jìn)行測試會(huì )發(fā)現大量的錯誤。根據白盒測試和黑盒測試用例設計方法設計測試用例。設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
Ø 運算的優(yōu)先次序不正確或誤解了運算的優(yōu)先次序；
Ø 運算的方式錯誤（運算的對象彼此在類(lèi)型上不相容）；
Ø 算法錯誤；
Ø 初始化不正確；
Ø 運算精度不夠；
Ø 表達式的符號表示不正確等。
Ø 不同數據類(lèi)型的比較；
Ø 不正確的邏輯運算符或優(yōu)先次序；
Ø 因浮點(diǎn)運算精度問(wèn)題而造成的兩值比較不等；
Ø 關(guān)系表達式中不正確的變量和比較符；
Ø “差1錯”，即不正確地多循環(huán)或少循環(huán)一次；
Ø 錯誤的或不可能的循環(huán)終止條件；
Ø 當遇到發(fā)散的迭代時(shí)不能終止循環(huán)；
Ø 不適當地修改了循環(huán)變量等。
4) 錯誤處理測試：比較完善的模塊設計要求能預見(jiàn)出錯的條件，并設置適當的出錯處理對策，以便在程序出錯時(shí)，能對出錯程序重新做安排，保證其邏輯上的正確性。這種出錯處理也是模塊功能的一部分。表明出錯處理模塊有錯誤或缺陷的情況有：
5) 邊界測試：邊界上出現錯誤上常見(jiàn)的。設計測試用例檢查：
何時(shí)進(jìn)行單元測試？單元測試在編碼階段進(jìn)行。在源程序代碼編制完成、經(jīng)過(guò)評審和驗證、確認沒(méi)有語(yǔ)法錯誤之后，就可以開(kāi)始進(jìn)行單元測試的測試用例設計。要利用軟件設計文檔，設計可以驗證程序功能、找出程序錯誤的多個(gè)測試用例。
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】對于每一組輸入，應該有預期的正確結果。在單元測試時(shí)，如果模塊不是獨立的程序，需要輔助測試模塊，有兩種輔助模塊：
被測試模塊、驅動(dòng)模塊和樁模塊共同構成了一個(gè)測試環(huán)境，如下圖所示：
1.測試用例的組成（在單元測試中測試用例基本上由測試腳本組成）
2.測試用例的設計原則
-
一個(gè)好的測試用例在于能夠發(fā)現至今沒(méi)有發(fā)現的錯誤；
-
測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成；
-
在測試用例設計時(shí)，應當包含合理的輸入條件和不合理的輸入條件；
-
為系統運行起來(lái)而設計測試用例；
-
為正向測試而設計測試用例；
-
為逆向測試而設計測試用例；
-
為滿(mǎn)足特殊需求而設計測試用例；
-
為代碼覆蓋而設計測試用例；
3.用例設計方法
1) 規范（規格）導出發(fā)
2) 等價(jià)類(lèi)劃分法
3) 邊界值分析法
4) 狀態(tài)轉移測試法
5) 分支測試法
6) 條件測試法
7) 數據定義－使用測試法（又名數據流測試法）
8) 內部邊界值測試法
9) 錯誤猜測法
4. 特定的用例測試設計
1)聲明測試：檢查模塊中的所有變量是否被聲明。經(jīng)驗表明，大量重要的錯誤都是由于變量沒(méi)有被聲明或沒(méi)有被正確的聲明而引起的。
2)路徑測試：要求模塊中所有可能的路徑都被執行一遍，屬邏輯覆蓋測試。
基本路徑測試：由于實(shí)際中，一個(gè)模塊中的路徑可能非常多，由于時(shí)間和資源有限，不可能一一測試到。這就需要把測試所有可能路徑的目標減少到測試足夠多的路徑，以獲得對模塊的信心。要測試的最小路徑集就是基本測試路徑集?；緶y試路徑集要保證：
3)循環(huán)測試：重點(diǎn)檢查循環(huán)的條件－判斷部分以及邊界條件。測試循環(huán)是一種特殊的路徑測試，因為循環(huán)比其他語(yǔ)句都復雜一些。循環(huán)中錯誤的發(fā)生機會(huì )比其他代碼構成部分多。因此，對于任何給定的循環(huán)測試應該包括測試下面每一條件的測試用例：
對于增量和減量不是1的FOR語(yǔ)句，要特別注意，因為程序員習慣于增量1。
4) 循環(huán)嵌套：循環(huán)嵌套使邏輯的次數呈幾何級數增長(cháng)，設計測試嵌套循環(huán)的測試用例應該包括的測試條件有：
-
把外循環(huán)設置為最小值，并運行內循環(huán)所有可能的情況；
-
把內循環(huán)設置為最小值，并運行外循環(huán)所有可能的情況；
-
把所有的循環(huán)變量都設置為最小值運行；
-
把所有的循環(huán)變量都設置為最大值運行；
-
把外循環(huán)設置為最大值，并運行內循環(huán)所有可能的情況；
-
把內循環(huán)設置為最大值，并運行外循環(huán)所有可能的情況；
5) 邊界值測試：指程序內部邊界測試。檢查確定代碼在任何邊界情況下都不會(huì )出差錯。重點(diǎn)檢查小于、等于和大于邊界條件的情況。邊界值測試是指專(zhuān)門(mén)設計用來(lái)測試當條件語(yǔ)句中引用的值處在邊界或邊界附近時(shí)系統反映的測試。被測試語(yǔ)句的最好的例子就是“IF-THEN…ELSE-ENDIF”部分。這樣語(yǔ)句的例子如：
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】 IF a <= 123 THEN
b = 1
ELSE IF a >= 123 THEN
b = 2
ELSE b = 3
END IF
上面例子中的邊界值測試用例應該至少包括a的以下值：122，123，124。當a=123時(shí)，b=1還是2。（找出邏輯判斷的矛盾）
6)接口測試：檢查模塊的數據流（輸入、輸出）是否正確。檢查輸入的參數和聲明的自變量的個(gè)數，數據類(lèi)型和輸入順序是否一致。檢查全局變量是否被正確的定義和使用等。
7)確認測試：是否接受有效輸入數據（操作），拒絕無(wú)效數據（操作）。
8)事務(wù)測試：輸入－>輸出，錯誤處理。
一般來(lái)說(shuō)，做單元測試均采用的是商用的測試工具或自行開(kāi)發(fā)的測試工具，用例的編寫(xiě)都是在測試工具上完成，測試用例都是一些測試腳本，都以文件的方式來(lái)保存，故其用例的執行過(guò)程主要是由測試工具根據所編寫(xiě)的具體的測試用例腳本來(lái)完成，這樣對于用例的管理和執行也非常靈活。
在特定場(chǎng)合，比如某種壓力測試或極限測試，對于測試執行過(guò)程時(shí)間很長(cháng)時(shí)（幾個(gè)小時(shí)以上），一般都預先編寫(xiě)好用例（確保用例無(wú)誤），使用空閑機或非工作時(shí)間執行測試用例，這樣操作起來(lái)較節約時(shí)間。
在用例的執行過(guò)程中務(wù)必注意如下事項：
在測試的過(guò)程中為了提高測試效率和效果，不斷的減少冗余勞動(dòng)，也為后期的回歸測試和測試管理帶來(lái)很大的方便，不至于感到測試很混亂無(wú)序。因此我們要對測試用例和測試執行進(jìn)行不斷的優(yōu)化，以測試策略為指導方針進(jìn)行測試。
【文章來(lái)源：文斯測試技術(shù)研究中心 http://blog.csdn.net/vincetest】1、測試用例的優(yōu)化
測試用例的優(yōu)化主要是指用例的合并、修改和刪除，減少冗余的無(wú)價(jià)值的測試，其優(yōu)化依據來(lái)源于測試后的測試數據分析和評估，其中測試覆蓋也是用例優(yōu)化的主要參考。
2、測試執行的優(yōu)化
測試執行的優(yōu)化主要是指測試步驟的優(yōu)化，減少測試人員的手工操作，因為太多的手工操作會(huì )導致測試人員很厭倦，直接影響測試效果，優(yōu)化依據來(lái)源于測試總結。
3、測試策略
在測試過(guò)程中由于時(shí)間或資源的原因可能會(huì )使測試處于緊張的局面，在此情況下我們要采取一定的策略來(lái)解決此局面。策略來(lái)源于測試數據的分析，主要的方法是：為各模塊制定測試優(yōu)先級，其優(yōu)先級的劃分依據如下：
單元測試完成以后，需要對單元測試的執行效果進(jìn)行評估，主要從以下幾方面進(jìn)行：
1)測試完備性評估，主要檢查測試過(guò)程中是否已經(jīng)執行了所有的測試用例，對新增的測試用例是否已及時(shí)更新測試方案等。
2)代碼覆蓋率評估，主要是根據代碼覆蓋率工具提供的語(yǔ)句覆蓋情況報告，檢查是否達到方案中的要求，公司要求語(yǔ)句覆蓋達到100％。但很多情況下，第一輪測試用例執行完后是很難達到的，這時(shí)在評估過(guò)程中要對覆蓋率進(jìn)行分析，主要從以下方面來(lái)考慮：
-
不可能的路徑或條件
-
不可達的或冗余的代碼
-
不充分的測試用例
3) 從覆蓋的角度看，測試應該覆蓋：
-
功能覆蓋
-
輸入域覆蓋
-
輸出域覆蓋
-
函數交互覆蓋
-
代碼執行覆蓋
大多數有效的測試用例都來(lái)自于分析，而不是僅僅為了達到測試覆蓋率目標而草率設計測試用例。千萬(wàn)不要誤解測試覆蓋，測試覆蓋并不是我們最求的目的，它只是評價(jià)測試的一種方式，為測試提供指導和依據。
1.測試過(guò)程中各種人員的作用
負責編碼和單元測試過(guò)程，完成單元測試計劃、方案和報告。
參與單元測試計劃、方案和報告的評審，對單元測試的計劃、設計和執行質(zhì)量進(jìn)行監控。根據實(shí)際情況，可選擇參與由開(kāi)發(fā)人員負責的代碼檢視、單元測試等活動(dòng)。
對代碼及單元測試文檔進(jìn)行配置管理。
參與編碼與單元測試評審，對編碼和單元測試過(guò)程進(jìn)行審計。
2. 單元測試輸入
3.單元測試的輸出
1. 單元測試實(shí)施步驟
1) 制定測試計劃和測試方案（包括測試工具的選擇）
2) 根據計劃和方案及相關(guān)輸入文檔編寫(xiě)測試用例
3) 搭建測試環(huán)境
4) 執行測試
5) 記錄和跟蹤問(wèn)題
6) 編寫(xiě)測試報告和總結報告
2. 單元測試實(shí)施遵循的原則
-
精心制定測試計劃
-
嚴格評審測試計劃
-
嚴格執行測試計劃
-
系統分析測試結果并提交報告
常用的C語(yǔ)言單元測試工具介紹如下：
1. VcTester
1) 簡(jiǎn)介
VcTester是與VC（注：Visual C++及VisualStudio開(kāi)發(fā)套件是微軟發(fā)布的產(chǎn)品）配套使用的新一代單元測試工具，分共享版與商用版兩大系列，其主要功能包括：腳本化測試驅動(dòng)（包括修改變量與調用函數）、腳本樁、支持持續集成測試、測試覆蓋率統計（僅商用版本）、生成測試報告（僅商用版本）、測試消息編輯器（僅商用版本）等。
2) 功能特性
-
腳本化測試驅動(dòng)
-
腳本樁
-
在線(xiàn)測試
-
即時(shí)調測
-
測試工程管理
3) 價(jià)格
共享版免費
4) 相關(guān)網(wǎng)站
2. C++Test
1) 簡(jiǎn)介
C++Test是一個(gè)功能強大的自動(dòng)化C/C++單元級測試工具，可以自動(dòng)測試任何C/C++函數、類(lèi)，自動(dòng)生成測試用例、測試驅動(dòng)函數或樁函數，在自動(dòng)化的環(huán)境下極其容易快速的將單元級的測試覆蓋率達到100%。
-
即時(shí)測試類(lèi)/函數
-
支持極端編程模式下的代碼測試
-
自動(dòng)建立類(lèi)/函數的測試驅動(dòng)程序和樁調用
-
自動(dòng)建立和執行類(lèi)/函數的測試用例
-
提供快速加入和執行說(shuō)明和功能性測試的框架
-
執行自動(dòng)回歸測試
-
執行部件測試(COM)
3) 價(jià)格
4) 相關(guān)網(wǎng)站
