黑盒测试基础之BUG三方评估
bug三方评估场景:
bug三方确认的触发点一定是 在对于bug的处理意见 上开发、测试、产品三方或任意两方有不同意见时;
- 一、开发与测试意见不统一
1. 开发把bug置为不是问题打回;
2. 开发把bug置为开发难以实现打回;
3. 开发把bug置为需求如此打回;
4. 上线前开发修改一个bug,测试认为改动影响较大;
- 二、测试与产品意见不统一
1. 产品认为此bug不影响上线,测试认为问题严重;
2. 产品认为此bug需要修改,测试认为改动影响较大最好暂时不做修改;
- 三、开发与产品意见不统一
1、产品回复上线计划邮件,明确此bug需要修改,开发持不同意见;
bug三方评估的方式:(几种场景适合的方式)
- bug系统: 成本最低,效率也最低,适用于不紧急的场景;
1. 需求未测完,距上线还有充分时间;
2. 用户报的线上问题,测试评估过影响较小;
- 邮件: 适用于中等紧急的问题
标题:【bug三方评估】
收件人:开发、产品、测试
1. 类似上线计划邮件中的中优先级bug评估;
2. 测试过程中有争议的bug偏多,需要推产品和开发尽快处理;
- 口头: 效率最高,成本也最高,适用于处理重要且紧急的bug
1. 代码已冻结,高优先级bug未解决;
2. 代码已冻结,开发要改bug;
3. 代码已冻结,线上用户反馈了影响严重的bug;
评估原则:
- 三方共同评估,非一方或两方决定;
- 实事求是、只说事实、不说自己的推断;
- 明确都是以“保证产品质量”为最终目的;
评估内容:
- 1、bug现象
- 2、影响是否严重
影响严重
系统所提供的功能或服务受到明显的影响
主要功能丧失,数据被破坏,系统崩溃、悬挂,死机,数据不能保存;
LOGO不对,有错字,提示信息不正确
影响不严重
系统所提供的功能或服务没有受到明显的影响
版本信息、文件描述、签名、changelog存在明显勘误,导致公司口碑受到影响的问题
- 3、重现路径是否常用路径
常用路径
常见环境:网络,系统,硬件
常见场景:例如用户经常访问的网站,使用用户常用的第三方软件
常用数据
常见操作:使用全屏模式(习惯于使用全屏模式的用户会频繁使用)
- 4、是否有很高的重现几率
- 5、线上版本是否已经存在
上线在即,开发要求修改一个底层函数,目的是修复线上一个长期存在的问题;需三方评估
- 6、改动方法
浏览器一款插件在xp下显示异常,开发的修改方案是,对xp用户不显示;需三方评估
- 7、改动范围
开发为了修复插件在副屏显示异常的bug,重构了扩展模块;需三方评估
- 8、实现难度
- 9、影响范围
改动影响所有win7用户
- 10、风险
开发改动一笔数据库操作相关的底层函数,回归了主路径功能未见异常,但总觉得不放心;
- 11、开发修改需要的时间
开发修改一个bug,且跟测试说改动很小不用回归,但修改了很长时间,或者改动多次仍未改好;
- 12、改动验证需要的时间
开发要更改浏览器的签名文件,此时需要长时间做冲突测试,及签名相关的功能验证;
- 13、上线时间点
上线目的是为了解决线上急需解决的崩溃,必须尽快上线,此时有开发想搭车解决其它bug;
- 14、其它经验
新入职1周的开发修了一个bug,跟测试说不用回归;
开发大神修了一个bug,跟测试说不用回归;
评估结论:
- 1、三方意见统一
- 2、意见不统一
经过一系列的三方确认,最终意见仍然不统一;上报各自leader确定最终解决方案
最终结论:
- 1、是否推迟上线
- 2、下一版本修改
- 3、带着风险上线