软件工程第 4章 软 件 实 现

本章要点 ： 程序设计语言及编码风格 软件测试的任务、方法及步骤 单元测试、集成测试和系统测试 测试用例的设计 面向对象的软件测试策略及用例设计 软件调试的原则、方法和步骤软件可靠性常用的软件测试工具

软件工程第 4章 软 件 实 现

本章学习目标 ：理解并掌握程序设计语言的分类和选择，理解程序设计中应注意的问题，培养良好的编程风格。了解常用的程序设计工具及软件测试 CASE 工具 掌握测试阶段的目的及原则、测试方法和步骤 理解单元测试、集成测试和系统测试方法和策略 深刻理解并掌握白盒、黑盒测试法用例的设计技术 了解面向对象的测试策略及测试用例的设计 理解调试的原则，掌握调试的方法和步骤 掌握可靠性概念及指标， MTTF 及错误总数的估算方法

软件工程第 4章 软 件 实 现

软件编码和软件测试通常统称为软件实现。 软件编码就是平常所说的软件编程，实质上，编码是把详细设

计的算法翻译成计算机上可执行的语言，翻译员就是程序员。 程序的质量主要取决于软件设计的质量。 在软件交付使用以前必须经过严格的软件测试，通过测试尽可

能找出软件计划、总体设计、详细设计、软件编码中的错误，并加以纠正，才能得到高质量的软件。

通常软件测试并不是在软件编码完全完成后进行，它常常横跨软件生命周期中两个阶段。

测试的工作量和成本非常大，据统计测试工作量要占软件开发总工作量的 40％到 50％以上，用在测试上的开销要占软件开发总成本的 30%至 50%。测试的目的是确保软件的质量，尽量找出软件错误并加以纠正，而不是证明软件没有错误。

软件工程4.1 编 码

4.1.1 程序设计语言 1 程序设计语言的分类 根据程序设计语言的发展历程基本上可以分为低级语言

和高级语言两大类。 (1) 低级语言 低级语言包括机器语言和汇编语言。这两种语言都依赖

于相应的计算机硬件。机器语言属于第一代语言，汇编语言属于第二代语言 。

(2) 高级语言 高级语言包括第三代程序设计语言和第四代超高级程序

设计语言 ( 简称 4GL) 。第三代程序设计语言利用类英语的语句和命令，尽量不再指导计算机如何去完成一项操作，如 BASIC 、 COBOL 和 FORTRAN 等。第四代程序设计语言比第三代程序设计语言更像英语但过程更弱，与自然语言非常接近，它兼有过程性和非过程性的两重特性，如数据库查询语言、程序生成器等。

软件工程高级语言分类

分别从应用特点和语言内在特点两个不同角度对高级语言进行分类

高级语言

从内在特点分

从应用特点分

基础语言，如 BASIC

现代语言，如 PASCAL 、 C

专用语言，如 APL

系统实现语言，如 C

静态高级语言，如 COBOL

块结构高级语言，如 PASCAL

动态高级语言，不属于通用语言

软件工程2 程序设计语言的选择

通常选择程序设计语言时优先考虑高级语言，而不是低级语言 ( 主要是汇编语言 ) 。这是因为高级语言明显优于低级语言。

高级语言的选择可以参照以下标准。 ① 理想标准 为了使程序容易测试和维护以减少软件的总

成本，所选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构。

为了便于调试和提高软件可靠性，应该使编译程序能够尽可能多地发现程序中的错误。

为了降低软件开发和维护的成本，选用的高级语言应该有良好的独立编译机制。

软件工程2 程序设计语言的选择

②实用标准 语言自身的特性 软件的应用领域 软件开发的环境 软件开发的方法 算法和数据结构的复杂性 软件可移植性要求 软件开发人员的知识

软件工程2 程序设计语言的选择

目前在软件实现中使用面向对象语言非常普遍。到底应该选用面向对象语言还是非面向对象语言，关键不在于语言功能强弱。选择面向对象语言的关键因素，是语言的一致的表达能力、可重用性及可维护性。开发人员在选择面向对象语言时，除了考虑上述的实用标准以外，还应该着重考虑以下一些实际因素：

可重用性。 类库和开发环境。 将来能否占主导地位。 其他因素。

软件工程4.1.2 编码风格

编码风格又称程序设计风格或编程风格。编码风格实际上指编程的基本原则。

1. 好程序的标准 能够工作，即能够满足用户的使用要求。 可靠性高。 使用方便。 简单、容易理解。 易于维护和修改。 高效率。 易移植性。 可重用性。

软件工程2. 编程的基本原则

一个公认的、良好的编程风格可以减少编码的错误，减少读程序的时间，从而提高软件的开发效率。为了做到这一点，应该遵循下述一些原则：

源程序文档化 数据说明：在编写程序时，要注意数据说明的风

格。 语句构造 ：构造的语句要简单、直接，不要为了提高效率而使语句更为复杂。

输入和输出：输入／输出的方式和格式应当尽量作到对用户友好，尽可能方便用户的使用。

效率：选择良好的设计方法才是提高程序效率的根本途径，设计良好的数据结构与算法，都是提高程序效率的重要方法。

软件工程2. 编程的基本原则

由于面向对象的程序设计语言所具有的特殊性，面向对象编程原则，除了遵循上述编程的基本原则之外，还包括为适应面向对象方法所特有的概念 ( 如继承性 )而必须遵循的一些新原则：

提高可重用性 提高可扩充性 提高健壮性 总之，在编码时要善于积累编程经验，培养

和学习良好的编程风格，使程序清晰易懂，易于测试与维护，从而提高软件的质量。

软件工程4.1.3 常用程序设计工具简介

目前不同的程序设计语言相应的程序设计工具非常之多，而且相同的程序设计语言对应的程序设计工具随各公司不同而五花八门。但比较流行和常用的有：Microsoft系列有 Visual Studio和 Visual Studio.NET； Borland系列有 Delphi、 Jbuilder、 C++ Builder ；其它还有 Eclipse、 Visual Age for Java、Visual Café for Java、 PowerBuilder和Macromedia系列等。

软件工程4.2 软件测试概述

