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个字符）
输入值为布尔值（如：真或假、是或否、对与错） 不存在无效等价例
规定了输入数据的一组值（如文化程度：初中、高中、大学）
规定了输入规则时，可以划分出一个有效的等价类（符合
规则）和若干个无效等价类（从不同角度违反规则）
测试用例编写如：
输入值 有效等价类 无效等价类
日期类型及长度 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判定表
适用范围：遇到复杂业务，可以使用判定表来梳理业务之间的逻辑关系。
条件桩：条件(输入)需求规格说明书定义的被测对象所有值。
动作桩：动作(输出)针对条件，被测对象可能采取的所有操作。
动作项：针对动作桩，被测对象所有的可能取值。
◆设计判定表的步骤：
1、理解需求、确定条件桩、动作桩
2、确定规则的个数；若有N个条件，每有N个条件下面有2个值，则有2^n种规则。
3、设计判定表 4、填写动作项
4、根据判定表种输入结果的表现，进行判定表并入，简化得出结果并理清业务逻辑
◆判定表法测试用例
1、画出判定表2、简化得出清晰的业务逻辑 3、转化为测试用例
|
条件桩 |
|
1 |
2 |
3 |
4 |
|
用户欠费？ |
|
Y |
Y |
N |
N |
|
用户关机？ |
|
Y |
N |
Y |
N |
|
规则条数统计 |
4 |
1 |
1 |
1 |
1 |
|
动作桩 |
|
|
|
|
|
|
允许主被叫 |
|
|
|
|
√ |
|
禁止主被叫 |
|
√ |
√ |
√ |
|
注：判定表每一行/每一列都是一条测试用例
- 简化得出清晰的业务逻辑（合并相似规则）
用例编号 用户是否欠费 用户是否关机 预期结果
1 是 是 禁止主被叫
2 是 否 禁止主被叫
3 否 是 禁止主被叫
4 否 否 允许主被叫
- 转化为测试用例
用例编号 用例标题 前置条件 操作步骤 预期结果 优先级
1
5.2.6因果图
◆因果图定义
用画图的方式来表达输入条件和输出结果的直接关系。
因(原因)：输入条件 果(结果)：输出结果
◆四种基本关系
恒等关系：==当原因出现的时候，结果一定出现
非关系：～ not ≠ 当原因出现的时候，结果不一定出现
或关系：V or / | || 多个原因中有一个原因出现时，则结果一定出现
与关系：^ 和 且 and 多个原因同时出现,则结果才能出现
◆约束符号
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(输入胡萝卜，结果强制为蔬菜)
◆因果图设计测试用例
找出原因结果并进行编号：
画出因果图：
面试题：你在上一家公司是怎么使用因果图设计测试用例的？
an：我在上一家公司一般不会画因果图，但是对于需求文档当中有因果关系的需求时，我们会把因果图的原因放到判定表的条件桩中，再把因果图中的结果放入到判定表的动作桩中，从而把因果图转为了判定表，可以防止用例的漏写和漏测。
→因果图的优点
1.等价类法尽管各个输入条件可能出错的情况都考虑到了，但是多个输入条件组合起来出错的情况却被忽略了
2.因果图法能够帮助我们按照一定步骤，高效的选择测试用例，设计多个输入条件组合用例
3.因果图分析还能为我们指出，程序规格说明描述中存在什么问题
→因果图的缺点：
1.输入条件与输出结果的因果关系，有时难以从软件需求规格说明书得到
2. 即使得到了这些因果关系，也会因为因果关系复杂导致因果图非常庞大，测试用例数目及其庞大
◆场景法设计测试用例：
基于用户场景梳理业务逻辑，再挑选最合适的方法设计测试用例，为的是尽可能的去还原用户全部真实操作。
◆业务需求方面：对所测软件的重要功能，业务逻辑(系统要干什么，怎么去实现这个过程)和行业背景进行深入了解
技术层面：基于等价类划分
有效等价类：用户的一个正确操作场景
无效等价类：用户的一个错误操作场景
核心概念：
基本流(正确，有效流)：模拟用户的正确操作过程
备选流(错误，无效流)：模拟用户的错误操作过程
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
