脑图-海盗派测试分析
2022-03-05 09:17:11 3 举报AI智能生成
登录查看完整内容
软件测试需求分析方法集成，KYM，TCO，质量保障体系
作者其他创作
大纲/内容
可以问出多少问题
哪些是最好的问题
哪些地方风险较高
会出现什么风险
哪些地方容易出现bug
分析风险发生的影响和可能性
收集更多的信息
按风险大小排序选出最高优先级的问题
获取有价值的信息，提前发现风险
为什么要做KYM
交付件
测试项
进度
设备和工具
测试团队
用户
信息
开发者关系
用CIDTESTD引导词法来做KYM
怎么做KYM
问问题的能力
沟通交流的能力
迅速提取有价值信息的能力
记笔记的能力
自我测试管理的能力
识别风险的能力
基于风险调整测试策略的能力
站在用户角度测试的能力
把握测试项目全局的能力
等等
体现测试人员思考问题的方式
KYM是一种Heuristic
KYM补充说明
了解用户
了解项目
了解产品
了解测试任务本身
从项目早期开始介入
较快地、较容易地获得Customers相关信息
获取Project相关信息
了解Mission相关的信息
从项目 中期开始介入
了解Customers、Project、Product、Mission
重点了解被测对象与质量相关的信息
查看已有bug
翻阅从用户现场发来的各种反馈
了解用户和项目利益相关人对质量的预期和与当前质量的差距
从项目后期开始介入
在测试中的任何时期，越早使用越好
什么时候应用KYM
任何人
谁可以使用KYM Heuristic
将KYM形式化
重结果而不重过程
KYM过于关注需求的细节
怎么样吧KYM做糟糕
了解测试任务
大致确定测试的范围
TCO是什么
提取出有价值的信息
信息提炼
将所提取出的有价值的信息进行结构化整理
内容重组
心中有数
怎么画TCO
结构
功能
数据
接口
平台
操作
时间
Bugs
TCO实例，运用SFDIPOT，从不同维度对产品进行测试覆盖
基于模型的单功能测试分析与测试设计
M
功能交互测试分析与测试设计
F
质量属性测试分析与测试设计
Q
MFQ的思路
需要了解测试的整体范围时，或者对被测对象还不熟悉而想快速地学习了解它
什么时候应用TCO
没有办法正确地划分单功能
如何正确地划分单功能
没有一个准确的单功能粒度标准
单功能划分到什么粒度合适
TCO补充说明
测试覆盖大纲
确定测试对象
确定单功能边界
单功能拆分
挑选一个单功能建模
确定M2-业务规则处理边界
流程
参数
组合
状态
选择Model
确定参数（判定表表头）
识别业务规则-普通商品
识别业务规则-称重商品
判断规则完整性
Given-给定被测对象所处的预置状态（预置条件）
When-当执行某个操作时（动作）
Then-发生了什么（后置条件）
借鉴Given-When-Then
对单功能进行测试的一些基本测试场景
得出测试条件
M2建模
确定数据D
M1识别测试条件
M1用Given-When-Then描述Test Condition
M1建模
打印小票实例
等价类表格
边界值
判定表
判定树
场景法
模型
当需求中有明显的“业务流程”的含义时
有多个步骤，各步奏间有一定前后约束关系，所有步骤共同完成一件事
整个过程可能涉及多于1个的执行者或触发者
特点
应用条件
用流程图表达模型
建模
流程图简单，分支少，可以考虑覆盖所有的路径
流程图复杂，分支多，可以考虑“主要流程（MF）+可选补充流程（AF）”的方式覆盖模型
流程图
可以用Given-When-Then的形式来描述测试条件
设计测试条件
应用步骤
P-Process流程
当能从需求中明显地区分出多个参数或变量
需求中经常是多个参数占主导地位，而没有太多流程上的处理
需求规格的描述中含有多条规则，每个规则由多个参数的不同取值组合而成
用判定表、判定树或因果图等来画模型
使用自然描述法构造的判定表，每一行的规则就是一个测试条件
如果是判定树形式的Model，由根节点到每一个叶子节点的路径就是一个规则，可以用一个测试条件来表示
P-Parameter参数
当需求仅仅围绕着一些数据，每个数据有明确的取值范围时
各数据之间逻辑上的关系是相互比较独立
各数据的取值之间有可能存在一些约束关系
用等价类来建模
覆盖等价类（边界值）表格
包括Weak Normal、Strong Normal、Weak Robust、Strong Robust
D-Date数据
当需求紧紧围绕一些因子，每个因子有几种不同的取值
因子个数多
每个因子有多种可能的状态
因子之间有可能存在一些逻辑约束关系
用因子-状态表表达模型，然后可以使用组合类的测试设计技术帮助我们得到测试条件
用Pairwise方法减少组合个数
C-Combination组合
当需求中设计多种状态时
设计多种状态，最好是针对同一个对象的多个状态
各个状态之间可以由于某件事情的发生相互转换
输出与当前状态和输入都有关
Mealy Machine
输出仅与当前状态有关
Moore Machine
有两种典型的有机状态机
用状态图表达模型
选取好行为主体
识别出该行为体具有的各个状态
识别哪些状态之间可以转换
步骤
Chow提出
覆盖状态图
S-State状态
PPDCS是什么
信息以线性的方式顺序呈现出来
需要用心去看、用耳朵仔细聆听这些线性信息中的触发词语
用逻辑倾听的方式寻找需求与流程、规则、数据、状态相对应的触发词语
关注触发词语
蒸馏信息
忽略干扰
抓住核心功能
尝试用P、P、D、C、S每一种特征建模
尝试不同特征
能够清晰地区分出哪些是当前单功能测试分析应该考虑的（M）
哪些应该放到另外一个单功能的测试分析中（M）
哪些属于功能交互部分应该考虑的（F）
哪些应该放到非功能质量属性的测试分析中去考虑（Q）
在做测试分析时
给单功能起个名字，用一两句话描述其核心功能
画一张简单的功能结构图
避免混淆单功能边界、忘记核心功能
围绕既定目标
现状TEST Heuristics
如何选用PPDCS
PPDCS
当时间紧张、采用手工测试而不是自动化测试、测试人员熟悉被测对象或者直接参与了测试分析的过程不用文本描述
是否一定要将测试条件用文本形式描述出来
子主题
建模时想到很多补充的test idear，是否都以test condition的方式补充进来
是逐步演进来的
模型是一次建成的吗
Modeling补充说明
得出具体的测试实例以达成这个测试目标
什么是测试设计
首先要识别测试条件中可变化的部分
然后为每个变量确定具体的取值
最后得出可以直接拿来测试的实例
为什么要做测试设计
识别变量
变化数据
选取数据
得出测试实例
怎么做测试设计
测试设计
TESTS是设计出来的写成文字的东西
TESTING需要与真实的被测对象接触
Tests与Testing
TA最主要的事情就是做出明智的选择
TA-做明智的选择
主动收集信息
尽早提供反馈
及时调整策略
基于风险测试
测试人员处于核心地位
TS-TA-TE测试反馈环
测试反馈环
尽早地开始测试分析、尽早地开始了解需求、等等
在非常高效的探索性测试中，上一个测试的结果可以立即为下一个测试提供反馈
由于测试反馈发生的更早更快，测试反馈环发生的更加频繁
更早、更快、更频繁
KYM：识别我本次Session的任务
TCO：边探索边绘制一张测试覆盖地图，了解都有哪些分支需要或者可以去探索
Try：不断的试错，收集更多的反馈信息
TA（持续的测试分析）：逐步了解问题域，在大脑中建立问题域模型，基于反馈和已有经验，分析当前的形式，病快速设计下一步要采取的动作
TS：不断地识别风险，并根据风险的变化及时调整测试策略
TD：基于TS和TA的结果，快速开展测试设计，选择一个合适的珠子与合适的位置
Observe：没摆放一个珠子后，都仔细观察最新的局势变化
Communicate：必要的时候与周边的人沟通交流
Take Notes：记录关键的，必要的信息
Alternate：分析、执行、记录、交流等各种活动交替进行
Self-Manage：管理自己的强需
Debrief：用简洁的话想别人讲述我的测试
快速测试分析与测试设计
如何理解测试广度与测试深度
测试深度图
怎么表示测试广度与测试深度
测试分析遗漏
测试执行不到位
缺少面向实现的测试
拿着好的测试条件或测试实例去执行，不能确保bug的发现
与发现bug的关系
测试的广度与测试深度
测试执行
海盗派测试分析
0 条评论
回复 删除
下一页
