Más contenido relacionado MFQ and PPDCS book sharing CH1-33. 五大主題
1. 了解測試任務(KYM) Know Your Mission
了解測試的用戶及用戶的需求
2. 測試覆蓋大綱(TCO) Test Coverage Outline
大致確認測試的範圍
3. 建模(Modeling)
針對每一個測試內容,分析需要的測試點,以實現上述的測試需求
4. 測試設計(TD)
編寫測試實例,實現測試需求
5. 測試執行(TE)
發布給測試人員
5. WHY? 為什麼要做KYM?
• 找出BUG所在 = 找出風險所在
1. 收集信息
2. 風險識別
3. 風險分析
4. 風險控制
• Right test ideas > test ideas
以盡可能少的時間、發現盡可能多的、盡可能重要的BUG
7. How? 怎麼做到KYM
Critical Thinking 批判式思維(問問題的能力)
1. Huh?
真的理解對方說的話了? 是否有疑惑? 有沒有模糊的地方?
2. Really?
這是真的嗎? 有確切的證據嗎?
3. So?
為什麼要關注這件事? 這件事與誰相關? 相關度多大? 接下來要做
什麼?
9. CIDTESTED引導詞法 分析項目環境
• Test Team — 有幾個測試團隊,測試人員經驗,測試穩定度,測
試人手是否充足
• Equipment & Tools — 需要的設備工具,測試環境,有無自動
化測試腳本
• Schedule — 何時交給用戶,一次性還是分期,最早何時拿到可
測試版本
• Test Item — 主要測試項目,哪些降低優先等級,產品改變後的
測試策略
• Deliverable — 需要測試的交付件有哪些,有無模板或
CHECKLIST
13. 五大主題
1. 了解測試任務(KYM) Know Your Mission
了解測試的用戶及用戶的需求
2. 測試覆蓋大綱(TCO) Test Coverage Outline
大致確認測試的範圍
3. 建模(Modeling)
針對每一個測試內容,分析需要的測試點,以實現上述的測試需求
4. 測試設計(TD)
編寫測試實例,實現測試需求
5. 測試執行(TE)
發布給測試人員
23. TCO補充及總結
• When to apply TCO?
1. 需了解測試整體範圍時
2. 對被測對象不熟,而想快速學習時
• 並不是必須有KYM才能畫TCO(視對程式了解程度決定)
• 各功能劃分可能改變
• 粒度如何決定?
視風險質量(Testing Rely on Risks)
26. 五大主題
1. 了解測試任務(KYM) Know Your Mission
了解測試的用戶及用戶的需求
2. 測試覆蓋大綱(TCO) Test Coverage Outline
大致確認測試的範圍
3. 建模(Modeling)
針對每一個測試內容,分析需要的測試點,以實現上述的測試需求
4. 測試設計(TD)
編寫測試實例,實現測試需求
5. 測試執行(TE)
發布給測試人員
36. 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
邊界值
38. D-Data應用步驟
• 等價類劃分測試
考慮的因素 可能的取值 表示符號
等價類覆蓋方式
Weak
Normal
Strong
Normal
Weak
Robust
Strong
Robust
引起缺陷的
故障因子個
數
單因子故障
假設
Weak V V
多因子故障
假設
Strong V V
是否覆蓋無
效等價類
只覆蓋有效
等價類
Normal V V
也覆蓋無效
等價類
Robust V V
39. 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 輸入日期不正確
一般等價類
強健壯等價類
54. 避免混淆單功能邊界-TSP Heuristic
TSP Heuristic
• Topic-探索性測試Session的主題
• Scope-這個Session的範圍
• Purpose-本次探索性測試希望達成的目的
單功能:手動修改自動填入的表格數據
Topic:對一個原本是自動填入的數據表格「手動編輯修改」
Scope:填入表單中的聯絡資料送出後,系統自動填入通訊錄數據表格中
Purpose:驗證可以手動修改部分數據,並且修改內容生效
64. 分析過程-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
Notas del editor P43 P39 Reference: https://www.digitimes.com.tw/iot/article.asp?cat=158&cat1=20&cat2=10&id=0000513686_mer7701v720evy71lm117
P44 P49 50 P51 52 https://medium.com/@hokihorris/%E6%B5%B7%E7%9B%9C%E6%B4%BE%E6%B8%AC%E8%A9%A6%E5%88%86%E6%9E%90-%E9%82%B0%E6%9B%89%E6%A2%85-%E7%AD%86%E8%A8%981-a12c4320fb15 P57 P63 P64 P76
圖 P94 P78 80 P80 P88 P92 P95 P96 P100 P101 104 P104
P105、P106說明 P108 109 P112 113 2018-02-01海盗派测试分析 -读书笔记 https://www.jianshu.com/p/d45adb3b179e
MF-Main FlowAF-Additional Flow
舉例:RegisterService 更多因果圖、判定表圖例:https://www.cnblogs.com/KalosOwen/p/8244846.html P177通常情況,對於「數據」和「參數」區分沒有那麼明顯
本書中 數據指的是一些簡單的具有一定取值的名詞
而參數指這些名詞還參與到業務規則的處理中
相比於這些名詞取某個值時程序是否正確,「參數」更關心規則的處理是否正確 這裡是以印出收據為例,所以以商品ITEM行數舉例。 Reference: https://www.itread01.com/content/1547093701.html
關於強弱健壯等價類劃分的說明:
https://www.itread01.com/content/1547259661.html “弱”是指含單缺陷假設(失效極少是由兩個或兩個以上的缺陷同時引起的),
“強”是指含多缺陷假設(失效是由兩個或兩個以上的缺陷同時引起的);
“一般”是指不考慮無效值。 弱一般等價類測試用例通過使用一個測試用例中的每個有效等價類(區間)的代表值來實現(常以對稱方式來標識這些測試用例,且注意單邊假設作用) 參考說明:
https://zhuanlan.zhihu.com/p/58809365
#Title
Header: a,b,c
Header2:a,b,c,d
Header3:a,b….
>pict FileName.txt>OutputFile.xls Reference: UML超新手入門(10)狀態圖型
http://www.codedata.com.tw/java/umltutorial-10/
Reference: 測試設計之狀態轉換圖
https://www.itread01.com/content/1547492249.html 按照這種方法可以設計2-switch、3-switch……但是,在實際工作中,航空和醫療等特殊領域除外,一般做到1-switch就已經足夠了。 P191 Test Heuristics
啟發式評估方法簡介
https://iflytekux.lofter.com/post/297ff9_289a64c
P197 P198
抓住核心功能的兩層涵義
客戶一定會講出很多很多需求,從他的需求中尋找關鍵,發現問題並且釐清
舉例:? P205
同樣的需求可能會識別出不同模型,該如何判斷哪一個模型比較好?
使用不同模型建模,經驗多了慢慢的就比較不會舉棋不定!
舉例:?? P209 P210
有效避免單功能發散的方法,在尋找PPDCS主導特徵之前,先給單功能起名字,並且用一兩句話描述其核心功能
在後續尋找PPDCS主導特徵的過程中,以及建模過程中,都始終圍繞這個核心功能進行。 P212
視情況而定,當測試時間緊張、採用手動測試而不是自動化測試,測試人員熟悉被測對象或是直接參與了測試分析的過程,可以不用將時間花在描述測試條件上,完全可以直接拿著Model去做探索性的測試。如果測試人員完全沒有參與測試分析,對被測對象不了解或缺乏測試觀察能力和探索性測試能力,則文件可能要詳細點。=>根據當前自己的測試上下文,自由決定是否要出具文本形式的測試條件。
不要試圖讓Models負擔太多的內容,請把補充的test ideas正確的放在屬於它的單功能測試項目(可能不見得是同一個Model),或者在交互測試、質量測試才去執行=>正確辨識自己要補充的test ideas是否屬於此models。
當然不是。不要一開始就追求完美,Model一定是逐步演進來的。 P212 實際用例 以spo-server-postgres為例:https://docs.google.com/spreadsheets/d/1Vy5K105yi8OjFM7moV7D5qtkZ0w0U-st2uSusYkjhUg/edit#gid=0
P200 針對異常情況的銷售額,這裡只是用Weak Robust方式覆蓋了3個異常的等價類,實務上可以視需求增加測試條件。