《软件工程》课件-第6章 软件编码和测试

第6章

软件编码和测试XX大学XX系XXX软件工程教程电子科技大学出版社学习目标l

了解编程语言的发展与分类；l

了解选择编程语言时所需考虑的因素；l

熟悉编程风格；l

理解软件测试的定义、目标和原则；l

掌握软件测试的各种分类；l

掌握软件测试过程的四个阶段；学习目标l

理解测试用例的定义和原则；l

掌握等价类划分、边界值分析、因果图等黑盒软件测试用例设计方法；l

掌握逻辑覆盖、基本路径测试、程序插桩等白盒软件测试用例设计方法；l

掌握黑盒和白盒测试方法应用策略；l

熟悉软件调试过程和策略。目录01020304程序设计语言程序设计风格软件测试软件测试分类0506软件测试过程软件测试用例定义目录07080910黑盒测试用例设计白盒测试用例设计软件测试方法应用策略软件调试11本章小结程序设计语言01程序设计语言◆

编码的过程就是把软件设计阶段得到的解决方案转化为可以在计算机上运行的软件产品的过程。◆

选择合适的编程语言是编码过程的关键。◆

编程语言是人与计算机交流的重要工具。对于软件开发人员而言，编程语言是除了计算机本身之外的所有工具中最重要的。◆

编程语言是定义了一组计算机的语法规则，通过这些语法规则可以把人的意图、思想等转化为计算机可以理解的指令，进而让计算机帮助人类完成某些任务。程序设计语言①

机器语言◆

最早的编程语言是机器语言，它是计算机可以识别和执行的指令代码。◆

机器语言采用“0”和“1”为指令代码来编写程序，它可以直接被计算机的CPU识别，从而操纵计算机硬件的运行。◆

因为机器语言直接操纵底层硬件，所以其执行速度较快，但是程序员必须熟悉计算机的全部指令代码和代码的含义。◆

机器语言具有“面向机器”的特点，它不能直接在不同体系结构的计算机间移植。程序设计语言②

汇编语言◆

像机器语言一样，汇编语言也是一种“面向机器”的低级语言。它通常为特定的计算机或系列计算机专门设计，可高效地访问和控制计算机的各种硬件设备。◆

汇编语言采用一组助记符来代替机器语言中晦涩、难懂的二进制代码，用地址符号或标号来代替地址码，使得代码比较直观，容易被程序员理解。◆

汇编语言必须由特定的翻译程序转化为相应的机器语言才能由计算机执行，把汇编语言转换为机器语言的过程称为汇编，相应的翻译程序就是汇编程序。程序设计语言③

高级语言◆

高级语言采用类似英文的语句来表示语义，更加方便了软件开发人员的理解和使用。◆

高级语言不再依赖于特定的计算机硬件，所以移植性较强，同种高级语言可以用在多种型号的计算机上。◆

一些高级语言是面向过程的，比如FORTRAN、COBOL、ALCOL和BASIC。还有一些高级语言是面向对象的，以C++语言为典型代表，这类语言与面向过程的高级语言有着本质的区别。程序设计语言④

超高级语言第四代语言是超高级语言，它是对数据处理和过程描述的更高级的抽象，一般由特定的知识库和方法库支持，比如，与数据库应用相关的查询语言、描述数据结构和处理过程的图形语言等，它们的目的在于直接实现各种应用系统。程序设计语言在选择编程语言时，通常需考虑以下七个因素。①待开发系统的应用领域，即项目的应用范围。②用户的要求。③将使用何种工具进行软件开发。④软件开发人员的喜好和能力。⑤软件的可移植性要求。⑥算法和数据结构的复杂性。⑦平台支持。程序设计语言◆

软件需求分析阶段和系统设计阶段所产生的文档，都不能直接在计算机上执行。只有完成了程序设计、产生可执行代码后，才能使系统的需求真正实现。◆

软件系统的分析和设计是程序设计(编码)的前导，实践表明，编码中出现的问题主要是由设计中存在的问题引起的。因而我们主张在编码之前进行分析、设计，尽可能在编码之前保证设计的正确性、高质量。程序设计语言结构化程序设计(Structured

Programming，SP)有三个基本特点。（1）结构化程序设计采用自顶向下、逐步求精的程序设计方法。（2）结构化程序设计的定义是：只使用顺序、选择和循环三种基本控制结构来构造程序。这三种基本结构的共同特点是每个代码块只有一个入口和一个出口。结构化程序设计主张以容易理解的形式和避免使用GOTO语句等原则进行程序设计。（3）采用主程序员组的组织形式。用经验多、能力强、技术好的程序员作为主程序员。程序设计风格02程序设计风格◆

程序不只是给机器执行的，也是供人阅读的。在软件生存期中，人们经常要阅读程序。特别是在软件”测试阶段和维护阶段，编写程序的人和参与测试、维护的人都要阅读程序。◆

阅读程序是软件开发和维护过程中的一个重要组成部分，而且读程序的时间比写程序的时间还要多。程序设计风格（1）源程序文档化源程序文档化包括标识符的命名、安排注释以及程序的视觉组织等。”1）标识符的命名标识符包括模块名、变量名、常量名、标号名、子程序名以及数据区名、缓冲区名等，这些名字应能反映它所代表的实际东西，使其能够见名知意，有助于对程序功能的理解。程序设计风格2）程序的注释正确的注释能够帮助读者理解程序，为测试和维护提供明确的指导，注释绝不是可有可无的。注释分为序言性注释和功能性注释。”序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。功能性注释嵌入在源程序体中，用以描述其后的语句或程序段，也就是解释下面要“做什么”或是执行了下面的语句会怎么样。程序设计风格序言性注释做了明确而严格的规定，要程序编制者列出:①程序(模块)标题；②有关本模块功能和目的的说明；③主要算法；”④

接口说明，包括调用形式、参数描述、子程序清单；程序设计风格⑤

有关数据描述，包括重要的变量及其用途、约束或限制条件，以及其他有关信息；⑥

模块位置，说明在哪一个源文件中，或隶”属于哪一个软件包；⑦

开发简历，包括模块设计者、复审者、复审日期、修改日期及有关说明等。程序设计风格书写功能性注释，要注意以下三点。①用于描述一段程序，而不是每一个语句；”②用缩进和空行，使程序与注释容易区别；③注释要正确。程序设计风格3）视觉组织——空格、空行和移行①

空格：恰当地利用空格，可以突出运算的优先性，避免发生运算错误；”②空行：自然的程序段之间可用空行隔开；③

移行：移行也叫做向右缩格。它是指程序中的各行不必都左端对齐，都从第一格起排列。程序设计风格序言性注释做了明确而严格的规定，要程序编制者列出:①程序(模块)标题；②有关本模块功能和目的的说明；③主要算法；”④

