编写Bug，Report Bug注意事项
1.Bug的Description的描述
Report Bug时，描述有效的Description的关键点：
Condense－精简，清晰而简短；
Accurate－准确，确定是Bug；
Neutralize－用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言；
Precise－精确；
Isolate－定位，尽量缩小这个问题的范围；
Generalize－还有没有其他的某些地方存在这样的问题；
Re-Create－如何引发和重现这个Bug？（环境，步骤，前提条件）
Impact－影响，这个缺陷对客户的影响以及对测试的影响；
DeBug－怎么做才可以让开发更容易来修改这个Bug？（跟踪，截图，日志，直接访问等等）
Evidence－证据。
Condense－精简，清晰而简短
首先，去掉不必要的词；
其次，不要添加无关的信息。
包含相应的信息是最重要的，但是确保这些信息都是有用的。对于那些没有描述清楚如何重现或者难以理解的问题，都应该提供更多的信息。但也要避免写过多的不必要的信息。
| Example |
Description |
| 不恰当的描述：TMI（Too Much Information） |
当我正在专心测试的时候，报内存错误，这时我发现一个我不熟悉的GUI，我试了好多边界值以及错误的条件，但是运行正常。最后我请空了数据，并且点击了前进按钮，这时系统异常中止了，多次的反复尝试证明，在任何情况下，只要“产品描述”这个字段没有数据，点击前进或者退出甚至取消，系统都会中止。 |
| 恰当的描述： |
在产品信息页面，如果产品的描述字段为空，前进，退出和取消的功能会使系统意外中止。 |
Accurate－准确，确定是Bug
确信是一个Bug，避免因为其他原因，导致错误的Report Bug，需要考虑：
l 是否会因为安装的某个原因导致这个问题？例如，是否安装了正确的版本而且各种先决条件也已经满足？是否登陆，安全设定，命令或者操作的顺序有错误？
l 是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致？
l 是否是网络或者环境的问题？
l 是否理解了期望的结果？
l 中性的语言
l 客观的描述Bug，不要使用幽默的或者其他带有感情色彩的语句。在提交Bug之前，仔细阅读Bug的描述，删除或者修改可能让人产生歧义的句子。
| Example |
Description |
| 不恰当的描述： |
输入任何的非法数据都会中止。 |
| 恰当的描述： |
功能ABC在任何非法的数据都会中止，例如：-1,-36,-32767 |
Precise－精确
当Bug的描述很长时，例如：“我按了回车键，然后现象A出现，接着按了后退键，现象B出现，接着输入命令‘XYZ’，现象C出现”，看到这样的说明，很难明白到底想说明什么问题，三个现象中哪一个是错误的。清晰准确并且客观的描述Bug，而不是简单说明发生了什么。
| Example |
Bug描述 |
| 不恰当的描述： 这个描述很难让人知道到底是什么问题。是打印端口延时还是打印机没有准备好或者是打印机的显示面板的信息不正确。 |
问题发生在取消打印时打印端口延时，打印机的就绪灯始终不亮，此时打印机显示面板上显示“PRINTING IPDS FROM TRAY1” |
| 恰当的描述： 在描述之前，用简短的语言概述时如何发生的这个问题。 |
当打印机正在打印时，取消打印会让打印机挂起。 问题发生在取消打印时打印端口延时，打印机的就绪灯始终不亮，此时打印机显示面板上显示“PRINTING IPDS FROM TRAY1” |
Isolate－定位，尽量缩小这个问题的范围
定位发现的问题。在试图隔离一个问题的时候，需要考虑下面的几点：
l 尝试找到最短，最简单的步骤来重现这个问题。
l 查看是否是外部的什么特殊的原因引起的这个问题？例如，系统挂起或延时，会不会是因为网络的问题？
l 对于一个存在多种输入条件的项目，尝试不断的改变输入值，并查看结果，直到确定哪个值导致的错误。
l 在问题描述中，在尽可能的范围内，精确描述所使用的测试输入值。例如，如果在测试中发现打印一份脚本的时候会出错，首先判断是不是打印所有的这种类型的脚本都会出错。
归纳
Report Bug时，采用合理的步骤来确定这个问题是通常会发生还是偶然一次出现或者是在特殊条件才出现。
| Example |
Description |
| 不恰当的描述： |
当用非法字符做为文件名时，系统会出现“文件找不到”的错误提示信息。 |
| 恰当的描述： |
当用非法字符做为文件名时，系统会出现“文件找不到”的错误提示信息。每一次插入字符时都存在这个问题，但是不插入字符就没有问题。 |
重现
如果测试时，可以重现Bug，那么，应该准确的解释重现Bug所必需的条件。列出所有的步骤，包括精确的组合，文件名以及碰到或者重现这个问题的操作顺序。如果确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也最好能够给出一个明确的示例用来帮助开发来重现。
如果测试时，不能重现Bug，那就提供尽可能多的有效的信息。在开发没有重现或者开发没有解决之前，不要清除相应的测试数据，或者至少要备份这些数据。
影响
发布产品时，需要判断未解决的影响问题。例如，在某一个窗口发现一个排版错误或者拼写错误，这类Bug对测试人员来说可能是微不足道的，但对于客户来说，这是接触产品的第一件事，所以必须在给客户实施前修改好。
调试
如果需要，在Report时，提供跟踪、截图、日志等对捕获这个Bug有帮助的信息。
证据
提供Report的是一个Bug的证据信息，这些信息可能包括操作指导，文档，必备条件等等，还有可能是客户以前反馈过来的零碎的信息，或者是竞争对手的软件中的一些标准，又或者来源于以往版本中的结果。
2.Bug的标题
Bug的标题在很多情况下是一个有力的和项目组成员之间的沟通工具，在很多情形下，PM，Team Leader等只是查看Bug的标题。
l 简单，明确的说明问题（不能只是说出现问题）
l 建议（如果长度允许的话）：
l 使用有意义的单词；
l 描述环境和影响；
l 回答5W1H的问题（why，when，who，where，what，how）；
l 使用简写，例如挂起，异常中止，拼写错误等
l 相对于描述清楚而言，语法不是很重要
l 例如：下面的标题就没有提供足够多的信息。
例一：Summary：在保存和恢复数据成员时出错。
例二：Summary:一个比较好的标题可能是这样：在WINNT环境下，XYZ的保存和恢复数据失败，数据丢失。
3. 其它注意事项
使用Bugzilla，报Bug时，需要注意以下事项：
第一，应先确认Bugzilla上已经建立了相应当前的版本；
第二，在报Bug时，需要选择，Show Advanced Fields，这样才会罗列出详细的信息，如要CC的人，QA Contact等等；
第三，Attachment，保存和发送的图片格式一般为JPG格式，OS操作系统也要选择好。
Bugzilla上，有7个严重程度等级。
具体定义如下，This field describes the impact of a Bug.
| blocker |
Blocks development and/or Testing work |
| critical |
crashes, loss of data, severe memory leak |
| major |
major loss of function |
| normal |
regular issue, some loss of functionality under specific circumstances |
| minor |
minor loss of function, or other problem where easy workaround is present |
| trivial |
cosmetic problem like misspelled words or misaligned text |
| enhancement |
Request for enhancement |
第四,在报告Bug时，除了在描述中说明Bug的复现步骤外，还要在Description中，添加该Bug的测试发生率。测试发生率为按照特定步骤执行多次的Bug重现率。测试发生率=ug重现次数/按照特定步骤执行的总次数。其中：对于概率性问题，执行的总次数应根据Bug的复杂程度执行(20-50次)。这样对于再现Bug，定位问题等都有帮助。