设计测试用例方法

一、常用的设计方法:

等价类、边界值，判定表、因果图

（1）黑盒测试方法：

等价类、边界值，判定表、因果图、正交表，场景法、状态迁移法;

（2）经验测试方法：

错误推测法、异常分析法、随机测试;

（3）白盒测试方法：

语句覆盖，判断覆盖，条件覆盖，判断、条件覆盖，

路径覆盖(基本路径法、Z路径法)

二、等价类

1、定义

等价类定义：指某个输入域的集合，在集合中各个输入的条件都是等效的。

等价类分为两种：有效等价类，无效等价类

有效等价类定义：对程序规格说明有意义的、合理的入输入数据

无效等价类定义：对程序规格说明无意义的、不合理的入输入数据

例如1：有效：atm识别银行卡;  （有磁性、银联卡，完整）

无效：

（1）无磁性，

 （2）电话卡，

（3）不完整的卡

等价类划分举例:

规定了输入值的范围或值的个数(如:0<a<100或输入6-10个字符)

输入值为布尔值(如:真或假)

规定了输入数据的一组值(如 文化程度:初中、高中、大学)

规定了输入规则时，可以划分出一个有效的等价类(符合规则)和若干个无效等价类(从不同角度违反规则，

规定了输入值的范围或值的个数(如:0<a<100或输入6-10个字符)

输入值为布尔值(如:真或假)

规定了输入数据的一组值(如 文化程度:初中、高中、大学)

规定了输入规则时，可以划分出一个有效的等价类(符合规则)和若干个无效等价类(从不同角度违反规则）

2、等价类划分的设计用例思路

1.找输入条件

2.为每个输入条件找有效、无效等价类

3.为每个等价类编号

4.用最少的用例覆盖最多的有效等价类

5.每一个无效等价类都是一个用例

6.并非所有有效等价类都有无效

7.等价类的覆盖可以重复覆盖

案例

案例-练习:

现有一个档案管理系统，容许用户通过输入年月对档案文

件进行 检索，系统对查询条件年月的输入限定为1990年1月~2049年12月，并规定:日期由6位数字字符组成，前4位表示年，后2位表示

1、找出条件：年、月、日期组成部分6个数字

年：1991  有效

1989  无效

2050 无效

月：2 有效

0无效

13无效

日期类型：199101 有效

         19910 小于6位

         1991055  大于6位

        1991ss  非纯数字

测试用例：

199101  

3、常见的能够划分等价类的地方:

1.数值范围

2.重复次数

3、字符串长度

4、字符串组中字符的个数

5、文件命名

6.文件大小

7.屏幕的颜色种类

8.超时时间

4、等价类的优缺点

优点:是考虑了单个输入域的各类情况，避免了盲目或随机选取输入数据的不完整 性和覆盖的不稳定性。

缺点:方法虽然简单易用，但是没有对组合情况进行充分的考虑。需要结合其他测试用例设计的方法进行补充。

三、边界值

1、定义

(1)上点：边界上的点

(2)离点：离上点最近的点

（3）内点：在域的范围内的点

在测试过程中根据实际情况定：

闭区间：

案例：5-13位qq号

上点：5，13

离点：4，14

内点：8（6，7，8，9，10，11，12）

测试：5 最小值，13 最大值，4小于最小值，14 大于最大值，8范围值

开区间：

上点：5，13

离点：6，12

内点：8（7，8，9，10，11）

测试：5 最小值，13 最大值，6最小值多1，12 最大值少1，8范围值

2、边界条件分析：

1. 输入条件明确了一个值的取值范围，或规定了值的个数

2. 输入条件明确了一个有序集合

3、边界值分析原则

1. 如果输入（输出）条件规定了取值范围，则应该 以该范围的边界内及边界附近的值作为测试用例

2. 如果输入（输出）条件规定了值的个数，则用最 大个数，最小个数，比最小个数少一，比大个 数多一的数作为测试数据

3. 如果程序规格说明中提到的输入或输出是一个有 序集合，应该注意选取有序集合的第一个和最后 一个元素作为测试数据

案例1：微信担任红包金额0.01-200  元

最小值：0.01

最大值：200

小于最小值：0.00

大于最大值：200.01

范围值：100（0.02-199.99）

案例2：atm机取款金额100-5000

最大金额：5000

最小金额：100

小于最小金额：99

大于最大金额5001

范围值：200

4、边界值是发现bug能力最强的一种测试

四、判定表

1、定义

分析和表达多逻辑条件下的执行不同操作的情况

2、作用

对组合情况设计用例

利用判定表将复杂的问题按照各种可能的 情况全部列举出来，能针对不同逻辑条件 的组合值，分别执行不同的操作。

3、组成部分：

1）条件桩（condition stub）:列出问题的 所有条件（通常条件次序无关紧要）。

2）条件项（condition entry）：列出针对 它条件的取值（所有情况下的真假值）

3）动作桩（action stub）：列出问题规定 可采取的动作（顺序无约束）。

4）动作项（action entry）：列出条件各种情况的应采取的 动作

4、案例讲解：

对功率大于50马力的机器、维修记录不全或已运行10年以上的机器，应给予优先的维修处理……”。

理解：1、 功率大于50马力的机器 和维修记录不全（优先）

2、已运行10年以上的机器（优先）

备注：条件3个 2的3次方=8次， 8次可以覆盖所有的组合情况

简化后的判定表

5、创建步骤:

1)确定规则的个数:若有N个条件，每一

个条件下有2个值，则有2~n种规则。

2)列出所有条件桩与动作桩。

