缺陷的定义
- 产品的定义不满足用户需求
- 测试执行时，实际结果与预期结果不一致
缺陷产生的根本原因
- 需求变更
- 沟通不畅，信息不同步
- 软件复杂
- 进度压力
- 需求文档存在错误非根本
- 设计存在错误非根本
缺陷的基本要素
- ID编号：唯一
- 模块：根据产品进行具体的划分，如登录、注册
- 缺陷状态：表明缺陷处理进度
- 严重程度：从技术维度来衡量，bug的破坏力
- 优先级：从业务的角度，决定bug修改的先后顺序
- 缺陷类别：用于分类整理缺陷
缺陷的状态
- new：新建
- open：打开
- fix：已修复
- close：关闭（修复完之后回归测试没问题就可以关闭）
- reopen：重新打开
- reject：已拒绝（开发人员认为bug不是很重要）
- postpone：延期
缺陷严重程度
- 5-致命的
- 4-非常高
- 3-高
- 2-中
- 1-小
缺陷的优先级
- 5-紧急的
- 4-非常高
- 3-高
- 2-中
- 1-低
软件缺陷类型
- 功能错误
- 界面UI错误
- 兼容性错误
- 易用性
- 改进建议
- 其他
编写缺陷报告注意事项
- 可复现
- 唯一性
- 一个问题只提交一个bug记录
缺陷跟踪管理过程
- 开始
- 1.测试发现并提交bug
- 2.分配bug到负责具体模块的开发工程师
- 3.是否重复
- 4.确认是否是bug
- 5.确认是否延期
- 6.开发修改bug
- 7.测试人员针对bug进行回归测试
- 8.回归测试是否通过
- 9.测试/开发关闭bug
- 10.开发拒绝修改bug
- 11.开发延期处理
- 结束
测试用例
1->2->3不重复->4是->5否->6->7->8通过->9
1->2->3不重复->4是->5否->6->7->8不通过->6->7->8
1->2->3重复->9开发关闭bug
1->2->3不重复->4不是->10
1->2->3不重复->4是->5是->11
场景一：确认bug解决 new->open->fix->close
场景二：验证未通过，缺陷仍存在 new->open->fix->reopen
场景三：开发延期处理 new->open->postpone
场景四：拒绝处理 new->open->reject
