bug严重程度或等级划分（urgent 致命,high 严重,medium 中等,low 轻微，低级)
致命urgent：
通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：
1.内存泄漏
2.系统容易崩溃
3.功能设计与需求严重不符
4.系统无法登陆
5.循坏报错，无法正常退出。
严重\高high：
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性
比如：
1.功能未实现；
2.功能存在报错；
3.数值轻微的计算错误
一般/中等medium：
通常表现为：界面、性能缺陷
比如：
1.边界条件下错误
2.大数据下容易无响应
3.大数据操作时，没有提供进度条
轻微/低low：
通常表现为：易用性及建议性问题
比如：
1.界面颜色搭配不好
2.文字排列不整齐
3.出现错别字，但是不影响功能
4.界面格式不规范
（注：文档可能无法思考全面，请浏览后下载，供参考。可复制、编制，期待你的好评与关注！）
缺陷严重级别定义: 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 ： 测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。 严重(Serious) BUG： 系统的次要功能点或需求点没有实现；数据丢失或损坏。执行软件主要功能的测试用例导致系统出错，程序无法正常继续执行；程序执行过于缓慢或是占用过大的系统资源。 一般(Minor) BUG： 软件的实际执行过程与需求有较大的差异；系统运行过程中偶尔（<10%）有出错提示或导致系统运行不正常。 微小(Information) BUG： 软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。
缺陷等级定义 目录 缺陷等级定义 (1) B/S架构(Web)测试的缺陷等级定义： (1) C/S架构(Client)测试的缺陷等级定义： (2) 服务器及接口测试的缺陷等级定义： (4) B/S架构(Web)测试的缺陷等级定义： A: 致命 1.正常的用户操作导致浏览器崩溃或无响应 2.产品核心功能没有实现或无法使用 3.程序实现与需求严重不符 4.其他导致无法测试的错误 5.严重的数值计算错误 6.存在致命的安全漏洞 7.Bug被重开3次以上含3次 8.上线前最后一个版本配置管理出现问题 B: 严重 1.产品功能实现不正确 2.主业务流程对应的功能未实现，阻碍测试继续进行 3.严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定 位； 4.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率20%以上） 5.程序实现与需求功能上不符 6.其他导致部分模块无法测试的错误 7.主要数值计算错误 8.严重的功能逻辑错误 9.Bug被重开2次 10.上线前进入最后一轮测试时版本配置管理出现问题 C: 较严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率10%以下） 2.用户非常规操作导致浏览器崩溃或影响系统性能的问题
3.程序上非主要功能与需求上功能描述不符 4.功能实现错误但不影响主要流程 5.轻微的数值计算错误 6.页面出现JS错误且导致某功能不可用 7.兼容性导致的主要功能问题 8.系统中用户权限实现有误 9.初始化错误 10.Bug被重开1次 11.上线前进入测试时，提交测试的过程版本配置管理出现问题 12.操作界面UI类的严重错误，易造成大量投诉，产生较坏影响力 D: 一般性问题主要为：界面类、容错类缺陷 1.操作界面UI类的一般性错误 2.边界条件下错误 3.提示信息错误（包括未给出信息、信息提示错误等） 4.界面中操作焦点错误（如按Tab键未顺序操作，弹出其他窗口后主界面焦点位置错误等） 5.输入域的相关问题，如：输入框长度判断错误； E:易用性和建议类缺陷 1.界面格式等不规范 2.辅助说明描述不清楚 3.操作时未给用户提示 4.可输入区域和只读区域没有明显的区分标志 5.个别不影响产品理解的错别字 6.文字排列不整齐等一些小问题 7.建议类型的缺陷 C/S架构(Client)测试的缺陷等级定义： A: 致命 1.程序无法运行/模块无法启动/异常退出 2.程序导致操作系统崩溃/死机/蓝屏 3.程序实现与需求严重不符 4.程序实现与技术文档严重不符 5.程序实现与开发规范严重不符 6.导致产品无法继续进行测试的缺陷 7.程序占用资源高（比同类产品高出50%以上） 8.内存、GDI等泄漏 9.Bug被重开3次以上含3次 10.上线前最后一个版本配置管理出现问题
附录E（资料性附录）输电线路缺陷分类 E1架空线路紧急缺陷 E1.1防护区 1.江河泛滥、山洪、泥石流、杆塔被淹。 2.森林起火。 3.威胁线路安全的工程设施（如高大机械及可移动的设施）。 4.导线与弱电线路、电力线路交叉或接近的距离小于重大缺陷表1规定数值的80%。 5.导线对树木的距离小于重大缺陷表2规定数值的80%。 6.导线对建筑物的距离小于重大缺陷表3规定数值的80%。 7.导线对地距离小于重大缺陷表4规定数值的80%。 8.防护区内有严重污染源，绝缘爬距不够，有可能造成线路污闪。 E1.2基础 1.基础受洪水冲刷或淹没，致使基础外露，出现不稳定现象或已经倾斜。 2.杆塔基础或拉线基础已经明显上拔或沉陷，并有发展趋势。 3.杆塔或拉线基础移位。 4.基础受到严重的外力破坏。 E1.3杆塔 1.杆塔上悬挂有可能造成接地短路的铁丝、绳线或其它异物。 2.缺塔材11根及以上。 3.水泥杆焊口断裂。 4.杆塔倾斜严重，倾斜值超过重大缺陷表5规定要求。 E1.4导线与地线 1.导地线断股、损伤到需切断重接的程度，超过重大缺陷表6规定数值。 2.导线上挂有较长的铁丝、绳线或其它异物，并随时有可能危及线路安全运行。 3.导线连接器过热、烧伤。 E1.5绝缘子 1.绝缘子串每串中零值、低值、劣化、破损、裂纹或烧伤的绝缘子数量超过重大缺陷表7规定数值。 2.绝缘子串上挂有异物，极易造成接地。 3.针式绝缘子、瓷横担绑线松动、断脱、烧伤。 E1.6金具
1.交叉跨越处导线线夹未就位、未固定。 2.张力金具严重锈蚀、断裂、变形或缺件，并随时有可能危及线路安全运行。 E1.7拉线 3.拉线或拉线下把被破坏（或被盗）。 4.拉线断股达7股断2股，19股断3股者，损伤截面超过表6规定者。 E2架空线路重大缺陷 E2.1防护区 1.在杆塔、拉线基础周围倾倒酸、碱、盐及其他有害化学物品。 2.利用杆塔拉线作起重牵引地锚。 3.在杆塔内或杆塔与拉线之间修建车道。 4.在杆塔、拉线基础周围5～10m的区域内取土、打桩、钻探、开挖。 5.杆塔上方有危石，滚落时可能伤害基础或铁塔。 6.线路附近有影响线路运行安全的采石场或采矿厂。 7.防护区内未经供电部门批准进行建筑施工。 8.安全距离不符合要求的栅架、招牌、天线等。 9.防护区内进行爆破作业。 10.换算到+40℃时，导线与弱电线路、电力线路交叉或接近的最小垂直距离小于表1的基本要求。 表1 导线与弱电线路、电力线路交叉或接近的最小垂直距离 l) 在最大风偏、最大弧垂时，导线与树木之间的最小安全距离小于表2所列数值。 表2 最大风偏、最大弧垂时，导线与树木的最小安全距离 2) 导线在最大弧垂、最大风偏时与建筑物的最小安全距离小于表3数值。 表3 导线在最大弧垂、最大风偏时与建筑物的最小安全距离
目录 1前言 (2) 2文档范围 (2) 3文档对象 (2) 4.用例级别 (2) 5.BUG等级划分 (3) 6.BUG发生率 (4) 7.Bug修改优先级 (5) 8.BUG修改优先级与BUG严重性的分别 (7)
1前言 为了使技术平台开发的软件测试更加规范，STE组制定了一系列和缺陷相关的标准。制定此标准的另一目的是便于平台和产品的相关人员对STE在平台中提出的软件缺陷的等级 和修改优先级达成共识。 2文档范围 描述了技术平台开发中和软件缺陷相关的内容。内容包括：用例级别、Bug等级、Bug 发生率、Bug修改优先级。 3文档对象 技术开发全体软件成员及其他组的相关人员。 4.用例级别 用例级别表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果，而是对应用例的基本程度，一个可能导致死机的用例未必是高级别的，因为其触发条件可能相当生僻。测试用例的级别分4级，如下表。 下面是用例级别的具体分类和内容： Level 1-级别“1”：基本 该类用例涉及系统正常的基本功能。该用例执行的失败会导致多处重要功能无法运行的。如果不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。 此级别用例用于版本提交时作为“版本冒烟测试通过准则”。如存在不通过的项目时可考虑重新提交版本，例如“申请书不能添加成功”或者“WIFI不能连接”等。1级用例的数量应受到控制。 Level 2-级别“2”：重要 该类测试用例涉及系统的重要功能。主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例。该类用例最常执行以保证功能是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。 该类测试用例在非回归的系统测试版本（即在新Feature和TPM版本计划中的正式版本）中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是否进行测试。
缺陷严重级别定义: 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）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现 功能，没有达到预期的效果。如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等
BUG等级划分方法 一、测试 BUG等级划分标准 1、Blocker （崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致 数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。 2、 Critical （严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失， 一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。 如：软件中数据保存后数据库中显示错误，用 户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。 3、 Major （一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响 系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错 误，删除没有确认框、数据库表中字段过多等 ( 该问题实际测试中存在最多，合理安排解决 BUG，解决率关系版本的优化程度 ) 4、 Minor （次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化 性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正 确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理） 二、BUG状态标准 1、待处理（ new）：测试人员或用户发现新问题后提交的状态 2、已确认（ open）：经测试人员及研发人员讨论后确认是BUG，提交的状态， 由测试人员来设置。 3、已处理（fixed ）：经研发人员确认是BUG后修复的状态，修改还没有验证， 由开发人员来设置。 4、已修改（ closed ）：测试人员认为问题已经修改，通过验证，由测试人员 设置。 5、仍存在（ reopened）：测试人员认为BUG未修复成功，问题仍然存在，由 测试人员设置。 6、不是问题（ reject ）：研发人员确认不是BUG，或者建议与意见决定不采 纳。 7、暂不处理（ hold ）：当前版本不做修改，后续版本再考虑，由研发人员或测试人 员设置。 三、BUG处理流程
BUG等级划分方法 一、四级的划分方式： 1.BUG等级划分建议： 目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。 ● 致命(可对应目前BUG体系中的“非常严重”)： 致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 具体基本上可分为： ○严重花屏 ○内存泄漏 ○用户数据丢失或破坏 ○系统崩溃/死机/冻结 ○模块无法启动或异常退出 ○严重的数值计算错误 ○功能设计与需求严重不符 ○其它导致无法测试的错误 ● 严重(可对应目前BUG体系中的“严重”) 严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 具体基本上可分为： ○功能未实现 ○功能错误
○系统刷新错误 ○语音或数据通讯错误 ○轻微的数值计算错误 ○系统所提供的功能或服务受明显的影响 ● 一般(可对应于目前BUG体系中的“普通”) 一般性问题主要为：界面、性能缺陷 具体基本上可分为： ○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误 ○提示信息错误(包括未给出信息、信息提示错误等) ○长时间操作无进度提示 ○系统未优化(性能问题) ○光标跳转设置不好，鼠标(光标)定位错误 ● 提示(可对应于目前BUG体系中的“轻微及建议”) 提示性问题主要为：易用性及建议性问题 具体基本上可分为： ○ 界面格式等不规范 ○ 辅助说明描述不清楚 ○ 操作时未给用户提示 ○ 可输入区域和只读区域没有明显的区分标志 ○ 个别不影响产品理解的错别字
1.1bug定义表 缺陷等级详细含义： 一级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩溃或挂起等导致系统不能继续运行。 包括以下各种错误： 1.由于程序所引起的死机,非法退出 2.死循环 3.数据库发生死锁 4.因错误操作导致的程序中断 5.重大功能错误 6.与数据库连接错误 7.数据通讯错误 二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。 包括以下各种错误： 1.程序接口错误 2.因错误操作迫使程序中断
3. 系统可被执行，但操作功能无法执行（含指令） 4. 单项操作功能可被执行，但在此功能中某些功能（含指令参数的使用）无法被执行（对系统非致命的） 5. 在功能项的某些项目（选项）使用无效（对系统非致命的） 6.业务流程不正确 7.功能实现不完整，如删除时没有考虑数据关联 8.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 9. 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误） 三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 包括以下各种错误： 1.操作界面错误（包括数据窗口内列名定义、含义是否一致） 2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 3.简单的输入限制未放在前台进行控制 4.删除操作未给出提示 5.虽然正确性不受影响，但系统性能和响应时间受到影响 6.不能定位焦点或定位有误，影响功能实现 7. 显示不正确但输出正确 8. 增删改功能，在本界面不能实现，但在另一界面可以补充实现。 四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。 包括以下各种错误： 1.界面不规范 2.辅助说明描述不清楚 3.输入输出不规范
不能完全满足系统要求，系统停止运行，系统的重要功能无法运行，系统崩溃或者挂起等导致系统不能继续运行。 修改优先级为最高，该级别问题需要立即修改。 1、系统崩溃； 2、导致程序重启、死机或者非法退出； 3、关键功能不能实现使得后续工作无法进行； 4、死循环； 5、数据丢失或异常。 高级问题： 严重的影响系统要求或基本功能的实现，且没有更正方法（重新安装或重新启动该软件不属于更正方法）。使系统不稳定、或破坏数据、或产生错误结果、或部分功能无法执行，而且常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。 修改优先级为高，该级别需要程序员尽快修改。 1、功能不符合需求、实现不正确； 2、数据计算错误； 3、程序接口错误； 4、误操作迫使程序中断或者报错。 中级问题： 系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 修改优先级为中，该级别需要程序员修改。 1、数据长度不一致； 2、内容或格式错误； 3、响应速度较慢； 4、提示不正确但输出结果正确； 5、操作界面错误（包括数据窗口内列名定义、含义是否一致）； 6、简单的输入限制未放在前台进行控制； 7、虽然正确性不受影响，但系统性能和响应时间受到影响。
使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方面等需要完善的小问题。 修改优先级为低，该级别需要程序员修改或不修改。 1、界面不规范； 2、辅助说明描述不清楚； 3、输入输出不规范； 4、长时间的操作未给用户提示； 5、提示用语不规范； 6、可输入区域和只读区域没有明显的区分标志； 7、必填项与非必填项没有加以区别； 8、界面不能及时刷新，影响功能实现； 9、功能模块名称、标题等不一致； 10、界面、网页、图片出现错别字。 建议优化： 希望提出的建议进行但不强制进行的修改。不会给发布的准确性或可用性带来任何严重影响。 修改优先级为低，该级别需要程序员修改或不修改。 1、各种提示框信息使用不统一； 2、界面显示或描述建议； 3、光标跳转设置不好，光标定位错误； 4、其他建议性问题。
缺陷等级划分规定 １．缺陷等级划分规范 １．１Bug等级种类及定义: Bug等级可分为:致命,严重,一般的,微小的四种. 致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失 严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明 一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等 微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等 １．２等级划分步骤: 1) 功能方面 结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分. ”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少. 不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的. 偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%. 很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的. “缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性. 灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求； 障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。执行软件主要功能的测试用例导致系统出错，程序无法正常继续执行；程序执行过于缓慢或是占用过大的系统资源。 干扰性(Disturbing):一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。 具体等级划分参照表如下:
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 只有在极端条件下才会重现的Bug 2 在特定配置情况下不会出现的Bug 3 操作界面错误（包括数据窗口内列名定义、含义是否一致） 4 边界条件下错误 5 提示信息错误 6系统未优化，性能问题 7 兼容性问题（有一定用户群体，影响较大） 低（4类）轻微-- 不影响当前发布，可以推迟到下一个发布中修复，即易用性及建设性问题 1 不能稳定重现的Bug 2 因为电脑上装有其他干扰软件产生的Bug 3 非功能性Bug, 如日志，错误回复等 4 界面规格不规范 5 辅助说明描述不清 6 操作时未给用户提示信息 7 个别不影响产品功能的错别字 8 文字排列不整齐
Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。 操作系统 这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。浏览器 对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。 不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug 前提条件之一。 其它（这个“其它”非常重要） 对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。 对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本
软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。 问题类型 根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。 JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。） Bug : 测试过程、维护过程发现影响系统运行的缺陷。（这就是一般测试人员所提交的bug）New Feature : 对系统提出的新功能。（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。） Task : 需要完成的一任务。（开发或测试任务指派。） Improvement : 对现有系统功能的改进。（一般产品经理或产品体验师做的事）当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。 Bug 类型： 这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。 下面看一些常见的分类：
新终端游戏缺陷严重级别分类标准V0.2 定义以下四类缺陷：致命、严重、一般、建议 致命——所有会导致游戏无法运营的问题，对用户来说，这是必须立即修复的（随机性或影响部分用户的缺陷可排后修复），包括： 1.核心系统功能问题： ●核心系统出现功能性Bug（核心系统：游戏核心玩法和玩家正常体验所涉及的 系统），这些bug导致基础游戏体验无法进行。核心系统定义请参见《附件1： 核心系统和关键路径的定义.doc》 2.稳定性问题： ●有必现的崩溃、假死或导致终端死机、重启的问题 ●客户端进行正常功能体验和游戏流程时，频繁崩溃（在两个小时内崩溃3次以上）。正常体 验不包括非常规性操作，破坏性操作，反编译修改等操作。 ●需要7*24运行的服务器的出现core dump。 ●服务器和客户端存在必现的持续内存泄漏和资源泄漏问题。 3.性能问题：客户端和服务器有明显的性能问题。 ●客户端：在设定的游戏场景和硬件基线上，游戏帧率低于目标标准一半以上；cpu/内存、 流量、电量指标低于开发和测试目标标准一半以上；游戏的关键路径加载延迟低于目标标 准一半以上。 说明：a）游戏不同类别可以有不同的指标，需要产品、开发、测试等在系统设计初就共同确定目标值。b）关键路径定义请参见《附件1：核心系统和关键路径的定义.doc》 ●服务器：在指定的测试服务器上，该模块的实际可达容量低于设定可达容量一半以上；以 及其它性能维度低于设定目标一半以上。常用性能测试纬度包括在线人数，平均响应时间， 存储容量，带宽bps，专线占用，消息处理能力，CPU占用率，内存占用率，数据库读写次 数等。 4.安全类问题： ●所有金钱、物品复制类错误；
文档名缺陷等级定义说明文档撰写人方杰 缺陷等级定义 目录 缺陷等级定义 (1) B/S架构(Web)测试的缺陷等级定义： (1) C/S架构(Client)测试的缺陷等级定义： (3) 服务器及接口测试的缺陷等级定义： (4) B/S架构(Web)测试的缺陷等级定义： A: 致命 1.正常的用户操作导致浏览器崩溃或无响应 2.产品核心功能没有实现或无法使用：例如博客不能发博文、播放器无法播放视频、邮箱 无法登录、不能收发邮件 3.程序实现与需求严重不符：例如一个程序改版只为了按需求增加统计功能，但程序没有 统计功能或有统计输出但并非是要统计的数据 4.其他导致无法测试的错误：例如没有新功能入口 5.严重的数值计算错误：例如算法设计错误，导致计算结果错误 6.存在致命的安全漏洞：例如密码不匹配也可登录、密码暴露在URL串中、复制最高权限 登录后的页面链接在其他进程浏览器中，无需再次验证即可拥有最高权限 7.Bug被重开次数>=3次，如果原来bug定级为A，则无需改变缺陷级别 8.上线前最后一个版本配置管理出现问题 B: 严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率20%以上） 2.主业务流程对应的功能没有实现或实现不正确，阻碍测试继续进行 3.程序上主要功能实现与需求不符 4.其他导致部分模块无法测试的错误 5.主要数值计算错误：例如需要统计5类数据，但只有3类数据被统计 6.XSS漏洞等安全性问题 7.1 文档名缺陷等级定义说明文档撰写人方杰 9.主要页面404、502或其他问题 10.严重的功能逻辑错误 11.严重的操作权限错误，对用户数据造成严重影响，如博客的访客可以做删除博文操作等 12.严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定 位 13.页面下载明显缓慢或接口调用明显缓慢并可能导致功能无法使用等性能问题 C: 较严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率10%以下） 2.用户非常规操作导致浏览器崩溃或影响系统性能的问题 3.次业务流程对应的功能没有实现或实现错误，但不影响测试继续进行：例如不能修改昵 称等非主要问题 4.程序上主要功能的分支或非主要功能与需求不符 5.轻微的数值计算错误：对于取整类、四舍五入类的计算，异常操作的输出未被计算在内 6.Bug被重开次数=1次，如果原来bug定级为A或B，则无需改变缺陷级别 7.上线前进入测试时，提交测试的过程版本配置管理出现问题 8.初始化错误：如统计中的初始值 9.输入域执行SQL、JS等代码的问题 10.系统中用户权限实现有误 11.兼容性导致的主要功能问题 12.CSS错乱等严重的样式问题 13.页面出现JS错误且导致某功能不可用 D: 一般性问题主要为：界面类、容错类缺陷 1.次要功能的分支与需求不符 2.操作界面UI类错误：例如显示折行、溢出等样式问题 3.边界条件下错误、输入域的边界问题 4.输入域对特殊字符处理的相关问题 5.提示信息错误（包括未给出信息、信息提示错误等） 6.界面中操作焦点错误（如按Tab键未顺序操作，弹出其他窗口后主界面焦点位置错误等） 7.输入域的相关问题，如：输入框长度判断错误 8.非主流浏览器出现的一些可替代的功能异常 E:易用性和建议类缺陷 1.界面格式等不规范 2.一些边角的样式问题 3.需求未定义的一些页面展现，如Title显示不正确等 测试管理规 修订历史记录 测试准入和准出标准 1.1.系统测试准入标准 （1）开发人员编码结束，并已完成单元测试； （2）需求说明书规定的功能或该阶段版本提交的功能均已实现； （3）被测系统的基本流程可以走通，界面上的功能均实现，符合设计文档规定的功能；（4）开发人员提交被测系统的最新版本，安装测试通过； （5）开发人员向测试负责人提交测试申请。 1.2.系统测试暂停、停止标准 （1）被测系统在进行功能测试时，发现程序存在重大bug（1级bug超过2个）或bug过多时（2级bug超过4个），测试工作无常进行，可以暂停测试返回开发； （2）被测项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据； （3）存在其他优先级更高的任务时，可向领导申请暂停测试； （4）被测项目在其开发生命周期出现重大估算、进度偏差，需暂停或终止时，测试应随之暂停或终止，并备份暂停或终止点数据归档； （5）被测系统经过系统测试，达到系统测试准出标准，可以停止测试。 1.3.系统测试恢复标准 （1）重大bug被解决或程序通过重新修正； （2）优先级更高的任务已经被完成； （3）软件项目被调整后重新启动，测试任务应随之启动。 1.4.系统测试准出标准 1.5.系统回归测试准出标准 1.6.UAT验证回归测试准出标准 1.7.UAT验收测试准出标准 1.8.上线回归测试准出标准 一、系统错误类型 本文只定义系统测试错误，定义以下五个级别测试错误类型。 一级：严重错误，包括以下各种错误： 1．由于程序所引起的死机,非法退出 2．死循环 3．数据库发生死锁 4．因错误操作导致的程序中断 5．功能错误（业务逻辑错误、流程控制错误） 6．与数据库连接错误 7．数据通讯错误 8．404，500等浏览器报错 二级：较严重错误，包括以下各种错误： 1．程序错误 2．程序执行界面未有反应 3．程序接口错误 4．数据库的表、业务规则、缺省值未加完整性等约束条件三级：一般性错误，包括以下各种错误： 1．操作界面错误（包括数据窗口列名定义、含义是否一致） 2．打印容、格式错误 3．简单的输入限制未放在前台进行控制 4．删除操作未给出提示 5．数据库表中有过多的空字段 四级：较小错误，包括以下各种错误： 附录E： 缺陷分类分级管理 根据输变电设备运行管理标准中设备缺陷的分类原则，设备缺陷按其严重程度分为紧急、重大、一般。 1.一般缺陷：是指对近期安全运行影响不大的缺陷，可列入年、季检修计划或日常维护工作中去消除 2.重大缺陷：是指缺陷比较严重，但设备仍可短期继续安全运行，该缺陷应在短期内消除，消除前应加强监视 3.紧急缺陷; 是指严重程度以使设备不能继续安全运行，随时可能导致发生事故或危及人身安全的缺陷，必须尽快消除或采取必要的安全技术措施进行临时处理 根据供电系统常用电气设备运行状况中的缺陷进行整理，对缺陷现状进行分类分级管理，并制定缺陷处理计划及措施，跟踪缺陷处理进度、完成情况，对已处理缺陷及时进行关闭，规范化管理设备缺陷，参照设备缺陷分类分级实施细则。 1 变电站设备缺陷分类标准 1.1 变压器（消弧线圈、接地变、站用变、电抗器参照执行）3 1.2 断路器4 1.3 隔离开关5 1.4 母线6 1.5 防雷设备6 1.6 电力电缆7 1.7 控制电缆8 1.8 继电器8 1.9 表计9 1.10 电力电容器10 1.11 电压、电流互感器、耦合电容器、阻波器10 1.12 继电保护及自动装置11 1.13 直流设备12 1.14 土建部分13 1.15 变电其它设备14 2 通讯、计算机、远动、消防系统分类标准15 2.1 通讯15 2.2 计算机系统16 2.3 远动部分16 2.4 消防系统17 3 电力线路设备缺陷分类标准18 3.1 导线及架空地线18 3.2 绝缘子及金具19 3.3 杆塔20 3.4 横担20 3.5 拉线21 3.6 柱上开关21 3.7 配电变压器及令克22 3.8 避雷器22 3.9 接地装置23 3.10 线路电力电缆23 附件1：设备缺陷记录25 附件2：线路缺陷记录26 需求规格说明书 1. 引言 1.1编写目的 软件缺陷跟踪管理系统在现代软件开发中已经占据了很重要的位置。每一个软件组织都知道必须妥善处理软件中的缺陷，这是关系到软件组织生存、发展的质量根本。所以我们要熟悉了解软件跟踪管理系统的基本流程。 1.2项目背景 软件名称：软件缺陷跟踪管理系统软件。 1.3定义 软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。 为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。 作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，处理意见，错误记录的当前状态。 缺陷就是：不满足用户确定的需求；软件使用当中出现的问题；不符合设计要求。 2．任务概述 2.1缺陷管理的目标 （1）确保被发现的缺陷能够被解决；这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致； （2）收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式； （3）收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 2.2 缺陷管理的一般流程 缺陷信息提交后，会进行分配，进入待修正状态。通常情况下，被分配的开发人员会负责对它进行修复。然后由测试人员进行验证，验证通过后就会被关闭。如果没有通过验证，就会交给开发人员进行修复。但开发人员基于某种原因或理由，也可能会拒绝修改，这时会交给评审委员会进行评审，如果通过评审，则这个缺陷会被关闭，否则开发人员还是要继续进行修复。 焊缝等级分类及无损检测要求 焊缝应根据结构的重要性、荷载特性、焊缝形式、工作环境以及应力状态等情况，按下述原则分别选用不同的质量等级， 1. 在需要进行疲劳计算的构件中，凡对接焊缝均应焊透，其质量等级为 1) 作用力垂直于焊缝长度方向的横向对接焊缝或T形对接与角接组合焊缝，受拉时应为一级，受压时应为二级； 2）作用力平行于焊缝长度方向的纵向对接焊缝应为二级。 2 .不需要计算疲劳的构件中，凡要求与母材等强的对接焊缝应予焊透，其质量等级当受拉时应不低于二级，受压时宜为二级 3 .重级工作制和起重量Q≥50t吊车梁的腹板与L冀缘之间以及吊车析架上弦杆与节点板之间的T形接头焊缝均要求焊透．焊缝形式一般为对接与角接的组合焊缝，其质量等级不应低于二级 4 .不要求焊透的’I'形接头采用的角焊缝或部分焊透的对接与角接组合焊缝，以及搭接连接采用的角焊缝，其质量等级为： 1)对直接承受动力荷载且需要验算疲劳的结构和吊车起重量等于或大于50t的中级工作制吊车梁，焊缝的外观质量标准应符合二级； 2) 对其他结构，焊缝的外观质量标准可为二级。 外观检查一般用目测，裂纹的检查应辅以5 倍放大镜并在合适的光照条件下进行，必要时可采用磁粉探伤或渗透探伤，尺寸的测量应用量具、卡规。 焊缝外观质量应符合下列规定: 1 一级焊缝不得存在未焊满、根部收缩、咬边和接头不良等缺陷，一级焊缝和二级焊缝不得存在表面气孔、夹渣、裂纹和电弧擦伤等缺陷； 2 二级焊缝的外观质量除应符合本条第一款的要求外，尚应满足下表的有关规定； 3 三级焊缝的外观质量应符合下表有关规定 设计要求全焊透的焊缝，其内部缺陷的检验应符合下列要求: 1 一级焊缝应进行100%的检验，其合格等级应为现行国家标准《钢焊缝手工超声波探伤方法及质量分级法》(GB 11345)B 级检验的Ⅱ级及Ⅱ级以上； 2 二级焊缝应进行抽检，抽检比例应不小于20%，其合格等级应为现行国家标准《钢焊缝手工超声波探伤方法及质量分级法》(GB 11345)B级检验的Ⅲ级及Ⅲ级以上； 3 全焊透的三级焊缝可不进行无损检测。 4 焊接球节点网架焊缝的超声波探伤方法及缺陷分级应符合国家现行标准JG/T203-2007《钢结构超声波探伤及质量分级法》的规定。 5 螺栓球节点网架焊缝的超声波探伤方法及缺陷分级应符合国家现行标准JG/T203-2007《钢结构超声波探伤及质量分级法》的规定。 6 箱形构件隔板电渣焊焊缝无损检测结果除应符合GB50205-2001标准第7.3.3 条的有关规定外，还应按附录C 进行焊缝熔透宽度、焊缝偏移检测。 7 圆管T、K、Y 节点焊缝的超声波探伤方法及缺陷分级应符合GB50205-2001标准附录D的规定。 8 设计文件指定进行射线探伤或超声波探伤不能对缺陷性质作出判断时，可采用射线探伤进行检测、验证。 9 射线探伤应符合现行国家标准《钢熔化焊对接接头射线照相和质量分级》(GB 3323)的规定，射线照相的质量等级应符合AB 级的要求。一级焊缝评定合格等级应为《钢熔化焊对接接头射线照相和质量分级》(GB 3323)的Ⅱ级及Ⅱ级以上，二级焊缝评定合格等级应为《钢熔化焊对接接头射线照相和质量分级》(GB 3323)的Ⅲ级及Ⅲ级以上。 10 以下情况之一应进行表面检测: 1）外观检查发现裂纹时，应对该批中同类焊缝进行100%的表面检测； 2）外观检查怀疑有裂纹时，应对怀疑的部位进行表面探伤； 3）设计图纸规定进行表面探伤时； 4）检查员认为有必要时。 铁磁性材料应采用磁粉探伤进行表面缺陷检测。确因结构原因或材料原因不能使用磁粉探伤时，方可采用渗透探伤。磁粉探伤应符合国家现行标准《焊缝磁粉检验方法和缺陷磁痕的分级》(JB/T 6061)的规定，渗透探伤应符合国家现行标准《焊缝渗透检验方法和缺陷迹痕的分级》(JB/T 6062)的规定。磁粉探伤和渗透探伤的合格标准应符合外观检验的有关规定。设计要求全焊透的一、二级焊缝应采用超声波探伤进行内部缺陷的检验，超声波探伤不能对缺陷作出判断时，应采用射线探伤，其内部缺陷分级及探伤方法应符合现行国家标准《钢焊缝手工超声波探伤方法和探伤结果分级》GB11345或《钢熔化焊对接接头射结照相和质量分级》GB3323的规定。 焊接球节点网架焊缝、螺栓球节点网架焊缝及圆管T、K、Y形点相贯线焊缝，其内部缺陷分级及探伤方法应分别符合国家现行标准JG/T203-2007《钢结构超声波探伤及质量分级法》、《建筑钢结构焊接技术规程》JGJ81的规定。一级、二级焊缝的质量等级及缺陷分级应符合下表的规定。 一、二级焊缝质量等级及缺陷分级测试错误类型与准入准出评定标准
缺陷分类分级管理
(完整版)Bug(缺陷管理)需求规格说明书
焊缝等级分类及无损检测要求
相关主题
文本预览