测试建模知识点总结

测试建模过程

• 步骤1：为需求创建模型（SUT模型）
  建模：决策表、流程图、状态机、因果图等
  随着测试人员对SUT的更深入理解，需要不断回到此步骤更新模型

• 步骤2：分析失效风险，生成测试想法，在SUT模型基础逐步形成TRM模型，建议使用TQED故障模型，TRM建模的深入程度由测试策略决定
  例如：对于低风险需求，只需要C0,C1级用例时，只需要依据TQED模型进行单个维度分析，不需要维度组合

• 步骤3：测试设计评审（重点评审上一步骤创建的模型），重点关注：

  1. 需求理解和覆盖程度
  2. 建模方法的选择和应用
  3. 模型质量：是否系统全面、容易理解等，是否按照测试策略中的强度要求进行设计，额外的测试思路（评审加脑暴）

• 步骤4：生成/编写测试用例

各种测试建模关系

通过流程图生成测试用例

基本概念

流程图是理解过程性比较复杂需求的重要利器。主要符号如下：

工作中最主要的用到过程和决策。

典型案例

需求

政府规定的汽车保费是根据考虑了成本的基本利率计算而成的。该计算的输入如下所示：

基本利率是600美元。
保险持有者的年龄( 16 ≤年龄< 25； 25 ≤年龄< 65； 65 ≤年龄< 90 )。
小于16岁或者大于90岁的，不予保险。
过去5年中出险次数(0、1_3、310 )。
过去五年，出险次数超过10次的，不予保险。
好学生减免50美元。
非饮酒者减免75美元。

流程图建模

测试用例生成

一般使用等价类的思想，1个正例+无数反例。
这边要把所有case覆盖，那就会产生组合爆炸，一般设计用例的思路如下：

• 基本P0用例集合：务必将每个分支全部覆盖组成的用例集合。
• P1用例：边界值产生的用例集合。

优劣分析

优势：使客户和开发者之间具有更好的交互性，具有扩展性。
劣势：流程图几乎没有办法表达数据，表达数据结构以及数据之间的关系就更难了。

TQED模型辅助分析被测对象

基本概念

当我们思考“计算机程序到底在做什么”时，最常见的答案是：“处理数据”。是的，每个程序都接受一些输入数据，转换它们并输出其它数据， 这个过程与时间有关：程序不能立即返回答案——它需要执行一个算法，需要一些步骤。 程序执行的动作是一些来自软件内部或外部事件的结果，并且来自软件运行的环境。

TQED模型参考物理学的SI国际单位制，提出了四个基本的软件维度：数据（D）、事件（E）、时间（T）和数量（Q）。软件和计算是物理世界的一部分， 这个世界上发生的一切都可以用几个基本属性来描述，比如质量、热力学温度、时间或物质的数量，以此来理解软件的四个基本维度：

• 数据就像物质，它是一种代表信息的物质
• 事件就像热力学，描述物理对象的转换
• 时间就是我们从物理学中知道的时间
• 数量就像物质的数量

然后再根据维度组合来进行测试用例设计

TQED模型只是一种有组织的测试方法的主张。这绝不是测试的灵丹妙药。它在测试过程中为测试人员提供支持，强加一个有组织的工程方法，但不能让测试人员逃避思考。软件分解、选择正确的抽象级别、根据风险分析确定测试的优先级、将维度及其组合映射到实际实体——所有这些都是创造性的部分，不能自动化。

Data 数据

代表了定性或定量的变量值。就TQED模型而言，数据可能是最广泛的维度。Data对象的例子有:

• 内部输入/输出数据
• 变量的值、类型、属性
• 浏览器的cookie
• 发送/接收的消息
• 文件名、文件内容
• 数据库记录
• web表单字段/其值

Event 事件

事件是指在时间上持续时间很短，几乎是即时的事件。这些现象我们可以称之为“出现”或“发生”。事件通常会引起变化。属于E类的样本现象有：

• 创建一个变量，定义它的值，在计算中使用它，或者从内存中删除它
• 调用方法、函数或过程
• 抛出异常
• 通过系统发送或接收信息
• 用户执行一些操作(关闭网页浏览器，在应用程序之间切换，按键盘上的一个键，插/拔设备，关闭计算机，等等)

Quantity 数量

数量是系统或环境中存在的实体的大小或数量。 也可能与不同对象的边界有关。在分析过程中，将其与其他维度结合考虑更有意义。Quantity 的示例如下：

• 空集合/零(无元素nothing)
• 低于最小可能的值/大于最大可能的值
• 最小可能值/最大可能值
• 低值/高值
• 平均值，典型值

Time 时间