3)输入条件项。

4)输入动作项得到初始判定表。

5)简化(合并相似规则)

6)编写测试用例

6、判定表的作用:

利用判定表将复杂的问题按照

各种可能的 情况全部列举出来，

能针对不同逻辑条件的组合值，

分别执行不同的操作。

案例：扫雷

扫雷游戏：链接

网站1：（没有问号）http://www.minesweeper.cn/

 网站2：https://saolei123.com/

网址3：http://p.1234wu.com/h5/019/ （有问号）

判定表-经典案例:扫雷游戏 

条件

1.方块当前状态:标识问号方块、方块初 始状态、方块标识红旗标识数字X且周围 已标记了X个雷、标识

数字X且周围没有标记完X个雷，标识数字X标雷错误

鼠标操作:左键、右键、双击

方块状态:有雷、无雷

多测

1.方块白色

2.方块标识问号

3.方块标识数字

4、方块旗子

5、炸弹爆炸，游戏结束

6、未标识方块闪速

7.周围所有的非雷显示条件

五、场景法

1、定义：

场景法主要是针对测试场景类型的，顾也称场景流程分析法。

流程分析是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。

根据流程的顺序依次进行组合，使得流程的各个分支都能走到

案例1：购物流程

案例2：离职流程

案例3：

atm机

2、流程分析步骤:

1.画出业务流程图

注:描述正常流程和异常流程

2、确定条件分支(功能路径)

注:设计路径的优先级

3、确认测试路径

注:考虑路径覆盖率

4、选择数据构造用例

注:选数据要结合等价类边界值分析

三、1、下载软件：xmind图或亿图、wps

2、打开软件

3、使用软件画图

六、状态迁移法：

1、定义

通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为

2、案例：

订机票案例1：

l向航空公司打电话预定机票—>此时机票信息处于“完成”状态

l顾客支付了机票费用后—>机票信息就变为“已支付”状态

l旅行当天到达机场后，拿到机票后—>机票信息就变为“已出票”状态

l登机检票后—>机票信息就变为“已使用”状态

l在登上飞机之前任何时间可以取消自己的订票信息，如果已经支付了机票的费用，则还可以得到退款，取消后—>订票信息处于“已被取消”状态

转换成迁移树：

3、状态迁移图设计测试用例步骤：

1.画出状态迁移图

2.通过状态迁移图出状态转换树

3.从状态转换树推导出测试路径

4.根据测试路径编写合法（正常）测试用例或非法（异常）测试用例

注意：保证从状态转换树的根节点到每个叶节点的每一条路径都至少设计出一个测试用例

