2024年5月25日发(作者：)

bug分析报告模板

报告bug的目的是为了开发人员或者其他人员了解程序的错误。

您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。

如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如

果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信

息。以下是整理的bug分析报告模板模板，欢迎阅读。

在99年的Qualityweek上的一次演讲中，微软的一个测试经理，

RogerSherman指出了由于“不可重现”导致bug关闭的主要原因。

这是一个非常可惜的情况，因为这样的bugreport浪费了紧张的开发

计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时

导致了在开发人员和测试之间的挫败感和差的感觉。有时，bugreport

是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，

或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的

由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者

只是文字的错误。

幸运的是，我学习到一些能够引起管理层注意，更清楚的和开

发人员沟通并得到修复的编写优秀bugreport的诀窍。这些技巧不仅

仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同

开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这

种方法编写bugreport，8份bugreport中大约只有一个没有被修复。

这篇文章的思想只有当你的报告针对的测试执行过程是专业的

质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测

试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍

了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险

管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计

划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。

另外一个关键的因素－bugreport，却没有得到太多的关注。这

是非常令人遗憾的，因为优秀的bugreport对反映测试小组真实的和

可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果

你不能用开发人员能够理解的术语和能够用于调试的方法给开发人

员解释一个错误，他怎么能够修复问题呢？如果你不能够在

bugreport中提出象“保险杆标签”（bumpersticker）一样的错误

总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？

Bugreport的核心是对错误的描述。表格1中是一个关于好和

差的错误描述的例子。编写好的bugreport是一种好的艺术形式。采

用以下的10条技巧可以帮助你的小组提高编写bugreport的质量：

组织Structure：测试人员应该采用深思熟虑的，小心谨慎的

方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系

统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知

道最早出现问题的地方。

重现Reproduce：测试人员在编写bugreport之前必须在检查

问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须

说明问题的偶然性。一个好的处理原则就是在编写bugreport之前反

复尝试3次。

隔离Isolate：在尝试编写bugreport之前，必须试着隔离错

误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变

错误的症状。这些信息可以为开发人员着手调试提供思路。

归纳Generalize：在测试人员发现了一个已隔离的，可重现的

问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或

其他的地方？同一个故障是否有更加严重的问题？

对比Compare：如果测试人员以前曾经验证过现在出错的测试

用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过

以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注

意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅

仅只是检查一个测试用例在以前的多个结果。

总结Summarize：在bugreport的第一行写上错误的总结是非

常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。

这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟

通清晰，还要能够帮助设置错误修复的优先级别。

精简Condense：在bugreport的初稿完成后，测试人员应该反

复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说

明和那些由于对没有任何关系的细节或者那些在重现错误过程中不

需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bugreport的目

标。

消除歧义Disambiguate：测试人员在精简空话的同时或其之后

随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽

量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表

述事实，清楚的，不会产生争执的词语。

中立Neutralize：如文中所述，作为坏消息的传递人，和善地

提交消息是一个挑战。如同所有的错误总结一样，独立的bugreport

在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙

谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质

量”这个大的目标上转移开了。谨慎的测试人员只用Bugreport来描

述事实。

检查Review：一旦测试人员感觉bugreport是他能够编写的最

好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也

应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至

可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可

能提交最好的bugreport。

以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校

订的，精心构思的，高质量的技术文档。测试小组应该集中编写

bugreport的任务，测试组长和经理应该让测试组成员清楚地认识到

编写优秀的bugreport是一项首要的工作任务。衡量优秀的

bugreport的质量指标应该包括如下：

o对管理层来说，是清晰明了的，特别是在概要这一级；

o可以很快的将bug从“Opened”状态转变成“Closed”状态，

减少为得到更多的信息从开发人员打回的差的bugreport并导致测

试人员返工的时间。

改进bug报告的流程是需要花费一些时间的，但是也给予了效

果显著的回报。首先，简单的流程改进了测试小组和高层、平行管理

层之间的沟通，增强小组的信任度，名望和鼓励管理层给测试投资更

多的资源。第二，平稳地递交报告给开发人员促进了测试和开发人员

之间积极的关系。第三，更短的bug生命周期是更加有效的，在时间

上之前花费在编写优秀bugreport上的时间和后期由于返工差的

bugreport花费的时间相抵消。这些回报帮助开发流程通过有效的沟

通和高效率的流程获得更好的产品质量。