计算机系统概论十五章.doc

《计算机系统概论十五章.doc》由会员分享，可在线阅读，更多相关《计算机系统概论十五章.doc（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第十五章 测试和调试15.1 绪论在1999年的十二月，美国国家航空和宇宙航行局（NASA）任务控制中心在火星极地着陆者号接近火星表面时失去了与它的联系。极地着陆者号这次的任务是去探测火星的南极地区。从那以后联系就中断了，美国国家航空和宇宙航行局宣布飞行器很可能在着陆过程中坠毁了。在评估了当时的情况后，调查组认为事故可能是由控制软件的错误造成的，它在探测器距火星表面还有40米而不是着陆时就过早的关闭了板上发动机。发送探测器在物理上的复杂性使人吃惊，而控制飞行器的软件系统同样也不简单。软件和构成一个系统的任何一个机械或电子子系统相同，而做好软件更困难是因为它是不可视的。它不像推进系统或着陆系统一

2、样可以容易地被观测到。 软件现在无处不在。它在你的手机里，在你的汽车里甚至你看到的这本书的正文出现于你面前之前，也是被无数行的软件处理于十分老式的打印页面上。由于软件在我们现实世界中扮演着重要而关键的角色，所以软件根据要求正确的运行是很重要的。设计工作程序不是自动的。只构建程序是不正确的。那时因为，仅仅写了一个程序并不意味着它可以正确的运行。在我们认为可以完成它之前，我们必须尽可能的彻底测试和调试它。程序员花在调试上的时间经常要比花在写程序上的时间长。专家们做出的一个关于这方面的普遍性调查显示：一个熟练的程序员花在调试代码上的时间和花在写程序上的时间一样多。因为写代码与测试、调试的不可分性，我

3、们会在这一章中向你介绍一些基本的测试和调试的概念。测试是找出错误的过程，而调试是去除错误的过程。为了使软件暴露出它们的错误，测试一段代码包括提供尽可能多的输入条件。例如，在前面的章节中函数ToUpper的测试过程中（回忆这个函数返回了作为参数传递的字母的大写形式），我们为了检查这个函数是否按照规格说明的那样运行，我们可能希望传递每一个可能的ASCII码值作为输入的参数，同时观察这个函数的输出。如果这个函数在一个特殊的输入下产生了一个错误的输出，那么我们就发现了一个错误。在代码还处在开发阶段发现错误，远比一个没有怀疑过软件的用户在不经意间被这个错误“绊倒”要好。要是NASA（美国国家航空和宇宙航

4、行局）的软件工程师在地球上发现火星探测者号的错误，而不是在距火星表面40米才遇到错误就好了。通过一个程序的信息和它的执行，程序员就可以应用常识找出错误产生的位置。调试一个程序有点像解决一个谜语。就像一个犯罪场景中的侦探一样，程序员为了找出问题的根源，必须检查出现的线索。如果你知道如何收集关于错误的信息，调试代码就会更容易，例如在程序执行过程中用系统的方法，收集主要变量的值。在这一章中，我们描述了一些可以用来在程序中查找和纠正错误的技术。我们先介绍一些在程序中出现的错误种类。接着，我们会描述一些快速发现这些错误的测试方法。最后我们会描述一些可以用来隔离和修复这些错误的调试技术，同时我们会提供一些

5、防御性的编程技术，使你写的代码中的错误最小化。15.2 错误类型为了更好的理解如何找出并修复程序中的错误，首先理解我们写的程序中出现的几种错误类型是很有用的。在你的代码里可能会遇到三类错误。语法错误是最容易处理的，因为它们会被编译器捕获。当编译器试图把源代码翻译成机器代码时，会把这样的错误报告给我们，通常会精确指出错误出现在哪一行。另一方面，语义错误往往是我们最难纠正的错误。它们出现在当程序语法上正确却无法如我们期望的那样运行的时候。语法和语义错误一般都是字符排列上的错误：常常出现在我们键入的字符并不是我们的本意的时候。而算法错误则是我们解决问题的方法是错误的。它们常常很难被检测到，一旦被发现

