軟件測試用例

1.測試用例的概念和作用

1.1.引言

對一個測試工程師來說,測試用例的設計編寫是一項必須掌握的能力，但有效的設計和熟練的編寫測試用例卻是一個十分復雜的技術，測試用例編寫者不僅要掌握軟件測試技術和流程，而且要對整個軟件不管從業(yè)務，還是對軟件的設計、程序模塊的結構、功能規(guī)格說明等都要有透徹的理解。

測試的設計方法不是單獨存在的，具體到每個測試項目里都有很多種方法，每種類型都有各自的特點。

1.2. 測試用例的定義：

1.2.1.什么是測試用例？

測試用例是執(zhí)行測試的依據，把測試系統(tǒng)的操作步驟用文檔的形式描述出來。

任意的測試用例都含有

用例編號所屬模塊執(zhí)行條件執(zhí)行條件操作步驟和數據預期結果實際結果是否通過測試人版本備注

1郵箱登錄Windows10操作系統(tǒng)，IE11瀏覽器(1)輸入郵箱地址

(2)輸入用正確戶名“123”，輸入錯誤密碼

(3)單擊登錄按鈕查看是否成功

(1)郵箱頁面能正常打開

(2)用戶名和密碼可以被正確輸入

(3)郵箱登錄不成功，提示用戶名和密碼錯誤

（1）測試用例是為達到最佳的測試效果或高效的揭露隱藏的錯誤，而精心設計的少量測試數據，包括測試輸入、執(zhí)行條件和預期的結果，實際結果

（2）測試用例是執(zhí)行的最小實體。

（3）測試用例是測試工作的指導，是軟件測試的必須遵守的準則，更是軟件測試質量穩(wěn)定的根本保障

1.2.2.測試用例的特征：

1、正確性：測試用例最好是要求輸入用戶實際數據已驗證系統(tǒng)是否滿足需求規(guī)格說明書的需求，并且測試用例中的測試的應保證至少覆蓋需求規(guī)格說明書中的各項功能。

2、完整性：一些基本功能，如有遺漏，那是不可原諒的。

3、準確：按測試用例輸入實施測試后，要能根據測試用例描述的輸出得出正確的結論，不能出現(xiàn)模糊不清的語言。

4、清晰、簡潔：好的測試用例描述清晰，每一步都應有相應的作用，有很強的的針對性，不應出現(xiàn)一些無用的操作步驟。

5、可維護性：由于軟件開發(fā)過程中需求變更等原因的影響，常常對測試用例進行修改、增加、刪除等，以便測試用符合相應測試要求。

6、適應性：測試用例應該適合特定的測試環(huán)境以及符合整個團隊的測試水平。

7、可重復性：要求不同測試者在同樣的測試環(huán)境下使用同樣測試用例都能得出相應結論。

8、可追溯性、可移植性

1.3.編寫測試用例的好處

1.1.3.測試用例的作用：

在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。

測試用例的使用令軟件測試的實施重點突出、目的明確。

在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強度、縮短項目周期。

檢驗軟件是否滿足客戶需求、體現(xiàn)一個測試人員的工作量、展現(xiàn)測試用例的設計思路

功能模塊的通用化和復用化使軟件易于開發(fā)，而相對于功能模塊的測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。

2.需求分析

2.1.什么是需求？

客戶的需要的東西以及對東西的要求

2.2.需求的種類有什么？

用戶需求：關注系統(tǒng)是否滿足用戶習慣

行業(yè)業(yè)務需求（界面提示信息為行業(yè)術語，處理和操作模式為行業(yè)從業(yè)人員習慣模式等）

實際使用環(huán)境需求（網絡帶寬，速率，斷電數據備份，軟件部署設置等）

操作使用需求（類似快捷鍵，緊急關閉，數據恢復保護，回退機制，安裝兼容性，語言環(huán)境等）

用戶需求引發(fā)的測試需求（按軟件測試質量模型進行劃分）

功能需求：關注系統(tǒng)是否滿足功能要求

3.測試用例的設計方法和編寫

3.1.如何設計測試用例？

對各個功能模塊進行測試點分析提取測試點再對測試點進行用例編寫

比如對PC端QQ賬號的登錄模塊，提取測試點就有：

