大家的 bug 率有多低？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1939 天前的主题，其中的信息可能已经有所发展或是发生改变。

按需求功能来算：

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

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

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

bug 多的时候真的想哭

第 1 条附言 · 2019-07-16 22:17:33 +08:00

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

bug

prd

接口

CURD

55 条回复 • 2019-07-31 16:20:58 +08:00

jmc891205

2019-07-16 17:39:34 +08:00

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

LongMaoz

2019-07-16 17:39:49 +08:00

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

nihaoaa

2019-07-16 17:41:22 +08:00

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

wizzer

2019-07-16 17:42:15 +08:00

每天都在写 bug 中

orzorzorzorz

2019-07-16 17:43:21 +08:00

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

leonard916

2019-07-16 17:44:22 +08:00

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

way2create

2019-07-16 19:11:38 +08:00

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

Sapp

2019-07-16 19:19:22 +08:00

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

infun

2019-07-16 19:19:56 +08:00 via iPhone

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

Torpedo

2019-07-16 21:38:51 +08:00

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

Breadykid

2019-07-16 22:06:11 +08:00

@jmc891205 分母是功能数量

Breadykid

2019-07-16 22:06:43 +08:00

@LongMaoz 看来大佬从不写 bug 呐

Breadykid

2019-07-16 22:07:10 +08:00

@nihaoaa 噗噗噗

Breadykid

2019-07-16 22:07:44 +08:00

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

vyronlee

2019-07-16 22:08:11 +08:00 via iPhone

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

Breadykid

2019-07-16 22:08:41 +08:00

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

Breadykid

2019-07-16 22:09:23 +08:00

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

Breadykid

2019-07-16 22:09:37 +08:00

@way2create 真理！

Breadykid

2019-07-16 22:10:02 +08:00

@Sapp 哭哭

herozzm

2019-07-16 22:10:42 +08:00

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

Breadykid

2019-07-16 22:13:54 +08:00

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

Breadykid

2019-07-16 22:15:20 +08:00

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

Breadykid

2019-07-16 22:20:46 +08:00

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

Breadykid

2019-07-16 22:21:19 +08:00

@vyronlee 被批了吗？

vyronlee

2019-07-16 22:23:16 +08:00 via iPhone

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

fademeter

2019-07-16 22:48:15 +08:00 via Android

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

encro

2019-07-16 22:59:14 +08:00

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

encro

2019-07-16 23:01:07 +08:00

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

wengjin456123

2019-07-16 23:02:48 +08:00 via Android

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

lei2j

2019-07-17 08:32:04 +08:00 via Android

修改需求容易出现 bug

brust

2019-07-17 09:04:32 +08:00

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

miaotaizi

2019-07-17 09:26:24 +08:00

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

cwjokaka

2019-07-17 09:31:00 +08:00

效率跟质量只能选 1

kinghly

2019-07-17 09:52:40 +08:00

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

Torpedo

2019-07-17 10:05:58 +08:00

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

Breadykid

2019-07-17 10:58:18 +08:00

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

encro

2019-07-17 11:07:39 +08:00

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

kuyuzhiqi

2019-07-17 11:17:19 +08:00

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

sherryqueen

2019-07-17 11:23:18 +08:00

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

TabGre

2019-07-17 13:02:45 +08:00 via iPhone

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

mixure

2019-07-17 13:17:21 +08:00

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

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