如何给高效地给开发提bug

这一篇我们讲一下如何高效地给开发提bug，
很多人会觉的，提bug挺简单的啊，这应该没什么可以讲的。
提bug确实挺简单的，但是如何高效而且准确的提bug，这就不是很简单就能掌握的。

我们来看一下比较标准的bug是怎么样的（个人认为），这里举一个例子：

标题：
【Android】【火爆tab】【无限视频】在无限视频第一页点击进入视频详情页，上滑切换视频只能浏览已加载出来的视频。
（最好是多级标题，其他人可以一眼就了解是哪里出现的问题）

内容：
操作步骤：
1.后台配置无限视频，且视频数量较多
2.进入火爆tab，加载出第一页视频后点击视频封面，进入视频详情页后上滑切换视频
3.视频切换几个后上滑不能继续浏览更多视频

预期结果：在无限视频流点击任意视频进入视频详情页，上滑可切换浏览所有视频，至最后一个。

还有一些诸如发生bug的版本，手机系统，网络类型等等。

这样提bug确实清楚明了，开发同学也几乎不用找你进行再次确认，但是又一个问题出现了，就是太费时间了，在我刚做测试的前一两年，就是这么做的。提bug和处理bug的时间占到了测试时间的1/3-1/2，这样的测试效率是比较低的。你有没有这种经历，就是在测试的时候，把很多时间都花在了提bug上，不知不觉时间就过去了。

接下来说一下我们如何的更高效一点给开发提bug。
首选，也是很重要的一点。需要看你们公司或者部门是否会把bug的数量作为工作量，业绩的考核标准等，或者说对这个看的比较重要。如果是的，那么只能把你测试时候发现的bug都提到缺陷管理工具上去（jira，婵道等），因为这样方便统计。我这里有个小建议，就是针对一些简单的bug，你只写标题就可以了，就是那种开发看了标题就知道问题在那里的那种。不过这里有个前提，就是你和开发的关系比较熟了。他可以接受这样。如果是其他部门或者其他公司的开发，这样提bug给人的印象不太好。
如果bug的数量跟工作量，绩效啥的没关系，那么咱们其实不必把所有bug都提上去，可以为我们省出不少时间。我个人感觉如果一个公司把bug的数量作为考核工作量或者绩效的标准，这个公司不会做的太大，bug的数量跟测试的个人能力其实并没有太大的关系。下面重点说一下什么类型的bug可以提，什么类型可以不用提。先从bug的分类来说，一般前端或者服务器可以不提，就是那种开发修复后可以立即验证的那种，在工作群或者私聊一下开发，修复好了你就验证了。然后就是开发，如果开发是你们本部门的人平常沟通十分频繁，都十分了解了，那么一般你就可以不提，如果是其他部门或者其他公司的人，那么最好你把bug提上去，万一以后流程或者责任说不清楚，这样可以作为依据。一般自己部门内不太会出现这种情况。最后就是bug的修复程度和偶现程度，修复程度难和偶现程度低的建议提上去，因为这些bug一般都不是即时能修复的，如果不提的话会比较容易遗忘。

我们如何和开发沟通bug会受到公司，项目，上级等诸多因素影响。以上仅仅是我个人和开发沟通bug的一些经验总结，供你参考，希望对你有帮助。