BUG管理给开发人员带来了方便，但，如果你描述的不合理，或者无法让开发人员重现BUG，那么，你其实是在给开发人员带来困惑。。。
一般情况下，我们使用bugzilla来记录BUG，有时候也用 mantis，毕竟这两个都算是开源软件了。bugzilla被使用的更多，因为有很多IDE，都有插件支持，但对于开发人员来说，更重要的是BUG产生的情况，所以淘宝的QA TEAM 这样谈BUG描述时，我觉得有必要记录一下，以后也可以让同事看看，HOHO，可以报BUG更精确一点：
清楚准确的描述BUG，这是测试人员的必备的基础。但是针对各种问题，我们又如何使自己提交的BUG让开发人员看一遍就明白呢？我相信大部分人都会碰到以 下这种情况，我们提交上去的BUG在某些特定的环境下存在，这时候如果没有写清楚具体产生BUG的前提条件的话，BUG难以重现，这个时候开发就会说： “为什么我测试的时候没有出现这个问题呀，人品问题。：）”。还有就是开发经常说：“为什么在我的机器上没有出现这个问题呀？”。“这个BUG是什么意 思”等等问题，出现以上一些问题还是追究其根源：
1． 测试与开发理解需求有偏差
2． BUG的出现是有概率性的
3． BUG受环境影响
4． BUG在一定条件下存在
5． BUG受数据影响，数据量达到一定量时才存在。
6． 测试人员提交的BUG，描述不清楚，让开发人员不明白其意
为了尽量避免以上问题的出现，我们测试就要尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象等。下面讲一讲BUG的描述规则：
1．摘要主要用于指明Bug发生的地点、在什么条件下发生什么现象。
2．描述字段：
1）描述Bug发生的地点、所用账号类型、操作步骤、期望值、实际值， 如果Bug与浏览器相关，需尽量描述更多的环境参数，如操作系统等。
2) 一个Bug不会包含多个问题，会尽量单一化，便于跟踪处理及统计
3) 对于很难描述清楚的Bug需截屏作为附件上传，并在描述中写明参照附件。
4）尽量减少重现的步骤以达到用最少的步骤来重现问题；
5）不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。
6）不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。
7）在BUG提交前，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤。
8）测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
9）如有必要可以把产生结果的SQL语句放上去，不过需要开发人员在短时间内定位问题，否则测试人员不能保证数据的完整性。
10）如果是概率性的BUG，尽量重现BUG，找到BUG产生的条件，如果找不出BUG产生的原因必须写明BUG发生的概率大约是多少。
11）BUG如果在特定条件下产生的，必须写明BUG产生的条件和操作步聚。
对了，本文来源：http://rdc.taobao.com/blog/qa/?p=5168，作者是pingyan