缺陷管理与工具应用

第三章缺陷管理与工具应用目录•缺陷的定义•缺陷的生命周期•缺陷的跟踪与分析•缺陷工具应用缺陷的定义•什么是缺陷–（美）RonPatton在其著作的《软件测试》一书中把符合下列五个规则的问题称为缺陷：•1．软件未达到产品说明书标明的功能；•2．软件出现了产品说明书指明不会出现的错误；•3．软件功能超出了产品说明书指明范围；•4．软件未达到产品说明书虽未能指出但应达到的目标；•5．软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。缺陷的定义•缺陷的名称–Defect–Bug–Failure–Error–………测试执行的监控测试监控的任务和目的•记录和管理测试用例的执行状态•根据当前的执行状态，判定测试用例的设计质量和效率–使用脚本进行自动测试•根据发现的缺陷分布，判定结束测试的条件是否成熟测试监控的任务和目的•评估测软件的质量–缺陷的数量、种类、…•评估开发过程的质量–缺陷的分布、修复缺陷的时间、回归测试时发现的缺陷数量、…•评估测试工程师的表现–是否按计划完成任务–发现缺陷的数量测试监控的内容•测试用例执行的进度=已执行的数目/总数目–此数据只表明执行进度，不表示测试的成功率–为了得到更精确的进度数据，可计算测试步骤数测试监控的内容•缺陷的存活时间=缺陷从open到closed的时间–表明修改缺陷的效率测试监控的内容•缺陷的趋势分析---按照测试执行的时间顺序(以月、周、天为时间单位)，被发现的缺陷数量的分布–如果越来越少，趋近于0，则考虑结束测试执行–相反，则说明存在以下的问题：•代码修改引发新的缺陷•前一版本的测试存在覆盖率的问题，新的测试发现了原先未发现的缺陷•必须先修改某些缺陷后才能继续测试，然后才发现其他的缺陷测试监控的内容•缺陷分布密度=对应于一项需求的总缺陷数/对应于该项需求的测使用例总数–需要考虑缺陷的优先级和严重程度–如果过多的缺陷集中在某项需求上，可能表明以下问题：•该项功能需求是否过于复杂？•该项的需求设计、实现是否有问题？•分配给该项的开发资源是否不足？•……测试监控的内容•缺陷修改质量=每次修改后发现的缺陷数量（包括重现的缺陷和由修改所引起的新缺陷）–评价开发部门修复缺陷的质量–如果修改某项功能后，此数值较高，测试部门应当及时通知开发部门改进测试执行过程•基于质量风险分析，先测试最容易出现缺陷、对软件影响最大的部分•基于用户操作分析,先测试用户经常使用的功能可能对软件的影响•正确分析测试结果•……缺陷报告元素•Bug编号（BugID）•版本号（Version）•Bug状态（State）•Bug类型（Keyword）•项目及子模块名称（Product）缺陷报告元素•Bug摘要（Summary）•附件（Attachment）•操作系统（OS）•浏览器（Browser）•优先级（Priority）缺陷报告元素•严重级（Severity）•Bug操作描述（Description）•报告人（Reporter）•报告日期（Date）缺陷报告元素•Bugzilla缺陷表缺陷状态与生命周期•缺陷的状态•New：报告一个Bug。•Open：验证后分配给相关的开发人员进行修改状态。•Fixed：开发人员修改后的状态。•Verified：等待测试人员验证的状态。•Reject：拒绝修改Bug。•Reopen：如果没修改成功，则重新打开。•Closed：如果修改成功，则关闭Bug。缺陷状态与生命周期截图技巧•Windows全屏用键盘上的print•Windows截面活动窗口alt+Print•Mac全屏截图Command+Shift+3•区域截图:Command+Shift+4程序窗口截图:Command+Shift+4+Space录制•录制gif动画LICEcap•录制Flash动画Jing缺陷分析•缺陷分析–在整个测试工作的及时总结，不仅可以调整测试的重点，而且会大大提高测试工作的效率。因为测试工作的效果要直接依赖测试用例的设计与执行状况，所以在测试过程中和测试结束后都要对测试用例的一些重要结果进行度量。缺陷分析•缺陷主要分析重点–设计了多少测试用例，实际执行了多少？–有多少测试用例执行失败？–在失败的测试用例中，有多少个错误得到修改后最终运行成功？–测试用例执行的时间比计划用例是长还是短，主要原因是什么？缺陷分析•缺陷主要分析重点–测试过程中有多少高优先级和高严重级错误，有多少已解决，多少未解决，未解决的问题如何进行处理–对于影响性能的重要问题是否都已解决？–在执行测试用例中，有多少是跳过未执行？–那些模块出现错误比较多，而且还非常严重–有多少问题是因为开发人员修改后引出的问题缺陷分析•缺陷与时间关系图缺陷分析•缺陷与版本关系图缺陷分析•缺陷与设计类型关系图缺陷分析•缺陷与优先级关系图缺陷分析•缺陷与模块关系图缺陷分析•缺陷与状态关系图缺陷分析•缺陷与错误类型关系图缺陷分析•测试各阶段与严重级别关系图缺陷分析总结报告•缺陷分析总结报告包含以下内容：–测试各阶段的缺陷分布–测试中发现的Bug数量–Bug的优先级/严重性分布–缺陷类型分析–存在的风险缺陷分析总结报告•缺陷分析总结报告包含以下内容：–测试中已解决问题统计–未解决问题的处理方式–测试结论（即通过与否）–测试总结与分析–………测试总结报告•测试总结报告是测试计划的扩展IEEE829——1998软件测试文档编制标准软件测试文档模板目录1．测试总结报告标识符2．总结3．差异4．综合评估5．结果评估5.1已解决的意外事件5.2未解决的意外事件6．评价7．建议8．活动总结9．审批测试总结报告•缺陷报告应遵循的原则–尽快报告软件缺陷；–操作步骤简单，描述清晰、专业、完整；–明确指明缺陷的类型；–问题单一；–跟踪缺陷的最新状态；–对有争议的缺陷要及时沟通；项目总结报告•项目总结报告–详细项目总结报告请参见附页《项目总结报告》表。TestDirector•TD的管理流程TestDirector•TestDirector工作原理TestDirector-Requirement•需求规范流程确定测试范围建立需求详细需求信息需求分析TestDirector-Requirement需求菜单栏文档视图需求工具栏需求树TestDirector-TestPlan•测试计划流程定义测试策略定义测试对象设计测试步骤创建需求覆盖定义测试自动测试分析测试计划TestDirector-TestPlan测试计划菜单栏测试计划工具栏测试计划树TestDirector-TestPlan•引入自动测试化–1．对于版本的每次更新版本需重新测试时；–2．同一操作使用多个数据值的测试；–3．压力测试和负载测试；–4．对于项目周期较长，功能强大的软件产品也应引入自动化测试。TestDirector-TestLAB•测试执行流程创建TestSets运行时间表分析运行结果手动运行自动运行TestDirector-TestLAB网格筛选器测试集窗格工具栏TestDirector-TestLAB•Details（详细信息）显示测试的运行详细信息•AllRuns（所有运行）显示所有测试运行的结果•Attachments显示测试的所有附件，包括在测试计划过程中添加到测试的所有附件•Configuration显示测试运行配置信息•RunEvents显示自动测试失败规则•History显示对测试运行字段所做的更改的历史记录TestDirector-TestLAB•“Details”视图TestDirector-TestLAB–PlanDescription：显示测试的描述信息–ActualTester：实际执行测试的用户名–ExecDate（计划执行日期）：计划执行测试的日期–PlannedExecDate：计划执行测试的时间–PlannedHostName（计划主机名）：计划运行测试的计算机主机名称或IP地址–ResponsibleTester：最后执行测试的负责人–ExecTime（执行日期）：上次执行测试的日期–PlannedExecTime（执行时间）：上次执行测试的时间–Status（状态）包括：Failed、N/A、NoRun、NoCompleted、Passed。–Time（时间）：运行时间TestDirector-Defects•缺陷跟踪流程添加缺陷检查新的缺陷修改开放的缺陷测试新的构建分析缺陷数据TestDirector-Defects•TestDirector用户权限–TDAdmin–QATester–ProjectManager–Developer–ViewTestDirector-Defects•Bug生命周期TestDirector-Defects菜单栏工具栏筛选器网格注释记录TestDirector-Defects•添加缺陷–在缺陷管理页面中选择菜单栏“Defect”—“Adddefect”TestDirector-Defects•TM管理流程JIAR简介JIRA的优势JIRA创建问题JIRA创建问题JIRA解决问题JIAR解决问题Bugzilla简介•Bugzilla是Mozilla公司为用户提供的一个免费开源的缺陷•跟踪工具，其创始人是TerryWeissman.•简称：DefectTrackingSystemBugzilla的优点•基于Web形式,安装配置简单•开源软件、免费•跨平台运行（Windows、Linux、Unix）•邮件服务绑定Bug状态变更•强大的搜索功能•版本向下兼容Bugzilla创建BUGBUG处理状态•Fixed:开发人员已将Bug解决•INVALID:Bug描述错误或不是Bug•WONTFIX:Bug永远不被修复，即无法修改•LATER:Bug在当前版本中将暂不解决•DUPLICATE:Bug出现重复•WORKSFORME:Bug暂时无法重现，仅作备案用BUG严重性•Blocker:指严重影响开发/测试工作的缺陷•Critical:指死机、数据丢失、内存溢出等缺陷•Major:指比较严重的功能缺陷•Normal:指普通的功能缺陷•Minor:指影响较小的功能缺陷•Trivial:指界面外观、字体等影响较小的问题•Enhancement:指提出的一些个人建议，此类问题一般不处理BUG优先级•P1:指Bug状态为Blocker、Critical•P2:指Bug状态为Major•P3:指Bug状态为Normal•P4:指Bug状态为Minor、Trivial•P5:指Bug状态为EnhancementBug管理工具•Bug管理工具–开源测试工具Bugzilla–Mercury公司TestDirector–IBM公司ClearQuest–Compuware公司QAdirector–BugFree–JIRA–……….总结•缺陷的跟踪与管理•缺陷优先级/严重性的划分•缺陷管理工具应用•缺陷的状态跟踪•缺陷的处理流程1.什么是软件缺陷?2.软件缺陷的生命周期及常见状态?3.如何做好软件缺陷的总结与分析?