最詳細的測試用例設計方法講解

大家好，我是一名測試開發工程師，今天跟大家分享下測試用例設計方法。
在做軟體測試時，最容易忽略但卻最重要的知識點，那就是測試用例設計。用例設計就是軟體測試工程師的靈魂，體現了你的測試思維，以及對業務需求的熟悉程度。有時侯出現線上事故，可能就是測試用例沒有覆蓋全面。

測試用例概述

考慮部分同學是剛入行做測試的，我先說一下測試用例是什麼：

• 測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求

看到測試用例的定義是不是有點暈，通俗的來講，測試用例就是一個參照物，在測試過程中，會按照測試用例來逐條執行測試。測試用例最主要是有 4 部分組成：

• 用例標題
• 前置條件
• 操作步驟（輸入）
• 預期結果（輸出）

對於測試用例的第 3 部分，操作步驟可以理解成是輸入，比如我們在手機鍵盤上輸入數字或者字母，除此之外，常見的輸入還有點選按鈕、長按、滑動螢幕等等，注意這裡的輸入需要滿足前置條件
在完成輸入以後會有一個預期的結果，可以理解成輸出，常見的輸出有（1）彈窗（2）跳轉新頁面（3）tosat 提示（4）展示文字、圖片等
那測試用例到底怎麼寫呢，可以看看下面這個例子，現在我需要測試某個網站的登陸功能，我設計的 1 條測試用例如下：

這條用例是為了驗證登陸功能當中成功登陸的情況，所以用例標題為 01_登陸功能_成功登陸，標題裡面加入編號是為了方便管理。操作步驟是在符合前置條件下進行，即在使用者已註冊並且未登陸的情況下，輸入指定位數的使用者名稱和密碼，預期結果就是有彈窗提示，跳轉主頁

常見用例設計方法

測試用例最核心的部分，大家可以想想是哪一部分，毫無疑問是操作步驟，咱們平常做測試也就是根據測試用例裡面的操作步驟在點點點，怎麼點才能更有效率，並且把測試覆蓋得更全面呢？
於是咱們需要學習測試用例的設計方法，本篇文章主要是介紹 2 種黑盒測試 用例設計方法，分別是等價類和邊界值，這是實際工作當中最常用的 2 種：

等價類

等價類，等價類從字面上來理解就是相同的種類，先看一下等價類的定義：

• 等價類是把使用者所有可能輸入的資料，即程式的輸入域劃分成若干部分（子集），然後從每一個子集中選取少數具有代表性的資料作為測試用例
• 使用等價類設計測試用例時，要同時考慮有效等價類和無效等價類

有效等價類：對於程式的規格說明（需求文件）來說，是合理的、有意義的輸入資料所構成的集合；
無效等價類：對於程式的規格說明來說，是不合理的、沒有意義的輸入資料所構成的集合

舉個例子便於理解有效等價類和無效等價類，現在我要測試兩個 1-100 整數（包含 1 和 100）相加，請你利用等價類設計測試用例，按照題目先劃分出有效等價類和無效等價類。
有效等價類：
【1】輸入的都是 1-100 的整數
無效等價類：
【2】輸入小於 1 的整數
【3】輸入大於 100 的整數
【4】輸入空
【5】輸入字母和特殊字元
【6】輸入空格

確定有效等價類和無效等價類後，我們就可以設計測試用例：

邊界值

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

舉一個例子來幫助理解邊界值，一個輸入的檔案應包括 1~255 個記錄, 那麼可以分析出 6 個邊界點，分別是略小於最小值 0，最小值 1，略大於最小值 2，略小於最大值 254，最大值 255 和略大於最大值 256。這 6 個點即可作為測試用例的輸入資料。

等價類和邊界值往往結合起來使用，邊界值分析使用與等價類劃分法相同的劃分，只是邊界值分析假定錯誤更多地存在於劃分的邊界上，因此在等價類的邊界上以及兩側的情況設計測試用例；

1. 將軟體的輸入或者輸出引數進行等價類劃分；
2. 在等價類的基礎之上進行邊界值分析。一般情況下，假如邊界值已經由等價類劃分覆蓋，則可以不予考慮；
3. 將邊界值進行組合，作為測試用例的輸入資料；

