缺陷等级一般划分为四个等级:致命.严重.一般.低 一.致命(一级bug) 通常表现为:系统无法运行,崩溃或严重资源不足,应用模块无法启动或者异常退出,主要功能模块无法使用. 比如: 1.系统崩溃(蓝屏) 2.功能设计与需求严重不符 3.系统无法登录 4.产品无法运行 5.内存泄漏 6.错误操作导致的程序中断 二.严重(二级bug) 通常表现为:影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性. 比如: 1.功能未实现 2.功能出现异常 3.数据错误 三.一般(三级bug) 通常表

Priority()和Severity(严重程度)是Bug的两个重要属性.很多新人经常混淆这两个概念. 通常,人员在提交Bug时,只定义Bug的Severity, 即该Bug的严重程度, 而将Priority交给Project Leader 或Team Leader来定义,由他们来决定该Bug被修复的优先等级. 某种意义上来说,Priority的定义要依赖于Severity,在大多数情况下,Severity越严重,那这个Bug的Priority就越高. 你知道如何合理定义bug的Sevrity么

1 编写目的 本文档是对独立测试阶段发现的缺陷(bug)按照严重等级进行分类,确保测试出的缺陷得到正确的理解,以方便缺陷的修改.回归测试工作可以顺利进行,同时也可以作为测试考核的依据. 2 适用范围 本公司的相关测试人员及研发人员 3 缺陷定义说明 3.1 缺陷定义 l 软件没有达到任务书或需求规格说明书中表明的功能 l 软件出现了与任务书或需求规格说明书中不一致的表现 l 软件功能超出任务书或需求规格说明书的范围 l 软件没有达到用户期望的目标(虽然任务书或需求规格说明书中没有要求) l 测试

解决 方法一:将maven改为离线模式,自己下载jar包复制到仓库中 eclipse中Window>preferences>maven>勾选Offline 方法二:将maven镜像改为阿里云 maven安装目录>conf>settings.xml,将<mirrors> </mirrors>之间默认的国外镜像注释掉,改为阿里云镜像: 1 <mirror> 2 <id>alimaven</id> 3 <name&g

一.bug的定义 软件的bug,狭义指软件程序的漏洞或缺陷,广义指测试工程师或用户提出的软件可改进的细节.或与需求文档存在差异的功能实现等 对应三个测试目的:(3个为了) 1.为了发现程序的代码或业务逻辑错误 2.为了检查产品是否符合用户需求 3.为了提高用户的体验   二.bug的类型 对bug的划分,禅道为例,包括: 1.代码错误 2.设计缺陷 3.界面优化 4.性能问题 5.配置相关 6.安装部署 7.安全相关 8.标准规范 9.测试脚本 10.其他划分:功能类.界面类.性能类.易用性类.

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

作为测试人员,我们都知道Bug的生命周期是: 我们都希望自己不仅有敏锐的洞察力能够全面的找出隐藏在软件中的bug,还希望自己有系统的分析能力能够准确的分析出每个bug的原因以至于能正确.全面的解决修复bug.这也是一个优秀的测试工程师应该具备的基本能力.那么对于回归验证bug这个环节就是对前面两项工作是否合格的体现及验证.bug回归到不到位, 关系到发现bug本身有没有修复正确, ?同样也关系到bug修复过程中可能引起新的bug.接下来我们就讲讲如何做好bug的回归验证: 一.确认好bug的复现

在提交缺陷时,需要遵循以下5个原则: 准确性:缺陷每个组成部分描述准确,不会产生误解,减少“异常”“正常”等模糊词的使用 完整性:复现该缺陷完整的步骤.截图.日志 一致性:按照一致的格式书写全部缺陷信息 简洁性:只包含必不可少的信息,不包括任何多余的内容 清晰性:每个组成部分的描述清晰,易于理解 规范的目的: 方便开发人员更好的理解BUG问题与期望 方便相关人员重现BUG 测试人员更加清晰的描述问题 统一BUG单的编写习惯,提升工作效率 提单的规则: 标题 问题描述 特殊情况: 当问题为单机型导

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

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

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

在软件工程理论中,BUG严重级别(severity)是用于指示软件质量问题导致的负面影响的程度.但在大部分实际的软件开发组织中,对BUG严重级别(severity)的定义和使用常常充斥着大量的争议和分歧.甚至有些组织即使有专门的BUG严重级别定义文档,但是由于其描述的宽泛和模糊性,使得争议和分歧并没有得到有效的减轻.本文将尝试探讨工程实践中的一些具体问题,并提出笔者的一些观点. BUG严重级别定义对于软件开发组织来讲,是一个非常重要的事情.因为它影响了如下几个方面: 影响修复某个BUG的必要性和

