最近在测试时代翻看一些老帖子，发现一些很有意思的东西，收集整理后，把它放到了这里，那天回头看会有另一翻感受。^_^

 

Ayi 问： 请问怎么写 bug 才能不被开发人员讨厌？

 

davy_chen 答：

1、   描述精确，完整；

2、   简洁，无歧义；

3、   可稳定复现；

4、   利用截图，调试信息等辅助说明；

5、   反馈验证结果及时，变化内容描述详尽。不被开发人员讨厌最主要的是建立威信，也就是你说出的都是真实的，你说有 bug 就确实存在。

6、   若对于很难重现的 Bug 还需要注明该 Bug 在测试过程中出现的几率。

 

sww1980 答：

1 、不被讨厌不一定用写 bug 的方式，跟开发人员搞好关系也很重要。
2 、只要有 bug, 开发人员肯定会烦，这时候你的亲和力就尤为重要，让开发人员觉得你不是在挑他的毛病，  

而是想一起开心的把软件做好。

 

小颖 答：

1、   如果能够指出 bug 的原因或出处一方面可以让开发人员感觉你的水平比较高，另一方面减少了开发人员找错的时间，他会心服口服。

2、   在有不要抓住一些规范性的错误不放，应该发现一些有深度的错误，功能实现是重要的

 

celine 答：

我觉得沟通很重要，尝试站在开发人员的角度上描述问题，而且要对事不对人。

 

gigobin 答：

1、   开发人员喜欢的 bug ，是能够一幕了然知道出现了什么样的问题，然后是一个简洁的复显问题的步骤。 一般我都习惯于先写一个简单的问题的 brief ，一句话，比如：在 xxx 输入某字符后，点击 save 报 500 错误。 然后下面是你的测试端的配置。然后是你的测试平台的情况。这些都是参考。 然后就是第一步怎么做，第二步怎么做，。。。，然后出现了什么错误。 最好是一个 bug 里面只有一个问题。这样便于大家跟踪状态。

2、   对于交流问题，我觉得如果有一个好的 bug 平台，在一个清楚的 bug 时，很少需要开发人员和测试人员交流。尤其是什么是不是一个问题时，如果开发人员认定不是，不需要太多的纠缠。除非你认为这个将非常有损客户的利益。而且这个时候应该报知测试 leader 去和开发 leader 进行协调。 而且尽量不要去写我认为这个问题是什么引起的，应该怎么改。你只需要保证开发人员能够复显就可以了。过多的涉及这个问题，会牵扯双方的精力。你的任务是发现问题，报告问题，追踪问题而不是解决问题。

3、   测试人员不是在找开发人员的错，也不是开发人员的矛盾体。测试人员是帮助开发人员节省精力去找出错误，修改错误的。一个好的开发人员是不会因为测试人员找出他很多错误而烦恼的，因为不断改进错误的同时，是对他的一个提高。 一个好的产品团队是协作良好的开发团队，测试团队以及管理组和设计核心组组成的。