How to Write a Fully Effective Bug Report
英文原文：To write a fully effective report you must:- Explain how to reproduce the problem - Analyze the error so you can describe it in a minimum number of steps.
- Write a report that is complete and easy to understand.
Write bug reports immediately; the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.
Writing a one-line report summary (Bug's report title) is an art. You must master it. Summaries help everyone quickly review outstanding problems and find individual reports. The summary line is the most frequently and carefully read part of the report. When a summary makes a problem sound less severe than it is, managers are more likely to defer it. Alternatively, if your summaries make problems sound more severe than they are, you will gain a reputation for alarmism. Don't use the same summary for two different reports, even if they are similar. The summary line should describe only the problem, not the replication steps. Don't run the summary into the description (Steps to reproduce) as they will usually be printed independently of each other in reports.
Ideally you should be able to write this clearly enough for a developer to reproduce and fix the problem, and another QA engineer to verify the fix without them having to go back to you, the author, for more information. It is much better to over communicate in this field than say too little. Of course it is ideal if the problem is reproducible and you can write down those steps. But if you can't reproduce a bug, and try and try and still can't reproduce it, admit it and write the report anyway. A good programmer can often track down an irreproducible problem from a careful description. For a good discussion on analyzing problems and making them reproducible, see Chapter 5 of Testing Computer Software by Cem Kaner.
The most controversial thing in a bug report is often the bug Impacts: Low, Medium, High, and Urgent. Report should show the priority which you, the bug submitter, believes to be appropriate and does not get changed.
谷歌翻译：
为了写一个完全有效的报告，您必须：
- 说明如何重现问题 - 分析错误，所以你可以在最少的步骤描述。
- 写一份报告，是完整的和易于理解的。
立即写错误报告，你不再等待发现问题和报告之间的，就越有可能是描述将是不完整的，不可再生的，或者干脆被遗忘的问题。
写一个报告摘要（Bug的报告标题）是一门艺术。你必须掌握它。摘要可以帮助大家尽快检讨突出问题，并发现个别报告。汇总行是最常见的，并仔细阅读该报告的一部分。当一个总结，使有问题的声音比它是那么严重，经理人更倾向于推迟。另外，如果您的摘要问题的声音比他们更严重的，你会获得一个危言耸听的声誉。不要使用两种不同的报告相同的摘要，即使它们是相似的的。汇总行应说明问题，而不是复制的步骤。不要碰上的说明（步骤来重现）的总结，因为它们通常会被打印在报告中相互独立的。
理想的情况下，你应该能写为开发人员重现和解决的问题，另一个QA工程师，以验证他们回去给你，以获取更多信息的作者，修复，这显然不够。这是要好得多超过在这一领域的沟通，而不是说太少。当然，这是理想的，如果问题是重复的，你可以写下这些步骤。但是，如果不能重现的bug，和尝试，并尝试仍然无法重现它，承认它，反正写的报告。一个好的程序员往往能追查仔细的描述复制的问题。对于一个良好的讨论分析问题，使它们重现，请参阅第5章计算机软件测试杰姆坎儿。
在错误报告中最有争议的东西往往是错误的影响：低，中，高，和紧急。报告显示，错误提交，你认为是适当的，并不会改变优先改变。 校对后的文章（能力有限，如有错误，大家见谅！）
为了写一份完全有效的测试报告，你必须做到以下几点：
--说明如何重现问题
--分析错误，用尽量少的步骤描述问题
--书写一份完整并且易于理解的报告。
（发现问题后）马上写错误报告，从发现错误到报告错误之间的时间越长，越有可能对问题的描述不完整，或者问题不能重现，或者干脆将问题忘了。
写一个报告摘要（bug的报告标题）是一门艺术，也是必须掌握的。摘要可以帮助每个人快速的回顾总结重要问题并找到个人的报告。汇总行是报告中经常被阅读的，也是被仔细阅读的一部分。当一个汇总描述的问题听起来并不那么严重，部门经理更倾向于推迟修改该问题。另外，如果你的汇总描述的问题比问题本身要严重，你会获得一个危言耸听的名声。即使两份报告很相似，也不要使用相同的摘要。汇总行只描述问题本身，不描述操作步骤。不要将汇总描述成操作步骤，因为这两者在报告中是互相独立的。
理想的情况下，你应该能讲问题描述清楚，这样开发人员可以独立重现和解决问题，QA可以独立验证修改是否正确，而不需要再回来问你-发现问题的人。在这个领域中如果不用沟通（就能解决问题）就更好了。当然，如果问题可以重现并且你可以写出详细 的测试步骤，这一点（不用沟通就可以解决问题）是可以实现的，但是如果你不能重现问题，或者试验了很多次仍然不能重现问题，也要承认问题所在并书写缺陷报告。一个好的程序员经常能从详细的问题描述中发现不可重现的问题。关于如何分析问题，使问题重现，参考Cem Kaner的计算接软件测试的第5章。
在缺陷报告中最有争议的东西往往是缺陷产生的影响：低、中、高、紧急。测试报告中必须显示你认为适当的缺陷优先级，并且这个优先级不能改变。 鼓励鼓励！ the translate its very correctly, thanks for 事实和胜利 回复 4# 骄阳似火
谢谢~~~ Great, thanks. Thank U！！！ 文章很好，请问文章的出处在哪里？ 文章很好，请问文章的出处在哪里？ 文章很好，请问文章的出处在哪里？
页:
[1]
