软件测试技术完整教程(一)

《软件测试技术完整教程(一)》由会员分享，可在线阅读，更多相关《软件测试技术完整教程(一)（234页珍藏版）》请在金锄头文库上搜索。

1、第一章第一章 概概 述述 本章要点本章要点 l 软件测试的发展历史；l 软件测试技术的分类方法；l 软件测试原则；l 软件测试的定义；l 软件测试同软件开发之间的关系；l 软件测试与开发模型；l 软件测试工作流程。 本章目标本章目标 u 了解软件测试的发展历程和行业现状；u 掌握软件测试技术的分类；u 理解软件测试的目的和软件测试原则，以及了解 人们对软件测试行业的错误认识；u 掌握软件测试中的基本定义、基本知识;u 理解软件开发与软件测试的关系。 1.1软件测试的软件测试的发展发展历程及现状历程及现状 1.1.1软件测试的发展历程软件测试的发展历程 20世纪50-60年代，软件仍然处于次要位

2、置,测试理论和方法的发展比较缓慢。70年代以后，软件技术的成熟和完善使得软件测试的规模和复杂度加大，软件测试也逐渐形成了一套完整的体系，逐渐走向规范化。 1.1.2软件测试的现状软件测试的现状 与一些发达国家相比，国内测试工作还存在一定的差距。国内测试人员所占比例小，但是，在软件测试实现方面都是相当的，而且向产业化方向发展。 1.2 1.2 什么是软件测试什么是软件测试 1.2.11.2.1软件测试的定义软件测试的定义 根据侧重点的不同，主要有以下三种观点： 1）1983年IEEE将软件测试定义为：“使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果

3、与实际结果之间的差别”，该定义明确地提出了软件测试以检验是否满足需求为目标。 2）Myers认为：“是为了发现错误而执行程序的过程”，明确提出了“寻找错误”是测试目的。 3）从软件质量保证的角度看：是一种重要的软件质量保证活动，其动机是通过一些经济、高效的方法，捕捉软件中的错误，从而达到保证软件内在质量的目的。 测试过程中的活动包括“分析”软件（静态测试）和“运行”软件（动态测试）。 也有人认为软件测试（software testing）就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。 软件测试有两个基本职责：即验证和确认。 注意：区分软件测试和软

4、件调试。 1.2.21.2.2软件测试生命周期软件测试生命周期 测试的生命周期（softwaretestinglifecycle）分为几个阶段（如图1-1所示 ）。 前三个阶段就是引入程序错误阶段； 后三个阶段就是清除程序错误的阶段。 图1-1 测试生命周期 1.2.3 1.2.3软件开发与测试模型软件开发与测试模型 下面我们将介绍几种典型的软件开发与测试模型。 一、软件开发与测试一、软件开发与测试V V模型模型 在传统开发过程中测试不受重视，仅把它作为在需求分析、概要设计、详细设计及编码之后的一个阶段。尤其在瀑布模型中。 如图1-2所示，在V模型中，描述了一些不同的测试级别，并说明了这些级别

5、所对应的生命周期中不同的阶段，清楚地描述了这些测试阶段和开发过程期间的对应关系。 图1-2 V模型示意图 V模型适用于所有类型的开发过程，但并不一定适用于开发和测试过程的所有方面。 二、软件开发与测试二、软件开发与测试WW模型模型 由于各种原因，开发的每一个环节都可能产生错误，如果坚持各个阶段的技术评审,就能够尽早发现和预防错误。 图1-3为软件开发与测试的W 模型，形象地说明了软件测试与开发的这种同步性。 图1-3 W模型示意图 应用该模型的优点在于，每个软件开发活动结束后就可以执行相应的测试，如：在需求分析结束后，就可以进行需求分析测试。 三、软件开发与测试三、软件开发与测试H H模型模型

6、 与前两种模型相比，H模型充分地体现了测试过程。如图1-4所示的H 模型揭示了: 1、 软件测试不仅仅指测试的执行, 还包括很多其他的活动。 2、软件测试是一个独立的流程, 贯穿产品的整个开发周期, 与其它流程并发进行。 3、软件测试要尽早准备, 尽早执行。 图1-4 H模型示意图 4、软件测试根据被测物的不同是分层次的. 不同层次的测试活动可以是按照某个次序先后进行的, 但也可能是反复的。 1.2.4 1.2.4与软件测试相关的术语与软件测试相关的术语 1.错误（Error） 程序员在编写代码时会出错，我们把这种错误称之为bug。随着开发过程的进行，错误会不断的放大。 2.缺陷(Defaul

7、t) 缺陷是错误的结果，更精确的说是错误的表现。 3.失效（Failure） 在缺陷运行时，常常会发生失效的情况。一种是过错缺陷对应的失效；一种是遗漏缺陷对应的失效。 4.测试（Test） 测试是一项采用测试用例执行软件的活动，在这项活动中某个系统或组成的部分将在特定的条件下运行，然后要观察并记录结果，以便对系统或组成部分进行评价。 5.测试用例(Test Case) 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。 6.回归测试（Regression testing） 回归测试的目的是为了测试由于修正缺陷而更新的应用程序，以确保彻底修正了上一个版本的缺陷，并且没有引入新的软

8、件缺陷。 1.31.3软件测试技术分类软件测试技术分类 从不同的角度，可以把软件测试技术分成不同种类，如： 一 、从是否需要执行被测软件的角度，可分为静态测试和动态测试。 那些不利用计算运行被测程序，而是通过其他手段达到测试目的的方法称作静态测试。下面我们对这几种静态测试分别加以介绍： 代码检查 代码走查 桌面检查 同行评分 下面我们将要介绍的黑盒测试和白盒测试就属于动态测试。 二、从软件测试用例设计方法的角度，可分为黑盒测试（Black-Box Testing）和白盒测试（White-Box Testing）。 三、按照软件测试的策略和过程分类，软件测试可分为单元测试(UnitTesting

9、)、集成测试(IntegrationTesting)、确认测试(ValidationTesting)、系统测试(SystemTesting)和验收测试(VerificationTesting)。 1.4 1.4软件测试的目的软件测试的目的 测试真正的目的是使我们通过对软件错误的原 因和分布进行归纳，来发现并排除当前软件产品的 缺陷，对在需求和设计过程中存在的问题查缺补漏，从而确保软件产品的质量。 GMyers给出了关于测试的一些规则，我们也可以把这些规则看作是测试的目标： 1)软件测试是为了发现错误而执行程序的过程。 2)测试是为了证明程序有错，而不是证明程序无错。 3)一个好的测试用例在于他

10、能发现至今未发现的错误。 4)一个成功的测试是发现了至今未发现的错误的测试。 这里要强调的一点是，软件测试不只是软件测试人员的工作，也是软件开发人员和软件使用者的工作。 1.51.5软件测试的原则软件测试的原则 1.5.1 1.5.1尽早地和不断地进行软件测试尽早地和不断地进行软件测试 IBM的研究结果表明，缺陷存在放大趋势。图1-5表示了缺陷放大模型大致状况。图1-5 缺陷放大模型 由此可见，问题发现越早，解决问题的代价就越小，这是软件开发过程中的黄金法则。 1.5.21.5.2不可能完全的测试不可能完全的测试 对一个程序进行完全测试就是意味着在测试结束之后，再也不会发现其它的软件错误了。其

11、实，这是不可能的，主要原因有以下几点： 一、不可能测试程序对所有可能输入的响应。 二、不可能测试到程序每一条可能的执行路径 三、无法找出所有的设计错误 四、不能采用逻辑来证明程序的正确性 1.5.3 1.5.3增量测试，由小到大增量测试，由小到大 图1-7 测试资源关系图 由小到大，指的是软件测试的粒度。无论是传统的软件测试还是面向对象的软件测试都要遵循这样的原则。如图1-7所示，多个单元组合过渡到集成测试阶段，集成测试阶段过渡到更高级别的系统测试阶段，虚线是各个测试阶段的发布基线。随着测试的逐步深入，范围的逐步扩大，测试时间、可用资源也随之增大。 1.5.4 1.5.4避免测试自己的程序避免

12、测试自己的程序 避免程序员测试自己的代码的主要原因归纳如下： 1.程序员轻易不会承认自己写的程序有错误。 2.程序员的测试思路有局限性，在做测试时很容易受到编程思路的影响。 3.多数程序员没有严格正规的职业训练，缺乏专业测试人员的意识。 4.程序员没有养成错误跟踪和回归测试的习惯. 1.5.5 1.5.5设计周密的测试用例设计周密的测试用例 软件测试的本质就是针对要测试的内容确定一组测试用例。测试用例至少应该包括如下几个基本信息： 1、在执行测试用例之前，应满足的前提条件。 2、输入（合理的、不合理的）。 3、预期输出（包括后果和实际输出）。 图1-8显示了一个典型的测试用例所应该具有的基本信

13、息。图1-8 典型的测试用例信息 测试用例是测试工作的核心，应该尽量设计的周密细致，这样才能更好的保证测试工作的质量。 下面举例来说明这一点。 以一个实现登录功能的小程序为例，它允许用户选择城市和地区，输入自己的账号和密码。 如图1-9所示，通过Alt-F4组合键和“Exit”按钮来终止程序，Tab键在区域中间移动。 图1-9 登录窗口下面根据组成页面的具体元素，分别从几个方面做了一些比较全面的测试用例：1. 下拉框和输入框测试用例 表1-1 下拉框和输入框测试用例测试测试内容内容输输入操作入操作预预期期输输出出实际结实际结果果下拉框下拉框未和后台数据未和后台数据库绑库绑定定（显显示列表元素固

14、示列表元素固定）定）不允不允许许列表中出列表中出现现NULL现现象，固定象，固定“请选择请选择-”已和后台数据已和后台数据库绑库绑定定（显显示列表元素活示列表元素活动动）不允不允许许列表中出列表中出现现NULL现现象，固定象，固定“请选择请选择-”输输入入框框限定字符限定字符型型输输入入12、6无无#，*等等错误错误提示提示限定型数限定型数字字输输入入测试测试数据数据无无12月、月、7*、0错误错误提示提示2、功能测试 （表1-2 功能测试用例）用例应产生行为结果失败原因1.基本功能测试1.1在输入框内输入资料并且执行存储程序必须能够接受使用者的输入并且将输入值存在登录文件内1.2在输入框内不

15、输入资料但执行储存程序必须能够检查使用者输入是否为空白，同时必须能够告知使用者原因1.3检查city字段储存结果City字段输入后存入cookies1.4检查area字段储存结果Area字段输入后存入cookies储存结果1.5检查ID字段储存结果ID字段输入后存入cookies2.使用接口功能测试2.1检查输入字段的输入值必须组织使用者输入空白，同时部分字段只能输入数字2.2检查使用者接口的TabOrder所有的TabOrder必须按照正常顺序2.2检查所有的Button所有的Button必须能够起作用2.3检查所有的HotKey所有的HotKey必须能够起作用3、各种错误数据的测试表1-3

16、 错误数据的测试用例测试内容测试内容输入操作输入操作预选测试数预选测试数据据预期输出预期输出实际结果实际结果点击登录点击登录按钮按钮不完整的数不完整的数据据CityCity，areaarea，IDID，pswdpswd略略提示错误对话提示错误对话框框不正确的数不正确的数据据CityCity，areaarea，IDID，pswdpswd略略提示错误对话提示错误对话框框回车操作回车操作不完整的数不完整的数据据CityCity，areaarea，IDID，pswdpswd略略提示错误对话提示错误对话框框点击点击“退退出出”按钮按钮无无无无无无关闭当前应用关闭当前应用系统系统4、特殊测试 表1-4 特

