测试用例的设计方法

测试用例的总体设计方法

基于需求的设计

RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，
因为它使测试专注于质量问题产生的根源，即需求。

基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
（1）验证需求是否正确、完整、无二义性，并且逻辑一致。
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。

案例：

用户需求:
购买3000块钱以内的华为智能手机
测试用例：
1.价格<=3000元
2.品牌为华为
3.智能手机
4.手机功能验证：
  4-1.打电话
  4-2.接电话
  4-3.发短信
  4-4.收短信
 ...

软件需求：
1.1.1.1.5.3 事件流
1. 若用户未收到**邮件，可在登录界面录入电子邮件及密码后，再次发送**邮件。
2. 每次发送的**邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送**邮件。

**测试用例**
1-1、未收到邮件，登录时输入电子邮件及密码后，再次发送**邮件
1-2、已收到邮件，登录时输入电子邮件及密码后，不发送**邮件
2-1、收到邮件，24小时内进行**
2-2、收到邮件，24小时后链接过期进行**。
2-3、收到邮件，已**，24小时后链接过期，再次点击**？
页面检查：
1、收到**邮件
2、邮件内容正确
3、**URl正确，可**
4、再次**提示已**
5、过期**提示已过期

具体的设计方法

等价类

思路：输入的集合是无穷的, 不能全都覆盖到

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
• 无效等价类：根据需求说明书，不满足需求的集合。

超市买水果
有效等价类：苹果、桃子、梨
无效等价类：青菜、米、饮料，...

边界值

边界值分析法：
就是对输入或输出的边界值进行测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

日常语言中的"边界"漏洞

考完试发成绩了, 老师布置寒假作业: 超过60分的, 所有题目抄写1遍, 
低于60分的, 所有题目抄写3遍. 于是小明就没有写作业..., 因为他刚好60分.

1.  输入框长度为1-11，取边界值为：1、11、12、0
2.  运动员的参赛项目为1-3项，取边界值为：0项、1项、3项、4项
3.  查询面页面有999行，每50行为一页，取边界值为：输出0行、1行、50行、51行、999行

以注册邮箱的软件需求为例子 
用户名要求长度为6-15位 
边界值上点为：5，6，15，16 全了吗？

在实际的测试设计中，会将等价类和边界值结合起来使用，
那么我们最终可以确认的用例设计为：
5,6,10,15,16五个长度的字符的输入值

因果图

因果图：简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。
因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

因果图的需要掌握的基本知识

• 恒等
  
  恒等：如果原因为真，那么结果必定为真。

• 与
  
  只有2个原因都为真，那么结果为真

• 或
  
  2个原因中有一个为真时，结果就为真。

• 非
  
  只有原因为假，结果才为真。

因果图法设计测试用例的步骤如下：
(1)分析所有可能的输入和可能的输出。
(2)找出输入与输出之间的对应关系。
(3)画出因果图。
(4)把因果图转换成判定表。
(5)把判定表对应到每一个测试用例。

案例：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。

1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：
   ● 输入：订单已提交、金额大于300、有红包。
   ● 输出：优惠、不优惠。
2. 然后，进行第二步，找出输入与输出之间的对应关系。
   通过分析，可以看出有以下的对应关系。
   (1)订单已提交，订单金额大于300元，则优惠。
   (2)订单已提交，订单金额小于等于300元，无红包，不优惠
   (3)订单已提交，有红包，则优惠。
   (4)订单已提交，订单金额大于300元，有红包，则优惠。
   (5)订单未提交，不优惠。
3. 为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下：
   1：订单已提交。
   2：订单金额大于300元。
   3：有红包
   21：优惠
   22：不优惠
4. 画因果图
   
5. 画判定表：有3个条件,输出有2个取值，所以表的列数为2x2x2=8
   
6. 最终的测试用例
   1，2，3，4，5（包含6，7，8）。

因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间。

正交排列

目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

因素(Factor)：在一项试验中，凡欲考察的变量称为因素（变量） 

水平(位级)(Level)：在试验范围内，因素被考察的值称为水平（变量的取值） 

正交表的构成：
行数(Runs)：正交表中的行的个数，即试验的次数,用N代表。 
因素数(Factors)：正交表中列的个数，用C代表。

水平数(Levels)：
   任何单个因素能够取得的值的最大个数。			
   正交表中的包含的值为从0到数“水平数-1”或从1到“水平 数”，用T代表。

正交表的表示形式： L=行数(水平数*因素数) L=N(TC) 

正交表的两条性质： 
   每一列中各数字出现的次数都一样多。 
   任何两列所构成的各有序数对出现的次数都一样多。

正交法设计测试用例的步骤： 
   1、有哪些因素（变量）
   2、每个因素有哪几个水平（变量的取值）
   3、选择一个合适的正交表
   4、把变量的值映射到表中
   5、把每一行的各因素水平的组合作为一个测试用例
   6、加上你认为可疑且没有在表中出现的用例组合 

案例：
以注册为例：

1. 因素：姓名、邮箱、密码、确认密码、验证码
2. 水平：填写、不填写
   
3. 表中的因素数=5；
   表中至每个因素数的水平数=2 行数取最少的一个，
   即试验次数最少的一个
   L=N(TC)=(2-1)*5+1=6=6(25) L=6(25)
   N试验次数
   T水平数
   C因素数
   选择正交表，这里选择了L6_2_5。
   正交表不是随便选择的，而是设计好的。
4. 生成测试用例
   思路：
   因素取值为填写时：正交按取值个数5-3-2-1（5已全了，3，2，1任意排列）进行排列，实验次数不够用取 值为填写个数为2或3任意组合，但要满足正交的二条性质。
   
5. 增补测试用例 姓名、邮箱、密码、确认密码、验证码都不填写

场景设计法

事件触发控制流程，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

案例：
以注册为例：

错误猜测法

错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。
经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。
梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

案例：
以注册为例：
1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文？

总结

1.基于需求：学习需求，
    难点：看出需求以外的测试点

2.等价类：
   思想：减少测试用例，解决输入无穷的问题
   使用场景：输入，输入无穷
   概念：无穷的输入分成N个类，然后从类里边提取一个数据进行测试，
  	     只要这一个数据测试通过，我们就认为它所在的这一类数据全部测试通过。
  	     
3.边界值：
   使用场景：输入和输出的“边界值”
   取值规则：开区间、闭区间
   [1,50] 则取：0,1,50,51
   (1,50] 则取：1,2,50,51
   
4.因果图（掌握概念）：
   使用场景：输入（原因）和输出（结果）之间的关系。
		     输出依赖我们的输入（多个）。
   步骤：		     
      第一步：理解所有的输入和输出
	  第二步：再出输入和输出之间的关系
      第三步：画因果图
	  第四步：再判定表（列数：输入：幂数  输出：底数）
	  第五步：从判定表提取测试用例
	  
5.正交排列法（掌握概念）：
   目的：减少测试用例条目
   思想：正交表（抽样）
   两条性质：1.所有列中的数据个数相同
			 2.任何两列中的有序对数相同
			 
6.场景法：业务流程（一个业务流程中不一定是一个场景），事件流。
  难点：对需求很了解

7.错误推测法：
   三个来源：
      1.测试人员对项目测试时间长					
         A：功能、业务复杂度了解
		 B: 对开发人员的代码能力了解		
      2.用户反馈（线上或线下反馈）                  
      3.缺陷（未发布上线之前）、
	    故障库（线上环境、生产环境，如果出现bug，就是故障）