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