软件工程导论第7章编码和单元测试.doc

第7章 实 现 通常把编码和测试统称为实现。 所谓编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。作为软件工程过程的一个阶段，编码是对设计的进一步具体化，因此，程序的质量主要取决于软件设计的质量。但是，所选用的程序设计语言的特点及编码风格也将对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。 软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。 大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的3倍到5倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成 了，实际上，大约还有同样多的开发工作量需要完成。 仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是最终目的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件，因此，通过测试发现错误之后还必须诊断并改正错误，这就是调试的目的。调试是测试阶段最困难的工作。 在对测试结果进行收集和评价的时候，软件所达到的可靠性也开始明朗了。软件可靠性模型使用故障率数据，估计软件将来出现故障的情况并预测软件的可靠性。7.1 编 码7.1.1 选择程序设计语言 程序设计语言是人和计算机通信的最基本的工具，它的特点必然会影响人的思维和解题方式，会影响人和计算机通信的方式和质量，也会影响其他人阅读和理解程序的难易程度。因此，编码之前的一项重要工作就是选择一种适当的程序设计语言。 适宜的程序设计语言能使根据设计去完成编码时困难最少，可以减少需要的程序测试量，并且可以得出更容易阅读和更容易维护的程序。由于软件系统的绝大部分成本用在生命周期的测试和维护阶段，所以容易测试和容易维护是极端重要的。 使用汇编语言编码需要把软件设计翻译成机器操作的序列，由于这两种表示方法很不相同，因此汇编程序设计既困难又容易出差错。一般说来，高级语言的源程序语句和汇编代码指令之间有一句对多句的对应关系。统计资料表明，程序员在相同时间内可以写出的高级语言语句数和汇编语言指令数大体相同，因此用高级语言写程序比用汇编语言写程序生产率可以提高好几倍。高级语言一般都容许用户给程序变量和子程序赋予含义鲜明的名字，通过名字很容易把程序对象和它们所代表的实体联系起来；此外，高级语言使用的符号和概念更符合人的习惯。因此，用高级语言写的程序容易阅读，容易测试，容易调试，容易维护。 总的说来，高级语言明显优于汇编语言，因此，除了在很特殊的应用领域(例如，对程序执行时间和使用的空间都有很严格限制的情况；需要产生任意的甚至非法的指令序列；体系结构特殊的微处理机，以致在这类机器上通常不能实现高级语言编译程序)，或者大型系统中执行时间非常关键的(或直接依赖于硬件的)一小部分代码需要用汇编语言书写之外，其他程序应该一律用高级语言书写。 为了使程序容易测试和维护以减少软件的总成本，所选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构；为了便于调试和提高软件可靠性，语言特点应该使编译程序能够尽可能多地发现程序中的错误；为了降低软件开发和维护的成本，选用的高级语言应该有良好的独立编译机制。 上述这些要求是选择程序设计语言的理想标准，但是，在实际选择语言时不能仅仅使用理论上的标准，还必须同时考虑实用方面的各种限制。下面是主要的实用标准： (1)系统用户的要求。如果所开发的系统由用户负责维护，用户通常要求用他们熟悉的语言书写程序。 (2)可以使用的编译程序。运行目标系统的环境中可以提供的编译程序往往限制了可以选用的语言的范围。 (3)可以得到的软件工具。如果某种语言有支持程序开发的软件工具可以利用，则目标系统的实现和验证都变得比较容易。 (4)工程规模。如果工程规模很庞大，现有的语言又不完全适用，那么设计并实现一种供这个工程项目专用的程序设计语言，可能是一个正确的选择。 (5)程序员的知识。虽然对于有经验的程序员来说，学习一种新语言并不困难，但是要完全掌握一种新语言却需要实践。如果和其他标准不矛盾，那么应该选择一种已经为程序员所熟悉的语言。 (6)软件可移植性要求。如果目标系统将在几台不同的计算机上运行，或者预期的使用寿命很长，那么选择一种标准化程度高、程序可移植性好的语言就是很重要的。 (7)软件的应用领域。所谓的通用程序设计语言实际上并不是对所有应用领域都同样适用，例如，FORTRAN语言特别适合于工程和科学计算，COBOI。语言适合于商业领域应用，c语言和Ada语言适用于系统和实时应用领域，LISP语言适用于组合问题领域，PROLOG语言适于表达知识和推理。因此，选择语言时应该充分考虑目标系统的应用范围。7.1.2 编码风格 源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准，为了做到这一点，应该遵循下述规则。 1.程序内部的文档 所谓程序内部的文档包括恰当的标识符、适当的注解和程序的视觉组织等等。 选取含义鲜明的名字，使它能正确地提示程序对象所代表的实体，这对于帮助阅读者理解程序是很重要的。如果使用缩写，那么缩写规则应该一致，并且应该给每个名字加注解。 注解是程序员和程序读者通信的重要手段，正确的注解非常有助于对程序的理解。通常在每个模块开始处有一段序言性的注解，简要描述模块的功能、主要算法、接口特点、重要数据以及开发简史。插在程序中间与一段程序代码有关的注解，主要解释包含这段代码的必要性。对于用高级语言书写的源程序，不需要用注解的形式把每个语句翻译成自然语言，应该利用注解提供一些额外的信息。应该用空格或空行清楚地区分注解和程序。注解的内容一定要正确，错误的注解不仅对理解程序毫无帮助，反而会妨碍对程序的理解。 程序清单的布局对于程序的可读性也有很大影响，应该利用适当的阶梯形式使程序的层次结构清晰明显。2.数据说明虽然在设计期间已经确定了数据结构的组织和复杂程度，然而数据说明的风格却是在写程序时确定的。为了使数据更容易理解和维护，有一些比较简单的原则应该遵循。 数据说明的次序应该标准化(例如，按照数据结构或数据类型确定说明的次序)。有次序就容易查阅，因此能够加速测试、调试和维护的过程。 当多个变量名在一个语句中说明时，应该按字母顺序排列这些变量。 如果设计时使用了一个复杂的数据结构，则应该用注解说明用程序设计语言实现这个数据结构的方法和特点。 3.语句构造 设计期间确定了软件的逻辑结构，然而个别语句的构造却是编写程序的一个主要任务。构造语句时应该遵循的原则是，每个语句都应该简单而直接，不能为了提高效率而使程序变得过分复杂。下述规则有助于使语句简单明了： 不要为了节省空间而把多个语句写在同一行； 尽量避免复杂的条件测试； 尽量减少对“非”条件的测试； 避免大量使用循环嵌套和条件嵌套； 利用括号使逻辑表达式或算术表达式的运算次序清晰直观。 4.输入输出 在设计和编写程序时应该考虑下述有关输入输出风格的规则： 对所有输入数据都进行检验； 检查输入项重要组合的合法性； 保持输入格式简单； 使用数据结束标记，不要要求用户指定数据的数目； 明确提示交互式输入的请求，详细说明可用的选择或边界数值； 当程序设计语言对格式有严格要求时，应保持输入格式一致； 设计良好的输出报表； 给所有输出数据加标志。 5.效率 效率主要指处理机时间和存储器容量两个方面。虽然值得提出提高效率的要求，但是在进一步讨论这个问题之前应该记住3条原则：首先，效率是性能要求，因此应该在需求分析阶段确定效率方面的要求。软件应该像对它要求的那样有效，而不应该如同人类可能做到的那样有效。其次，效率是靠好设计来提高的。第三，程序的效率和程序的简单程度是一致的，不要牺牲程序的清晰性和可读性来不必要地提高效率。下面从三个方面进一步讨论效率问题。 (1)程序运行时间 源程序的效率直接由详细设计阶段确定的算法的效率决定，但是，写程序的风格也能对程序的执行速度和存储器要求产生影响。在把详细设计结果翻译成程序时，总可以应用下述规则： 写程序之前先简化算术的和逻辑的表达式； 仔细研究嵌套的循环，以确定是否有语句可以从内层往外移； 尽量避免使用多维数组； 尽量避免使用指针和复杂的表； 使用执行时间短的算术运算； 不要混合使用不同的数据类型； 尽量使用整数运算和布尔表达式。 在效率是决定性因素的应用领域，尽量使用有良好优化特性的编译程序，以自动生成高效目标代码。 (2)存储器效率 在大型计算机中必须考虑操作系统页式调度的特点，一般说来，使用能保持功能域的结构化控制结构，是提高效率的好方法。 在微处理机中如果要求使用最少的存储单元，则应选用有紧缩存储器特性的编译程序，在非常必要时可以使用汇编语言。 提高执行效率的技术通常也能提高存储器效率。提高存储器效率的关键同样是“简单”。 (3)输入输出的效率 如果用户为了给计算机提供输入信息或为了理解计算机输出的信息，所需花费的脑力劳动是经济的，那么人和计算机之间通信的效率就高。因此，简单清晰同样是提高人机通信效率的关键。 硬件之间的通信效率是很复杂的问题，但是，从写程序的角度看，却有些简单的原则可以提高输入输出的效率。例如： 所有输入输出都应该有缓冲，以减少用于通信的额外开销； 对二级存储器(如磁盘)应选用最简单的访问方法； 二级存储器的输入输出应该以信息组为单位进行； 如果“超高效的”输入输出很难被人理解，则不应采用这种方法。 这些简单原则对于软件工程的设计和编码两个阶段都适用。7.2软件测试基础 本节讲述软件测试的基本概念和基础知识。 表面看来，软件测试的目的与软件工程所有其他阶段的目的都相反。软件工程的其他阶段都是“建设性”的：软件工程师力图从抽象的概念出发，逐步设计出具体的软件系统，直到用一种适当的程序设计语言写出可以执行的程序代码。但是，在测试阶段测试人员努力设计出一系列测试方案，目的却是为了“破坏”已经建造好的软件系统竭力证明程序中有错误不能按照预定要求正确工作。 当然，这种反常仅仅是表面的，或者说是心理上的。暴露问题并不是软件测试的最终目的，发现问题是为了解决问题，测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。但是，仅就测试本身而言，它的目标可能和许多人原来设想的很不相同。7.2.1 软件测试的目标 什么是测试?它的目标是什么?G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义。 (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。 从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。 由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。 此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。关于这个结论下面还要讨论。7.2.2 软件测试准则 怎样才能达到软件测试的目标呢?为了能设计出有效的测试方案，软件工程师必须深入理解并正确运用指导软件测试的基本准则。下面讲述主要的测试准则。 (1)所有测试都应该能追溯到用户需求。正如上一小节讲过的，软件测试的目标是发现错误。从用户的角度看，最严重的错误是导致程序不能满足用户需求的那些错误。 (2)应该远在测试开始之前就制定出测试计划。实际上，一旦完成了需求模型就可以着手制定测试计划，在建立了设计模型之后就可以立即开始设计详细的测试方案。因此，在编码之前就可以对所有测试工作进行计划和设计。 (3)把Pareto原理应用到软件测试中。Pareto原理说明，测试发现的错误中的80很可能是由程序中20的模块造成的。当然，问题是怎样找出这些可疑的模块并彻底地测试它们。 (4)应该从“小规模”测试开始，并逐步进行“大规模”测试。通常，首先重点测试单个程序模块，然后把测试重点转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。 (5)穷举测试是不可能的。所谓穷举测试就是把程序所有可能的执行路径都检查一遍的测试。即使是一个中等规模的程序，其执行路径的排列数也十分庞大，由于受时间、人力和资源的限制，在测试过程中不可能执行每个可能的路径。因此，测试只能证明程序中有错误，不能证明程序中没有错误。但是，精心地设计测试方案，有可能充分覆盖程序逻辑并使程序达到所要求的可靠性。 (6)为了达到最佳的测试效果，应该由独立的第三方从事测试工作。所谓“最佳激果”是指有最大可能性发现错误的测试。由于前面已经讲过的原因，开发软件的软件工程师并不是完成全部测试工作的最佳人选(通常他们主要承担模块测试工作)。7.2.3 测试方法 测试任何产品都有两种方法：如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用；如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。前一种方法称为黑盒测试，后一种法称为白盒测试。 对于软件测试而言，黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息(例如，数据库或文件)的完整性。黑盒测试又称为功能测试。 白盒测试法与黑盒测试法相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试又称为结构测试。7.2.4 测试步骤 除非是测试一个小程序，否则一开始就把整个系统作为一个单独的实体来测试是不现实的。根据第4条测试准则，测试过程也必须分步骤进行，后一个步骤在逻辑上是前一个步骤的继续。大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成，因此，大型软件系统的测试过程基本上由下述几个步骤组成。1.模块测试 在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。2.子系统测试 子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。3.系统测试 系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。 不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。4.验收测试 验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。验收测试也称为确认测试。 5.平行运行 . 关系重大的软件产品在验收之后往往并不立即投入生产性运行，而是要再经过一段平行运行时间的考验。所谓平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。这样做的具体目的有如下几点： (1)可以在准生产环境中运行新系统而又不冒风险； (2)用户能有一段熟悉新系统的时间； (3)可以验证用户指南和使用手册之类的文档； (4)能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。 以上集中讨论了与测试有关的概念，但是，测试作为软件工程的一个阶段，它的根本任务是保证软件的质量，因此除了进行测试之外，还有另外一些与测试密切相关的工作应该完成。这就是下一小节要讨论的内容。7.2.5 测试阶段的信息流 图7.1描绘了测试阶段的信息流，这个阶段的输入信息有两类：(1)软件配置，包括需求说明书、设计说明书和源程序清单等；(2)测试配置，包括测试计划和测试方案。所谓测试方案不仅仅是测试时使用的输入数据(称为测试用例)，还应该包括每组输入数据预定要检验的功能，以及每组输入数据预期应该得到的正确输出。实际上测试配置是软件配置的一个子集，最终交出的软件配置应该包括上述测试配置以及测试的实际结果和调试的记录。 比较测试得出的实际结果和预期的结果，如果两者不一致则很可能是程序中有错误。设法确定错误的准确位置并且改正它，这就是调试的任务。与测试不同，通常由程序的编写者负责调试。 在对测试结果进行收集和评价的时候，软件可靠性所达到的定性指标也开始明朗了。如果经常出现要求修改设计的严重错误，那么软件的质量和可靠性是值得怀疑的，应该进测试 测试 测试 测试 图7.1 测试阶段的信息流 一步仔细测试。反之，如果看起来软件功能完成得很正常，遇到的错误也很容易改正，则仍然应该考虑两种可能：(1)软件的可靠性是可以接受的；(2)所进行的测试尚不足以发现严重的错误。最后，如果经过测试，一个错误也没有被发现，则很可能是因为对测试配置思考不充分，以致不能暴露软件中潜藏的错误。这些错误最终将被用户发现，而且需要在维护阶段改正它们(但是改正同一个错误需要付出的代价比在开发阶段高出许多倍)。 在测试阶段积累的结果，也可以用更形式化的方法进行评价。软件可靠性模型使用错误率数据估计将来出现错误的情况，并进而对软件可靠性进行预测。7.3单元测试 单元测试集中检测软件设计的最小单元模块。通常，单元测试和编码属于软件过程的同一个阶段。在编写出源程序代码并通过了编译程序的语法检查之后，就可以用详细设计描述作指南，对重要的执行通路进行测试，以便发现模块内部的错误。可以应用人工测试和计算机测试这样两种不同类型的测试方法，完成单元测试工作。这两种测试方法各有所长，互相补充。通常，单元测试主要使用白盒测试技术，而且对多个模块的测试可以并行地进行。7.3.1 测试重点 在单元测试期间着重从下述5个方面对模块进行测试。 1.模块接口 首先应该对通过模块接口的数据流进行测试，如果数据不能正确地进出，所有其他测试都是不切实际的。 在对模块接口进行测试时主要检查下述几个方面：参数的数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致。 2.局部数据结构 对于模块来说，局部数据结构是常见的错误来源。应该仔细设计测试方案，以便发现局部数据说明、初始化、默认值等方面的错误。 3.重要的执行通路 由于通常不可能进行穷尽测试，因此，在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。 4.出错处理通路 好的设计应该能预见出现错误的条件，并且设置适当的处理错误的通路，以便在真的出现错误时执行相应的出错处理通路或干净地结束处理。不仅应该在程序中包含出错处理通路而且应该认真测试这种通路。当评价出错处理通路时，应该着重测试下述一些可能发生的错误： (1)对错误的描述是难以理解的； (2)记下的错误与实际遇到的错误不同； (3)在对错误进行处理之前，错误条件已经引起系统干预； (4)对错误的处理不正确； (5)描述错误的信息不足以帮助确定造成错误的位置。 5.边界条件 边界测试是单元测试中最后的也可能是最重要的任务。软件常常在它的边界上失效，例如，处理n元数组的第n个元素时，或做到i次循环中的第i次重复时，往往会发生错误。使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误。7.3.2 代码审查 人工测试源程序可以由编写者本人非正式地进行，也可以由审查小组正式进行。后者称为代码审查，它是一种非常有效的程序验证技术，对于典型的程序来说，可以查出30 9，670的逻辑设计错误和编码错误。审查小组最好由下述4人组成： (1)组长，应该是一个很有能力的程序员，而且没有直接参与这项工程； (2)程序的设计者； (3)程序的编写者； (4)程序的测试者。 如果一个人既是程序的设计者又是编写者，或既是编写者又是测试者，则审查小组中应该再增加一个程序员。 审查之前，小组成员应该先研究设计说明书，力求理解这个设计。为了帮助理解，可以先由设计者扼要地介绍他的设计。在审查会上由程序的编写者解释他是怎样用程序代码实现这个设计的，通常是逐个语句地讲述程序的逻辑，小组其他成员仔细倾听他的讲解，并力图发现其中的错误。审查会上进行的另外一项工作，是对照类似于上一小节中介绍的程序设计常见错误清单，分析审查这个程序。当发现错误时由组长记录下来，审查会继续进行(审查小组的任务是发现错误而不是改正错误)。 审查会还有另外一种常见的进行方法，称为预排：由一个人扮演“测试者”，其他人扮演“计算机”。会前测试者准备好测试方案，会上由扮演计算机的成员模拟计算机执行被测试的程序。当然，由于人执行程序速度极慢，因此测试数据必须简单，测试方案的数目也不能过多。但是，测试方案本身并不十分关键，它只起一种促进思考引起讨论的作用。在大多数情况下，通过向程序员提出关于他的程序的逻辑和他编写程序时所做的假设的疑问，可以发现的错误比由测试方案直接发现的错误还多。 代码审查比计算机测试优越的是：一次审查会上可以发现许多错误；用计算机测试的方法发现错误之后，通常需要先改正这个错误才能继续测试，因此错误是一个一个地发现并改正的。也就是说，采用代码审查的方法可以减少系统验证的总工作量。 实践表明，对于查找某些类型的错误来说，人工测试比计算机测试更有效；对于其他类型的错误来说则刚好相反。因此，人工测试和计算机测试是互相补充，相辅相成的，缺少其中任何一种方法都会使查找错误的效率降低。7.3.3 计算机测试 模块并不是一个独立的程序，因此必须为每个单元测试开发驱动软件和(或)存根软件。通常驱动程序也就是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块，并且印出有关的结果。存根程序代替被测试的模块所调用的模块。因此存根程序也可以称为“虚拟子程序”。它使用被它代替的模块的接口，可能做最少量的数据操作，印出对入口的检验或操作结果，并且把控制归还给调用它的模块。 例如，图7.2是一个正文加工系统的部分层次图，假定要测试其中编号为3.O的关键模块正文编辑模块。因为正文编辑模块不是一个独立的程序，所以需要有一个测试驱动程序来调用它。这个驱动程序说明必要的变量，接收测试数据字符串，并且设置正文编辑模块的编辑功能。因为在原来的软件结构中，正文编辑模块通过调用它的下层正文加工系统输入1.0 输出2.0 插入3.3 编辑3.0 删除3.2 加标题 4.0 编目录7.0 检索6.0 合并3.5 修改3.4 列表3.6 添加3.1 存储5.0 格式化 8.0 图7.2 正文加工系统的层次图模块来完成具体的编辑功能，所以需要有存根程序简化地模拟这些下层模块。为了简单起见，测试时可以设置的编辑功能只有修改(CHANGE)和添加(APPEND)两种，用控制变量CFUNCT标记要求的编辑功能，而且只用一个存根程序模拟正文编辑模块的所有下层模块。下面是用伪码书写的存根程序和驱动程序。 I.TEST STUB(*测试正文编辑模块用的存根程序*) 初始化； 输出信息“进入了正文编辑程序”； 输出“输入的控制信息是”CFUNCT； 输出缓冲区中的字符串； IF CFUNCT=CHANGE THEN 把缓冲区中第二个字改为 * * * ELSE 在缓冲区的尾部加? END IF； 输出缓冲区中的新字符串； END TEST STUB .TEST DRIVER(*测试正文编辑模块用的驱动程序*) 说明长度为2 500个字符的一个缓冲区； 把CFUNCT置为希望测试的状态； 输入字符串； 调用正文编辑模块； 停止或再次初启； END TEST DRIVER 驱动程序和存根程序代表开销，也就是说，为了进行单元测试必须编写测试软件，但是通常并不把它们作为软件产品的一部分交给用户。许多模块不能用简单的测试软件充分测试，为了减少开销可以使用下节将要介绍的渐增式测试方法，在集成测试的过程中同时完成对模块的详尽测试。 模块的内聚程度高可以简化单元测试过程。如果每个模块只完成一种功能，则需要的测试方案数目将明显减少，模块中的错误也更容易预测和发现。7.4集成测试 集成测试是测试和组装软件的系统化技术，例如，子系统测试即是在把模块按照设计要求组装起来的同时进行测试，主要目标是发现与接口有关的问题(系统测试与此类似)。例如，数据穿过接口时可能丢失；一个模块对另一个模块可能由于疏忽而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等等。不幸的是，可能发生的接口问题多得不胜枚举。 由模块组装成程序时有两种方法。一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非渐增式测试方法；另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法称为渐增式测试，这种方法实际上同时完成单元测试和集成测试。这两种方法哪种更好一些呢?下面对比它们的主要优缺点： 非渐增式测试一下子把所有模块放在一起，并把庞大的程序作为一个整体来测试，测试者面对的情况十分复杂。测试时会遇到许许多多的错误，改正错误更是极端困难，因为在庞大的程序中想要诊断定位一个错误是非常困难的。而且一旦改正一个错误之后，马上又会遇到新的错误，这个过程将继续下去，看起来好像永远也没有尽头。 渐增式测试与“一步到位”的非渐增式测试相反，它把程序划分成小段来构造和测试，在这个过程中比较容易定位和改正错误；对接口可以进行更彻底的测试；可以使用系统化的测试方法。因此，目前在进行集成测试时普遍采用渐增式测试方法。 当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。7.4.1 自顶向下集成 自顶向下集成方法是一个日益为人们广泛采用的测试和组装软件的途径。从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。在把附属于(及最终附属于)主控制模块的那些模块组装到程序结构中去时，或者使用深度优先的策略，或者使用宽度优先的策略。 参看图7.3，深度优先的结合方法先组装在软件结构的一条主控制通路上的所有模块。选择一条主控制通路取决于应用的特点，并且有很大任意性。例如，选取左通路，首先结合模块M1、M2和M5；其次，M8或M6(如果为了使M。具有适当功能需要M6)将被结合进来。然后构造中央的和右侧的控制通路。而宽度优先的结合方法是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。对于图7.3来说，首先结合模块M2、M3和M4(代替存根程序S4)，然后结合下一个控制层次中的模块M5、M6和M7；如此继续进行下去，直到所有模块都被结合进来为止。 S4 M1 M3 M2 M6 S7 M5 M8 图7.3 自顶向下结合 把模块结合进软件结构的具体过程由下述4个步骤完成： 第一步，对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块； 第二步，根据选定的结合策略(深度优先或宽度优先)，每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序)； 第三步，在结合进一个模块的同时进行测试； 第四步，为了保证加入模块没有引进新的错误，可能需要进行回归测试(即，全部或部分地重复以前做过的测试)。 从第二步开始不断地重复进行上述过程，直到构造起完整的软件结构为止。图7.3描绘了这个过程。假设选取深度优先的结合策略，软件结构已经部分地构造起来了，下一步存根程序S7，将被模块M7，取代。M7可能本身又需要存根程序，以后这些存根程序也将被相应的模块所取代。 自顶向下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验。在一个分解得好的软件结构中，关键的抉择位于层次系统的较上层，因此首先碰到。如果主要控制确实有问题，早期认识到这类问题是很有好处的，可以及早想办法解决。如果选择深度优先的结合方法，可以在早期实现软件的一个完整的功能并且验证这个功能。早期证实软件的一个完整的功能，可以增强开发人员和用户双方的信心。 自顶向下的方法讲起来比较简单，但是实际使用时可能遇到逻辑上的问题。这类问题中最常见的是，为了充分地测试软件系统的较高层次，需要在较低层次上的处理。然而在自顶向下测试的初期，存根程序代替了低层次的模块，因此，在软件结构中没有重要的数据自下往上流。为了解决这个问题，测试人员有两种选择：第一，把许多测试推迟到用真实模块代替了存根程序以后再进行；第二，从层次系统的底部向上组装软件。第一种方法失去了在特定的测试和组装特定的模块之间的精确对应关系，这可能导致在确定错误的位置和原因时发生困难。后一种方法称为自底向上的测试，下面讨论这种方法。7.4.2 自底向上集成 自底向上测试从“原子”模块(即在软件结构最低层的模块)开始组装和测试。因为是从底部向上结合模块，总能得到所需的下层模块处理功能，所以不需要存根程序。 用下述步骤可以实现自底向上的结合策略： 第一步，把低层模块组合成实现某个特定的软件子功能的族； 第二步，写一个驱动程序(用于测试的控制程序)，协调测试数据的输入和输出； 第三步，对由模块组成的子功能族进行测试； 第四步，去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。 上述第二步到第四步实质上构成了一个循环。图7.4描绘了自底向上的结合过程。首先把模块组合成族1、族2和族3，使用驱动程序(图中用虚线方框表示)对每个子功能族进行测试。族1和族2中的模块附属于模块Ma，去掉驱动程序D1和D2，把这两个族直接同Ma连接起来。类似地，在和模块Mb结合之前去掉族3的驱动程序D3。最终M8和Mb这两个模块都与模块Mc结合起来。 Mc Mc Mb Ma D1 D2 D3 族1 族2 族3 图7.4 自底向上结合合 随着结合向上移动，对测试驱动程序的需要也减少了。事实上，如果软件结构的顶部两层用自顶向下的方法组装，可以明显减少驱动程序的数目，而且族的结合也将大大简化。7.4.3 不同集成测试策略的比较 上面介绍了集成测试的两种策略，到底哪种方法更好一些呢?一般说来，一种方法的优点正好对应于另一种方法的缺点。自顶向下测试方法的主要优点是不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。自顶向下测试方法的主要缺点是需要存根程序，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。可以看出，自底向上测试方法的优缺点与上述自顶向下测试方法的优缺点刚好相反。 在测试实际的软件系统时，应该根据软件的特点以及工程进度安排，选用适当的测试策略。一般说来，纯粹自顶向下或纯粹自底向上的策略可能都不实用，人们在实践中创造出许多混合策略： (1)改进的自顶向下测试方法。基本上使用自顶向下的测试方法，但是在早期使用自底向上的方法测试软件中的少数关键模块。一般的自顶向下方法所具有的优点在这种方法中也都有，而且能在测试的早期发现关键模块中的错误；但是，它的缺点也比自顶向下方法多一条，即测试关键模块时需要驱动程序。 (2)混合法。对软件结构中较上层使用的自顶向下方法与对软件结构中较下层使用的自底向上方法相结合。这种方法兼有两种方法的优点和缺点，当被测试的软件中关键模块比较多时，这种混合法可能是最好的折衷方法。7.4.4 回归测试 在集成测试过程中每当一个新模块结合进来时，程序就发生了变化：建立了新的数据流路径，可能出现了新的IO操作，激活了新的控制逻辑。这些变化有可能使原来工作正常的功能出现问题。在集成测试的范畴中，所谓回归测试是指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。 更广义地说，任何成功的测试都会发现错误，而且错误必须被改正。每当改正软件错误的时候，软件配置的某些成分(程序、文档或数据)也被修改了。回归测试就是用于保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动。 回归测试可以通过重新执行全部测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具自动进行。利用捕获回放工具，软件工程师能够捕获测试用例和实际运行结果，然后可以回放(即重新执行测试用例)，并且比较软件变化前后所得到的运行结果。 回归测试集(已执行过的测试用例的子集)包括下述3类不同的测试用例： (1)检测软件全部功能的代表性测试用例； (2)专门针对可能受修改影响的软件功能的附加测试； (3)针对被修改过的软件成分的测试。 在集成测试过程中，回归测试用例的数量可能变得非常大。因此，应该把回归测试集设计成只包括可以检测程序每个主要功能中的一类或多类错误的那样一些测试用例。一旦修改了软件之后就重新执行检测程序每个功能的全部测试用例，是低效而且不切实际的。7.5确认测试 确认测试也称为验收测试，它的目标是验证软件的有效性。 上面这句话中使用了确认(validation)和验证(verification)这样两个不同的术语，为了避免混淆，首先扼要地解释一下这两个术语的含义。通常，验证指的是保证软件正确地实现了某个特定要求的一系列活动，而确认指的是为了保证软件确实满足了用需求而进行的一系列活动。 那么，什么样的软件才是有效的呢?软件有效性的一个简单定义是：如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的。 需求分析阶段产生的软件需求规格说明书，准确地描述了用户对软件的合理期望，因此是软件有效性的标准，也是进行确认测试的基础。7.5.1 确认测试的范围 确认测试必须有用户积极参与，或者以用户为主进行。用户应该参与设计测试方案，使用用户界面输入测试数据并且分析评价测试的输出结果。为了使得用户能够积极主动地参与确认测试，特别是为了使用户能有效地使用这个系统，通常在验收之前由开发单位对用户进行培训。 确认测试通常使用黑盒测试法。应该仔细设计测试计划和测试过程，测试计划包括要进行的测试的种类及进度安排，测试过程规定了用来检测软件是否与需求一致的测试方案。通过测试和调试要保证软件能满足所有功能要求，能达到每个性能要求，文档资料是准确而完整的，此外，还应该保证软件能满足其他预定的要求(例如，安全性、可移植性、兼容性和可维护性等)。 确认测试有下述两种可能的结果： (1)功能和性能与用户要求一致，软件是可以接受的； (2)功能和性能与用户要求有差距。 在这个阶段发现的问题往往和需求分析阶段的差错有关，涉及的面通常比较广，因此解决起来也比较困难。为了制定解决确认测试过程中发现的软件缺陷或错误的策略，通常需要和用户充分协商。7.5.2软件配置复查 确认测试的一个重要内容是复查软件配置。复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。 除了按合同规定的内容和要求，由人工审查软件配置之外，在确认测试过程中还应该严格遵循用户指南及其他操作程序，以便检验这些使用手册的完整性和正确性。必须仔细记录发现的遗漏或错误，并且适当地补充和改正。7.5.3 AIpha和Beta测试 如果软件是专为某个客户开发的，可以进行一系列验收测试，以便用户确认所有需求都得到满足了。验收测试是由最终用户而不是系统的开发者进行的。事实上，验收测试可以持续几个星期甚至几个月，因此能够发现随着时间流逝可能会降低系统质量的累积错误。 如果一个软件是为许多客户开发的(例如，向大众公开出售的盒装软件产品)，那么，让每个客户都进行正式的验收测试是不现实的。在这种情况下，绝大多数软件开发商都使用被称为Alpha测试和Beta测试的过程，来发现那些看起来只有最终用户才能发现的错误。 Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。 Beta测试由软件的最终用户们在一个或多个客户场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在Beta测试过程中遇到的一切问题(真实的或想像的)，并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。7.6白盒测试技术 设计测试方案是测试阶段的关键技术问题。所谓测试方案包括具体的测试目的(例如，预定要测试的具体功能)，应该输入的测试数据和预期的结果。通常又把测试数据和预期的输出结果称为测试用例。其中最困难的问题是设计测试用的输入数据。 不同的测试数据发现程序错误的能力差别很大，为了提高测试效率降低测试成本，应该选用高效的测试数据。因为不可能进行穷尽的测试，选用少量“最有效的”测试数据，做到尽可能完备的测试就更重要了。 设计测试方案的基本目标是，确定一组最可能发现某个错误或某类错误的测试数据。已经研究出许多设计测试数据的技术，这些技术各有优缺点，没有哪一种是最好的，更没有哪一种可以代替其余所有技术；同一种技术在不同的应用场合效果可能相差很大，因此，通常需要联合使用多种设计测试数据的技术。 本节讲述在用白盒方法测试软件时设计测试数据的典型技术，下一节讲述在用黑盒方法测试软件时设计测试数据的典型技术。7.6.1 逻辑覆盖 有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。所谓逻辑覆盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。测试数据执行(或叫覆盖)程序逻辑的程度可以划分成哪些不同的等级呢?从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准。 1.语句覆盖 为了暴露程序中的错误，至少每个语句应该执行一次。语句覆盖的含义是，选择足够多的测试数据，使被测程序中每个语句至少执行一次。例如，图7.5所示的程序流程图描绘了一个被测模块的处理算法。 为了使每个语句都执行一次，程序的执行路径应该是sacbed，为此只需要输入下面的测试数据(实际上X可以是任意实数)： 语句覆盖对程序的逻辑覆盖很少，在上面例子中两个判定条件都只测试了条件为真的情况，如果条件为假时处理有错误，显然不能发现。此外，语句覆盖只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值时的情况。在上面的例子中，为了执行sacbed路径，以测试每个语句，只需两个判定表达式(A1)AND(B=0)和(A=2)OR(X1)都取真值，因此使用上述一组测试数据就够了。但是，如果程序中把第一个判定表达式中的逻辑运算符AND错写成“0R”，或把第二个判定表达式中的条件“X1”误写成“X1 AND B=0X=X/A T 4 4F 5 A=2 OR X1 X=X/A T 6 4F 7 S a b c e 返回 图7.5 被测试模块的流程图 2.判定覆盖 判定覆盖又叫分支覆盖，它的含义是，不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。 对于上述例子来说，能够分别覆盖路径sacbed和sabd的两组测试数据，或者可以分别覆盖路径sacbd和sabed的两组测试数据，都满足判定覆盖标准。例如，用下面两组测试数据就可做到判定覆盖： I. A=3，B=O，X=3 (覆盖sacbd) .A=2，B=1，X=1 (覆盖sabed) 判定覆盖比语句覆盖强，但是对程序逻辑的覆盖程度仍然不高，例如，上面的测试数据只覆盖了程序全部路径的一半。 3.条件覆盖 条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。 图7.5的例子中共有两个判定表达式，每个表达式中有两个条件，为了做到条件覆盖，应该选取测试数据使得在a点有下述各种结果出现： A1，A1，B=O，BO在b点有下述各种结果出现： A=2，A2，X1，X1只需要使用下面两组测试数据就可以达到上述覆盖标准： I.A=2，B=O，X=4 (满足A1，B=O，A=2和X1的条件，执行路径sacbed) .A=1，B=1，X=1 (满足A1，B0，A2和X1的条件，执行路径sabd) 条件覆盖通常比判定覆盖强，因为它使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值。例如，上面两组测试数据也同时满足判定覆盖标准。但是，也可能有相反的情况：虽然每个条件都取到了两个不同的结果，判定表达式却始终只取一个值。例如，如果使用下面两组测试数据，则只满足条件覆盖标准并不满足判定覆盖标准(第二个判定表达式的