发现BUG，提交BUG，不论使用什么BUG管理工具，一条BUG信息中都必须包含对BUG的描述和BUG的重现方法，同样不能缺少的是BUG信息的主题。

　　对于上述三个信息元素的重要性和叙述方法，我们一一论述。

　　首先讲BUG信息的主题，主题是对大量信息的简洁概括，那么概括出主题的意义在哪里呢？意义在于快速查找。开发人员需要通过主题迅速定位一条BUG所属的功能模块，甚至可以通过主题判断出BUG的严重程度，面对一堆的BUG，开发人员不会逐个打开去看，他一定会通过主题来决定哪个BUG先解决，哪个BUG后解决，万事都得分出个轻重缓急嘛，此外，毕竟解决BUG的难易程度和BUG本身的严重程度之间是没有绝对关系的。BUG信息主题对开发人员有着这样的意义，那么对测试人员来说也是一样，等开发人员将BUG解决后，测试人员需要再次验证，同样也要分出个轻重缓急，同样不能逐个将BUG信息打开查看，而是要根据主题来决定优先验证哪一个。如果没有主题信息，那么这些意义都不存在，对双方来说，都会或多或少带来一些麻烦。而如果有这些信息，且主题信息简洁明了，那么开发人员自然喜欢，这倒不是为了讨好，实在是测试人员自己也需要，再者，好的语言概括能力是需要严谨思维的支撑，不要给人留下这样一个印象，这家伙语言概括的能力太差了。

　　接下来，我们讲BUG的重现方法。对于开发人员，他需要根据重现方法来判断你的测试步骤是否正确，也需要根据重现方法来自己重现BUG，所以如果你的重现过程写的有问题，不清晰甚至混乱，开发人员就会很头疼，甚至会怀疑你的操作步骤是有问题的，甚至怀疑你的工作能力，怎么连操作步骤都写不清楚呢？对于测试人员来说，可以根据BUG重现方法去验证修复后的软件，不然，你还得去找测试用例。我认为好的重现方法的描述应该是这样的，用数字标明重现的步骤，一个步骤占用一行，这里举例说明一下：

　　1、第一步

　　2、第二步

　　3、第三步

　　最后，我们谈一谈BUG的描述。关于BUG的描述，是非常非常重要的，对于开发人员来说，他没有发现这个BUG，在他自己重现BUG之前，这是他唯一的获取BUG信息的渠道，同时也是测试人员和开发人员之间的一次交流，因为对BUG描述中，必然包含了测试人员对这个问题的理解，即原本软件该如何处理。对于BUG的描述就好比一个犯罪现场，开发人员将从这些信息中大致判断出软件的错误出在哪里。基于以上的分析，这个BUG描述首先要包含对出问题时的场景的描述，这是双方进一步交流的基础，即BUG是在什么条件下发生的，其次，测试人员必须讲清楚如果没有这个BUG，软件正常该如何处理或反映，测试与开发只有在这个问题上达成共识才能开展其他的工作，最后，测试人员必须讲清楚，软件实际中的处理行为。如此，开发人员在阅读完BUG描述后清楚的知晓了一个BUG的最为重要的三个信息。

　　任何工作都是能力的体现，如果一个工作需要相互协作来完成，一个参与者通常会对过程中自己认为能力不足的人不自觉的产生否定心态，毫不避讳的讲，做测试时我曾对一个开发人员产生过这种心态，当然，也会有人对我产生这种心态，只要大家不拿出来进行人身攻击，这些都可以归入到正常的个人内心活动。我要表达的是，事无巨细，要想证明自己，就把活干的漂亮点，你既然都已经发现BUG了，为什么不把它说清楚？