文章目录
1. 如何创建Bug
提 Bug 就是要开发人员进行问题的解决 (1. 尝试复现 2. 代码修复)
创建 Bug 的要素:问题出现的版本、问题出现的环境、出现步骤、预期结果、实际结果等
2. Bug的级别
Bug 存在不同的严重级别
不同的 Bug 等级,惩罚机制不一样
不同的 Bug 等级,也跟开发人员的开发质量能力有直接关系
严重级别:崩溃、严重、一般、次要(具体的级别数量,要看当前公司的规范)
-
Blocker(崩溃):阻塞开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,数据库连接错 误,主要功能丧失,基本模块缺失等问题
-
Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等
-
Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性
-
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
4. 面试题:跟开发产生争执怎么办
- 多反思自己,是不是 Bug 创建的时候描述不太清楚
- 开发人员对 Bug 级别不认可,Bug 定级一定要有理有据,测试人员需要明确企业 Bug 定级规范,拿着规范和开发人员沟通,为什么这样定级
- 合理友好的进行沟通,站在用户的角度反问,如果你是用户,你能接受这样的功能吗,提 Bug 必定会增加开发人员的工作量,小问题不想解决
- 不仅能够发现问题,最好也能够提出解决方案给开发参考
- 如果确实是 Bug,友好沟通已经不能解决问题了,那就召开 Bug 评审,需要有相关的代表来参加:产品代表、开发代表、测试代表等 (1. 如何解决 Bug 2. 如何预防类似的 Bug 再发生)
5. 设计测试用例的万能公式
假如有一个水杯,如何针对这个水杯来设计测试用例
水杯是否保温、能够盛放多少毫升的水、水杯是否漏水、是否易于携带、有没有问题显示功能、是否抗衰…
如果仅仅通过简单直接的思考来设计测试用例,用例是比较少的
原则上用例的设计不仅要考虑其实现了其应该实现的,还要考虑其未实现其不应该实现的
那么测试用例是否是设计的越多越好?
工作中,测试用例能够更多的覆盖项目测试为最好
面试的时候测试用例设计的越多越好,主要就是面试时考察的是设计测试用例的能力,思维发散能力
万能公式:功能测试 + 性能测试 + 界面测试 + 兼容性测试 + 易用性测试 + 安全测试
功能测试:可能来自于需求文档,也可能来自生活经验
性能测试:功能没有问题不代表性能一定是好的,性能往往表现在一些极端情况下
界面测试:颜色、形状、大小、材质、文字、输入框、图片、下拉框… 所有可以看到的元素
兼容性测试:浏览器的兼容性、版本兼容性、系统兼容性、数据兼容性
易用性测试:软件是否具有简单易上手的属性
安全性测试:密码是否加密,数据库里是否对隐私数据加密、SQL注入
使用万能公式对水杯设计测试用例
兼容性测试中需要注意,不同的浏览器,不同的版本可能会有非常多,难道所有的版本和浏览器都需要进行测试吗,我们选型的标准是什么
- 大部分用户使用的
- 在工作中是有数据后台可以检测到大部分用户使用到的浏览器/版本/手机型号… 后台可以将这些数据进行检测和管理起来,就可以参考数据管理平台给出的数据选型
6. 设计测试用例的具体方法
6.1 等价类
用户的密码为 6~12 位,测试的时候使用到的测试数据是什么, 10位?8位?
如果使用穷举法 6,7,8,9…12 全部都测试一遍,这样可以,但是如果把密码位数改为 6~1000位,那么穷举法就不行了
可以根据等价类,来划分测试数据
根据需求将输入划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,就认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题
等价类的划分
- 有效等价类:针对需求文档的要求是有意义的集合 (6~12位密码)
- 无效等价类:针对需求文档的要求是没有意义的集合 (小于6位,大于12位的密码)
步骤
- 确认有效等价类和无效等价类
- 编写测试用例
- 输入长度为 6~12 位的密码,具体是 10 位
- 输入长度为小于 6 位的密码,具体是 1 位
- 输入长度为大于 12 位的密码,具体是 20 位
6.2 边界类
密码长度为 6~12 位,有效边界值为 6、18 ,无效边界值 5、19
边界值指的是 有效边界 + 无效边界
例如:成绩大于 60 可以获奖,无效边界 60,有效边界 61
数字为浮点数,6~10 有效边界值 无效边界值 到底是单精度浮点型还是双精度浮点型
6.3 判定表
使用场景:输入条件的组合对应不同的结果
- 确认输入条件和输出条件
- 找出输入条件和输出条件之间的关系
- 画判断表
- 根据判定表编写测试用例
案例:假设业务单据的处理规则为:“淘宝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. 画判断表
4. 根据判定表编写测试用例
- 有红包,订单金额小于300,不提交订单,则该订单为无优惠订单
- 无红包,订单金额大于300,不提交订单,则该订单为无优惠订单
- 无红包,订单金额小于300,提交订单,则该订单为无优惠订单
- 有红包,订单金额大于300,不提交订单,则该订单为无优惠订单
- 有红包,订单金额小于300,提交订单,则该订单为有优惠订单
- 无红包,订单金额大于300,提交订单,则该订单为有优惠订单
- 有红包,订单金额大于300,提交订单,则该订单为有优惠订单
- 无红包,订单金额小于300,不提交订单,则该订单为无优惠订单
因果图法相比于判定表法步骤差不多,只不过因果图法中多了一步叫做 “画因果图”
6.4 正交法(allparis)
正交法用的比较少
正交试验设计法指从大量的试验中挑选出适量的、有代表性的点,依据 “正交表” 从而合理的设计出测试用例
地图软件,从出发地到目的地需要耗时多久
因素:下班的高峰期(水平:是高峰期、不是高峰期)、今天不限号、天气、所经路段红灯时间长、地段(城市路段/郊区)、道路施工、行驶人的驾车技能好坏、车况
如果使用判定表,那么当输入条件过多时,出现的情况太多了,那么判定表就不太合适了,这就可以使用正交表
正交表的表示L4(2^3),4代表的是4组实验(4个测试用例),3代表的因素数(3个输入条件),2代表的每个因素数对应的水平数(输入条件的可能选项)
根据正交表设计测试用例的步骤:
- 找出因素数(输入条件)和水平数(输入条件的可能选项)
- 生成正交表(需要借助生成正交表的工具:allparis)
- 根据正交表来编写测试用例
- 补充可能存在遗漏但是非常重要的测试用例
案例:
1. 找出因素 和 水平
因素:姓名、电子邮箱、密码、确认密码、验证码
水平:填写、不填写
2. 使用 allparis 生成正交表
(1)将水平和因素写入 Excel
(2)allparis 同级目录中创建一个新的 txt 文件(xxx.txt),复制 Excel 中的因素和水平,粘贴到 xxx.txt 文本中,保存(注意格式,间距)
(3)使用 allparis 工具生成正交表 (cmd)
注意:保存正交结构的文件不需要提前生成,可以是不存在的 txt 文件
打开 20230109jg.txt 文件可以看到
利用 allpairs 生成的正交跟实际的正交可能有出入,但仍然不影响我们使用 allparis 生成正交表
3. 根据正交表编写测试用例
- 全部填写姓名、电子邮箱、密码、确认密码、验证码
- 填写姓名、不填写电子邮箱、密码、确认密码、验证码
- 填写电子邮箱、确认密码,不填写姓名、密码、验证码
- 填写密码、验证码、不填写姓名、电子邮箱、确认密码
- 填写姓名、电子邮箱、密码,不填写确认密码、验证码
- 填写确认密码、验证码,不填写姓名、电子邮箱、密码
4. 补充可能存在遗漏但是非常重要的测试用例
- 全部都不写姓名、电子邮箱、密码、确认密码、验证码
6.5 场景设计法
作用:进行思路引导
基本事件流和备选事件流
编写测试用例:
-
基本事件流的用例:先插卡,输入正确的密码,选择取款功能 … 退卡
-
备选事件流:
1)插入卡之后,卡被 ATM 卡住 … 退卡
2)插入卡之后,输入密码错误 … 退卡
…
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/87288.html