新版缺陷管理专题知识宣讲培训课件

本课教学目标了解缺陷的严重级和优先级分类正确理解缺陷跟踪管理流程了解缺陷管理流程的要点正确理解缺陷数据分析的重要性1新版缺陷管理专题知识宣讲8/23/2024课程内容6.1软件缺陷概念回顾6.2缺陷的严重性和优先级6.3缺陷跟踪管理6.4缺陷书写规范6.5缺陷数据分析2新版缺陷管理专题知识宣讲8/23/20246.1软件缺陷概念回顾软件缺陷的定义：（1）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；

（4）软件功能超出了产品说明书中指明的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。3新版缺陷管理专题知识宣讲8/23/2024软件缺陷概念回顾（续）软件缺陷的特征：

“看不到”

——软件的特殊性决定了缺陷不易看到“看到但是抓不到”

——发现了缺陷，但不易找到问题发生的原因所在4新版缺陷管理专题知识宣讲8/23/2024软件缺陷概念回顾（续）其他10%软件产品说明书（需求）56%编写代码7%设计27%图软件缺陷产生的原因分布缺陷分布情况：5新版缺陷管理专题知识宣讲8/23/2024

6.2软件缺陷严重性和优先级重要软件缺陷会导致重大经济损失与灾难测试员应对软件缺陷分类，以简明扼要的方式指出其影响，以及修改次序划分软件缺陷严重级和优先级的通用原则表示软件缺陷所造成的危害的恶劣程度优先级表示修复缺陷的重要程度与次序6新版缺陷管理专题知识宣讲8/23/2024

软件缺陷严重性和优先级（续）严重级严重：系统崩溃、数据丢失、数据损坏较严重：操作性错误、错误结果、遗漏功能一般：小问题、错别字、UI布局、罕见故障建议：不影响使用的瑕疵或更好的实现7新版缺陷管理专题知识宣讲8/23/2024

软件缺陷严重性和优先级（续）优先级最高优先级：立即修复，停止进一步测试次高优先级：在产品发布之前必须修复中等优先级：如果时间允许应该修复最低等优先级：可能会修复，不修复也能发布一般严重性和优先级的划分用数字１～４表示，有的小数字表示的级别最高，而有的用大数字表示级别高。另外严重级和优先级的划分并不唯一，可适当修改8新版缺陷管理专题知识宣讲8/23/2024缺陷等级划分（SZSTC）等级描述说明5-紧急发现可重复出现的致命问题——导致系统崩溃；——导致程序模块丢失；——主业务流程出现断点；——内存泄漏；——导致死机4-非常高发现可重复出现的严重问题——被测功能不能正确实现；——软件错误导致数据丢失；——被测数据处理错误；——用户需求未实现。3-高一般性的错误或功能实现有不完美处——操作界面错误；——打印内容、格式错误；——简单的输入限制未放在前台进行控制；——删除操作未给出提示。2-中细小的错误——界面不规范；——辅助说明描述不清楚；——输入输出不规范；——长操作未给用户提示；——提示窗口文字未采用行业术语。1-低建议类错误需求说明书、用户手册中未说明，但影响用户对软件使用的方便性等9新版缺陷管理专题知识宣讲8/23/2024问题与讨论请将自己的缺陷定义等级划分10新版缺陷管理专题知识宣讲8/23/2024

6.３软件缺陷跟踪管理6.3.1缺陷跟踪管理目标6.3.2缺陷跟踪管理6.3.3软件缺陷的状态6.3.4缺陷管理流程6.3.5缺陷流程管理原则11新版缺陷管理专题知识宣讲8/23/2024

6.3.1缺陷跟踪管理目标确保每个被发现的缺陷都能够被解决

（修正或其他处理方式）收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段

收集缺陷数据并在其上进行数据分析，作为组织的过程财富12新版缺陷管理专题知识宣讲8/23/2024

6.3.2缺陷跟踪管理为了正确跟踪每个软件缺陷的处理过程，通常将软件测试发现的每个错误作为一条条记录输入指定的错误跟踪管理系统目前的缺陷跟踪管理软件包括：ClearQuest(IBM)TestDirector(MercuryInterative)Bugzilla(很重要自己学习一下)13新版缺陷管理专题知识宣讲8/23/2024缺陷跟踪管理（续）作为一个缺陷跟踪管理系统，需要正确的记录错误信息和错误处理信息的全部内容Bug记录信息测试软件名称测试版本号测试人名称测试用例标题测试软件和硬件配置环境发现软件错误的类型错误严重等级详细步骤必要的附图发生错误的模块…Bug处理信息

处理者姓名处理时间处理步骤缺陷记录的当前状态14新版缺陷管理专题知识宣讲8/23/2024软件缺陷的主要状态包括以下的内容新建(New)： 测试中新报告的软件缺陷；打开(Open)： 被确认并分配给相关开发人员处理；修正(Fixed)： 开发人员已完成修正，等待测试人员验证；拒绝(Declined)： 拒绝修改缺陷；延期(Deferred)： 不在当前版本修复的错误，下一版修复关闭(Closed)： 错误已被修复。

