重读《测试架构师修炼之道》之测试设计

鉴于近期对测试设计的重新理解，再回顾一遍多年前看过的《测试架构师修炼之道》，得到不少不一样的感悟。

本篇文章包含：

一、测试架构师具备的测试技术能力

二、软件产品质量模型

三、测试设计技术

 

 

一、测试架构师具备的测试技术能力

---

 

书中提到测试架构师需要具备的能力有：

 鉴于书发布时间距离如今接近10年了，由于软件工程的飞速发展，按我的理解，除了上述能力之外，还需要具备：

1.对于系统架构设计的理解能力，微服务、中间件等

2.在软件工程中持续开发、持续集成的能力，CI/CD，docker容器部署等

二、软件产品质量模型

---

 

 软件产品的质量模型主要表现在6个方面：功能性、可靠性、易用性、效率、可维护性、可移植性

6个维度基本上覆盖了测试的质量范围，当前我们的测试方案基本上也围绕这6个维度进行设计，也就不再赘述

三、测试设计技术

---

 

这个章节作为我回顾的重点，重新看还是有很多收益，里面包含四步测试设计法、流程类设计、参数类设计、数据类设计、组合类设计，还有测试用例的颗粒度控制等

3.1四步测试设计法

正常的用例设计为把测试点根据产品质量模型的维度进行测试设计，对测试点使用路径分析法、判定表法、正交分析法、等价类、边界值等方法进行设计加工得到我们的测试用例。

而四步测试设计法通过更好的规范模型对测试用例设计进行指引

 

 step1:建模

对测试点进行模型选择，通常的模型包含以下四类

1）流程类→通过绘制流程图来建立测试模型

2）参数类→通过输入输出表来建立测试模型

3）数据类→通过等价类和边界值来建立测试模型

4）组合类→通过因子表来建立测试模型

 step2:设计基础测试用例

测试用例和基础测试用例的区别在于，测试用例确定了测试条件和测试数据，而基础测试用例只确定了测试条件

也就是说，基础测试用例更加关心的是对模型的覆盖情况

 step3:补充测试数据

在这个步骤中，为基础用例来确定测试输入，补充测试数据，这时的基础用例就称为真正的测试用例了

 step4:用例扩展

模型不能解决测试设计的所有问题，还需要根据经验，针对系统哪些容易发生缺陷的认识，补充一些测试用例，增加系统有效性

3.2流程类测试设计

流程类测试点的特征：

流程类测试点可能测试点变成一些步骤，或者说一个测试点只能绘制出一个流程片段，多个测试点的排列组合整合成一个完整的流程

 

路径分析法：（适用于白盒测试，也适用于流程类的系统测试）

路径分析法是一种基于流程图的测试设计技术，旨在覆盖系统中所有可能的执行路径。该方法通过识别流程中的决策点（分支）和路径，确保每个分支至少被测试一次，从而验证系统在各种条件下的行为。

路径分析法包含以下四种方式：

1）语句覆盖 2）分支覆盖 3）全覆盖 4）最小线性无关覆盖

 

1）语句覆盖

覆盖系统中所有判定和过程中的最小路径集合

 语句覆盖程度相对较弱，不考虑判定和过程之间的相互关系，只考虑覆盖到里面的路径一次足够，所以按这种方式去验证所有流程容易出现遗漏

2）分支覆盖

分支覆盖指覆盖系统中每个判定的所有分支所需最小路径

按字面意思，画出的流程图和语句覆盖是一样的，覆盖程度相对较低

3）全覆盖

全覆盖指的是遍历所有覆盖的集合

 

全覆盖包含了系统的所有路径，但是节点只要稍微一多，需要覆盖的路径会变得特别的庞大，实际也很难按这个方式执行

4）最小线性无关覆盖

仔细分析全覆盖，发现全覆盖中有很多重复执行的路径片段，我们希望每个路径都至少能被执行一次，但又希望减少重复路径的数量，

于是就做一些算法，去判定哪些路径是线性无关路径，得到最少的路径组合，就是最小线性覆盖

 通过这个算法可以得到，只要执行了全覆盖的路径1，3，4，5就已经达成了所有路径的覆盖

 3.3参数类测试设计

根据四步分析法

 

  3.4数据类测试设计

数据类测试设计不同于参数类的点在于，数据类的测试设计更关注于数据值的范围和输入类型，而参数类的设计在于各类参数的组合

所以数据类测试方法一般会用等价类和边界值的设计方法去设计用例，这个比较常见，就不继续解释了

  3.5组合类测试设计

 组合类的测试设计适用正交分析法来生成测试用例，后面单独拉个篇幅出来写写