一、Bug 的生命周期
new - open - fixing - verify - close
发现bug–>提交bug–>指派bug–>研发确认bug–>研发去修复bug–>回归验证bug–>是否通过验证–>关闭bug
● New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。
● Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。
● Rejected:如果认为不是Bug,则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
● Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。
● Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
无效的bug:open->closed open-rejected-closed
二、Bug 的等级
- Blocker(崩溃):
阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。 - Critical(严重):
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。 - Major(一般):
功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多) - Minor(次要):
界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)
三、Bug 包含的内容
Bug 标题、短描述
发现问题的版本、重现步骤(详细步骤)、实际结果、预期结果
Bug 类型和严重程度、Bug 测试环境(出现问题的环境)、附件
四、Bug 的管理状态处理-测试
- 已经指派的bug
- 已经解决的bug
- 重复bug
- 不足缺陷
- 无法重现
- 不予解决
- 设计如此
- 延期修改
五、常见面试题
- 有没有你印象深刻的bug?怎么解决的?
- Bug 的生命周期?
- 当你开了一个bug,但开发不认为是bug,如何处理?
- 你在发现bug并确认bug的过程中对于复现率不高的bug怎么处理的?
- bug 记录里面包含哪些内容?
- 你了解哪些bug 管理系统?(禅道(zentao)、bugzilla、jira、bugfree、easybug、QC)
- 你们测试用例和bug是如何管理的?