0


测试之Bug与用例【创建Bug、Bug级别、Bug生命周期、测试用例的万能公式、设计测试用例具体方法】

文章目录

1. 如何创建Bug

提 Bug 就是要开发人员进行问题的解决 (1. 尝试复现 2. 代码修复)

创建 Bug 的要素:问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3mmA5kvZ-1673571841366)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1672906127476.png)]

2. Bug的级别

Bug 存在不同的严重级别

不同的 Bug 等级,惩罚机制不一样

不同的 Bug 等级,也跟开发人员的开发质量能力有直接关系

严重级别:崩溃、严重、一般、次要(具体的级别数量,要看当前公司的规范)

  1. Blocker(崩溃):阻塞开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,数据库连接错 误,主要功能丧失,基本模块缺失等问题
  2. Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等
  3. Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性
  4. Minor(次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等

3. Bug的生命周期

测试人员在执行测试的过程中,如有发现 Bug,需要在对应的 Bug 管理平台来创建 Bug

  • New:测试人员创建了一个 Bug
  • Open:开发人员要去确认是否是 Bug,是 Bug 状态就改为 Open,不是 Bug 就拒绝 (rejected)
  • Fixed:开发人员在修复完成之后将 Bug 状态改为 fixed
  • Rejected:如果认为不是 Bug,则拒绝修改
  • Delay:确认是 Bug 之后,如果 Bug 优先级比较低且开发人员不能立即修复 Bug,状态改为 delay
  • Closed:Bug 确认修复完成,测试人员将 Bug 改为 closed
  • Reopen:Bug 确认修复未完成,测试人员将 Bug 状态改为 Reopen

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Nf2IlmjU-1673571841367)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1672907247263.png)]

4. 面试题:跟开发产生争执怎么办

  1. 多反思自己,是不是 Bug 创建的时候描述不太清楚
  2. 开发人员对 Bug 级别不认可,Bug 定级一定要有理有据,测试人员需要明确企业 Bug 定级规范,拿着规范和开发人员沟通,为什么这样定级
  3. 合理友好的进行沟通,站在用户的角度反问,如果你是用户,你能接受这样的功能吗,提 Bug 必定会增加开发人员的工作量,小问题不想解决
  4. 不仅能够发现问题,最好也能够提出解决方案给开发参考
  5. 如果确实是 Bug,友好沟通已经不能解决问题了,那就召开 Bug 评审,需要有相关的代表来参加:产品代表、开发代表、测试代表等 (1. 如何解决 Bug 2. 如何预防类似的 Bug 再发生)

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

假如有一个水杯,如何针对这个水杯来设计测试用例

水杯是否保温、能够盛放多少毫升的水、水杯是否漏水、是否易于携带、有没有问题显示功能、是否抗衰…

如果仅仅通过简单直接的思考来设计测试用例,用例是比较少的

原则上用例的设计不仅要考虑其实现了其应该实现的,还要考虑其未实现其不应该实现的

那么测试用例是否是设计的越多越好?

工作中,测试用例能够更多的覆盖项目测试为最好

面试的时候测试用例设计的越多越好,主要就是面试时考察的是设计测试用例的能力,思维发散能力
万能公式:功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全测试

功能测试:可能来自于需求文档,也可能来自生活经验

性能测试:功能没有问题不代表性能一定是好的,性能往往表现在一些极端情况下

界面测试:颜色、形状、大小、材质、文字、输入框、图片、下拉框… 所有可以看到的元素

兼容性测试:浏览器的兼容性、版本兼容性、系统兼容性、数据兼容性

易用性测试:软件是否具有简单易上手的属性

安全性测试:密码是否加密,数据库里是否对隐私数据加密、SQL注入

使用万能公式对水杯设计测试用例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yPUaaYsz-1673572074413)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1672909323421.png)]

兼容性测试中需要注意,不同的浏览器,不同的版本可能会有非常多,难道所有的版本和浏览器都需要进行测试吗,我们选型的标准是什么

  1. 大部分用户使用的
  2. 在工作中是有数据后台可以检测到大部分用户使用到的浏览器/版本/手机型号… 后台可以将这些数据进行检测和管理起来,就可以参考数据管理平台给出的数据选型

6. 设计测试用例的具体方法

6.1 等价类

用户的密码为 6~12 位,测试的时候使用到的测试数据是什么, 10位?8位?

如果使用穷举法 6,7,8,9…12 全部都测试一遍,这样可以,但是如果把密码位数改为 6~1000位,那么穷举法就不行了

可以根据等价类,来划分测试数据

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

等价类的划分

  1. 有效等价类:针对需求文档的要求是有意义的集合 (6~12位密码)
  2. 无效等价类:针对需求文档的要求是没有意义的集合 (小于6位,大于12位的密码)

步骤

  1. 确认有效等价类和无效等价类
  2. 编写测试用例
  1. 输入长度为 6~12 位的密码,具体是 10 位
  2. 输入长度为小于 6 位的密码,具体是 1 位
  3. 输入长度为大于 12 位的密码,具体是 20 位

6.2 边界类

密码长度为 6~12 位,有效边界值为 6、18 ,无效边界值 5、19

边界值指的是 有效边界 + 无效边界

