缺陷管理工具jira从入门到精通课件

软件测试培训--缺陷管理1软件测试培训1缺陷管理软件测试的根本目的是什么?在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别缺陷管理在于检验它是否满足规定的需求缺陷管理软件测试中经常使用各种术语来描述软件出现的问题,如下一些通用的术语:软件错误(SoftwareError)软件缺陷(SoftwareDefect)软件故障(Softwarefault)软件失效(Softwarefailure)区分这些术语很重要，它关系到测试工程师对软件失效现象与机理的深刻理解.由于软件内部逻辑复杂,运行环境动态变化,且不同的软件差异可能很大,因而软件失效的机理可能也有不同的表现形式,但总的来说,软件失效的机理可描述为:软件错误->软件缺陷->软件故障->软件失效缺陷管理软件测试中经常使用各种术语来描述软件出现的问题,如下软件错误:在可以遇见的时期内,软件将有人来开发.在整个生存期的各个阶段,都贯穿着人的直接或间接的干预.然而人难免犯错误,这必然给软件留下不良的痕迹.软件错误是指在软件生存期内的不希望或不可接受的人为错误,其结果是导致软件缺陷的产生.可见,软件错误是一种人为过程,相对于软件本身,是一种外部行为.软件缺陷:软件缺陷是存在于软件(文档,数据,程序)之中的那些不希望或不可接受的偏差.其结果是软件运行于某一特定条件时出现软件故障,这时称软件被激活.软件故障:软件故障是指软件运行过程中出现的一种不希望或不可接受的内部状态.比如:软件处于执行一个多余循还过程时,我们可以软件出现故障.若此时没有适当的措施(容错)加以处理,便产生软件失效.软件故障是一种动态行为.软件失效:软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果.缺陷管理软件错误:在可以遇见的时期内,软件将有人来开发.在整个生存期缺陷管理

综上所述,软件错误是一种人为错误.一个软件错误必定产生一个或多个软件缺陷.当一个软件缺陷被激活时,便产生一个软件故障;同一个软件缺陷在不同条件下被激活,可能产生不同的软件故障.软件故障如果没有及时容错措施加以处理,便不可避免地导致软件失效.缺陷管理综上所述,软件错误是一种人为错误.一个软件错误必缺陷管理缺陷管理缺陷管理-目的缺陷管理目的:缺陷管理目的是对各阶段测试发现的缺陷进行跟踪管理，以保证各级缺陷的修复率达到标准。主要实现以下目标：及时了解并跟踪每个被发现的缺陷；确保每个被发现的缺陷都能被处理；收集缺陷数据并根据缺陷趋势曲线识别测试过程阶段；收集缺陷数据并在其上进行数据分析，作为组织过程的财富。缺陷管理-目的缺陷管理目的:缺陷管理-人员职责参与缺陷管理过程人员角色职责:项目经理（PM）负责指派缺陷给相关责任人.项目测试负责人（TM）:决定缺陷管理方式和工具，拟定决策评审计划；管理所有缺陷关闭情况；审核测试人员提交的缺陷；对测试人员的工作质量进行跟踪与评价。测试人员（TE）负责报告系统缺陷记录，且协助项目人员进行缺陷定位；负责验证缺陷修复情况，且填写缺陷记录中相应信息；负责执行系统回归测试；提交缺陷报告；负责被测软件进行质量数据和分析。项目相关开发人员（DE）修改测试发现的缺陷，并提交成果物做再测试；负责接收各自的缺陷记录，并且修改；负责提供缺陷记录跟踪中其它相应信息。质量保证人员（SQA）监控项目组缺陷管理规程执行情况。缺陷管理-人员职责参与缺陷管理过程人员角色职责:缺陷管理-流程图缺陷管理-流程图缺陷管理-过程介绍缺陷登记:缺陷审批:是否缺陷：缺陷分派：修复缺陷：缺陷回归测试：缺陷管理-过程介绍缺陷登记:缺陷管理-缺陷来源介绍缺陷来源

