如何編寫一份優質的測試用例？

前言

這篇文章主要是想要寫給測試小伙伴們的，因為我發現還是有很多小伙伴在遇到寫測試用例的時候無從下手，我就想和大家簡單的聊聊，分享一下我的一些見解和經驗。

用例的五個構成元素：

用例標題
前置條件
測試步驟
期望結果
后置條件

下面從這五個元素的角度，去剖析如何編寫測試用例

用例標題

用例標題就是測試點名稱。用例標題是用來說明這個用例的測試目的的，好的用例標題是別人看完你這個用例標題后就知道你這個用例是測什么的。但并不是標題越詳細越好。既然是標題，就要言簡意賅，能多簡潔就多簡潔，但簡潔的同時又要能體現你的測試目的。用例的標題最好不要超過30個字，太長會讓人看起來很累也很不專業。一般可以遵循這樣的公式：主體(可省略) + 動詞 + 名詞 + 結果(可省略)(即誰做了什么有什么影響)，但很多時候是動詞 + 名詞的形式。要注意：我們寫的每一個案例對應的就是要測試的一個點。其實每個點都是用戶的一種操作行為。

前置條件

用例的前置條件就是在測這個用例之前你要先準備的環境和數據。同時，我們需要將前置條件和測試步驟區分開來，但怎么區分呢，是不是還是比較模糊？我們從用例標題入手，我們的用例標題是動作+名詞嘛，那我們的測試重點是動作，那產生這個動作之前的所需的所有環境和數據都算是前置條件，產生這個動作和這個動作帶來的后果都算是測試步驟。這樣是不是就比較清晰了。前置條件只是說明測試這個用例需要準備的環境和數據，故前置條件不用像步驟那樣寫得那么詳細，但也不能太過于簡潔，不能有歧義。

測試步驟

測試步驟是一個用例的精髓，用例標題體現測試的目的，用例步驟就是如何來測從而達到測試的目的。即然是步驟那就是一步一步的操作過程，但這個操作過程并不是寫得越詳細越好。我們的步驟是來體現我們的測試目的的，即要怎樣做什么操作，這個操作后要如何檢查產生的結果。這個操作可能是一步，也可能是幾步，也可能是來回循環。不管是什么操作都是告訴別人如何去做，如何去檢查。但步驟不能寫得過于詳細，如【登錄控制臺，打開xx頁面，點擊xx按鈕】這種就沒必要寫上去，因為這種既是浪費時間也會給用例的維護帶來成本。只需精簡明確地告訴別人在哪做什么操作即可，同時，寫案例時需要遵循一些準則規范：

用例規范

