測試用例設計的底層邏輯

轉載請註明出處❤️

你好，我是測試蔡坨坨。

眾所周知，測試用例是每個測試人員都繞不開的話題，也是大家習以為常的事情，無論是功能測試、效能測試，還是自動化測試，都會涉及到用例設計，可以說測試用例是一切測試的基礎。

雖然有時候公司並沒有強制要求寫測試用例，但至少測試點是必不可少的。幾乎所有測試相關的專欄、部落格、公眾號都會提及用例設計，其重要性不言而喻。即便如此，還有許多從業者設計用例的方式僅僅靠經驗積累，雖然他們知道用例的設計需要從軟體功能、效能、易用性、可靠性、資訊保安性、維護性、相容性、可移植性等多方面考慮，但是並沒有形成一套通用的體系結構。

所以，本篇將會從體系的角度來聊一聊測試用例的設計，深挖用例設計的底層邏輯。

1 萬物皆可測試

前段時間收到一個朋友私信詢問，介面測試用例怎麼設計？當時他已經是個熟練的功能測試人員，換了種場景就不會寫測試用例？本質上還是未能掌握用例設計的通用邏輯。

想必大家在面試的時候或多或少有被問到「朋友圈點贊功能怎麼測試？、「淘寶購物車如何測試？」，甚至是一些非軟體物品測試，比如「這個杯子怎麼測試？」、「電梯怎麼測試？」等類似的問題。其實這類問題主要用來考察應聘者的測試思維，以及設計測試用例的角度與思考問題的全面性。

對於此類面試題，其實是有一定套路的，只要你掌握了相關方法，那麼任何物品都可以進行測試，並且設計出相對全面的測試用例。

先給出通用公式：場景法（互動分析） - 等價類劃分 - 邊界值 - 用例組合

在測試之前，我們要深入瞭解被測物件，也就是需求分析，通常我們會根據PRD（產品需求檔案）去構建測試用例，比如：水杯的PRD就是「這是一個水杯」，但是這裡面存在一個問題，業務的質量特性包括顯性特性和隱性特性，而PRD往往只給出顯性需求，甚至有時候連顯性特徵都不齊全，這就很考驗產品同學。因此我們需要通過其他方法去挖掘更多的隱性特性，以得到更加全面的特性，而不僅僅通過需求檔案直接生成測試用例。

我們要明白幾乎所有被測物件都是可以被互動的，互動時的情景便形成了場景，用例設計其實就是尋找互動點，從而轉化為輸入域和輸出域。比如我們與水杯的互動：看起來（外觀，應用到軟體中就是前端UI介面）、拿起來（功能/效能/安全/易用）、裝起來（功能/效能/相容/安全/易用/可靠）、喝起來（功能/效能/相容/安全/易用/可靠）、放起來（效能/相容/安全/可維護/可移植）。

通常來說，我們要從功能、效能、安全、易用性、可靠性、相容性、維護性、可移植性等多方面考慮，其實指的就是單個互動輸入域的完整性。還是拿杯子舉例：

功能：能否裝水；除了裝水，能否裝其他液體，如：碳酸飲料、酒精、茶、咖啡等；是否有刻度……
效能：能否裝100℃的水；能否裝0℃的冰水；裝滿水，放幾天，是否會漏水；杯子上的塗料是否容易脫落；是否易碎 ……
安全：製作杯子的材料對人體是否有害；給杯子加熱是否會融化、爆炸；杯子是否有缺口，會劃傷嘴巴；內壁的塗料是否會溶解到水中；杯子破碎後是否會對使用者造成傷害 ……
易用性：是否容易燙傷；把手是否好端；杯子裡的水是否容易喝到；是否有防滑措施 ……
……

以上舉例主要是提供思路，起到拋磚迎玉的作用，用例僅供參考，並不是很全面。

當我們碰到一個不熟悉的場景時，如果有了這套方法論，就可以幫助我們提供更全面的思考以及更完整的輸入域。這裡提供一種較好的描述方式對互動進行描述，就是用產品質量的八大特性，即功能性（是否滿足客戶需求，三大核心：正確性、完備性、適合性）、效能效率（時間特性、資源佔用）、易用性（使用者理解、操作簡單）、可靠性（能夠正常維持產品特性的程度）、安全性（輸入輸出安全、互動安全、內容安全，比如密碼輸入框掩碼、檔案加密傳輸、重要資訊掩碼）、維護性（因環境變化需要作出調整的難易程度，比如用開關控制功能是否可用）、相容性（與環境的共存，互動物件的互操作，比如不同瀏覽器之間的相容、不同作業系統之間的相容）、可移植性（從一個環境移到另一個環境的難易程度）。

