大家提交的bug一样怎么办

2024-10-25

如何避免测试人员提交重复的Bug

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

Bug概述、状态、类型、级别、优先级提交和Bug生命周期管理

缺陷概述: 1)缺陷(Defect):是指存在于软件之中偏差,可被激活,以静态形式存在于软件内部,相当于Bug. 2)故障(Fault):当缺陷被激活后,软件运⾏中出现的状态,可引起意外情况,若不加处理,可产⽣失效,是⼀个动态行为. 3)失效(Failure):软件运⾏时产⽣的外部异常⾏为结果,表现与⽤户需求不⼀致,功能能⼒终⽌,⽤户⽆法完成所需要的应用. 4)Bug:电脑系统或者程序中存在的任何⼀种破坏正常运转能⼒的问题或者缺陷,都可以称之为"Bug":有时也泛指因软件产品类部引起

软件测试面试-如何高质量提交缺陷bug？

从实际工作中整理,如下:如有补充可以讨论! 所以会发现现在的面试题大部分问的都是工作中出现的场景了,而不是单纯的背诵 1:充分理解需求规则.原型图,知道预期结果,操作时判断是否为bug 解析:预期结果不等于实际结果的时候为:bug 因此理解原型图.需求.设计文档.数据库流程,是为了更好的判断.知晓预期结果是什么,这样你才能在发现问题后确定是否是bug. 这就类似咱们考试的时候,老师要判卷子,得先要知道标准答案,才能发现你的对错,所以预期结果准确得知,是测试工程师第一道难关,特别是银行行业.后台程

给MySQL官方提交的bug report备忘

1. Bug #72215 When LOCK_plugin conflicts very much, one uninstall-audit-plugin operation crash http://bugs.mysql.com/bug.php?id=72215 2. Bug #72217 When uninstall a audit plugin, there is a warning info which is not correct http://bugs.mysql.co

zf-关于表单不能提交的bug修改

因为使用onclick="submitForm();" 函数提交的就表示这里面有js代码 js代码里面使用document.from1.submit()提交的所以from 表单的onsubmit 这个属性就不管用了之所以不能提交是因为 submitForm(); 函数里面有3 个日期判断写错了注释掉即可走到document.from1.submit()方法--因为submit是写在方法最后的 .

怎样才能提交一个让开发人员拍手叫好的bug单

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

Bug报告提交规范

首先声明,bug的测试规范应该在公司的正式文档建立.本建议非正式文档,有些内容可能不正确,有些内容可能需要继续商榷,甚至有些内容同公司规范有冲突.如果发现问题,直接忽略本文相应内容.本帖本意仅就工作中的一些现象记录,可以通过简单规范让大家工作轻松,高效.后续继续补充修改,也请大家补充修改. 其次,本帖也仅就填写bug报告的行为进行了一些梳理和建议,不能取代正式的bug测试流程或质量管理过程. 内容: 填写bug报告,可能是专门的测试人员或者开发人员,甚至其他临时帮忙或者最终用户.发现bug和解决

提交bug的标准及书写规范

Bug有效性 1.交付过程中测试者需按照专家设定好的模块,对Bug进行归类提交: 2.Bug的类型默认为UI问题.功能问题.崩溃问题,提交Bug时不能弄错: 3.需求是否明确.前提条件是否满足.输入数据是否正确.操作步骤是否清楚.Bug是否唯一性: 4.避免提交设计如此.操作错误.重复的.已知的Bug: 5.尽量少花时间在边界值.页面显示问题上,多提业务逻辑功能.交互测试方面的问题: Bug标题 Bug标题要求简明扼要的阐述问题本质,使查看人员能快速了解Bug内容.需要写明在哪个页面执行什么操作

bug描述技巧

进入测试行业已经两年了,我从未认真的考虑过提交一个bug需要注意哪些问题,只是主观的认为我只需要描述清楚就OK了,但是我在工作中发现有个别的开发经常跑来告诉我"这个bug你是不是描述错了","这个bug无法复现"--每次听到这种问题的时候,我都会按照我的bug描述去重现这个bug,我每次可以重现--后来我意识到这大概是因为我的bug描述的不够简洁,开发人员没有耐心一步一步的根据我的描述去操作.其次我并没有注意到在测试时,需要对bug的普遍性做出总结,我在测试过程中通

APP成功上线前的bug解决方案

首先测试用例设计阶段,设计并维护一个各个功能入口的说明文档.其实这个文档的作用很大,一方面对于bug回归阶段的人来说,这是用于提醒的;另外一个方面,在随机测试的时候,随机程度也能有所提高,测试人员能够自己随意组合可能的路径.当然,一样一份文档也能提升文档设计人员,文档阅读人员对于模块的整体认识. 在Bug提交阶段,评估阻塞用例说明.在项目初期,尤其是版本刚提交的时候,往往会出现功能无法使用或者没有实现的问题,这时候我们提交bug并不仅仅是说明预期没有实现,更重要的是我们如何备忘这件事情,如何保证

