*錯誤數據：顯而易見，錯誤數據就是編寫與程序輸入規范不符的數據從而檢測輸入篩選、錯誤處理等程序的分支。
由于執行測試用例的數據量巨大以及還要進行回歸測試，所以可以考慮使用自動測試工具，但提取測試數據仍要依靠編寫測試用例人員的經驗。并且，我們還要注意到自動測試也許不能找到程序中所有錯誤，手動測試所找到的錯誤會比自動測試所找到的要多。
有了測試用例，我們就可以進行測試了吧?許多公司也是這樣做的，但在這里我建議大家最好要先進行代碼的審議。通過代碼審議找到的錯誤可以比測試用例測試所能找到的錯誤更加深入，并且發現錯誤的時間也比測試用例要早。
代碼審議要以代碼標準(根各公司具體情況自行制定)為依據，一般情況下要檢查以下幾點：
* 代碼風格和規則審核
* 程序設計和結構的審核
* 業務邏輯的審核
代碼風格和規則的審核是在每個程序員完成一個模塊或類的 時候要進行編碼規范的檢查。要召開審核會議讓所有的項目組人員都參加。在會前項目經理要做一個檢查表，以表的內容為檢查依據，檢查表的內容主要是檢查的要點。在審核會上項目組的每一個人員都能看到自己和其他人員的編碼問題，從而起到預防的作用。這些問題都要被解決，并且解決的結果要在審議會上被確認。
進行程序設計和結構的審議是因為開發工具的不同和項目時間的限制而造成設計不詳細。比較深入的設計通常是在編碼階段完成的，但由于程序人員和設計人員的經驗是不同的，所以會出現很大的問題。我們引入了程序設計和結構審核來保證質量。審核人員要有先進的技術開發經驗。在審核之前也要一個審核列表，列出主要幾項，如：程序的概要、詳細設計。但僅局限于列表是不夠的，審議人員 還要審議程序的精巧度和具有創造力的方面，這只能靠經驗而不能只靠列表中的內容來審議。對于不同的程序員所檢測代碼的寬度和深度也是不同的。項目經理可以根據程序員經驗的不同制定被審議人員的寬度和深度。例如：年輕的程序員要審議所有代碼。但有經驗的就可適當減少。
業務邏輯性審議必須要在代碼完成后審議。業務邏輯審議實際上是審議單元模塊的功能。這些功能是以系統說明為依據的。審議人員要有開發的經驗并且對系統也要熟悉。審議人員通過執行程序從而了解底層代碼的狀態。這階段的審議實際也包含了前兩種審議，因為審議者也可以通過最后的結果檢測單元模塊設計和結構的準確性。
以上三種審議都要耗費一定的時間和資源，但是它卻能更早地發現和解決不易顯現的錯誤。
審議通過后，我們終于可以使用用例來進行代碼測試和調試了。代碼的調試是用來保證程序能按照系統需求正常運行的一種手段。但是我所提到的這種代碼調試并不是簡單的調試，它要包括以下兩部分：
* 特征調試
* 代碼覆蓋調試
首先我們要先進行特征 調試。它是通過運行程序找到代碼中的錯誤，這與我們平時常進行的調試相同。到程序能運行后，我們可使用已編好的三種類型的用例并以正常數據測試用例進行測試，若不能正常運行則要用調試工具調試。在這階段，我們要用大量正常數據去測試。測試后，該程序應可在絕大多數的正常數據中運行。
其次，我們要進行代碼覆蓋測試，一直要達到以下目標為至：
* 測試到每一個最小語句的代碼
* 測試到所有的輸出結果
我們應該通過一步步的調試去運行每個程序的所有語句和分支。如果我們想要百分之百地覆蓋就應適當運用邊緣數據和錯誤數據。測試在這個階段的質量是難以掌握的。它基于程序員的責任心和經驗。當這階段完成后，每個程序員所測的深度也是不同的。
在這個測試階段之前，項目經理(或測試工程師)應制定出測試指導和計劃書。它們至少應包括以下內容：
* 測試的主要對象
* 主要調試點
* 怎樣測試
* 什么時候可以完成
至今為至，我們已完成了代碼的審議和調試。如果我們是嚴格按照以上步驟做的，那就可以保證代碼沒有太多的錯誤，至少沒有使程序運行中斷的錯誤了。如果我們不能很好地執行代碼審議和正確的調試，那我們就不能順利地通過測試，有時我們還要不得不返回來做這些事。
好了，我們終于完成了單元測試
文章來源于領測軟件測試網 http://www.kjueaiud.com/
