第 4 章 软 件 实 现

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

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

3. 第4章 软 件 实 现 软件工程 • 软件编码和软件测试通常统称为软件实现。 • 软件编码就是平常所说的软件编程，实质上，编码是把详细设计的算法翻译成计算机上可执行的语言，翻译员就是程序员。 • 程序的质量主要取决于软件设计的质量。 • 在软件交付使用以前必须经过严格的软件测试，通过测试尽可能找出软件计划、总体设计、详细设计、软件编码中的错误，并加以纠正，才能得到高质量的软件。 • 通常软件测试并不是在软件编码完全完成后进行，它常常横跨软件生命周期中两个阶段。 • 测试的工作量和成本非常大，据统计测试工作量要占软件开发总工作量的40％到50％以上，用在测试上的开销要占软件开发总成本的30%至50%。测试的目的是确保软件的质量，尽量找出软件错误并加以纠正，而不是证明软件没有错误。

4. 4.1 编码 软件工程 4.1.1 程序设计语言 1 程序设计语言的分类 根据程序设计语言的发展历程基本上可以分为低级语言和高级语言两大类。 (1) 低级语言 低级语言包括机器语言和汇编语言。这两种语言都依赖于相应的计算机硬件。机器语言属于第一代语言，汇编语言属于第二代语言 。 (2) 高级语言 高级语言包括第三代程序设计语言和第四代超高级程序设计语言(简称4GL)。第三代程序设计语言利用类英语的语句和命令，尽量不再指导计算机如何去完成一项操作，如BASIC、COBOL和FORTRAN等。第四代程序设计语言比第三代程序设计语言更像英语但过程更弱，与自然语言非常接近，它兼有过程性和非过程性的两重特性，如数据库查询语言、程序生成器等。

5. 基础语言，如BASIC 从应用特点分 现代语言，如PASCAL、C 高级语言 专用语言，如APL 系统实现语言，如C 静态高级语言，如COBOL 从内在特点分 块结构高级语言，如PASCAL 动态高级语言，不属于通用语言 高级语言分类 软件工程 分别从应用特点和语言内在特点两个不同角度对高级语言进行分类

6. 2 程序设计语言的选择 软件工程 通常选择程序设计语言时优先考虑高级语言，而不是低级语言(主要是汇编语言)。这是因为高级语言明显优于低级语言。 高级语言的选择可以参照以下标准。 ① 理想标准 l为了使程序容易测试和维护以减少软件的总成本，所选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构。 l为了便于调试和提高软件可靠性，应该使编译程序能够尽可能多地发现程序中的错误。 l为了降低软件开发和维护的成本，选用的高级语言应该有良好的独立编译机制。

7. 2 程序设计语言的选择 软件工程 ②实用标准 l语言自身的特性 l软件的应用领域 l软件开发的环境 l软件开发的方法 l算法和数据结构的复杂性 l软件可移植性要求 l软件开发人员的知识

8. 2 程序设计语言的选择 软件工程 • 目前在软件实现中使用面向对象语言非常普遍。到底应该选用面向对象语言还是非面向对象语言，关键不在于语言功能强弱。选择面向对象语言的关键因素，是语言的一致的表达能力、可重用性及可维护性。开发人员在选择面向对象语言时，除了考虑上述的实用标准以外，还应该着重考虑以下一些实际因素： l可重用性。 l类库和开发环境。 l将来能否占主导地位。 l其他因素。

9. 4.1.2 编码风格 软件工程 编码风格又称程序设计风格或编程风格。编码风格实际上指编程的基本原则。 1. 好程序的标准 l能够工作，即能够满足用户的使用要求。 l可靠性高。 l使用方便。 l简单、容易理解。 l易于维护和修改。 l高效率。 l易移植性。 l可重用性。

10. 2. 编程的基本原则 软件工程 一个公认的、良好的编程风格可以减少编码的错误，减少读程序的时间，从而提高软件的开发效率。为了做到这一点，应该遵循下述一些原则： l源程序文档化 l数据说明：在编写程序时，要注意数据说明的风格。 l语句构造 ：构造的语句要简单、直接，不要为了提高效率而使语句更为复杂。 l输入和输出：输入／输出的方式和格式应当尽量作到对用户友好，尽可能方便用户的使用。 l效率：选择良好的设计方法才是提高程序效率的根本途径，设计良好的数据结构与算法，都是提高程序效率的重要方法。

