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