image.png

①正常登陸 ②賬號為空時點擊登錄 ③密碼為空時點擊登錄 ④賬號密碼都為空時點擊 登錄 ⑤密碼錯誤時點擊登錄 ⑥找回密碼功能是否有效 ⑦記住密碼功能是否有效 ⑧ 自動登錄功能是否有效9 多個qq號登錄10.二維碼掃描登錄

3.2.編寫測試用例該注意什么？

根據產品規(guī)格，測試基本功能；

考慮設計一般用戶（非專業(yè)人員）的使用方案；

考慮設計稀有或特殊的使用方案；

與系統(tǒng)其他組成部分的配合（如FAX和上網可能要用到MODEM，？測試中考慮對設- 備的共享）；

考慮特殊情況（如內存和硬件的沖突等）；

設計極端情況（如內存泄漏、破壞性測試等）；

好的測試用例集能花費最小的代價（人力、物力、財力、時間）做最好的測試。

3.3.測試用例的4個特性

代表性：能夠代表并覆蓋各種合理的和不合理、合法的和不合法的、邊界的和越界的以及極限的輸入數據、操作等。

針對性：對程序中的可能存在的錯誤有針對性地測試

可判定性：測試執(zhí)行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果

可重現(xiàn)性：對同樣的測試用例，系統(tǒng)的執(zhí)行結果應當是相同的。

第一個數字 和 第二個數字都為 0-10 之間的數 計算結果

？ + ？ = ？

1-10 1 -10 正向測試用例

反向

3.4.測試用例通常包括以下幾個組成元素：

測試用例編號 測試用例名稱 測試用例設計者 軟件版本號 測試目的

參考信息 測試環(huán)境 輸入數據 操作步驟 預期結果 測試結果 測試功能模塊

3.5.測試用例示例

image.png

image.png

筆試題： 你用到的測試方法/測試策略有哪些？

等價類劃分 邊界值 因果圖 場景法 正交表

4.編寫測試用例的基本方法

4.1.等價類劃分法

1.1.4.概念

等價類劃分是把所有可能輸入的數據分為若干個區(qū)域，然后從每個區(qū)域中取少量有代表性的數據進行測試即可。

等價類 ：何為等價類，某個輸入域的集合，在這個集合中每個輸入條件都是等效的。

一般可分為有效等價類和無效等價類

比如：在一個系統(tǒng)中，填寫一個多少歲的未成年人數學考了多少分（假設成年人年齡為x,0

那么年齡按照等價類劃分可分為x<0,018,有效等價類是018

數學成績按照等價類劃分可分為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之間呢，窮舉測試肯定不可能的。由此引入了等價類劃分思想。

等價類劃分為：

有效等價類：指符合《需求規(guī)格說明書》，輸入合理的數據集合

無效等價類：指不符合《需求規(guī)格說明書》，輸入不合理的數據集合

image.png

我們將輸入域分成了一個有效等價類（1～100）和兩個無效等價類（<1和>100），并為每一個等價類進行編號，然后我們就可以從每一個等價類中選取一個代表性的數據來測試，設計如下表所示的測試用例

image.png

在任意文本輸入框中可以填寫的 字符類型 中文 英文 特殊符號 空格 數字

1.1.6.練習案例:

image.png

劃分等價類并編號,下表為等價類劃分的結果

image.png

4.2.邊界值法

定義：邊界值分析是取稍高于或稍低于邊界的一些數據進行測試。

原因：程序開發(fā)循環(huán)體時的取數可能會因為<,<=搞錯。

比如下面代碼：

//有效等價劃分? ? -1? 0? ? 100? 101? for(int i=0;i<100;i++){int j=i+1;System.out.println("循環(huán)第“+j+"次")//循環(huán)地做某件事情}

這里的程序是循環(huán)了100次，所以會做100次;

如果程序員不小心，把i <100寫成i <= 100，則會溢出，這時候邊界值檢查是一個很好的測試方法。

比如：在一個系統(tǒng)中，填寫一個多少歲的成年人數學考了多少分（假設成年人年齡為x,0

根據上面的等價類劃分法我們可知，年齡的有效等價類是0

