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

一个外部的相对定位div,内部一个绝对定位的div(right:0), 如图: 可是在IE6下查看,却变成了right:1px的效果了: IE6还有奇数宽高的bug,解决方案就是将外部相对定位的div宽度改成偶数.高度也是一样的查看源码: XML/HTML代码: <div id=“out”> <div id=“inn”>此处为内部绝对定位的 DIV</div> </div> CSS代码: #out { width: 609px;/*这里宽度为奇数,bug就出

IE6真是太疯狂了.今天由于项目需要做了这么一个布局:一个外部的相对定位div,内部一个绝对定位的div(right:0), 如图: 可是在IE6下查看,却变成了right:1px的效果了: IE6还有奇数宽高的bug,解决方案就是将外部相对定位的div宽度改成偶数.高度也是一样的查看源码: CSS代码: #out {width: 609px;/*这里宽度为奇数,bug就出现了!!改成偶数就OK了*/height: 300px;position: relative;background:#FF0

曾经在做手机上传图片的时候.直接获取相机拍摄的原图上传,原图大小一般1~2M.因此上传一张都比較浪费资源,有些场景还须要图片多张上传,所以近期查看了好多前辈写的关于图片处理的资料.然后试着改了一个图片压缩的方法.经測试用着还不错.压缩效果非常理想,主要是失真不明显.在这里分享一下. 以下直接上代码: /** * 上传server时把图片调用以下方法压缩后 保存到暂时目录 图片压缩后小于200KB.失真度不明显 * * @param path * @return * @throws IOExcep

欢迎添加华为云小助手微信(微信号:HWCloud002 或 HWCloud003),输入关键字"加群",加入华为云线上技术讨论群:输入关键字"最新活动",获取华为云最新特惠促销.华为云诸多技术大咖.特惠活动等你来撩! 电脑硬盘里的图片 收藏夹的照片(硬盘里的女神)看了又删,去年夏天后就没聊过天-很久前有这么一首歌很火,不知道大家听过没,只是括号里的歌词被改成了现在的样子.那么,你们以为我今晚要开车?NONONO- 每天做公众号,最愁的两件事,一是选题,二是公众号配图

回顾 APP专项测试(兼容性,安装,卸载,升级,交叉事件,PUSH消息,性能,其他类型) 项目环境(开发环境,测试环境,准生产环境,生产环境) APP内测发布平台(蒲公英,fir.im)支持apk,ipa APP线上发布平台(安卓,IOS) 敏捷开发模式(客户需求,迭代, 循序渐进) SCRUM模型(三个角色,PO,SM,DEV Team,四个会议,sprint,backlog) APP测试流程(需求评审,测试计划,测试用例,测试执行和BUG跟踪,测试报告) 学习目标 掌握点赞评论功能点用例编写

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

在测试圈中,相信大家对“Bug敏感度”这一词并不陌生,但是Bug敏感度具体是指什么呢,本文对此关键词进行解读的基础上,对其与软件质量的关系,影响的关键因素,如何提高测试人员的bug敏感度进行分享.(--续集) Bug敏感度的故事 [测试经理的评价] 在一次绩效评价中,A主管对某位测试工程师的评价如下: 本季度完成了模块A.模块B.模块C的系统测试工作,设计了1200用例,提交了500+Bugs,严重Bug占40%,Bug数占测试团队(同期参与项目有4人)的35%,其突出的Bug敏感度,对某项目软

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

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

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

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

一.        BUG处理流程图: 流程描述: 1.  测试人员发现bug提交给开发. 2.  开发人员判断是否是bug. 3.  如果是bug,进行修改,修改完成后更改bug状态为已解决. 4.  如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部原因,或者不能重现. 5.  开发人员修改完成的bug,由测试人员进行验证,确认修改正确,关闭bug. 6.  验证未通过的bug重新激活,开发人员继续修改,直至验证通过,关闭bug. 7.  测试人员需要对开发人员退回的bug

在我们日常测试活动中,经常会发现一些bug,但是这些bug可能就是昙花一现,再也无法(或者很难)重现出来,内心灰常崩溃.那到底有哪些方面可能会导致这类的缺陷发生呢? 我以自己工作中所遇到的给出一些自己的总结,当然如有补充请自行添加. 一．环境问题 这个问题导致的缺陷无法重现的情况还是比较多的,测试和开发环境的不一致可能导致开发那边缺陷无法重现,还有实际运行环境和我们测试的环境不一致.如(硬件的配置,软件的配置,网络因素),当然极少数是系统内部问题或者时间触发的(这类bug重现非常困难) 二．操作

摘 要:本文简要分析了无法重现的Bug的可能产生原因,包括环境不一致.缺少最准确的描述和浏览器的不当设置.针对这些原因,本文给出了相应的对策.通过这些措施,可以重现许多以前认为不可重现的Bug.        关键词:重现:Bug:环境 在测试人员提交bug后,最不希望看到的结果是它们被标记为INVALID,尽管你坚信这一定是Bug.开发人员查看了bug的Description后,最不希望的结果是你无法重现它们,尽管他使用了所有可能的方法去重现它.一旦出现这样的情况,测试人员会很伤心,开发人员也

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

BUG 的生命周期 Bug-->软件程序的漏洞或缺陷 Bug 的类型:代码错误.设计缺陷.界面优化.性能问题.配置相关.安装部署.安全相关.标准规划.测试脚本....其他(功能类.界面类.性能类.易用性类.兼容性类....) Bug 的等级 1)致命错误: 常规操作引起的系统崩溃.死机.死循环 造成数据泄露的安全性问题,比如恶意攻击造成的账户私密信息泄露 设计金钱的计算 2)严重错误: 重要功能不能实现 错误的波及面广,影响到其他重要的正常功能实现,功能交互 非常规操作导致的程序崩溃.死机.死循

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

BUG 的生命周期 BUG 的生命周期 Bug-->软件程序的漏洞或缺陷 Bug 的类型:代码错误.设计缺陷.界面优化.性能问题.配置相关.安装部署.安全相关.标准规划.测试脚本....其他(功能类.界面类.性能类.易用性类.兼容性类....) Bug 的等级 1)致命错误: 常规操作引起的系统崩溃.死机.死循环 造成数据泄露的安全性问题,比如恶意攻击造成的账户私密信息泄露 设计金钱的计算 2)严重错误: 重要功能不能实现 错误的波及面广,影响到其他重要的正常功能实现,功能交互 非常规操作导致的

一个wap端改版项目完结了,总结下测试过程中的典型性bug:应该从哪个角度去总结? 有点疑问?不知道是以bug的影响度去总结,还是以优先级去总结(好像优先级和影响度是成正比的,优先级比较高的bug,影响度一般也是比较大的) 以测试角度去总结的bug:和开发自己总结的典型bug:好像都是不一样的(筛选角度不一样吧) 项目中功能测试占比90%,筛选典型bug,大都会以功能业务去筛选bug(一般这种bug出现的原因,就是开发对需求理解有偏差或者手下误) 接口测试占比比较少,还是有时间就测试接口:没有时