【软件测试】程序不改bug,先别动手,听我说

前言

今天的话题,是所有测试员都会经历的,也多为此苦恼过。墨白借此谈谈自己的看法,不求解决现状,只希望大家看完此文后能少一些苦恼。

现状分析

之前,墨白身边一位测试老人提了一个打印文字溢出的缺陷,但该缺陷的负责人,一个年轻的程序员以项目临近上线没时间修改,且该缺陷影响很小而驳回,态度强硬(强硬的诉苦),那位测试专家从开始的坚持到最后无奈妥协,让墨白感触良多。

程序员为什么不愿意修改bug?

无非是没时间,问题太小,重现不了,理解不了,在实际环境中不太可能发生,问题只出现在没有人用的非常特殊的设备配置上 ,改正缺陷的风险太大(特别是临近封版),不会影响程序的实际用户等。

我们测试人员为什么苦恼?

可能是觉得封版之前bug就应该全部解决(强迫症),也可能是觉得程序员没有理解bug的严重性,也许是bug明显违反规范,也可能是觉得缺陷肯定会影响到用户。

我们为什么难以说服程序员去修改那些bug?

说一说我看到的:测试员过于执着(bug并非必须修改),测试员不清楚说服程序员的技巧,测试员看轻自己(程序员一旦强势,测试员就低声下气),测试员技术水平低(不清楚修改bug的成本,可能只是加一个字段就能修复,开发说成本大,测试员就以为真的很大)。

应对措施

应对措施本应跟先将问题分类,分析根源之后再一一作答。不过本文不是严谨的学术报告,只谈几点一般性的措施。

如何说服开发改正bug?

· 解释问题会怎样影响产品的正常使用?

· 会破坏什么数据?

· 用户如何经常遇到这个问题?

· 市面上类似产品的有关评论

· 指出类似的问题给客户带来的麻烦

· 多引用技术支持收集的数据

· 以前的版本通过了这个功能的测试

· 与其他项目干系人沟通。找出如果程序错误不修改受影响最大的人(或修改后受益的人),确定程序错误会给他们带来多×××烦。让关心这个模块的人去说服。

· 列举一些场景,说明合理的用户在合理地使用程序时会遇到的程序错误,或产生的疑问。

· 补充做一些后续测试,寻找该程序错误更严重的后果,或寻找比在错误报告中所描述的更广环境下出现的情况。

补充  

1、对于上面最后一点做点补充:如果程序员不修改某bug而我们决定反驳,不要完全依赖自己最初测试报告中的语言和信息。尽可能做一些补充测试,或列举更有效的例子,否则不仅浪费自己的时间,而且损害自己的信誉,影响自身的说服力。

2、不必坚持修改所有bug。项目经理可能会因为风险、费用等方面的原因,拒绝修改某些bug,这种情况下,我们测试员不需要坚持修改全部缺陷,除非能说明某缺陷可能引入的严重风险。

另外,以下措施有助于推动bug的解决:

1、养成良好的报告编写习惯:比如在报告中描述问题出现的多种配置(需核实),或者在报告中预测某种可能并提供相关信息(特别是难以复现的bug) 。好的错误报告会推动问题的修正。

2、先等一等,在评审时看看大家反映,以静制动,提供补充信息。

3、多用事实和数据说话,例如“某个类似系统也有这个问题,客户因为那个问题,对程序的意见很大,因为客户平均每周要浪费XX时间在上面”

4、学习编程,理解bug产生的原因,助于写出更好的报告,以及理解bug修复成本。

注意点

1、关于利用bug管理系统监视程序员的表现。有的测试经理尝试用bug跟踪数据来促使程序员修改bug,比如利用数据反馈某程序员是否存在大量的bug未修改,或是否修改时间过长,或是否总是推迟修改。是否应该推行这种制度这里不做评论,不过建议推行时需注意引导程序员的情绪,否则很容易引起某些程序员的反感,他们会在某些时候大肆放大测试员的无能,或者发表不利于测试部的言论。不过这也是正常的,bug管理工具只要被用于行政或人事管理,而不是技术管理,就会产生这些问题。

2、关闭bug的权限应控制在测试员手中。除非经过测试员的验证,否则bug都不能闭环。在某些情况下,程序员会将未修复的bug置为“延期修改 ”、“非程序错误不予修改”“重复缺陷不予修改 ”,测试员需要且有义务对此提出质疑。

3、尽量避免“延期修改”变为“永不修改”。在很多公司中,bug标记为“延期修改”即意味着“永不修改”。为避免这种情况,有一种可行的措施是在下一版本做项目范围评审时即提出这些缺陷,那时候的进度压力最小,而且项目经理也最理智、最清醒。另外,发现“延期修改”的bug后,若持反对意见,建议尽快跟测试经理或者项目经理进行沟通。

4、bug修改后尽快验证,回归不通过后尽快跟程序员沟通,否则时间耽误越久,程序员记得的内容越少。

5、如果bug多次回归不通过,或在临近封版时发现严重缺陷,不仅要在缺陷管理工具中记录,更应该直接找到相应的程序员进行沟通。

好了,你们看完了我的文章,我也说话算数给你们分享一下资料。

接口测试相关资料

链接:https://pan.baidu.com/s/1ojpoWnpxxReR1sO2Gxy_YQ 密码:dgfa

性能测试相关资料

链接:https://pan.baidu.com/s/1_oZhvOIRvcz0JGcCWUGT-g 密码:d82b

软件测试入门提升电子书

链接:https://pan.baidu.com/s/1Fp8CFE0D2p0uAZk6xcexhQ 密码:exna

自动化测试相关资料

链接:https://pan.baidu.com/s/1yeD1EMg-HalNuRBDODGx7g 密码:ofdg

