软件测试缺陷

缺陷的定义

• 产品的定义不满足用户需求
• 测试执行时，实际结果与预期结果不一致

缺陷产生的根本原因

• 需求变更
• 沟通不畅，信息不同步
• 软件复杂
• 进度压力
• 需求文档存在错误非根本
• 设计存在错误非根本

缺陷的基本要素 

• 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