測試用例的編寫是測試過程中的乙個環節，位於在真正開始測試執行之前，在測試分析完成之後。
用例（case）主要有兩個作用：一是提供可執行/可操作的用例執行方式說明；二是在測試執行過程中記錄用例的通過情況及bug跟蹤。
為滿足上述目的，可見用例需滿足以下幾個要求：
1.可執行
根本目的在於，使有一定背景知識的操作人員，根據用例中的執行步驟，能夠完整地執行整個操作過程，得出乙個確定的結果。
所以，任何操作用例都是有受眾的，受眾即是具體執行測試用的測試執行人員。把受眾假設為毫無背景知識的人，是最穩妥的方式，這樣寫出來的用例，按照step by step的方式，告訴使用者如何進行用例的執行，盡可能全量地包含所有操作過程中可能遇到的問題點。這樣的用例，集盒起來，其實也是乙個技術性的操作手冊。
但是，這樣的用例編寫是有代價的，更為細緻的用例必然會消耗更多的用例編寫精力，而且測試執行人員也並非零背景知識的參與人員。在如何盡可能詳細表達測試需要執行的步驟和節約用例編寫成本之間取得乙個平衡。這也是用例編寫人員的核心競爭力之一，即如何簡約地描述測試執行。
2.結果明確
乙個用例，只有在有明確的驗證點的情況下，才能夠判斷用例執行是否通過。像「系統執行正常」，「輸入資料友好」，「介面呈現正常」等類似的結果描述是不合格的用例結果描述方式，因為結果包含的含義太寬泛，以至於用例執行人員無法判定用例執行到底是否通過，如果後續還有用例自動化的。
合格的用例，對結果的描述應當是確定並且唯一的，如「資料庫××表中××欄位的值為×××」，「頁面彈出提示資訊××××」，「跳轉到××頁面，url為http://****」。
3.與功能點同步
用例是伴隨乙個產品的某個功能點而生，因而也有它自己的生命週期。用例要隨著該部分功能點的調整而調整，隨著功能下線而下線，保持產品的用例庫同步和精簡，防止用例庫「年久失修」。這樣的用例庫一般就面臨著「推倒重建」，而這種代價，實際上比實時維護用例庫要高的多，因為重新寫用例，意味著要重新再去熟悉和學習一遍當前系統的功能。用例本身可作為學習乙個功能的入口，而非相反。
4.控制用例粒度
乙個用例所涉及的功能點應當盡可能單一。你當然可以寫乙個用例測試「系統啟動正常」，但是可能包含了1000個操作步驟和500個測試驗證點，但是這樣對用例執行人員和測試結果統計來說，就是災難。乙個用例測試了系統的全部功能，還會對用例的生命週期的維護產生很大的影響，可能別人鼓起用例去維護這個用例時，先要花半天的時間，找到更新的點在**。
測試用例（四）測試用例編寫
一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來，但它不是從乙個等價類中任選乙個例子作為代表，而是...
測試用例編寫
一 測試用例編寫準備 從配置管理員處申請軟體配置 需求規格說明書 和 設計說明書 根據需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂測試用例。二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選用少量...
測試用例編寫
一 測試 用例編寫準備 從配置管理員處申請軟體配置 需求規格說明書 和 設計說明書 根據 需求規格說明書和設計說明書，詳細理解使用者的真正需求，並且對軟體所實現的功能已經準確理解，然後著手制訂 測試用例。二 測試用例制定的原則 測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果。測試資料應該選...