如何編寫測試用例

如何編寫測試用例

用例的五個構成元素：

1. 用例標題
2. 前置條件
3. 測試步驟
4. 指望結果
5. 後置條件

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

用例標題

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

前置條件

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

測試步驟

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

• 用例規範

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

• 可維護性規範

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

指望結果

指望結果對應的是測試步驟，每個測試步驟都對應一個指望結果，即作了這個操做後，但願它產生的後果。即你們在用例裏看到的測試步驟裏的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這種，可能涉及到很複雜的網絡部署或很異常的環境構造。

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