一、背景
爲保證測試用例對需求的覆蓋率，即對一個系統從整體功能到單個功能，都儘可能的高的覆蓋。而單個功能點主要強調的是不同的輸入及其組合所帶來的各種輸入動作，系統是否都做了處理；測試用例設計首先要明確該系統存在多少功能點，要通過各種常用的測試方法來保證用例的完整性，然後再對各功能點的邊界範圍進行考慮。所以要保證測試用例的設計按照一種合理的結構組織進行，這樣才能夠更有效的保證系統所有功能點的覆蓋率。
二、目的
1、規範化
爲測試用例的質量負責，使測試工作能有序、合理化的進行，從而提高實施測試時對所測產品、系統或者模塊的測試質量，也是作爲各測試人員在設計用例時的一種規範，使之設計的用例能有效的被管理，便於用例庫的維護。
2、標準化
統一用例標準，使質控團隊中每個人寫出的用例任何人都可以執行，可以維護。區分用例的所屬模塊，優先級，按需使用。並且也爲後面的自動化測試用例打下基礎。
三、用途
指導測試工作有序進行，使實施測試的數據有據可依
確保所實現的功能與客戶預期的需求相符合
完善軟件不同版本之間的重複性測試
跟蹤測試進度，確定測試重點
評估測試結果的度量標準
增強測試過程的可信任度
分析缺陷的標準
四、設計依據
產品需求文檔
視覺交互設計稿
研發技術方案
項目測試需求功能點
所屬行業的業務知識掌握程度
軟件產品的系統特性
測試工程師對需求的理解及擴展
五、用例規範
1、用例要求
用例原子性（測試用例（Test Case）是爲某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或覈實是否滿足某個特定需求）：
測試用例是執行的最小實體；
一個功能正常流程，編寫一個測試用例；
同一功能不同入口，可合併編寫一個測試用例；
一個功能中多個異常流程，應分開編寫多個測試用例；
同一功能不同數據準備，應分開編寫多個測試用例；
同一個功能用例的自動化用例和功能用例要匹配，若自動化用例不能完全覆蓋功能用例，自動化用例和功能用例拆分兩個互補測試用例；（如自動化項目暫未關聯testcase，可先不區分）
2、用例內容
【用例標題】
名稱簡潔易懂，不要包括具體操作步驟（必填）
概述用例的主要內容，明確用例意圖，最好不超過20字。我發現很多用例在標題上都寫了詳細的操作步驟，實際不太可取
如果系統中有所屬模塊有單獨選項，則模塊可不作爲標題的標籤。
【前置條件】
簡潔描述預製條件及環境要求、數據準備相關內容
執行用例測試步驟前需要做的所有必備條件，原則上所有用例都有前置條件，但一般默認環境則不用填寫；前置條件爲非測試點， 包括但不限於入口頁面、是否登錄、數據準備等。
【用例步驟】
明確寫明執行步驟（必填）
步驟中要有具體的值，類似“結果A+結果B”這種的預期結果不建議出現。描述中不允許出現假設性詞彙，比如：假如，或許，可能，…的時候等。
【期望結果】
對應執行步驟給出具體預期結果（必填）
原則上每個用例必需要有預期結果，結果不能爲空；這部分可以和用例步驟參到一起寫
【用例優先級】
寫明用例優先級便於後續用例整理，迴歸用例篩選，全功能用例篩選，挑選冒煙用例等
【關鍵詞】
是否已經實現自動化等、項目名稱、版本（便於搜索）
【附件】
數據文件、包等執行相關附件、腳本
【所屬產品】
需統一定義產品線，業務線，需產品配合定義各個業務線
【所屬模塊】
所屬產品下的產品模塊，測試自行定義所屬模塊
【相關需求】
需求的必須有用例覆蓋，需產品配合在禪道羅列具體需求（需要產品針對不同業務線給出具體明確的需求）
【用例類型】
功能、性能、安全等
【適用階段】
冒煙、功能、集成、迴歸、自動化等