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

　　在上一篇文章中介绍了bug的“官方”定义和个人见解，其中涉及到了“产品说明书”这个对于当前一些软件项目而言尚属理想主义产物的东西，在这篇文章中，我分享给大家的就是我之前所经历的一个类似的项目经历，当然也要献给大家一些我的“偏方”。51Testing软件测试网8H v"vL uVh],l1a sN q

　　对于同一个问题，不同的人会有不同的看法，“一千个观众眼中有一千个哈姆莱特”就是这个意思。这句话用来形容开发人员和测试人员对于bug的态度就更加贴切了。很多的时候，当测试人员发现并提交了一个bug之后，得到的开发人员的回应是“This is not a bug”（这不是一个bug）或者“这不是一个严重的bug”之类，我第一次听到这句话的时候心情是相当沮丧，进而转化为愤怒。

　 　没有“产品说明书”，凭什么这是bug？这的确是个问题。问题生来就是被解决的，所以我们一定治得了它。最直接最天真的想法可能就是建立起一套完善的机 制，有了产品说明书不久结了么。果真是个好办法，可是太理想主义了，这就如同老鼠挂铃铛故事中的那一群老鼠一样，办法是很好，但是却无法实施或者很难实 施。一套合理的软件流程不是朝夕之间的事情，更何况一套完善的机制也不可能完全杜绝未定义bug。怎么办呢？另一种办法来了：有事好商量呗。51Testing软件测试网T9toP&R@Jx

g%J_/n!A0　　在进行讨论之前，测试人员还是有些准备工作要做的。对于“bug”这种罪大恶极的东东，我们应该列举其罪证。这个时候可能拿着《软件测试》 上面的东西来解释就显得有些苍白无力，这毕竟是测试人员的“圣经”却不是开发人员的。夸张点就像两种信奉不同宗教的人一样，可以说是一个信奉上帝，一个信 奉阿拉，你叫人家阿拉伯人跟着美国人信奉基督教，那显得有点过分了吧。更何况“圣经”上面讲的东西也是泛泛而谈，并没有严格指出bug到底长什么样子。这 个时候更加合理的办法是列出自己的考虑的点，也有更有说服力的做法——找一些可以印证自己看法的知名软件产品中相同或者相似功能点，在这一方面“微软”可帮了不少“忙”。51Testing软件测试网#|MU'y BN;D+W

　 　开始讨论了，双方本着实事求是的态度来讨论这是不是一个bug，这就如同一场法庭辩论。测试人员作为原告代理律师，开发人员作为被告代理律师，项目经理 作为法官。记住，我们只是律师来的，所以宣判的结果并不会直接影响到我们，因此测试人员千万不要把自己当成原告，开发人员也不要把自己当成被告他爸（实际 情况却经常这样，测试人员把bug当作自己的战利品，而那可是开发人员辛辛苦苦创造出来的软件啊），我们应该以理性的态度来审视这个待定的“bug”。开 庭之后，原告代理律师陈述己方观点，接着被告代理律师陈述，然后双方进行短暂的和平而友好的辩论，然后宣判，不准上诉。51Testing软件测试网g!|"LJ["@

　　当然还需要注意的是，这个会议尽量不要占用大家太多的时间，也没有必要十分正式的邀请一大帮人来开会，但是开会完毕之后，测试开发双方要无条件接受讨论结果并及时进行相关的处理。

　 　笔者经历的项目中，很多时候都是测试人员取得了最终的胜利，这倒不是因为笔者强势或者咄咄逼人，更多的时候我拿出相关著名软件的例子之后并陈述为什么应 该这样做之后，开发人员便接受了这样的解释。当然，有时候也是测试人员不了解软件产品相关领域知识而导致了误报bug，这个时侯测试人员应该心悦诚服地接 受“This is not a bug”，这个时候任何多余的动作或者言语都是无效的，不仅不会给自己带来什么好处，也会给项目组带来不和谐的因素。在全民建设社会主义和谐社会的年代， 大家都要和谐~51Testing软件测试网r!D~9|w3rz,SR

　　以上为个人意见，如有意见建议，欢迎一起交流。51Testing软件测试网Jg,?$v'lz FJ%EB

9C%],oZRK7Z/OPl"{0相关链接：

A$\"S_yL'[0软件测试Bug之“庐山真面目”