五、测试用例和设计方法

测试用例

定义

+ 定义：设计一个情况，软件程序在这种情况下，必须能正常进行并且达到程序所设计的预期结果

+ 如果软件按照测试用例达不到预期结果怎么办？
	=> 表示已经测出软件的缺陷
	=> 标示该缺陷，通知软件开发人员
	=> 开发人员把这个问题修改完成于下一个测试版本内
+ 开发人员说缺陷修复了，OK么？
	=> 测试人员获取到新的测试版本后，必须利用同一个用例来测试该问题，确保该问题已修改完成

模板和内容

+ 工具：excel
+ 设计测试用例的模板范围：测试用例编号 ... 预期结果

+ 标识符(用例编号)
	=> 一般编号规则：Testcase_项目名称_模块名称_功能名称_0001
	=> 也可加入测试分类：功能(Function)、界面(UI)、性能(Performance)、安全(Security)、接口(Interface)。例：Testcase_项目名称_模块名称_功能名称_Function_0001
	
+ 测试项
	=> 测试目的(包含测试模块、对象、方式和事件)。 一般只写一个目的，必须明确，不可摸棱两可！
	=> 决定测试步骤和预期结果
	=> 例如：使用谷歌浏览器打开百度首页；在QQ登陆界面输入正确的用户名和密码能登陆上。
	
+ 依赖用例
	=> 一般功能流程上、下游的功能测试依赖于上游的功能测试用例
	=> 可以跨越模块
	=> 例：要登陆QQ，就必须有注册过QQ；删除功能测试用例依赖于添加功能测试用例
	
+ 测试步骤
	=> 用最简单的语言，尽量详细地写出来软件的操作步骤
	=> 例：在用户名文本框输入： XXX；在省份下拉列表选择：北京，在城市下拉列表选择：北京
	
+ 输入数据/说明
	=> 单独整合输入数据，必须和测试步骤中的数据保持一致
	=> 没有数据，就空着不写（须在测试项中标注某一个内容为空）
	
+ 预期结果/输出说明
	=> 准确性：对象、内容
	=> (原则上每一个操作，都要有一个结果)
	=> 在重要的步骤之后，设定预期结果
	=> 例：页面跳转到XXX；程序弹出对话框，提示用户名或密码错误，请重新输入！(一般和测试目的密切相关)
	
+ 测试结果
	=> 要求在测试执行完成后添加。没有执行保持为空。
	=> 测试结果只要两个：通过/失败；Pass/Failed
	
+ 测试人
	=> 测试的执行人。可以和设计者相同，也可以不同。
	
+ 备注
	=> 为了测试用例正常执行而做的特殊准备
	=> 例：在网络不畅通的情况下，软件的错误提示：您已和服务器断开连接

作用

编写注意事项

+ "杀虫剂效应"：
	=> 一个发现过缺陷的测试用例，就相当于杀虫剂，该测试用例会变得具有耐药性
	=> 所以需要使用“更强的杀虫剂”——新的测试用例(与之前的用例中数据类型保持一致)进行重新测试。

黑盒测试用例设计方法

测试数据选择

等价类划分法

+ 把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例

+ 若某一类中的一个例子发现了错误，这一等价类中的其他例子也会发现同样的错误

+ 注意不要出现重复，也不要缺失

设计步骤

+ 确定等价类的原则
	1. 在输入条件规定了取值范围或值的个数得情况下，可以确立一个有效等价类和两个无效等价类
		=> 例：一个文本框规定输入字符个数为 6~18位
		=> 一个有效的等价类：范围内的任意一个
		=> 两个无效的等价类：小于6；大于18
	2. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件下，可以确立一个有效等价类和一个无效等价类
		=> 例：请输入11位的手机号
		=> 一个有效的等价类：11位
		=> 一个无效的等价类：不是11位
	3. 在输入条件是一个布尔值的情况下，可确定一个有效等价类和一个无效等价类
		=> 例：“true”有效，“false”无效
	4. 在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类
		=> 例：登陆中要输入用户名和密码
	5. 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
		=> 例：用户名要求6~18，由字母、数字、下划线组成；字母区分大小写；要以大写字母开头
	6. 在确定已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小地等价类

+ 划分等价类和列出等价类表
	=> 有效等价类
	=> 无效等价类
		-> 一个反向的(无效等价类)测试数据，只要违反一个需求即可(不要一次测试多个点)
	