17、殊测试用例测试内容测试内容输入操作输入操作预选测试数预选测试数据据预期输出预期输出操作焦点逃操作焦点逃逸逸连续连续TabTab切换，察看异常切换，察看异常无无焦点可准确回归焦点可准确回归当前操作窗口当前操作窗口分配内存不分配内存不足足启动多个应用程序或模拟启动多个应用程序或模拟多个程序运行多个程序运行无无是否可以正常运是否可以正常运行行网络断线网络断线切断网络连接切断网络连接无无是否可正常抛出是否可正常抛出异常异常 1.5.6 1.5.6注意错误集中的现象注意错误集中的现象 软件缺陷的“扎堆”现象的常见形式： 1、对话框的某个控件功能不起作用，可能其他控件的功能也不起作用。 2、某个文本框不能

18、正确显示双字节字符，则其他文本框也可能不支持双字节字符。 3、联机帮助某段文字的翻译包含了很多错误，与其相邻的上下段的文字可能也包含很多的语言质量问题。 4、安装文件某个对话框的“上一步”或“下一步”按钮被截断，则这两个按钮在其他对话框中也可能被截断。 1.5.7 1.5.7确认确认BUGBUG的有效性的有效性 有时候测试人员提交的BUG并不是真正的BUG。图1-10具体地描述了无效BUG的来源。一般由A测试人员发现的BUG，一定要由另外一个B测试人员来进行确认，如果发现严重的BUG可以召开评审会进行讨论和分析。图1-10 无效BUG来源构成图 1.5.8 1.5.8合理安排测试计划合理安排测

19、试计划 合理的测试计划有助于测试工作顺利有序地进行，因此要求在对软件进行测试之前所作的测试计划中，应该结合了多种针对性强的测试方法、列出所有可使用资源，建立一个正确的测试目标； 要本着严谨、准确的原则，周到细致地做好测试前期的准备工作，避免测试的随意性。尤其是要尽量科学合理地安排测试时间。 图1-11 错误依赖关系1.5.91.5.9回归测试回归测试 这些错误之间存在单纯的依赖或者复杂的多重依赖关系，如图1-11所示。 其中，（a）图中的A、B 关系表达为：A错误依赖于B错误的关闭而关闭。如果多了一条路径（如（b）图中A、B、C关系），A错误依赖于B错误和C错误的同时关闭而关闭。（c）图是（a

20、）和（b）的复合方式，因程序中的错误存在着一对多，多对多的复杂关系而变得难以处理，并且有些错误关联和依赖关系处于隐性状态。 1.5.10 1.5.10测试结果的统计和分析测试结果的统计和分析 只有对这些输出信息进行深入地统计、分析和比较，才能够正确的鉴别测试后输出的数据，给出清晰的错误原因分析报告。当输出的信息很庞大时，我们可以借助专业的测试工具。 1.5.11 1.5.11及时更新测试及时更新测试 事实上，有可能导致测试失败的原因还有很多，可大致归纳为如下几点： 1、测试团队管理者失职； 2、测试团队中沟通不好； 3、测试团队和项目团队沟通不良； 4、测试过程中，执行角色无准确定义； 5、测

21、试团队缺乏良好的培训。 1.6 1.6软件测试工作流程软件测试工作流程 一般的软件测试总体工作流程如图1-12所示： 图1-12 软件测试工作总体流程图 1、需求阶段 需求阶段是软件测试活动的前提。需求阶段测试工作流程如图1-13所示： 图1-13 需求阶段测试活动流程图2、设计&编码阶段测试工作流程 图1-14 设计&编码阶段测试流程图 这一环节以模块为单位循环：单元测试方案制定编码单元测试是否通过测试抽检是否通过，重新编写没有通过单元测试和测试抽检的代码。最终形成一份单元测试总结报告。具体流程如图1-14所示。 3、集成测试、系统测试和验收测试阶段 该测试阶段流程如图1-15所示： 图1-

22、15 集成测试、系统测试和验收测试阶段流程图 1.7 1.7软件测试中的误区软件测试中的误区 误区1 调试和测试是一样的 误区2 软件测试在软件开发过程中并不重要 误区3 在软件开发结束之后进行测试 误区4 过分依赖Beta测试 误区5 过分依赖自动化测试 误区6 测试是可穷尽的 误区7 测试是证明软件的正确性 误区8 可以忽略测试的设计 1.81.8一个贯穿全文的例子一个贯穿全文的例子 电厂两票管理系统电厂两票管理系统 1.8.1 1.8.1系统简介系统简介 操作票、工作票（简称两票）是“电业(电厂)安全工作规程”中的核心内容之一，对保证电业安全生产具有重要的作用。操作票是保证正确电气倒闸（

23、热机）操作的重要环节和前提条件，使用操作票的目的是为了保障人身与设备的安全，确保电气设备倒闸操作的正确性，防止电气误操作事故发生。 工作票是保证电气(电厂设备)检修工作安全的重要措施，是检修人员在运行设备上或运行区域内进行检修和试验工作，以及做可能影响设备的正常运行或备用状态的其它工作的重要书面依据。“两票”的办理过程基本上都是开票、各部门负责人或三种人审批签字、工作结束、部门或厂部检查审核这样的一种线性办理过程。 电力部门分为水电、火电、供电三种类型，各厂、局要处理的两票类型通常有： 水电厂：电气一种工作票、电气二种工作票、水力机械工作票、一级动火工作票、二级动火工作票、电气倒闸操作票、继保

24、安措票、脚手架工作单、水力机械操作票、溢洪闸门操作票 火电厂：电气一种工作票、电气二种工作票、水力机械工作票、一级动火工作票、二级动火工作票、电气倒闸操作票、继保安措票、脚手架工作单、热力工作票 供电局：电气一种工作票、电气二种工作票、水力机械工作票、一级动火工作票、二级动火工作票、电气倒闸操作票、继保安措票、脚手架工作单、 一种工作票、线路二种工作票。 为了使读者更好的了解两票系统以及后面各章节的内容，在这里对一些电力系统专业术语作如下解释： 一次图：电气主接线是由高压电器通过连接线，按其功能要求组成接受和分配电能的电路，成为传输强电流、高电压的网络，故又称为一次接线。那么用规定的设备文字和

25、图形符号并按工作顺序排列，详细地表示电气设备或成套装置的全部基本组成和连接关系的单线接线图，成为主接线电路图，这里简称为一次图。 二次图：在电力系统中，凡监视、控制、测量以及起保护作用的设备，如机电保护、控制和信号装 置等，皆属于二次设备。二次接线就是由二次设备构成的回路。这里我们就把二次设备接线图简称为二次图。 分厂：发电厂通常由多个分厂组成，其中电气分厂、汽机分厂和锅炉分厂是发电厂的几个重要的分厂。 电气设备：为满足生产的需要，发电厂中安装有各种设备。通常把生产和分配电能的设备称为一次设备，具体包括如下几种：生产和转换电能的设备；接通或断开电路的开关电器；限制故障电流和防御过电压的电气；接

26、地装置；载流导体。此外还有一些对一次设备进行测量、控制、监视和保护用的二次设备，如：仪用互感器；机电保护及自动装置；直流电源设备等。 在本书中提到的刀闸、开关等设备就属于电气设备。 “五妨”规则：电力系统的倒闸操作具有前后顺序和严格的逻辑规则。“五防”规则就是根据电气运行人员多年的运行经验，总结出来的倒闸操作规则，如下： 1、防止误分合断路器;防止带地线合刀闸 2、防止带负荷拉合隔离开关; 3、防止带电挂接地线或接地刀闸; 4、防止带接地线或合接地刀闸送电; 5、防止误入带电间隔 1.8.21.8.2系统运行环境系统运行环境 客户端平台：windows98/2000、windows NT wo

27、rkstation、Linux等所有具有支持JAVA的浏览器系统； 服务器端平台：windows2000 server、windows NT Server、Linux、UNIX等所有支持JAVA Bean的系统平台； 数据库服务器：Oracle数据库或SQL Server 2000数据库或ACCESS数据库。 Web服务器：Tomcat 5.0 1.8.31.8.3系统总体结构系统总体结构 两票系统主要由两部分构成，即：操作票子系统和工作票子系统。整个系统的总体结构如图1-16所示：1.8.41.8.4系统功能系统功能( (略略) )图1-16 两票系统总体结构图 本章小结本章小结 本章介绍了

28、软件测试发展的历程，以及其在国内的发展状况。随着软件开发过程和开发技术的不断改进，软件测试理论和方法也在不断完善，测试工具也在蓬勃发展。 通过本章的论述，可以了解到软件测试已经不再只是进行简单的程序逻辑检查，而是一个伴随着整个软件开发过程的活动。 测试对象也不仅仅是程序代码，而开发过程中产生的所有软件产品，甚至是产品使用说明也包括在内。 测试过程中为了更好的保证软件测试的质量，首先要遵循一定的测试原则，最为重要的就是应该尽早的进行测试。 其次，正确处理开发与测试之间的关系，更好的把开发与测试过程集成到一起。从而提高测试效率，节约测试成本。 本章所介绍的几种软件开发与测试模型，如：V模型、W模型

29、和H模型，三种模型在不同程度上反映了软件开发与软件测试的关系。 其中，V模型非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了测试和开发过程中各阶段的对应关系。而W模型作为V模型的改进，更好地体现了软件开发与软件测试工作的同步性，更为明确地指出测试的对象不仅仅是程序本身，而且包括需求分析、概要设计和详细设计说明书，强调了软件测试是软件开发过程中的一项重要的工作，贯穿于整个软件开发过程。 H模型则从微观的角度来看待软件测试过程。 最后一个做好测试工作的关键因素就是精心的组织和安排软件测试的工作流程，本章把测试工作分为几个阶段，分别阐述了通用的测试工作流程，但要求读者在工作中，根据每个项目

30、的具体情况制定可行的测试流程。 各种测试技术是软件测试工作的敲门砖，本章从不同的角度介绍了软件测试技术的分类。 从是否需要执行被测软件的角度，可分为静态测试（Static Testing）和动态测试（Dynamic Testing）； 从测试用例设计的角度，可分为黑盒测试和白盒测试；按照软件测试过程和测试策略，可分为单元测试、集成测试和系统测试。 另外，本章还专门介绍了目前在实际工作中对软件测试的错误认识，希望读者能够明确软件测试的目的，正确的认识软件测试工作的必要性和重要性。习题习题1.名词解释： 软件测试 错误 缺陷 失效 测试用例 回归测试 静态测试 动态测试 黑盒测试 白盒测试 单元测

31、试 集成测试 系统测试 2.简述软件测试发展的过程。从不同角度描述软件测试的现状。3.测试的生命周期可以分为几个阶段？简单描述各阶段需要完成的任务。4.什么是V模型？简述V模型在软件测试过程中的作用，以及在V模型中各个测试阶段和开发过程的对应关系。5.请概括一下静态测试和动态测试，以及黑盒测试与白盒测试的不同点。6.分别描述一下，需求阶段、设计&编码阶段、集成系统验收测试的软件测试流程。7.列举软件测试的目的。8.列举软件测试的十项原则。9.列举软件测试的误区。第二章第二章 软件测试基础软件测试基础 本章要点本章要点 软件测试基础知识； 白盒测试和黑盒测试的定义； 常见的白盒和黑盒测试设计技术

32、； 白盒测试与黑盒测试的区别； 测试计划和测试报告的编制； 测试用例的定义和编制方法。 本章目标本章目标 u掌握有关测试的一些数学知识，包括集合、函数和图论基础等；u理解并掌握白盒测试和黑盒测试，以及二者的优缺点和各自的应用范围；u能够熟练使用几种常见测试用例设计技术；u了解测试计划和测试文档的作用，以及应该包含的内容和制定方法；u了解测试报告的基本内容，以及测试用例的基本内容和编制方法。 2.12.1用于测试的离散数学和图论基础用于测试的离散数学和图论基础 一般而言，在功能性测试中，通常要用到离散数学知识，而在结构性测试领域中，则要用到一些关于图论的知识。 2.1.1 2.1.1集合论集合论

