缺陷和错误的联系和区别：
1.缺陷报告是描述软件缺陷现象和重现步骤的集合。软件缺陷报告Sofeware Bug Report(SBR)
2.软件问题报告Sofeware Problem Report(SPR)
3.问题一定是缺陷，缺陷不一定是问题
缺陷报告的作用
• 缺陷报告是软件测试人员的工作成果之一，体 现软件测试的价值
• 缺陷报告可以把软件存在的缺陷准确的描述出 来，便于开发人员修正
• 缺陷报告可以反映项目/产品当前的质量状态， 便于项目整体进度和质量控制
• 软件测试缺陷报告是软件测试的输出成果之一， 可以衡量测试人员的工作能力
测试人员的考核;
1.Bug的数量：基本上每天五个，一个月每人100个
2.Bug的质量：不要都是界面问题、易用性问题，要发现深层次的问题、业务流程问题、需求问题
软件测试缺陷报告的“5C”原则
内容准确(Correct) 每个组成部分的描述准确，不会引起误解
步骤简洁(Concise) 只包含必不可少的信息，不包括任何多余的内容
内容清晰(Clear) 每个组成部分的描述清晰，易于理解
结构完整(Complete) 包含重现该缺陷的完整步骤和其他本质信息
风格一致(Consistent) 按照一致的格式书写全部缺陷报告（简单、清晰、明了的风格）
缺陷报告的内容
• 缺陷的标题；
• 缺陷的基本信息；
– 测试的软件和硬件环境；
– 测试的软件版本；
– 缺陷的类型；
– 缺陷的严重程度；
– 缺陷的处理优先级。
• 复现缺陷的操作步骤；
• 期望的正确结果描述；
• 注释文字和截取的缺陷图像
80%+20%*80%=96% 剩余4% BUG不能完全被消灭
记录缺陷与缺陷报告
• 使用较少的、必要的操作步骤确保缺陷能够重 现
• 记录缺陷时要使用专业术语、注意书写格式
• 缺陷要言简意骇、尽量一个缺陷一个报告
• 对于实在不可重新的缺陷也需要报告并且尽 快报告
• 不能夸大缺陷的数量和缺陷的级别
• 及时记录缺陷
缺陷的分类
类型、严重程度、优先级、所属模块
严重程度：
致命错误：如数据丢失、死机、系统崩溃
严重错误：如功能未完成，功能完成不正确
一般错误：如功能不完善，界面问题等
建议：测试人员认为怎么处理更好一些的问题。
类型：
– 功能
– 压力/负载
– 界面
– 兼容
– 易用
– 安装/卸载
– 安全
优先级：
– 立即修改
– 在本版本中修改
– 在产品发布前修改
– 在发布版本中可以存在的问题
缺陷报告的处理流程
提交缺陷报告
返测报告
分配缺陷报告
处理缺陷报告
返测通过
关闭缺陷报告
返测未通过
总结：
1.一条BUG包括哪些类型？
2.怎么提交一个高质量的BUG？
3.缺陷和错误的区别？
4.缺陷的分类？
5.严重程度的分类及表现，严重程度高的优先度不一定高
6.优先级的等级及表现？
7.缺陷处理流程？
