06缺陷管理

《06缺陷管理》由会员分享，可在线阅读，更多相关《06缺陷管理（37页珍藏版）》请在金锄头文库上搜索。

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

2、软件缺陷概念回顾（续）,软件缺陷的特征： “看不到” 软件的特殊性决定了缺陷不易看到 “看到但是抓不到” 发现了缺陷，但不易找到问题发生的原因所在,软件缺陷概念回顾（续）,图 软件缺陷产生的原因分布,缺陷分布情况：,6.2 软件缺陷严重性和优先级,重要软件缺陷会导致重大经济损失与灾难 测试员应对软件缺陷分类，以简明扼要的方式指出其影响，以及修改次序 划分软件缺陷严重级和优先级的通用原则 表示软件缺陷所造成的危害的恶劣程度 优先级表示修复缺陷的重要程度与次序,软件缺陷严重性和优先级（续）,严重级 严重：系统崩溃、数据丢失、数据损坏 较严重：操作性错误、错误结果、遗漏功能 一般：小问题、错别字、U

3、I布局、罕见故障 建议：不影响使用的瑕疵或更好的实现,软件缺陷严重性和优先级（续）,优先级 最高优先级：立即修复，停止进一步测试 次高优先级：在产品发布之前必须修复 中等优先级：如果时间允许应该修复 最低等优先级：可能会修复，不修复也能发布 一般严重性和优先级的划分用数字表示，有的小数字表示的级别最高，而有的用大数字表示级别高。 另外严重级和优先级的划分并不唯一 ，可适当修改,缺陷等级划分（ SZSTC ）,问题与讨论,请将自己的缺陷定义等级划分,6. 软件缺陷跟踪管理,6.3.1 缺陷跟踪管理目标 6.3.2 缺陷跟踪管理 6.3.3 软件缺陷的状态 6.3.4 缺陷管理流程 6.3.5 缺

4、陷流程管理原则,6.3.1 缺陷跟踪管理目标,确保每个被发现的缺陷都能够被解决 （修正或其他处理方式） 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段 收集缺陷数据并在其上进行数据分析，作为组织的过程财富,6.3.2 缺陷跟踪管理,为了正确跟踪每个软件缺陷的处理过程，通常将软件测试发现的每个错误作为一条条记录输入指定的错误跟踪管理系统 目前的缺陷跟踪管理软件包括： ClearQuest (IBM) TestDirector (Mercury Interative) Bugzilla(很重要 自己学习一下),缺陷跟踪管理（续）,作为一个缺陷跟踪管理系统，需要正确的记录错误信息和错误处理信息的全

5、部内容,Bug记录信息 测试软件名称 测试版本号 测试人名称 测试用例 标题 测试软件和硬件配置环境 发现软件错误的类型 错误严重等级 详细步骤 必要的附图 发生错误的模块,Bug处理信息 处理者姓名 处理时间 处理步骤 缺陷记录的当前状态,软件缺陷的主要状态包括以下的内容 新建(New)： 测试中新报告的软件缺陷； 打开 (Open)： 被确认并分配给相关开发人员处理； 修正(Fixed)： 开发人员已完成修正，等待测试人员验证； 拒绝(Declined)： 拒绝修改缺陷； 延期(Deferred)： 不在当前版本修复的错误，下一版修复 关闭(Closed)： 错误已被修复。,6.3.3 软

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

7、osed” 如果问题没有结果，则置状态为“Reopen”,6.3.4 缺陷管理流程,问题与讨论,请以缺陷管理流程图的形式描述自己平时工作中的缺陷管理流程（包括涉及到的人物角色，缺陷状态和工作方式）,Open,Resolved,Verified,Closed,Close（ 缺陷评审委员会）,Reopen（测试人员）,Resolve（程序员）,Verify（测试工程师）,Close（测试工程师）,Reopen（测试人员）,缺陷流程管理应遵循以下原则 为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。 每次对错误的处理都要保留处理信息

