一. Bug的严重等级定义: 1. Blocker 即系统无法执行.崩溃或严重资源不足.应用模块无法启动或异常退出.无法测试.造成系统不稳定. 严重花屏 内存泄漏 用户数据丢失或破坏 系统崩溃/死机/冻结 模块无法启动或异常退出 严重的数值计算错误 功能设计与需求严重不符 其它导致无法测试的错误, 如服务器500错误 2.Critical 即影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性. 功能未实现 功能错误 系统刷新错误 数据通讯错误 轻微的数值计算错误 影响功能及界面的错

1. Blocker级别——中断缺陷 客户端程序无响应,无法执行下一步操作. 2. Critical级别――临界缺陷,包括: 功能点缺失,客户端爆页. 3. Major级别——较严重缺陷,包括: 功能点没有满足需求. 4. Normal级别――普通缺陷,包括: 1. 数值计算错误 2. JavaScript错误. 5. Minor级别—一次要缺陷,包括: 1. 界面错误与UI需求不符. 2. 打印内容.格式错误 3. 程序不健壮,操作未给出明确提示. 6. Trivial级别——轻微缺陷,包括:

一.严重程序 P1:致命(该问题在测试中较少出现,一旦出现应立即中止当前版本测试) 阻碍开发或测试工作的问题:造成系统崩溃.死机.死循环,导致数据库数据丢失, 与数据库连接错误,主要功能丧失,基本模块缺失等问题.如:代码错误.死循环.数 据库发生死锁.重要的一级菜单功能不能使用.内存泄漏.严重计算错误.无法登录.无法正常退出.功能设计与需求严重不符,模块无法启动或调用,程序重启.自动退出, 关联程序间调用冲突等. P2:严重(不影响其他功能测试的情况下可以继续该版本测试) 系统主要功能部分丧失.

测试的问题大致可分为以下几个类型:致命问题严重问题一般问题轻微问题 判断标准如下1.致命问题:造成系统崩溃.死机.死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题.如:代码错误.死循环.数据库发生死锁.重要的一级菜单功能不能使用等2.严重问题:系统主要功能部分丧失.数据库保存调用错误.用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试.功能设计与需求严重不符,模块无法启动或调用,程序重启.自动退出,关联程序间调用冲突,安全问题.稳定性等.3.一般问题功能没有

软件测试中Bug的生命周期以及Bug的严重等级 我猜你们都会,但能说专业且全面不? 1.首先当测试人员接到一个项目或产品准备测试的时候,测试人员会根据测试用例一步步的来执行用例进行简单的功能测试.当测出一个Bug的时候,就是这个Bug被开始创建的状态(也就是被新建New): 2.当一个Bug出现,测试人员会将这个Bug递交给开发人员,让开发人员进行修复,这个时候Bug的生命周期就进入到了被指派的状态(Assigned): 3.当开发人员将这个Bug接到手之后会认证它到底是不是一个Bug,此时Bu

