软件测试技术

第

1章

软件工程与软件测试1.1软件工程1.2软件质量1.3软件测试1.4软件测试人员的基本素质

严格地说，软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。通俗地说，软件工程是实现一个大型程序的一套原则方法，即按工程化的原则和方法组织软件开发工作。软件测试是软件工程的一个重要环节，相当于工程领域中的质量检验部分，是确保软件工程质量的重要手段。1.1软件工程1.1.1

软件工程的目标及其一般开发过程一个软件产品从形成概念开始，经过开发、使用和维护，直到最后退出使用的全过程称为软件生存周期。软件生存周期根据软件所处的状态，以及软件开发活动的目的和任务，可划分为若干个阶段。一般软件生存周期包括软件定义、软件开发以及软件使用与维护3个部分。1．软件定义可行性分析的任务是了解用户的要求及实现环境，从技术、经济和社会等几个方面研究并论证软件系统的可行性。需求分析的任务是确定所要开发软件的功能需求、性能需求和运行环境约束，编制软件需求规格说明、软件系统的确认测试准则。软件的性能需求包括软件的适应性、安全性、可靠性、可维护性错误处理等。2．软件开发软件开发是按照需求规格说明的要求，由抽象到具体，逐步生成软件的过程。软件开发一般由设计、实现和测试等阶段组成。3．软件使用和维护软件的使用是在软件通过测试后，将软件安装在用户确定的运行环境中移交给用户使用。软件的维护是对软件系统进行修改或对软件需求变化做出反应的过程。1.1.2软件过程模型软件开发过程中存在各种复杂因素，为了解决由此而带来的种种问题，软件开发者们经过多年的摸索，给出了多种实现软件工程的方式——软件过程模型，如瀑布过程模型、螺旋过程模型和增量过程模型等。1．瀑布过程模型瀑布过程模型反映了人们早期对软件工程的认识水平，是人们所熟悉的一种线性思维的体现。瀑布过程模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性，是一种严格线性的、按阶段顺序的、逐步细化的开发模式，如图1-1所示。图1-1瀑布过程模型2．螺旋过程模型螺旋过程模型的基本思路是，依据前一个版本的结果构造新的版本，这个不断重复迭代的过程形成了一个螺旋上升的路径，如图1-2所示。图1-2螺旋过程模型3．增量过程模型有些时候可能会用一种几乎连续的过程小幅度地推进项目，这就是增量过程模型，如图1-3所示。图1-3增量过程模型1.2软件质量

软件质量是软件的生命，它直接影响软件的使用与维护。通常软件质量由以下几方面进行评价。①软件需求是衡量软件质量的基础，不符合需求的软件就不具备质量。设计的软件应在功能、性能等方面都符合要求，并能可靠地运行。

②软件结构良好，易读、易于理解，并易于修改、维护。

③软件系统具有友好的用户界面，便于用户使用。

④软件生存周期中各阶段文档齐全、规范，便于配置、管理。1.2.1质量与质量模型软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。软件质量因素也称为软件质量特性，反映了质量的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。

面对众多的质量因素如何取折衷，这实际上就是区分质量因素对软件质量影响程度轻重的问题，这个问题已经有了解决方案，即软件质量模型。图1-4所示为ISO/IEC9126－1991标准规定的软件质量度量模型。它由3层组成，其中第1层称为质量特性，第2层称为质量子特性，第3层称为度量。图1-4ISO软件质量度量模型

软件质量评价的目的是为了直接支持开发并获得能满足用户要求的软件。最终目标是保证产品能提供所要求的质量，即满足用户明确的和隐含的要求。软件产品的一般评价过程是，确定评价需求，然后规定、设计和执行评价，如图1-5所示。图1-5软件评价过程1.2.2软件质量保证为了在软件开发过程中保证软件的质量，软件的质量保证活动应贯穿整个软件生存周期的每一个阶段。软件的质量保证的措施主要有检查、评审和测试。如图1-6所示，软件质量保证的工作从项目一开始就应介入。图1-6质量保证活动1.3软件测试

1.3.1软件测试的定义及目的简单地说，软件测试就是为了发现错误而执行程序的过程。

在IEEE提出的软件工程标准术语中，软件测试被定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。”软件测试是与软件质量密切联系在一起的，归根结底，软件测试是为了保证软件质量。

软件测试是一个找错的过程。软件测试的过程亦是程序运行的过程。程序运行需要数据，为测试设计的数据称为测试用例。测试用例的设计原则是尽可能暴露程序中的错误。

软件是由人来完成的，所有由人做的工作都不会是完美无缺的。软件开发是个很复杂的过程，期间很容易产生错误。无论是软件从业人员、专家和学者做了多大的努力，软件错误仍然存在。因而大家也得到了一种共识：软件中残存着错误，这是软件的一种属性，是无法改变的。所以通常说软件测试的目的就是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。一个成功的测试用例在于发现了至今尚未发现的缺陷。

