软件测试测试设计

1. 测试设计的定义

1.1. 定义

测试设计包括测试分析和测试用例，是前期测试需求分析的功能点和测试点通过功能测试设计方法（黑盒测试设计方法）产出测试用例的过程。具体来说，测试分析是确定目标的过程（中间过程）；测试设计是得出具体的测试实例（用例）以达到完成这个测试目标的过程。

2. 测试用例设计方法

2.1. 黑盒测试

黑盒测试(功能测试)：这种方法把被测软件看成黑盒，在不考虑软件内部结构和特性的情况下测试软件的外部特性。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。

2.1.1. 等价类划分法

定义：把所有可能输入的数据分为若干个区域，然后从每个区域中取少量具有代表性的数据进行测试即可。

2.1.1.1. 等价类划分原则

• 划分为有效等价类和无效等价类
• 根据取值范围或值的个数、值的集合
• 根据需要遵守的规则一条用例尽可能多的满足有效等价类
• 一条用例覆盖一条无效等价类

2.1.1.2. 等价类划分步骤

a. 分析需求，确定输入数据类型

b. 使用规则划分有效和无效等价类

c. 设计用例覆盖有效等价类

d. 设计用例覆盖无效等价类

2.1.1.3. 等价类划分举例

需求：

QQ账号6-10位自然数，第一位不能为0。

等价类划分：

测试用例设计：

2.1.2. 边界值分析法

定义：边界是指对于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。通常边界值分析法是作为对等价类划分法的补充，长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

2.1.2.1. 边界值分析原则

• 上点：是指边界上的点，无论此时的域是开区间还是闭区间，开区间的话，上点就是在域外，闭区间的话，上点就是在域内。

• 离点：是指离上点最近的点，这里就跟是闭区间还是开区间就有关系了，如果是开区间，那么离点就在域内，如果是闭区间，那么离点就在域外。(开内闭外)    遵循的原则：开内闭外，开区间往中间找，闭区间往外找。

• 内点：域内的任意点都是内点。

2.1.2.2. 边界值分析步骤

a. 分析需求，确定输入数据类型

b. 使用规则划分有效/无效等价类

c. 确认上点、离点、内点

d. 设计测试用例覆盖有效等价类

e. 设计测试用例覆盖无效等价类

2.1.2.3. 边界值案例

需求：

一个文本框的输入长度为 6-10 个字符。

等价类划分、边界值确认：

测试用例设计：

2.1.3. 判定表法

定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具，适用于多条件的内容组合与结果分析。

2.1.3.1. 判定表法原则

判定表的组成：(使用条件：所有的条件桩在表中的位置和顺序互不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同)

• 条件桩：列出了问题的所有条件
• 动作桩：列出了问题规定可能采取的操作
• 条件项：列出条件项中的各种情况下的真假值
• 动作项：列出在条件项中的各种取值情况下应该采取的动作

2.1.3.2. 判定表法步骤

a. 分析需求，确定原因和动作，列出所有的条件桩和动作桩

b. 分析条件的组合数量，即条件项（全组合：若有n个条件，每个条件有m种情况，则最后一共有m^n个条件项）

c. 填写动作项，合并、简化相似规则或者相同动作，排除一些不可能的情况

d. 简化判定表，输出测试用例

2.1.3.3. 判定表案例

需求：

• 如果金额大于500元，又未过期，则发出批准单和提货单。
• 如果金额大于500元，但过期了，则不发批准单和提货单。
• 如果金额小于等于500元，则不论是否过期都发出批准单和提货单。
• 在过期的情况下不论金额大小还需发出通知单。

列出判定表：

简化判定表，输出用例（一个规则对应一条测试用例）：

2.1.4. 场景法

定义：场景法是通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法，适用于解决业务流程清晰的系统或者功能。

2.1.4.1. 场景法原则

• 基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流只有一个起点和一个终点。
• 备选流：除了基本功能流程之外的各支流，包含多种不同情况。

场景1:基本流;

场景2:基本流,备选流1;

场景3:基本流,备选流1,备选流2;

场景4:基本流,备选流1,备选流4;

场景5:基本流,备选流3;

场景6:基本流,备选流3,备选流1;

场景7:基本流,备选流3,备选流1,备选流2;

场景8:基本流,备选流4;

场景9:基本流,备选流3,备选流4。

2.1.4.2. 场景法步骤

a. 分析需求，描述出程序的基本流及各项备选流。

b. 根据基本流和各项备选流生成不同的场景。

c. 对每一个场景生成相应的测试用例。

2.1.4.3. 场景法案例

需求：

取款机银行卡取款

