软件缺陷管理之缺陷严重等级分类

合集下载

BUG严重等级划分

BUG严重等级划分
2、开发人员收到bug报告后,认为是一个bug,于是就开始修复它,修复后,传送给测试人员。 3、测试人员收到bug修复报告后,开始对它进行验证,验证通过后,就把它置于closed状态。当一个bug 被置为closed状态的同时,该bug的声明周期也就此结束。如果发现该bug仍然存在问题,唯一的办法就 是再open一个同样的bug。 4、开发人员收到bug报告后,认为它不是一个bug,或者是描述不清、重复、不采纳所提意见建议、或虽 然是个问题但还没到非改不可的地步故可忽略不计、或者是测试人员提错,就把它置于rejected状态。把 reject报告传送给测试人员。 5、测试人员收到开发人员的reject报告后,会对开发人员的意见进行验证。如果经过验证后,测试人员 不同意开发方的意见,就把该bug置于reopen状态,同时,把reopen报告传送给开发人员。 6、开发人员收到测试人员的reopen报告后,会对测试人员的意见进行证实,如果证实错误,就会把该 bug置于rejected状态,同时,把rejected报告传送给测试人员。 7、开发人员收到测试人员的reopen报告后,会对测试人员的意见进行验证,如果验证是一个bug,就会 对它进行修复,修复后会把它置于fixed状态,同时把fix报告传送给测试人员。 8、测试人员收到开发人员的fix报告后,会对该bug进行验证,如果没有通过验证,会把该bug置于 reopen状态,并且把reopen报告传送给开发人员。 9,开发人员收到测试人员的open报告,由于技术或者其它原因不能解决,或者留到一版本作为扩展功能 点所处的状态,先由开发人员置于下一版本开发。 10、测试人员收到开发人员的reject报告,会对该bug进行验证,如果验证该bug不存在,就会对它置于 closed状态。 11、开发人员收到测试人员的open报告后,会对该bug进行验证,如果开发人员不确定该bug的可修复性 ,就会把该bug上报给项目负责人,如果项目负责人认为该bug由于技术或者其它原因不能解决,或者作 为下一个版本的功能点来扩展,就会把该bug置于deferred状态。同时,把defer报告传送给测试人员。 12、测试人员收到项目负责人的defer报告后,会把它置于closed状态。

缺陷等级划分

缺陷等级划分

缺陷严重级别定义:o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等. o 紧急---事件非常重要,并且需要马上给予关注.o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决. o 低级---事件不重要,可以在时间和资源允许的情况下再解决.o 建议性缺陷.更为详细的划分如下:A类——严重错误,包括:o 由于程序所引起的死机,非法退出o 死循环o 导致数据库发生死锁o 数据通讯错误o 严重的数值计算错误B类——较严重错误,包括:o 功能不符o 数据流错误o 程序接口错误o 轻微的数值计算错误C类——一般性错误,包括:o 界面错误(详细文档)o 打印内容、格式错误o 简单的输入限制未放在前台进行控制o 删除操作未给出提示D类——较小错误,包括:o 辅助说明描述不清楚o 显示格式不规范o 长时间操作未给用户进度提示o 提示窗口文字未采用行业术语o 可输入区域和只读区域没有明显的区分标志o 系统处理未优化E类——测试建议(非缺陷)软件公司对软件缺陷级别的定义不尽相同,一般可以分为4种:1. 致命(fatal):致命的错误,造成系统或应用程序崩溃(crash)、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失2. 严重(critical):严重错误,指功能或者特性(feature)没有实现,主要功能丧失,导致严重的问题,或致命的错误声明3. 一般的(major):不太严重的错误,这样的缺陷虽然不影响系统的基本使用,但没有很好的实现功能,没有达到预期的效果。

如次要功能丧失,提示信息不太正确,或用户界面太差,操作时间长等4. 微小的(minor):一些小问题,对功能几乎没有影响,产品及属性仍可使用,如有个别错别字、文字排列不整齐等Bug严重程度定义:致命(Critical)BUG :测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出;系统的主要功能或需求没有实现。

缺陷的优先级和严重性定义

缺陷的优先级和严重性定义

缺陷的优先级和严重性定义我们可以简单地将软件缺陷的严重性划分为4个等级,如表11-1所示。

1.严重性(Severity)严重性说明1 严重缺陷。

系统无法满足基本的商业要求且没有便捷可用的工作区。

性能、功能或使用方面严重不达标2 一般缺陷。

系统能够满足商业要求。

有快捷方便的工作区可供使用。

性能、功能或使用方面并不是严重不达标3 微小缺陷。

微小修改,希望提出建议,最好能够修正,但不是必需的。

