《缺陷管理》ppt课件

1、第6章 缺陷管理本课教学目的 了解缺陷的严重级和优先级分类 正确了解缺陷跟踪管理流程 了解缺陷管理流程的要点 正确了解缺陷数据分析的重要性课程内容 6.1 软件缺陷概念回想 6.2 缺陷的严重性和优先级 6.3 缺陷跟踪管理 6.4 缺陷书写规范 6.5 缺陷数据分析 6.1 软件缺陷概念回想软件缺陷的定义：1软件未到达产品阐明书中曾经标明的功能； 2软件出现了产品阐明书中指明不会出现的错误； 3软件未到达产品阐明书中虽未指出但该当到达的目的； 4软件功能超出了产品阐明书中指明的范围； 5软件测试人员以为软件难以了解、不易运用，或者最终用户以为该软件运用效果不良。软件缺陷概念回想续软件缺陷的特

2、征： “看不到 软件的特殊性决议了缺陷不易看到“看到但是抓不到 发现了缺陷，但不易找到问题发生的缘由所在软件缺陷概念回想续其他其他10%软件产品阐明软件产品阐明书需求书需求56%编写代码编写代码7%设 计设 计27%缺陷分布情况： 6.2 软件缺陷严重性和优先级重要软件缺陷会导致艰苦经济损失与灾难测试员应对软件缺陷分类，以简明扼要的方式指出其影响，以及修正次序划分软件缺陷严重级和优先级的通用原那么表示软件缺陷所呵斥的危害的恶劣程度优先级表示修复缺陷的重要程度与次序 软件缺陷严重性和优先级续严重级严重：系统解体、数据丧失、数据损坏较严重：操作性错误、错误结果、脱漏功能普通：小问题、错别字、UI规

3、划、稀有缺点建议：不影响运用的瑕疵或更好的实现 软件缺陷严重性和优先级续优先级最高优先级：立刻修复，停顿进一步测试次高优先级：在产品发布之前必需修复中等优先级：假设时间允许应该修复最低等优先级：能够会修复，不修复也能发布普通严重性和优先级的划分用数字表示，有的小数字表示的级别最高，而有的用大数字表示级别高。另外严重级和优先级的划分并不独一 ，可适当修正缺陷等级划分 SZSTC 等级等级描画描画阐明阐明测试特性测试特性5-致命系统死机系统、环境及运用解体死机。可靠性数据损坏软件发生缺点数据毁坏或丧失。可靠性功能失效软件发生缺点导致功能失效。可靠性异常退出软件发生缺点异常退出。可靠性4-非常高功能

4、短少用户需求未实现。功能性功能错误实践提供功能与用户需求不一致。流程或接口中，数据未做关联。功能性计算错误结果计算错误。功能性精度错误精度与用户需求不一致。功能性交互错误与其他软件或系统交换数据出错，包括导出文件后内容丧失。功能性性能缺陷未到达需求阐明书中所规定的性能目的，例如呼应时间过长。效率3-高控制错误输入未控制和未判别导致功能异常、信息缺失，或界面显示、提示信息异常等；如必输项、反复、数据约束、数据长度；删除未确认；屏蔽断定；正常逻辑错误。可靠性2-普通显示错误界面显示错误，页面刷新问题，提示信息不准确，错别字，打印内容格式错误。可修正字段与不可修正字段中字体颜色标示未区别；易用性不易

5、操作界面风格不一致，术语不一致，对话框颜色不一致，按钮大小不一致，提示信息不一致；未运用默许值，默许值运用不便或不正确。易用性1-低建议意见需求阐明书、用户手册中未阐明，但影响用户对软件运用的方便性等。易用性 6. 软件缺陷跟踪管理6.3.1 缺陷跟踪管理目的6.3.2 缺陷跟踪管理6.3.3 软件缺陷的形状6.3.4 缺陷管理流程6.3.5 缺陷流程管理原那么 6.3.1 缺陷跟踪管理目的确保每个被发现的缺陷都可以被处理 修正或其他处置方式搜集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段 搜集缺陷数据并在其上进展数据分析，作为组织的过程财富 6.3.2 缺陷跟踪管理为了正确跟踪每个软件缺陷的