8、，包括处理姓名，时间，处理方法，处理意见，Bug 状态。 拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。 错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。 加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例。,6.3.5 缺陷管理流程要点,6.4 缺陷书写规范（一）,标题：应保持简短、准确，提供缺陷的本质信息 尽量按缺陷发生的原因与结果的方式书写； 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状； 为了便于他人理解，避免使

9、用术语、俚语或过分具体的测试细节。 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。 常见问题： 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解； 包含的信息过少，丢失了操作的必要步骤； 没有对软件缺陷发生的条件和影响区域进行隔离。,复现步骤的正确书写方式： 提供测试的环境信息； 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多； 每个步骤前使用数字对步骤编号； 尽量使用短语或短句，避免复杂句型句式； 复现的步骤要完整、准确、简短； 将常见步骤合并为较少步骤； 按实际需要决定是否包含步骤执行后的结

10、果。 实际结果：是执行复现步骤后软件的现象和产生的行为。 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。,6.4 缺陷书写规范（二）,期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。 附件：对缺陷描述的补充说明，可以是以下一些类型： 缺陷症状的截图； 测试使用的数据文件； 缺陷交流的记录，例如相关邮件等； 解决缺陷的补丁程序 其它： 选择合适的缺陷严重性属性； 按相应的规定，填写相应的字段信息,6.4 缺陷书写规范（三）,避免常见的错误： 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替 避免使用情绪化

11、的语言和强调符号； 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果； 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息； 避免提交不确定的测试问题，自己至少需要重现一次再提交。,6.4 缺陷书写规范（四）,上海人：哪能查询到的结果和查询条件不搭噶的。 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。,问题与讨论,请指出下面这个缺陷的不足之处,问题与讨论,请修改自己的缺陷描述,6.5 缺陷数据分析,6.5.1 缺陷数据分析关注的问题 6.5.2 缺陷数据分析的重要性 6.5.3 缺陷数据分析的数据指标,6.5.1 缺陷数据分析关注的问题,正在测

12、试的软件哪个模块的问题最多？ 测试人员中谁报告的软件缺陷最多？ 各类缺陷所占的数量百分比分别是多少？ 开发人员能及时修复软件缺陷吗？ 开发人员一次正确修复缺陷的百分比是多少？ 正在开发的软件能否在计划的时间内正常发布？ 。,6.5.2 缺陷数据分析的重要性,统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。,6.5.3 缺陷数据分析的数据指标,每天

13、/周报告的新缺陷数目； 每天/周修复的缺陷数； 累计报告的缺陷数目； 累计修复的缺陷数； 不同严重性类型的缺陷数； 程序模块与发现的缺陷的对应关系； 。,6.5.4 不同软件组织的缺陷管理过程,个体行为 处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。 所以这样的软件组织的项目交货期（Release Date）

14、表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。,6.5.4 不同软件组织的缺陷管理过程(续),项目行为 在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面： （1）提交缺陷 （2）分析和定位缺陷 （3）提请修改相应的软件 （4）修改相应的软件 （5）验证修改 项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。,6.5.4 不同软件组织的缺陷管理过程(续),组织行为 CMM第三级（或称为已定义级）的软件组织会汇集

15、组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。 从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。,6.5.4 不同软件组织的缺陷管理过程(续),量化管理 CMM第四级（或称为已管理级）的软件组织会根据已收集的缺陷数据，采用SPC的方法建立软件过程能力基线（Process Capability Baseline）。对于缺陷管理，可以缺陷密度为例，过程能力基线通常

16、包括期望（Mean），能力上限（Upper Control Limit，UCL），能力下限（Low Control Limit，LCL）。其中，“期望“描述了未来项目的缺陷密度的预期值，而UCL和LCL描述了未来项目的缺陷密度的合理变化范围。 这样的过程能力基线可以用来：(1)帮助未来的项目设立量化的项目质量目标；(2)理解和控制未来项目的实际结果。,6.5.4 不同软件组织的缺陷管理过程(续),6.5.4 不同软件组织的缺陷管理过程(续),持续优化 与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。 就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。 缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。,6.5.4 不同软件组织的缺陷管理过程(续),问题与讨论,如果你是一个测试经理