Grenford J ． Myers在《 The Art Of Software Testing 》一书中的观点常被许多人作为软件测试的目的或定义：

软件测试是为了发现缺陷而执行程序的过程。 测试是为了证明程序中有错误，而不是证明程序中无错误。

一个好的测试用例指的是它可能发现至今尚未发现的缺陷。

一次成功的测试指的是发现了新的软件缺陷的测试。 测试的目的是想以最少的时间和人力找出软件中潜在

的各种错误和缺陷。测试只能尽可能多的查找出程序中错误，而不能证明程序中没有错误。

软件工程4.2 软件测试概述

软件测试的范围并不只是对编码阶段的语法错、语义错、运行错进行查找的一系列活动。而是对软件计划、软件设计、软件编码进行查错和纠错的活动，它涉及到软件开发周期中各个阶段的错误，并分析错误的性质与位置而加以纠正。纠正过程可能涉及到改正或重新设计相关的文档活动。找错的活动称软件测试，纠错的活动称软件调试。

软件工程4.2.1 软件测试的概念和原则

1. 错误 (error) 、缺陷 (fault) 和故障 (failure) 人们在进行软件开发的过程中犯了一个错，则称为一个错误 (er

ror) 。 —应用到测试过程时，有两种不同的使用方式。在第 种使用方式中，错误是指一个实际测量值与理论预期值之间的差异，这种差异就是错误；第二种使用方式中，错误是指一些人的行为引起的软件中的某种故障，通常这些故障是由软件错误造成的。

缺陷 (fault) 常被称为 bug，它是导致软件失败的一个条件。当开发人员犯了一个错，就会在软件中引人一个或多个缺陷。

故障 (failure)又称失效，它是指软件不能按软件规格说明要求执行，从而引起软件行为与用户需求的不一致现象。失效可能发生在测试阶段，也可能发生在软件交付之后的运行阶段和维护阶段。

缺陷是开发人员所看到的软件系统的内部问题，而故障是用户从外部观察到的软件行为与软件需求的偏差。并不是每个软件缺陷都一定会导致软件发生故障，缺陷只有在满足某种条件的情况下才会导致软件故障。

软件工程4.2.1 软件测试的概念和原则

2. 软件测试的基本原则 不完全原则 ：不完全原则表明测试是不完全

的，穷举测试是不可能的。 免疫性原则 ：软件缺陷具有免疫性，测试人

员完成的测试越多，其免疫能力就越强，寻找更多软件缺陷也就更加困难。

全程测试原则 ：全程测试原则要求软件测试不仅存在于完成程序之后，而应该跨越整个软件开发流程。

80／ 20 原则 ： 80／ 20 原则是指 80％的软件缺陷存在于软件 20％的空间里，软件缺陷具有空间聚集性。

软件工程4.2.2 软件测试的方法和步骤

1. 软件测试方法 根据测试过程是否需要运行被测试的程序，软件

测试方法一般分为静态测试方法与动态测试方法。 ①静态测试 静态测试是在对软件代码进行分析、检查和测试时不实际运行被测试的程序，同时它还可以用于对各种软件文档进行测试。静态测试可以采用人工检测和计算机辅助的手段进行，它适用于软件开发的全过程。 静态测试方法主要有代码走通 (Code Walkthrough) 和 Fagan 检查两种。

软件工程1. 软件测试方法

②动态测试 动态测试就是通过运行软件来检验软件的动

态行为和运行结果的正确性。动态测试的主要特征是计算机必须真正运行被测试的程序，通过输入测试数据，对其运行情况 (即输入与输出之间的对应关系 ) 进行分析。因此所有动态测试都必须包括两个基本要素：被测试软件和用于运行软件的数据，即测试数据。动态测试根据测试时的方法不同，分为黑盒测试与白盒测试两类。

软件工程黑盒测试

黑盒测试又称为功能测试或数据驱动测试。它是在已知软件所应具有功能的前提下，通过测试来检测每个功能是否都能正常使用。该方法把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的界面上进行测试，用来证实软件功能的可操作性，检查程序是否满足功能要求或遗漏了功能，程序是否能正确地接收输入数据并产生正确的输出信息，数据结构是否错误或外部数据库访问是否错误，界面和性能是否错误，初始化和终止是否错误。黑盒测试方法主要有等价类划分、边界值分析、错误推测等，它主要用于软件系统测试阶段。

软件工程白盒测试

白盒测试也称结构测试或逻辑驱动测试。它是在已知程序内部结构和处理过程的前提下，通过测试来检测程序中的每条路径是否按预定要求正常运行。该方法把被测试对象看成一个透明的白盒子，测试人员完全知道程序的内部结构和处理算法，并按照程序内部的逻辑测试程序，对程序中尽可能多的逻辑路径进行测试，在所有的点检验内部控制结构和数据结构是否和预期相同。白盒测试方法主要有逻辑覆盖、基本路径测试等，它主要用于验证测试的充分性。

软件工程2.软件测试过程

一个规范化的软件测试过程通常包括以下一些基本测试活动：制定软件测试计划、编制软件测试大纲、设计和生成测试用例、实施测试、生成软件问题报告。

通常可以将测试阶段划分成代码审查、单元测试、集成测试和系统测试 4 个阶段。

①代码审查 代码审查是一种非常有效的程序验证技术，对

于典型的程序来说，可以查出 30%～ 70% 的逻辑设计错误和编码错误。它是由审查小组通过阅读、讨论和争议对程序进行静态测试的过程。

软件工程2.软件测试过程

②单元测试 单元测试就是对软件中的基本组成单位 ( 如一个类、

类中的一个方法、一个模块等 ) 进行测试。因为需要知道程序内部设计和编码的细节，所以单元测试一般由程序员而非测试人员来完成。通过测试可发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。

③集成测试 集成测试又称组装测试或联合测试。它是指在单元

测试的基础上，将模块或组件按照设计要求组装起来同时进行测试，其主要目标是发现与接口有关的问题，即模块或组件之间的协调与通信。

软件工程2.软件测试过程

④系统测试 集成完模块或组件后，系统测试是确保整个测试的

