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