6、，也很难纠正。15.2.1语法错误在C语言中，语法错误（或句法错误，或语法分析错误）总能被编译器捕获。当我们让编译器翻译那些与C语言规范不一致的代码时，会出现这些错误。例如，图15.1中所列的代码包含一个语法错误，当这段代码被编译的时候编译器会标记出这个错误。对变量i的声明少了一个分号。作为编写C语言程序的新手，缺少分号和对变量的声明会占到你遇到的语法错误的大多数。幸运的是，这种类型的错误很容易发现，因为编译器会检测到它们，并且很容易纠正，因为编译器指明了它们在哪里出现。一旦语法错误被纠正，真正的问题就出现了，更困难的语义和算法错误还没有被纠正。15.2.2 语义错误语义错误与语法错误相似。它

7、们的产生原因相同：当我们键入一个程序的时候，我们的思维和手指不可能完全的一致。语义错误不包括不正确的语法，因此，程序可以被翻译，我们能够执行它。只有我们分析了输出后我们才会发现程序不像期望的那样运行。图15.2列出了一个存在一个简单的语义错误（语法错误被纠正了）的和图15.1相同的例子。这个程序应该打印出一个数字7的乘法表。在此，程序的一次执行揭示了这个问题。只打印出乘法表中的一行。以你所掌握的C程序设计语言的知识，你应该能够推论出，为什么这个程序错误地执行。为什么打印出117=70？这个程序显示了被称为控制流程错误的一种错误。在此，程序的控制流程，或语句被执行的顺序，与我们所期望的不同。图1

8、5.3中列出的代码包含一个常见的，却是难处理的包含局部变量的语义错误。这个例子与我们在14.2节中讨论的阶乘的程序相似。这个程序计算的是所有小于或等于从键盘中输入的数字的和（即计算1+2+3+.+n）。试运行这个程序，你将会发现，输出的结果不是你期望的结果。为什么这个程序不能正常地运行呢？提示：画出一个这个程序执行的运行时栈。语义错误是特别麻烦的，因为它们经常不能被编译器和程序员检测到，直到某个特别的输入集引起错误发生。回到图15.3中的AllSum程序，但是要修改之前的语义错误，并且要注意如果传给AllSum的数值小于或等于0或太大，那么AllSum将会返回一个错误的结果，因为它超过了整数变

9、量result的范围。纠正前一个的错误，编译这个程序，并且输入一个小于1的数，你将会注意到另外一个错误。一些错误在执行程序的过程中被发现，因为一个非法的行为被程序执行。几乎所有的计算机系统都有阻止一个程序去执行可能会影响其它无关的程序的行为的保护措施。例如，不希望一个用户程序去修改存储了操作系统的存储单元，或是去写一个可能影响其它程序的控制寄存器，例如一个引起计算机关机的控制寄存器。当那样的非法行为被一个程序执行时，操作系统就会终止它的执行，并输出一个运行时错误消息。修改AllSum例子中的scanf语句为如下语句：scanf(%d,in)；在这种情况下，字符“&”，正如我们将会在16章看到的

10、，是C语言中的一个特殊运算符。在这里省略它，将产生一个运行时错误，因为程序正试图去修改一个它不能访问的存储单元。我们将会在后面的章节中详细查看这个例子和错误产生的原因。15.2.3 算法错误算法错误是不正确的程序设计的结果。也就是说，程序本身准确的按照我们所设计的运行了，但是这种设计本身有缺陷。这种错误非常隐蔽，它们可能经过许多次运行程序的试验才会被发现。甚至当它们被检测到并且被隔离后，仍然很难修复。好消息是在写代码之前的设计阶段，通过一个恰当的规划，这种错误经常能够被减少甚至消除。图15.4 提供了一个有个简单的算法缺陷的程序的例子。这段代码要求输入一个年份并且判断这一年是否为闰年。初看一眼