案例1：

红、黄、黑 三种颜色，可以互相转换

（1）状态迁移图

状态迁移树

推到出的设计用例

红-黄-红

红-黄-黑

红-黑-红

红-黑-黄

案例2：

状态迁移图

状态迁移树

设计测试用例

（1）打印完成

（2）缺纸加纸打印

（3）修复故障打印

练习：

电商的订单状态有些流程（售后订单）

用户订单状态

商家订单状态

运营端订单状态

七、因果图

（1）定义：

因果图提供了一个把规格转化为判定表的系统化方法，从该图中可以产生测试数据。

其 中，原因是表示输入条件，结果是对输入执 行的一系列计算后得到的输出

（2）作用：

因果图方法最终生成的就是判定表。它适合于检查软件输入条件的各种组合情况
（3）

因果图中的4种基本关系 在因果图的基本符号中，图中的左结点ci 表示输入状态（或称原因），右结点ei表示输出 状态（或称结果）。

 ci与ei取值0或1，0表示某 状态不出现，1则表示某状态出现。（1）恒等：若 c1 是1，则 e1 也为1，否则 e1 为0。 案例1：有钱=====富豪
（2）非：若 c1 是1，则 e1 为0，否则e1为1。 案例2：有钱=====穷人
（3）或：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0。 案例3： 有车、 有房、       满足一个有钱人
有存款 

（4）与 若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0。

（3）案例4

有车、 有房、有存款        满足三个是：有钱人

a.因果图中的约束 在实际问题中输入状态相互之间、输出状 态相互之间可能存在某些依赖关系，称为“约 束”。对于输入条件的约束有E、I、O、R四种 约束， 对于输出条件的约束只有M约束。 

（1）E约束(异)：a和b中最多有一个可能为1，即a和b不能 同时 为1。 

（2）I约束(或)：a、b、c中至少有一个必须为1，即 a、b、 c不能同时为0。 

(3)O约束(唯一)：a和b必须有一个且仅有一个为1。

 (4)R约束(要求)：a是1时，b必须是1，即a为1时，b不能 为0。

 (5)M约束(强制)：若结果a为1，则结果b强制为0。 

 
（4）因果图的步骤：

 1.把大的系统规格划分解成可以测试的规格片段
2.分析分解后待测的系统规格，找出哪些是原因，哪些是结果
3.画出因果图 4.把因果图转换成判定表
5.简化判定表
6.用判定表中的每一列生成测试用例 

（5）  因果图的优点/缺点

优点： 1. 等价类法尽管各个输入条件可能出错的情况都考虑 到了，但是多个输入条件组合起来出错的情况却被 忽略了 

2. 因果图法能够帮助我们按照一定步骤，高效的选择 测试用例，设计多个输入条件组合用例 

3. 因果图分析还能为我们指出，程序规格说明描述中 存在什么问题 

缺点： 1. 输入条件与输出结果的因果关系，有时难以从软件 需求规格说明书得到
2. 即使得到了这些因果关系，也会因为因果关系复杂 导致因果图非常庞大，测试用例数目及其庞大
 
================================
案例： 因果图案例：
一个处理单价为5角钱的饮料的自 动售货机。其规格说明如下： 若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币

因果图：

(6)因果图转换判定表的方法：

1. 将因果图中的所有条件（因）填入判定表 的条件桩中；
2. 将因果图中的所有动作（果）填入判定表 的动作桩中；
3. 根据因果图确定各个条件组合对应的动作， 并且确定判定表中各个规则的条件项和动 作项， 在需要时优化判定表。

案例：

某软件规格说明书包含这样的要求：

第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。 

解答： 根据题意，原因和结果如下： 

原因： 1——第一列字符是A；

 2——第一列字符是B； 

3——第二列字符是一个数字。 

结果： 21——修改文件；22 ——给出信息L； 23——给出信息M。 

11为中间节点；

考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。

重点：因果图是对组合情况设计用例。

最终生成判定表

七、正交表

1、正交试验

