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

Bug三方评估场景：

　　Bug三方确认的触发点一定是在对于Bug的处理意见上开发、测试、产品三方或任意两方有不同意见时；

　　一、开发与测试意见不统一

1. 开发把bug置为不是问题打回；

2. 开发把bug置为开发难以实现打回；

3. 开发把bug置为需求如此打回；

4. 上线前开发修改一个bug，测试认为改动影响较大；

　　二、测试与产品意见不统一

1. 产品认为此bug不影响上线，测试认为问题严重；

2. 产品认为此bug需要修改，测试认为改动影响较大最好暂时不做修改；

　　三、开发与产品意见不统一

　　1、产品回复上线计划邮件，明确此bug需要修改，开发持不同意见；

　　Bug三方评估的方式：（几种场景适合的方式）

• Bug系统： 成本最低，效率也最低，适用于不紧急的场景；

　　需求未测完，距上线还有充分时间；

　　用户报的线上问题，测试评估过影响较小；

• 邮件： 适用于中等紧急的问题

　　标题:【bug三方评估】

　　收件人：开发、产品、测试

　　类似上线计划邮件中的中优先级bug评估；

　　测试过程中有争议的bug偏多，需要推产品和开发尽快处理；

• 口头： 效率最高，成本也最高，适用于处理重要且紧急的bug

　　代码已冻结，高优先级bug未解决；

　　代码已冻结，开发要改bug；

　　代码已冻结，线上用户反馈了影响严重的bug；

　　评估原则：

1. 三方共同评估，非一方或两方决定；

2. 实事求是、只说事实、不说自己的推断；

3. 明确都是以“保证产品质量”为最终目的；

　　评估内容：

　　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、带着风险上线