从BUG库看一个测试开发团队的自我修养-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

从BUG库看一个测试开发团队的自我修养

技术小菜鸟 2016-08-24 20:07:07 3368
程序员不喜欢BUG,每当有人说这里有个bug的时候,就不自觉的启动了自我防御机制,开始在想是不是这家伙不会用什么的,其实恰恰是程序员创造了bug;如果每个程序员都能写出完美的代码,测试人员就该失业了,事实是测试人员越来越重要。人无完人,首先承认自己的不完美,接受bug的存在;程序不可避免的会存在bug,但这不妨碍程序员不断的最求完美,努力写出高质量代码。

BUG不可避免,因此记录BUG的系统就不可或缺。我经常说,看一个团队够不够专业只要看他们的BUG系统就可以了。如果一个开发了近半年的项目还没有一个BUG库,或者BUG系统里记录的内容乱糟糟的,你又如何能认为这样的团队能开发出高质量的产品。


一个BUG的生命周期


关心BUG的就有测试,开发,项目经理,他们在一个BUG的一生中扮演着自己的角色。提出BUG(提出者)-》解决BUG(开发者)-》证实BUG是否解决(测试)-》已解决(测试人员)-》已发布(项目经理,SCM)。


提出BUG的可以是任何人,产品开发内部人员以及外部人员,比方:内部人员有测试,项目经理,开发人员,测试团队;外部人员有老板,客户,用户。事实说明,外部人员无法专业的描述一个bug,建议专门建立一个面向外部的bug录入系统,可以由测试人员,或技术支持来管理整个系统里的BUG。如果确实是BUG,再由测试人员和技术支持人员录入到内部BUG系统中。


项目经理会进一步指派谁解决某个BUG,以及解决的优先级。项目经理判断的依据有:1,根据bug所属的模块,指定最属性这一块的开发者;2,根据大家手里的任务的多少,指定一个开发者;3,根据一个bug的影响程度,严重的bug需要优先解决,测试,立即上线。


接着就是开发人员进行bug的修复,开发人员首先要做的是,仔细阅读bug的描述(具体格式如下),并在开发环境中重新bug,有的时候可能需要专门配置对应的开发环境;重现问题后,分析问题,解决问题,并在开发环境中验证问题是否的确解决了。然后测试人员从某个开发分支获取相应的补丁,有的时候也可能直接在开发搭建的环境中,进行bug修复验证;首先要做的是,仔细阅读开发人员解决bug的描述(如下),然后开始测试验证,注意的是,如果代码影响的范围很多,需要做相关模块的回归测试,防止引入新的问题。测试没有问题,那么就可以标示为“已解决”。


项目经理或SCM从开发分支上获取已验证的代码合并到主干,然后发布新的版本,同时将bug状态标示为“close”。


测试人员必须完整的描述一个BUG


看一下BUG里的描述,就能看出开发团队的素养:专业程度,是否足够负责任:

  • BUG标题:简洁且突出重点,好比给一篇文章起个好名字

  • 所属的功能模块:

  • 复现的前提条件:

  • 复现的步骤:

  • 提供问题的截图以及日志:

附加描述:
测试人员面临一个难题,一个测试发现的BUG究竟应该指派给谁呢?究竟属于后端问题,还是客户端的问题?将BUG指派给正确的人可以有效提高效率,也能避免来自开发的抱怨。这里的几个有效的方法来判别谁是问题的责任人:

1,就是通过对比,你可以同时对比andriod端和iphone端的表现,如果在这两个客户端上都有问题,说明很可能是后端的问题;

2,通过抓网络包看接口数据,或者查看数据库来判别:页面呈现的内容都是基于对数据的加工和解释,如果你能直接从数据层切入,也帮助进一步确定问题的根源。
3,咨询你信得过的前端和后端的工程师。

但不管怎样,测试人员无论如何也无法确认这到底是前端问题,还是后端问题。在这里开发人员也需要给予谅解,如果发现这并非自己的问题,完全可以加上一些说明后,转给对应的责任人。


开发人员简明扼要的说明一个BUG的解决情况


