[测开篇]设计测试用例的方法如何正确描述Bug

文章目录

- 为什么测试人员要写测试用例？
- 怎样设计测试用例？
- - （总的方面）1.基于需求设计测试用例
  - （总的方面） 2.页面
  - （总的方面） 3.非功能性测试
  - （具体方面） 4.1 等价类解决穷举问题
  - （具体方面） 4.2 边界值法解决边界限制问题
  - （具体方面）4.3使用多条件依赖问题
  - （具体方面） 4.4 解决业务测试点覆盖问题
  - （具体方面） 4.5 错误猜测法
- 练习
- 测试分类介绍(除功能测试之外)：
- - 1.按照是否查看代码划分
  - 2. 按照开发阶段划分
  - 3.按照实施组织划分
  - 4.按照代码是否运行划分
  - 5. 按照是否手工划分
  - 6. 按照地域划分
- Bug
- - 1.衡量是否为缺陷的标准：
  - 2.缺陷产生的原因：
  - 3.缺陷描述的核心内容：
  - 4.提交Bug的要素
  - 5.缺陷类型
  - 6.如何区分是前端Bug还是后端Bug
  - 7.管理Bug的工具
  - 8.使用execl管理Bug

什么是测试用例？

测试用例是向被测试系统发起的一组集合，也就是执行测试的文档。

测试用例书写的八大要素：
1.测试编号：项目+模块+编号
2.用例标题：预期结果+操作步骤
3.模块/项目：所属项目或模块
4.前置条件：要执行此条用例，有哪些前置操作
5.优先级：表示用例的重要性或者影响力P0 ~ P4(P0最高)
6.测试步骤：描述测试步骤
7.测试数据:操作的数据，没有话可以为空
8.预期结果：期望达到的结果

为什么测试人员要写测试用例？

测试用例是测试执行的依据。
测试用例可以复用，在进行回归测试的时候不用重新编写用例。
测试用例可以衡量需求的覆盖率
后人可以借鉴
手工测试用例是自动化测试的依据
防止漏测
实时测试的标准

怎样设计测试用例？

（总的方面）1.基于需求设计测试用例

需求是测试人员进行测试的依据
测试人员分析需求，验证需求的正确性和合理性，无二义性。
从需求当中提取测试项。根据测试项进行进一步的细分，提取测试点，编写测试用例

从界面开始进行测试(符合UI设计稿和原型图)
验证软件的功能，把业务相关的功能串起来进行测试，不能光关注每一个孤立的功能
一个功能不同的输入和相应的不同的输出
功能之间的交互性（同一个系统不同的角色之间的交互）
异常功能的测试
功能用到的算法验证
从易用性，兼容性等几个方面考虑

那么最终总结出来一种模型（质量模型）

针对任何的软件和硬件，测试要覆盖的方面：

功能性
兼容性
可靠性
可维护性
性能效率
易用性
信息安全
可移植性

重点：功能，兼容，性能，易用，安全

（总的方面） 2.页面

从上到下，从左到右依次去分析碰到的测试点

（总的方面） 3.非功能性测试

易用性，兼容性，性能，安全，可移植性，可靠性，可维护性
非功能性测试就是测试在软件本身有的功能之上做的一些限制。

（具体方面） 4.1 等价类解决穷举问题

方法使用等价类实现

如果此时让我们对这个QQ登录写出测试用例。那么我们应该首先想到的就是，找到一些数据填写账号和密码。那么如果此时有大量的测试数据，我们要一个一个的测试吗？

其实不然，我们要对这些测试数据做出分类，那么我们在每个分类中选出一两个此时数据，填写到账号栏和密码栏验证QQ 登录即可。

这就相当于我们在衣柜中，把春夏秋冬的衣服归类一样。

分类：

有效等价类：在所有有效数据集合中，取一个即可
无效等价类：在所有无效数据集合中，取一个即可

步骤：

明确测试需求
确定有效和无效等价类
提取数据编写测试用例

测试案例： 此时有一个登录场景，只需要输入QQ号，QQ号限定是8位自然数，方可登录成功

测试点：在这里插入图片描述

测试用例：
在这里插入图片描述

测试案例

1.区号：空或者是三位数字

2.前缀码：每0且非1开头的三位数字

3.后缀码四位数字

合格

确定有效和无效等价类
在这里插入图片描述

2个合格测试用例，8条不合格测试用例
在这里插入图片描述

等价类使用场景：

针对：需要有大量的数据测试输入，当时没法穷举测试的地方

如：输入框，下拉列表，单选复选框

经典代表：页面级的输入框类测试

（具体方面） 4.2 边界值法解决边界限制问题

方法：边界值设计方法

所以说我们如果要对这个范围做测试的话，那么就要测试 -100 -99 99 100 50

案例一：

首先明确需求： 标题长度大于0，小于等于30个字符