时间就是存在物进展，与Quantity类似，它也是一个抽象维度，所以通常会结合其他“真实”维度(如数据和事件)进行分析。然而，我们可以想象一个纯时间维度的测试：一个可靠性测试，我们只是运行程序并观察它是否失败。在这样的测试中，我们不分析任何数据或事件。我们只是等待和观察应用程序。

• 时间可以是离散的，也可以是连续的。它也可以用不同的单位来衡量，例如:
• 正常、真实(时钟)时间，
• Action动作的数量(关注的是行动而不是真正的时间流逝)，
• CPU周期(当我们想要在运行许多其他进程的环境中为测试的应用程序指定正确的时间份额时，我们只计算操作系统处理SUT的CPU周期，这就消除了测量错误(例如，由在后台运行的另一个进程导致应用程序的响应时间更长)。

典型案例

需求

对于微信朋友圈功能如何测试？

需求分析

微信朋友圈主要功能包括：

1. 发表朋友圈
2. 朋友圈权限设定
3. 删除朋友圈
4. 查看朋友圈

TQED建模

维度
数据-Data	发送朋友圈的信息	发表的用户	朋友圈信息的状态	朋友圈信息的发送时间
事件-Event	发表朋友圈	查看朋友圈	删除朋友圈	修改朋友圈
数量-Quatity	发表朋友圈的数量	删除朋友圈的数量	修改朋友圈的数量	查看朋友圈的数量
时间-Time	朋友圈发送的快慢	发送两个朋友圈之间的间隔

生成用例

单维度例子

维度
D	编写朋友圈的信息包含图像
D	编写朋友圈为信息为空
D	编写朋友圈为信息包含emoji图像
D	编写朋友圈为信息为英文字符
D	编写朋友圈时发表的用户为空
D	编写时系统时间为1990年
E	随机发送一个朋友圈
Q	发送2个朋友圈
T	1秒内发送1000个朋友圈

维度组合例子

维度
DD	编写朋友圈的信息包含图像，且编写的用户未登录
DE	发送朋友圈为信息为空
DQ	发送1000个朋友圈

总结

虽然有些用例看样子没有必要，但是对于打开自己的测试思路很有帮助。

组合测试缩减用例数量

在测试工作中，经常会遇到这样的场景：
一个软件功能有多个输入项，每个输入项有多个可选项；一个接口有多个参数，每个参数有多个值。这样的情况在平时非常常见，如果按照排列组合，得到的测试用例数目非常庞大。
举个直观的例子就很容易明白了。有一个接口函数，该函数有3个参数，每个参数又可以取值4个，那如果要验证所有参数传入情况的话则需要测试444=64种情况。
如果参数和取值状态更多话，那将是一个灾难。有没有一种更好的办法，少做一些测试，同时可以满足测试覆盖率呢？

Pairwise/All-Pairs

Pairwise/All-Pairs，也叫配对测试 或 结对测试，是一种软件测试的组合方法，核心在于用最少的测试用例来覆盖多个因素取值的两两组合。

理论基础：根据数学统计分析，73% 的缺陷（单因素是 35%，双因素是 38%）是由单因素或两个因素相互作用产生的。19% 的缺陷是由三个因素相互作用产生的。因此，Pairwise 基于覆盖所有两因素的交互作用产生的用例集合性价比最高而产生的。

步骤总结

步骤总结：

1. 变量排序【确认变量和因子】
2. 根据第二个变量计算出第一个变量需要的用例数（行数）
3. 每增加一列（n），则需要看 1和n，2和n，。。。 n-1和n之间是否覆盖了两列之间所有的组合，如果没有则适当调整上下的位置。直到所有都符合。
4. 如何还是有不符合的，则适当增加几行。

需求案例

有一个产品的输入如下：

下拉单选: 0-9
下拉单选: checked, unchecked
单选按钮: on, off
填写框: 1-100

请设计精简而高覆盖率的测试用例

思路

如果使用常规的组合测试，需要用例的数量为：1022*100=4000个，那人都要点傻了。

使用等价类简化用例

下拉单选: 0-9的等价类为：0与其他数字
填写框: 1-100的等价类为：范围内的数字，范围外的数字，非数字

那么用例数量就减少到222*3=24个，那么还能不能减少呢？

使用Pairwise/All-Pairs精简用例

1. 变量排序【确认变量和因子】，这个例子中，因子的排序顺序如下：

填写框: 1-100	单选按钮: on, off	下拉单选: checked, unchecked	下拉单选: 0-9
3	2	2	2

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

3. 每增加一列（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个

pairwise的优缺点

缺点：

• 业务上高概率的组合受到的关注不够
• 不知道元素之间的依赖关系
  适合的场景：
• 变量的组合特别大的时候
• 参数值很容易划分等价类