正常情况下， 如果加上你修复的BUG，你犯的错误，差不多，10行代码至少有一个BUG。所1000行代码， 至少要有100个BUG。

但是大部分BUG都被消除在编码阶段，剩下的一大半消除在单元测试阶段。然后更少的在集成测试，以及测试人员测试中发现。最后只有几个type error可能会隐藏很久。

如果按单元测试阶段计算，100行代码有4-5个BUG是正常的，但是测试人员发现的BUG，1千行代码， 可能1-2个BUG。真正的大部分BUG，在程序员手里已经解决了。

软件开发中一个三个月的对日项目，黑盒测试一般能测出多少个bug（要具体的数字）

没有一个明确的定义的。比如：严重等级的BUG必须修正、影响用户使用的BUG必须修正。但是有一些是是很难复现的、在测试中发现了BUG但是却不能复现出来、或者是有的BUG能复现 但是项目组讨论却认为不一定要修改。

bug原意是“臭虫”，现可用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。广义上，bug可用作形容各领域范围内出现的漏洞或缺陷。

名称由来：

为马克2号（Harvard Mark II）编制程序的葛丽丝·霍波（Grace Hopper）是一位美国海军准将及计算机科学家，同时也是世界最早的一批程序设计师之一。

有一天，她在调试设备时出现故障，拆开继电器后，发现有只飞蛾被夹扁在触点中间，从而“卡”住了机器的运行。于是，霍波诙谐的把程序故障统称为BUG(飞虫)，把排除程序故障叫DEBUG，而这奇怪的“称呼”，竟成为后来计算机领域的专业行话。

如何统计平均需求bug率

要看具体的软件代码行数。

一般日方允许的bug率大概在千分之2左右，即1千行代码2到3个bug。

而且代码量越多，相应的bug率也要越低。

如果整个代码量是10万行，那么整个测试阶段的bug上限就在200个，最好控制在100个以内。

黑盒测试大概占到三分之一左右。具体个数计算一下就行了。

有哪些最大限度降低bug率的办法？

＂＊＊率＂这个东西由分子和分母计算而来的，所有要确定分子和分母是什么先，其实也就是要确定分母，具体起来，主要的一方面就要看你是对bug这么个分类了，状态，严重程度，发现人，解决人，所属模块，所属负责人，出现阶段，缺陷根源类型，等等不同的bug划分方法和不同的bug　属性都可以参考的，至于统计哪些值要取决于你的度量目的了，也就是统计是为了说明或证明什么事情，证明给谁看．另一个方面还要统计bug以外的相关数据，如需求用例书，功能点数，代码行数，代码生产效率（这个和bug数量关系也很大，不同的开发语言也不同），等等，数据的使用同样是要基于你的统计目的的．

1、编程习惯

种⽠得⽠种⾖得⾖，好的编程习惯可以⼤⼤降低Bug数量。譬如有if必须写else，即使else是个空语句 。

2、写代码的时间问题

对于程序员⽽⾔，千万别熬夜写代码。⼀些程序员在晚上11点，仍然在敲代码。

虽然你⾃⼰觉得头脑其实很清醒，但是第⼆天⾃测，或者QA测试的时候你有可能就会发现问题很多。

我们⼀般不提倡长期加班写代码，因为那样会导致Bug率直线上升。

3、验

在提交测试前要多验，其中包括⾃动化测试、⼿动跑⽤例等。

有句话说得好，千万别怕烦，不然你会烦辈。

4、仔细的设计

在程序员编写代码之前，必须对代码的整个结构以及逻辑结构胸有成⽵。

5、避免⼲扰

有部分的程序员敲代码的时候，经常会⼀边听⾳乐⼀边敲代码，这样效率不仅仅低，⽽且也更容易产⽣Bug。

6、注释

写注释，写注释，写注释。重要的事情说三遍。

因为前期的注释有利于后续开发的时候容易减少bug。

⾃从修改了注释模板，整个⼈精神多了，bug也明显少了。

7、利用工具

另外为了尽早发现Bug，CoCode开发了评审分析工具，通过缺陷移除率评估，评估项目评审效果，从而尽早发现项目里的缺陷，提高项目开发质量。

以上就是关于1000行代码出现多少个bug在合理范围内全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！