目錄

1. 測試用例

1.1 概念

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

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

2.2 萬能公式?

3. 設計測試用例例的方法

3.1 基于需求的設計方法

?編輯

3.2 具體的設計方法

3.2.1 等價類

3.2.2 邊界值

3.2.3 正交法

3.2.4 判定表法

3.2.5 場景法

3.2.6 錯誤猜測法

---

1. 測試用例

1.1 概念

什么是測試用例？

測試用例（Test Case）是為了實施測試而向被測試的系統提供的?組集合，這組集合包含：測試環境、操作步驟、測試數據、預期結果等要素

設計測試用例原則?：

測試用例中?個必需部分是對預期輸出或結果進行定義

什么是要素？我們在編寫測試?例的時候，每個?例需要給出這些要素對應的信息。

?例編號	test-01
標題	成功注冊網易郵箱
測試?式	??測試
功能模塊	注冊登陸

重要性	重要
測試前提	系統運?正常，郵件服務器已開啟
測試環境	win10 Chrome版本103.0.5060.66（正式版本）（64位）
測試數據	郵箱地址：996402440@qq.com 密碼：123456 ?機號：12312341234
測試步驟	1.打開?歌瀏覽器，輸??易注冊地址：https://mail.163.com/register/index.htm 2.輸?郵箱地址，密碼，?機號，獲取驗證碼并輸?正確的驗證碼，勾選協議 3.點擊注冊按鈕
期望結果	展現注冊成功的結果?，并且使?剛注冊的賬號可以正常登陸并進?郵箱??

為什么需要測試用例呢，不寫測試用例可以進行測試嗎？

測試中可能會遇到很多問題，諸如：

• 不知道是否較全?的測試了所有功能
• 測試的覆蓋率?法衡量
• 對新版本的重復測試很難實施（即回歸測試?法僅通過??測試的方式進行歷史功能的回歸）
• 存在大量冗余測試影響測試效率

測試用例的出現就是解決這些問題。另外，測試用例的作用還可以避免測試?員被迫背鍋~~

實際中產品出現問題，第?責任?首先想到的是測試為啥沒有測到？

上面展示的是傳統的編寫測試用例的方式，我們在學習敏捷模型的時候了解到，如今大多數企業采?的都是思維導圖的方式來編寫測試用例。以下課程內容包括日常用例練習都是用思維導圖/腦圖進行編寫。

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

現在有?款產品，要求我們對“門鎖”設計測試用例，假如你是測試?員，你會怎么設計呢？

可以看出，用例的設計最重要的?點是保證功能是正確的。上圖給出的案例，在互聯網企業中，這樣去設計測試用例的非常少，缺乏經驗的同學往往以這樣的思路去設計。

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

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

設計測試用例的原則?：

1.測試用例的編寫不僅應當根據有效和預料到的輸?情況，而且也應該根據無效和未預料到的輸?情況。

2.檢查程序是否“未做其應該做的”僅是成功的?半，測試的另?半是檢查程序是否“做了其不應該做的”。（是上?條原則的必然結果）

3.計劃測試?作時不應默許假定不會發現錯誤

明白了設計測試用例是思維的正確還往往不夠。

若僅僅通過頭腦風暴去設計測試用例，那么當我們面對面試官時，能夠想出來的用例是寥寥??的，所以在設計測試用例的時候需要有思路的去設計。

2.2 萬能公式?

設計測試用例的萬能公式：功能測試+界面測試+性能測試+兼容性測試+易用性測試+安全測試。

功能測試

功能測試是?個試圖發現程序與其外部規格說明之間存在不?致的過程。外部規格說明是?份從最終用戶的角度對程序行為的精確描述。功能測試通常是?項黑盒操作。在進行功能測試時，需要對規格說明進行分析以提煉測試用例，本課程中討論的具體設計測試用例的方法尤其適用于功能測試。然而，不僅是?作中還是面試中，可能會存在需求不明確的功能？這種情況下該如何進行功能測試？