再回顧一下上述介紹等價類時的例子，測試兩個 1-100 整數（包含 1 和 100）相加，現在我們將等價類和邊界值用例設計法結合起來，用例 1 可以改成輸入整數 1，2，99，100，用例 2 改成 輸入整數 0，用例 3 改成輸入 101。經過這樣的改造，我們的用例既經過了等價類劃分覆蓋有效和無效等價類，也進行了邊界值分析，覆蓋到邊界值的測試。

細心的小夥伴會問，為什麼我們要用邊界值去設計測試用例呢？這個是由大量的測試實踐經驗得出，大量的 Bug 往往發生在輸入定義域或者輸出值域的邊界上，而不是在內部。因此，我們針對邊界情況設計測試用例，一般能發現更多的問題。

再看看為什麼要用等價類去設計測試用例，對於一個程式，往往可以輸入的資料非常多，就拿一個可輸入 11 位的密碼框來說，我們不可能實現窮舉測試，可以從大量的可能資料中選取一部分具有代表性的資料作為測試用例，這樣極大提高測試效率同時保證了測試的質量，因為經過等價類劃分後，每一類的代表性資料在測試中的作用都等價於這一類中的其他值。

更多用例設計方法

• 功能圖
• 場景法
• 因果圖
• 錯誤推測
• 判定表
• 正交試驗
• 狀態遷移

除了等價類和邊界值，還有很多測試用例的設計方法，在上面已經列出來了。我這裡再講講錯誤推測法，這個方法是基於經驗和直覺推測程式中所有可能存在的各種錯誤，從而有針對性的設計測試用例。在企業裡面，當你熟悉業務以後，就可以根據業務的特點去定製化的設計測試用例作為補充了。

用例設計考慮層面

前面我們介紹了等價類和邊界值的用例設計方法，這兩種黑盒用例設計方法所產生的用例都是屬於功能測試層面，除了功能方面，我們在設計測試用例時，還應該考慮到安全、效能、相容性這三個層面：

功能測試用例

還是登陸功能舉一個例子，對於我們測試人員該怎麼設計用例呢，先從功能層面考慮，我們比較容易能想到以下用例：

• 輸入已註冊的使用者名稱和正確的密碼，驗證是否登陸成功
• 輸入已註冊的使用者名稱和不正確的密碼，驗證是否登陸失敗
• 輸入未註冊的使用者名稱和任意密碼，驗證是否登陸失敗
• 使用者名稱和密碼兩者都為空，驗證是否登陸失敗
• 使用者名稱和密碼兩者之一為空，驗證是否登陸失敗
• 如果登陸功能啟動了驗證碼功能，在使用者名稱和密碼正確的前提下，輸入正確的驗證碼，是否登陸成功
• 如果登陸功能啟動了驗證碼功能，在使用者名稱和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登陸失敗

列出這些測試用例後，你是不是感覺上面的測試用例已經涵蓋了主要的功能測試場景，但是在高階測試工程師眼中，這些用例還不夠，再看看下面這些測試用例你是否考慮到：

• 使用者名稱和密碼是否大小寫敏感
• 頁面上的密碼框是否加密顯示
• 後臺系統建立的使用者第一次登入成功時，是否提示修改密碼
• 忘記使用者名稱和忘記密碼的功能是否可用
• 前端頁面是否根據設計要求限制使用者名稱和密碼長度（若有限制長度位數，則可以根據邊界值設計測試用例）
• 如果登入功能需要驗證碼，點選驗證碼圖片是否可以更換驗證碼，更換後的驗證碼是否可用
• 重新整理頁面是否會重新整理驗證碼
• 如果驗證碼具有時效性，需要分別驗證時效內和時效外驗證碼的有效性
• 使用者登入成功但是會話超時後，繼續操作是否會重定向到使用者登入介面
• 不同級別的使用者，比如管理員使用者和普通使用者，登入系統後的許可權是否正確
• 頁面預設焦點是否定位在使用者名稱的輸入框中
• 快捷鍵 Tab 和 Enter 等，是否可以正常使用
• 滑鼠游標是否只在固定位置才顯示可點選或編輯狀態

