文章目录
前言
-
什么是海盗派tester?
-
测试分析的目的:如何在有限的测试时间和测试资源的条件下,从无限多可能中挑出那些right test idea,以便达到"以尽可能少的时间、发现尽可能多的bug"的测试效果
-
本书大纲
KYM(Know Your Mission)
了解您的测试任务。
拿到一个测试对象,可以根据以下思路进行分析。
-
第一步:可以问出多少问题?
对被测对象问问题的能力就是测试分析中的一部分,针对任何一个被测对象,可以提问出无数多个问题。 -
第二步:哪些是最好的问题
需要在这无穷多个问题中找到最好的问题,什么是最好的问题呢?有更高几率帮我们找到bug的问题就是好问题。 -
第三步:哪些地方容易出现bug?
出现bug的地方就是风险比较高的地方。任何风险都有2个重要的属性:风险发生的可能性和风险发生后的影响,根据这两个属性进行综合起来排序,得到最有价值的问题。 -
第四步:分析风险发生的影响和风险发生的可能性
风险发生的可能性和什么有关呢?这就需要凭借测试人员的经验来进行判断了,比如需求复杂度,技术复杂度,研发人员经验,测试人员经验,时间是否充裕。
风险发生后的影响有多大呢?这个问题恐怕要数用户了,我们需要深入了解用户痛点所在,我们产品帮助用户解决了什么样的问题,用户为什么会提出这样的需求,这样这容易判断失效影响。 -
第五步:收集更多的信息
这样一来,为了判断L和I的大小,我们可能需要问出更多的问题,了解更多的信息。 -
第六步:按风险大小排序选出高优问题
根据风险值对问题进行排序筛选出高优问题。 -
第七步:风险持续评估
风险是不断变化的
问问题的能力对于测试人员来说非常重要,KYM的本质就是不断问问题,收集信息,了解上下文,对测试最终达成的目标有更加清晰的认识,KYM像航海中的灯塔一样,时刻帮助测试人员辨别方向。
比how更重要的是先想清楚why的问题,了解清楚任务本身以及任务背景,明确最终达到的目的,然后开始考虑how的问题,并且在执行过程中不断深入理解why,不断迭代和优化why,使得输出的what和任务目标始终是对其的,我们把这种说法叫Know Your Mission。促进测试人员与周边沟通,即时获取有价值的信息,提前发现风险所在,也正是KYM的价值所在。
在做KYM时,谨记把握主干、忽略细节。
实际案例
产品经理就给程序员1句话:造一个电梯。
对于这样子的一句话需求,没有明确的其他信息,这时候就需要KYM
- 电梯要造的地点在哪里?
- 电梯层数几层?
- 电梯用户对象是什么,公司还是小区?
- 电梯运行快慢有没有要求?
- 电梯的容量多大?
- 电梯最大承重多少?
- 多久造好?
- 材料是否充足?
- 研发人员怎么分配?
- 制造的材料是否合格?
。。。。
TCO(Testing Coverage Outline)
测试覆盖大纲,从测试的角度定义需求的过程,以便所有人都明白针对当前被测系统又哪些测试需求。该项技能主要应用在没有需求文档或者设计文档可以依照,没有可运行的程序提供线索,此时只有通过交流的方式获取信息。
作用:
-
信息提炼
- 当遇到比较紧急的项目提测,之前又没有看需求文档,时间又很紧急情况下怎么办?我们可以使用KYM明确测试需求,TCO整理测试大纲,花2小时进行探索性测试对被测系统进行学习。这样就节约了学习被测对象的时间。
-
内容重组
有时候获取的信息是凌乱的,这时候需要重组信息,便于理解
MFQ
如何画TCO呢,最常用的方法就是MFQ
- M:单功能分析与测试设计
- F:功能交互的测试分析与设计
- Q:质量属性的测试分析与设计
- question(可选):对于疑问点的罗列
- risk(可选):对于识别出的风险进行罗列
实际案例
- 当需求文档杂乱无章的时候,此时就可以使用TCO的方法,对详细进行提炼重组,便于理解。
- 当需求文档达到几十页甚至几百页的时候,使用TCO的方法快速提取关键信息,从而加快理解被测对象的时间。
- 没有需求或者设计文档可依,还没有可以运行的程序可以探索,测试人员还不熟悉代码,并且产品代码大量复杂,只好通过交流的方式获取信息。
- 让产品经理介绍特性
- 过程中边倾听,边问问题,边记录,TCO草稿
- 根据TCO草稿,进行脑暴test idea
Modeling
经过TCO,我们识别出了很多单功能M,对于这些单功能如何进行测试分析呢。可以使用建模的方式对其进行测试分析。
PPDCS介绍
P-Process
介绍
当需求中有明显的业务流程的含义时,可以采用P-Process建模,P-Process业务流程的特点是:
- 有多个步骤,各步骤之间有一定的前后约束关系,所有步骤共同完成一件事情
- 整个过程可能涉及多余1个的执行者或者触发者
P-Process建模的常用手段:画流程图
案例
需求
- 用户登录注册的流程
- 词条审核流程
测试分析
model的过程是让我们想到更多的test idea,而不是用一个model涵盖尽可能多的idea
设计测试条件
- 如果流程比较简单,分支少,可以考虑覆盖所有的路径
- 如果流程图比较复杂,分支繁多,可以考虑“主要流程”+"可选补充流程"的方式覆盖
P-Parameter
介绍
能够从需求中明显的区分出多个参数或者变量,可以考虑P-Parameter方式建模。
特点:
- 需求中经常多个参数占主导地位,没有太多流程上的处理
- 需求规格的描述中含有多条规则,每个规则由多个参数的不同取值组合而成
P-Parameter建模的常用手段:决策表,决策树
案例
需求
政府规定的汽车保费是根据考虑了成本的基本利率计算而成的。该计算的输入如下所示:
- 基本利率是600美元。
- 保险持有者的年龄( 16 ≤年龄< 25; 25 ≤年龄< 65; 65 ≤年龄< 90 )。
- 小于16岁或者大于90岁的,不予保险。
- 过去5年中出险次数(0、1-3、4-10 )。
- 过去五年,出险次数超过10次的,不予保险。
- 好学生减免50美元。
- 非饮酒者减免75美元。
测试分析
拿到需求后明确输入与输出
输入条件:基本利率、年龄、出险次数、是否为三好学生、是否为非饮酒者
输出:汽车保费
首先识别出需求中存在的多个参数,并且每个参数有各种可能的取值,把这些参数放入表格的纵列,然后识别出需求中的所有规则,每一个规则涉及多个参数的组合,在表格中每一行代表一个规则。
判断出这个需求的参数部分有:年龄、出险次数、是否为三好学生、是否为非饮酒者
决策表
年龄 | 出险次数 | 是否为三好学生 | 是否为非饮酒者 |
---|---|---|---|
16 ≤年龄< 25 | 0 | Y | Y |
25 ≤年龄< 65 | 1-3 | N | N |
65 ≤年龄< 90 | 4-10 | ||
年龄小于16岁或者大于90岁 | 10以上 |
设计测试条件
使用正交方法获得了4x3x2x2=48个测试条件,根据业务或者pairwise方法选取最有用的测试条件进行测试执行。
D-Data
当需求仅仅围绕一些数据,每个数据有明确的取值范围时,可以考虑使用D-Data来建模。
特点:
- 不像P-Parameter,使用D-Data建模的M,数据之间没有明显的"各种组合关系从而构成的某个规则",各数据之间的逻辑上相互比较独立的
- 各数据之间可能存在约束关系
D-Data建模的常用手段:等价类划分
案例
需求
用户资料补充需求输入输出如下:
输入:
字段 | 类型 | 必填 | 含义 |
---|---|---|---|
id | Integer | Y | 用户id |
name | String | Y | 姓名 |
phone | String | Y | 手机号 |
idCard | String | Y | 身份证号 |
输出:
code | message |
---|---|
0 | 成功 |
10000 | 系统错误 |
10001 | 参数缺失 |
10002 | 参数错误 |
测试分析
设计测试条件
等价类划分用例设计一般是一个正例配上多个反例
C-Combination
当需求围绕一些因子的时候,每个因子有几种不同的取值,但是因子之间各种组合数目庞大,人工很难穷举,可以采用C-Combination方式建模。
特点:
- 因子个数多
- 每个因子有多种可能状态
- 因子之间有可能存在逻辑约束
案例
需求
有一个产品的输入如下:
下拉单选: 0-9
下拉单选: checked, unchecked
单选按钮: on, off
填写框: 1-100
请设计精简而高覆盖率的测试用例
测试分析
思路:
如果使用常规的组合测试,需要用例的数量为:1022*100=4000个,那人都要点傻了。
使用等价类简化用例:
下拉单选: 0-9的等价类为:0与其他数字
填写框: 1-100的等价类为:范围内的数字,范围外的数字,非数字
那么用例数量就减少到222*3=24个,那么还能不能减少呢?
使用Pairwise/All-Pairs精简用例:
- 变量排序【确认变量和因子】,这个例子中,因子的排序顺序如下:
填写框: 1-100 | 单选按钮: on, off | 下拉单选: checked, unchecked | 下拉单选: 0-9 |
---|---|---|---|
3 | 2 | 2 | 2 |
-
根据第二个变量计算出第一个变量需要的用例数(行数),3*2=6,需要6行
-
每增加一列(n),则需要看 1和n,2和n,。。。 n-1和n之间是否覆盖了两列之间所有的组合,如果没有则适当调整上下的位置。直到所有都符合。
填写框: 1-100 | 单选按钮: on, off | 下拉单选: checked, unchecked | 下拉单选: 0-9 |
---|---|---|---|
valid Int | on | checked | 0 |
valid Int | off | unchecked | others |
invalid Int | on | unchecked | others |
invalid Int | off | checked | 0 |
Alpha Special | on | checked | 0 |
Alpha Special | off | unchecked | others |
设计测试条件
24个用例就缩减到了6个
S-State
当需求中涉及多种状态时,可以考虑采用S-State特征来建模。
特点:
- 涉及多种状态,最好是针对同个对象的多个状态,否则把多个对象的多个状态都放在一个模型中表达,容易混淆
- 各个状态之间可以由某种事件相互转换
案例
需求
有一个产品的输入如下:
下拉单选: 0-9
下拉单选: checked, unchecked
单选按钮: on, off
填写框: 1-100
请设计精简而高覆盖率的测试用例
测试分析与测试条件设计
具体见状态图法在软件测试的应用
https://blog.csdn.net/qq_36502272/article/details/115542715
Test Desgin
- 测试设计首先要识别出测试条件中可变化的部分,即变量,然后为每个变量确定具体的取值,最后得出直接拿来执行的测试实例
- 仔细选择测试条件中每个变量的具体取值,以便提高发现缺陷的概率
- 选取测试数据时兼顾多样化原则
这边举个最简单的例子,有个输入框可以输入字母,测试员A输入z,测试员B输入a,同样测试条件是字母,A与B输入的不一样,结果A报错了,B没报错。
虽然这个例子很蠢,但不排除有这种可能性
Test Execution
测试执行需要我们真实的与被测对象接触,基于对原有被测对象的认知和猜测,去进一步挖掘那些未知的信息,包括未知的需求,未知的风险。
测试人员始终坚持的核心原则:
- 主动收集信息
- 尽早提供反馈
- 及时调整策略
- 基于风险测试
测试域是无穷尽的,测试资源是有限的,这两点决定基于风险展开测试始终是一个重要的测试策略。而风险有个重要的特征就是“风险是不断变化的”。所以RBT运用的效果取决于是否能根据风险的变化及时调整测试策略。
个人理解–读后感
本书条理清晰且确实能让人受益匪浅打开思路,给测试人员带来一些方法论上的启发。
结合实际业务测试,感觉KYM和TCO的思想确实很有用:
- 面对模糊的需求,或者一句话需求,就需要使用KYM的能力对被测需求进行不断的提问,了解背景。之后使用TCO的方法梳理逻辑,方便测试。
- 面对几十页几百页的需求文档,我们可以使用TCO的方法整理测试大纲,明确主线脉络,方便理解需求。
MFQ的建模思路也很有用,从单模块,模块交互以及非质量属性这几个维度对需求进行拆分,易于理解。
至于PPDCS,就显得过于理论了,实际项目中:
- 对于复杂业务一般使用流程图梳理逻辑就够了
- 对于状态比较多的需求,使用状态图建模
- 对于后面的几种方法PDC,一般用于接口测试用例设计或者单测用例设计上,但是过程过于冗余,感觉不适合互联网,敏捷模式下的软件测试
TD不做评论,基本用不到。
TE中基于风险不断调整测试策略也是很好的思想,用例都是有重要程度与优先级的,他们的执行顺序需要根据风险不断进行调整。