软件测试的目的是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。1.3.2软件测试信息流为进一步说明软件测试的过程，这里给出软件测试的信息流示意图，如图1-8所示。图1-8软件测试信息流1.3.3软件测试与软件开发过程的关系对于软件测试与软件开发过程之间的关系，套用固定的模型不是聪明之举。比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后，如图1-9（a）所示。而对于一些复杂的程序，将测试分为同步测试与总测试更有效，如图1-9（b）所示。图1-9程序设计与测试的关系

现在还有一种全新的软件开发模式——以测试驱动软件开发，总的思想是：软件测试是贯穿于软件开发过程的。软件生存周期的各个阶段中都少不了相应的测试，软件生存周期各个阶段的测试分别对应于软件测试过程中的单元测试、集成测试、系统测试和确认测试，如图1-10所示。这种对应关系有利于软件开发过程的管理和软件质量的控制。图1-10软件测试与软件开发的关系1.3.4软件测试与质量保证的区别1．质量保证质量保证（QA）工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理”和“过程改进”的原理开展质量保证工作。2．软件测试测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行”软件，对过程中的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。测试人员必须假设软件存在潜在的问题，测试中所做的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。

对测试中发现的问题的分析、追踪与回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节。软件质量保证活动与软件测试的关系可用图1-11说明。图1-11软件质量保证活动与测试的关系1.3.5软件测试的发展历程及趋势软件测试是伴随着软件的产生而产生的，有了软件的生成和运行就必然有软件测试。在早期的软件开发过程中，测试的含义比较窄，将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由软件开发人员自己完成这部分工作。对测试的投入极少，测试介入得也晚，常常是等到形成代码，产品已经基本完成时才进行测试。

直到1957年，软件测试才开始与调试区别开来，成为一种发现软件缺陷的活动。直到20世纪80年代早期，“质量”的号角才开始吹响。软件测试的定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。制定了各类标准，包括IEEE标准、美国ANSI标准和ISO国际标准。20世纪90年代，测试工具终于盛行起来。到了2002年，Rich和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义：“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程”。这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响。

近20年来，随着计算机和软件技术的飞速发展，软件测试技术的研究也取得了很大的突破，测试专家总结了很好的测试模型，如著名的V模型，在单元测试、自动化测试等方面涌现了大量优秀的软件测试工具。

虽然软件测试技术的发展很快，但是其发展速度仍落后于软件开发技术的发展速度，使得软件测试在今天面临着很大的挑战，主要体现在以下几个方面。

①软件在国防现代化、社会信息化和国民经济信息化领域中的作用越来越重要，由此产生的测试任务越来越繁重。

②软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。③面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。

④对分布式系统的整体性能还不能进行很好的测试。

⑤对实时系统缺乏有效的测试手段。

⑥随着安全问题的日益突出，对信息系统的安全性如何进行有效的测试与评估，成为世界性难题。

根据国内外软件测试的发展现状，可以看到软件测试有以下的发展趋势。

①测试工作将进一步前移。

②软件架构师、开发工程师、QA人员、测试工程师将进行更好的融合。

③测试职业将得到充分的尊重。④设置独立的软件测试部门将成为越来越多的软件公司的共识。软件测试部门将和开发部、质量保证部一样作为一个重要的独立部门存在。

⑤测试外包服务将快速增长。和软件开发外包一样，软件测试外包将成为全球化的一种趋势。可以利用职业测试专家队伍与机构为自己的产品进行测试，而且可以节省测试费用。1.4软件测试人员的基本素质

软件测试人员应具备下列基本素质。1．具有良好的计算机编程基础2．具有创新精神和超前意识3．不懈努力，追求完美4．具有整体观念，对细节敏感5．团队合作精神第2章软件测试的基本知识

2.1软件测试贯穿于整个的软件开发生命周期2.2测试模型2.3软件测试的分类2.4软件测试的原则2.5软件测试策略2.6软件测试流程2.7测试的成功经验2.1软件测试贯穿于整个的软件开发生命周期2.1.1软件测试中使用的各种术语

①软件错误

②软件缺陷

③软件故障

④软件失效2.1.2软件测试贯穿于整个的软件开发生命周期

20世纪70年代中期以来，形成了软件开发生命周期的概念。测试工作应该着眼于整个软件开发生命周期，特别是着眼于编码以前各开发阶段的工作来保证软件的质量。也就是说，测试应该从软件开发生命周期的第一个阶段开始，并贯穿于整个的软件开发生命周期。

谈到测试，首先是为什么要进行测试的问题。所有的测试都是为了发现和消除软件的缺陷。明确为什么要进行软件测试的问题之后，就需要明确测试什么的问题。

软件的开发有其自己的生命周期，在整个软件生命周期中，软件都有各自的相对于各生命周期的阶段性的输出结果，其中也包括需求分析、概要设计、详细设计及程序编码等各阶段所产生的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，而所有这些输出结果都应成为被测试的对象。

随着人们对软件工程化的重视以及软件规模的日益扩大，软件分析、设计的作用越来越突出，而且有资料表明，60%以上的软件错误并不是程序错误，而是分析和设计错误。因此，做好软件需求和设计阶段的测试工作就显得非常重要。这就是传统的测试概念的扩大化，从而提出了软件全生命周期测试的概念。

