软件测试调试

《软件测试调试》由会员分享，可在线阅读，更多相关《软件测试调试（13页珍藏版）》请在金锄头文库上搜索。

1、软件测试：调试(DEBUGGING)简单地讲，调试是执行一次成功的测试之后所要进行的工作。记住，所谓成功 的测试，是指它可以证明程序没有实现预期的功能。调试是一个包含两个步骤的过 程，从执行了一个成功的测试用例、发现了一个问题之后开始。第一步，确定程序 中可疑错误的准确性质和位置；第二步，修改错误。虽然调试对于程序测试来说非常必要、不可或缺，但它似乎是软件开发过程中 最不受程序员欢迎的部分之一。其主要原因可能包括以下几点：个人自尊会从中阻挠。不管我们是否喜欢，调试都说明了程序员并不完美， 要么在软件的设计，要么在程序编码时会犯错。热情耗尽。在所有的软件开发活动中，调试是最耗费脑力的苦差事，况且

2、， 进行调试往往经受着来自机构或自身的巨大压力，必须尽可能快地改正问 题。可能会迷失方向。调试是艰苦的脑力工作，因为发现的错误实际上可能会 出现在程序的任何语句中。也就是说，如果不首先检查程序，我们就不能 绝对地肯定在一个薪金管理程序出具的支票中出现的数字错误不是由某个 子程序引起的，该子程序要求操作员将一个特定的表格传输给打印机。让 我们以诊断一个物理系统为例子作对比，如汽车。假如汽车在爬坡时熄火 了（症状），那么我们可能会迅速而有效地排除掉某些部件调频/调幅 收音机、速度表或汽车门锁引起该故障的可能。根据我们对汽车引擎 的整体了解，该故障一定是发生在引擎上，我们甚至可以排除掉某些引擎 部件

3、，如水箱和滤油器。必须自力更生。与其他软件开发活动相比，关于调试过程的研究、资料和 正式的指南都比较少。尽管本书是关于软件测试的，并不讨论调试，但这两个过程显然是相互联系的。 针对调试的两个步骤，即错误定位和错误修改，对错误进行定位可能解决了 95的问题。因此，本章集中讨论错误的定位过程，当然是假定某个成功的测试用例已经发现了一个错误。7.1 暴力法调试(Debugging by Brute Force)调试程序的最为普遍的模式是所谓的“暴力”方法。这种方法之所以流行，是 因为它不需要过多思考，是耗费脑力最少的方法，但同时也效率低下，通常来讲不 是很成功。暴力调试方法可至少被划分为三种类型：1

4、.利用内存信息输出来调试。2.根据一般的“在程序中插入打印语句”建议来调试。3.使用自动化的调试工具进行调试。 第一种类型，使用内存信息输出（通常使用十六进制或八进制格式粗略地显示所有的存储区域）是最缺乏效率的暴力调试方法，原因如下：难以在内存区域写源程序中的变量之间建立对应关系。即使对下复杂程度较低的程序，内存信息输出也会产生数最非常庞大的数 据，其中的大多数都是与调试无关的。内存信息输出显示的是程序的静态快照，仅能显示出在某一个时刻程序的 状态；为了发现错误，还需要研究程序的动态状态（随时间的状态变化）。内存信息输出很少可以精确地在错误发生的地方产生，因此无法显示在错 误发生时程序的状态。

5、错误发生到输出内存信息这段时间之内程序执行的 活动，可能会掩盖掉发现错误所需的线素。通过分析输出的内存信息来发现问题的方法并不大多（因此很名程序员都 是密切注视，急切地渴望着错误能神奇地从内存信息输出中自行暴露出 来）。第二种类型，在失效的程序中插入输出变量值的语句，这种做法也不具有很强 的优势。它可能比内存信息输出要好一些，因为可以显示程序的动态状态，让我们 检查的信息可以相对容易地与源程序联系起来。但是这种方法同样也有很多缺点：它不是鼓励我们去思考程序中的问题，而主要是一种碰运气的方法。它所产生的需要分析的数据量非常庞大。它要求我们修改程序，这些修改可能会掩盖掉错误、改变关键的时序关系，

