測試用例的設計在很大程度上是由簡單到詳細且逐步完善的一個過程。其依據需求文檔、概要設計、詳細設計等參考資料。假如在測試過程中沒有測試用例或僅有簡單的功能描述，那么測試過程難以控制或測試結果將毫無可靠性而言。網上對測試用例的具體設計的文章也數不勝數了，筆者在這也不重復闡述。
因此，筆者對測試用例的總結為：
簡單的測試用例可靠性低、重用性差，且可能導致不同人員理解不同。
詳細的測試用例可靠性高，而且便于估計執行所需時間，易于控制。
我們在設計測試用例時應當考慮以下幾點：
第一、時間要求。［是否在測試過程中，測試用例的執行易于控制］
第二、執行者。［應當考慮不同的測試用例執行者對系統的了解程度］
第三、理解程度。［當把測試用例交付給他人執行時應不需要過多的解釋］
所以，測試用例的設計重要性顯而易見。
登錄功能，是一個大家熟悉得不能再熟悉的功能了。但是往往這類看似簡單但卻不簡單的功能，在設計測試用例時卻漏洞百出。下面，我們通過Google郵箱的登錄窗口實例進一步了解測試用例的設計。
☆ 簡單的測試用例
用例編號 | 功能點 | 操作過程 | 預期結果 | 備注 |
01 | 登錄 | 能夠正確處理用戶登錄 | 正確處理登錄操作 | 無 |
☆ 一般的測試用例
用例編號 | 功能點 | 操作過程 | 預期結果 | 備注 |
01 | 登錄 | 輸入正確的用戶名和口令可以進入系統 | 登錄成功 | 無 |
輸入用戶名或口令錯誤無法進入系統 | 登錄失敗 | 無 |
☆ 詳細的測試用例
用例編號 | 功能點 | 操作過程 | 預期結果 | 備注 |
01 | 登錄 | 輸入正確的用戶名和口令（均為6位），點擊[登錄]按鈕 | 進入系統 | 無 |
輸入正確的用戶名和口令（均為10位），點擊[登錄]按鈕 | 進入系統 | 無 |
輸入正確的用戶名和口令（均為6至8位之間），點擊[登錄]按鈕 | 進入系統 | 無 |
用戶名為空，點擊[登錄]按鈕 | 提示輸入用戶名 不能進入系統 | 無 |
用戶名為空格，點擊[登錄]按鈕 | 提示無效用戶名 不能進入系統 | 無 |
用戶名小于6位，點擊[登錄]按鈕 | 提示用戶名太短 不能進入系統 | 無 |
通過以上三個測試用例，我們可以很直觀的了解到測試用例具體實現價值。但是，我們達到第三種測試用例設計技巧時還是不能體現其“詳細”的概念化。
到這，可能很多讀者會問為什么？其實，答案很簡單。雖然我們在設計用例時把過程體現了，但并沒有把測試數據容入當中。那為什么又要寫入相應的測試數據 呢？我們可以分三點看待這個問題。第一、沒有將測試數據和測試邏輯分開的測試用例可能顯得非常龐大，不利于測試員理解，導致難以控制和執行；第二、通過將 用例參數化，可以簡化用例，使測試用例邏輯清晰，數據與邏輯的關系明了，易于理解；第三、有利于提高測試用例的復用性。所以，在加入輸入（數據或操作 等）、輸出（結果數據或預期結果等）的測試用例可以很好的重復使用。
☆ 詳細的測試用例（含測試數據）
結束語：測試用例的設計是否詳細，直接關系著測試生命周期的正常表現。