在发布准确性或实用性方面不会产生重大影响2.优先级(Priority)小组中使用的主观对任务和工作项排定优先次序评级。

与严重性结合在一起来评定可见度、变更、风险修复等。

(A "subjective" rating used by groups to prioritize tasks and work items.A combination of Severity with the visibility, workarounds, fix risk, etc... subjective importance)(1)优先级0(Priority 0)⏹这类软件缺陷必须在24小时之内被解决(These bugs need to be resolved within 24hours):⏹问题导致了中断或者阻止了产品的正常版本编译(Issues that break or prevent aproduct build)⏹问题导致了阻止了BVT和其他测试自动化的运行(Issues that prevent BVTs andother test automation)⏹问题导致了无法成功构建国内和全球文档(Issues that keep production fromsuccessfully building Domestic and International Doc Builds)⏹由于粗心丢失内容,如文档文件、命名空间(Unintentionally dropped out content, e.g.doc file, namespace)(2)优先级1(Priority 1)⏹这类软件缺陷必须修复然后才能发布产品或者才能达到用户体验所包含的最主要目标(Bugs that must be fixed in order to ship the product or achieve UE's top/maingoals):⏹高法律风险;地域相关;版权,商标,准许法令(High Legal risk; Geopolitical,Copyright, Trademark, Consent Decree)⏹高风险编码实践(High risk security coding practices)⏹问题导致了对客户和/或本公司的重大影响(Issues with significant impact oncustomers and/or the company)⏹对用户/产品关键的用于描述场景的新文档和/或新特性(New documentation forscenarios and/or new features that are crucial to customers and/or the product)⏹辅助访问主题的元数据的变更;搜索,属性F1和索引问题(Metadata changes to helpaccess topics; search, attributes, F1 and indexing issues)⏹在目标命名空间中的代码样例/代码片段(Code samples/snippets in targetednamespaces)⏹过多从参考文档到概念性文档的引用(More linking of reference docs to conceptualdocs )⏹在顶层页面/节点发现的问题,例如在首页,门户上发现的问题(Issue found on toplevel pages/node,e.g., homepage, portal)⏹在大标题上存在的问题(Issue appears in a large number of topics through out the docset)⏹技术性的不正确的内容(Technically incorrect content)(3)优先级2(Priority 2)⏹软件缺陷应该被修复(Bugs that should be fixed):⏹对客户和产品不是那么关键性的场景或者特性(Scenarios or features that are notcrucial to customers or the product)⏹从先前版本来的内容修复(Fixing content from previous releases)⏹非目标命名空间中代码样例/代码片段(Code samples/snippets in non targetednamespaces)⏹在中等级页面/节点中发现的缺陷(Bug found in mid level pages/nodes)⏹在小标题上存在的问题(Bug appears in a significant number of topics through out thedoc set)(4)优先级3(Priority 3)⏹如果修复这个缺陷会比较好(Bugs that would be good to fix):⏹目录问题(Table of Contents issues)⏹先前版本中未完成的文档(Incomplete documentation from previous releases)⏹重写或重新格式化原本正确的文档,为了让它更清晰,更容易阅读(Rewriting orreformatting correct content to make it clearer, easier to read)⏹在视觉上影响到用户但是但不影响阅读(Issues that visually impacts the customer butwon't affect the readability or use of the topic)⏹最佳实践修复(Best practice fixes)⏹代码样例/代码片段(Code samples/snippets)⏹在低级的页面中/节点中发现的问题(Issues found in low level pages/nodes)⏹被阅读很少的主题(Issues found in a small number of topics)(5)优先级4(Priority 4)⏹如果修复这个缺陷我们的工作就算是达到精细的程度,这种问题比较细小,可以被推迟处理(Bugs that would be nice to fix, are trivial and can be postponed):⏹在文档中藏得比较深的问题(Issues buried in the docs)⏹仅在一个话题中有的问题(Issues found in only one topic )⏹对用户影响比较小的问题(Issues with low to no customer impact)⏹如果要修复这个问题导致的本地化的投入要比对用户的获益高得多(Issues with a highlocalization cost versus customer gain)。

软件缺陷定义1

软件缺陷定义1

