一、基本术语
常见术语：bug defect issue
严重程度：Mistake→defect&bug→fault→failure
二、缺陷报告单
*Bug title/summary：标题 对问题的简单概要描述
描述的问题，实际结果（不等于/有偏差）预期
如:视频播放的进度条挡住主界面
测试绩效考核： bug数量，有效的bug率=(总bug-重复bug-不重现的bug)/总bug量
*Bug reproduce steps:重现步骤
1)按照重现步骤执行，可以看到描述的缺陷：
a.如果bug是执行用例发现的，--用例执行步骤
b.详细的实际结果
c.期望结果
2)Bug重现率：bug不是每次重现，一般重现3次再提交，例如10次中6次重现，重现率6%
3)附件：图片格式gif,jpg,jpge一般不用bmp太大，同时给图片命名
4)缺陷原因分析：缺陷产生的可能原因。
三、缺陷管理的基本流程
流程梳理：
1.测试人员在发布服务器上拿到最新版本的软件，开始测试（手动或自动化测试），执行测试过程中，发现bug,记录到BMS缺陷管理系统中；
2.测试人员会发送邮件给开发人员，开发人员得到最新bug后，定位bug，寻找原因，若问题简单直接解决，若问题较复杂（比如一个bug可以采取三个修改方案，三个方案各有利弊），开发人员会发送邮件给评审专家，共同商讨采用哪种方案；
3.经讨论确认方案后，开发人员进行修改，修改完毕后把修改后的源代码check in 到源代码服务器上，这个服务器上有软件对代码进行管理，该软件就是配置管理软件；
4.开发人员check in 后，Builder（每日构建技术人员）会从源代码服务器上获取最新的源代码，并且进行编译，编译之后把软件最新版本发布到服务器上；
5.测试人员再把新版本下载下来，并验证该版本是否修复了之前版本中发现的缺陷，这就是一个回归测试的过程。
上面就是一个简单的缺陷管理流程，通过这样一个完整的流程，以bug为驱动，对软件的缺陷记录、提交、修改、验证有了一个很好的管理流程，因为一个完整的缺陷管理过程是贯穿测试、开发、builder的全过程。
四、缺陷管理的目的
1.缺陷跟踪
保证缺陷得到有效的跟踪和解决。
2.缺陷分析
获取正确的bug信息，用作缺陷分析和产品度量。
五、缺陷管理相关工具
软件缺陷跟踪过程需要有软件工具支持：
1.付费工具有：Mercury Quality Center(简称TD) Rational ClearQuest(简称CQ) HP Quality Center(简称QC)
2.免费开源工具有：Bugzilla Mantis Jira
如何选择工具，建议根据公司财力来，如果公司财力比较雄厚，可以采用付费工具，可用性和易用性较好，同时还有相关技术支持服务；若公司较小，建议使用免费工具，节省开支。
六、缺陷管理相关角色
软件开发人员，测试人员，开发经理，测试经理，CCB变更控制委员会（开发和测试的协调）、配置管理员（软件版本管理）
七、缺陷管理的相关属性
1.缺陷发现人：可以据此对测试人员进行绩效考核
2.缺陷发现时间
3.缺陷所属版本：避免开发和测试产生混乱。
4.缺陷修改日期：可以据此对开发人员进行绩效评估。
5.软件缺陷的状态 state
| 软件缺陷状态 | |
| New | 缺陷的初始状态 |
| Open | 开发人员开始修改缺陷 |
| Fixed | 开发人员修改缺陷完毕 |
| Closed | 回归测试通过 |
| Reopen | 回归测试失败 |
| Postpone | 推迟修改 |
| Rejected | 开发人员认为不是程序问题，拒绝缺陷 |
| Duplicate | 与已提交的Defect重复 |
| Abandon | 被 Reject和Duplicate的Defect，测试人员确认后的确不是问题，改为此状态 |
6.severity 软件缺陷严重程度
严重程度：致命→严重→一般→提示
1) 严重性（bug修改的顺序 站在项目的角度综合权衡项目时间、进度、技术和风险）
高：当天修改 0~8h内
中：2~4天
低：一周内或者本发布周期
2）priority 优先级 P0~p4级别（BUG出现对于系统造成的影响，站在用户角度）
P0：block issue导致测试挂起 尽快修改（代码回滚，回到前一个版本）
P1：当天修改 0~8
P2：功能相关
P3：主要配置环境的UI
P4：可以不修改
判断：严重等级比较高的bug优先级别一定高？
N 。若 bug很严重但是重复率很低，或者影响项目发布，或当前技术有限，或当前bug修改会产生更大的风险，优先级别可以降低。
7.Issue type 缺陷类型
a. 功能角度
-----error 错误
-----missing 功能遗漏
-----extra 多余的
-----improvement 需优化的，建议修改
b. 质量特性
-----功能性
-----性能
-----安全性
-----配置
-----可靠性
c. 缺陷产生的原因
DCR→design change request设计变更、Perf→性能、Spec→需求、Test→测试
8.bug管理流程图
9.缺陷状态迁移矩阵
