什么是bug

bug的定义：

程序错误（英语：Bug），在程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、体验不佳、死机、数据丢失、非正常中断等现象。中文常称BUG为“缺陷”。而且，“缺陷”一词更能反映事情的本质。因为“臭虫”是从外面爬进去的，并非程序本身有问题。而程序本身存在的问题，是程序原来就具有的。因此，在这里将BUG翻译为“系统漏洞”更合适。在程序运用中，特别是应用程序，会出现莫名其妙的警告，让普通用户丈二和尚----摸不着头脑，这些警告常被称作“BUG”。

https://baike.baidu.com/item/bug/32708?fr=kg_qa

Bug组成部分	分类	描述	解决时长	备注
bug标题	对你所提交的Bug进行简明扼要的描述	对你所提交的Bug进行简明扼要的描述
bug详细描述	测试步骤 实际结果 预期结果	对Bug进行进一步详细的描述，例如在什么情况下发生等； 也可以直接将标题作为描述部分（简短明了时可以） 测试步骤：让你将自己在测试的过程简单的写一下，从你开始测试软件的最开始到你发现bug的时刻为止（简单的说就是你的测试过程一步步罗列下） 实际结果：在测试软件的过程中，软件所表现出来的特征或者行为； 预期结果：软件需要设计所要求达到的结果或者目标。
bug所属业务线	属于哪个业务线	如：A、B、C
bug所属项目版本	哪个项目哪个版本	如：A项目1.0版本 B项目1.2版本
bug所涉及到的域	是哪个域产生的bug	如：test.com testa.com
bug所属模块	属于哪个功能模块（一般按菜单/功能划分）
bug产生环境	测试环境 回归环境 预发布环境 线上环境	在什么环境中发现的这个bug，例如：什么系统，哪个版本等。 对于bug环境的描述可以通过简单的罗列即可（精简为主）。
bug优先级	紧急	重要非常紧急：优先级最高，一定要做的 Immediate 即“马上解决”， 表示问题必须马上解决，否则系统根本无法达到预定的需求。
	高	重要比较紧急：暂时可以先缓一缓 但一定要做的 Urgent即“急需解决”， 表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
	中	重要不紧急：暂时可以先缓一缓 但一定要做的 High即“高度重视”， 表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
	低	紧急不重要：可以先准备下，随时准备做的
	一般	不紧急不重要：可忽略不计的
bug严重程度	Blocker 即系统无法执行、崩溃或严重资源不足、 应用模块无法启动或异常退出、 无法测试、造成系统不稳定。	· 阻碍开发或测试工作的问题； · 内存泄漏 ·  用户数据丢失或破坏 · 造成系统崩溃、死机、死循环，导致数据库数据丢失， 与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数 据库发生死锁、重要的一级菜单功能不能使用、内存泄漏、严重计算错误、无法登录、无法正常退出、功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出， 关联程序间调用冲突等。 · 模块无法启动或异常退出 · 严重的数值计算错误 · 功能设计与需求严重不符 · 其它导致无法测试的错误, 如服务器500错误	1-2小时
	Critical 即影响系统功能或操作， 主要功能存在严重缺陷， 但不会影响到系统稳定性。	· 功能未实现 · 功能错误 · 系统刷新错误 · 数据通讯错误 · 轻微的数值计算错误 · 安全性问题 · 数据库保存调用错误、用户数据丢失 · 一级功能菜单不能使用	2-4小时
	Major 即界面、性能缺陷、兼容性。	· 操作界面错误（包括数据窗口内列名定义、含义是否一致） · 边界条件下错误 · 提示信息错误（包括未给出信息、信息提示错误等） · 长时间操作无进度提示 ·  系统未优化（性能问题） · 光标跳转设置不好，鼠标（光标）定位错误 ·  兼容性问题 · 影响功能及界面的错误字或拼写错误 · 功能没有完全实现但是不影响使用 · 功能菜单存在缺陷但不会影响系统稳定性。 如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多、容错性不好、大数据无响应或没有滚动条等	1天
	Normal 即“正常处理”，进入个人计划解决， 表示问题不影响需求的实现，但是影响其他使用方面	页面调用出错，调用了错误的等。	1-2天
	Low 即“低优先级”，即问题在系统发布以前必须 确认解决或确认可以不予解决	界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。 如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏， 描述不清楚，提示语丢 失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等	2天
bug状态	新的New	当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug 的状态设为New
	已指派Assigned	当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug 指定给某位开发人员处理，并将bug的状态设定为“Assigned”
	已解决fixed	当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug 返还给测试组
	已关闭closed	如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”
	重开Reopen	如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
	Rejected(被拒绝的)	测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，发组负责人就将这个bug的状态设置为“Rejected”
	Postponed（延期）	有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“