+ 确定测试用例
	=> 给每个等价类规定一个唯一的编号
	=> 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖
	=> 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖

以百度登陆界面为例

+ 用户名：设置后不可更改；中英文均可；最多14个英文或7个汉字（隐性条件：用户名不能重复；不可为空；特殊符号不支持）

+ 将等价类划分组成表格分析

边界值分析法

因为开发中数据范围的边界是最容易产生bug的地方，所以为了保证测试质量，就需要重点测试边界，就有了边界值这样的测试方法

+ 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超过该范围边界的值(次边界值)作为测试输入数据
	=> 边界值点：有效等价类和无效等价类之间的分界点。（最大值、最小值）
	=> 次边界值点：边界值左右两边相邻的点是次边界值点 (按照系统规定的单位或计算方式，一个数据的差异)，共4个次边界
		-> 有效最小次边界
		-> 无效最小次边界
		-> 有效最大次边界
		-> 无效最大次边界

思考：
1) 6≤x≤18，请问测试中x的边界值要选取哪几个进行测试？
	-> 边界值：6，18
	-> 次边界值：5，7，17，19
2) 6<x<12, 请问测试中x的边界值要选取哪几个进行测试？
	-> 边界值：7，17
    -> 次边界值：6，8，16，18
3) 文本框输入字符的个数要求是不大于150字。测试时如何选择边界值？
	-> 空，1，149，150，151

+ 若程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
+ 若程序中使用了一个内部数据结构，则应当选择这个内部数据边界上的值作为测试用例

案例

+ 三角形：构成三角形？直角、等腰、等边、钝角、锐角？

等价类划分：

测试用例：

作业：

+ 四边形：平行四边形？正方形？长方形？
+ 五边形：有没有特殊的形状？若有，如何判断？

测试步骤设计

因果图法

+ 一种适合于描述多种输入条件组合的测试方法
+ 根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法
+ 适合于检查程序输入条件涉及的各种组合情况
+ 优势：能够发现设计中存在的不足
+ 局限性：当原因和结果很多时，逻辑关系多，因果图的可读性差。因此因果图用作局部的小功能(原因和结果不多的时候)

步骤

分为原因对原因，原因对结果，结果对结果的约束

1. 原因→结果：
	=> 恒等：原因C成立，结果Ef一定成立
	=> 非：原因C成立，结果Ef一定不成立
	=> 与：原因C1、C2、C3都成立，结果Ef才会出现
		-> 例：QQ注册页面：在所有元素内容(邮箱、昵称、密码、手机号...)都填写正确的情况下，才会有注册成功的结果
	=> 或：原因C1、C2里只要有一个成立，结果Ef一定成立

2. 原因→原因：
	=> 互斥Exklusve(E)：C1，C2，C3不会同时成立，至多只有一个为1
	=> 包含Inclusive(I)：C1，C2至少有一个为1(成立)，不能同时为0(不成立)
	=> 要求Require(R)：C1是1时，C2必须是1，即C1为1时，C2不能为0
		-> 例：要想发送验证码，必须手机号填写正确
	=> 唯一Only One(O)：C1和C2中有且只有一个为1

3. 结果→结果：
	=> 屏蔽Masking(M)：结果之间会出现互相屏蔽的情况，即Ef1结果出现，Ef2结果一定不出现
		-> 例：当你收到注册成功的提示，就一定不会收到数据填写数据的提示

案例

案例：有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下。若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来。若投入1元钱的硬币，同样也是按“橙汁”或“啤酒”的按钮，则自动售货机在送出相应饮料的同时退回5角钱的硬币。

+ 1. 确定需求中的原因与结果

+ 2. 确定原因与结果的逻辑关系(以下只画了部分)

+ 3. 确定因果图中的约束

+ 4. 画出因果图并转化为决策表，以便测试用例的设计
	=> 标黄的C5-C7都是bug，不能作为测试设计：
		1）只选择饮料，没有投币的时候，软件没有任何结果/提示信息
		2）只投币，没有选择饮料的时候，软件也没有任何结果/提示信息
		3）我们不能把软件的缺陷，设计成测试用例
			-> 因果图的设计用例只能用来测试正确的因果关系，结果是理想的预期结果。

+ 5. 根据决策表把每一次操作和预期结果填入测试用例模板表中，即可

判定表法

场景法

正交实验法

功能图法