测试过程包括了软件开发生命周期的每个阶段。在需求阶段，重点要确认需求定义是否符合用户的需要；在设计和编程阶段，重点要确定设计和编程是否符合需求定义；在测试和安装阶段，重点是审查系统执行是否符合系统规格说明；在维护阶段，要重新测试系统，以确定更改的部分和没有更改的部分是否都正常工作。2.1.3软件测试的手段1．验证和确认通常在测试中，使用验证来检查中间可交付的结果，使用确认来评估可执行代码的性能。一般来说，验证回答这样的问题：“是否建立了正确的系统？”，而确认回答的问题是：“建立的系统是否正确？”。

所谓验证，是指如何决定软件开发的每个阶段、每个步骤的产品是否正确无误，并与其前面的开发阶段和开发步骤的产品相一致。验证工作意味着在软件开发过程中开展一系列活动，旨在确保软件能够正确无误地实现软件的需求。所谓确认，是指如何决定最后的软件产品是否正确无误。2．功能和结构测试当测试人员测试项目小组的解决方案时，将利用验证和确认技术完成功能和结构测试。功能测试通常也被称为黑盒测试，因为测试案例中都不涉及系统的内部逻辑。

相反，结构测试通常被称为白盒测试，因为系统的内部逻辑常被用于假想的测试案例。结构测试主要使用验证技术。如上所述，测试人员用验证技术，通过评审系统的结构和逻辑来确认系统的合理性。而确认要严格应用于物理测试，来确定是否产生了预期的结果。执行结构测试将主要使用验证技术，而执行功能测试则主要使用确认技术。2.2测试模型

就像软件开发有过程模型一样，测试也有测试模型。描述以上测试过程的就是测试模型。最具有代表意义的测试模型称为V模型。V模型如图2-1所示。图2-1V模型示意图

在开发过程中，从需求阶段到编码阶段，主要是采用验证手段进行测试，如需求评审、设计评审、代码走查以及代码审查等，从而完成对开发的中间结果的正确性的评估。编码完成并经过代码审查等测试之后，此时的测试主要在软件的可执行模式下进行，即利用确认手段进行测试，确认测试包括单元测试、集成测试、系统测试以及用户验收测试等，其相应的关系如图2-2所示。图2-2V模型中的测试2.3软件测试的分类

按照不同的分类方法，软件测试可分为以下几种类型。1．按照开发阶段划分按照开发阶段划分，软件测试可分为单元测试、集成测试、系统测试和验收测试。2．按照测试实施组织划分按照测试实施组织划分，软件测试可分为开发方测试、用户测试（β测试）和第三方测试。3．按照测试技术划分按照测试技术划分，软件测试可分为白盒测试和黑盒测试，也可分为静态测试和动态测试。2.4软件测试的原则

软件测试的原则尚没有标准的说法，大多是经验之谈，一般有下面几条可作为测试的基本原则。（1）所有的测试都应追溯到用户需求。（2）应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。（3）设计时应完成测试计划，详细的测试用例定义可在设计模型确定后开始，测试可在代码产生之前进行计划和设计。（4）pareto原则：测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块，进行重点测试。（5）完全测试是不可能的，测试需要终止。（6）应由独立的第三方来构造测试。（7）充分注意测试中的群集现象。（8）要尽量避免测试的随意性。（9）兼顾合理的输入和不合理的输入数据。（10）程序修改后要回归测试（11）应长期保留测试用例，直至系统废弃。2.5软件测试策略

软件测试策略描述软件测试活动的总体方法和目标。为了检验开发的软件能否符合规格说明书的要求，测试活动可以采用各种不同的策略。这些策略的区别在于它们表明了不同的出发点、不同的思路以及采用不同的手段和方法。具体地说，包括要使用的测试技术和工具；测试完成标准；影响资源分配的特殊考虑等。通常，制定软件测试策略要考虑如下的内容。（1）要使用的测试方法。（2）确定质量风险。（3）测试完成和测试成功所采用的评价标准。（4）有关资源要求或涉及进度的特殊考虑。（5）测试类型、评估标准以及测试方法。（6）确定资源。

在软件测试策略所包含的内容中最主要的部分有两个，一是要进行的测试过程，另外一个就是要执行的测试类型。1．测试过程共分为以下4个过程。

①单元测试

②集成测试

③系统测试

④验收测试2．测试类型对于测试类型的说法多种多样，最多的能有30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要，测试主要包含下面的类型。①功能测试②健壮性测试③接口测试④强度测试⑤压力测试⑥性能测试⑦用户界面测试⑧安全测试⑨可靠性测试⑩安装/反安装测试

11.文档测试12.恢复测试13.兼容性测试14.α测试15.β测试2.6软件测试流程

软件测试工作必须要通过制定测试计划、设计测试、实施测试、执行测试、评估测试几个阶段来完成。其流程如图2-4所示。图2-4软件测试流程2.6.1制定测试计划测试计划是对每个产品，或是对各个开发阶段的产品开展测试的策略。

