測試用例設計需要注意的幾個點[摘取]
摘錄by:授客qq：1033553122
宣告：非原創，摘取自網路，取其精華
測試用例需要注意以下幾點：
1、單個用例覆蓋最小化原則
下面舉個例子來介紹，假如要測試乙個功能a，它有三個子功能點a1，
a2 和
a3，可以有下面兩種方法來設計測試用例：
方法1 ：用乙個測試用例
(確卻的說是用例的邏輯部分
)覆蓋三個子功能
-test_a1_a2_a3
，
方法2 ：用三個單獨的用例分別來覆蓋三個子功能
- test_a1
，test_a2
，test_a3
方法1適用於規模較小的工程，但凡是稍微有點兒規模和質量要求的專案，方法
2則是更好的選擇，因為它具有如下的優點：
1）測試用例的覆蓋邊界定義更清晰；
2）測試結果對產品問題的指向性更強；
3）測試用例間的耦合度最低，彼此之間的干擾也就越低
上述這些優點所能帶來直接好處是，測試用例的除錯、分析和維護成本最低。每個測試用例應該盡可能的簡單，只驗證你所要驗證的內容，不要「摟草打兔子」捎帶著把啥啥啥都帶進來，這樣只會增加測試執行階段的負擔和風險。
此外，覆蓋功能點簡單明確的測試用例，也便於組合生成新的測試。
2、單次投入成本和多次投入成本原則。
例如：第一條原則－單個用例覆蓋最小化原則- 就是乙個很好的例子，測試
a功能的
3個功能點a1，
a2和a3，從表面上看用
test_a1_a2_a3
這乙個用例在設計和自動化實現時最簡單的，但它在反覆執行階段會帶來很多的問題：
首先，這樣的用例的失敗分析相對複雜，你需要確認到底是哪乙個功能點造成了測試失敗；
其次，自動化用例的除錯更為複雜，如果是a3功能點的問題，你仍需要不斷地走過a1和
a2，然後才能到達
a3，這增加了除錯時間和複雜度；
第三，步驟多的手工測試用例增加了手工執行的不確定性，步驟多的自動化用例增加了其自動執行的失敗可能性，特別是那些基於ui自動化技術的用例；
第四，（last but not least
）將不相關功能點耦合到一起，降低了盡早發現產品回歸缺陷的可能性，這是測試工作的大忌。
例如：如果test_a1_a2_a3
是乙個自動測試用例，並按照
a1->a2->a3
的順序來執行的，當
a1存在
bug時，整個測試用例就失敗了，而a2和
a3並未被測試執行到。如果此時a1的
bug由於某些原因需要很長時間才能修復，則
test_a1_a2_a3
始終被認為是因為a1的
bug而失敗的，而a2和
a3則始終是沒有被覆蓋到，這裡存在潛在的危險和漏洞。當你在產品就要發布前終於修復了a1的
bug，並理所當然地認為
test_a1_a2_a3
應該通過時，a2和
a3的問題就會在這時爆發出來，你不得不繼續加班修復a2和
a3的問題。不是危言聳聽，當
a2/a3
的**與a1的
bug修復相關時，當你有很多如此設計的測試用例時，問題可能會更糟…
…，真的！
:(
綜上所述，test_a1_a2_a3
這樣的設計，減少地僅是一次性設計和自動化的投入，增加地卻是需要多次投入的測試執行的負擔和風險，所以需要決策時（事實上這種決策是經常發生的，尤其是在設計測試用例時）選擇
test_a1_a2_a3
還是test_a1
、test_a2
和test_a3
，請務必要考慮投入的代價。
3、使測試結果分析和除錯最簡單化原則。
這條原則是實際上是上一條- 單次投入成本和多次投入成本原則
- 針對自動化測試用例的擴充套件和延續。在編寫自動化測試**時，要重點考慮如何使得測試結果分析和測試除錯更為簡單，包括：用例日誌、除錯輔助資訊輸出等。因為測試用例的執行屬於多次投入，測試人員要經常地去分析測試結果、除錯測試用例，在這部分活動上的投入是相當可觀的。
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...
測試用例設計
1.名稱與標識 2.測試追蹤 3.用例說明 4.測試的初始化要求 5.測試的輸入 6.期望的測試結果 7.評價測試結果的準則 8.操作過程 9.前提和約束 10.測試終止條件 編寫用例規範 1 系統性 對系統業務流程要完整說明整個系統的業務需求 系統由幾個子系統組成以及它們之間的關係 對模組業務流程...
測試用例設計
測試用例格式 用例編號 a b c d a 產品或專案名稱 b 用例屬性 st,it,ut c 客戶管理 新增客戶，什麼型別的客戶 d編號 例 crm st 客戶管理 新增客戶 001 測試項 針對於某種物件的測試用例 客戶管理 新增客戶 20個字元的客戶資訊 新增名稱包含單引號的客戶資訊 用例屬性...