编写优秀Bug报告的艺术.doc

编写优秀 Bug 报告的艺术 在 Qualityweek 上的一次演讲中，微软的一个测试经理， RogerSherman 指出了由于“不可重现”导致 bug 关闭的主要原因。这是一个非常可惜的情况，因为这样的 bugreport 浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。有时，bugreport 是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者只 是文字的错误。 幸运的是，我学习到一些能够引起管理层注意，更清楚的和开发人员沟通并得到修复的编写优秀 bugreport 的诀窍。这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这种方法编写 bugreport， 8 份 bugreport 中大约只有一个没有被修复。 这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍 了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。 另外一个关键的因素－ bugreport，却没有得到太多的关注。这是非常令人遗憾的，因为优秀的 bugreport 对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在 bugreport 中提出象“保险 杆标签”（ bumpersticker）一样的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？ Bugreport 的核心是对错误的描述。表格 1 中是一个关于好和差的错误描述的例子。编写好的 bugreport 是一种好的艺术形式。采用以下的 10 条技巧可以帮助你的小组提高编写 bugreport 的质量： 组织 Structure：测试人员应该采用深思熟虑的，小