需求測試用例通常是按照需求執行的功能逐條地編寫輸入數據和期望輸出。一個好的需求用例是可以用少量的測試用例就能夠覆蓋所有的程序功能。　　設計測試用例檢測的是代碼和設計是否完全相符。是對底層設計和基本結構上的測試。設計測試用例可以涉及到需求測試用例沒有覆蓋到的代碼空間(例如界面的設計)。

　　代碼測試用例是基于運行軟件和數據結構上的。它要保證可以覆蓋所有的程序分支、最小的語句和輸出。

　　以上三種用例所用的數據又可分為正常數據、邊緣數據和錯誤數據。

　　*正常數據：在測試中所用的正常數據的量是最大的，而且也是最關鍵的。少量的測試數據不能完全覆蓋需求，但我們要從中提取出一些具有高度代表性的數據作為測試數據，以減少測試時間。

　　*邊緣數據：邊緣測試是界于正常數據和錯誤數據之間的一種數據。它可以針對某一種編程語言、編程環境或特定的數據庫而專門設定。例如若使用SQL Server數據庫，則可把SQL Server關鍵字(如：‘;AS;Join等)設為邊緣數據。其它邊緣數據還有：HTML的HTML;<>等關鍵字以及空格、@、負數、超長字符等。邊緣數據要靠測試人員的豐富經驗來制定。

　　*錯誤數據：顯而易見，錯誤數據就是編寫與程序輸入規范不符的數據從而檢測輸入篩選、錯誤處理等程序的分支。

　　由于執行測試用例的數據量巨大以及還要進行回歸測試，所以可以考慮使用自動測試工具，但提取測試數據仍要依靠編寫測試用例人員的經驗。并且，我們還要注意到自動測試也許不能找到程序中所有錯誤，手動測試所找到的錯誤會比自動測試所找到的要多。

　　有了測試用例，我們就可以進行測試了吧?許多公司也是這樣做的，但在這里我建議大家最好要先進行代碼的審議。通過代碼審議找到的錯誤可以比測試用例測試所能找到的錯誤更加深入，并且發現錯誤的時間也比測試用例要早。代碼審議要以代碼標準(根各公司具體情況自行制定)為依據，一般情況下要檢查以下幾點：

　　* 代碼風格和規則審核

　　* 程序設計和結構的審核

　　* 業務邏輯的審核

　　代碼風格和規則的審核是在每個程序員完成一個模塊或類的 時候要進行編碼規范的檢查。要召開審核會議讓所有的項目組人員都參加。在會前項目經理要做一個檢查表，以表的內容為檢查依據，檢查表的內容主要是檢查的要點。在審核會上項目組的每一個人員都能看到自己和其他人員的編碼問題，從而起到預防的作用。這些問題都要被解決，并且解決的結果要在審議會上被確認。

　　進行程序設計和結構的審議是因為開發工具的不同和項目時間的限制而造成設計不詳細。比較深入的設計通常是在編碼階段完成的，但由于程序人員和設計人員的經驗是不同的，所以會出現很大的問題。我們引入了程序設計和結構審核來保證質量。審核人員要有先進的技術開發經驗。在審核之前也要一個審核列表，列出主要幾項，如：程序的概要、詳細設計。但僅局限于列表是不夠的，審議人員 還要審議程序的精巧度和具有創造力的方面，這只能靠經驗而不能只靠列表中的內容來審議。對于不同的程序員所檢測代碼的寬度和深度也是不同的。項目經理可以根據程序員經驗的不同制定被審議人員的寬度和深度。例如：年輕的程序員要審議所有代碼。但有經驗的就可適當減少。

　　業務邏輯性審議必須要在代碼完成后審議。業務邏輯審議實際上是審議單元模塊的功能。這些功能是以系統說明為依據的。審議人員要有開發的經驗并且對系統也要熟悉。審議人員通過執行程序從而了解底層代碼的狀態。這階段的審議實際也包含了前兩種審議，因為審議者也可以通過最后的結果檢測單元模塊設計和結構的準確性。