【IT168 技术文档】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-定位，尽量缩小这个问题的范围

　　定位发现的问题。在试图隔离一个问题的时候，需要考虑下面的几点：

　　尝试找到最短，最简单的步骤来重现这个问题。

　　查看是否是外部的什么特殊的原因引起的这个问题?例如，系统挂起或延时，会不会是因为网络的问题?

　　对于一个存在多种输入条件的项目，尝试不断的改变输入值，并查看结果，直到确定哪个值导致的错误。

　　在问题描述中，在尽可能的范围内，精确描述所使用的测试输入值。例如，如果在测试中发现打印一份脚本的时候会出错，首先判断是不是打印所有的这种类型的脚本都会出错。

　　归纳

　　Report Bug时，采用合理的步骤来确定这个问题是通常会发生还是偶然一次出现或者是在特殊条件才出现。

　　重现

　　如果测试时，可以重现Bug，那么，应该准确的解释重现Bug所必需的条件。列出所有的步骤，包括精确的组合，文件名以及碰到或者重现这个问题的操作顺序。如果确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也最好能够给出一个明确的示例用来帮助开发来重现。

　　如果测试时，不能重现Bug，那就提供尽可能多的有效的信息。在开发没有重现或者开发没有解决之前，不要清除相应的测试数据，或者至少要备份这些数据。

　　影响

　　发布产品时，需要判断未解决的影响问题。例如，在某一个窗口发现一个排版错误或者拼写错误，这类Bug对测试人员来说可能是微不足道的，但对于客户来说，这是接触产品的第一件事，所以必须在给客户实施前修改好。

　　调试

　　如果需要，在Report时，提供跟踪、截图、日志等对捕获这个Bug有帮助的信息。

　　证据

　　提供Report的是一个Bug的证据信息，这些信息可能包括操作指导，文档，必备条件等等，还有可能是客户以前反馈过来的零碎的信息，或者是竞争对手的软件中的一些标准，又或者来源于以往版本中的结果。