目錄

測試用例

1. 概念

1.1 什么是測試用例

1.2 什么是要素

1.3 為什么需要測試用例

2. 設計測試用例的萬能公式

2.1 常規思維 + 逆向思維 + 發散性思維

2.2 萬能公式

3. 設計測試用例的方法

3.1 基于需求的設計方法?

3.2 具體的設計方法

3.3 更多用例練習

---

測試用例

1. 概念

1.1 什么是測試用例

// 測試用例 (Test Case) 是為了實施測試而被測試的系統提供的一組集合, 這組集合包含: 測試環境, 測試步驟, 測試數據, 預期結果等要素

1.2 什么是要素

// 我們在編寫測試用例的時候, 每個用例需要給出這些要素對應的信息

// 要素包括: 用例編號, 標題, 測試方式, 功能模塊, 重要性, 測試前提, 測試環境, 測試數據, 測試步驟, 期望結果等

1.3 為什么需要測試用例

1.3.1 測試中可能會遇到很多問題, 測試用例的出現急速解決這些問題, 例如:

// 不知道是否較全面的測試了所有功能

// 測試的覆蓋率無法衡量

// 對新版本的重復測試很難實施

// 存在大量冗余測試影響測試效率

1.3.2 測試用例還可以避免測試人員被迫背鍋?

2. 設計測試用例的萬能公式

// 例如: 現在有一款產品, 要求我們對 "門鎖" 設計測試用例

// 測試用例的設計, 最重要的一點就是保證功能是正確的

2.1 常規思維 + 逆向思維 + 發散性思維

// 正確設計測試用例的思想:?常規思維 + 逆向思維 + 發散性思維

// 設計測試用例的原則二 :

2.1.1 測試用例的編寫不僅應當根據有效和預料到的輸入情況, 而且也應該根據無效和未預料到的輸入情況

2.1.2 檢查程序是否 "未做其應該做的" 僅是成功的一半, 測試的另一半是檢查程序是否 "做了其不應該做的"

2.1.3 計劃測試工作時不應默許假定不會發生錯誤

2.2 萬能公式

// 設計測試用例的萬能公式:

// 功能測試?+ 界面測試 + 性能測試 + 兼容性測試 + 易用性測試 + 安全測試

2.2.1 功能測試

// 功能測試時一個試圖發現程序與其外部規則說明之間存在不一致的過程

// 從產品功能角度出發, 驗證功能是否是正確的

2.2.2 界面測試

// 對軟件界面上所有的內容都需要進行測試

// 界面涉及到的內容: 元素 (大小, 顏色, 形狀, 材質)

// 要求: 整體界面測試界面的實現與設計圖要求一致, 界面元素測試

2.2.3 性能測試

// 性能測試和功能測試的區別是: 功能測試檢查軟件是否做了, 性能測試測試軟件做的好不好

// 通常為一些極端的情況驗證功能是否是正常的

2.2.4 兼容性測試

// 軟件是部署在硬件系統之上, 并依賴所需的軟件環境. 軟件是否能夠在不同環境下正確運行需要測試人員進行驗證

// 選取標準: 優先選擇使用當前產品 top 級別的機型進行測試; 選擇主流的瀏覽器/機型進行測試

2.2.5 易用性測試

// 易用性測試的標準是檢查產品是否具備簡單易上手的屬性

2.2.6 安全測試

// 安全測試和性能測試一樣都是比較大的領域

// 常見的安全問題: 隱私數據明文顯示; 參數未強校驗導致 SQL 注入; 越權: 普通用戶也可以執行管理員權限的操作

// 除了萬能公式外, 還有一個比較常用的測試類型: 弱網測試, 安裝卸載測試

// 弱網測試: 主要是為了盡可能保證用戶體驗

// 借助抓包工具來模擬實現弱網測試 (fiddle, charles)

// 安裝卸載測試: 針對需要部署的軟件, 除了軟件功能外, 我們還需要關注軟件的能夠成功完成安裝和卸載

// 安裝: 安裝包是否可以安裝, 卸載之后是否可以繼續安裝, 重復安裝...

// 卸載: 安裝完成后卸載, 安裝一半后卸載, 卸載一次后繼續安裝繼續卸載

// 測試接口: URL, 請求參數, 請求方法, 響應

3. 設計測試用例的方法