33、 集合论可分为：自然和不言自明两种。自然的集合论把集合看作是基本术语，我们把集合看作一个单位，或一个整体引用多个事物。 集合的表示法有以下两种： 1、将集合所有元素一一列出的表示法叫做“枚举法”，但有时也可以只列出一部分元素。 2、用一个集合所具有的共同性质来刻画这个集合。 2.1.2 2.1.2函数函数 简而言之，函数是将唯一的输出值赋予每一输入的“法则”。 2.1.3 2.1.3关系关系 通俗的讲，关系就是客观世界一定范围的对象之间的某种特定联系。 集合之间的关系集合之间的关系 定义: : 给定两个集合A和B，关系R是笛卡儿积A B的一个子集。 如果希望描述整个关系，则通常只写RAB。对于

34、特定元素aiA、biB，我们记做aiRbi 。 关系的表示关系的表示 关系关系表示事物之间的某种联系，二元关系表示两个事物之间的关系，如果把这两个事物分别放在一边，如果某两个元素有关系，那么就在它们之间画一条有向线，用这种方式表示关系，称作关系图。 这里我们必须对“势”进行解释。势在用于集合时，是指集合中的元素的个数。 定义定义: : 给定两个集合A和B，一个关系RAB，关系R的势是： 1）一对一势 2）多对一势 3）一对多势 4）多对多势 单个集合上的关系单个集合上的关系 首先，我们对关系进行定义。设A是一个集合，RAA是定义在A上的一个关系，、R。关系具有四个特殊属性： 定义定义: : 关

35、系RAA是： 1）自反的 2）对称的 3）反对称的 4）传递的 2.1.4 2.1.4命题逻辑命题逻辑 凡是能分辨其真假的语句都叫做命题。我们通常采用小写字母p，q和r表示命题。 命题逻辑有着和集合论相似的操作，表达式和标识。命题的真值只有两种，T代表真，而F代表假。 命题公式的分类：命题公式的分类： 如果命题公式A在任意的真值赋值函数t : U0, 1下的真值t(A)都为1,则称命题公式A为永真式(tautology)（或称重言式）； 如果命题A在任意的真值赋值函数下的真值都为0，则称A为矛盾式(contradiction)； 如果A不是矛盾式，则称为可满足式。 2.1.52.1.5概率论概

36、率论 概率是随机事件发生的可能性的数量指标。 在独立随机事件中，如果某一事件在全部事件中出现的频率，在更大的范围内比较明显的稳定在某一固定常数附近。就可以认为这个事件发生的概率为这个常数。对于任何事件的概率值一定介于 0和 1之间。 2.1.6 2.1.6用于测试的图用于测试的图 测试中使用两种基本图：无向图和有向图。这里我们给出一些概念。 图（又叫做线性图）是一种由两种集合定义的抽象数据结构，即一个节点集合和一个构成节点之间连接的集合。 图中节点的度节点的度是以该节点作为端点的边的条数。 在本节中将介绍的三种图：程序图、有限状态机、状态图。 1、程序图 经过改进的程序图定义：节点要么是整个语

37、句，要么是语句的一部分，边表示控制流（从节点i到节点j有一条边，当且仅当对应节点j的语句或语句的一部分，可以立即在节点i对应的语句或语句的一部分之后执行）。 程序的有向图公式化能够非常准确地描述程序的测试方面的问题。基本结构化程序设计的构造，例如：串行、选择和循环等可以用如图 2-1所示的有向图表示。图2-1 结构化程序设计构造的有向图 2、有限状态机 有限状态机已经成为需求规格说明的一种相当标准的表示方法。有限状态机是一种有向图，其中状态是节点，转移是边。 图2-2是一个简单的自动柜员机(SATM)系统。该图描述了用于个人标识编号PIN尝试部分的有限状态机。这种机器包含5 个状态（空闲、等待

38、第一次PIN尝试等等）和8个用边表示的转移。转移上的标签所遵循的规则是，“分子”是引起转移的事件，“分母”是与该转移关联的行为。图2-2 用于PIN尝试的有限状态机 3、状态图 状态图现在被Rational公司选为统一建模语言，即UML的控制模型。图2-3 状态图的团点 Harel使用与方法无关的术语“团点”表示状态图的基本构建块。在图2-3中，团点A包含两个团点B和C，通过边连接。团点A通过边与团点D连接。 根据Harel的意图，我们可以把团点解释为状态，把边解释为转移。 在图2-4中，状态A是初始状态，当进入到这个状态时，也进入低层状态B。当进入某个状态时，我们可以认为该状态是活动的，这可

39、与Petri网中的被标记地点类比。状态图工具采用色彩表示哪个状态活动的，并等效于Petri网中的标记地点。 图2-4中有一些微妙的地方，从状态A转移到状态D初看起来是有歧义的，因为它没有区分状态B和C。约定是，边必须开始和结束于状态的周围。如果状态包含子状态，就像图中的A一样，边会“引用”所有的子状态。 因此，从A到D的边意味着转移可以从状态B或从状态C发生。如果有从状态D到状态A的边，如图2-5所示，则用B来表示初始状态这个事实，意味着转移实际上是从状态D到状态B。这种约定可以大大减缓有限状态机向“空心代码”发展的趋势。 图2-4 状态图中的初始状态 图2-5 进入自状态的默认入口 我们最后

40、要讨论的一个状态图的特性就是并发状态图概念。图2-6中状态D的虚线用于表示状态D实际上引用两个并发状态E和F。图2-6 并发状态 2.2 2.2白盒测试白盒测试 白盒测试是一种可视的测试软件的方法，即它把测试对象看作一个透明的盒子，测试人员要了解程序结构和处理过程，按照程序内部逻辑测试程序，检查程序中的每条通路是否按照预定要求正确工作。白盒测试的过程如图2-7所示：图2-7 白盒测试过程示意图 那么，在对被测软件进行白盒测试时，主要对程序进行哪些方面的检查呢？有如下几点： （）保证一个模块中的所有独立执行路径至少测试一次； （）对所有逻辑判定取值“true”和“false”的两种情况都至少测试

41、一次； （）在循环边界和运行界限内执行循环体； （）测试内部数据结构的有效性。 在软件测试领域，有六种基本的测试类型：单元测试，集成测试，功能测试/系统测试，可接受性测试，回归测试和Beta测试。白盒测试可以用在其中的三种测试类型中： 1、单元测试 2、集成测试 3、回归测试 2.2.12.2.1白盒测试与调试的异同白盒测试与调试的异同 白盒测试和调试有哪些不同点呢？ 1、从承担的任务来看，白盒测试同其他类型测试一样，它的任务是发现所开发的项目中的缺陷；但是，调试不属于测试，其任务是纠正软件中的缺陷。 2、从最终的结果来看，白盒测试有预知的结果，不可预知的只是程序是否通过测试，并且成功测试的结

42、果是发现错误的症状，从而引起调试的进行；而调试的结果是消除项目中的错误。 3、从执行的过程来看，测试是一个发现错误、改正错误、重新测试的过程；而调试是一个推理过程。 4、从准备工作来看，测试从已知的条件开始，使用预先定义的程序；调试一般是以不可知的内部条件开始，做统一性调试 。 5、从执行的计划性来看，测试是有计划的并要进行测试设计；而调试则不受时间约束。 6、从执行的人员来看，测试经常是由独立的测试组在不了解软件设计的条件下完成的，而调试必须由程序员来完成。 7、从所使用的工具来看，大多数白盒测试的执行和设计可有工具支持，而调试程序员能利用的工具主要是调试器。 2.2.2 2.2.2白盒测试

43、的用例设计白盒测试的用例设计 白盒测试用例设计技术就是研究如何用最少的测试用例最大限度地发现软件中的错误，目前主要有基本路径测试、等价类划分/边界值分析测试、覆盖测试、循环测试、数据流测试、程序插桩测试、变异测试等等方法。下面主要对几种常见的方法加以介绍： 一、基本路径测试 二、等价类划分/边界值分析（Equivalence partitioning/boundary value analysis） 三、控制流/覆盖测试（Control-flow/CoverageTesting） 方法覆盖 方法覆盖可用于衡量测试用例所覆盖的方法的百分比。 语句覆盖（Statement Coverage） 语句

44、覆盖是一种衡量测试所覆盖的程序语句百分比的措施。通过测试应该达到100%程序语句覆盖的目标，可以标识圈数，然后执行最少的一组测试用例就可以达到语句覆盖的目标。 判断/分支覆盖 判断/分支覆盖是为了衡量在测试过程中覆盖了多少个程序中的布尔表达式。图2-11 各种循环图 四、循环测试是一种白盒测试技术，注重于循环构造的有效性。n 循环结构测试用例的设计循环可以划分为以下几种模式，如图2-11： 可以使用如下方法设计循环测试用例： 一、简单循环： 二、嵌套循环： 三、串接循环： 四、无结构循环： 五、数据流测试： 六、程序插装： 程序插装（Program Instrumentation）是指在程序中

45、设置断点或打印语句，在执行过程中了解程序的一些动态特性。 七、变异测试 变异测试（Mutation Testing）的提出始于70年代末期，是一种错误驱动测试，即针对某类特定程序错误而进行的测试，也是一种比较成熟的排错性测试方法（排错性测试方法的基本思想是通过检验测试数据集的排错能力来判断软件测试的充分性）。 2.2.32.2.3白盒测试举例（略）白盒测试举例（略） 2.32.3黑盒测试黑盒测试 黑盒测试也称作功能测试和行为测试，主要是根据功能需求来测试程序是否按照预期工作。 黑盒测试的目的是尽量发现代码所表现的外部行为的错误，主要有以下几类： 功能不正确或不完整； 接口错误； 接口所使用的数

46、据结构错误； 行为或性能错误； 初始化和终止错误。 黑盒测试的示意图如图2-14 所示。从图2-14中，我们可以看出黑盒测试只考虑程序的输入和输出，无须考虑程序的内部代码。 图2-14 黑盒测试示意图2.3.12.3.1黑盒测试和白盒测试的异同黑盒测试和白盒测试的异同 本书归纳出以下几点：1.执行测试人员不同 黑盒测试通常由用户以及非开发人员来进行；而白盒测试通常要有了解软件内部结构的开发人员来做。2.测试覆盖目标不同 如果我们用一个盒子来代替整个软件系统，那么黑盒测试可以看成是一种系统测试。而对盒子内部的多个单元的测试就可以称作为白盒测试。 另外一种区别就是，二者的覆盖目标不同。黑盒测试的目

47、标是覆盖所有的用户需求；而白盒测试的目标是覆盖所有的代码。3、测试动机不同 有效的安全测试有时也需要详细了解代码以及系统结构，此时把这些技术称作白盒测试。 另外一种风险测试的目标可能就只是测试软件是否能够为用户提供预期输出。可用性测试就是如此，所以被称作黑盒测试。 4、测试方法不同 一个最普通的区别就是行为测试设计是基于功能需求来定义测试，而结构测试则是基于代码本身来定义测试的。这就是两种设计测试的方法。因为行为测试是基于外部功能定义的，所以称作黑盒测试；结构测试则是基于代码内部结构来定义的，所以称作白盒测试。 5、评估测试方法不同 一些技术是使用代码工具来跟踪软件内部的工作过程，因此称为白盒

48、测试技术。与之相比，黑盒测试技术只是简单的观察程序的正常输出。 2.3.22.3.2黑盒测试的用例设计黑盒测试的用例设计 常用的黑盒测试用例设计方法主要有以下几种：功能图分析方法，等价类划分方法，边界值分析方法，错误推测方法，因果图方法，判定表驱动分析方法，正交实验设计方法和功能图分析方法等。 下面对上述方法分别作以简要介绍。 一、基于用户需求的测试 黑盒测试用例就是基于用户需求的，也是从研究客户需求工作开始的。 二、对等区间划分 对等区间划分是一种黑盒测试方法，该方法也称为等价类划分，是一种设计测试用例的非常形式化的方法。 三、边界值分析法 边界值分析方法是对等价类划分方法的补充。长期的测试

