• 0
  • 0
分享
  • 软件测试--Bug等级划分规范——软件测试圈
  • TIMI 2022-02-07 15:53:40 字数 422 阅读 4534 收藏 0

1、Blocker级别——中断缺陷

客户端程序无响应,无法执行下一步操作。

2、Critical级别――临界缺陷,包括:

功能点缺失,客户端爆页。

3、Major级别——较严重缺陷,包括:

功能点没有满足需求。

4、Normal级别――普通缺陷,包括:

  • 数值计算错误

  • JavaScript错误。

5、Minor级别—一次要缺陷,包括:

  • 界面错误与UI需求不符。

  • 打印内容、格式错误

  • 程序不健壮,操作未给出明确提示。

6、Trivial级别——轻微缺陷,包括:

  • 辅助说明描述不清楚

  • 显示格式不规范,数字,日期等格式。

  • 长时间操作未给用户进度提示

  • 提示窗口文字未采用行业术语

  • 可输入区域和只读区域没有明显的区分标志

  • 必输项无提示,或者提示不规范。

7、Enhancement级别——测试建议、其他(非缺陷)

  • 以客户角度的易用性测试建议。

  • 通过测试挖掘出来的潜在需求。


作者:shizhi57

原文链接:https://www.cnblogs.com/shizhi57/p/3557668.html

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   最近,项目上出于系统性稳定性、减少测试工作量考虑,打算在 Web 前端引入 BDD。由于上一个项目写了一定的 Cucumber 代码(BDD 测试框架之一),这个框架选型的责任便落到了我的肩膀上了。  在我们进行框架选型的时候,着重考虑了一个因素:测试实现脚本是由开发人员编写的,因此最好寻找 JavaScript 支持的框架。在搜索了一天后,选择了三个框架 Cucumber、Robot、Gauge。以下是上述的三个框架入选的原因:  Cucumber,团队的开发人员有一些有相关的开发经验、支持 JavaScript。  Robot Framework,测试人员接受过相关的培训、不支持 Ja...
            0 0 75
            分享
          •   1、${__counter(,)} 计数器-加1的功能  疑问:假如加2,使用计数器 -计数器超过最大值后重新开始计数  重点:最大值, 如果运行结果超过最大值时,又会从起始值开始循环每个  用户独立计数器:多线程时,每个用户都是从起始值开始计数,跟线程号有关(${__threadNum} 获取线程号函数)  计数器注意事项如图显示:  2、时间相关的几个函数  ${__time(,)} 默认获取当前时间戳函数,但可以设置格式,比如yyyy-MM-dd 年月日的格式 HHmmss 时分秒 S毫秒   ${__dateTimeConvert(...
            0 0 371
            分享
          • 前言HTTP接口测试很简单,不管工具、框架、还是平台,只要很的好的几个点就是好工具。测试数据问题:比如删除接口,重复执行还能保持结果一致,必定要做数据初始化。接口依赖问题:B接口依赖A的返回值,C接口依赖B接口的返回值。加密问题:不同的接口加密规则不一样。有些用到时间戳、md5、base64、AES,如何提供种能力。断言问题:有些接口返回的结构体很复杂,如何灵活的做到断言。对于以上问题,工具和平台要么不支持,要么很麻烦,然而框架是最灵活的。unittest/pytest + requests/https 直接上手写代码就好了,既简单又灵活。那么同样是写代码,A框架...
            9 9 1008
            分享
          •   一.性能测试指标  在用jmeter做性能测试之前,首先要回顾下性能测试的关键指标  1.系统吞吐量throughput  单位时间内系统的请求数目  在没有达到性能瓶颈时吞吐量和虚拟用户间存在一定的联系  F=VU*R/T——VU:虚拟用户数,R:每个用户发出的请求数,T:考察的时间  2.响应时间(系统延迟)  通常一个系统的性能受吞吐量和响应时间两个条件的约束,有以下两种场景  吞吐量越大,系统延迟越大,因为请求量过大,系统繁忙,响应速度降低  系统延迟越好,能支持的吞吐量就越高,因为响应速度快,因此能处理更多的请求  3.并发数  系统能够同时处理的请求数/事务数  4.QPS(T...
            0 0 1777
            分享
          • 概述记得2019年,微信支付出过一个故障,用户发起支付给了钱后,微信一直不回调,导致使用了微信支付的商家的订单都成了未支付状态了,如果业务系统设计的不好,那瞬间就会有大量的客诉出现。像下面的对话场景,我相信当时肯定非常的多:用户:我支付了好几次了,你说你没收到?别开玩笑了。 商家:我这边真的没收钱。然后心想:这家伙不会是想吃霸王餐吧?虽然像微信和支付宝这样的大牌支付平台,出大故障的几率比较少,但是也不得不防。下面列举几个支付问题以及对应的解决思路。第三方支付平台无法支付以微信为例子,像2019年微信支付出故障时,美团那边,是在APP侧,立刻将微信支付置灰了,引导用户使用支付宝支付,将损失和影响...
            0 0 2416
            分享
      • 51testing软件测试圈微信