每個文件夾下不能超過10個測試用例
每個用例的步驟不能超過8步(算整個案例測試步驟，比如測試步驟和后置條件中執行1-3步)
測試用例不寫“編號”和“測試步驟名稱”
每個測試用例一個測試點，用例標題不宜過長，需要精簡明了
詳細測試需求點、測試步驟和預期結果必須體現測試目的和測試重點
測試用例中需要用到附件的，需附上文件和文件存放路徑；(附件大于1M可指定路徑）
預期結果要量化和直接化，減少用例執行的溝通成本
測試用例設計時需考慮測試執行效率，功能用例執行10分鐘原則：用例里用到的數據或樣本、腳本需要在備注里附上
“測試步驟”和“預期結果”必須可實現和可執行
測試用例需驗證客戶業務，不能只檢查配置和頁面，除非為純頁面測試
體現強關聯，去掉弱關聯；強關聯：案例中缺少此步驟就無法達到案例目的；弱關聯：案例中缺少此步驟可以達到案例目的；對于大家都知道或應該清楚的點不用體現在用例中
測試用例需要有正反對比驗證：開和關的對比、匹配和不匹配對比、輸出結果的對比等，這種用例可以合并，減少用例冗余
提示內容不用寫的太具體，說明大概意思即可，后面修改了提示需要返工用例
用例里不能有具體的版本號
模塊備注盡可能詳細，便于測試和觀察測試點
測試方法可實現，測試數據貼近于用戶環境
和其它功能、第三方之間有關聯的測試場景有沒有遺漏
標題精簡，需要體現測試目的
模塊目錄中的備注是否足夠詳細，能支撐其它人快速理解特性和提高測試效率
測試結果的檢查有沒有站在客戶的角度進行測試和驗證
頁面的測試需要覆蓋多款瀏覽器的測試
不用把所有檢查點放在一個用例上，這樣會出現執行漏測或前面失敗了后面就不執行了，問題發現滯后
若多個案例之間在步驟上就是互相覆蓋的，需要合并：如測最長字符和包含特殊字符這兩個測試點可以合并為一個案例
用例里不能出現有歧義的詞，闡述需要清晰，不能兩個人執行同樣的案例可能會產生兩種執行結果
用例需要專業性，不能出現口語化的詞語；
期望結果需要明確性，不能出現模糊的詞語；如可能、如果、符合要求等

可維護性規范

測試用例中不能出現頁面配置路徑，如：系統配置-網絡配置-網絡接口
測試用例中不能出現操作過程，比如打開XX目錄下文件，點擊什么；直接寫需做的操作即可
測試用例需用到的例行檢查點、公共檢查點、后臺、調試、配置文件等查看方法統一寫到模塊備注

期望結果

期望結果對應的是測試步驟，每一個測試步驟都對應一個期望結果，即做了這個操作后，希望它產生的后果。即大家在用例里看到的測試步驟里的1,2,3對應期望結果里的1,2,3。理論上每一個測試步驟都需要有一個對應的期望結果，但有些測試步驟我們并不關注這一步驟的操作后果，那這樣的期望結果可寫可不寫。

這里需要注意期望兩字，期望的意思是說要從用戶的角度出發，我用戶做了這個操作后，我希望它能給我反饋的結果。這個結果不是開發程序代碼返回的結果，開發程序代碼返回的結果是實際結果，執行用例時只有實際結果與用例期望結果一致時，案例才能標pass。所以在寫案例或執行案例時，得到實際結果與期望結果不一致時不要輕易被開發忽悠了，一切以用戶主。

后置條件

與前置條件對應，即執行完這個用例后需要還原環境，否則會給下個用例帶來影響。一般寫功能用例時，后置條件基本不用太關注，因為測試環境本來就需要多樣化才能模擬用戶的環境，若每次執行用例都保持一個純凈環境則帶來的測試工作量也大，而且也不能很好地體現測試環境的多樣性。后置條件一般是自動化需要做的，因為自動化需要保持環境的獨立性，彼此不依賴，執行完一個案例后需要將這個案例創建的數據、策略等全部清空，防止影響下一個案例。

如何劃分用例等級

現用例等級是怎么劃分的？

一般在一個模塊里的案例按照等級進行劃分時，遵循下面的比例：

BVT(10%)：模塊最基本的功能驗證(含常用部署、基本關聯)，推薦1級用例的20%左右
Leve1(30%)：基本需求點，基本邏輯，基本可靠性，基本關聯，基本用戶場景
Leve2(40%)：常見功能/邏輯細化點/專項細化點，常見關聯/容錯/邊界值/用戶場景
Leve3(20%)：錯誤提示，極少測試的用例，非常見部署方式/用戶場景/容錯/邊界值等

我們在劃分用例等級時，為什么要這樣劃分？

BVT的案例應該是最基本最簡單的案例，如一個功能模塊的增刪改就是最基本的；

level1是基本的功能需求基本操作相關的，如上面說的增刪改，增可能有多種增加方式，BVT只是最基本的操作，level1是對BVT的一種補充；

level2是一些內部邏輯細化點或一些常見的異常操作。Level2的異常是對用戶來是比較常見的，是很大概率上會遇到的；

level3是可能會出現但出現概率很低的一些操作或異常場景。level3的異常是很極端的異常，是很小概率會發生的，如不斷重啟之類的。

這樣劃分的意義何在？

這樣劃分是有意義的，從這個等級劃分的原則上看就知道BVT是最好執行的，然后等級越高難度系數越大，特別是level3這種，可能涉及到很復雜的網絡部署或很異常的環境構造。

不同等級的案例需要消耗的時間和帶來的影響是不一樣的。當一個模塊轉測后，我們希望的是能快速驗收這個模塊的質量，那如何驗收？不就是它的基本功能是不是完成了，它的基本操作是不是都能順暢執行，在這些基本功能基本操作都沒問題的情況下，再來檢視內部邏輯細節處理是不是到位，最后再檢視各種異常場景下的處理是不是已經合理。即從簡單到困難，先保障基本功能再檢驗其他的發散點。

?感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：