软件系统与系统的功能和非功能性需求保持一致。为了完成这一目的，需要开展下面几种系统测试活动：功能测试、性能测试、验收测试、安装测试。

与软件开发过程相反，测试是从模块或组件开始，自底向上逐步集成的过程。代码审查主要是发现编码时产生的错误；单元测试主要是发现详细设计说明书或源程序代码的错误；集成测试发现的往往是概要设计中的错误或需求说明书中的错误；系统测试主要是发现需求说明书中的错误。因此软件测试就是对软件开发各阶段产生的错误进行检查，以便得到一个最终满足用户需要的软件系统。

软件工程4.3 软件测试的策略

4.3.1 单元测试 在单元测试时，由于被测试的模块或组件处于整个软件结构的某一层位置上，一般是被其它模块或组件调用或调用其它模块或组件，其本身不能单独运行，因此需要为被测模块或组件设计驱动程序和存根程序。所谓驱动程序也就是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块或组件，并且印出有关的结果。存根程序也称桩 (stub) 程序，它代替被测试的模块所调用的模块或组件。因此存根程序也可以称为“虚拟子程序”。

单元测试通常采用白盒测试对模块或组件进行彻底测试，然后辅之以黑盒测试使之对任何合理和不合理的输入都能鉴别和响应。所测模块、驱动程序和存根程序共同构成了一个模块“测试环境”。测试主要针对每个模块或组件的 5个基本特征进行测试：模块或组件接口、局部数据结构、重要的执行通路、出错处理通路和影响上述各方面特性的边界条件等。

软件工程4.3 软件测试的策略

4.3.2 集成测试 在每个模块完成单元测试以后，需要按照设计时的

结构图，把它们连接起来，进行集成测试。通常将模块连接成系统主要有两种方式：非渐增方式、渐增方式。

1. 非渐增方式 不非渐增方式又称为一次性组装方式， 也称为大爆炸集成 (Big-bang Integration) 。这种方式是在所有模块进行了单元测试后，将所有模块按设计的结构图要求连接起来，连接后的程序作为一个整体来进行测试。

在一些很小型的软件项目中，可以使用非渐增方式进行系统集成测试，而在大型软件项目中，这种集成测试策略显然是不合适的。所以目前在进行集成测试时普遍采用渐增方式来进行测试。

软件工程

4.3.2 集成测试

2. 渐增方式 渐增方式又称增殖式组装方式。该方式是把下一个要

测试的模块同已经测试好的模块连接起来进行测试，测试完以后再把下一个应该测试的模块连接进来测试。显然渐增方式的作法与非渐增方式不同。它的集成是逐步实现的，集成测试也是逐步完成的。当使用渐增方式把模块连接到程序中去，按不同的次序实施时有：自顶向下和自底向上两种策略可供选择。

①自顶向下集成 自顶向下集成首先单独测试最顶层的模块或构件。最顶层的模块或构件一般是一个控制模块或构件，它可能调用其他还没有测试的模块或构件。因此，测试时需要为它编写存根程序代替所有直接附属于主控模块的模块。存根程序接受被测模块或构件的调用并且返回结果数据，以便测试能够进行下去。

软件工程2. 渐增方式

自顶向下集成 在组装过程中，可以使用深度优先的策略或宽度优先的策略。深度优先的策略是首先集成一个主控路径下的所有模块，主控路径的选择具有任意性，它依赖于应用程序的特性。宽度优先的策略是将每一层中所有直接隶属于上层的模块集成起来测试。为了保证加入模块没有引进新的错误，可能需要进行回归测试。

所谓回归测试就是在对软件进行修改之后所进行的测试，其目的是检验对软件的修改是否正确。回归测试一般在软件维护阶段进行，但在软件开发和测试阶段也经常会用到。回归测试通常包括重新运行原有的测试数据。因此，需要弄清哪些

测试数据与被修改部分有关。

软件工程2. 渐增方式

自底向上集成 自底向上集成首先单独测试位于系统最底层的模块或构件，

然后将最底层模块或构件与那些直接调用最底层模块或构件的上一层模块或构件集成起来一起测试。这个过程一直持续下去，直到将系统所有的模块或构件都集成起来，形成一个完整的软件系统进行测试。具体步骤如下：①把低层模块组合成实现某个特定的软件子功能的功能集合。②写一个驱动程序 ( 用于测试的控制程序 ) ，协调测试数据

的输入和输出。 ③ 对由模块组成的子功能集合进行测试。 ④ 去掉驱动程序，沿软件结构自下而上移动，把子功能集合组合起来形成更大的子功能集合。

⑤ 重复②～④步。 自底向上集成测试一般适用于底层存在众多通用例行子程序、采用面向对象设计方法以及系统使用了大量单独的可重用模块的地方。

软件工程2. 渐增方式

自顶向下测试方法的主要优点是不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。自顶向下测试方法的主要缺点是需要存根程序，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。因此在实际的集成测试中，往往采用将两种策略进行混合使用的策略。改进的自顶向下集成。 混合法或三明治集成 (Sandwich Integration) 。

软件工程4.3.3 系统测试

系统测试的目的是保证所实现的系统确实是用户所想要的。为了到达此目的，需要完成一系列测试活动。这些活动包括功能测试、性能测试、验收测试、安装测试。

1. 功能测试 功能测试也称为需求测试，主要测试系统的功能性需求，

找出功能性需求和系统之间的差异，即检查软件系统是否完成了需求规格中所指定的功能。功能测试主要使用黑盒测试技术。

2. 性能测试 性能测试主要测试系统的非功能性需求，找出非功能性需求和系统之间的差异，即检查软件系统是否完成了需求规格中所指定的非功能性要求，如安全性、计算精度、运行速度以及安全性等。性能测试期间要进行很多项测试活动，下面是主要的一些活动。

软件工程4.3.3 系统测试

2. 性能测试强度测试安全性测试恢复测试 软件配置审查 兼容性测试

通过功能测试和性能测试后有下述两种可能的结果： ⑴ 功能和性能与用户要求一致，软件是可以接受的； ⑵ 功能和性能与用户要求有差距。 如出现⑴中的结果，则可进行以未来用户为主的验收测试。

