1、性。一个bug说明一个问题，如果有能力的话，一个bug说明一类问题，这一类问题一定要能判断出是一条代码错误引起。

　　2、可重现。提供这个bug的精确步骤，使开发人员容易看懂。

　　3、一致性。bug描述及所有信息要前后一致，不可有歧义。

　　4、完整性。好能抓图，一目了然；测试环境和特定条件一定要描述清楚，许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。

　　5、简洁性。通过使用关键词，可以使软件缺陷的标题描述短小简练，又能准确解释产生缺陷的现象。

　　6、跟踪性。也许随着版本的变化，或者测试的深入，对bug有了新的认识或者新的判断，及时补充相关信息，能够提供给开发更有用的信息。

　　7、客观性。软件缺陷描述不要带有个人观点，不要对开发人员进行评价，软件缺陷报告是针对产品的。

　　其实在平时测试中，经常会遇到不能重现的bug，这些问题有不能提交bug，如果放过往往上线后出现的概率很大，问题也一般比较不可接受。所以我觉得对于重现不可重现的bug是做好测试很重要的能力。

　　1、保留信息。遇到问题，好抓图，搜集错误日志，保留测试现场环境，一旦发现此问题不可重现，这些数据和信息将很重要。

　　2、提高意识。很多人在遇到这类问题时，往往觉得后来操作不可重现了，因此忽视了。这样往往会把此类bug遗留到产品发布后。欠的帐总要还得。

　　3、自我分析。对于自己分析这类问题，其实对自己的提高是大的。分析思路：环境问题和操作顺序。

　　4、寻求帮助。如果研发可以帮忙，并且研发是负责任的话，只有信息全，研发分析往往是快的途径。如果研发忙或者不乐意做，也是不可厚非的。但要寻求组内能力强的人员或者组内讨论分析，集中大家的力量往往可以事半功倍。

　　在我的经历中，通过上面的方法，几乎能把所有的不可重现的问题变成可重现的并且提交bug。