參考文章：https://www.cnblogs.com/cheneyboon/p/11339795.html
https://wenku.baidu.com/view/f28003335f0e7cd1842536b0.html
http://www.51testing.com/html/27/n-848427.html
https://www.iteye.com/blog/onemonth-2005790
1.測試用例的模板
| 測試用例編號 | 用例名稱 | 用例說明 | 前置條件 | 預置輸入 | 執行步驟 | 優先級/重要程度 | 預期結果 | 實際結果 |
2.標題解釋
測試用例編號：編號具有唯一性、易識別性，由數字和字符組合成的字符串，如你可以簡單的用1做開始依次遞增。
規則：系統測試用例：產品編號-ST-系統測試項名-系統測試子項名-XXX。
集成測試用例：產品編號-IT-集成測試項名-集成測試子項名-XXX。
單元測試用例：產品編號-UT-單元測試項名-單元測試子項名-XXX。
用例名稱：測試用例的概括，簡單的描述用例的出發點，關注點，原則上不能重復。
用例說明：描述當前所測試的功能點。
前置條件：執行當前測試用例需要的前提條件，是后續步驟的先決條件。如:登錄賬號時，前置條件就是賬號已注冊。
預置輸入：輸入測試的數據，如登錄的賬戶名及密碼。
測試步驟：1）要有條有理，一般分1，2，3步驟來寫；
2）需要在步驟中描述操作環境等信息；
3）詳細描述測試過程，言簡意賅。
優先級（重要程度）：高：保證系統基本功能、核心業務、重要特性、實際使用頻率高的測試用例；
中：重要程度介於高和低之間的測試用例；
低：實際使用頻率不高、對系統業務功能影響不大的模塊或功能的測試用例。
預期結果：應該出現的結果，使用錯誤的賬號登錄，應填寫的結果為提示使用正確的賬號密碼登錄。
實際結果：實際出現的結果，上例中如果輸出的是登錄成功，那么填寫登錄成功，即使使用的錯誤的賬號，實際軟件提示的結果。
3.實例
| 測試用例編號 | 用例名稱 | 用例說明 | 前置條件 | 預置輸入 | 執行步驟 | 優先級/重要程度 | 預期結果 | 實際結果 |
| HJWZ-ST-DL001-001 | 登錄功能 | 界面文字顯示正確性驗證 | 登錄頁面打開正常 | 無 | 點擊登錄鏈接或按鈕 | 低 | 1.界面文字顯示正確，無錯別字 2.表單，按鈕正常顯示，無重疊，可點擊 |
與預期結果相同 |
4.測試用例的優先級
4.1 划分等級
P0： 核心功能測試用例（冒煙測試BVT），BVT也成為冒煙測試用例集。是每次測試開始allin投入前最希望被運行得以確認的測試用例集，此部分測試用例如果fail會阻礙大部分其他測試用例的驗證。
P1： 高優先級測試用例，最常執行以保證功能性是穩定的；基本功能測試，重要功能測試，和重要的錯誤、邊界測試。
舉例：web信息系統中的各種增刪查改功能，登錄功能，權限管理，用戶管理等核心功能。
P2： 中優先級測試用例，更全面的驗證功能的各個方面，異常測試，邊界、中斷、斷網、容錯、UI等測試用例。
P3： 低優先級測試用例，不常常被執行，性能、壓力、兼容性、穩定性、安全、可用性等等。
4.2 划分原則
1.使用頻率或失效的概率：
系統的某些特定的被經常使用的功能優先級更高（若該功能包含了故障，其在被頻繁使用而導致的概率將會很高，故該功能的用例具有更高的優先級）。
2.失效的風險
高風險失效的用例應該比低風險失效的用例具有更高的優先級（用戶或客戶在使用時，高風險失效導致的后果和造成的損失將更加嚴重）。
3.失效的可見性
失效對用戶的可見性，是划分測試優先級的更進一步准則（尤其在交互系統中，用戶可減的失效，例如：界面錯誤，會導致用戶對產品的極度不信任）。
4.需求的優先級
系統對使用的用戶來說，各個功能的重要性不同，某些不重要的功能對用戶來說缺失該功能是致命的，但是有些功能，即使缺失，用戶也是可以接受的。
5.質量特性
質量特性對用戶也有不同的重要性，因此驗證與重要質量特性是否一致的用例具有更高的優先級。
6.開發人員角度
能夠導致系統或組件崩潰的測試用例具有更高的優先級。
7.測試對象的復雜性
復雜的程序的組件需要加強測試，因為開發人員可能在該位置引入更多的缺陷；但不是說簡單的程序組件就可以忽視，該部分缺陷往往由於開發人員的粗心導致。
8.高項目風險的失效
存在高項目風險的缺陷應該盡早被發現（該類失效會導致大量的修正工作，並導致項目時間的明顯延遲）。
9.缺陷的集群效應
在先前發現缺陷的位置可能會存在更多的缺陷。
4.3 划分方法（轉自網絡，如有侵權，請告知）
第一步：隨意分配
I)把你所有功能性驗證（或基本路徑（Happy Path））的測試標注為高優先級別。
II)把你所有錯誤和邊界值或確認測試標注為中優先級別。
III)把你所有非功能性的測試（例如性能和可用性）標注為低優先級別。
第二步：提升和降級
並非所有的功能性測試都一樣的重要，並且和邊界和非功能性測試一樣的重要。思考一下測試的重要性及相對於其他同等優先級別的測試，你想要檢查這個功能的頻率，考慮質量目標和你項目的需求。
I)把功能性驗證測試分為兩組：重要和不是十分重要。
II)將“不是十分重要”的能性驗證測試降級為中優先級別。
III)把錯誤和邊界測試分成兩組：重要和不是十分重要。
IV)將“重要”的錯誤和邊界測試升級為高優先級別。
V)把非功能性測試分成兩組：重要和不是十分重要。
VI)把“重要”的非功能性測試升級為中優先級別。
VII)針對每組高，中和低優先級別的測試用例，重復划分和升級/降級流程直到你達到一個點，可以在不同優先級別之間移動的測試用例的數量到最小。
在這個流程的最后，就是要檢查優先級別的百分比分布情況是：高為20-30%,，中為40-60%，低為10-15% 。
在升級和降級測試用例時，需要考慮的方面是用戶將要求這個功能或功能性的頻率是怎樣。同樣的，對於用戶日常的或月尾的活動而言，這種行為的嚴重性是如何。Robyn Brilliant在測試進度報告中提供了一個清單，你可以在考慮降級或升級測試用例的時候使用
使用從一到五的一個刻度，從最嚴重到最少的嚴重程度，量化可靠性風險如下：
I)這個功能的失敗將影響用戶。
II)這個功能的失敗將給公司造成重大的影響
III)這個功能的失敗將引起一個潛在的延期給客戶
IV)這個功能的失敗對公司將有較小的影響
V)這個功能的失敗沒有任何影響
這個和其相似的刻度可以幫助你達到你測試用例優先級別划分的最后一步。
總結：
這是一個簡化的划分測試用例優先級別過程的例子。然而，在快速組織測試用例和安排測試進度和工作量，及制訂項目計划時需要完成哪些測試用例等方面，它可以給你很多幫助。
記住，你怎樣給你的測試任務划分優先級和如何執行測試用例將取決於你在你的項目周期的位置。當你朝發布前進並通過調查和觀察確定危險和缺陷出現的地方時，你可能會重新給你的測試用例划分優先級別。向上為每個階段建立你的測試目標並保證他們在你的測試用例的優先級別上被反映，當它在解釋並執行你的計划時，將使你的生活變得容易得多。
最后，擁有划分了優先級別的測試用例也為你潛在的，待定的自動化項目給出了一個好的起點。比如，自動化中的測試用例，度量收益，改進測試自動化，自動化高優先級的測試用例等方面。