如出现⑵中的情况，则问题就比较复杂。在这个阶段发现的问题往往和需求分析阶段的差错有关，涉及面通常比较广，因此解决起来也比较困难。为了制定解决该测试过程中发现的软件缺陷或错误的策略，通常需要和用户充分协商。

软件工程4.3.3 系统测试

3. 验收测试 验收测试的目的是使得未来的用户能够确认所开发的系统满足了他们的需求，并确实是他们所想要的系统。在此阶段开发人员提供必要的支持和帮助，由用户自己设计和运行测试数据，验收测试一般采用黑盒测试。验收测试的组织一般有三种方式：基准测试、典型测试和并行测试。

基准测试 基准测试有一个很特殊的应用场合：用户具有明确的项目需求，为了降低开发风险，用户同时要求两个或两个以上的开发团队按照他们给出的一份相同的需求各自独立地开发系统。待各个系统开发完成之后，用户组织基准测试。首先，用户准备一个测试用例集合，这个集合代表了系统运行的典型情况。然后，用户在各个系统中运行每个测试用例，并就系统所实现的功能和性能情况作出评价。最后，基于基准测试的结果，用户选择购买其中的一个软件系统。

软件工程3. 验收测试

典型测试 它是在试用的基础上来运行系统，依赖于每天对系统

的操作来测试各项功能。如果一个软件是为许多客户开发的（例如，向大众公开出售的盒装软件产品），那么，让每个客户都进行典型测试是不现实的。在这种情况下，绝大多数软件开发商都使用被称为 Alpha测试和 Beta测试的过程，来发现那些看起来只有最终用户才能发现的错误。

Alpha测试由用户在开发环境下进行的测试，并且在开发者对用户的“指导”下进行测试。开发者坐在用户旁边，负责记录发现的错误和使用中遇到的问题。总之， Alpha测试是在受控的环境中进行的。

软件工程3. 验收测试

Beta测试由软件的最终用户们在一个或多个用户的实际使用环境下进行的测试。与 Alpha测试不同，开发者通常不在 Beta测试的现场，因此， Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在 Beta测试过程中遇到的一切问题（真实的或想像的），并且定期把这些问题报告给开发者。接收到在 Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

并行测试 当新开发的系统是用来替代一个老系统时，常常采用

并行测试方法。并行测试方法是将新系统和老系统并行运行，并行测试可以使得用户能够逐渐熟悉新系统的使用，可以验证用户指南和使用手册之类的文档，还能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。

软件工程4. 安装测试

系统验收后，就在用户环境中进行安装并测试。在大多数情况下，安装测试重复用户环境中功能测试和性能测试时执行的测试数据。如果验收测试是在目标环境中进行的，就不需要进行安装测试。

软件工程4.4 测试用例的设计

设计测试方案是测试的首要任务。测试方案包括具体的测试目的（如预定要测试的具体功能）和测试用例 (test case) 。一个测试用例是用来执行被测代码的系统的一个输入集合或一个场景。通常又把测试数据和预期的输出结果称为测试用例。理想情况下选择的测试用例，应使这些用例的成功执行能保证软件中无故障。由于穷举测试用例集是不现实的，我们只能选择

一个能逼近理想情况的测试用例集。

软件工程4.4 测试用例的设计

4.4.1 白盒测试法用例的设计 白盒测试法设计用例的指导思想是选择测试

用例集检验代码的内部结构是否正确，因此它是在清楚地知道了程序的内部结构和处理算法的基础上进行的测试用例设计。

1. 逻辑覆盖 所谓逻辑覆盖是对一系列测试过程的总称，

这组测试过程逐渐进行越来越完整的通路测试。逻辑覆盖要求对某些程序的结构特性做到一定程度的覆盖，或者说是“基于覆盖的测试”，即有选择地执行程序中某些最有代表性的通路。

软件工程 1. 逻辑覆盖

•语句覆盖 语句覆盖是指使用足够多的测试数据，使被测试程序中每个语句至少执行一次。

•分支覆盖 分支覆盖又叫判定覆盖，是指设计出足够多的测

试用例，使得被测程序中每个判定表达式都执行一次“真”和一次“假”，从而使程序的每一个分支至少都通过一次。

•条件覆盖 条件覆盖要求不仅每个语句至少执行一次，而且

使得判定表达式中每个条件的各种可能的值都至少执行一次。

软件工程1. 逻辑覆盖

•判定 -条件覆盖 判定 -条件覆盖要求设计足够的测试用例，

使得判定表达式中的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。

•条件组合覆盖 条件组合覆盖它要求选取足够多的测试数据，

使得每个判定表达式中条件的各种可能组合都至少执行一次。

•路径覆盖 路径覆盖就是要求设计足够多的测试数据，

可以覆盖被测程序中所有可能的路径。

软件工程逻辑覆盖举例

TF

F

T

入口

A>1 AND B=0

返回

A=2 OR X>1

S

a

b

d

X=X/A

X=X+1 e

c

语句覆盖的测试用例是：【 {A=2 ， B=0 ， X=4}， {A=2 ， B=0 ， X=3} 】 覆盖 sacbed 分支覆盖的测试用例是： 【 {A=3 ， B=0 ， X=3}， {A=3 ， B=0 ， X=1} 】 覆盖 sacbd【 {A=2 ， B=1 ， X=1}， {A=2 ， B=1 ， X=2} 】 覆盖 sabed 覆盖的测试用例是： 【 {A=2 ， B=0 ， X=4}， {A=2 ， B=0 ， X=3} 】 覆盖 sacbed (满足 A＞ 1 ， B＝ O ， A＝ 2 和 x ＞ 1 的条件 ) 【 {A=1 ， B=1 ， X=1}， {A=1 ， B=1 ， X=1} 】 覆盖 sabd (满足 A≤1 ， B≠O ， A≠2 和 x≤1 的条件 )

软件工程逻辑覆盖举例

判定 -条件覆盖的测试用例是：【 {A=2 ， B=0 ， X=4}， {A=2 ， B=0 ， X=3} 】 覆盖 sacbed【 {A=1 ， B=1 ， X=1}， {A=1 ， B=1 ， X=1} 】 覆盖 sabd