计划的目的是用来识别任务、分析风险、规划资源和确定进度。计划并不是一张时间进度表，而是一个动态的过程，最终以系列文档的形式确定下来。拟定软件测试计划需要测试项目管理人员的积极参与，这是因为主项目计划已经确定了整体项目的一个时间框架，软件测试作为阶段工作必须服从计划和资源上的约定。

一般来说，一个完整的测试计划应该包含以下几个方面。（1）对测试范围（即测试活动需要覆盖的范围）的界定（2）风险的确定（3）资源的规划（4）时间表的制定2.6.2设计测试设计测试阶段要设计测试用例和测试过程，要保证测试用例完全覆盖测试需求。设计测试阶段最重要的是如何将测试需求分解，如何设计测试用例。1．如何对测试需求进行分解对测试需求进行分解需要反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行。（1）确定软件提供的主要任务。（2）对每个任务，确定完成该任务所要进行的工作。（3）确定从数据库信息引出的计算结果。

（4）对于对时间有要求的交易，确定所要的时间和条件。（5）确定会产生重大意外的压力测试，包括内存、硬盘空间、高的交易率。（6）确定应用需要处理的数据量。（7）确定需要的软件和硬件配置。

（8）确定其他与应用软件没有直接关系的商业交易。（9）确定安装过程。（10）确定没有隐含在功能测试中的用户界面要求。2．如何设计测试用例测试用例一般指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。值得提出的是，测试数据都是从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的。测试用例是软件测试系统化、工程化的产物，而测试用例的设计一直是软件测试工作的重点和难点。

设计测试用例即设计针对特定功能或组合功能的测试方案，并编写成文档。测试用例应该体现软件工程的思想和原则。

传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细记录下来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。评价测试用例的好坏有以下两个标准。①是否可以发现尚未发现的软件缺陷？②是否可以覆盖全部的测试需求？2.6.3实施测试实施测试是指准备测试环境、获得测试数据、开发测试规程，以及为该过程挑选和准备辅助测试工具的过程。1．准备测试环境（1）测试技术准备（2）配置软件、硬件环境（3）人员2．获得测试数据需要测试的常见情形如下。（1）正常事务的测试（2）使用无效数据的测试创建测试数据时主要考虑如下步骤。

①识别测试资源

②识别测试情形

③排序测试情形

④确定正确的处理结果

⑤创建测试事务

确定实际的测试数据时，必须说明处理测试数据的以下4个属性。（1）深度（2）宽度（3）范围（4）结构3．测试脚本概要所谓脚本，是完整的一系列相关终端的活动。一般测试脚本有5个级别，分别是：单元脚本，用于测试特定单元/模块的脚本；并发脚本，用于当两个或多个用户同时访问同一文件时测试的脚本；集成脚本，用于确定各模块是否可以前当连接；回归脚本，用于确定系统未改变的部分在系统改变时是否改变；强度/性能脚本，用于验证系统在被施加大量事务时的性能。（1）测试脚本的结构为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。（2）记录技术为使测试脚本获得更高的可维护性，应该以最不易受测试对象变化影响的方式来记录测试脚本。（3）数据驱动的测试许多测试过程包括在给定的数据输入屏幕内输入几组字段数据，检查字段确认功能、错误处理等。（4）测试脚本同步和时间安排当进行重点测试时，通常需要同步测试脚本以便它们在预先确定的时间启动。（5）测试和调试测试脚本在记录测试脚本的同一测试软件上执行这些最近记录的测试脚本时，不应该发生任何错误。4．辅助测试工具为了实施高效的测试工作，还需要有高效、好用的辅助工具，做软件测试通常需要以下一些基本工具。①优秀的办公处理软件②秒表③错误跟踪系统④自动测试工具⑤软件分析工具⑥好的操作系统⑦多样化平台2.6.4执行测试执行测试是执行所有的或选定的一些测试用例，并观察其测试结果的过程。尽管为执行测试所做的准备和计划工作会贯穿于软件开发生命周期之中，但是执行测试往往都会在软件开发生命周期的末期，或者接近末期进行，即在编码完成之后进行。由于测试过程一般分成代码审查、单元测试、集成测试、系统测试和验收测试几个阶段，尽管这些阶段在实现细节方面都不相同，但其工作流程方面却是一致的。

执行测试的过程由以下4个部分组成。

①输入。要完成工作所必须的入口标准或可交付的结果。

②执行过程。从输入到输出的过程或工作任务。

③检查过程。确定输出是否满足标准的处理过程。

④输出。推出标准或工作流程产生的可交付的结果。执行测试过程如图2-5所示。图2-5执行测试过程2.6.5评估测试软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。1．覆盖评测覆盖指标提供了“测试的完全程度如何”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。2．质量评测测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。3．性能评测评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。2.7测试的成功经验

为了减少系统的开发费用，越早测试越好，这是多年来软件行业的一个成功经验，即在整个软件开发生命周期中通过各种软件工程技术尽量早地完成各种软件测试任务。首先，软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程

在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都做出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。

通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期，在每个迭代周期都进行测试，这样在很大程度上提前了软件系统测试发生的时间，这可以在很大程度上降低项目风险和项目开发成本。第3章软件测试的方法和技术3.1软件测试方法概述3.2白盒测试3.3黑盒测试3.4测试用例设计3.1软件测试方法概述