接口说明，包括调用形式、参数描述、子程序清单；程序设计风格⑤

有关数据描述，包括重要的变量及其用途、约束或限制条件，以及其他有关信息；⑥

模块位置，说明在哪一个源文件中，或隶”属于哪一个软件包；⑦

开发简历，包括模块设计者、复审者、复审日期、修改日期及有关说明等。程序设计风格（2）数据说明标准化为了使程序中数据说明更易于理解和维护，在编写程序时，需要注意数据说明的风格。具”体需要注意以下几点：①

数据说明的次序应当规范化，使数据属性容易查找，也有利于测试、排错和维护。程序设计风格②

在类型说明中还可进一步要求，例如，可按如下顺序排列，整型量说明、实型量说明、字符量说明和逻辑量说明。”③

当多个变量名用一个语句说明时，应当对这些变量按字母顺序排列。④

对于复杂的数据结构，应当使用注释对其进行说明。程序设计风格（3）语句结构简单化①

在一行内只写一条语句，并且采取适当的移行格式，使程序的逻辑和功能变得”更加明确②

程序编写首先应当考虑清晰性，不要刻意追求技巧性，使程序编写得过于紧凑；程序设计风格③

程序编写要简单、清楚，直截了当地说明程序员的用意；④

除非对效率有特殊的要求，否则程序编写”的原则是清晰第一，效率第二，不要为了追求效率而丧失了清晰性；⑤避免使用临时变量而使可读性下降；程序设计风格⑥让编译程序做简单的优化；⑦尽可能使用库函数；”⑧

避免不必要的转移，如果能保持程序的可读性，则不必用GOTO语句；程序设计风格⑨

尽量只采用3种基本的控制结构来编写程序，除顺序结构外，使用if

else来实现选择结构；使用do-until或do-while来实现循环结构；”⑩避免使用空的else语句和ifthenif语句；⑪

避免采用过于复杂的条件测试。⑫

尽量减少使用“否定”条件的条件语句。程序设计风格（4）输入/输出规范化输入/输出信息是与用户的使用直接相关的。”输入/输出的方式和格式应当尽可能方便用户使用，避免因设计不当给用户带来麻烦。程序设计风格在设计和程序编码时都应考虑下列原则。①

对所有的输入数据都进行检验，从而识别错误输入，以保证每个数据的有效性；”②

检查输入项的各种重要组合的合理性，必要时报告输入状态信息；③

使得输入的步骤和操作尽可能简单，并保持简单的输入格式；程序设计风格④输入数据时，应允许使用自由格式输入；⑤应允许缺省值；”⑥

输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；程序设计风格⑦

在以交互式输入/输出方式进行输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围，同时，在数据输入的过程中和输入结束时，也要在屏幕上给出信息；”状态⑧

当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句的要求一致；⑨给所有的输出加注解，并设计输出报表格式。软件测试03软件测试◆

软件测试(Software

Testing)是软件工程过程的一个重要阶段,在软件投入运行前，对软件需求分析、设计和编码各阶段产品的最终检查，是为了保证软件开发产品的正确性、完全性和一致性，从而进行检测错误和修正错误的过程。◆

软件开发的目的是开发出满足用户需求的高质量、高性能的软件产品，而软件测试以检查软件产品内容和功能特性为核心，是软件质量保证的关键步骤，也是成功实现软件开发目标的重要保障。◆

软件测试的过程就是发现并改正软件缺陷的过程。软件测试在1990年颁布的软件工程标准术语集中沿用了这一定义，它非常明确地提出了软件测试是以检验软件是否满足需求为目标，包含两个方面的含义。（1）软件是否满足规定的需求；（2）软件是否有差别。如果有差别，说明设计或实现过程中存在故障，自然不满足规定的需求。近年来，也有学者从软件测试的不同阶段定义软件测试，如图6.1所示。软件测试从图6.1可以看出，软件测试历经了三个主要阶段。第一阶段，软件测试是寻找产品中的Bug。Bug的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都是Bug,即使这个Bug在实践中是可行的。第二阶段，软件测试是对软件质量的度量。第三阶段，软件测试是为了度量和提高被测试软件的质量，对软件测试进行设计，使用和维护的过程。软件测试◆

软件测试贯穿于软件生存周期的全过程。软件交付后，软件测试只是从软件测试人员移到用户，用户每次使用程序都是一次软件测试，软件测试是一门技术，是一个从实践到理论再由理论到实践循环往复的过程。◆

以下是G.J.Myers在《软件测试技巧》一书中对测试提出的规则，可看作软件测试的目标。①测试是为了发现程序中的错误而执行程序的过程。②好的测试方案能够发现尚未发现的错误。③成功的测试是发现了尚未发现的错误的测试。软件测试综合软件测试的定义和目标，我们可以将软件测试的主要作用总结如下:①测试是执行一个系统或者程序的操作；②测试是带着发现问题和错误的意图来分析和执行程序的；③测试结果可以检验程序的功能和质量；④测试可以评估软件项目产品是否达到预期目标和是否能被客户接受；⑤测试不仅包括执行代码，还包括对需求等编码以外东西的测试。软件测试在软件测试过程中，通常应该遵循以下七个原则。①所有的测试都应追溯到用户需求。②应尽早地和不断地进行软件测试。③

在有限的时间和资源下进行完全测试并找出软件所有的错误和缺陷是不可能的，软件测试不能无限进行下去，应适时终止。④

测试只能证明软件存在错误，而不能证明软件没有错误。测试无法显示潜在的错误和缺陷，继续进一步测试可能还会找到其它错误和缺陷。软件测试⑤充分关注测试中的集群现象。在测试的程序段中,若发现的错误数目比较多，则残存在该程序段中的错误数目也会比较多,因此应当花较多的时间和代价测试那些具有更多错误数目的程序模块。⑥程序员应避免检查自己的程序。⑦尽量避免测试的随意性。软件测试是有组织、有计划、有步骤的活动，要严格按照测试计划进行,要避免测试的随意性。软件测试分类04软件测试分类◆

按测试方式分类：（1）静态测试(Static

Testing)不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。（2）动态测试(Dynamic

Testing)通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。软件测试分类◆

按测试方法分类：（1）白盒测试(White-box

Testing)白盒测试又称结构测试或逻辑驱动测试，指通过对程序内部结构的分析、检测来寻找问题。白盒测试把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件的内部动作是否按照设计说明的规定正常进行。软件测试分类（2）黑盒测试(Black-box

Testing)黑盒测试又称功能测试或数据驱动测试，指通过软件的外部表现来发现缺陷和错误。黑盒测试把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。软件测试分类任何工程产品都可以使用以下两种方法之一进行测试：①

已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。②

