MFQ and PPDCS book sharing CH1-3

海盜派測試分析
測試是一門匠藝
分享者：Penny Chang

CH1
了解測試任務（KYM）

五大主題
1. 了解測試任務(KYM) Know Your Mission
了解測試的用戶及用戶的需求
2. 測試覆蓋大綱(TCO) Test Coverage Outline
大致確認測試的範圍
3. 建模(Modeling)
針對每一個測試內容，分析需要的測試點，以實現上述的測試需求
4. 測試設計(TD)
編寫測試實例，實現測試需求
5. 測試執行(TE)
發布給測試人員

Know Your Mission(KYM)
• 先了解WHY，再考慮HOW
• 透過不斷的優化WHY最終得出與任務
目標對齊的WHAT
• WHY → HOW → WHAT
why how what

WHY? 為什麼要做KYM?
• 找出BUG所在 = 找出風險所在
1. 收集信息
2. 風險識別
3. 風險分析
4. 風險控制
• Right test ideas > test ideas
以盡可能少的時間、發現盡可能多的、盡可能重要的BUG

KYM價值
• 預防性測試 Preventive Testing－預測潛在影響，進而趁問題發
生之前，提醒研發團隊預先解決問題。
• 促進測試人員與周邊人員的溝通，及時獲取有價值的信息，提前
發現風險所在。

How? 怎麼做到KYM
Critical Thinking 批判式思維（問問題的能力）
1. Huh?
真的理解對方說的話了? 是否有疑惑? 有沒有模糊的地方?
2. Really?
這是真的嗎? 有確切的證據嗎?
3. So?
為什麼要關注這件事? 這件事與誰相關? 相關度多大? 接下來要做
什麼?

CIDTESTED引導詞法分析項目環境
了解Project Environment，從八個層面分析（問問題）
利用CIDTESTED分析項目環境，以做到KYM
• Customers — 用戶有那些，產品特性，需求優先級
• Information — 產品關鍵訊息，向誰了解進一步訊息，文檔、手
冊、網站參考
• Developer Relations — 產品誰開發，開發人員經驗，敏捷還是
瀑布，程式碼規模，測試開發人員溝通方式，開發人員做了那些
測試，需求變更的情況如何

CIDTESTED引導詞法分析項目環境
• Test Team — 有幾個測試團隊，測試人員經驗，測試穩定度，測
試人手是否充足
• Equipment & Tools — 需要的設備工具，測試環境，有無自動
化測試腳本
• Schedule — 何時交給用戶，一次性還是分期，最早何時拿到可
測試版本
• Test Item — 主要測試項目，哪些降低優先等級，產品改變後的
測試策略
• Deliverable — 需要測試的交付件有哪些，有無模板或
CHECKLIST

KYM補充說明
KYM主要從四大方面收集訊息
• 了解用戶(Customers)
• 了解項目(Project)
• 了解產品(Product)
• 了解任務(Mission)

KYM應用原則
Apply Heuristics, Not to Follow Them
把握主幹，忽略細節（掌握之後不斷調整）
KYM貫穿始終，不是一次性的行為

TCO－Test Coverage Outline
覆蓋測試大綱
• TCO－從測試角度定義需求的過程
• TCO圖例：

TCO圖
• 目的
信息提煉－不須記錄每一句話
內容重組－清楚掌握內容
心中有數－對後續要做的事有大致的認識
• 初衷
把對測試人員來說較關鍵的訊息提取、重新組織，並且對訊息源中
沒有的訊息添加

對訊息源沒有的訊息做添加？
訊息源中沒有但畫TCO過程中湧現的新訊息，使得TCO成為開展預
防性測試的重要手段。
EX 整理TCO的過程中發現：
• 疑問和風險
• 發現bug
• 當前訊息聯想到需要測試的方面

Curation and Subtraction Heuristic
過濾與剔除啟發式方法
繪製TCO的主要技能，包含兩層意思：
1. 提取有價值的訊息
2. 將提取的訊息
進行結構化整理

