1. 測試用例的概念和作用
1.1. 引言
對一個測試工程師來說,測試用例的設計編寫是一項必須掌握的能力，但有效的設計和熟練的編寫測試用例卻是一個十分復雜的技術，測試用例編寫者不僅要掌握軟件測試技術和流程，而且要對整個軟件不管從業務，還是對軟件的設計、程序模塊的結構、功能規格說明等都要有透徹的理解。
測試的設計方法不是單獨存在的，具體到每個測試項目里都有很多種方法，每種類型都有各自的特點。
1.2. 測試用例的定義：
1.1.1. 什么是測試用例？
測試用例是執行測試的依據，把測試系統的操作步驟用文檔的形式描述出來
（1）測試用例是為達到最佳的測試效果或高效的揭露隱藏的錯誤，而精心設計的少量測試數據，包括測試輸入、執行條件和預期的結果，實際結果
（2）測試用例是執行的最小實體。
（3）測試用例是測試工作的指導，是軟件測試的必須遵守的准則，更是軟件測試質量穩定的根本保障
1.1.2. 測試用例的特征：
1、有效性：測試用例的能夠被使用，且被不同人員使用測試結果一致
2、可重復性：良好的測試用例具有重復使用的功能。(回歸測試)
3、易組織性：好的測試用例會分門別類地提供給測試人員參考和使用(功能、性能、易用分類編號)
4、清晰、簡潔：好的測試用例描述清晰，每一步都應有相應的作用，有很強的的針對性，不應出現一些無用的操作步驟。
5、可維護性：由於軟件開發過程中需求變更等原因的影響，常常對測試用例進行修改、增加、刪除等，以便測試用符合相應測試要求。
1.3. 編寫測試用例的好處：
1.1.3. 測試用例的作用：
在開始實施測試之前設計好測試用例，可以避免盲目測試並提高測試效率。
測試用例的使用令軟件測試的實施重點突出、目的明確。
在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。
檢驗軟件是否滿足客戶需求、體現一個測試人員的工作量、展現測試用例的設計思路
1.4. 測試用例的4個特性
代表性：能夠代表並覆蓋各種合理的和不合理、合法的和不合法的、邊界的和越界的以及極限的輸入數據、操作等。
針對性：對程序中的可能存在的錯誤有針對性地測試
可判定性：測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果
可重現性：對同樣的測試用例，系統的執行結果應當是相同的。
1.5. 測試用例通常包括以下幾個組成元素：
用例編號、測試模塊、用例標題、用例級別、測試環境、測試輸入、執行操作、預期結果,實際結果….
1.6測試用例示例:
2. 編寫測試用例的基本方法
2.1. 等價類划分法
應用場景：多用於輸入框
1.1.4. 概念
有效，無效
等價類划分是指分步驟地把海量（無限）的測試用例集減得很小，但過程同樣有效。
等價類 ：何為等價類，某個輸入域的集合，在這個集合中每個輸入條件都是等效的。
一般可分為有效等價類和無效等價類
比如：一個青少年考試的分數（備注13-17歲為青少年）
假設青少年年齡為x,13<=x<=17,數學成績為y：0<=y<=100
那么年齡按照等價類划分可分為x<13,13<=x<=17,x>17,有效等價類是13<=x<=17，無效等價類是x<13，x>17
數學成績按照等價類划分可分為y<0,0<=y<=100,y>100,有效等價類是0<=y<=100，無效等價類是y<0，y>100
1.1.5. 示例
計算兩個1～100之間整數的和。
如果要進行完全測試，一共要設計多少個測試用例呢？
加數1有1～100共計100個取值，加數2也有1～100共計100個取值，所以他們之間的組合就有100*100=10000種組合可能，但這只是測試了正常范圍內的取值。如果用戶輸入的數據不在1～100之間呢，窮舉測試肯定不可能的。由此引入了等價類划分思想。
等價類划分為：
有效等價類：指符合《需求規格說明書》，輸入合理的數據集合
無效等價類：指不符合《需求規格說明書》，輸入不合理的數據集合
我們將輸入域分成了一個有效等價類（1～100）和兩個無效等價類（<1,>100），並為每一個等價類進行編號，然后我們就可以從每一個等價類中選取一個代表性的數據來測試，設計如下表所示的測試用
1.1.6練習案例:
划分等價類並編號,下表為等價類划分的結果
2.2. 邊界值法
一般邊界值分析是因為程序開發循環體時的取數可能會因為<,<=搞錯。
比如下面代碼
for(int i = 0;i <100; i ++)
{
int j = i+1;
System.out.println("循環第“+j+"次")//循環地做某件事情
}
這里的程序是循環了100次，所以會做100次;
如果程序員不小心，把i <100寫成i <= 100，則多循環添加一次，這時候邊界值檢查是一個很好的測試方法。
比如：在一個系統中，填寫一個多少歲的青少年考了多少分（假設成年人年齡為x,13<=x<=17,數學成績為y：0<=y<=100
根據上面的等價類划分法我們可知，年齡的有效等價類是13<=x<=17，所以邊界值就是12， 18
數學成績的,有效等價類是0<=y<=100，所以邊界值就是-1，0，100，101
對數據進行軟件測試，就是在檢查用戶輸入的信息、返回的結果以及中間計算結果是否正確。即使最簡單的程序要處理的數據量也可能極大，使這些數據得以測試的技巧是，根據一些關鍵的原則進行等價類的划分，以合理減少測試用例，這些關鍵的原則是：邊界條件，次邊界條件、空值和無效數據。
1.1.7. 確定邊界值的方法（）
選取正好等於、剛剛大於或剛剛小於邊界值作為測試數據
輸入要求是1 ～ 100之間的整數，因此自然產生了1和100兩個邊界，我們在設計測試用例的時，要重點考慮這兩個邊界問題。
[1 100] 上點1 ，100 離點 0 101所屬
(1,100) 上點 2，99 離點 1 ，100
(1,100] 上點 2，100 離點 1 ，101
2.3. 因果圖法
1.1.8. 概念:
因果圖法比較適合輸條件比較多的情況，測試所有的輸入條件的排列組合。所謂的原因就是輸入，所謂的結果就是輸出。
1.1.9. 因果圖基本圖形符號
恆等：若原因出現，則結果出現；若原因不出現，則結果不出現。
非（～）：若原因出現，則結果不出現；若原因不出現，則結果出現。
或（∨）：若幾個原因中有一個出現，則結果出現；若幾個原因都不出現，則結果不出現。
與（∧）：若幾個原因都出現，結果才出現；若其中有一個原因不出現，則結果不出現。
1.1.10. 因果圖的約束符號
E（互斥）：表示兩個原因不會同時成立，兩個中最多有一個可能成立
I（包含）：表示三個原因中至少有一個必須成立
O（惟一）：表示兩個原因中必須有一個，且僅有一個成立
R（要求）：表示兩個原因，a出現時，b也必須出現，a出現時，b不可能不出現
M（屏蔽）：兩個結果，a為1時，b必須是0，當a為0時，b值不定
1.1.11. 因果圖測試用例
例如：有一個處理單價為2.5元的盒裝飲料的自動售貨機軟件。若投入2.5元硬幣，按“可樂”、“啤酒”、或“奶茶”按鈕，相應的飲料就送出來。若投入的是3元硬幣，在送出飲料的同時退還5角硬幣。
分析這一段說明，我們可列出原因和結果
原因(輸入)：
投入2.5元硬幣；
投入3元；
按“可樂”按鈕；
按“啤酒”按鈕；
按“奶茶”按鈕。
中間狀態： ① 已投幣；②已按鈕
結果(輸出)：
退還5角硬幣；
送出“可樂”飲料；
送出“啤酒”飲料；
送出“奶茶”飲料；
判定表法
2.4. 場景法
1.1.12. 測試用例設計的思想
現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
用例場景是通過描述流經用例的路徑來確定的過程，
這個流經過程要從用例開始到結束遍歷其中所有基本流和備選流。
基本流和備選流的區別
1.1.1. 銀行案例ATM:
個人標識號 (PIN＝personal identification number )，用於保護智能卡免受誤用的秘密標識代碼。PIN 與密碼類似，只有卡的所有者才知道該 PIN。只有擁有該智能卡並知道 PIN 的人才能使用該智能卡
第一次測試中，根據測試計划，我們需要核實提款用例已經正確地實施。此時尚未實施整個用例，只實施了下面的事件流：
基本流-提取預設金額（100 元、200元、500元、1000元）
備選流2 - ATM 內沒有現金
備選流3 - ATM 內現金不足
備選流4 - PIN 有誤
備選流5 - 帳戶不存在/帳戶類型有誤
備選流6 - 帳面金額不足
對於這7個場景中的每一個場景都需要確定測試用例。可以采用矩陣或決策表來確定和管理測試用例。
從確定執行用例場景所需的數據元素入手構建矩陣。然后，對於每個場景，至少要確定包含執行場景所需的適當條件的測試用例。
下面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。
本示例中，對於每個測試用例，存在一個測試用例ID、條件（或說明）、測試用例中涉及的所有數據元素（作為輸入或已經存在於數據庫中）以及預期結果。
2.5. 錯誤推測法
錯誤猜測法是測試經驗豐富的人喜歡使用的一種測試用例設計方法。
一般這種方法是基於經驗和直覺推測程序中可能發送的各種錯誤，有針對性地設計。只能作為一種補充。
例如，測試手機終端的通話功能，可以設計各種通話失敗的情況來補充測試用 例：
1) 無SIM 卡插入時進行呼出（非緊急呼叫）
2) 插入已欠費SIM卡進行呼出
3) 射頻器件損壞或無信號區域插入有效SIM卡呼出
4) 網絡正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）
5) 網絡正常，插入有效SIM卡，使用“快速撥號”功能呼出設置無效號碼的數字
技巧：最重要的是要思考和分析測試對象的各個方面，多參考以前發現的bug的相關數據，總結的經驗，個人多考慮異常的情況、反面的情況、特殊的輸入，以一個攻擊者的態度對待程序，就能設計出比較完善的測試用例來。
2.6. 正交表法
正交實驗法就是利用排列整齊的表 -正交表來對試驗進行整體設計、綜合比較、統計分析，實現通過少數的實驗次數找到較好的生產條件，以達到最高生產工藝效果，這種試驗設計法是從大量的試驗點中挑選適量的具有代表性的點，利用已經造好的表格—正交表來安排試驗並進行數據分析的方法。正交表能夠在因素變化范圍內均衡抽樣，使每次試驗都具有較強的代表性，由於正交表具備均衡分散的特點，保證了全面實驗的某些要求，這些試驗往往能夠較好或更好的達到實驗的目的。正交實驗設計包括兩部分內容：第一，是怎樣安排實驗；第二，是怎樣分析實驗結果。
應用場景：在一個界面中有多個控件，每個控件有多個取值，控件之間可以相互組合，不可能（也沒有必要）為每一種組合編寫一條用例，如何使用最少最優的組合進行測試。——正交排列法
判定表，因果圖也是考慮控件組合，但是組合數量較少（一般不會超過20中）
公式：Ln(mk)
k是表的列數，表示控件的個數（因數個數）
m是每個控件的取值個數（因數水平）
n是表的行數，也就是需要測試組合的次數
正交表查詢地址：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm
正交排列法：http://support.sas.com/techsup/technote/ts723_Designs.txt
| 編號 |
字體 |
字符樣式
|
顏色 |
字號 |
| 1 |
仿宋 |
粗體 |
紅色 |
20 |
| 2 |
仿宋 |
斜體 |
綠色 |
30 |
| 3 |
仿宋 |
下划線 |
藍色 |
40 |
| 4 |
楷體 |
粗體 |
綠色 |
40 |
| 5 |
楷體 |
斜體 |
藍色 |
20 |
| 6 |
楷體 |
下划線 |
紅色 |
30 |
| 7 |
華文彩雲 |
粗體 |
藍色 |
30 |
| 8 |
華文彩雲 |
斜體 |
紅色 |
40 |
| 9 |
華文彩雲 |
下划線 |
綠色 |
20 |
正交表測試用例設計方法的特點是什么？
1、用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；
2、對於基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；
3、體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。
3. 測試用例的評審和變更
測試用例並非一成不變。如果軟件修改之后發生變化，或者需求發生變更，那么測試用例便不再滿足當前版本軟件的測試需求，由此需要進行修改和變更操作。
首先要清楚內部評審的定義，是測試組內部的評審，還是項目組內部的評審。評審的定義不同，內容也不會相同。
如果是測試組內部的評審，應該着重於：
1.測試用例本身的描述是否清晰；
2.是否考慮到測試用例的執行效率.往往測試用例中步驟不斷重復執行，驗證點卻不同，而且測試設計的冗(rong)余性，都造成了效率的低下；
3.是否針對需求文檔，測試用例是否覆蓋了所有的軟件需求；
4.是否完全遵守了軟件需求的規定。這並不一定的，因為即使再嚴格的評審，也會出現錯誤，應具體情況具體對待。
如果是項目組內部的評審，也就需要評審委員會來做了，角度不同，評審的標准也不同。比如收集客戶需求的人員注重你的業務邏輯是否正確，分析軟件需求規格的人注重你的用例是否跟規格要求一致，開發負責人會注重你的用例中對程序的要求是否合理。
測試用例的評審能夠使用例的結構更清晰，覆蓋的用戶場景更全面對於測試工程師來說也是一個快速提高用例設計能力的過程。
1、需要評審的原因
測試用例是軟件測試的准則，但它並不是一經編制完成就成為准則。由於用例開發人員的設計經驗和對需求理解的深度各不相同，所以用例的質量難免會有不同程度的差異。
2、進行評審的時機
一般會有兩個時間點。第一，是在用例的初步設計完成之后進行評審第二是在整個詳細用例全部完成之后進行二次評審。如果項目時間比較緊張，盡可能保證對用例設計進行評審，提前發現其中的不足之處。
3、參與評審人員
這里會分為多個級別進行評審。
1)部門評審，測試部門全體成員參與的評審。
2)公司評審，這里包括了項目經理、需求分析人員、架構設計人員、開發人員和測試人員。
3)客戶評審，包括了客戶方的開發人員和測試人員。這種情況在外包公司比較常見。
4、評審內容
評審的內容有以下幾個方面
1)用例設計的結構安排是否清晰、合理，是否利於高效對需求進行覆蓋。
2)優先極安排是否合理。
3)是否覆蓋測試需求上的所有功能點。
4)用例是否具有很好可執行性。例如用例的前提條件、執行步驟、輸入數據和期待結果是否清晰、正確期待結果是否有明顯的驗證方法。
5)是否已經刪除了冗余的用例。
6)是否包含充分的反面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍於正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼都是在"保護"20%的功能實現。
7)是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
8)是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標准步驟。
5、評審的方式
1)召開評審會議。與會者在設計人員講解之后給出意見和建議，同時進行詳細的評審記錄。
2)通用郵件與相關人員溝通
3)通用IM(辦公通訊)工具直接與相關人員交流
方式只是手段，得到其它人員對於用例的反饋信息才是目的。
無論采用那種方式，都應該在溝通之前把用例設計的相關文檔發送給對方進行前期的學習和了解，以節省溝通成本。
6、評審結束標准
在評審活動中會收集到用例的反饋信息，在此基礎上進行用例更新，直到通過評審。
