软件测试之测试用例的设计

对于测试工作而言，最重要的无疑就是测试用例的设计。好的测试用例可以帮助测试人员更好更快地发现软件中的错误，对于提高产品质量意义重大。本文就是针对测试用例的设计方法。

测试用例的基本要素

在前面的文章中，已经提到了测试用例是为了实施测试而向被测试的系统提供的一组集合。一般这组集合中需要包含的几个要素分别是：测试环境、操作步骤、测试数据、预期结果等；

测试用例的设计

基于设计测试用例的目的，即为了满足用户需求，验证产品与需求是否相符。因此，一般我们可以从以下几个方面来设计测试用例；

• 功能测试：以需求文档为参考，验证产品是否实现了其应该实现的功能，是否没有实现其不应该实现的；
• 性能测试：站在用户的角度，考虑在一些极端情况下的用户体验是否友好，包括高并发量、产品的响应时间等；
• 界面测试：可以参考设计图进行，包括但不限于用户看到产品的一切像颜色、大小、材质、错别字、是否存在遮挡情况等等；
• 兼容性测试：考虑产品在不同的环境下的使用体验，像浏览器的兼容性、版本的兼容性、系统的兼容性、数据兼容性等；
• 易用性测试：同样以用户体验为主，产品是否具备了简单易上手的属性；
• 安全测试：检查产品对于用户隐私数据的保护，产品本身对用户是否安全等；

对于一件产品而言，测试用例的设计是可以牵扯到产品的方方面面的，当然也是越全面越好。上面只是提供了一些测试用例设计时可以参考的角度，因此也不必局限于设计测试用例只能从这几个方面。

这是一些有关于测试用例设计的案例，可以参考（点击此处即可跳转）

其中，在兼容性测试中可能会遇到这样的问题：产品版本和浏览器版本一定是众多的，要想达到完全测试几乎不可能，那么要如何选择测试的版本呢？

首先一定是选择大部分用户使用的版本，大家主流认可的版本使用者一定更多，而在实际的工作中其实是有数据后台可以检测到大部分用户使用的版本情况的，因此同样可以帮助我们更好的选择测试的版本；

设计测试用例的具体方法

前面有关于测试用例的设计，更多地提供的是一些设计测试用例的角度和思路，下面是设计测试用例的具体方法；

等价类划分法

一般一个程序都会有多个输入，等价类划分法就是将这些输入数据根据输入需求进行划分，等价类的划分一般分为有效等价类和无效等价类；
有效等价类即有效值的集合，一般是符合规格说明书的有意义的输入值构成的集合；
无效等价类即无效值的集合，不符合规格说明书或用户需求的集合；

以最常见的密码输入为例，规定密码长度为8-18位的数字，有效等价类和无效等价类的划分如下：

等价类划分成功以后，就可以进行测试用例的编写了：

1. 输入长度为8~18位的密码，具体测试数据563368368；
2. 输入长度小于8位的密码，2345；
3. 输入长度大于18位的密码，56638649636478467793646447;
4. 输入非数字的密码，sghtesh;

边界值分析法

边界值分析法就是针对输入或输出的边界值进行测试的方法，它更多的是一种对等价类划分法的补充测试；

同样以上面密码输入为例，使用边界值分析法对测试用例进行补充：

1. 输入长度为7位的密码，4563245；
2. 输入长度为8位的密码，78564390；
3. 输入长度为18位的密码，542398540981234567；
4. 输入长度为19位的密码，4327856419076423162；

一般情况下的边界值是有效边界+无效边界；

判定表

判定表是一种常见但不常用的测试用例设计方法，更多地使用在输入条件的组合会对应不同结果的场景；

使用判定表设计测试用例可以参考下面的步骤进行：

1. 确认输入条件与输出条件；
2. 寻找输入条件与输出条件之间的关系；
3. 画判定表；
4. 根据判定表编写测试用例；

以淘宝购物时的优惠活动为例，当用户提交的订单使用了红包或者订单金额大于500元，认定此订单为优惠订单；

根据判定表编写测试用例：

