大家的 bug 率有多低？

[Breadykid]

按需求功能来算：

后端 拿一个简单功能的 curd 接口来说好了

前端 按一个页面模块来说好了

为什么提这种问题呢？ 因为我觉得在开发的时候看 word 版的 prd 对于细枝末节的地方真的很容易遗漏，特别是写成论文式样的 prd。还没人摘出来，有的需求在好几个地方要求一致，然后只在某一个功能上标注了，开发量一大好容易漏掉，然后测试 bug 率飙升。 而且，测试很多都是按看到的点来提的，比如一个接口的 bug，字段 A 值不对一个 bug，字段 B 为空一个 bug。。。结果一个接口好几个 bug。。。

bug 多的时候真的想哭

[Breadykid]

@infun 我们测试把 bug 数量算作自己的工作量。。。没开 bug 好像觉得自己没干活一样。。。坐边上的开发很鸡贼的在提测前 py 测试让他测一波，结果测完改完，提测后就不测了，还没提 bug。。。我觉得非常的不公平。。。

[Breadykid]

@Torpedo 我以前也写单元测试的，可惜现在所在的团队是业务导向，也没有开发老大。。。估时不仅不给单测时间，还要压榨开发时间。。。哭哭

[Breadykid]

@herozzm 是啊，大佬不但 bug 少，代码量更少

[Breadykid]

@vyronlee 被批了吗？

[vyronlee]

@Breadykid 没有，这可是丰功伟绩

[fademeter]

50% 这个概率应该很精准了，出 bug,不出 bug

[encro]

我们公司没有测试，2 刀 3 个程序员每个月几百万的营收也可以跑吧。
我认为：
1，测试就是将原本一个人的责任让两个人做，多一个人背锅，最后代码质量下降，没有单元测试，没有自动化测试；
2，写代码之前先画时序图，流程图，原型图，了解业务和数据流向；
3，写代码的时候先用注释实现伪代码（注释要求解析的是 why 而不是 how ），可以避免逻辑错误，提高写效率；
4，一键发布撤销
5，代码严格遵守 mvc,业务，界面逻辑，数据完全接偶；
6，与钱相关，基础核心一定要健壮，少而精，确保以后基本不要改的，做到最小化影响原则；
7，在清楚表达意思，不降低维护基础上，代码越短越好

[encro]

核心思想：
程序最终健壮度、可用性等，是一个程序员的品牌，维护好自己的品牌，身价自然高。

[wengjin456123]

少说几十个 bug 还没修，安心睡觉

[lei2j]

修改需求容易出现 bug

[brust]

BUG 是需求文档要求的,这锅不背

[miaotaizi]

需求没 BUG 了, 再来说 代码 bug 率

[cwjokaka]

效率跟质量只能选 1

[kinghly]

自测，像你说的文档看不够细、接口返回值不对与返回空，这本身就是你的问题，别推卸责任。做好这些你的 bug 率肯定大大降低。

[Torpedo]

@Breadykid 有啥条件做啥事。之前还有部门测试都没有的。
当然，后来我感觉它流程太不正规，转岗了

[Breadykid]

@encro 我下次一定要延长估时，按理想要求慢慢开发

[encro]

@Breadykid 争取时间是一定的，但是不一定能争取到，因为任何时候都不会有充裕的时间，自己下班后付出，平时多动手练习。

[kuyuzhiqi]

bug 多=公司兢兢业业的人才，代码混乱=公司不可或缺人才

[sherryqueen]

bug 率? 难道不是每天写 bug 改 bug 吗?

[TabGre]

@encro 对于前端单元测试有什么指导吗？