11. 2. 编程的基本原则 软件工程 由于面向对象的程序设计语言所具有的特殊性，面向对象编程原则，除了遵循上述编程的基本原则之外，还包括为适应面向对象方法所特有的概念(如继承性)而必须遵循的一些新原则： l提高可重用性 l提高可扩充性 l提高健壮性 总之，在编码时要善于积累编程经验，培养和学习良好的编程风格，使程序清晰易懂，易于测试与维护，从而提高软件的质量。

12. 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系列等。

13. 4.2 软件测试概述 软件工程 Grenford J．Myers在《The Art Of Software Testing》一书中的观点常被许多人作为软件测试的目的或定义： l软件测试是为了发现缺陷而执行程序的过程。 l测试是为了证明程序中有错误，而不是证明程序中无错误。 l一个好的测试用例指的是它可能发现至今尚未发现的缺陷。 l一次成功的测试指的是发现了新的软件缺陷的测试。 测试的目的是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。测试只能尽可能多的查找出程序中错误，而不能证明程序中没有错误。

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

15. 4.2.1 软件测试的概念和原则 软件工程 1. 错误(error)、缺陷(fault)和故障(failure) 人们在进行软件开发的过程中犯了一个错，则称为一个错误(error)。应用到测试过程时，有两种不同的使用方式。在第—种使用方式中，错误是指一个实际测量值与理论预期值之间的差异，这种差异就是错误；第二种使用方式中，错误是指一些人的行为引起的软件中的某种故障，通常这些故障是由软件错误造成的。 缺陷(fault)常被称为bug，它是导致软件失败的一个条件。当开发人员犯了一个错，就会在软件中引人一个或多个缺陷。 故障(failure)又称失效，它是指软件不能按软件规格说明要求执行，从而引起软件行为与用户需求的不一致现象。失效可能发生在测试阶段，也可能发生在软件交付之后的运行阶段和维护阶段。 缺陷是开发人员所看到的软件系统的内部问题，而故障是用户从外部观察到的软件行为与软件需求的偏差。并不是每个软件缺陷都一定会导致软件发生故障，缺陷只有在满足某种条件的情况下才会导致软件故障。

16. 4.2.1 软件测试的概念和原则 软件工程 2. 软件测试的基本原则 l不完全原则 ：不完全原则表明测试是不完全的，穷举测试是不可能的。 l免疫性原则 ：软件缺陷具有免疫性，测试人员完成的测试越多，其免疫能力就越强，寻找更多软件缺陷也就更加困难。 l全程测试原则 ：全程测试原则要求软件测试不仅存在于完成程序之后，而应该跨越整个软件开发流程。 l80／20原则 ：80／20原则是指80％的软件缺陷存在于软件20％的空间里，软件缺陷具有空间聚集性。

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

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

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

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

21. 2.软件测试过程 软件工程 一个规范化的软件测试过程通常包括以下一些基本测试活动：制定软件测试计划、编制软件测试大纲、设计和生成测试用例、实施测试、生成软件问题报告。 通常可以将测试阶段划分成代码审查、单元测试、集成测试和系统测试4个阶段。 ①代码审查 代码审查是一种非常有效的程序验证技术，对于典型的程序来说，可以查出30%～70%的逻辑设计错误和编码错误。它是由审查小组通过阅读、讨论和争议对程序进行静态测试的过程。

22. 2.软件测试过程 软件工程 ②单元测试 单元测试就是对软件中的基本组成单位(如一个类、类中的一个方法、一个模块等)进行测试。因为需要知道程序内部设计和编码的细节，所以单元测试一般由程序员而非测试人员来完成。通过测试可发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。 ③集成测试 集成测试又称组装测试或联合测试。它是指在单元测试的基础上，将模块或组件按照设计要求组装起来同时进行测试，其主要目标是发现与接口有关的问题，即模块或组件之间的协调与通信。

23. 2.软件测试过程 软件工程 ④系统测试 集成完模块或组件后，系统测试是确保整个测试的软件系统与系统的功能和非功能性需求保持一致。为了完成这一目的，需要开展下面几种系统测试活动：功能测试、性能测试、验收测试、安装测试。 与软件开发过程相反，测试是从模块或组件开始，自底向上逐步集成的过程。代码审查主要是发现编码时产生的错误；单元测试主要是发现详细设计说明书或源程序代码的错误；集成测试发现的往往是概要设计中的错误或需求说明书中的错误；系统测试主要是发现需求说明书中的错误。因此软件测试就是对软件开发各阶段产生的错误进行检查，以便得到一个最终满足用户需要的软件系统。