原文地址:http://blog.51cto.com/13848818/2310888

时间: 2024-11-08 07:35:29

【软件测试】程序不改bug,先别动手,听我说的相关文章

关于cocos2dx程序的BUG调试解决方案

今天说一下手机游戏开发的调试问题吧.不得不说的是和PC平台游戏.软件开发相比,手机上开发游戏和软件要困难的多.原因是多方面的,比如说开发环境比较复杂,工具软件不够人性化等等. cocos2dx的出现解决了一个很大的问题,因为他是跨平台的,相对来说windows的软件开发环境比较友好,对中国程序员来说更熟悉.这样可以在windows进行日常开发和调试,然后在发布到其它平台的时候进行少量的处理就好了. cocos2dx程序的调试,在windows下和端游类似,可以在后台窗口进行打印,也可以直接在vs

【软件测试】软件测试是找bug,不是找茬

前两天和一个新认识的朋友聊天 "你是码农吗?" 我那个气啊,我这个形象像吗?像吗?真想抽他丫的 "不是,我是做软件测试的,代码用的没有那么多,所以称不上" "哦!那你就是专门挑毛病,找茬的呗?" 当时我就认定了这个朋友拜拜了您内 "我是做测试的,找的是缺陷,不是找茬,谢谢您老了,先忙,再见" 回家了之后我就想分享一下: 第一: 测试是找bug,不是找茬.以前在外包做测试,面对的之间人是PM,面对所谓的客户是开发软件的人,而且因

C语言一个小程序的bug疑问 数组相关

程序目的:输入一个数组的元素数,然后给每个元素赋值,再给出一个值作为关键词,查出数组内是否有元素等于这个值. 代码如下: 1 #include <stdio.h> 2 int main() 3 { 4 int n,m,x,b; 5 int array[n]; 6 7 //本段代码用来获取元素个数 8 do 9 { 10 printf("\n请输入数组元素的个数: "); 11 scanf("%d",&n); 12 if(n<=0) 13 {

练手小项目(5)安全卫士_程序锁bug修复一

程序锁的基本功能,已经实现了,但是你如果输入密码进入 APP以后,看门狗,还是监听你想进入的APP,这时候又会出现一个输入密码的界面. 我先说一下思路. ①思路 1.通过发送自定义广播在服务里面,监控多一个判断如果是临时取消保护的程序就不再启动程序锁 ,这时候,我们要解决的就是什么时候再让他启动监听呢,答案就是 锁屏的时候. 2.通过锁屏将零时保护值设为空就可以继续保护了 但是bug 还是有 那就不停的安返回键 取消 输入密码界面,可以慢慢把界面内容看完,怎么解决呢 解决方案的是: 3. 如果在

程序的bug排查流程总结

只要是人写的程序,不可能没有bug,那么解决bug,将伴随程序员的一生: ? 只会写代码,但不会排查bug的程序员,只能算是业余程序员 ? 能解决一般bug的,只能算是初级程序员 ? 代码写的质量较好,还能查找较难bug的,中级程序员 ? 代码写的质量好,注重性能,不但能排查疑难bug的,还能解决疑难bug的,高级程序员 ? 代码写的质量好,注重性能,稳定性,可靠性,架构设计合理,能解决绝大部分疑难问题,属于资深程序员 以上的话引自某个论坛网站,不一定说的绝对正确,但基本是有道理的. 面对出现的

JDK8安装程序重大bug

jdk-8u151-windows-x64.exe安装程序存在一个很严重的bug.当你的机器上已经安装了jdk8u151时,如果你再次运行这个jdk-8u151-windows-x64.exe安装程序,就算你在安装程序运行起来后并没有继续安装下去,而是取消了安装,这个安装程序依然会将你本地之前安装的jdk-8u151安装目录删除掉. 这个安装程序存在逻辑错误. 我不清楚其他版本的安装程序是否也存在类似问题.

微信小程序开发BUG经验总结

摘要: 常见的微信小程序BUG! 小程序开发越来越热,开发中遇到各种各样的bug,在此总结了一些比较容易掉进去的坑分享给大家. 1. new Date跨平台兼容性问题 在Andriod使用new Date("2018-05-30 00:00:00")木有问题,但是在ios下面识别不出来. 因为IOS下面不能识别这种格式,需要用2018/05/30 00:00:00格式.可以使用正则表达式对做字符串替换,将短横替换为斜杠.var iosDate= date.replace(/-/g, '

开发不改bug?给你支个招

在测试过程中,不免会遇到开发人员因为一些原因不想修改个别bug的情况.那一般遇到这种问题时,我们该如何去推进开发修改bug呢? 我们先来分析下到底会有哪些原因会导致开发不修改bug 1. 开发与测试对bug的定义理解不一致产生的问题,例如暴力操作.非常规操作出现的问题.问题路径深.服务器返回的数据不规范.竞品同样有的问题.个别机型问题等情况,开发可能会不愿意修改. 2. 工作流程方面的原因,例如开发有更高优先级的任务没有时间修改.上线时间紧急,来不及修改.开发不关注名下的bug.开发认为目前的实

怎么进行软件测试才能把bug降到最低呢??

最近经常出现这种问题,一个功能,明明做完了,到整体测试的时候,出bug了,一个流程,明明是测试没问题了,产品到到客户那边还是有很多没有测试到的盲点.或许在有测试团队的公司中,会不会出现的少呢,这个不得而知,而在我看来,大体小公司还是经不起测试团队的消耗的,那如果没有测试团队,只靠开发人员开发后的功能测试,该怎么办呢??,或许是不是该使用单元测试,这样会不会耗时比较长.或者,这样,项目整体测试的时候,在只有几个人得情况下,可以先有一个人测试,其他人修改,然后换一个人测试,另外的人再进行修改,这样会