一、目的
- 統一測試用例編寫的規范，提高編寫測試用例的可讀性、可執行性；
- 提升測試用例的編寫效率
二、測試用例梳理要求
- 控制測試用例粒度的要求：
- 測試用例標題不要超過30個漢字
- 測試步驟不要多於7步，不要少於2步
- 測試預期結果不要多於5個，不要少於1個
- 測試用例必含要素：模塊名、用例名稱、前置條件（選填）、操作步驟、預期結果、優先級
- 測試用例划分：
- 基本原則：最小功能模塊來划分，保障用例的覆蓋度。
- 用例分類：P0用例、完整用例
- p0測試用例：系統基本功能及主要功能的測試用例，單獨對P0用例梳理放入畫布。
- 完整的測試用例：按照模塊進行划分梳理即可。
- 規范編寫要求：
- 一個功能正常流程，編寫一個測試用例；
- 一個功能中多個異常流程，分開編寫多個測試用例；
- 同一功能不同入口，可合並編寫一個測試用例；
- 同一功能不同數據准備，分開編寫多個測試用例；
- 操作步驟與預期結果要相對應。
三、測試用例評審
- 評審步驟：中心內部評審——>項目組評審
- 發起人：用例設計者
- 參與人：測試負責人，項目經理、開發人員及產品經理
- 要求：評審過程中，重點關注參與人提出的建議，完善自己的測試用例，去掉冗余的，修改和場景不符的，評審結束后，測試用例設計者需在km上填寫用例評審會議紀要；
- 會議紀要：
會議紀要需包含：會議名稱，會議地點、會議時間、會議參與人員（新建時選擇模板），會議中溝通梳理問題，會議中未確認或者需跟進的問題；
跟進方式：會議記錄中@對應的處理人員，測試人員負責跟進；
四、測試用例完善
- 測試用例在迭代結束后必須更新，在測試過程中發現設計的測試用例時考慮不周或遺漏，需要不斷的進行補充和完善;
- 模塊更新后，需根據版本需求完善checklist文檔，按照模塊分類上傳到雲盤中，然后需要同步到中心群；
- 同步事項：
修改的信息，修改前和修改后的區別；
將修改的用例和用例存放的地址（截圖或鏈接地址），同步到項目組的群中。
五、測試用例設計方法
主要包括功能測試、界面測試、兼容性測試、易用性測試、異常測試、性能測試、壓力測試等，在設計用例時要盡量考慮錄入正常、邊界、異常值等系統的處理情況。（備注：此類作為測試基礎，不太清楚的請自行百度）
六測試用例設計的原則（此處內容網上較多，自行查找）
- 正確性測試：輸入用戶實際數據以驗證系統是滿足需求的要求；測試用例中的測試點應首先保證要至少覆蓋需求中的各項功能，並且正常。
例如：登錄功能：輸入正確的賬號和密碼
- 容錯性（健壯性）測試：系統能夠接收正確數據輸入並且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），能給出提示 並進行相應處理。把自己想象成一名對產品操作一點也不懂的用戶，在進行任意操作。
例如：登錄功能，輸入正確的賬號和密碼，登錄成功。輸入錯誤的賬號或者密碼，給出對應的提示信息（提示請輸入正確的手機號碼或密碼錯誤）；
- 邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。
例如: 測試登錄功能時，登錄賬號考慮大於8/11位數的手機號碼；小於8/11位的手機號碼、等於8/11位的手機號碼等場景；
- 等價划分：將所有可能的輸入數據（有效的和無效的）划分成若干個等價類。
例如：登錄賬號：香港號碼、澳門號碼、大陸號碼、空的賬號、未注冊的手機號碼等；
- 錯誤推測：主要是根據測試經驗和直覺，參照以往的系統出現錯誤之處。
- 可理解（操作）性：理解和使用該系統的難易程度（界面友好性）。
例如:引導頁、頁面的提示文案等；
- 回歸測試：按照測試用例將所有的測試點測試完畢，測試中發現的問題開發人員 已經解決，進行下一輪的測試。
- 接口測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。
例如：接口的參數必傳非必傳、參數類型、入參長度；
- 兼容性測試：操作系統的兼容性測試內容不僅包括軟件的安裝，還需對關鍵流程和功能點進行檢查。而需要測試哪些操作系統的兼容性，首先取決於軟件需求上對用戶的承諾，其次就需要對一些常用操作系統兼容的檢查
例如：版本升級的兼容、手機系統的兼容、系統之間的版本兼容、系統類型的兼容