11、，这段代码似乎是对的。闰年的确是4年出现一次。但是闰年除了每4个世纪之外，还要忽略掉每一个世纪的交界处（即，2000年是闰年，但是2100、2200、2300都不是闰年）。这段代码对几乎所有年份都用效，除了那些在这些例外中的情况。我们把这个归为算法错误或者设计缺陷的类型中。另一个算法错误的例子也与日期有关，这就是臭名昭著的千年虫问题（Y2K）。许多计算机程序把存储日期所需要的存储量减到最少。它们采用的位数只够存储年份的最后两位数字。因此，2000年无法与1900年区别开来（或1800或2100也是这样）。在最近的世纪相交期间的1999年12月31日，这引起了一个问题。也就是说，例如，你已经在1

12、999年末从大学图书馆借了一本书，它应该在2000年初按期归还。如果图书馆计算机系统遭受了千年虫，你就会受到一个过期警告的邮件通知，上面有一张高额的罚单。因此，大量的人力财力投入到在2000年1月1日前解决千年虫的问题上来。15.3 测试具有丰富经验的程序员之间有这么一句谚语：任何一行没有经过测试的代码都可能是有错误的。好的测试技术对编写一个好的软件起至关重要的作用。什么是测试呢？使用测试，基本上我们是将这个软件进行试验，对其应用不同的输入组合（为了模拟在真实的情况下软件将要遇到的问题），并且将程序的输出结果进行正确性检查。现实世界中的软件在发布之前都需要经过无数次的试验。在一个理想的情况下，

13、我们可以通过在所有可能的输入条件下，检查程序的操作，对其进行测试。但是对于一个程序而言，测试并不只是试验，对所有的输入情况进行测试是不可能的。例如，如果我们想对一个判断从A到B之间某个数字是不是素数的程序进行测试，其中A和B都是32位的输入的数值，那么就有(232)2种可能的输入组合。即使我们一秒钟能进行一百万次测试，那么也会需要花费50万年来完成这项测试工作。很明显，对每一个输入组合进行测试不是一种可选的方法。那么我们应该对哪些输入组合进行测试呢？我们可以随机的选择一些输入，希望这些随机的组合中的一些输入能够揭示出这个程序的错误所在。软件工程师典型的依赖于一些更加系统化的方法来对他们的代码来

14、进行测试。特别的，黑盒测试是用来检查一个程序是否符合它的规格说明，而白盒测试则是为了确保每一行代码都被测试，以实现程序的不同方面为目标。15.3.1 黑盒测试通过黑盒测试，我们来检查程序是否满足其输入和输出规格说明，而忽略程序内部。也就是说，使用黑盒测试，我们只关心这个程序是做什么的，而不是它是怎么做的。例如，在图15.3中的AllSum程序的一个黑盒测试可能包括运行程序，键入一个输入的数字，以及将输出结果与你所手算的结果相比较。如果两者不相符，那么要么是程序包含一个错误，要么是你的算术技巧不是很好。我们会继续试验，直到有理由相信程序是可以使用的。对于测试更大的程序，为了在单位时间内运行更多的

15、测试，测试过程是自动的。也就是说，我们创建另一个程序，此程序可以自动运行原来的程序，提供一些随机的输入，检查输出是否符合规格说明，然后重复。使用那样的过程，与每次试验由人来执行相比，我们无疑可以运行更多的试验。为了使黑盒测试自动化，然而，我们需要一种方法去自动测试程序的输出结果是否正确。此时，我们可能需要去构建一个检查器程序，它与原来的程序不同，但都执行类似的计算。若原来的程序与检查器程序有着相同的错误，那么通过黑盒测试过程，错误是检查不出来的。基于这个原因，那些写检查器程序的黑盒测试员通常不允许去看他们正在测试的黑盒里面的代码，以便我们可以获得一个真正独立的检查器的版本。15.3.2 白盒测