正交试验设计法，是从大量的试验点中挑选出适量的、有代表性的点，应用依据迦罗瓦理论导出的“正交表”，合理的安排试验的一种科学的试验设计方法，

2、正交常用的术语

指标:通常把判断试验结果优劣的标准叫做试验的指标

因子:所有影响试验指标的条件

水平值:影响试验因子的取值

因子：条件   3（姓名、身份证、手机号）

水平值：2个水平值（填和不填）

2的3次方 8种方法，现在用正交表用4种方法代替

公式：实验数=因子 x（水平数-1）+1

4=3*（2-1）+1

实验数是4

映射正交表

2的8次方=128种方法

8种方法代替

正交表特点:

1》整齐可比性

在同一张正交表中，每个因素的每个水平出现的次数是完全相同的由于在试验中每个因素的每个水平与其它因素的每个水平参与试验的机率是完全相同的，这就保证在各个水平中最大程度的排除了其它因素水平的干扰。

2》均衡分散性

在同一张正交表中，任意两列(两个因素)的水平搭配(横向形成

的数字对)是完全相同的。这样就保证了试验条件均衡地分散在因素水平的完全组合之中，因而具有很强的代表性，容易得到好的试验条件。

3、用正交表设计测试用例的步骤，

(1)有哪些因素(变量或条件)

(2)每个因素有哪几个水平(变量或条件的取值)

(3)为了满足整齐可比性，选择一个合适的正交表

（4)把变量的值映射到表中(建议第1行是全真或全假)

(5)把每一行的各因素水平的组合做为一个测试用例

加上你认为可疑且没有在表中出现的组

正交的原则:两两组合

八、设计测试用例的三种经验方法

1、基于经验的测试技术之错误推测法

错误推测法也叫错误猜测法，就是根据经验猜想，已有的缺陷，测试经验和失败数据等可能有什么问题并依此设计测试用例

2、基于经验的测试技术之异常分析法

系统异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此设计测试用例。主要针对系统的容错能力、故障恢复能力进行测试。

3、基于经验的测试技术之随机测试

随机测试指的是测试中的所有的输入数据都是随机生成的，其目标是模拟用户的操作。

真实环境中，尤其是软件刚刚发布时，会有成千上万的人在上面乱敲乱试:因此在发布软件前，用模拟用户的随机测试就可能发现其它方式漏掉的软件缺陷。设计用例方法概况：

九、设计测试用例的综合策略

1、使用各种测试方法思路:

1.在任何情况下都必须使用边界值分析方法，

经验表明用这种方法设计出测试用例发现程序错误的能力最强;

2.必要时用等价类划分方法补充一些测试用例;

3.用错误推测法再追加一些测试用例(依靠经验):

4.如果程序的功能说明中含有输入条件组合情况，则可选用因果图/判定表;

5.对业务流程场景清晰的系统，使用场景法贯穿:

6.检查已设计的测试用例的覆盖程度;

7.最后要考虑异常分析，再进行综合使用。

2、个人总结：

1、梳理项目流程：通过场景法测试主流程

例如：注册--登录--搜索商--选择商品--立即购买--支付--收货

2、等价类有效，无效的用例，

例如：姓名（有效名字，无效名字）

3、注册输入的手机号，可以用边界值设计用例；

例如：手机号11位，（10，11，12）

4、针对组合情况，用判定表，因果图，正交表来设计用例

例如：注册（姓名，手机号，身份证号，验证码）

5、再用状态迁移法设计：状态用例

例如：注册申请状态：（申请成功，申请失败，申请种）

6、再根据经测试方法补充用例

（错误推测法，异常分析法，随机测法）

十、测试用例设计步骤（从设计到输出用例）

1、基本步骤

1.构造根据设计规格得出的基本功能测试用例

2.边界值测试用例

3.状态转换测试用例

4.错误猜测测试用例

5.异常测试用例

6.其它测试类型测试用例(如性能测试，易用性测试，安全测试等)

2、如何设计好用例：

使用10种测试设计用例方法不断进行分解与合并

查看测试用例模板

3、常用测试用例模板（重点）

1.用例的来源