关于kindeditor中点击图片后，滚动条往上顶的bug

比如现在我插入两张图片, 无论我点击哪张图片,里边的滚动条都会往上顶. 本来以为往上会有解决方法,一查结果没有:然后想着去官网查查,然而什么都没有,想到官网提交这个bug,结果没地方提交. 怎么解决,如果单是解决这个bug,去研究源码,我觉的是吃力不讨好的. 然后我就直接从 click.mousedown 这两个事件找起,找它们获得高度的地方,然后感觉是的话就console.log下,看是不是.然后就找到了. 在这个函数里 pos : function() { var self = this,

百度地图ip定位，不算bug的bug

做为一个入行不足两年的菜鸟,能在博客园写下第一篇博客,是需要多大的勇气啊.主要还是怕大神们喷啊.其次自己文笔实在太差了. 哈哈~还请各位大神,口下留情啊. 首先说下我的需求:一个需要城市分站的手机站. 当用户访问时自动定位到用户所在的城市.因为之前做微信开发的时候,研究过一段时间的百度地图api,拿到这个需求后,第一时间想到的就是ip定位api. 先贴出百度官方的说明: IP定位 API是一个根据IP返回对应位置信息的http形式位置服务接口,支持多种语言调用,如C# .C++.Java等,即通

ASP.NET MVC的Ajax.ActionLink 的HttpMethod="Get" 一个重复请求的BUG

这段时间使用BootStrap+Asp.net Mvc5开发项目,Ajax.ActionLink遇到一个重复提交的BUG,代码如下: @model IList<WFModel.WF_Temp> @{ Layout = null; } <!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width" /> <

Bugtags：移动时代首选 Bug 管理系统

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

Safari on iOS 7 中Element.getClientRects的Bug

在Safari浏览器中,DOMElement和Range对象都提供了getBoundingClientRect方法和getClientRects方法.顾名思义,getBoundingClientRect就是获取一个DOMElement或者Range对象的最外围的包围矩形的基于视口左上角的坐标,返回对象类型为ClientRect,getClientRects就是获取一个DOMElement或者Range对象的所有组成矩形的基于视口左上角的坐标,返回的对象类型为ClientRectList. 但是在

bug的处理流程

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

web 表单提交按钮的测试点

web表单中的提交按钮的测试点: 在提交前需要理解清楚的点: 1.表单中哪些字段是必填项 2.表单中字段内容的限制:非空.重复.长度.特殊字符,空格.以及一些和业务相关的约束条件测试点: 1.是否支持回车 2.单击 3.快速双击, 可能会导致重复提交的bug 4.网络中断 5.只输入必填项,单击提交 6.分别缺少一个必填项.单击提交(无效等价类不能合并) 7.所有字段的最大长度,单击提交 8.所有必填项+非必填项 ,单击提交 9.提交成功是否有提示 10.如果有上传附件,附件超大.网络慢,提交

bug生命周期&bug跟踪处理

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

如何更有效地说服开发接收你的bug？！

来来来,测试小伙伴们,看看以下这张图是不是觉得很熟悉.. 虽然这张图带点戏谑的成分,但确实折射出大部分IT公司测试人员在报bug时,与开发的沟通存在些许问题.如何更有效地说服开发接收你的bug,以下整理下资深老鸟们给测试新人的一些建议: 1.首先确定这是一个个实实在在的bug. 不要出现因为配置原因或者是操作错误引起的“bug”,这样是会被开发“鄙视”的.比如说在测试过程中,短信平台没有配置,手机当然就接收不到短信,然后直接就提交bug了.作为测试人员应该尽量做到专业,尽量少给开发找麻烦,不要制

用excel记录测试bug问题总结

前几天与开发在讨论问题的时候,开发提了一个问题,说是已经解决的问题,能否用excel表格总结一下,问了一下原因,感觉想法很好,就总结了一下. 在上家公司的时候,提交bug用的是mantis,现在是禅道,两者模式差不多,都是提交bug.开发修改.测试验证是否解决,解决了关闭,没有解决则打回重新解决. 这个时候,假如开发在解决bug的过程中引入了新的bug,该如何判断是哪些操作引入了新bug?一般情况下,开发人员与测试人员在验证bug的时候,都是就题解题,很少会去关心其它方面. 例如:A点到D点,有

印象深刻的bug

测试中测到一个印象比较深刻的bug,问题出现在web端的电商平台,展示商品的时候每点击一个商品相应的url=~/productid.html,如果知道productid可以直接在url输入跳转到商品详情,相应的下单的时候会生成一个ordid,订单详情页url=~/ordid.html,于是随意更改了几个ordid试了试,发现可以浏览订单编号存在的别人的订单详情,没有做权限过滤故提交这个bug. 开发解决方案:在访问订单数据前获取登陆用户信息做权限处理. ‘

大家提交的bug一样怎么办

热门专题