如何進行測試需求分析：從接收需求到用例設計

如何進行用例設計，如何讓設計好的用例覆蓋全面，將代碼存在的問題在上線前更早發現是每一個測試工程師必備的技能。那么如何達到這些指標呢？如何將用例設計既快又全面呢？今天小編就告訴大家常用設計用例的方法，以及每個方法的適用范圍，便于大家更快的選擇出最優的方法。

從需求到用例設計

在項目中我們從拿到產品需求到最后的用例設計完成，都要經歷哪些事情，包括今天要講的用例設計方法是在哪個階段使用，上面的圖會告訴你答案。

設計用例方法

1.等價類

定義：把所有可能的輸入數據,即程序的輸入域劃分成若干部分（子集）,然后從每一個子集中選取少數具有代表性的數據作為測試用例。等價類數據一般分為有效等級類和無效等級類。

構造測試用例方法：

1）明確需求

2）分析需求中包含功能數

3）確認每一個獨立功能具有多少輸入

4）確認每個輸入的規則

5）針對每個輸入設計等價類表：有效數據和無效數據。以三邊是否能組成三角形為例

6）構造測試用例：輸入和操作進行組合

2.邊界值

定義：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充。這種情況下，其測試用例來自等價類的邊界。

與等價劃分的區別:

注：上點是邊界上的點；離點是指距離上點最近的點，開區間在域內，閉區間在域外。

3.判定表

定義：判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

判定表的組成：

判定表通常由四個部分組成如下圖所示：

條件樁（Condition

Stub）：列出了問題得所有條件。通常認為列出的條件的次 序無關緊要。

動作樁（Action

Stub）：列出了問題規定可能采取的操作。這些操作的排列順 序沒有約束。

3)條件項（Condition

Entry）：列出針對它左列條件的取值。在所有可能情況下的 真假值。

4)動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。

5）規則及規則合并

A 規則

：任何一個條件組合的特定取值及其相應要執行的操作稱為規則。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列。

B 化簡 ：就是規則合并 。

a. 有完全相同的動作樁；

b. 條件樁中只有一個不同項

構造測試用例方法：

1 ）需求中 找到 條件樁：輸入參數要滿足的條件

2 ）需求中 找到 動作樁：滿足條件后得到的結果

3 ）組合所有的條件樁形成2的n次方個組合，n代表條件樁的個數

4 ）分析需求 中提到的 每一組條項樁所對應的一個或多個動作樁

5 ）查看是否可以合并， 但合并時要謹慎，因為合并后容易發生漏測

6 ）寫測試用例，每一列對應一條測試用例（不存在的結果可以忽略，因沒有數據可?。?/p>

以下 是形成 普通 三角形 的判定表 ：

4.流程分析法（場景設計）

簡介：現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。類似于白盒測試中的路徑覆蓋，通過畫流程圖分析功能的路徑。

如下圖所示，用例經過的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也可能起源于另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。

快速畫流程圖方法：

1 ）從需求 中找到 判定條件（如果，假如，當）

2 ）將這些判定框羅列到流程圖中（可以暫時不用考慮順序），注意挖掘SRS中沒有提到的隱性判定條件

3 ）先畫基本流（正常路徑），再畫備選流（分支）

構造測試用例方法：

1 ）分析業務，畫出流程圖

2 ）根據基本路徑寫基于業務場景的測試用例（用例 數= 判定條件個數+1）

5.正交試驗

簡介：把影響實驗指標的條件稱為因子。影響實驗因子的條件叫因子的狀態（水平）。利用正交試驗設計方法設計用例時,首先要從需求中找出影響其功能實現的操作對象和外部因素,把他們當作因子。而各個因子的取值當作狀態。確定因子與狀態是設計測試用例的關鍵。因此要求盡可能全面的正確的確定取值,以確保測試用例的設計作到完整與有效。

構造

測試用例方法：

1）從需求中找出因子（輸入參數）

2）從需求中找出因子狀態（輸入參數對應的取值）并編號，畫出因子狀態表

3）合并或補充因子狀態表，代入正交表

4）拆分正交表，替換成文字，一行是一條用例，以打印機功能為例，正交試驗表如下：

6.因果圖

定義 ：

是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

構造測試用例方法：

1）需求分析找出原因，然后給原因編號

2）需求分析找出結果，然后給結果編號

3）根據需求分析文檔，分析原因與結果之間的關系

4）根據需求分析文檔，分析原因與原因之間的關系

5）根據需求分析文檔，分析結果與結果之間的關系

6）根據需求分析文檔，畫因果圖

7）依據因果圖去除判定表中不存在的組合

8）判定表中每一列對應一條測試用例

7.輸入域覆蓋

簡介

： 輸入 的數據包含一些 易 引出內存溢出和內存泄露（區別，定義）的 類型邊界 ， 或者一些特殊 值

如電話號碼等。

構造測試用例方法：

1 ）SRS分析對應的輸入參數是否存在特殊值和類型邊界

2 ）若存在，則補充特殊值和類型邊界的測試數據（檢查是否會出現內存溢出）

8.輸出域覆蓋

簡介：分析輸出結果的形式（提示信息，輸出的顯示結果，數據庫的記錄等）

構造測試用例方法：

1 ）通過與開發的溝通，明確對應功能所有可能的輸出結果有哪些

2 ）逐一羅列（輸出的形式主要針對提示信息和顯示結果）

3 ）檢查對照現有測試用例是否已經覆蓋了所有的輸出

4）若沒有完全覆蓋，則根據輸出結果要求，倒推補充測試用例

9.異常分析

定義：基于經驗和直覺推測程序中所有可能存在的各種錯誤,

從而有針對性 的設計測試用例的方法

基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例。如網絡異常、斷電、服務器宕機等

構造測試用例方法：

1）根據需求分析文檔，構造環境異常（網絡、電源、服務器、程序關閉）

2）補充異常測試用例

適用范圍

通過上述的介紹，設計用例的方法這么多，如何選擇使用哪種方法呢？文章開篇中的流程圖，處理過程為什么用流程分析而不用狀態遷移法呢？下面小編總結了各種方法的優缺點以及適用范圍，希望可以幫助大家。

我們在實際工作中，可能一個功能會存在多種情況，所以大家要靈活使用方法，必要時設計用例方法要進行組合使用，設計出的用例才能更全面。一般情況下，一份用例最少用到2種以上方法才能全面覆蓋測試點。

原文轉自：www.uml.org.cn/Test/201906171.asp