【测试开发】测试用例的设计方法

目录

一. 测试用例的基本要素  

二. 测试用例的设计方法

1. 测试用例设计的万能公式

水杯测试用例

 2. 基于需求的设计方法

邮箱注册测试用例 

 3. 等价类方法

有效等价类和无效等价类

 等价类思想设计测试用例步骤

 4. 边界值方法

边界值思想设计测试用例步骤

 5. 判定表方法

判定表思想设计测试用例步骤 

6. 正交表法

正交表思想设计测试用例步骤 

7. 场景设计法 

---

在熟悉了测试的流程后，就可以开始来设计测试用例了。

一. 测试用例的基本要素  

测试用例可以提高测试效率，节省测试时间；测试用例也是进行自动化测试的前提；

测试用例的基本要素主要包括：测试环境，测试数据，操作步骤，预期结果等。 

应注意：测试用例的基本要素不包括执行结果，因为执行结果是需要执行完测试用例才能知道的，没有测试用例，自然就还没有执行结果。 

二. 测试用例的设计方法

1. 测试用例设计的万能公式

可以主要围绕以下几个方面来进行：功能，性能，界面，易用，兼容，安全，网络，中断等；

功能

物体方面：主要描述这个物体可以干什么；

软件方面：主要描述软件实现的功能特性，拿着软件可以实现什么操作；

性能

物体方面：可以描述物体的使用寿命；

软件方面：可以描述软件的响应时间，并发数，CPU占用率等； 

界面

物体方面：可以描述物体的外表，材质，大小，容量等；

软件方面： 软件的界面，字体大小颜色，页面的整体布局；

易用

物体方面：可以从人性化的方面去思考，例如杯子的把柄易于我们放取；

软件方面：操作简单，使用流畅；

兼容

物体方面：考虑物体除了本质的功能外，还有什么其他的功能；

软件方面： 可以考虑软件兼容 操作系统的不同版本，设备的不同型号，浏览器的不同版本。

安全

物体方面：考虑物体的材质是否有毒，会不会对人体健康造成损害；

软件方面：考虑到软件是否有信息泄露，漏洞出现，是否有有毒脚本入侵，以及密码是否有加密保存，加密传输，还有对于权限的控制，sql注入等；

网络

主要考虑软件：是否适用于 2G~5G，弱网，WiFi； 

水杯测试用例

此处根据万能公式对于 水杯 做出一个测试用例： 

 2. 基于需求的设计方法

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求， 在分析测试需求时，一般分为功能测试需求和非功能测试需求， 验证需求是否正确、完整。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测 试点或者测试项，然后根据每一个测试点进行测试用例的设计 ；

整体过程就是：需求文档 -> 掌握需求 -> 基于需求设计测试用例；

而基于需求的设计方法，是一种头脑风暴式的，只针对需求来分析，对产品进行一个大概的测试用例的设计。还不够全面，因此就需要到后面一些具体的设计测试用例的方法。

邮箱注册测试用例 

此处以 邮箱注册 为例，写一个基于需求的测试用例设计方法：

 3. 等价类方法

依据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类和无效等价类

有效等价类：

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

无效等价类： 

根据需求说明书，不满足用户需求的输入集合；

例如以下这种情况：6~15位的用户名就属于有效等价类，小于6位和大于15位的就属于无效等价类

 等价类思想设计测试用例步骤

1. 充分理解需求；

2. 划分有效等价类和无效等价类；

3. 从有效等价类中抽取一个数据进行设计测试用例，从无效等价类中抽取一个数据进行设计测试用例；

 4. 边界值方法

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

一般会涉及到三个点：

上点：边界上的点；

内点：边界内的点；

离点：边界值附近的一个点（闭区间区间外距离上点最近的一个点，开区间区间内距离上点最近的点） 

边界值思想设计测试用例步骤

1. 充分理解需求；

2. 找边界点；

3. 针对边界点设计测试用例； 

 5. 判定表方法

 判定表是一种表达逻辑判断的工具，可以把判定表对应到每一个测试用例；

 其中的关系包括：与或非，恒等(条件为真，结果一定为真)；

判定表思想设计测试用例步骤 

1. 分析所有可能的输入和可能的输出；

2. 找出输入和输出之间的对应关系；

3. 设计判定表；

4. 把判定表对应到每一个测试用例； 

例如："淘宝618活动中，订单已提交，订单合计金额大于300元或有红包的，就有优惠"

输入：订单已提交，订单金额大于300；有红包 ；输出：优惠，不优惠；

设计判定表： 

6. 正交表法

在使用前面的判定表设计测试用例，如果输入条件比较多，此时来写测试用例就会很容易出现差错。因此正交表就是用尽可能少的用例来去覆盖尽可能多的场景。

名词：

   因素：此处需求的输入变量；

   水平：变量的取值；

性质：

1. 每一列中，各个数字出现的次数一样多；

2. 任何两列中的各有序数对出现的次数都一样多；例如：

 

正交表思想设计测试用例步骤 

1. 充分理解需求；

2. 确认因素和水平；

3. 作出正交表；

4. 将正交表转换为测试用例；

5. (有时候正交表转换的测试用例不一定完整，还需要加以补充)；

此处以注册为例进行讲解：姓名，邮箱，密码，确认密码，验证码必须全部输入，才能进行注册。

因素：姓名，邮箱，密码，确认密码，验证码；  水平：填写，不填写；

此处借助 allpairs 画正交表：

1. 先画出表格，将水平和因素填写入表格中，并复制到 txt 文件中：

 2. 将文件放置与 allpair.exe 相同路径下：

3. 进入cmd中，进入该路径中，执行命令：allpairs.exe 文件名 > 生成文件名

 4. 执行完后，就会得到对应的 111_result.txt 文件，文件中就有了正交表：

正交表中的 ~填写 表示这个值可以是填写也可以是不填写。

使用allpairs生成的内容，有时候不一定完整。因此还需要补充一些其他的测试用例，例如上述的正交表中，就没有一种情况是：都不填写的，所以就应该补充进去。此时一个横行就可以是一个测试用例，然后，根据这些测试用例进行测试。

allpairs的安装路径：Allpairs - Satisfice, Inc. 

7. 场景设计法 

相当于是使用一个软件的时候，对应的一个流程。

主要有两个概念：

主事件流：可以理解为用户正常使用的一些场景；

次事件流：可以理解为用户使用时出现的异常场景；

类比于 ATM取款 的场景： 

将每个事件串起来也就形成了一个场景，也就是一个测试用例；

通常情况下，需要把用户经常用到的功能模块串联到一起进行测试；