已知产品的功能设计规格，可以通过测试证明每个实现了的功能是否符合要求。前者是白盒测试，后者是黑盒测试。表6.2给出了两种方法的一个基本比较：如表6.2所示，白盒测试和黑盒测试各有侧重点，不能相互取代，在实际测试活动中，这两种测试方法不是截然分开的。通常在白盒测试中交叉着黑盒测试，黑盒测试中也交叉着白盒测试。软件测试分类（3）灰盒测试（Grey-box

Testing）灰盒测试是介于白盒测试和黑盒测试之间的测试方法，它关注输出对于输入的正确性，同时也关注内部表现，但是不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件和标志来判断内部的运行状态。有时候输出是正确的，但是程序内部已经是错误的，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此，可采取灰盒测试这种方法。灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境。软件测试分类◆

按测试过程分类（1）单元测试（Unit

Testing）单元测试又称模块测试、逻辑测试或结构测试，是针对软件设计的最小单位——程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验每个程序单元能够正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各个模块内部可能存在的各种错误。软件测试分类（2）集成测试（Integration

Testing）集成测试又称组装测试、综合测试或联合测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。软件测试分类（3）系统测试（System

Testing）系统测试为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括计算机硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。系统测试的主要依据是《系统需求规格说明书》文档。软件测试分类（4）验收测试（Acceptance

Testing）验收测试又称交付测试，是软件在完成了单元测试、集成测试、系统测试之后，产品发布之前进行的软件测试活动。验收测试又分为Alpha测试（α测试）和Beta测试（β测试），Alpha测试是由一个用户在开发环境下进行的测试，或者是公司内部的用户在模拟实际操作环境下进行的受控测试，Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。软件测试分类（1）功能测试（Functional

Testing）功能测试主要针对产品需求规格说明书对软件进行测试，逐项验证软件功能是否符合要求，包括对原定功能的检验以及测试软件是否有冗余功能、遗漏功能。（2）接口测试（Interface

Testing）接口测试指对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。在接口测试中，测试人员在单元测试阶段进行一部分工作，大部分工作在集成测试阶段完成。软件测试分类（3）用户界面测试（Interface

Testing）用户界面测试主要检查用户界面的风格是否满足客户的要求、界面是否友好、软件是否方便易用、系统设计是否合理、界面位置是否正确等问题。（4）健壮性测试（Interface

Testing）健壮性测试侧重于对程序容错能力的测试，主要是验证程序在各种异常情况下是否能正确运行，包括数据边界测试、非法数据测试、异常中断测试等。软件测试分类（5）性能测试（Performance

Testing）性能测试主要测试系统的性能是否满足用户要求，即在特定的运行条件下验证系统的能力状况。性能测试主要是通过自动化测试工具模拟正常、峰值以及异常负载状况，对系统的各项性能指标进行测试，测试中得到的负荷和响应时间等数据可以被用于验证软件系统是否能够达到用户提出的性能指标。软件测试分类（6）强度测试（Strength

Testing）强度测试是一种性能测试，强度测试总是迫使系统在异常的资源配置下运行，目的是找出因资源不足或资源争用而导致的错误，例如，如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷，这些缺陷可能由于争用共享资源（如数据库锁或网络带宽）而显现出来。软件测试分类（7）压力测试（Stress

Testing）压力测试是一种性能测试，指在超负荷环境中，检验程序是否能够正常运行，检验系统的稳定性。压力测试的目的是检测系统在资源超负荷情况下的表现，是通过极限测试方法，发现系统在极限或恶劣环境中的自我保护能力。压力测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，压力测试还要评估软件的性能特征，例如响应时间、事务处理速率和其他与时间相关的性能特征。软件测试分类（8）负载测试（Load

Testing）负载测试是一种性能测试，是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。软件测试分类（9）安全性测试（Security

Testing）安全测试主要测试系统防止非法侵入的能力，例如，测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何运行，是否能够保证数据的安全。软件测试分类（10）可靠性测试（Reliability

Testing）可靠性测试是指在真实的或仿真的环境中，为了保证和验证软件的可靠性水平是否满足用户的要求而进行的测试，即确定软件是否满足软件规格说明书中规定的可靠性指标。软件可靠性测试的目的是给出可靠性的定量估计值，通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，验证软件可靠性是否达到要求。软件可靠性测试是一项高投入的测试工作，通常需要进行大量的测试。软件测试分类（11）恢复测试（Restore

Testing）恢复测试主要测试当出现系统崩溃、硬件错误或其他灾难性问题时系统的表现情况，以及系统从故障中恢复的能力。（12）安装/卸载测试（Install/Uninstall

Testing）安装测试主要检验软件是否可以正确安装，安装过程是否符合安装规程，安装文件的各项设置是否有效，安装后是否影响整个计算机系统；卸载测试是逆过程，测试软件是否被删除干净，删除后软件是否影响整个计算机系统等。软件测试分类（13）兼容性测试（Compatibility

Testing）兼容性测试主要测试软件产品在不同的平台、不同的工具软件或相同工具软件的不同版本下的兼容性，其目的是测试系统与其他软件、硬件兼容的能力。（14）文档测试（Documentation

Testing）文档测试主要检查内部/外部文档的清晰性和准确性，对外部文档而言，测试工作主要针对用户的文档，以需求说明、用户手册、安装手册等为主，检验文档是否和实际应用存在差别，而且还必须考虑文档是否简单明了，相关的技术术语是否解释清楚等问题。软件测试过程05软件测试过程◆

根据软件测试过程分类，软件测试工作可以分为单元测试、集成测试、系统测试和验收测试。这些测试工作是按照图6.2中所示的顺序逐项进行的。◆

单元测试是对软件中的基本组成单位进行的测试，验证每个模块是否满足系统设计说明书的要求。◆

集成测试是将已测试过的模块组合成子系统，重点测试各模块之间的接口和联系。软件测试过程◆

系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求。◆

验收测试是根据需求规格说明书中定义的全部功能和性能要求，确认软件是否达到了要求。软件测试过程◆

单元测试也称模块测试，其目的是集中检验软件设计的最小单元--模块，检查每个模块是否能独立、正确地运行。◆

在这个阶段所发现的错误往往是在编码和详细设计时产生的，通常在编码阶段就应该进行单元测试。◆