分析基本流（正常流程）：

①插入银行卡：客户将银行卡插入ATM机的读卡器；

②验证银行卡：ATM机从银行卡的磁条中读取账户代码，并检查它是否属于可以接受的银行卡；

③输入密码：ATM机要求客户输入密码；

④验证密码：确定该密码是否正确；

⑤进入ATM主界面：ATM显示在本机中可用的各种选项；

⑥取款并选择金额：客户选择“取款”，并选择取款金额；

⑦ATM机验证：ATM机进行验证账户余额是否满足以及总取款金额是否满足要求，验证ATM机内现金是否够用；

⑧更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示用户收取现金；

⑨返回主界面。

分析备选流：

①银行卡无效：提示错误并退卡；

②密码错误：提示错误，并判断是否3次错误；

③密码3次错误：提示错误，吞卡；

④账户余额不足：提示错误并退卡；

⑤总取款金额超出当日可取限额：提示错误并退卡；

⑥ATM机余额不足：提示错误并退卡。列出所有场景：

列出所有场景：

为每一个场景设计测试用例：

2.1.5. 功能图法

2.1.5.1、功能图法原则

状态迁移图和逻辑功能模型的相关描述如下：

状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。

逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型仅用于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。

2.1.5.2、功能图法步骤

a. 明确状态节点。分析被测对象的测试特性及需求规格说明书，明确被测对象的状态节点数量及相互迁移关系。

b. 绘制状态迁移图。利用圆圈表示状态节点，有向箭头表示状态间的迁移关系，根据需要在箭头旁边标识迁移条件。可以利用绘图软件绘制状态迁移图。

c.绘制状态迁移树。根据状态迁移图，按照广度优先和深度优先搜索绘制状态迁移树。首先确定起始节点和终止节点，在绘制时，当路径上遇到终止节点时，不再扩展，遇到已经出现的节点也停止扩展。

抽取测试路径设计用例。根据绘制好的状态迁移树，提取测试路径，从左到右，横向抽取，每条路径构成一条测试规则，然后再利用等价类和边界值等测试用例设计方法设计具体的测试用例。

2.1.5.3、功能图法案例

需求： 一个编辑文本的软件中有可以改变字体颜色的功能，其中可选的颜色共有黑、红、蓝三种颜色。

分析需求：功能共有三种状态，假设红色为起始状态，那么可以得到如下的状态迁移图： 根据上述的状态迁移图，绘制出如下的状态迁移树：

从状态迁移树中，导出以下规则：

根据规则输出测试用例：

2.1.6、正交实验法

定义：正交实验法是一种测试组合的方法。把影响实验指标的条件称为因子，而影响实验因子的条件叫因子的状态。 利用正交实验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把他们当作因子；而把各个因子的取值当作状态。

2.1.6.1、正交实验法原则

正交表的构成：

• 行数：正交表中的行的个数，即试验的次数，也是我们通过正交实验法设计的测试用例的个数。

• 因素数：正交表中列的个数，即我们要测试的功能点。

• 水平数：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到“水平数-1”或从1到“水平数” 。即要测试功能点的输入条件。

• 正交表的形式：L行数(水平数因素数) 如：L8(27)如下图

• 与判定表法的区别是：判定表法是人工对全排列进行组合，正交试验法是借助数学工具从全排列组合中选出组合组成正交表，测试的时候查看正交表编写测试用例。下图是四因子三状态的正交表：

• 可以使用正交试验法的情形： 单个功能测试：输入是因子，输出是状态 功能组合测试：功能是因子，是否包含功能是状态 配置测试：配置项是因子，每个配置项的值是状态

2.1.6.2、正交实验法步骤

分析需求，获取因子和水平； 根据因子和水平查正交表； 替换正交表中的因子与水平； 根据正交表获取测试用例。

2.1.6.3、正交实验法案例

需求：

某银行交易系统的卡号查询功能界面如图所示：

分析需求，获取因子和水平：

因子（功能点）：卡号、卡号所属地区、卡状态、用户姓名、开户年月

水平（条件）：输入、不输入

综上为5因子2水平（一般通过工具生成正交表） 查正交表（取7因子2水平，要取最接近且结果大于所需数量）：

替换因子与水平：

根据正交表的每一行编写测试用例： 略

（以上正交实验法的部分知识来源于CSDN博主rm group，若侵权可联系我及时删除。）

2.1.7、因果图法

定义：因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。适用于输入条件比较多，输入存在复杂（相互制约或者相互依赖）关系的情况。测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

2.1.7.1、因果图法原则