• 查找其他相關?檔，來幫助理解所要測試的產品需要完成的目標;
• 盡量多參加項目組內的會議，比如需求討論、設計討論、計劃討論等，能夠加深對產品的理解;
• 召集相關?員，對你整理的結果進行討論，通過評審后，這份文檔就可以作為依據來設計你的case了;
• 如果是?款已經上線的產品，可以多使用產品，有不懂的問產品經理;
• 也可以去看歷史bug，可以了解到?些需要關注的東西。

界面測試

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

要求：

• 整體界面、測試界面的實現與設計圖要求?致。
• 界面元素測試：控件操作驗證

性能測試

性能測試和功能測試的區別是：功能測試檢查軟件是否做了，而性能測試測試軟件做的好不好。

兼容性測試

軟件是部署在硬件系統之上，并依賴所需要的軟件環境。如QQ可以在PC端打開，也可以在移動端打開；移動端?分為IOS系統和Android系統，且市面上?機?有不同的品牌、不同的機型、不同的版本。軟件是否能夠在不同的環境下正確運行需要測試?員進?驗證。

問題：既然市?上有眾多版本的機器，那么在執?兼容性測試時難道所有的機型都需要全面覆蓋嗎？

選取標準：

• 優先選擇使?當前產品top級別的機型進?測試，實際在企業中，后臺是可以獲取到使?產品的機型，并以報表的形式統計在后臺，供產品?員或其他?員制定策略參考。
• 選擇主流的瀏覽器/機型進?測試

易用性測試

易用性測試的標準是檢查產品是否具備簡單易上?的屬性。假如測試人員從來沒有安裝或使用過該產品，作為?個新用戶，對當前產品是否能夠快速適用產品的使用流程。

安全測試

安全測試和性能測試?樣都是比較大的領域。常見的安全問題如：

• 隱私數據明文顯示。
• 參數未強校驗導致SQL注?。
• 越權：普通用戶也可以執行管理員權限的操作

接下來繼續嘗試對門鎖進?測試?例的設計，你能設計多少呢？

除了萬能公式之外，還有?個比較常用的測試類型：弱網測試、安裝卸載測試

弱網測試

弱網測試的目的就是盡可能保證用戶體驗，關注的關鍵點包括：

• 頁面響應時間是否可以接受，關注包括熱啟動、冷啟動時間、頁面切換、前后臺切換、?字時間，?屏時間等。
• 頁面呈現是否完成?致。
• 超時?案是否符合定義，異常信息是否顯?正常。
• 是否有超時重連。
• 安全?度：是否會發?dns劫持、登陸ip更換頻繁、單點登陸異常等。
• ?流量事件分險：是否會在弱網下進行更新apk包、下載文件等大流量動作。

弱網需要借助?具來構造弱網，這?推薦使?fiddler

1. fiddler配置代理
2. fiddler進行抓包（桌?/移動端）
3. fiddler如何構造弱網條件

安裝卸載測試

針對需要進行部署的軟件，除了軟件功能外，我們還需要關注軟件的能夠成功安裝和卸載

3. 設計測試用例例的方法

3.1 基于需求的設計方法

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

測試人員接到需求之后，要對需求進行分析和驗證，從合理的需求中進?步分析細化需求，從細化的需求中找出測試點，根據這些測試點再去設計測試用例。

以該注冊郵箱賬號需求為例，我們來設計測試?例

1.明確需求中的功能點

????????賬號注冊，賬號登陸

2.結合萬能公式設計測試點

3.2 具體的設計方法

3.2.1 等價類

上述設計的測試?例，存在用例還未完全設計完成，“姓名必填，6~15位的字符類型”，這樣?個具體的需求該如何來設計測試用例呢？

測試的時候通過窮舉法來測試6位、7位、8位......14位，15位是否測試通過，這樣的方法能夠滿?測試的要求嗎？若此時把范圍從“6~15位”改成“6~150位呢”？試想?下這樣?個簡單的測試點需要測試多久呢，顯然是不符合企業測試要求的。

而等價類法的出現就解決了窮舉法不能解決的問題

?依據需求將輸?（特殊情況下會考慮輸出）劃分為若干個等價類，從等價類中選出?個測試用例，如果這個測試用例測試通過，則認為所代表的等價類測試通過，這樣就可以用較少的測試用例達到盡量多的功能覆蓋，解決了不能窮舉測試的問題。

?活中等價類的案例：

因材施教的例?:

原則上講, ?師應該依據每個學?自身的情況, 指定符合的學習方案. 但是實際上學?太多?師管不過來, 只能分成幾類: 優等?強調知識面的擴展和綜合能力的提升; 中等生強調夯實基礎, 查缺補漏; 差等?強調 優先掌握重點, 暫時跳過難點...

思路：輸?的集合是無窮的, 不能全都覆蓋到

?等價類分類：

• 有效等價類：對于程序的規格說明書是合理的、有意義的輸?數據構成的集合，利用有效等價類驗證程序是否實現了規格說明中所規定的功能和性能
• ?效等價類：根據需求說明書，不滿足需求的集合。

根據等價類設計測試用例的方式：

• 確定有效等價類和無效等價類
• 編寫測試用例，設計具體測試數據

練習：根據學到的邊界值將上述未完成的用例進行完善

?缺點：等價類只考慮輸?域的分類，沒有考慮輸?域的組合，需要其他的設計方法和補充。

3.2.2 邊界值

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

?常語?中的"邊界"漏洞。

考完試發成績了, ?師布置寒假作業: 超過60分的, 所有題目抄寫1遍, 低于60分的, 所有題目抄寫3遍。

于是小明就沒有寫作業~~, 因為他剛好60分。

邊界值包含：邊界值+次邊界值

邊界值即給定返回的左數據和右數據

選擇次邊界值的時候需要根據邊界值的有效無效情況來定

1. 若邊界值為有效等價類中的數據，則次邊界值為無效等價類中的邊界
2. 若邊界值為無效等價類中的數據，則次邊界值為有效等價類中的邊界

• 輸?框?度為1-11，取邊界值為：1、11、12、0
• 運動員的參賽項?為1-3項，取邊界值為：0項、1項、3項、4項
• 查詢???有999?，每50?為一頁，取邊界值為：輸出0?、1?、50?、51?、999?

?繼續將上述用例通過邊界值補充完整

3.2.3 正交法

通過等價類和邊界值方法我們完成了部分用例的補充

當前還剩下?個場景的用例未補充完成，“只填寫部分選項”，這?到底要設計多少測試用例呢？

通常來說，為了保證系統的測試覆蓋率，我們?先能夠想到的就是排列組合。

假如當前有兩個選項A和B，可以設計出都填寫、都不填寫、填寫A、填寫B四個測試?例（22）。

假如當前有三個選項A、B、C，通過設計可以得到8個測試?例（23）

......

當前可選的選項是5個，分別是，姓名、電子郵箱、密碼、確認密碼、驗證碼。按照排列組合設計出來的?例是32個.....

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

正交試驗設計(Orthogonal experimentaldesign)是研究多因素多水平的?種設計方法，它是根據正交性，由試驗因素的全部水平組合中挑選出部分有代表性的點進行試驗，通過對這部分試驗結果的分析了 解全面試驗的情況，找出最優的水平組合。正交試驗設計是?種基于正交表的、高效率、快速、經濟的試驗。

正交表：

如圖最簡單的正交表是L(4)(2(3))，含意如下：“L”代表正交表；L 下?的數字“4”表示有 4 橫行，簡稱行，即要做四次試驗；括號內的指數“3”表示有3 縱列，簡稱列，即最多允許安排的因素是3 個；括號內的數“2”表示表的主要部分只有2 種數字，即因素有兩種水平1與2。

正交表的構成：因素數、水平數、行數。

因素：對指標的影響條件，通常是正交表中的?列。（存在的條件）

水平：因素對應的可選項。（因數的取值）

正交表的性質：

• 每?列中，不同的數字出現的次數相等。
• 任意兩列中數字的排列方式齊全而且均衡

?根據正交表的性質，?般人很難通過手動設計出正交表，

正交法設計測試用例的步驟：

1. 找到因素和水平

2. 用allparis?具生成正交表

• 將因素和水平寫入Excel表格中
• allparis?錄下創建新的?本?件new.txt，復制Excel中的因素和水平，直接粘貼到?本中保存并退出
• 使?allparis命令?成正交表：allparis.exe new.txt>zhengjiao.txt

3. 根據正交表編寫測試用例

4. 補充遺漏的重要測試用例