（1）公司就有模板

（2）自己设计模板

（3）用例管理工具种导出模板

模板1：

模板2：

模板3：

4.写用例的核心要素（重点）

用例编号、用例标题、前置条件、用例步骤，预期结果、优先级（必填）

系统名称、模块名称、用例创建时间、用例类型、实际结果、执行时间（非必填项）

详解：

（一）用例编号

可以称为：用例id、用例编号、编号

（1）系统名称_模块名称_编号（一般用__连接）

WX_ FHB_1

(2)根据公司模板白编写

1

（二）用例标题

又称为：测试内容、测试名称、测试标题等

用例标题：用例用例验证什么

案例：

1、验证微信能发红包

2、验证微信不能发红包（余额不足）

3、验证微信不能发红包（余额0）

4、验证微信不能发红包（无网络）

5、验证单个红包最大金额（200元）

6、验证单个红包超过最大金额，有提示（201）

标题规则：

1、用例标题是永远唯一的，不存在两条一样的用例

2、标题描述简单、易懂、清晰

3、标题能加上“验证”尽量加上

4、用例标题和预期结果相呼应

5、用例标题要写清除验证的点

6、用例标题是陈述句，不能用判断句或者选择范围，用是否，不能写疑问句

7、不能把bug写成用例

8、一个无效等价类就是一条用例，不能多个无效等价类写在一条用例上

（三）前置条件

前置条件：执行操作之前的准备工作

比如：

1、准备两台手机

2、两个微信号

3、银行卡，余额充足

4、网络已连接

（四）测试步骤

定义：验证测试标题的具体步骤

1、测试流程步骤按照编号编写：1，2，3，4，5

2、测试步骤的开头都是动词

3、测试步骤一般不超过8个步骤（简化步骤）

4、不能把上一个而用力的步骤，用来做下一个步骤的前置条件

5、保证每一条用例是独立的

（五）预期结果

定义：达到预期的目标

1、预期结果要详细

2、预期结果要注意一些隐藏成功

3、页面跳转

4、订单状态变更

5、预期结果不能只写成功、失败

6、页面提示、提示语

7、结果涉及数据变化、说明提示内容等

8、结果涉及到数据库的数据和字段也可以写

例如：

1、数据库有新增用户名

2、用户查询种有用户名

3、注册页面提示

（六）优先级

高

中

低

先级有三个级别：

高：核心功能测试用例（冒烟测试用例），会阻碍大部分其他测试的用例，基本功能测试

举例：

死机，白屏，卡顿，闪退，

中：异常测试，边界，中断，弱网

举例：删删位置，返回，取消，刷新，更新，翻页等

低：字体，颜色，色差，易用性等

举例：ui样式、颜色，大小，排版

场景设法设计的用例，基本流， 高级用例

场景法设计的用例，备选流，中级用例

因果图设计的用例，有效用例，选一条为高级，其他的为中级

等级类和错误推测法， 设计的有效用例 中级

等价类和错误推测法，设计的无效用例  低级

用例优先级对应我们bug等级

十一、bug介绍（禅道）

1、bug的等级分类

（1）1级bug （致命bug）

必须优先修改，在测试中较少出现，一旦出现应立即中止当前版本测试；

致命bug：

（1）常规操作引起的崩溃，死机，死循环，内存泄露，无法启动，异常退出，严重花屏

（2）数据泄露，数据安全性问题， 如恶意攻击造成账户密码信息泄露

（3）涉及金钱，如支付类的软件，金钱的计算

（4）导致无法测试的错误：如服务器报500

（5）功能实际与需求严重不符

（2）2级bug （严重bug）

不影响其他功能测试的情况下可以进行版本测试

（1）重要功能不能实现如：微信不能聊天，或发朋友圈

（2）错误的波及面广，影响其他重要功能实现（如系统刷新，数据不更新）

（3）非常规操作告知:崩溃，死机，死循环，比如：一个账号，多区域，多设备登录等

（4）外观难以接受的缺陷（如：页面失真，完全变形）

（5）密码铭文显示（需要脱敏）

（6）轻微的数据计算错误