6、处置过程，通常将软件测试发现的每个错误作为一条条记录输入指定的错误跟踪管理系统 目前的缺陷跟踪管理软件包括：ClearQuest (IBM)TestDirector (Mercury Interative)Bugzilla缺陷跟踪管理续作为一个缺陷跟踪管理系统，需求正确的记录错误信息和错误处置信息的全部内容 Bug记录信息测试软件称号测试版本号测试人称号测试用例标题测试软件和硬件配置环境发现软件错误的类型错误严重等级详细步骤必要的附图发生错误的模块Bug处置信息 处置者姓名处置时间处置步骤缺陷记录的当前形状 软件缺陷的主要形状包括以下的内容新建(New)：测试中新报告的软件缺陷； 翻开 (Op

7、en)： 被确认并分配给相关开发人员处置；修正(Fixed)： 开发人员已完成修正，等待测试人员验证； 回绝(Declined)：回绝修正缺陷；延期(Deferred)： 不在当前版本修复的错误，下一版修复 封锁(Closed)：错误已被修复。 6.3.3 软件缺陷形状测试人员提交新发现的缺堕入库，缺陷形状为“New高级测试人员验证错误假设确认是错误，那么分配给相应的开发人员，设置形状为“Open假设不是错误，那么回绝，设置为“Declined形状开发人员查询形状为“Open的缺陷，对其进展处置假设不是错误，那么形状置为“Declined假设是错误，那么修复并置形状为“Fix假设不能处理，要留

8、下文字阐明并坚持缺陷形状仍为“Open对于不能处理或者延期处理的缺陷，不能由开发人员本人决议，普通要经过某种会议评审会才干认可测试人员查询形状为“Fix的缺陷，验证缺陷能否已处理，做如下处置假设问题处理了，置缺陷的形状为“Closed假设问题没有结果，那么置形状为“Reopen 6.3.4 缺陷管理流程OpenResolvedVerifiedClosedClose 缺陷评审委员会Reopen测试人员Resolve程序员Verify测试工程师Close测试工程师Reopen测试人员缺陷流程管理应遵照以下原那么为了保证错误的正确性，需求有丰富测试阅历的测试人员验证发现的错误能否是真正的错误，书写的

9、测试步骤能否准确，可以重现。每次对错误的处置都要保管处置信息，包括处置姓名，时间，处置方法，处置意见，Bug 形状。回绝或延期错误不能由程序员一方面决议，应该由工程经理，测试经理和设计经理共同决议。错误修复后必需由报告错误的测试人员验证后，确认曾经修复，才干封锁错误。加强测试人员与程序员的交流，对于某些不能重现的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。 6.3.5 缺陷管理流程要点6.4 缺陷书写规范一标题：应坚持简短、准确，提供缺陷的本质信息尽量按缺陷发生的缘由与结果的方式书写；防止运用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用等。应该运用详细文字阐

10、明缺陷的病症；为了便于他人了解，防止运用术语、俚语或过分详细的测试细节。复现步骤：应包含如何使他人可以很容易的复现该缺陷的完好步骤。为了到达这个要求，复现步骤的信息必需是完好的、准确的、简明的、可复现的。常见问题：包含了过多的多余步骤，且句子构造混乱，可读性差，难以了解；包含的信息过少，丧失了操作的必要步骤；没有对软件缺陷发生的条件和影响区域进展隔离。复现步骤的正确书写方式：提供测试的环境信息；简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；每个步骤前运用数字对步骤编号；尽量运用短语或短句，防止复杂句型句式；复现的步骤要完好、准确、简短；将常见步骤合并为较少步骤；按实践需求决议能否包含步

11、骤执行后的结果。实践结果：是执行复现步骤后软件的景象和产生的行为。 实践结果的描画应向标题信息那样，要列出详细的缺陷病症，而不是简单地指出“不正确或“不起作用。6.4 缺陷书写规范二期望结果：描画应与实践结果的描画方式一样。通常需求列出期望的结果是什么。附件：对缺陷描画的补充阐明，可以是以下一些类型：缺陷病症的截图；测试运用的数据文件；缺陷交流的记录，例如相关邮件等；处理缺陷的补丁程序其它：选择适宜的缺陷严重性属性；按相应的规定，填写相应的字段信息6.4 缺陷书写规范三防止常见的错误：防止运用我、他等人称代词，可以直接运用动词或必要时运用“用户替代防止运用心情化的言语和强调符号；防止运用诸如“

12、似乎、“看上去能够等含义模糊的词汇，而需求报告确定的缺陷结果；防止运用自以为比较幽默的语句，只需客观地描画缺陷的信息；防止提交不确定的测试问题，本人至少需求重现一次再提交。6.4 缺陷书写规范四上海人：哪能查询到的结果和查询条件不搭噶的。北京人：哥们好不容易输入一堆个人详细信息后，点击保管后全瞎了。问题与讨论 请指出下面这个缺陷的缺乏之处6.5 缺陷数据分析6.5.1 缺陷数据分析关注的问题6.5.2 缺陷数据分析的重要性6.5.3 缺陷数据分析的数据目的6.5.1 缺陷数据分析关注的问题 正在测试的软件哪个模块的问题最多？ 测试人员中谁报告的软件缺陷最多？ 各类缺陷所占的数量百分比分别是多少

