软件测试工程师怎么正确描述bug？
有些工程师心想：“作为测试工程师我怎么不知道提交bug吗？难道还要你来教我吗？好low的问题。”
正因为软件测试工程师的这种傲慢，这种傲慢直接导致和开发人员冲突，经常碰到开发人员抱怨测试提交的bug看不懂。
我先声明下，我今天不是替软件开发工程师说话，我只是站在一个客观的角度看待问题。我刚开始做测试的时候也是不理解软件开发的抱怨和责怪，随时时间的推移才明白做人真的不易，每个岗位每个人都有他的难处，多理解他人的处境，要知道软件开发整天面对密密麻麻的代码很费脑，再碰到测试提交的很多bug，他们的内心是排斥、抗拒的。
现在我们站在软件开发人员的角度，看软件测试工程师有哪些毛病？
1.描述bug不清晰，就一句话，没有具体的操作步骤。
比如：拨打电话出现死机。（就简单的一句话，就啥都没了，拨打什么号码–没写，在什么情况下拨打电话–没写）
2.提交的bug看不懂啥意思，不知所云。
这种bug只有测试工程师自己能看懂，别人根本看不懂，他却以为别人能懂。
3.没有写出现的概率。
偶发的bug没有log和其他更多信息，有的bug概率很小，小到不影响用户使用，如果不写清楚，开发人员将浪费大量时间去定位问题。
4.bug发生的前提条件都不写。
比如：bug描述是充电图标显示重叠。但是没有写什么条件下出现，开机状态？还是关机状态？开发工程师懵逼，还要自己去一个个去试，浪费开发人员的时间，描述不详细但是测试工程师还觉得自己没毛病，一切挺好。
5.bug等级乱定位
比如一个很小的甚至是建议性的问题，把bug等级提到最高。
软件开发一看，全是致命性1级bug，仔细一看很多小问题也被提为1级bug，此时开发人员的心情肯定的奔溃的。
6.测试工程师描述bug，却不写预期结果。
开发都不知道要修改成什么样，一脸懵逼。结果开发理解错了，修改的结果不是预期的结果，这就浪费开发的时间了，你想想此刻开发人员的心情是怎样的？
7.出现问题的软件版本没写清楚，开发人员不知道是在哪个软件版本出现的。
8.bug出现的模块没有划分清楚，所有的bug都提到一块，看的眼花缭乱。
正确的提交bug才是我们和开发人员友好的沟通的最好方式。
1.bug标题要简洁明了，不要啰嗦一堆。
2.要写出现问题的前提条件。什么情况才会出现,必须要写清楚。
3.操作步骤要分步骤一步步写清楚，不要怕麻烦。比如步骤1，步骤2，步骤3。
4.要写实际结果和预期结果，让开发清楚要修改bug到达的预期效果。
5.要写出现的概率，比如操作10次出现1次。
6.提供必要的截图和log，甚至复杂的操作步骤要提供视频。
7.bug等级要分类好，致命性bug、严重bug、一般性bug、建设性意见，必须严格按照标准划分。
8.出现bug的软件版本号，要写清楚。
9.bug出现的模块要写清楚，比如app–设置模块出现了bug，就把bug归类为设置模块的bug，这样分类让人一目了然。
以下是完整的bug：
前提条件： 操作步骤： 1. 2. 3. 实际结果： 预期结果： 概率： 版本号： log、截图、视频等 |
bug的分类严格遵守，如下：
致命（1级bug）
通常表现为:系统无法运行，崩溃。
应用模块无法启动或异常退出，主要功能模块无法使用。
比如：
1)内存泄漏；
2)系统容易崩溃；
3)系统无法登陆；
4)循坏报错，无法正常退出。
严重（2级bug）
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：
1)功能未实现；
2)功能存在报错；
3)数值轻微的计算错误；
4)乱码；
5)程序里有有危害国家安全或带有政治色彩的字样。
一般（3级bug）
通常表现为：界面、性能缺陷。
比如：
1)边界条件下错误；
2)极限条件下容易无响应；
3)大数据操作时，没有提供进度条；
4)出现错别字，但是不影响功能。
建设性意见（4级bug）
通常表现为：易用性及建议性问题
比如：
1)界面颜色搭配不好；
2)文字排列不整齐；
3)界面格式不规范。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