數學成績的,有效等價類是0<=y<=100，所以邊界值就是-1，0，100，101

對數據進行軟件測試，就是在檢查用戶輸入的信息、返回的結果以及中間計算結果是否正確。即使最簡單的程序要處理的數據量也可能極大，使這些數據得以測試的技巧是，根據一些關鍵的原則進行等價類的劃分，以合理減少測試用例，這些關鍵的原則是：邊界條件，次邊界條件、空值和無效數據。

1.1.7.確定邊界值的方法（）

確定邊界情況（輸入或輸出等價類的邊界）

選取正好等于、剛剛大于或剛剛小于邊界值作為測試數據

輸入要求是1 ～ 100之間的整數，因此自然產生了1和100兩個邊界，我們在設計測試用例的時，要重點考慮這兩個邊界問題。

image.png

注明:邊界值不是從每個等價類中挑一個作為代表，而是把每個等價類的邊界都進行測試。

4.3. 因果圖法

1.1.8.概念

因果圖法比較適合輸入條件比較多的情況，測試所有的輸入條件的排列組合。所謂的原因就是輸入，所謂的結果就是輸出。

1.1.9. 因果圖基本圖形符號

恒等：若原因出現(xiàn)，則結果出現(xiàn)；若原因不出現(xiàn)，則結果不出現(xiàn)。

非（～）：若原因出現(xiàn)，則結果不出現(xiàn)；若原因不出現(xiàn)，則結果出現(xiàn)。

或（∨）：若幾個原因中有一個出現(xiàn)，則結果出現(xiàn)；若幾個原因都不出現(xiàn)，則結果不出現(xiàn)。

與（∧）：若幾個原因都出現(xiàn)，結果才出現(xiàn)；若其中有一個原因不出現(xiàn)，則結果不出現(xiàn)。

image.png

1.1.10.因果圖的約束符號

E（互斥）：表示兩個原因不會同時成立，兩個中最多有一個可能成立

I（包含）：表示三個原因中至少有一個必須成立

O（惟一）：表示兩個原因中必須有一個，且僅有一個成立

R（要求）：表示兩個原因，a出現(xiàn)時，b也必須出現(xiàn)，a出現(xiàn)時，b不可能不出現(xiàn)

M（屏蔽）：兩個結果，a為1時，b必須是0，當a為0時，b值不定

image.png

1.1.11.因果圖測試用例

例如：有一個處理單價為2.5元的盒裝飲料的自動售貨機軟件。若投入2.5元硬幣，按“可樂”、“啤酒”、或“奶茶”按鈕，相應的飲料就送出來。若投入的是3元硬幣，在送出飲料的同時退還5角硬幣。

分析這一段說明，我們可列出原因和結果

原因(輸入)：

投入2.5元硬幣；

投入3元；

按“可樂”按鈕；

按“啤酒”按鈕；

按“奶茶”按鈕。

中間狀態(tài)： ① 已投幣；②已按鈕

結果(輸出)：

退還5角硬幣；

送出“可樂”飲料；

送出“啤酒”飲料；

送出“奶茶”飲料；

image.png

判定表法

image.png

image.png

4.4.場景法

4.4.1. 場景法基本原理

原理：