条件组合覆盖的测试用例是： 【 {A=2 ， B=0 ， X=4}， {A=2 ， B=0 ， X=3} 】 覆盖 sacbed (满足 A＞ 1 ， B＝O ， A＝ 2 和 x＞ 1 的条件 )【 {A=2 ， B=1 ， X=1}， {A=2 ， B=1 ， X=2} 】 覆盖 sabed (满足 A＞ 1 ， B≠O ， A＝ 2 和 x≤1 的条件 )【 {A=1 ， B=0 ， X=3}， {A=1 ， B=0 ， X=4} 】 覆盖 sabed (满足 A≤1 ， B＝O ， A≠2 和 x＞ 1 的条件 )【 {A=1 ， B=1 ， X=1}， {A=1 ， B=1 ， X=1} 】 覆盖 sabd (满足 A≤1 ， B≠O ， A≠2 和 x≤1 的条件 )

软件工程2.  基本路径测试

使用这种技术设计测试用例时，首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合，从该基本集合导出的测试用例可以保证程序中的每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值。基本路径测试技术设计测试用例的步骤：

第一步：将详细设计结果或程序编码映射成程序控制结构图。

第二步：根据程序控制结构图计算程序的环形复杂度。

第三步：确定线性独立路径的基本集合。 第四步：设计测试用例，确保基本路径集中每条路径的执行。

软件工程4.4.2 黑盒测试法用例的设计

黑盒测试法用例的设计有等价类划分、边界值分析、错误推测等。根据这些方法来生成测试用例，可以提前到需求分析阶段或设计阶段。同时使用这些方法很可能发现白盒测试不易发现的其他类型的错误。

①等价类划分 等价类划分的基本思想是将程序的所有可能输入数据 ( 有效与无效的 ) 划分为若干等价类。当程序输入数据集合的等价类确定以后，从每个等价类任取一组代表值就可以产生一个测试用例。等价类的划分有两种不同情况：

软件工程①等价类划分

有效等价类：是指对于软件的需求规格说明来说，是合理的、有意义的输入数据集合。 无效等价类：是指对于软件的需求规格说明来说，是不合理的、无意义的输入数据集合。

利用等价类划分产生测试用的具体步骤如下： 第一步：划分等价类。 第二步：设计测试用例。根据等价类设计测试用例时主要

使用下面两个步骤：设计一个有效等价类的测试用例。对于各个输入条件，以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止；设计一个无效等价类的测试用例。使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。注意因为在输入中有一个错误存在时，往往会屏蔽掉其它错误显示，所以设计无效等价类的测试用

例时，一次只覆盖一个无效等价类。

软件工程等价类划分举例

例 某城市电话号码组成规则是：地区码 +前缀 +后缀。

地区码：空白或者 3位数字； 前缀：非 0或者 1开头的 3位数字： 后缀： 4位数字。 某程序接受符合以上条件的电话号码，拒绝所有不符合规定的号码。对该程序使用等价类划分法设计测试用例。

( 略 )

软件工程2. 边界值分析

在等价类划分中，测试用例从各等价类中任意选取，没有考虑同一等价类中各组数据对于发现隐藏错误的差异。实践经验证明，程序往往在处理边界情况时会发生错误。如果将测试值选取在等价类的边界附近，可以期望得到高效的测试用例，可以查出更多的错误和问题。这就是边界值分析的出发点。

通常设计测试用例时总是联合使用等价类划分和边界值分析两种技术。一般先采用边界值分析设计测试用例，再用等价类划分补充之。

软件工程2. 边界值分析

典型边界值包括下面一些情况： 如果输入条件说明了输入值的范围，则应该在范围的边界上取值；另外还应该刚好越过边界的值作为无效情况的测试用例。

如果输入条件指出了输入数据个数，则应为最小个数、最大个数、低于最小个数，高于最大个数分别设计测试用例。

对于输出结果应该作类似于输入一样的处理。 如果程序的输入输出数据是有序集合，则应该特

别注意表中第一个、最后一个元素，以及集合中仅有 1 个元素的情况。

对于输入输出为线性表的程序，应该考虑输入输出有 0 个、 1 个和可能的最大元素个数情况。

软件工程3. 错误推测

有经验的测试人员往往根据经验与直觉，推测程序中可能存在的各种错误，从而有针对性的编写检查这些错误的测试用例，实现高效的测试，这就是错误推测法。

对于测试对象中可能存在何种类型的错误，是挑选测试用例应该考虑的重要因素。推测的重要依据是程序设计规格说明书(或者代码的序言性注释 ) ，不但要考虑它告诉了我们什么，还应该考虑说明中遗漏了什么，或者是否存在可能的冲突。

软件工程测试用例设计小结

在实际应用中通常以黑盒测试法设计测试用例为主，白盒测试法设计测试用例为辅。并可以考虑以下测试策略：

任何情况下都应该使用边界值分析设计测试用例；

必要时采用等价类划分法补充用例； 必要时再用错误推测法补充用例； 对照程序内部逻辑，检查已设计用例的逻辑覆盖。根据程序可靠性要求，补充用例使之达到规定的逻辑覆盖要求。

软件工程4.5 面向对象的软件测试 从“小型测试”开始逐步过渡到“大型测试”，这是软件软件测试经典的策略和经典的用例生成技术。测试面向对象软件的策略和用例生成技术与上述策略基本相同，但由于面向对象程序的特殊性质，测试的焦点不是模块而是对象类，因此必须增加一系列措施和手段，来保证最大限度地发现软件中潜在的各种错误和缺陷。

通常认为面向对象的性质有助于简化测试，其实并非如此。

软件工程4.5.1 面向对象的测试策略

面向对象的测试应该针对 4 个不同的层次：功能、类、聚类（彼此协作的对象的交互群）和整个系统。在面向对象的每个不同测试阶段，都有其不同层次的侧重点，如在面向对象的单元测试中侧重于类层次，面向对象的集成测试侧重于聚类，而面向对象的系统测试则是整个系统。

1. 面向对象的单元测试 面向对象的单元测试主要是对每个类进行单元测试。在对

