我很不喜欢我提交的问题被开发同事贴上“无效问题”的标签,你呢?我想每一个测试员都应该尽量使自己提交的缺陷都能得到修复,这需要一些提交缺陷报告的技巧了。想要很专业地提交没有任何歧义的缺陷报告,可以看看我之前发的一个帖子“怎样才能写出好的BUG报告?提示与技巧”。

  BUG会被贴上“无效”标签的主要原因是,测试员在提交BUG之前没有做“足够的故障排除”。在这个帖子里,我将重点讨论引起BUG的主要原因的故障排除。故障排除可以帮助你判断,在测试过程中发现的“可疑问题”到底是一个真正的BUG还是说只是由于某些测试设置错误引起的。

  没错,有一半的BUG被贴上“无效问题”的标签,是由于测试员不完整的测试设置而引起的。我们打个比方,你在测试系统的过程中发现了一个“可疑问题”,你是不是马上把它判定为BUG,准备写好操作步骤,然后提交报告呢?但是,且慢!你在提交这个BUG之前有没有做了足够的故障排除呢?或者说你真的确定它是一个BUG吗?

  在提交BUG之前,需要做哪些故障排除呢?

  包括以下几点:

  ● 什么地方出错?

  ● 为什么会出错?

  ● 怎么才能使它正常运行?

  ● 出错的有可能的原因是什么?

  要把问题提交到缺陷跟踪系统里面,第一个问题“什么地方出错”的答案已经足够了,那么为什么还要回答剩下的三个问题呢?站在一个更高的层次来考虑这个问题吧。要表现的醒目一点,不要像头拉磨的驴一样,只是不停地重复打转而从来不想想外面的世界。你应该可以提出解决这个问题的所有可能的方法,同时还有每个方法的优势和劣势。这样既可以让你赢得团队的尊重,又可以降低你的BUG被驳回的可能性,这并不是因为别人有多尊重你,而是因为你的故障排除的能力。

  在提交任何BUG之前,要确保不是因为你自己的错误而引起的,(有可能在测试过程中)你忘记了设置某些重要标记,或者没有正确的配置测试环境。

  找出系统不能正常运行的原因,在正确的故障排除的基础上,再提交相应的缺陷报告。

  我总结出来一个故障排除的列表,看看吧 --- 系统失效的各种可能原因。

  系统失效的原因:

  1)当你测试的软件系统涉及到配置文件时,要确保你的配置文件是新的且符合需求的:很多时候,一些全局配置文件是用来获取或者设置某些程序标记的,此时,根据软件需求,如果配置文件的维护出现了问题,那么会导致在测试的过程中系统出现故障,这个并不能当作BUG来提交。

  2)检查数据库是否正确:表的缺失是引起系统不能正常工作的主要原因。

  我举个我亲身经历的典型例子:我曾做过这样一个项目,是通过查询多个月用户表来打印用户报表。第一个表是放在主表里面(这个表主要是用来维护月表名的),而数据则是从各个不同的月表中查询得到。很多测试员都是选择了一个很大的日期范围来查看用户报表,但是,由于这些表并不是存在于测试服务器上面,很多时候会引起系统的崩溃,同时报SQL查询错误。这个时候,测试员会把这个问题当作是一个BUG来提交,然而,随之而来的则是开发同事将其标为无效。

  3)如果你是在用自动化测试工具的话,那么在认为这个系统失效是个BUG之前,需要再次调试你的测试脚本。

  4)检查你是否使用了非法身份访问系统。

  5)检查软件版本是否兼容。

  6)检查是否存在一些与系统无关的硬件问题。

  7)确保系统的硬件和软件配置都是正确的。

  8)检查测试机器上是否正确安装了所有的软件组件,检查注册表项是否合法。

  9)对于任何的系统失效,可以打开“系统事件查看器”来获取详细信息,根据这个系统事件日志文件,可以追踪到很多错误出现的原因。

  10)在测试之前,要确保已经把所有新的版本文件上传到测试环境里面了。

  虽然这些都是很细小而且很常见的错误,但是对于你在团队中的关系以及可靠性方面却有很大的影响。当你发现你提交的BUG被标记为无效,而无效的原因从上面的列表中可以找得到,那是一个相当愚蠢的错误,很有可能会伤害到你自己的自信。(至少对于我来说是这样的!)

  分享一下你在提交BUG的过程中所犯过的错误吧,这样的话,其他读者可以从你的经验中吸取教训!