软件测试的种类大致可分为人工测试和基于计算机的测试。而基于计算机的测试又可分为黑盒测试和白盒测试。1．黑盒测试黑盒测试是根据软件产品的功能设计规格，在计算机上进行测试，以证实每个已经实现的功能是否符合要求。黑盒测试意味着测试要在软件的接口处进行。2．白盒测试白盒测试是根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。白盒测试把测试对象看做一个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。3.2白盒测试

白盒测试也称为结构测试或逻辑驱动测试，前提是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能够按预定要求正确工作，而不管产品的功能，主要用于软件验证。

白盒测试方法又可分为静态测试和动态测试。静态测试是一种不通过执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。而动态测试需要软件的执行，当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析是动态测试的主要特点。它显示了一个系统在检查状态下是正确还是不正确。

白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：（1）保证一个模块中的所有独立路径至少被使用一次；（2）对所有逻辑值均需测试true和false；（3）在上下边界及可操作范围内运行所有循环；（4）检查内部数据结构以确保其有效性。

下面将介绍几种实用的白盒测试用例设计方法，包括程序插桩、逻辑覆盖、基本路径测试等。3.2.1程序插桩在软件动态测试中，程序插桩是一种基本的测试手段，有着广泛的应用。1．方法简介程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法。

如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况，或是每个语句的实际执行次数，最好的办法是利用插桩技术。这里仅以计算整数X和整数Y的最大公约数程序为例，说明插桩方法的要点。图3-3给出了这一程序的流程图。图3-3插桩后求最大公约数程序的流程图设计插桩程序时需要考虑的问题包括：①探测哪些信息；②在程序的什么部位设置探测点；③需要设置多少个探测点。2．断言语句在程序中特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实。我们把插入的这些语句称为断言。这一做法是程序正确性证明的基本步骤，尽管算不上严格的证明，但方法本身仍然是很实用的。下面以求两个非负数NUM和DEN之商的Wensley迭代算法为例，对断言语句的作用做一简要说明。图3-5计算非负数之商的迭代程序

图3-6插入断言后的迭代程序3.2.2逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术，是通过对程序逻辑结构的遍历实现程序的覆盖，它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。这一方法要求测试人员对程序的逻辑结构有清楚的了解，甚至要能掌握源程序的所有细节。它属于动态测试。

从覆盖源程序语句的详细程度分析，逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正条件判定覆盖。为便于理解，使用如下所示的程序，图3-7所示的是其流程图。图3-7参考例子流程图intfunction1（boola，boolb，boolc）{intx;x=0;if(a&&(b||c))x=1;returnx;}1．语句覆盖为了暴露程序中的错误，程序中的每条语句至少应该执行一次。所以，语句覆盖的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。2．判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖。按判定覆盖准则进行测试是指，设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。判定覆盖又称为分支覆盖。3．条件覆盖在设计程序中，一个判定语句是由多个条件组合而成的复合判定。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。4．条件判定组合覆盖条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。5．多条件覆盖多条件覆盖也称为条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。6．修正条件判定覆盖它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的bool条件，每个条件对于判定的结果值是独立的。7．测试覆盖准则（1）Foster的ESTCA覆盖准则前面所介绍的逻辑覆盖其出发点似乎是合理的。所谓“覆盖”，就是想要做到全面而无遗漏。但是，事实表明，它并不能真的做到无遗漏。

K.A.Foster从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准则。（2）Woodward等人的层次LCSAJ覆盖准则

Woodward等人曾经指出结构覆盖的一些准则，如分支覆盖或路径覆盖，都不足以保证测试数据的有效性。为此，他们提出了一种层次LCSAJ覆盖准则。3.2.3基本路径测试上节的例子是个比较简单的程序段，只有两条路径。但在实际问题中，即使一个不太复杂的程序，其路径的组合都是一个庞大的数字。如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为基本路径测试。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。1．程序的控制流图控制流图是描述程序控制流的一种图示方式。其中基本的控制结构对应的图形符号如图3-8所示。在图3-8所示的图形符号中，圆圈称为控制流图的一个结点，它表示一个或多个无分支的语句或源程序语句。图3-8控制流图的图形符号

图3-9（a）所示的是一个程序的流程图，它可以映射成图（b）所示的控制流图。图3-9程序流程图和对应的控制流图2．计算程序环路复杂性进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。所谓独立路径，是指包括若干未曾处理的语句或条件的一条路径。

基本路径集不是惟一的，对于给定的控制流图，可以得到不同的基本路径集。通常环路复杂性可用以下3种方法求得。

①将环路复杂性定义为控制流图中的区域数。

②设E为控制流图的边数，N为图的结点数，则定义环路的复杂性为V(G)=E−N+2。

③若设P为控制流图中的判定结点数，则有V(G)=P+1。3．基本路径测试法步骤基本路径测试法适用于模块的详细设计及源程序，其主要步骤如下。

①以详细设计或源代码作为基础，导出程序的控制流图。

