测试开发中关于BUG的一些知识点

由来（小故事）

  bug的本意是昆虫、飞蛾。由于早先的计算机体积庞大，一些小飞蛾飞进去很容易导致计算机运行出现问题，在1947年，美国海军少将格蕾丝·霍普（Grace Hopper）和她的团队正在哈佛大学操作一台名为Mark II的大型机械计算机时遇到了一个问题，导致他们的机器无法正常运行。经过仔细检查，他们在读卡器的继电器中发现了一只真正的飞蛾，正是这只飞蛾阻止了机器的正常运作。因为这只飞蛾被粘在了机器内部，所以他们将其取出并贴在了日志书中，旁边写着：“First actual case of bug being found。”从那以后，“bug”这个术语就在计算机领域内广泛传播开来，用来描述任何导致程序或系统出现故障的问题。

  霍普的故事虽然是一个有趣的轶事，但“bug”一词在计算机科学中的使用其实早于这一事件，可以追溯到至少1878年托马斯·爱迪生的笔记中，他提到了“虫子”（bugs）在他的实验设备中造成的问题。

定义

  bug又叫计算机程序错误，一个计算机bug是指在计算机程序中存在的错误或疏忽，这些bug导致程序无法正确运行。（注意是无法正确运行而不是无法运行）

• 一切bug的的判断标准都应从用户的需求出发，当程序没有实现用户的功能需求时，就是程序错误，也就是bug。

如何规范地描述一个BUG

  一个规范的bug描述应该包含但不限于以下五个部分：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果。

• 例：
  问题出现的版本:谷歌浏览器版本 123.0.6312.123(正式版本)(64 位)
  问题出现的环境:Windows家庭版
  问题出现的步骤:
  1、打开谷歌浏览器，输入网址https://www.10leduyun.com/
  2、等待首页页面渲染完成预期结果:二维码与登陆模块不会出现遮挡，二维码可以正常扫描实际结果::二维码被登陆模块遮挡，二维码扫描失败
  预期结果:二维码与登陆模块不会出现遮挡，二维码可以正常扫描
  实际结果:二维码被登陆模块遮挡，二维码扫描失败
  

BUG的级别划分

  bug一般分为崩溃、严重、一般、次要四个等级。bug级别能反映问题严重程度，开发人员通常需按级别分配优先级来处理bug，而且对bug进行分级登记也能对开发人员的开发质量进行评级和量化。

崩溃	阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。
严重	系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
一般	功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等 (该问题实际测试中存在的最多)
次要	界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

BUG的生命周期

• new（新bug状态）:测试人员发现一个新bug（此时并未确认是否为有效bug）
• rejected（拒绝修改）:如果确认为认为不是bug，则拒绝修改。
• open（有效bug）:确认是有效bug，并且认为需要进行修改，指派给相应的开发人员。
• fixed（已修改状态）:开发人员进行修改后标识成已修改状态，有待测试人员的回归测试验证。
• delay（延后修改）:如果认为暂时不需要修改或暂时不能修改，则延后修改。
• closed（关闭状态）:已修改的Bug经测试人员的回归测斌验证通过，则关闭Bug。
• reopen(重新修改)：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

但
bug的级别和bug的数量都会影响到程序猿的年终奖，所以很多时候测试人员和开发人员都会因为bug出现争论，如果测试人员和开发人员意见达不到统一，那么就需要进行bug评审的环节辽~

• （这里有一个高频考题：当你与开发人员产生争执了怎么办？写到测开高频考题那篇文章里了测开高频考题）

BUG评审

如果确实是bug，友好沟通不能解决问题，那么就召开bug评审。bug评审主要解决两个问题:

1. 决定如何处理bug
2. 分析缺陷产生的原因，找出预防的对策

bug评审至少需要项目组各个方面的代表参加:

• 测试代表
    测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。
• 开发代表
    开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
• 产品代表
    产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见