【怎样才能写出好的BUG报告？提示与技巧】

ilove51

How to write a good bug report? Tips and Tricks

Why good Bug report?
If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill.

"The point of writing problem report(bug report) is to get bugs fixed" - By Cem Kaner. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers morale and some time ego also. (I suggest do not keep any type of ego. Ego's like "I have reported bug correctly", "I can reproduce it", "Why he/she has rejected the bug?", "It's not my fault" etc etc...)

What are the qualities of a good software bug report?
Anyone can write a bug report. But not everyone can write a effective bug report. You should be able to distinguish between average bug report and a good bug report. How to distinguish a good or bad bug report? It's simple, apply following characteristics and techniques to report a bug.

1) Having clearly specified bug number:
Always assign a unique number to each bug report. This will help to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.

2) Reproducible:
If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.

3) Be Specific:
Do not write a essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.

How to Report a Bug?

Use following simple Bug report template:
This is a simple bug report format. It may vary on the bug report tool you are using. If you are writing bug report manually then some fields need to specifically mention like Bug number which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub modules of the product.

Platform: Mention the hardware platform where you found this bug. The various platforms like 'PC', 'MAC', 'HP', 'Sun' etc.

Operating system: Mention all operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.

Priority: When bug should be fixed? Priority is generally set from P1 to P5. P1 as "fix the bug with highest priority" and P5 as "Fix when time permits".

Severity: This describes the impact of the bug.

Types of Severity:
·  Blocker: No further testing work can be done.
·  Critical: Application crash, Loss of data.
·  Major: Major loss of function.
·  Minor: minor loss of function.
·  Trivial: Some UI enhancements.
·  Enhancement: Request for new feature or some enhancement in existing one.

Status: When you are logging the bug in any bug tracking system then by default the bug status is 'New'.
Later on bug goes through various stages like Fixed, Verified, Reopen, Won't Fix etc.

Assign To: If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.

URL: The page url on which bug occurred.

Summary: A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.

Description: A detailed description of bug. Use following fields for description field:
·   Reproduce steps: Clearly mention the steps to reproduce the bug.
·   Expected result: How application should behave on above mentioned steps.
·   Actual result: What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the "Report type" as one more field which will describe the bug type.

The report types are typically:
1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately:
If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report:
Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

3) Test the same bug occurrence on other similar module:
Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.

4) Write a good bug summary:
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button:
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

6) Do not use Abusive language:
It's nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.

Conclusion:
No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.


-----------------------------------------------------------------
翻译：kongkongtest
校对：月光疾风
日期：2009/10/15

版权归【天天翻译团】所有，如要转载，请注明出处。

-----------------------------------------------------------------



本文来自: 天天测试交流(http://www.365testing.com/bbs/) 详细文章参考：http://www.365testing.com/bbs/thread-13079-1-1.html

TEST_119

有道理，说的很对！

yuefang3344

恩恩



www.tiwens.com/c/553648128.htm

ilove51

一个里放不下，译文在此：
怎样才能写出好的BUG报告？提示与技巧

为什么要写好的缺陷报告呢？

如果你的缺陷报告是高效的，那么被修复的几率就高很多。所以说是否修复你提交的BUG，取决于你报告的质量。怎样写出好的报告，毫无疑问是需要技巧的。我现在将告诉你怎样学会这项技巧。

Cem Kaner说过：“写问题报告（缺陷报告）的目的就是为了让问题得到解决”。如果测试员不能正确的描述缺陷的话，开发人员很有可能会以问题无法重现为由而拒绝修复，这样的话，很容易打击测试员的士气，有时候甚至伤到测试员的自尊。（我建议在测试过程中，不要带有任何自我的想法，比如说“我已经很正确的描述这个缺陷了呀”，我可以重现这个问题呀”，“为什么他们拒绝修复这个问题呢？”，“这不是我的问题”等等，等等……）

一个好的软件缺陷报告应该具备哪些特点呢？
任何人都会写缺陷报告，但不是每个人都可以写出一份高效的缺陷报告。你要学会区分一份缺陷报告是一般的还是高质量的。如何区分报告的好坏呢？很简单，在描述一个缺陷时，运用到以下的特征和技巧就可以了。

1) 具有明确的缺陷编号
每一个缺陷报告都要赋予一个惟一编号，这样可以让你轻松的区分缺陷记录。如果你正在使用自动化的缺陷报告工具，那么在你每次提交缺陷的时候，系统会自动的产生一个惟一编号，记录下每个缺陷的编号和简述。

2) 具有可重现性
如果你提交的问题不能重现的话，那么它们永远也别想得到修复。你要清楚的描述重现过程中的每一个步骤，不要假设或忽略任何一步。一步接一步的描述问题，问题才可能较容易的重现，问题才能被修复。

