《海盗派测试分析》读书笔记

前言

• 什么是海盗派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

1. 电梯要造的地点在哪里？
2. 电梯层数几层？
3. 电梯用户对象是什么，公司还是小区？
4. 电梯运行快慢有没有要求？
5. 电梯的容量多大？
6. 电梯最大承重多少？
7. 多久造好？
8. 材料是否充足？
9. 研发人员怎么分配？
10. 制造的材料是否合格？
    。。。。

TCO(Testing Coverage Outline)

测试覆盖大纲，从测试的角度定义需求的过程，以便所有人都明白针对当前被测系统又哪些测试需求。该项技能主要应用在没有需求文档或者设计文档可以依照，没有可运行的程序提供线索，此时只有通过交流的方式获取信息。
作用：

1. 信息提炼

   • 当遇到比较紧急的项目提测，之前又没有看需求文档，时间又很紧急情况下怎么办？我们可以使用KYM明确测试需求，TCO整理测试大纲，花2小时进行探索性测试对被测系统进行学习。这样就节约了学习被测对象的时间。

2. 内容重组

有时候获取的信息是凌乱的，这时候需要重组信息，便于理解

MFQ

如何画TCO呢，最常用的方法就是MFQ

• M：单功能分析与测试设计
• F：功能交互的测试分析与设计
• Q：质量属性的测试分析与设计
• question(可选)：对于疑问点的罗列
• risk(可选)：对于识别出的风险进行罗列

实际案例

• 当需求文档杂乱无章的时候，此时就可以使用TCO的方法，对详细进行提炼重组，便于理解。
• 当需求文档达到几十页甚至几百页的时候，使用TCO的方法快速提取关键信息，从而加快理解被测对象的时间。
• 没有需求或者设计文档可依，还没有可以运行的程序可以探索，测试人员还不熟悉代码，并且产品代码大量复杂，只好通过交流的方式获取信息。
  1. 让产品经理介绍特性
  2. 过程中边倾听，边问问题，边记录，TCO草稿
  3. 根据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美元。
  

测试分析

拿到需求后明确输入与输出
输入条件：基本利率、年龄、出险次数、是否为三好学生、是否为非饮酒者
输出：汽车保费

首先识别出需求中存在的多个参数，并且每个参数有各种可能的取值，把这些参数放入表格的纵列，然后识别出需求中的所有规则，每一个规则涉及多个参数的组合，在表格中每一行代表一个规则。

判断出这个需求的参数部分有：年龄、出险次数、是否为三好学生、是否为非饮酒者

决策表

设计测试条件

使用正交方法获得了4x3x2x2=48个测试条件，根据业务或者pairwise方法选取最有用的测试条件进行测试执行。

D-Data

当需求仅仅围绕一些数据，每个数据有明确的取值范围时，可以考虑使用D-Data来建模。
特点：

• 不像P-Parameter，使用D-Data建模的M，数据之间没有明显的"各种组合关系从而构成的某个规则"，各数据之间的逻辑上相互比较独立的
• 各数据之间可能存在约束关系

D-Data建模的常用手段：等价类划分

案例

需求

用户资料补充需求输入输出如下：
输入：

输出：

测试分析

设计测试条件

等价类划分用例设计一般是一个正例配上多个反例

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. 变量排序【确认变量和因子】，这个例子中，因子的排序顺序如下：

2. 根据第二个变量计算出第一个变量需要的用例数（行数），3*2=6，需要6行

3. 每增加一列（n），则需要看 1和n，2和n，。。。 n-1和n之间是否覆盖了两列之间所有的组合，如果没有则适当调整上下的位置。直到所有都符合。

设计测试条件

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中基于风险不断调整测试策略也是很好的思想，用例都是有重要程度与优先级的，他们的执行顺序需要根据风险不断进行调整。