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個字符）
輸入值為布林值（如：真或假、是或否、對與錯） 不存在無效等價例
規定了輸入資料的一組值（如文化程度：初中、高中、大學）
規定了輸入規則時，可以劃分出一個有效的等價類（符合
規則）和若干個無效等價類（從不同角度違反規則）
測驗用例撰寫如：
輸入值 有效等價類 無效等價類
日期型別及長度 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判定表
適用范圍：遇到復雜業務，可以使用判定表來梳理業務之間的邏輯關系，
條件樁：條件(輸入)需求規格說明書定義的被測物件所有值，
動作樁：動作(輸出)針對條件，被測物件可能采取的所有操作，
動作項：針對動作樁，被測物件所有的可能取值，
◆設計判定表的步驟：
1、理解需求、確定條件樁、動作樁
2、確定規則的個數；若有N個條件，每有N個條件下面有2個值，則有2^n種規則，
3、設計判定表 4、填寫動作項
4、根據判定表種輸入結果的表現，進行判定表并入，簡化得出結果并理清業務邏輯
◆判定表法測驗用例
1、畫出判定表2、簡化得出清晰的業務邏輯 3、轉化為測驗用例
|
條件樁 |
|
1 |
2 |
3 |
4 |
|
用戶欠費？ |
|
Y |
Y |
N |
N |
|
用戶關機？ |
|
Y |
N |
Y |
N |
|
規則條數統計 |
4 |
1 |
1 |
1 |
1 |
|
動作樁 |
|
|
|
|
|
|
允許主被叫 |
|
|
|
|
√ |
|
禁止主被叫 |
|
√ |
√ |
√ |
|
注：判定表每一行/每一列都是一條測驗用例
- 簡化得出清晰的業務邏輯（合并相似規則）
用例編號 用戶是否欠費 用戶是否關機 預期結果
1 是 是 禁止主被叫
2 是 否 禁止主被叫
3 否 是 禁止主被叫
4 否 否 允許主被叫
- 轉化為測驗用例
用例編號 用例標題 前置條件 操作步驟 預期結果 優先級
1
5.2.6因果圖
◆因果圖定義
用畫圖的方式來表達輸入條件和輸出結果的直接關系，
因(原因)：輸入條件 果(結果)：輸出結果
◆四種基本關系
恒等關系：==當原因出現的時候，結果一定出現
非關系：～ not ≠ 當原因出現的時候，結果不一定出現
或關系：V or / | || 多個原因中有一個原因出現時，則結果一定出現
與關系：^ 和 且 and 多個原因同時出現,則結果才能出現
◆約束符號
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(輸入胡蘿卜，結果強制為蔬菜)
◆因果圖設計測驗用例
找出原因結果并進行編號：
畫出因果圖：
面試題：你在上一家公司是怎么使用因果圖設計測驗用例的？
an：我在上一家公司一般不會畫因果圖，但是對于需求檔案當中有因果關系的需求時，我們會把因果圖的原因放到判定表的條件樁中，再把因果圖中的結果放入到判定表的動作樁中，從而把因果圖轉為了判定表，可以防止用例的漏寫和漏測，
→因果圖的優點
1.等價類法盡管各個輸入條件可能出錯的情況都考慮到了，但是多個輸入條件組合起來出錯的情況卻被忽略了
2.因果圖法能夠幫助我們按照一定步驟，高效的選擇測驗用例，設計多個輸入條件組合用例
3.因果圖分析還能為我們指出，程式規格說明描述中存在什么問題
→因果圖的缺點：
1.輸入條件與輸出結果的因果關系，有時難以從軟體需求規格說明書得到
2. 即使得到了這些因果關系，也會因為因果關系復雜導致因果圖非常龐大，測驗用例數目及其龐大
◆場景法設計測驗用例：
基于用戶場景梳理業務邏輯，再挑選最合適的方法設計測驗用例，為的是盡可能的去還原用戶全部真實操作，
◆業務需求方面：對所測軟體的重要功能，業務邏輯(系統要干什么，怎么去實作這個程序)和行業背景進行深入了解
技術層面：基于等價類劃分
有效等價類：用戶的一個正確操作場景
無效等價類：用戶的一個錯誤操作場景
核心概念：
基本流(正確，有效流)：模擬用戶的正確操作程序
備選流(錯誤，無效流)：模擬用戶的錯誤操作程序
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/501075.html
標籤：其他
上一篇：HCIA學習筆記八：子網掩碼劃分