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

一共分为五个等级. 1.CMMI一级,完成级.在完成级水平上,企业对项目的目标与要做的努力很清晰.项目的目标得以实现. 2.CMMI二级,管理级.在管理级水平上,企业在项目实施上能够遵守既定的计划与流程,有资源准备,权责到人,对相关的项目实施人员有相应的培训,对整个流程有监测与控制,并与上级单位对项目与流程进行审查. 3.CMMI三级,定义级.在定义级水平上,企业不仅仅能够对项目的实施有一整套的管理措施,并保障项目的完成:而且,企业能够根据自身的特殊情况以及自己的标准流程,将这套管理体系与流程予

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

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

前言:工作三年了,工作内容主要是嵌入式软件开发和维护,用的语言是C,毕业后先在一家工业自动化控制公司工作两年半,目前在一家医疗仪器公司担任嵌入式软件开发工作.软件开发中,难免不产生bug:产品交付客户使用后,难免不产生问题,那么关于bug分析和异常处理则是软件开发和维护中无法躲避的工作内容.工作至今,我一直在思考关于bug分析和异常处理,有没有一些原则性.规律性的东西可循,以减少bug,提高bug分析的效率,对于一些异常,基于什么原则进行处理,才能达到客户的要求.这些问题每个行业.每个职位上的人

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

生活中有这么一种现象:如果你关注某些东西,它就会经常出现在你眼前,例如一个不出名的歌手的名字,一种动物的卡通形象,某个非常专业的术语,等等等等.这种现象也叫做“孕妇效应”.还有类似的一种效应叫做“视网膜效应”,它讲的是:你有什么东西或者特质你就特别容易在别处发现你有的这类东西和特质.干了多年测试的我就会经常发现日常使用的系统中有很多的bug,而我老婆就发现不了.今天要说的事儿是“重现难以重现的bug”,这件事儿在本周共遇见了4次:第一次是微博上有一篇<程序员,你调试过的最难的 Bug 是?>(

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

1. 禅道简介 禅道是一个基于"敏捷开发"模式的软件开发全生命周期管理软件,在国内的软件开发公司里占据了超过70%的份额,从大公司到小公司,都能适用. 禅道官网:http://www.zentao.net/ 2. Bug管理规范 2.1 角色及人员 一般来说,禅道用于需求/Bug管理方面,在用户角色上,是分为这么几个角色: 1.公司/部门管理层  以下简称"管理层" 2.产品经理 以下简称"产品经理" 职责:负责整个产品生命周期内的全面管理 3.

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

1. 禅道简介 禅道是一个基于“敏捷开发”模式的软件开发全生命周期管理软件,在国内的软件开发公司里占据最大的份额,从大公司到小公司,都能适用. 笔者使用禅道多年,根据自己的经验总结了一套Bug管理的方法论,不只是禅道,也可以运用在别的软件开发管理系统上. 2. Bug管理规范 2.1 角色及人员 一般来说,禅道用于需求/Bug管理方面,在用户角色上,是分为这么几个角色: 1.公司/部门管理层  以下简称“管理层” 2.产品经理 以下简称“产品经理” 职责:负责整个产品生命周期内的全面管理 3.项

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

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

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

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

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

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

在代码测试中,通常一个 Bug 需要我们定义他们的优先级(即定义开发人员应该如何相应这个Bug) 和它的严重等级(即该 Bug 发生后对程序的影响). 专业的英文为 Priority -- 优先级:和Severity -- 严重等级. 优先级和严重等级不是紧密结合的 Bug 的两个属性,不是一个 Bug 的严重等级越严重那么它的优先级就越高. 具体为一个Bug 定义多少个 Severity 的值取决于不同项目/团队对其的定义.这里根据我个人的理解给出一些定义: Highest - 最高,通常当一

switch什么时候用break,什么时候不用break 调用break:一次执行一个分支,输入一个数据,对应一个级别 不调用break:连续执行多个分支 if...else 可以处理任何情况,大于小于等于与或非等复杂逻辑都可以处理,看起来不够简洁. switch 只能处理常量,处理字符整数型常量,看起来很简洁. case标签值必须是常量,只能判断相等. 在 if 或 else 后面总是用{} 即使只有一条语句的时候 if 最简单的用法 #include <stdio.h> main() {

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

导读 2014 年开源加密库 OpenSSL 项目爆出的高危漏洞 Heartblood 让世人意识到一些鲜为人知的开源项目对整个互联网和其它基础设施的完整性和可靠性至关重要,随后 Linux 基金会发起了 Core Infrastructure Initiative(CII)倡议. 2014 年开源加密库 OpenSSL 项目爆出的高危漏洞 Heartblood 让世人意识到一些鲜为人知的开源项目对整个互联网和其它基础设施的完整性和可靠性至关重要,随后 Linux 基金会发起了 Core Inf