1）單元測試是對軟體基本組成單元進行的測試，如函式（fuction或procedure）或乙個類的方法（method）。這裡，基本單元不一定是指乙個具體的函式（fuction或procedure）或乙個類的方法（method），在具體實現時，也可能對應的是多個程式檔案中的一組函式。
2）在軟體系統中，單元也具有一些基本屬性，如：明確的功能、規格定義、明確的與其他部分的介面定義等，可清晰的與同一程式的其他單元劃分開來。
1)單元測試的目的在於發現各模板內部可能存在的各種錯誤，主要是基於白盒測試。
2)軟體產品不僅僅包含**，還包含各種文件，因此測試應從三方面考慮:
a.針對文件的測試;
b.針對**的測試;
c.針對文件和**是否一致的測試。
3）單元測試階段，對應的文件時詳細設計說明書，對應的**是單元**，因此單元測試的目的主要有三方面：
a.驗證單元**和詳細設計文件的一致性;
b.跟蹤詳細設計文件中設計的實現，發現詳細設計文件中存在的錯誤;
c.發現在編碼過程中引入的錯誤(編碼過程中引入的錯誤包含兩類:和設計不符引入的錯誤;和設計相符但由於編碼出現疏漏導致錯誤),這裡其實是針對文件和**是否一致的測試。
因此，單元測試的關注的重點有5點：單元介面、區域性資料結構、邊界條件、獨立路徑、出錯處理，下列一一介紹。
1）單元介面
介面實際上就是輸入輸出對應關係的集合，如果資料不能正確的輸入和輸出，就談不上進行其他測試，單元介面處常見錯誤：
a.被測單元的輸入輸出引數在個數、屬性、順序上和詳細設計中的描述不一致；
b.修改了只做輸入用的形式引數，可能會導致資料的錯誤修改；
c.約束條件通過形式引數來傳送，導致函式間的控制耦合增大（耦合是指兩個實體相互依賴於對方的乙個度量）。
2）區域性資料結構
在單元工作過程中，必須測試單元內部的資料能否保持完整性，包括內部資料的內容、形式及內部關係不發生錯誤。
對於區域性資料結構，應該在單元測試中注意發現以下幾類錯誤：
a.不正確或不一致的資料型別說明；
b.使用尚未賦值或尚未初始化的變數；
c.錯誤的初始值或錯誤的預設值；
d.變數名拼寫或書寫錯誤。
3）獨立路徑
對基本執行路徑和迴圈進行測試會發現大量的錯誤，常見的錯誤有：
a.運算的優先次序不正確或誤解了運算的優先次序；
b.運算的方式錯誤；
c.不同資料型別的比較；
d.關係表示式中不正確的變數和比較符；
e.「差1錯」。即不正確的多迴圈或少迴圈一次；
f.錯誤的或不可能的迴圈終止條件；
g.當遇到發散的迭代時不能終止的迴圈；
h.不適當地修改了迴圈變數等。
4）出錯處理
比較完善的單元設計要求能預見出錯條件，並設定適當的出錯處理，以便在出錯時，能對出錯程式重新作安排，保證其邏輯上的正確性，出錯處理模組常見的錯誤或缺陷有：
a.出錯的描述難以理解；
b.出錯的描述不足以對錯誤定位和確定出錯的原因（這個錯誤由系統的安全級別來定）；
c.現實的錯誤與實際的錯誤不符；
d.對錯誤條件的處理不正確；
e.在對錯誤驚醒處理之前，錯誤條件已經引起系統的干預等。
5）邊界條件
邊界上出現錯誤是比較常見的，單元測試時，應當仔細的測試為限制資料處理而設定的邊界條件。
需要注意與邊界有關的資料型別如數值、字元、位置、數量、尺寸等，還需注意這些邊界的首個、最後乙個、最大值、最小值等特徵，常見錯誤出現情況：
a.在n次迴圈的第n次，取最大最小值時容易發生錯誤；
b.特別要注意資料流，控制流中剛好等於、大於、小於確定的比較值時出現錯誤的可能性。
1）驅動單元（driver）
用來模擬被測試單元的上層單元，相當於被測函式的主程式，它接收測試資料，將相關資料傳送到被測單元，啟動被測單元，最後再輸出實測結果。當被測單元能完成相關功能時，也可以不要驅動單元。
驅動單元，主要完成以下幾個步驟
a.接受測試資料，包含測試用例的輸入和預期輸入；
b.把測試用例輸入傳送給要測試的單元，驅動被測單元執行；
c.將被測單元的實際輸出和預期輸出進行比較，得到測試結果；
d.將測試結果輸出到指定位置。
2）樁單元（stub）
指用來代替被測單元工作過程中呼叫的子單元，樁單元的功能是從測試角度模擬被測單元所呼叫的其他單元，樁單元需要針對不同的輸入，返回不同的期望值，模擬不同的功能。如果被測單元為底層函式嗎，則不需要設計樁單元。
樁單元的型別：系統函式、自定義函式。
樁單元模擬的單元可能是自定義函式：這些自定義函式可能尚未編寫完成，為了測試被測單元，需要構造樁單元來替代他們；或者可能存在錯誤，會影響測試結果，給分析被測單元造成困難，因此需要構造正確無誤的樁單元來達到隔離的目的。
3）構造單元的測試環境的主要工作
a.構造最小執行排程系統，即驅動單元，用以模擬被測單元的上一級單元;
b.模擬實現單元介面，即單元函式需呼叫的其他函式介面，即樁單元;
c.模擬生成測試資料和狀態，為單元執行準備動態環境。
1）孤立的單元測試策略（isolation unit testing）
a.方法：不考慮每個模組與其他模組之間的關係，為每個模組設計樁模組和驅動模組;
每個模組進行獨立的單元測試.
b.優點：最簡單，最容易操作;
可以達到高的結構覆蓋率;
可以並行開開展；
是純粹的單元測試。
c.缺點：樁函式和驅動函式工作量很大，效率低。
2）自頂向下的單元測試策略（top down unit testing ）
a.方法：先對最頂層的單元進行測試，把頂層所呼叫的單元做成樁模組；
對第二層進行測試，使用上面已測試的單元做驅動模組；
如此類推直到測試完所有模組。
b.優點：可以節省驅動函式的開發工作量，測試效率較高。
c.缺點：隨著被測單元乙個乙個被加入，測試過程將變得越來越複雜，並且開發和維護的成本將增加。
3）自底向上的單元測試策略（bottom up unit testing）
a.方法：先對模組呼叫層次圖上最底層的模組進行單元測試，模擬呼叫該模組的模組做驅動模組；
然後再對上面一層做單元測試，用下面已被測試過的模組做樁模組；
以此類推，直到測試完所有模組。
b.優點：可以節省樁函式的開發工作量，測試效率較高。
c.缺點：不是純粹的單元測試，底層函式的測試質量對上層函式的測試將產生很大的影響。
1）單元測試計畫階段：完成單元測試計畫
2）單元測試設計階段：完成單元測試方案
3）單元測試實現階段：完成單元測試用例、單元測試教程、單元測試指令碼及資料檔案
4）單元測試執行階段：執行單元測試用例。修改發現的問題並進行回歸測試，提交單元測試報告
1）對全新的**或修改過的**進行測試；
2）單元測試根據單元測試方案和計畫進行，排除測試的隨意性；
3）必須保證單元測試計畫、單元測試方案、單元測試用例等經過評審；
4）當測試用力地測試結果與預期結果不一致時，單元測試的執行人員需如實記錄實際的測試結果；
5）只有當測試計畫中的結束標準達到時，單元測試才能結束；
6）對被測試單元需達到一定的**覆蓋率要求。
1）**靜態分析工具
2）**檢查工具
3）測試指令碼工具
4）覆蓋率檢測工具
5）記憶體檢測工具
6）專為單元測試設計的工具
軟體測試之單元測試
對於一般的大型程式，我們一般都會先進行單元測試，乙個單元一般是乙個子程式 乙個類 乙個函式 乙個模組等等，根據具體情況劃分。單元測試將注意力放在各個小的單元上，使得測試人員能夠相對容易的定位到錯誤的地方，同時由於把程式進行了模組化，所以可以多個單元模組同時測試。單元測試過程主要需要考慮兩個大點 設計...
單元測試之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...