InfoQ：您能否就“缺陷狩猎”技术的起源再多谈一些呢？
早在 2003 年我就从 James Whittaker 的一本名为“How to Break Software【译注 2】”的书中读到了它。James Whittaker 在此书中用了一整页的篇幅来阐述他在佛罗里达理工学院所使用的体系，他所描述的内容使我深受启发，于是我在丹麦本地的 SIGIST（2003 年成立的软件测试领域专门兴趣团体）进行了实验来尝试他的观点，然后在阿姆斯特丹举行的 EuroSTAR 2003 大会上，我将“缺陷狩猎”的想法作为实验品进行了展示并获得了成功。
此后在我所工作的几家公司中，我们使用了“缺陷狩猎”技术。在这些经历的基础上，我建立起了对“缺陷狩猎”技术的一些研究成果和经验教训，随后，在印度新德里、澳大利亚的悉尼和堪培拉、欧洲的布拉格和赫尔辛基以及这次在里斯本举行的一系列大会上，我将我的研究成果进行了展示。
InfoQ：您是从何时起被这种技术所吸引的？为什么？
我对“缺陷狩猎”技术可以说是一见钟情。因为“缺陷狩猎”在测试中混合使用了多种测试技术，而结对工作的方式促进了测试技术及专业领域知识的分享和传播，更加锦上添花的是，与此同时你还进行了团队建设。
此外还有一个天大的好处：你获得了被测软件的相关知识，从而能够详细全面的记录被测软件的质量情况。绝大多数情况下，测试团队将识别出一份软件内部缺陷的列表，这份列表上的缺陷都是可修复的，一旦我们修复了这些缺陷，并再一次测试这些缺陷以确保修复有效，再加上一般意义上的回归测试，我们就能提高软件的质量。
InfoQ：在你看来，使用“缺陷狩猎”技术最主要的优点是什么？
“缺陷狩猎”技术可以非常快捷的确保任意一件软件的质量。如果在一个精心准备的时长两小时、由 10 至 16 人执行的缺陷狩猎活动中，被测软件上没有发现任何缺陷或发现的缺陷非常少（当然，这要基于该软件的规模和复杂度），那么我的经验告诉我，起码在我这些年接触并测试过的软件当中，这款被测软件的质量也可能会是中等偏上的。
当你获得了另一家公司的软件产品，并且你的公司准备执行验收测试时，把“缺陷狩猎”作为一种高效的冒烟测试使用将取得非常好的效果。在验收测试之前执行的“缺陷狩猎”可以作为一个质量检查保障机制来执行，通过该机制，你就可以判断待验收的软件是否已经足够好，从而决定是否需要抽调人手去帮忙进行验收测试。
如果在“缺陷狩猎”中你发现了大量的缺陷和很多高优先级的缺陷，那么你就知道了验收测试必须推迟而且待验收软件的质量必须提高，在此之前你是不会抽调人手去进行验收测试的。
InfoQ：您引用了名言“没有银弹”，那么，您建议将何种技术和“缺陷狩猎”配合使用呢？您能否给出一些具体例子？
“缺陷狩猎”是建立在“探索性测试”基础上的，我认为“探索性测试”就是一个很好的测试方式 / 方法，但是如果你仅仅把你的测试建立在软件运行时可见的部分上时，它会有一个缺点。
这个缺点就是，由于你只进行了探索性测试，那么如果有一些需求没有被实现到被测软件中去的话，在测试中你将有可能无法识别出这些缺失的部分。出于这个原因，你需要让测试有一些层次结构，以保证需求和测试用例之间是可追溯的。
如果想追求测试对需求的覆盖率，那么这会是一个更好的做法。
【译注 1】TMMi：测试成熟度模型集成。详见：http://tmmi.org
【译注 2】中译版本由电子工业出版社出版，中译名《实用软件测试指南》，ISBN：7505381601
查看英文原文： Klaus Olsen Elaborates on Bug Hunting Top of Form
感谢杨赛对本文的审校。
给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。
评论