24. 4.3 软件测试的策略 软件工程 4.3.1 单元测试 在单元测试时，由于被测试的模块或组件处于整个软件结构的某一层位置上，一般是被其它模块或组件调用或调用其它模块或组件，其本身不能单独运行，因此需要为被测模块或组件设计驱动程序和存根程序。所谓驱动程序也就是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块或组件，并且印出有关的结果。存根程序也称桩(stub)程序，它代替被测试的模块所调用的模块或组件。因此存根程序也可以称为“虚拟子程序”。 单元测试通常采用白盒测试对模块或组件进行彻底测试，然后辅之以黑盒测试使之对任何合理和不合理的输入都能鉴别和响应。所测模块、驱动程序和存根程序共同构成了一个模块“测试环境”。测试主要针对每个模块或组件的5个基本特征进行测试：模块或组件接口、局部数据结构、重要的执行通路、出错处理通路和影响上述各方面特性的边界条件等。

25. 4.3 软件测试的策略 软件工程 4.3.2 集成测试 在每个模块完成单元测试以后，需要按照设计时的结构图，把它们连接起来，进行集成测试。通常将模块连接成系统主要有两种方式：非渐增方式、渐增方式。 1.非渐增方式 不非渐增方式又称为一次性组装方式， 也称为大爆炸集成(Big-bang Integration)。这种方式是在所有模块进行了单元测试后，将所有模块按设计的结构图要求连接起来，连接后的程序作为一个整体来进行测试。 在一些很小型的软件项目中，可以使用非渐增方式进行系统集成测试，而在大型软件项目中，这种集成测试策略显然是不合适的。所以目前在进行集成测试时普遍采用渐增方式来进行测试。

26. 4.3.2 集成测试 软件工程 2.渐增方式 渐增方式又称增殖式组装方式。该方式是把下一个要测试的模块同已经测试好的模块连接起来进行测试，测试完以后再把下一个应该测试的模块连接进来测试。显然渐增方式的作法与非渐增方式不同。它的集成是逐步实现的，集成测试也是逐步完成的。当使用渐增方式把模块连接到程序中去，按不同的次序实施时有：自顶向下和自底向上两种策略可供选择。 ①自顶向下集成 自顶向下集成首先单独测试最顶层的模块或构件。最顶层的模块或构件一般是一个控制模块或构件，它可能调用其他还没有测试的模块或构件。因此，测试时需要为它编写存根程序代替所有直接附属于主控模块的模块。存根程序接受被测模块或构件的调用并且返回结果数据，以便测试能够进行下去。

27. 2.渐增方式 软件工程 • 自顶向下集成 在组装过程中，可以使用深度优先的策略或宽度优先的策略。深度优先的策略是首先集成一个主控路径下的所有模块，主控路径的选择具有任意性，它依赖于应用程序的特性。宽度优先的策略是将每一层中所有直接隶属于上层的模块集成起来测试。为了保证加入模块没有引进新的错误，可能需要进行回归测试。 所谓回归测试就是在对软件进行修改之后所进行的测试，其目的是检验对软件的修改是否正确。回归测试一般在软件维护阶段进行，但在软件开发和测试阶段也经常会用到。回归测试通常包括重新运行原有的测试数据。因此，需要弄清哪些测试数据与被修改部分有关。

28. 2.渐增方式 软件工程 • 自底向上集成 自底向上集成首先单独测试位于系统最底层的模块或构件，然后将最底层模块或构件与那些直接调用最底层模块或构件的上一层模块或构件集成起来一起测试。这个过程一直持续下去，直到将系统所有的模块或构件都集成起来，形成一个完整的软件系统进行测试。具体步骤如下： ①把低层模块组合成实现某个特定的软件子功能的功能集合。 ②写一个驱动程序(用于测试的控制程序)，协调测试数据的输入和输出。 ③ 对由模块组成的子功能集合进行测试。 ④ 去掉驱动程序，沿软件结构自下而上移动，把子功能集合组合起来形成更大的子功能集合。 ⑤ 重复②～④步。 自底向上集成测试一般适用于底层存在众多通用例行子程序、采用面向对象设计方法以及系统使用了大量单独的可重用模块的地方。

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