6.3.3软件缺陷状态15新版缺陷管理专题知识宣讲8/23/2024测试人员提交新发现的缺陷入库，缺陷状态为“New”高级测试人员验证错误如果确认是错误，则分配给相应的开发人员，设置状态为“Open”如果不是错误，则拒绝，设置为“Declined”状态开发人员查询状态为“Open”的缺陷，对其进行处理如果不是错误，则状态置为“Declined”如果是错误，则修复并置状态为“Fix”如果不能解决，要留下文字说明并保持缺陷状态仍为“Open”对于不能解决或者延期解决的缺陷，不能由开发人员自己决定，一般要通过某种会议（评审会）才能认可测试人员查询状态为“Fix”的缺陷，验证缺陷是否已解决，做如下处理如果问题解决了，置缺陷的状态为“Closed”如果问题没有结果，则置状态为“Reopen”

6.3.4缺陷管理流程16新版缺陷管理专题知识宣讲8/23/2024问题与讨论请以缺陷管理流程图的形式描述自己平时工作中的缺陷管理流程（包括涉及到的人物角色，缺陷状态和工作方式）OpenResolvedVerifiedClosedClose（缺陷评审委员会）Reopen（测试人员）Resolve（程序员）Verify（测试工程师）Close（测试工程师）Reopen（测试人员）17新版缺陷管理专题知识宣讲8/23/2024缺陷流程管理应遵循以下原则为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。

6.3.5

缺陷管理流程要点18新版缺陷管理专题知识宣讲8/23/20246.4缺陷书写规范（一）标题：应保持简短、准确，提供缺陷的本质信息尽量按缺陷发生的原因与结果的方式书写；避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状；为了便于他人理解，避免使用术语、俚语或过分具体的测试细节。复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解；包含的信息过少，丢失了操作的必要步骤；没有对软件缺陷发生的条件和影响区域进行隔离。19新版缺陷管理专题知识宣讲8/23/2024复现步骤的正确书写方式：提供测试的环境信息；简单地一步步引导复现该缺陷，一个步骤包含的操作不要多；每个步骤前使用数字对步骤编号；尽量使用短语或短句，避免复杂句型句式；复现的步骤要完整、准确、简短；将常见步骤合并为较少步骤；按实际需要决定是否包含步骤执行后的结果。实际结果：是执行复现步骤后软件的现象和产生的行为。实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。6.4缺陷书写规范（二）20新版缺陷管理专题知识宣讲8/23/2024期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。附件：对缺陷描述的补充说明，可以是以下一些类型：缺陷症状的截图；测试使用的数据文件；缺陷交流的记录，例如相关邮件等；解决缺陷的补丁程序其它：选择合适的缺陷严重性属性；按相应的规定，填写相应的字段信息6.4缺陷书写规范（三）21新版缺陷管理专题知识宣讲8/23/2024避免常见的错误：避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替避免使用情绪化的语言和强调符号；避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；避免提交不确定的测试问题，自己至少需要重现一次再提交。6.4缺陷书写规范（四）上海人：哪能查询到的结果和查询条件不搭噶的。北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。22新版缺陷管理专题知识宣讲8/23/2024问题与讨论请指出下面这个缺陷的不足之处23新版缺陷管理专题知识宣讲8/23/2024问题与讨论请修改自己的缺陷描述24新版缺陷管理专题知识宣讲8/23/20246.5缺陷数据分析6.5.1缺陷数据分析关注的问题6.5.2缺陷数据分析的重要性6.5.3缺陷数据分析的数据指标25新版缺陷管理专题知识宣讲8/23/20246.5.1缺陷数据分析关注的问题正在测试的软件哪个模块的问题最多？测试人员中谁报告的软件缺陷最多？各类缺陷所占的数量百分比分别是多少？开发人员能及时修复软件缺陷吗？开发人员一次正确修复缺陷的百分比是多少？正在开发的软件能否在计划的时间内正常发布？。。。26新版缺陷管理专题知识宣讲8/23/20246.5.2缺陷数据分析的重要性统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。27新版缺陷管理专题知识宣讲8/23/20246.5.3缺陷数据分析的数据指标每天/周报告的新缺陷数目；每天/周修复的缺陷数；累计报告的缺陷数目；累计修复的缺陷数；不同严重性类型的缺陷数；程序模块与发现的缺陷的对应关系；。。。28新版缺陷管理专题知识宣讲8/23/20246.5.4不同软件组织的缺陷管理过程个体行为处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。所以这样的软件组织的项目交货期（ReleaseDate）表现出强烈的不可预测性。并且，为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。29新版缺陷管理专题知识宣讲8/23/20246.5.4不同软件组织的缺陷管理过程(续)项目行为在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：

（1）提交缺陷

（2）分析和定位缺陷

（3）提请修改相应的软件

（4）修改相应的软件

（5）验证修改项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。30新版缺陷管理专题知识宣讲8/23/20246.5.4不同软件组织的缺陷管理过程(续)组织行为

CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。31新版缺陷管理专题知识宣讲8/23/20246.5.4不同软件组织的缺陷管理过程(续)量化管理

CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（ProcessCapabilityBaseline）。对于缺陷管理，可以缺陷密度为例，过程能力基线通常包括期望（Mean）