单元测试通常采用白盒测试方法，而且对多个模块的测试可以并行地进行。软件测试过程（1）单元测试的主要任务①程序语法检查通过编译语言对程序进行检查；人工检查。②程序逻辑检查检查程序的逻辑结构是否正确；程序中所使用的循环语句的上下项以及循环次数是否有问题；函数或子模块是否有自我调用问题。软件测试过程③模块接口测试模块接口测试是单元测试的第一步，前两个任务只是程序走查。模块接口是模块内与模块外联系的关键部位，是保证模块间高内聚低耦合的关键。④局部数据结构测试局部数据结构测试是为了保证临时存储模块在模块内的数据。模块错误的根源往往是局部数据结构。软件测试过程⑤路经测试对模块中的重要执行路径进行测试，路径错误主要是由错误的计算，不正确的比较或不正常的控制流导致。⑥边界条件测试边界测试执行的好，可以大大提高程序的质量。⑦错误处理。利用测试，查找错误。⑧代码书写规范检查。软件测试过程（2）单元测试特点①它是一种验证行为②它是一种设计行为③它是一种编写文档的行为④它具有回归性⑤提升反馈速度，减少重复工作，提高开发效率⑥保证最后的代码修改不会破坏之前代码的功能⑦让代码维护更容易⑧有助于改进代码质量和设计软件测试过程单元测试常常和代码编写同步进行,在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。辅助模块有两种，一种是驱动模块(

Driver)，用以模拟被测模块的上级模块。驱动模块在单元测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。另一种是被调用模拟子模块(Sub)，用以模拟被测模块工作过程中所调用的模块。被调用模拟子模块由被测模块调用,它们一般只进行很少的数据处理。软件测试过程◆

集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。一般使用黑盒测试方法测试集成的功能，并且对以前的集成进行回归测试。◆

集成测试关注的是组装系统或者子系统的各个软件单元之间的交互，测试的主要任务是发现软件单元之间的接口、接口之间的数据传递关系和其它与接口有关的各种错误，以及各个软件单元组合后是否实现预期的功能。软件测试过程（1）集成测试任务①将各个软件单元组装起来时，各个软件单元在通过接口进行数据交互的时候，数据是否会发生丢失的情况；②将各个软件单元组装成系统或者子系统时，能否达到预期设计的各项功能要求；③某一个软件单元的功能会不会对其它的软件模块产生不良的影响；④全局数据结构是否有问题，是否会被不正常修改；⑤每个软件单元所产生的误差累积起来，是否会被放大，从而造成整个系统的误差达到不能接受的程度。软件测试过程为了保证在进行集成测试的时候，能够很好地完成测试工作，应该遵循以下11个基本原则：①所有的公共接口都要被测试到；②所有的关键模块必须进行充分的测试；③集成测试应当按照一定的层次进行；④

集成测试的策略选择应当综合考虑质量、成本和进度之间的关系；⑤集成测试应当尽早开始，并以总体设计为基础；⑥

在模块和接口的划分上，测试人员应当和开发人员进行充分的沟通；软件测试过程⑦

当测试计划中的结束标准满足时，集成测试才能结束；⑧

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

集成测试应该根据集成测试计划和方案进行，不能随意测试；⑩项目管理者应该保证测试用例经过审核；⑪

测试执行结果应当如实记录。软件测试过程（3）集成测试方法一般集成测试有两种方法，一种方法是分别测试各个模块，再把这些模块组合起来进行整体测试，这种方法称为非增量集成。另一种方法是把一个要测试的模块组合到已测试好的模块中，测试完后再将一个需要测试的模块组合进来测试，逐步把所有模块组合在一起，并完成测试，该方法称为增量集成。软件测试过程1）非增量集成非增量集成可以对模块进行并行测试，能充分利用人力，加快工程进度。但这种方法容易混乱，且错误不容易被查找和定位。增量集成测试的范围是一步步扩大的，因此，错误容易定位，而且已测试的模块可在新的条件下进行测试，程序测试得更彻底。软件测试过程例6.1：图6.4所示为采用非增量集成测试的一个实例，被测试程序的结构如图6.4a）所示，它由七个模块组成。在进行单元测试时，根据它们在结构图中的位置，对模块C和D配备了驱动模块和被调用模拟子模块。对模块B、E、F、C配备了驱动模块。主模块A由于处于结构图的顶端，无其他模块调用它，因此仅为它配备了三个被调用模拟子模块，以模拟被它调用的3个模块B、C、D，如图6.4b）至图6.4h）所示，分别进行单元测试后，再按图6.4a）所示的结构图形式连接起来进行集成测试。软件测试过程非增量集成测试的优点如下。①

非增量集成测试可以并行地测试所有的软件单元，能够加快测试工作的速度，充分利用了人力和物力资源；②

非增量集成测试需要用到测试用例数量较少，因此，对设计测试用例的工作量相对较小；③

非增量集成测试的测试方法较为简单，容易执行。软件测试过程非增量集成测试的缺点如下。①

非增量集成测试是将软件单元一次性集成起来，如果集成的软件单元数量较多，集成测试过程中可能会出现较多的错误，而且因为一次性集成，很难判断出现错误的位置。而且，在对某个软件单元的某处错误进行修改之后，可能会在系统的其它地方带来新的错误，这样给整个系统的修正会带来较大的难度；②

非增量集成测试因为是一次性集成，各个软件单元之间的接口没有进行充分的测试，因此，有可能会遗漏一些潜在的接口错误，即使在集成测试通过，这些接口可能也会存在问题。软件测试过程2）增量集成测试①

自顶向下的增量集成测试方式自顶向下的增量集成测试是模块按程序的控制结构，从上到下的组合方式。在增量集成测试时，有深度优先和广度优先两种策略。深度优先策略首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的，一般根据问题的特性来确定。广度优先策略首先沿着水平方向，把每层中所有直接隶属于上一层的模块集成起来，直至最底层。图6.5为自顶向下的深度优先增量集成测试过程。软件测试过程自顶向下的增量集成测试的优点如下。①

在集成测试的过程当中，可以首先验证主要的控制和判断点，即主控软件单元，在功能划分合理的程序模块结构中，对于较高层次中的主控软件单元，可以首先做出测试，能够提前发现问题，以便及时对程序作出相应的修改，减少人力资源消耗；②

选择深度优先的集成方式，可以首先实现和验证一个完整的软件功能，能够首先对逻辑输入的分支进行组装和测试，检测出潜在的错误和缺陷，验证其功能的正确性，为之后的主要分支的组装和测试提供保证③

能够较早的验证软件功能的可用性，给软件的开发者和软件的用户奠定了信心；软件测试过程自顶向下的增量集成测试的缺点如下。①

采用自顶向下的增量集成测试方法，在测试时需要给每个软件单元的下层软件单元设计开发测试用被调用模拟子模块，对于被调用模拟子模块的开发以及维护成本较大；②

在当底层的软件单元的发生变更时，可能会需要修改整个软件系统中的多个上层软件单元，进而容易破坏之前已经构造好的测试包；③

随着自顶向下增量集成测试的进行，新的底层软件单元不断加入，这会让整个系统的会变得越来越复杂，这可能会导致之后加入的底层软件单元的测试不够充分。软件测试过程②