無文檔參考如何繪製？
1. 找了解特性的人交流，獲取信息
2. 執行程式並探索

Product Element－SFDIPOT
• 快速得到test ideas的方法，從中挑選展開探索性測試（非深入）

頭腦風暴
使用在無文檔參考的情況
• 利用10分鐘列出所有能想到的測試點，挖掘test ideas
• 對提取出的訊息進行有效重組
「用邏輯聽力理解發言，用概括歸納選擇取捨」

MFQ三維視角思路
相較於前述，是較深入尋找test ideas的方法
• Ｍ－單功能測試分析與測試設計
• Ｆ－功能交互測試分析與測試設計
• Ｑ－質量屬性測試分析與測試設計

MFQ三維視角思路
• Ｍ－單功能的測試點
• Ｆ－單功能與單功能間、整
個系統與其他系統間存在需
要測試的交互點
• Ｑ－非功能質量屬性（EX:
Reliability、Security、
Performance…etc）
M F Q
LLT
HLT
Lower Level Test – 早期進行的測試方法
Higher Level Test – 晚期進行的測試方法

TCO補充及總結
• When to apply TCO?
1. 需了解測試整體範圍時
2. 對被測對象不熟，而想快速學習時
• 並不是必須有KYM才能畫TCO（視對程式了解程度決定）
• 各功能劃分可能改變
• 粒度如何決定？
視風險質量（Testing Rely on Risks）

TCO補充及總結
• 紀錄的形式並非最重要的，畫TCO的主要目的：
1. 熟悉了解被測對象，進一步劃分單功能（Ｍ）
2. Ｆ、Ｑ不求完整（寫出來的目的是為了未來開展Ｆ與Ｑ測試點）
• 過程持續更新KYM圖
• 測試為不斷收集信息的過程，回報給客戶更有價值的產品質量信
息。

模型PPDCS
1. P-Process流程
2. P-Parameter參數
3. D-Data數據
4. C-Combination組合
5. S-State狀態

P-Process流程
• 應用條件：當需求有明顯的業務流程含義時
• 特點：
1. 有多個步驟，各步驟間有一定前後約束關係，所有步驟共同完
成一件事情。
2. 整個過程可能涉及多於一個執行者或觸發者

P-Process應用步驟
1. 建模：流程圖
• 畫Model更多的是不斷澄清需求的過程
• 畫Model的過程讓我們想到更多Test
ideas，而不是用一個Model涵蓋盡可能
多的test ideas。

2. 設計測試條件
流程圖簡單：覆蓋所有路徑
流程圖複雜：
主要流程(MF)
可選補充流程(AF)
右圖為例：
Test Condition1 (MF)
用戶發起註冊申請，成功通過申請
Test Condition2(AF1)
用戶輸入的個人訊息非法
Test Condition3(AF2)
用戶信用檢查不通過

• 利用Given-When-Then描述測試條件
• 以Test Condition1(用戶發起註冊申請，成功通過申請)為例：
測試條件 Given When Then
Tcon-001 -新的未註冊用戶
-網路連接正常
-用戶無違規信用紀錄
-用戶發起註冊申請
-用戶填寫有效用戶訊息
-註冊申請通過
-新生成帳戶和密碼
-標記並告知用戶，將郵
寄帳戶和密碼給用戶
…

P-Parameter參數
• 應用條件：當能夠從需求中明顯地區分出多個參數或變量
• 特點：
1. 需求中經常是「多個參數」佔主導地位，沒有太多流程處理
2. 需求規格的描述中含多條規則，每個規則由多個參數的不同取
值組合而成

P-Parameter應用步驟
1. 建模：判定表、判定樹
圖例1：判定樹
圖例2：判定表

P-Parameter應用步驟
2. 得出測試條件：
判定表每一行規則就是一個測試條件
判定樹由根節點至葉節點的路徑就是一個測試條件

