关于bug的沟通

【关于bug的沟通】的更多相关文章

关于BUG的沟通一个人要去做一件事情,一般来说是按照自己的意愿去做的,如果不是自己想做而是被要求这么做的话,心里一定会留下点不愉快,特别是那种有自信有自己主见的人,比如说开发人员,当测试人员发现一个BUG,然后告知开发人员后,开发人员之所以会去修改BUG,是因为他自己认为的确需要修改,而不是因为你提到要改他才改的,所以当他认为不需要修改的时候,肯定是有自己的想法和理由,不妨理解下他们,合理的就可以接受,不合理的话,也不要强制的让他去修改,试着解释给他听,让他心甘情愿的去修改,这才不会让他心里产…

作为测试人员，我是这么报BUG的

在测试人员提需求的时候,大家经常会看到,测试员和开发一言不合就上BUG.然后开发一下就炸了,屡试不爽,招招致命. 曾经看到有个段子这么写道: 不要对程序员说,你的代码有BUG. 他的第一反应是:1.你的环境有问题吧:2.你踏马到底会不会用? 如果你委婉的说:你这个程序和预期的不一样,你看看是不是我的方法不一样. 他本能的会想:是不是程序出BUG了. 后来发现,段子也只是个段子.当然,这些只是种辅助报BUG的沟通技巧,实际工作也是要知道如何正确描述BUG也是很重要滴. 1. BUG存在性测试员在…

定位bug的姿势对吗？

举个例子来说明 WEB页面上数据显示错误,本来应该显示38, 结果显示35,这个时候你怎么去定位这个问题出在哪里? 1.通过fiddler抓包工具(或者其他抓包工具), 分析接口返回的数据是35还是38, 如果返回的是正确的,那就是前端的问题, 如果返回就是错误的, 你还得看看我们请求的参数是否正确,如果不正确,那肯定是前端的问题,如果正确,那就是后端的问题,接着以下步骤看 2.分析这个数据的业务, 搞清楚这个数据是怎么产生的, 把数据的源头到显示整个业务流搞清楚, 通过日志和数据库, 检查每…

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

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

UI型Bug定义的处理方法

[UI型Bug定义] 这里指的UI型指以下两种Bug: 第一种是文字型Bug,即和给定的字符资源不一致的Bug,比如文字/字符/提示语/引导语/用户协议等文字方面的不一致. 第二种是UI效果不一致的Bug,比如应该是个圆角按钮,做出来的界面却是个平角的按钮;有下拉箭头效果,做出来的界面却没有下拉箭头效果;混动界面应该有3屏,做出来的界面却只有2屏,诸如此类. [UI型Bug的产生] 理论上UI型Bug的产生只有一种原因,即开发人员没有按照需求文档或者UI做. 开发人员为什么没按需求的要求去实现?…

围绕Buganizer的产品流程

做技术的一定知道缺陷跟踪系统(bug系统),更不用说做测试的了,不过普遍都认为这系统是用来记录bug的,其实在google内部,这套系统是产品/项目围绕的核心.Google Buganizer扩展了类型,包含的不仅仅是缺陷,还有功能需求.流程.客户问题等,今天就来介绍下围绕这个系统是如何将产品所有人员联系在一起. 1. Bug 这个就不说了此处略过,只要是缺陷,都会登记到系统里,无法重现的bug也必须登记,对应的开发进行了修复,匹配上changelist(CL),这个CL进了哪个release,…