如何对所发现的缺陷进行严密的等级划分?

提问:如何对所发现的缺陷进行严密的等级划分?

  回答:测试过程中发现的缺陷一般分为如下几类

  功能问题(FunctionError):对产品、项目质量有影响,但尚难以确定是否是错误,暂时无法解决

  功能缺陷(FunctionDefect):不满足用户需求等bug的总称

  页面缺陷(UIDefect):页面美观性、协调性、错别字等

  建议类(Suggestion):对产品、项目的建议性意见,不强制要求修改

  硬件性能:进行性能测试时使用,暂定:网络延时、内存问题、CPU占用、硬盘问题

  安全性问题:进行系统安全测试时使用,暂不订具体标准

  业务流程问题:进行业务流程测试时进行

  数据库性能:暂不执行

  模块间接口问题:涉及有模块间数据传递时使用

  其他(Other):其它

  根据各类缺陷的严重程度将缺陷分为5个等级,具体如下:

  1)低(Low)

  建议类错误,对软件的改进意见或者建议。如:

  a)功能建议

  b)操作建议

  c)校验建议

  d)说明建议

  e)UI建议

  2)中(Medium)

  使操作者不合理或者不方便或操作遇到麻烦,但它不影响执行工作功能或重要功能,次要功能,对产品使用影响不大。如:

  界面错误

  a)使操作者不方便或者遇到麻烦,但不影响执行工作功能的实现

  b)界面、控件的摆布、图标、输入输出不规范

  提示类错误

  a)删除操作未给出提示

  b)长时间操作未给出提示

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

  d)出错没有提示

  其他错误

  a)不符合编码标准

  b)辅助说明描述不清楚、不规范

  c)快捷键无效,快捷键错误操作

  d)打印内容、格式错误

  3)高(High)

  影响系统正常运行的缺陷,主要功能出现错误,影响到产品的使用。如:

  数据库缺陷:数据库设计未达到第三范式的要求或需求规格说明的格式水平

  操作错误:因错误操作迫使程序中断

  功能错误:

  a)程序功能无法实现

  b)程序功能实现错误

  其他错误:

  a)脚本错误

  b)软件产品的编译,打包,安装,卸载错误

  4)非常高(Very High)

  规定的功能没有实现或不完整或产生错误结果;设计不合理造成性能低下,影响系统的运营;使系统不稳定、或破坏数据;而且是常规操作中经常发生或非常规操作中不可避免的主要问题,且没有办法更正(重新安装或重新启动软件不属更正办法),须尽快修正,如:

  数据缺陷

  a)数据计算错误

  b)数据约束错误

  c)数据输入、输出错误

  数据库缺陷

  a)数据库发生死锁

  b)数据库的表、业务规则、缺省值未加完整性等约束条件

  c)数据库连接错误

  d)数据通讯错误

  接口缺陷

  a)程序接口错误

  b)硬件接口、通讯错误

  功能错误:

  a)程序功能无法实现

  b)程序功能实现错误

  5)紧急(Critical)

  不能执行正常工作或重要功能,使系统崩溃或资源严重不足,数据丢失(金币,包子)非常死机等导致系统不能继续运行须马上修正,如:

  a)由于程序所引起的死机,非法退出

  b)程序死循环

  c)性能与需求不一致(压力测试)

  d)存在安全性与保密性问题

  e)文件打开与保存错误

  总结:

  1级-建议问题的软件缺陷(Enhancemental):由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

  2级—较小错误的软件缺陷(Minor),使操作者不方便或遇到麻烦,但它不影响功能过的操作和执行,如错别字、界面不规范(字体大小不统一,文字排列不整齐,可输入区域和只读区域没有明显的区分标志),辅助说明描述不清楚。

  3级—一般错误的软件缺陷(major):次要功能没有完全实现但不影响使用。如提示信息不太准确,或用户界面差,操作时间长,模块功能部分失效等,打印内容、格式错误,删除操作未给出提示,数据库表中有过多的空字段等。

  4级—严重错误的软件缺陷(critical):系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失。问题局限在本模块,导致模块功能失效或异常退出。如致命的错误声明,程序接口错误,数据库的表、业务规则、缺省值未加完整性等约束条件

  5级—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起,或造成数据丢失,主要功能完全丧失,导致本模块以及相关模块异常等问题。如代码错误,死循环,数据库发生死锁、与数据库连接错误或数据通讯错误,未考虑异常操作,功能错误等。

原帖地址:http://bbs.51testing.com/thread-1000328-1-1.html

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-11-05 19:39:55

如何对所发现的缺陷进行严密的等级划分?的相关文章

Testin发布众测平台 助开发者发现质量缺陷建立质量体系

APP新增数量和场景上都非常广泛实现难度大幅增加,这也为测试带了了更多难题.Testin云测则上线Testin众测平台,帮助开发者发现质量缺陷,建立质量体系.众测是一种全新的应用质量管理方式,为开发者提供一种完全开箱即用.按需付费的SaaS服务,帮助中小开发者无需招聘专业的测试团队也可以轻松将应用质量管理. Testin众测平台不仅提供了测试规划.功能测试.兼容性测试.可用性测试.Beta测试等测试服务,开发者还可以直接使用众测平台的Bug管理.用例管理.项目管理.崩溃监控等在线工具. 众测需要

谷歌眼镜被用于测试宝马 可帮助发现隐藏缺陷

