黑盒测试基础之BUG三方评估

黑盒测试基础之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、带着风险上线