1.描述bug不清晰，就一句话，没有具体的操作步骤。
比如：拨打电话出现死机。（就简单的一句话，就啥都没了，拨打什么号码–没写，在什么情况下拨打电话–没写）
2.提交的bug看不懂啥意思，不知所云。
这种bug只有测试工程师自己能看懂，别人根本看不懂，他却以为别人能懂。
3.bug发生的前提条件都不写。
比如：bug描述是充电图标显示重叠。但是没有写什么条件下出现，开机状态？还是关机状态？开发工程师懵逼，还要自己去一个个去试，浪费开发人员的时间，描述不详细但是测试工程师还觉得自己没毛病，一切挺好。
4.没有写出现的概率。
偶发的bug没有log和其他更多信息，有的bug概率很小，小到不影响用户使用，如果不写清楚，开发人员将浪费大量时间去定位问题。
5.测试工程师描述bug，却不写预期结果。
开发都不知道要修改成什么样，一脸懵逼。结果开发理解错了，修改的结果不是预期的结果，这就浪费开发的时间了，你想想此刻开发人员的心情是怎样的？
6.bug等级乱定位
比如一个很小的甚至是建议性的问题，把bug等级提到高。
软件开发一看，全是致命性1级bug，仔细一看很多小问题也被提为1级bug，此时开发人员的心情肯定的奔溃的。
7.出现问题的软件版本没写清楚，开发人员不知道是在哪个软件版本出现的。
8.bug出现的模块没有划分清楚，所有的bug都提到一块，看的眼花缭乱。
推荐阅读：
sales@spasvo.com
