第三讲 缺陷报告
一、测试人员主要工作职责
1、编写（阅读）测试计划 ——3篇
2、编写测试用例并执行测试——1000条
3、提交缺陷报告——50份
4、编写测试总结报告——3篇
5、测试（缺陷）管理工具——QC
二、缺陷报告重要组成
1、缺陷编号（defect id） 提交缺陷的顺序 注意：
在实际项目中，一般采用缺陷管理工具，可以生成编号，整个项目组统一编号
2、缺陷标题（summary） 简明扼要的描述一下该bug
3、缺陷的发现者（detected by） 一般就是自己
4、发现缺陷的日期（detected on date） 一般就是当天
5、缺陷所属的模块（subject）
在测试程序的哪个功能模块时发现的bug 开发经理会根据bug所在的模块，找到由谁解决该bug
6、发现缺陷版本（detected in release） 在测试程序的哪个版本时发现的bug
7、指派给谁处理（aigned to） 测试人员指派给开发经理，开发经理会根据该bug所在的模块，再次指派给具体的开发人员进行解决bug
8、缺陷的状态（status）
缺陷此时所处的情况或处理的阶段
（1）测试人员发现bug，提交缺陷报告给开发经理，把缺陷的状态写成：New（新提交）
（2）开发经理验证此bug，如果是，把缺陷状态改为：Open（打开的bug，开发组承认的bug），并指派给开发人员进行bug修复；如果不是，把缺陷状态改为：rejected（拒绝的bug）
（3）开发人员看到指派给自己的bug，进行bug修复，修改完后，把缺陷的状态改为：Fixed（解决的bug，待返测的bug）
（4）测试人员对修复的bug进行返测，如果返测成功，把缺陷的状态改为：Closed（关闭的bug，归档的bug，返测成功的bug）；如果返测失败，把缺陷的状态改为：Reopen（重新打开的bug，返测失败的bug）
此过程称为：缺陷的处理流程，或者缺陷报告处理流程，缺陷的跟踪管理过程，缺陷的生命周期
New->Open->Fixed->Closed
9、缺陷的严重程度（severity）
表明该bug有多糟糕，或者对软件影响的大小
（1）urgent——致命的、造成系统死机、崩溃的bug （2）VeryHigh——非常严重的bug （3）High——严重的bug （4）Medium——中等程度的bug （5）Low——小的bug
说明：
在实际工作中，每个单词代表的具体情况会有所不同，为了避免争议，应该在相关文档中把每个级别的具体情形列举出来，供测试人员和开发人员参考 Bug Level（级别） Definition（定义）.xls 性能：Performance 功能：Function
10、缺陷的优先级（priority）
希望程序员什么时间内或在程序的哪个版本中解决该bug （1）Urgent——立即修改，否则影响测试/开发进度 （2）VeryHigh——本版本修改 （3）High——下版本修改
（4）Medium——发布之前修改
（5）Low——允许在发布中存在的bug
优先级制定时主要考虑因素：
（1）严重程度—— 一般严重程度越高，优先级越高 （2）影响范围—— 一般影响范围越广，优先级越高
（3）参考开发组的当前任务压力——开发任务越轻，优先级越高 （4）解决bug的成本——成本越低，优先级越高
11、缺陷描述
把发现缺陷的过程、步骤、使用的数据等记录下来，使程序员通过该描述，能够再现该bug 第三讲（续） 说明：
1、优先级和严重程度不是严格正比关系
2、严重程度确定好后，一般就不再更改；而优先级确定好后，可能经常修改，一般会向后推延
3、不是所有的bug在产品发布之前都能被修复
对于发布之前不修复的bug，要通过缺陷讨论，明确解决bug的成本、时间，以及该bug如果不解决给用户造成的影响、损失
三、缺陷报告的用途
1、记录bug
2、对bug进行分类（日期、版本、模块、发现者、严重程度、优先级、状态）
3、对bug进行跟踪管理（New->Closed）
4、对bug进行统计、分析
四、软件缺陷的识别
1、用“实际结果”与测试用例中的“预期结果”进行比对，如果不一致，就是bug
2、参考需求文档
3、与开发人员、需求人员、用户等进行沟通讨论
4、参考第一讲中缺陷的5点定义
五、注意问题（了解）
不可重（再）现的bug也叫做随机bug，也要报告，但要说明该bug不可重现，如果可能可以对bug做截图
六、缺陷报告的处理流程 ——参考缺陷状态时笔记
七、上机练习（即时贴） 每人提交10个bug
