大家的 bug 率有多低？

[Breadykid]

按需求功能来算：

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

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

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

bug 多的时候真的想哭

业务型团队的大迭代开发真的伤不起。。。
我要在 2 周内写 40+个接口，还附带一个技术难点。。。测试用例还是一下子发出来，光看用例就能花 4 小时- -，不要说跟着用例调一遍接口了- -

[jmc891205]

bug 率是什么
分子是 bug 数量
分母是什么？代码行数？

[LongMaoz]

脑子正常的时候基本不会写 BUG
但是有时候脑子抽了想不开了写出来的代码全是 BUG

[nihaoaa]

不存在的，我的代码没有 bug，肯定是测试不会测，还没搞懂需求就瞎 bb

[wizzer]

每天都在写 bug 中

[orzorzorzorz]

并不会有。要是测试组测出来的 bug 多于某个数字是要扣绩效的，所以我都是 py 好测试，有 bug 别急着白纸黑字，先跟我说，我先熬着改着。你看无 bug 多简单。

[leonard916]

基本不存在什麽 bug
只要需求明確也基本不會有設計問題

[way2create]

bug 一般不是写出来的，是改出来的

[Sapp]

只要不是改需求，我一般差不多一天一个 bug，不分大小，加班和赶工就不一定了，bug 急速增长。比较蛋疼的是经常有几个月前的小 bug 被发现，找了半天改完又改出了新 bug。

[GlobalNPC]

@orzorzorzorz 要是再来一条 ，测试开的 bug 少于多少扣绩效 咋办？

[Torpedo]

一般提测前，自己把功能过一遍明显减少。有时间加单元测试。
流程上来说，测试必不可少

[Breadykid]

@jmc891205 分母是功能数量

[Breadykid]

@LongMaoz 看来大佬从不写 bug 呐

[Breadykid]

@nihaoaa 噗噗噗

[Breadykid]

@wizzer 以前老大说，写代码就是在写 bug [非嘲讽，诚恳脸

[vyronlee]

巅峰时期最多挂着 200 多个 bug

[Breadykid]

@orzorzorzorz 看来我没和测试搞好关系，人家是公事公办，态度强硬

[Breadykid]

@leonard916 就是需求有很多无所谓的地方。。。然后测试用例变成了某个指定。。。

[Breadykid]

@way2create 真理！

[Breadykid]

@Sapp 哭哭

[herozzm]

其实我一直想说 bug 多是水平差 别说需求 xxx

[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 还没修，安心睡觉

[JLX]

修改需求容易出现 bug

[brust]

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

[miaotaizi]

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

[cwjokaka]

效率跟质量只能选 1

[kinghly]

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

[Torpedo]

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

[Breadykid]

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

[encro]

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

[kuyuzhiqi]

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

[sherryqueen]

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

[TabGre]

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

[mixure]

1. TDD：测试提 bug 告诉开发，根据 prd, 你这功能没做
2. 管理：我不管你用什么方法， xx 号必须上线
3. m 开发，n 个测试：m>>n, 老板可以对外说，这不是测试工作效率高的体现吗？ 其实是公司能省就省，根本不拿测试当回事儿；

反正就这样，把质量当回事的人，不多；反正这是常态，爱咋咋地。

[glaucus]

系统没下线，就永远有可能有还没发现的 BUG，所以我的 BUG 率没法算，发现一个修一个

[tabris17]

bug 率怎么计算？分母是啥？代码行数么

[encro]

@TabGre 一起探讨，前端 selemium,appium 之类，对于经常变动的、一次性开发的、非关键性业务，我也只能强调前端人员的品牌意识了。

[opengps]

基本每个接口都是 bug

[wujl100]

不存在的，公司要统计 bug 率来扣绩效嘛？ 我司都已经开始一群人抽签来决定扣谁的了。。随缘。

[LokiSharp]

我连写单元测试都能写出 Bug

[arnoldxiao]

肯定是测试的方法不对

[liuy1994g]

我是前端，八个工作日写了一个模块，接近五十个接口，大概也有五十个 bug 吧，主要都出在时间太紧，细节部分出现 bug。
bug 率不知道，反正每次我的 bug 是最多的，

[8355]

我司测试出的用例只能他们自己用. 我是不能按照用例来自测接口的...... 不然真到线上出 bug 会被喷死.

[linZ]

按功能？ 500%吧，一个功能可以提 5 个 bug

[andy2415]

逗比测试,自己不会用说我有 bug?

[songtianyi]

我曾经对自己重构的项目做过统计， 计算公式：由 bug 导致的 issue 数 / issue 总数 = 15.7 %

[quceng]

我们公司是按照 BUG 数量 /开发人日计算 BUG 率的，按照平均标准是 3 个 /日 ，高级岗位人员一般是 1-2 个 /日。

[Breadykid]

@mixure yoooooo