②计算得到的控制流图G的环路复杂性V（G）。

③确定线性无关的路径的基本集。

④生成测试用例，确保基本路径集中每条路径的执行。3.2.4程序的静态测试1．源程序静态分析在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表，可以清晰地标识整个软件系统的组成结构，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。

通常采用以下一些方法进行源程序的静态分析。（1）生成各种引用表

①标号交叉引用表

②变量交叉引用表

③子程序（宏、函数）引用表

④等价表

⑤常数表（2）错误静态分析错误静态分析主要用于确定在源程序中是否有某类错误或“危险”结构。

①类型和单位分析

②引用分析

③表达式分析

④接口分析2．人工测试静态分析中进行人工测试的主要方法有桌前检查、代码审查和走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。（1）桌前检查由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。（2）代码审查代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。（3）走查走查与代码审查基本相同，其过程分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。3.2.5其他白盒测试方法简介1．域测试域测试是一种基于程序结构的测试方法。域测试正是在分析输入域的基础上，选择适当的测试点以后进行测试的。2．符号测试符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也因此而得名。3．Z路径覆盖分析程序中的路径是指检验程序从入口开始，执行过程中经历的各个语句，直到出口。4．程序变异程序变异方法是一种错误驱动测试。所谓错误驱动测试方法，是指该方法是针对某类特定程序错误的。经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围尽可能地缩小，以利于专门测试某类错误是否存在。错误驱动测试主要有两种，即程序强变异和程序弱变异。

最后，归纳一下白盒测试中各种测试方法的应用策略。在白盒测试中，可以使用各种测试方法的综合策略如下。（1）在测试中，应尽量先使用工具进行静态结构分析。（2）测试中可采取先静态后动态的组合方式：先进行静态结构分析、代码检查，再进行覆盖率测试。

（3）利用静态分析的结果作为导引，通过代码检查和动态测试的方式对静态发现结果进行进一步的确认，使测试工作更为有效。（4）覆盖率测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖标准；对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率。

（5）在不同的测试节点，测试的侧重点不同：在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析等；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。3.3黑盒测试

黑盒测试也称功能测试或数据驱动测试，前提是已知产品所具有的功能，通过测试来检测每个功能是否都正常使用。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测、功能图法等，主要用于软件确认测试。3.3.1等价类划分法等价类划分是一种典型的黑盒测试方法。使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。由于不可能用所有可以输入的数据来测试程序，而只能从全部可供输入的数据中选择一个自己进行测试。如何选择适当的子集，使其尽可能多地发现错误，解决的办法之一就是等价类划分。

首先，把数目极多的输入数据，包括有效的和无效的，划分为若干等价类，而所谓等价类，是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等价于对这一类其他值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可用少量代表性测试数据，取得较好的测试结果。等价类的划分有以下两种不同的情况。

①有效等价类

②无效等价类划分等价类的原则如下。①按区间划分②按数值划分③按数值集合划分④按限制条件或规则划分

在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表3-6所示。

再从划分出的等价类中按以下原则选择测试用例。

①为每一个等价类规定一个惟一的编号。

②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类；重复这一步骤，直到所有的有效等价类都被覆盖为止。

③设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。3.3.2边界值分析法人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。

选择测试用例的原则如下。

①如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。

②如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数作为测试数据。③根据规格说明的每一个输出条件，使用规则1。

④根据规格说明的每一个输出条件，使用规则2。

⑤如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试用例。⑥如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。⑦分析规格说明，找出其他可能的边界条件。3.3.3错误推测法人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。3.3.4因果图法因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的基本步骤如下。

①分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入条件或输入条件的等价类，结果是输出条件。②分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图。

③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干标准的符号标明约束条件。④把因果图转换成判定表。

⑤为判定表中的每一列设计测试用例。通常在因果图中，用Ci表示原因，Ei表示结果，其基本符号如图3-12所示。图3-12因果图的基本符号

对于黑盒测试方法来说，以上4种方法是基本的测试方法，除此之外还有判定表驱动法、正交试验法、功能图法和场景法等。在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平。

以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。

①首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。

②在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。③可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

④对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

⑤如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。⑥对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

⑦功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。

⑧对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。3.3.5场景法现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。1．基本流和备选流

如图3-14所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。图3-14基本流和备选流2．ATM例子（1）例子描述图3-15所示是ATM例子的流程示意图。图3-15ATM流程示意图（2）场景设计表3-8所示是生成的场景。（3）用例设计对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。（4）数据设计一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。3.4测试用例设计

3.4.1测试用例的基本概念简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。

如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接到通知后，将问题修改完成于下一个测试版本内，测试工程师取得新的测试版本后，必须利用同一个测试用例来测试这个问题，确保该问题已修改完成。

在测试时，不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。

使用测试用例的好处主要体现在以下几个方面。

①在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

②测试用例的使用令软件测试的实施重点突出、目的明确。③在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。

④功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断提高。

测试用例主要有如下几种。

①功能测试用例。包含功能测试、健壮性测试、可靠性测试。

②性能测试用例。包含性能测试、压力测试、强度测试。

