软件测试中关于Bug沟通的一些细节和建议

发表于:2012-9-25 11:39

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:51Testing软件测试网采编

  这两周产品线加速bug收敛速度以来,开发和测试人员陆续的反馈了一些问题,大部分都属沟通类或者细节类。对几种典型问题,测试人员也经过了组内讨论,希望能在细节方面,大家都能注意互相提醒一下,提高产品线的运作效率。

  一、resolve的bug,验证不通过,然后把bug进行reject操作----------这个处理过程,会出现一些疑义。

  目前测试组进行约定,测试人员验证resolve的bug,未通过验证后,首先要做的是和开发人员进行沟通,而不是直接把bug进行reject操作。

  bug验证不通过,可能存在很多方面的问题:

  1.1 版本编译问题

  1.2 多封闭版本提交错误问题

  1.3 模块编译和整体编译时间不一致问题

  1.4 测试人员版本未更新

  1.5 测试人员验证条件不满足,实际bug未得到有效验证。

  1.6 开发人员resolve为模块提交时间,和实际版本可获取时间有提前性。

  很多时候,bug验证未通过,不是开发人员或者测试人员的问题,流转环节的问题,需要大家一起沟通讨论,才能定位,从而提高团队的运作效率。

  同时,针对resolve的bug,特别是很难复现的bug,也希望开发人员能够说明解决的问题点,给出建议的测试方法。

  针对必现或者很容易复现的bug,测试人员知道验证方法,按照原来的操作步骤进行多次验证,如果未出现问题,那么就认为解决。

  针对很难复现的问题,如果没有开发人员的指导,测试人员去验证此类的问题,只能依靠拷机,大规模的覆盖测试,一段时间后没有出现此bug,再进行关闭。实际上,这种验证方式,效率很低,而且不一定真正的验证到了问题点。

  所以这是一个双向沟通的过程:开发人员主动的说明问题原因、解决方案和相关测试建议;测试人员主动去询问问题原因、解决方案和相关测试建议。

  二、一个较难复现的问题出现,bug打出去,开发人员要求复现,到底要不要做?

  针对这个问题,开发人员和测试人员每天都要纠结好一阵。从产品线现状而言, 也不可能做到一刀切,按照严格的要求去必须复现或者必须不去复现。

  无论是开发人员或者测试人员,大家都有自己的任务指标。很多时候,就需要动态的把握具体的工作

  是否要复现某问题,给测试人员提出几个判断的标准:

  1、开发人员是否没有相关测试设备、测试环境,必须要使用测试环境来复现。

  高清项目以来,很多设备单价都很高,产品线的设备不多,或者新产品的demo板卡不多,针对这种情况,测试肯定是需要协调资源,提供给开发人员自行复现,或者帮忙复现问题的。还有,比如大容量的测试,长考,mcu的三级级联适配逻辑等,都可以根据实际的bug情况,很直观的判断是否需要在测试环境进行复现。

  2、如果要复现问题,开发人员是否提供捕获信息的要求,提供新版本进行复现?

  一个bug出现,大家在测试环境查了半天没有定位,然后重启,回头给测试人员说,再复现一下。--------这种表现,是效率很低的体现。

  如果一定要复现问题,希望能大致判断几个问题点,然后和测试人员沟通下,需要如何捕获信息,捕获那类信息?是不是提供debug版本进行复现,或者根据预判的点增加打印信息版本进行复现?

  一个很浅显的认识: 一个bug,如果出现问题后,根据结果状态无法定位,那么再复现出现问题,我们认为依然无法定位。那么我们就尝试捕获问题出现前,问题发生过程中的一些状态、逻辑。那么肯定就涉及到对一些信息进行捕获,对一些过程态进行打点、跟踪和反馈。

  这也是希望开发人员能积极和测试人员沟通的点。

  如果一定要复现问题,那么,让我们大家的工作更有价值,有效率。

  3、问题或者项目优先级。

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • littlehj
    2012-9-26 09:26:51

    测试VS开发,纠结的关系·

  • uouske0
    2012-9-26 00:34:43

    不错

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号