D-Data數據
• 應用條件：當需求緊緊圍繞著一些數據，每個數據有明確的取值
範圍
• 特點：
1. 不像P-Parameter，數據之間沒有明顯的「各種組合關係從而
構成某個規則」，各數據之間邏輯上的關係是較獨立的。
2. 各數據的取值之間有可能存在一些約束關係

D-Data應用步驟
1. 建模：等價類，結合邊界值使用
商品ITEM的行數
VEC 1個 1~Max
IVEC 2個
0行
>Max行(大於最大行數)
VBV 2個 1,Max
IVBV 2個 0, Max+1
*VEC-Valid Equivalent Class
*IVEC-Invalid Equivalent Class
*VBV-Valid Boundary Value
*IVBV-Invalid Boundary Value
邊界值

D-Data應用步驟
• 等價類舉例：有個功能請使用者輸入出生年月日，限制如下
①1≤month≤12
②1≤day≤31
③1912≤year≤2050
測試條件輸入預期輸出
Month Day Year
TCon-01 6 14 2003 2003年6月14日
TCon-02 2 30 1999 輸入日期錯誤
TCon-03 -1 3 2000 輸入日期錯誤
←有效類別
←無效類別
←無效類別

D-Data應用步驟
• 等價類劃分測試
考慮的因素可能的取值表示符號
等價類覆蓋方式
Weak
Normal
Strong
Normal
Weak
Robust
Strong
Robust
引起缺陷的
故障因子個
數
單因子故障
假設
Weak ＶＶ
多因子故障
假設
Strong ＶＶ
是否覆蓋無
效等價類
只覆蓋有效
等價類
Normal ＶＶ
也覆蓋無效
等價類
Robust ＶＶ

D-Data應用步驟
• 等價類範例
Month Day Year
TCon-01 6 14 2003 2003年6月14日
TCon-02 2 23 1999 1999年2月23日
TCon-03 1 3 2000 2000年1月3日
Month Day Year
TCon-01 6 14 2003 2003年6月14日
TCon-02 2 30 1999 輸入日期不正確
TCon-03 -1 -3 2000 輸入日期不正確
一般等價類
強健壯等價類

C-Combination組合
• 應用條件：當需求緊緊圍繞著一些因子，每個因子有幾種不同的
取值，即不同的狀態，但是因子之間的各種組合數目龐大，人工
很難窮舉，需要借助某種技術選擇最有效的一組test ideas的時
候
• 特點：
1. 因子個數多
2. 每個因子有多種可能的狀態
3. 因子之間有可能存在一些邏輯的約束關係

C-Combination應用步驟
1. 建模：因子-狀態表
狀態/因子因子1
性別
因子2
學歷
因子3
年齡
因子4
上一份工作是
否超過一年
1 男學士 21-30 Y
2 女碩士 31-40 N
3 博士 41-50

C-Combination應用步驟
2. 得出測試條件： Pairwise法－2-way組合方式
任意2個因子的任意狀態值的組合均至少出現一次
PICT工具產生測試條件
https://github.com/microsoft/pict
Pairwise.org
http://www.pairwise.org/tools.asp

PICT應用方式
1. 將前述因子狀態表條列成txt檔
2. Terminal 輸入pict testing.txt > test.xls
3. 產生的excel檔會有編碼問題，用記事本開啟xls另存新檔改編碼

S-State狀態
• 應用條件：當需求中涉及多種「狀態」
• 特點：
1. 涉及多種狀態，最好是針對同一對象的多個狀態(把多個對象的
多個狀態都放在一個模型中會造成混淆)
2. 各個狀態之間可以因某種事件的發生互相轉換

S-State狀態
1. 建模：狀態圖→狀態樹
複雜的狀態轉換圖不利於編寫完備的測試用例，為此，我們需要將
其轉換為狀態轉移樹，然後基於狀態轉換樹去設計每個階段的測試
用例。

