一、缺陷流程
错误——开发文档中的 错误
bug—— 源代码中的错误
缺陷——功能实现错误、功能遗漏、功能冗余、功能实现不好
失效——动态产生，不一定有效
二、缺陷产生原因
1、需求编写，表述不清楚
2、系统设计架构引起 （超出系统承受能力）
3、开发过程中缺乏有效的沟通 （涉及到决策 的工作 应主动和同时沟通）
4、编写代码时 产生错误
5、开发工具本身错误
6、软件需求复杂度较高，容易产生较多的缺陷
7、产品功能 不符合客户群体需求
三、缺陷格式（** 缺陷报告生成依据）
制定缺陷格式，便于记录缺陷
缺陷id
为阿拉伯数字，不可删除，不可复用，为缺陷的五一标识字段
概要描述
例如：商品查询功能，输出显示乱码
概括描述缺陷现象 或缺陷存在的形式，便于缺陷的处理
发现人
张某
发现时间
XX年/XX日/XX
修复时间
发现时间--修复时间 中间间隔最多不能超过3个工作日
所属版本
便于后期统计不同版本双，确定测试版本的发行风险
所属模块
缺陷所属功能的业务模块，便于后期统计每一个功能或业务模块的缺陷情况，利于回归投入，确定研发资源分配
缺陷状态
缺陷所属的活动状态
new 新发现的bug,还没有进入缺陷管理
open 确认缺陷，正式进入缺陷管理流程
fix 开发同时确认为 bug，并完成修改
close 经过测试校验 bug 已经恢复正常，无需再修改
reject 开发确认，是缺陷，并进行修改；不是，因需求变化不需修复的 bug 可定义为reject 状态
reopen 修复完成的fix 再次产生，或则再下一个版本中出现
缺陷严重度
缺陷引发的后果严重程度
low 缺陷后果不是很严重，表现为 页面不美观 使用不是太方便
medium 有错别字，显示字体不正确，子功能实现不完美
high 某个功能不可以正常使用
veryhigh
urgent
修复优先级
研发人员决定
详细概述
概要补充、产生错误步骤、测试数据、截图……
下一步处理人
某某
四、缺陷管理活动
角色定义
定义管理流程中涉及到的角色，主要职责
测试工程师： 发现bug 提交bug ，跟踪bug，回归测试
测试经理：审查测试工程师提交的 缺陷，以及解决有争议的bug
开发经理：负责分配缺陷 （决定那个开发解决 bug ），以及解决有争议的bug
开发工程师：编写bug 更改bug
项目经理：有争议的 bug 报告，进行解决 ，决策
流程定义
bug 解决流程，发现bug 提交——>测试经理 审查——>开发经理 审查——>开发 更改 （效率太低 个人建议）
工具应用
具体采用的是那一种 缺陷管理工具
开源工具
bugzilla
jira
mastins
bugfree
excel
QC/QLX
商用工具
模型选择
odc
四象限
gompertz