30. 4.3.3 系统测试 软件工程 系统测试的目的是保证所实现的系统确实是用户所想要的。为了到达此目的，需要完成一系列测试活动。这些活动包括功能测试、性能测试、验收测试、安装测试。 1. 功能测试 功能测试也称为需求测试，主要测试系统的功能性需求，找出功能性需求和系统之间的差异，即检查软件系统是否完成了需求规格中所指定的功能。功能测试主要使用黑盒测试技术。 2. 性能测试 性能测试主要测试系统的非功能性需求，找出非功能性需求和系统之间的差异，即检查软件系统是否完成了需求规格中所指定的非功能性要求，如安全性、计算精度、运行速度以及安全性等。性能测试期间要进行很多项测试活动，下面是主要的一些活动。

31. 4.3.3 系统测试 软件工程 2. 性能测试 • 强度测试 • 安全性测试 • 恢复测试 • 软件配置审查 • 兼容性测试 通过功能测试和性能测试后有下述两种可能的结果： ⑴ 功能和性能与用户要求一致，软件是可以接受的； ⑵ 功能和性能与用户要求有差距。 如出现⑴中的结果，则可进行以未来用户为主的验收测试。如出现⑵中的情况，则问题就比较复杂。在这个阶段发现的问题往往和需求分析阶段的差错有关，涉及面通常比较广，因此解决起来也比较困难。为了制定解决该测试过程中发现的软件缺陷或错误的策略，通常需要和用户充分协商。

32. 4.3.3 系统测试 软件工程 3.验收测试 验收测试的目的是使得未来的用户能够确认所开发的系统满足了他们的需求，并确实是他们所想要的系统。在此阶段开发人员提供必要的支持和帮助，由用户自己设计和运行测试数据，验收测试一般采用黑盒测试。验收测试的组织一般有三种方式：基准测试、典型测试和并行测试。 l基准测试 基准测试有一个很特殊的应用场合：用户具有明确的项目需求，为了降低开发风险，用户同时要求两个或两个以上的开发团队按照他们给出的一份相同的需求各自独立地开发系统。待各个系统开发完成之后，用户组织基准测试。首先，用户准备一个测试用例集合，这个集合代表了系统运行的典型情况。然后，用户在各个系统中运行每个测试用例，并就系统所实现的功能和性能情况作出评价。最后，基于基准测试的结果，用户选择购买其中的一个软件系统。

33. 3.验收测试 软件工程 l典型测试 它是在试用的基础上来运行系统，依赖于每天对系统的操作来测试各项功能。如果一个软件是为许多客户开发的（例如，向大众公开出售的盒装软件产品），那么，让每个客户都进行典型测试是不现实的。在这种情况下，绝大多数软件开发商都使用被称为Alpha测试和Beta测试的过程，来发现那些看起来只有最终用户才能发现的错误。 Alpha测试由用户在开发环境下进行的测试，并且在开发者对用户的“指导”下进行测试。开发者坐在用户旁边，负责记录发现的错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。

34. 3.验收测试 软件工程 Beta测试由软件的最终用户们在一个或多个用户的实际使用环境下进行的测试。与Alpha测试不同，开发者通常不在Beta测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户记录在Beta测试过程中遇到的一切问题（真实的或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。 • l并行测试 当新开发的系统是用来替代一个老系统时，常常采用并行测试方法。并行测试方法是将新系统和老系统并行运行，并行测试可以使得用户能够逐渐熟悉新系统的使用，可以验证用户指南和使用手册之类的文档，还能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。

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

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

37. 4.4 测试用例的设计 软件工程 4.4.1 白盒测试法用例的设计 白盒测试法设计用例的指导思想是选择测试用例集检验代码的内部结构是否正确，因此它是在清楚地知道了程序的内部结构和处理算法的基础上进行的测试用例设计。 1. 逻辑覆盖 所谓逻辑覆盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。逻辑覆盖要求对某些程序的结构特性做到一定程度的覆盖，或者说是“基于覆盖的测试”，即有选择地执行程序中某些最有代表性的通路。

38. 1. 逻辑覆盖 软件工程 • 语句覆盖 语句覆盖是指使用足够多的测试数据，使被测试程序中每个语句至少执行一次。 • 分支覆盖 分支覆盖又叫判定覆盖，是指设计出足够多的测试用例，使得被测程序中每个判定表达式都执行一次“真”和一次“假”，从而使程序的每一个分支至少都通过一次。 • 条件覆盖 条件覆盖要求不仅每个语句至少执行一次，而且使得判定表达式中每个条件的各种可能的值都至少执行一次。

39. 1. 逻辑覆盖 软件工程 • 判定-条件覆盖 判定-条件覆盖要求设计足够的测试用例，使得判定表达式中的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。 • 条件组合覆盖 条件组合覆盖它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少执行一次。 • 路径覆盖 路径覆盖就是要求设计足够多的测试数据，可以覆盖被测程序中所有可能的路径。