現(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的。測試時，可以比較生動地描繪出事件觸發(fā)時的情景，有利于測試設計者設計測試用例，同時使測試用例更容易理解和執(zhí)行。

基本流：軟件功能按照正確的事件流實現(xiàn)的一條正確的流程。

備選流：除了基本流之外的各支流，包含多種不容情況。

image.png

如圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執(zhí)行，然后重新加入基本流中（如備選流1和3）；也可能起源于另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。

場景模板

遵循上圖中每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，可以確定以下用例場景：

場景 1 基本流

場景 2 基本流 備選流 1

場景 3 基本流 備選流 1 備選流 2

場景 4 基本流 備選流 3

場景 5 基本流 備選流 3 備選流 1

場景 6 基本流 備選流 3 備選流 1 備選流 2

場景 7 基本流 備選流 4

場景 8 基本流 備選流 3 備選流 4

注：為方便起見，場景 5、6 和 8 只描述了備選流 3 指示的循環(huán)執(zhí)行一次的情況。

注意

場景中必須有基本流

場景中必須有內容從用例開始，到用例結束。

4.4.2. 銀行案例ATM

個人標識號 (PIN＝personal identification number )，用于保護智能卡免受誤用的秘密標識代碼。PIN 與密碼類似，只有卡的所有者才知道該 PIN。只有擁有該智能卡并知道 PIN 的人才能使用該智能卡

流.png

image.png

第一次測試中，根據測試計劃，我們需要核實提款用例已經正確地實施。此時尚未實施整個用例，只實施了下面的事件流：

基本流-提取預設金額（100 元、200元、500元、1000元）

備選流2 - ATM 內沒有現(xiàn)金

備選流3 - ATM 內現(xiàn)金不足

備選流4 - PIN 有誤

備選流5 - 帳戶不存在/帳戶類型有誤

備選流6 - 帳面金額不足

image.png

對于這7個場景中的每一個場景都需要確定測試用例?？梢圆捎镁仃嚮驔Q策表來確定和管理測試用例。

從確定執(zhí)行用例場景所需的數據元素入手構建矩陣。然后，對于每個場景，至少要確定包含執(zhí)行場景所需的適當條件的測試用例。

下面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。

本示例中，對于每個測試用例，存在一個測試用例ID、條件（或說明）、測試用例中涉及的所有數據元素（作為輸入或已經存在于數據庫中）以及預期結果。

image.png

4.4.3. 設計用例步驟

根據說明，描述出程序的基本流和各項備選流

根據基本流和各項備選流生成不同的場景

對每一個場景生成響應的測試用例

對生成的所有測試用例重新復審，去掉多余的測試用例

測試用例確定后，對每一個測試用例確定測試數據值

注意：

場景法使用與解決業(yè)務流程清晰的系統(tǒng)或功能。

每一個場景，都是一個測試用例。

4.5.錯誤推測法

錯誤猜測法是測試經驗豐富的人喜歡使用的一種測試用例設計方法。

一般這種方法是基于經驗和直覺推測程序中可能發(fā)送的各種錯誤，有針對性地設計。只能作為一種補充。

例如，測試手機終端的通話功能，可以設計各種通話失敗的情況來補充測試用 例：

無SIM 卡插入時進行呼出（非緊急呼叫）

插入已欠費SIM卡進行呼出

射頻器件損壞或無信號區(qū)域插入有效SIM卡呼出

網絡正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）

網絡正常，插入有效SIM卡，使用“快速撥號”功能呼出設置無效號碼的數字

技巧：最重要的是要思考和分析測試對象的各個方面，多參考以前發(fā)現(xiàn)的bug的相關數據，總結的經驗，個人多考慮異常的情況、反面的情況、特殊的輸入，以一個攻擊者的態(tài)度對待程序，就能設計出比較完善的測試用例來。

4.6.正交表法

概述

日本人提出

使用工具：正交表

正交實驗法就是利用排列整齊的表 -正交表來對試驗進行整體設計、綜合比較、統(tǒng)計分析，實現(xiàn)通過少數的實驗次數找到較好的生產條件，以達到最高生產工藝效果。

這種試驗設計法是從大量的試驗點中挑選適量的具有代表性的點，利用已經造好的表格—正交表來安排試驗并進行數據分析的方法。

正交表能夠在因素變化范圍內均衡抽樣，使每次試驗都具有較強的代表性，由于正交表具備均衡分散的特點，保證了全面實驗的某些要求，這些試驗往往能夠較好或更好的達到實驗的目的。

正交實驗設計包括兩部分內容：第一，是怎樣安排實驗；第二，是怎樣分析實驗結果。

應用場景

在一個界面中有多個控件，每個控件有多個取值，控件之間可以相互組合，不可能（也沒有必要）為每一種組合編寫一條用例，如何使用最少最優(yōu)的組合進行測試?！慌帕蟹?/p>

判定表

因果圖也是考慮控件組合，但是組合數量較少（一般不會超過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

image.png

image.png

使用正交設計助手

（1）下載解壓正交設計助手

（2）文件新建工程

（3）實驗新建實驗

①實驗說明

實驗說明.png

②選擇正交表

選擇正交表.png

③因素與水平

因素與水平.png

④確定

結果.png

正交表測試用例設計方法的特點是什么？

1、用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；

2、對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力 的；

3、體的環(huán)境下，正交表一般都很難做的。大多數，只在系統(tǒng)測試的時候使用此方法。

5. 測試用例的評審和變更

（1）變更背景

測試用例并非一成不變。如果軟件修改之后發(fā)生變化，或者需求發(fā)生變更，那么測試用例便不再滿足當前版本軟件的測試需求，由此需要進行修改和變更操作。

（2）測試用例評審

首先要清楚評審的定義，是測試組內部的評審，還是項目組內部的評審。評審的定義不同，內容也不會相同。

如果是測試組內部的評審，應該著重于：

測試用例本身的描述是否清晰，是否存在二義性；

是否考慮到測試用例的執(zhí)行效率.往往測試用例中步驟不斷重復執(zhí)行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下；

是否針對需求跟蹤矩陣，覆蓋了所有的軟件需求；

是否完全遵守了軟件需求的規(guī)定。這并不一定的，因為即使再嚴格的評審，也會出現(xiàn)錯誤，應具體情況具體對待。

如果是項目組內部的評審，也就需要評審委員會來做了，角度不同，評審的標準也不同。比如收集客戶需求的人員注重你的業(yè)務邏輯是否正確，分析軟件需求規(guī)格的人注重你的用例是否跟規(guī)格要求一致，開發(fā)負責人會注重你的用例中對程序的要求是否合理。

測試用例的評審能夠使用例的結構更清晰，覆蓋的用戶場景更全面對于測試工程師來說也是一個快速提高用例設計能力的過程。

1、需要評審的原因

測試用例是軟件測試的準則，但它并不是一經編制完成就成為準則。由于用例開發(fā)人員的設計經驗和對需求理解的深度各不相同，所以用例的質量難免會有不同程度的差異。

2、進行評審的時機

一般會有兩個時間點。第一，是在用例的初步設計完成之后進行評審第二是在整個詳細用例全部完成之后進行二次評審。如果項目時間比較緊張，盡可能保證對用例設計進行評審，提前發(fā)現(xiàn)其中的不足之處。

3、參與評審人員

這里會分為多個級別進行評審。

1)部門評審，測試部門全體成員參與的評審。

