4.1.3 單元測試計劃表格
在設計測試用例時可以參考如下表格，擬定對每個類（或模塊或包）的測試計劃。表1，是對每個類（或模塊或包）作測試計劃的表頭，它指明本測試計劃是針對那個模塊及相關文件的。表2是針對表1指定模塊測試用例而對應的子表，每個測試用例可以擁有一個子表；單元測試結果子表留作執行測試用例時根據實際結果填寫。
子系統名. PackageName. JavaClassName
|
單元測試計劃 | |
| 標識 | 格式： “子系統名. jsp_filename（含目錄中間用\分開即可）” 或者 “子系統名. PackageName. JavaClassName” |
| 組件功能項 | 如：組件完成 “新增貼子”的功能 |
| 針對概要/詳細設計文件名 | 如：1.1版本公告部分詳細設計說明書 |
| 物理文件名 | jsp_filename（含目錄）； packageName. JavaClassName |
表1
單元測試子項001
下面表格為針對上面表格“子系統名. PackageName. JavaClassName”而對應的子表，每個測試用例用一張子表：
| 編號 | .001 注：“. 編號” 部分要從001編號開始一直到999，個人自行編號 |
| 程序設計人員 | 如：XXX |
| 測試人員 | 如：XXX |
| 測試目的 | 如：對錯誤邏輯輸入檢驗 |
| 測試內容描述 | 如：對于public int fun3（String p1, int p2 ）的輸入檢驗，如果 p1 == null，程序中檢驗到，應該記錄到系統 logfile, return –1; |
| 輸入期望 | P1 == null |
| 功能處理期望描述 | Logfile 多一條歷史記錄，方法return -1； |
| 輸出期望 | Return –1 |
|
單元測試結果 | |
| 實際輸入數據 | P1 = null |
| 實際處理情況描述 | 程序沒有進行p1 == null 的驗證，沒有及時return –1，而是運行到 p1.aaa( ) 方法時出現 null pointer 異常。 |
| 實際輸出 | 沒有寫 logfile 文件； |
| 測試結論 | 正常 / 異常 |
表2
4.2 測試類設計
一個模塊或一個方法（Method）并不是一個獨立的程序，在考慮測試它時要同時考慮它和外界的聯系，用些輔助模塊去模擬與所測模塊相聯系的其他模塊。這些輔助模塊分為兩種：
1. 驅動模塊（driver）：相當于所測模塊的主程序。它接收測試數據，把這些數據傳送給所測模塊，最后再輸出實際測試結果。
2. 樁模塊（stub）：用于代替所測模塊調用的子模塊。樁模塊可以做少量的數據操作，不需要把子模塊所有功能都帶進來，但不容許什么事情也不做。
所測模塊與它相關的驅動模塊及樁模塊共同構成了一個“測試環境”，如圖2。驅動模塊和樁模塊的編寫會給測試帶來額外的開銷。因為它們在軟件交付時不作為產 品的一部分一同交付，而且它們的編寫需要一定的工作量。特別是樁模塊，不能只簡單地給出“曾經進入”的信息。為了能夠正確的測試軟件，樁模塊可能需要模擬 實際子模塊的功能，這樣樁模塊的建立就不是很輕松了。
圖2 單元測試的測試環境
編寫樁模塊是困難費時的，其實也是完全可以避免編寫樁模塊的；只需在項目進度管理時將實際樁模塊的代碼編寫工作安排在被測模塊前編寫即可。而且這樣可以提 高測試工作的效率，提高實際樁模塊的測試頻率從而更有效的保證產品的質量。但是，為了保證能夠向上一層級提供穩定可靠的實際樁模塊，為后續模塊測試打下良 好的基礎，驅動模塊還是必不可少的。
對于每一個包或子系統我們可以根據所編寫的測試用例來編寫一個測試模塊類來做驅動模塊，用于測試包中所有的待測試模塊。而最好不要在每個類中用一個測試函數的方法，來測試跟蹤類中所有的方法。這樣的好處在于：
1. 能夠同時測試包中所有的方法或模塊，也可以方便的測試跟蹤指定的模塊或方法。
2. 能夠聯合使用所有測試用例對同一段代碼執行測試，發現問題。
3. 便以回歸測試，當某個模塊作了修改之后，只要執行測試類就可以執行所有被測的模塊或方法。這樣不但能夠方便得檢查、跟蹤所修改的代碼，而且能夠檢查出修改對包內相關模塊或方法所造成的影響，使修改引進的錯誤得以及時發現。
4. 復用測試方法，使測試單元保持持久性，并可以用既有的測試來編寫相關測試。
5. 將測試代碼與產品代碼分開，使代碼更清晰、簡潔；提高測試代碼與被測代碼的可維護性。
4.3 跟蹤調試
跟蹤調試不但是深入測試代碼的最佳方法，而且也是程序調試發現錯誤根源的有利工具。
測試類設計完成后，最好能借助代碼排錯工具來跟蹤調試待測代碼段以深入的檢查代碼的邏輯錯誤�，F有的代碼開發工具（如：JBuilder）一般都集成了這 類排錯工具。排錯工具一般由執行控制程序、執行狀態查詢程序、跟蹤程序組成。執行控制程序包括斷點定義、斷點撤銷、單步執行、斷點執行、條件執行等功能。 執行狀態查詢程序包括寄存器、堆棧狀態、變量、代碼等與程序相關的各種狀態信息的查詢。跟蹤程序用以跟蹤程序執行過程中所經歷的事件序列（如：分支、子程 序調用等）。程序員可通過對程序執行過程中各種狀態的判別進行程序錯誤的識別、定位及改正。
對于模塊的單元跟蹤調試，最好能夠做到對被測模塊的每次修改，都對每個測試用例進行跟蹤執行一遍以排除所有可能出現或引進的錯誤。在時間有限的情況下也必須調用驅動模塊對所有的測試用例執行一次，并對出現錯誤或異常的測試用例跟蹤執行一次，以發現問題的根源。
排錯過程往往是一個艱苦的過程，特別是那種算法復雜、調用子模塊較多的模塊，對于錯誤的定位來說并不是一件容易的事情。盡管排錯不是一門好學的技術（有時人們更愿意稱之為藝術），但還是有若干行之有效的方法和策略，下面介紹幾種排錯時應該采用的方法策略。
1. 斷點設置，設置斷點對源程序實行斷點跟蹤將能夠大大提高排錯的效率。通常斷點的設置除了根據經驗與錯誤信息來設置外，還應重點考慮以下幾種類行的語句。
1） 函數調用語句。子函數的調用語句是測試的重點，一方面由于在調用子函數時可能引起接口引用錯誤，另一方面可能是子函數本身的錯誤。
2） 判定轉移/循環語句。判定語句常常會由于邊界值與比較優先級等問題引起錯誤或失效而作出錯誤的轉移。因此，對于判定轉移/循環語句也是一個重要的測試點。
3） SQL語句。對于數據庫的應用程序來說，SQL語句常常會在模塊中占比較重要的業務邏輯，而且比較復雜。因此，它也屬于比較容易出現錯誤的語句。
4） 復雜算法段。出錯的概率常與算法的復雜度成正比。所以越復雜的算法越需要作重點跟蹤，如遞歸、回朔等算法。
2. 可疑變量查看，在跟蹤執行狀態下當程序停止在某條語句時可以查看變量的當前值和對象的當前屬性。通過對比這些變量當前值與預期值可以輕松的定位程序問題根源。
3. SQL語句執行檢查，在跟蹤執行或運行狀態下將疑似錯誤的SQL語句打印出來，重新在數據庫SQL查詢分析器（如：Oracle SQL Plus）中跟蹤執行可以較高效的檢查糾正SQL語句錯誤。
4. 注意群集現象，經驗表明測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目或檢錯率成正比。根據這個規律，應當對錯誤群集的程序段進行重點測試，以提 高測試投資的效益。如果發現某一代碼段似乎比其他程序模塊更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程序模塊。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