描述

缩写Cause-Requirement 由于需求的问题引起的缺陷 C-RCause–Design 由于设计的问题引起的缺陷 C-DCause–Code 由于编码的问题引起的缺陷 C-CCause–Test 由于测试的问题引起的缺陷（测试用例设计问题等）C-TCause–Integration&Other 由于集成或其它问题引起的缺陷 C-I&O缺陷管理-缺陷来源介绍缺陷来源缺陷管理-缺陷相关属性缺陷属性描述缺陷描叙（Summary）简单描述缺陷，主要是什么缺陷缺陷发现提交者（DetectedBy）描叙缺陷是由谁发现提出的。缺陷发现时间（DetectedonDate）描叙缺陷发现提出时间。缺陷严重性（Severity）描述缺陷的严重性。缺陷分给谁（Assignedto）指缺陷分派给谁。缺陷在哪个版本发现(DetectedinVersion)描叙缺陷发现的版本缺陷被修改的时间（Modified）描叙缺陷被修改的时间。计划修复时间（PlanfixedData）描叙缺陷计划完成修复的时间。缺陷优先级（priority）描述缺陷的优先级。缺陷所属项目（Project）描述缺陷所属的工程。是否是重现缺陷(Reproducible)描述缺陷是否是重现缺陷。缺陷的状态(Status)描述缺陷的状态缺陷所属于的模块（subject）描述缺陷所属的模块。缺陷详细描述（Description）缺陷详细描述，包括缺陷产生的步骤，缺陷的实际结果，缺陷的理想结果，建议等。缺陷实际关闭的版本（ClosedinVersion）描述缺陷实际关闭的版本。缺陷实际修复所花的时间（ActualFixedTime）描述缺陷实际修复所花的时间缺陷修复完成时间（ClosingDate）描述缺陷实际关闭的时间。注释(Comments)描叙对缺陷的注释。附件（Attachments）添加缺陷附件。缺陷管理-缺陷相关属性缺陷属性描述缺陷描叙（Summary）缺陷管理-缺陷等级定义等级说明现象描述（部分例子）优先级A类致命错误由于程序所引起的死机,非法退出；死循环；数据库发生死锁；因错误操作导致的程序中断；与数据库连接错误；数据通讯错误；导致测试无法继续执行。可能影响其他模块功能。立即处理或解决B类很严重的错误程序错误；程序接口错误；数据库的表、业务规则、缺省值未加完整性等约束条件；关键功能完全不能实现；程序运行不稳定，如出现不可继续进行操作的错误；程序运行出现难以捕捉和不可再现的错误；响应其他业务流程的错误。在发现的两天内完成。C类一般严重错误操作界面错误（包括数据窗口内列名定义、含义是否一致）打印内容、格式错误简单的输入限制未放在前台进行控制删除/退出操作未给出提示数据库表中有过多的空字段功能不完整，如菜单、按钮不响应对错误没有处理信息系统上线前必须修复完成D类一般性错误界面不规范；辅助说明描述不清楚；输入输出不规范；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分标志。正常排队等待修复或方便时修复E类较小错误Tab键跳转不正常；窗口控件的Z-Order不正确；；窗口中的按钮或者控件缺少快捷字母，或快捷字母冲突；文字表述中有错别字或歧义；测试人员所提出的建设性意见。方便时再修复缺陷管理-缺陷等级定义等级说明现象描述（部分例子）优先级A类缺陷管理-缺陷修复优先级优先级描述紧急（5-Urgent）缺陷很紧急且很严重，得立即修复。很高优先级(4-veryHigh)例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。较高优先级(3-High)例如，影响软件功能和性能的一般缺陷。一般优先级(2-Medium)例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷。低优先级（1-Low）例如，对软件的质量影响非常轻微或出现几率很低的缺陷。缺陷管理-缺陷修复优先级优先级描述紧急（5-Urgent）缺缺陷管理-缺陷状态缺陷状态描述新提交（New）新提交的缺陷状态激活(Open)缺陷已提交，正在处理已拒绝(Rejected)拒绝“已提交的缺陷”，不需要修改或不是缺陷已解决(Fixed)缺陷已修改重激活(Reopen)缺陷修改未通过再测试，或因其他原因造成缺陷再次打开重复缺陷（Duplicate）缺陷重复出现，已经被提交过。已关闭(Closed)确认缺陷已被修复，将其关闭缺陷管理-缺陷状态缺陷状态描述新提交（New）新提交的缺陷状缺陷管理-缺陷状态转换图缺陷管理-缺陷状态转换图缺陷管理-怎样专业的描述缺陷软件缺陷的有效描述规则，主要是：

