用例的五個構成元素：

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這種，可能涉及到很複雜的網路部署或很異常的環境構造。

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