关于如何正确的去描述bug，可能是很多测试人员都比较关心的热点问题。
可能有人会说：“作为测试人员我会不知道提交bug吗？难道还要你来教我？”
恰恰是因为软件测试人员的这种傲慢，直接导致与开发人员的沟通不顺畅，甚至发生冲突。常常会碰到开发人员抱怨测试提交的bug看不懂，测试人员抱怨开发固执难沟通的事情。
图源网络：侵删客观看待这个问题，小编刚开始做测试的时候也不太理解开发人员的抱怨和责怪。经历了很多事情后，逐渐明白工作的不易，也学会了去设身处地的思考问题，明白了每个岗位每个人都有他的难处。要知道开发人员每天面对密密麻麻的代码本来就很费神，这时候面对测试人员提交的很多bug，他们的内心是非常排斥和抗拒的。
站在软件开发人员的角度，小编总结了几点软件测试工程师在和开发人员沟通时最容易发生的一些问题。作为参考，大家可以对照一下，看自己有没有遇到过。
图源网络：侵删1.描述bug不明确，没有具体的信息。
比如：拨打电话出现死机。描述过于简单，没说明拨打什么号码，在什么情况下拨打的电话。
2.提交的bug定位不清晰，开发看不懂出现了什么问题。
这种bug只有测试人员自己能看懂，别人根本看不懂，他却以为别人能懂。
3.没有写明bug出现的概率。
图源网络：侵删偶发的bug没有日志和其他信息，开发无法判断。有的bug概率比较小，小到基本不影响用户使用，如果不写清楚，开发人员将浪费大量时间去定位问题。
4.没有写明bug发生的前提条件。
比如：bug描述是充电图标显示重叠。但是没有写明出现在什么情况下，开机状态？还是关机状态？开发人员不知道，还需要自己去一个个的试，很浪费开发人员的时间
5.bug级别定位不准确
比如一个很小的甚至是建议性的问题，把bug等级定的很高。
开发一看，全是致命性1级bug，仔细一看很多小问题也被提为1级bug，此时开发人员的心情肯定非常奔溃。
图源网络：侵删6.测试人员光描述bug，却不写预期结果。
开发不知道要修改成什么样，如果开发理解错误，那么修改的结果很可能就不会是预期的结果，最后又得再次修改。很浪费开发人员的时间，降低工作效率。
7.未写清楚出现bug的软件版本，开发人员不知道bug是在哪个软件版本出现的。
8.bug出现的模块没有划分清楚，所有bug写在一起，看起来非常混乱。
图源网络：侵删关于bug的正确提交方式，小编整理了九条小建议，希望能帮到大家。
1.bug标题要简洁明了，重心明确，不要啰嗦一堆。
2.要写明问题出现的前提条件。在什么情况下出现,必须要写清楚。
3.操作过程要按步骤写清楚，比如步骤1，步骤2，步骤3等。
4.要写实际效果和预期效果，让开发清楚修改bug要到达的预期效果。
5.要标明bug出现的概率，比如操作10次出现1次。
6.提供必要的截图和日志，比较复杂的操作步骤最好提供视频。
7.bug等级要分好类，致命性bug、严重bug、一般性bug、建设性意见，必须严格按照标准划分。
8.出现bug的软件版本号，要写清楚。
9.bug出现的模块要写清楚，比如app设置模块出现了bug，就把bug归类为设置模块的bug，这样分类让人一目了然。
图源网络：侵删对测试人员来说，学会使用正确的提交bug的方式对自己的工作是有很大的益处的。不仅能够更顺畅的与开发人员进行沟通交流，提升自己的工作效率，还能增强自己的工作能力，办事也会更具有条理性，在职业发展方面也能得到比较大的进步。
而在掌握正确描述bug的方法的同时，也要注意与开发的沟通方式。多换位思考，尊重对方一般就能得到对方的尊重与配合。其次是加强和开发工程师的沟通，让对方清楚地认识到你的工作对他的价值，和你发现的每一个bug的重要性。那么，测试人员与开发之间的协作就会顺畅很多。
转载请注明：http://www.0431gb208.com/sjslczl/1501.html
