1.Bug的Description的描述
Report Bug时，描述有效的Description的关键点：
Condense－精简，清晰而简短；
Accurate－准确，确定是Bug；
Neutralize－用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言；
Precise－精确；
Isolate－定位，尽量缩小这个问题的范围；
Generalize－还有没有其他的某些地方存在这样的问题；
Re-Create－如何引发和重现这个Bug？（环境，步骤，前提条件）
Impact－影响，这个缺陷对客户的影响以及对测试的影响；
DeBug－怎么做才可以让开发更容易来修改这个Bug？（跟踪，截图，日志，直接访问等等）
Evidence－证据。
Condense－精简，清晰而简短
首先，去掉不必要的词；
其次，不要添加无关的信息。
包含相应的信息是最重要的，但是确保这些信息都是有用的。对于那些没有描述清楚如何重现或者难以理解的问题，都应该提供更多的信息。但也要避免写过多的不必要的信息。
Accurate－准确，确定是Bug
确信是一个Bug，避免因为其他原因，导致错误的Report Bug，需要考虑：
- 是否会因为安装的某个原因导致这个问题？例如，是否安装了正确的版本而且各种先决条件也已经满足？是否登陆，安全设定，命令或者操作的顺序有错误？
- 是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致？
- 是否是网络或者环境的问题？
- 是否理解了期望的结果？
- 中性的语言
- 客观的描述Bug，不要使用幽默的或者其他带有感情色彩的语句。在提交Bug之前，仔细阅读Bug的描述，删除或者修改可能让人产生歧义的句子。
Precise－精确
当Bug的描述很长时，例如：“我按了回车键，然后现象A出现，接着按了后退键，现象B出现，接着输入命令‘XYZ’，现象C出现”，看到这样的说明，很难明白到底想说明什么问题，三个现象中哪一个是错误的。清晰准确并且客观的描述Bug，而不是简单说明发生了什么。
Isolate－定位，尽量缩小这个问题的范围
定位发现的问题。在试图隔离一个问题的时候，需要考虑下面的几点：
- 尝试找到最短，最简单的步骤来重现这个问题。
- 查看是否是外部的什么特殊的原因引起的这个问题？例如，系统挂起或延时，会不会是因为网络的问题？
- 对于一个存在多种输入条件的项目，尝试不断的改变输入值，并查看结果，直到确定哪个值导致的错误。
- 在问题描述中，在尽可能的范围内，精确描述所使用的测试输入值。例如，如果在测试中发现打印一份脚本的时候会出错，首先判断是不是打印所有的这种类型的脚本都会出错。