③集成测试用例。包含接口测试、健壮性测试、可靠性测试。④安全测试用例。安全测试用例。⑤用户界面测试用例。用户界面测试用例、少量功能测试用例。⑥安装/反安装测试用例。安装/反安装测试用例。测试种类、阶段和用例的关系如表3-11所示。

测试工作和开发通常一同进行，所以在完成测试计划编写后，就可以进行用例的编写工作了。测试和开发的对应关系如表3-12所示。3.4.2测试用例的设计步骤测试按照阶段分为单元测试、集成测试以及系统测试。而各阶段都有相应的测试用例。这里，以单元测试的用例设计为依据来说明测试用例的设计步骤。

单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含以下4个关键元素。

①被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）。

②被测单元的输入，包含由被测单元读入的任何外部数据值。③该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如单元中哪一个决策条件被测试。

④测试用例的期望输出结果。测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。下面说明测试用例的设计步骤。（1）步骤1：使被测单元运行这个阶段适合的技术有：

①模块设计导出的测试；

②对等区间划分。（2）步骤2：正面测试（PositiveTesting）这个阶段适合的技术有：

①设计说明导出的测试；

②等价类分析；

③状态转换测试。（3）步骤3：负面测试（NegativeTesting）这个阶段适合的技术有：

①错误猜测；

②边界值分析；

③内部边界值测试；

④状态转换测试。（4）步骤4：需求中其他测试特性用例设计这个阶段适合的技术有：设计说明导出的测试。（5）步骤5：覆盖率测试用例设计这个阶段适合的技术有：

①分支测试；

②条件测试；

③数据定义——使用测试；

④状态转换测试。其中①和②均属于逻辑覆盖范畴。（6）步骤6：测试执行（7）步骤7：完善代码覆盖这个阶段适合的技术有：

①分支测试；

②条件测试；

③设计定义——试验测试；

④状态转换测试。最后，总结一下用例设计的一般原则。

通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量。

测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。

在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试代码本身。3.4.3测试用例的编写1．测试用例计划的编写2．测试设计说明3．测试用例说明测试用例的编写请参考表3-13。表3-13 测试用例

4．测试程序说明图3-16所示是“Windows计算器”的测试程序说明的例子片断。图3-16测试程序说明片断3.4.4测试用例设计实例1．软件设计说明导出的测试2．基本路径测试3．等价类划分4．因果图法5．边界值分析3.4.5测试用例的管理可以把测试用例看成程序——测试工程师编写的程序，这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作。1．用例评审有效的用例评审通常由下面两种形式组成。①测试部门外部评审②测试部门内部评审通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。2．用例管理版本管理是用例管理的核心部分，建议采用工具（例如VisualSourceSafe）对用例进行控制。建议用例参照图3-19进行管理。图3-19用例管理示意图第

4章

软件测试过程4.1软件测试过程概述4.2单元测试4.3集成测试4.4系统测试4.5验收测试4.6回归测试4.7系统排错4.1软件测试过程概述

软件测试过程与软件工程的开发过程是相对的。第2章图2-1采用V形图表示软件开发与软件测试的对应关系，也可以采用图4-1所示的螺旋形图来表示这种关系。图4-1测试过程

单元测试的目的是保证每个模块单独运行正确，多采用白盒技术，检查模块控制结构的某些特殊路径，期望覆盖尽可能多的出错点。经单元测试后的模块，组装为软件包，对软件包进行集成测试，主要测试软件结构问题，因测试建立在模块间的接口上，所以多为黑盒测试，适当辅以白盒测试技术，以便能对主要控制路径进行测试。

系统测试主要是检验软件是否满足功能、行为和性能方面的要求，这一步完全采用黑盒测试技术。验收测试是检验软件产品的最后一道工序，与前面各种测试过程的不同之处主要在于它突出了客户的作用，同时软件开发人员也要参与。4.2单元测试

单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。

单元测试应对模块内所有重要的控制路径进行测试，以便发现模块内部的错误。单元测试是检查软件源程序的第一次机会，通过孤立地测试每个单元，确保每个单元工作正常，这样比单元作为一个更大系统的一个部分更容易发现问题。在单元测试中，每个程序模块可以并行、独立地进行测试工作。4.2.1单元测试的主要任务单元测试是针对每个程序模块进行测试，单元测试的主要任务是解决以下5个方面的测试问题。1．模块接口测试针对模块接口测试应进行的检查，主要涉及以下几方面的内容。①模块接受输入的实际参数个数与模块的形式参数个数是否一致。

②输入的实际参数与模块的形式参数的类型是否匹配。

③输入的实际参数与模块的形式参数所使用单位是否一致。④调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。

⑤调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。

⑥调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位一致。

⑦调用内部函数时，参数的个数、属性和次序是否正确。⑧在模块有多个入口的情况下，是否有引用与当前入口无关的参数。⑨是否会修改了只读型参数。⑩出现全局变量时，这些变量是否在所有引用它们的模块中都有相同的定义。11.有没有把某些约束当做参数来传送。2．模块局部数据结构测试3．模块中所有独立执行路径测试4．各种错误处理测试5．模块边界条件测试4.2.2单元测试的执行过程一般情况下，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试。测试用例设计应与复审工作相结合，根据设计信息选取数据，将增大发现上述各类错误的可能性。