看完以後你是不是覺得原來一個簡單的登陸功能可以考慮這麼多測試點，使用者登入功能的測試用例設計還沒結束。我們應該知道軟體的需求包含顯式功能性需求（指的是軟體本身需要實現的具體功能）和隱式功能性需求（即非功能性需求），所以除了功能以外，我們還要考慮安全、效能、相容性層面的用例。

安全性測試用例

• 使用者密碼及個人資訊是否加密儲存；
• 使用者密碼及個人資訊在網路傳輸過程中是否加密；
• 密碼是否具有有效期，密碼有效期到期後，是否提示需要修改密碼；
• 不登入的情況下，在瀏覽器中直接輸入登入後的 URL 地址，驗證是否會重新定向到使用者登入介面；
• 密碼輸入框是否不支援複製和貼上；
• 密碼輸入框內輸入的密碼是否都可以在頁面原始碼模式下被檢視；
• 使用者名稱和密碼的輸入框中分別輸入典型的 “SQL 注入攻擊” 字串，驗證系統的返回頁面；
• 使用者名稱和密碼的輸入框中分別輸入典型的 “XSS 跨站指令碼攻擊” 字串，驗證系統行為是否被篡改；
• 連續多次登入失敗情況下，系統是否會阻止後續的嘗試以應對暴力破解；
• 同一使用者在同一終端的多種瀏覽器上登入，驗證登入功能的互斥性是否符合設計預期；
• 同一使用者先後在多臺終端的瀏覽器上登入，驗證登入是否具有互斥性。
• 登入介面返回的資料是否對使用者資訊進行加密顯示
• 登入 UA 獲取，確保是使用者本人登入

效能測試用例

• 單使用者登入的響應時間正常網路環境下是否小於 2 秒；
• 單使用者登入時，後臺請求數量是否過多；
• 高併發場景下使用者登入的響應時間是否小於 5 秒；
• 高併發場景下服務端的監控指標是否符合預期；
• 高集合點併發場景下，是否存在資源死鎖和不合理的資源等待；
• 長時間大量使用者連續登入和登出，伺服器端是否存在記憶體洩漏。
• 防止同一使用者惡意併發

相容性測試用例

• 不同瀏覽器下，驗證登入頁面的顯示以及功能正確性；
• 相同瀏覽器的不同版本下，驗證登入頁面的顯示以及功能正確性；
• 不同移動裝置終端的不同瀏覽器下，驗證登入頁面的顯示以及功能正確性；
• 不同解析度的介面下，驗證登入頁面的顯示以及功能正確性；

複雜系統如何設計用例

對於複雜系統的用例設計，有著非常重要的一步，就是拆解功能點。那應該怎麼拆解功能點呢，就播放頁面來說，別看只有一個頁面，但是上面包含了非常多的功能點，我們至少能拆出如下功能點：

• 點贊
• 投幣
• 收藏
• 分享
• 評論
• 彈幕
• 播放頁面 Tab、文案與資訊展示

拆解完功能點以後，我們就可以依據各自的功能點利用等價類、邊界值、錯誤推測等方法設計測試用例，單功能的用例設計完成以後，還需要使用場景法設計場景化的測試用例，覆蓋到使用者的操作流程，比如：

從主頁點選影片，跳轉到影片播放頁面，在播放頁面點選評論 Tab 跳轉到評論頁面，點選評論按鈕，進行評論，評論完成後，檢視評論列表，這就一個使用者操作的基本流程，再舉一個場景化的例子，我們都用過淘寶，從挑選商品->加入購物車->從購物車付款，這就是購買商品的核心場景。

場景法偏重於大的、複雜的業務流程，目的是用業務流把各個孤立的功能點串起來，所以在用場景法設計用例時，測試人員必須非常熟悉整體業務流程，才能設計出完整的場景化測試用例，想要徹底弄懂業務流程我們可以細看需求文件、多和產品經理溝通交流還可以親自體驗功能。

結尾

好了，能完整的看到這裡，說明你已經是一個非常想學好設計測試用例設計的同學了，想要設計好測試用例，掌握了測試用例的設計方法，還需要勤加練習，你設計出的測試用例體現出你的測試思維，而測試思維的養成也不是一天兩天就能形成，它需要不斷的積累和大量的測試實踐。