5.1 认识基本术语
5.1.1术语一：
◆动态测试（dynamic testing）
通过运行软件的组件或系统来测试软件(实际运行被测软件/系统)【需要进行操作】
◆静态测试（static testing)
对组件的规格说明书进行评审，对静态代码进行走查 (不实际运行被测软件/系统，通过对需求规格说明书进行走查、阅读等动作，代码进行备注走查)【主要以看为主】
◆正式评审（formal review）
对评审过程及需求文档的一种特定评审 （也就是会议评审，一般公司会对需求进行正式的评审）如：
1、代码评审：当前迭代功能相关的代码进行评审
2、接口评审:前后端需要进行数据交互；如电商商家在后台添加商品
◆度量（metric）
测量所使用的方法或标准
◆评审员（reviewer）
参与评审的人
◆记录员（scribe）
记录评审会议上的会议纪要
5.1.2 术语二：
◆技术评审（Technical Review)
同行间对技术进行的评审，目的是技术实现达成共识。
◆走查（Walkthrough)
由文档作者逐步陈述文档内容，以收集信息并对内容达成一致 。(即产品经理在讲解需求文档的时候，大家各抒己见，最后达成一致意见的过程.)
◆复杂性（complexity）
系统或组件的设计或内部结构比较复杂， 导致难以理解，维护或验证的程度(与代码相关，用圈复杂度来体现)
◆圈复杂度（Cycloramic complexity）
程序中独立路径的数量。可以衡量一个组件模块的判定结构的复杂程度。(用来衡量代码的复杂程度，代码越复杂，圈复杂度越高；反之越低)
◆控制流(Control Flow)
执行组件或系统的一系列顺序的路径
◆数据流（Data Flow）
表示数据对象的顺利或状态发生变化的过程()
5.1.3术语三：
◆控制流图概念
(CFG,Controlflowgraph)也叫控制流程图，是一个过程或程序的抽象表现。
◆圈复杂度
圈复杂度是一种代码复杂度的衡量标准。程序中独立路径的数量,可以衡量一个组件模块的判定结构的复杂程度,数量上表现为独立现行路径条数,即合理的预防错误所需测试的最少路径条数，圈复杂度大说明程序代码可能质量低且难于测试和维护,根据经验,程序的可能错误和高的圈复杂度有着很大关系。
计算对象是结构图或程序图，而程序图又包括控制流图与流程图。
Ø圈复杂度第一个计算公式：V(G)=E-N+2(E表示控制流图中的边数；N表示控制流图中节点数)
Ø圈复杂度(反映了“判定条件”的数量)第二个计算公式：V(G)=(控制流图)区域数
Ø圈复杂度第三个计算公式：V(G)=P(判定节点数)+1
5.2 常见的用例设计方法
5.2.1等价类定义(重点)
等价类：指某个输入域的集合，在集合中各个输入的条件都是等效的。
字符：指类字形单位或符号，包括字母、数字、运算符号、标点符号和其他符号，以及一些功能性符号。
5.2.2等价类分析方法
Ø使用范围：适用于有无限多种输入
Ø目的：使用较少的测试用例尽可能将更多的功能点覆盖全通常等价类划分为2种情况：
Ø有效等价类：对程序规格说明有意义的、合理的输入数据
Ø无效等价类：对程序规格说明无意义的、不合理的输入数据
5.2.3等价类划分举例
Ø规定了输入值的范围或值的个数（如：0<a<100或输入6-10个字符）
Ø输入值为布尔值（如：真或假、是或否、对与错不存在无效等价例)
Ø规定了输入数据的一组值（如文化程度：初中、高中、大学）
Ø规定了输入规则时，可以划分出一个有效的等价类（符合规则)和若干个无效等价类（从不同角度违反规则）
◆常见的能够划分等价类的地方
1.数值范围 2. 重复次数 3. 字符串长度
4. 字符串组中字符的个数 5. 文件命名 6. 文件大小
7. 屏幕的颜色种类 8. 超时时间
◆等价类划分的设计用例思路
1. 找输入条件 2. 为每个输入条件找有效、无效等价类
3. 为每个等价类编号 4. 用最少的用例覆盖最多的有效等价类
5. 每一个无效等价类都是一个用例
6. 并非所有有效等价类都有无效 7. 等价类的覆盖可以重复覆盖
◆等价类设计用例覆盖的原则
Ø每个用例尽可能多的覆盖多个有效的等价类
Ø每个用例只能覆盖一个无效等价类
◆等价类的优缺点
优点：是考虑了单个输入域的各类情况， 避免
了盲目或随机选取输入数据的不完整性和覆盖
的不稳定性。
缺点：方法虽然简单易用，但是没有对组合情况
进行充分的考虑。需要结合其他测试用例设计的
方法进行补充。比如边界值
→测试用例编写如：
输入值 有效等价类 无效等价类
日期类型及长度 6位数字字符(1) 非数字类型(6)
大于6位(7)
小于6位(8)
注意：不能合写
年份范围 1990-2049(2) 大于2049(9)
小于1990(10)
月份范围 01-12(3) 小于01 0特殊(11)
大于12(12)
前4位表示年 前四位为年(4) 前四位不为年(13)
后2位表示月 后两位为月(5) 后两位不为月(14)
—— —– —– —- ——
有效输入值：199101 202207 （满足1、2、3、4、5）
无效输入值：二零220705 （6、7） 2207（8）
205007（9） 189907（10）
◆测试用例
Ø面试题：用例中包含哪些内容？ 包括用例编号、用例标题、前置条件、操作步骤、预期结果、用例等级
Ø用例标题：只能用陈述句，不能出现是否等判断性的文字，简单且清晰明了
5.2.4边界值（重点）
◆边界点定义
Ø上点：边界上的点 Ø内点：在域范围内的点
Ø离点：离上点最近的点(即上点左右两边最邻近的点）
◆边界条件分析
Ø 输入条件明确了一个值的取值范围或规定了值的个数
Ø输入条件明确了一个有序集合边界值分析法:满足a
eg.正整数值域[66,88]上点：66、88 内点：77离点：65,89
eg.正整数值域(66,88)上点：66、88 内点：77离点：67,87
★注：内点一般取中间值
★区别：闭区间上点有效，离点无效；开区间上点无效，离点有效。
◆边界值分析原则
Ø如果输入（输出）条件规定了取值范围，则应该以该范围的边界内及边界附近的值作为测试用例
Ø如果输入（输出）条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据
Ø如果程序规格说明中提到的输入或输出是一个有序集合，应该注意选取有序集合的第一个和最后一个元素作为测
试数据
5.2.5判定表
Ø判定表定义： 分析和表达多逻辑条件下执行不同操作的情况
Ø适用范围：遇到复杂业务，可以使用判定表来梳理业务之间的逻辑关系。
◆结构：由4个部分组成
1）条件桩（condition stub）:列出问题的所有条件（通常条件次序无关紧要）。条件(输入)需求规格说明书定义的被测对象所有值。
2）条件项（condition entry）：列出针对它条件的取值（所有情况下的真假值）
3）动作桩（action stub）：列出问题规定可采取的动作（顺序无约束）。动作(输出)针对条件，被测对象可能采取的所有操作。
4）动作项（action entry）：列出条件各种情况的应采取的动作。针对动作桩，被测对象所有的可能取值。
◆设计判定表的步骤：
1、理解需求、确定条件桩、动作桩
2、确定规则的个数；若有N个条件，每一个条件下面有2个值，则有2^n种规则。
3、设计判定表并列出所有条件桩与动作桩。
4、输入条件项和动作项得到初始判定表
5、根据判定表种输入结果的表现，进行判定表并入，简化得出结果并理清业务逻辑（合并相似规则）6、编写测试用例
◆判定表法测试用例
1、画出判定表2、简化得出清晰的业务逻辑 3、转化为测试用例
|
条件桩 |
|
1 |
2 |
3 |
4 |
|
用户欠费？ |
|
Y |
Y |
N |
N |
|
用户关机？ |
|
Y |
N |
Y |
N |
|
规则条数统计 |
4 |
1 |
1 |
1 |
1 |
|
动作桩 |
|
|
|
|
|
|
允许主被叫 |
|
|
|
|
√ |
|
禁止主被叫 |
|
√ |
√ |
√ |
|
注：判定表每一行/每一列都是一条测试用例
1、简化得出清晰的业务逻辑（合并相似规则）
用例编号 用户是否欠费 用户是否关机 预期结果
1 是 是 禁止主被叫
2 是 否 禁止主被叫
3 否 是 禁止主被叫
4 否 否 允许主被叫
2、转化为测试用例
用例编号 用例标题 前置条件 操作步骤 预期结果 优先级
5.2.6因果图
◆因果图定义
因果图用画图的方式来表达输入条件和输出结果的直接关系。因果图提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。其中，原因是表示输入条件，结果是对输入执行的一系列计算后得到的输出。
Ø因果图方法最终生成的就是判定表。它适合于检查软件输入条件的各种组合情况
因(原因)：输入条件 果(结果)：输出结果
◆因果图中的四种基本关系
在因果图的基本符号中，图中的左结点ci 表示输入状态（或称原因),右结点ei表示输出状态（或称结果）。ci与ei取值0或1，0表示某状态不出现，1则表示某状态出现。
Ø恒等关系：==当原因出现的时候，结果一定出现
Ø非关系：～ not ≠ 当原因出现的时候，结果不一定出现
Ø或关系：V or / | || 多个原因中有一个原因出现时，则结果一定出现
Ø与关系：^ 和 且 and 多个原因同时出现,则结果才能出现
◆因果图中约束符号
在实际问题中输入状态相互之间、输出状态相互之间可能存在某些依赖关系，称为“约束”。对于输入条件的约束有E、I、O、R四种约束，对于输出条件的约束只有M约束。
ØE约束(异)： a和b中最多有一个可能为1，即a和b不能同时为1(两个可以都不选，但是如果要选只能选一个)
ØI约束(或)：a、b、c中至少有一个必须为1，即a,b,c不能同时为0(所有原因中最少选一个，但不能同时都不选或同时都选)
ØΦΟ约束(唯一)：a和b必须有一个且仅有一个为1(只能选一个，不能同时都选或同时都不选)
ØR约束(要求)：a是1时。b必须是1，即a为1时，b不能为0(深圳市，出现的时候必须要求出现广东省)
ØM约束(强制)：若结果a为1，则结果b强制为0(输入胡萝卜，结果强制为蔬菜)
◆因果图的步骤：
1.把大的系统规格划分解成可以测试的规格片段
2.分析分解后待测的系统规格，找出哪些是原因，
哪些是结果
3.画出因果图 4.把因果图转换成判定表
5.简化判定表 6.用判定表中的每一列生成测试用例
◆因果图转换判定表的方法：
1. 将因果图中的所有条件（因）填入判定表的条件桩中；
2. 将因果图中的所有动作（果）填入判定表的动作桩中；
3. 根据因果图确定各个条件组合对应的动作，并且确定判定表中各个规则的条件项和动作项，在需要时优化判定表。
◆因果图设计测试用例
找出原因结果并进行编号：
画出因果图：
面试题：你在上一家公司是怎么使用因果图设计测试用例的？
an：我在上一家公司一般不会画因果图，但是对于需求文档当中有因果关系的需求时，我们会把因果图的原因放到判定表的条件桩中，再把因果图中的结果放入到判定表的动作桩中，从而把因果图转为了判定表，可以防止用例的漏写和漏测。
→因果图的优点
1.等价类法尽管各个输入条件可能出错的情况都考虑到了，但是多个输入条件组合起来出错的情况却被忽略了
2.因果图法能够帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例
3.因果图分析还能为我们指出，程序规格说明描述中存在什么问题
→因果图的缺点：
Ø输入条件与输出结果的因果关系，有时难以从软件需求规格说明书得到
Ø即使得到了这些因果关系，也会因为因果关系复杂导致因果图非常庞大，测试用例数目及其庞大
◆场景法设计测试用例：
基于用户场景梳理业务逻辑，再挑选最合适的方法设计测试用例，为的是尽可能的去还原用户全部真实操作。
◆业务需求方面：对所测软件的重要功能，业务逻辑(系统要干什么，怎么去实现这个过程)和行业背景进行深入了解
◆技术层面：基于等价类划分
Ø有效等价类：用户的一个正确操作场景
Ø无效等价类：用户的一个错误操作场景
◆核心概念：
Ø基本流(正确，有效流)：模拟用户的正确操作过程
Ø备选流(错误，无效流)：模拟用户的错误操作过程
5.3 黑盒用例设计方法
◆黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
◆在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
◆黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
◆黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了。
◆黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景图法等。目前黑盒测试的常用测试用例设计方法有5种：等价类划分、边界值分析、错误推测法、因果图、功能图
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/279704.html