測試用例設計的基本原則

大家好，我是十一。

前情回顧

在沒有匹配的正交表的情況下，縮減水平匹配正交表的方法設計出來的測試用例覆蓋率更高些。

用正交表實驗法設計出來的測試用例，需要再透過邊界值、錯誤分析法等進行進一步補充。

本篇內容

前面我們用了7篇介紹了5種測試用例設計方法，分別是

等價類劃分法、邊界值分析法、因果圖法、判定表法、正交實驗法

。5種方法各有利弊，根據我多年測試經驗，綜合使用多種設計方法比使用一種設計方法更有效，設計出來的測試用例覆蓋率更高。另外，我們在設計測試用例的時候需要根據任務說明、需求說明、選定的測試策略以及自身因素來綜合考慮具體選擇哪些設計方法對當前的測試工作更有效！

分享一個有效的測試策略

接下來我為大家分享一個我認為合理有效的策略，該策略原型來源於梅爾斯的《軟體測試的藝術》，根據我的經驗做了稍微改變以及說明，供大家參考：

1.如果規格說明中包含輸入條件組合的情況。

a。如果輸入條件較少，應優先考慮因果圖分析法；

b。如果輸入條件較多，測試用例量過大，則應優先考慮正交實驗法。

2.在任何情況下都應使用邊界值分析方法。

邊界值分析可以產生一系列補充的測試條件。事實上，我們在實際工作中邊界值分析法是一個必不可少的重要的設計方法。但是缺點也顯而易見，他不能擔起測試用例設計的重任，必須與其他設計方法結合使用。

3.應為輸入和輸出確定有效和無效等價類。

a。等價類劃分法可以同邊界值分析法一樣與其他測試用例結合使用，在必要情況下對上面確認的測試用例進行補充

b。另外，為其他設計方法提供技術支援，比如：在正交表構建過程中，我們確定因素水平就會用到等價類劃分法和邊界值分析法。

4.使用錯誤推測法補充更多的測試用例。

這個方法主要是根據規範、經驗、常識等提取/增補測試用例。

5.針對上述測試用例集檢查程式的邏輯結果。

此處會用到白盒測試用例設計方法，比如：判定覆蓋、條件覆蓋、判定/條件覆蓋或者多重條件覆蓋準則。（這些設計方法我們往後放放，暫時先忽略這部分）

要注意的是:使用上述策略並不可能發現所有的錯誤，但實踐證明，這是一個有效的且合理的方案。

注意事項

另外，關於測試用例還有一些點需要大家注意。

1.一個測試用例必須包含前置條件(背景)、測試輸入、測試輸出(期望結果);

2.測試用例的粒度越小越好;粒度小的測試用例具有如下優點:

a測試用例的覆蓋邊界定義更清晰

b。測試結果對產品問題的指向性更強

c。測試用例間的耦合度最低，彼此之間的干擾也就最低

d。測試用例可讀性比較高，資訊含量越小，可讀性越高

3.測試用例必須描述簡潔清晰;

a。測試用例必須描述清晰。因為測試用例並不是給自己用的，而且測試用例大多數不是一次性的，所以我們必須要描述清晰，保證下次可用，他人可用。

b。測試用例必須簡潔。通常，我們的工作週期都是有限的，且現在迭代更新速度越來越快，所以我們在編寫測試用例的時候要注意在描述清晰的前提下，使用簡潔的語言。

4.測試用例必須要持續更新;

a。需求大多數情況不是永恆不變的，所以我們在需求發生了改變的時候或者在測試時候發現測試用例描述不準確，不完全時就要及時修改測試用例，以保障測試用例的準確性；

b。測試用例都是人工設計出來的，設計者可能對需求的理解或者功能知識點的理解存在偏差，這樣就會造成設計出來的測試用例不準確甚至不正確，這時候我們就需要有辨別是非的能力，且發現測試用例錯誤後要及時修訂，以免造成二度損失/二度浪費。

5.測試用例集合必須是一個“完備”的集合，保證需求中的每個功能點都被覆蓋到;這裡要注意的是，測試用例要覆蓋所有的功能點，而不是要做完全測試;

a。

完全測試:

對產品進行窮盡測試，把所有可能以及所有可能的組合均測試一遍

b。

覆蓋所有的功能點:

要求覆蓋需求中所有顯性功能點（需求說明書提到的）、隱性功能點（沒有提到，但是是約定俗成的或者常識性的點，比如我們在測試身份證號碼的文字框時候，需求說明書可能只會寫：合法允許儲存，不合法文字框後提示非法使用者，此處不會給出身份證號碼具體什麼是合法，什麼是非法；那麼這個點就是隱性功能點；再比如：密碼框必須是密文，很多需求中也不會強調，但是我們在測試時候一定要設計這個點的測試用例），我們可以對所有資料透過等價類劃分和邊界值分析法提取出有代表性資料來做測試即可。

6.只有在深入理解軟體需求、甚至架構設計後，我們才有可能設計出“完備”的測試用例集

；因此，我們在設計測試用例之前一定要好好研究軟體需求（對於初級測試人員來講，大家只要做好這點即可）、架構設計、實際設計等。

7.先正常再異常，且一定要對異常進行測試。

這個很重要，很多人不是忽略了異常情況，就是次序混亂，導致測試用例遺漏或者重複。

8.最最重要的一點，我們在測試用例設計之前一定要先對需求進行測試!

這個就是在需求分析、需求評審階段測試一定要參與進去，測試參與到專案的時間越早越好。

好了，今天到此結束。如有任何問題請留言及時與我溝通，我會盡快回復大家！謝謝大家~我們下次再見！