请不要在回答技术问题时复制粘贴 AI 生成的内容 #Wrapper { background-color: #e2e2e2; background-image: url("/static/img/shadow_light.png"), url("//cdn.v2ex.com/assets/bgs/circuit.png"); background-repeat: repeat-x, repeat-x; } #Wrapper.Night { background-color: #1f2e3d; background-image: url("/static/img/shadow.png"), url("//cdn.v2ex.com/assets/bgs/circuit_night.png"); background-repeat: repeat-x, repeat-x; background-size: 20px 20px, 162.5px 162.5px; }
这是一个创建于 2285 天前的主题，其中的信息可能已经有所发展或是发生改变。
按需求功能来算：
后端 拿一个简单功能的 curd 接口来说好了
前端 按一个页面模块来说好了
为什么提这种问题呢？ 因为我觉得在开发的时候看 word 版的 prd 对于细枝末节的地方真的很容易遗漏，特别是写成论文式样的 prd。还没人摘出来，有的需求在好几个地方要求一致，然后只在某一个功能上标注了，开发量一大好容易漏掉，然后测试 bug 率飙升。 而且，测试很多都是按看到的点来提的，比如一个接口的 bug，字段 A 值不对一个 bug，字段 B 为空一个 bug。。。结果一个接口好几个 bug。。。
bug 多的时候真的想哭
第 1 条附言 2019-07-16 22:17:33 +08:00
业务型团队的大迭代开发真的伤不起。。。
我要在 2 周内写 40+个接口，还附带一个技术难点。。。测试用例还是一下子发出来，光看用例就能花 4 小时- -，不要说跟着用例调一遍接口了- -
我要在 2 周内写 40+个接口，还附带一个技术难点。。。测试用例还是一下子发出来，光看用例就能花 4 小时- -，不要说跟着用例调一遍接口了- -
 | 1 jmc891205 2019-07-16 17:39:34 +08:00  1 bug 率是什么 分子是 bug 数量 分母是什么？代码行数？ |
 | 2 LongMaoz 2019-07-16 17:39:49 +08:00 脑子正常的时候基本不会写 BUG 但是有时候脑子抽了想不开了写出来的代码全是 BUG |
 | 3 nihaoaa 2019-07-16 17:41:22 +08:00 2 不存在的，我的代码没有 bug，肯定是测试不会测，还没搞懂需求就瞎 bb |
 | 4 wizzer 2019-07-16 17:42:15 +08:00 每天都在写 bug 中 |
 | 5 orzorzorzorz 2019-07-16 17:43:21 +08:00 并不会有。要是测试组测出来的 bug 多于某个数字是要扣绩效的，所以我都是 py 好测试，有 bug 别急着白纸黑字，先跟我说，我先熬着改着。你看无 bug 多简单。 |
 | 6 leonard916 2019-07-16 17:44:22 +08:00 基本不存在什麽 bug 只要需求明也基本不有 |
 | 7 way2create 2019-07-16 19:11:38 +08:00 1 bug 一般不是写出来的，是改出来的 |
 | 8 Sapp 2019-07-16 19:19:22 +08:00 1 只要不是改需求，我一般差不多一天一个 bug，不分大小，加班和赶工就不一定了，bug 急速增长。比较蛋疼的是经常有几个月前的小 bug 被发现，找了半天改完又改出了新 bug。 |
 | 9 GlobalNPC 2019-07-16 19:19:56 +08:00 via iPhone @orzorzorzorz 要是再来一条 ，测试开的 bug 少于多少扣绩效 咋办？ |
 | 10 Torpedo 2019-07-16 21:38:51 +08:00 一般提测前，自己把功能过一遍明显减少。有时间加单元测试。 流程上来说，测试必不可少 |
 | 15 vyronlee 2019-07-16 22:08:11 +08:00 via iPhone 巅峰时期最多挂着 200 多个 bug |
 | 16 Breadykid OP @orzorzorzorz 看来我没和测试搞好关系，人家是公事公办，态度强硬 |
| 17 Breadykid OP @leonard916 就是需求有很多无所谓的地方。。。然后测试用例变成了某个指定。。。 |
| 18 Breadykid OP @way2create 真理！ |
 | 20 herozzm 2019-07-16 22:10:42 +08:00 其实我一直想说 bug 多是水平差 别说需求 xxx |
