测试用例常用的7种设计方法:等价类、边界值、场景设计法、判定表、因果图、功能图分析法(状态迁移图)、正交法、错误猜测法。
一、等价类
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。某个输入域的子集合就是等价类。等价类划分有两种不同的情况:有效等价类和无效等价类。设计测试用例时,要同时考虑这两种等价类。
- 有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能。 - 无效等价类
指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能多个。
举例
设有一个档案管理系统,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。
(1)划分等价类并编号
输入等价类 | 有效等价类 | 无效等价类 |
---|---|---|
日期的类型及长度 | ①6位数字字符 | ②有非数字字符 ③少于6位数字字符 ④多于6位数字字符 |
年份范围 | ⑤在1990~2049之间 | ⑥小于1990 ⑦大于2049 |
月份范围 | ⑧在01~12之间 | ⑨等于00 ⑩大于12 |
(2)设计测试用例,覆盖所有的有效等价类
测试数据 | 期望结果 | 覆盖的有效等价类 |
---|---|---|
200211 | 输入有效 | ①⑤⑧ |
(3)设计测试用例,覆盖无效等价类
测试数据 | 期望结果 | 覆盖的有效等价类 |
---|---|---|
95June | 无效输入 | ② |
20036 | 无效输入 | ③ |
2001006 | 无效输入 | ④ |
198912 | 无效输入 | ⑥ |
200401 | 无效输入 | ⑦ |
200100 | 无效输入 | ⑨ |
200113 | 无效输入 | ⑩ |
二、边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
与等价划分的区别:
(1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
(2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。
通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。下表举例利用边界值作为测试数据。
项 | 边界值 | 测试用例的设计思路 |
---|---|---|
字符 | 起始-1个字符/结束+1个字符 | 设一个文本输入区域允许输入1个到255个 字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值。 |
数值 | 最小值-1/最大值+1 | 假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、99999作为最大值;然后使用刚好小于5位和大于5位的数值来作为边界条件。 |
空间 | 小于空余空间一点/大于满空间一点 | 例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件。 |
在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。内部边界值条件主要有下面几种:
- 数值的边界值检验
项 | 范围或值 |
---|---|
位(bit) | 0或者1 |
字节(byte) | 0——225 |
字(word) | 0~65535(单字)或 0~4294967295(双字) |
千(K) | 1024 |
兆(M) | 1048576 |
吉(G) | 1073741824 |
- 字符的边界值检验
字符 | ASCII码值 | 字符 | ASCII码值 |
---|---|---|---|
空(null) | 0 | A | 65 |
空格 (space) | 32 | a | 97 |
斜杠 ( / ) | 47 | Z | 90 |
0 | 48 | z | 122 |
冒号 ( : ) | 58 | 单引号 ( ‘ ) | 96 |
@ | 64 |
- 其他边界值检验
三、场景设计法
通过运用场景对系统的功能点或业务流程进行描述,从而提高测试效果的一种方法。模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。
基本流:是经过用例的最简单的路径(无任何差错,程序从开始直接执行到结束)
备选流:一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,也可以起源于另一个备选流,或终止用例,不在加入到基本流中;(各种错误情况)
-
基本流
进入购物网站,选择物品,登录账号,付费,生成订单 -
备选流
(1)账号不存在
(2)账户余额不足
(3)……
四、判定表
判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合。判定表很适合于处理这类问题。
判定表由四部分组成,如下图:
(1) 条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
(2) 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
(3) 条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
(4) 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
判定表的建立步骤:
(1)确定规则的个数。假如有n个条件。每个条件有两个取值(0,1),故有2的n次方种规则。
(2)列出所有的条件桩和动作桩。
(3)填入条件项。
(4)填入动作项。得到初始判定表。
(5)简化。合并相似规则(具有相同的动作,并且其条件项之间存在着极为相似的关系)
举例
需要确保电脑有打印机的驱动、打印机正常工作、打印机的纸张充足、打印机墨粉充足才能满足打印。
(1)确定规则个数:4个条件,规则个数是2^4=16
(2)得到条件桩和动作桩
(3)生成判定表
*其中出现多个动作项的情况,按照最先触发的情况给出。
化简后如下:
实际写用例的时候可以先以一条规则为基准,每次改变一个条件桩的条件项(有几个条件项就改变几次)。再进行补充或化简。
软件测试基础—流程和用例设计方法https://www.cnblogs.com/deliaries/p/12393843.html
自动化测试之-测试用例设计方法总结
http://www.uml.org.cn/Test/201906181.asp