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

大多数公司都是用bugzilla来管理bug,也有的公司使用内部开发的bug管理平台.这里以bugzilla为例,我最不爽的是提bug的时候既要选择severity(严重级别)又要选择priority(优先级别),实际工作中severity很少用得上,因为大多数开发人员都是根据priority来进行修复的,比如经过N步操作+N种牛角尖式使用找到一个崩溃bug,它严重程度很高,但是因为在实际用户那里根本不会遇到这种情景,则它的优先级就很低,而开发和产品的意见往往就是“根据用户反馈再做修改”,这种b

通常应遵循“谁malloc,谁free”的原则. ------------------------   一位大神的话. 2013-02-09

前言 本周一(2019.07.22),给某知名手机“大厂”提了个安全BUG,默默修复了后,周五回复我“已忽略”,此处省略上千字的心理活动..... 做安全的朋友说这都小事,国内氛围本来就不太好,hackone就不会这样. 今天周六写些文时,既然安全问题已修复,那直接发文也不存在什么问题,但是, 写文过程中抓包补图,发现安全问题修复只是表象,文章写了一半,发也不是不发也不是... 斟酌再三,做事哪有做一半的道理,于是写完了本文,图片全部打码处理,交流为主提高大家的安全意识. 如有此文有不妥之处,请

在测试的工作中,提BUG是日常工作. 以前自己为了省事,省时,仅仅是截图,在图片上注明一下问题,就放到BUG库中了. 现在发现这样会造成开发的时间的浪费,增加了沟通成本. 对于BUG,当发现了异常时,首先自己重现一下刚才的步骤,判断是偶现还是可以重现,另外,也可以请同事,帮忙检查一下,按照步骤操作一次. 如果还是有疑问,可以请产品同事来帮忙确认,这样就可以避免与开发同事的争论. 当发现了BUG后,提到BUG管理工具中时,注意一下提BUG的格式. 提BUG格式: 标题(简单描述一下问题) 1,测试

某个周四早上,沏好一杯茶,刚要坐到座位上,就听开发说,你们测试怎么提的Bug,给个截图能说明啥?截图上面显示的奔溃,如果是必现还好,如果不是必现,那么我们怎么去定位?至少给个日志吧?当时我的内心活动是,昨晚你们下班走了,留下我们测试,5分钟找出两个奔溃,这两处奔溃是用户必须去操作的两个按钮,你们打完包居然连点都没点就直接发布了,说好的自测,说好的版本质量呢?但是嘴上却说,你们要日志,你们早说呀,那不能我们随便给个日志给你吧?日志是什么类型?总得有约束吧...... 我叫皮皮,是一名软件测试工程师

提bug注意(此为公司开发提出的建议): 开发如果改bug影响导致另一个问题,原bug没有问题,尽量重新提bug,不要直接激活,因为可能不是同一个问题导致的:   不要一个bug里提多个问题,因为不同问题可能负责的人不一样,需要一直转bug,比较麻烦:此外,由禅道可知,有时一个bug提多个问题,开发容易忽略问题,导致没有改全:   举例说明时,尽量用文字输入,不要只有截图,方便开发操作:   提bug时,描述清楚步骤,能给动图尽量给动图,能给数据给出数据,以免出现开发与测试理解不一致情况,以及减

互联网人罪状系列 1.上班第一天,前端把后端告上县衙,还列了 5 宗罪 2. 程序员状告产品经理八大罪状 (上) 3.程序员状告产品经理八大罪状(下) 开发人员与测试人员的关系,就如同程序员与产品经理的关系一样,开发没了测试,项目没有办法保质上线,产品经理离了程序员,再牛的产品,也只是纸上谈兵. 所以两者之间,就像鱼跟水,谁能离不开谁,却又相互看对方不爽,这不,公司的开发与测试人员,又吵起来了,这次玩的还有点大,直接对簿公堂了- 本期漫画情节纯属虚构,切勿对号入座 如有雷同,纯属巧合. 这是苏南

 浏览(1502)  赞(29) 一直以来都想开发一个自己的网站,总想做一个网站然后让千千万万的人去访问,去使用,然后收到热烈的好评, 再然后某某著名机构有意投资我的网站(其实收购也是没有问题的), 自己因此而赚到了人生的第一桶金, 我当然是很乐意接受这个结果的,啊哈哈哈哈哈哈哈哈哈哈哈,就先让我做一会梦吧~ 好啦,说点正经的吧,马云说过,梦想还是要有的,万一实现了呢!对啊,我怀着这个梦想,不对,是怀着这个幻想有一年的时间了, 但是一想到要付出的时间和精力,顿感有心无力,首先你要弄好网站的设计,

