(翻译)编写优秀Bug报告的艺术 ----转载自CSDN（imlogic的专栏）
(翻译)编写优秀Bug报告的艺术----------http://blog.csdn.net/imlogic/
前言
在99年的Quality week上的一次演讲中，微软的一个测试经理，Roger Sherman指出了由于“不可重现”导致bug关闭的主要原因。这是一个非常可惜的情况，因为这样的bug report浪费了紧张的开发计划中的宝贵时间，增加了对产品质量完全是无关紧要的事情，同时导致了在开发人员和测试之间的挫败感和差的感觉。有时，bug report是由于短暂的或随机的事件，测试和开发之间不一致的工具和配置，或者在测试的环境下对正确的行为的模糊定义而产生的，但是许多的由于不可重现而被关闭的测试报告是因为描述不清晰，被误解，或者只是文字的错误。
幸运的是，我学习到一些能够引起管理层注意，更清楚的和开发人员沟通并得到修复的编写优秀bug report的诀窍。这些技巧不仅仅提供了是在被修复的问题的比例方面得到了可靠的回报，而且在同开发人员和管理层的通过中也得到了回报。在我管理的项目中使用这种方法编写bug report，8份bug report中大约只有一个没有被修复。
这篇文章的思想只有当你的报告针对的测试执行过程是专业的质量工作才可以发挥作用。聪明地执行完整的测试包是产生可靠的测试状况信息的基础的其中一个因素。在许多的测试文献中广泛地介绍了多种多样的关于如何构建这样的测试包的方法。选择和你质量风险管理需求相一致的技术并且使之适应你的具体情况，敏捷地监督已计划的测试的执行过程，这样你就可以拥有可靠的测试执行过程。
另外一个关键的因素－bug report，却没有得到太多的关注。这是非常令人遗憾的，因为优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。试想一下：如果你不能用开发人员能够理解的术语和能够用于调试的方法给开发人员解释一个错误，他怎么能够修复问题呢？如果你不能够在bug report中提出象“保险杆标签”（bumper sticker）一样的错误总结来引起管理层的注意，你又如何让他们关心你们发现的问题呢？
Bug report的核心是对错误的描述。表格1中是一个关于好和差的错误描述的例子。编写好的bug report是一种好的艺术形式。采用以下的10条技巧可以帮助你的小组提高编写bug report的质量：
组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。
重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。
隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。
消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。
检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。
以上10条技巧可以帮助你和你的小组提交准确简洁的，彻底校订的，精心构思的，高质量的技术文档。测试小组应该集中编写bug report的任务，测试组长和经理应该让测试组成员清楚地认识到编写优秀的bug report是一项首要的工作任务。衡量优秀的bug report的质量指标应该包括如下：
o 对管理层来说，是清晰明了的，特别是在概要这一级；
o 对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题的相关信息
o 可以很快的将bug从“Opened”状态转变成“Closed”状态，减少为得到更多的信息从开发人员打回的差的bug report并导致测试人员返工的时间。
改进bug报告的流程是需要花费一些时间的，但是也给予了效果显著的回报。首先，简单的流程改进了测试小组和高层、平行管理层之间的沟通，增强小组的信任度，名望和鼓励管理层给测试投资更多的资源。第二，平稳地递交报告给开发人员促进了测试和开发人员之间积极的关系。第三，更短的bug生命周期是更加有效的，在时间上之前花费在编写优秀bug report上的时间和后期由于返工差的bug report花费的时间相抵消。这些回报帮助开发流程通过有效的沟通和高效率的流程获得更好的产品质量。
[ Last edited by eatmouse on 2005-6-1 at 08:44 ] ８错８错:)
请问有没有使用lr性能测试的高手啊，请教几个问题啊？
1、使用lr做性能测试，怎么确定一个通过的标准，一般情况下的标准（就是在用户也不知道怎样合格的前提下）2、使用lr测试完毕后，生成的结果图表，怎样分析。
3、我觉的用lr测试软件的性能，不知道是在一台机器上配置好，还是多台，如果是多台机器的话，怎么样配置是合理的？（假如需要加载100个用户，到底是要加在两台机器上，还是三台机器上，这个应该怎样确定） 写的很好，谢谢指导
我是新手，想和大家交个朋友！
希望大家能够交我这个朋友！我的QQ：215143066，MSN:jickllyloveshe@hotmail.com欢迎加入我的群！26526836
呵呵
够详细、具体的了，根据这就能编写更好的 report了
这里还有一篇，参考下。
你有没有为了要更多的信息而被返回 bug report 的经历呢？有没有碰到过你发现的一个非常严重的错误被推迟到下一个版本才去修复的情况呢？你提交的每一个 bug report 都是和项目组就正在测试中的软件质量问题的一种书面沟通方式。通常，你用于沟通程序错误的能力－不是体现在错误本身的内在严重程度－而是体现在确定这个错误是否需要修复。
如果这是一个可怕的想法，你可能会想， “ 等等！我讨厌写作，我并不擅长写作。怎么样才能够通过编写 bug report 来决定错误的命运呢？ ” 它要吸引大家相信错误是为他们说话的－任何一个头脑正常的人都应该主动地查看一个特定的错误是足够可怕的以致要被修复。不幸的是，事实并不是这样。
但是好消息是：有效的和软件开发人员、项目组沟通的能力不是由你在高校英语课程中的表现所决定的。
这不是关于用有趣的词语编写流畅散文，也不是关于优秀语法和拼写的方法。它是有关仅用能够表达你观点的词语明白地表述错误的方法。太多地话将会使你的观点陷入茫然无措中。太少地话又会使他人用自己的假设去填补隔阂－通常是对软件有害的部分。如果你不是很确信是什么样的错误，那么不管你的 bug report 写得怎么好，也没有人知道那是什么样的错误。
这篇文章主要讨论你现在能够开始着手提高人们倾听你发现的错误的机会的 4 个方法。
• 了解你的听众
毋庸置疑，任何写作课都会告诉你必须了解你是为谁编写 bug report 。
每份 bug report 至少有两个听众：必须要修复错误的人和决定错误命运的人或团体。有时一个人会同时负责这两份工作，但是仍然是两个不同的听众，只是一起发生在同一个人身上罢了。
你的第一个听众－那个必须修复错误的人需要清楚，明确的步骤以重现错误。信息越多越好。针对这个目的，我们称这个人为 “ 开发人员 ” 。开发人员需要关于我们操作了什么和我们看见了什么的准确信息。
你的第二个听众－决定错误命运的人或团体需要知道如果不修复此错误的后果。这个听众需要精练的语句以抓住他们的注意力并且引发对错误的相关连问题的讨论。基于这个目的，我们称他为 “ 错误审核委员会 ” 。在使错误得以修复的过程中你的角色是帮助错误审核委员会了解不修复错误的风险远远超过修复错误可能发生的风险。
你越了解你的开发人员和错误审核委员会如何工作，你就越可以根据他们的需要裁减你的 bug report 。尽力在私底下设法了解你的听众。如果你能够出席错误审核委员会会议，尝试这样做。你将学习到许多关于你的听众是如何思考的知识。
• 选择一个好的标题
一般把用于描述错误的短句称为错误的标题或描述。这是 bug report 中最重要的部分。错误审核委员会成员经常通过它来决定错误是否可以推迟修复。如果标题没有力度，委员会成员可能认为它是不值得花费太多的时间。（毕竟，在接下来的 2 个小时里还有 145 个以上的错误要审核。）
以下是一些示例：
好的 ： 超时后在退出时崩溃了
太长的 ： 在数据库不可用后你又保存记录的更改 , 然后从文件菜单中选择退出时程序崩溃了
不足够的信息 ： 程序崩溃了
太模糊 ： 当数据库离线时出现问题
标题变成了一种给项目组提供检查和调查错误的方法。和数据相比，人们更容易记词语。人们更愿意记得 “ 在 windows2000 下不能够安装 ” 的错误，而不是类似 “ ＃ 23423” 错误，而且在以后人们还会利用这些关键词搜索错误。
编写一个好的，简明的错误标题是不容易的。和编写 bug report 的其他部分相比，应该多花些时间构造理想的错误标题。要确信标题是足够短以便能够在显示错误的屏幕上和由缺陷跟踪系统生成的报表中显示完全（不会折行）。标题不必是完美的语法，而应简短并一针见血。
• 书写清楚，明确的步骤
你提交给开发人员的步骤应该提供如何产生错误的信息，这样错误就能够被发现并且修复。它也需要给错误审核委员会提供错误发生的环境。
唯一正确 ：
1 ．运行客户端
2 ．找出一个记录
3 ．更改记录但不存盘
4 ．使数据库服务器脱机
5 ．尝试保存记录
6 ．收到一个超时的错误
7 ．退出客户端
结果：崩溃
马虎的（有很大空间让人产生误解的 ）：
使数据库服务器脱机，保存，然后退出，崩溃了。
太多冗余的信息（不能够指出什么是引发错误的最关键原因）
1 ．运行客户端
2 ．为输入新的条目查询数据库
3 ．打开一个浏览器
4 ．在 yahoo.com 上浏览新闻
5 ．关闭浏览器
6 ．选择一个条目
7 ．把种类从 “ 蔬菜 ” 更改到 “ 水果 ”
8 ．使数据库服务器脱机
9 ．尝试保存记录
10 ．收到一个超时的错误
11 ．退出客户端
结果：崩溃 sdlkfj2学习 顶顶
ok
ok xuexi sdlkfj2 sdlkfj2 sdlkfj2zan!!! 学习！~ 学习！~ sdlkfj2 不错，要好好学学怎么才能提交好的报告 很好，非常感谢楼主 看来以后也要注意了啊求助
深刻度1重要度4不会再现的bug和深刻度４重要度２经常再现的bug要修复各需要多长时间呢？？ 好书大家一起看呀，好贴大家顶
页:
[1]
2
