設計、書寫和執行測試案例是測試活動中重要的組成部分，測試案例通常由測試案例管理系統或工具進行管理。
測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據。測試用例編寫應該遵循的原則：
特性：
壹個好的測試用例應該具有較高的發現某個尚未發現的錯誤的可能性，而壹個成功的測試案例能夠發現某個尚未發現的錯誤，通常壹個好的測試案例有以下特性：
測試用例不可能設計得天衣無縫，也不可能完全滿足軟件需求的覆蓋率，測試執行過程裏肯定會發現有些測試路徑或數據在用例裏沒有體現，那麽事後該將其補充到用例庫裏，以方便他人和後續版本的測試。
測試用例的信息有很多，可以根據實際的情況進行增刪，壹般來說壹個優秀的測試用例應該包含以下信息：
這些信息建議可以由測試案例自動生成。
測試級別進行說明：
6.測試類型：功能測試、邊界測試、異常測試、性能測試、壓力測試、兼容測試、安全測試、恢復測試、安裝測試、界面測試、啟動/停止 測試、文檔測試、配置測試、可靠性測試、易用性測試、多語言測試。
7.預置條件：對測試的特殊條件或配置進行說明
8.測試步驟：詳細描述測試過程，案例的操作步驟建議少於15個。
9.預期結果：預期的測試結果
例如：假設目前測試中國移動互聯短信網關是否能正確發送短信給中國聯通互聯網關，測試用例的設計如下：
（1）測試用例ID：TC000001
（2）測試用例名稱：中國移動全球通手機用戶成功發送短信給中國聯通手機用戶
（3）測試功能點：中國移動全球通手機用戶成功短信給中國聯通手機用戶，中國聯通網關返回成功的狀態報告
（4）測試目的：
A、中國移動互聯短信網關能否正確處理全球通用戶發送給中國聯通用戶的短信；
B、中國移動互聯短信網關能否正確處理中國聯通互聯短信網關返回成功的狀態報告的情況。
（5）測試級別：基本功能測試
（6）測試類型：功能測試
（7）預置條件：各網關實體按照組網圖中的關系連接好，各實體之間的連接和通信正常。
（8）測試步驟：
A、中國移動全球通手機用戶（13901000001）給中國聯通手機用戶（13001000001）發送MO短信，內容為“測試”，目的號碼填為中國聯通手機號碼；
B、中國聯通互聯短信網關把短信下發給中國聯通用戶成功後，給中國移動互聯短信網關返回壹個標識成功的狀態報告。
（9）預期結果：
A、中國聯通手機用戶（13001000001）接收到了短信，內容為“測試”，源號碼為中國移動全球通的用戶號碼（13901000001）；
B、在中國移動互聯短信網關上產生SMO話單，其中“短消息發送狀態”填0（表示成功），“源手機號碼”13001000001，“目的手機號碼”為13001000001。
下面是壹個完整的測試用例的模版：
對壹個全新的產品來說，首先需要了解的是產品需求文檔和產品模塊之間的關系。然後需要從需求文檔中書寫與所有需求相對應的主路徑測試案例和煙霧測試案例， 這個時候也同時會包括壹定的基本路徑測試案例甚至是詳細測試案例。在這個時候，因為對產品沒有直接的使用感受，書寫測試案例要考慮面廣而不要太過精細。繼 續閱讀產品功能定義文檔，將所有的功能定義直接對應寫相關的測試案例，這個時候，最好能夠對程序的本身有壹定的接觸，加深對程序的了解，以便寫出更好，更 全面的測試案例。最後，在實際測試中，還需要不斷擴充，修改以前的測試案例，得到完整的基本功能測試案例和詳細測試案例。如果對於壹個已有壹定或大部分案 例的產品來說，不管測試者是否本身熟悉這個產品，其主要的任務就是閱讀，檢查需求及相關的變更，然後對原有的案例進行理解，擴充和修改。這就是案例的重用 /復用。設計測試案例的時候，需要有清晰的測試思路，對要測試什麽，按照什麽順序測試，覆蓋哪些需求做到心中有數。測試用例編寫者不僅要掌握軟件測試的技 術和流程，而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。
測試用例設計壹般包括以下幾個步驟：
1、測試需求分析從軟件需求文檔中，找出待測試軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試對象具有哪些功能。測試需求的特點是：包含軟件需求，具有可測試性。
測試需求應該在軟件需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關系是多對壹的關系，即壹個或多個測試用例集對應壹個測試需求。
2、業務流程分析軟件測試，不單純是基於功能的黑盒測試，還需要對軟件的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的了解軟件產品的業務流程。建 議在做復雜的測試用例設計前，先畫出軟件的業務流程。如果設計文檔中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流 程，測試工程師應通過閱讀設計文檔，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟件的處理邏輯和數據流向，從而指導測試用例的設計。
從業務流程上，應得到以下信息：
A、主流程是什麽
B、條件備選流程是什麽
C、數據流向是什麽
D、關鍵的判斷條件是什麽
3、測試用例設計
完成了測試需求分析和軟件流程分析後，開始著手設計測試用例。測試用例設計的類型包括功能測試，邊
界測試，異常測試，性能測試，壓力測試等。在用例設計中，除了功能測試用例外，應盡量考慮邊界、異
常、性能的情況，以便發現更多的隱藏問題。
黑盒測試的測試用例設計方法有：等價類劃分、邊界值劃分、因果圖分析和錯誤猜測，白盒測試的測試用
例設計方法有：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、多重條件覆蓋。在這裏主要討論黑盒測
試。在設計測試用例的時候可以使用軟件測試用例設計方法，結合前面的需求分析和軟件流程分析進行設
計：
功能測試：測試某個功能是否滿足需求的定義，功能是否正確，完備。
適合的技術：由業務需求和設計說明導出的功能測試、等價類劃分
邊界測試：對某個功能的邊界情況進行測試。
適合的技術：邊界值劃分
異常測試：對某些功能來說，其邊界情況無法簡單的了解或某些操作不完全是正確的但又是可能發生的，
類似這樣的情況需要書寫相關的異常測試。
適合的技術：由業務需求和設計說明導出的特殊業務流程、錯誤猜測法、邊界值分析、內部邊界值測試、
性能測試：檢查系統是否滿足在需求中所規定達到的性能，性能主要包括了解程序的內外部性能因素。內部性能因素包括測試環境的配置，系統資源使用狀況；外部因素包括響應時間，吞吐量等。
適合的技術：業務需求和設計說明導出的測試
壓力測試：壓力測試又稱強度測試，主要是檢查系統運行環境在極限情況下軟件運行的能力，比如說給壹個相當大的負荷或網絡流量給應用軟件兼容測試：測試軟件產品在不同的平臺，不同的工具，相同工具的不同版本下功能的兼容性。
4、測試用例評審
測試用例設計完成後，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。
測試用例評審壹般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、項目經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，並記錄修改日誌。
5、測試用例更新完善
測試用例編寫完成之後需要不斷完善，軟件產品新增功能或更新需求後，測試用例必須配套修改更新；在測試過程中發現設計測試用例時考慮不周，需要對測試用例 進行修改完善；在軟件交付使用後客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。壹般小的修改完善可在原測試用例文檔 上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例壹般也應隨之編制升級更新版本。測試用例是“活”的，在軟件的生命周期中不斷更新與完善。