bug处理人	开发 测试 产品	指派给谁，谁需要处理这个bug
bug产生原因	代码问题	白盒测试、自测、代码review 业务逻辑方面以及业务描述等相关问题 功能上的错误性bug
	设计问题	数据库设计文档、概要/详细设计文档
	用户界面	表单逻辑、样式、内容问题 用户界面：UI表现，包括对话框样式和文字描述问题
	需求建议	原有的需求基础上的更改 新增需求：会议上提出的新需求，非正式会议提出的不属于该项 功能已满足但待改善，属于改良性建议
	环境问题	如web服务器或者数据库服务器配置等问题 安装部署：项目部署时出现的错误，可能不是程序本身的问题而是工具本身和人为因素引起
	性能问题	负载、压力测试
	安全问题	加密和水印等安全信息
	测试误报	不理解功能需求未跟开发产品确认
	其他
bug解决方案	代码 需求 设计 其他	简单说明bug是怎么解决的
备注	对bug的一些补充，例如：其它系统也发生，上个版本不发生等需要补充的内容

bug等级划分

bug严重等级	bug现象	bug优先级	解决时长
致命：Blocker 即系统无法执行、崩溃或严重资源不足、 应用模块无法启动或异常退出、 无法测试、造成系统不稳定。	· 阻碍开发或测试工作的问题； · 内存泄漏 · 用户数据丢失或破坏 · 造成系统崩溃、死机、死循环，导致数据库数据丢失， 与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用、内存泄漏、无法登录、无法正常退出、关联程序间调用冲突等。 · 模块无法启动或调用，程序重启、自动退出 · 严重的数值计算错误 · 功能设计与需求严重不符 · 其它导致无法测试的错误, 如服务器500错误 · 接口不可用或调用不通	重要非常紧急：优先级最高，一定要做的 Immediate 即“马上解决”， 表示问题必须马上解决，否则系统根本无法达到预定的需求。	1-2小时
严重：Critical 即影响系统功能或操作， 主要功能存在严重缺陷， 但不会影响到系统稳定性。	· 功能未实现：如增删改查未实现 · 功能错误 · 系统刷新错误 · 数据通讯错误 · 轻微的数值计算错误 · 安全性问题 · 数据库保存调用错误、用户数据丢失 · 一级功能菜单不能使用	重要比较紧急：暂时可以先缓一缓 但一定要做的 Urgent即“急需解决”， 表示问题的修复很紧要，很急迫，关系到系统的 主要功能模块能否正常。	2-4小时
较严重：Major 即界面、性能缺陷、兼容性。	· 操作界面错误（包括数据窗口内列名定义、含义是否一致） · 边界条件下错误 · 提示信息错误（包括未给出信息、信息提示错误等） · 长时间操作无进度提示 · 系统未优化（性能问题） · 光标跳转设置不好，鼠标（光标）定位错误 ·  兼容性问题 · 影响功能及界面的错误字或拼写错误 · 功能没有完全实现但是不影响使用 · 功能菜单存在缺陷但不会影响系统稳定性。 如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多、容错性不好、大数据无响应或没有滚动条等	重要不紧急：暂时可以先缓一缓 但一定要做的 High即“高度重视”，表示有时间就要马上解决， 否则系统偏离需求较大或预定功能不能正常实现。	1天
一般：Normal 即“正常处理”，进入个人计划解决， 表示问题不影响需求的实现，但是影响其他使用方面	页面调用出错，调用出错	紧急不重要：可以先准备下，随时准备做的 不影响功能正常使用	1-2天
较低：Low 即“低优先级”，即问题在系统发布以前必须 确认解决或确认可以不予解决	界面、性能缺陷，建议类问题 如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏， 描述不清楚，提示语丢 失，文字排列不整齐，光标位置不正确	不紧急不重要：可忽略不计的 不影响操作功能的执行，可以优化性能的方案等。	2天

bug分类

bug分类	描述
代码问题	白盒测试、自测、代码review 业务逻辑方面以及业务描述等相关问题 功能上的错误性bug
设计问题	数据库设计文档、概要/详细设计文档
用户界面	表单逻辑、样式、内容问题 用户界面：UI表现，包括对话框样式和文字描述问题
需求建议	原有的需求基础上的更改 新增需求：会议上提出的新需求，非正式会议提出的不属于该项 功能已满足但待改善，属于改良性建议
环境问题	如web服务器或者数据库服务器配置等问题 安装部署：项目部署时出现的错误，可能不是程序本身的问题而是工具本身和人为因素引起
性能问题	负载、压力测试
安全问题	加密和水印等安全信息
测试误报	不理解功能需求未跟开发产品确认
其他

bug状态
新的New	当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug 的状态设为New
已指派Assigned	当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug 指定给某位开发人员处理，并将bug的状态设定为“Assigned”
已解决fixed	当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug 返还给测试组
已关闭closed	如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed”
重开Reopen	如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
Rejected(被拒绝的)	测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，发组负责人就将这个bug的状态设置为“Rejected”
Postponed（延期）	有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed“