软件测试Bug之“自定义”bug.doc

软件测试Bug之“自定义”bug
发布时间: 2012-5-10 13:47    作者: Aaron Wu    来源: 51Testing软件测试网采编 
所谓“自定义”是指针对于当前很多软件项目中没有“产品说明书”或者没有合格的“产品说明书”这类现实主义情形而言的。
在上一篇文章中介绍了bug的“官方”定义和个人见解,其中涉及到了“产品说明书”这个对于当前一些软件项目而言尚属理想主义产物的东西,在这篇文章中,我分享给大家的就是我之前所经历的一个类似的项目经历,当然也要献给大家一些我的“偏方”。
对于同一个问题,不同的人会有不同的看法,“一千个观众眼中有一千个哈姆莱特”就是这个意思。这句话用来形容开发人员和测试人员对于bug的态度就更加贴切了。很多的时候,当测试人员发现并提交了一个bug之后,得到的开发人员的回应是“This is not a bug”(这不是一个bug)或者“这不是一个严重的bug”之类,我第一次听到这句话的时候心情是相当沮丧,进而转化为愤怒。
没有“产品说明书”,凭什么这是bug?这的确是个问题。问题生来就是被解决的,所以我们一定治得了它。最直接最天真的想法可能就是建立起一套完善的机制,有了产品说明书不久结了么。果真是个好办法,可是太理想主义了,这就如同老鼠挂铃铛故事中的那一群老鼠一样,办法是很好,但是却无法实施或者很难实施。一套合理的软件流程不是朝夕之间的事情,更何况一套完善的机制也不可能完全杜绝未定义bug。怎么办呢?另一种办法来了:有事好商量呗。
在进行讨论之前,测试人员还是有些准备工作要做的。对于“bug”这种罪大恶极的东东,我们应该列举其罪证。这个时候可能拿着《软件测试》上面的东西来解释就显得有些苍白无力,这毕竟是测试人员的“圣经”却不是开发人员的。夸张点就像两种信奉不同宗教的人一样,可以说是一个信奉上帝,一个信奉阿拉,你叫人家阿拉伯人跟着美国人信奉基督教,那显得有点过分了吧。更何况“圣经”上面讲的东西也是泛泛而谈,并没有严格指出bug到底长什么样子。这个时候更加合理的办法是列出自己的考虑的点,也有更有说服力的做法——找一些可以印证自己看法的知名软件产品中相同或者相似功能点,在这一方面“微软”可帮了不少“忙”。
开始讨论了,双方本着实事求是的态度来讨论这是不是一个bug,这就如同一场法庭辩论。测试人员作为原告代理律师,开发人员作为被告代理律师,项目经理作为法官。记住,我们只是律师来的,所以宣判的结果并不会直接影响到我们,因此测试人员千万不要把自己当成原告,开发人员也不要把自己当成被告他爸(实际情况却经常这样,测试人员把bug当作自己的战利品,而