• 14
  • 13
分享
  • 软件测试中Bug的分类——软件测试圈
  • TIMI 2021-07-28 16:17:28 字数 1627 阅读 3700 收藏 13

1、按严重程度分类:

是指bug对软件质量的破坏程度,即此bug的存在将对软件的功能和性能产生什么样的影响。

  1. 崩溃(Blocker):系统无法正常运行。阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环、导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。

  2. 严重(Critical):很明显的错误性的bug。系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等。(该等级问题出现在不影响其他测试的情况下可以继续改版本测试)。

  3. 一般:常见的bug。功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等。(该问题实际测试中存在最多,合理安排解决BUG,解决率关系到版本的优化程度)。

  4. 界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等。(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)。

2、按优先级分类:

表示处理和修正软件缺陷的先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。

  1. 重要且紧急:优先级最高,一定要做的;

  2. 重要不紧急:暂时可以先缓一缓,但一定要做的;

  3. 紧急不重要:可以先准备下,随时准备做的;

  4. 不紧急不重要:可忽略不计的。

Bug的严重程度和优先级是含义不同但相互联系密切的两个概念,从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

注:

严重程度高,优先级一定高?

  • 如果某个严重的缺陷只在非常极端的条件下产生,则没有必要马上解决。

  • 若修正一个缺陷,要修改软件的整体架构,可能产生更多缺陷,市场压力尽快发布。严重程度低,优先级不一定低?

  • 例如软件名称或公司名称的拼写错误,随属于界面错误,不严重,但关系公司形象,必须尽快修正。

3、按测试种类划分:

功能逻辑类、性能类、界面类、边界值类、内存溢出类…

按照测试种类分类,可让我们了解不同测试方法所能发现的bug比例,使测试的时候有所重点。

4、按功能分类:

一般的软件产品都是分为若干功能模块的。二八定理,统计bug主要集中在哪个功能模块里,后面要投入重点精力去测试。

5、按bug的生命周期:

  • 新建(new)

  • 已确认(open)

  • 已解决(fixed)

  • 关闭(closed)

  • 重新打开(reopen)

6、Bug描述注意事项:

  1. 确保重现Bug,严重错误重复测试两次以上。

  2. 用最少且最必要的步骤描述Bug。

  3. 简洁,准确,完整。尽量使用中性词语。

  4. 一个Bug一个缺陷报告。便于Bug分配,便于回归测试。

7、一条bug记录包含哪些内容:

  1. 填写所属产品;

  2. 填写所属项目;

  3. 选择所属的模块(前提是创建了相对应的模块);

  4. 选择影响版本,默认选择trunk;

  5. Bug类型(10大种,选择对应的bug类型即可);

  6. 兼容性PC端,考虑在某个操作系统下的某个浏览器,手机型号等;

  7. Bug的标题,唯一性,便于查找;

  8. Bug的严重程度(1,2,3,4);

  9. Bug的优先级(书写上三个级别:1,2,3(高,中,低));

  10. 重现步骤包括三个方面:操作步骤、预期结果、实际结果;

  11. Bug的重现需上传对应的文件(如操作时发现的截图)。

作者:佳期如顭

原文链接:https://blog.csdn.net/weixin_44773193/article/details/103941073

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   测试代码是确保代码稳定的第一步。能做到这一点的最佳方法之一就是使用单元测试,确保应用程序中的每个较小的功能都按应有的方式运行——尤其是当应用程序接收到极端或无效输入,甚至可能有害的输入时。  为什么要进行单元测试?  进行单元测试有许多不同的方法,一些主要目的是:  验证功能:单元测试确保代码做正确的事情并且不做任何不应该做的事情——大多数错误发生在这里。  防止代码回归:当我们发现错误时,添加单元测试来检查场景可以防止代码更改在将来重新引入错误。  记录代码:通过正确的单元测试,一套完整的测试和结果提供了应用程序应该如何工作的规范。  保护您的应用程序:单元测试可以检查可利用的漏洞(例如...
            0 0 1138
            分享
          •      工程造价软件按地区、行业进行划分,每个地区和每个行业的计算规则、取费标准皆不相同。各类造价软件都是以模板为基础,根据标准报表设计页面,录入造价数据,实时计算汇总出工程造价。每个工程皆是以工程树的形式存在,一般分为工程总项目、单项工程和单位工程三级,单位工程由基础造价数据构成,并在单位工程的汇总页面实时计算;单项工程由单位工程构成,工程总项目由单项工程构成,并实时汇总所有单位工程的数据。  由于造价相关主管部门会根据实际情况发布各地区和各行业新的计价文件,则会根据最新标准发布工程造价软件的相应补丁。因此,造价软件的版本迭代非常频繁。这种情况下,工程造价软件一般会引入...
            1 0 1735
            分享
          • 一、为什么要分布式并发?JMeter性能实践过程中,一旦进行高并发操作时就会出现以下尴尬场景,JMeter客户端卡死、请求错误或是超时等,导致很难得出准确的性能测试结论。目前沐沐知道的有两个方法可以解决JMeter支撑高并发,一是将JMeter部署在Linux服务器上,可以支撑的并发量远大于windows客户端,极少出现JMeter客户端卡死的情况;另外一种方式就是今天要介绍的分布式,简单来说,分布式就是将一次大的操作分布在多个服务器上,由多个服务器来承担负载压力。分布式并发的原理详见下图: 二、分布式并发实现步骤1、打开Jmeter,在运行->远程启动,可以看到只有“127....
            1 0 4299
            分享
          • 方法一:利用利用xlrd读取excel文件其实整个过程比较简单,利用xlrd读取excel文件,再把读取到的数据转换为dict即可。1.安装 xlrdpip install xlrd2.读取文件,并进行格式转换导入的excel表格的格式是这样的:解析后的格式为 [{'编号': 1, '时间': '1988-07-21 00:00:00', '年龄': 1, '分数': 63.2, '总分&...
            1 0 2223
            分享
          • 作为知名的市场颠覆者之一,亚马逊在医疗健康领域正又一次遭遇失败。最初,亚马逊与摩根大通和伯克希尔哈撒韦共同启动了Haven项目,试图对医疗系统进行改革,但很快就宣布了终止。现在,亚马逊即将关闭远程护理服务AmazonCare。这家公司致力于在美国全国范围内为雇主解决远程医疗和初级保健问题,亚马逊也曾宣传该公司的服务正赢得越来越多的客户。这些情况是否真的证明了过去多年外界的普遍观点:与大多数行业相比,医疗行业更难颠覆?或许并非如此。不过这可能释放了一个信号,表明亚马逊在医疗健康行业的策略发生了变化。关于AmazonCare的关闭,最终问题可能是个简单的选择题:大公司,尤其是那些拥有大笔现金的公司...
            0 0 835
            分享
      • 51testing软件测试圈微信