前言：
測試工作最為基礎核心的內容就是設計測試用例，什麼樣的測試用例是好的測試用例？我們一般會認為數量越少，發現缺陷越多的用例就是最好的用例。
那麼我們如何才能設計出好的測試用例呢？
一份好的用例是設計出來的，是測試人員思路和方法的集合，而非測試邏輯和需求的羅列。
一、測試用例設計的幾個準則

1、用例設計=思路
強調測試的場景，測試方法。
2、測試步驟化
此處說的測試步驟，不是說每條測試用例都要寫明測試步驟，而是指那些通過測試步驟的調整會出現缺陷的地方需要重點關注測試步驟，比如新增操作，單純的新增功能是OK的，但是先刪除一條資料，再新增相同的資料就失敗了，這個就涉及到操作步驟了。
 3、用例流程化
此過程依託於完整的業務流程圖，每個分支就是一條支流，通過業務端發起的請求，最終都會流向一條分支，而流程化就是將這些分支梳理為測試場景，通過覆蓋測試場景來覆蓋業務邏輯。

二、測試用例設計的步驟
1、明確原始需求
原始需求是軟體的使用者（客戶）的需求，在需求文件基礎+本質理解才能真正理清楚需求要實現什麼樣的目的，以此為出發點才能不偏離需求本質；
2、拆分原始需求
在需求測試階段，如果按照需求測試策略對需求梳理一遍之後，對於所有的需求點應該都已經很清楚了，將這部分的需求點羅列出來，就可以作為需求粗略的測試點；
3、梳理業務邏輯
現在比較多的前端業務都來源於介面所返回的資料，前端最多的時候也就是根據返回資料做一些相應的顯示和計算，所以如果對頁面設計測試用例，那麼需要關注介面資料的完整性和正確性對頁面的影響，而介面本身的測試則要歸納到介面測試用例設計環節。

• 介面沒有返回資料時，頁面如何處理；
• 介面返回的引數不完整，比如返回包有list結構，此作為前臺展示列表資料的依據，但是list為空；
• 介面返回包中沒有需求的引數名稱

這個地方有一個原則，需要注意，即前後端分離和前後端測試集合。

• 前後端分離，有專門的介面測試人員來保證介面功能的正確性。此時作為前端測試人員，只需要保證介面返回資料正確時，頁面顯示正確；介面返回資料異常時，頁面顯示正確；呼叫介面的資料正確即可；
• 前後端半分離，介面也做測試，但是是使用自動化工具，保證基本的引數正確性與通暢性，而對於介面的邏輯需要前端配合測試。

此時作為前端測試人員，就需要了解介面的實現邏輯，如資料的處理邏輯，儲存結構等。據此來設計前端測試用例，必要時也要繞開前段，直接呼叫介面模擬前段測試。

綜上所述，對業務邏輯的理解程度，取決於業務的結構，在理解了業務邏輯後，補充對應需求點的業務邏輯測試點。
4、區分頁面測試和業務邏輯類測試
頁面層級的測試遵循以下的方法：
• 整體介面測試：就是去驗證整體的介面是否和設計圖一致；
• 介面元素測試
• 控制元件操作驗證：如對控制元件能否操作、操作是否正常的驗證；

業務邏輯（功能）等級的測試遵循以下方法：
• 任何情況下都必須使用邊界分析法，出問題最多的就在邊界值；
• 必要時用等價類劃分方法補充一些測試用例；
• 用錯誤推測法再追加一些測試用例；
• 對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例
三、測試用例的方法
用例測試方法：基於需求的設計方法、等價類劃分法、邊界值分析、場景法 、錯誤推斷、因果圖、正交排列、探索式測試
1、需求分析法
RBT( Requirements-Based Testing)是基於需求的測試方法，按照需求去設計測試用例。有多細緻的需求就有多細緻的測試用例. 基於需求的測試是一種最根本的軟體測試，重點關注以下兩大關鍵問題。
（1）驗證需求是否正確、完整、無二義性，並且邏輯一致。
（2）要從“黑盒”的角度，設計出充分並且必要的測試集，以保證設計和程式碼都能完全符合需求。
2、等價類劃分法
等價類劃分法將所有可能的輸入資料（有效和無效）劃分成若干個等價類，然後找中找出具有代表性的資料進行測試。

a.定義有效類和無效類：
（1）資料劃分
（2）資料型別
（3）是否為空

b.等價類劃分原則：
（1）有效類儘可能多覆蓋
（2）無效類只覆蓋一個

