測試用例設計需要注意的幾個點

測試用例需要注意以下幾點：

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、使測試結果分析和除錯最簡單化原則。

這條原則是實際上是上一條- 單次投入成本和多次投入成本原則 - 針對自動化測試用例的擴充套件和延續。在編寫自動化測試**時，要重點考慮如何使得測試結果分析和測試除錯更為簡單，包括：用例日誌、除錯輔助資訊輸出等。因為測試用例的執行屬於多次投入，測試人員要經常地去分析測試結果、除錯測試用例，在這部分活動上的投入是相當可觀的。

測試思想 測試設計 測試用例設計需要注意的幾個點

測試用例設計需要注意的幾個點 摘取 摘錄by 授客qq 1033553122宣告 非原創，摘取自網路，取其精華測試用例需要注意以下幾點 1 單個用例覆蓋最小化原則下面舉個例子來介紹，假如要測試乙個功能 a，它有三個子功能點a1，a2 和 a3，可以有下面兩種方法來設計測試用例 方法 1 用乙個測試用...

測試用例設計注意點

1 單個用例覆蓋最小化原則 舉個例子，假如測試乙個功能a，它有三個子功能點a1 a2和a3，可以有如下兩種用例設計方法 方法1 用乙個測試用例 主要指用例的邏輯部分 覆蓋三個子功能 test a1 a2 a3 方法2 用三個單獨的用例分別來覆蓋三個子功能 test a1,test a2,test a...

Masonry需要注意的幾個點

masonry不常用到的方法 關於mas key masonry中用來標記view的key值 a key to associate with this view 通過runtime在view中新增的屬性。在沒有定義mas key時，發生約束衝突，後台報的錯誤資訊 當定義mas key後，發生約束衝突...