是指bug对软件质量的破坏程度,即此bug的存在将对软件的功能和性能产生什么样的影响。
崩溃(Blocker):系统无法正常运行。阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环、导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
严重(Critical):很明显的错误性的bug。系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等。(该等级问题出现在不影响其他测试的情况下可以继续改版本测试)。
一般:常见的bug。功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等。(该问题实际测试中存在最多,合理安排解决BUG,解决率关系到版本的优化程度)。
界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等。(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)。
表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
重要且紧急:优先级最高,一定要做的;
重要不紧急:暂时可以先缓一缓,但一定要做的;
紧急不重要:可以先准备下,随时准备做的;
不紧急不重要:可忽略不计的。
Bug的严重程度和优先级是含义不同但相互联系密切的两个概念,从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。
注:
严重程度高,优先级一定高?
如果某个严重的缺陷只在非常极端的条件下产生,则没有必要马上解决。
若修正一个缺陷,要修改软件的整体架构,可能产生更多缺陷,市场压力尽快发布。严重程度低,优先级不一定低?
例如软件名称或公司名称的拼写错误,随属于界面错误,不严重,但关系公司形象,必须尽快修正。
功能逻辑类、性能类、界面类、边界值类、内存溢出类…
按照测试种类分类,可让我们了解不同测试方法所能发现的bug比例,使测试的时候有所重点。
一般的软件产品都是分为若干功能模块的。二八定理,统计bug主要集中在哪个功能模块里,后面要投入重点精力去测试。
新建(new)
已确认(open)
已解决(fixed)
关闭(closed)
重新打开(reopen)
确保重现Bug,严重错误重复测试两次以上。
用最少且最必要的步骤描述Bug。
简洁,准确,完整。尽量使用中性词语。
一个Bug一个缺陷报告。便于Bug分配,便于回归测试。
填写所属产品;
填写所属项目;
选择所属的模块(前提是创建了相对应的模块);
选择影响版本,默认选择trunk;
Bug类型(10大种,选择对应的bug类型即可);
兼容性PC端,考虑在某个操作系统下的某个浏览器,手机型号等;
Bug的标题,唯一性,便于查找;
Bug的严重程度(1,2,3,4);
Bug的优先级(书写上三个级别:1,2,3(高,中,低));
重现步骤包括三个方面:操作步骤、预期结果、实际结果;
Bug的重现需上传对应的文件(如操作时发现的截图)。
作者:佳期如顭
原文链接:https://blog.csdn.net/weixin_44773193/article/details/103941073