详细填写以下内容可以迫使自己做全面思考,也可以给予测试必要的信息,在确认的时候能了解问题发生的原因,并能就修改涉及的其他内容也做检查。


  • 问题发生的前提条件:

  • 严重程度:从发生的频率,对系统的影响程度,对用户的影响程度几个方面进行评估。

  • 问题原因:

  • 解决方案:

  • 代码影响到的模块:

  • 如何确认问题是否已解决:从日志里确认?开发环境测试?

  • 总结:系统中其他地方是否存在类似问题?引入该问题的原因?下次如何避免类似问题?

开发解决问题要避免“打地鼠”式,大家都见过打地鼠游戏,就是那种你按下了这边,那边又冒出了只地鼠;所以,必须要注意:

1,确定解决了这个问题,不要引起另外的问题。

2,其他地方是不是存在类似问题。
解决完问题后,一个问题作为一个代码提交单位;每次提交,注明解决的BUG号,以及BUG的标题。

BUG的流动


可能会在不同角色间流动,比方分配给某个开发的BUG,他通过了解发现BUG描述不清楚无法开始工作,他会把BUG重新分配给测试人员。也有可能测试发现开发并没有解决问题,就把BUG再转给开发。我认为,正常的流动是必须的,特别是大型系统中,各个开发团队负责一部分内容,所以要果断将不属于自己能力范围内的bug及时转给对的开发人员;也有可能,问题的表象是发生在了客户端,比方字段的显示不对,但根源是在服务器端。那么开发人员必须留下必要的备注说明自己分析的内容,然后及时转给对应的负责人。特别忌讳的是不健康的流动,不加上自己的分析备注就转给他人(不说明来意),或者对测试提的bug吹毛求疵,粗鲁对待。记得,bug系统的存在是为了提高协作效率,不要推诿责任,必要的时候可以直接走到别人的座位上,问清楚原因。

我们提倡有益而又健康的流动,拒绝无谓的,纯粹推诿的流动。


终结一个BUG


除了确实是bug,且被解决了这个happy ending,bug还有其他可能的命运:


1,确实是个bug,但是影响很小,而且修复工作量巨大,导致影响到其他模块,所以不予修复;

2,需求未能定义清楚,导致测试和开发的理解有不同,需要明确需求;
3,是个问题,但有BUG提到了同样的bug,所以需要合并处理;
4,是个bug,但在本次版本中不予修复;
5,是个bug,但始终不能复现,开发人员长时间无法进行调研,所以暂时关闭;

... 总结来说,不是所有的BUG都是BUG,不是所有的BUG都必须解决。


谁是BUG系统的负责人


俗话说一山难容二虎,也就是说一件事只能有一个负责人;那么谁是BUG系统的负责人?我认为,测试人员应该是BUG系统当仁不让的负责人,BUG系统是测试人员的主战场:

1,保证录入的bug质量,检查每个bug描述是否完整准确;

2,以及检查开发人员解决bug的备注是否完整,解释又是否合理;如果解释不合理,必须要求开发人员重新填写;
3,保证每次发现的问题及时录入到系统中,建议测试过程中发现的问题截图收集完日志后,简单用笔记录下。全部完成测试后再一次性记录到BUG系统中。
4,追踪BUG修复的情况:BUG是否在修复中了;及时测试已被修复BUG。

BUG系统的其他重要作用


需求变更库:很多公司不但把BUG系统也称作为需求变更管理库,这就意味着不但可以录入bug,有些小功能,小需求,小的用户体验改进也可录入。我非常推荐这种做法。


测试用例库:我觉得测试最核心的能力之一在于设计测试用例的能力,具体测试的过程,只是一个按测试用例执行的过程。


与版本管理相关联:一个bug的解决意味着代码的提交,所以可将bug管理系统和版本管理系统相结合和关联。


经验教训库:这里的每个内容都是一个你犯过的错误,你在这里也记录的总结和反思;随着系统开发不断往前迭代,BUG的内容也会越来越丰富,沉淀了越来越多的经验,帮助我们了解错误原因所在,避免再犯。


云效平台推出的缺陷管理系统,主要对bug的生命周期进行跟踪管理,包括缺陷的记录、分析、状态更新以及项目缺陷数据的统计分析,帮助规范项目中缺陷处理的流程。



(本文来源: 51Testing软件测试网  )


相关阅读:https://bbs.aliyun.com/read/283975.html?spm=5176.bbsl360.0.0.pbFRoc&fpage=3
前端开发 程序员 测试技术 数据库 开发者 UED iOS开发
分享到
取消 提交回答
全部回答(1)
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

推荐文章
相似问题