16、试对于更大的软件系统，黑盒测试是远远不够的。使用黑盒测试，不可能知道哪几行代码已被测试过，哪些还没被测试，所以，根据前面说过的谚语，所有的都被假定为错误的。当一个程序的输入或输出规格说明不是很具体的时候，用黑盒测试有时是很困难的。例如，因为输出结果的不精确性，一个音频播放器（如一个MP3播放器）的黑盒测试可能是很困难的。此外，黑盒测试只在软件完成时开始为了被测试，软件必须编译并且必须满足规格说明中的一部分。软件工程师用白盒测试补充黑盒测试。白盒测试隔离了软件内部的各组件，并测试这些组件是否与设计相一致。比如说，查看每个函数是否按照设计正确执行的测试就是白盒测试。我们如何把程序划分成函数，是执行

17、的一部分而不是规格说明的一部分。我们可以把同样类型的测试应用到循环和函数内部的其他一些结构中。如何构建白盒测试呢？对于很多测试，我们可能需要修改代码本身。例如，为了检查一个函数是否正确运行，我们可能会添加额外的代码，用不同的输入多调用函数几次，并核对输出。我们可能会添加额外的printf语句到代码中，借以观察内部变量的值，查看程序是否按照预期的运行。一旦代码被完成测试并准备发布，这些printf语句就能够被移走了。在程序内使用策略性放置的检测错误的代码是一种普遍应用的白盒测试技术。这些代码会检查能够造成程序运行不正确的条件。当一个不正确的状态被检测到时，这些代码就会打印出一个警告消息，显示该状

18、态的一些相关信息，或者使程序提前终止。既然这些检测错误的代码断言程序执行期间存在某种条件，我们一般将其称为断言。例如，错言可以用来检查一个函数是否返回了一个在预期范围内的值。假如返回值超出了这个范围，就会显示一条错误信息。在下面的例子中，我们检查由函数IncomeTax执行的计算是否在合理的范围内。正如你能根据代码段推想的那样，该函数根据一个作为参数提供给它的特定的收入，计算所得税。我们不能支付超过收入的税额（很幸运！），我们也不能支付负的税额。在此，如果IncomeTax中的计算不正确，通过断言代码，就会显示一条警告信息。一个彻底的测试方法需要同时使用黑盒测试和白盒测试。认识到这一点很重要：

19、仅仅使用白盒测试无法覆盖软件的所有功能，即使通过了所有的白盒测试，也有可能遗漏了软件的某一部分规格说明。类似的，仅仅使用黑盒测试无法确保每一行代码都被测试过。15.4 调试一旦找到了一个错误，我们就要开始修复它，这也往往比寻找它们更需要技巧。调试一个错误需要充分使用分析的技巧：我们观察错误的症状，比如错误的输出等等，我们甚至会有其它的信息，比如产生的错误在代码中的位置，并从这些有限的信息中，我们需要使用推论来隔离出错误产生的根源。有效调试的关键是能够快速地搜集到会带来识别出错误的相关信息，就像侦探在犯罪地点搜集证据，或是医生为了诊断出病人的病症所做的一系列的检查。为了诊断出一个错误，有许多方法

20、能够搜集更多的信息，从快速但令人厌恶的专门技术，到更加系统的包括使用软件调试工具的技术。15.4.1 专门技术当你意识到你的程序有问题的时候，最简单的方法就是去看源代码。有时候错误的特征会提示你到代码中可能存在错误的区域。如果源代码的区域很小而且你对代码非常熟悉的话，这种技术非常好。另一个简单的方法是在代码中插入一些语句，用来在执行期间输出相关信息。你可以使用printf语句来输出那些你认为在找错误上有用的重要变量的值。你也可以在代码中不同的地方加入printf语句，以此来查看程序的控制流程是否正确运行。例如，如果你想快速判断一个计数器控制的循环是否迭代了正确的重复次数，你可以把printf语

21、句放在循环体中。对于简单的程序，这种专门的技术容易并且使用合情合理。包含复杂的错误的大程序需要使用更高效的技术。15.4.2 源水平调试器通常专门技术不能为揭示错误的来源提供足够的信息。在这种情况下，程序员通常使用源水平调试器来隔离出错误。源水平调试器是一个允许程序在一个可控的环境下执行的工具，在其中，程序的执行的所有方面都可以被程序员控制和检查。例如，调试器允许我们一次执行程序的一条语句，并且可以检查变量的值（以及存储单元和寄存器，如果我们那样选择的话）。源水平调试器类似于我们在第6章描述的LC-3调试器，只不过源水平调试器在高级源代码上操作，而不是在LC-3机器指令上操作。对于一个用于程序

