|
英文原文: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章计算机软件测试杰姆坎儿。
在错误报告中最有争议的东西往往是错误的影响:低,中,高,和紧急。报告显示,错误提交,你认为是适当的,并不会改变优先改变。 |
评分
-
查看全部评分
|