bug定义 狭义:软件程序的漏洞或缺陷 广义:测试工程师或用户所发现和提出的软件可改进的细节(增强型.建议性)或需求文档存在差异的功能实现 职责:发现bug,提给开发,让其修改 bug类型--了解 代码(功能)错误---最常见--优先级偏高 界面优化--UI测试--优先级偏低 设计缺陷--优化建议:需求就不合理--优先级偏低 bug的等级--优先级 致命错误--blocker 常规操作引起的系统崩溃.死机.死循环.闪退 造成数据泄露的安全性问题,比如恶意攻击造成的账户私密信息泄露 涉及金钱计算-

一听到初级Bug这个名字,很多开发工程师都会觉得很头痛,还有那个“初级Bug率”,让人随时受不了. 初级Bug这个概念,在多数缺陷跟踪工具中,是不存在的,可以说是淘宝研发部的特色.初级Bug对应Bug的一个属性:“Bug深度”,这个属性有三个选项:1很容易发现.2正常发现.3很难发现,其中“很容易发现”的Bug就是初级Bug.深度代表了发现Bug需要的成本和技术含量,初级Bug就是那些非常明显,通过简单的操作就能发现的Bug. 从初级Bug这个概念被提出,到现在大约有2年时间.最初的时候,在一次

转自:http://zhidao.baidu.com/link?url=7HnNxxUei6m3X3JOLfK4yShElbu5xwvU9Z7ipBAaIvQOi3Bc30N-7o7JgfnZDEg3bbClEd_qswWceHs7R_EUtq 简单的说,就是配合log的等级过滤输出比如,你在开发的时候,要验证一个方法有没有被调用到,为了方便调试,通常会在这个方法开始的时候加一些system.out.但是项目真正发布的时候这些代码通常是要移除掉的,所以通常更建议用logger来记录,所以你可能会

分享下我的debug的经验 1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间. 2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多年的大型系统里,经常会反复出现同样原因的bug,原因都类似,改了一处,过一阵子另外一处又冒出来,而且无法根治.比如:我那个系统里有个特别危险的API,接口参数比较难用,一旦有人用错了某些情况下就会出诡异的现象,解决很简单,找到调用这个API的地方把调用方式写对就好

分享下我的debug的经验 1. 优先解决那些可重现的,可重现的bug特别好找,反复调试测试就好了,先把好解决的干掉,这样最节约时间. 2. 对于某些bug没有头绪或者现象古怪不知道从哪里下手,找有经验的同事问一下思路,因为在那种开发多年的大型系统里,经常会反复出现同样原因的bug,原因都类似,改了一处,过一阵子另外一处又冒出来,而且无法根治.比如:我那个系统里有个特别危险的API,接口参数比较难用,一旦有人用错了某些情况下就会出诡异的现象,解决很简单,找到调用这个API的地方把调用方式写对就好

遭遇 bug 的时候,理性的程序员会说:这个 bug 能复现吗? 自负型:这不可能,在我这是好好的. 经验型:不应该,以前怎么没问题? 幻想型:可能是数据有问题. 无辜型:我好几个星期都没碰这块代码了! 乐观型:只需要改一行代码,不会影响其它程序的. 实践型:你重启一下服务试试. 无论你是哪种类型的程序员,遭遇 bug,内心都是崩溃的,尤其是产品经理或测试人员在使用或测试产品的过程中抓到你的一个 bug 之后那种如获至宝的表情和欢呼声,会让我们的心情久久不能平静.于情于理,防患于未然,减少编程中

一 css的优先级 今天有人跟我说css hack中用!important来区分ie6,因为ie6不支持!important,是的在很早以前我也是用过这种方法写hack,但是后来就基本不用了.本来我对他谁的ie6不支持!important也没什么异议,可是正好在前几天正好用个这个!important属性解决了一个样式优先级的问题,而且是支持ie6的,这是为什么呢?到底ie6支不支持!important呢? 首先我们来看看!important这个属性的作用:!important是用来提升样式优先级

最近一两年在一些项目上,通过实际需求出发,编写了一些库在项目中使用,现在将这些项目都稍微整理了一下开源了出来,也许也有刚好能够你也用得上的,顺便也骗一下star.均在项目的README中加了相关的说明. 迷你全功能的模板引擎(压缩版代码不到2kb) 项目地址: https://github.com/coffeedeveloper/coffee-tmpl npm包名: coffee-tmpl 语法和ejs保持一致,只不过这个模板引擎只能用到浏览器,不支持layout之类的高级用法.会写这个库是因为