複用這套方法，我們就可以找到更多的隱性特性，顯性特性就是我們上面討論的那些，當然，我們能夠識別隱性特性，還取決於我們對業務的熟練程度。再次拿杯子舉例，比如水杯的設計還要考慮使用者群體，啤酒杯、紅酒杯、白酒杯它們的容量和形狀都是不一樣的，所以在列舉輸入域的時候，理應結合需求背景、業務特性和使用者群體。

做完互動分析後，再使用等價類劃分將輸入域按某個維度進行有效的歸類，比如：可樂、雪碧等對於常規水杯來說是同類物體，沒有必要窮舉，於是將它們都歸類為碳酸飲料。然後在等價類的基礎上再使用邊界值分析法提取單個輸入域分類的有效代表值，比如：0℃（在1個標準大氣壓下，純淨的冰水混合物溫度為0℃）和100℃（沸水的溫度為100℃）。至於為什麼要這麼做，在第二小節「用例的本質」中將會給出答案。

最後進行用例組合，就是對這些代表值按分類做交叉考慮。比如：常溫的碳酸飲料、冰凍的碳酸飲料、冰凍的水、沸騰的水、沸騰的碳酸飲料 ……

我們再回到剛開始的那個問題——「介面測試用例怎麼設計？」，套用這個公式，我們可以通過發起介面呼叫，檢查是否能調通以及返回內容的正確性，以驗證功能是否實現；可以高頻次的發起請求以檢查效能是否滿足要求；可以嘗試提交未經授權的請求，以檢驗它的安全性 ……

2 用例的本質

理論上來說，從輸入端要保證查出程式中所有的錯誤，只能採用窮舉的方法，把所有可能的輸入都作為測試情況考慮。但實際上測試情況有無窮多個，我們不僅要測試所有合法的輸入，還要測試不合法的輸入，所以窮舉測試在很多時候是不可行的。也就是說「完美的測試是不可能的」，那是不是代表測試是靠運氣？並不然。

實際的測試工作需要我們採用各種技術來有針對性地進行測試，通過制定測試案例指導測試實施，保證軟體測試有組織、按步驟以及有計劃的進行，也就是我們需要把無限的輸入域，變成有限的、有代表性的輸入集。測試的意義並不是找到所有的缺陷，而是找到對業務有價值的缺陷。

好的測試用例，是能夠用較少的用例，找到儘可能多的有價值的問題。

因此這也解釋了為什麼會出現等價類劃分法、邊界值分析法等許許多多的用例設計方法。

3 通用公式中的用例設計方法

我們再來回顧一下第一小節給出的通用公式：場景法（互動分析） - 等價類劃分 - 邊界值 - 用例組合

在這個小結，將會介紹這個通用公式用到了哪些具體的用例設計方法。

場景法（互動分析）

很顯然，在這一步驟中用到的方法就是場景法。

什麼是場景法？

現在的軟體幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成了事件流。這種在軟體設計方面的思想引入到軟體測試中，可以生動形象描繪出事件觸發時的情景，有利於測試人員設計測試用例，同時使用例更容易理解和執行。

場景法使用被測軟體與使用者或其他系統之間的互動序列模型來測試被測軟體的使用流程。

簡單來說，場景法就是儘可能真實全部的模擬使用者操作，比如：訂單、發貨、商品狀態變化。

場景法主要基於：

業務/需求層面：對所測軟體的重要功能、業務邏輯、行業背景深入理解。
技術層面：基於等價類劃分，有效等價類（模擬使用者正確的操作）；無效等價類（模擬使用者錯誤的操作）。

應該包含以下場景：

基本場景/基本流/正確流/有效流：模擬使用者正確的操作流程。
可選場景/備選流/錯誤流/無效流：模擬使用者錯誤的操作流程，非正常的使用、極端或者壓力條件和異常等。

舉慄：以自動取款機ATM系統為例

基本場景：

成功從賬戶取款

可選場景：

銀行卡不能被ATM機識別，被拒絕
使用者輸入密碼錯誤不多於2次
使用者輸入密碼錯誤3次，凍結並吐卡
使用者選擇存款或轉賬，不選擇取款
ATM中現金不足
使用者輸入不符合面額的取款金額
使用者輸入的取款金額超過每日最大取款金額
使用者銀行賬戶中的金額不足
……

等價類劃分

什麼是等價類劃分法

依據需求將輸入劃分為若干等價類，從等價類中選定少數代表性的資料作為測試用例，如果該用例通過，則表明整個等價類通過測試。

使用場景

適用於有無限多種輸入，我們不可能完成窮舉測試，等價類可以使我們用比較少的測試用例儘可能多的將功能覆蓋，從而把無限的窮舉輸入轉化為有限的等價類有代表性的輸入，用少量的代表性測試資料來取得較好的測試結果。