自底向上的增量集成测试方式自底向上的增量集成测试方式是从最底层的功能模块开始，边组合边测试，从下向上地完成整个程序结构的测试。在单元测试的基础上，从最底层模块开始，按功能组合模块，从下而上地进行测试。这样的测试方式可以较早地发现底层关键性模块出现的错误。在测试时不需要编写被调用模拟子模块，但需要驱动模块。另外，对程序中的主要控制错误发现较晚。图6.6所示为自底向上的增量集成测试过程。软件测试过程自底向上的增量集成测试的优点如下。①能够尽早验证底层软件单元的功能。任何一个底层软件单元通过单元测试之后，就可以开始进行集成测试；②在集成测试开始时，可以同时对系统层次结构中的每个分支集成测试，这样较大提高了测试的效率；③减少了设计开发测试用被调用模拟子模块的工作量；④更容易对被测系统的错误进行定位。软件测试过程自底向上的增量集成测试的缺点如下。①

只有在被测系统的最顶层的最后一个软件单元组装起来之后才能看到整个系统的框架；②测试用驱动模块的开发以及维护工作量大；③

由于顶层的软件单元要到集成测试的最后阶段才能进行测试，因此不能及时发现高层模块设计上的错误，对于那些在整个体系结构中控制结构非常关键的产品来说，受到的影响就更大。软件测试过程3）“三明治”集成测试方法“三明治”集成（也称为混合测试方法）是一种混合增量集成测试方法，综合了自顶向下和自底向上两种集成方法的优点。“三明治”集成测试方法的基本步骤如下:①确定以哪一层作为运用“三明治”集成测试方法的分界层②

对分界层及其所在层下面的各个层次使用自底向上的集成测试方法③对分界层上面的各个层次使用自顶向下的集成测试方法④对被测系统进行整体测试。软件测试过程“三明治”集成测试的优点如下。①

同时具有自顶向下集成测试和自底向上集成策略的优点；②

通过一定集成技巧，可以减少被调用模拟子模块和驱动模块的开发。“三明治”集成测试的缺点如下：在被集成之前，中间层不能够尽早得到充分的测试。软件测试过程系统测试是在真实系统工作环境下或系统仿真环境下检验完整的软件配置项能否和系统正确连接，并满足系统设计文档的要求。系统测试原则表现在如下两个方面。（1）独立性原则（2）全面性原则软件测试过程（1）功能测试功能测试是系统测试中最基本的测试，它不管软件内部是如何实现的，而只是根据需求规格说明书和测试需求列表，验证产品的功能是否符合需求规格。（2）性能测试性能测试用来测试软件系统在实际的集成系统中的运行性能。（3）安装测试安装测试用来确保软件在正常情况和异常情况的不同条件下都不丢失数据或者功能，具体测试活动包括首次安装、升级、完整安装、自定义安装和卸载等。软件测试过程（4）可用性测试所谓可用性测试，即是对软件的“可用性”进行测试，检验其是否达到可用性标准。（5）压力测试压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单，不是在常规条件下运行手动或自动测试，而是长时间或超大负荷地运行测试软件来测试被测系统的性能、可靠性和稳定性等。软件测试过程（6）容量测试在进行压力测试时，如果发现了被测系统在可接受的性能范围内的极限负载，则在一定程度上完成了容量测试。容量测试的完成标准可以定义为：所计划的测试已全部执行，而且达到或超出指定的系统限制时没有出现任何软件故障。（7）安全性测试安全性测试的目的是验证系统的保护机制是否能够在实际的环境中抵御非法入侵、恶意攻击等非法行为。软件测试过程（8）健壮性测试健壮性是指在故障存在的情况下，软件还能正常运行的能力。（9）图形用户界面测试图形化用户接口(GraphicUser

Interface，GUI)测试包含两方面内容，一是界面实现与界面设计是否吻合；二是界面功能是否正确。（10）文档测试文档的种类包括开发文档、管理文档和用户文档。这三类文档中，一般主要测试的是用户文档。软件测试过程◆

验收测试应检查软件能否按合同要求进行工作，即是否满足需求规格说明书中的验收标准。验收测试包括功能确认测试、安全可靠性测试、易用性测试、可扩充性测试、兼容性测试、资源占用率测试、用户文档资料验收等一些测试工作。通过验收测试后，才能成为可交付的软件。◆

验收测试的结果有两种可能，一种是功能和性能指标满足需求规格说明书的要求，用户可以接受；另一种是软件不满足需求规格说明书的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此，必须与用户协商，寻求一个妥善解决问题的方法。软件测试过程（2）配置评审确认测试的另一个重要环节是配置评审。评审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必需的细节。（3）α、β测试事实上，软件开发人员不可能完全预见用户实际使用软件情况。软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。一个软件产品可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。软件测试过程◆

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部人员模拟各类用户行为对即将面市的软件产品(称为α版本)进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为α版本。◆

β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后，软件开发公司再对β版本进行改错和完善。软件测试过程回归测试（Regression

Testing）是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。虽然已发现的程序缺陷被修复了，但可能在其他受影响的区域出现新的软件缺陷，这样的缺陷称为回归缺陷。如果这时没有回归测试，产品就带着这样的回归缺陷被发布出去了，就会造成严重的后果。回归测试就是为了发现回归缺陷而进行的测试。软件测试过程回归测试是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法，因为这时的测试不一定要进行全面测试，而是根据修改的情况进行有效测试。（1）回归测试的测试目的①

测试软件变更之后，变更部分的正确性和对变更需求和符合性；②

测试软件变更之后，软件原有的、正确的功能、性能和其他规定的要求的不损害性。软件测试过程（2）回归测试的对象①

未通过软件单元测试的软件，在变更之后，应对其进行单元测试；②

未通过软件配置项测试的软件，在变更之后，首先应对变更的软件进行单元测试，然后再进行相关的集成测试和配置项测试；③

未通过系统测试的软件，在变更之后，首先应对变更的软件进行单元测试，然后再进行相关的集成测试、软件配置项和系统测试；④

因其他原因进行变更之后的软件单元，首先应对变更的软件进行单元测试，然后再进行相关的软件测试。软件测试用例定义06软件测试用例定义◆

测试用例作为测试工作的指导，是软件测试必须遵守的准则，是软件测试质量稳定的根本保障。◆

比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。◆