49、工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。 四、状态转换测试 状态转换测试适用于软件被设计成一个状态机或实现了一种被建模成一种状态机的情况。可以设计测试用例测试状态间转换，测试用例创建引起转换的事件。可以设计负面测试的测试用例用于测试状态与事件的非法组合。 五、分支测试 在分支测试中，测试用例用于测试单元的控制流分支或决策点。通常用于实现决策覆盖（Decision Coverage）的测试目标。 六、错误推测法 错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，借助边界值分析等方法有针对性的设计测试用例的方法。 七、因果图方法 因果

50、图方法适合于检查程序输入条件的各种组合情况。使用该方法首先要理解软件所表示的对象及其关系，然后，定义一组保证“所有对象与其他对象都具有所期望的关系”的测试序列。 2.3.3 2.3.3黑盒测试举例（略）黑盒测试举例（略） 2.4 2.4白盒测试和黑盒测试的比较白盒测试和黑盒测试的比较 1、白盒测试只关注软件产品的测试，不能够确保产品已经实现了规格说明中的所有功能。黑盒测试则只关注规格说明中的功能测试，不能够保证已经实现的各个部分都被测试到。 2、与黑盒测试相比，白盒测试的成本要高一些。 3、黑盒测试故意不考虑控制结构，而只注意信息域。白盒测试只考虑测试软件产品，它不保证完整的需求规格是否被满足

51、。黑盒测试是一种确认技术，回答“我们在构造一个正确的系统吗？白盒测试是一种验证技术，回答“我们在正确地构造一个系统吗？” 总之，建议测试人员在进行测试的过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充以保证测试的完整性。 2.4.12.4.1白盒测试的优缺点白盒测试的优缺点 1）优点可构成测试数据对特定程序部分测试，可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；有较多工具支持；有一定的充分性度量手段。 2）缺点工作量大, 成本高。通常只用于单元测试，有应用局限；无法检测代码中遗漏的路径和数据敏感性错误；不能验证规格说明的正确

52、性；无法对规格说明中未实现的部分进行测试；不易生成测试数据(通常)。2.4.22.4.2黑盒测试的优缺点黑盒测试的优缺点1.优点对于较大的代码单元来说，效率高；测试人员不需要了解实现的细节，包括具体的编程语言；测试员和程序员可以由不同的人员来担任；从用户的角度进行测试，容易被理解和接受；有助于暴露任何规格不一致或有歧义的问题；测试用例的设计可以在规格说明完成之后马上进行；容易入手生成测试数据；适用于各阶段测试。2.缺点实际上，只有一小部分可能的输入被测试到，某些代码得不到测试；如果没有清晰、简洁的规格说明，难以设计测试用例；如果测试人员不知道开发人员已经执行过该测试用例，会存在不必要的重复测试

53、；会有很多程序路径没有被测试到；不能直接针对可能隐蔽了许多问题的特定程序段进行测试，；如果规格说明有误，则无法发现；不易进行充分性测试。2.4.32.4.3灰盒测试灰盒测试 灰盒测试介于白盒测试和黑盒测试之间，是现代测试的一种理念。就是指，在白盒测试中交叉使用黑盒测试的方法；在黑盒测试中交叉使用白盒测试的方法。2.52.5测试方法的选择测试方法的选择 一、单元测试 测试方法：白盒测试 参考规范：详细设计说明和代码结构 二、集成测试 测试方法：黑盒和白盒测试 参考规范：详细设计说明和概要设计说明 2.6 2.6测试计划与测试文档测试计划与测试文档 最常见的测试文档包括测试计划，测试规范，测试用例

54、和测试时发现缺陷后要写的缺陷报告等。 那么，测试计划和测试文档在测试过程中能够发挥什么样的作用呢？ 1、测试文档有助于测试任务的完成。 2、使用测试文档可以更好的协调测试任务与测试过程。 3、测试文档为测试项目的组织、规划与管理提供了一个架构。 2.6.1 2.6.1测试计划的制定测试计划的制定为了给读者一个宏观的认识，首先请看测试计划活动图，如图2-20所示。 在制定测试计划过程中，核心活动就是： 一、确定测试策略 通常，可以采用以下几个方法来制定测试策略： 1、确定测试的范围 2、确定测试的方法 3、确定测试标准和质量检查点 4、确定自动化测试策略 二、确定测试系统（硬件和软件） 1、测试

55、架构 测试架构指的就是测试用例的组织结构。 图2-20 测试计划活动 2、测试工具 3、测试环境 测试环境的组成包括物理测试设施，产品运行的操作系统、产品运行的计算平台等。 4、测试配置情况 需要排列配置的优先级，然后决定哪些配置需要全面测试，哪些可以进行部分测试。 三、预估测试工作量（资源和时间进度计划） 对项目进行预估有5个准备步骤： 1、确定要完成的任务。 2、确定每项任务所需的工作量和整个测试生命周期的工作量。 3、确定完成每项任务以及整个测试生命周期所需的时间。 4、为测试工作建立详细的时间进度计划和里程碑表。 5、评估时间进度风险并准备缓解风险计划。 四、准备并复查测试计划文档。

56、1、测试计划格式 2、测试计划复查 2.6.2 2.6.2测试报告测试报告 测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一 份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终测试结果的分析。 2.6.3 2.6.3测试用例的编制测试用例的编制 本节我们首先讨论几个和测试用例相关的几个问题，然后探讨如何编制一个有效的测试用例。 一、为什么做测试用例 主要原因有如下几点：完全测试是不可能的；输入量太大；输出结果太多；软件实现途径太多；软件说明书没有客观标准。从不同角度看，软件缺陷的标准不同。 二、什么是测试用例 比

57、较通常的说法是：为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，称之为测试用例。 三、使用测试用例的好处 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。 功能模块的通用化和复用化使软件易于开发，而 用于功能模块测试的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。 四、测试用例在软件测试中的作用 指导测试的实施 规划测试数据的准备 评估测试结果的度量基准 分析缺陷的标准 编写

58、测试脚本的设计规格说明书 五、测试用例文档的编制 首先，在编写测试用例之前需要准备以下几个编写的依据：需求说明以及相关文档；相关的设计说明（概要设计，详细设计等）；与开发组交流对需求理解的记录（可以是开发人员的一个解释）；已经基本成型的UI（可以有针对性地补充一些用例）。 其次，编写测试用例文档应有文档模板，须符合内部的规范要求。 最后一点就是，测试用例文档应该由简介和测试用例两部分组成。那么，下面从测试用例的设置、设计、评审、修改以及管理等几方面来详细讨论测试用例文档的编制问题： 1、测试用例的设置 2、测试用例的设计 测试用例可以分为基本事件、备选事件和异常事件。软件测试常用的设计测试用例

59、的基本方法有：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用 例，并最终实现暴露隐藏的缺陷，则要凭测试设计人员的丰富经验和精心设计。 3、测试用例的评审 4、测试用例的修改更新 5、测试用例的管理 测试管理软件的主要功能有三个： 能将测试用例文档的关键内容； 可供测试实施时及时输入测试情况； 最终实现自动生成测试结果文档。 本章小结本章小结 在功能性测试中，我们通常使用离散数学，而涉及到结构性测试的领域，我们则会用到关于图论的知识。使用这两方面的知识，有助于我们更精确的描述软件测试，减少对测试过程的误解

60、。 白盒测试与黑盒测试则是软件测试工作中设计测试用例的两个主要的方法。在实际测试过程中，如果黑盒测试是足够充分的，那么白盒测试就没有必要，但是“足够充分”只是一种理想状态，例如：真的是所有功能点都测试了吗？程序的功能点是人为的定义，常常是不全面的； 各个输入数据之间，有些组合可能会产生问题，怎样保证这些组合都经过了测试？难于衡量测试的完整性是黑盒测试的主要缺陷，而白盒测试恰恰具有易于衡量测试完整性的优点，两者之间具有极好的互补性。 白盒测试主要是针对程序的逻辑结构设计测试用例，用逻辑覆盖率来衡量测试的完整性。逻辑单位主要有：语句、分支、条件、条件值、条件值组合、路径。语句覆盖就是覆盖所有的语句

61、，其他类推。 另外还有一种判定条件覆盖，其实是分支覆盖与条件覆盖的组合，在此不作讨论。跟条件有关的覆盖就有三种： 条件覆盖是指覆盖所有的条件表达，即所有的条件表达式都计算了，不考虑计算结果；条件值覆盖是指覆盖条件的所有可能取值，即每个条件的取真值和取假值都要计算一次；条件值组合覆盖是指覆盖所有条件取值的所有可能组合。 效率比较高且完整性也足够的测试要求一般是这样的：完成功能测试，完成语句覆盖、条件覆盖、分支覆盖、路径覆盖。读者可能认为这似乎是不可能的要求，要达到这种测试完整性，其测试成本是不可想象的，但是通过使用一些工具，可以在较低的成本下达到这种测试要求。 精心的测试计划是做好软件测试的关键

62、步骤，因此应该根据需求的变更随时修改测试计划。全面地测试文档，能够为测试工作提供更好的支持，因此在测试的过程中应该给测试计划的制定和测试文档的编写工作以足够的重视。习习 题题1.请列出下列集合的所有元素： （1）大于4并小于28的所有素数的集合； （2）大于38并小于70的所有素数的集合；2.调试会遇到哪些困难？白盒测试与调试有哪些相同点和不同点？3.请阐述白盒测试用例设计的各种方法。4.请阐述黑盒测试用例设计的各种方法。 2.比较白盒测试与黑盒测试各自的优缺点。3.制定测试计划的主要步骤有哪些？如何确定测试范围？ 4.为什么要提交测试报告？5.编写测试用例的依据有哪些？ 第三章第三章 单元测

63、试单元测试 本章要点本章要点 单元测试的定义；单元测试同集成测试和系统测试的区别；单元测试环境的组成；单元测试的分析方法；单元测试的用例设计方法；单元测试的过程；单元测试举例。 本章目标本章目标 u掌握单元测试的概念；u了解单元测试的误区；u了解单元测试与集成测试和系统测试的区别；u掌握单元测试的策略；u掌握单元测试分析的方法；u掌握单元测试用例设计方法。 3.13.1单元测试概述单元测试概述 通常而言，单元测试是在软件开发过程中要进行的最低级别的测试活动，或者说是针对软件设计的最小单位程序模块，进行正确性检验的测试工作。其目的在于发现每个程序模块内部可能存在的差错。 在单元测试活动中，软件的

64、独立单元将在与程序的其他部分相隔离的情况下进行测试，主要工作分为两个步骤：人工静态检查和动态执行跟踪。 单元测试的分工大致如下：一般由开发组在一般由开发组在开发组组长监督下进行，保证使 用合适的测试技术，根据单元测试计划和测试说明文档中制定的要求，执行充分的测试；由编写该单元的开发组中的成员设计所需要的测试用例，测试该单元并修改缺陷。 3.1.1 3.1.1单元测试误区单元测试误区 1、单元测试是一种浪费时间的工作 2、单元测试只能证明代码做了什么 3、我是个很棒的程序员， 我是不是可以不进行单元测试？ 4、集成测试能捕捉到所有的Bug 5、单元测试的成本效率不高 其实，在经过了单元测试之后，

65、系统集成过程将会大大地简化。 3.1.2 3.1.2单元测试与集成测试区别单元测试与集成测试区别 单元测试与集成测试的主要区别在于测试的对象不同。单元测试对象是实现具体功能的单元，一般对应详细设计中所描述的设计单元。集成测试是针对概要设计所包含的模块以及模块组合进行的测试。 单元测试所使用的主要测试方法是基于代码的白盒测试。而集成测试所使用的主要测试方法是基于功能的黑盒测试。 因为集成测试要在所有要集成的模块都通过了单元测试之后才能进行，也就是说在测试时间上，集成测试要晚于单元测试，所以单元测试的好坏直接影响着集成测试。 单元测试的工作内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处

