由於格式的限制,這裡給一個列表。
1. 是否涵蓋了需求文件上的每個功能點
2. 是否涵蓋了需求文件上的每條業務規則說明
3. 是否覆蓋了輸入條件的各種有意義組合
4. 是否覆蓋了業務操作的基本路徑和異常路徑
5. 是否考慮了重要表單欄位的資料合法性檢查
6. 是否考慮了其他的測試型別(對某個功能很重要,但未在需求文件中提及的,如安全測試、週期性測試和故障恢復等方面)
7. 是否考慮了對其他模組/功能的影響
8. 是否使用了專案組的標準用例模板
9. 用例是否覆蓋了測試設計中定義的所有場景
10.用例編號是否統一、規範
11.用例名稱是否簡潔、明瞭
12.目的欄位是否準確地描述了對應場景的測試輸入的特徵(不同資料,操作,配置等)
13.前提條件欄位的條目是否充分、準確,操作上是否不依賴於同組之外的其他用例
14.對應的需求編號欄位是否填寫正確
15.用例粒度、預估出的執行時間是否適當
16.同組用例中,僅資料不同的,是否實現了測試步驟的重用
17.某個功能點的第一個用例是否是基本流的
18.操作步驟的描述,是否清晰、易懂
19.操作步驟是否充分和必要,並具有可操作性
20.測試用例的檢查點是否明確、充分和可操作
21.單個用例步驟或檢查點中是否不再存在分支
22.測試資料的特徵描述是否準確,有條件的情況下,是否給出了一個當前環境下的可用參考值
23.文字、語法是否準確;佈局、格式是否統一
測試用例(Test Case)是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果,以便測試某個程式路徑或核實是否滿足某個特定需求。
測試用例(Test Case)目前沒有經典的定義。比較通常的說法是:指對一項特定的軟體產品進行測試任務的描述,體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入資料、測試步驟、預期結果、測試指令碼等,並形成文件。
領測國際認為不同類別的軟體,測試用例是不同的。不同於諸如系統、工具、控制、遊戲軟體,管理軟體的使用者需求更加不統一,變化更大、更快。筆者主要從事企業管理軟體的測試。因此我們的做法是把測試資料和測試指令碼從測試用例中劃分出來。測試用例更趨於是針對軟體產品的功能、業務規則和業務處理所設計的測試方案。對軟體的每個特定功能或執行操作路徑的測試構成了一個個測試用例。