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