『软件测试3』八大典型的黑盒测试方法已来袭,快快接住!
文章目錄
- 一、等價類劃分法
- 1、定義
- 2、等價類劃分法步驟
- 3、設計測試用例步驟
- 4、案例:學生選修課程
- 二、邊界值分析法
- 1、邊界值分析法概述
- 2、設計測試用例
- 3、邊界值設計原則
- 三、錯誤推測法
- 1、錯誤推測法概述
- 2、錯誤推測法基本思想
- 四、因果圖設計法
- 1、因果圖設計法概述
- 2、因果圖表示
- 3、約束條件
- 4、設計測試用例
- 5、優點
- 6、思考題
- 五、判定表驅動法
- 1、判定表驅動法概述
- 2、判定驅動法 —— 引例
- 3、判定表結構
- 4、判定表的建立步驟
- 5、使用判定表設計測試用例的條件
- 6、案例:工資發放
- 六、正交實驗設計法
- 1、正交實驗設計法概述
- 2、正交實驗設計法三個關鍵因素
- 3、利用正交實驗法設計測試用例的步驟
- 4、正交表的特點
- 5、總結
- 6、案例:微信Web頁面運行環境正交試驗設計
- 七、場景法
- 1、設計思想
- 2、場景的構成要素
- (1)基本流
- (2)場景流
- 3、基本流和備選流的場景說明
- 4、設計測試用例
- 5、總結
- 6、案例:在線購物案例
- 八、功能圖法
- 九、黑盒測試方法策略總結
- 1、各種測試方法選擇的綜合策略
- 2、黑盒測試的優缺點
- 十、寫在最后
一、等價類劃分法
1、定義
一個程序可以有多個輸入,等價類劃分就是將這些輸入數據按照輸入需求進行分類,將它們劃分為若干個子集,這些子集即為等價類(某個輸入域的子集合),在每個等價類中選擇有代表性的數據設計測試用例。
舉個例子:
這種方法類似于學生站隊,男生站左邊,女生站右邊,老師站中間,這樣就把師生這整個群體劃分成了三個等價類。
2、等價類劃分法步驟
(1)先從程序規格說明書中找出各個輸入條件;
(2)再為每個輸入條件劃分等價類,形成若干互不相交的子集;
(3)列出等價表
| …… | …… | …… |
3、設計測試用例步驟
等價類劃分法設計測試用例要經歷劃分等價類(列出等價類表)和選取測試用例兩步。
(1)劃分等價類
等價類是指某個輸入域的子集合。在該子集合中,各個輸入數據對于揭露程序中的錯誤都是等效的。測試代表值就等價于這一類其他值的測試。
那在劃分等價類的時候,會出現有效等價類和無效等價類,這個時候我們需要怎么判斷呢?
有效等價類就是有效值的集合,它們是符合程序要求、合理且有意義的輸入數據。
無效等價類就是無效值的集合,它們是不符合程序要求、不合理或無意義的輸入數據。
因此,在設計測試用例時,要同時考慮有效等價類和無效等價類的設計。
同時,在劃分等價類的時候,需要遵循一定的劃分原則:
等價類劃分原則:
原則1:如果輸入條件規定了取值范圍或值的個數的情況下,可以確定一個有效等價類和兩個無效等價類。
原則2:如果輸入條件規定了輸入值的集合或者規定了**“必須如何”的條件**的情況下,可以確立一個有效等價類和一個無效等價類。
原則3:如果輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類。
原則4:如果規定了輸入數據的一組值(假定n個),并且程序要對每一個輸入值分別處理的情況下,可確定n個有效等價類和一個無效等價類。
原則5:如果規定了輸入數據必須遵守的規則,可確定一個有效等價類(符合規則)和若干個無效等價類(從不同角度違反規則)。
原則6:在確知已劃分的等價類中,各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步地劃分為更小的等價類。
同一個等價類中的數據發現程序缺陷的能力是相同的,如果使用等價類中的其中一個數據不能捕獲缺陷,那么使用等價類中的其他數據也不能捕獲缺陷;同樣,如果等價類中的其中一個數據能夠捕獲缺陷,那么該等價類中的其他數據也能捕獲缺陷,即等價類中的所有輸入數據都是等效的。
(2)設計測試用例
- 在確立了等價類之后,建立等價類列表,列出所有劃分出的等價類。
- 為每個等價類規定一個唯一編號。
- 設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋的有效等價類。重復這一步,直到所有的有效等價類都被覆蓋為止。
- 設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類。重復這一步,直到所有的無效等價類都被覆蓋為止。
4、案例:學生選修課程
看到這里,不妨再做下案例分析。
案例1:每個學生可以選修1~3門課程,要求采用等價類設計測試用例。
解題思路:首先分析有效等價類和無效等價類,然后建立等價類表。
【解析】
(1)根據題干分析有效等價類和無效等價類:
? 有效等價類:選修1~3門課
? 無效等價類:沒有選修課、選修3門課以上
(2)根據分析建立等價類表:
(3)根據等價類表設計測試用例覆蓋有效等價類和無效等價類:
案例2:某連鎖酒店集團實行積分獎勵計劃,會員每次入住集團旗下酒店均可以獲得一定積分,積分由歡迎積分加消費積分構成。其中歡迎積分跟酒店等級有關,具體標準如表1-1所示;消費積分跟每次入住消費金額有關,具體標準為每消費1元獲得2積分(不足1元的部分不給分)。此外,集團會員分為優先會員、金會員、白金會員三個級別,金會員和白金會員在入住酒店時可獲得消費積分的額外獎勵,獎勵規則如表1-2所示。
表1-1 集團不同等級酒店的歡迎積分標準
表1-2 額外積分獎勵規則
該酒店集團開發了一個程序來計算會員每次入住后所累積的積分,程序的輸入包括會員級別L、酒店等級C和消費金額A(單位:元),程序的輸出為本次積分S。其中,L為單個字母且大小寫不敏感,C為取值1到6的整數,A為正浮點數且最多保留兩位小數,S為整數。
【問題一】采用等價類劃分法對該程序進行測試,等價類表如表1-3所示,請補充表中空(1)-(7)。
【問題二】根據以上等價類表設計的測試用例如下表所示,請補充表2-4中空(1)-(13)。
二、邊界值分析法
1、邊界值分析法概述
(1)邊界值分析法是對軟件的輸入或輸出邊界進行測試的一種方法,它通常作為等價類劃分法的一種補充測試。
(2)在等價類劃分法中,無論是輸入等價類還是輸出等價類,都會有多個邊界,而邊界值分析法就是在這些邊界附近尋找某些點作為測試數據,而不是在等價類內部選擇測試數據。
2、設計測試用例
設計測試用例步驟:
(1)首先劃分等價類,根據等價類劃分情況確定邊界情況。
(2)選取正好等于、剛剛大于、剛剛小于邊界的值作為測試數據,而不是選取等價類中的典型值或任意值。
3、邊界值設計原則
原則1:如果輸入條件規定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數據
原則2:如果輸入條件規定了值的個數,則用最大個數、最小個數、比最小個數少1、比最大個數多1的數作為測試數據
原則3:根據規格說明的每個輸出條件,使用前面的原則1。
原則4:根據規格說明的每個輸出條件,使用前面的原則2。
原則5:如果程序的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最后一個元素作為測試用例。
原則6:如果程序中使用了一個內部數據結構,則應該選擇這個內部數據結構邊界上的值作為測試用例。
原則7:分析規格說明,找出其他可能的邊界條件。
三、錯誤推測法
1、錯誤推測法概述
錯誤推測法就是人們可以靠經驗和直覺推測程序中可能存在的各種錯誤,從而有針對性地編寫檢查這些錯誤的例子。
2、錯誤推測法基本思想
(1)列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況(比如,程序只能輸入數字,測試時可以輸入字母進行測試)。
(2)根據它們選擇測試用例。
四、因果圖設計法
1、因果圖設計法概述
如果在測試時必須考慮輸入條件的各種組合以及各種輸出情況,那么可以使用一種適用于描述對于多種條件的組合,相應產生多個動作的形式來設計測試用例,這就需要利用因果圖。
2、因果圖表示
因果圖使用一些簡單的邏輯符號和直線將程序的因(輸入)與果(輸出)連接起來,一般原因用ci表示,結果用ei表示,各結點表示狀態,可以取值“0”或“1”,其中“0”表示狀態不出現,“1”表示狀態出現。
如下圖所示:
ci與ei之間有恒等、非(~)、或(∨)、與(∧)4種關系,分別為:
恒等:在恒等關系中,要求程序有一個輸入和一個輸出,輸出與輸入保持一致。若c1為1,則e1也為1,若c1為0,則e1也為0。
非:非使用符號“~”表示,在這種關系中,要求程序有一個輸入和一個輸出,輸出是輸入的取反。若c1為1,則e1為0,若c1為0,則e1為1。
或:使用符號“∨”表示,或關系可以有任意個輸入,只要這些輸入中有一個為1,則輸出為1,否則輸出為0。
與:使用符號“∧”表示,與關系也可以有任意個輸入,但只有這些輸入全部為1,輸出才能為1,否則輸出為0。
以下用一張圖展示這4種關系:
總結:
- 在軟件測試中,如果程序有多個輸入,那么除了輸入與輸出之間的作用關系之外,這些輸入之間往往也會存在某些依賴關系,某些輸入條件本身不能同時出現,某一種輸入可能會影響其他輸入。
- 例如,某一軟件用于統計體檢信息,在輸入個人信息時,性別只能輸入男或女,這兩種輸入不能同時存在,而且如果輸入性別為女,那么體檢項就會受到限制。
3、約束條件
為了表示原因與原因之間,原因與結果之間可能存在的約束條件,在因果圖中可以附加一些表示約束條件的符號。
(1)輸入條件的約束類別可分為四種:
E(Exclusive,這些依賴關系在軟件測試中稱為“約束”,異)、I(at least one,或)、O(one and only one,唯一)、R(Requires,要求),在因果圖中,用特定的符號表明這些約束關系。
- E(異):a和b中最多只能有一個為1,即a和b不能同時為1。
- I(或):a、b和c中至少有一個必須是1,即a、b、c不能同時為0。
- O(唯一):a和b有且僅有一個為1。
- R(要求):a和b必須保持一致,即a為1時,b也必須為1,a為0時,b也必須為0。
(2)輸出條件的約束類別只有一種:
- 除了輸入條件,輸出條件也會相互約束,輸出條件的約束只有一種M(Mask,強制),強制約束關系。若結果a是1,那么結果b強制為0。
4、設計測試用例
(1)因果圖設計測試用例思想:
-
從程序規格說明書的描述中,找出因(輸入條件)和果(輸出結果或者程序狀態的改變);
-
通過因果圖轉換為判定表;
-
為判定表中的每一列設計一個測試用例;
(2)使用因果圖設計測試用例的步驟:
-
分析程序規格說明書描述內容,確定程序的輸入與輸出,即確定“原因”和“結果” 。
-
分析得出輸入與輸入之間、輸入與輸出之間的對應關系,將這些輸入與輸出之間的關系使用因果圖表示出來。
-
由于語法與環境的限制,有些輸入與輸入之間、輸入與輸出之間的組合情況是不可能出現的,對于這種情況,使用符號標記它們之間的限制或約束關系。
-
將因果圖轉換為決策表,根據決策表設計測試用例。(決策表將在標題五判定表驅動法中提到)
5、優點
因果圖法的優點:
-
考慮到了輸入情況的各種組合以及各個輸入情況之間的相互制約關系。
-
因果圖的約束關系可以有效簡化決策表,幫助測試人員高效率的開發測試用例。
-
因果圖法是將自然語言規格說明轉化成形式語言規格說明的一種嚴格的方法,可以指出規格說明存在的不完整性和二義性。
6、思考題
程序的規格說明要求:輸入的第一個字符必須是#或*,第二個字符必須是一個數字,在此情況下進行文件的修改;如果第一個字符不是#或*,則給出信息N,如果第二個字符不是數字,則給出信息M。采用因果圖法設計該軟件的測試用例。
具體解析如下:
(1)分析程序規格說明中的原因和結果:
| C1:第一個字符是# | e1:給出信息N |
| C2:第一個字符是* | e2:修改文件 |
| C3:第二個字符是一個數字 | e3:給出信息M |
(2)畫出因果圖:
(3)將因果圖轉換成判定表,3個條件一般可以有23種組合
| 原因 | c1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 |
| c2 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | |
| c3 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | |
| 結果 | e1 | ? | ? | ||||||
| e2 | ? | ? | |||||||
| e3 | ? | ? |
(4)簡化判定表,第7列和第8列合并
| 原因 | c1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 |
| c2 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | |
| c3 | 1 | 0 | 1 | 0 | 1 | 0 | - | |
| 結果 | e1 | ? | ||||||
| e2 | ? | ? | ||||||
| e3 | ? | ? |
(5)根據判定表生成測試用例
| 1 | #3 | 修改文件 |
| 2 | #M | 給出信息M |
| 3 | *5 | 修改文件 |
| 4 | *A | 給出信息M |
| 5 | MM | 給出信息N |
五、判定表驅動法
1、判定表驅動法概述
判定表也稱為決策表,其實質就是一種邏輯表。在程序設計發展初期,判定表就已經被當作程序開發的輔助工具了,幫助開發人員整理開發模式和流程,因為它可以把復雜的邏輯關系和多種條件組合的情況表達的既具體又明確,利用判定表可以設計出完整的測試用例集合。
2、判定驅動法 —— 引例
為了讓大家明白什么是判定表,下面通過一個“圖書閱讀指南”來制作一個判定表,圖書閱讀指南指明了圖書閱讀過程中可能出現的狀況,以及針對各種情況給讀者的建議。
(1)在圖書閱讀過程中可能會出現3種情況:
- 是否疲倦。
- 是否對內容感興趣。
- 對書中的內容是否感到糊涂。
如果回答是肯定的,則使用“Y”標記;
如果回答是否定的,則使用“N”標記。
那么這3種情況可以有23=8種組合,針對這8種組合。
(2)閱讀指南給讀者提供了4條建議:
- 回到本章開頭重讀。
- 繼續讀下去。
- 跳到下一章去讀。
- 停止閱讀并休息。
(3)針對以上分析,得出以下圖書閱讀指南判定表。
| 問題 | 是否疲倦 | Y | Y | Y | Y | N | N | N | N |
| 是否對內容感興趣 | Y | Y | N | N | N | Y | Y | N | |
| 對書中內容是否感到糊涂 | Y | N | N | Y | Y | Y | N | N | |
| 建議 | 回到本章開頭重讀 | ? | |||||||
| 繼續讀下去 | ? | ||||||||
| 跳到下一章去讀 | ? | ? | |||||||
| 停止閱讀并休息 | ? | ? | ? | ? |
(4)在實際測試中,條件樁往往很多,而且每個條件樁都有真假兩個條件項,有n個條件樁的判定表就會有2n種條件規則,如果每條規則都設計一個測試用例,不僅工作量大,而且有些工作量可能是重復的無意義的。例如在“圖書閱讀指南”中,第1、2條規則,第1條規則取值為:Y、Y、Y,執行結果為“停止閱讀并休息”;第2條規則取值為:Y、Y、N,執行結果也是為“停止閱讀并休息”;對于這兩條規則來說,前兩個問題的取值相同,執行結果一樣。
這些不影響結果取值的問題稱為無關條件項,用“-”表示。忽略無關條件項,可以將兩條規則合并。
合并規則需要滿足如下兩個條件:①兩條規則采取的動作相同;②兩條規則的條件項取值相似。
(5)根據合并規則,可以將“圖書閱讀指南”判定表合并。
| 問題 | 是否疲倦 | Y | Y | N | N | N |
| 是否對內容感興趣 | Y | N | N | Y | Y | |
| 對書中內容是否感到糊涂 | - | - | - | Y | N | |
| 建議 | 回到本章開頭重讀 | ? | ||||
| 繼續讀下去 | ? | |||||
| 跳到下一章去讀 | ? | |||||
| 停止閱讀并休息 | ? | ? |
3、判定表結構
判定表是把作為條件的所有輸入的各種組合值以及對應的輸出值都羅列出來而形成的表格,判定表由4個部分組成,判定表結構如下:
| 動作樁 | 動作項 |
其中每一列稱為一個規則。判定表的4個部分分別為:
- 條件樁:列出問題的所有條件,除了某些問題對條件的先后次序有要求之外,通常決策表中所列條件的先后次序都無關緊要。
- 條件項:條件項就是條件樁的所有可能取值。
- 動作樁:動作樁就是問題可能采取的操作,這些操作一般沒有先后次序之分。
- 動作項:指出在條件項的各組取值情況下應采取的動作。
在判定表中,任何一個條件組合的特定取值及其相應要執行的操作稱為一條規則,即判定表中的每一列就是一條規則,每一列都可以設計一個測試用例,根據判定表設計測試用例就不會有所遺漏。
4、判定表的建立步驟
- 確定規則個數(n個條件相應的有2?條規則)。
- 列出所有的條件樁和動作樁。
- 填入條件項。
- 填入動作項,制定初始判定表。
- 簡化,合并相似規則或相同動作。
5、使用判定表設計測試用例的條件
- 規格說明以判定表的形式給出,或很容易轉換成判定表。
- 條件的排列順序不影響執行哪些操作。
- 規則的排列順序不影響執行哪些操作。
- 當某一規則的條件已經滿足,并確定要執行的操作后,不必檢驗別的規則。
- 如果某一規則要執行多個操作,這些操作的執行順序無關緊要。
6、案例:工資發放
某公司的薪資管理制度如下:員工工資分為年薪制與月薪制兩種,員工的錯誤定位包括普通錯誤與嚴重錯誤兩種,如果是年薪制的員工,犯普通錯誤扣款2%,犯嚴重錯誤扣款4%;如果是月薪制的員工,犯普通錯誤扣款4%,犯嚴重錯誤扣款8%。該公司編寫了一款軟件用于員工工資計算發放,現在要對該軟件進行測試。
對公司員工工資管理進行分析,可得出員工工資由4個因素決定:年薪、月薪、普通錯誤、嚴重錯誤。其中,年薪與月薪不可能同時并存,但普通錯誤與嚴重錯誤可以并存。
員工最終扣款結果有7種:未扣款、扣款2%、扣款4%、扣款6%(2%+4%)、扣款4%、扣款8%、扣款12%(4%+8%)。
采用判定表驅動法設計該軟件的測試用例。
具體解析如下:
(1)分析員工工資的原因和結果:
(2)有4個原因,每個原因有“Y”和“N”兩個取值,理論上可以組成24=16種規則,但是c1與c2不能同時并存,因此有23=8種規則。得出員工工資判定表如下:
(3)最終得出員工工資測試用例表:
六、正交實驗設計法
1、正交實驗設計法概述
正交實驗設計法(Orthogonal experimental design)是指從大量的實驗點中挑選出適量的、有代表性的點,依據Glois理論導出“正交表”,從而合理的安排實驗的一種實驗設計方法。
2、正交實驗設計法三個關鍵因素
- 指標:判斷實驗結果優劣的標準。
- 因子:因子也稱為因素,是指所有影響實驗指標的條件。
- 因子的狀態:因子的狀態也叫因子的水平,它指的是因子變量的取值。
3、利用正交實驗法設計測試用例的步驟
- 提取因子,構造因子狀態表
- 加權篩選,簡化因子狀態表
- 構建正交表,設計測試用例
接下來對這三個步驟進行一一解析。
(1)舉個栗子(步驟一):
提取因子,構造因子狀態表—— 即分析軟件的規格需求說明得到影響軟件功能的因子,確定因子可以有哪些取值,即確定因子的狀態。
例如,某一軟件的運行受到操作系統和數據庫的影響,因此影響其運行是否成功的因子有操作系統和數據庫兩個,而操作系統有Windows、Linux、Mac三個取值,數據庫有MySQL、MongoDB、Oracle三個取值,因此操作系統的因子狀態為3,數據庫因子狀態為3。得到如下因子-狀態表:
| 操作系統 | Windows | Linux | Mac |
| 數據庫 | MySQL | MongoDB | Oracle |
(2)舉個栗子(步驟二):
加權篩選,簡化因子狀態表 —— 在實際軟件測試中,軟件的因子及因子的狀態會有很多,每個因子及其狀態對軟件的作用也大不相同,如果把這些因子及狀態都劃分到因子-狀態表中,最后生成的測試用例會相當龐大,從而影響軟件測試的效率。因此需要根據因子及狀態的重要程度進行加權篩選,選出重要的因子與狀態,簡化因子-狀態表。
(3)舉個栗子(步驟三):
構建正交表,設計測試用例 —— 正交表的表示形式為 Ln(tc) 來表示。
- L表示正交表。
- n為正交表的行數,正交表的每一行可以設計一個測試用例,因此行數n也表示可以設計的測試用例的數目。
- c表示正交實驗的因子數目,即正交表的列數,因此正交表是一個n行c列的表。
- t稱為水平數,表示每個因子能夠取得的最大值,即因子有多少個狀態。
- 在行數為n(n為正整數)的正交表中,行數n(試驗次數)=∑(每列水平數t-1)+1。如: ①L8(27),n=7×(2-1)+1=8;②L4(23),n=3×(2-1)+1=4。
下面舉出兩個例子輔助理解:
例1:
L4(23) 是最簡單的正交表,它表示該實驗有3個因子,每個因子有兩個狀態,可以做4次實驗,如果用0和1表示每個因子的兩種狀態,則該正交表就是一個4行3列的表。
正交表如下圖所示:
例2:
在實際軟件測試中,大多數情況下,軟件有多個因子,每個因子的狀態數目都不相同,即各列的水平數不等,這樣的正交表稱為混合正交表,如L8(24 + 41) ,這個正交表表示有4個因子有2種狀態,有1個因子有4種狀態。
那么正交表的行數為 n= ∑(每列水平數t-1)+ 1 = (2-1)×4 + (4-1)×1 + 1 = 8,這個n值的計算如果發生在大型項目時往往是很難計算的。
所以,混合正交表往往難以確定測試用例的數目,即n的值。因此,在這種情況下,可以登錄正交表的一些權威網站,查詢n值,下面給大家提供一個正交表查詢網站,
在這里,可以查詢到不同因子數、不同水平數的正交表的n值。
最終得出,該混合正交表如下圖所示:
4、正交表的特點
正交表最大的特點是取點均勻分散、齊整可比,每一列中每種數字出現的次數都相等,即每種狀態的取值次數相等。
5、總結
寫到這里,對正交實驗設計法做個小結:
- 在正交表中,每個因子的每個水平與另一個因子的各水平都“交互”一次,這就是正交性,它保證了實驗點均勻分散在因子與水平的組合之中,因此具有很強的代表性。
- 對于受多因子多水平影響的軟件,正交實驗法可以高效適量的生成測試用例,減少測試工作量,并且利用正交實驗法得到的測試用例具有一定的覆蓋度,檢錯率可達50%以上。
- 正交實驗法雖然好用,但在選擇正交表時要注意先要確定實驗因子、狀態及它們之間的交互作用,選擇合適的正交表,同時還要考慮實驗的精度要求、費用、時長等因素。
6、案例:微信Web頁面運行環境正交試驗設計
微信是一款手機App軟件,但它也有web版微信可以登錄,如果要測試微信web頁面運行環境,需要考慮多種因素,在眾多的因素中,我們可以選出幾個影響比較大的因素,如服務器、操作系統,插件和瀏覽器。利用正交實驗設計法設計該軟件的測試用例。
具體解析如下:
(1)提取因子,構造因子狀態表
-
對于選取出的4個影響因素,每個因素又有不同的取值,同樣,在每個因素的多個值中,可以選出幾個比較重要的值。如:
-
服務器:IIS、Apache、Jetty;
-
操作系統:Windows7、Windows10、Mac;
-
插件:無、小程序、微信插件;
-
瀏覽器:IE11、Chrome、FireFox;
-
-
構造的因子狀態表如下:
| 操作系統 | IIS | Apache | Jetty |
| 數據庫 | Windows7 | Windows10 | Mac |
| 插件 | 無 | 小程序 | 微信插件 |
| 瀏覽器 | IE11 | Chrome | FireFox |
(2)加權篩選,簡化因子狀態表
- 微信web版運行環境正交實驗中有4個因子:服務器、操作系統、插件、瀏覽器,每個因子又有3個水平,因此該正交表是一個4因子3水平正交表。
- 所以正交表的行數為 n= ∑(每列水平數t-1)+ 1 = (3-1)×4 + 1 = 9,因此正交表的表示形式為L9(34)。
- 得出n=9后,查表可得,簡化后的因子狀態表如下:
(3)構建正交表,設計測試用例 - 將因子、狀態映射到正交表,可生成具體的測試用例,具體如下表:
七、場景法
1、設計思想
現在的軟件幾乎都是由事件來觸發的,事情觸發便形成了場景,而同一事件不同的觸發順序和處理結果就形成了事件流。
2、場景的構成要素
場景可以看成是基本流與備選流的集合。用例的場景用來描述流經用例的路徑,從用例的開始到結束遍歷這條路徑上所有的基本流和備選流。
(1)基本流
基本事件流,從系統某個初始狀態開始,經一系列狀態后,到達最終狀態的一個業務流程,并且是最主要、最基本的一個業務流程(無任何差錯,程序從開始直接到執行結束)。
(2)場景流
備選事件流,以基本流為基礎,在基本流所經過的每個判定節點處滿足不同的觸發條件而導致的其他事件流。
3、基本流和備選流的場景說明
先用一張圖來描述基本流和備選流的流程。
從上圖可以看出,圖中經過用例的每條路徑都用基本流和備選流來表示。
基本流:采用直黑線表示,是經過用例的最簡單的路徑。
備選流:采用不同色彩表示,一個備選流可能從基本流開始,在某個特定條件下執行,然后重新加入基本流中(如備選流1和3);也可能起源于另一個備選流(如備選流2),或者終止用例而不再重新加入到某個流(如備選流2和4)。
根據圖中每條經過的可能路徑,從基本流開始,再經過基本流、備選流的綜合,可以確定不同的用例場景,如下:
基于以上例子,可以得出以下結論:基本流只有一個,而備選流的數目則取決于基本流上判定節點的數目與事務分析的顆粒度,顆粒度越細,考慮越周全,得到的備選流數目就越多,相應的測試工作量就越大。
4、設計測試用例
場景法設計測試用例的基本步驟如下:
(1)根據需求規格說明,描述出程序的基本流及各項備選流。
(2)根據基本流和各項備選流生成不同的場景。
(3)對每一個場景生成相應的測試用例。
(4)對生成的所有測試用例重新復審,去掉多余的測試用例。測試用例確定后,對每一個測試用例確定測試數據值。
5、總結
寫到這里,對場景法做個小結:
- 場景法以事件流和場景為核心,又被稱為業務流程測試法,要求測試人員使用場景法設計測試用例時把自己當成最終用戶,盡可能真實地模擬用戶在使用此軟件時的操作情形。
- 在測試過程中,測試人員需要模擬兩個方面的業務:正確的操作流程和可能出現的錯誤操作。
- 它適用于業務比較復雜的軟件系統測試。
6、案例:在線購物案例
有一個在線購物的實例:用戶進入一個在線購物網站進行購物,選購物品后,進行在線購買,這時需要使用賬號登錄;登錄成功后,進行付錢交易;交易成功后,生成訂購單;完成整個購物過程。請使用場景法設計測試用例。
案例解析如下:
(1)確定基本流和備選流
- 基本流:登錄在線購物網站,選擇物品,登錄賬號,付錢交易,生成訂購單。
- 備選流1:賬號不存在。
- 備選流2:密碼錯誤。
- 備選流3:貨物庫存不足。
- 備選流4:賬號余額不足。
(2)根據基本流和備選流來確定場景,如下表:
表 購物系統場景表
| 場景2:賬號不存在 | 備選流1 |
| 場景3:密碼錯誤 | 備選流2 |
| 場景4:貨物庫存不足 | 備選流3 |
| 場景5:用戶賬號余額不足 | 備選流4 |
(3)根據每一個場景,設計需要的測試用例
【解析】
可以采用矩陣或判定表來確定和管理測試用例,下面介紹一種通用的格式,其中各行代表各個測試用例,而各列則代表測試用例的信息。
在矩陣中,
- V(有效)用于表明這個條件必須是VALID(有效的)才可執行基本流;
- I(無效)用于表明這種條件下將激活所需備選流;
- N/A(不適用)表明這個條件不適用于測試用例。
購物系統場景矩陣見下表:
表 購物系統場景矩陣
| 1 | 場景1:成功購物 | V | V | V | V | V | 成功購物 |
| 2 | 場景2:賬號不存在 | I | N/A | N/A | N/A | N/A | 提示賬號不存在 |
| 3 | 場景3:密碼錯誤 | V | I | N/A | N/A | N/A | 提示密碼輸入有誤 |
| 4 | 場景4:購買商品庫存不足 | V | V | V | I | N/A | 提示庫存不足 |
| 5 | 場景5:用戶賬號余額不足 | V | V | V | V | I | 提示賬號余額不足 |
(4)設計具體的測試用例數據(假設所購物品單價為30元)
表 購物系統具體測試用例
| 場景1:成功購物 | 1 | admin123 | test123 | 10件 | 50件 | 2000元 | 成功購物 |
| 場景2:賬號不存在 | 2 | admin | N/A | N/A | N/A | N/A | 提示賬號不存在 |
| 場景3:密碼錯誤 | 3 | admin123 | test | N/A | N/A | N/A | 提示密碼輸入有誤 |
| 場景4:購買商品庫存不足 | 4 | admin123 | test123 | 60件 | 50件 | N/A | 提示庫存不足 |
| 場景5:用戶賬號余額不足 | 5 | admin123 | test123 | 10件 | 50件 | 200元 | 提示賬號余額不足 |
八、功能圖法
此處還未學習明白,靜待后續更新……
九、黑盒測試方法策略總結
寫到這里,對上面八大黑盒測試方法做個小結。
1、各種測試方法選擇的綜合策略
(1)首先進行等價類劃分,包括輸入條件和輸出條件的等價劃分,將無限測試變成有限測試,這是減少工作量和提高測試效率最有效的方法。
(2) 在任何情況下都必須使用邊界值分析方法。經驗表明,用這種方法設計出的測試用例發現程序錯誤的能力最強。
(3)可以用錯誤推測法追加一些測試用例,這需要依靠測試工程師的智慧和經驗。
(4)對照程序邏輯,檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準,應當再補充足夠的測試用例。
(5)如果程序的功能說明中含有輸入條件的組合情況,則一開始就可選用因果圖法和判定表。
(6)對于參數配置類的軟件,要用正交試驗法選擇較少的組合方式達到最佳效果。
(7)對于業務流清晰的軟件,可以使用場景貫穿測試,再綜合使用各種測試方法。
2、黑盒測試的優缺點
(1)優點:①對較大的代碼單元來說,黑盒測試比白盒測試的效率高 ,測試人員不需要了解實現的細節,包括特定的編程語言;②測試人員和編程人員是相互獨立的,從用戶的角度進行測試,很容易被接受和理解,有助于暴露任何與規格不一致或者歧異的地方,測試用例可以在規格完成后馬上進行。
(2)缺點:不能測試程序內部特定部位,比如程序未執行的代碼,這些代碼得不到測試,則無法發現錯誤。若沒有清晰的和簡明的規格,測試用例很難被設計,不易進行充分性測試。
十、寫在最后
黑盒測試相較于白盒測試來說比較簡單,不需要了解程序內部的代碼,與軟件的內部實現無關;從用戶角度出發,能很容易的知道用戶會使用到哪些功能,會遇到哪些問題;并且是基于軟件開發文檔做的相關測試,能較清楚地了解軟件實現了文檔中的哪些功能。
八大典型的黑盒測試方法講解到這里就結束啦!如有不理解或者有誤的地方歡迎私聊或加我微信指正~
下一篇文章將講解白盒測試。
如果想查看往期文章,也可以直接點擊進入軟件測試欄目。
- 公眾號:星期一研究室
- 微信:MondayLaboratory
碼字不易,如果這篇文章對你有用,記得留個Star哦~
總結
以上是生活随笔為你收集整理的『软件测试3』八大典型的黑盒测试方法已来袭,快快接住!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 『软件工程6』详解软件项目管理之软件范围
- 下一篇: 了解js基础知识中的作用域和闭包以及闭包