66、理、需求和设计中有具体的要求等方面测试。集成测试的工作内容主要是验证各个接口、接口之间的数据传递关系、模块组合后能否达到预期效果。 虽然单元测试和集成测试有一些区别，但是二者之间也有着千丝万缕的联系。目前集成测试和单元测试的界限趋向模糊。3.1.33.1.3单元测试与系统测试区别单元测试与系统测试区别 单元测试与系统测试的区别不仅仅在于测试的对象和测试的层次的不同，最重要的区别是测试性质不同。在单元测试过程中，单元测试的执行早于系统测试，测试的是软件单元的具体实现、内部逻辑结构以及数据流向等。系统测试属于后期测试，主要是根据需求规格说明书进行的，是从用户角度来进行的功能测试和性能测试等等，证明

67、系统是否满足用户的需求。 单元测试中发现的错误容易进行定位，并且多个单元测试可以并行进行；而系统测试发现的错误比较难定位。 3.2 3.2单元测试环境单元测试环境 由于一个模块或一个方法（Method）并不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，因此要用到一些辅助模块，来模拟与所测模块相联系的其他模块。一般把这些辅助模块分为两种： 1、驱动模块（driver）:相当于所测模块的主程序。 2、桩模块（stub）:用于代替所测模块调用的子模块。 那么，所测模块和与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如图3-2所示。图3-2 单元测试环境3.33.3单元测试策略单元

68、测试策略 单元测试涉及到的测试技术通常有：针对被测单元需求的功能测试、用于代码评审和代码走读的静态测试、白盒测试、状态转换测试和非功能测试。 为了提高单元测试的质量，只了解这些单元测试技术还远远不够，还要选择合适的测试策略。在选择测试策略时，主要考虑如下3种方式：自顶向下（Top Down Unit Testing）的单元测试策略、自底向上的单元测试策略（Bottom up Unit Testing）和孤立的单元测试策略。 3.3.1 3.3.1自顶向下的单元测试策略自顶向下的单元测试策略 一）步骤： 1. 从最顶层开始，把顶层调用的单元做成桩模块。 2. 对第二层测试，使用上面已测试的单元做

69、驱动模块。 3. 依次类推，直到全部单元测试结束。 二）优点：可以在集成测试之前为系统提供早期的集成途径。 三）缺点：单元测试被桩模块控制，随着单元测试的不断进行，测试过程也会变得越来越复杂，测试难度以及开发和维护的成本都不断增加； 要求的低层次的结构覆盖率也难以得到保证；由于需求变更或其他原因而必须更改任何一个单元时，就必须重新测试该单元下层调用的所有单元；低层单元测试依赖顶层测试，无法进行并行测试，使测试进度受到不同程度的影响，延长测试周期。 四）总结：从上述分析中，不难看出该测试策略的成本要高于孤立的单元测试成本，因此从测试成本方面来考虑，并不是最佳的单元测试策略。 3.3.23.3.2

70、自底向上的单元测试自底向上的单元测试 一）步骤： 1、先对模块调用图上的最底层模块开始测试，模拟调用该模块的模块为驱动模块。 2、其次，对上一层模块进行单元测试，用已经被测试过的模块做桩模块。 3、依次类推，直到全部单元测试结束。 二）优点：不需要单独设计桩模块。 三）缺点：随着单元测试的不断进行，测试过程会变得越来越复杂，测试周期延长，测试和维护的成本增加；随着各个基本单元逐步加入，系统会变得异常庞大，因此测试人员不容易控制；越接近顶层的模块的测试其结构覆盖率就越难以保证； 另外，顶层测试易受底层模块变更的影响，任何一个模块修改之后，直接或间接调用该模块的所有单元都要重新测试。 由于只有在底

71、层单元测试完毕之后才能够进行顶层单元的测试，所以并行性不好。另外，自底向上的单元测试也不能和详细设计、编码同步进行。 四）总结：相对其它测试策略而言，该测试策略比较合理,尤其是需要考虑对象或复用时。它属于面向功能的测试，而非面向结构的测试。对那些以高覆盖率为目标或者软件开发时间紧张的软件项目来说，这种测试方法不适用。 3.3.3 3.3.3孤立测试孤立测试 一）步骤：无需考虑每个模块与其他模块之间的关系，分别为每个模块单独设计桩模块和驱动模块，逐一完成所有单元模块的测试。 二）优点：该方法简单、容易操作，因此所需测试时间短，能够达到高覆盖率。 三）缺点：不能为集成测试提供早期的集成途径。依赖结

72、构设计信息，需要设计多个桩模块和驱动模块，增加了额外的测试成本。 四）总结：该方法是比较理想的单元测试方法。如辅助适当的集成测试策略，有利于缩短项目的开发时间。 3.3.4 3.3.4综合测试综合测试 在单元测试中，为了有效地减少开发桩模块的工作量，可以考虑综合自底向上测试策略和孤立测试策略。 3.4 3.4单元测试分析单元测试分析 一般可以从如下几个方面进行分析和测试，即： 1、判断得到的结果是否正确？ 因为，对于测试而言，首要的任务就是察看一下所期望的结果是否正确，即对结果进行验证。 2、判断是否满足所有的边界条件？ 边界条件是指软件计划的操作界限所在的边缘条件。边界条件测试是单元测试中最

73、后也是最重要的一项任务。在使用边界值测试的方法时，不妨结合实际项目参考以下测试技巧：输入了完全伪造或者和要求不一致的数据。 1）输入一个格式错误的数据。 2）提供一个空值或者不完整的值。 3）与意料之中的值相差很远的值。 4）假如一个列表中不允许有重复的数值存在，就可以给它传入一组存在重复数值的列表；如果某个字段的值要求唯一，那么可以输入两个或多个相同的数值来进行测试。 5）假如一个列表中不允许有重复的数值存在，就可以给它传入一组存在重复数值的列表；如果某个字段的值 要求唯一，那么可以输入两个或多个相同的数值来进行测试。 6） 如果要求按照一定的顺序来存储一些数据，那么可以输入一些顺序打乱的数

74、据来做测试。 7）对于一些做了安全限制的部分，尽量通过各种途径尝试能否绕过安全限制的测试。 8） 如果功能的启用有一定的顺序限制，就用和期望不一致的顺序来进行测试。 3、分析能否使用反向关联检查？ 在实际程序中，有一些方法可以使用反向的逻辑关系来验证它们。 4、分析是否能使用其他手段来交叉检查一下结果？ 一般而言，对某个值进行计算会有一种以上的算法，但我们会因考虑到运行效率或其他方面的原因而选择其中的一种。 5、分析是否可以强制一些错误发生？ 在实际使用过程当中，总会有意想不到各种各样的情况和错误发生。 6、分析模块接口 数据在接口处出错就好像丢掉了进入大门的钥匙，无法进行下一步的工作，只有在

75、数据能正确流入、流出模块的前提下，其他测试才有意义。 7、分析局部数据结构 局部数据结构往往是错误的根源，对其检查主要是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，因此应仔细设计测试用例。 8、 分析独立路径 在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。 9、 分析出错处理是否正确 一个好的设计应能预见各种出错条件，并进行适当的出错处理，即预设各种出错处理通路。 3.53.5单元测试用例设计单元测试用例设计 单元测试用例的设计既可以使用白盒测试也可以使用黑盒测试，但以白盒测试为主。 白盒测试进入的前提条件是测试人员已经对被测试对象有

76、了一定的了解，基本上明确了被测试软件的逻辑结构。 黑盒测试是要首先了解软件产品具备的功能和性能等需求，再根据需求设计一批测试用例以验证程序内部活动是否符合设计要求的活动。 测试人员在实际工作中至少应该设计能够覆盖如下需求的基于功能的单元测试用例： 测试程序单元的功能是否实现； 测试程序单元性能是否满足要求（可选）； 是否有可选的其它测试特性，如边界、余量、安全性、可靠性、强度测试、人机交互界面测试等。 无论是白盒测试还是黑盒测试，每个测试用例都应该包含下面4 个关键元素： (1) 被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用中间状态的情况)； (2) 被测单元的输

77、入，包含由被测单元读入的任何外部数据值； (3) 该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如：单元中哪一个决策条件被测试； (4) 测试用例的期望输出结果（在测试进行之前的测试说明中定义）。 一、测试用例设计步骤 以下描述进行测试用例设计的6步通用过程。 步骤1：首先使被测单元运行； 这个阶段适合的技术有： 模块设计说明导出的测试 对等区间划分 步骤2：正面测试(Positive Testing) 这个阶段适合的技术： 设计说明导出的测试 对等区间划分 状态转换测试 步骤3：负面测试(Negative Testing) 适合的技术有： 错误猜测 边界值分析

78、内部边界值测试 状态转换测试 步骤4: 模块设计需求中其它测试特性用例设计 适合的技术：设计说明导出的测试 步骤5：覆盖率测试用例设计 适合的技术： 分支测试 条件测试 数据定义使用测试 状态转换测试 步骤6：测试执行 步骤7：完善代码覆盖 适合的技术： 分支测试 条件测试 设计定义试验测试 状态转换测试 二、面向对象应用程序的单元测试用例设计 类测试一般也采用传统的两种测试方式：功能性测试和结构性测试，即黑盒测试和白盒测试。 1、 功能性测试 功能性测试包括两个层次： 类的规格说明和方法的规格说明。 2、 结构性测试 结构性测试对类中的方法进行测试，它把类作为一个单元来进行测试。测试分为两层

79、：第一层考虑类中各独立方法的代码；第二层考虑方法之间的相互作用，每个方法的测试要求能针对其所有的输入情况。 (1) 方法的单独测试： (2) 方法的综合测试： 3、基于对象状态转移图的面向对象软件测试 面向对象设计方法通常采用状态转移图建立对象的动态行为模型。状态转移图用于刻画对象 响应各种事件时状态发生转移的情况，结点表示对象的某个可能状态，结点之间的有向边通常用“事件动作”标出。 如图3-3的示例中，表示当对象处于状态A 时，若接收到事件e 则执行相应的操作a且转移到状态B。因此，对象的状态随各种外来事件发生怎样的变化，是考察对象行为的一个重要方面。图3-3 对象-状态转换图 下面给出基于

80、状态测试的主要步骤： 依据设计文档，或者通过分析对象数据成员的取值情况空间，得到被测试类的状态转移图； 给被测试的类加入用于设置和检查对象状态的新方法,导出对象的逻辑状态； 对于状态转移图中的每个状态，确定该状态是哪些方法的合法起始状态，即在该状态时，对象允许执行哪些操作； 在每个状态，从类中方法的调用关系图最下层开始，逐一测试类中的方法； 测试每个方法时，根据对象当前状态确定出对方法的执行路径有特殊影响的参数值，将各种可能组合作为参数进行测试。 4、类的数据流测试 数据流测试是一种白盒测试方法，它利用程序的数据流之间的关系来指导测试的选择。 数据流分析 当数据流测试用于单个过程的单元测试时，

81、定义-引用对可利用传统的迭代的数据流分析方法来计算，这种方法利用一个控制流图(control flow graph)来表示程序，其中的节点表示程序语句，边表示不同语句的控制流，且每一个控制流图都加上了一个入口和一个出口。 类及类测试 类是个独立的程序单位，它应该有一个类名并包括属性说明和服务说明两个主要部分，对象是类的一个实例。不失一般性，我们这里构造一个类的模型。 我们对类进行三级测试，定义如下： A. 方法内部测试：测试单个方法，这级测试相当 于单元测试； B.方法间测试：在类中与其它方法一起测试一个 直接或间接调用的公开方法，这级测试相当于 集成测试； C.类内部测试：测试公开方法在各种