6、或者会引入新的错误。它可能对小型程序有效，但如果应用到大型程序，成本就相当高。况且对 于某些类型的程序，如操作系统或过程控制软件，这种办法甚至无法使用。第三种类型，自动化调试工具的工作机制类似于在程序中插入打印语句， 但是并不修改程序本身。可以使用编程语言的调试功能，或使用特殊的交互式 调试工具来分析程序的动态状态。可能会用到的典型的语言功能有：产生可打 印的语句执行轨迹的机制、子程序调用以及/或者对特定变量的修改等。调试工 具的一个共同的功能是可以设置断点，使程序在执行到某条特定语句或改动了 某个特定变量的值时暂停执行，然后程序员就可以检查程序的当前状态。同样， 这种方法也主要是在碰运气，常

7、常会生成数量过于庞大的无关数据。这些暴力调试方法的主要问题在于：它们都忽略了思考的过程。我们可以 在调试程序和侦破谋杀案之间找出相似点来。实际上，在几平所有的谋杀悬念 小说中，谜案都是通过仔细分析线索，将表面上不重要的细节全联结起来而最 终侦破的。这不是一个使用蛮力的方法，要使用蛮力的是寻觅障碍物或搜寻财 宝。还有些证据表明，无论调试小组成员是富有经验的程序员还是学生，肯动 脑筋而不是依赖别人帮助的人能够更快、更准确地发现程序错误。因此，我们 建议仅在下列情况下使用暴力调试方法：（l）其他的方法都失败了：（2）作为 我们下面将会讨论的思考过程的补充，而不是替代方法。7.2 归纳法调试(Debu

8、gging by Induction)很显然，认真的思考能够发现大部分错误，甚至不需要调试人员使用调试 工具归纳是一种特殊的思考过程，可以从细节转到全局，也就是从线索（即 错误的症状，可能是一个或多个测试用例的结果）出发，寻找线索之间的联系。 归纳的过程如图 7-1 所示。不能数据组织数据间联系构造假设能证明假设不能 能修改错误图 7-1 使用归纳法的调试过程归纳调试的步骤如下：1.确定相关数据。调试人员犯的一个主要错误是未能将所有可用的数据或症 状都考虑进去。第一步是列举出所有知道的程序执行的正确和不正确之处， 这些不正确之处即是症状，让我们相信确实存在错误。那些相似却不相同、 且未引起症状

9、出现的测试用例提供了额外的有价值的线索。2.组织数据。记住，归纳意味着从特殊到一般，因此第二步是组织这些相关 数据，以便观察线索间的模式，尤其重要的是要找到矛盾、事件，比如仅 当客户的保险金账户收支不太平衡时出现的错误。我们可以采用图 7-2 所 示的表格来组织现有的数据。“是什么”框列举的是总体的症状，“在何处” 框描述了这些症状出现的地方，“多大程度”框描述了这些症状的范围和重 要性。注意“是”和“否列，它们所描述的矛盾之处最终可能会导致对错误的假设。?IsIs notWhatWhereWhenTo what next图 7-2 组织线索的一种方法3.做出假设。下一步是研究线索之间的联系，

10、利用线索结构里可能的模式做 出一个或多个关于错误原因的假设。如果还无法做出推测，就需要更多的数据。如果可能有多个假设存在，首先选择最有能的一个。4.证明假设。考虑到调试在进行时所承受的压力，这个时期最主要的错误是 忽略了这个阶段，直接跳到结论去改正问题。但是在继续下一步之前，证 明这些假设的合理性是非常重要的。如果忽略了这一步，可能接下去只修 改了问题症状，而没解决问题本身。应将假设与其最初的线索或数据相比 较，以此来证明假设的合理性，确定这些假设可以完全解释这些线索的存 在。如果无法解释，要么这些假设是无效的或不完整的，要么还有更多的 错误存在。举一个简单的例子、假设在第 4 章描述的考试评

