bug被拒绝的幕后
我做GUI测试的时候，BUG经常被拒绝或者遗留，因为严重等级低暂时遗留也正常，但被拒绝的大多是由于开发人员的疏忽造成的，错误太简单，开发不愿意承认，修改完程序之后就给拒绝了，我一般都当自己没提过这个缺陷，提交缺陷的目的也是为了修复缺陷，既然改过来了就算了。但是这种事情屡有发生，比较恼火
大家觉得应该怎么妥善处理。。。 比如说英文标题拼写错误:lol 提交bug的时候也都附有截图的 遗留到那，确实是问题改不改他的事 发现bug一定要报，不报导致的结果只能说明你测试的问题。报了不修是开发的问题。开发事情多的时候很有可能不去修复一些简单的bug。你可以在他们空闲的时候去说说这些问题。这样人家比较容易接受。 对的哦:) 一个是要留截图证据，另一个是在流程控制上，可以让测试人员有拒绝“拒绝”的权利。也就是开发人员拒绝不能是最终的拒绝，而只是“申请拒绝”，是否真的可以拒绝，要由测试人员来决定。如果测试人员反对“拒绝”，可以将bug提交给开发经理，由开发经理去管教一下手下。
如果使用URTracker软件，可以这么设置流程：在“申请拒绝”（这个时候提交给了测试人员）后有两个可选的步骤，一个是关闭bug，另一个步骤就是拒绝bug，将bug提交给项目经理。 你们那里是什么平台？监管性强的话再小的BUG开发也会改的，写错个句号我都要求改。:lol 要真正搞清楚：开发为何在修复之后，要拒绝？:)
对症下药，这个才是最为关键的，一味地蛮干不一定能起到最好的效果。 我们公司有一个专门的In EQA的中转机制，他们会把测试报上去的BUG分类，比如是一些UI的bug，他们就直接修改，然后如果是开发上的BUG他们会转给开发。当然BUG级别是个很重要的问题，开发那边根据级别来修的，一般重要等级比较低的他们会滞留或是放弃。当然，在测试过程中，也有很多不能被修复的BUG，如果开发有给出代码无法修复的回答，你也只能关闭BUG。
发现BUG是一定要上报的，不管开发怎么样处理，这是我们测试的职责。别烦恼，无忧测试，软件无忧，测试人员也要无忧呀！呵呵，积极一点哟！ :victory: 证据一定要有啊,做银行的都习惯截图了
况且银行方面也要求那样做..... 不规范的流程，这种情况很正常 曾经也遇到过这种情况，但是我习惯截图，如果遇到重要的bug，会当面和他们确认了，让他们知道有这个问题存在。我们这边的缺陷流程不允许开发直接拒绝就关闭bug的，如果拒绝了，测试允许状态修改为无效或者关闭，无效意味着不是bug，而关闭意味着测试判定是bug
还有，就是测试环境控制在测试这边，每一个版本的更新测试来控制，也就是开发提交一个版本之后，那么下一个版本修改了什么内容，更新了那些文件，这个是由测试控制的，所以开发就是偷偷修复了一个bug，那么除非更新否则这个版本之内，bug应该是能够重现的。 直接把这个现象发邮件抄送给总裁吧，记得附上几个“证据” 这个问题恐怕是现在测试人员经常遇到的问题了，我个人认为这种问题倒好解决。凡事都有个标准，在测试结论中应该会有体现，如： UI级bug的数量、2-3级bug的数量等，其实这个标准就是让老大们告诉大家他们能忍受这个软件或系统有什么样的问题。有了这种类似的标准，剩下的就不用我去说怎么办了吧，呵呵。
小弟拙见，欢迎大家拍砖 还幕后……楼主是标题党 首先，太低级的缺陷不应该出现在测试版本中，单元测试应该是由开发人员做得，如果此类问题太多，觉得你们的开发流程有问题。
其次，建议找到的缺陷要正规的从缺陷跟踪系统走，这样产生的问题好跟踪，好统计。
最后，提缺陷的时候要提供各种信息，好比说的截图，其实还可以使用HyperCam录屏，Windows和Linux环境下面提供了dump工具，可以把内存中的信息保存下来供开发使用。 我不知道你们是什么项目组织结构
是职能性？那你就保留截图给你的部门经理报告
是项目性？那你就保留截图给项目经理报告
是矩阵性？那就保留截图给你的部门经理和项目经理都报告 最直接有效的，也是最难实现的方法就是完整的开发测试流程。呵呵。我遇见过最低级的bug普通储蓄取款界面的标题栏竟然是普通储蓄存款。
页:
[1]
2