软件缺陷的级别、优先级及状态
软件缺陷有四种级别分别为: 致命的(Fatal) 严重的(Critical) 一般的(Major) 微小的(Minor)
A类—致命的软件缺陷(Fatal): 造成系统或应用 程序崩溃、死机、系统挂起,或造成数据丢失,主 要功能完全丧失,导致本模块以及相关模块异常等 问题。如代码错误,死循环,数据库发生死锁、与 数据库连接错误或数据通讯错误,未考虑异常操作, 功能错误等 B类—严重错误的软件缺陷(critical):系统的主 要功能部分丧失、数据不能保存,系统的次要功能 完全丧失。问题局限在本模块,导致模块功能失效 或异常退出。如致命的错误声明,程序接口错误, 数据库的表、业务规则、缺省值未加完整性等约束 条件
缺陷注入分析
缺陷注入分析:对被测软件注入一些缺 陷,通过已有用例进行测试,根据这些 刻意注入缺陷的发现情况,判断测试的 有效性、充分性,预测软件残留缺陷数
DRE/DRM分析
DRE/DRM分析:通过已有项目历史数据, 得到软件生命周期各阶段缺陷注入和排 除的模型,用于设定各阶段质量目标, 评估测试活动
Gompertz分析
Gompertz分析:根据测试的累积投入时 间和累积缺陷增长情况,拟合得到符合 自己过程能力的缺陷增长Gompertz曲线, 用来评估软件测试的充分性、预测软件 极限缺陷数和退出测试所需时间、作为 测试退出的判断依据、指导测试计划和 策略的调整;
Rayleigh分析
Rayleigh分析:通过生命周期各阶段缺陷 发现情况得到缺陷Rayleigh曲线,用于评 估软件质量、预测软件现场质量
C类—一般错误的软件缺陷(major):次要功能没有完全 实现但不影响使用。如提示信息不太准确,或用户界面差,操 作时间长,模块功能部分失效等,打印内容、格式错误,删除 操作未给出提示,数据库表中有过多的空字段等 D类—较小错误的软件缺陷(Minor),使操作者不方便或遇 到麻烦,但它不影响功能过的操作和执行,如错别字、界面不 规范(字体大小不统一,文字排列不整齐,可输入区域和只读区 域没有明显的区分标志),辅助说明描述不清楚 E类- 建议问题的软件缺陷(Enhancemental):由问题提出 人对测试对象的改进意见或测试人员提出的建议、质疑。

软件缺陷等级划分标准

软件缺陷等级划分标准

软件缺陷等级划分标准
软件缺陷等级划分标准是指根据软件缺陷的严重程度和影响范围,将软件缺陷分为不同等级,以便开发人员和测试人员能够更好地管理和解决软件缺陷。

软件缺陷等级划分标准通常由软件开发公司或项目组制定,也可以参考国际标准或行业标准。

一般来说,软件缺陷等级划分标准包括以下几个方面:
1. 缺陷等级的定义:通常包括严重、一般、轻微等等,不同等级的定义可能有所不同,但一般都是根据缺陷的影响程度和紧急程度来划分的。

2. 缺陷的影响范围:缺陷的影响范围通常包括功能、性能、安全等方面,不同的缺陷可能会对不同的方面产生影响,因此需要根据具体情况来划分。

3. 缺陷的修复时间:不同等级的缺陷需要在不同的时间内进行修复,一般来说,严重的缺陷需要在最短时间内进行修复,而轻微的缺陷可以在后续版本中进行修复。

4. 缺陷的优先级:缺陷的优先级通常是根据缺陷的紧急程度和影响程
度来划分的,优先级高的缺陷需要在优先处理,以保证软件的稳定性和安全性。

总的来说,软件缺陷等级划分标准是软件开发和测试过程中非常重要的一部分,它可以帮助开发人员和测试人员更好地管理和解决软件缺陷,提高软件的质量和稳定性。

因此,在软件开发和测试过程中,需要根据具体情况制定合理的软件缺陷等级划分标准,并严格按照标准进行管理和处理。

缺陷的等级评定

缺陷的等级评定

缺陷的等级评定
缺陷的等级评定通常根据其严重程度和影响范围进行评定。

以下是常见的缺陷等级评定:
1. 严重缺陷(Critical):这些缺陷会导致系统崩溃、数据丢失或无法使用,且不具备可用的替代方案。

这类缺陷需要立即修复,否则系统无法正常运行。

2. 主要缺陷(Major):这些缺陷会导致系统功能性的问题,
但可通过绕过或使用备用方案来解决。

这类缺陷对系统正常运行的影响较大,需要尽快修复。

3. 次要缺陷(Minor):这些缺陷通常是一些界面问题、行为
不一致或用户体验不佳等,对系统整体运行影响较小。

这类缺陷应该在合适的时机进行修复,以提高系统的质量。

4. 提示缺陷(Suggestion):这些缺陷不影响系统的正常运行,但可能会对用户的操作产生困惑或导致一些不必要的操作。

这类缺陷通常是一些改进性的建议,可以在后续的版本中进行修复。

缺陷的等级评定可根据具体的项目和组织而有所区别,因此有时还可能存在其他等级评定。

最终评定缺陷等级时,需要综合考虑缺陷的严重程度、影响范围和修复的难度等因素。

缺陷等级划分

缺陷等级划分