3) 要具体明确
不要把问题描述的像篇散文一样，一定要明确并且重点突出。尽量用最简短的语句同时又是高效的方式来描述问题。就算有些问题表面上看来是类似的，也不要把它们都合并成一个问题，每个问题都要有自己的报告单。

如何描述一个问题呢？

参考下面这个简单的缺陷报告模板：
这是一个简单的缺陷报告模板，你可以根据你当前使用的缺陷报告工具来加以变化。如果你是手工记录缺陷报告的话，那么有些值就需要特别的指明，比如说这个需要手动分配的缺陷编号。

报告人：你的姓名和电邮地址

产品：发现问题的产品名称

版本：产品的版本（没有的话可以不填）

组件：产品的主要组成模块

平台：在哪个平台下发现的问题。平台有很多种，比如：PC, MAC, HP, Sun等等

操作系统：在什么操作系统下发现的问题。操作系统有Windows, Linux, Unix, SunOS, Mac OS. 如果可以的话，把操作系统的版本也写上，比如说Windows NT, Windows 2000, Windows XP等等。

优先级：问题应该在什么时候被修复？通常是将优先级设为从P1到P5，PI表示“该问题的优先级是最高的，必须马上修复”，而P5则表示“时间允许的话就修复，没时间的话就延迟修复或者不修复”。

严重性：描述这个问题的影响程度
严重性的类型有：
·  致命的：无法进行下一步测试工作
·  严重的：系统崩溃，数据丢失
·  主要的：主要功能无法实现
· 次要的：次要功能无法实现
·  轻微的：界面需要完善
·  系统增强/优化：新特征的需求或者一些已经存在的优化

状态：提交缺陷报告到任何缺陷跟踪管理系统的时候，缺陷状态的默认值为“新建”，之后会经过各种不同阶段，如“已修复”、“已确认”、“重新打开”、“不修复”等等。

指派给：如果你知道问题产生的模块是由哪个开发人员负责的话，你可以直接填上该开发同事的电邮地址。如果不知道的话，就不填，把这个问题交给该模块的负责人或者经理，他们会分派给相应的开发人员的，也可以把问题抄送给经理。

URL: 出现问题的页面链接

摘要：60个字或以下的简明摘要，要确保你的摘要能够反映出是在什么地方出现的什么问题。

描述：问题的详细描述，需要包括以下几方面：
·  重现步骤：清晰地描述重现问题的步骤
·  期望结果：基于上述步骤，系统应该出现什么样的结果
·  实际结果：基于上述步骤，系统实际出现了怎样的结果，也就是问题所在

这些就是缺陷报告的重要内容，你也可以在报告中再增加“报告类型”这一栏，用来描述缺陷的类型。

典型的报告类型有：
1) 编码错误
2) 设计错误
3) 新的建议
4) 文档问题
5) 硬件问题


写一份好的缺陷报告的一些额外提示：

1) 及时报告问题
一旦在测试中发现任何问题，马上写出错误报告。不要等着测试结束后再写详细的错误报告。这样做，才能保证你的报告是正确的，描述的问题可重现。你写报告的时间越晚，你遗忘其中步骤的可能性就越大，最糟糕的是你甚至可能遗忘这个问题。

2) 编写报告之前，重现问题三次
你提交的问题必须是可以重现的，要确保你描述的步骤能够正确的重现而不会产生歧义。如果你发现该问题不是每次都出现的话，也可以把问题出现的周期写到报告里面。

3) 在类似模块中，测试是否存在同样的问题
有时候，开发者会把同样的代码应用大到相类似的模块中。所以说，在相似的模块中，这类问题出现的概率会很高。甚至你可以尝试找到更多的问题。

4) 写好问题摘要
问题摘要可以帮助开发人员快速的分析出问题的本质，质量差的报告会增加一些不必要的开发和测试时间。要通过问题摘要令到两者的沟通更为有效。记住，在缺陷报告库里查询问题的时候，问题摘要是当作查询条件来使用的。

5) 提交之前，仔细检查
检查报告中的每一个句子、每一个词语、每一个步骤，看看是否有一些句子存在歧义而令人产生误解。要有一个清晰明了的缺陷报告，就应该避免出现一些含糊不清的句子或者词语。

6) 切勿使用污言秽语
没错，你找到问题说明你很努力工作，这个值得赞扬，但是不能以此为傲，讽刺或者批评开发人员，或者是进行人身攻击。

结束语：
毫无疑问，你的缺陷报告应当是一份高质量的文档了。花些时间在提高写报告上，是有很大价值的。因为这是测试人员，开发人员和你的管理人员主要的交流重点。管理者应该使整个团队意识到，写出好的，高质量的测试报告是每个测试人员工作的首要责任。如果你的报告写的好，有价值，那么你不仅仅节约公司的资源，同时也会让测试与开发建立良好的关系。