狀態圖狀態樹
（1）開機→執行→快進→執行
（2）開機→執行→快進→快進
（3）開機→執行→停機→執行
（4）開機→執行→停機
狀態樹 0-switch

狀態樹 1-switch
運
行
停
機

如何選用PPDCS？
• Triggers 關注觸發詞語
• Essentials 抓住核心功能
• Spanning Differences 嘗試不同特徵
• Targets 圍繞既定目標

Triggers 關注觸發詞語
仔細傾聽需求文檔，從中識別PPCDS中相對應的觸發詞
例一
• 這個表格最多可以有多少條紀錄呢？
• 有哪些類型的車？
• 存入DB包含什麼內容呢？如果是空或異常值如何處理？
=>捕捉到Data Triggers

Triggers 關注觸發詞語
例二
• 如果Test fail導致警示燈亮，還沒有停止閃爍的時候，又有其他
的Test fail，這時候燈亮還會重新計時嗎？如果程式修好的時候
燈就會暗嗎？
=>捕捉到State Triggers

Essentials 抓住核心功能
• 蒸餾信息
• 忽略干擾
Triggers列出細節
↓
Essentials抓住核心

Spanning Differences 嘗試不同特徵
• 分別以不同的特徵為基礎建模，然後比較一下這些模型之間的差
異。
• 使用不同的特徵建模，會帶來新的Test ideas。

Targets 圍繞既定目標
尋找Triggers的過程是高度發散的、探索性的過程，如果缺少目標
牽引，很容易從「為一個單功能尋找PPDCS主導特徵」變成「為
多個單功能尋找PPDCS主導特徵」
目標：單功能的核心功能
• 盡量讓所有的發散和探索都圍繞著被測單功能展開
• 避免混淆單功能邊界

避免混淆單功能邊界－TSP Heuristic
TSP Heuristic
• Topic－探索性測試Session的主題
• Scope－這個Session的範圍
• Purpose－本次探索性測試希望達成的目的
單功能：手動修改自動填入的表格數據
Topic：對一個原本是自動填入的數據表格「手動編輯修改」
Scope：填入表單中的聯絡資料送出後，系統自動填入通訊錄數據表格中
Purpose：驗證可以手動修改部分數據，並且修改內容生效

避免混淆單功能邊界－功能結構圖
• 畫一張簡單的功能結構圖，將
各個單功能之間的關係體現出
來，這樣測試分析人員的大腦
中始終有個全局的印象，避免
各功能間的混淆。

Modeling補充說明
1. 是否一定要將測試條件用文件形式描述出來？
2. 建模時想到很多補充的test ideas，是否都以test condition的
方式補充進來？
3. 模型是一次建成的嗎？

Conclusion
• 測試條件代表一些基本測試場景，可以用Given-When-Then描
述。
• 將所有識別出的測試條件進行100%的測試覆蓋不見得是最好的
測試策略。
• 不要指望使用某一種方法就可以解決測試完整性的問題。
• PPDCS有助於解決「如何更有效地選取合適的測試設計來建模」
的問題。
• 畫Model的過程讓我們想到更多的test ideas，而不是用一個
Model涵蓋盡可能多的test ideas。

Conclusion
• 不同的Model，得出測試條件的方式也是不一樣的。
• 畫Model的過程可以發現很多問題和風險，越早進行越好。
• 畫Model的過程是對原來模糊的問題不斷澄清的過程。
• 沒有哪一種Model可以全面地刻畫一個需求的方方面面。

建模練習引導
• 描述單功能
• 識別PPDCS主導特徵
單功能編號 (例如M1)
單功能標題 (例如輸入出生年月日)
單功能描述 Topic：
Scope：
Purpose：
需求描述尋找Triggers
例如：購買超過5樣相同商品就可以得
到八折優惠
>> Data rules Triggers
…
…
…
…

建模練習引導
• 基於主導特徵建模
根據選的主導特徵，採用相應的技術建模。
如果有多個夥伴一起練習，可以相互討論參考彼此的Model，提升
對Model的理解，反覆討論不斷修正。
• 基於Model得出測試條件
測試條件 Given When Then
TCon-001 …
TCon-002 …
… …