82、调用顺序时的 相互作用关系，由于类的调用能够激发一系列不 同顺序的方法，我们可以用类内部测试来确定类 的相互作用关系顺序，但由于公开方法的调用顺 序是无限的，我们只能测试其中一个子集。 数据流测试 为了支持现有的类内部测试（Intra-class testing）技术，我们需要一个基于代码的测试技术来识别需要测试的类的部件，这种技术就是数据流测试，它考虑所有的类变量及程序点说明的定义-引用对（defuse pairs）。 计算类的数据流信息 为了支持类的数据流测试，我们必须计算类的各种定义-引用对。 为了计算类的三种定义-引用对，我们可以构造一个类控制流图(class control flow

83、 graphCCFG)，其算法如下： 为类构造类调用图，作为类控制流图的初值； 把框架(frame)加入到类调用图中； 根据相应的控制流图替换类调用图中的每一 个调用节点，具体实现方法：对于类C 中的每一 个方法M，在类调用图中用方法M 的控制流图 替代方法M 的调用结点，并更新相应的边； 用调用节点和返回节点替换调用点，具体实现方法：对于类调用图中的每一个表示类C 中调用方法M 的调用点S，用一个调用节点和返回节点代替调用点S； 把单个的控制流图连接起来，具体实现方法：对于类控制流图中的每一个方法M，加上一条从框架调用节点到输入节点的边和一条从输出节点到框架返回节点的边，其中输入节点和输出节

84、点都在方法M 的控制流图中； 返回完整的类控制流图。 3.63.6单元测试过程单元测试过程 图3-7从宏观的角度概括了单元测试的工作过程图。 一、单元测试进入和退出准则 如表3-1和表3-2所示：表3-1 进入准则要素判断准则详细设计说明书单元测试用例经过审查获得批准进入配置库 要素判断准则源代码文件源代码文件清单源代码文件获得批准源代码文件进入配置库的 源代码区测试用例源代码通过同级评审软件Bug 清单单元测试报告提交测试负责人提交软件产品配置管理表3-2 退出准则二、单元测试过程图3-7 单元测试工作过程（1）准备阶段（2）编制阶段（3）代码审查阶段（4）单元测试阶段（5）评审、提交阶段

85、3.73.7单元测试举例单元测试举例 一、单元测试计划一、单元测试计划 1. 简介 这份文档的目标是详细描述对两票系统的可以实现在二次系统图上进行图形开票模块的功能验证的测试过程。 2. 本测试的总目标： 是否实现了需求文档中定义的所有功能。 3. 完整性需求 在测试该模块是否实现了需求文档中定义的所有功能之前，应该做如下两项工作： 测试数据初始化是否无误； 测试二次图开票GUI界面是否与系统维护模块显示一致。 4. 单元测试终止标准 硬件资源不足或故障造成软件无法运行 软件运行后无法正确显示（如：因数据初始化有误造成GUI界面同系统维护模块显示不一致或不正确等）； 所有功能测试均已经完成 5

86、. 资源需求 软件资源 操作系统：windows 2000 web服务器：Tomcat 5.0 数据库服务器：SQL Server 2000 浏览器：Microsoft IE 6.0 测试工具：Junit 硬件资源 同开发用pc机配置相同即可。 测试进度任务开始日期结束日期配置并调试测试环境10/0110/03GUI界面测试10/0410/06所有功能测试10/0710/10表3-3 二次系统图图形开票模块 6. 准备测试的特征 以下特征将被测试，以确保该模块能满足需求规格说明书中指定的需求： 需求2.2.1 用户界面 需求2.2.2 弹出菜单 需求2.2.3图形开票 7. 不准备测试的特征

87、本次测试将不考虑是否能够同一次系统图图形开票模块的集成。 8. 测试方法 该单元测试方法包括功能测试、GUI测试。 9. 通过/失败标准 10. 测试结束后须提交的产物包括以下几个文档： 本测试计划 测试规格说明文档 测试结果报告 向测试经理和开发经理提交的每日测试状态报告 缺陷报告 11、测试执行人员 12、风险和应急计划 二、测试的设计和开发 测试设计和开发要以测试计划作为输入。在设计测试时，首先应明确测试目标（细化测试的方法和范围）；确定每个测试的输入规格说明；确定每个测试使用的测试配置；复查测试设计的覆盖率和测试的准确度。 在对本单元进行测试时所采用的方法是：先完成黑盒测试，然后统计白

88、盒覆盖率，针对未覆盖的逻辑单位设计测试用例覆盖它。 然后，就应该开发测试用例，应该注意的是在测试用例中应该尽可能详细地描述测试过程，对于耗时的测试进行自动化。 最后，验证和调试测试。 3.83.8单元测试经验总结单元测试经验总结 测试人员在进行测试的工作过程中，应该注意积累测试工作经验，这样可以缩短单元测试的时间，提高测试效果和效率。如： 1、在做单元测试的过程中，要灵活选用测试用例设计技术，如本章中的两票系统单元测试过程中，首先使用黑盒测试用例设计技术，然后根据相应的覆盖率统计再补充白盒测试用例。既减少了测试工作的重复，又保证了单元测试的完整性。 2、应该尽量开发简单测试驱动代码，增强其可读

89、性。最重要的是，单元测试代码中不能包含分支和逻辑语句，因为这意味着有多个测试在同时进行。这样将会使测试代码变得难以理解和维护。 本章小结本章小结 通过单元测试，我们验证开发人员所书写的编码是可以按照其所设想的方式执行的，产出了符合预期值的结果。这就实现了单元测试的目的。相比后面阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。 从全程的费用来考虑， 相比起那些复杂且旷日持久的集成测试，或是不稳定的软件系统来说，单元测试所需的费用是很低的。 模块单元设计完毕之后的开发阶段就是单元测试。 值得注意的是，如果在书写代码之前就进行单元测试，测试设计就会显得更加灵活，因为一旦代码完

90、成，对软件的测试可能就受制于代码，倾向于测试该段代码完成什么功能，而不是真正的测试，我们需要的做的应该是测试这段代码应该做什么。因此，应该把单元测试的设计放在详细设计阶段。习习 题题1.什么是单元测试？2.测试用例设计的步骤有哪些？3.单元测试的策略有哪些？每种测试策略具有哪些优点和缺点？4.单元测试与集成测试、系统测试各有哪些区别？5.针对你所熟悉的一个简单的小程序，根据其特点考虑一下如何对其进行单元测试。并试着使用基本的黑盒或白盒测试技术设计一些测试用例和测试数据?第四章第四章 集集 成成 测测 试试 本章要点本章要点 集成测试的定义；集成测试与系统测试的区别；集成测试与开发之间的关系；集

91、成测试的分析方法；集成测试策略的选择；集成测试环境的搭建；集成测试用例设计的方法。 本章目标本章目标 u了解集成测试与系统测试的区别；u了解集成测试与开发过程之间的关系；u了解集成测试的层次和集成测试的重点；u理解集成测试的概念和集成测试的过程；u掌握集成测试的分析方法及集成测试的策略。u掌握集成测试用例设计的方法。 4.14.1集成测试概述集成测试概述 一般这样定义集成测试：根据实际情况对程序模块采用适当的的集成测试策略组装起来，对系统的接口以及集成后的功能进行正确性检验的测试工作。 4.1.1 4.1.1集成测试与系统测试的区别集成测试与系统测试的区别 1、测试对象 集成测试的测试对象是由

92、通过了单元测试的各个模块所集成起来的组件。而系统测试的测试对象，除了软件之外，还有计算机硬件及相关的外围设备、数据采集和传输机构、计算机系统操作人员等的整个系统。 2、 测试时间 集成测试是介于单元测试和系统测试之间的测试. 在测试时间上，先于系统测试。 3、测试方法 集成测试通常会采用灰盒测试。而系统测试通常使用黑盒测试。 4、测试内容 集成测试的主要内容就是各个单元模块之间的接口，以及各个模块集成后所实现的功能。而系统测试的主要内容就是整个系统的功能和性能。 5、测试目的 集成测试的主要目的就是发现单元之间接口的错误，以及发现集成后的软件同软件概要设计说明不一致的地方。而系统测试的主要目的

93、就是，通过与系统需求定义相比较之后发现软件与系统定义不符合或矛盾的地方。 6、测试角度 集成测试工作的开展更多的是站在测试工作人员的角度上。系统测试工作的开展更多的是站在用户的角度来进行。 4-1 软件结构图 4.1.2 4.1.2集成测试与开发的关系集成测试与开发的关系 为了使读者更好的了解集成测试与开发的关系，图4-1给出了软件基本结构图。 4.1.3 4.1.3集成测试的重点集成测试的重点 1、各个模块连接起来后，穿过模块接口的数据是否会丢失，是否能够按期望值传递给另外一个模块； 2、各个模块连接起来后，需要判断是否仍然存在单元测试时所没发现的资源竞争问题； 3、分别通过单元测试的子功能

94、模块集成到一起能否实现所期望的父功能； 4、兼容性，检查引入一个模块后，是否对其他与之相关的模块产生负面影响； 5、全局数据结构是否正确，是否被不正常的修改； 6、集成后，每个模块的误差是否会累计扩大，是否会达到了不可接受的程度； 4.1.4 4.1.4集成测试的层次集成测试的层次对于传统软件来说，按集成粒度不同，可以把集成测试分为3个层次，即：- 模块内集成测试- 子系统内集成测试- 子系统间集成测试对于面向对象应用系统来说，按集成粒度不同，可以把集成测试分为2个层次：- 类内集成测试- 类间集成测试4.24.2如何进行集成测试如何进行集成测试4.2.14.2.1集成测试分析集成测试分析 一

95、、体系结构分析 首先，跟踪需求分析，对要实现的系统划分出结构层次图。 其次，是对系统各个组件之间的依赖关系进行分析，然后据此确定集成测试的粒度，即集成模块的大小。二、模块分析 一般，可从以下几个角度进行模块分析： 1）确定本次要测试的模块；2） 找出与该模块相关的所有模块，并且按优先级对这 些模块进行排列；3）从优先级别最高的相关模块开始，把被测模 块与其集成到一起；4）然后依次集成其他模块。三、接口分析 接口的划分要以概要设计为基础，一般通过以下几个步骤来完成： (1)确定系统的边界、子系统的边界和模块的边界。 (2)确定模块内部的接口。 (3)确定子系统内模块间接口。 (4)确定子系统间接

96、口。 (5)确定系统与操作系统的接口。 (6)确定系统与硬件的接口。 (7)确定系统与第三方软件的接口。四、风险分析 风险通常被分为3种类型： 项目风险：包括项目管理和项目环境的风险。 商业风险：它和领域的相关概念及规则息息相关。 技术风险：这是针对应用程序的具体实现而言的，主要和代码级的测试有关。 风险分析是一个定义风险并且找出阻止潜在的问题变成现实的方法的过程。 通常把风险分析分为3个阶段：风险识别、风险评估和风险处理。 五、可测试性分析 必须尽可能早地分析接口的可测试性，提前为后续的测试工作做好准备。 六、集成测试策略分析 集成测试策略分析的主要任务就是根据被测对象选择合适的集成测试策略

97、。4.2.24.2.2集成测试策略集成测试策略 一、基于分解的集成一、基于分解的集成 大爆炸集成大爆炸集成 1. 1. 目的目的 尽可能缩短测试时间，使用最少的测试用例验证系统。 2. 2. 定义定义 大爆炸集成也称为一次性组装或整体拼装，这种集成测试策略的做法就是把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。 3. 3. 具体方法具体方法 举例来说，假设要对某个系统的部分功能（包括4个模块）进行测试，其功能分解如图4-3所示。具体测试过程如下： 对模块A进行测试 对模块B进行测试 对模块C和模块D进行测试 把通过单元测试的所有模块组装到一起进行