繼續以郵箱注冊為例， 采?正交法補全剩下的測試用例。

1. 找到因素和水平

• 因素：姓名、電?郵箱、密碼、確認密碼、驗證碼
• 水平：填寫、不填寫

2. 用allparis工具生成正交表

• 將因素和水平寫?Excel表格中
• allparis目錄下創建新的文本文件0714.txt，復制Excel中的因素和水平，直接粘貼到文本中保存并退出
• 使用allparis命令生成正交表：allparis.exe 0714.txt>0714jg.txt（將生成的正交表數據放入0714jg.txt文件中）

3. 根據正交表編寫測試用例

4. 補充遺漏的重要測試用例

注意：使用allparis生成的正交表和預期有出?，但是不影響我們用來設計測試用例。

3.2.4 判定表法

通過具體的方法能夠將測試用例設計的更加完整和規范。

需求中會存在各種各樣的場景，現在我們把需求改成如下的要求：

輸?的賬號中包含admin字符，或者通過內部鏈接進?注冊頁面，提交注冊按鈕成為管理員?份；反之無管理員?份。

?通過這個需求可以看出，不同的組合操作可能對應不同的結果。采?正交法?法解決這樣的問題。而正交法能夠解決需要考慮輸?之間的組合關系對應不同結果的場景。

判定表

判定表是?種表達邏輯判斷的工具，形如：

通過該圖，可以把所有條件對應的結果清晰的表達出來。我們就需要借助該表來清晰的寫出測試用例。

根據判定表法設計測試用例的步驟：

1. 確認需求中輸?條件和輸出條件
2. 找出輸?條件和輸出條件之間的關系
3. 畫判定表
4. 根據判定表編寫測試?例

確認了步驟后，我們使?判定表法進?步對上述需求進行測試用例的設計：

1. 確認需求中輸?條件和輸出條件

• 輸?條件：賬號包含admin字符（a）、內部注冊鏈接(b)、點擊注冊按鈕(c)
• 輸出條件：管理員（1）、?管理員（2）
  ?

?2. 找出輸?條件和輸出條件之間的關系

• 輸?條件：ac ab bc abc? a? ?b? ?c? ??abc
• 對應結果： 1? ?2? ?1? ? 1? ? 2? 2? ? 2? ? ?2?

3. 畫判定表

?4. 根據判定表編寫測試用例

a. 賬號包含admin，?內部注冊鏈接，點擊注冊按鈕，為管理員?份

b. 賬號包含admin，內部注冊鏈接，不點擊注冊按鈕，?管理員?份

c. 賬號不包含admin，內部注冊鏈接，點擊注冊按鈕，為管理員?份

d. 賬號包含admin，內部注冊鏈接，點擊注冊按鈕，為管理員?份

e. 賬號包含admin，?內部注冊鏈接，不點擊注冊按鈕，?管理員?份

f. 賬號不包含admin，?內部注冊鏈接，點擊注冊按鈕，?管理員?份

g. 賬號不包含admin，?內部注冊鏈接，不點擊注冊按鈕，?管理員?份

3.2.5 場景法

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

通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果的?種方法。用例場景來測試需求是指模擬特定場景邊界發?的事情，通過事件來觸發某個動作的發?，觀察事件的最終結果，從而用來發現需求中存在的問題。我們通常以正常的用例場景分析開始，然后再著手其他的場景分析。場景法?般包含基本流和備用流，從?個流程開始，通過描述經過的路徑來確定的過程，經過遍歷所有的基本流和備用流來完成整個場景。場景主要包括4種主要的類型：正常的用例場景，備選的用例場景，異常的用例場景，假定推測的場景。

讀完上面的概念是不是?臉懵，場景法就是?個常規的流程中，某些階段可能會出現?些意想不到的情況，常規流程是基本流，從階段中分析出來的不同情況被稱之為備選流，場景法比較考驗同學們的發散思維。

針對場景法給出?活中的案例。以逛街買衣服為例，講講場景法的使用?法。

該方法可以比較生動地描繪出事件觸發時的情景，有利于測試設計者設計測試用例，使測試用例更容易理解和執行。