（3）3级bug （一般bug）

测试工作中存在最多的，解决率关系版本的优化程度

（1）次要功能不能实现：如表情包，添加文字

（2）操作页面错误

（3）查询错误，数据显示错误

（4）兼容性问题

（4）4级bug（建议性bug）

测试初期较多，优先程度低，在测试后期出现较少，

（1）界面不规范 （如：风格，一半中文，一半英文）

（2）辅助说明描述不清

（3）日常描述实用专业术语不规范

（4）界面存在错误文字

（5）用户体验感不好

2、 bug包含的内容：

1、所属产品

2、所属项目

3、所属模块

4、影响版本

5、当前指派

6、bug类型

7、bug标题

8、bug严重级别

9、bug优先级

10、重现步骤

11、相关联需求

3、bug类型：

（1）代码错误

（2）界面优化

（3）配置相关

（4）安装部署

（5）安全相关

（6）性能问题

（7）标准规范

（8）测试脚本

（9）其他

4、bug生命周期

1、基本流程

新建bug（测试）==指派给开发（指派前后端开发，测试指派）==开发验证bug==解决bug（开发）==待验证，（开发转给测试)==验证bug（测试）== 验证通过==关闭bug（测试）

2、异常流程（验证不通过情况）

新建bug（测试）==指派给开发（前后端开发，测试指派）==开发验证bug==解决bug（开发）==待验证，（开发转给测试)==验证bug（测试）==验证不通过==再次指派给开发（前后端开发，测试指派）==解决bug（开发）==待验证，直到验证通过===关闭bug（测试）

3、异常流程（关闭bug后，激活bug）

新建bug（测试）==指派给开发（前后端开发，测试指派）==解决bug（开发）==待验证，（开发转给测试)==验证bug（测试）== 验证通过==关闭bug（测试）==再次遇到同一个bug==激活bug==指派开发==解决bug（开发）==待验证，（开发转给测试)==验证bug（测试）==  验证通过==关闭bug（测试）

在工作中已经提了bug，需要和对应的开发通知下，自己要跟进

5、bug解决方案：

（1）设计如此

（2）重复bug

（3）外部原因

（4）已解决

（5）无法重复

（6）延期处理

（7）不予解决

6、 你认为是bug，开发认为不是bug，如何处理？

总结：三个方向：

（1）自我原因，检查自己的测试过程或疏忽的问题，如：页面404，服务未启动，自己配置错了、后天数据库有脏数据等。

（2）开发原因：

a.把报错的图片截取出来

b.把测试步骤记录下来，重现bug步骤

c. 查看后台的日志，把日志错误查找出来

d、在和开发进行沟通，说明原因；如果电话沟通不了，现场沟通，操作bug说明报错，说明影响程度。

e.如果开发还是不认，需要找开发经理，协调测试，请求其他开发辅助解决；

（3）既不是开发原因，也不是测试原因，是产品原因

与开发沟通，开发是按需求开发，测试是按需求测试，测试的时候发现测试不了，少了某个步骤或环节，测试不了，找到开发，开发不认。找产品确定功能点，是不是产品遗漏了，如果是产品少了需求，就要从产品通过邮件发送整个项目组，补上需求，给开发加上工期，测试在测试。

7、偶现bug？

工作中出现了偶现的bug如何处理？（刚刚有，现在没有了）

偶现bug就是无法重现的bug：

解决方案‘：

1、先记录重现步骤，和报错的现象，查看后天报错

2、在与开发交流，描述bug的现象，确认bug的严重程度；

3、尽量去重现或查看源代码，查看逻辑是否有问题，让开发修改

4、根据bug的严重程度，找测试经理确认：影响小，不影响版本，先记录下，写明原因，下一个版本解决或后期关注；如果影响大，找测试经理和开发经理协调修改

8、bug的状态：

1、new （新的）

2、assigned(已指派)

3、open（打开）

4、fixd（修复）

5、pending reset（待再测）

6、close（已关闭）

7、reopen（再次打开）

8、pending reject(拒绝)

9、rejected（被拒绝）