互联网产品竞争激烈，在生存的巨大压力之下，策划和运营人员们恨不得每一个需求都能秒级上线，这就给研发团队带来了巨大的压力。

有时候，产品的老大很关注某一个功能点，希望能尽快上线，可是，他发现这个功能的开发只要10天，测试居然要7天，秋水都望穿了还没有上线，于是，老大们就忍不了了，一声怒吼：“要提高测试效率！”

这确实是存在于现有研发流程的一个问题，但当我们深入地去分析这个问题的时候，发现测试人员表现出一脸委屈。

A

说好的星期一提测的，可是星期一那个版本还有很多bug，根本就没法测，开发修改关键bug，最后拖到星期二才开始测试”

B

“进度定得特别紧张，开发非常忙，功能一开发完成就丢给测试了，但是还有很多bug，版本来回了好几次才逐渐收敛”；

小C

“为了赶项目进度，我们会在开发没完成的时候就帮忙找bug，所以测试时间看起来就会非常长”。

在这些情形中，我们发现开发人员和测试人员都是三观很正的好同事，一个为了需求能尽快赶出来制定了非常紧张的时间表，一个为了能尽快发现bug提早进行测试。

那究竟是哪里出错了呢？

还有没有优化的空间的呢？

Bug的时间分析

看到这里，你可能会说：“别卖关子了，有啥宝赶紧献出来吧！”

还是请你稍安勿躁，为了表明这个帖子是一个技术贴，我们需要一些技术性的推理和演绎。

再来仔细地分析现有的流程：

开发一完成功能就把版本扔给测试人员，但bug太多，导致测试人员花时间报了很多bug，然后开发花很多时间修改bug；第二次的版本，可能质量还是很差；这样多次的版本往复。

我们来分析一下bug的代价：

测试人员打版本、发现bug、报bug、跟开发沟通、验证bug，这其中都是有时间成本的。假设测试人员为每一个bug花费12分钟。

假设有一个项目

开发人员5个

测试人员1个；

开发了14天（10个工作日），

发现了100个bug

如果开发能加强自测的话

假设每个开发人员能花2个小时进行自测，靠自己的自测消灭了50个bug，只剩下50个之后

我们来算一笔账

Bug减少测试人员节省的时间＝（100-50）＊12分钟＝600分钟 ~＝1天。

那相当于，整个项目就延长了2个小时开发自测的时间，但是测试时间就缩短了1天，效率的提升是杠杠的。

当然，实际情况中数据可能会更好，两个因素：

实际的情况中，测试人员为每个bug花费12分钟是假设的，实际的情况可能比12分钟还长，也就是说，效率可能提升得更多。

这里我们也没计算沟通和修改bug给开发带来的时间花费，100个bug要跟测试沟通、要把代码调入脑内存、再修复还是需要很多时间的，如果能在代码在脑内存的时候消灭掉50个bug，那节省的时间说不定已经够抵掉2个小时的自测时间了。

试点的情况

另外，作为一篇严谨的技术贴，这里有一个假设是不得不说明的：开发人员靠2小时的自测真的能消灭50个bug？？

根据我们的实践经验，真的是可以的哟~

那开发和测试人员的主观感受如何呢？

测试人员说：“Bug减少了以后，流程走顺了，以前需要打5个版本，现在只需要打3个就刷刷搞定了。”

开发人员说：“Bug减少了以后，流程走顺了，开发过程不那么乱了，自信心也提升了。”从项目反馈来看，开发还是挺愿意看到这种改变的。

所以，这真的是可以尝试的一个方向哦~

现有的经验和后续方向

根据我们的初步经验，有如下方式可以减少bug：

加强测试用例的Review，跟策划、运营、开发一起，把测试用例的思路好好地Review一下。在这个过程中可以发现很多策划模糊和缺失的地方，提早修复这些问题减少bug。

就是刚才讲的开发自测，测试人员写完用例以后，选择更多的用例让开发自测，有必要的话，事先教开发怎么自测。让开发、测试乃至整个项目组都树立起开发自测的意识，让这个环节能真正生效。

代码review是能大幅度减少bug的，不过要看项目的具体情况而定，有一些项目文化比较适合，有些项目需要慢慢来培养这种文化。

这是一篇可以让开发和测试人员和谐相处，共同进步的文章，希望测试童鞋多多转载给身边的开发童鞋看看哟

---

资源分享【这份资料必须领取~】

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】