1. 背景 之前读JUC的AQS源码,读到Condition部分,我当时也写了一篇源码阅读文章--(AbstractQueuedSynchronizer源码解读--续篇之Condition)[http://www.cnblogs.com/micrari/p/7219751.html].Doug Lea大师的代码写的很好,整个设计与编码都很优秀.但是我也在最后的思考与总结中指出了Condition有一个缺陷,在于await/awaitNanos/awaitUntil那些方法,在JavaDoc中写了

个人观察 1.通过系统和业务拆分,遵循单一职责原则SRP,保障整个系统的可用性和稳定性. 2.单一职责原则SRP,真的很关键,广大程序员需要不断深入理解这个原则. 3.架构图是架构师的重要输出,通过图可以直观地看出整个架构思路. 本文转载于 <程序员>2014年11月刊:电商峰值系统架构设计 原文链接:http://www.csdn.net/article/2014-11-04/2822459 该做什么的就做什么 保障整个系统的可用性和稳定性,第一步需要做 的就是,使整体架构清晰化.层次化.那

Bug 管理系统之重 回想我们每次开启一个新项目,筹备之初,首要之事就是选择一款 Bug 管理系统.市面上有诸多 Bug 管理系统可供选择:Jira.Redmine.Bugzilla 等.这些系统功能强大,经过多年的迭代,可谓无所不能,却又无一例外,存在如下问题: 功能复杂 用户体验差 学习成本高部署难 这些问题,在不涉及到 App 开发的时候,还可以忍. 移动应用 Bug 管理之痛 在一切皆移动的时代,一款 App 几乎是所有创业项目的标配,测试提 Bug 是 App 开发的重要步骤,崩溃管理

欢迎关注我的公众号,了解更多的测试知识:[软件测试经验与教训] 一一BUG描述基础知识 Bug标题中需包含Bug的具体位置并以[]标注 举例:[模块-子模块-页面]XXXXXXXXXXXX Bug标题中切勿出现错别字 错误示例: 奔溃(崩溃),电击(点击),登陆,(登录),重置(充值),现实(显示) 当所发现Bug前提条件为空时,需要填无.特殊条件下的Bug必须详细描述产生Bug的前提. 示例:只有在使用附件中的图片(大图片:60M)时,会出现此Bug. 描述复现步骤中的页面切换为避免出现描述不

前言 最近看到行业的前辈都分享一些过往的经历来指导我们这些测试人员,我很尊敬我们的行业前辈,没有他们在前面铺路,如今我们这帮年轻的测试人估计还在碰壁或摸着石头过河,结合前辈们的经验,作为年轻的测试人也有自己的一些职场,技术以及行业交际的一些总结经验,今天有些时间,我也写写我做为一名90后测试人的一些经历和看法吧,还是先简单介绍一下自己,本人15年本科毕业,还有一个月工作就满两年了,现在在公司的创新团队任测试负责人,不过由于个人发展的原因,也很快要和现在的公司说88啦 二.情怀 我对软件测试这个方

原文地址:https://blog.csdn.net/haoyujie/article/details/80601455 1.  问题引出 这向天,在编写一系列文档. 其中一篇要今天交,前天写好后,一个不小心的操作,多级序号全都乱了. 作为一名典型的中国人,首先我认为是自己不努力,今晚抽出时间,想要解决这个问题. 发现,完全找不到门. 无奈之余,只好百度一下,最近没有办法google了,只好百度.百度上一群人给出的意见都没有用处. 然后去biying了一下,如下,发现有许多人,认为这的确是一个b

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

5. 迪米特法则(Law of Demeter,LoD) 5.1 定义 (1)应尽量减少其他对象之间的交互,对象只和自己的朋友交谈,即对其他依赖的类越少越好(不要和太多的类发生关系). (2)尽量不要让类和类之间建立直接的关系,这样可减少类与类之间的依赖,降低类之间的耦合. (3)一个类应对自己需要耦合的类知道得最少,只知道其public方法,其内部如何复杂自己没有关系,也叫最少知识原则(Least Knowledge Principle,LKP). 5.2 迪米特法则:核心要义就是类间解耦.低

我们在软件测试过程中,由于不同人员测试同一个项目,所以往往会出现Bug重复提交情况,导致对整个项目和人员产生影响: 浪费测试人员时间和精力,从而影响测试进度 浪费开发人员重复看Bug时间 若开发人员由Bug数量算绩效,会影响开发人员和测试人员之间的关系 导致整个测试工作不规范.不严谨 对于测试人员来说避免重复提Bug和提一个精确有效的Bug一样重要.为了避免重复Bug,先分析下导致Bug重复的可能情况: 不同测试人员重复测试相同的模块 不同测试人员重复测试相交的模块 总结了下解决上述情况的办法(

1．  开闭原则(Open-Closed Principle,OCP) 1)定义:一个软件实体应当对扩展开放,对修改关闭( Software entities should be open for extension,but closed for modification.).即在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展. 2)满足“开-闭”原则的系统的优点: a)通过扩展已有的软件系统,可以提供新的行为,以满足对软件的新需求,使变化中的软件系统有一定的适应性和灵活性. b

随着时间的流逝,人们开发出了一套设计与编写软件工具的原则.在本书用来解决问题的程序中,你将会看到这些原则的应用示例.好的软件工具应该具备下列特点:一次做好一件事在很多方面,这都是最重要的原则.若程序只做一件事,那么无论是设计.编写.调试.维护,以及生成文件都会容易得多.举例来说,对于用来查找文件中是否有符合样式的grep程序,不应该指望用它来执行算术运算.这个原则的结果,自然就是会不断产生出更小.更专用于特定功能的程序,就像专业木匠的工具箱里,永远会有一堆专为特定用途所设计的工具.处理文本行,不

最近感觉很扯蛋的事情就是测试人员提bug的问题.先说下前提,公司测试会以提bug数量来做为一部分员工绩效的成份.再说一下公司从需求到开发 到测试,先是需求出一个文档,开发根据文档做功能的开发,然后测试看文档做黑合测试,文档里面没有用例,所以测试对文档用自己的理解来测试. ----------------割了公司老总的JJ--------------- 下面就是我要吐槽的东西了,需求说做一个A,开发做了个A',A与A'有一点偏差,然后测试理解的是A'',A与A''也有偏差.我去,我不是想说这个偏差