缺陷严重级别定义:o最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.o紧急---事件非常重要,并且需要马上给予关注.o高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.o中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.o低级---事件不重要,可以在时间和资源允许的情况下再解决.o建议性缺陷.更为详细的划分如下:A类——严重错误,包括:o由于程序所引起的死机,非法退出o死循环o导致数据库发生死锁o数据通讯错误o严重的数值计算错误B类——较严重错误,包括:o功能不符o数据流错误o程序接口错误o轻微的数值计算错误C类——一般性错误,包括:o界面错误(详细文档)o打印内容、格式错误o简单的输入限制未放在前台进行控制o删除操作未给出提示D类——较小错误,包括:o辅助说明描述不清楚o显示格式不规范o长时间操作未给用户进度提示o 提示窗口文字未采用行业术语o可输入区域和只读区域没有明显的区分标志o 系统处理未优化E类——测试建议(非缺陷)软件公司对软件缺陷级别的定义不尽相同,一般可以分为4种:1.致命(fatal):致命的错误,造成系统或应用程序崩溃(crash)、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失2.严重(critical):严重错误,指功能或者特性(feature)没有实现,主要功能丧失,导致严重的问题,或致命的错误声明3.一般的(major):不太严重的错误,这样的缺陷虽然不影响系统的基本使用,但没有很好的实现功能,没有达到预期的效果。

如次要功能丧失,提示信息不太正确,或用户界面太差,操作时间长等4.微小的(minor):一些小问题,对功能几乎没有影响,产品及属性仍可使用,如有个别错别字、文字排列不整齐等Bug严重程度定义:致命(Critical)BUG:测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出;系统的主要功能或需求没有实现。

软件缺陷级别定义【Rice老师】

软件缺陷级别定义【Rice老师】

软件缺陷级别定义1.缺陷定义>软件没有达到产品说明书表明的功能>软件出现了产品说明书中不一致的表现软件功能超出产品说明书的范围软件没有达到用户期望的目标虽然产品说明书中没有要求测试员或用户认为软件的易用性差2.不是所有的缺陷都会修改市场的压力使得产品最终发行有时间限制测试员错误理解或者不正确操作引出的缺陷错误的修改影响的模块较多,带来的风险较大缺陷报告中提出的问题很难重现修改性价比太低3. 优先级o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.o 紧急---事件非常重要,并且需要马上给予关注.o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.o 低级---事件不重要,可以在时间和资源允许的情况下再解决.o 建议性缺陷.4. 分类标准:A类——致命错误,不能执行正常工作功能或重要功能。

使系统崩溃或资源严重不足。

包括:o 由于程序所引起的死机,非法退出o 死循环o 导致数据库发生死锁o 数据通讯错误o 严重的数值计算错误o与数据库连接错误o 数据通讯错误B类——严重错误,严重地影响系统要求或基本功能的实现,且没有办法更正(重新安装或重新启动该软件不属于更正办法)。

包括:o 功能不符o 数据流错误o 程序接口错误o 轻微的数值计算错误C类——一般性错误,严重地影响系统要求或基本功能的实现,但存在合理的更正办法(重新安装或重新启动该软件不属于更正办法)。

包括:o 界面错误(详细文档)o 打印内容、格式错误o 简单的输入限制未放在前台进行控制o 删除操作未给出提示D类——较小错误,使操作者不方便或遇到麻烦,但它不影响执行工作或功能实现。

包括:o 辅助说明描述不清楚o 显示格式不规范o 长时间操作未给用户进度提示o 提示窗口文字未采用行业术语o 可输入区域和只读区域没有明显的区分标志o 系统处理未优化E类——测试建议(非缺陷)。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件缺陷管理之缺陷严重等
级分类
标准化文件发布号:(9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
A类——严重错误,包括:
由于程序所引起的死机,非法退出
死循环
导致数据库发生死锁
数据通讯错误
严重的数值计算错误
需求未实现
文档与软件不符、文档严重不足、系统文档关键错误B类——较严重错误,包括:
功能不符
数据流错误
程序接口错误
轻微的数值计算错误
C类——中等错误。

包括:
程序非正常终止但可通过其它输入来避免
系统边界错误
显示报表错误
数据处理、需求理解错误
系统文档一般错误
D类——一般性错误,包括:
界面错误(详细文档)
打印内容、格式错误
简单的输入限制未放在前台进行控制
删除操作未给出提示
系统操作不方便
E类——较小错误,包括:
辅助说明描述不清楚
显示格式不规范、查询报告格式错误
长时间操作未给用户进度提示
提示窗口文字未采用行业术语
可输入区域和只读区域没有明显的区分标志系统处理未优化
F类——测试建议(非缺陷)。

相关文档
最新文档