2)公司評審，這里包括了項目經理、需求分析人員、架構設計人員、開發(fā)人員和測試人員。

3)客戶評審，包括了客戶方的開發(fā)人員和測試人員。這種情況在外包公司比較常見。

4、評審內容

評審的內容有以下幾個方面

1)用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。

2)優(yōu)先極安排是否合理。

3)是否覆蓋測試需求上的所有功能點。

4)用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數據和期待結果是否清晰、正確期待結果是否有明顯的驗證方法。

5)是否已經刪除了冗余的用例。

6)是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數量，畢竟一個健壯的軟件，其中80%的代碼都是在"保護"20%的功能實現(xiàn)。

7)是否從用戶層面來設計用戶使用場景和使用流程的測試用例。

8)是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。

個人認為，一個"健康"的測試用例至少要通過前5個標準。

5、評審的方式

1)召開評審會議。與會者在設計人員講解之后給出意見和建議，同時進行詳細的評審記錄。

2)通用郵件與相關人員溝通

3)通用IM工具直接與相關人員交流

方式只是手段，得到其它人員對于用例的反饋信息才是目的。

無論采用那種方式，都應該在溝通之前把用例設計的相關文檔發(fā)送給對方進行前期的學習和了解，以節(jié)省溝通成本。

6、評審結束標準

在評審活動中會收集到用例的反饋信息，在此基礎上進行用例更新，直到通過評審。

6. 測試用例基本思路

QQ郵箱登錄模塊

QQ郵箱登錄.png

（1）登錄模塊的需求文檔

賬號：由3~18位英文字符、數字、點、減號、下劃線組成

密碼：由6-18位，不能為空，至少包含英文、數字、符號中的兩種

（2）基本功能測試點分析

根據需求圖看到QQ郵箱登錄界面主要有賬號的密碼組成，同樣可以使用正交表分析法來設計。

用戶名賬號

正確正確

正確錯誤

錯誤正確

錯誤錯誤