软件测试用例的设计以及分类_用例类型

---

测试用例设计

1.测试用例

设计一个测试用例可以采取以下几个方面来进行设计

• 功能测试
• 界面测试
• 性能测试
• 兼容性测试
• 易用性测试
• 安全测试

假设使用水杯测试用例和注册登录测试用例做简单对比

2.设计测试用例的方法

基于需求进行测试用例的设计：需求分析、需求有哪些功能、设计测试点、设计测试用例

假设软件需求是：提示用户名为6到15个文字。

我们可以穷举测试用例，从0到16开始穷举，如果测试通过，则认为功能符合需求要求。但如果姓名长度是6到200位，该如何设计测试用例呢？显然穷举法是不行的。

1) 等价类

等价类的思想是：根据需求将输入分成几个若干个等价类，从等价类中选取一个测试用例进行测试，如果测试通过则认为该测试用例所在的等价类是通过的。

等价类就是分区分块，使用较少的测试用例到到符合的系统测试覆盖。

等价类又划分为有效等价类和无效等价类

• 有效等价类：针对需求来说是有效且有意义的数据构成的集合
• 无效等价类：针对需求来说是无效且没有意义的数据构成的集合

根据等价类划分测试用例的步骤：

1. 确认有效等价类和无效等价类
2. 编写测试用例

需求：用户长度为6~200位，应该如何设计测试用例。

1. 确定有效等价类和无效等价类
   • 有效等价类：6~200
   • 无效等价类：小于6大于200
2. 编写测试用例

又或者是针对密码为6到20位来设计无效等价类？

• 长度设计：小于6或者大于20
• 根据类型：数字、字符串、特殊字符等等

2) 边界值

边界值法通常是对等价类的补充

设计边界值的测试用例时需要加上：边界值+次边界值

假设有某一个需求：活动截止的日期是5月23日(acEndtime)

时间的次边界值就得设置为：00:00:00和23:59:58

比如1的次边界值为：0和2

-1的次边界值为：-2和0

3) 判定表法

适用场景：针对不同的输入条件之间的组合对应不同的输出结果

判定表法是一种逻辑判断工具

假设有需求：订单已提交，订单合计金额大于300或者订单有红包，则认为该订单属于有优惠的订单，否则属于没有优惠的订单。

判定表设计测试用例的步骤：

1. 找出输入条件和输出条件

2. 找出输入条件和输出条件之间的关系

3. 画出判定表

4. 根据判定表编写测试用例

5. 针对上述去求确定输入条件和输出条件

   • 输入条件：金额大于300(A)、有红包(B)、订单已提交©
   • 输入条件：1有优惠、2无优惠

6. 找出输入条件和输入条件之间的关系

   AC	BC	ABC	C	A	B	AB 非ABC
   1	1	1	2	2	2	2	2
   1
   2

7. 画判定表

4. 根据判定表来编写测试用例

   • 有红包、金额不大于300、订单已提交，结果为有优惠
   • 无红包、金额大于300、订单已提交。结果为有优惠
   • 有红包、金额大于300、订单已提交，结果为有优惠
   • 无红包、金额不大于300，订单已提交，结果为无优惠
   • 无红包、金额大于300、订单未提交，结果为无优惠
   • 有红包、金额不大于300、订单未提交、结果为无优惠
   • 有红包、金额大于300、订单未提交，结果为无优惠
   • 无红包、金额不大于300、订单未提交，结果为无优惠

有一个步骤叫根据因果图画判定表法，因为因果图画判定表很多余，而且因果图实际在设计测试用例的时候并没有什么意义，而且抽象。

4) 正交法

要使用正交法就需要用到正交表：

• 因素数：输入条件
• 水平数：输入条件对应的结果（不是输出条件）

正交表的特性：

1. 在每一列中，不同的数字出现的次数相等
2. 任意两列中数字的排列方式齐全且均衡

需求：用户注册信息填写（姓名、电子邮箱、密码、确认密码、验证码）

• 因素数：姓名、电子邮箱、密码、确认密码、验证码
• 水平数：填写、不填写

通过正交法设计测试用例的步骤

1. 找到因素数和水平数
2. 用allpartis工具来生成正交表
3. 根据正交表来编写测试用例
4. 补充测试用例

通过allpartis来生成测试用例

1. 将因素数和水平数写入Excel

2. allparis目录下创建一个新的文本文件，复制Excel中的因素数和水平数直接粘贴到文本中，直接保存

使用alparis命令来生成正交表文件

4. 最后完成

4. 再根据正交表编写测试用例

注意，使用allpairs生成的正交表可能和实际的正交表文件可能不一样，但不影响我们设计测试用例

• 姓名、电子邮箱、密码、确认密码、验证码全部填写
• 填写姓名，其它电子邮箱、密码、确认密码、验证全都不填写
• 不填写姓名，填写电子邮箱、不填写密码、填写确认密码、不填写验证码
• 不填写姓名、不填写电子邮箱、填写密码、不填写确认密码、填写验证码
• 填写姓名、填写电子邮箱、填写密码、不填写确认密码、不填写验证码
• 填写姓名、不填写电子邮箱、不填写密码、填写去认密码、填写验证码

5) 场景设计法

场景设计法主要分为：基本事件流和多个备用事件流

以ATM取款为例子

最基本的事件流：

1. 插卡
2. 输入密码
3. 选择对应业务
4. 执行对应业务
5. 出钞票

备用事件流：

• 密码输入次数？
• 取款金额限制？
• 机器故障？

编写测试用例：

1. 基本事件流
   • 插入银行卡
   • 输入正确的秘密
   • 选择取款业务
   • 选择小于5W，且金额是100的倍数
   • 等待出钞(取钞票)
   • 最后出卡
