软件工程师如何描述bug？软件测试工程师有哪些毛病？

某年某月某日某日，负责的网站出现崩溃的状态。于是不懂技术的我问了我们公司的软件工程师小哥，他说：“网络问题导致的崩溃状态”，由于过了10分钟还没好（已经被领导劈头盖脸的骂了一顿），我就弱弱的问，是不是有bug，能不能解决一下呢？他说有bug，会自己解决的，不用你教我哈！于是，过了1个小时，网站才恢复正常！我也不敢问，我也不敢说啊！

但今天，我不是来吐槽的，是我看到一篇文章《软件测试工程师怎么正确描述bug？》，觉得很有意思，想给大家分享一下，并且会附上我的观点哈！如有侵权，请及时联系我进行删除！

有些工程师心想：“作为测试工程师我怎么不知道提交bug吗？难道还要你来教我吗？好low的问题。”正因为软件测试工程师的这种傲慢，这种傲慢直接导致和开发人员冲突，经常碰到开发人员抱怨测试提交的bug看不懂，结果导致问题越来越严重。
1.现在我们站在软件开发人员以及运营者的角度，看软件测试工程师有哪些毛病？
①描述bug不清晰，就一句话，没有具体的操作步骤。
比如：拨打电话出现死机。（就简单的一句话，就啥都没了，拨打什么号码–没写，在什么情况下拨打电话–没写）
②提交的bug看不懂啥意思，不知所云。
这种bug只有测试工程师自己能看懂，别人根本看不懂，他却以为别人能懂。
③没有写出现的概率。
偶发的bug没有log和其他更多信息，有的bug概率很小，小到不影响用户使用，如果不写清楚，开发人员将浪费大量时间去定位问题。
④bug发生的前提条件都不写。
比如：bug描述是充电图标显示重叠。但是没有写什么条件下出现，开机状态？还是关机状态？开发工程师懵逼，还要自己去一个个去试，浪费开发人员的时间，描述不详细但是测试工程师还觉得自己没毛病，一切挺好。
⑤.bug等级乱定位
比如一个很小的甚至是建议性的问题，把bug等级提到最高。软件开发一看，全是致命性1级bug，仔细一看很多小问题也被提为1级bug，此时开发人员的心情肯定的奔溃的。
⑥测试工程师描述bug，却不写预期结果。

开发都不知道要修改成什么样，一脸懵逼。结果开发理解错了，修改的结果不是预期的结果，这就浪费开发的时间了，你想想此刻开发人员的心情是怎样的？
⑦出现问题的软件版本没写清楚，开发人员不知道是在哪个软件版本出现的。
8.bug出现的模块没有划分清楚，所有的bug都提到一块，看的眼花缭乱。
2.正确的提交bug才是我们和开发人员友好的沟通的最好方式。
①.bug标题要简洁明了，不要啰嗦一堆。
②要写出现问题的前提条件。

什么情况才会出现,必须要写清楚。
③操作步骤要分步骤一步步写清楚，不要怕麻烦。比如步骤1，步骤2，步骤3。
④要写实际结果和预期结果，让开发清楚要修改bug到达的预期效果。
⑤要写出现的概率，比如操作10次出现1次。
⑥提供必要的截图和log，甚至复杂的操作步骤要提供视频。
⑦bug等级要分类好，致命性bug、严重bug、一般性bug、建设性意见，必须严格按照标准划分。
⑧出现bug的软件版本号，要写清楚。
⑨bug出现的模块要写清楚。

比如app–设置模块出现了bug，就把bug归类为设置模块的bug，这样分类让人一目了然。

3.bug的分类严格遵守，如下：
①致命（1级bug）
通常表现为:系统无法运行，崩溃。
应用模块无法启动或异常退出，主要功能模块无法使用。
比如：1.内存泄漏；2.系统容易崩溃；3.系统无法登陆；4.循坏报错，无法正常退出。
②严重（2级bug）
通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误；4.乱码；

4.程序里有有危害国家安全或带有政治色彩的字样。
③一般（3级bug）
通常表现为：界面、性能缺陷。
比如：1.边界条件下错误；2.极限条件下容易无响应；4.大数据操作时，没有提供进度条；出现错别字，但是不影响功能
④建设性意见（4级bug）
通常表现为：易用性及建议性问题
比如：1.界面颜色搭配不好；2.文字排列不整齐；3界面格式不规范。

以上，就是小编看到这篇文章时的感受哈，希望大家理解软件工程师工作，每个岗位每个人都有他的难处，多理解他人的处境，要知道软件开发整天面对密密麻麻的代码很费脑，再碰到测试提交的很多bug，他们的内心是排斥、抗拒的。