典型的應用是用業務流把各個孤立的功能點串起來，為測試?員建立整體業務感覺，從而避免陷?功能細節忽視業務流程要點的錯誤傾向。

案例：

還是根據郵箱賬號注冊的案例，根據場景法來設計測試用例TODO

根據場景法設計測試用例的步驟

1.確定基本流

2.確定備選流

3.根據備選流補充測試用例

4.編寫測試用例

確定基本流和備用流后，編寫測試用例：

1.基本流：點擊注冊同意協議，輸?正確的信息，點擊注冊，成功激活

2.備用流：點擊注冊不同意協議，重新點擊注冊同意協議，輸?正確的信息，點擊注冊，成功激活

3.備用流：點擊注冊不同意協議，重新點擊注冊同意協議，輸?錯誤的信息，重新輸入正確信息，點擊注冊，成功激活

4......

3.2.6 錯誤猜測法

錯誤猜測法是對被測試軟件設計的理解，過往經驗以及個人直覺，推測出軟件可能存在的缺陷，從而針對性地設計測試用例的方法。

這個方法強調的是對被測試軟件的需求理解以及設計實現的細節把握，還有個人的經驗和直覺。 錯誤推測法和目前流行的“探索式測試方法”的基本思想?致，這類方法在敏捷開發模式下的投?產出比很高，被?泛應用于測試。

當我們?提到某個非常熟悉的?的名字，腦海會?刻浮現對他的評價

“武?郎”：憨厚，?實，為?坦誠，樂于助?

“潘金蓮”：美麗，“溫柔”，“疼愛丈夫”，“善于交友”，“精通制?”

張三要去賣?

?例1：張三這?不實誠，小心他缺斤少兩

?例2：張三這?粗心，小心他的瓜被壓壞了

?例3：張三這人小氣，小心不要把他惹哭了

這個方法的缺點是難以系統化，并且過度依賴個?能?。

還是根據郵箱賬號注冊的案例，根據場景法來設計測試?例

?案例：

以注冊為例

1、校驗中特殊字符空格的處理?

2、密碼校驗中的大小寫？

3、姓名中的特殊字符？

4、密碼發送是否明文

?3.3 更多用例練習

上面介紹設計測試用例以及方法已經介紹過web場景用例的設計。接下來看看不同題型用例的設計。

3.3.1 命令行程序

存在功能可以在命令行使?zip/unzip命令對?件進行解壓縮，這樣的場景如何來設計測試?例？

zip命令

功能測試：對不同的?件類型進行測試

1. 普通的txt文件能夠生成zip文件
2. 圖片/視頻/zip?件能夠?成zip?件
3. 多個?件能夠?成zip?件（混合?件）
4. 空?件夾可以?成zip?件
5. 錯誤的命令是否可以解壓（zip zip/沒有寫壓縮包?件名稱/沒有源?件）
6. 其他參數的測試

界?測試：

1. ?件壓縮成功命令行提示是否美觀
2. ?件壓縮報錯命令行提示是否友好

性能測試：

1. ?件大小超過1G時?件是否可以壓縮
2. ?件大小超過1G時?件壓縮消耗的時間是否在合理的時間范圍內

兼容性測試：

1. zip?具可以在多系統上使?，如Windows、Linux、Mac
   ?

?易用性測試：

1. zip命令有使用幫助教程，如zip --help命令下會展示如何使用

安全性：

1. 使?zip命令不會泄漏?件內容

?3.3.2 接口

通過curl命令我們可以在命令行上請求接口，并對接口進行測試。

如何對當前接口設計測試用例呢？

不同的請求方式：

1. 以GET方式請求接口是否可以返回預期的響應數據
2. 以POST方式請求接口是否可以返回數據

參數組合（如果接口需要拼參數的情況下）：

1. 空參數
2. 多參數
3. 少參數
4. 參數對應的值為空/過?/特殊字符....

不同的參數格式：

1. url拼參
2. form-data格式
3. raw格式等等

接口性能：

1. ?千萬個請求同時發起，是否能夠返回響應
2. 并發情況下響應時間是否在大眾接受范圍內

對接口進行測試時，使用curl命令進行接口測試在操作上并不理想，實際在?作中我們常常使用接口測試?具來提供測試的質量和效率，常用的接?測試?具有postman