22、中的源水平调试器，为了使调试器能够正确的工作，程序的编译必须被编译器使用足够的附加信息增加可执行映像。另外，调试器需要来自编译过程的信息，以便将机器语言指令映射为相应的高级源程序的语句。调试器还需要关于变量名和它们在存储器中的地址的信息（即符号表）。这样的要求是为了程序员使用源代码中的变量名检查程序中任意变量的值。有很多可用的源水平调试器，每一个都有它自己的用户界面。对于UNIX和Windows提供的调试器是不同的，每一个都有自己独特的运行特点。例如，gdb是一个在大多数基于UNIX平台上可用的免费的源水平调试器。所有的调试器都支持一个查明程序的执行所必需的核心操作集，大多数都与LC-3调试器

23、的调试特征相似。所以，不是描述任意一个特定的调试器的用户界面，在这一节，我们将描述对任意调试器都通用的核心操作集。 核心的调试器命令分成两类：一类是让你控制程序的执行，另一类是让你在程序执行过程中检测变量和存储器的值等。断点在程序执行的过程中，断点允许我们可以指定一些点，这样在程序应该被临时停止时，我们就可以检查或者修改这个程序的状态。这是非常有用的，因为它可以帮助我们检查错误出现的代码区域中的程序的执行情况。例如，我们可以在一段源代码中或者在一个特定的函数中，在一个特定行添加一个断点。当执行到那一行时，程序的执行被及时冻结，因而我们在这个特定的情况下可以检查所有的与程序有关的事物。如何添加断