| 21 Breadykid OP @infun 我们测试把 bug 数量算作自己的工作量。。。没开 bug 好像觉得自己没干活一样。。。坐边上的开发很鸡贼的在提测前 py 测试让他测一波，结果测完改完，提测后就不测了，还没提 bug。。。我觉得非常的不公平。。。 |
| 22 Breadykid OP @Torpedo 我以前也写单元测试的，可惜现在所在的团队是业务导向，也没有开发老大。。。估时不仅不给单测时间，还要压榨开发时间。。。哭哭 |
 | 26 fademeter 2019-07-16 22:48:15 +08:00 via Android 50% 这个概率应该很精准了，出 bug,不出 bug |
 | 27 encro 2019-07-16 22:59:14 +08:00 1 我们公司没有测试，2 刀 3 个程序员每个月几百万的营收也可以跑吧。 我认为： 1，测试就是将原本一个人的责任让两个人做，多一个人背锅，最后代码质量下降，没有单元测试，没有自动化测试； 2，写代码之前先画时序图，流程图，原型图，了解业务和数据流向； 3，写代码的时候先用注释实现伪代码（注释要求解析的是 why 而不是 how ），可以避免逻辑错误，提高写效率； 4，一键发布撤销 5，代码严格遵守 mvc,业务，界面逻辑，数据完全接偶； 6，与钱相关，基础核心一定要健壮，少而精，确保以后基本不要改的，做到最小化影响原则； 7，在清楚表达意思，不降低维护基础上，代码越短越好 |
| 28 encro 2019-0716 23:01:07 +08:00 1 核心思想： 程序最终健壮度、可用性等，是一个程序员的品牌，维护好自己的品牌，身价自然高。 |
 | 29 wengjin456123 2019-07-16 23:02:48 +08:00 via Android 少说几十个 bug 还没修，安心睡觉 |
 | 30 lei2j 2019-07-17 08:32:04 +08:00 via Android 修改需求容易出现 bug |
 | 31 brust 2019-07-17 09:04:32 +08:00 BUG 是需求文档要求的,这锅不背 |
 | 32 miaotaizi 2019-07-17 09:26:24 +08:00 1 需求没 BUG 了, 再来说 代码 bug 率 |
 | 33 cwjokaka 2019-07-17 09:31:00 +08:00 效率跟质量只能选 1 |
 | 34 kinghly 2019-07-17 09:52:40 +08:00 自测，像你说的文档看不够细、接口返回值不对与返回空，这本身就是你的问题，别推卸责任。做好这些你的 bug 率肯定大大降低。 |
 | 38 kuyuzhiqi 2019-07-17 11:17:19 +08:00 bug 多=公司兢兢业业的人才，代码混乱=公司不可或缺人才 |
 | 39 sherryqueen 2019-07-17 11:23:18 +08:00 bug 率? 难道不是每天写 bug 改 bug 吗? |
 | 41 mixure 2019-07-17 13:17:21 +08:00 1 1. TDD：测试提 bug 告诉开发，根据 prd, 你这功能没做 2. 管理：我不管你用什么方法， xx 号必须上线 3. m 开发，n 个测试：m>>n, 老板可以对外说，这不是测试工作效率高的体现吗？ 其实是公司能省就省，根本不拿测试当回事儿； 反正就这样，把质量当回事的人，不多；反正这是常态，爱咋咋地。 |
 | 42 glaucus 2019-07-17 13:19:20 +08:00 系统没下线，就永远有可能有还没发现的 BUG，所以我的 BUG 率没法算，发现一个修一个 |
 | 43 tabris17 2019-0717 13:21:13 +08:00 bug 率怎么计算？分母是啥？代码行数么 |
| 44 encro 2019-07-17 13:37:52 +08:00 1 @TabGre 一起探讨，前端 selemium,appium 之类，对于经常变动的、一次性开发的、非关键性业务，我也只能强调前端人员的品牌意识了。 |
 | 45 opengps 2019-07-17 13:40:09 +08:00 基本每个接口都是 bug |
 | 46 wujl100 2019-07-17 13:48:55 +08:00 不存在的，公司要统计 bug 率来扣绩效嘛？ 我司都已经开始一群人抽签来决定扣谁的了。。随缘。 |
 | 47 LokiSharp 2019-07-17 13:52:02 +08:00 我连写单元测试都能写出 Bug |
 | 48 arnoldxiao 2019-07-17 13:52:34 +08:00 肯定是测试的方法不对 |
 | 49 liuy1994g 2019-07-17 14:08:11 +08:00 我是前端，八个工作日写了一个模块，接近五十个接口，大概也有五十个 bug 吧，主要都出在时间太紧，细节部分出现 bug。 bug 率不知道，反正每次我的 bug 是最多的， |
 | 50 8355 2019-07-17 14:44:46 +08:00 我司测试出的用例只能他们自己用. 我是不能按照用例来自测接口的...... 不然真到线上出 bug 会被喷死. |
 | 51 linZ 2019-07-17 15:49:57 +08:00 按功能？ 500%吧，一个功能可以提 5 个 bug |
 | 52 andy2415 2019-07-17 15:50:23 +08:00 逗比测试,自己不会用说我有 bug? |
 | 53 songtianyi 2019-07-17 17:39:37 +08:00 我曾经对自己重构的项目做过统计， 计算公式：由 bug 导致的 issue 数 / issue 总数 = 15.7 % |
 | 54 quceng 2019-07-17 17:46:27 +08:00 我们公司是按照 BUG 数量 /开发人日计算 BUG 率的，按照平均标准是 3 个 /日 ，高级岗位人员一般是 1-2 个 /日。 |
Select Language