常用的測試用例設計方法：
- 等價類劃分
- 邊界值分析法
- 因果圖方法
- 正交實驗設計方法
- 功能圖分析方法
- 錯誤推測法
- 需求文檔轉化法
- 隨機測試和探索式測試
等價類劃分法
等價類劃分，指的是一種典型的、重要的黑盒測試方法。其就是解決如何選擇適當的數據子集來代表整個數據集的問題，通過降低測試的數目去實現“合理的”覆蓋，以此發現更多的軟件缺陷。
等價類劃分法將程序所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。然後從每個部分中選取具有代表性的數據做測試用例，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性。
- 有效等價類
- 有效等價類指對於程序規格說明來說，是合理的、有意義的輸入數據構成的集合；
- 有效等價類可以是一個，也可以是多個
- 等價類是輸入域的集合
- 無效等價類
- 無效等價類是指對於軟件規格說明而言，沒有意義的、不合理的輸入數據集合。
- 利用無效等價類，可以找出程序異常說明情況，檢查程序的功能和性能的實現是否有不符合規格說明要求的地方。
邊界值分析法
邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作爲對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界
- 邊界值分析不是從某等價類中隨便挑一個作爲代表，而是使這個等價類的每個邊界都要作爲測試條件。
- 應當選取正好等於，剛剛大於或剛剛小於邊界的值作爲測試數據，
因果圖/判定表法
因果圖(Cause-Effect Graph)是用於描述系統的輸入、輸出以及輸入和輸出之間的因果關係、輸入和輸入之間的約束關係。
根據系統輸入和輸出間的因果圖可以得到判定表，根據判定表產生設計測試用例。
(因果圖/判定表法比較適合測試組合數量較少的情況，一般少於20種)
- 基本圖形符號
因果關係圖, 表示的是因與果之間的關係
因：輸入條件
果：輸出結果
輸入和輸出之間的關係有下面幾類：
- 恆等
- 與(A): 只有所有條件都爲1時，結果爲1，有任何一個條件爲0（或者所有條件爲0）那麼結果爲0.
- 或(V): 只有所有條件都爲0時，結果爲0，有任何1個條件爲1（或者所有條件爲1）時，結果爲1
- 取反()
- 限制關係圖形符號
限制關係圖形要麼在因（輸入條件）之間，要麼在果（輸出結果）之間。
互斥（E-exclude）含義：可以不選，如果選的話只能選1個。
唯一（O-Only）含義：有且只有1個（必須要選，而且只能選1個）
唯一和互斥的區別：互斥可以不選，唯一必須要選1個
包含（I-include）含義：至少選1個（可以多選，不能不選，最少得選1個）
要求（R-required）含義：如果a=1 那麼要求b必須是1，反之如果a=0，那麼b值無所
屏蔽（M-masked）含義：當a=1時，b=0；當a=0，b的值有可能是1，也有可能是0
四、測試步驟
被測程序：交通一卡通充值模擬系統
步驟1：瞭解需求，找出所有的輸入條件（因）
投幣50元
投幣100元
充值50元
充值100元
步驟2：找出所有的輸出結果（果）
成功充值並退卡
找零
錯誤提示並退卡
思考一下：輸入之間的組合關係
判定表：
將因和果填入《判定表》中
|
輸入條件 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
投幣50元 |
1 |
1 |
|
|
1 |
|
|
|
|
投幣100元 |
|
|
1 |
1 |
|
2 |
|
|
|
充值50元 |
1 |
|
1 |
|
|
|
3 |
|
|
充值100元 |
|
1 |
|
1 |
|
|
|
4 |
|
|
||||||||
|
成功充值並退卡 |
1 |
|
1 |
1 |
|
|
1 |
1 |
|
找零 |
|
|
1 |
|
1 |
1 |
|
|
|
錯誤提示並退卡 |
|
1 |
|
|
1 |
1 |
|
|
根據判定表導出測試用例。實際應用中，程序會有判斷條件。其中第2，7，8三個用例，可能會存在對應的異常分支處理邏輯。
錯誤推測法
錯誤推測法是指：在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。
錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例.
隨機測試
軟件測試中除了根據測試用例和測試說明書進行測試外，還需要進行隨機測試(Ad-hoctesting)，主要是根據測試者的經驗對軟件進行功能和性能抽查。
隨機測試最好由具有豐富測試經驗的熟悉被測軟件的測試人員進行測試。對於被測試的軟件越熟悉，執行隨機測試越容易
探索式測試
探索性測試強調測試設計和測試執行的同時性，這是相對於傳統軟件測試過程中嚴格的“先設計，後執行”來說的。測試人員通過測試來不斷學習被測系統，同時把學習到的關於軟件系統的更多信息通過綜合的整理和分析，創造出更多的關於測試的主意。
優點與缺點
優點
- 鼓勵創造性。
- 可增加機會找到新的、未知的程式缺陷。
- 允許測試者花較多的時間去測試一些有趣或複雜的狀況。
- 可較快速的對受測的系統做出快速的評量。
- 可讓你知道系統是否容易使用。
- 可變通的，有彈性的。
- 它比腳本測試有趣，因爲它不會一成不變。
缺點
- 不容易被協調及調整。
- 無法對系統作全面性的測試。
- 提供有限的測試可信度。
- 非常的依靠測試者的領域知識（domain knowledge）以及技術。
- 無法保證最重要的程序錯誤一定被發現。
- 並不適用要執行很久的測試（例如執行一整個晚上的測試）
煙霧測試（SmokeTest）
煙霧測試是一組用以確定系統處於穩定狀態、所有的主要功能都具備並且能夠在 “ 正常 ” 條件下運行的測試用例。煙霧測試不能由測試小組獨立來建立；它應該是通過聯合的方式，至少是在與開發達成一致的情況下建立的。煙霧測試的目標是顯示穩定性、而不是發現系統的每個 bug ，必須在系統測試環境中運行。
煙霧測試的對象是每一個新編譯的需要正式測試的軟件版本，目的是確認軟件基本功能正常，可以進行後續的正式測試工作。煙霧測試的執行者是版本編譯人員
參考文獻：
https://zhuanlan.zhihu.com/p/55147816