2. 备用事件流
   • 插入银行卡，第一密码输入错误，第二次输入正确，选择了小于5W的金额且是100的倍数，等待出钞取钞，最后退卡
   • 插入银行卡，前两次密码输入错误，第三次输入正确，选择取款，选择了小于5W的金额且是100的倍数，等待取钞票，然后退卡。
   • 等类似测试用例…

6) 错误猜测法

这个设计测试用例的方法其实是依据测试人员的工作经验和积累。

3. 测试分类

1) 按测试对象划分

1. 界面测试

   • 界面测试也叫做UI测试，界面测试参考UI设计图。
   • 非软件类界面测试：颜色、大小、材质、整体是否美观
   • 软件类界面测试：输入框、按钮、文字、图片的尺寸、颜色、形状、整体适配、清晰度等
   • 验证整个页面的排版是否合理，图片展示是否符合用户需求

2. 可靠性测试

   • 可靠性一般是指程序正常向用户提供软件服务的时间占总时间的百分比

• 可靠性$=$正常运行时间$/$(正常运行时间+非正常运行时间)$\ast 100$
  • 可用性指标一般要求达到4个或者5个$9$，比如$99.99$或者$99.999$
  • 系统的非正常运行时间可能是由硬件、软件、网络故障或任何其它因素照成的，它们可能让系统停止工作

3. 容错性测试

   • 容错性测试是指系统能够处理异常，用户的错误而不至于系统奔溃，从而能够提高系统的可用性
   • 比如说输入异常数据或者进行一些异常的操作，如果系统的容错性好，系统就会内部过滤掉，而不会导致系统出错或者奔溃
   • 或者通过各种手段，让软件强制性的发生故障，然后检验系统的数据是否丢失，系统和数据是否能够快速的恢复

4. 可靠性和容错性的区别？

   • 假设有一个服务器集群有多台服务器
   • 突然有一台服务宕机了，但没有影响用户的使用，这就是集群容错性好的表现
   • 同样这台宕机的服务器就是不可靠的表现

5. 文档测试

   • 通常来说文档测试是在需求评审的时候由测试人员进行需求分析
   • 文档测试关注的是文档的正确性、完整性、一致性、易用性

6. 兼容性测试

   • 浏览器的兼容性(Chrome、Firefox等)
   • 平台兼容性(windows、Linux、Mac)
   • 自身兼容性：浏览器版本(Chrome 100~113)，多个版本的基本功能都是可以使用的
   • 其它平台：安卓手机/iphone 的显示功能是否正常

7. 安装卸载测试

   • 软件的不同的安装和卸载方式
   • 在不同的系统、版本下安装
   • 安装或卸载是否可以暂停或取消
   • 安装空间不足的时候是否有提示
   • 是否可以正常卸载和支持其它卸载方式
   • 卸载安装是系统出现问题，软件是否可以正常应对，比如死机、断电。

8. 易用性测试

   • 软件需要具备简单易上手的属性

9. 安全测试

   • SQL注入
   • XSS漏洞
   • 越权(垂直越权、水平越权)

10. 性能测试

    • 资源泄露
    • 若果对文件进行操作忘记close就会造成文件资源泄露
    • 资源瓶颈(CPU、内存、网络、线程死锁等)

11. 内存泄露测试

    • 比如分配完内存未回收，或者程序写法有问题导致内存泄露
    • 可以通过工具检测：静态扫描工具
    • 人工检查：查看代码来查找

2) 按是否查看代码划分

黑盒测试

黑盒测试，把代码看成一个黑匣子，不关心代码的内部结构和内部特性，只关心软件的功能是否符合产品规格说明书的需求。黑盒测试又可以称为数据驱动测试或者功能测试。

常见的黑盒测试设计测试用例的方法：等价类、边界值、判定表、正交法、场景法、错误猜测法等

白盒测试

白盒测试称为结果测试或者逻辑驱动测试。白盒测试的方法，检测程序的内部实现、检查程序的运行状态是否符合预期。

常见的白盒测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆、路径覆盖等

灰盒测试

灰盒测试介于两者之间，既要关心内部结构和内部特性，还要关心功能是否符合要求。灰盒测试通常用在集成测试中。

为什么不直接使用灰盒测试

灰盒测试没有白盒测试详细、完整，黑盒测试是覆盖产品功能范围最广的测试。所以灰盒测试是不能取代黑盒测试和白盒测试。但是黑盒测试可以去掉灰盒测试，但是并不建议这么做，因为这样做需要很大的代码量，需要设计非常非常多的测试用例。

常见的测试方法有哪些？哪些方法用的多？

常见的有白盒测试和黑盒测试，在工作中需要根据实际情况来结合白盒测试和黑盒测试，通常来说测试人员使用黑盒测试方法相对要多一点。

3) 按开发阶段划分

单元测试

单元测试是针对系统最小单元进行测试(最小单元是人为规定的)

集成测试

完成单元测试后，将模块和模块之间进行集成测试，按照功能来进行测试

冒烟测试

冒烟测试由测试人员来进行执行，检查系统主要功能和主要的流程是否正常，评估软件/系统是否具备可测试的条件/可测试的标准。如果冒烟测试通过则测试人员进行正式的系统测试，如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。

系统测试

集成测试完成后，测试人员准备项目环境，将程序看成一个整体，对程序/系统进行系统测试，保证系统功能符合产品规格说明书的要求。其实冒烟测试和回归测试都是属于系统测试的一部分。

回归测试

对历史版本、历史功能进行测试，保证功能是符合要求的。

随着功能迭代越来越多，版本越来越多，回归测试的难度相对来说大一些，需要借助自动化测试来进行回归测试。

---