1. 有红包，订单金额大于500，提交订单，为优惠订单；
2. 有红包，订单金额不大于500，提交订单，为优惠订单；
3. 有红包，未提交订单，为非优惠订单；
4. 无红包，订单金额大于500，为优惠订单；
5. 无红包，订单金额大于500，未提交订单，为非优惠订单；
6. 无红包，订单金额不大于500，提交订单，为非优惠订单；
7. 有红包，订单金额大于500，未提交订单，为非优惠订单；
8. 无红包，订单金额不大于500，未提交订单，为非优惠订单；

场景设计法

场景由事件触发而形成，产品的使用又一定会有事件的触发，因此经同一事件不同的触发顺序和处理结果就形成了事件流。场景设计法其实就是通过对事件触发时情景的描绘来设计测试用例。

实际就是使用业务流程将产品的各个孤立的功能点串起来，可以避免测试陷入功能细节而忽略业务流程结构的误区；
事件流有基本事件流与备选事件流；

以使用ATM取款为例，基本事件流为程序执行正常时的情况，但也不可避免地会出现备选事件流中的故障，备选事件流是根据实际使用ATM取款时设计的，这就是场景设计法的运用；

根据上面的事件流编写测试用例：

1. 基本事件流的用例：首先插卡，选择取款功能，输入卡的密码，选择要取款的金额，进行取钞操作，退卡；
2. 备选事件流的用例：
3. 插入卡时插入不进去；
4. 插入卡之后，无法选择取款操作；
5. 插入卡，选择取款操作，输入密码时输入错误；
6. 插入卡，选择取款操作，输入密码，选择取款金额，金额不符合要求；
7. 插入卡，选择取款操作，输入密码，选择合适的取款金额，等待ATM吐钞失败；
8. 插入卡，选择取款操作，输入密码，选择合适的取款金额，待吐钞之后取钞，退卡时不成功；

场景设计法主要是一种思路引导的作用，在设计测试用例时，不仅要基于需求文档进行基础测试，还应该尽可能地考虑到在实际使用中可能会出现的情况；

正交法

前面我们使用判定表的方式来设计测试用例，但判定表的方式有可能会得到很多测试测试，其中不乏有一些是不太必要的。因此我们使用正交法来尝试解决这个问题；

正交法是一种对试验元素的水平组合进行试验，通过试验结果分析了解全面试验的情况，最终找出最优的水平组合；
正交法的目的就是为了减少用例数目，用尽量少的用例覆盖更多的输入组合情况；
正交试验设计是一种基于正交表的高效率且快速经济的试验；

关于正交法的几个概念：

因素：需要被考察的变量；
水平：因素可能的取值；

以网站的注册操作为例，演示正交法设计测试用例的步骤（使用allparis生成正交表）：

1. 确定试验的因素和水平都有哪些；
   因素：用户名、电话号码、验证码、密码、确认密码；
   水平：每个因素的水平都为填写和未填写；

2. 将水平和因素写入excel；

3. 在allparis同级目录下创建一个新的txt文件，复制前面excel中的内容，直接保存；

4. 使用allparis生成正交表（使用cmd操作）；

这里重定向指定的文件（保存正交结果的文件）可以是在该目录下不存在的；

打开保存结果的文件，就可以看到生成的正交结果了：

5. 利用正交表每一行的各因素水平的组合为一个测试用例，最后可以增加有必要但正交表中不存在的测试用例；

然后就可以使用生成的正交表编写测试用例啦；

1. 用户名、电话号码、验证码、密码、确认密码都填写；
2. 只填写用户名，其他未填写；
3. 只填写电话号码和密码，其他未填写；
4. …(~表示此处选项可以为任意值，不影响测试结果)；

正交表的两条性质：
每一列中不同的选项出现的次数相等；
任意两列中的各有序选项出现的次数齐全且均衡；

错误猜测法

错误猜测法是建立在测试人员对产品设计的理解上，更多地是依赖测试人员的工作经验和积累来设计测试用例；

设计测试用例是测试人员测试工作中重要的一环，一个好的测试用例应该是对于一个不熟悉业务的人也能够根据用例来进行测试；而一组好的测试用例则是尽可能多的覆盖产品使用的各种情况。

over!