谷歌眼镜被用于测试宝马 可帮助发现隐藏缺陷最近不少媒体报道了 GoogleGlass的负面消息,有些用户给它取了不雅的外号,还有些行业分析师把它比作是江河日下的Segway.不过宝马公司似乎对这款可穿戴设备情有独钟,他们正在美国南卡罗纳州运行一个试点项目,希望探索Google Glass是如何提升汽车小批量生产过程中的质量控制,帮助公司更好地从原型开发过渡到正式定型量产阶段.在现代汽车制造过程中,小批量生产是非常重要的一个环节.一开始,汽车会有一个吸引眼球的设计概念,然后 它们会进入原型制造阶段

如何使用Contemplate ThreadSafe发现并判断Java并发问题

事实证明,要发挥多核硬件所带来的收益是很困难和有风险的.当使用并发正确和安全地编写Java软件时,我们需要很仔细地进行思考.因为错误使用并发会导致偶尔才出现的缺陷,这些缺陷甚至能够躲过最严格的测试环境. 静态分析工具提供了一种方式,可以在代码执行之前探查并修正并发错误.它能够在代码执行之前分析程序的源码或编译形成的字节码,进而发现隐藏在代码之中的缺陷. Contemplate的ThreadSafe Solo是一个商用的Eclipse静态分析插件,其目的就是专门用来发现并诊断隐藏在Java程序之中

大型对日外包企业的缺陷跟踪

本文档的作者是一家大型软件外包企业的管理人员.该企业在全国服务外包企业50强中排在15位以前.为保护隐私,我们在此隐去客户的名称. 由于本公司的业务是日本外包,而外包会遇到2个客户--发包方和用户,缺陷管理就变得十分复杂,而且又十分重要重要. 在使用URTracker之前,本公司的缺陷管理相当混乱,并且修改效率低下,无迹可寻. 因此,公司的领导层决定寻找一种合理的管理工具加以管理,经过反复比较选择,最终选定了URTracker作为本公司的缺陷管理工具,使用将近两年,效果显著. 以下详细介绍一下本

量化项目管理案例:缺陷趋势预测利器(8)

理论知识终于告一段落啦.接下来要和大家分享的是S型曲线模型中的重要模型--Gompertz模型和Logistic模型在公司内部实际项目中的应用.下面的数据都是来自于公司内部实际项目,应用主要分4个场景:进入测试阶段前.测试阶段过程中.测试退出时.以及其它的应用.下面将依据场景,从测试阶段开始一直到结束,分阶段介绍S型曲线的应用. ● 进入测试阶段前的缺陷发现目标的预测 进入测试阶段前的缺陷预测过程可以说是一个静态的预估过程.简单来说,即根据经验.历史数据.预测开始时的缺陷数.release时的缺

谷歌G1手机存在严重安全缺陷 黑客可安装恶意件

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 网易科技讯 北京时间10月26日消息,据国外媒体报道,T-Mobile新推出的G1智能手机所使用的Android软件中存在一处严重的安全缺陷. 发现该缺陷的安全研究人员查尔斯·米勒(Charles Miller)表示,他日前已经向谷歌通报了这一缺陷,但决定同时公开这一消息,保护用户不会受到黑客的侵害. 黑客可以利用该缺陷诱骗用户访问恶意站点,

量化项目管理案例:缺陷趋势预测利器(1)

量化项目管理案例:缺陷趋势预测利器(1) 不知身为软件工程师的你,在写代码时是不是有过这样的经历:一方面对自己写的代码信心满满,一方面又非常希望知道自己开发的代码的质量到底多高.如果代码真的没被测出bug来或者测出的bug较少时,反而有点担心--会不会还有隐藏的更深的bug没被发现?或者身为测试工程师的你,可能比开发人员担心的会更多:这些代码该不该再继续测试了?怎么就能断定当前的版本算是通过验收标准了,继而可以被客户和用户认可?是不是就可以把这个版本交付使用了呢? ---------------

软件测试类型/缺陷分类的获取

软件测试类型分析是进行细化测试用例条件的重要手段之一,通过测试类型的分类,软件测试人员可以将测试条件从不同的维度进行考虑,并发现不同的缺陷类型,从而提高测试的覆盖率. 测试类型并不是一个标准,它的定义需要考虑公司内部不同的产品,结合项目开发特点和软件产品的特点,以及测试人员在行业领域的技能和经验的积累.图1是作者提出的测试类型定义需要考虑的几个方面: 图1 测试类型的主要来源 测试类型定义需要综合考虑各个方面的输入,包括开发文档定义的需求(包括涉及的一些标准与规范等).ISO/IEC 9126质

《中国人工智能学会通讯》——8.44 基于用户缺陷报告挖掘软件缺陷

8.44 基于用户缺陷报告挖掘软件缺陷 缺陷报告是用户向软件开发者汇报软件使用过程中所遇故障的报告.该报告基于自然语言书写,记录了软件发生故障场景和症状等信息.通过分析软件缺陷报告,可以有效定位出导致该缺陷的程序代码,从而帮助程序员对其进行修复. 由于缺陷报告是终端用户通过自然语言书写,因此基于用户缺陷报告进行缺陷挖掘的关键在于如何建立缺陷报告与符合其功能描述的代码之间的联系.现有技术通常将程序代码视为自然语言,然后基于文本空间建立缺陷报告与程序代码之间的相关性,从而发现缺陷代码.向量空间模型