对象类进行测试时，可从 2 个层次来进行：测试与对象关联的单个操作；测试单个对象类。对象关联的单个操作是一些函数或程序，可以使用白盒测试方法和黑盒测试方法来进行测试。对于单个对象类应该把操作作为类的一部分来测试，不能再孤立地测试单个操作。黑盒测试的原理不变，但等价类划分这个概念需要扩展以便适合操作序列的情况。划分测试（ partition testing）和基于故障的测试（ fault based testing）就是对原概念扩展的方法。

软件工程2.面向对象的集成测试

由于构成类的各个成分彼此间存在直接或间接的交互，一次集成一个操作到类中通常是不现实的。Murphy等认为一组对象类通过组合行为提供一组服务，它们应该一起测试．即所谓集群测试（ cluster testing）。集群测试使用的测试用例主要是力图发现相互协作的类之间的协作错误。

在面向对象系统的集成测试中通常有 2 种不同的策略：

基于线程的测试（ thread based testing） 基于使用的测试（ use based testing）

软件工程3.面向对象的系统测试

在系统测试层次，面向对象的系统测试集中检查用户可见的动作和用户可识别的输出，不再考虑类之间相互连接的细节。系统测试时的用例生成可使用上节介绍的黑盒测试方法，但是，基于用例或场景的测试是面向对象系统测试的主要方法。

基于用例或场景的测试是根据用例或场景对系统使用的描述来制定测试用例。基于用例或场景的测试通常是最有效的方法，因为它是这样组织测试过程的，先测试那些最平常的场景，不寻常的或异常的场景故在稍后测试。这样做符合测试的基本原理，即最大的测试努力应诙用于系统最常用到的部分。此外，测试用例还可以从动态模型中导出。

软件工程4.5.2 面向对象的测试用例设计 面向对象测试关注于设计合适的操作序列以测试类

的状态。 Berard 提出了面向对象的软件测试用例设计的整体方法：

每个测试用例应该被惟一标识，并且和将被测试的类显式地相关联；

应该陈述测试的目的；对每个测试应该开发一组测试步骤，应该包含： ①  将被测试的对象的一组特定状态 ②  将作为测试的结果使用的一组消息和操作 ③  当测试对象时可能产生的一组例外 ④   一组外部条件，即为了适当地进行测试而必须存在的软件外部环境的变化

⑤辅助理解或实现测试的补充消息

软件工程1.类的测试方法

对面向对象的软件来说，单元测试着重测试单个类和类中封装的方法。测试单个类的方法主要有随机测试、划分测试和基于故障的测试等 3 种。

随机测试 划分测试 划分测试（ partition testing）可以减少测试类时

所需要的测试用例的数量，它是等价类划分法思想的扩展。首先，把输入和输出分类，然后设计测试用例以测试划分出的每个类别。划分类别的 3 种方法：

（ 1） 基于状态的划分 （ 2） 基于属性的划分 （ 3） 基于类操作的划分

软件工程1.类的测试方法

基于故障的测试 基于故障的测试（ fault based testing）就是设计最有可能发现故障的测试用例来进行测试，它是错误推测法思想在面向对象测试中的应用。首先，推测软件中可能有的错误，然后设计出最可能发现这些错误的测试用例。

软件工程2．  类间测试方法

当面向对象的系统开始集成时，测试用例的设计变得更加复杂。在这个测试阶段，必须对类间协作进行测试。和测试单个类相似，测试类协作可以使用随机测试方法和划分测试方法，以及基于情景的测试和行为测试来完成。

类的动态行为可以用状态转换图来表达。利用类的状态图可以帮助我们导出测试该类（及与其协作的那些类）的动态行为的测试用例。在遍历

“ ” “状态模型时，可以按 深度优先的方式 和 宽度”优先的方式 。在类的行为导致与一个或多个类

协作的情况下，应该使用多个状态图去跟踪系统的行为流。

软件工程 4.6 软件调试

调试 (debug)又称排错或纠错。调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。准确的说，调试工作包括：对错误进行定位并分析原因，即诊断；对于错误部分重新编码以改正错误；重新测试。调试工作的重点是诊断，通常诊断约占调试工作量的 90 ％以上。

软件测试应该由他人进行，调试工作主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。

调试是一件很困难的工作，之所以困难，是由于人的心理因素以及技术方面的原因而致，其中心理方面的原因可能多于技术方面的原因。

软件工程4.6.1 调试原则

1. 诊断原则用头脑去分析思考与错误征兆有关的信息。 避开死胡同。 只把调试工具当做辅助手段来使用。 避免用猜测或试探的办法，最多只能把它当作最后手段。

2. 修改原则 修改错误前一定要仔细考虑。在出现错误的地方，很可能还有别的错误。 修改错误的一个常见失误是只修改了这个错误的征兆或这个错误的表现，而没有修改错误的本质。 当心修正一个错误的同时有可能会引入新的错误。 修改错误的过程将迫使人们暂时回到程序设计阶段。 修改源代码程序，不要改变目标代码。

软件工程4.6.2 调试步骤

调试的步骤如下：(1) 调试过程从执行一个测试用例开始，然后从

错误的外部表现形式入手，确定程序中出错位置；

(2) 研究有关部分的程序，找出错误的内在原因；(3) 修改设计和代码，以排除这个错误；(4) 重复进行暴露了这个错误的原始测试或某些

有关测试，以确认： 1) 是否排除了该错误；2) 是否引进了新的错误。

(5) 如果所做的修正无效，则撤消这次改动，恢复程序修改之前的状态。重复上述过程，直到找到一个有效的解决办法为止。

软件工程4.6.3 调试方法

目前常用的调试方法有如下几种： 1.试探法 :试探法又称蛮干法。该方法一般由调试人员分析错误的症状，猜测问题的所在位置，利用在程序中设置输出语句，分析寄存器、存储器的内容等手段来获得错误的线索，一步步地试探和分析出错误所在。该方法的排错能力主要依赖于调试人员的经验、直觉和运气。

2. 回溯法：调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回跟踪程序代码，直到找出错误根源为止。这是一种适合于小型程序排错的有效方法，对于大规模程序，由于其需要回溯的路径太多而变得不可操作。