BUG等级划分,一般划分为:严重BUG.较严重BUG.一般性BUG.建议性BUG A类—严重错误,包括以下各种错误: 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误 B类—较严重错误,包括以下各种错误: 1． 程序错误 2． 程序接口错误 3． 数据库的表.业务规则.缺省值未加完整性等约束条件 C类—一般性错误,包括以下各种错误: 1． 操作界面错误(包括数据窗口内列名定义.含义

又属于一篇普及文,希望自己在被各种技术吸引的同时,能时常来整理和总结软件测试最基本的知识. 从刚工作时接触的第一个缺陷管理工具禅道,到redmine.JIRA.bugzilla ,再到现在的QC,当然还有其它种的开源的或商业的缺陷管理工具,它们的本质是一样的,就是来管理缺陷的生命周期. 其实,你理解任意的一款工具,其它的工具也一定能无师自通.这不谈某款工具,单把它本质的一些东西抽离出来与大家分享. Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法

一.BUG BUG:软件的缺陷 1.BUG的定义:----与软件测试的目的对应 软件的BUG,狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节.或与需求文档存在差异的功能实现等. 我们的职责就是,发现这些BUG,并提交给开发,让开发去修改. 2.BUG的类型 要确定一个BUG的类型,需要对项目(或产品)有比较深的理解.这个划分对于开发的定位问题影响很小,但对于问题类型的统计就比较重要了. 功能问题.设计缺陷.界面优化.性能问题.配置相关.安装

一.划分一个bug的等级 bug等级主要分为致命.严重.一般.轻微或者建议四个等级: 1.致命错误:系统无法执行.崩溃或严重资源不足.应用模块无法启动或异常退出.无法测试.造成系统不稳定.价值较高功能异常(比如与金钱相关的功能) 具体基本上可分为: (1)严重花屏 (2)内存泄漏 (3)安全问题 (4)用户权限问题 (5)网页无法正常打开 (6)严重的数值计算错误 (7)功能设计与需求严重不符 (8)系统崩溃/死机/冻结/死循环 (9)模块无法启动.调用或异常退出 (10)数据库数据丢失或破坏.

Bug的属性 Bug重现环境 这个应该是我们重现BUG的一个前提,如果没有这个前提,我们可能会无法重现问题,或者根本就无从下手. • 操作系统 这个是一般软件运行的一大前提,基本上所有的软件都依赖于操作系统之上的,对于一个软件来说,要想在某个操作系统上运行,必须要对这个操作系统支持,这就需要有针对性的设计与开发.对于不同的操作系统,其可能存在差异(如:win xp 与win 7)或本质的区别(如 win 7 与 CentOS linux),所以,操作系统环境是重现问题的一个重要前提. • 浏览器

禅道官网:http://www.cnezsoft.com/ 简介: 开源免费的项目管理软件.集产品管理.项目管理.测试管理一体以及事物管理组织管理的功能 使用原因: 开源 方便跟踪管理Bug 使用简单易学 及多种管理于一身 1.Bug操作流程 2.Bug的几种解决方案 已解决 延期处理 不予处理 外部原因: 第三方问题 设计如此: 无效Bug 无法重现: 无效Bug 重复Bug : 无效Bug 3.Bug等级简介 Priority: bug的重要性及其解决顺序. Notes: 程序员/工程师可以

怎样才能提交一个让开发人员拍手叫好的bug单 软件测试人员写得最多的文档就是测试用例和BUG,现在测试用例和BUG都没有标准的模板,每个公司使用的缺陷管理工具都有可能不一样,如果你换了一家公司就有可能接触到新的缺陷管理工具,但提交bug的方式却是大同小异,今天这篇文章主要讲解怎样才能提交一个高质量的BUG单. 目录 为什么要提交BUG单 缺陷管理工具 编写高质量的BUG单 为什么要提交BUG单 其实要提交BUG单的原因很简单,就是在测试过程中程序中出错了,那么测试人员就要提交BUG单,以便开发人

一.提单模板 标题:[项目组][模块][子模块][发生原因]问题简要描述描述:[预置条件] 有就写清楚,没有就写无[操作步骤]1.XXXXX2.XXXXXX3.XXXXX[实际结果] XXXXX[预期结果] XXXXXX[问题发生时间]——偶现的问题必须要写,必现问题可以不用写[设备信息]机器人SN号[复现概率]3/3[备注]如果有一些其他信息,可以写在这里 二.偶现bug 在上述提交bug要求上添加:1.填写复现概率(30次以上),寻找规律协助开发定位2.截图3.记录时间点4.记录设备编号5.

在为期一周的发布周中,我们将app本身最后的细节完善,功能代码到位,UI不断改进和优化,团队在开始准备发布之前,对整个APP进行了一次BUG检查,每个人都部署了app在自己的android设备上进行测试.一共发现了以下的bug. bug等级:高. bug位置:android代码. 现象:加载此页面程序崩溃弹出. 原因分析:图片尺寸太大导致图片加载时崩溃问题. 解决:缩小图片尺寸,修改加载函数. bug等级:中. bug位置:android代码. 现象:某些菜品价格显示为-1. 原因分析:爬虫对于

优先级定义如下: <版本前期阶段>(功能刚提测): [P0—紧急]:完全不能满足产品要求,基本功能明显未实现或完全不可用,阻塞测试流程与进度(核心功能流程) 1.功能未实现 .功能缺失 2.业务流程不正确 3.闪退 4.数据未上报 5.越权(付费与免费) 6.数据统计计算错误 7.用户信息丢失或错误,如升级及覆盖安装后数据异常 8.币种显示错误 9.严重视觉(UI)问题:核心页面 10.页面显示(元素不可点.核心页面错乱) 11.安全问题(XSS.SQL等注入) 12.系统兼容性问题导致主要功

对BUG的分析与理解 bug的分类 bug,其实就是软件期望的行为与实际行为的差异.从程序的角度来看,在软件整个生命周期中都会有bug的出现.需求分析过程中,需求理解的不足,导致的理解错位 ,遗漏甚至变化都可能导致bug:设计本身有好坏之分,但是bug本身还是比较隐晦,不是那么明显. 编码阶段,也会有理解错误,语言特性,第三方库框架,等等导致的bug. 后期打包,部署,运维也会产生 bug,打包的错误,配置错误,以及环境的错位. 自己主要谈谈编码引入的和环境的导致bug.这是最最经常碰到的bug

标题不是“一个馒头引发的血案”. 言归正传:今天上午测试的时候,发现了一个BUG,如图: 一个用肉眼就能发现的BUG.原因当然是因为开发同事没有自测试,流入到了测试人员这里了. 无非是开发同事不严谨造成的,无可厚非.(不想从态度与能力,业务理解角度考虑) 这件事情是起因,联想到接触到各色的开发同事,对待测试人员找到BUG后的反应与态度. 有埋怨,不屑,有吃惊,感激,甚至碰到了害怕的开发同事. 一:我想说,对于测试人员找到的BUG,优化,建议也好,持埋怨,不屑的开发同事,基本都是初级,中级的开发.

itest 简介 test 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发版频繁,需求常变,itest还可导出用例,线下修改.执行,新增后再导入(同步)到线上:且可根据测试策略来设置测试流程,并可实时调整:在测试看板中,能查看迭代报告,测试包执行情况,测试任务进展,也可以在看板上直接执行用包用例,具体介绍详见下面开源中国连接:itest 入围2019 最受欢迎国产开源软件

itest 简介 test 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发版频繁,需求常变,itest还可导出用例,线下修改.执行,新增后再导入(同步)到线上:且可根据测试策略来设置测试流程,并可实时调整:在测试看板中,能查看迭代报告,测试包执行情况,测试任务进展,也可以在看板上直接执行用包用例,具体介绍详见下面开源中国连接:itest 入围2019 最受欢迎国产开源软件

作者|孙敏 为什么要做Bug分析? Bug是项目过程中的一个有价值的虫子,它不只是给开发的,而是开给整个项目组的. 通过Bug我们能获得什么? 积累测试方法,增强QA的测试能力,提升产品质量 发现项目过程中的问题,推动优化解决问题:以及可以用来侧面验证流程优化是否有效 提高开发的编码能力,做到Bug预防 项目过程中不可能没Bug,但是我们要利用已有Bug减少未来Bug数,提高产品质量. Bug包含了哪些信息可以分析? Bug本身的信息 标题.描述(操作步骤.预期结果.实际结果.截图等附加信息.环