软件工程第6章-测试课件.ppt

第第6章章 测试测试6.1 软件测试基础6.2 单元测试6.3 集成测试6.4 确认测试6.5 白盒测试技术6.6 黑盒测试技术软件测试在软件生命周期中横跨两个阶段通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作软件测试的工作量往往占软件开发总工作量的40%以上.仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是最终目的软件工程的根本目标是开发出高质量的完全符合用户需要的软件，因此，通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的调试是测试阶段最困难的工作在对测试结果进行收集和评价的时候，软件所达到的可靠性也开始明朗了软件可靠性模型使用故障率数据，估计软件将来出现故障的情况并预测软件的可靠性表面看来，软件测试的目的与软件工程所有其他阶段的目的都相反软件工程的其他阶段都是“建设性”的：软件工程师力图从抽象的概念出发，逐步设计出具体的软件系统，直到用一种适当的程序设计语言写出可以执行的程序代码。

但是，在测试阶段测试人员努力设计出一系列测试方案，目的却是为了“破坏”已经建造好的软件系统竭力证明程序中有错误不能按照预定要求正确工作6.1 软件测试基础G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义1)测试是发现程序中的错误而执行程序的过程；(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；(3)成功的测试是发现了至今为止尚未发现的错误的测试6.1.1 软件测试的目标从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计1）所有测试都应该能追溯到用户需求从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误应该认识到测试决不能证明程序是正确的即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中测试只能查找出程序中的错误，不能证明程序中没有错误6.1.2 软件测试准则（2）应该远在测试开始之前就制定出测试计划实际上，一旦完成了需求模型就可以着手制定测试计划，在建立了设计模型之后就可以立即开始设计详细的测试方案。

因此，在编码之前就可以对所有测试工作进行计划和设计3）把Pareto原理应用到软件测试中Pareto原理说明，测试发现的错误中的80%很可能是由程序中20%的模块造成的当然，问题是怎样找出这些可疑的模块并彻底地测试它们4）应该从“小规模”测试开始，并逐步进行“大规模”测试通常，首先重点测试单个程序模块，然后把测试重点转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误5）穷举测试是不可能的所谓穷举测试就是把程序所有可能的执行路径都检查一遍的测试即使是一个中等规模的程序，其执行路径的排列数也十分庞大，由于受时间、人力和资源的限制，在测试过程中不可能执行每个可能的路径因此，测试只能证明程序中有错误，不能证明程序中没有错误6）为了达到最佳的测试效果，应该由独立的第三方从事测试工作测试任何产品都有两种方法：(1)黑盒测试如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用；(2)白盒测试如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行6.1.3 测试方法对于软件测试而言，黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。

也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性黑盒测试又称为功能测试白盒测试法与黑盒测试法相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作白盒测试又称为结构测试根据第4条测试准则，测试过程也必须分步骤进行，后一个步骤在逻辑上是前一个步骤的继续大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成，因此，大型软件系统的测试过程基本上由下述几个步骤组成6.1.4 测试步骤1.模块测试在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试在这个测试步骤中所发现的往往是编码和详细设计的错误2.集成测试（子系统测试）子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。

模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口3.系统测试系统测试是把经过测试的子系统装配成一个完整的系统来测试在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试4.验收测试验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误验收测试也称为确认测试单元测试集中检测软件设计的最小单元模块通常，单元测试和编码属于软件过程的同一个阶段在编写出源程序代码并通过了编译程序的语法检查之后，就可以用详细设计描述作指南，对重要的执行通路进行测试，以便发现模块内部的错误通常，单元测试主要使用白盒测试技术，而且对多个模块的测试可以并行地进行6.2 单元测试单元测试，从下述5个方面对模块进行测试。

1.模块接口首先应该对通过模块接口的数据流进行测试在对模块接口进行测试时主要检查下述几个方面：参数的数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致测试重点2.局部数据结构对于模块来说，局部数据结构是常见的错误来源应该仔细设计测试方案，以便发现局部数据说明、初始化、默认值等方面的错误3.重要的执行通路由于通常不可能进行穷尽测试，因此，在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误4.出错处理通路好的设计应该能预见出现错误的条件，并且设置适当的处理错误的通路，以便在真的出现错误时执行相应的出错处理通路或干净地结束处理不仅应该在程序中包含出错处理通路，而且应该认真测试这种通路1)对错误的描述是难以理解的；(2)记下的错误与实际遇到的错误不同；(3)在对错误进行处理之前，错误条件已经引起系统干预；(4)对错误的处理不正确；(5)描述错误信息不足以帮助确定造成错误位置5.边界条件边界测试是单元测试中最后的也可能是最重要的任务。

