【测试】功能测试用例设计方法总结

测试用例可以用来衡量一个项目测试质量，因此在平时的测试流程中，编写测试用例就是测试过程中很重要的一步，每一个测试工程师都需要并且非常熟练的编写测试用例，能在编写测试用例中尽可能的覆盖任何异常的测试点；如何能编写优秀的测试用例，就需要测试人员掌握更多的用例编写技巧以及思考出更多的测试点。针对于游戏测试，大多更偏向于功能方面的测试，根据功能测试用例逐项测试，检查产品是否达到了策划的需求。功能测试主要采用黑盒测试策略设计测试用例，进行测试。主要功能模块测试的测试用例设计方法包括：等价类划分、边界值分析、错误推测法、因果图和判定表、场景法、正交实验法。下面就以上几种方法进行一些分享。

等价类划分法

等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此发现更多的软件缺陷，统计好数据后由此对软件进行改进升级。

举例一：设有一个认证条件，要求玩家输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。首先，划分等价类并编号,下表等价类划分的结果。

设计测试用例，以便覆盖所有的有效等价类，在表中列出了3个有效等价类，编号分别为（1）、（5）、（8），设计的测试用例如下：

为每一个无效等价类设计一个测试用例，设计结果如下：

举例二：登录账号的时候，邮箱地址输入框输入数据，程序检测，判断用户输入的邮箱地址是否合法。现用等价类划分法和边界值分析法设计测试用例：

1）对输入的要求

1、用户名只能用小写字母和数字还有‘.’组成

2、邮箱用户名首位必须是小写字母或者数字

3、用户名长度在6-30个字符之间

4、必须要有 @ 符号和必须要有 ‘.’

5、@后面要以*.*结束(*为任意字符串)

2）等价类表：

3）覆盖等价类的测试用例：

边界值分析法

其实边界值可以算是为了配合等价类而加的一个限制条件，一般会根据略小于最小值、略大于最大值、等于最小值/最大值进行边界值的一些验证；一般来说，关于区间型数据边界值的测试，大多都是略小于最小值和略大于最大值是不满足要求的，中间的数据是满足需求的。边界值附近的数据确定的几种方法：

举例一：还是以上面要求玩家输入以年月表示的日期来作为例子。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"，下面是关于边界值需要检测的点。

举例二：购买一个宝箱，一次性最多只能购买5个，以边界值的标准可选取5个（正好等于）、6个（刚刚大于）、4个（刚刚小于），3个（正常值）作为边界值来测试。

错误推测法

没有确定的步骤，很大程度上是凭经验，结合以往测试经验和直觉设计软件在功能和流程上可能存在的各种错误，进行容错性测试。例如输入数据为零或输出数据为零时容易发生错误的情况，所以可选择输入值为零的例子，以及使输出值为零的例子；又如输入表格为“空”或输入表格只有一行是较易出错误的情况，所以可选择表示这些情况的例子。根据字面意思，也就是列出可能出现问题的点，猜测哪些情况可能会有问题。举例一：如面购买宝箱的例子，针对于需求，仅是对于给出的数据进行了测试，但是在实际情况中，实际要求中需要注意的点。根据平时测试，出现过问题的地方，所以又应该考虑到以下的测试点：

（1）尝试购买-1个宝箱

（2）尝试购买0个宝箱

（3）多次购买小于5个宝箱

（4）多次购买5个宝箱

（5）购买宝箱后重启客户端/服务器

（6）.......

举例二：对于游戏中，需要做屏蔽词功能，需要考虑到以下玩家会进行操作的功能点进行测试（多多自走棋为例），我们需要考虑到所有可能出现玩家输入信息的地方，根据对平时对项目的熟悉以及自己的经验，想到一些可能会出现问题的地方：

（1）创建账号（玩家填写角色名称）

（2）聊天功能(世界聊天、好友私聊、队伍聊天、发送邀约信息、制图工坊、房间队伍聊天、局内战斗聊天、局内私聊、局内观众、局内裁判、观战发送聊天信息)

（3）个人信息（玩家修改昵称）

（4）自建房间（玩家创建/修改房间昵称）

场景法