練習題－佣金問題
• 某銷售商銷售步槍機、槍托和槍管。槍機賣45美元、槍托賣30美元、
槍管賣25美元。
• 銷售商每月至少要售出一支完整的步槍，且生產限額是大多數銷售商
在一個月內可銷售70槍機、80個槍托和90個槍管。每訪問一個小鎮後，
銷售商都給製造商發出電報，說明在每個小鎮中售出的槍機、槍托和
槍管的數量。到了月末，銷售商要發出一封很短的電報，通知有-1個
步槍被售出，這樣步槍製造商就知道當月的銷售情況，並計算銷售商
的佣金。
• 銷售額不到（含）1000美元的部分為10%，1000（不含）~1800
（含）美元的部分為15%，超過1800美元的部分為15%，超過1800
美元的部分為20%。
• 佣金程式生產月份銷售報告，彙整售出的槍機、槍托和槍管總數，銷
售商的總銷售額以及佣金。

分析過程－尋找Triggers
某銷售商銷售步槍機、槍托和槍管。槍機賣45
美元、槍托賣30美元、槍管賣25美元。
>> 3個Data：槍機單價、槍托單價、槍管單
價
銷售商每月至少要售出一支完整的步槍，且生
產限額是大多數銷售商在一個月內可銷售70槍
機、80個槍托和90個槍管。
>>第1條Rule：每月至少要售出一支完整步
槍
>>3個Data：槍機數量、槍托數量、槍管數
量
每訪問一個小鎮後，銷售商都給製造商發出電
報，說明在每個小鎮中售出的槍機、槍托和槍
管的數量。到了月末，銷售商要發出一封很短
的電報，通知有-1個步槍被售出，這樣步槍製
造商就知道當月的銷售情況，並計算銷售商的
佣金。
>>這段話與傭金計算沒有什麼關係，是「傭
金計算」這個核心功能的干擾訊息。

分析過程－尋找Triggers
銷售額不到（含）1000美元的部分為10%，
1000（不含）~1800（含）美元的部分為15%，
超過1800美元的部分為15%，超過1800美元的
部分為20%。
>>2個Data：銷售額、傭金率，與輸出值有
關（取值取決於輸入數據－槍機、槍托、槍
管的價錢和數量）
>>第2條Rule：分段計算傭金
佣金程式生產月份銷售報告，彙整售出的槍機、
槍托和槍管總數，銷售商的總銷售額以及佣金。
>>只是簡單羅列上面計算的結果，與「傭金
計算」這個核心功能關係不大，是個干擾訊
息。

分析過程－Data特徵建模
Data 等價類 Weak Robust Test Conditions(弱健壯測試條件)
正常情況下的銷售額(P) 異常情況下的銷售額
P<=1000,
傭金率r=10%
1000<P<=1000,
傭金率r=15%
P>1800,
傭金率r=20%
槍機數量
(m)
VEC 1~70 45m 45m 45m 45m 45m
IVEC 0 0
槍托數量
(n)
VEC 1~80 30n 30n 30n 30n 30n
IVEC 0 0
槍管數量
(q)
VEC 1~90 25q 25q 25q 25q 25q
IVEC 0 0
傭金 (45m+30n+25q)*r 0
Test Condition編號 TCon-001 TCon-002 TCon-003 TCon-
004
TCon-
005
TCon-
006

分析過程－釐清模糊點並更新測試條件
• 在建模過程中會遇到需求模糊點
EX1：超出銷售額的處理方式？
EX2：不滿足「至少需銷售一支完整步槍」規則時，如何處理？
• 模糊點釐清過程同時不斷更新Model和Test Conditions

MFQ and PPDCS book sharing CH1-3

Recommended

Recommended

More Related Content

Featured

Featured (20)

MFQ and PPDCS book sharing CH1-3

Editor's Notes