常用測試用例設計方法
1、等價類划分
2、邊界值分析方法
3、因果圖方法
4、正交實驗設計方法
5、功能圖分析方法
6、錯誤推測法
7、需求文檔轉化法
8、隨機測試
9、對象屬性分析法
等價類划分：
1）輸入條件中規定了輸入數據的取值范圍，可分為一個有效等價類和另兩個無效等價類
2）輸入條件中規定了輸入數據的個數，可分為一個有效等價類和兩個無效等價類
3）若規定了輸入數據必須遵循的原則，則可分為一個有效等價類和若干個無效等價類
4）若輸入條件中規定了輸入數據的一組取值，且軟件對不同的輸入值對應有不同的處理，則每個允許值構成一個有效的等價類，其他值構成一個無效的等價類
5）若規定輸入為整數，則正整數、負整數。零構成有效三個等價類，小數構成無效的等價類
等價類划分例子：
邊界值分析方法：
意義：測試輸入數據規則的邊界是否有問題
較常用
1)若輸入條件規定了取值范圍，則選擇恰好落在邊界上和處在邊界內、邊界外的測試值
2）若規定了輸入數據的個數，則選擇最小個數，比最小個數多1、少1，比最大個數多1少1等幾種測試情況作為測試時輸入數據的個數
3）若輸入數據為有序集合，則選擇有序集合中的第一個、最后一個以及越界輸入作為測試用例
邊界值分析方法例子：
1）對16-bit位整數而言，32767和-32768是邊界值
2）屏幕上光標在最左上和最右下位置
3）報表的第一行和最后一行
4）數組元素的第一個和最后一個
5)循環的第0，1和倒數第1次和倒數第2次
因果圖：
等價類和邊界值方法，着重考慮輸入條件，沒有考慮輸入條件之間的聯系和相互組合，若考慮輸入條件中的相互組合可能會產生一些新的情況，將等價類和邊界值的方法做一些組合來考慮，最終生成一個判定表
因果圖方法最終生成的就是判定表，它時候檢查程序入條件中的各種組合情況
根據需求分析中的條件來進行一些組合來生成判定表
因果圖——生成判定表
1）分析軟件規格說明書描述中，那些是原因（輸入條件和輸入條件的等價類），那些是結果（即輸出條件），並給每個原因和結果賦予一個標志符
2）分析軟件規格說明書描述中的語義，找出原因與結果之間、原因與原因之間的對應關系，根據這些關系，畫出因果圖
3）由於語法與環境限制，有些原因與原因之間、原因與結果之間的組合情況不可能出現，在因果圖上用一些記號表明約束或者限制條件
4）把因果圖轉換成判定表
5)把判定表的每一列作為依據拿出來設計測試用例
判定表的例子;
s
正交實驗設計方法：
實驗里面有很多數據，數據量比較大，只挑選一些有代表性的點來進行科學實驗，即從大量的元素中抽取一些代表性的元素來進行測試
功能圖分析方法：狀態遷移圖和邏輯功能模型構成的，主要關注輸入條件和輸出之間的對應關系
功能圖用在白盒測試比較多
功能圖方法要用到邏輯覆蓋和路徑測試的概念和方法，其屬於白盒測試中方法的內容。邏輯覆蓋是以程序中邏輯結構為基礎的測試用例設計方法，該方法要求對程序邏輯結構有較清楚的了解，由於覆蓋測試的目標不同，邏輯覆蓋分為：
1）語句覆蓋:程序中每條語句至少執行一次
2）條件覆蓋
一個判定語句中有多個條件組合而成的復合判定。構成一組測試用例，使得每一條判定語句每一個邏輯條件的值至少滿足一次
3）判定覆蓋
設計足夠的測試用例，使得程序中的每一個判定至少獲得一次“真值”或者“假值”，或者說使得程序中的每一個分支“真值”分支或者“假值”分支至少執行一次，因此判定覆蓋又稱分支覆蓋。
4）條件組合覆蓋
設計足夠多的測試用例 ，使得每個判定中條件的各種組合至少出現一次，顯然滿足多條件覆蓋的測試用例一定滿足判定覆蓋、條件覆蓋和條件組合覆蓋。
面試問題：
語句覆蓋什么意思？
程序中的每條語句都至少被執行一次，表示語句被執行過
什么叫做判定覆蓋？條件覆蓋？條件組合覆蓋？
判定覆蓋：
程序中有if else時，至少執行一次取True和取False時，都能覆蓋到，能執行正確
條件覆蓋：
多個條件組合，至少每個條件都被觸發過一次
條件組合覆蓋：
所有條件的排列組合都遍歷到，所有的取值都做組合，工作量海量（工作中一般不會做）
流程圖
輸入條件進行判斷，yes的時候是一種情況，no的時候是另外一種分支情況，那么邏輯圖里面所有的分支都要覆蓋到
錯誤推測法
根據經驗和直接來推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法
猜測哪有錯，程序中有可能出現錯誤的地方，基於代碼評審來看
根據經驗推測可能出現的錯誤
1）程序中所有可能出現的錯誤
2）容易發生錯誤的特殊情況
3）以前產品測試中曾經發現的錯誤
建議：
知識積累和分享：
總結常見的錯誤，常見bug類型，分析總結錯誤的原因
面試問題：
你覺得測試的項目中有哪些最嚴重的bug?
需求文檔轉化法
所見即所得的思想：
1）將需求文檔描述中所有的文字信息，全部轉化成測試用例
2）所有的示意圖、流程圖、狀態圖直接轉成測試用例
3）所有項目需求達成口頭的共識，需求確認的郵件溝通信息，直接轉成測試用例
隨機測試法：條件比較多的情況，選擇一些代表性條件組合來測試
組合
隨意測試，完全不考慮需求和測試用例，站在用戶的角度對產品進行試用
適用的場景：
1）之前設定的測試用例已經完全執行完畢
2）海量組合條件無法一一遍歷的時候
對象屬性分析法：
被測系統的中的元素被定義為一個對象，並且給這個對象設定關聯的相關屬性和狀態，並且不同對象的相關屬性和狀態進行不同的組合，以擴展測試用例
例如：
文件
屬性：
大小、路徑（本地、網絡）、文件名、文件編碼（文本、二進制？）、文件內容、文件讀寫屬性、文件共享屬性
溝通：
測試一個產品前，根據獲得的信息，想像一下這個產品是什么樣子的，在腦子里生成產品的一個狀態，包括頁面，流程 的一個理想的狀態
都想清楚了，寫測試用例，寫好用例，再和開發的產品進行比對，和自己想的樣子比對，是否滿足產品發布的要求，如果發現產品實現和自己想象的不一樣，那么一定是有問題，這樣可以做很多的事情。
溝通：
如果提供一些文檔，我就會讀懂文檔的每一句話，如果有說的不完全的地方，就會來做提問，以文檔方式發給相關人員來進行確認問題或者有二意性的東西，這樣有一個基本測試邏輯的一些東西
需求變更機制：