13、？ 开发人员能及时修复软件缺陷吗？ 开发人员一次正确修复缺陷的百分比是多少？ 正在开发的软件能否在方案的时间内正常发布？ 。6.5.2 缺陷数据分析的重要性 统计未修复的缺陷数目特别是严重性高的缺陷，估计软件能否可以如期发布。 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出缘由，进展软件开发过程改良。 根据测试人员报告缺陷的数量和准确性，评价测试有效性和测试技艺。 根据报告的缺陷修复能否及时，改良软件开发与测试的关系，使测试与开发更有机的配合。6.5.3 缺陷数据分析的数据目的 每天/周报告的新缺陷数目； 每天/周修复的缺陷数； 累计报告的缺陷数目； 累计修复的缺陷数； 不同严重性类型的

14、缺陷数； 程序模块与发现的缺陷的对应关系； 。6.5.4 不同软件组织的缺陷管理过程个体行为个体行为处于处于CMM第一级或称为初始级的软件组织，对软件缺陷的第一级或称为初始级的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修正相应的软件。管理无章可循。工程师们只是在发现缺陷后，修正相应的软件。通常，没有人会去记录本人发现的缺陷。也没有人知道在新的软通常，没有人会去记录本人发现的缺陷。也没有人知道在新的软件版本里，终究纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，件版本里，终究纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只需在下一轮测试中才有能够知道那些所谓已被纠正了的缺陷能只需在

15、下一轮测试中才有能够知道那些所谓已被纠正了的缺陷能否真的被纠正了，更重要的是纠正过程能否引入了新的缺陷。否真的被纠正了，更重要的是纠正过程能否引入了新的缺陷。所以这样的软件组织的工程交货期所以这样的软件组织的工程交货期Release Date表现出剧烈表现出剧烈的不可预测性。并且，的不可预测性。并且， 为了获得一个高质量的软件产品假设可为了获得一个高质量的软件产品假设可以的话，通常要在测试上破费大量的人力。以的话，通常要在测试上破费大量的人力。 6.5.4 不同软件组织的缺陷管理过程(续)工程行为工程行为在在CMM第二级或称为可反复级的软件组织中，软件工程会第二级或称为可反复级的软件组织中，软

16、件工程会从本身的需求出发，制定本工程的缺陷管理过程。一个完备软件从本身的需求出发，制定本工程的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：缺陷管理过程通常会包括如下几个方面：1提交缺陷提交缺陷2分析和定位缺陷分析和定位缺陷3提请修正相应的软件提请修正相应的软件4修正相应的软件修正相应的软件5验证修正验证修正工程组会完好地记录开发过程中的缺陷，监控缺陷的修正正程，工程组会完好地记录开发过程中的缺陷，监控缺陷的修正正程，并验证修正缺陷的结果。并验证修正缺陷的结果。6.5.4 不同软件组织的缺陷管理过程(续)组织行为组织行为CMM第三级或称为已定义级的软件组织会聚集组织内部以第三级

17、或称为已定义级的软件组织会聚集组织内部以前工程的阅历教训，制定组织级的缺陷管理过程。并且，要求工前工程的阅历教训，制定组织级的缺陷管理过程。并且，要求工程根据组织级的缺陷管理过程定制本工程的缺陷管理过程。程根据组织级的缺陷管理过程定制本工程的缺陷管理过程。从而，整个软件组织中的工程都遵照类似的过程来管理缺陷。好从而，整个软件组织中的工程都遵照类似的过程来管理缺陷。好的缺陷管理实际成为一切工程的实际，而教训也为一切工程所了的缺陷管理实际成为一切工程的实际，而教训也为一切工程所了解。更重要的是，随着组织的不断开展完善，组织的过程会得到解。更重要的是，随着组织的不断开展完善，组织的过程会得到继续性的

18、改良，一切工程的过程也都会相应的改良。继续性的改良，一切工程的过程也都会相应的改良。6.5.4 不同软件组织的缺陷管理过程(续)量化管理量化管理CMM第四级或称为已管理级的软件组织会根据已搜集的缺第四级或称为已管理级的软件组织会根据已搜集的缺陷数据，采用陷数据，采用SPC的方法建立软件过程才干基线的方法建立软件过程才干基线Process Capability Baseline。对于缺陷管理，可以缺陷密度为例，过程。对于缺陷管理，可以缺陷密度为例，过程才干基线通常包括期望才干基线通常包括期望Mean，才干上限，才干上限Upper Control Limit，UCL，才干下限，才干下限Low Control Limit，LCL。其中，。其中，期望期望描画了未来工程的缺陷密度的预期值，而描画了未来工程的缺陷密度的预期值，而UCL和和LCL描画描画了未来工程的