明确有效等价类和无效等价类：

有效大于0小于等于30长度的字符
等于0，大于30长度的字符

边界值： 有效：1个，30个无效：0个，31个
在这里插入图片描述

测试用例： 在这里插入图片描述

使用场景：

常见词语描述：大小，尺寸，重量，最大，最小，至多，至少等修饰词语

典型代表：有边界范围的输入框类测试

**提示：**边界值可以覆盖等价类的长度，但是无法覆盖类型，所以设计用例是，必须两者结合

（具体方面）4.3使用多条件依赖问题

方法：判定表法

定义：是一种以表格形式表达多条件逻辑判断的工具

组成：

条件桩：列出问题中的所有条件，列出条件次序无关紧要

动作桩：列出问题中可能采取的操作，操作的排序没有约束

条件项：列出条件对应的取值，所有可能情况的真假值

动作项：列出条件项的，个中取值情况下应该采取的动作结果
在这里插入图片描述

规则：

判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方中规则

步骤：

明确需求
画出判定表
- 列出条件桩和动作桩
- 填写条件项，对条件进行全组合
- 根据条件项的组合确定动作项
- 简化，合并相似规则(有相同的动作)

3.根据规则编写测试用例

案例一：

需求：

订购单检查

如果金额大于500，有未过期，则发出批准单的提货单
如果金额大于500，但是过期了，则不发批准单与提货单
如果金额小于等于500，则不论是否过期都发出批准单和提货单
在过期的情况下不论金额大小还需要发出通知单

画判定表：
在这里插入图片描述

根据判定表，写测试用例
在这里插入图片描述

案例二：

需求：

输入的第一列字符必须是A或B
第二列字符必须是一个数字
如果第一列字符不正确，则给出信息L
如果是第二列字符不正确，则给出信息M
如果两列字符输入正确，则修改文件成功

画出判定表：
在这里插入图片描述

根据判定表写出测试用例：
在这里插入图片描述

使用场景：

有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖关系
判定表一般适用于条件组合数量较少的情况(比如4个条件一下)
提示：如果碰到项目中多条件组合大于4个相互依赖，可以用正交法和因果图法来实现

（具体方面） 4.4 解决业务测试点覆盖问题

那么此时就可以使用场景法，就是用我们的流程图来梳理每个条件

根据流程图写测试用例
在这里插入图片描述

（具体方面） 4.5 错误猜测法

定义：通常经验推测系统可能出现的问题

思想：根据经验列举出可能出现的问题的清单，根据清单分析问题可能原因，推测发现缺陷。

场景：时间紧，任务中，根据之前项目类似经验找出出错的模块重点测试

时间宽裕通过该方法列出之前问题较多的模块再次测试

就如用户在输入密码的时候，在密码的前面和后面都输入了大量的空格等

练习

单模块测试：
在这里插入图片描述

测试点：
在这里插入图片描述

测试用例：ps 我们这里仅仅对功能测试用例作以描述
在这里插入图片描述

测试分类介绍(除功能测试之外)：

易用性测试: 软件需求具备简单易上手的属性

安装卸载测试：移动端测试很容易一楼掉的此时

安全测试:SQL注入，XSS漏洞，越权问题

文档测试: 通常来说是在需求评审是测试人员需要进行需求分析(文档测试)

兼容性测试：平台兼容，不同平台也有版本不同

可靠性测试：正常运行的时间除以（正常运行的时间 + 非正常运行的时间） * 100％可用性指标一般要求达到4个或者5个9 即 99.99% 或者 99.999%

容错性测试：系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。

**性能测试:**性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试

压力测试：。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

负载测试 通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况

强度测试： 强度测试检查程序对异常情况的抵抗能力；是检查系统在极限状态下运行的时候性能下降的幅度是否在允许的范围内。

容量测试： 容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。

1.按照是否查看代码划分

黑盒测试： 不去关心代码内部实现的逻辑结构，不去查看代码，只关心软件功能的外部的输入和输出是否满足用户需求相当于把软件的内部实现给屏蔽掉了。

站在用户的角度设计测试用例，容易培养产品思维。设计测试用例是根据软件需求设计的，不容易遗漏需求

黑盒测试的方法：等价类，边界值，场景法，判定表法，因果图法，错误猜测法，正交法。
白盒测试： 查看代码是否规范，代码风格是否和公司设计一致，分析代码的逻辑结构，对代码进行测试，看代码是否实现了需求

我们通常说的单元测试，就是白盒测试的一种，这个通常是由开发人员实施的。

白盒测试的方法：语句覆盖，路径覆盖，逻辑覆盖，判定覆盖，条件覆盖，判定组合覆盖，判定和条件组合覆盖，条件和条件组合覆盖

路径覆盖有；if else switch case try catch finally 等价类，边界值
灰盒测试

即关心软件功能的输入和输出，也关心软件内部程序的实现。