软件工程4.6.3 调试方法

3.对分查找法：对分查找法的基本思路是，如果已经知道每个变量在程序内若干个关键点的正确值，则可以用

“ ”赋值语句或输入语句在程序中点附近 注入 这些变量的正确值，然后运行程序并检查所得到的输出。如果输出结果是正确的，则错误原因在程序的前半部分；反之，错误原因在程序的后半部分。对错误原因所在的那部分再重复使用这个方法，直到把出错范围缩小到容易诊断的程度为止。

4. 归纳法：归纳法是一种从特殊推断一般的系统化思考方法。归纳法排错的基本思想是：从一些错误征兆的线索着手，通过分析它们之间的关系来找出错误。它一般从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。

软件工程4.6.3 调试方法

5.演绎法：演绎法是一种从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。演绎法排错是测试人员根据测试结果，列出所有可能的错误原因。分析已有的数据，排除不可能和彼此矛盾的原因。对余下的原因，选择可能性最大的，利用已有的数据完善该假设，使假设更具体。用假设来解释所有的原始测试结果，如果能解释这一切，则假设得以证实，也就找出错误；否则，要么是假设不完备或不成立，要么有多个错误同时存在，需要重新分析，提出新的假设，直到发现错误为止。

对分查找法、归纳法和演绎法都是对错误发生有关的数据进行分析，来寻找到潜在的原因，因此它们都属于原因排除法。

软件工程4.7 软件可靠性

4.7.1 软件可靠性概念 1.软件可靠性定义 软件可靠性是软件在给定的时间间隔内及给定的环境条件下，按照规格说明书的规定成功地运行的概率。定义中“时间间隔”是一个随机变量，它随运行时间的增加，程序运行中出现故障的概率也增大。定义中的“成功地运行”，是指不仅程序能正确地运行，满足用户对它的功能要求，而且当程序一旦受到意外的伤害，或系统错误时，能尽快恢复，仍能正常地运行。

软件工程4.7.1 软件可靠性概念

2. 软件可靠性的主要指标 平均无故障时间MTTF(Mean Time To Failure)

和平均故障间隔时间MTBF(Mean Time Between Failures) 。

假设某软件系统运行时发生了 n+1次故障，每两次故障之间所经历的时间间隔为 t1 ， t2 ， t3 ，…，tn 。那么这 n个时间段的平均值就是平均无故障时间。即：

MTTF=(t1＋ t2＋ t3＋…＋ tn)/n 平均故障间隔时间MTBF 是指两次相继故障之间的平均时间。平均修复时间 (MTTR)描述的是修复一个软件缺陷所花费的平均时间，将平均无故障时间和平均修复时间加起来，就是每两次故障之间的平均时间。

软件工程4.7.2 软件测试中可靠性分析

1.估算平均无故障时间MTTF 平均无故障时间MTTF 通常是通过 Shooman模型来估算。 Shooman模型MTTF 估算公式是：

MTTF=1/[K(ET/IT-Ec(τ)/IT)] 其中， K是一个经验常数，它的值应该根据经验选取 (美国的

一些统计数字表明， K的典型值是 200) 。 ET是测试之前程序中原有或固有的错误总数， IT是程序长度 (机器指令条数或简单汇编语句条数 )， τ是测试 (包括排错 )的时间， Ec(τ)是在 O～ t期间内检出并排除的错误总数。

测试时根据发现和改正错误的个数，利用MTTF=1/Kεr(τ)式，其中 εr(τ)=ET/IT -Ec(τ)/IT可以计算出平均无故障时间MTTF。

利用 Ec= ET - IT /(K×MTTF)式，可以根据软件规格说明对软件平均无故障时间MTTF 的要求，估计需要改正多少个错误之后，测试工作可以停止，以此来评价软件测试的进展情况。

软件工程2.估算软件中错误总数

估计 ET 的两种方法： ①植入错误法 这种估算法的主要思想是：假设测试时使用测试用例发现植入错误和固有错误的概率相同。因此，在测试之前由专人在程序中随机地植入一些错误，测试之后，根据测试小组发现的错误中原有的和植入的两种错误的比例，来估计程序中原有错误的总数 ET 。

若设 Ns是测试之前人为地植入的错误数 ,经过一段时间的测试之后发现ｎ s个植入的错误，此外还发现了ｎ个程序固有的错误数。如果认为测试用例发现植入错误和发现固有错误的能力相同，则能够估计出程序中原有错误的总数为：

Ｎ =ｎ×Ns /ｎ s 上式中Ｎ即是错误总数 ET 的估计值。所以在测试结束时，

程序中残存的固有错误数为：Ｎ -ｎ个。

软件工程2.估算软件中错误总数

②分别测试法 分别测试法使用两个测试员（或测试小组）同时互相独立地

测试同一程序的两个副本。具体做法是，在测试过程的早期阶段，由测试员甲和测试员乙分别测试同一个程序的两个副本，另一名分析员分析他们的测试结果。用 τ表示测试时间，假设：

τ=0时错误总数为 B0； τ=τ1时测试员甲发现的错误数为 B1； τ=τ1时测试员乙发现的错误数为 B2； τ=τ1时两个测试员发现的相同错误数为 bc 。 如果把测试员甲发现的错误作为植入错误，即程序中植入错

误的总数为 B1,则测试员乙发现的 B2 个错误中有 bc 个相当于是植入错误。假定测试员乙发现各种错误的概率相同，则可以估计出测试前程序中的错误总数为：

软件工程

②分别测试法

B0= B1×B2/bc

使用分别测试法，在测试阶段的早期，分析员每隔一段时间分析两名测试员的测试结果，并且用上式计算 B0 。如果几次估算的结果相差很多，还需要继续估算 B0 ，直到几次估算的结果相差不多，则可用 B0 的平均值作为 ET 的估计值。此后一名测试员可以改做其他工作，余下的一名测试员继续完成剩余的测试工作，因为他可以继承另一名测试员的测试结果，所以分别测试法增加的测试成本并不太多。

软件工程4.8 软件测试 CASE 工具

