Bug的基本知识
1.Bug的定义：
bug就是一个电脑程序里的错误，而现在更是将其诞生为漏洞，或者一个程序不完善的地方。
2.Bug的分类：
- 致命（一级bug）：修改优 先级为最高，该级别问题需要立即修改。
致命bug：不能完全满足系统要求，系统停止运行，系统的重要部件无法运行，系统崩溃或者挂起等导致系统不能正常运行。
通常表现为：1.系统崩溃；2.导致程序重启，死机或非法退出；3.死循环；4.数据丢失或异常；5.数据通讯错误；6.硬件故障，系统悬挂。
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登录；6.循环报错，无法正常退出......
- 严重（二级bug）:修改优先级为高，该级别需要程序员尽快修改。
严重bug：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。
通常表现为：1.功能不符合用户需求 ;2.数据计算错误 ;3.业务流程错误 ;4.程序接口错误 ;5.因错误操作迫使程序中断； 6.系统可被执行，但操作功能无法执行（含指令）； 7.功能项的某些项目（选项）使用无效（对系统非致命的）； 8.功能实现不完整，如删除时没有考虑数据关联； 9.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用，对数据库的操作不能正确实现。
比如：1.功能未实现；2.功能存在报错；3.数值轻微的计算错误......
- 一般（三级bug）:修改优先级为中，该级别需要程序员修改。
一般bug：系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。
通常表现为：1.数据长度不一致;2.内容或格式错误 ;3.响应时间较慢 ;4.功能性建议 ;5.提示信息不太准确 ;6.操作界面错误（包括数据窗口内列名定义、含义是否一致）； ;7.简单的输入限制未放在前台进行控制； 8.虽然正确性不受影响，但系统性能和响应时间受到影响； 9.不能定位焦点或定位有误，影响功能实现； 10.增删改功能，在本界面不能实现，但在另一界面可以补充实现。
比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条......
- 低级（四级bug）：修改优先级为低，该级别需要程序员修改或不修改。
低级bug：使操作者不方便或操作麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题
通常表现为：1.界面不规范； 2.辅助说明描述不清楚； 3.输入输出不规范； 4.长时间操作未给用户提示； 5.提示窗口文字未采用行业术语； 6.可输入区域和只读区域没有明显的区分标志； 7.必填项与非必填项应加以区别； 8.滚动条无效； 9.键盘支持不好，如在可输入多行的字段中，不支持回车换行； 10.界面不能及时刷新，影响功能实现。
比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但不影响功能；4.界面格式不规范......
- 建议（四级bug）：修改优先级为低，该级别需要程序员修改或不修改。
建议：希望提出的建议以及建议进行但不强制进行的修改。不会给发布的准确性或可用性带来任何严重影响。
通常表现为：1.各种提示框信息使用不统一,未采用行业术语 ； 2.界面显示或描述建议 ；3.光标跳转设置不好，鼠标（光标）定位错误； 4.其他建议性问题。
禅道与bug级别的对应
| 禅道 |
|
| bug级别定义 |
对应值 |
| 致命 |
P1 |
| 严重 |
P2 |
| 一般 |
P3 |
| 低级与建议 |
P4 |
3.Bug的处理流程（生命周期）：
bug处理流程图
对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。
提交（打开） ： 表示问题被提交等待有人处理。
指派（转交） ： 问题被重新指派给某人处理。
处理 ： 问题在处理中，尚未完成。
固定 ： 确认此问题存在，但暂时不进行处理。
回归 ： 对已经修复的问题进行回归确认。Reopened :
关闭 ： 问题的最后一个状态。
提交（打开）缺陷
在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。如果是回归不通过的缺陷，其状态又会变为打开状态。
分配（转交）缺陷
这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
确认缺陷
当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
推迟处理
在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。
固定
对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷
开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
回归缺陷
回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。
确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。
确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。
确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷
对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
4.bug 单的要素：
一个bug单包含哪些要素：
1、所属的系统(产品)
2、发现的版本（轮次）
3、发现bug所属的模块
4、bug提交人
5、bug的错误类型：代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题等（默认）
6、bug的重现概率： 必现 大概率重现 小概率重现 极小概率重现
7、bug的严重级别：致命 严重 一般 提示 （影响范围越大，严重级别越高）
8、bug的优先级：高 中 低
9、bug的标题 言简意赅说明是什么bug， 而不是把测试用例名字复制一遍
10、bug单号 一般系统自动生成
11、bug内容：发现的环境、 预制条件、重现步骤、预期结果、实际结果， 截图证明，bug错误说明，(当开发看到能容能够独立重现这个bug，说明写的还行)
12：附件：测试用的数据或者出错的日志， 如果需要添加上日志
5.提交Bug 单的原因：
1、bug容易漏掉，导致bug遗漏到客户那里
2、把bug录入系统，给开发提供bug解决的依据，哪些bug 要优先改、哪些bug可以先不修改、
3、把bug录入系统，方便开发定位这个bug，因为bug会记录重现步骤
4、把bug录入系统，方便测试知道哪些bug 需要修改但是未修改，哪些bug已经修改可以回归
5、提交bug，测试人员有成就感
6、把bug录入系统，是研发过程改进的大数据库，根据不同维度的统计数据，发现研发过程中存在的问题