因果图基本符号 （a）恒等 若原因出现，则结果出现； 若原因不出现，则结果也不出现； （b）非 ~ 若原因出现，则结果不出现； 若原因不出现，则结果出现； 若结果存在，则不提示错误，若结果不存在，则提示错误。 （c）或 ∨ 若几个原因中出现一个，则结果出现； 若几个原因都不出现，则结果不出现； （d）与 ∧ 若几个原因都出现，则结果出现； 若其中的一个原因不出现，则结果不出现；

• 因果图约束条件

（1）互斥：最多有一个可能成立 （2）包含：至少有一个成立 （3）屏蔽：a成立时，b不成立；a不成立时，b的值不一定 （4）唯一：三个或多个原因中有且只有一个成立 （5）要求：一个出现，另一个一定出现

2.1.7.2、因果图法步骤

分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入或输入条件的等价类，结果是输出条件。给每个原因和结果赋予一个标识符，根据这些关系，画出因果图。 因果图上用一些记号表明约束条件或限制条件。 对需求加以分析并把它们表示为因果图之间的关系图。 把因果图转换成判定表。 将判定表的每一列作为依据，设计测试用例。

2.1.7.3、因果图法案例

需求： 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。

分析需求，明确输入和输出： 原因： 1——第一列字符是A； 2——第一列字符是B； 3——第二列字符是一数字。 结果： 21——修改文件； 22 ——给出信息L； 23——给出信息M。 根据原因结果画出因果图：

（说明：11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。） 根据因果图建立判定表：

（说明：表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。）

输出测试用例： 略 （和前面判定表一样)

2.1.8、错误推测法

定义：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误，以前产品测试中曾经发现的错误等，这些就是经验的总结。还有输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行，这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

2.2、

白盒测试

白盒测试(结构测试)：这种方法把被测软件看成白盒，根据程序的内部结构和逻辑设计来设计测试实例，对程序的路径和过程进行测试。

2.2.1、桌面检查

桌面检查是一种人工检查程序的方法，通过对源程序代码的分析、检验来发现程序中的错误。桌面检查关注的是变量的值和程序逻辑，所以执行桌面检查要求严格按照程序中的逻辑顺序。桌面检查可以由程序作者本人执行，但是效率很低。最好是两个程序员互相检查。桌面检查不如审查或者走查有效。但是比什么都不做好。

2.2.2、代码审查

正式的代码评审过程。由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。

2.2.3、代码走查

非正式的代码评审过程。代码走查就是，项目开发人员在一起，对代码进行讨论。项目开发人员可以向大家阐述代码的逻辑和写代码的思路，在向别人阐述的时候，会发现做自己写的代码出现的一些问题。

2.2.4、代码扫描工具

代码质量的重要性不言而喻，代码质量水平决定了软件的可靠性、可维护性、执行效率、安全性等软件质量水平。而大规模的软件系统的代码庞大而复杂，必须借助自动化手段辅助完成代码审查。 Sonar（SonarQube）是一个开源平台，用于管理源代码的质量。Sonar 不只是一个质量数据报告工具，更是代码质量管理平台。支持的语言包括：Java、PHP、C#、C、Cobol、PL/SQL、Flex 等。Sonar是一个Web系统，展现了静态代码扫描的结果，结果是可以自定义的 ，支持多种语言的原理是它的扩展性。 Sonar作用： 对源代码执行静态分析； 可以静态分析编译代码，比如Java的Class文件、C#的dll文件等； 对应特定语言，Sonar能够执行动态分析，比如Java、C#的单元测试。

2.2.5、语句覆盖

定义：

设计测试用例，使得程序中每条语句至少被执行一次 语句覆盖率 = 至少被执行一次的语句数量 /可执行的语句总数 尽可能使得语句覆盖率达成100% 局限性：不能准确判断运算中的逻辑关系错误

2.2.5.1、语句覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

2.2.6、判定覆盖

定义：

也叫分支覆盖，设计测试用例，使得程序中的每个判断的“真”和“假”都至少被执行一次；即程序中的每个分支至少执行一次 判定覆盖率 = 每个判定的真假值至少出现一次 / 判定结果的总数 满足判定覆盖一定满足语句覆盖 局限性：判定覆盖会忽略条件中取或的情况

2.2.6.1、判定覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2

2.2.7、条件覆盖

定义：

设计测试用例，使得判定中的每个条件至少有一次取真值，有一次取假值 条件覆盖率 = 每个条件真假值至少出现一次/条件结果的总数 局限性：条件覆盖不能保证判定覆盖

2.2.7.1、判定覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.8、判定条件覆盖

定义：

设计测试用例，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值（真假）也至少被满足一次，即同时满足100%判定覆盖和100%的条件覆盖的标准

判定条件覆盖率 = 每个判定真假值和条件真假值至少出现一次 / (判定结果的总数+条件结果的总数) 满足判定条件覆盖一定满足判定覆盖、条件覆盖、语句覆盖 局限性：判定覆盖会忽略条件中取或的情况

2.2.8.1、判定条件覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.9、条件组合覆盖

定义:

设计测试用例，使得被测试程序中的每个判定中条件结果的所有可能组合至少执行一次 条件组合覆盖率=条件组合至少出现一次的数量/条件组合的总数 条件组合覆盖满足判定覆盖、条件覆盖、判定-条件覆盖、语句覆盖 局限性：不能保证所有路径被执行

例：假设代码中有判定2个，条件3个（判定1有2个条件，判定2有1个条件），则判定1 的条件组合为4个，判定2的条件组合为2个，设计测试用例执行5个条件组合，则条件覆盖率=5/(4+2) = 83%

2.2.9.1、条件组合覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.10、路径覆盖

定义：

设计测试用例，覆盖程序中所有可能的路径 路径覆盖率 = 至少被执行过一次的路径数/总的路径数 局限性：不适合包含路径过多的程序

2.2.10.1、路径覆盖案例

需求：

某个程序如下图流程图

测试用例设计：

• if(x>0 && y>0)判定：记为P1
• if(m<0)判定：记为P2
• x>0：记为C1
• y>0：记为C2
• m<0：记为C3 需要满足C1、C2、C3均取真、取假

2.2.11、基本路径测试法

定义：基本路径测试法又称独立路径测试，是在程序控制流图的基础上，通过分析控制结构的环路复杂性，导出基本可执行路径集合，从而设计出相应的测试用例的方法。设计出的测试用例要保证在测试中程序的语句覆盖100%，条件覆盖100%。

PART 03 什么是测试用例

3.1、定义

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。（来自百度百科）

测试用例主要包含（不限于）四个内容：用例标题，前置条件，测试步骤和预期结果。用例标题主要描述测试某项功能；前置条件是指用例标题需要满足该条件；测试步骤主要描述用例的操作步骤；预期结果指的是符合预期（开发规格书、需求文档、用户需求等）需求。

3.2、 测试用例的作用

• 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

• 测试用例的使用令软件测试的实施重点突出、目的明确。

• 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

• 检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路。

3.3、测试用例八要素

• 用例编号

• 测试项目

• 测试标题

• 重要级别

• 预置条件

• 测试输入

• 操作步骤

• 预期结果

3.4、测试用例需具备的特性

• 易读、可执行性：测试用例可被其他测试人员易于理解和执行

• 有效性：测试用例能够被使用，且被不同人员使用测试结果一致

• 可重复性：良好的测试用例具有重复使用的功能。(回归测试)

• 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)

• 清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。

• 可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用例符合相应测试要求。

3.5、如何写出漂亮的测试用例

• 测试用例名称要是一个完整的句子，例：在怎样的条件下，谁做了怎样的事情，得到什么结果。

• 划分好用例的优先级

• 明确测试步骤和预期结果的对应关系

• 测试步骤不宜过多，不要多余7步，不要少于2步

• 不要在测试用例中引用测试用例

• 避免在测试步骤中使用笼统的词，简洁易懂

……

PART 04 测试分析与测试用例的区别

测试分析：主要是对测试点进行细化，明确测试设计方法，通过思维导图的方式列出每一个测试点的所有测试项和优先级，并写明使用的测试方法，测试分析不包含测试步骤和测试数据。测试分析是测试设计的中间产物，一般不作为产出物（无需拿到项目组进行评审）。

测试用例：是对测试分析具体的实现，需要将测试分析的所有测试项转换为用例，通过表格文档进行呈现，需要详细写明测试步骤和测试数据。测试用例是测试设计的最终产物，需要将产出的测试用例拿到测试内部（内部评审）和项目组（外部评审）进行评审，评审后需要根据评审结果建议进行修改，并最终达成一致。

PART 05 测试数据的准备

1、测试过程中通常会设计到两类数据：

• 基础数据：在对某个业务进行测试之前，数据库已存在的数据，一般提测包会包含（例如下拉框等默认数据，字典表）

• 业务数据：在测试过程中使用的数据，是测试需要提前准备的数据（例如某可视化大屏展示的数据，提前了解数据流构造数据）

2、数据准备遵守的原则：

• 全面性：包含所有类型数据

• 无约束性：不能存在相互依赖的现象

• 正确性：保证业务被执行

• 数据量充足：性能测试

• 无敏感数据：安全测试

……