11、分软件报告了一个明显的错 误。错误是在某些但不是所有情况下，中间值似乎不正确。在某个特殊的测试用例 中，有 51 名学生被评分。正确打印出宋的平均分数为 73.2，但打印出的中间值是26 分，而不是预期的 82 分。经过对该测试用例及其他一些测试用例结果的检查，线索按图 7-3 所示的形式进行组织。?IsIs notWhat报告 3 中显示的中间值不正确计算平均值或标准偏差时出现Where仅在报告 3 中出现在其它报告中出现。学生成绩的计算似乎正确When当测试学生为 51 时发生在测试学生数量为 2 和 200时未发生To what next显示的中间值为 26。当学生数量为 1 时也同样发

12、生，显示 的中间值。图 7-3 组织线索的例子下一步是通过寻找模式和矛盾之处，做出关于该错误的假设。我们看到的一个 矛盾是这个错误似乎出现在学生人数为奇数的测试用例中，这也许是个巧合，但看 来很重要，因为我们要根据学生人数为奇数或偶数而不同地计算中间值。还有一个 奇怪的模式：在些测试用例中，计算出来的中间值总是小于或等于学生的人数（26 小等于 51，l 小等于 1）。这时，一个可能的方法是再重新运行一次学生人数为 51 名的测试用例，给学生打与以前不同的分数，看一下是如何影响中间依的计算的。 如果中间值仍然是 26，那么“否多大程度”框可以填上“中间值似乎与实际分 数无关”。尽管这个结果提供

13、了一条有价值的线索，但即使没有它，我们可能已经能够猜出这个错误来。从现有数据计算出的中间值似乎等于学生人数的一半，经过四舍五入后得到最接近的一个整数。换句话说，如果将分数设想为存储在一个分类 表里，该程序打印的是中间学生的人数而不是其成绩。因此，我们有了一个关于该 错误准确性质的坚定的假设。下一步就是通过检查代码或执行一些附加的测试用例 来证明这个假设。7.3 演绎法调试(Debugging by Deduction)演绎的过程是从一些普遍的理论或前提出发，使用排除和精炼的过程，达到一 个结论（错误的位置），参见图 7- 4 。130列出可能 的原因使用排除 法提炼剩下 的假设证明剩下能 的假

14、设修改错误都被排除不能收集更多 数据图 7-4 使用演绎法的调试过程举个谋杀犯的例子，与归纳过程相反，首先从一系列嫌疑人入手，通过排除（花 匠有当时不在现场的合理证词）和提炼（罪犯可能是红色头发）的过程，判断出管 家可能犯了罪。演绎的步骤如下：1.列举出所有可能的原因或假设第一步是建立一份所有想象得到的错误线 索的清单，线索不需要有完整的解释，它们纯粹是一些推测，帮助我们组 织和分析现有的数据。2.利用数据排除可能的原因。详细检查所有的数据，尤其寻找存在矛盾的地 方（图 7-2 可以用在此处），然后尽量排除所有可能的原因，仅留下一条， 如果所有的原因都排除掉了，需要增加额外的测试用例，得到更多

15、的数据 来设计新的推测。如果剩下的原因多于一个，那么首先选择最有可能的原 因，即主要假设。3.提炼剩下的假设。此时的可能原因也许是正确的,但可能不够具体，不能指出错误来。因此，下一步是使用现有的线索来提炼这个推侧举例来说，我们可能会首先想到“对文件中最后事务的处理可能存在错误”，并将其提 炼为“缓冲区中的最后事务被文件结束指示器覆盖” 。4.证明剩下的假设。这个重要步骤与归纳法中的第 4 步骤相同。 举个例子，假设我们着手对第 4 章讨论的 DISPLAY 命令进行功能测试。在由因果图分析方法确定的 38 个测试用例中，我们首先使用 4 个测试用例。作为建立输入条件过程的一部分，我们对内存进行初始化，将第一个、第五个、第九个、 字的值设置为 0000，将第二个、第六个、 字的值设置为 4