海盗派测试分析
海盗派测试分析读书笔记.png
1.了解测试任务
1.1为什么要做KYM
可以问出多少问题
哪些是最好的问题
哪些地方才容易出BUG
效果：以尽可能少的时间、发现尽可能多的、尽可能重要的BUG
分析风险发生的影响和可能性
收集更多的信息
按风险大小排序选出最高优先级的问题
1.2HOW
CIDTESTD来自启发式测试策略模型
Customers用户
Infomation信息
Developer Relations关系
Test Team测试团队
Equipmengt&Tools设备和工具
Schedule进度
Test Item测试项
Deliverables交付件
1.3 怎么做KYM
了解用户
了解项目
了解产品
了解测试任务本身
是一种Heuristic
重点了解被测对象与质量相关信息，查看已有BUG，翻阅线上反馈
1.4小结
不必拘泥表面形式，据测试上下文
重视过程比结果更重要
不要过度关注细节，15min-2H做一次KYM即可
2.测试覆盖大纲
2.1 TCO是什么
通过测试执行而不是阅读文档方式了解被测对象包含的主要功能点，并用思维导图的形式记录下来
2.2 TCO达成结果
信息提炼
内容重组
对信息源中提取的信息进行重新组织，以及对于信息源中没有的信息的添加
心中有数
2.3怎么做TCO
提取出有价值的信息
将所提取出有价值的信息进行结构化整理
系统地图（思维导图）
过程地图
对比地图
2.4 TCO实例（SFDIPOT)
S
structure
产品是由什么组成的？
F
function
产品是做什么的？
D
data
产品处理什么数据？
I
interface
产品与外部有哪些接口？
P
Platform
产品所依赖的东西？
O
Operation
产品是怎样被使用的？
T
Time
产品与时间相关的任何方面
2.5 MFQ的思路
M
单功能测试分析与测试设计
F
功能交互测试分析与测试设计
Q
质量属性测试分析与测试设计
2.6 什么时候应用TCO
当需要了解测试的整体范围时，或者当对被测对象还不熟悉而想快速地学习了解它时
3.建模
3.1 例子
确定测试对象
确定单功能的边界
单功能拆分
挑选一个单功能建模
确定“M2-业务规则处理”边界
选择MODEL
确定参数（判定表表头）
识别业务规则
判断规则完整性
得出测试条件
M/识别测试条件
覆盖测试模型
M/用Given-when-Then描述Test Condition
3.2 模型（PPDCS）
P-Process流程
特点
流程图表达建模：有多个步骤，各步骤间有一定前后约束关系，所有步骤共同完成一件事情；
整个过程可能涉及多于1个执行者或触发者
步骤
建模（流程图，抓重点）
设计测试条件（主要流程MF+可选补充流程AF)
流程图（推荐）
流程图简单，分支少，覆盖所有路径
流程图复杂，分支多，流程图无法全部包含，采用“主要流程MF+可选补充流程AF”的方式覆盖模型
Given-When-Then描述测试条件
P-Parameter参数
应用条件
特点
需求中经常是“多个参数”占主导地位，而没有太多“流程”上的处理
需求规格的描述中含有多条规则，每个规则由多个参数的不同取值组合而成
需求明显区分多个参数或变量时可用此建模
应用步骤
建模
判定表、判定树，因果图等测试设计技术来画MODEL
判定表
条件 桩
动作桩
设计测试条件
自然描述法构造的判定表MODEL，每行规则就是一个测试条件
判定树MODEL，从根节点到每个叶子节点的路劲就是一条规则（测试条件）
D-data数据
应用条件
特点
不像P-Parameter,数据之间明显的“各种组合关系从而构成某个规则”各数据之间逻辑上的关系是相互比较独立的
各数据的取值之间有可能存在一些约束关系
需求紧紧围绕数据，每个数据有明确的取值范围时，考虑用此建模
应用步骤
建模
等价类、边界值
设计测试条件
覆盖等价类（边界值）表格
4个覆盖方式
Weak Normal
Strong Normal
Weak Robust
Strong Robust
C-Combination组合
应用条件
特点
因子个数多
每个因子有多种可能的状态
因子之间有可能存在一些逻辑约束关系
需求紧紧围绕“因子”每个因子不同取值，考虑此建模
应用步骤
建模
因子-状态表 表达模型
设计测试条件
使用PICT工具得出测试条件的过程就是编写一个脚本，将各个因子和状态，以及约束关系用类似编程的方式体现出来
S-State状态
应用条件
特点
涉及多种状态，最好是针对同一个对象的多个状态，否则把多个对象的多个状态都放在一个模型中表达，容易引起混淆
各个状态之间可以由于某种事件的发生相互转换
需求设计多种状态时，考虑此模型
应用步骤
状态图表达模型
设计测试条件
覆盖状态图
3.3 如何选用PPDCS
关注触发词语
用逻辑倾听的方式寻找需求中与“流程”、“规则”、“数据”、”状态“相对应的触发词语
倾听到名字，可能是DATA数据
倾听到一串名字和动作，可能是规则
倾听到一系列事件，可能是流程
抓住核心功能
蒸馏信息
信息过滤与剔除
忽略干扰
尝试不同特征
接触时下意识的从MFQ三个维度和PPDCS五个特征去分析和思考
围绕既定目标
避免单功能边界，忘记核心功能错误方法
寻找单功能PPDCS主导特征前，给单功能起名，采用TSP Heuristic
T-Topic探索性测试Session主题
S-Scope是这个Session的范围
P-Purpose本次探索性测试希望达成目的
画一张简单的功能结构图，将各个功能之间的关系体现出来
测试分析应注意区分
3.4 建模过程精简
描述单功能
识别PPDCS主导特征
Test Heuiristic
寻找Triggers
基于主导特征建模
画MODEL
基于MODEL得出测试条件
4. 测试设计
4.1 什么是测试设计
得出具体的测试实例以达成这个测试目标的过程
4.2 为什么要做测试设计
首先要识别测试条件中可变化的部分，即变量
然后为每个变量确定具体的取值
最后得出可以直接拿来执行的测试实例
4.3 怎么做测试设计
识别变量
变化数据
选取数据
兼顾测试的多样化原则
得出测试实例
5. 测试执行
测试的质量不能过分依赖测试分析活动，测试执行的质量不容小觑
5.1 tests与testing
tests是我们设计出来的写成文字的东西
testing挖掘未知的测试信息的行为
5.2 测试反馈环
TA做明智的选择
TS-TA-TE测试反馈环（协作过程）
主动收集信息 、尽早提供反馈
TS基于风险不断调整测试策略
TE收集信息提供反馈
5.3 更早、更快、更频繁
更早：尽早地开始测试分析、尽早地开始了解需求、尽早与客户沟通，尽早验证testing ideas、尽早地考虑如何测试、尽早地提供测试反馈（代码级、接口级、Story级、特性级、系统级）、尽早地开展验收测试、尽早地发现缺陷、尽早地预防缺陷等
更快：在非常高效的探索性测试中，上一个测试结果可以立即为下一个测试提供反馈，决定下一个测试的策略和内容，这种TS-TA-TE测试反馈环是实时发生的
更频繁：测试对项目的反馈更加频繁，风险的识别和更新更频繁、测试优先级和测试策略调整更频繁，这些都可以很好地应对更频繁的需求变化
5.4 快速测试分析和测试设计
KYM：识别我本次Session任务，包括主题、范围和母的
TCO：边探索边绘制一张测试覆盖地图，了解有哪些分支需要或可以去探索
Try:不断地试错，收集更多的反馈信息
TA（持续测试分析）：逐步了解问题域，在大脑中建立问题域模型，基于反馈和已有的经验，分析当前的形势，并快速设计下一步要采取的动作
TS(不断调整测试策略）：不断地识别风险，并根据风险的变化及时调整测试策略
TD（快速的测试设计）：基于TS和TA的结果，快速开展测试设计，选择一个合适的珠子与合适的位置
Observe(观察）：每摆放一个珠子后，都观察最新的局势变化
Communicate(沟通协作）：必要的时候与周边的人沟通交流
记录
交替处理事务：分析、执行、记录、交流等各种活动交替进行
自我管理
回顾
5.5 测试广度与测试深度
测试深度图
横轴：随着时间推移覆盖到的测试点
纵轴：这个测试点上的测试深入程度
BUG的发现与测试深度紧密相关
需要基于上下文考虑测试广度与测试深度的平衡问题
基于风险的测试时最重要的测试策略