这个是不会有一个明确的定义的
也没定义说一个产品测试出多少BUG之后就发布了
所以按照BUG数量来判断产品是不对的
一般产品发布公司都有要求
比如：严重等级的BUG必须修正、影响用户使用的BUG必须修正
但是有一些是是很难复现的、你在测试中发现了BUG但是却不能复现出来、或者是有的BUG能复现
但是项目组讨论却认为不一定要修改。
我现在的这个产品、我在做第一个版本的是有2000多个BUG
之后在做第二个版本的时候只有100个左右、第三个的版本时候有70多个
现在已经更新到第五个版本了也都差不多是70个左右
一天提多少个bug属于正常
正常情况下， 如果加上你修复的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有效性
Bug严重程度、优先级、缺陷类型是否准确；
需求是否明确、前提条件是否满足、输入数据是否正确、操作步骤是否清晰、问题是否必现、log是否齐全，Bug是否唯一性；
避免提交设计如此、操作错误、重复的、已知的Bug；
尽量多提业务逻辑功能、交互测试方面的问题，同时要兼顾边界值、页面显示问题；
bug六要素：
测试环境、前提条件、操作步骤、预期结果、实际结果、恢复方法
测试设备：
提交Bug要表明测试使用的设备、设备操作系统版本、测试环境、网络类型等等。
前提条件
明确指出所提交的Bug是在怎么样的情况下出现的，当所发现Bug前提条件为空时，需要填【无】。
测试步骤
要简明清晰分步骤描述如何复现Bug问题，步骤用序号编排。
要按照自己的操作的实际步骤写清楚每一步是怎么操作的，最后操作到哪个页面或者点击哪个按键。
如在特定情况下发生的问题，还需明确提供以下信息：
1.准确写出连续点击次数，点击时长与上下滑动屏幕时长。
2.对于特定数据产生的问题，提供具体数据。
3.精准描述bug产生的路径后，再描述现象。
特别提醒：测试步骤中的点击要用->符号连接
期望结果
按照测试步骤应当得到的正确结果，按照产品需求的期望清晰准确的填写预期结果。而且结果必须是肯定无疑义，可判定性的结果。
特别提醒：期望结果不要包含测试步骤，要是简单的一个结果
实际结果
按照测试步骤实际出现的错误结果，避免使用“不正常”，“有误”等模糊词汇，需要直接描述实际现象。
特别提醒：期望结果和实际结果要相互对应
复现步骤描述及概率
描述复现步骤中的页面切换为避免出现描述不清晰或者有歧义，需用“->”符号连接
关于复现概率一定要在多次测试的基础之上填写，若必定复现则填写100%，若偶现，请执行多次后统计概率填写。
截图和附件
UI类型：Bug需要上传截图，并且增加相应的红框标识；
功能类型：必要时上传视频文件，上传格式MP4为主；
崩溃类型：bug则需要上传视频和log并且log不得超过10分钟。
特别提醒：
为避免错失偶现bug，测试时应保持开启log，bug尽量都附上log
附件命名需与标题相呼应，必须注明出现bug的时间点
log日志抓取不能超过10分钟
文件名称不能出现怪异冗长
以上就是关于软件测试中bug数量一般为多少全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