软件常常在它的边界上失效，例如，处理n元数组的第n个元素时，或做到i次循环中的第i次重复时，往往会发生错误使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误人工测试源程序可以由编写者本人非正式地进行，也可以由审查小组正式进行后者称为代码审查，它是一种非常有效的程序验证技术，对于典型的程序来说，可以查出30%70%的逻辑设计错误和编码错误审查小组最好由下述4人组成：(1)组长，应该是一个很有能力的程序员，而且没有直接参与这项工程；(2)程序的设计者；(3)程序的编写者；(4)程序的测试者6.2.2 代码审查集成测试是测试和组装软件的系统化技术，例如，子系统测试即是在把模块按照设计要求组装起来的同时进行测试，主要目标是发现与接口有关的问题(系统测试与此类似)例如，数据穿过接口时可能丢失；一个模块对另一个模块可能由于疏忽而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等等6.3 集成测试由模块组装成程序时有两种方法1）非渐增式测试方法一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非渐增式测试方法；（2）渐增式测试方法。

把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试这种每次增加一个模块的方法称为渐增式测试非渐增式测试一下子把所有模块放在一起，并把庞大的程序作为一个整体来测试，测试时会遇到许许多多的错误，改正错误更是极端困难，因为在庞大的程序中想要诊断定位一个错误是非常困难的而且一旦改正一个错误之后，马上又会遇到新的错误，这个过程将继续下去渐增式测试与“一步到位”的非渐增式测试相反，它把程序划分成小段来构造和测试，在这个过程中比较容易定位和改正错误；对接口可以进行更彻底的测试；可以使用系统化的测试方法因此，目前在进行集成测试时普遍采用渐增式测试方法当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略自顶向下集成方法是从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来在把附属于（及最终附属于）主控制模块的那些模块组装到程序结构中去时，或者使用深度优先的策略，或者使用宽度优先的策略深度优先的结合方法先组装在软件结构的一条主控制通路上的所有模块选择一条主控制通路取决于应用的特点，并且有很大任意性宽度优先的结合方法是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。

6.3.1 自顶向下集成 自顶向下结合模块结合进软件结构由下述4个步骤完成：（1）对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块；（2）根据选定的结合策略(深度优先或宽度优先)，每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序)；（3）在结合进一个模块的同时进行测试；（4）为了保证加入模块没有引进新的错误，可能需要进行回归测试(即，全部或部分地重复以前做过的测试)从第二步开始不断地重复进行上述过程，直到构造起完整的软件结构为止自顶向下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验在一个分解得好的软件结构中，关键的抉择位于层次系统的较上层，因此首先碰到如果主要控制确实有问题，早期认识到这类问题是很有好处的，可以及早想办法解决如果选择深度优先的结合方法，可以在早期实现软件的一个完整的功能并且验证这个功能早期证实软件的一个完整的功能，可以增强开发人员和用户双方的信心自顶向下的方法遇到的问题如下：为了充分地测试软件系统的较高层次，需要在较低层次上的处理然而在自顶向下测试的初期，存根程序代替了低层次的模块，在软件结构中没有重要的数据自下往上流。

为了解决这个问题，测试人员有两种选择：第一，把许多测试推迟到用真实模块代替了存根程序以后再进行；第二，从层次系统的底部向上组装软件自底向上测试从“原子”模块(即在软件结构最低层的模块)开始组装和测试，不需要存根程序用下述步骤可以实现自底向上的结合策略：第一步，把低层模块组合成实现某个特定的软件子功能的族；第二步，写一个驱动程序(用于测试的控制程序)，协调测试数据的输入。