1.单一准确

每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。

2.可以再现

提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。

3.完整统一

提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。

4.短小简练

通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。

5.特定条件

许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。

6.补充完善

从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。

7.不做评价

在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。缺陷管理-怎样专业的描述缺陷软件缺陷的有效描述规则，主要是：缺陷管理-工具介绍TestDirectorHp公司TMBUGZILLIAJIRA缺陷管理-工具介绍TestDirectorHp公司基于测试流程上的缺陷管理系统缺陷的定义软件没有达到产品说明书表明的功能软件出现了产品说明书中不一致的表现软件功能超出产品说明书的范围软件没有达到用户期望的目标(虽然产品说明书中没有要求)测试员或用户认为软件的易用性差不是所有缺陷都会修改市场的压力使得产品最终发行有时间限制测试员错误理解或者不正确操作引出的缺陷(FAQ)错误的修改影响的模块较多，带来的风险较大（遗留）修改性价比太低(FAQ，遗留）缺陷报告中提出的问题很难重现基于测试流程上的缺陷管理系统3.1缺陷报告管理系统是测试流程在工具上的固化通过权限控制来实现流程监控记录了缺陷识别到关闭过程中的所有数记录了版本变更的信息是开发和测试之间沟通的信息平台实时的数据和信息的更新度量和统计分析，为改进产品提供依据3.1缺陷报告管理系统是测试流程在工具上的固化测试缺陷跟踪与管理系统采用LotusNotes作为bug管理平台完全电子化的信息传递统一管理和备份测试缺陷跟踪与管理系统采用LotusNotes作为bug管3.1.1系统测试缺陷处理流程新建表单待测试提交待指定处理人正在处理返回处理待开发提交待返测待归档已归档个人提交退回测试提交指定处理人重新指定处理完毕返测完毕归档重新返测退回提交版本更新说明3.1.1系统测试缺陷处理流程新建表单待测试提交待指缺陷报告Bug报告准则如何重现错误-使用最少步骤重现现象描述没有歧义尽量简单-一个bug一个报告可以提出对错误的解决建议开发人员拒绝修改的bug程序员无法重现或者现象难以捕捉没有明确的报告以说明重现bug的步骤程序员无法读懂的bug报告用户很少使用或者不符合用户使用习惯的操作出错由不受信任的测试人员提出缺陷报告Bug报告准则3.1.2集成测试缺陷处理流程新建表单待指定处理人正在处理待返测待归档已归档返回处理测试提交指定处理人重新指定处理完毕返测完毕归档重新返测退回3.1.2集成测试缺陷处理流程新建表单待指定处理人4.1缺陷分析的关注点：1.对软件问题的功能域分布进行分析，找出系统的薄弱环节要详细采集每个功能模块或系统构件的bug数据，并按功能、错误类型、严重程度等分类比较实际发现的软件bug是否与预期的问题分布相吻合二八定理：80%的软件问题总是发生在大约20%的功能模块（系统构件）中。4.1缺陷分析的关注点：1.对软件问题的功能域分布进行分析缺陷分析的关注点2、对bug的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集bug的数据要求软件各开发阶段的缺陷密度小于本单位过去的平均值而且要求需求分析、设计和代码复查阶段的缺陷排除率之和大于或等于规定值（例如75%）。（同行评审）缺陷分析的关注点2、对bug的注入阶段的分布进行分析，并与历缺陷分析的关注点3、应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。可参考PSP中缺陷类型标准（如下表），其中缺陷类型是按照问题的复杂度来排列的，类型10到40是比较简单的编码缺陷，类型50到100是比较复杂的设计缺陷。类型编号类型名称描述10文档注释，消息20句法拼写，标点，打字，指令格式30联编，打包理改管理，库，版本控制40分配说明，重名，作用域，限制50接口过程调用和引用，输入/输出，用户格式60检查出错信息，不恰当的检查70数据结构，内容80函数逻辑，指针，循环，递归，计算，函数缺陷90系统配置，记时，内存100环境设计，编译，测试，或其它支持系统问题缺陷分析的关注点3、应对软件缺陷类型进行分析，以便针对各自的缺陷分析的关注点4、应动态采集每个测试周期中发现的bug数，并有效地控制缺陷的修复率。5、应密切观察bug的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况缺陷分析的关注点4、应动态采集每个测试周期中发现的bug数，缺陷分析的关注点6、应该采集bug不同方式的修复数据，以便检验软件产品是否满足交付规则分析修改代码、改变设计、封掉功能遗留以及下一版本解决的bug数约占缺陷总数的比例。在有严密和有效的质量保证体系条件的监控下，常常会引起有较高比例的延期解决的缺陷数，这是因为许多细微的或枝节性的问题被测试出来，经过评价证明不会造成大的质量影响，但可为产品进一步升级提供有价值的参考。缺陷分析的关注点6、应该采集bug不同方式的修复数据，以便检4.2测试人员的绩效评价评价标准：1、bug数量：同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。2、bug严重程度：Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。3、bug价值：Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判以上三个因素的加权平均才能更有效的评价测试人员的绩效！4.2测试人员的绩效评价评价标准：4.3缺陷统计分析工具介绍4.3缺陷统计分析工具介绍测试结果分析和评价缺陷密度:

基本的缺陷测量是以每千行代码的缺陷数(Defects/KLOC)来测量的。称为缺陷密度(Dd)，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：累计开发过程中每个阶段发现的缺陷总数(D)。统计程序中新开发的和修改的代码行数(N)。计算每千行的缺陷数Dd=1000*D/N。例如，一个29.6万行的源程序总共有145个缺陷，则缺陷密度是：Dd＝1000*145/296000=0.49defects／KLOC。在计算缺陷密度时，最重要的是要使用正确的规模测量。测试结果分析和评价缺陷密度:测试结果的分析和评价输出《测试综合报告》：测试过程的总结测试数据分析（按照严重程度等方式分类统计的分析，包括测试密度等）产品主要问题和总体评价遗留的问题总结最终的测试结论测试结果的分析和评价输出《测试综合报告》：测试结果分析和评价为了了解和控制缺陷带来的费用，很有必要测量缺陷排除的效果测量：一种测量方法是计算每小时排除缺陷的个数；一种是计算缺陷排除效益，即测量通过某一排除方法所发现的缺陷的百分比。测试结果分析和评价为了了解和控制缺陷带来的费用，很有必要测量测试结果分析和评价测试覆盖率测量语句覆盖率 测试经历语句数/总语句数分支覆盖率 测试经历支路数/总支路数简单路径覆盖率 测试经历简单路径数/总简单路径数功能覆盖率 界面数菜单数输入/输出的数据元数构件、模块…测试结果分析和评价测试覆盖率测量4.5软件测试经验分享所有的测试都应追溯到需求。因最严重的错误是导致程序无发满足需求的错误；软件开发人员和管理人员首先应该尽早地和不断地进行各种软件质量保证活动（如需求和设计阶段同行评审和走查等）;软件开发人员应避免检查自已的程序，利用同行评审的方式对代码进行审查；(自己检查容易依照原有的程序设计思路进行，往往查不出问题)在设计测试用例时，必须明确预期的输出结果，否则对实际的输出结果很难有检验的标准，测试失去意义。测试