等價類的劃分

有效等價類：合理的、有意義的輸入資料構成的集合，對於需求規格說明書是合法的，利用有效等價類可檢驗程式是否實現了規格說明中所規定的功能和效能。
無效等價類：對於程式的規格說明來說是不合理或無意義的輸入資料所構成的集合。

考慮這兩種等價類是因為軟體不僅要能接收合理的資料，也要能經受各種意外的考驗，這樣的測試才能確保軟體具有更高的可靠性。

劃分等價類的原則

常見的劃分方法包括：按區間劃分、按數值劃分、按數值集劃分、按限制條件劃分、按處理方式劃分。

若輸入條件規定了取值範圍（1-120s）或值的個數（手機號11個字元），可以確定一個有效等價類（範圍內）和兩個無效等價類（大於、小於）
若輸入條件規定了「必須如何」，可確定一個有效等價類和一個無效等價類
若輸入條件是一個布林值，可確定一個有效等價類（true）和一個無效等價類（false）
若輸入條件規定了一組值（假定n個），需要對每一個輸入值分別處理，可確定n個有效等價類和一個無效等價類
若輸入資料必須遵守某個規則，可確定一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）
在確知已劃分的等價類中，各個元素在程式處理中的方式不同時，則應再將等價類進一步分為更小的等價類

舉慄

日期輸入框，要求使用者輸入以年月標識的日期，輸入範圍在2000年1月至2100年12月之間，格式為200001。

輸入條件	有效等價類	無效等價類
日期的型別及長度	6位數位字元（202210）	有非數位字元（20221A）；小於6位數位字元（20221）；大於6位數位字元（20221000）
年份範圍	在2000至2100之間（202210）	小於2000（19990222）；大於2100（220010）
月份範圍	在01至12之間	等於00（202200）；大於12（202213）

等價類與測試用例之間的關係：可以由每一個測試用例覆蓋一個特定的等價類，也可以由一個測試用例對應多個等價類。

邊界值

什麼是邊界值分析法

邊界值測試是源於人們長期以來的測試工作經驗所提出的一個關鍵假設：錯誤更容易發生在輸入域的邊界或者說極值附近，而非輸入域的中間部分。

邊界值分析法是對等價類劃分法的補充，一遍都是從等價類的邊緣去尋找錯誤。

邊界值分析法的分類

邊界值的選擇可以分為二值邊界測試和三值邊界測試。

二值邊界測試：如果有一個n變數的軟體輸入域，就會有略小於最小值、最小值、正常值、最大值、略大於最大值五種選擇。

三值邊界測試：對於三值邊界測試，就有略小於最小值、最小值、略大於最小值、正常值、略小於最大值、最大值、略大於最大值七種選擇。

舉慄

微信紅包：最小金額0.01，最大金額200元，邊界值就是0、0.01、0.02、199.99、200、200.01
一個文字方塊輸入區域包括0-255個字元，邊界值就是-1、0、1、254、255、256

PS：0/空，N/A，null是一個特殊值，我們在考慮邊界值的時候同時也要考慮這個特殊值。

用例組合

用例組合就是對以上代表值按分類做交叉考慮，其中會用到判定表、因果圖、正交試驗法等，這些方法就是告訴我們如何做交叉考慮的方法論。

判定表

什麼是判定表？

用於展示輸出條件與輸出結果的對應關係。

分析和表述若干輸入條件下，被測物件針對這些輸入做出的響應的一種工具。

在遇到複雜業務邏輯時可以利用該表理清邏輯關係，適用於輸入框有關聯的場景，例如：使用者名稱輸入框和密碼輸入框。

判定表的組成

條件
- 條件樁（condition stub）：需求規格說明書中定義的被測物件的所有輸入。
- 條件項（condition entry）：針對條件樁所有可能輸入資料的真假值。
動作
- 動作樁（action stub）：針對條件，被測物件可能採取的所有操作。
- 動作項（action entry）：針對動作樁，被測物件響應的可能取值。

規則：動作項和條件項組合在一起，形成的業務邏輯處理規則。

判定表的建立

理解需求，確定條件樁、動作樁。
設計及優化判定表。
填寫動作項。
根據判定表輸出結果的表現，進行判定表的合併（非必須），簡化判定表；如果輸出相同，在對應輸入中，有且只有一個條件的取值對動作不產生任何影響則可合併。

舉慄

登入模組為例

條件樁：使用者名稱正確、密碼正確
動作樁：登入成功、提示使用者名稱或密碼錯誤

因果圖

什麼是因果圖？