百度百科对场景法的解释是：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。在一个游戏功能中，将大功能拆分为一个个小功能，而这些小功能就可以视为一个个小场景，这些小场景的集合就成了这个完整的功能模块。

举例，比如多多自走棋的通行证每周挑战功能：

根据这个界面，我们可以分为以下几个部分：

（1）每日奖励

（2）经验等级

（3）具体任务信息

（4）购买等级

（5）奖励展示

（6）视频播放

（7）帮助按钮

（8）购买等级

以上这些小功能以玩家可能会涉及到的操作为出发点，我们可以理解为一个个小场景，将他们组合起来就构成了这个完整的功能，这些小功能构成了整个每周挑战这个功能。以上的这些小功能应该更多以玩家的角度进行考虑。

因果图法和判定表

等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系、相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多，因此需要考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要利用因果图。下面先了解一下因果图得一些规则，下面以图的形式详细说明6种因果逻辑。 c表示原因，e表示结果：

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

（2）非：只有原因为假，结果才为真。

（3）与：只有2个原因都为真，那么结果为真。

（4）或：2个原因中有一个为真时，结果就为真。

（5）与非：先与后非。

（6）或非：先或后非。

（7）排他性约束：各个原因之间不能同时为真，但可以同时为假。

（8）包含性约束：各个原因中总有一个为真。即可以同时为真，但不可以同时为假。

（9）必要性约束：当原因a为真时，原因b必须同时为真

（10）唯一性约束：有且只有原因a和原因b中的一个为真但是原因b为真时，原因a既可以为真，也可以为假。

（11）掩码标记（结果约束）：如果结果b为真，那么结果a一定为假，如果结果b为假，则结果a的状态不定

举例一：以多多自走棋为例，玩家查看图鉴中的棋子：第一步必须是A（点击仓库）或B（点击大厅右上角图鉴按钮），第二步必须是C（点击棋子图鉴），在此情况下玩家进入到棋子图鉴界面，但如果第一步不正确，得出结论L；如果第二步骤不是C，则得出结论M。首先我们整理一下，得出以下信息以及因果图：

1）根据题意，原因和结果如下：

原因：

1——第一步是A；

2——第一步是B；

3——第二步是点击棋子图鉴。

结果：

21——进入棋子图鉴；

22——得出结论L；

23——得出结论M。

2）其对应的因果图如下：

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

3)根据因果图建立判定表：因为一般可以根据因果图画出判定表，判定表里只有0,1（1代表真，0代表假）两个数字。若输入条件有n个，则用例考虑的情况有2n种，即8种：

表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。所以用例有：

（1）1，3------21

（2）1-----23

（3）2，3----21

（4）2-----23

（5）3---22

（6）不进行任何操作-----22，23

正交试验法

利用正交实验设计方法设计测试用例，比使用等价类划分、边界值分析、因果图等方法有以下优点：节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率。

举例：

这是游戏账号注册的一个窗口。我们可以看到要测试的控件有3个：邮箱地址、密码、验证码，也就是要考虑的因素有三个；而每个因素里的状态有两个：填与不填。选择正交表时分析一下：

1、表中的因素数>=3；

2、表中至少有3个因素数的水平数>=2；

3、行数取最少的一个。

从正交表公式中开始查找，结果为：

L4(23)（0-填 1-不填）：

变量映射如下

测试用例如下：

1：填写邮箱地址、填写密码、填写验证码

2：填写邮箱地址、不填密码、不填验证码

3：不填邮箱地址、填写密码、不填验证码

4：不填邮箱地址、不填密码、填写验证码增补测试用例

5：不填邮箱地址、不填密码、不填验证码

从测试用例可以看出：

（1）如果按每个因素两个水平数来考虑的话，需要8个测试用例，而通过正交实验法进行的测试用例只有5个，大大减少了测试用例数。用最小的测试用例集合去获取最大的测试覆盖率。

（2）因素数不相同如果因素数不同的话，可以采用包含的方法，在正交表公式中找到包含该情况的公式，如果有N个符合条件的公式，那么选取行数最少的公式。

（3）水平数不相同采用包含和组合的方法选取合适的正交表公式。