單元測試怎麼造數據

❶ 如何編寫單元測試

單元測試是代碼正確性驗證的最重要的工具，也是系統測試當中最重要的環節。也是唯一需要編寫代碼才能進行測試的一種測試方法。在標準的開發過程中，單元測試的代碼與實際程序的代碼具有同等的重要性。每一個單元測試，都是用來定向測試其所對應的一個單元的數據是否正確。
Microsoft Visual Studio 2005中集成了一個專門用來進行測試的組件，該組件能夠提供給我們單元測試、壓力測試、代碼覆蓋率等等的測試相關的功能。我們無須借用第三方的測試工具來進行這些測試。
2.1 創建單元測試
該工具可以對任何類、介面、結構等實體中的欄位、屬性、構造函數、方法等進行單元測試。創建單元測試大致可以分為兩類：
整體測試，整體測試是在類名稱上右擊滑鼠，在下拉菜單中點擊創建單元測試選項。這樣就可以為整個類創建單元測試了，這時他會為整個類可以被測試的內容全部添加測試方法。開發人員直接在這些自動生成的測試方法中添加單元測試代碼就可以了。
單獨測試，如果只想單獨對某個方法、屬性、欄位進行測試，則可以將滑鼠焦點放在這個待測試的項目名稱之上，然後點擊滑鼠右鍵，在右鍵菜單中選擇創建單元測試選項。這樣就可以單獨為某個方法創建單元測試了。
2.2 編寫單元測試代碼
創建完單元測試之後，就可以為單元測試編寫測試代碼了。具體的測試代碼的編寫標准會在第三章中介紹。
2.3 運行單元測試
單元測試代碼編寫完畢，就可以通過運行單元測試來進行測試了。需要運行單元測試的時候，需要打開測試管理器窗口。該窗口可以通過菜單中的「測試」－「窗口」——「測試管理器」來打開。打開該窗口之後，就可以在該窗口中看到我們所建立的單元測試的列表。我們可以在列表中勾選某個單元測試前面的復選框。然後右擊滑鼠在右鍵菜單中點擊「調試選中的測試」或者「運行選中的測試」。
調試選中的測試的時候，我們可以在測試代碼中或者我們自己的代碼中添加斷點並逐步運行以看其狀態。
運行選中的測試只會運行測試並不能夠進行測試，這時代碼的運行是模擬真實軟體運行的時候的情況執行的。我們可以根據我們的實際情況來選中執行哪種測試。
2.4 測試結果
運行了測試之後，我們需要查看這次測試的結果。我們可以通過點擊菜單中的「測試」——「窗口」——「測試結果」來打開一個測試結果窗口。每次測試都會在測試結果中向我們顯示一些記錄。我們也可以通過雙擊這個測試結果，來查看詳細的結果信息。

❷ 單元測試的基本方法

單元測試的對象是軟體設計的最小單位——模塊。單元測試的依據是詳細設描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多採用白盒測試技術，系統內多個模塊可以並行地進行測試。

單元測試任務包括：
1 模塊介面測試；
2 模塊局部數據結構測試；
3 模塊邊界條件測試；
4 模塊中所有獨立執行通路測試；
5 模塊的各條錯誤處理通路測試。

1 輸入的實際參數與形式參數的個數是否相同；
2 輸入的實際參數與形式參數的屬性是否匹配；
3 輸入的實際參數與形式參數的量綱是否一致；
4 調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；
5 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；
6調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；
7 調用預定義函數時所用參數的個數、屬性和次序是否正確；
8 是否存在與當前入口點無關的參數引用；
9 是否修改了只讀型參數；
10 對全程變數的定義各模塊是否一致；
11是否把某些約束作為參數傳遞。

如果模塊內包括外部輸入輸出，還應該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語句是否正確；
3 格式說明與輸入輸出語句是否匹配；
4緩沖區大小與記錄長度是否匹配；
5文件使用前是否已經打開；
6是否處理了文件尾；
7是否處理了輸入/輸出錯誤；
8輸出信息中是否有文字性錯誤；

檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
1 不合適或不相容的類型說明；
2變數無初值；
3變數初始化或省缺值有錯；
4不正確的變數名（拼錯或不正確地截斷）；
5出現上溢、下溢和地址異常。