因果圖是一種簡化了的邏輯圖，能直觀地表明輸入條件和輸出動作之間的因果關係。

主要組成部分：原因、中間節點、結果。

操作步驟：

分析程式的規格說明書中哪些是原因，哪些是結果。所謂原因，是指輸入條件或輸入條件的等價類，而結果是指輸出條件，給每一個原因和結果賦一個表示符。
分析程式規格說明書中的語意，確定原因與原因，原因與結果之間的關係，畫出因果圖。
由於語法環境的限制，一些原因與原因之間，原因與結果之間的組合不能出現。對於這種特殊情況，在因果圖中用一些記號表明約束或限制條件。
將因果圖轉化為判定表。
根據判定表的每一列設計測試用例。

PS：若能直接得到判定表，可以直接根據判定表設計測試用例，即可以跳過繪製因果圖部分。

舉慄

考試系統，作業達到80分且已確認可進入下一階段學習

因果圖：

將因果圖轉化成判定表：

正交試驗法

什麼是正交試驗法？

正交試驗法是研究多因素、多水平的一種試驗法
它是利用正交表來對試驗進行設計
通過少數的試驗替代全面試驗，根據正交表的正交性從全面試驗中挑選適量的、有代表性的點進行試驗，這些有代表性的點具備了「均勻分散，整齊可比」的特點

舉慄

Word字型樣式：

字型大小：大、中、小
字型顏色：紅、綠、藍
字型樣式：宋體、黑體、楷體

`大紅宋體`	大紅黑體	大紅楷體	中紅宋體	中紅黑體	中紅楷體	小紅宋體	小紅黑體	小紅楷體
大綠宋體	大綠黑體	大綠楷體	中綠宋體	`中綠黑體`	中綠楷體	小綠宋體	小綠黑體	小綠楷體
大藍宋體	大藍黑體	大藍楷體	中藍宋體	中藍黑體	中藍楷體	小藍宋體	小藍黑體	`小藍楷體`

4 其他用例設計方法

通常來說，使用以上測試方法就能應對絕大多數的場景。

除此之外，還有一些其他的測試方法，同樣可以給測試人員帶來較大的幫助，這裡選擇性地介紹幾個。

錯誤推斷法

基於經驗和直覺推測程式中所有可能存在的各種錯誤，從而有針對性的設計測試用例。

二八原則：80%的問題往往出現在20%的模組。

基本思想：列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。

基本要素：

對開發的開發習慣很熟悉。
對同型別專案業務非常熟悉。

軟體錯誤型別：

軟體需求錯誤
- 需求不合理
- 需求不全面、不明確
- 邏輯錯誤
- 檔案有誤
功能和效能錯誤
- 需求規格說明中規定的功能實現不正確、存在未實現或冗餘的情況
- 效能未滿足規定的要求
- 為使用者提供的資訊不準確
- 異常情況處理有誤
軟體結構錯誤
- 程式控制流或控制順序有誤
- 處理過程有誤
資料錯誤
- 資料定義或資料結構有誤
- 資料存取或資料操作有誤
軟體實現和編碼錯誤
- 編碼錯誤或按鍵錯誤
- 違反編碼要求和標準，例如語法錯誤、資料名錯誤、程式邏輯有誤等
軟體整合錯誤
- 軟體內部介面或外部介面有誤
- 軟體各相關部分在時間配合、資料吞吐量等方面不協調

探索式測試

可參考往期文章「五分鐘搞懂探索式測試」

基於檢查表的測試

通過設計相應的檢查點，並按照檢查點進行測試驗證的一種測試方法。檢查表中的檢查項來源於以往的測試經驗總結。檢查表用於支援各種測試型別，包括功能和非功能測試。

舉慄：基於程式碼檢查表的測試

在程式碼審查階段，程式碼檢查表將常見的錯誤進行分類，在每一類錯誤下列舉出容易出錯的位置和在以往工作中的典型錯誤，將其以清單的形式展示，比如：NullPointerException空指標異常通常是因為沒有做非空判斷、switch中是否有default ……

檢查點	檢查項	結果
格式規範性	巢狀的IF語句是否正確地縮排、註釋是否準確並有意義、整體上是否遵循全套的程式設計標準
判斷和轉移	正確的條件是否經判斷、用於判斷的是否是正確的變數
效能	每個邏輯是否實現最佳編碼
邏輯性	全部設計是否都已實現、程式碼實現是否與設計一致
……

測試用例是測試的基礎，測試用例設計是一個很大的話題，還有很多內容值得探討，由於時間關係，暫且討論到這裡，同時，我相信隨著測試理論和技術的發展，將來一定會有更多更智慧的用例設計策略出現，讓我們共同期待它的到來吧。