例如:成绩大于 60 可以获奖,无效边界 60,有效边界 61

数字为浮点数,6~10 有效边界值 无效边界值 到底是单精度浮点型还是双精度浮点型

6.3 判定表

使用场景:输入条件的组合对应不同的结果

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

案例:假设业务单据的处理规则为:“淘宝618活动,订单已提交,订单合计金额大于300元或有红包,则进行优惠,否则不优惠”。

1. 确认输入条件和输出条件

输入条件:红包(A)、金额大于300元(B)、订单已提交©

输出条件:有优惠(1)、无优惠(2)

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

先确定输出条件之间的可能组合关系:A、B、C、AB、AC、BC、ABC、null

输出条件:A=2、B=2、C=2、AB=2、AC=1、BC=1、ABC=1、null=2

3. 画判断表

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BPKSBGSD-1673572074413)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673151115073.png)]

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

  1. 有红包,订单金额小于300,不提交订单,则该订单为无优惠订单
  2. 无红包,订单金额大于300,不提交订单,则该订单为无优惠订单
  3. 无红包,订单金额小于300,提交订单,则该订单为无优惠订单
  4. 有红包,订单金额大于300,不提交订单,则该订单为无优惠订单
  5. 有红包,订单金额小于300,提交订单,则该订单为有优惠订单
  6. 无红包,订单金额大于300,提交订单,则该订单为有优惠订单
  7. 有红包,订单金额大于300,提交订单,则该订单为有优惠订单
  8. 无红包,订单金额小于300,不提交订单,则该订单为无优惠订单

因果图法相比于判定表法步骤差不多,只不过因果图法中多了一步叫做 “画因果图”

6.4 正交法(allparis)

正交法用的比较少

正交试验设计法指从大量的试验中挑选出适量的、有代表性的点,依据 “正交表” 从而合理的设计出测试用例

地图软件,从出发地到目的地需要耗时多久

因素:下班的高峰期(水平:是高峰期、不是高峰期)、今天不限号、天气、所经路段红灯时间长、地段(城市路段/郊区)、道路施工、行驶人的驾车技能好坏、车况

如果使用判定表,那么当输入条件过多时,出现的情况太多了,那么判定表就不太合适了,这就可以使用正交表

正交表的表示L4(2^3),4代表的是4组实验(4个测试用例),3代表的因素数(3个输入条件),2代表的每个因素数对应的水平数(输入条件的可能选项)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3HofoQQw-1673572074414)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673229073286.png)]

根据正交表设计测试用例的步骤:

  1. 找出因素数(输入条件)和水平数(输入条件的可能选项)
  2. 生成正交表(需要借助生成正交表的工具:allparis)
  3. 根据正交表来编写测试用例
  4. 补充可能存在遗漏但是非常重要的测试用例

案例:[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KqY7cL8r-1673572074415)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673250320800.png)]

1. 找出因素 和 水平

因素:姓名、电子邮箱、密码、确认密码、验证码

水平:填写、不填写

2. 使用 allparis 生成正交表

(1)将水平和因素写入 Excel

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3ihhBHto-1673572074415)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673251758923.png)]

(2)allparis 同级目录中创建一个新的 txt 文件(xxx.txt),复制 Excel 中的因素和水平,粘贴到 xxx.txt 文本中,保存(注意格式,间距)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CO8cNaxU-1673572074415)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673252078187.png)]

(3)使用 allparis 工具生成正交表 (cmd)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4XUpd3py-1673572074416)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673252753218.png)]

注意:保存正交结构的文件不需要提前生成,可以是不存在的 txt 文件

打开 20230109jg.txt 文件可以看到

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q71ODUbh-1673572074416)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673253210459.png)]

利用 allpairs 生成的正交跟实际的正交可能有出入,但仍然不影响我们使用 allparis 生成正交表

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

  1. 全部填写姓名、电子邮箱、密码、确认密码、验证码
  2. 填写姓名、不填写电子邮箱、密码、确认密码、验证码
  3. 填写电子邮箱、确认密码,不填写姓名、密码、验证码
  4. 填写密码、验证码、不填写姓名、电子邮箱、确认密码
  5. 填写姓名、电子邮箱、密码,不填写确认密码、验证码
  6. 填写确认密码、验证码,不填写姓名、电子邮箱、密码

4. 补充可能存在遗漏但是非常重要的测试用例

  1. 全部都不写姓名、电子邮箱、密码、确认密码、验证码

6.5 场景设计法

作用:进行思路引导

基本事件流和备选事件流

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cqj4mAh2-1673572074417)(C:\Users\28463\AppData\Roaming\Typora\typora-user-images\1673228352559.png)]

编写测试用例:

  1. 基本事件流的用例:先插卡,输入正确的密码,选择取款功能 … 退卡
  2. 备选事件流:1)插入卡之后,卡被 ATM 卡住 … 退卡2)插入卡之后,输入密码错误 … 退卡…

本文转载自: https://blog.csdn.net/m0_58761900/article/details/128669160
版权归原作者 快到锅里来呀 所有, 如有侵权,请联系我们删除。

“测试之Bug与用例【创建Bug、Bug级别、Bug生命周期、测试用例的万能公式、设计测试用例具体方法】”的评论:

还没有评论