對於一般的大型程式，我們一般都會先進行單元測試，乙個單元一般是乙個子程式、乙個類、乙個函式、乙個模組等等，根據具體情況劃分。單元測試將注意力放在各個小的單元上，使得測試人員能夠相對容易的定位到錯誤的地方，同時由於把程式進行了模組化，所以可以多個單元模組同時測試。
單元測試過程主要需要考慮兩個大點：設計測試用例和執行測試。
對於單元測試，在設計測試用例時，單元測試主要是使用白盒測試，因為對於乙個單元，主要是需要檢查程式內部的邏輯結構。當然也需要根據情況結合黑盒測試，因為在規格說明中可能會有定位的這個模組的說明，因此需要使用黑盒測試來根據規格說明進行測試。
在執行測試的時候，又需要選擇具體的測試方法策略，因為我們雖然測試了各個單元，但是我們最終的目的還是要將各個單元模組組裝在一起，即：由點到面的過程。測試方法主要分為增量測試和非增量測試，而增量測試又可分為自頂向下測試和自底向上測試。
非增量測試主要是先單獨測試每個單元模組，當所有的單元模組都測試完了之後，再將這些模組組合成完整的程式。舉乙個具體的例子，如圖：
假設這是乙個程式，共有5個模組a，b，c，d，e，它們之間的關係是：a模組呼叫了b模組和c模組，b模組和c模組又分別呼叫了d模組和e模組，a模組是這個程式的最上層，d模組和e模組是最下層。
對於這個例子，如果是使用非增量測試的話，那麼是應該先對a，b，c，d，e這5個模組先單獨測試，單獨編寫測試用例，當測試完成後，直接將這5個模組組裝在一起。這就是非增量測試的整體流程。然而事實上並沒有這麼簡單，假如我們現在正在測試a模組，但是在a模組中卻呼叫了b模組和c模組，這應該怎麼辦呢？顯然是不可能將b模組和c模組拿過來用的。這裡就需要用到驅動模組和樁模組，驅動模組就是測試人員編寫的小模組，用來將測試用例傳入被測模組，並返回結果，這個可以看成是乙個函式，這個函式呼叫了被測模組，然後向被測模組傳入測試用例（引數），然後接受被測模組返回結果。樁模組主要是用來模擬被測模組中呼叫的其他模組的功能，比如a模組中呼叫了b模組和c模組，那麼這裡就需要新增兩個樁模組來模擬b模組和c模組的功能。
增量測試是將下乙個需要測試的模組先組裝到已經測試過的模組集合中去，然後再編寫測試用例，再進行測試。還是以上個例子為例，a模組是最上層，d模組和e模組是最下層，根據是從上層開始測試還是先從下層開始測試將增量測試分為了自頂向下測試和自底向上測試。
a.自頂向下測試
自頂向下測試是從程式的頂部或者初始模組開始，比如上例中的a模組。當a模組測試完畢後，就可以選擇b模組或者c模組與a模組組合，然後再進行測試，就這樣逐步向下組合進行測試，直到組合成最終的程式。
對於組合模組的序列，沒有具體的序列，需要根據情況去選擇合適的組合序列。這有兩項指南：
自頂向下測試的優點：
自頂向下測試的缺點：
b.自底向上測試
自底向上測試是從程式的底部（終端）模組開始，比如上例中的d模組或者e模組。自底向上測試彌補了自頂向下測試的不足，但是也有一些缺點。關於自底向上測試的組合序列，和自頂向下測試相同。
自底向上測試的優點：
自底向上測試的缺點：
通過對比，得到了以下幾個結論：
綜上：增量測試優於非增量測試，但是在具體的專案中，需要根據專案的實際情況選擇合適單元測試方法。
軟體測試之 單元測試
1 單元測試是對軟體基本組成單元進行的測試，如函式 fuction或procedure 或乙個類的方法 method 這裡，基本單元不一定是指乙個具體的函式 fuction或procedure 或乙個類的方法 method 在具體實現時，也可能對應的是多個程式檔案中的一組函式。2 在軟體系統中，單元...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...
軟體測試 Python 單元測試
數字轉布林型 class js def he self,i j 0s 0 while j i s j j 1 return simport unittest from com.tjb.tt.js import js 測試檔案不能使用 print 方法 class test1 unittest.tes...