缺陷管理工具jira从入门到精通.ppt

单击以编辑,母版标题样式,单击以编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件工程,教学,*,软件测试培训,-,缺陷管理,1,缺陷管理,软件测试的根本目的是什么,?,在于,检验它是否满足规定的需求,或是弄清预期结果与实际结果之间的差别,缺陷管理,软件测试中经常使用各种术语来描述软件出现的问题,如下一些通用的术语,:,软件错误,(Software Error),软件缺陷,(Software Defect),软件故障,(Software fault),软件失效,(Software failure),区分这些术语很重要，它关系到测试工程师对软件失效现象与机理的深刻理解,.,由于软件内部逻辑复杂,运行环境动态变化,且不同的软件差异可能很大,因而软件失效的机理可能也有不同的表现形式,但总的来说,软件失效的机理可描述为,:,软件错误,-,软件缺陷,-,软件故障,-,软件失效,软件错误,:,在可以遇见的时期内,软件将有人来开发,.,在整个生存期的各个阶段,都贯穿 着人的直接或间接的干预,.,然而人难免犯错误,这必然给软件留下不良的痕迹,.,软件错误是指在软件生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生,.,可见,软件错误是一种人为过程,相对于软件本身,是一种外部行为,.,软件缺陷,:,软件缺陷是存在于软件,(,文档,数据,程序,),之中的那些不希望或不可接受的偏差,.,其结果是软件运行于某一特定条件时出现软件故障,这时称软件被激活,.,软件故障,:,软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态,.,比如,:,软件处于执行一个多余循还过程时,我们可以软件出现故障,.,若此时没有适当的措施,(,容错,),加以处理,便产生软件失效,.,软件故障是一种动态行为,.,软件失效,:,软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果,.,缺陷管理,缺陷管理,综上所述,软件错误是一种人为错误,.,一个软件错误必定产生一个或多个软件缺陷,.,当一个软件缺陷被激活时,便产生一个软件故障,;,同一个软件缺陷在不同条件下被激活,可能产生不同的软件故障,.,软件故障如果没有及时容错措施加以处理,便不可避免地导致软件失效,.,缺陷管理,缺陷管理,-,目的,缺陷管理目的,:,缺陷管理目的是对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准。主要实现以下目标：,及时了解并跟踪每个被发现的缺陷；,确保每个被发现的缺陷都能被处理；,收集缺陷数据并根据缺陷趋势曲线识别测试过程阶段；,收集缺陷数据并在其上进行数据分析，作为组织过程的财富。,缺陷管理,-,人员职责,参与缺陷管理过程人员角色职责,:,项目经理（,PM,）,负责指派缺陷给相关责任人,.,项目测试负责人（,TM,）,:,决定缺陷管理方式和工具，拟定决策评审计划；,管理所有缺陷关闭情况；,审核测试人员提交的缺陷；,对测试人员的工作质量进行跟踪与评价。,测试人员（,TE,）,负责报告系统缺陷记录，且协助项目人员进行缺陷定位；,负责验证缺陷修复情况，且填写缺陷记录中相应信息；,负责执行系统回归测试；,提交缺陷报告；,负责被测软件进行质量数据和分析。,项目相关开发人员（,DE,）,修改测试发现的缺陷，并提交成果物做再测试；,负责接收各自的缺陷记录，并且修改；,负责提供缺陷记录跟踪中其它相应信息。,质量保证人员（,SQA,）,监控项目组缺陷管理规程执行情况。,缺陷管理,-,流程图,缺陷管理,-,过程介绍,缺陷登记,:,缺陷审批,:,是否缺陷：,缺陷分派：,修复缺陷：,缺陷回归测试：,缺陷管理,-,缺陷来源介绍,缺陷来源,描述,缩写,Cause-Requirement,由于需求的问题引起的缺陷,C-R,Cause,Design,由于设计的问题引起的缺陷,C-D,Cause,Code,由于编码的问题引起的缺陷,C-C,Cause,Test,由于测试的问题引起的缺陷（测试用例设计问题等）,C-T,Cause,Integration&Other,由于集成或其它问题引起的缺陷,C-I&O,缺陷管理,-,缺陷相关属性,缺陷属性,描述,缺陷描叙（,Summary,）,简单描述缺陷，主要是什么缺陷,缺陷发现提交者（,Detected By,）,描叙缺陷是由谁发现提出的。,缺陷发现时间（,Detected on Date,）,描叙缺陷发现提出时间。,缺陷严重性（,Severity,）,描述缺陷的严重性。,缺陷分给谁（,Assigned to,）,指缺陷分派给谁。,缺陷在哪个版本发现,(,Detected in Version,),描叙缺陷发现的版本,缺陷被修改的时间（,Modified,）,描叙缺陷被修改的时间。,计划修复时间（,Plan fixed Data,）,描叙缺陷计划完成修复的时间。,缺陷优先级（,priority,）,描述缺陷的优先级。,缺陷所属项目（,Project,）,描述缺陷所属的工程。,是否是重现缺陷,(,Reproducible,),描述缺陷是否是重现缺陷。,缺陷的状态,(,Status,),描述缺陷的状态,缺陷所属于的模块（,subject,）,描述缺陷所属的模块。,缺陷详细描述（,Description,）,缺陷详细描述，包括缺陷产生的步骤，缺陷的实际结果，缺陷的理想结果，建议等。,缺陷实际关闭的版本（,Closed in Version,）,描述缺陷实际关闭的版本。,缺陷实际修复所花的时间（,Actual Fixed Time,）,描述缺陷实际修复所花的时间,缺陷修复完成时间（,Closing Date,）,描述缺陷实际关闭的时间。,注释,(,Comments,),描叙对缺陷的注释。,附件（,Attachments,）,添加缺陷附件。,缺陷管理,-,缺陷等级定义,等级,说明,现象描述（部分例子）,优先级,A,类,致命错误,由于程序所引起的死机,非法退出；,死循环；,数据库发生死锁；,因错误操作导致的程序中断；,与数据库连接错误；,数据通讯错误；,导致测试无法继续执行。,可能影响其他模块功能。,立即处理或解决,B,类,很严重的错误,程序错误；,程序接口错误；,数据库的表、业务规则、缺省值未加完整性等约束条件；,关键功能完全不能实现；,程序运行不稳定，如出现不可继续进行操作的错误；,程序运行出现难以捕捉和不可再现的错误；,响应其他业务流程的错误。,在发现的两天内完成。,C,类,一般严重错误,操作界面错误（包括数据窗口内列名定义、含义是否一致）,打印内容、格式错误,简单的输入限制未放在前台进行控制,删除,/,退出操作未给出提示,数据库表中有过多的空字段,功能不完整，如菜单、按钮不响应,对错误没有处理信息,系统上线前必须修复完成,D,类,一般性错误,界面不规范；,辅助说明描述不清楚；,输入输出不规范；,提示窗口文字未采用行业术语；,可输入区域和只读区域没有明显的区分标志。,正常排队等待修复或方便时修复,E,类,较小错误,Tab,键跳转不正常；,窗口控件的,Z-Order,不正确；,窗口中的按钮或者控件缺少快捷字母，或快捷字母冲突；,文字表述中有错别字或歧义；,测试人员所提出的建设性意见。,方便时再修复,缺陷管理,-,缺陷修复优先级,优先级,描述,紧急（,5-Urgent,）,缺陷很紧急且很严重，得立即修复。,很高优先级,(,4-very High,),例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。,较高优先级,(,3-High,),例如，影响软件功能和性能的一般缺陷。,一般优先级,(,2-Medium,),例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷。,低优先级（,1-Low,）,例如，对软件的质量影响非常轻微或出现几率很低的缺陷。,缺陷管理,-,缺陷状态,缺陷状态,描述,新提交（,New,）,新提交的缺陷状态,激活,(,Open,),缺陷已提交，正在处理,已拒绝,(,Rejected,),拒绝,“,已提交的缺陷,”,，不需要修改或不是缺陷,已解决,(,Fixed,),缺陷已修改,重激活,(,Reopen,),缺陷修改未通过再测试，,或因其他原因造成缺陷再次打开,重复缺陷（,Duplicate,）,缺陷重复出现，已经被提交过。,已关闭,(,Closed,),确认缺陷已被修复，将其关闭,缺陷管理,-,缺陷状态转换图,缺陷管理,-,怎样专业的描述缺陷,软件缺陷的有效描述规则，主要是：,1.,单一准确每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。,2.,可以再现提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。,3.,完整统一提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，,Log,文件等。,4.,短小简练通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如,“,主页的导航栏在低分辨率下显示不整齐,”,中,“,主页,”,、,“,导航栏,”,、,“,分辨率,”,等是关键词。,5.,特定条件许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如,“,搜索功能在没有找到结果返回时跳转页面不对,”,。,6.,补充完善从发现,bug,那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。,7.,不做评价在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。,缺陷管理,-,工具介绍,Test Director Hp,公司,TM,BUGZILLIA,JIRA,基于测试流程上的缺陷管理系统,缺陷的定义,软件没有达到产品说明书表明的功能,软件出现了产品说明书中不一致的表现,软件功能超出产品说明书的范围,软件没有达到用户期望的目标,(,虽然产品说明书中没有要求,),测试员或用户认为软件的易用性差,不是所有缺陷都会修改,市场的压力使得产品最终发行有时间限制,测试员错误理解或者不正确操作引出的缺陷,(FAQ),错误的修改影响的模块较多，带来的风险较大,（遗留）,修改性价比太低,(FAQ,，,遗留）,缺陷报告中提出的问题很难重现,3.1,缺陷报告管理系统,是测试流程在工具上的固化,通过权限控制来实现流程监控,记录了缺陷识别到关闭过程中的所有数,记录了版本变更的信息,是开发和测试之间沟通的信息平台,实时的数据和信息的更新,度量和统计分析，为改进产品提供依据,测试缺陷跟踪与管理系统,采用,Lotus Notes,作为,bug,管理平台,完全电子化的信息传递,统一管理和备份,3.1.1,系统测试缺陷处理流程,新建表单,待测试提交,待指定处理人,正在处理,返回处理,待开发提交,待返测,待归档,已归档,个人提交,退回,测试提交,指定处理人,重新指定,处理完毕,返测完毕,归档,重新返测,退回,提交版本更新说明,缺陷报告,Bug,报告准则,如何重现错误,-,使用最少步骤重现,现象描述没有歧义,尽量简单,-,一个,bug,一个报告,可以提出对错误的解决建议,开发人员拒绝修改的,bug,程序员无法重现或者现象难以捕捉,没有明确的报告以说明重现,bug,的步骤,程序员无法读懂的,bug,报告,用户很少使用或者不符合用户使用习惯的操作出错,由不受信任的测试人员提出,3.1.2,集成测试缺陷处理流程,新建表单,待指定处理人,正在处理,待返测,待归档,已归档,返回处理,测试提交,指定处理人,重新指定,处理完毕,返测完毕,归档,重新返测,退回,4.1,缺陷分析的关注点：,1.,对软件问题的功能域分布进行分析，找出系统的薄弱环节,要详细采集每个功能模块或,系统构,件的,bug,数据，并按功能、错误类型、严重程度等分类,比较实际发现的软件,bug,是否与预期的问题分布相吻合,二八定理：,80%,的软件问题总是发生在大约,20%,的功能模块（系统构件）中。,缺陷分析的关注点,2,、对,bug,的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集,bug,的数据,要求软件各开发阶段的缺陷密度小于本单位过去的平均值,而且要求需求分析、设计和代码复查阶段的缺陷排除率之和大于或等于规定值（例如,75%,）。（同行评审）,缺陷分析的关注点,3,、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。,可参考,PSP,中缺陷类型标准（如下表），其中缺陷类型是按照问题的复杂度来排列的，类型,10,到,40,是比较简单的编码缺陷，类型,50,到,100,是比较复杂的设计缺陷。,类型编号,类型名称,描 述,10,文档,注释，消息,20,句法,拼写，标点，打字，指令格式,30,联编，打包,理改管理，库，版本控制,40,分配,说明，重名，作用域，限制,50,接口,过程调用和引用，输入,/,输出，用户格式,60,检查,出错信息，不恰当的检查,70,数据,结构，内容,80,函数,逻辑，指针，循环，递归，计算，函数缺陷,90,系统,配置，记时，内存,100,环境,设计，编译，测试，或其它支持系统问题,缺陷分析的关注点,4,、应动态采集每个测试周期中发现的,bug,数，并有效地控制缺陷的修复率。,5,、应密切观察,bug,的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况,缺陷分析的关注点,6,、应该采集,bug,不同方式的修复数据，以便检验软件产品是否满足交付规则,分析修改代码、改变设计、封掉功能遗留以及下一版本解决的,bug,数约占缺陷总数的比例。,在有严密和有效的质量保证体系条件的监控下，常常会引起有较高比例的延期解决的缺陷数，这是因为许多细微的或枝节性的问题被测试出来，经过评价证明不会造成大的质量影响，但可为产品进一步升级提供有价值的参考。,4.2,测试人员的绩效评价,评价标准：,1,、,bug,数量：,同一个项目组内，提交,bug,数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的,bug,数。,2,、,bug,严重程度：,Bug,的严重程度是衡量,bug,的质量的一个重要因素，好的,bug,应该是极端严重的，对系统造成极大危害的。,3,、,bug,价值：,Bug,的双方面评判，对于,bug,的价值开发人员在另外一个角度上进行评判,以上三个因素的加权平均才能更有效的评价测试人员的绩效！,4.3,缺陷统计分析工具介绍,测试结果分析和评价,缺陷密度,:,基本的缺陷测量是以每千行代码的缺陷数,(Defects/KLOC),来测量的。称为缺陷密度,(Dd),，其测量单位是,defects,KLOC,。可按照以下步骤来计算一个程序的缺陷密度：,累计开发过程中每个阶段发现的缺陷总数,(D),。,统计程序中新开发的和修改的代码行数,(N),。,计算每千行的缺陷数,Dd=1000*D/N,。,例如，一个,29.6,万行的源程序总共有,145,个缺陷，则缺陷密度是：,Dd,1000*145/296000=0.49 defects,KLOC,。,在计算缺陷密度时，最重要的是要使用正确的规模测量。,测试结果的分析和评价,输出,测试综合报告,：,测试过程的总结,测试数据分析（按照严重程度等方式分类统计的分析，包括测试密度等）,产品主要问题和总体评价,遗留的问题总结,最终的测试结论,测试结果分析和评价,为了了解和控制缺陷带来的费用，很有必要测量缺陷排除的效果测量：,一种测量方法是计算每小时排除缺陷的个数；,一种是计算缺陷排除效益，即测量通过某一排除方法所发现的缺陷的百分比。,测试结果分析和评价,测试覆盖率测量,语句覆盖率测试经历语句数,/,总语句数,分支覆盖率测试经历支路数,/,总支路数,简单路径覆盖率测试经历简单路径数,/,总简单路径数,功能覆盖率,界面数,菜单数,输入,/,输出的数据元数,构件、模块,4.5,软件测试经验分享,所有的测试都应追溯到需求。因最严重的错误是导致程序无发满足需求的错误；,软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）,;,软件开发人员应避免检查自已的程序，利用同行评审的方式对代码进行审查；,(,自己检查容易依照原有的程序设计思路进行，往往查不出问题,),在设计测试用例时，,必须明确预期的输出结果，否则对实际的输出结果很难有检验的标准，测试失去意义。,测试用例应由输入数据和与之对应的期望输出结果这两部分组成，在输入数据中，应当包括合理的输入条件和不合理的输入条件；,在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果。,软件测试经验分享,统计表明大约有,60%,的错误是在设计阶段之前注入的，并且修正一个软件错误所需的费用将随着软件生存期的进展而上升。错误发现得越晚，修复它的费用就越高，而且呈指数增长的趋势。,测试后程序中残存的错误数目与该程序中已发现的错误数目（即检错率）很可能成正比；,(,编码规范、需求理解、技术能力、内部耦合性是引起这些现象的原因,),程序中的大部分错误往往是在一小部分模块中发现的，遵循普遍适用的“二八定理”（即,80%,的错误往往是由,20%,的模块所造成的），例如，,IBM,公司的,OS/370,操作系统中，,47%,的错误仅与该系统中的,4%,的程序模块有关；,要严格执行测试计划，排除测试的随意性，这样才能消除各种无序操作所造成的副作用；,测试设计决定了测试的有效性和效率，测试工具只能提高测试效率,应当对每一个测试结果做全面的检查，这样才有可能找到真正的出错原因，为今后的调试工作奠定基础。,结束语,产品越复杂，测试花费的时间就越长，费用就越大，测试发现缺陷的效率也就越低。,缺陷会掩盖或加重其它缺陷。也就是说，当一个程序有许多缺陷时，由于缺陷相互作用，使得发现和修复缺陷的过程更加复杂。这使得一些缺陷很难查找和修复。一个缺陷可能掩盖其它缺陷，使得这些被掩盖的缺陷难以发现，增加了它们逃过测试的可能性。,遵照规范化的方法，仔细复查和测试每个小程序模块，这比让任何测试组在你的程序中发现缺陷的效果要好。也就是说，尽早的将缺陷排除掉。测试不能避免缺陷的发生，只能是一种补救。,你是唯一能做到生产出无缺陷程序的人，其他任何人都无法帮你做到这一点,。,