《《缺陷管理》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《缺陷管理》PPT课件.ppt（35页珍藏版）》请在三一办公上搜索。
1、第6章 缺陷管理,本课教学目标,了解缺陷的严重级和优先级分类正确理解缺陷跟踪管理流程了解缺陷管理流程的要点正确理解缺陷数据分析的重要性,课程内容,6.1 软件缺陷概念回顾6.2 缺陷的严重性和优先级6.3 缺陷跟踪管理6.4 缺陷书写规范6.5 缺陷数据分析,6.1 软件缺陷概念回顾,软件缺陷的定义：（1）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；（4）软件功能超出了产品说明书中指明的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。,软件缺陷概念回顾（续）,
2、软件缺陷的特征：“看不到”软件的特殊性决定了缺陷不易看到“看到但是抓不到”发现了缺陷，但不易找到问题发生的原因所在,软件缺陷概念回顾（续）,图 软件缺陷产生的原因分布,缺陷分布情况：,6.2 软件缺陷严重性和优先级,重要软件缺陷会导致重大经济损失与灾难测试员应对软件缺陷分类，以简明扼要的方式指出其影响，以及修改次序划分软件缺陷严重级和优先级的通用原则表示软件缺陷所造成的危害的恶劣程度优先级表示修复缺陷的重要程度与次序,软件缺陷严重性和优先级（续）,严重级严重：系统崩溃、数据丢失、数据损坏较严重：操作性错误、错误结果、遗漏功能一般：小问题、错别字、UI布局、罕见故障建议：不影响使用的瑕疵或更好的
3、实现,软件缺陷严重性和优先级（续）,优先级最高优先级：立即修复，停止进一步测试次高优先级：在产品发布之前必须修复中等优先级：如果时间允许应该修复最低等优先级：可能会修复，不修复也能发布一般严重性和优先级的划分用数字表示，有的小数字表示的级别最高，而有的用大数字表示级别高。另外严重级和优先级的划分并不唯一，可适当修改,缺陷等级划分（SZSTC）,6.软件缺陷跟踪管理,6.3.1 缺陷跟踪管理目标6.3.2 缺陷跟踪管理6.3.3 软件缺陷的状态6.3.4 缺陷管理流程6.3.5 缺陷流程管理原则,6.3.1 缺陷跟踪管理目标,确保每个被发现的缺陷都能够被解决（修正或其他处理方式）收集缺陷数据并根
4、据缺陷趋势曲线识别测试过程的阶段 收集缺陷数据并在其上进行数据分析，作为组织的过程财富,6.3.2 缺陷跟踪管理,为了正确跟踪每个软件缺陷的处理过程，通常将软件测试发现的每个错误作为一条条记录输入指定的错误跟踪管理系统 目前的缺陷跟踪管理软件包括：ClearQuest(IBM)TestDirector(Mercury Interative)Bugzilla,缺陷跟踪管理（续）,作为一个缺陷跟踪管理系统，需要正确的记录错误信息和错误处理信息的全部内容,Bug记录信息测试软件名称测试版本号测试人名称测试用例标题测试软件和硬件配置环境发现软件错误的类型错误严重等级详细步骤必要的附图发生错误的模块,B
5、ug处理信息 处理者姓名处理时间处理步骤缺陷记录的当前状态,软件缺陷的主要状态包括以下的内容新建(New)：测试中新报告的软件缺陷；打开(Open)：被确认并分配给相关开发人员处理；修正(Fixed)：开发人员已完成修正，等待测试人员验证；拒绝(Declined)：拒绝修改缺陷；延期(Deferred)：不在当前版本修复的错误，下一版修复 关闭(Closed)：错误已被修复。,6.3.3 软件缺陷状态,测试人员提交新发现的缺陷入库，缺陷状态为“New”高级测试人员验证错误如果确认是错误，则分配给相应的开发人员，设置状态为“Open”如果不是错误，则拒绝，设置为“Declined”状态开发人员查
6、询状态为“Open”的缺陷，对其进行处理如果不是错误，则状态置为“Declined”如果是错误，则修复并置状态为“Fix”如果不能解决，要留下文字说明并保持缺陷状态仍为“Open”对于不能解决或者延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）才能认可测试人员查询状态为“Fix”的缺陷，验证缺陷是否已解决，做如下处理如果问题解决了，置缺陷的状态为“Closed”如果问题没有结果，则置状态为“Reopen”,6.3.4 缺陷管理流程,缺陷流程管理应遵循以下原则为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重现。每
7、次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug 状态。拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。加强测试人员与程序员的交流，对于某些不能重现的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。,缺陷管理流程要点,6.4 缺陷书写规范（一）,标题：应保持简短、准确，提供缺陷的本质信息尽量按缺陷发生的原因与结果的方式书写；避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；为了便于他人理解，
8、避免使用术语、俚语或过分具体的测试细节。复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；包含的信息过少，丢失了操作的必要步骤；没有对软件缺陷发生的条件和影响区域进行隔离。,复现步骤的正确书写方式：提供测试的环境信息；简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；每个步骤前使用数字对步骤编号；尽量使用短语或短句，避免复杂句型句式；复现的步骤要完整、准确、简短；将常见步骤合并为较少步骤；按实际需要决定是否包含步骤执行后的结果。实际结果：是执
9、行复现步骤后软件的现象和产生的行为。实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。,6.4 缺陷书写规范（二）,期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。附件：对缺陷描述的补充说明，可以是以下一些类型：缺陷症状的截图；测试使用的数据文件；缺陷交流的记录，例如相关邮件等；解决缺陷的补丁程序其它：选择合适的缺陷严重性属性；按相应的规定，填写相应的字段信息,6.4 缺陷书写规范（三）,避免常见的错误：避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替避免使用情绪化的语言和强调符号；避免使用诸如“似乎”、“
10、看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；避免提交不确定的测试问题，自己至少需要重现一次再提交。,6.4 缺陷书写规范（四）,上海人：哪能查询到的结果和查询条件不搭噶的。北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。,问题与讨论,请指出下面这个缺陷的不足之处,6.5 缺陷数据分析,6.5.1 缺陷数据分析关注的问题6.5.2 缺陷数据分析的重要性6.5.3 缺陷数据分析的数据指标,6.5.1 缺陷数据分析关注的问题,正在测试的软件哪个模块的问题最多？测试人员中谁报告的软件缺陷最多？各类缺陷所占的数量百分比分别
11、是多少？开发人员能及时修复软件缺陷吗？开发人员一次正确修复缺陷的百分比是多少？正在开发的软件能否在计划的时间内正常发布？。,6.5.2 缺陷数据分析的重要性,统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。,6.5.3 缺陷数据分析的数据指标,每天/周报告的新缺陷数目；每天/周修复的缺陷数；累计报告的缺陷数目；累计修复的缺陷数；不同严重性类型的缺陷数；
12、程序模块与发现的缺陷的对应关系；。,6.5.4 不同软件组织的缺陷管理过程,个体行为处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且，为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。,6.5.4 不
13、同软件组织的缺陷管理过程(续),项目行为在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：（1）提交缺陷（2）分析和定位缺陷（3）提请修改相应的软件（4）修改相应的软件（5）验证修改项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。,6.5.4 不同软件组织的缺陷管理过程(续),组织行为CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。从而，整个软件组织中的
14、项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。,6.5.4 不同软件组织的缺陷管理过程(续),量化管理CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（Process Capability Baseline）。对于缺陷管理，可以缺陷密度为例，过程能力基线通常包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，
15、期望描述了未来项目的缺陷密度的预期值，而UCL和LCL描述了未来项目的缺陷密度的合理变化范围。这样的过程能力基线可以用来：(1)帮助未来的项目设立量化的项目质量目标；(2)理解和控制未来项目的实际结果。,6.5.4 不同软件组织的缺陷管理过程(续),6.5.4 不同软件组织的缺陷管理过程(续),持续优化与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。,6.5.4 不同软件组织的缺陷管理过程(续),问题与讨论,如果你是一个测试经理，你最关心的缺陷数据是什么？,
