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

这里系统专门指的是那种用户量大的系统,比如有几百万或者上千万的注册会员.因为小系统因为用户量少,不存在这种思考,考虑有时候是多余的.另外还有内部系统,给自己公司内部人员使用的,即便是出现了问题,也不会造成很大的问题,内部协调一下即可. 而针对客户的系统,公司的收入和价值来源于给客户提供稳定的服务.这是关系到公司命脉的.如果系统不稳定,在客户心中造成的印象就会不好. 快速修复与稳定测试之间的权衡 如果线上系统出现了bug,用户反馈问题.作为开发人员,肯定要修复bug.是马修复代码后上传到生产环境,

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

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

BUG提交规范 1.标题 2.步骤描述 ①.步骤使用序号编排 ②.在特定情况下发生的问题,还需提供准确的前提条件 ③.精准的描述bug产生的路径后,再描述现象 如: >打开客户端进行首页->点击“我的”页面->点击用户头像进入个人资料页 >个人资料页点击头像选择拍照->拍照后点击保存头像 >从个人资料页返回 “我的”页面,查看头像是否更新④.若步骤并不能必现错误,需要说明出现错误的概率(需要多次测试的基础上,若必现则填写100%,若偶现,则执行多次后统计概率填写) 3.

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

王颖2015/10/08 最新版本中,严重程度1.2.3.4分别代表什么意思?还有优先级中1.2.3.4分别代表什么意思? 回复 石洋洋2015/10/08 1 2 3 4 都代表不同的级别,一般是1最严重最紧急,4最轻不紧急,可以在 后台-自定义 中修改显示的名称. 示例:如何修改禅道的语言提示? 2010-08-28 17:38:37 王春生 17952 最后编辑:春哥 于 2014-09-01 19:17:18 简介:本篇文章讲述如何修改禅道的语言提示来满足自己的需要. 下面来看具体的例子

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

问题描述: 测试过程中如何区分什么是功能bug,什么是需求bug,什么是设计bug? 精彩答案: 会员 土土的豆豆: 本期问题其实主要是针对不同方面或纬度上对于bug的一个归类和定位. 个人认为,从软件开发测试生命周期上分析的话,三者从开发测试阶段应该是需求bug.设计bug.功能bug.(这里仅针对提问排比) 需求问题可以包括设计问题和功能问题,当然还有非功能性缺陷等. 需求bug,简而言之就是对于业务需求不清晰或者理解有偏差产生的问题.可能包括业务分析人员不专业因素.开发与测试人员思维不一致

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

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

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

博主在搭建好bugfree后,修改了系统中“优先级”字段,将原先系统定义的优先级“1.2.3.4”修改为符合博主自己项目要求的优先级“高.中.低”.修改成功后,系统确实将原先提交的BUG优先级从“1.2.3.4”自动修改为“高.中.低”,博主很开心. 但是突然发现系统内已有的一个项目无法访问. 问题现象 一旦从界面上切换到该项目,整个界面便会抛出一个PHP Error,如下图: 问题原因 优先级修改的时候我自定义了三个等级“高.中.低”,原来系统有四个等级“1.2.3.4”,该项目中有人提交了一

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

  在不同的JVM中(JVM也算是一个操作系统),有着不同的CPU调度算法,对于大部分的JVM来说,优先级也是调度算法中的一个参数.所以,线程优先级在一定程度上,对线程的调度执行顺序有所影响,但不能用于保证线程的执行顺序,因为优先级仅仅是其中一个参数而已,其他参数还可能有线程的等待时间.执行时间等.而且操作系统也可抗能可以完全不用理会JAVA线程对于优先级的设定.   线程优先级的范围一般是1~10,默认是5,但也有的JVM不是这个范围.所以,一般也尽量不要设置优先级为数字,可以使用Thread

系列目录 Pod可以拥有优先级.优先意味着相对于其它pod某个pod更为重要.如果重要的pod不能被调度,则kubernetes调度器会优先于(驱离)低优先级的pod来让处于pending状态的高优先级pod被调度. kubernetes 1.9以后,优先级会影响pod的调度顺序和资源耗尽时pod的驱离顺序 警告:在一个不是所有用户都被信任的集群里,可能有恶意用户创建最高可能优先级的pod,导致其它pod被驱离或者无法调度.为了解决这个问题,需要增大资源配额来支持优先pod.集群管理员可以为特定

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

工具/原料 有网的电脑 方法/步骤1: 打开公司给的访问JIRA的链接,输入公司给你注册的账号和密码,点击登录 方法/步骤2: 点击JIRA主菜单上的“创建”,进入编辑bug界面 方法/步骤3: 项目:点击输入框旁边的下拉按钮,选择项目单击选入 问题类型:点击输入框旁边的下拉按钮,选择BUG单击选入 方法/步骤4: 主题:输入框中输入文字描述bug 缺陷类型:点击输入框旁边的下拉按钮,选择bug所属于的类型单击选入 方法/步骤5: 严重级别:级别有1.2.3.4 :1表示最高级bug最严重的 点

1 . 优先级表示重要程度或者紧急程度.但是能不能抢到资源也是不一定.2 . 分配优先级:反映线程的重要或紧急程度线程的优先级用1-10 表示,1的优先级最低,10的优先级最高,默认值是5 package com.qf.demo3;/** * 优先级 : 只能反映 线程 的 中或者是 紧急程度 , 不能决定 是否一定先执行 * setPriority() * 1~10 1最低 10最高 5是默认值 */ public class Test { public static void main(St

五款轻量型bug管理工具横向测评 最近正在使用的本地bug管理软件又出问题了,已经记不清这是第几次了,每次出现问题都要耗费大量的时间精力去网上寻找解决方案,劳心劳力.为了避免再次出现这样的情况,我决定从线下转到线上,使用轻量型的在线bug管理工具,在选择工具时有以下几个要求:1．不用在本地安装部署,配置环境,即开即用:2．方便bug管理,bug属性设置:3．可以跨团队沟通,方便和开发协作:4．随时掌握bug状态,修复进展等. 花费了一个星期的时间试用了五款在线bug管理工具,其评测结果如下: 1

第一部分 调研,评测 ●评测 bug one 在词典界面中搜完单词后,将鼠标移到英文例句上的单词时,会显示对应的中文翻译,而当移到短语时则不对应中文翻译. bug two 用orc强力取词,查询如上图单词dream,dream先用鼠标选定后有蓝色背景再截图保存,然后在图上选取dream查不出反而翻译了后面first单词.会出现这个bug应该是制作团队没有考虑这个问题吧,因为一般人都不会这么做,所以这个bug的危害应该也不是特别大. bug three 在酷狗音乐的歌词列表中用orc查询英文歌名时