98、集成测试。以上测试过程如图4-4所示：图4-3 程序结构图 4. 4. 优点优点 （1）可以并行调试所有模块。 （2）需要的测试用例数目少。 （3）测试方法简单、易行。 图4-4 大爆炸法示例图 5. 5. 缺点缺点 （1）不能充分对各个模块之间的接口进行充分测试。 （2）不能很好的对全局数据结构进行测试。 （3）如果一次集成的模块数量多，集成测试后可能会出现大量的错误。另外，修改了一处错误之后，很可能新增更多的新错误，新旧错误混杂，给程序的完善带来很大的麻烦。 （4）使集成测试通过，也会遗漏很多错误。 6. 6. 适用范围适用范围 （1）只需要修改或增加少数几个模块的前期产品稳定的项目； （

99、2）功能少，模块数量不多，程序逻辑简单，并且每个组件都已经过充分单元测试的小型项目； （3）基于严格的净室软件工程（由IBM公司开创的开发零缺陷或接近零缺陷的软件的成功做法）开发的产品，并且在每个开发阶段，产品质量和单元测试质量都相当高的产品。 自顶向下集成自顶向下集成 1. 1. 目的目的 从顶层控制（主控模块）开始，采用同设计顺序一样的思路对被测系统进行测试，来验证系统的稳定性。 2. 2. 定义定义 自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。 3. 3. 方法方法 集成测试的过程如下： 把主控模块作

100、为测试驱动，所有与主控模块直接相连的模块作为桩模块； 根据集成的方式（深度优先或者广度优先），逐渐使用实际模块替换相应的下层桩模块；再用桩代替他们的直接下属模块，与已通过测试的模块或子系统组装成新的子系统。 在每个模块被集成时，都必须已经通过了单元测试； 进行回归测试（重新执行以前做过的全部或部分测试），以确定集成新模块后没有引入错误； 从上述过程中的第二步开始重复执行，直到所有模块都已经集成到系统中为止。 4. 4. 优点优点 在测试的过程中，可以较早地验证主要的控制和判断点。 选择深度优先组合方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错

101、误和缺陷， 验证其功能的正确性，为此后主要分支的组装和测试提供保证；能够较早的验证功能可行性，给开发者和用户带来成功的信心； 只有在个别情况下，才需要驱动程序（最多不超过一个），减少了测试驱动程序开发和维护的费用， 可以和开发设计工作一起并行执行集成测试，能够灵活的适应目标环境； 容易进行故障隔离和错误定位。 5. 5. 缺点缺点 在测试时需要为每个模块的下层模块提供桩模块，桩模块的开发和维护费用大； 底层组件的需求变更可能会影响到全局组件，需要修改整个系统的多个上层模块。 要求控制模块具有比较高的可测试性； 可能会导致底层模块特别是被重用的模块测试不够充分。 6. 6. 适用范围适用范围 控

102、制结构比较清晰和稳定的应用程序； 系统高层的模块接口变化的可能性比较小； 产品的低层模块接口还未定义或可能会经常因需求变更等原因被修改； 产品中的控制模块技术风险较大，需要尽可能提前验证； 需要尽早看到产品的系统功能行为； 在极限编程（Extreme Programming）中使用测试优先的开发方法。自底向上集成自底向上集成1.1.目的目的 从依赖性最小的底层模块开始，按照层次结构图，逐层向上集成，验证系统的稳定性。2.2.定义定义 自底向上集成是从系统层次结构图的最底层模块开始进行组装和集成测试的方式。 3. 3.方法方法 从最底层的模块开始组装，组合成一个能够完成制定的软件子功能的构件；

103、编制驱动程序，协调测试用例的输入与输出； 测试集成后的构件； 使用实际模块代替驱动程序，按程序结构向上组装测试后的构件； 重复上面的第二步，直到系统的最顶层模块被加入到系统中为止。 4 4优点优点 即使数据流并未构成有向的非环状图，生成测试数据也没有困难。 可以尽早的验证底层模块的行为。 提高了测试效率； 对实际被测模块的可测试性要求要少； 减少了桩模块的工作量; 容易对错误进行定位。 5 5缺点缺点 直到最后一个模块加进去之后才能看到整个系统的框架； 只有到测试过程的后期才能发现时序问题和资源竞争问题； 驱动模块的设计工作量大; 不能被及时发现高层模块设计上的错误。 6 6适用范围适用范围

104、底层模块接口比较稳定的产品； 高层模块接口变更比较频繁的产品； 底层模块开发和单元测试工作完成较早的产品。二、三明治集成二、三明治集成1.1.目的目的: : 综合利用自顶向下和自底向上两中集成测试策略的优点。2.2.定义定义: : 三明治集成是一种混合增殖式测试策略，综合了自顶向下和自底向上两种集成方法的优点，因此也属于基于功能分解集成。 3 3、方法、方法 首先，确定以哪一层为界来决定使用三明治集成策略（在4-7中，我们确定以B模块为界）； 其次，对模块B及其所在层下面的各层使用自底向上的集成策略；图4-7 三明治集成策略示意图 再次，对模块B所在层上面的层次使用自顶向下的集成策略； 然后，

105、把模块B所在层各模块同相应的下层集成； 最后，对系统进行整体测试。 4 4优点优点 除了具有自顶向下和自底向上两种集成策略的优点之外，运用一定的技巧，能够减少了桩模块和驱动模块的开发。 5 5缺点缺点 在被集成之前，中间层不能尽早得到充分的测试。 6 6适用范围适用范围 多数软件开发项目都可以应用此集成测试策略。 三、修改过的三明治集成三、修改过的三明治集成1.1.目的目的 充分发挥测试的并行性，弥补三明治集成中不能充分测试中间层的缺点。 2. 2. 定义定义(略) 3. 3. 方法方法 并行测试目标层，目标层上面一层，目标层下面一层。 并行测试目标层与目标层上面一层的集成和目标层与目标层下面

106、一层的集成。 4. 4.优点优点 具有三明治集成的所有优点，且对中间层能够尽早进行比较充分的测试； 该策略的并行度相对比较高。 5. 5.缺点缺点 中间层如果选择不适当，可能会增加驱动模块和桩模块工作量的设计负担。 6.6.适用范围适用范围 大多数软件开发项目。 四、基于调用图的集成四、基于调用图的集成 基于调用图的集成方式有两种，即：成对集 成和相邻集成。 1、成对集成 成对集成的思想就是免除桩/驱动器开发工作，使用实际代码来代替桩/驱动器。成对集成的方法就是对应调用图的每一个边建立并执行一个集成测试会话。 2、相邻集成 这里的相邻是针对节点而言的，节点的邻居就是由给定节点引出的节点集合。在

107、有向图中，节点邻居包括所有直接前驱节点和所有直接后继节点。 五、基于路径的集成五、基于路径的集成 首先，我们来看一下与基于路径的集成相关的几个概念： 1. 源节点 程序中的源节点是指程序执行开始或重新开始处的语句片断。 2汇节点 汇节点是程序执行结束处的语句片断。这里转移控制到其它单元的节点也是汇节点。 3模块执行路径 模块执行路径是以源节点开始、以汇节点结束的一系列语句，中间没有插入汇节点。 在图4-12中有七条模块执行路径： MEP（A，1）=1，2，3，6 MEP（A，2）=1，2，4 MEP（A，3）=5，6 MEP（B，1）=1，2 MEP（B，2）=3，4 MEP（C，1）=1，2

108、，4，5 MEP（C，1）=1，3，4，5 4. 消息 消息是一种程序设计语言机制，通过这种机制可以把控制从一个单元转移到另一个单元。 5、MM-路径是穿插出现模块执行路径和消息的序列。如图4-12中的粗线所示，代表模块A调用模块B，模块B调用模块C，这就是一个MM-路径，可用图4-13表示。对于传统软件来说，MM-路径永远是从主程序开始，在主程序中结束。 图4-12 跨三个单元的MM-路径图4-13 从图4-12中导出的MM-路径图六、分层集成六、分层集成1.1.目的目的 通过增量式集成的方法验证一个具有层次体系结构的应用系统的稳定性和可互操作性。2.2.介绍介绍 分层集成就是针对通信系统中

109、的分层模型使用的一种集成策略。3策略策略 分层集成的具体步骤如下： 划分系统的层次； 确定每个层次内部的集成策略。 确定层次间的集成策略。 4.4.优点优点 其优点与其使用的层间集成测试策略类似。5.5.缺点缺点 其缺点与其使用的层间集成测试策略类似。6.6.适用范围适用范围 有明显线性层次关系的产品系统。七、基于功能的集成七、基于功能的集成1.1.目的目的 采用增值的方法，尽早地验证系统关键功能。2.2.介绍介绍 从功能实现的角度出发，按照模块的功能重要程度组织模块的集成顺序。3策略策略 基于功能的集成策略具体如下：确定功能的优先级别；分析优先级最高的功能路径，把该路径上的所有模块集成到一起

110、，必要时使用驱动模块和桩模块；增加一个关键功能，继续步骤2，直到所有模块都被集成到被测系统中。4 4优点优点 直接验证系统中主要功能，最早地确认所开发的系统中关键功能得以实现； 测试过程比三明治策略所用时间短； 验证接口的正确性时，为覆盖接口使用的实例相对要少； 可以减少驱动模块的开发，只要设计和维护一个顶层模块的驱动器。5 5缺点缺点 不适用复杂系统； 对于部分接口测试不充分，容易漏掉大量接口错误； 集成测试开始的时候需要大量的桩模块的设计； 容易出现相对大的冗余测试。 6 6适用范围适用范围 主要功能具有较大风险性的产品； 探索型技术研发项目； 注重功能实现的项目； 对于所实现的功能信心不

111、强的产品。 八、高频集成八、高频集成1.1.目的目的 频繁地向一个已经稳定的基线中添加新的代码，避免遗留集成故障，同时控制可能出现的基线(Baseline)偏差。2.2.介绍介绍 使用高频集成需要具备的条件如下：可以获得一个稳定的增量，并且已经完成的某子系统已经通过测试证明不存在错误；大部分有意义的功能增加可以在一个恰当的频率间隔内获得；测试包和代码并行开发，保证维护的是最新的版本；使用自动化，例如采用GUI的捕获/回放工具；使用配置管理工具，实际上是对版本的增量或变更进行维护。3.3.策略策略 高频集成有3个主要的步骤，具体如下：开发人员完成要提供的代码的增量部分，同时测试人员完成相关的测试

112、包。集成测试人员将开发人员修改或增加的组件集中起来形成一个新的集成体，并且在上面运行集成后的测试包。评价结果。 4. 4.优点优点 高效性。 可预测性。 并行性。 对桩代码的需要不是必须的，这可以避免编写和维护容易损坏的测试代码； 尽早查出错误。 容易进行错误定位。 5 5 缺点缺点 测试包可能会过于简单，不容易发现有价值的问题； 初始阶段不能平稳地进行集成； 如果没有适当的标准做保证，成功的集成可能导致不应有的可信度，增加系统的风险性。 6. 6.适用范围适用范围 应用迭代（或增量）过程模型开发的产品。九、基于进度的集成九、基于进度的集成1.1.目的目的 尽可能早地进行集成测试，提高开发与集

113、成的并行性，有效地缩短进度。2.2.介绍介绍 基于进度的集成就是在兼顾进度和质量两者之间寻找了一个均衡点。3策略（略）策略（略）4.4.优点优点 具有比较高的并行度； 能够有效缩短项目开发的进度。 5.5.缺点缺点 可能最早拿到的模块之间缺乏整体性，只能进行独立的集成，导致许多接口必须等到后期才能验证，但此时系统可能已经很复杂，往往无法发现有效的接口问题； 桩模块和驱动模块的工作量可能会变得很庞大； 由于进度的原因，模块可能很不稳定且会不断变动，导致测试的重复和浪费。6.6.适用范围适用范围 进度优先级高于质量的项目。 十、基于风险的集成十、基于风险的集成1.1.目的目的 尽可能提早验证高危模

