前端bug每次都比后端多，我总结了5点原因

最近总有朋友跟我吐槽说，每次一汇报，就说前端bug多，前端能力有问题，几乎每次都是前端bug比后端多，还好几次导致项目延期。

我其实听的挺不是滋味的，前端bug比后端多，可能是这么几点原因吧

目录

1、 需求不明确

2、测试用例环节不到位

3、测试觉得这就是一个bug

4、code 500了，我不管，反正你前端没显示

5、UI随便在ps上一拖动，前端就是工作量

6、目前很多团队的问题：

1、 需求不明确

前端造成自身bug的原因，可能是最初的需求不明确。评审的时候说好的这块有疑问，我们后续常沟通，大家答应的好好的，结果到了后边沟通少了，模棱两可了，很快时间不够用了，就提测了。测着测着，成了bug了。

也有可能是需求的连锁反应，上一环节没搞通顺，结果改着改着，上一步改完了，下一步遗漏了。而且前端目前有个很大的问题是，前端很多地方只管显示，其实数据来源，数据整合，某一步的数据走向都不是特别清楚，我就该提交了提交，该显示了显示，至于数据存到哪里去了，我根本不知道。

也有可能就是前端同学自己的疏忽，大意，写完了没有自测到位，就提交上去了。再加上代码review的时候很多人其实只能看个大概，眼睛特别毒辣的还是少数，就匆匆评审完了，最后造成了bug。

2、测试用例环节不到位

也有可能是测试同学写测试用例的时候有遗漏，虽然你看着那个xmind子项一个套N个，也许在测试同学还没有拿到真正项目的时候，也会有疏漏，这就导致了测试同学看到真正跑起来的项目了，发现某个地方漏掉了，怎么办呢？先提个bug吧，虽然我这里有遗漏，但你们也真的是出问题了啊，你敢狡辩？出了问题你难道不应该改吗？

也有可能是根本就没有测试用例评审这一环节，导致测试同学和前端同学对同一个需求理解不一致，前端开发完了，走了流程就是这样子的，结果测试一走，立马就能走出一个不一样的复现步骤来。

也有可能就是前端同学没仔细看测试用例，冒烟测试那些东西自己也没把握好，导致人家刚一开始测，就走不下去了，直接禅道上给你提个p1的bug，你有脾气吗？

3、测试觉得这就是一个bug

也有可能开发人员觉得这个模块就应该是这个样子的，但测试同学秉承着我得对产品负责的原则，不行，这个地方我就是觉得不行，谁来了也不好使，你不改是吧，不改我就给你激活，激活了我最后就汇报，张三有bug不改。

有时候前端开发会先保证功能，样式可以先完成一定比例，后者先不自我要求那么高，再保证样式，这就造成了，比如按钮这里小了写，边框那里多了一条。测试同学觉得，不行，这叫啥呀，你们做完了也不看看。提个bug吧。

4、code 500了，我不管，反正你前端没显示

有时候前端不显示了，提个bug吧；有时候按钮点了一直转圈，提个bug吧；有时候本该有3页数据，只显示了2页，提个bug吧；有时候这里先出了，那里后出了，不行，这怎么能行呢，提个bug吧；有时候两条数据显示的一样了，重复了，前端有bug了；有时候明明显示total23，分了3页，把一页10条改成20，本该分2页的，结果还是3页，不行，前端太不仔细了，又有bug了；有时候查详情，id传的1和2显示的不对，前端弄坏了；有时候登录上了，前端还是总提示“请登录”，哎，公司这个前端不行啊，祭天吧。

5、UI随便在ps上一拖动，前端就是工作量

有时候我做PPT的时候，总会有一种快感，让我有一种UI设计的感觉。我想让哪个小方块在哪里，我左拖一拖，右挪一挪，我想让哪里的边框改一改，点个按钮，我想让哪些方块罗列起来，鼠标点住不撒手，往上一放就完成了。

很多时候，UI走查环节了，妹子们说这里改一改就得改一改，不行，你不改不能上线，影响美观；人家说这里的位置改一改，你就在那里吭哧吭哧布局半天；你这个背景毛玻璃效果不行啊，我要的是那种模糊效果，不是这样子的。

哎，不对啊，尺寸变了坏了，浏览器变了坏了。咋回事啊，你还上线不啦？

△ 有的bug，查来查去，可能是后端的，但最初把bug指给了前端，很可能汇报着汇报着，这个bug的第一印象人就成了前端；

△ 前端改着改着，发现后端排查完了，UI改完了，发现某个地方的功能点又坏了，前端又背锅了；

△ 一次又一次，复盘的时候大家一个比一个说的好听，实战起来前端又导致项目延期了，下个月的CY名额给他们小组来俩吧，技术太次了。

偷笑：我有一次做一个node项目，没有负责前端，我发现后端有时候数据相关的逻辑，安全，兜底其实还真挺耐人寻味的，但当你开发完了。你就看吧，前端调了改了功能问题，改UI问题，改兼容性问题，我就把数据给了你，我就看着你在那里活蹦乱跳的。而我，就是一个不粘锅。

6、目前很多团队的问题：

目前很多团队他们特别想衡量开发人员的效率，工作能力，怎么衡量呢，统计一个人的bug数量，统计测试人员提的bug数量，统计某个开发人员提测后被激活的bug数量。

这就导致了团队内有种上纲上线的感觉，测试不留情面，开发人员拿到bug首先想到的不是我们赶紧排查一下是谁的问题，哪里的问题，先是特别生气，这个测试咋这样，我们一个团队总共那么几个人，你这是要把我们往火坑里送啊。

然后领导也是每次都让测试汇报进度，还特别细致，哪个开发人员上榜了，怎么怎么样。其实现在好多公司这么做。反正我是觉得这样不太好。

问题肯定是要统计的，但测试这个职位终归不是为了提bug，而是协同开发人员一起把产品做的更加完美。