bug的严重程度和bug对应的测试用例的优先级
bug严重性和优先级的定义
BUG定义Building 7, 439 Chun Xiao Road Zhangjiang High Technology Park Shanghai, China 201203 Tel: +86-21-50803377 Fax: +86-21-50275100 一.严重性分类●Critical1.系统上电后,播放Video文件就会无声音/无图象/死机/花屏/黑屏/严重打顿/马赛克的现象。
2.系统上电后,播放Audio文件时出现无声音/噪声/爆音,声音失真现象,声音打顿。
3.系统上电后,播放Picture会出现花屏,图片显示不完整,或图片颜色失真。
4.在播放时操作遥控器无响应的现象。
5.不能识别设备/热插拔死机现象。
6.通过设备不能播放VIDEO/MUSIC/JPEG文件。
7.播放VIDEO文件时声音和图像不同步。
8.不能连接AP,连接AP/Server时死机。
9.不能连接BT设备,连接时出现死机现象。
10.平台连PC后不能识别平台上的Memory Card和Nand。
11.拷贝/删除/打印过程中出现死机现象。
12.OSD/ICON刷新过程中或刷新后死机。
13.无法升级或升级死机,或升完级无法正常工作。
14.煲机死机。
●Major1.播放单个文件时出现死机/黑屏/花屏等现象。
2.个别的卡和USB设备不能识别的问题。
3.个别的蓝牙手机连接的兼容性问题。
4.Wifi平台连接个别AP或多个Wifi平台连到一个AP上出现的问题。
5.在多个卡槽上同时插卡或USB口同时都插上USB设备,相互影响后一部分设备不能识别,或文件列表显示乱码。
6.打印机连接平台后不识别。
7.文件系统的问题(如长文件名或繁体中文的文件名的文件可以识别但不能播放)8.播放中出现图像和声音干扰。
9.无开机画面或开机画面错误。
10.开机画面显示时间大于10S。
11.开机画面彩色明显失真。
12.开机画面与正常机比较明显偏亮或过暗。
13.开机画面残缺不全或画面上有干扰亮点、亮条、亮纹或其它干扰缺陷。
关于BUG严重程度、处理优先级、bug类型的划分
关于BUG严重程度、处理优先级、bug类型的划分转载⼀严重程度致命:系统⽆法正常运⾏严重:很明显的错误性的bug较重:相对明显的错误性的bug⼀般:常见的bug建议类:(暂时保留,可能去掉)⼆优先级说明:紧急相当于执⾏前的准备⼯作,重要相当于后续的⼯作重要且紧急:优先级最⾼,⼀定要做的重要不紧急:暂时可以先缓⼀缓但⼀定要做的紧急不重要:可以先准备下,随时准备做的不紧急不重要:可忽略不计的三 bug类型:功能错误:功能上的错误性bug代码错误:⼀般很少出现,通常在⾃测时出现(对⽩盒测试、⾃测的⽐较适合)内容相关:业务逻辑⽅⾯以及业务描述等相关问题表单相关:表单逻辑、样式、内容问题⽤户界⾯:UI表现,包括对话框样式和⽂字描述问题需求变动:原有的需求基础上的更改新增需求:会议上提出的新需求,⾮正式会议提出的不属于该项设计⽂档:数据库设计⽂档、概要/详细设计⽂档建议:功能已满⾜但待改善,属于改良性建议配置相关:如web服务器或者数据库服务器配置等问题安装部署:项⽬部署时出现的错误,可能不是程序本⾝的问题⽽是⼯具本⾝和⼈为因素引起安全相关:加密和⽔印等安全信息性能压⼒:负载、压⼒测试标准规范:根据国际标准或者公司内部制定的某标准测试脚本:如⽤⼯具LR编写并执⾏脚本进⾏测试事务跟踪:产品缺陷/bug跟踪(Defect/bug Tracking)⼯作任务跟踪(Task Tracking)问题解决过程跟踪(Problem Tracking)产品需求管理(Request Management)客户服务过程跟踪(Customer Support TrackingBad Case:和⽤例没有关联起来,所以暂时不⽤其他:尽量避免⽤该项,不便于统计但仍保留。
22、BUG类型、等级、优先级
22、BUG类型、等级、优先级BUG类型、等级、优先级Bug类型bug类型分12种,常见有1-5代码错误界⾯优化设计缺陷后台配置相关产品体验安全相关性能问题标准规范需求未实现历史BUG历史问题优化其他Bug等级Bug定义标准分四级:①级Bug(致命错误)=================1、导致运⾏程序中断(正常操作导致的崩溃、闪退)2、严重性能问题:严重内存泄露/占⽤、严重发热、严重耗电3、App⽆响应(如ANR)4、循环报错,⽆法正常退出(如:卡在当前页⾯,物理返回/返回按钮都⽆法退出当前页⾯)5、功能设计与需求“严重不符”--差距⼤(产品设计A,技术实现成B)6、阻断测试⼯作进⾏,⽆法往下进⾏测试⼯作(例如:⽆法发帖)7、严重程序错误:死循环、数据通讯错误、数据库死锁、严重数值计算错误②级Bug(严重错误)=================1、常规功能未实现(判断功能实现必要性)2、功能存在报错,不完整3、轻微数值计算错误(程序代码层级)4、程序接⼝请求/响应报错(明显错误、如重复请求)5、业务流程错误6、系统⽆法登录(我们的登录影响⽤户具体数据信息获取、质量分、等级、消息中⼼、爆⽶花等)③级Bug(⼀般错误)=================1、边界条件错误2、容错性不好(版本功能兼容错误)3、⼤数据下容易⽆响应(⼤数据情况下,⼀些异常报错;正常数据量下正常)4、主要功能实现存在问题,但不影响系统稳定5、功能操作常规报错(不影响性能)6、响应时间较慢(请求响应时间太长)7、定位焦点错误,影响功能实现(单个按钮点击热区范围太⼩/越界影响其他功能按钮)8、界⾯不能及时刷新,影响功能实现(如:页⾯未及时跳转,影响下⼀步操作)④级Bug(易⽤性、建议性)=================1、界⾯UI相关:颜⾊搭配、⽂字整齐(如设备兼容)2、⽂章、按钮名称、介绍⽂案、标题等出现错别字3、排版错误4、按钮样式5、提⽰语丢失、友好提⽰语、显⽰格式等6、光标定位显⽰、跳转设置7、⽤户体验感受不好Bug优先级Bug优先级分四级:①级(紧急)=================1、系统⽆法⼯作2、测试⽆法继续正常⼯作3、特殊情况:如重要客户(项⽬重要性)②级(⾼)=================1、需求问题2、实现与需求不符3、出现调试代码4、功能性错误5、关联性错误6、前后模块不⼀致7、链接错误8、特殊性的程度性能低下9、程序引起的安全问题③级(中)=================1、页⾯格式错误2、兼容性问题3、校检错误4、图⽚错误5、⽂案错误6、程序性能低下7、缺少容错性处理8、功能易⽤程度低9、配置问题④级(低)=================1、遗留问题2、暂时⽆法实现技术问题3、合理建议。
测试BUG等级划分标准
BUG类型缺陷
S级bug,优先级最高
致命缺陷:
1、代码存在巨大缺陷(代码结构有巨大问题)
2、数据库存在巨大隐患(如恶意攻击造成的账户私密信息泄露)
3、充值存在问题(如金钱计算错误、充值不到账)
4、具体功能未实现
5、系统不稳定等(如常规操作会引发系统崩溃、死机、死循环)
A级bug,优先级次高
严重缺陷:
1、重要功能未实现(例如:更新的功能为实现,功能设计与需求严重不符)
2、功能操作影响多个其他功能
3、代码有错误(非常规操作会导致的崩溃、死机、死循环等)
4、UI界面存在影响功能实现的问题(封面图片的失真、压缩、完全变形等)
5、前端的安全问题等(密码明文显示等)
B级bug,优先级一般
一般缺陷:
1、次要功能不能正常实现
2、操作UI显示错误(增删改查等)
3、部分操作未给出提示(例如:删除、修改等)
4、UI兼容性问题等
建议修改类型缺陷
优化建议,优先级最低(建议修改)
程序在一些显示上不美观,不符合用户习惯,用户体验不佳或者是一些文字的错误
1、界面格数等不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误等等
需求
测试过程中发现的一些为实现功能,但不属于本次版本内容,下个版本增加的内容,缺陷记录为:需求。
bug严重等级及修复优先级划分
相符)。
1、微小的问题, 如果不进行修改,不影响主要功能,产品及属性 仍可使用,如有个错别字。
4
提示 从用户角度:
用户可以使用,但交互性不好,对于用户可能造成难于操作、学习
和理解
从使用者角度,提出的建议性意见。
5
建议性 从用户角度:
个别功能使用不够方便,但是不影响用户使用的问题
例如
1、操作或使用某一功能时,导致程序异常退出,或其余功能无法使用,或造成经常性 死机和重启; 2、严重花屏、内存泄漏; 3、用户数据丢失或破坏; 4、系统崩溃/死机/冻结; 5、程序或模块无法正常启动或异常退出; 6、功能设计与需求严重不符; 7、导致其它功能无法测试的错误。
2、严重影响系统要求或基本功能的实现,且没有办法避免冲突;
2
严重 3、主要功能丧失,导致严重的问题,或致命的错误声明。
从用户角度: 用户可以使用,但性能非常不稳定,经常出现服务中断
次要功能丧失, 不太严重,可通过变通手段解决。
3
一般 从用户角度:
用户可以使用,偶尔出现服务中断(软件功能和需求规格级别基本
序号 1
严重级别
状态描述
致命
1:导致运行中断(应用程序崩溃)、预期的功能没有得到实现、测 试工作无法继续进行等; 2:由于程序引起的非法死机,退出,数据丢失,主要功能完全丧 失,系统悬挂等错误。
从用户角度: 由于产品功能或者性能造成80%以上用户无法使用的问题。
1、较大的功能缺陷 如该功能没有实现或实现有错误;
1、用户界面不太友好; 2、使用不习惯; 3、好的操作建议等。
备注
1、按键操作错误或失灵; 2、客户环境本身没有问题的情况下,网络不稳,频繁断线,掉线; 3、实现的功能与相关需求严重不符; 4、功能未实现; 5、功能错误; 6、系统所提供的功能或服务受到明显的影响;
BUG级别(优先级、严重级)定义
BUG级别(优先级、严重级)定义⼀、主要分类BUG类型标准主要分两类:Ø 依据优先级分类。
Ø 依据严重程度分类。
⼆、主要内容依据优先级分类标准定义优先级:指⼀个BUG相对于其他BUG对于公司的影响,解决的及时性。
分类标准紧急² 系统⽆法⼯作² 测试⽆法继续正常⼯作² 特殊情况:如重要客户(项⽬重要性)⾼² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 关联性错误² 前后模块不⼀致² 链接错误² 特殊性的程度性能低下² 程序引起的安全问题注:涉及所有关于数据流的错误中² 页⾯格式错误² 兼容性问题² 校检错误² 图⽚错误² ⽂案错误² 程序性能低下² 缺少容错性处理² 功能易⽤程度低² 配置问题注:涉及的所有关于⽂本的错误低² 遗留问题² 暂时⽆法实现技术问题² 合理建议依据严重程度分类标准定义严重程度:指⼀个BUG对于⽤户造成的影响,风险和可视性。
分类标准紧急² 程序⽆法运⾏的错误² 测试⽆法执⾏的错误⾮常⾼² 链接错误² 前后模块不⼀致² 需求问题² 实现与需求不符² 出现调试代码² 功能性错误² 程序性能低下² 程序引起的安全问题⾼² 页⾯格式错误² ⽂案错误² 图⽚错误² 兼容性错误² 校检错误中² 关联性错误² 配置问题² 功能易⽤程度低低² 合理建议² 遗留问题² 暂时⽆法实现技术问题注意事项1) ⼀些错误可以分在多个级别中,但总的标准以此为准,具体的问题具体分析后再确定其等级数。
测试文档二 bug严重程度和优先级(缺陷管理)
bug严重级别和优先级别定义Bug严重级别:是指因缺陷引起的故障对软件产品的影响程度。
由测试人员指定。
如下:最高级(1类)-- 致命级别阻止对后续功能的测试,通常适用于以下情况1 模块无法启动或异常退出2界面/功能Crash 导致一系列测试不能运行3严重花屏4数据丢失(用户数据,服务器数据)5系统崩溃/死机/冻结6 业务逻辑错误(数据计算错误:例如支付错误,业务流程缺失或者走错)7功能设计和需求严重不符8服务器400,500等错误9 影响流程问题,升级失败10 业务逻辑流程中断跳转到其他页面次最高级(2类)- 严重级别在当前发布版本中必须修复,即影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性1 Bug 的出现导致软件没有完成用户的需求2 系统刷新错误3数值计算错误4影响功能及界面的错误字或拼写错误5 安全性问题6 兼容性问题(用户群体大,影响严重)7 数据不准,建单据报错8 引发性新BUG(说明此单BUG是由于前面修改BUG或做的新需求导致其它模块出现新的错误。
一般(3类)一般级别-- 在时间许可的范围内修复,即界面、性能缺陷1 只有在极端条件下才会重现的Bug2 在特定配置情况下不会出现的Bug3 操作界面错误(包括数据窗口内列名定义、含义是否一致)4 边界条件下错误5 提示信息错误6系统未优化,性能问题7 兼容性问题(有一定用户群体,影响较大)低(4类)轻微-- 不影响当前发布,可以推迟到下一个发布中修复,即易用性及建设性问题1 不能稳定重现的Bug2 因为电脑上装有其他干扰软件产生的Bug3 非功能性Bug, 如日志,错误回复等4 界面规格不规范5 辅助说明描述不清6 操作时未给用户提示信息7 个别不影响产品功能的错别字8 文字排列不整齐9兼容性问题(用户群体不大,影响相对较小)10 错误提示信息不准确有歧义Priority(优先级)1 Immediate(紧急,一类)即“马上解决”,表示问题必须马上解决,否则系统根本无法达到预定的需求。
bug优先级定义标准
bug优先级定义标准Bug优先级定义标准是一个用于确定和组织软件缺陷修复顺序的系统。
这个标准可以根据缺陷的严重程度、影响范围和紧急性进行评估和排序。
通过定义和遵循一套统一的标准,团队可以更好地管理和解决各种缺陷,确保关键问题得到及时解决,同时也能够更好地分配资源和时间。
一般来说,一个完善的Bug优先级定义标准应包括以下几个关键要素:1. 严重程度(Severity):指的是缺陷对系统功能或性能的重大影响程度。
常见的严重程度分级可以是致命(Critical)、严重(Major)、一般(Minor)和轻微(Trivial)等。
这些级别通常是根据缺陷对用户体验、系统稳定性和关键功能的影响程度来定义的。
2. 优先级(Priority):指的是修复该缺陷的紧急程度。
通常使用高、中、低等级别来表示。
优先级的确定可以考虑到缺陷对用户的影响、缺陷的复现频率、工作量以及项目进度等因素。
3. 影响范围(Impact):指的是缺陷对系统其他功能或模块的影响程度。
评估缺陷的影响范围可以帮助团队更好地理解和评估修复该缺陷的优先级。
4. 复现频率(Reproducibility):缺陷的复现频率可以作为评估优先级的参考因素之一。
如果一个缺陷容易被复现,可能会被赋予更高的优先级,因为它对用户和系统的影响更大。
5. 解决时限(Deadlines):指定某些缺陷需要在特定时间内得到解决的情况。
根据项目的需求和进度,团队可以设定不同的修复时限来确定优先级。
通过以上要素的评估和综合考虑,团队可以为每个缺陷确定一个准确的优先级,从而能够更好地管理和解决系统中的问题。
举个例子,假设有一个软件中存在一个导致系统崩溃的缺陷,这个缺陷导致用户无法完成关键操作。
在这种情况下,这个缺陷在严重程度上应该被定义为致命(Critical),因为它会导致系统不可用,直接影响用户体验和业务流程。
在优先级上,这个缺陷应该被赋予高优先级,尽快解决并发布修复版本。
测试BUG等级划分标准
测试BUG等级划分标准
BUG类型缺陷
S级bug,优先级最高
致命缺陷:
1、代码存在巨大缺陷(代码结构有巨大问题)
2、数据库存在巨大隐患(如恶意攻击造成的账户私密信息泄露)
3、充值存在问题(如金钱计算错误、充值不到账)
4、具体功能未实现
5、系统不稳定等(如常规操作会引发系统崩溃、死机、死循环)
A级bug,优先级次高
严重缺陷:
1、重要功能未实现(例如:更新的功能为实现,功能设计与需求严重不符)
2、功能操作影响多个其他功能
3、代码有错误(非常规操作会导致的崩溃、死机、死循环等)
4、UI界面存在影响功能实现的问题(封面图片的失真、压缩、完全变形等)
5、前端的安全问题等(密码明文显示等)
B级bug,优先级一般
一般缺陷:
1、次要功能不能正常实现
2、操作UI显示错误(增删改查等)
3、部分操作未给出提示(例如:删除、修改等)
4、UI兼容性问题等
建议修改类型缺陷
优化建议,优先级最低(建议修改)
程序在一些显示上不美观,不符合用户习惯,用户体验不佳或者是一些文字的错误
1、界面格数等不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误等等
需求
测试过程中发现的一些为实现功能,但不属于本次版本内容,下个版本增加的内容,缺陷记录为:需求。
Bug的优先级
Bug的优先级在测试工程师的日常工作中,最经常做的也是必须做的就是提交缺陷报告.在提交Bug的时候,我们要给出这个Bug的优先级(Priority),开发人员会根据Bug的优先级来决定先修那个Bug,后修哪个Bug.所以优先级的正确与否会影响到Bug的解决时间进而可能会影响测试和开发的进度.对于一个Bug的优先级也往往是QA和RD争论的焦点.在我们的公司中Bug的优先级根据其严重度和发生的频率和环境来决定.首先一个Bug有5种严重程度的定义:严重度A--系统Crash,不能进行安装等;严重度B--需求说明书中要求的重要功能没有实现;严重度C--功能存在缺陷;严重度D--功能可以进一步改进;严重度E--建议优先级的定义如下:Priority 1--必须立即修复;Priority 2--在Beta前必须修复;Priority 3--在release前必须修复;Priority 4--在下一版修复;Priority 5--可以修复或不修;接下来根据Bug发生的频率和环境建立一张优先级Mapping表.根据这张表就可以很容易定义Bug的优先级了.如何填写BugFree中严重程度和优先级严重程度(Severity)分为4级,新建Bug时依照下面的标准必须指定。
同时开发和产品等人员在Bug处理过程中可以随时调整。
1 :系统崩溃或数据丢失2 :主要功能问题3 :次要功能问题4 :细微问题或建议优先级(Priority):测试人员如果不清楚问题的轻重缓急,新建Bug的时候不要随意填写。
一般由开发人员、产品经理或者客服人员在Bug处理过程中填写。
可以参考当前业务需求、开发计划和资源状态,按照下面的标准选择一个合理优先级。
1 :需要立即解决的问题(Now)2 :需要在指定时间内解决的问题(Need to be fixed in N days)3 :产品开发计划内解决的问题(Need to be fixed in this sprint)4 :资源充沛时解决的问题(Fix or not)BUG解决优先级第一级(blocker): 引起操作系统“挂起”或“崩溃”的错误;第二级(critical): 引起软件本身“挂起”或“崩溃”的错误;第三级(major): 不能完成软件说明书定义的功能的错误;第四级(normal): 程序所完成的功能与软件说明书定义不符的错误;第五级(minor) : 显示方面的错误;第六级(trivial) : 其它“轻微”的错误(如文本差错);第七级(enhancement):增强或者改进。
(完整版)BUG 等级划分标准
BUG等级划分方法一、测试BUG等级划分标准1、Blocker(崩溃):阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。
如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
2、Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。
如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
3、Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。
如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多,合理安排解决BUG,解决率关系版本的优化程度)4、Minor(次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。
如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)二、BUG状态标准1、待处理(new):测试人员或用户发现新问题后提交的状态2、已确认(open):经测试人员及研发人员讨论后确认是BUG,提交的状态,由测试人员来设置。
3、已处理(fixed):经研发人员确认是BUG后修复的状态,修改还没有验证,由开发人员来设置。
4、已修改(closed):测试人员认为问题已经修改,通过验证,由测试人员设置。
bug缺陷严重与优先性定义
bug缺陷严重与优先性定义缺陷严重等级对照表Bug Severity List缺陷状态Status此栏位表明缺陷现在状态,允许值包含:This field in dicates the curre nt bug status. The permissible values in clude:新缺陷:标示一个缺陷状态刚发现。
New: status in dicates a bug that is being reviewed and fixed by developme nt.审核中:标示一个缺陷状态正进行经由审核与修复。
Un der Review: status in dicates a bug that is being reviewed and fixed.测试进行中:标示一个缺陷状态正进行重测,但将花时间或正等待一些标准在重测前。
Test ing In Progress: status in dicates a bug that is being re-tested, but will take time需要重测:标示一个缺陷状态已经修复和正等待重测。
Needs Re-Test: status in dicates a bug that has bee n fixed and is wait ing re-testi ng.重审核:标示一个缺陷状态修复,重测但仍发现有错误。
Re-Review: status in dicates a bug that was fixed, re-tested, and found to still contain the error.关闭:标示一个缺陷状态已经修复,重测和通过确认,缺陷修正。
Closed: status in dicates a bug that has bee n fixed, re-tested and pass verificati on. The bug is fixed.暂时递延:标示一个缺陷状态已经递延到补丁发布等。
Bug严重级和优先级
Bug严重级和优先级严重程度优先级严重主要功能完全丧失阻碍流程/系统崩溃导致重⼤任务不能正常进⾏的缺陷1. 由于程序所引起的死机,⾮法退出2. 死循环3. 数据库发⽣死锁4. 错误操作导致的程序中断5. 严重的计算错误6. 与数据库连接错误7. 数据通讯错误等8. 系统崩溃,内存泄漏9. 严重的数值计算错误(商城系统,银⾏系统)10. 主要业务功能报50011. 主要功能⽆法测试紧急1 当缺陷所引发的问题没有达到紧急的级别,但当该缺陷出现后,影响到了后续的测试⼯作进⾏2 客户⽆法容忍的页⾯,如页⾯上显⽰其他公司名称3 当前操作⽅式与客户使⽤习惯背道⽽驰。
4 严重不合理,核⼼功能完全违反软件规范或业务规范,可能导致⽤户强烈的反感5系统响应时间过长(例如WEB响应时间超过10s)6模块提供的数据不合理,例如(查询“录⼊⼈”的下拉项提⽰为⾮⽤户名字段)7负载测试、压⼒测试结果和⽤户需求不符较⾼1.次要业务功能报5002.次要功能⽆法测试3.功能未实现/错误4.影响功能或界⾯的错别字或拼写错误5.轻微的数值计算错误(四舍五⼊错误等)6.安全问题⾼1 快捷⽅式不正确,如能够回车直接进⼊下⼀步的设计成了空格直接进⼊下⼀步2 严重的逻辑错误3常⽤操作平台不能正常使⽤功能(WIN XP/WIN 2000/WINVISTA)4常⽤浏览器不能正常使⽤(IE6.0/IE7.0/FireFox)5超时限制的时间设置不合理6未登录即可浏览页⾯7给客户演⽰等过程中客户重点指出的,严重级别却不是很⾼的BUG,建议级别定义⾄少是⾮常⾼8.次要功能报5009.次要功能⽆法测试10.次要功能未实现11.轻微的数值计算错误⼀般次要功能丧失,不太严重,如提⽰信息不太准确操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现,例如:1.界⾯错误(附详细说明)2.打印内容、格式错误3.简单的输⼊限制未放在前台进⾏控制4.删除操作未给出提⽰5、数据输⼊没有边界值限定或不合理错别字、罕见故障等不影响执⾏⼯作或功能实现,例如:1.辅助说明描述不清楚2.系统处理未优化v提⽰窗⼝⽂字未采⽤⾏业术语1.边界条件错误2.提⽰信息错误3.长时间操作⽆进度提⽰4.性能问题5.严重的兼容性问题(功能⽆法使⽤,⽹站⽆法打开等,web:edge,chorme,firefox,safari,phone:主流⼿机系统:ios,Android系统)中进⼊个⼈计划处理,表⽰问题不影响需求的实现,但是影响其他⽅⾯使⽤1.影响功能或界⾯的错别字或拼写错误2.边界条件错误3.提⽰信息错误4.影响功能或界⾯的错别字或拼写错误5.安全问题6.性能问题7.严重的兼容性问题(功能⽆法使⽤,⽹站⽆法打开等,web:edge,chorme,firefox,safari,phone:主流⼿机系统:ios,Android系统)8.cookie未正常保存9.整体风格不统⼀轻微易⽤性及建议性问题1.界⾯格式等不规范2.辅助说明不规范3.操作时未给⽤户提⽰4.可输⼊区域和只读区域没有明显区分5.个别不影响产品理解的错别字6.⽂字排列不整齐7.轻微的兼容性问题(图⽚⽆法显⽰,界⾯排列错位等,web:edge,chorme,firefox,safari,phone:主流⼿机系统:ios,Android系统)低1 虽有不尽⼈意之处,但不影响⽤户操作或⽤户使⽤频率较低,并且不会造成错误2 局部界⾯不够美观3.长时间操作⽆进度提⽰虽然BUG严重级和优先级规范已经定好,但是有时候不能完全按照该标准执⾏,⽐如⼀个⾼级别BUG(报500),在系统中属于辅助业务,基本很少⽤到的功能,可以定优先级为中.⼜⽐如⼀个接⼝,前端已经去掉操作按钮,但是接⼝未做处理=功能错误,严重级应该是⾼,但优先级可以定为低.。
BUG等级划分标准
BUG等级划分方法一、测试BUG等级划分标准1、Blocker(崩溃):阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。
如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
2、Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。
如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
3、Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。
如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多,合理安排解决BUG,解决率关系版本的优化程度)4、Minor(次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。
如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)二、BUG状态标准1、待处理(new):测试人员或用户发现新问题后提交的状态2、已确认(open):经测试人员及研发人员讨论后确认是BUG,提交的状态,由测试人员来设置。
3、已处理(fixed):经研发人员确认是BUG后修复的状态,修改还没有验证,由开发人员来设置。
4、已修改(closed):测试人员认为问题已经修改,通过验证,由测试人员设置。
Bug定级与优先级解析
Bug定级与优先级解析Bug,也称为软件缺陷或故障,是指在计算机程序或系统中出现的错误或异常行为。
在软件开发和维护过程中,及时、准确地定级和分配Bug的优先级对于项目的成功与否起着至关重要的作用。
本文将对Bug的定级与优先级进行解析,并探讨如何有效管理和处理Bug。
一、Bug定级Bug定级是根据Bug的严重程度和影响范围来对其进行分类和等级划分的过程。
通常,Bug定级可分为以下几个层次:1. 严重级别:指Bug所引发的后果对于整个系统或核心功能的影响程度。
根据实际情况和需求,可将严重级别分为致命级、严重级、一般级等不同等级。
2. 优先级:指解决Bug的紧急性和重要性程度。
优先级可分为高、中、低三个等级,用于确定Bug的处理优先级。
3. 紧急性:指解决Bug的时间紧迫程度。
常见的紧急性等级有紧急、高、中、低等。
4. 影响范围:指Bug对系统或功能的影响范围。
可以将影响范围划分为功能受限、功能完全无法使用、系统崩溃等等不同级别。
适当的Bug定级能够使开发人员和测试人员更好地理解和评估Bug,为后续处理提供依据,提高问题解决的效率。
二、Bug优先级Bug优先级是根据Bug的严重程度和紧急性来确定Bug的处理优先级。
在处理Bug时,开发人员将按照Bug的优先级进行处理,以确保较重要或紧急的Bug得到更快的解决。
一般而言,Bug的优先级可分为以下几个等级:1. 高优先级:指必须尽快解决的Bug,如系统崩溃、核心功能无法使用等严重影响系统正常运行的Bug。
2. 中优先级:指在Bug处理队列中紧随其后的Bug,如某些功能无法正常使用、数据出现错误等影响系统的Bug。
3. 低优先级:指不影响系统正常运行和核心功能的Bug,可能是一些小功能或界面问题。
根据Bug的优先级,开发人员可以合理安排解决Bug的顺序,优先处理对系统功能和使用影响较大的Bug,提高用户满意度和系统稳定性。
三、Bug管理与处理在软件开发和维护过程中,能够有效管理和处理Bug对于项目的进展和质量控制至关重要。
试述软件缺陷的严重性与优先级
试述软件缺陷的严重性与优先级作者:陈顺来源:《无线互联科技》2013年第08期摘要:严重性和优先级是软件缺陷的两个重要属性,在软件测试过程中如果对两者的概念、划分方法和关联性理解的不够准确,不但对缺陷的统计结果、缺陷报告的质量造成影响,而且还会延误软件的正常发布期限。
本文就如何正确区分和处理缺陷的严重性和优先级展开讨论,旨在提高软件质量、降低研发风险。
关键词:软件测试;缺陷;严重性;优先级缺陷的严重性是指缺陷对被测试系统造成的破坏程度的大小,这种破坏既包括缺陷对被测系统的影响程度,也包括缺陷妨碍系统使用的程度。
在软件测试中,判断缺陷的严重性应该从软件最终用户的角度出发,评估缺陷给用户造成的恶劣后果和产生的损失。
缺陷的优先级是指处理和修正软件缺陷先后顺序的指标,即哪些缺陷需要优先修正,哪些缺陷可以稍后修正。
确定软件缺陷优先级,更多的是站在软件开发工程师的角度考虑问题,因为缺陷的修正顺序是个复杂的过程,不纯粹是技术问题,而且开发人员更熟悉软件代码,能够比测试工程师更清楚修正缺陷的难度和风险。
1 四种错误和轻重缓急1.1 判断缺陷的4种错误正确处理和区分缺陷的严重性和优先级,是包括软件测试人员和开发人员在内的全体项目组成员的一件大事,对于经验不很丰富的项目组成员来说,经常会犯下述4种错误:①把低严重性的缺陷当作高严重性来处理。
②把高严重性的缺陷当作低严重性来处理。
③把低优先级的缺陷当作高优先级来处理。
④把高优先级的缺陷当作低优先级来处理。
在此,可以将这4种错误归结为2类,在测试工作中,犯了前2种错误说明在缺陷的判断上“不分轻重”,出现后2种错误则表示在缺陷的判断上“不分缓急”。
如果要在测试工作中准确判断缺陷的严重性与优先级,应该合理区分轻重缓急,这既是保证软件质量的重要环节,也是项目组成员能力与经验的最好体现。
1.2 何为缺陷的轻重缓急现代管理学之父彼得·德鲁克说过:“做事情必须分清轻重缓急。
BUG等级划分标准
B U G等级划分标准 Document number:NOCG-YUNOO-BUYTT-UU986-1986UTBUG等级划分方法一、测试BUG等级划分标准1、Blocker(崩溃):阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。
如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
2、Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。
如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
3、Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。
如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多,合理安排解决BUG,解决率关系版本的优化程度)4、Minor(次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。
如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)二、BUG状态标准1、待处理(new):测试人员或用户发现新问题后提交的状态2、已确认(open):经测试人员及研发人员讨论后确认是BUG,提交的状态,由测试人员来设置。
3、已处理(fixed):经研发人员确认是BUG后修复的状态,修改还没有验证,由开发人员来设置。
BUG 等级划分标准
BUG等级划分方法一、测试BUG等级划分标准1、Blocker(崩溃):阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。
如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。
2、Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。
功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。
如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
3、Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。
如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多,合理安排解决BUG,解决率关系版本的优化程度)4、Minor(次要):界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。
如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)二、BUG状态标准1、待处理(new):测试人员或用户发现新问题后提交的状态2、已确认(open):经测试人员及研发人员讨论后确认是BUG,提交的状态,由测试人员来设置。
3、已处理(fixed):经研发人员确认是BUG后修复的状态,修改还没有验证,由开发人员来设置。
4、已修改(closed):测试人员认为问题已经修改,通过验证,由测试人员设置。
bug优先级定义标准(一)
bug优先级定义标准(一)Bug优先级定义标准介绍在软件开发过程中,出现bug是不可避免的。
为了更好地管理和解决这些bug,我们需要一个明确的优先级定义标准,以确保团队在处理问题时能够有条不紊地进行工作。
本文将介绍一个常用的Bug优先级定义标准,帮助团队有效地解决bug。
Bug优先级定义标准根据问题的影响程度和紧急程度,我们可以将bug分为以下几个优先级:1.紧急 (Critical):–这类bug影响系统的核心功能,例如系统崩溃、无法登录等。
–这些bug需要立即解决,以确保系统的正常运行。
2.高 (High):–这类bug会显著影响系统的某些功能,但不会导致系统完全崩溃。
–例如,某些关键功能无法使用、页面上的错误信息无法正确显示等。
–这些bug需要在短期内解决,以确保用户体验。
3.中 (Medium):–这类bug对系统功能的影响相对较小,可能导致一些次要功能无法正常使用。
–例如,某些页面上的按钮功能无效、排版错乱等。
–这些bug需要在合理的时间范围内解决,以提高用户满意度。
4.低 (Low):–这类bug对系统的功能影响较小,可能只是一些视觉上的小问题或拼写错误等。
–例如,页面上的文本错误、图标显示不正确等。
–这些bug可以在开发周期内逐步解决,不会对整体系统运行产生重大影响。
如何确定优先级在确定bug的优先级时,可以考虑以下因素:•问题的影响程度:评估bug对系统功能和用户体验的影响程度。
•问题的紧急程度:评估bug需要多快修复以避免进一步影响。
同时,可以使用其他指标来细化优先级定义,例如:•复现概率:评估bug在何种环境下复现的概率,以确定其紧急性。
•影响范围:评估bug对用户的影响范围和用户数,以确定其影响程度。
•解决的工作量:评估修复bug所需的工作量和时间成本,以确定其优先级。
总结一个明确的Bug优先级定义标准可以帮助团队高效地管理和解决bug。
在定义bug的优先级时,需要综合考虑问题的影响程度、紧急程度、复现概率、影响范围和解决的工作量等因素。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
3、中:检查功能的一些细节,包括边界,配置测试
4、低:较少执行的测试用例,并不代表它不重要,而是说不是经常被运行。例如压力测试错误信息等。
用例级别设置的流程:
1、如果没有很多的时间来确定优先级,那么可以先大致的进行划分:
把所有功能性验证的用例标注为高
把边界值或错误能力的用例标注为中
bug的严重程度和bug对应的测试用例的优先级是平行的。
1、最高(又称Build Verification tests)也叫冒烟测试用例,一组你运行以确定这个build版本是否可测的测试用例。
2、高:这种用例运行,能发现重要的错误,或者它能够保证软件的功能是稳定的。俗称大的基本功能的测试用例
把非功能性和易用性的标注为低
2、提升和降级
针对1描述所有高级别的功能性用例划分为重要和不十分重要两种,然后重要的保持高,不十分重要的降级为中。同理,对应中级别的用例,重要的进行升级,不十分重要的保持中。对应低级别的,重要的升级,不十分重要的保持。
3、确定BVTs