設計測試用例的小禁忌

最近在組織團隊成員設計產品的測試用例。在評審了大量用例後，有些感悟，想記錄下來。

設計測試用例就好比程序員編寫代碼。程序員講究的是代碼是否有很高的可讀性、邏輯是否完整無漏洞。測試人員也一樣，也需要講究用例是否有很好的可讀性，邏輯是否完整清晰。

那麼如何設計出完美的測試用例呢？設計用例過程中有哪些小禁忌呢？我想把自己的感悟記錄下來，希望能時刻提醒自己，並分享給想要進步的你。

禁忌1. 設計的用例邏輯性差

一個模塊，若干個測試點需要用幾十甚至上百條用例來全面覆蓋到。邏輯性差的用例，瀏覽完這若干條用例後，給人的感覺是想到了什麼測試點就寫了什麼，並不能很快總結出哪些測試點未覆蓋到。因為整個瀏覽的過程你的思維是緊跟著設計者走的，設計者思路不清晰，讀者也會沒有頭緒。而邏輯性強的用例，閱讀時你能馬上找到設計者是思維過程，條例清晰，知道他在設計用例時思考的順序是什麼。這點不光對評審用例者、閱讀用例者幫助很大，對設計用例人員來說，也能更全面的覆蓋測試點，減少遺漏點的發生。

禁忌2. 用例標題概括性不足

標題可以說是整條用例的核心。它告訴了閱讀者這條用例的測試點是什麼，設計目的是什麼。甚至熟悉該產品的人，不需要看用例的步驟就知道如何執行這條用例。但是在評審用例時，發現了大量的用例，存在標題概括性不足，甚至標題和步驟中的測試點並不匹配的情況。比如一個用例中包括了測試點A1、A2、A3，但標題中只能體現出A1，甚至B1。

禁忌3.用例設計不合理

這個屬於進階一級的要求了。用例標題準備，思路清晰且覆蓋了全部的測試點，這就已經達到了標準。如果你想高要求，讓你的用例更完美，就需要考慮如何設計你的用例才更合理，可執行性更高，效率更高。比如功能A，有3個測試點A1、A2、A3，但執行時，想要測試A3，所包含的必經步驟就一定會完成A2。你可以設計3條用例分別對應A1、A2、A3。但更好的方式一定是設計2條用例A1和A2_A3。這樣設計，提高了執行用例者的工作效率。尤其是一些太基礎的測試點，沒必要單獨設計成一條用例，如下拉框中有值，下拉框中的值可以被選擇這些。

當然如果是自動化測試用例，有可能就另當別論了。因為A2_A3這樣的用例，在執行自動化測試時，會造成失敗分析相對複雜。你不能直觀的判斷是A2出錯還是A3出錯。

總之，還是要在工作中，用例設計中多思考多總結。不是說工作了很多年就一定會設計的很好，善於總結的人一般會做的更出色！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！