114、块间的接口，从而保证系统的稳定性。2.2.介绍介绍 在软件系统中，风险最高的模块间的集成往往是错误集中的地方，因此尽早地验证这些接口有助于系统的稳定，从而增强对系统信心。3策略（略）策略（略）4.4.优点优点 可以对最具有风险的模块提前进行验证，有利于系统的快速稳定开发。5.5.缺点缺点 需要花费额外的测试成本，对各组件的风险进行详细的分析。6.6.适用范围适用范围 在应用软件项目中，有一些模块具有较大的风险。十一、基于事件的集成十一、基于事件的集成1.1.目的目的 基于事件的集成，又称基于消息的集成。该方法是从验证消息路径的正确性出发，渐增式地把系统集成到一起，从而验证系统的稳定性。2.2.

115、介绍介绍 验证消息路径的正确性对于嵌入式系统和面向对象系统具有比较重要的作用，基于消息/事件/线程的集成就是针对这种特点而设计的一种策略。3.3.策略策略从系统的外部分析，判断系统可能输入的消息集；选取一条消息，分析其穿越的模块；集成这些模块进行消息接口测试；选取下一条消息，重复步骤2和3，直到所有模块都被集成到系统中；我们在选择消息的时候可以从不同角度出发，具体如下： a、消息的重要性：尽早验证重要的消息路径；b、消息路径的长度：为了能有效验证消息接口的完整性和正确性，尽可能选取路径较短的消息； c、新的消息的选择是否能够使得新的模块被加入到系统中。 4. 4. 优点优点 a) 直观性强，直

116、接验证系统中关键功能； b)相对耗时少，因此测试过程比三明治策略所用时间少。 c)验证接口的正确性时，为覆盖接口使用的实例相对要少；d)避免大量设计驱动模块，只要设计和维护一个顶层模块的驱动器。5.5.缺点缺点不适用功能之间的相互关联性强、不易于分析主要模块的系统；部分接口测试不完全，忽略大量接口错误；设计桩模块工作量大；容易出现相对大的冗余测试。6.6.适用范围适用范围面向对象系统；基于有限状态机的嵌入式系统。 十二、基于使用的集成十二、基于使用的集成 1. 1.目的目的 针对面向对象系统，根据类之间的依赖关系来集成系统，从而验证系统的稳定性。 2. 2.介绍介绍 基于使用的集成从分析类之间

117、的依赖关系出发，通过从对其它类依赖最少的类开始集成，逐步扩大到有依赖关系的类，最后集成到整个系统中。通过该集成方法，可以验证类之间接口的正确性。 3策略策略划分类之间的耦合关系；首先测试独立的类； 其次测试使用一些服务器类的类；最后逐步增加具有依赖性的类（即使用独立类的类），直到整个系统被集成到一起。 4. 4.优点优点 与自底向上集成的优点类似。 5. 5.缺点缺点 与自底向上集成的缺点类似。 6. 6.适用范围适用范围 面向对象软件系统。 十三、客户十三、客户/ /服务器的集成服务器的集成 1. 1.目的目的 验证客户和服务器之间交互的稳定性。 2. 2.介绍介绍 对于和单独的服务器组件进

118、行松散耦合的客户端组件，可以使用客户/服务器集成来完成。在这个模型中，不存在单独的控制轨迹。 3. 3.策略策略单独测试每个客户端和服务器端，必要时使用驱动模块和桩模块；把第一个客户端或客户端组与服务器进行集成；把下一个客户端或客户端组与上一个完成的系统进行集成；重复步骤3直到系统中所有客户端都被加入到系统中。 4. 4.优点优点避免了大爆炸集成的风险；集成次序没有大的约束，可以结合风险或功能优先级进行；有利于复用和扩充；支持可控制和可重复的测试。 5. 5.缺点缺点 在集成过程中，需要大量的驱动模块和桩模块，因此相对其它集成策略而言需求量要大一些。 6. 6.适用范围适用范围 客户/服务器结

119、构的系统。 4.2.3 4.2.3集成测试环境集成测试环境 在搭建集成测试环境时，可以从以下几个方面进行考虑： 1、硬件环境 2、操作系统环境 3、数据库环境 4、网络环境 5、测试工具运行环境 6、其它环境 图图4-144-14显示了两票系统的集成测试环境显示了两票系统的集成测试环境 图4-14 两票系统测试环境示意图 4.2.4集成测试用例设计 一、为系统运行设计的用例一、为系统运行设计的用例 可使用的主要测试分析技术：1、等价类划分 2、边界值分析 3、 基于决策表的测试 二、为正向测试设计用例二、为正向测试设计用例 作为正向集成测试的一个重点就是验证这些集成后的模块，按照设计实现了预期

120、的功能。基于这样的测试目标，我们可以直接根据概要设计文档导出相关的用例。 可使用如下几种主要测试分析技术： 1、输入域测试 2、输出域测试 3、等价类划分 4、状态转换测试 5、规范导出法 在集成测试中的逆向测试包括分析被测接口是否实现了需求规格没有描述的功能，检查规格说明中可能出现的接口遗漏或者判断接口定义是否有错误，以及可能出现的接口异常错误，包括接口数据本身的错误，接口数据顺序错误等。 可使用的主要测试分析技术：1.错误猜测法2.基于风险的测试3.基于故障的测试4.边界值分析5.特殊值测试6.状态转换测试四、为满足特殊需求设计用例四、为满足特殊需求设计用例 在大部分软件产品的开发过程中，

121、模块设计文档就已经明确地指出了接口要达到的安全性指标、性能指标等，此时我们就应该在对模 块进行单元测试和集成测试阶段就开展对满足特殊需求的测试，为整个系统是否能够满足这些特殊需求把关。 可使用的主要测试分析技术：规范导出法。 五、为高覆盖设计用例五、为高覆盖设计用例 与单元测试所关注的覆盖重点不同，在集成测试阶段我们关注的主要覆盖是功能覆盖和接口覆盖，通过对集成后的模块进行分析，来判断哪些功能以及哪些接口没有被覆盖到来设计测试用例。 可使用的主要测试分析技术： 1.功能覆盖分析 2.接口覆盖分析六、测试用例补充六、测试用例补充 在软件开发的过程中，难免会因为需求变更等原因，会有功能增加、特性修

122、改等情况发生，因此我们不可能在测试工作的一开始就100%完成所有的集成测试用例的设计，这就需要在集成测试阶段能够及时跟踪项目变化，按照需求增加和补充集成测试用例，保证进行充分的集成测试。七、注意事项七、注意事项 在集成测试的过程中，我们要注意考虑软件开发成本、进度和质量这三个方面的平衡。不能顾此失彼，也就是说要重点突出（在有限的时间内进行穷尽的测试是不可能的）。4.2.54.2.5集成测试过程集成测试过程 根据集成测试不同阶段的任务，可以把集成测试划分为5个阶段：计划阶段，设计阶段，实施阶段，执行阶段,评估阶段。如图4-15所示。 图4-15 集成测试过程一、计划阶段一、计划阶段 一般安排在概

123、要设计评审通过后大约一个星期的时候，参考需求规格说明书、概要设计文档、产品开发计划时间表来制定。二、设计阶段二、设计阶段 一般在详细设计开始时，就可以着手进行。可以把需要规格说明书、概要设计、集成测试计划文档作为参考依据。三、实施阶段三、实施阶段 在实施的过程中，我们要参考需求规格说明书、概要设计、集成测试计划、集成测试设计等相关文档来进行。四、执行阶段四、执行阶段 只要所有的集成测试工作准备完毕，测试人员在单元测试完成以后就可以执行集成测试。五、评估阶段五、评估阶段 当集成测试执行结束后，要召集相关人员对测试结果进行评估，确定是否通过集成测试。4.2.64.2.6集成测试举例（略）集成测试举

124、例（略）4.34.3集成测试经验总结集成测试经验总结 集成测试界于单元测试和系统测试之间，不易正确理解和把握。因此，有些项目在开发过程中使用调试的手段把模块或子系统一个一 个集成起来，并用这种办法来替换集成测试，而忽略了正规的集成测试，致使软件中存在很多隐患，从而无法保证质量。 根据以往项目开发和测试的实践，总结了如下几条集成测试的经验： 1.根据概要设计尽早进行集成测试计划； 2.要根据项目的实际情况制定一些覆盖率标准，从而根据覆盖率标准来设计足够多的测试用例。然后通过覆盖率分析来衡量集成测试的充分性，补充测试用例，最终使软件质量得到保证； 3.在选择集成测试策略时，应当综合考虑软件质量、开

125、发成本和开发进度这三个因素之间的关系； 4.要根据软件的体系结构特点，来选取集成测试策略，尽可能减少桩模块和驱动模块开发的工作量，同时要兼顾是否容易进行软件缺陷定位。 5.在测试时，可以根据各种集成测试策略的特点把各种集成测试策略结合起来； 6.在进行模块和接口划分时，尽量与开发人员多沟通； 7.当因为需求变更或其他原因更改代码时，应对有改动的模块及与其关联的模块进行回归测试； 8.从集成测试所使用的测试技术角度来说，我们可以使用黑盒测试。那么，经过覆盖率分析后，可以针对没有覆盖的代码或MM-路径补充一些白盒测试用例。 9.在必要的时候，如：单独的手工测试无法完成时可以选用一些适当的集成测试工

126、具。 10.对容易出错的模块要进行充分的集成测试。 本章小结本章小结 集成测试(Integration Testing)是介于单元测试和系统测试之间的过渡阶段，与软件概要设计阶段相对应，是单元测试的扩展和延伸。初学者特别容易把集成测试和系统测试混淆，但实际上二者之间在测试目的、测试对象和所使用的测试方法等方面都有着不同程度的差别。 如同在软件开发之前要进行系统分析一样，在做集成测试之前也需要围绕被测应用的体系结构系统层次关系和依赖关系来进行集成测试分析，找到被测系统中的关键模块，完成模块的接口分析、数据分析、风险分析以及可测试性分析等。而且还需要借助以往的测试经验针对典型的故障情况，选择恰当的

127、测试数据。 集成测试的策略就犹如作战方案一样，如果选取得当便能够顺利完成任务，否则将会兵败千里，甚至全军覆没。因此，要求测试人员要根据项目的实际特点选取一种或几种集成测试策略。其中最常见的几种策略就是：大爆炸集成、自底向上、自顶向下和三明治集成等，也可以把这些称为基于功能分解的集成测试策略，一般用于传统软件结构的集成测试。相对而言，面向对象软件的集成测试策略有所不同，可以使用各种UML 图形或面向对象软件的MM-路径等方法，通过设计能够覆盖所有路径的相应数量的测试用例来完成集成测试。 无论是那个级别的测试基本都使用黑盒和白盒两大类测试用例设计技术，集成测试也是如此。但是，只掌握了这些测试用例设

128、计技术，并不能保证能够很好的进行集成测试。关键还需要我们能够从不同的角度，如：为系统运行设计的用例、为正向测试设计用例、为逆向测试设计用例、为满足特殊需求设计用例、为高覆盖等多个角度设计足够多数量的测试用例，以便能够进行充分周密的测试。当然，这一点是建立在测试人员详细的集成测试分析基础之上的。 由于各组织内部的要求和软件项目的差别，集成测试过程会有所不同，但大体上都要经历集成测试计划、设计、实施和执行、评估等几个阶段。习习 题题1、名词解释：集成测试 函数(方法) 消息接口 接口 接口 风险分析2、 集成测试的重点是什么？3、 简述集成测试的过程。4、 简述集成测试与系统测试的区别。5、如何划分集成测试？ 6、集成测试中如何进行模块分析？衡量模块划分合理性的规则是什么？系统中不同等级的模块的区别是什么？如何判断哪种模块是易错模块？7、简述风险分析的几种类型及其含义。8、概括风险分析的三个阶段的具体内容。9、 简述各种集成测试策略的优点以及缺点。 10、分别用大爆炸集成、自顶向下集成、自底向上集成、三明治集成以及修改过的三明治集成方法对下图中的模块进行集成测试。 11、简要说明集成测试所需要的测试环境。 12、可以从哪些角度进行集成测试用例的设计？