測試案例的優先順序別

識別小組建驗證測試用例（Build Verification Tests）：

　　為了確保小版本是可以測試的並準備好給小組其他成員開始測試，哪些測試案例是必須在每個小版本中都檢查呢？

　　(a) 將好優先順序別的測試案例分成兩組：嚴重和重要的

　　(b) 將“嚴重”的高優先順序的測試案例升級為BVT優先順序

　　注意：不要先識別BVT測試案例！BVT只是高優先順序別測試案例的精選，它們已經被確定為對系統和測試是非常重要的。

　　在這個流程的最後，就是要檢查優先順序別的百分比分布情況是：BVT為10-15%，高為20-30%,，中為40-60%，低為10-15% 。

 

在升級和降級測試案例時，需要考慮的方面是使用者將要求這個功能或功能性的頻率是怎樣。同樣的，對於使用者日常的或月尾的活動而言，這種行為的嚴重性是如何。下面提供了一個清單，可以在考慮降級或升級測試案例的時候使用

　　使用從一到五的一個刻度，從最嚴重到最少的嚴重程度，量化

可靠性風險如下：

　　(a) 這個功能的失敗將影響使用者

　　(b) 這個功能的失敗將給公司造成重大的影響

　　(c) 這個功能的失敗將引起一個潛在的延期給客戶

　　(d) 這個功能的失敗對公司將有較小的影響

　　(e) 這個功能的失敗沒有任何影響

這個和其相似的刻度可以協助設計者達到測試案例優先順序別劃分的最後一步。

　　總結

這是一個簡化的劃分測試案例優先順序別過程的例子。然而，在快速組織測試案例和安排測試進度和工作量，及制訂專案計劃時需要完成哪些測試案例等方面，會有很多協助。

首先，必須確定什麼是優先順序別的類型和其暗示著什麼。就我們的目的來說， 我們將用一個假設開始，那就是我們可能發現的缺陷的嚴重程度和那些相應測試案例的優先順序別之間是平行的。

    1 –小版本
確認測試（Build
Verification Tests
(BVTs)：也叫做“煙霧測試 (Smoke Test)”，一組想先啟動並執行以確定這個給出的小版本是否可以測試的測試案例。如果不能訪問每一個功能區域或執行其他測試案例依
賴的基本操作，那麼在執行這個優先的測試案例之前，試圖做其他任何的測試都是沒有意義的，因為他們大多數肯定要失敗。

    2 – 高（Highs）：最常執行以保證功能性是穩定的，目標的行為和能力可以正常的工作，和重要的錯誤和邊界被測試的測試案例的集合。

    3 – 中（Mediums）：這是使給出的功能區域或功能變得更詳細，檢查功能的多數方麵包括邊界，錯誤和配置測試的測試案例。

    4 – 低（Lows）：這是通常最少被執行的測試案例。但這並不意味著這些測試都不重要，只是說他們在項目的生命期間裡不是常常被運行，例如GUI，錯誤資訊，可用性，壓力和效能測試
。

　　我們將測試案例分成4類：BVTs，高，中和低。現在的問題是將測試案例分到不同的優先順序別裡。畢竟，優先順序別將指出哪些測試案例被認為是需要更頻繁的執行的，哪些又不是

 

怎樣著手分配優先順序別

　　1）隨意地分配：

基於如果沒有足夠的時間測試卻又至少要保證所有的產品需求已經被確認可以在設想的良好狀況下像它們被期望的那樣工作的想法，前面這3步將讓可以任意的分組測試案例，如果停下來思考每個測試案例的測試的內容，它們都將變的很重要。因此只需要：

　　(a)  把所有功能性驗證（或基本路徑（Happy Path））的測試標註為高優先順序別

　　(b)  把所有錯誤和邊界值或確認測試標註為中優先順序別

　　(c)  把所有非功能性的測試（例如效能和可用性）標註為低優先順序別.

  

    2）提升和降級：

　　並非所有的功能性測試都一樣的重要，並且和邊界和非功能性測試一樣的重要。思考一下測試的重要性及相對於其他同等優先順序別的測試，想要檢查這個功能的頻率－考慮品質目標和項目的需求。

　　(a) 把功能性驗證測試分為兩組：重要和不是十分重要。

　　(b) 將“不是十分重要”的能性驗證測試降級為中優先順序別

　　(c) 把錯誤和邊界測試分成兩組：重要和不是十分重要

　　(d) 將“重要”的錯誤和邊界測試升級為高優先順序別

　　(e) 把非功能性測試分成兩組：重要和不是十分重要

　　(f) 把“重要”的非功能性測試升級為中優先順序別

　　(g) 針對每組高，中和低優先順序別的測試案例，重複劃分和升級/降級流程直到達到一個點，可以在不同優先順序別之間移動的測試案例的數量到最小。