测试用例将软件测试的行为活动做了一个科学化的组织归纳，目的是将软件测试的行为转化成可管理的模式，同时测试用例也是将测试具体量化的方法之一。软件测试用例定义设计测试用例时，应遵循以下原则。（1）基于测试需求的原则按照测试类别的不同要求设计测试用例。（2）用成熟测试用例设计方法来指导设计在设计测试用例时，不能只凭借一些主观或直观的想法来设计测试用例，应该要以一些比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例，将测试设计思想与丰富的实践经验相融合才能设计出高品质的测试用例。软件测试用例定义（3）兼顾测试充分性和效率的原则测试用例集应兼顾测试的充分性和测试的效率；测试用例的内容都应完整，具有可操作性。（4）测试执行的可再现性原则应保证测试用例执行的可再现性。（5）足够详细、准确和清晰的步骤即使是一个对所要测试的内容根本不了解的新手，也能准确的按照所写的测试用例完成测试。软件测试用例定义在设计测试用例时应避免如下五个方面的问题。（1）把测试用例设计等同于测试输入数据的设计。（2）强调测试用例设计的越详细越好。（3）追求测试用例设计“一步到位”。（4）将多个测试用例混在一个用例中。（5）让没有测试经验的人员设计测试用例。黑盒测试用例设计07黑盒测试用例设计等价类划分法是一种重要的、典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，而是只根据程序规格说明书对输入范围进行划分。等价类划分法的原理是把所有可能的输入数据，即程序的输入域划分成若干互不相交的子集，称为等价类。所有子集的并集则构成整个输入域。然后，从每一个子集中选取少量具有代表性的数据作为测试用例。因此，等价类对于测试有完备性和无冗余性两个重要的意义。黑盒测试用例设计等价类按照其有效性可以分为两种，有效等价类和无效等价类。①

有效等价类。对于程序规格说明而言，由合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中预先规定的功能和性能。②

无效等价类。对于程序规格说明而言，由不合理的、无意义的输入数据构成的集合。利用无效等价类可检验程序是否有不符合规格说明中预先规定的功能和性能。对于具体的问题，无效等价类至少应有一个，也可能有多个。黑盒测试用例设计常见的划分原则如下：①

在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类。②

输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。③

在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。④

在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。黑盒测试用例设计⑤

在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。⑥

在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类。在确立了等价类后，可建立等价类表，列出所有划分出的等价类，如表6.5所示。同时，也可以根据输出条件，列出输出域值的等价类，如表6.6所示。表6.6等价类表（输出条件）表6.5等价类表（输入条件）黑盒测试用例设计等价类划分法设计测试用例的步骤如下：1）分析并确定等价类2）建立等价类表，列出所有划分出的等价类3）根据列出的等价类表，按照以下三个步骤设计测试用例①为每一个等价类规定一个唯一的编号。②

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

设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类。重复这一步骤，直到所有的无效等价类都被覆盖为止。黑盒测试用例设计等价类划分法设计测试用例的步骤如下

：1）分析并确定等价类2）建立等价类表，列出所有划分出的等价类3）根据列出的等价类表，按照以下三个步骤设计测试用例①为每一个等价类规定一个唯一的编号。②

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

设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类。重复这一步骤，直到所有的无效等价类都被覆盖为止。黑盒测试用例设计例6.2：城市的电话号码由两部分组成。这两部分的名称和内容分别如下。地区码：以0开头的3位或者4位数字(包括0)。电话号码：以非O、非1开头的7位或者8位数字。设被调试的程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，就可用等价类划分法来设计测试用例。(1)划分等价类并编号，如表6.7所示。(2)为有效等价类设计测试用例，如表6.8所示。(3)为每个无效等价类至少设计一个测试用例，如表6.9所示。黑盒测试用例设计边界值分析方法是对输入或输出的边界值进行测试的一种黑盒测试方法。在测试过程中，边界值分析方法是等价类划分方法的补充，通过选择等价类边界的测试用例进行测试。边界值分析方法与等价类划分方法的区别是：边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件；另外，边界值分析不仅考虑输入条件边界，还要考虑输出域边界产生的测试情况。黑盒测试用例设计按照测试数据的有效性，将边界值分析法分为标准边界值测试和健壮边界值测试。（1）标准边界值测试只考虑有效数据范围内的边界值。对于一个有n个变量的程序，保留其中一个变量，其取值为最小值(Min)、略高于最小值(Min+)、正常值(Normal)、略低于最大值(Max-)、最大值(Max)，让其余变量取正常值，标准边界值分析测试程序会产生4n+1个测试用例。黑盒测试用例设计（2）健壮边界值测试会考虑有效和无效数据范围内的边界值。因此，对于一个含有n个变量的程序，保留其中一个变量，其取值为，其取值为略低于最小值(Min-)、最小值(Min)、略高于最小值(Min+)、正常值(Normal)、略低于最大值(Max-)、最大值(Max)，略高于最大值(Max+)，让其余变量取正常值，健壮边界值分析测试程序会产生6n+1个测试用例。黑盒测试用例设计（2）边界值分析法设计原则使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入等价类与输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。边界值分析方法设计测试用例具有如下原则。①

如果输入条件规定了值的范围，则应选取刚达到范围边界的值，以及刚刚超越边界的值作为测试输入数据。黑盒测试用例设计②如果输入条件规定了值的个数，则用略低于最小值(Min-)、最小值(Min)、略高于最小值(Min+)、正常值(Normal)、略低于最大值(Max-)、最大值(Max)、略高于最大值(Max+)作为测试数据。③将原则①和②应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。④如果程序的规格说明给出的输入域或输出域是有序集合(如有序表、顺序文件等)，则应选取集合的第一个和最后一个元素作为测试用例。⑤如果程序用了一个内部结构，应取这个内部数据结构的边界值作为测试用例。⑥分析规格说明，找出其他可能的边界条件。黑盒测试用例设计例6.3：使用边界值分析法对学生成绩管理系统中的学生成绩录入模块设计测试用例。解：本例中成绩的取值范围在0-100之间的整数。成绩的边界为0或者100。按照标准边界值分析，成绩标准边界值测试用例表如表6.10所示。按照健壮性边界值分析，成绩健壮性边界值测试用例表如表6.11所示黑盒测试用例设计因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况，适合于描述多种输入条件的组合、相应产生多个动作的方法。（1）因果图的优点①考虑多个输入之间的相互组合、相互制约关系；②

指导测试用例的选择，能够指出需求规格说明描述中存在的问题；黑盒测试用例设计③

能够帮助测试人员按照一定的步骤，高效率地开发测试用例；④

因果图法是将自然语言规格说明转化成形式语言规格说明的一种严格的方法，可以指出规格说明存在的不完整性和二义性。黑盒测试用例设计（2）因果图的基本关系图6.7描述了因果图的四种基本关系。图中左节点ci表示输入状态（或称原因)，右节点ei表示输出状态（或称结果）。ci与ei取值0或1，0表示某状态不出现，1则表示某状态出现。（1）恒等：若c1是1，则e1也为1，否则e1为0。（2）非(~)：若c1是1，则e1为0，否则e1为1。（3）或(∨)：若c1或c2或c3是1，则e1为1，否则e1为0。（4）与(∧)：若c1和c2都是1，则e1为1，否则e1为0。黑盒测试用例设计（3）因果图的约束输入状态相互之间还可能存在某些依赖关系，称为约束。比如，某些输入条件本身不可能同时出现，输出状态之间也往往存在约束。在因果图中，用特定的符号标明这些约束，如图6.8所示:因果图的约束又分为输入条件的约束和输出条件的约束。1）输入条件的约束有以下4种。①E约束（异，Exclusive）：a和b中至多有一个可能为1，即a和b不能同时为1。②

