你为什么没找到那个bug?

发表于:2014-10-21 11:45

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

 作者:Stephen Blower/大头    来源:51Testing软件测试网采编

#
Bug
分享:
  作为一名测试人员我知道我不可能找到每一个错误。但即便如此,当一个问题从你眼前溜过,跑向生产这一本垒时,我经常会问自己,我怎么就漏过了这个问题呢?有什么是我可以做得更好的?我能做些什么来防止未来这种情况的再次发生?
  这些都是很好的问题,但更实际的来说,我们需要认识到一点,错误往往会偷偷溜过而未被我们发现。有一些方法可以帮助我们减少这些未被发现的bug数量,但我明白没有任何办法能够保证产品完全无缺陷。
  当我刚开始做测试时我总是对别人在我测试过的产品的部分发现bug非常敏感。我常听到办公室回响着可怕的句子——“谁测试过这个?为什么没有发现这个错误?”那时我还没有足够的经验可以通过合理的方式来争论,为什么不是任何产品在任意给定时间段中都可以找到所有的bug。
  虽然在某些方面,这些经历帮助我使我的测试方法更完备。
  所以,我列出了一些你可以尝试一下的事情,以限制未被检测到的bug的数量,我有几个故事分享给大家,关于那些像夜晚的忍者那样悄悄溜过而未被我发现的错误。这些故事表明,即使最明显的错误(一旦知道就觉得很明显),可能发生也将发生。
  我们怎么会错过呢?
  在一个项目中,一个网站,正在一些关键部分,如注册和产品选择进行了重新设计并添加了一些额外的功能,我花了大约两个月进行各种测试活动。在这段时间内熟悉设置的各种变化和改进,我们都知道危险,并试图减少它们,我们找了一些人来进行用户支持测试以帮助测试。不幸的是,这些主要覆盖在验证bug修复或者专门针对测试网站的某些部分。
  在产品环境中启动网站的第一分钟,一个问题被确定。这是非常明显的bug,也产生了一些相当大的混乱,它是怎么能够被错过的。这个问题并不是说需要任何除了会拼写之外的特殊的技能才能找到的。在该网站的首页(它通常被称为商店橱窗),客户登陆后看到的你的网站的第一页,在屏幕中间非常大的字体,写着“BRAODBAND“而不是“BROADBAND”。 “这是一个非常明显的错误拼写,但不知何故,每个人都错过了发现它,直到这个网站开始使用,然后由于某种原因,这个错误立即被所有人发现了。
  它是活的!
  我现在受到了“它还活着”,在1931年的老电影科学怪人中那句台词的启发。当产品处于成熟状态,我用这句话来慢慢的推进我的想法,为了能够看到那些可能被我错过的东西。在这种情况下,问题是那么明显它造成了混乱的奇怪的氛围,而且可能因为修补程序过于简单而无从指责。然而,这很清楚地表明了,即使是最公然明显的错误也很容易被很多人错过。
  本应该,早该,早可以。
  这些错误不一定在测试过程中由于没有找到他们而被错过,而是因为测试者没有考虑如果X事件发生了,在整个开发周期中将会或者可能会发生什么错误。当在当天晚些时候发现或者当产品在生产过程中发现这些bug时,常常招来了一句“是啊,我就觉得这可能会发生”或“我就知道会发生这个问题。”
  这些方案有时被称为边缘情况(极限测试情况下)或边角情况(非常具体的,很少发生的情况下)。后者常常使我感到惊讶,因为它们可能很早就在项目中被定义为边角情况,可是后来发现实际上是一些经常发生的情况。这主要是由于不理解系统以及其相互作用够好才能够使得最初做出这样的判断。
  我曾有过此类的经历,测试一个新的需要处理成千上万的客户记录的应用程序。在测试过程中,我问了一个问题:“是否进行过负载测试?”对此的答复是“哦,这不是问题,它可以轻松地处理高达一百万条记录的负载。”然而,当推出了这个改变后,在前几分钟有显著的负载,经过观察其证明之后会导致严重的问题并且对应的代码会被还原。在那段时间,我并没有完全理解所涉及的技术,并假定了开发人员比我知道得更清楚,可能已经考虑过这个潜在的问题。从那天起我才知道,当我有直觉某处可能有问题,我不应该认为别人快速而简单的答案就是真理。我应该从别处寻求可以支持的资料以证实或反驳我的假设。
  我的第六感正在提醒!
  我把这称为我的“第六感”启发,当我对某些东西有一种感觉,比如我不能完全的理解或我所得到的信息看来可疑的情况下,我不愿意就此忽略它并继续下一步除非我对其有一个合理的认识。在这种情况下,我会让参与该项目的每个人都知道,我对这部分有所顾虑。这通常会有所帮助因为其他人会开始质疑为什么我会有顾虑;无论是由于我缺乏相关知识使得我的假设是错误的,或我的假设是正确的,对我而言都没关系。重要的是,我明白如果我忽视自己的直觉进行测试,我不认为自己能有效地做好工作
  容易复制。不容易找到。
  通常如果测试需要涵盖产品或系统的各个方面,其场景数量会高得难以负担。即使对于看来可以相对简单的进行测试的系统也可以有数以百万计的排列。有些办法可以处理这样的问题,其中之一被称为成对(或组合)的测试,我不会在这里来详述这个方法,但如果你想了解更多,可以看看Michael Bolton所著的对于这个方法的优秀的处理方式。
  我对于这一类的问题的经历是个标准的负面答案,当发现一个问题时,这是100%可复制的。由于只要通过5个简单的步骤,就次次都可复制,并最终导致“怎么又没发现这个bug?”的指责。
  问题是这样,基于一个复制系统,该系统有多个文件夹,每一个文件都具有三个不同的使用权限,仅读取,读或写以及拒绝。在每个文件夹中,每个文件都可以有相同的三个文件权限。
21/212>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • 薛双
    2014-11-20 14:01:59

    缺陷被漏掉有很多因素,我会常常因此觉得自己能力不够。我想请教,当被开发人或其他人质疑“你为什么没测出来?”时,我们该怎样去反驳呢

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号