40. 入口 S A>1 AND B=0 T a X=X/A c F A=2 OR X>1 T b X=X+1 e F 返回 d 逻辑覆盖举例 软件工程 语句覆盖的测试用例是： 【{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的条件)

41. 逻辑覆盖举例 软件工程 判定-条件覆盖的测试用例是： 【{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的条件)

42. 2.基本路径测试 软件工程 使用这种技术设计测试用例时，首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合，从该基本集合导出的测试用例可以保证程序中的每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值。基本路径测试技术设计测试用例的步骤： 第一步：将详细设计结果或程序编码映射成程序控制结构图。 第二步：根据程序控制结构图计算程序的环形复杂度。 第三步：确定线性独立路径的基本集合。 第四步：设计测试用例，确保基本路径集中每条路径的执行。

43. 4.4.2 黑盒测试法用例的设计 软件工程 黑盒测试法用例的设计有等价类划分、边界值分析、错误推测等。根据这些方法来生成测试用例，可以提前到需求分析阶段或设计阶段。同时使用这些方法很可能发现白盒测试不易发现的其他类型的错误。 ①等价类划分 等价类划分的基本思想是将程序的所有可能输入数据(有效与无效的)划分为若干等价类。当程序输入数据集合的等价类确定以后，从每个等价类任取一组代表值就可以产生一个测试用例。等价类的划分有两种不同情况：

44. ①等价类划分 软件工程 • 有效等价类：是指对于软件的需求规格说明来说，是合理的、有意义的输入数据集合。 • 无效等价类：是指对于软件的需求规格说明来说，是不合理的、无意义的输入数据集合。 利用等价类划分产生测试用的具体步骤如下： 第一步：划分等价类。 第二步：设计测试用例。根据等价类设计测试用例时主要使用下面两个步骤： • 设计一个有效等价类的测试用例。对于各个输入条件，以尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤直到所有有效等价类都被覆盖为止； • 设计一个无效等价类的测试用例。使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类都被覆盖为止。注意因为在输入中有一个错误存在时，往往会屏蔽掉其它错误显示，所以设计无效等价类的测试用例时，一次只覆盖一个无效等价类。

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

46. 2. 边界值分析 软件工程 在等价类划分中，测试用例从各等价类中任意选取，没有考虑同一等价类中各组数据对于发现隐藏错误的差异。实践经验证明，程序往往在处理边界情况时会发生错误。如果将测试值选取在等价类的边界附近，可以期望得到高效的测试用例，可以查出更多的错误和问题。这就是边界值分析的出发点。 通常设计测试用例时总是联合使用等价类划分和边界值分析两种技术。一般先采用边界值分析设计测试用例，再用等价类划分补充之。

47. 2. 边界值分析 软件工程 典型边界值包括下面一些情况： l如果输入条件说明了输入值的范围，则应该在范围的边界上取值；另外还应该刚好越过边界的值作为无效情况的测试用例。 l如果输入条件指出了输入数据个数，则应为最小个数、最大个数、低于最小个数，高于最大个数分别设计测试用例。 l对于输出结果应该作类似于输入一样的处理。 l如果程序的输入输出数据是有序集合，则应该特别注意表中第一个、最后一个元素，以及集合中仅有1个元素的情况。 l对于输入输出为线性表的程序，应该考虑输入输出有0个、1个和可能的最大元素个数情况。

48. 3. 错误推测 软件工程 有经验的测试人员往往根据经验与直觉，推测程序中可能存在的各种错误，从而有针对性的编写检查这些错误的测试用例，实现高效的测试，这就是错误推测法。 对于测试对象中可能存在何种类型的错误，是挑选测试用例应该考虑的重要因素。推测的重要依据是程序设计规格说明书(或者代码的序言性注释)，不但要考虑它告诉了我们什么，还应该考虑说明中遗漏了什么，或者是否存在可能的冲突。

49. 测试用例设计小结 软件工程 在实际应用中通常以黑盒测试法设计测试用例为主，白盒测试法设计测试用例为辅。并可以考虑以下测试策略： l任何情况下都应该使用边界值分析设计测试用例； l必要时采用等价类划分法补充用例； l必要时再用错误推测法补充用例； l对照程序内部逻辑，检查已设计用例的逻辑覆盖。根据程序可靠性要求，补充用例使之达到规定的逻辑覆盖要求。

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