约束（或，Inclusive)：a、b和c中至少有一个必须是1，即a、b、和c不能同时为0。③O约束（唯一，Only):a和b必须有一个，且有且仅有1个为1。④

R约束（要求，Request）：a是1时，b必须是1。即不可能a是1时b是0。2）输出条件约束类型输出条件的约束只有M约束（Masks,强制）：若结果a是1，则结果b强制为0。黑盒测试用例设计因果图设计测试用例需要如下五个步骤。①确定软件规格中的原因和结果。②确定原因和结果之间的逻辑关系。③

确定因果图中的各个约束，由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。④把因果图转换为决策表。⑤根据决策表设计测试用例。黑盒测试用例设计例6.4：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件，若投入1元5角硬币，按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退换5角硬币，试应用因果图法设计测试用例。解:（1）根据题意。原因和结果如下。原因:c1：投入1元5角硬币；c2：投入2元硬币；c3：按“可乐”按钮；c4：按“雪碧”按钮；c5：按“红茶”按钮。黑盒测试用例设计中间状态：11：已投币；12：已按钮。结果:e1：退还5角硬币；e2：送出“可乐”饮料；e3：送出“雪碧”饮料；e4：送出“红茶”饮料。（2）根据原因和结果，设计因果图，如图6.9所示:将因果图转换为判定表，如表6.12所示，每一列可作为确定测试用例的依据。黑盒测试用例设计◆

决策表（Decision

Table）也叫判定表，决策表是最具逻辑性的测试方法，和因果图法有重叠的地方。◆

决策表可以用来分析和表达多逻辑条件下执行不同操作的情况的工具。在程序设计发展初期，决策表就已被用作编写程序的辅助工具了。它可以把复杂的逻辑关系和多种条件组合的情况表达得比较明确。◆

（1）决策表组成决策表由四个部分组成，如图6.10所示:黑盒测试用例设计①

条件桩：列出了问题得所有条件，通常认为列出的条件次序无关紧要。②

动作桩：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束。③

条件项：列出针对它条件桩的取值，在所有可能情况下的真假值。④

动作项：列出在条件项的各种取值情况下应该采取的动作。黑盒测试用例设计（2）决策表构造步骤一般来说，构造决策表分为五个步骤。①

确定规则的个数，假如有n个条件，每个条件有两个取值(0,1)，故有2n种规则；②列出所有的条件桩和动作桩；③填入条件项；④填入动作项，等到初始判定表；⑤简化，合并相似规则(相同动作)。黑盒测试用例设计例6.5：如图6.11(a)所示，两规则动作项一样，条件项类似，在1、2条件项分别取Y、N时，无论条件3取何值，都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关。与6.11(a)类似，在6.11(b)图中，无关条件项“一”可包含其他条件项取值，具有相同动作的规则可合并。黑盒测试用例设计（3）适合使用决策表设计测试用例的情况在简化或最后的决策表给出之后，只需要选择恰当的输入，使得决策表每一列的输入条件值得到满足即可生成相应的测试用例。同其它软件测试一样，决策表测试法适用于具有以下特征的应用程序。适用于ifelse成者switchcase的程序，输入变量之间存在逻辑关系，涉及输入变量子集的计算，以及输入与输出之间存在因果关系的程序。黑盒测试用例设计B.Beizer指出了适合于使用判定表设计测试用例的条件如下。①

规格说明以判定表形式给出，或是很容易转换成判定表；②条件的排列顺序不会也不应影响执行哪些操作；③规则的排列顺序不会也不应影响执行哪些操作；④

当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；⑤

如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要；黑盒测试用例设计例6.6：一个软件的规格说明指出：①

当条件1和条件2满足，并且条件3和条件4不满足，或者当条件1、条件3和条件4满足时，要执行操作1；②在任个条件都不满足时，要执行操作2；③在条件1不满足，而条件4被满足时，要执行操作3。试根据规格说明建立决策表。解：确定规则的个数：软件规格说明中有4个条件，每个条件有2个取值，因此，有2*2*2*2=16种规则。根据规格说明，得到如表6.13所示的决策表。黑盒测试用例设计这里，决策表只给出了16种规则中的8种。事实上，除这8种以外的一些规则是指当不能满足指定的条件，执行这些条件时，要执行1个默许的操作。在无必要时，决策表通常可略去这些规则。但如果用决策表来设计测试用例，就必须列出这些默许规则，如表6.14所示:黑盒测试用例设计有经验的测试人员往往可以根据自己的工作经验和直觉推测出程序可能存在的错误，从而有针对性地进行测试，这就是错误推测法(Error

Guess

Method)，或叫探索性测试方法(Exploratory

Test)。错误推测法是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性地进行测试。“只可意会，不能言传”，就是表明这样一个道理。错误推测法的优点是测试者能够快速且容易地切入，并能够体会到程序的易用与否；缺点是难以知道测试的覆盖率，可能丢失大量未知的区域，这种测试行为带有主观性，且难以复制。黑盒测试用例设计例6.7：测试一个对线性表(如数组)进行排序的程序，应用错误推测法推测出需要特别测试的情况。解：根据经验，对于排序程序，下面一些情况可能使软件发生错误或容易发生错误，需要特别测试。（1）输入的线性表为空表；（2）表中只含有1个元素；（3）输入表中所有元素已排好序；（4）输入表已按逆序排好；（5）输入表中部分或全部元素相同。黑盒测试用例设计◆

软件系统中流程的控制由事件触发决定，事件不同的触发顺序和处理结果形成事件流，每个事件流触发时的情景便形成了场景。◆

通过运用场景来对系统的功能点或业务流程的描述，可以提高测试效果。场景法的测试思想的是Rational公司提出的，并在RUP

2000中文版中有详尽的解释和应用，能够比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。黑盒测试用例设计（1）基本流和备选流场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。对于场景法中基本流和备用流的描述如图6.12所示:在图6.12中，经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中(如备选流1和3)；也可能起源于另一个备选流(如备选流2)，或者终止用例而不再重新加入到某个流(如备选流2和4)。黑盒测试用例设计（2）场景法设计测试用例步骤场景法设计测试用例的步骤如下所示：①根据说明，描述程序的基本流及各项备选流；②根据基本流和各项备选流生成不同的场景；③对每一个场景生成相应的测试用例；④

对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值。白盒测试用例设计08白盒测试用例设计◆

测试覆盖率用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。◆