在进行单元测试时，需设置若干辅助测试模块。辅助模块有两种，一种是驱动模块（Driver），用以模拟被测试模块的上级模块。另一种是被调用模拟子模块（Sub），用以模拟被测模块工作过程中所调用的模块。图4-2显示了一般的单元测试环境。图4-2一般单元测试环境4.2.3单元测试技术和测试数据用于单元测试的主要技术如下。1．静态测试2．白盒测试3．状态转换测试4．功能测试和非功能测试

单元测试中使用的数据，通常不使用真实数据。当被测试单元的功能不涉及操纵或使用大量数据时，测试中可以使用有代表性的一小部分手工制作的测试数据。在创建测试数据时，应确保数据充分地测试单元的边界条件。当被测试单元要操纵大量数据，并且有很多单元都有这种需求时，可以考虑使用真实数据的一个较小的有代表性的样本。测试时还要考虑往样本数据中引入一些手工制作的数据，以便测试单元的某个具体特性，例如对错误条件的响应等。

当测试一个单元要从远程数据源接收数据时（例如，从一个客户端/服务器系统中接收数据），有必要在单元测试中使用测试辅助程序，来模拟对这些数据的访问。但在考虑这种选择时，必须首先对开发的测试辅助程序进行测试，以保证模拟的真实性。4.2.4单元测试人员单元测试一般由开发设计人员本身完成，一般由开发组在组长的监督下进行，由编写该单元的开发设计者设计所需的测试用例和测试数据，来测试该单元并修改缺陷。开发组组长负责保证使用合适的测试技术，在合理的质量控制和监督下执行充分的测试。4.3集成测试将经过单元测试的模块按设计要求连接起来，组成所规定的软件系统的过程称为“集成”。4.3.1集成测试的主要任务集成测试是组装软件的系统测试技术之一，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试的主要任务是要求软件系统符合实际软件结构，发现与接口有关的各种错误。单元测试的主要任务是解决以下5个方面的测试问题。①将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。

②将各个子功能组合起来，检查能否达到预期要求的各项功能。

③一个模块的功能是否会对另一个模块的功能产生不利的影响。

④全局数据结构是否有问题，会不会被异常修改。

⑤单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。4.3.2集成测试方法集成测试包括两种不同方法：非增量式集成和增量式集成。1．非增量式测试方法概括来说，非增量式测试方法是采用一步到位的方法来进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。图4-3给出的是采用这种非增量式的集成测试方法的一个经典例子。2．增量式测试方法（1）自顶向下增量式测试自顶向下增量式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。图4-4自顶向下集成集成测试的整个过程由下列3个步骤完成。

①主控模块作为测试驱动器，把对主控模块进行单元测试时引入的被调用模拟子模块用实际模块替代。

②依照所选用的模块集成策略（深度优先和广度优先），下层的被调用模拟子模块一次一个地被替换为真正的模块。

③在每个模块被集成时，都必须立即进行测试一遍。

回到第2步重复进行，直到整个系统结构被集成完成。图4-5给出了一个按广度优先策略进行集成测试的典型例子。图4-5自顶向下增量式测试（广度优先策略）（2）自底向上增量式测试自底向上增量式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。图4-6表示了采用自底向上增量式测试实现同一实例的过程。图4-6自底向上增量式测试4.3.3集成测试技术和测试数据集成测试主要测试软件的结构问题，因为测试建立在模块的接口上，所以多为黑盒测试，适当辅以白盒测试。

执行集成测试应遵循下面的方法。

①确认组成一个完整系统的模块之间的关系。

②评审模块之间的交互和通信需求，确认出模块间的接口。

③使用上述信息产生一套测试用例。

④采用增量式测试，依次将模块加入到（扩充）系统，并测试新合并后的系统，这个过程以一个逻辑/功能顺序重复进行，直至所有模块被功能集成进来形成完整的系统为止。

此外，在测试过程中尤其要注意关键模块，所谓关键模块一般都具有下述一个或多个特征。

①对应几条需求。

②具有高层控制功能。

③复杂，易出错。

④有特殊的性能要求。

因为集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，因此集成测试对数据的要求无论从难度和内容来说一般不是很高。集成测试一般也不使用真实数据，测试人员可以使用手工制作一部分代表性的测试数据。在创建测试数据时，应保证数据充分测试软件系统的边界条件。在单元测试时，根据需要生成了一些测试数据，在集成测试时可适当地重用这些数据，这样可节省时间和人力。4.3.4集成测试遵循的原则集成测试很不好把握，应针对总体设计尽早开始筹划。为了做好集成测试，需要遵循以下原则。①所有公共接口都要被测试到。②关键模块必须进行充分的测试。③集成测试应当按一定的层次进行。④集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。

⑤集成测试应当尽早开始，并以总体设计为基础。

⑥在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。

⑦当接口发生修改时，涉及的相关接口必须进行再测试。

⑧测试执行结果应当如实记