作者：京東物流 王玉坤
軟體測試設計是測試過程中重要的測試活動，怎麼樣設計測試用例能提高我們測試的效率和質量，從以下幾個方面做了簡單的講解。
1 測試用例設計原則
測試用例設計的基本原則包括：有效性、清晰性、可複用性、可維護性、完整性、相容性、易操作性、可管理性、可評估性
- 有效性:測試用例步驟必須描述清晰，不能出現模稜兩可的以及重複的話語，測試用例應該按照一定的順序進行編寫，這樣執行的時候效率比較高。
- 清晰性:用例的操作步驟要描述清晰，包含清晰的輸入資料以及預期輸出，驗證點必須明確清晰，並能突出重點，對於流程性的用例建議按照流程順序進行用例安排，從第一個驗證點到最後一個驗證點，組成流程的開始到結束，方便測試執行。 測試用例包含前置條件的必須將前置條件描述清楚，包括入口等。
- 可複用性:可重複使用，並儘量將具有相似功能的測試用例抽象並歸類。
- 可維護性:測試用例因為業務需求發生變更的時候，需要及時更新維護測試用例，做到測試用例的實時性與有效性，測試用例需要細化和不斷的完善，是個循序漸進的過程。
- 完整性:用例是否完成並覆蓋所有需求點，做到對需求的完全理解。
- 相容性:測試用例要包含新老版本的相容、新老資料相容、瀏覽器相容等測試點。
- 可管理性:能夠檢測測試人員的測試進度、工作量等。
- 可評估性:測試用例的透過率和缺陷的數目是評估軟體質量的好壞的標準。
2 測試用例的生命週期
軟體測試用例的設計階段包含：需求分析、測試用例設計、測試用例實現、測試用例執行、測試用例管理
2.1 需求分析
測試用例過程的第一步是確定測什麼，標識出測試點，並且對測試點進行優先順序的劃分。
2.2 測試用例設計
測試用例設計確定瞭如何來測試已經分析出的測試點。
測試設計的主要點是確定測試預期結果。為了確定測試預期結果，測試人員不僅需要關注測試輸出，同時也需要注意測試資料和測試環境的前後置條件。假如測試用例沒有測試的預期結果，則測試用例對於測試結果的對錯判斷是毫無意義的。
測試預期結果可以是各種各樣的，包括需要建立或者輸出的結果，也可以是需要更新或者變更的結果，也可以是刪除的結果。每個測試用例都應該清楚的描述測試的預期結果。這樣，就需要測試人員具有被測系統相關的豐富的知識和經驗，才可能對軟體系統的測試輸出作出正確的評估。假如測試輸出結果評估認為是正確的，那麼就可以作為測試用例的期望輸出結果。
2.3 測試用例實現
測試用例實現的過程包括準備測試指令碼、測試輸入、測試資料以及預期結果等。測試指令碼指的是按照標準的語法組織資料或者指令。測試執行之前，首先必須滿足測試前置條件，比如一個測試用例需要用到配置好的一些資料，那麼這個資料就必須提前建立等。
2.4 測試用例執行
透過執行測試用例來對被測系統進行測試。對於手動測試來說，主要參照測試用例的步驟來進行測試執行，比較預期結果和實際結果、並記錄測試過程中發現的問題。
對於自動化測試過程，執行時需要藉助測試工具，執行測試用例指令碼等，記錄測試結果。
執行測試時如實際結果和預期結果是一樣的，則認為是透過的，如果不一樣，那用例執行失敗，或存在問題，對於用例執行失敗，需要進一步的檢查，確定是軟體問題還是用例的預期結果有問題，或者是資料問題，環境問題引起的，需要從不同的方面進行問題分析。
2.5 測試用例管理
1）測試用例組織
每一個專案，其測試用例的數目都非常多。如何來組織、跟蹤和維護測試用例是一件非常重要的事情。如何來組織測試用例，是測試成功與否的一個重要因素，也是提高測試效率的一個重要步驟。
測試用例的組織，可以用不同的方法來進行組織或者分類：
- 按照軟體功能模組組織：軟體系統一般是根據軟體的功能模組來進行工作任務分配的。因此，根據軟體功能模組進行測試用例設計和執行等是很常用的一種方法。根據模組來組織測試用例，可以保證測試用例能夠覆蓋每個系統模組，達到較好的模組測試覆蓋率。
- 按照測試用例優先順序組織：測試用例是有優先順序的。對於任何軟體，實現窮盡測試是不現實的。在有限的資源和時間內，首先應該執行優先順序高的測試用例。
按照功能模組進行劃分是最常用的，我們也可以結合起來使用，比如在按照功能模組劃分的基礎上，再進行不同優先順序的劃分。
2）測試用例跟蹤
測試用例的跟蹤主要是針對測試執行過程中測試用例的狀態來進行的，透過測試狀態的跟蹤和管理，從而實現測試過程和測試有效性的管理和評估。
- 測試用例執行的跟蹤：在測試執行的過程中，對測試用例的狀態進行跟蹤，可以有效的將測試過程量化。比如，執行一輪測試過程中，測試的測試用例數目是多少，測試用例中透過、未透過、未測試的比例各是多少。這些資料可以提供一些資訊來判斷軟體專案執行的質量和執行進度，並對測試進度、狀態提供明確的資料，有利於測試進度和測試重點的控制。
3）測試用例維護
測試用例並不是一成不變的，當一個階段測試過程結束後，會發現一些測試用例編寫的不合理，或者需求發生了變化，這都需要對當前的一些測試用例進行修改和更新，從而使測試用例具有可複用性。
3 測試用例編寫要素
- 用例編號：用例的唯一標識
- 測試模組：測試用例所屬模組
- 用例標題：測試用例的簡要說明
- 前提條件：用例執行的前提
- 測試步驟：執行用例步驟
- 預期結果：應該得到的結果
- 優先順序：用例重要程度
4 功能測試用例設計方法
4.1 等價類劃分法
等價類劃分法的定義
- 輸入具有代表性的資料子集
等價類劃分法分類
- 有效等價類：滿足需求的
- 無效等價類：不滿足需求的
適用範圍
- 具有單個輸入的功能
步驟
- 明確需求
- 確定有效和無效等價類
- 編寫測試用例
舉例
需求：下單若是函速達，需要允許快遞員修改，且限定包裹數必須為1，重量要<0.5kg。
4.2 邊界值分析法
邊界值的定義
- 對於輸入等價類和輸出等價類而言稍高於其邊界或者稍低於其邊界的一些特定情況
邊界值範圍
- 正好等於
- 剛剛好大於
- 剛剛好小於
邊界值分析法中的三個點
- 上點：邊界上的點
- 離點：距離邊界最近的點
- 內點：範圍內的點
舉例：1-100 ，上點：1 100 離點：0 99 2 101 內點：50
適用範圍
- 有輸入引數，且輸入型別或範圍長度有邊界時（適用於題目需求中有長度或者範圍的情況）
- 和等價類一起使用，適用於單個功能的輸入的情況
步驟
- 明確需求
- 確定有效和無效等價類
- 明確題目條件中的邊界值
- 編寫測試用例
舉例
4.3 判定表法
適用條件
- 判定表表示的是有多個輸入和多個輸出，而且輸入與輸入之間相互的組合關係，輸入和輸出之間有相互的制約和依賴關係
組成部分
- 條件樁：題目條件中的所有的測試輸入
- 動作樁：題目條件中的所有輸出
- 條件項：測試輸入的取值
- 動作項：測試輸出的取值
步驟
- 明確條件樁
- 明確動作樁
- 對條件樁進行全組合
- 明確每個組合對應的動作樁
- 設計測試用例
舉例
4.4 因果圖法
因果圖法定義
- 理論中是通向判定表的一箇中間過程
適用範圍
- 因果圖是一種利用圖解法來分析輸入的各種組合情況，從而設計測試用例的方法，它適用於檢查程式輸入條件的各種組合情況
因果圖法的核心
- 所謂的原因就是輸入，所謂的結果就是輸出。
- 因果圖的因 —輸入條件
- 因果圖的果 -輸入結果
因果圖基本符號
關係
- 恆等：若Ci是1，則ei也是1；否則ei是0
- 非：若ci是1，則ei是0；否則ei是1
- 或：若c1或c2或c3是1，則ei是1；否則ei是0
- 與：若c1和c2都是1，則ei是1；否則ei是0
步驟
- 標識輸入和輸出
- 畫出因果圖
- 將因果圖轉換為判定表
- 生成測試用例
舉例
需求：某軟體規格說明書包含這樣的要求：第一列字元必須是A或B，第二列字元必須是一個數字，在此情況下進行檔案的修改，但如果第一列字元不正確，則給出資訊L；如果第二列字元不是數字，則給出資訊M。
轉化為判定表
最終轉化為測試用例。
4.5 正交分析法
定義
- 正交法又叫正交試驗法，又叫正交排列法，使用最小的測試過程集合獲得最大的測試覆蓋率，（測試用例的條數寫的少一點，而測出的bug多一點），正交試驗設計法，是從大量的試驗點中挑選出適量的，有代表性的點，應用依據伽羅瓦理論匯出的“正交表”，合理安排試驗的一種科學的試驗設計方法。
正交表的概念：一種特製的表，一般的正交表標記為Ln（mk）
- n表示行數，也就是需要測試組合的次數
- k表示的列數，表示控制元件的個數（因素的個數，或是因子的個數）
- m是每個控制元件包含的取值個數（各因素的水平數，即各因素的狀態數）
如：L9( 34 )
有4個控制元件
每個控制元件有3個取值
9為需要測試的組合個數、有9條測試用例
叫4因素3水平
步驟
- 根據需求形成因子狀態表—-因子：控制元件名稱 狀態：每個控制元件對應的取值
- 確定所採用的正交表
- 將正交表中的數字用文字代替
- 一行就是一條測試用例
舉例
注意
如果各個因子的狀態數是不統一的，幾乎不可能出現均勻的情況時，選擇正交表為 等於或略大於因子數，狀態數，且試驗次數最少
生成正交試驗表的一些方法
線上生成：https://jaccz.github.io/pairwise/tools.html
輸入每個控制元件和控制元件的取值
生成的表
正交試驗的例項表可套用到用例中http://www.york.ac.uk/depts/maths/tables/orthogonal.htm
正交試驗的例項表可套用到用例中http://support.sas.com/techsup/technote/ts723_Designs.txt
4.6 場景法-流程圖法
定義
- 模擬使用者操作時的場景，主要用於測試多個功能之間的組合使用情況
為什麼要使用者場景法
- 使用者角度：使用者平時使用的不是單個功能，而是多個功能組合起來進行使用
- 測試人員角度：平時測試的都是單個功能點進行測試，為了保證測試的全面性，考慮多個功能之間組合測試的場景
場景法的適用範圍
- 多個功能之間的組合測試
- 往往在冒煙測試時經常使用
場景法中兩個重要的概念
- 基本流：按照正確的業務流程操作的一種路徑
- 備選流：出現錯誤的操作流程
步驟
- 確定專案角色
- 明確角色的常用功能
- 根據需求構建測試場景
- 一個場景就是一條case
5 安全性測試設計
安全測試是在軟體產品開發基本完成時，驗證產品是否符合安全需求定義和產品質量標準的過程。安全測試是檢查系統對非法侵入滲透的防範能力。
包含的測試點如下：
- sql注入
- 明文傳輸
- 越權訪問
- 簡訊郵箱驗證
- 鑑權缺失
- 密碼安全
- 資料健壯性等