通过应用测试工具可以提高测试质量和测试效率，这是测试工具的价值所在。软件测试工具的开发较之于其他 CASE工具的开发，难度最大。这是由于适用于所有软件系统的测试工具是不存在的。一般

来说，软件测试工具至少应满足下列基本功能： (1) 测试工具能够根据特定的度量标准度量软件的若干质量指标。

(2) 查找并定位软件中所包括的错误并进行提示 ( 不少工具要求有自动修正功能 ) 。

(3)成测试报告。 作为软件测试工具其构成至少包括 5 方面的要素：

软件工程4.8 软件测试 CASE 工具

(1) 用户接口：最好采用基于 GUI 的界面方式，通过统一的交互式用户接口以协调其他各子系统的工作。

(2) 系统配置管理子系统：对评测系统的系统参数进行管理，通过修改这些参数可以重新配置评测系统和对软件进行不同验收标准的测试。

(3) 软件评价方法编辑子系统：可以编辑对语言描述进行评价的方法。该系统可进行词法分析、语法分析和错误检查，从而形成软件评价方法的内部表现形式，并将其存放于软件评测方法库中。

(4) 软件评测子系统：对被评测软件进行分析和测试，通过调用软件评测方法库中的方法和评测标准对被评测软件进行评测。软件评测子系统应该既可采用人机交互的方式进行评测，又可采用自动方式进行评测并将软件评测数据放入评测数据库中。

(5)评测报告生成子系统：创建、编辑评测报告的模板，放入评测报告模板库中，用户可以根据具体模板生成符合特定需要的测试报告。

软件工程4.8.1 软件测试工具分类

测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理 ( 测试流程管理、缺陷跟踪管理、测试用例管理 ) 的工具。

1．白盒测试工具 白盒测试工具一般是针对代码进行测试，测试中发现

的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。

静态测试工具：代表有 Panorama系列、 Telelogic公司的 Logiscope软件、 PR公司的 PRQA软件等。动态测试工具：代表有 Rational公司的 Purify系列、 Compuware公司的 DevPartner软件等。

软件工程4.8.1 软件测试工具分类

2. 黑盒测试工具 黑盒测试工具包括功能测试工具和性能测试工具。

黑盒测试工具的一般原理是利用脚本的录制 (Record)／回放 (Playback) ，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。黑盒测试工具的代表有 Rational 公司的 TeamTest、 Robot、 Quantify， Compuware 公司的 QACenter。另外，专用于性能测试的工具有 Radview公司的WebLoad，Microsoft 公司的WebStress及Microsoft Application Center Test等。

软件工程4.8.1 软件测试工具分类

3.测试管理工具 测试管理工具用于对测试进行管理。一般而言，测

试管理工具对测试计划、测试用例、测试实施进行管理，并且测试管理工具还包括对缺陷的跟踪管理。测试管理工具的代表有 Rational 公司的 Test Manager、 Compureware 公司的 TrackRecord等软件。

4. 其它测试工具 其它专用的测试工具，如驱动自动化测试程序 HCT

是Microsoft的Windows 驱动自动化测试工具 ，数据库测试的 TestBytes，对应用性能进行优化的EcoScope等 。

软件工程4.8.2 测试工具的选择

在考虑选用工具的时候，建议从功能和价格两个方面来权衡和选择。

目前市面上同类的软件测试工具之间的基本功能都大同小异，各种软件提供的功能也大致相同，只不过有不同的侧重点。除了基本功能外，测试工具的集成能力；操作系统和开发工具的兼容性；报表功能可以作为选择测试工具的参考。

价格也是一个必须考虑的重要因素，各个单位或公司可以根据自己的经济实际情况购买合适的工具。

选择测试工具时除了功能和价格之外，还必须考虑引入测试工具的连续性和一致性。对测试工具的选择必须有一个全盘的考虑，分阶段、逐步引入测试工具，应杜绝一次性投资和重复投资的行为。

软件工程本章小结

• 软件实现包括编码和测试两个阶段。 • 编码目的是把详细设计的结果翻译成用选定的语言书写

的源程序。程序的质量主要是由设计的质量决定的。但是，编码的风格和使用的语言，对编码质量也有重要的影响。具体选用哪种程序设计语言？一般不使用汇编语言写程序，而使用高级程序设计语言。至于具体选用哪种高级程序设计语言，则不仅要考虑语言本身的特点，还应该考虑使用环境等一系列实际因素。

• 软件测试是软件开发时期最繁重的任务，也是保证软件可靠性的最主要手段。测试阶段的根本目的是发现并改正软件中的错误。

• 大型软件的测试通常分阶段地进行，一般经过单元测试、集成测试和系统测试 3 个阶段。软件测试时既可以使用动态测试，也可以使用静态测试。两种测试各有优缺点，互相补充，缺一不可。

软件工程本章小结

• 设计测试用例，是搞好软件测试的一项关键技术。选择测试用例的目标，是用尽可能少的测试数据，达到尽可能大的覆盖面，发现尽可能多的软件测试与问题。白盒测试用例的生成技术本节介绍的主要有：逻辑覆盖和基本路径测试；黑盒测试用例的生成技术本节介绍的主要有：等价类划分、边界值分析和错误推测。

• 调试是要准确确定测试中的错误位置，并加以改正的过程。为了改正错误往往需要修正原来的设计，并使用正确的原则和方法，尽量避免在调试过程中引进新错误。

软件工程本章小结

• 通过测试的统计数据可以估算出程序中剩余的错误数。程序中潜藏的错误的数目，直接决定了软件的可靠性。根据测试和调试过程中已经发现和改正的错误数，可以估算软件的平均无故障时间。平均无故障时间是软件可靠性一个重要指标。根据用户需求规格说明书中的软件平均无故障时间要求，可以估算出应该改正的错误数，从而能够判断测试工作何时可以结束。

• 为了提高测试质量和测试效率，在测试中使用测试工具已经成为普遍趋势。由于测试工具种类繁多，一般可分为白盒测试工具、黑盒测试工具、性能测试工具、测试管理 ( 测试流程管理、缺陷跟踪管理、测试用例管理 ) 工具。在选择这些测试工具时除从考虑功能和价格两个主要方面外，还要考虑引入测试工具的连续性和一致性。