培訓日期：2023年9月14日到2023年9月15日
日程安排：
第1天:
上午：單元測試的技術與方法培訓
下午：linux下cunit單元測試工具的使用方法
第2天：
上午：分組練習
下午：分組練習
練習總結
練習情況概述：
約50名開發人員參加了練習，分成了7個小組進行了練習，其中乙個小組原來採用c#在windows開發平台下進行軟體開發，其他小組均是在linux環境下用c語言開發。練習均在實際的工作環境中進行的，有的是2個開發人員合用一台機器進行了練習。
在設計測試用例時，每個小組都對函式的輸入引數進行了等價類劃分，設計了對應的測試用例，大部分小組對輸入引數也進行了邊界值分析，有的小組也對程式的內部邏輯進行了分析，設計的測試用例達到了100%語句覆蓋。對於測試用例的設計技巧需要繼續在實踐中提高。
有3個小組的測試程式中，函式的返回值是結構體或資料檔案，需要自己編寫預期結果與實際結果比較的函式。
練習結果的度量資料：
組
被測程式行數
測試程式行數
用例個數
bug 個數
1
90
100
9
3
2
90
70
19
3
3
102
142
5
2
4
150
140
14
3
5
76
40
6
0
6
65
54
7
1
7
1000
210
23
8
合計
573
546
60
12
其中有6個組被測的**行在65行到150行之間，有乙個小組的被測的**行在1000行，因此在統計分析時，將該小組的度量資料排除在外。經過對6個專案組的有效資料進行分析，得出如下的度量結果：
平均缺陷密度=21個缺陷/kloc;
單元測試用例密度=105個用例/kloc；
測試**行數：產品**行數=1：1
測試用例的有效性=每5個測試用例發現1個缺陷。
學員的總結與諮詢顧問的點評：
（1）程式設計師普遍感到最多的錯誤是邊界的錯誤和異常處理的錯誤。
(2）感覺cunit工具還不錯，測試框架本身提供了豐富的函式，使用者無需關心cunit的內部細節，而只需專注於測試用例的設計上
（3）測試用例在設計上，要周全考慮，做到**覆蓋率100%。
（4）對於被測試函式中一些系統呼叫，可以通過單獨封裝乙個函式模擬出錯情況。
（5）在編碼前編寫測試用例可以提醒程式設計師在寫**時避免哪些缺陷。
（6）對於每個單元應該在本單元內對入口引數進行合法性檢查，而不是在呼叫它的函式中做合法性檢查，以提高函式的可復用性與健壯性。
（7）對於不可逆的加密類複雜演算法的測試，可以採用編寫另外乙個已經得到驗證的函式計算測試資料的結果，和被測函式的實際結果進行對比，以判斷被測函式的正確性。
（8）如果**難以做單元測試，需要寫多個樁程式，則要考慮對該單元進行重構，調整結構，優化函式的分工。
（9）設計測試用例時，要充分考慮：
i) 對入口引數等價類劃分
ii)邊界值分析
iii)函式內部的邏輯分析。
單元測試訓練
任務說明 二選一 實現模組判斷傳入的電子郵箱賬號的正確性 實現要求 一 實現功能模組 public static void main string args else public static boolean validateemail string email string strings em...
單元測試技術
1.模組新建乙個libs包 2.導包我用的是junit 4.9 3.add as library 4.編寫測試類 注意 測試類不用寫main 方法 被測試的方法必須是 公共的 無引數的 無返回值的 執行沒有異常則綠 有異常則紅 public class mathcaltest test public...
單元測試練習
一，測試物件 查詢list中的最大值 int largest int list,int length 首份實現 如下 int largest int list,int length return max 二，單元測試 include using namespace std void largest ...