[测开篇]设计测试用例的方法如何正确描述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 等价类，边界值
灰盒测试

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

2. 按照开发阶段划分

特点：越往底层走，测试效率越高，越往低走定位问题越容易，越往底层走测试独立性越高，耦合性变低。

单元测试阶段： 指的是对软件组成的最小单元进行测试

集成测试阶段： 按照一定的逻辑和策略把单元模块组合在一起，形成一个具体完整功能的大模块

测试阶段： 单元测试
测试方法： 灰盒测试
测试人员： 黑盒测试工程师，白盒测试工程师
测试依据： 概要设计文档
测试内容： 模块功能的正确性，组成模块的单元之间的接口测试，全局数据结构测试，单个模块的功能缺陷对整个模块的影响。

系统测试阶段： 对软件系统进行全面的功能的非功能测试

测试阶段：集成测试以后
测试对象：整个软件系统
测试方法：黑盒测试
测试人员：黑盒测试工程师
测试依据:需求设计文档
测试内容：系统的功能，界面，可靠性，容错性，易用性，可移植性，兼容性，安全性，性能，安装卸载

这里我们有必要说明一下冒烟测试：冒烟测试是由测试人员来执行，检验系统只要功能和主要流程是否正常，评估软件系统是否具备可测试条件，可测试标准。

回归测试:当系统引入新代码的时候，测试人员往往需要验证新的代码对旧的功能的影响。

验收测试: 软件在上线之前最后一次的测试，也称为交付测试

测试阶段：系统测试之后
测试对象：整个软件系统
测试依据：用户需求
测试人员：用户
测试方法：黑盒测试
测试内容：同系统测试，文档测试，可用性分析文档，需求设计文档，软件设计文档，软件开发文档，功能手册

3.按照实施组织划分

α测试: 在β测试之前，把用户或者非测试和开发的人青岛开发现进行检测

测试环境：开发现场
测试人员：非开发和测试的人

β测试： 让实际用户在实际使用环境中进行测试，测试完成之后对问题进行同一汇总反馈

α测试和β测试的区别：测试环境不同，测试时间集中长度不同，α测试优先于β测试

第三方测试： 是软件第三方测评机构，按照软件行业的标准规范对软件进行测试

4.按照代码是否运行划分

静态测试： 不运行代码，通过检查代码风格，格式是否符合公司标准规范，检查代码的逻辑结构是否满足需求要实现的功能。

动态测试: 运行代码，给程序响应的输入，看是否得到期待的结果。

5. 按照是否手工划分

手工测试： 按照测试用例，手工去测试系统的功能

缺点：量大，容易出错，效率低，有些极端情况无法测试到
优点：进行探索性测试比较灵活

自动化测试： 把手工测试用例转化为自动化测试，机器按照人的设定好预设条件运行，这些预设包括正常的，异常的，去检查软件系统有没有符合设定的条件。

6. 按照地域划分

软件国际化： 进行软件设计和开发的时候，使用一种工程技术，使得软件在转化为不同的国家语言的时候，可以不用修改源码，适应不同的语言，不同国家人民的风俗习惯

国际化软件测试：外观上开界面功能没缺失，正常使用，是否适应这个国家人的使用习惯，文字日期，度量单位，货币，不同分辨率下，软件的正常使用

软件本地化： 具体到每个国家

Bug

1.衡量是否为缺陷的标准：

和需求规格说明书上不符。这里是少功能
功能实现错误
多功能
隐形功能错误
不易使用

2.缺陷产生的原因：

需求阶段：需求描述不易理解，有分歧，错误等。
设计阶段：设计文档存在错误或者缺陷
编码阶段：代码出现错误
运行阶段：软硬件系统本身故障导致软件运行失败

3.缺陷描述的核心内容：

缺陷的标题：描述缺陷的核心问题
缺陷的预置条件：缺陷产生的前提
缺陷的复现步骤：复现缺陷的过程
缺陷的预期结果：希望得到的结果
缺陷的实际结果：实际得到的结果
缺陷的必要附件：图片，日志等信息(证据)

4.提交Bug的要素

缺陷报告编号： 缺陷的唯一性标志
严重程度：严重(主功能)，一般(次要功能)，微小(易用性，界面)，建议(建议性问题)
缺陷优先级： Priority：24小时内解决 Priority1：发布前必须修复。Prioity2：可以在写一个版本修复
Bug类型： 代码错误，兼容性错误，设计缺陷，性能问题
缺陷状态： New 新建 Open 打开 Closed 关闭 Postponed 延期

5.缺陷类型

功能缺陷，界面错误，兼容新，数据，易用性，改进建议，架构

6.如何区分是前端Bug还是后端Bug

在写的web项目（仅设计到前端代码和后端代码）在测试的时候发现有个字段展示的数据不正确，首先通过在页面上使用F12开发者工具查看接口的请求参数和返回值是否正确，当时发现接口返回值是正确的，所以判定是前端代码写的有问题。如果是接口返回值就是错误的，那可能是代码逻辑出现了问题，需要对后端代码进行调试。

7.管理Bug的工具

这里我们可以通过禅道和jire 进行Bug管理 https://78945.chandao.net/

8.使用execl管理Bug

在这里我们使用execl表格对Bug进行管理

现在利用的是我们以上的测试用例，执行相关程序之后，得到的对缺陷的描述