5.1 認識基本術語
5.1.1術語一：
◆動態測驗（dynamic testing）
通過運行軟體的組件或系統來測驗軟體(實際運行被測軟體/系統)【需要進行操作】
◆靜態測驗（static testing)
對組件的規格說明書進行評審，對靜態代碼進行走查 (不實際運行被測軟體/系統，通過對需求規格說明書進行走查、閱讀等動作，代碼進行備注走查)【主要以看為主】
◆正式評審（formal review）
對評審程序及需求檔案的一種特定評審 （也就是會議評審，一般公司會對需求進行正式的評審）如：
1、代碼評審：當前迭代功能相關的代碼進行評審
2、介面評審:前后端需要進行資料互動；如電商商家在后臺添加商品
◆度量（metric）
測量所使用的方法或標準
◆評審員（reviewer）
參與評審的人
◆記錄員（scribe）
記錄評審會議上的會議紀要
5.1.2 術語二：
◆技術評審（Technical Review)
同行間對技術進行的評審，目的是技術實作達成共識，
◆走查（Walkthrough)
由檔案作者逐步陳述檔案內容，以收集資訊并對內容達成一致 ，(即產品經理在講解需求檔案的時候，大家各抒己見，最后達成一致意見的程序.)
◆復雜性（complexity）
系統或組件的設計或內部結構比較復雜， 導致難以理解，維護或驗證的程度(與代碼相關，用圈復雜度來體現)
◆圈復雜度（Cycloramic complexity）
程式中獨立路徑的數量，可以衡量一個組件模塊的判定結構的復雜程度，(用來衡量代碼的復雜程度，代碼越復雜，圈復雜度越高；反之越低)
◆控制流(Control Flow)
執行組件或系統的一系列順序的路徑
◆資料流（Data Flow）
表示資料物件的順利或狀態發生變化的程序()
5.1.3術語三：
◆控制流圖概念
(CFG,Controlflowgraph)也叫控制流程圖，是一個程序或程式的抽象表現，
◆圈復雜度
圈復雜度是一種代碼復雜度的衡量標準，程式中獨立路徑的數量,可以衡量一個組件模塊的判定結構的復雜程度,數量上表現為獨立現行路徑條數,即合理的預防錯誤所需測驗的最少路徑條數，圈復雜度大說明程式代碼可能質量低且難于測驗和維護,根據經驗,程式的可能錯誤和高的圈復雜度有著很大關系，
計算物件是結構圖或程式圖，而程式圖又包括控制流圖與流程圖，
?圈復雜度第一個計算公式：V(G)=E-N+2(E表示控制流圖中的邊數；N表示控制流圖中節點數)
?圈復雜度(反映了“判定條件”的數量)第二個計算公式：V(G)=(控制流圖)區域數
?圈復雜度第三個計算公式：V(G)=P(判定節點數)+1
5.2 常見的用例設計方法
5.2.1等價類定義(重點)
等價類：指某個輸入域的集合，在集合中各個輸入的條件都是等效的，
字符：指類字形單位或符號，包括字母、數字、運算子號、標點符號和其他符號，以及一些功能性符號，
5.2.2等價類分析方法
?使用范圍：適用于有無限多種輸入
?目的：使用較少的測驗用例盡可能將更多的功能點覆寫全通常等價類劃分為2種情況：
?有效等價類：對程式規格說明有意義的、合理的輸入資料
?無效等價類：對程式規格說明無意義的、不合理的輸入資料
5.2.3等價類劃分舉例
?規定了輸入值的范圍或值的個數（如：0<a<100或輸入6-10個字符）
?輸入值為布林值（如：真或假、是或否、對與錯不存在無效等價例)
?規定了輸入資料的一組值（如文化程度：初中、高中、大學）
?規定了輸入規則時，可以劃分出一個有效的等價類（符合規則)和若干個無效等價類（從不同角度違反規則）
◆常見的能夠劃分等價類的地方
1.數值范圍 2. 重復次數 3. 字串長度
4. 字串組中字符的個數 5. 檔案命名 6. 檔案大小
7. 螢屏的顏色種類 8. 超時時間
◆等價類劃分的設計用例思路
1. 找輸入條件 2. 為每個輸入條件找有效、無效等價類
3. 為每個等價類編號 4. 用最少的用例覆寫最多的有效等價類
5. 每一個無效等價類都是一個用例
6. 并非所有有效等價類都有無效 7. 等價類的覆寫可以重復覆寫
◆等價類設計用例覆寫的原則
?每個用例盡可能多的覆寫多個有效的等價類
?每個用例只能覆寫一個無效等價類
◆等價類的優缺點
優點：是考慮了單個輸入域的各類情況， 避免
了盲目或隨機選取輸入資料的不完整性和覆寫
的不穩定性，
缺點：方法雖然簡單易用，但是沒有對組合情況
進行充分的考慮，需要結合其他測驗用例設計的
方法進行補充，比如邊界值
→測驗用例撰寫如：
輸入值 有效等價類 無效等價類
日期型別及長度 6位數字字符(1) 非數字型別(6)
大于6位(7)
小于6位(8)
注意：不能合寫
年份范圍 1990-2049(2) 大于2049(9)
小于1990(10)
月份范圍 01-12(3) 小于01 0特殊(11)
大于12(12)
前4位表示年 前四位為年(4) 前四位不為年(13)
后2位表示月 后兩位為月(5) 后兩位不為月(14)
------ ----- ----- ---- ------
有效輸入值：199101 202207 （滿足1、2、3、4、5）
無效輸入值：二零220705 （6、7） 2207（8）
205007（9） 189907（10）
◆測驗用例
?面試題：用例中包含哪些內容？ 包括用例編號、用例標題、前置條件、操作步驟、預期結果、用例等級
?用例標題：只能用陳述句，不能出現是否等判斷性的文字，簡單且清晰明了
5.2.4邊界值（重點）
◆邊界點定義
?上點：邊界上的點 ?內點：在域范圍內的點
?離點：離上點最近的點(即上點左右兩邊最鄰近的點）
◆邊界條件分析
? 輸入條件明確了一個值的取值范圍或規定了值的個數
?輸入條件明確了一個有序集合邊界值分析法:滿足a
eg.正整數值域[66,88]上點：66、88 內點：77離點：65,89
eg.正整數值域(66,88)上點：66、88 內點：77離點：67,87
★注：內點一般取中間值
★區別：閉區間上點有效，離點無效；開區間上點無效，離點有效，
◆邊界值分析原則
?如果輸入（輸出）條件規定了取值范圍，則應該以該范圍的邊界內及邊界附近的值作為測驗用例
?如果輸入（輸出）條件規定了值的個數，則用最大個數，最小個數，比最小個數少一，比最大個數多一的數作為測驗資料
?如果程式規格說明中提到的輸入或輸出是一個有序集合，應該注意選取有序集合的第一個和最后一個元素作為測
試資料
5.2.5判定表
?判定表定義： 分析和表達多邏輯條件下執行不同操作的情況
?適用范圍：遇到復雜業務，可以使用判定表來梳理業務之間的邏輯關系，
◆結構：由4個部分組成
1）條件樁（condition stub）:列出問題的所有條件（通常條件次序無關緊要），條件(輸入)需求規格說明書定義的被測物件所有值，
2）條件項（condition entry）：列出針對它條件的取值（所有情況下的真偽值）
3）動作樁（action stub）：列出問題規定可采取的動作（順序無約束），動作(輸出)針對條件，被測物件可能采取的所有操作，
4）動作項（action entry）：列出條件各種情況的應采取的動作，針對動作樁，被測物件所有的可能取值，
◆設計判定表的步驟：
1、理解需求、確定條件樁、動作樁
2、確定規則的個數；若有N個條件，每一個條件下面有2個值，則有2^n種規則，
3、設計判定表并列出所有條件樁與動作樁，
4、輸入條件項和動作項得到初始判定表
5、根據判定表種輸入結果的表現，進行判定表并入，簡化得出結果并理清業務邏輯（合并相似規則）6、撰寫測驗用例
◆判定表法測驗用例
1、畫出判定表2、簡化得出清晰的業務邏輯 3、轉化為測驗用例
|
條件樁 |
|
1 |
2 |
3 |
4 |
|
用戶欠費？ |
|
Y |
Y |
N |
N |
|
用戶關機？ |
|
Y |
N |
Y |
N |
|
規則條數統計 |
4 |
1 |
1 |
1 |
1 |
|
動作樁 |
|
|
|
|
|
|
允許主被叫 |
|
|
|
|
√ |
|
禁止主被叫 |
|
√ |
√ |
√ |
|
注：判定表每一行/每一列都是一條測驗用例
1、簡化得出清晰的業務邏輯（合并相似規則）
用例編號 用戶是否欠費 用戶是否關機 預期結果
1 是 是 禁止主被叫
2 是 否 禁止主被叫
3 否 是 禁止主被叫
4 否 否 允許主被叫
2、轉化為測驗用例
用例編號 用例標題 前置條件 操作步驟 預期結果 優先級
5.2.6因果圖
◆因果圖定義
因果圖用畫圖的方式來表達輸入條件和輸出結果的直接關系，因果圖提供了一個把規格轉化為判定表的系統化方法，從該圖中可以產生測驗資料，其中，原因是表示輸入條件，結果是對輸入執行的一系列計算后得到的輸出，
?因果圖方法最終生成的就是判定表，它適合于檢查軟體輸入條件的各種組合情況
因(原因)：輸入條件 果(結果)：輸出結果
◆因果圖中的四種基本關系
在因果圖的基本符號中，圖中的左結點ci 表示輸入狀態（或稱原因),右結點ei表示輸出狀態（或稱結果），ci與ei取值0或1，0表示某狀態不出現，1則表示某狀態出現，
?恒等關系：==當原因出現的時候，結果一定出現
?非關系：～ not ≠ 當原因出現的時候，結果不一定出現
?或關系：V or / | || 多個原因中有一個原因出現時，則結果一定出現
?與關系：^ 和 且 and 多個原因同時出現,則結果才能出現
◆因果圖中約束符號
在實際問題中輸入狀態相互之間、輸出狀態相互之間可能存在某些依賴關系，稱為“約束”，對于輸入條件的約束有E、I、O、R四種約束，對于輸出條件的約束只有M約束，
?E約束(異)： a和b中最多有一個可能為1，即a和b不能同時為1(兩個可以都不選，但是如果要選只能選一個)
?I約束(或)：a、b、c中至少有一個必須為1，即a,b,c不能同時為0(所有原因中最少選一個，但不能同時都不選或同時都選)
?ΦΟ約束(唯一)：a和b必須有一個且僅有一個為1(只能選一個，不能同時都選或同時都不選)
?R約束(要求)：a是1時，b必須是1，即a為1時，b不能為0(深圳市，出現的時候必須要求出現廣東省)
?M約束(強制)：若結果a為1，則結果b強制為0(輸入胡蘿卜，結果強制為蔬菜)
◆因果圖的步驟：
1.把大的系統規格劃分解成可以測驗的規格片段
2.分析分解后待測的系統規格，找出哪些是原因，
哪些是結果
3.畫出因果圖 4.把因果圖轉換成判定表
5.簡化判定表 6.用判定表中的每一列生成測驗用例
◆因果圖轉換判定表的方法：
1. 將因果圖中的所有條件（因）填入判定表的條件樁中；
2. 將因果圖中的所有動作（果）填入判定表的動作樁中；
3. 根據因果圖確定各個條件組合對應的動作，并且確定判定表中各個規則的條件項和動作項，在需要時優化判定表，
◆因果圖設計測驗用例
找出原因結果并進行編號：
畫出因果圖：
面試題：你在上一家公司是怎么使用因果圖設計測驗用例的？
an：我在上一家公司一般不會畫因果圖，但是對于需求檔案當中有因果關系的需求時，我們會把因果圖的原因放到判定表的條件樁中，再把因果圖中的結果放入到判定表的動作樁中，從而把因果圖轉為了判定表，可以防止用例的漏寫和漏測，
→因果圖的優點
1.等價類法盡管各個輸入條件可能出錯的情況都考慮到了，但是多個輸入條件組合起來出錯的情況卻被忽略了
2.因果圖法能夠幫助我們按照一定步驟，高效的選擇測驗用例，設計多個輸入條件組合用例
3.因果圖分析還能為我們指出，程式規格說明描述中存在什么問題
→因果圖的缺點：
?輸入條件與輸出結果的因果關系，有時難以從軟體需求規格說明書得到
?即使得到了這些因果關系，也會因為因果關系復雜導致因果圖非常龐大，測驗用例數目及其龐大
◆場景法設計測驗用例：
基于用戶場景梳理業務邏輯，再挑選最合適的方法設計測驗用例，為的是盡可能的去還原用戶全部真實操作，
◆業務需求方面：對所測軟體的重要功能，業務邏輯(系統要干什么，怎么去實作這個程序)和行業背景進行深入了解
◆技術層面：基于等價類劃分
?有效等價類：用戶的一個正確操作場景
?無效等價類：用戶的一個錯誤操作場景
◆核心概念：
?基本流(正確，有效流)：模擬用戶的正確操作程序
?備選流(錯誤，無效流)：模擬用戶的錯誤操作程序
5.3 黑盒用例設計方法
◆黑盒測驗也稱功能測驗，它是通過測驗來檢測每個功能是否都能正常使用，
◆在測驗中，把程式看作一個不能打開的黑盒子，在完全不考慮程式內部結構和內部特性的情況下，在程式介面進行測驗，它只檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入資料而產生正確的輸出資訊，
◆黑盒測驗著眼于程式外部結構，不考慮內部邏輯結構，主要針對軟體界面和軟體功能進行測驗，
◆黑盒測驗是以用戶的角度，從輸入資料與輸出資料的對應關系出發進行測驗的，很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測驗方法是發現不了，
◆黑盒測驗用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景圖法等，目前黑盒測驗的常用測驗用例設計方法有5種：等價類劃分、邊界值分析、錯誤推測法、因果圖、功能圖
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501516.html
標籤：其他