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

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

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

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

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

接口测试 一.你对HTTP有没有了解过?具体讲一下对http的了解.(答题思路: 定义.常见请求类型.状态码.请求头请求体.响应头和响应体.三次握手和四次挥手.)答:了解,我们做接口的时候基本上都是基于http接口来做的.HTTP是超文本传输协议,超文本是指数据传输时,可以进行文本传输之外的数据,比如图像.音频等,http默认端口是80.http的工作原理是,客户端通过URL向http服务器发送请求,服务器接收请求后,向客户端发送响应信息.HTTP常见的请求类型有post(增).get(查).p

本文章主要包括以下6个内容: 一.注释分类以及javadoc的使用 二.使用Alibaba Java Coding Guidelines规范编码. 三.IDEA配置类注释 四.IDEA配置方法注释 ====================正文开始==================== 一.注释分类以及javadoc的使用. 所谓注释就是只给人看的,而并不会被执行的语句.适当的代码注释可以提高代码可读性,也方便后期的维护,所以在编程初期就要养成良好的编码习惯.代码注释分为一下三种: 1.单行注释

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

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

BUG:软件系统中存在的可能导致系统出错.失效.死机等问题的错误或缺陷. 描述一个缺陷,需要以下核心要素 标题:用简洁的话描述该缺陷,主要让开发知道这是一个什么样的缺陷 参数设置:Bug的类型(功能/性能/界面等),Bug的严重程度.Bug优先级(是否需要立即修复等).所属项目模块.项目的版本号 详细描述:便于开发重现和定位缺陷 主要包括: 1.测试环境:如:浏览器及版本号,操作系统,手机app或微信公众号测试明确手机型号,版本号,微信版本号等 2.测试数据:用户名和密码,及相关的业务数据 3.

首先,测试人员发现 BUG ,做好记录并上报至 BUG 数据库.接着,开发组长或经理确定该 BUG 是否有效 之后指定 BUG 的优先级并安排给相关开发人员.否则拒绝该 BUG 的修复. 然后,该 BUG 进入初始化状态.开发人员着手解决 BUG ,BUG 进入修复状态. 由相关测试人员测试该 BUG 是否已经被修复,进入 BUG 验证状态.如果验证不通过,则将重新为该 BUG 分配状态并再一次进入修复状态. 测试人员验证该 BUG 已被修复之后关闭该 BUG ,即 BUG 进入关闭状态. 对于

顶头信息 所属产品,所属项目,所属模块,影响版本,当前指派,bug类型:代码错误,界面优化,设计缺陷,性能问题,标准规范,其他,安全相关.bug标题,严重程度,优先级 缺陷描述 bug描述,预置条件,操作步骤1,2,3 ,预期结果,实际结果,抄送给,附件 管理系统:bugzilla,禅道,jira,redmine

1.按照严重程度划分 定义:是指Bug对软件质量的破坏程度,即BUG的存在将对软件的功能和性能产生怎样的影响 分类:系统崩溃.严重.一般.次要.建议 2.按优先级划分 定义:表示处理和修正软件缺陷的现后顺序的指标 分类:高(high).中(middle).低(low) 注意:一般情况下,严重程度高的软件缺陷具有较高的优先级 特殊情况下,此条件不成立 (1)严重程度告优先级不一定高 a.如过某严重的缺陷只是在非常极端的条件下产生,则没有必要马上解决 b.如修改一个软件缺陷,需要重新修改软件的整体结

bug的要素 为了让开发人员更准确.更快的看懂Bug,测试需要按照一定的规范提交bug. 缺陷id:一般由缺陷管理系统自动生成: 缺陷标题:概要描述缺陷: 发现人:一般是缺陷管理系统自动获取当前用户: 发现时间:一般是缺陷系统自动获取当前系统时间: 版本: 缺陷所属模块: 是否可重现: 严重度:缺陷的严重程度: 优先级:缺陷修复的优先级: 缺陷状态:一般初始状态为new: 指派给:选择修改缺陷的开发人员: Bug复现步骤:描述Bug出现的详细过程,即: 1.URL.用户名.密码: 2.操作步骤:

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

我们知道了自身的症状,那么就从这里开始,一起聊一聊一个优秀的 BUG,应该包含哪些方面的内容呢? 标题 其实每一个 BUG 也都是一个小的文档,既然是文档,我们首先就要做好一个 “标题党”,当然,此 “标题党” 非彼标题党.作为一只优秀的标题,要清晰明确简洁的说明两个 “W”: Which: 哪个系统的哪个功能? What happened:出现了什么样的问题? 也记住另外一个规范:每条缺陷报告只包括一个缺陷.就像刚刚说的,这样可以让开发认真的定位和对待单一的 BUG,对于测试人员自己来说,也只

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

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

我在写插件时用到了 onresize 事件,在反复地测试后发现该事件在 Chrome 及 Opera(内核基本与 Chrome 相同,以下统称 Chrome)浏览器打开时就会执行,这种情况也许不能算作 bug 吧,估计他们的工程师认为浏览器打开时也算窗口发生了变化.解决问题之前我搜索了相关内容,确实有关于 Chrome 的 onresize 的问题,但跟我遇到的问题还有很大不同.我把这个问题抽象为以下函数: function init() { alert('a'); window.onresiz

bug已经成为程序员工作中的一部分,作为从事嵌入式软件开发已有三年的我,经手的bug也不少了.先说说自己对于bug的心态变化吧,刚开始工作的时候,自己还是很喜欢bug的.那时,自己是负责维护别人的代码,如果发现了bug,说明自己工作有成绩:后来,自己开始码代码,这个时候测试人员告诉我有bug,自己就有些心烦,尤其是当领导知道了这个bug以后,就会感到很大压力:再后来,经手的bug变多了,也变得淡定多了,而且还逐渐建立自己分析bug的工具箱和分析流程:现在,经过几年的工作,积累了一些经验,开始在设

在我们刚踏入软件测试行业时,不管你是专业的.非专业的,培训出来的还是未培训的.刚进公司时你看着身边的同时报的Bug很多并且大都是严重程度高,自己也很想提高一下,想要提高自己的bug敏感度,建议从下面几点做起,纯属个人建议.    1 熟悉需求  这是最基础也是最重要的,原始需求随着项目的进度在不断地变化,这就需要你多沟通多交流清楚最新的需求是什么.毕竟书面上的需求是不完整的,隐性需求就靠你和PM沟通了,让PM听你的建议,从用户的角度考虑.    2 Bug库    多看Bug库,看看别人找Bug