测试覆盖率包括功能点覆盖率和结构覆盖率，功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。白盒测试用例设计◆

逻辑覆盖法是以程序内部的逻辑结构为基础的用例设计方法，它通过对程序逻辑结构的遍历实现程序的覆盖。◆

根据覆盖目标的不同，逻辑覆盖分为语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定-条件覆盖（分支-条件覆盖）、条件组合覆盖、路径覆盖六种覆盖测试方法。下面举例说明六种覆盖测试方法。例6.9:示例程序源代码。IntlogicExample(intx,inty){intmagic=0;if(x>0&&y>0)magic=x+y+10;

//语句块1elsemagic=x+y-10;

//语句块2if(magic<0)magic=0;

//语句块3return

magic;

//语句块4}一般逻辑覆盖测试不会直接根据源代码，而是根据流程图来设计测试用例，根据例6.9示例程序源代码画出流程图，如图6.14所示。白盒测试用例设计（1）语句覆盖语句覆盖要求设计足够多的测试用例，运行被测程序，使得程序中每条语句至少被执行一次。在本例中，可执行语句是指语句块1到语句块4中的语句。例6.9的语句覆盖测试用例如表6.17所示：白盒测试用例设计白盒测试用例设计（2）判定覆盖判定覆盖，又称分支覆盖，要求设计足够多的测试用例，运行被测程序，使得程序中的每个判断的“真”和“假”分支都至少被执行一次。在本例中共有两个判断if(x>0&&y>0)和if(magic<0)。例6.9的判定覆盖测试用例如表6.18所示：白盒测试用例设计白盒测试用例设计（3）条件覆盖条件覆盖要求设计足够多的测试用例，运行被测程序，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。在本例中有两个判断if(x>0&&y>0)和if(magic<0)，共计三个条件x>0、y>0和magic<0。例6.9的条件覆盖测试用例如表6.19所示：白盒测试用例设计白盒测试用例设计（4）判定-条件覆盖判定-条件覆盖要求设计足够多的测试用例，运行被测程序，使得被测试程序中的每个判断本身的判定结果（真/假）至少满足一次，同时，每个逻辑条件的可能值也至少被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准。例6.9的判定-条件覆盖测试用例如表6.20所示：白盒测试用例设计白盒测试用例设计（5）条件组合覆盖条件组合覆盖要求设计足够多的测试用例，运行被测程序，使得被测试程序中每个判定中条件结果的所有可能组合至少执行一次。应该注意如下三点。①

条件组合只针对同一个判断语句内存在多个条件的情况，让这些条件的取值进行笛卡尔乘积组合；②不同的判断语句内的条件取值之间无需组合；③

对于单条件的判断语句，只需要满足自己的所有取值即可。例6.9的条件组合覆盖测试用例如表6.21所示:白盒测试用例设计白盒测试用例设计（6）路径覆盖路径覆盖要求设计足够的测试用例，运行被测程序，覆盖程序中所有可能的路径。例6.9的路径覆盖测试用例如表6.22所示:白盒测试用例设计白盒测试用例设计◆

从上例可知，单独采用任何一种逻辑覆盖方法都不能完全覆盖所有的测试用例，任何一个高效的测试用例，都是针对具体测试场景的。◆

逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。所以在实际测试用例设计中，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。要根据不同需要和不同测试用例设计特征，将不同的设计方法组合起来，交叉使用，以实现最佳的测试用例输出。白盒测试用例设计◆

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证被测程序的每个可执行语句至少被执行一次。白盒测试用例设计◆

采用基本路径测试法设计测试用例，主要包括以下四个步骤:（1）以详细设计或源代码作为基础，导出程序控制流图。◆

程序控制流图是描述程序控制流的一种图示方法，可以用图6.15的基本符号来描述程序结构。白盒测试用例设计◆

控制流图由结点和控制流线（弧）两种图形符号组成。结点以标有编号的圆圈表示，用于表示程序流程图中矩形框、菱形框的功能，是一个或多个五分支的语句或源程序语句。◆

控制流线（弧）也称控制流图的边或链接，以箭头表示，与程序流程图中的流线功能一致，需注意以下情况。①

分支的汇聚处应有一个汇聚结点，即使该结点并不代表任何语句；②

由边和结点限定的范围称为区域。需要注意，图形外的区域也应记为一个区域。例6.10：程序的源代码。白盒测试用例设计（2）计算程序控制流图的环路复杂度。通过对程序控制流图的分析和判断，来计算程序控制流图的环路复杂度。环路复杂度用V(G)表示，有三种计算方法。①将环路复杂度定义为控制流图中的区域数。如图6.17所示，程序控制流图将整个平面分成四个区域，R1、R2、R3和R4，因此V(G)=4。②设定E为控制流图的边数，N为图的结点数，则定义环路的复杂度为V(G)=E−N+2。如图6.17所示，E=10，N=8，V(G)=10-8+2=4。③设定P为控制流图中的判定结点数，则有V(G)=P+1。如图6.17所示，图中的判定结点数P=3，V(G)=3+1=4。白盒测试用例设计（3）确定独立路径集合。从程序的环路复杂度可导出程序的独立路径条数。独立路径，是指和其他的路径相比，至少引进一个新的处理语句集合或一个新判断条件的程序通路，即独立路径必须至少包含一条在定义之前不曾使用的边。如果只是已有路径的简单合并，并未包含任何新边，则不是独立路径。独立路径集合中的每一条路径都是唯一的，但独立路径集合不是唯一的，可以有多组不同的独立路径集合。白盒测试用例设计如图6.17所示，可确定独立路径为如下四条。1）①-⑧2）①-②-③-⑧3）①-②-④-⑤-⑦-①-⑧4）①-②-④-⑥-⑦-①-⑧白盒测试用例设计（4）根据独立路径，设计测试用例,

确保基本路径集合中每条路径的执行。为了确保独立路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证每一条路径都被测试到。依据步骤3）中的独立路径，结合程序源代码，设计测试用例如表6.23所示：白盒测试用例设计◆

在软件动态测试中，程序插桩是一种基本的测试手段，有着广泛的应用。◆

简单来说，程序插桩技术是借助往被测程序中插入操作来实现测试目的的方法，即向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。例如，想要了解一个程序在某次运行中所有可执行语句被覆盖的情况，或是每个语句的实际执行次数，就可以利用程序插桩技术。白盒测试用例设计在程序的特定部位插入记录动态特性的语句，最终是为了把程序执行过程中发生的一些重要历史事件记录下来。例如，记录在程序执行过程中某些变量值的变化情况、变化的范围等。白盒测试用例设计◆

设计程序插装程序时需要考虑的问题包括如下三个。（1）探测哪些信息；（2）在程序的什么部位设置探测点；（3）需要设置多少个探测点。白盒测试用例设计