// 以下都是針對黑盒測試用例設計的測試方法

3.1 基于需求的設計方法?

// 分為: 功能相關和非功能相關

// 基于新需求的設計方法也是總的設計測試用例的方法, 在工作中, 我們需要參考需求文檔/產品規格說明書來設計測試用例

// 測試人員街道需求之后, 要對需求進行分析和驗證, 從合理的需求中進一步分析細化需求, 從細化的需求中找到測試點.?

3.1.1 明確需求中的功能點

3.1.2 結合萬能公式設計測試點

3.2 具體的設計方法

3.2.1 等價類

// 依據需求將輸入劃分為若干個等價類, 從等價類中選出一個測試用例, 如果這個測試用例測試通過, 則認為所代表的等價類測試通過, 這樣就可以用較少的測試用例達到盡量多的功能覆蓋, 解決了不能窮舉測試的問題

// 等價類分為: 有效等價類; 無效等價類

// 有效等價類: 滿足用戶需求的數據集合

// 無效等價類: 不滿足用戶需求的數據集合

// 如何通過等價類的方法設計測試用例: 1. 充分理解需求; 2. 劃分出有效等價類和無效等價類; 3. 從有效等價類中抽取一個測試用例測試, 從無效等價類中抽取一個進行測試; 4. 組合有效等價類, 組合無效等價類

3.2.2 邊界值

// 邊界值包括: 邊界值 + 次邊界值

// 邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法, 通常邊界值分析法是作為對等價類劃分法的補充

// 主要測試的點: 上點, 離點, 內點

// 上點: 邊界上的點, 不管是開區間, 閉區間, 還是半開半閉

// 內點: 邊界內的點, 不管是開區間, 閉區間, 還是半開半閉

// 離點: 邊界左右的一個點, 如果是閉區間, 離點就是范圍外的點, 如果是開區間, 離點就是范圍內的點

// 設計測試用例的步驟: 1. 充分理解需求; 2. 找離點, 內點, 上點; 3. 針對離點, 內點, 上點設計測試用例

3.2.3 正交法

// 正交法的目的是為了減少用例數目, 用盡量少的用例覆蓋輸入的兩兩組合

// 可以使用 pairs 設計工具來設計正交表

// 步驟: 1) 在微軟自帶的 Excel 中輸入 因素 和 水平; 2) 復制到 allpairs.exe 同級目錄下的 .txt 文檔中直接保存; 3) 在黑窗口輸入命令 allpairs.exe 空格 .txt 文檔 > 新命名一個用來保存正交表的 .txt 文檔 回車

// 在根據生成好的正交表來編寫測試用例的同時也要繼續補全重要的測試用例

// allpairs 工具生成的正交表和實際的正交表會有一定的出入, 但是不影響整體的情況

3.2.4 判定表法

// 通過具體的方法能夠將測試用例設計的更急完整和規范, 通過判定表法我們可以非常容易的編寫測試用例 (思路清晰)

// 判定表是一種表達邏輯判斷的工具

// 根據判定表法設計測試用例的步驟: 1) 確認需求中輸入條件和輸出條件; 2) 找出輸入條件和輸出條件之間的關系; 3) 畫判定表; 4) 根據判定表編寫測試用例

3.2.5 場景法

// 場景法一般包含基本流 (基本事件流) 和備用流 (備用事件流)

// 現在的軟件幾乎都是用事件觸發來控制流程的, 實踐觸發時的情景形成了場景, 而同一事件不同的觸發順序和處理結果就形成了事件流

// 通過運用場景來對系統的功能點或業務流程的描述, 從而提高測試效果的一種方法

3.2.6 錯誤猜測法

// 對被測試軟件的需求理解以及設計的理解, 過往經驗以及個人直覺, 推測出軟件可能存在的缺陷, 從而針對性地設計測試用例的方法

// 強調的是對測試軟件的需求理解以及設計實現的細節把握, 還有個人的經驗和直覺

// 和目前流行的 "探索式測試方法" 的基本思想一致, 這類方法在敏捷開發模式下的投入產出比很高, 被廣泛應用于測試

3.3 更多用例練習

3.3.1 命令行程序

// 關于 Windows, Linux 系統命令設計測試用例

3.3.2 web 程序

// 使用 postman 進行測試

// postman 具體安裝及使用點擊下面鏈接跳轉

//?postman 安裝及使用