软件测试项目实战第5版 课件 第三章缺陷管理

第三章缺陷管理以“CVIT课程管理系统”权限模块为例于艳华长春职业技术大学软件回归测试01软件缺陷概念与种类02软件缺陷生命周期03软件缺陷严重性和优先级04目录软件缺陷概念与种类回归测试在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。回归测试概述概述1掌握测试用例库维护和回归测试包选择策略回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。回归测试概述概述1掌握测试用例库维护和回归测试包选择策略对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到测试用例库中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。回归测试策略2回归测试策略掌握测试用例库维护和回归测试包选择策略（1）测试用例库的维护为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。回归测试策略2回归测试策略掌握测试用例库维护和回归测试包选择策略测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括以下几个方面。①删除过时的测试用例。因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。②改进不受控制的测试用例。随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。③删除冗余的测试用例。如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期地整理测试用例库，并将冗余的用例删除掉。④增添新的测试用例。如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试，并将新开发的测试用例合并到基线测试包中。对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试用例库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。回归测试策略2回归测试策略掌握测试用例库维护和回归测试包选择策略（2）回归测试包的选择在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：回归测试策略2回归测试策略掌握测试用例库维护和回归测试包选择策略①再测试全部用例。选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用于任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。②基于风险选择测试。可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，应按从主要特征到次要特征的顺序进行测试。③基于操作剖面选择测试。如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效地提高系统可靠性，但实施起来有一定的难度。④再测试修改的部分。当测试者对修改的部分有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试应尽可能覆盖受到影响的部分。再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。回归测试策略2回归测试策略掌握测试用例库维护和回归测试包选择策略（3）回归测试的基本过程有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循以下基本过程：①识别出软件中被修改的部分。②从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。③依据一定的策略从T0中选择测试用例测试被修改的软件。④如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。⑤用T1执行修改后的软件。第②和第③步测试验证修改是否破坏了现有的功能，第④和第⑤步测试验证修改工作本身。回归测试策略2回归测试策略掌握测试用例库维护和回归测试包选择策略软件缺陷概念与种类认识软件缺陷的定义和常见分类软件缺陷（Defect），常常又被叫作Bug。所谓软件缺陷，即计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729—1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷概念规格说明书缺陷：规格说明书可能不完全，有二义性或自身矛盾。另外，在设计过程中可能修改功能，如果不能紧跟这种变化并及时修改规格说明书，则产生规格说明书错误。功能缺陷：程序实现的功能与用户要求的不一致。这常常是由于规格说明书包含错误的功能、多余的功能或遗漏的功能所导致的。在发现和改正这些缺陷的过程中又可能引入新的缺陷。测试缺陷：软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对规格说明书做了错误的解释，也会发生许多错误。测试标准引起的缺陷：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。功能缺陷1软件缺陷种类外部接口缺陷：外部接口是指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间、人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外，还包括对输入/输出格式的错误理解，对输入数据不合理的容错等。内部接口缺陷：内部接口是指程序内部子系统或模块之间的联系。它所发生的缺陷与外部接口相同，只是与程序内实现的细节有关，如设计协议错误、输入/输出格式错误、数据保护不可靠、子程序访问出错等。系统缺陷2软件缺陷种类硬件结构缺陷：与硬件结构有关的软件缺陷在于不能正确地理解硬件如何工作，如忽视或错误地理解分页机构、地址生成、通道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。操作系统缺陷：与操作系统有关的软件缺陷在于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有缺陷，但是一般用户很难发现这种缺陷。软件结构缺陷：由于软件结构不合理而产生的缺陷。这种缺陷通常与系统的负载有关，而且往往在系统满载时才出现。如错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定被调用子程序常驻内存或非常驻内存等，都将导致软件出错。控制与顺序缺陷：如忽视了时间因素而破坏了事件的顺序；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。资源管理缺陷：由于不正确地使用资源而产生的缺陷。如使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接到错误的队列中等。系统缺陷2软件缺陷种类算法与操作缺陷：是指在算术运算、函数求值和一般操作过程中发生的缺陷，如数据类型转换错误；除法溢出；不正确地使用关系运算符；不正确地使用整数与浮点数做比较等。初始化缺陷：如忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式、数据或类类型进行初始化等。控制和次序缺陷：与系统级同名缺陷相比，它是局部缺陷。如遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。静态逻辑缺陷：如不正确地使用Switch语句；在表达式中使用不正确的否定（例如，用“>”代替“<”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。加工缺陷3软件缺陷种类①

动态数据缺陷：动态数据是在程序执行过程中暂时存在的数据，它的生存期非常短。各种不同类型的动态数据在执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，就会导致数据出错。②

静态数据缺陷：静态数据在内容和格式上都是固定的。它们直接或间接地出现在程序或数据库中，有编译程序或其他专门对它们做预处理，但预处理也会出错。③

数据内容、结构和属性缺陷：数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容缺陷就是由于内容被破坏或被错误地解释而造成的缺陷。数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构缺陷包括结构说明错误及数据结构误用的错误。数据属性是指数据内容的含义或语义。数据属性缺陷包括对数据属性不正确的解释，如错把整数当实数，允许不同类型数据混合运算而导致的错误等。数据缺陷4软件缺陷种类代码缺陷包括数据说明错误、数据使用错误、计算错误、比较错误、控制流错误、界面错误、输入\输出错误及其他的错误。规格说明书是软件缺陷出现最多的地方，其原因是：①

用户一般是非软件开发专业人员，软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。②

由于在开发初期，软件产品还没有设计和编程，完全靠想象去描述系统的实现结果，所以有些需求特性不够完整、清晰。③

用户的需求总在不断变化，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文、上下文的矛盾。④

对规格说明书不够重视，在规格说明书的设计和写作上投入的人力、时间不足。⑤

没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得到比较多的信息。排在产品规格说明书之后的是设计，编程排在第三位。许多人印象中，软件测试主要是找程序代码中的错误，这是一个认识的误区。代码缺陷5软件缺陷种类软件缺陷生命周期软件缺陷的生命周期掌握缺陷生命周期的每个状态当缺陷被第一次递交的时候，它的状态即为“新建”。这也就是说缺陷未被确认其是否真正是一个缺陷。新建1在测试员提交一个缺陷后，测试组长确认其确实为一个缺陷的时候他会把状态置为“打开”。打开2一旦缺陷被测试经理置为“打开”，他会把缺陷交给相应的开发人员或者开发组。这时缺陷状态变更为“分配”。分配3当开发人员修复缺陷后，他会把缺陷提交给测试员进行新一轮的测试。在开发人员公布已修复缺陷的程序之前，他会把缺陷状态置为“测试”。这时表明缺陷已经修复并且已经交给了测试员。测试4缺陷状态被置为“延迟的”意味着缺陷将会在下一个版本中被修复。将缺陷置为“延迟的”原因有许多种。有些由于缺陷优先级不高，有些由于时间紧，有些是因为缺陷对软件不会造成太大影响。延迟的5如果开发人员不认为其是一个缺陷，他会不接受。他会把缺陷状态置为“不接受的”。不接受的6如果同一个缺陷被重复提交或者两个缺陷表明的意思相同，那么这个缺陷状态会被置为“重复提交”。重复提交7一旦缺陷被修复它就会被置为“测试”，测试员会执行测试。如果缺陷不再出现，这就证明缺陷被修复了同时其状态被置为“已核实”。已核实8缺陷生命周期各阶段如果缺陷被开发人员修复后仍然存在，测试员会把缺陷状态置为“再次打开”。缺陷即将再次穿越其生命周期。再次打开9一旦缺陷被修复，测试员会对其进行测试。如果测试员认为