除了局部數據結構外，如果可能，單元測試時還應該查清全局數據（例如FORTRAN的公用區）對模塊的影響。

在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：
1 誤解或用錯了算符優先順序；
2混合類型運算；
3變數初值錯；
4精度不夠；
5表達式符號錯。

比較判斷與控制流常常緊密相關，測試用例還應致力於發現下列錯誤：
1不同數據類型的對象之間進行比較；
2錯誤地使用邏輯運算符或優先順序；
3因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
4比較運算或變數出錯；
5循環終止條件或不可能出現；
6迭代發散時不能退出；
7錯誤地修改了循環變數。

一個好的設計應能預見各種出錯條件，並預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：
1輸出的出錯信息難以理解；
2記錄的錯誤與實際遇到的錯誤不相符；
3在程序自定義的出錯處理段運行之前，系統已介入；
4異常處理不當；
5錯誤陳述中未能提供足夠的定位出錯信息。

邊界條件測試是單元測試中最後，也是最重要的一項任務。眾的周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。

一般認為單元測試應緊接在編碼之後，當源程序編制完成並通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。
應為測試模塊開發一個驅動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環境。驅動模塊在大多數場合稱為「主程序」，它接收測試數據並將這些數據傳遞到被測試模塊，被測試模塊被調用後，「主程序」列印「進入-退出」消息。
驅動模塊和樁模塊是測試使用的軟體，而不是軟體產品的組成部分，但它需要一定的開發費用。若驅動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，這些模塊的單元測試只能採用下面討論的綜合測試方法。
提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數目將顯著減少，模塊中的錯誤也更容易發現。

本文轉自網路

❸ 如何編寫單元測試

元測試是代碼正確性驗證的最重要的工具，也是系統測試當中最重要的環節。也是唯一需要編寫代碼才能進行測試的一種測試方法。在標準的開發過程中，單元測試的代碼與實際程序的代碼具有同等的重要性。每一個單元測試，都是用來定向測試其所對應的一個單元的數據是否正確。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。
單元測試還具有一下幾個好處：
能夠協助程序員盡快找到BUG的具體位置
能夠讓程序員對自己的程序更有自信
能夠讓程序員在提交項目之前就將代碼變的更加健壯
能夠協助程序員更好的進行開發
能夠向其他程序員展現你的程序該如何調用
能夠讓項目主管更了解系統的當前狀況

❹ 單元測試到底是什麼應該怎麼做

單元測試一般是有開發人員或測試人員來做。誰來做並沒有一個絕對的標准，要根據公司的實際情況來決定。

單元測試的實現方式包括：人工靜態檢查、動態執行跟蹤。

人工靜態檢查：就是通常所說的「代碼走讀」，主要是保證代碼邏輯的正確性。

動態執行跟蹤：就是把程序代碼運行起來，檢查實際的運行結果和預期結果是否一致。

開發人員做單元測試：

優點：開發人員對代碼最熟悉，而且開發人員編程技能相對比較強，所以開發人員自己寫單元測試效率上和覆蓋率上都比較高。

缺點：開發人員平時寫業務代碼就要花費很多時間，有時候確實沒有時間寫單元測試；而且大部分開發人員沒有太好的測試思想，單元測試可能只是寫個最簡單的用例就完了；自己寫的代碼自己測，往往都是不靠譜。

測試人員做單元測試：

優點：測試人員有比較系統的測試思想，可以更好地保證用例的覆蓋。而且通過寫單測測試能更好地了解具體代碼結構、流程，對於後續的業務測試也非常有利。

缺點：測試人員的編程技能相對比較弱，如果不同編程是無法開展單元測試的。並且測試人員對代碼沒有開發人員熟悉，效率會比較低。

❺ java單元測試怎麼造大於1g的文件

輸入代碼。根據查詢相關公開信息顯示，java單元測試需要編程員在控制台中不斷輸入文件代碼使其累計大小達到1gb即可完成。Java是一種編程語言。

❻ 如何編寫單元測試用例

1，語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。

2，判定覆蓋（也叫分支覆蓋）：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。

3，條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次。

4，判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少執行一次。

5，條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次。

❼ 軟體工程單元測試應該怎麼寫

。。。。。。。。。。。。。。。。