24、点与调试器的用户界面有关。有些允许通过单击某行代码来添加断点。有些需要通过使用命令行命令指定一个行号来添加断点。有时候只有当一个特定的条件成立时才停于某一行是很有用的。这类条件断点对于隔离开我们怀疑执行有错误的特定情况是非常有用的。例如，如果我们怀疑performCalculation函数在输入参数是16的时候运行不正确，那么我们可以在下面的代码中添加一个只有当x等于16时才停止执行的断点：for (x=0;x231时报错，表明n必须小于等于31。在下面的代码中，我们已经对来自14章的Factorial函数添加了一个输入范围的检查。现在，如果其输入参数不在正确的运行范围内，函数打印出一条警告信

25、息，并返回一个-1。15.5.2 模块化设计 函数对于拓展编程语言的功能很有用。使用函数，我们可以为有助于某个特定的编程任务引入新的运算和结构。采取这种方法，函数使我们能够以模块化的方式写程序。一旦完成一个函数，我们就可以对它进行单独测试（即，白盒测试），判断它是否按照期望运行。既然一个典型的函数与完整的程序相比，执行的是更小的任务，它也就比整个程序更容易测试。一旦我们对每个函数单独的完成测试和调试，当所有的被整合起来时，我们让程序运行起来的机会更容易。这个把简单的、预先测试过的和可以运行的组件构建为程序的模块化设计的概念是系统设计中的一个基本概念。在以后的章节中，我们将介绍库的概念。库是一个

26、已测试的组件的集合，所有程序员都可以使用库写他们的代码。现代的编程实践着重围绕库的使用，因为它对模块化设计有固有的益处。我们不仅在软件设计上，在电路、硬件和计算系统的其它不同层次的设计中也使用一种类似的模块化设计原理。15.5.3防御性程序设计所有的经验丰富的程序员都有阻止错误“爬进”他们的编码中的技巧。他们通过那样的方法构建代码，这样，他们怀疑会影响程序的那些错误通过设计被消除。那就是说，他们防御性的编程。我们提供一列简短的有关防御性程序设计的技术，你应该采用这些技术来避免你写的程序出现问题。 注释你的代码。写注释能让你对你写的代码进行思考。代码文档不仅是告诉别人你的代码如何运行的方式，还是

27、一个让你重新思考你的代码的过程。在这个过程中，你会发现你忘记了一个特别的情况或一个最后会让代码崩溃的运行条件。 采用一致的编码风格。例如，对齐左右大括号能让你识别出那些缺少括号的简单的语义错误。在这些行中，变量名也应一致。变量的名字应当能传达一些关于变量包含的值的有意义的信息。 避免假设。在写代码的时候试图做简单的无知的假设，但是这些最终会导致代码的崩溃。例如，在写一个函数时，我们可能会假设输入的参数总是在某个范围内。如果这个假设不在这个程序的规格说明里，那么出现一个错误的可能性就产生了。写避免如此假设的代码，或者至少使用断言，并抽样调查说明假设何时不成立。 避免全局变量。尽管一些有经验的程序

28、员十分依赖全局变量，许多软件工程师主张尽可能的避免使用它们。全局变量会使一些编程任务更容易。然而，它们经常使代码更难理解、扩展，并且当检测到一个错误时，更难分析。 依赖编译器。大部分优秀的编译器都有一个选项来检查程序中可疑的代码（例如，没有初始化的变量），或者常见的代码结构误用（例如，使用赋值运算符代替相等运算符）。尽管这些检查是不彻底的，但它们确实有助于识别出常见的编程错误。如果你使用gcc编译器，使用gcc -Wall，可以从编译器获得所有的警告信息。这儿提到的防御性技术对于我们已经讨论过的编程概念中是特殊的。在以后的几章中，在我们介绍了新的编程概念后，我们还会讨论在使用它们编程时如何使用

29、防御性技术。15.6 总结在这一章里，我们介绍了关于查找和修复你的代码中的错误的方法论。现代的系统越来越依赖软件，而现代的软件通常也是非常复杂的。为了避免经常使我们的手机不能工作，或是偶然造成坠机事故的软件错误，软件和它的规格说明紧密一致是非常重要。我们在这一章里涉及到的关键概念有： 测试 找到你的代码中的错误并不容易，特别是当程序很大时。软件工程师使用系统的测试来查找软件中的错误。黑盒测试是用来确认程序的表现与其规格说明相一致。白盒测试的目标是程序的结构，它保证每一行代码都经过某个级别的测试。 调试 调试一个错误需要具备获取可用的信息，并推导出错误来源的能力。虽然一些专门的技术能够提供给我们

30、关于错误的一些额外信息，源水平调试器对于大多数调试任务而言还是被选择的软件工程工具。源水平调试器允许程序员在一个可控的环境中执行程序，在程序执行过程中检查各种数值和状态。 正确编程 有经验的程序员在编写第一行代码之前就努力避免出现错误。通常程序的规格说明是错误的来源，明确零碎的信息将有助于在代码写完之后消除错误。模块化设计包括使用简单的、预先测试过的函数写更大的程序，有助于降低测试大型程序时的难度。遵循一个防御性的编程风格有助于减少导致错误代码出现的情况。习题：15.1 下列程序都是计算从整数1到10的和并输出这个和，每个程序都包含一个简单错误，请做尽可能少的改动来纠正这些错误。15.2 下列

31、程序段均有语法错误，因而不能被编译通过。假设所有变量声明都是正确的，纠正这些错误。15.3 下面的C代码是用来找出用户输入的一组正整数中的最小值。用户输入一组正整数，最后输入-1结束，程序输出这组正整数中的最小值。然而，代码中包含一个错误，请找出这个错误并纠正。15.6 使用一个源水平调试器，判定函数Mystery的参数是何值时，返回值为0？15.7 下面的程序用来管理只有一架飞机的航空公司的机票预定工作。用户输入R请求预订，如果有座位，该请求可以被接受，否则，将被拒绝。预订过的用户输入P可以购买一张机票，即输入P命令之前，必须输入R命令才能购买，而输入了R命令并不意味着购买。程序以用户输入X结束。但是这段程序中有一个错误，请找出并纠正。