c.使用場景:輸入條件（取值範圍/值個數；必須值集合；布林值；一組處理值；必須遵守的規則；再細分更小等價類；）

d.舉例：

3、邊界值分析法
a.邊界值是對等價劃分的一個補充，邊界值一般是去等價類的邊緣去尋找。

b.取值原則：正好等於、剛剛大於、剛剛小於邊界值的資料作為測試。

c.需特殊考慮0和負數。

d.使用場景：輸入+輸出都需要考慮（值的範圍；值個數；有序集合；內部資料結構；分析規格說明；）

e.舉例：

4、場景法
a.將業務流程場景化，測試用例遍歷場景，驗證系統功能的正確性；

b.場景法的原則（正常流+分支流）：
正常路徑；
根據每個判斷，去找另一個出口；
確定出錯之後還能正常操作，再多走一個步驟；

c.注意事項：場景法的重點是流程測試，每個流程一個測試用例驗證即可，還需對單個功能進行測試。

d.使用場景：

e.舉例：

5、錯誤推斷法
錯誤猜測法是經驗豐富的測試人員喜歡使用的一種測試方法。錯誤猜測法只適用於其他測試用例設計法，設計完測試用例之後，進行測試用例的補充。

（1）基於經驗和直覺，找出程式中你認為可能出現的錯誤，有針對性地設計測試用例。
（2）經驗可能來自於在對某項業務的測試較多，也可以來自於售後使用者的反饋意見
（3）從故障管理庫中整理bug。

使用場景：任何測試、任何情景下都會用到的方法。

舉例：數字輸入驗證，分別輸入數字(正數、負數、零值、單精度、雙精度)、字串、空白值、空值、臨界數值；不合法的輸入，系統給出必要的判斷提示資訊；

6、判定表法
定義：分析和描述若干條件下 ，被測物件針對這些輸入所做出的一些迴應，在遇到複雜業務邏輯時可以利用該表理清業務邏輯關係

重要概念：條件樁：需求規格說明定義的被測物件輸入、條件項
動作樁：輸入所做出的迴應、動作項
規則：動作項和條件項組合在一起，形成的業務邏輯處理規則。

使用場景：控制類和遊戲。優點是能把複雜的問題按各種可能的情況一一列舉出來，簡明而易於理解，也可避免遺漏。缺點是不能表達重複執行的動作，例如迴圈結構。

7、因果法
表示輸入和輸出關係的一種邏輯圖.使用場景：當需求有多個輸入時候，並且需求的輸出和輸入相關，我們就用因果圖法。

恆等：如果原因為真，那麼結果必定為真。
與：只有兩個原因都為真，結果才為真。
或：只要有一個原因為真，結果就為真。
非：原因為假，結果為真。

因果圖設計測試用例的步驟：
分析所有輸入輸出的可能
找出輸入和輸出之間的對應關係、
畫出因果圖
把因果圖轉為判定表
把判定表對應到每一個測試用例

使用場景：必須考慮輸入條件的各種組合（一種適合於描述多種條件的組合、相應產生多個動作的形式來進行設計）；
8、正交實驗法
就是在各因素互相獨立的情況下，設計出一種特殊的表格，找出能以少數替代全面的測試用例（查詢條件）雖然說是特殊的表格，實際表現形式跟一般的表格沒有什麼區別，正交表的主要特徵是，“均勻分佈，整齊劃一”，正是因為“均勻”的，所以才能以少數代替全部。

正交法設計測試用例的步驟：
有哪些因素（變數）
每個因素有哪幾個水平（變數的取值）
選擇一個合適的正交表
把變數的值對映到表中
把每一行的各因素水平的組合作為一個測試用例
加上你認為可疑且沒有在表中出現的用例組

使用場景：必須考慮輸入條件的各種組合（從大量的資料中挑取適量、有代表性的點，合理有效的測試

9、探索式測試法
探索式測試法：無限創意的測試點，永無止境的探索測試；我們要在測試的最前沿發揮洞察力、技術及應變措施，找出產品的缺陷；

分析思路：
區域性探索式測試；全域性探索式測試；混合探索式測試；

使用場景：任何測試、任何情景下都會用到的方法。像漫遊一樣，自由地尋找軟體中的缺陷，軟體測試的未來必然有探索式測試。

四、測試用例方法的選擇
等價類劃分法，輸入條件的劃分（提高測試最有效的方法）；
任何情況都使用邊界值分析法（發現程式錯誤的能力最強）；
用錯誤推斷法去追加測試用例；
使用場景法儘可能覆蓋用例.