我很不喜欢我提交的问题被开发同事贴上“无效问题”的标签，你呢？我想每一个测试员都应该尽量使自己提交的缺陷都能得到修复，这需要一些提交缺陷报告的技巧了。想要很专业地提交没有任何歧义的缺陷报告，可以看看我之前发的一个帖子“怎样才能写出好的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的过程中所犯过的错误吧，这样的话，其他读者可以从你的经验中吸取教训！