第三讲缺陷报告一、测试人员主要工作职责1、编写(阅读)测试计划——3篇2、编写测试用例并执行测试——1000条3、提交缺陷报告——50份4、编写测试总结报告——3篇5、测试(缺陷)管理工具——QC二、缺陷报告重要组成1、缺陷编号(defectid)提交缺陷的顺序注意:在实际项目中,一般采用缺陷管理工具,可以生成编号,整个项目组统一编号2、缺陷标题(summary)简明扼要的描述一下该bug3、缺陷的发现者(detectedby)一般就是自己4、发现缺陷的日期(detectedondate)一般就是当天5、缺陷所属的模块(subject)在测试程序的哪个功能模块时发现的bug开发经理会根据bug所在的模块,找到由谁解决该bug6、发现缺陷版本(detectedinrelease)在测试程序的哪个版本时发现的bug7、指派给谁处理(assignedto)测试人员指派给开发经理,开发经理会根据该bug所在的模块,再次指派给具体的开发人员进行解决bug8、缺陷的状态(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-Closed9、缺陷的严重程度(severity)表明该bug有多糟糕,或者对软件影响的大小(1)urgent——致命的、造成系统死机、崩溃的bug(2)VeryHigh——非常严重的bug(3)High——严重的bug(4)Medium——中等程度的bug(5)Low——小的bug说明:在实际工作中,每个单词代表的具体情况会有所不同,为了避免争议,应该在相关文档中把每个级别的具体情形列举出来,供测试人员和开发人员参考BugLevel(级别)Definition(定义).xls性能:Performance功能:Function10、缺陷的优先级(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、记录bug2、对bug进行分类(日期、版本、模块、发现者、严重程度、优先级、状态)3、对bug进行跟踪管理(New-Closed)4、对bug进行统计、分析四、软件缺陷的识别1、用“实际结果”与测试用例中的“预期结果”进行比对,如果不一致,就是bug2、参考需求文档3、与开发人员、需求人员、用户等进行沟通讨论4、参考第一讲中缺陷的5点定义五、注意问题(了解)不可重(再)现的bug也叫做随机bug,也要报告,但要说明该bug不可重现,如果可能可以对bug做截图六、缺陷报告的处理流程——参考缺陷状态时笔记七、上机练习(即时贴)每人提交10个bug