软件测试基础教程杜文洁 景秀丽 主编中国水利水电出版社第二章 软件测试方法第二章 软件测试方法
2.1 软件测试方法概述
2.2 静态测试与动态测试
2.3 黑盒测试
2.4 白盒测试习题本章概要第二章 软件测试方法
软件测试方法概述
静态测试和动态测试
黑盒测试和白盒测试
2.1 软件测试方法概述第二章 软件测试方法软件测试的方法多种多样，可以从不同角度加以分类：
从是否需要执行被测软件的角度，分为静态测试和动态测试；
从是针对系统的外部功能还是针对系统的内部结构的角度，分为黑盒测试和白盒测试；
从软件测试的策略和过程的角度，分为单元测试、集成测试、确认测试、系统测试和验收测试等。
2.1 软件测试方法概述第二章 软件测试方法
1．从是否需要执行被测软件的角度分类从是否需要执行被测软件的角度，软件测试可分为静态测试（ Static
Testing）和动态测试 (Dynamic Testing)。顾名思义，静态测试就是通过对被测程序的静态审查，发现代码中潜在的错误。它一般用人工方式脱机完成，故亦称人工测试或代码评审（ Code Review） ;也可借助于静态分析器在机器上以自动方式进行检查，但不要求程序本身在机器上运行。按照评审的不同组织形式，代码评审又可分为代码会审，走查以及办公桌检查，同行评分 4种。对某个具体的程序，通常只使用一种评审方式。
动态测试是通常意义上的测试，即使用和运行被测软件。动态测试的对象必须是能够由计算机真正运行的被测试的程序，它包含黑盒测试和白盒测试，在 2.3节将会具体介绍这两种方法。
2.1 软件测试方法概述第二章 软件测试方法
2．从软件测试用例设计方法的角度分类从软件测试用例设计方法的角度，可分为黑盒测试（ Black-Box Testing）和白盒测试（ White-Box Testing）。
黑盒测试是一种从用户角度出发的测试，又称为功能测试。数据驱动测试和基于规格说明的测试。使用这种方法进行测试时，把被测试程序当作一个黑盒，忽略程序内部的结构的特性，测试者在只知道该程序输入和输出之间的关系或程序功能的情况下，依靠能够反映这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。简单地说，若测试用例的设计是基于产品的功能，目的是检查程序各个功能是否实现，并检查其中的功能错误，则这种测试方法称为黑盒。
白盒测试基于产品的内部结构来进行测试，检查内部操作是否按规定执行
，软件各个部分功能是否得到充分利用。白盒测试又称为结构测试，逻辑驱动测试或基于程序的测试。即根据被测程序的内部结构设计测试用例，测试者需要预先了解被测试程序的结构。
2.1 软件测试方法概述第二章 软件测试方法
3．从软件测试的策略和过程的角度分类。
按照软件测试的策略和过程分类，软件测试可分为单元测试（ Unit Testing），集成测试（ Integration Testing），确认测试（ Validation Testing），系统测试（ System
Testing）和验收测试（ Verification Testing）。
单元测试是针对每个单元的测试，是软件测试的最小单位。它确保每个模块能正常工作。单元测试主要采用白盒测试方法，用以发现内部错误。
集成测试是对已测试过的模块进行组装，进行集成测试的目的主要在于检验与软件设计相关的程序结构问题。在集成测试过程中，测试人员采用黑盒测试和白盒测试两种方法，来验证多个单元模块集成到一起后是否能够协调工作。
确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。
系统测试的主要任务是检测被测软件与系统的其他部分的协调性，通常采用黑盒测试方法。
验收测试是软件产品质量的最后一关。这一环节，测试主要从用户的角度着手，其参与者主要是用户和少量的程序开发人员，通常采用黑盒测试方法。
2.2 静态测试与动态测试第二章 软件测试方法根据程序是否运行可以把软件测试方法分为静态测试（ Static Testing）和动态测试（ Dynamic Testing）两大类。图 2-1是静态测试与动态测试的比喻图。
图 2-1 静态测试与动态测试的比喻图
2.2.1 静态测试第二章 软件测试方法静态方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序，只对被测程序进行特性分析。因此，静态方法常称为
“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。所谓静态分析，就是不需要执行所测试的程序，而只是通过扫描程序正文，对程序的数据流和控制流等信息进行分析，找出系统的缺陷，得出测试报告。
静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
2.2.1 静态测试第二章 软件测试方法通常在静态测试阶段进行以下一些测试活动：
检查算法的逻辑正确性，确定算法是否实现了所要求的功能；
检查模块接口的正确性，确定形参的个数、数据类型、顺序是否正确，确定返回值类型及返回值的正确性；
检查输入参数是否有合法性检查。如果没有合法性检查，则应确定该参数是否不需要合法性检查，否则应加上参数的合法性检查；
检查调用其他模块的接口是否正确，检查实参类型、实参个数是否正确，返回值是否正确。若被调用模块出现异常或错误，
程序是否有适当的出错处理代码；
检查是否设臵了适当的出错处理，以便在程序出错时，能对出错部分进行重做安排，保证其逻辑的正确性；
检查表达式、语句是否正确，是否含有二义性。例如，下列表达式或运算符的优先级,<=,=,>=,&&,||,++,--等；
检查常量或全局变量使用是否正确；
检查标识符的使用是否规范、一致，变量命名是否能够望名知义、
简洁、规范和易记；
检查程序风格的一致性、规范性，代码是否符合行业规范，是否所有模块的代码风格一致、规范；
检查代码是否可以优化，算法效率是否最高；
检查代码注释是否完整，是否正确反映了代码的功能，并查找错误的注释。
2.2.1 静态测试第二章 软件测试方法
2.2.1 静态测试第二章 软件测试方法静态分析的差错分析功能是编译程序所不能替代的。编译系统虽然能发现某些程序错误，但这些错误远非软件中存在的大部分错误。目前，已经开发了一些静态分析系统作为软件静态测试的工具，静态分析已被当作一种自动化的代码校验方法。
2.2.2 动态测试第二章 软件测试方法动态方法是通过源程序运行时所体现出来的特征，来进行执行跟踪、时间分析以及测试覆盖等方面的测试。动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例，对其输入与输出的对应关系进行分析，以达到检测的目的。
动态测试方法的基本步骤：
选取定义域的有效值，或选取定义域外的无效值；
对已选取值决定预期的结果；
用选取值执行程序；
执行结果与预期的结果相比，不吻合则说明程序有错。
不同的测试方法各自的目标和侧重点不一样，在实际工作中要将静态测试和动态测试结合起来，以达到更加完美的效果。
在动态测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试。
2.3 黑盒测试方法第二章 软件测试方法黑盒测试（ Black-box Testing）又称为功能测试、数据驱动测试和基于规格说明的测试。是一种从用户观点出发的测试，
主要以软件规格说明书为依据，对程序功能和程序接口进行的测试。
黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。黑盒测试作为软件功能的测试手段，是重要的测试方法。它主要根据规格说明设计测试用例，并不涉及程序内部结构和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。
2.3.1 黑盒测试方法概述第二章 软件测试方法黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。很明显，如果外部特性本身有问题或规格说明书的规定有误，用黑盒测试方法是发现不了的。黑盒测试方法着重测试软件的功能需求，是在程序接口上进行测试，主要是为了发现以下错误：
1.是否有不正确的功能，是否有遗漏的功能；
2.在接口上，是否能够正确地接收输入数据并产生正确的输出结果；
3.是否有数据结构错误或外部信息访问错误；
4.性能上是否能够满足要求；
5.是否有程序初始化和终止方面的错误。
2.3.1 黑盒测试方法概述第二章 软件测试方法黑盒测试有两个显著的特点：
黑盒测试不考虑软件的具体实现过程，当在软件实现的过程发生变化时，测试用例仍然可以使用；
黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。
黑盒测试不仅能够找到大多数其他测试方法无法发现的错误，而且一些外购软件、参数化软件包以及某些自动生成的软件，由于无法得到源程序，在一些情况下只能选择黑盒测试。
2.3.1 黑盒测试方法概述第二章 软件测试方法黑盒测试有两种基本方法，即通过测试和失败测试。
在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何，软件测试人员只是运用最简单，最直观的测试案例。
在设计和执行测试案例时，总是先要进行通过测试，验证软件的基本功能是否都已实现。
在确信了软件正确运行之后，就可以采取各种手段通过搞垮软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。
黑盒测试的具体技术方法主要包括边界值分析法、等价类划分法
、因果图法、决策表法等。这些方法是比较实用的，在项目中采用什么方法，在设计具体的测试方案时自然要针对开发项目的特点对设计方法进行适当的选择。
2.3.2 等价类划分法第二章 软件测试方法
1,等价类划分法概述等价类划分法是黑盒测试用例设计中一种常用的设计方法，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。所谓等价类是指输入域的某个子集合，所有等价类的并集就是整个输入域。在等价类中，各个输入数据对于揭露程序中的错误都是等效的，它们具有等价特性。因此，测试某个等价类的代表值就是等价于对这一类中其他值的测试。也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；
反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。
2.3.2 等价类划分法第二章 软件测试方法软件不能只接收合理有效的数据，也要具有处理异常数据的功能，
这样的测试才能确保软件具有更高的可靠性。
因此，在划分等价类的过程中，不但要考虑有效等价类划分，同时也要考虑无效等价类划分。
有效等价类是指对软件规格说明来说，合理、有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。
无效等价类则和有效等价类相反，即不满足程序输入要求或者无效的输入数据所构成的集合。利用无效等价类可以检验程序异常情况的处理。
使用等价类划分法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，然后列出等价类表。
2.3.2 等价类划分法第二章 软件测试方法输入条件 有效等价类 无效等价类
… … …
… … …
在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表 2-1所示。
表 2-1 等价类表再根据已列出的等价类表，按以下步骤确定测试用例：
为每一个等价类规定一个唯一的编号；
设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类
，重复这个过程，直至所有的有效等价类均被测试用例所覆盖；
设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这个过程，
直至所有的无效等价类均被测试用例所覆盖。
以三角形问题为例，输入条件是：
三个数，分别作为三角形的三条边都是整数取值范围在 1～ 100之间认真分析上述的输入条件，可以得出相关的等价类表
（包括有效等价类和无效等价类），如表 2-2所示。
2.3.2 等价类划分法第二章 软件测试方法
2.3.2 等价类划分法第二章 软件测试方法输入条件 等价类编号 有效等价类 等价类编号 无效等价类三个数 1 三个数
4 只有一条边
5 只有两条边
6 多于三条边整数 2 整数
7 一边为非整数
8 两边为非整数
9 三边为非整数取值范围在
1~100 3
1≤a≤100
1≤b≤100
1≤c≤100
10 一边为 0
11 两边为 0
12 三边为 0
13 一边小于 0
14 两边小于 0
15 三边小于 0
16 一边大于 100
17 两边大于 100
18 三边大于 100
表 2-2 三角形问题的等价类
2.3.2 等价类划分法第二章 软件测试方法
2,常见等价类划分形式针对是否对无效数据进行测试，可以将等价类测试分为标准等价类测试、健壮等价类测试以及对等区间的划分。
(1) 标准等价类测试标准等价类测试不考虑无效数据值，测试用例使用每个等价类中的一个值。通常
，标准等价类测试用例的数量和最大等价类中元素的数目相等。
以三角形问题为例，要求输入三个整数 a,b,c，分别作为三角形的三条边，取值范围在 1～ 100之间，判断由三条边构成的三角形类型为等边三角形、等腰三角形、
一般三角形（包括直角三角形）以及非三角形。在多数情况下，是从输入域划分等价类，但对于三角形问题，从输出域来定义等价类是最简单的划分方法。
因此，利用这些信息可以确定下列值域等价类：
R1={〈 a,b,c〉,边为 a,b,c 的等边三角形 }
R2={〈 a,b,c〉,边为 a,b,c 的等腰三角形 }
R3={〈 a,b,c〉,边为 a,b,c 的一般三角形 }
R4={〈 a,b,c〉,边为 a,b,c 不构成三角形 }
4个标准等价类测试用例如表 2-3所示。
2.3.2 等价类划分法第二章 软件测试方法测试用例 a b c 预期输出
Test Case 1 10 10 10 等边三角形
Test Case 2 10 10 5 等腰三角形
Test Case 3 3 4 5 一般三角形
Test Case 4 1 1 5 不构成三角形表 2-3 三角形问题的标准等价类测试用例
2.3.2 等价类划分法第二章 软件测试方法
(2) 健壮等价类测试健壮等价类测试主要的出发点是考虑了无效等价类。
对有效输入，测试用例从每个有效等价类中取一个值； 对无效输入，一个测试用例有一个无效值，其他值均取有效值。
健壮等价类测试存在两个问题：
需要花费精力定义无效测试用例的期望输出；
对强类型的语言没有必要考虑无效的输入 。
2.3.2 等价类划分法第二章 软件测试方法
(3) 对等区间划分对等区间划分是测试用例设计的非常规形式化的方法。它将被测对象的输入 /输出划分成一些区间，被测软件对一个特定区间的任何值都是等价的。形成测试区间的数据不只是函数 /过程的参数，也可以是程序可以访问的全局变量、系统资源等，这些变量或资源可以是以时间形式存在的数据，或以状态形式存在的输入 /输出序列。
对等区间划分假定位于单个区间的所有值对测试都是对等的，应为每个区间的一个值设计一个测试用例。
举例说明如下：
平方根函数要求当输入值为 0或大于 0时，返回输入数的平方根；
当输入值小于 0时，显示错误信息“平方根错误，输入值小于 0”，并返回 0。
输入区间 输出区间
ⅰ <0 A >=0
ⅱ >=0 B Error
考虑平方根函数的测试用例区间，可以划分出两个输入区间和两个输出区间，如表 2-5所示。
表 2-5 区间划分通过分析，可以用两个测试用例来测试 4个区间：
测试用例 1：输入 4，返回 2 //区间 ⅱ 和 A
测试用例 2：输入 -4，返回 0，输出“平方根错误，输入值小于 0”
//区间 ⅰ 和 B
上例的对等区间划分是非常简单的。当软件变得更加复杂时，对等区间的确定就越难，区间之间的相互依赖性就越强，使用对等区间划分设计测试用例技术的难度会增加。
2.3.2 等价类划分法第二章 软件测试方法
2.3.3 边界值分析法第二章 软件测试方法
1,边界值分析法边界值分析法（ Boundary Value Analysis,BVA）是一种补充等价类划分法的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。在测试过程中，可能会忽略边界值的条件，而软件设计中大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
在实际的软件设计过程中，会涉及到大量的边界值条件和过程，
这里有一个简单的 VB程序的例子：
Dim data(10) as Integer
Dim i as Integer
For i=1 to 10
data(i)=1
Next i
2.3.3 边界值分析法第二章 软件测试方法在这个程序中，目标是为了创建一个拥有 10个元素的一维数组，
看似合理，但是，在大多数 Basic语言中，当一个数组被定义时，其第一个元素所对应的数组下标是 0而不是 1。由此，上述程序运行结束后，数组中成员的赋值情况如下：
data(0)=0,data(1)=1,data(2)=1,...,data(10)=1
这时，如果其他程序员在使用这个数组的时候，可能会造成软件的缺陷或者错误的产生。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
2.3.3 边界值分析法第二章 软件测试方法在应用边界值分析法设计测试用例时，应遵循以下几条原则：
如果输入条件规定了值的范围，则应该选取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。
如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少 1、比最大个数多 1的数作为测试数据。
根据规格说明的每一个输出条件，分别使用以上两个原则。
如果程序的规格说明给出的输入域或者输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个元素和最后一个元素作为测试用例。
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界值作为测试用例。
分析规格说明，找出其他可能的边界条件。
第二章 软件测试方法
2,边界条件与次边界条件边界值分析法是对输入的边界值进行测试。在测试用例设计中，需要对输入的条件进行分析并且找出其中的边界值条件，通过对这些边界值的测试来查出更多的错误。
提出边界条件时，一定要测试临近边界的有效数据，测试最后一个可能有效的数据，同时测试刚超过边界的无效数据。通常情况下，软件测试所包含的边界检验有几种类型：数值、字符、位置、数量、速度、尺寸等，在设计测试用例时要考虑边界检验的类型特征：第一个 /
最后一个、开始 /完成、空 /满、最大值 /最小值、最快 /最慢、最高 /最低、最长 /最短等。这些不是确定的列表，而是一些可能出现的边界条件。
2.3.3 边界值分析法第二章 软件测试方法
2.3.3 边界值分析法在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户通常最容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到这些问题，但这些边界条件同时确实属于检验范畴内的边界条件，称为内部边界值条件或次边界值条件。主要有下面几种：
第二章 软件测试方法
2.3.3 边界值分析法项 范围或值位（ bit） 0或 1
字节（ byte） 0~255
字（ word） 0~65,535（单字）或 0~4,294,967,295（双字）
千（ K） 1 024
兆（ M） 1 048 576
吉（ G） 1 073 741 824
太（ T） 1 099 511 627 776
数值的边界值检验计算机是基于二进制进行工作的，因此，任何数值运算都有一定的范围限制，如表 2-7所示。
表 2-7 计算机数值运算的范围例如对字节进行检验，边界值条件可以设置成 254,255和 256。
第二章 软件测试方法
2.3.3 边界值分析法字符 ASCII码值 字符 ASCII码值空（ null） 0 A 65
空格（ space） 32 a 97
斜杠（ /） 47 左中括号（ [） 91
0 48 Z 122
冒号（：） 58 Z 90
@ 64 单引号（‘） 96
字符的边界值检验在字符的编码方式中,ASCII和 Unicode是比较常见的编码方式
，表 2-8中列出了一些简单的 ASCII码对应表。
表 2-8 字符的 ASCII码对应表第二章 软件测试方法
2.3.3 边界值分析法在做文本输入或者文本转换的测试过程中，需要非常清晰地了解 ASCII码的一些基本对应关系，例如小写字母 z和大写字母 Z在表中的对应是不同的，这些也必须被考虑到数据区域划分的过程中，从而定义等价有效类，来设计测试用例。
其他边界值检验包括默认值 /空值 /空格 /未输入值 /零、无效数据 /不正确数据和干扰数据等。
在实际的测试用例设计中，需要将基本的软件设计要求和程序定义的要求结合起来，即结合基本边界值条件和子边界值条件来设计有效的测试用例。
第二章 软件测试方法
2.3.3 边界值分析法
3,边界值分析法测试用例以三角形问题为例，要求输入三个整数 a,b,c，分别作为三角形的三条边，取值范围在 1～ 100之间，判断由三条边构成的三角形类型为等边三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。如表 2-9所示给出了边界值分析测试用例。
第二章 软件测试方法
2.3.3 边界值分析法测试用例 a b c 预期输出
Test Case 1 1 50 50 等腰三角形
Test Case 2 2 50 50 等腰三角形
Test Case 3 50 50 50 等边三角形
Test Case 4 99 50 50 等腰三角形
Test Case 5 100 50 50 非三角形
Test Case 6 50 1 50 等腰三角形
Test Case 7 50 2 50 等腰三角形
Test Case 8 50 99 50 等腰三角形
Test Case 9 50 100 50 非三角形
Test Case 10 50 50 1 等腰三角形
Test Case 11 50 50 2 等腰三角形
Test Case 12 50 50 99 等腰三角形
Test Case 13 50 50 100 非三角形表 2-9边界值分析测试用例
2.3.4决策表法第二章 软件测试方法
1,决策表法在所有的黑盒测试方法中，基于决策表（也称判定表）的测试是最为严格、最具有逻辑性的测试方法。决策表是分析和表达多个逻辑条件下执行不同操作情况的工具。由于决策表可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确，在程序设计发展的初期，
决策表就已被当作编写程序的辅助工具了。
决策表通常由四个部分组成，如图 2-2所示。
条件桩：列出了问题的所有条件，通常认为列出的条件的先后次序无关紧要。
动作桩：列出了问题规定的可能采取的操作，这些操作的排列顺序没有约束。
条件项：针对条件桩给出的条件列出所有可能的取值。
动作项：与条件项紧密相关，列出在条件项的各组取值情况下应该采取的动作。
2.3.4决策表法第二章 软件测试方法图 2-2 决策表的组成
2.3.4决策表法第二章 软件测试方法任何一个条件组合的特定取值及其相应要执行的操作称为一条规则，
在决策表中贯穿条件项和动作项的一列就是一条规则。显然，决策表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。
根据软件规格说明，建立决策表的步骤如下：
① 确定规则的个数。假如有 n个条件，每个条件有两个取值，故有
2n种规则。
② 列出所有的条件桩和动作桩。
③ 填入条件项。
④ 填入动作项，得到初始决策表。
⑤ 化简。合并相似规则（相同动作）。
2.3.4决策表法第二章 软件测试方法以下列问题为例给出构造决策表的具体过程。
如果某产品销售好并且库存低，则增加该产品的生产；如果该产品销售好，但库存量不低，则继续生产；若该产品销售不好，但库存量低，则继续生产；若该产品销售不好，且库存量不低，则停止生产。
2.3.4决策表法第二章 软件测试方法解法如下：
确定规则的个数。对于本题有 2个条件（销售、库存），每个条件可以有两个取值，故有 22=4种规则。
列出所有的条件桩和动作桩。
填入条件项。
填入动作项，得到初始决策表，如表 2-10所示。
每种测试方法都有适用的范围，决策表法适用于下列情况：
规格说明以决策表形式给出，或很容易转换成决策表。
条件的排列顺序不会也不应影响执行哪些操作。
规则的排列顺序不会也不应影响执行哪些操作。
每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
2.3.4决策表法第二章 软件测试方法规则选项
1 2 3 4
条件：
C1：销售好?
C2：库存低?
T
T
T
F
F
T
F
F
动作：
a1：增加生产
a2：继续生产
a3：停止生产
√ √ √ √
表 2-10 产品销售问题的决策表
2.3.4决策表法第二章 软件测试方法
2,决策表法的应用决策表最突出的优点是，能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。运用决策表设计测试用例，可以将条件理解为输入，将动作理解为输出。
以三角形问题为例，要求输入三个整数 a,b,c，分别作为三角形的三条边，取值范围在 1～ 100之间，判断由三条边构成的三角形类型为等边三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。
2.3.4决策表法第二章 软件测试方法分析如下：
确定规则的个数。例如，三角形问题的决策表有 4个条件，每个条件可以取两个值（真值和假值），所以应该有 24=16种规则。
列出所有条件桩和动作桩。
填写条件项。
填写动作项，从而得到初始决策表。如表 2-11所示。
简化决策表。合并相似规则后得到三角形问题的简化决策表。如表 2-12所示。
2.3.4决策表法第二章 软件测试方法规则选项 1 2 3 4 5 6 7 8
条件：
C1,a,b,c构成一个三角形？
C2,a=b？
C3,b=c？
C4,a=c？
F
T
T
T
F
T
T
F
F
T
F
T
F
T
F
F
F
F
T
T
F
F
T
F
F
F
F
T
F
F
F
F
动作：
a1：非三角形
a2：一般三角形
a3：等腰三角形
a4：等边三角形
a5：不可能
√ √ √ √ √ √ √ √
表 2-11 三角形问题的初始决策表
2.3.4决策表法第二章 软件测试方法规则选项 9 10 11 12 13 14 15 16
条件：
C1,a,b,c构成一个三角形？
C2,a=b？
C3,b=c？
C4,a=c？
T
T
T
T
T
T
T
F
T
T
F
T
T
T
F
F
T
F
T
T
T
F
T
F
T
F
F
T
T
F
F
F
动作：
a1：非三角形
a2,一般三角形
a3,等腰三角形
a4,等边三角形
a5：不可能
√
√ √ √ √ √ √ √
2.3.4决策表法第二章 软件测试方法规则选项 1～8 9 10 11 12 13 14 15 16
条件：
C1,a,b,c构成一个三角形？
C2,a=b？
C3,b=c？
C4,a=c？
F
－
－
－
T
T
T
T
T
T
T
F
T
T
F
T
T
T
F
F
T
F
T
T
T
F
T
F
T
F
F
T
T
F
F
F
动作：
a1：非三角形
a2：一般三角形
a3：等腰三角形
a4：等边三角形
a5：不可能
√
√
√ √ √ √ √ √ √
表 2-12 三角形问题的简化决策表
2.3.4决策表法第二章 软件测试方法测试用例 a b c 预期输出
Test Case 1 10 4 4 非三角形
Test Case 2 4 4 4 等边三角形
Test Case 3 不可能
Test Case 4 不可能
Test Case 5 4 4 5 等腰三角形
Test Case 6 不可能
Test Case 7 5 4 4 等腰三角形
Test Case 8 4 5 4 等腰三角形
Test Case 9 3 4 5 一般三角形根据决策表 2-12，可设计测试用例，如表 2-13所示。
表 2-13 三角形问题的决策表测试用例
2.3.5因果图法第二章 软件测试方法
1,因果图法前面介绍的等价类划分法和边界值分析法都着重考虑输入条件，
而没有考虑到输入条件的各种组合情况，也没有考虑到各个输入条件之间的相互制约关系。因此，必须考虑采用一种适合于多种条件的组合，相应能产生多个动作的形式来进行测试用例的设计，这就需要采用因果图法。因果图法就是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。
在因果图中使用 4种符号分别表示 4种因果关系，如图 2-3所示。用直线连接左右节点，其中左节点 Ci表示输入状态（或称原因），右节点 ei表示输出状态（或称结果）。 Ci和 ei都可取值 0或 1,0表示某状态不出现,1表示某状态出现。
2.3.5因果图法第二章 软件测试方法
（ a）恒等图 2-3 因果图的基本符号
（ b）非
（ c）或 （ d）与
2.3.5因果图法第二章 软件测试方法图 2-3中各符号的含义如下：
图 (a)：表示恒等。若 C1是 1，则 e1也是 1；若 C1是 0，则 e1为 0。
图 (b)：表示非。若 C1是 1，则 e1是 0；若 C1是 0，则 e1为 1。
图 (c)：表示或。若 C1或 C2或 C3是 1，则 e1是 1；若 C1,C2,C3全为 0
，则 e1为 0。
图 (d)：表示与。若 C1和 C2都是 1，则 e1是 1；只要 C1,C2,C3中有一个为 0，则 e1为 0。
在实际问题中，输入状态相互之间还可能存在某些依赖关系，我们称之为约束。例如，某些输入条件不可能同时出现。输出状态之间也往往存在约束，在因果图中，以特定的符号标明这些约束，如图 2-4所示。
2.3.5因果图法第二章 软件测试方法
（ a）异 （ b）或
（ c）惟一图 2-4 约束符号
（ d）要求 （ e）强制
2.3.5因果图法第二章 软件测试方法
2.3.5因果图法第二章 软件测试方法图 2-4中对输入条件的约束如下：
图 (a)：表示 E约束（异）。 a和 b中最多有一个可能为 1，即 a和 b不能同时为 1。
图 (b)：表示 I约束（或）。 a,b和 c中至少有一个必须是 1，即 a、
b和 c不能同时为 0。
图 (c)：表示 O约束（唯一）。 a和 b中必须有一个且仅有一个为 1。
图 (d)：表示 R约束（要求）。 a是 1时,b必须是 1，即 a是 1时,b
不能是 0。
对输出条件的约束只有 M约束。
M约束（强制）：若结果 a是 1，则结果 b强制为 0。
因果图法最终要生成决策表。
2.3.5因果图法第二章 软件测试方法利用因果图法生成测试用例需要以下几个步骤：
分析软件规格说明书中的输入输出条件，并且分析出等价类。分析规格说明中的语义的内容，通过这些语义来找出相对应的输入与输入之间，输入与输出之间的对应关系。
将对应的输入与输入之间，输入与输出之间的关系连接起来，并且将其中不可能的组合情况标注成约束或者限制条件，形成因果图
。
将因果图转换成决策表。
将决策表的每一列作为依据，设计测试用例。
上述步骤如图 2-5所示。
从因果图生成的测试用例中包括了所有输入数据取真值和假值的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。
2.3.5因果图法第二章 软件测试方法某软件规格说明中包含这样的要求：输入的第一个字符必须是 A
或 B，第二个字符必须是一个数字，在此情况下进行文件的修改；
但如果第一个字符不正确，则给出信息 L；如果第二个字符不是数字，则给出信息 M。
2.3.5因果图法第二章 软件测试方法图 2-5 因果图法示例
2.3.5因果图法第二章 软件测试方法解法如下：
分析程序的规格说明，列出原因和结果。
原因,C1----第一个字符是 A
C2----第一个字符是 B
C3----第二个字符是一个数字结果,e1----给出信息 L
e2----修改文件
e3----给出信息 M
2.3.5因果图法第二章 软件测试方法将原因和结果之间的因果关系用逻辑符号连接起来，得到因果图，如图 2-6所示。编号为
11的中间节点是导出结果的进一步原因。
图 2-6 因果图示例
2.3.5因果图法第二章 软件测试方法因为 C1和 C2不可能同时为 1，即第一个字符不可能既是 A又是 B，在因果图上可对其施加 E约束，得到具有约束的因果图，如图 2-7所示。
图 2-7 具有 E约束的因果图
2.3.5因果图法第二章 软件测试方法将因果图转换成决策表，如表 2-14所示。
规则选项 1 2 3 4 5 6 7 8
条件
C1 1 1 1 1 0 0 0 0
C2 1 1 0 0 1 1 0 0
C3 1 0 1 0 1 0 1 0
11 1 1 1 1 0 0
动作
e1 0 0 0 0 1 1
e2 1 0 1 0 0 0
e3 0 1 0 1 0 1
不可能 1 1
测试用例 A5 A# B9 B? X2 Y
%
表 2-14 决策表
2.3.5因果图法第二章 软件测试方法设计测试用例。表 2-14中的前两种情况，因为 C1和 C2不可能同时为 1，所以应排除这两种情况。根据此表，可以设计出 6个测试用例，如表 2-15所示。
编号 输入数据 预期输出
Test Case 1 A5 修改文件
Test Case 2 A# 给出信息 M
Test Case 3 B9 修改文件
Test Case 4 B? 给出信息 M
Test Case 5 X2 给出信息 L
Test Case 6 Y% 给出信息 L和信息 M
表 2-15 测试用例
2.3.6 各种黑盒测试方法的选择第二章 软件测试方法为了最大程度地减少测试遗留的缺陷，同时也为了最大限度地发现存在的缺陷，在测试实施之前，测试工程师必须确定将要采用的黑盒测试策略和方法，并以此为依据制定详细的测试方案。通常，一个好的测试策略和测试方法必将给整个测试工作带来事半功倍的效果。
如何才能确定好的黑盒测试策略和测试方法呢？通常，在确定黑盒测试方法时，应该遵循以下原则：
根据程序的重要性和一旦发生故障将造成的损失程度来确定测试等级和测试重点。
认真选择测试策略，以便能尽可能少地使用测试用例，发现尽可能多的程序错误。因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次测试是不足的，而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度又会带来资源的浪费。因此，
测试需要找到一个平衡点。
以下是各种黑盒测试方法选择的综合策略，可在实际应用过程中参考。
首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，
这是减少工作量和提高测试效率的最有效方法。
在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准
，应当再补充足够的测试用例。
如果程序的功能说明中含有输入条件的组合情况，则应在一开始就选用因果图法。
2.3.7 黑盒测试的优缺点第二章 软件测试方法黑盒测试是一种确认技术，目的是确认“设计的系统是否正确”。黑盒测试是以用户的观点，从输入数据与输出数据的对应关系，也就是根据程序外部特性进行的测试，而不考虑内部结构及工作情况；黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例；若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。
黑盒测试的优点如下：
① 适用于各个测试阶段；
② 从产品功能角度进行测试；
③ 容易入手生成测试数据。
黑盒测试的缺点如下：
① 某些代码得不到测试；
② 如果规则说明有误，无法发现；
③ 不易进行充分行测试。
2.4 白盒测试第二章 软件测试方法白盒测试（ White-box Testing）也称作结构测试或逻辑驱动测试，
它是知道产品的内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。按照程序内部的结构测试程序，
检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。白盒测试的主要方法有逻辑覆盖、基本路径测试等，主要用于软件验证。
2.4 白盒测试第二章 软件测试方法通常的程序结构覆盖有：
语句覆盖；
判断覆盖；
条件覆盖；
判断 /条件覆盖；
条件组合覆盖；
路径覆盖。
2.4 白盒测试第二章 软件测试方法语句覆盖是最常见也是最弱的逻辑覆盖准则，它要求设计若干个测试用例，使被测程序的每个语句都至少被执行一次。判定覆盖或分支覆盖则要求设计若干个测试用例，使被测程序的每个判定的真、
假分支都至少被执行一次。但判定含有多个条件时，可以要求设计若干个测试用例，使被测程序的每个条件的真、假分支都至少被执行一次，即条件覆盖。在考虑对程序路径进行全面检验时，即可使用条件覆盖准则。
虽然结构测试提供了评价测试的逻辑覆盖准则，但结构测试是不完全的。如果程序结构本身存在问题，比如程序逻辑错或者遗漏了规格说明书中已规定的功能，那么，无论哪种结构测试，即使其覆盖率达到了百分之百，也是检查不出来的。因此，提高结构测试的覆盖率，可以增强对被测软件的信度，但并不能做到万无一失。
2.4.1 逻辑覆盖测试第二章 软件测试方法白盒测试技术的常见方法之一就是覆盖测试，它是利用程序的逻辑结构设计相应的测试用例。测试人员要深入了解被测程序的逻辑结构特点，完全掌握源代码的流程，才能设计出恰当的用例。根据不同的测试要求，覆盖测试可以分为语句覆盖、判断覆盖、条件覆盖、判断 /条件覆盖、条件组合覆盖和路径覆盖。
下面是一段简单的 C语言程序，作为公共程序段来说明五种覆盖测试的各自特点。
程序 2-1：
1 If (x>100&& y>500) then
2 score=score+1
3 If (x>=1000|| z>5000) then
4 score=score+5
逻辑运算符,&&”表示“与”的关系，逻辑运算符,||”表示“或”的关系
。其程序控制流图如图 2-8所示。
2.4.1 逻辑覆盖测试第二章 软件测试方法图 2-8 程序流程图
2.4.1 逻辑覆盖测试第二章 软件测试方法语句覆盖语句覆盖（ Statement Coverage）是指设计若干个测试用例，程序运行时每个可执行语句至少被执行一次。在保证完成要求的情况下，
测试用例的数目越少越好。
以下是针对公共程序段设计的两个测试用例，称为测试用例组 1。
Test Case 1,x=2000,y=600,z=6000
Test Case 2,x=900,y=600,z=5000
如表 2-16所示，采用 Test Case 1作为测试用例，则程序按路径 a,c,e
顺序执行，程序中的 4个语句都被执行一次，符合语句覆盖的要求。
采用 Test Case 2作为测试用例，则程序按路径 a,c,d顺序执行，
程序中的语句 4没有执行到，所以没有达到语句覆盖的要求。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600，6000 True True ace
Test Case 2 900,600，5000 True False acd
表 2-16 测试用例组 1
2.4.1 逻辑覆盖测试第二章 软件测试方法从表面上看，语句覆盖用例测试了程序中的每一个语句行，好像对程序覆盖得很全面，但实际上语句覆盖测试是最弱的逻辑覆盖方法。例如，第一个判断的逻辑运算符,&&”错误写成,||”，
或者第二个判断的逻辑运算符,||”错误地写成,&&”，这时如果采用 Test Case 1测试用例是检验不出程序中的判断逻辑错误的。
如果语句 3,If (x>=1000|| z>5000) then”错误写成,If
(x>=1500|| z>5000) then”,Test Case 1同样无法发现错误之处。
根据上述分析可知，语句覆盖测试只是表面上的覆盖程序流程，
没有针对源程序各个语句间的内在关系，设计更为细致的测试用例。
2.4.1 逻辑覆盖测试第二章 软件测试方法判断覆盖判断覆盖（ Branch Coverage）是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的真值分支和假值分支至少被执行一遍。在保证完成要求的情况下，测试用例的数目越少越好。判断覆盖又称为分支覆盖。
测试用例组 2：
Test Case 1,x=2000,y=600,z=6000
Test Case 3,x=50,y=600,z=2000
如表 2-17所示，采用 Test Case 1作为测试用例，程序按路径 a,c，
e顺序执行；采用 Test Case 3作为测试用例，程序按路径 a,b,d顺序执行。所以采用这一组测试用例，公共程序段的 4个判断分支 b,c，
d,e都被覆盖到了。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or (z>5000) 执行路径
Test Case 1 2000,600，6000 True True ace
Test Case 3 50,600，2000 False False abd
表 2-17 测试用例组 2
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例组 3：
Test Case 4,x=2000,y=600,z=2000
Test Case 5,x=2000,y=200,z=6000
如表 2-18所示，采用 Test Case 4作为测试用例，程序沿着路径 a，
c,d顺序执行；采用 Test Case 5作为测试用例，则程序沿着路径
a,b,e顺序执行。显然采用这组测试用例同样可以满足判断覆盖。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or (z>5000) 执行路径
Test Case 4 2000,600，2000 True False acd
Test Case 5 2000,200，6000 False True abe
表 2-18 测试用例组 3
2.4.1 逻辑覆盖测试第二章 软件测试方法实际上，测试用例组 2和测试用例组 3不仅达到了判断覆盖要求，
也同时满足了语句覆盖要求。某种程度上可以说判断覆盖测试要强于语句覆盖测试。但是，如果将第二个判断条件 ((x>=1000)or
(z>5000))中的 z>5000错误定义成 z的其他限定范围，由于判断条件中的两个判断式是“或”的关系，其中一个判断式错误是不影响结果的，所以这两组测试用例是发现不了问题的。因此，应该用具有更强逻辑覆盖能力的覆盖测试方法来测试这种内部判断条件。
2.4.1 逻辑覆盖测试第二章 软件测试方法条件覆盖条件覆盖（ Condition Coverage）是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件中的每个判断式的真值和假值至少被执行一遍。
测试用例组 4：
Test Case 1,x=2000,y=600,z=6000
Test Case 3,x=50,y=600,z=2000
Test Case 5,x=2000,y=200,z=6000
如表 2-19所示，把前面设计过的测试用例挑选出 Test Case 1,Test Case 3,Test Case 5组合成测试用例组 4，组中的 3个测试用例覆盖了 4个内部判断式的 8种真假值情况。同时这组测试用例也实现了判断覆盖。但是并不可以说判断覆盖是条件覆盖的子集。
测试用例组 5：
Test Case 6,50,600,6000
Test Case 7,2000,200,1000
如表 2-20(a) 和表 2-20(b)所示，其中表 2-20(a)表示每个判断条件的每个判断式的真值和假值，
表 2-20(b)表示每个判断条件的真值和假值。测试用例组 5中的 2个测试用例虽然覆盖了 4个内部判断式的 8种真假值情况。但是这组测试用例的执行路径是 abe，仅是覆盖了判断条件的 4
个真假分支中的 2个。所以，需要设计一种能同时满足判断覆盖和条件覆盖的覆盖测试方法，
即判断 /条件覆盖测试。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500)
(x>=100
0) (z>5000)
执行路径
Test
Case 1
2000，
600,6000 True True True False ace
Test
Case 3
50,600，
2000 False True False False abd
Test
Case 5
2000，
200,6000 True False True True abe
测试用例 x,y,z (x>100) (y>500)
(x>=100
0) (z>5000)
执行路径
Test
Case 6
50,600，
6000 False True False True abe
Test
Case 7
2000，
200,1000 True False True False abe
表 2-20(a) 测试用例组 5
表 2-19测试用例组 4
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 6 50,600，6000 False True abe
Test Case 7 2000,200，1000 False True abe
表 2-20(b) 测试用例组 5
2.4.1 逻辑覆盖测试第二章 软件测试方法判断 /条件覆盖判断 /条件覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的真假值分支至少被执行一遍，并且每个判断条件的内部判断式的真假值分支也要被执行一遍。
测试用例组 6：
Test Case 1,x=2000,y=600,z=2000
Test Case 6,x=2000,y=200,z=6000
Test Case 7,x=2000,y=600,z=2000
Test Case 8,x=50,y=200,z=2000
如表 2-21(a) 和表 2-21(b)所示，其中表 2-21(a)表示每个判断条件的每个判断式的真值和假值，表 2-21(b)表示每个判断条件的真值和假值。测试用例组 6虽然满足了判断覆盖和条件覆盖，但是没有对每个判断条件的内部判断式的所有真假值组合进行测试。条件组合判断是必要的，因为条件判断语句中的“与”和“或”，
即,&&”和,||”，会使内部判断式之间产生抑制作用。例如,C=A && B中，如果 A为假值，那么 C就为假值，测试程序就不检测 B了,B的正确与否就无法测试了。
同样,C=A || B中，如果 A为真值，那么 C就为真值，测试程序也不检测 B了,B的正确与否也就无法测试了。
2.4.1 逻辑覆盖测试第二章 软件测试方法条件组合覆盖条件组合覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的的内部判断式的各种真假组合可能都至少被执行一遍。可见，满足条件组合覆盖的测试用例组一定满足判断覆盖、条件覆盖和判断 /条件覆盖。
测试用例组 7：
Test Case 1,x=2000,y=600,z=2000
Test Case 6,x=2000,y=200,z=6000
Test Case 7,x=2000,y=600,z=2000
Test Case 8,x=50,y=200,z=2000
如表 2-22(a) 和表 2-22(b)所示，表 2-22(a)表示每个判断条件的每个判断式的真值和假值，表 2-22(b)表示每个判断条件的真值和假值。测试用例组 7虽然满足了判断覆盖、条件覆盖以及判断 /条件覆盖，但是并没有覆盖程序控制流图中全部的 4条路径
（ ace,abe,abe,abd），只覆盖了其中 3条路径（ ace,abe,abd）。软件测试的目的是尽可能地发现所有软件缺陷，因此程序中的每一条路径都应该进行相应的覆盖测试，从而保证程序中的每一个特定的路径方案都能顺利运行。能够达到这样要求的是路径覆盖测试。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500) (x>=1000) (z>5000) 执行路径
Test Case 1 2000,600，6000 True True True True ace
Test Case 8 50,200,2000 False False False False abd
测试用例 x,y,z (x>100)and (y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600,6000 True True ace
Test Case 8 50,200,2000 False False abd
表 2-21(b) 测试用例组 6
表 2-21(a) 测试用例组 6
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500) (x>=1000) (z>5000) 执行路径
Test Case 1 2000,600，6000 True True True True ace
Test Case 6 50,600，6000 False True False True abe
Test Case 7 2000,200，1000 True False True False abe
Test Case 8 50,200，2000 False False False False abd
测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600,6000 True True ace
Test Case 6 50,600,6000 False True abe
Test Case 7 2000,200,1000 False True abe
Test Case 8 50,200,2000 False False abd
表 2-22(b) 测试用例组 7
表 2-22(a) 测试用例组 7
2.4.1 逻辑覆盖测试第二章 软件测试方法路径覆盖路径覆盖（ Path Coverage）要求设计若干测试用例，执行被测试程序时，能够覆盖程序中所有的可能路径。
测试用例组 8：
Test Case 1,x=2000,y=600,z=6000
Test Case 3,x=50,y=600,z=2000
Test Case 4,x=2000,y=600,z=2000
Test Case 7,x=2000,y=200,z=1000
如表 2-23(a) 和表 2-23(b)所示，表 2-23(a)表示每个判断条件的每个判断式的真值和假值，表 2-23(b)表示每个判断条件的真值和假值。测试用例组 8可以达到路径覆盖。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500) (x>=1000) (z>5000) 执行路径
Test Case 1 2000,600，6000 True True True True ace
Test Case 3 50,600,2000 False True False False abd
Test Case 4 2000,600，2000 True True True False acd
Test Case 7 2000,200，1000 True False True False abe
测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600,6000 True True ace
Test Case 3 50,600,2000 False False abd
Test Case 4 2000,600,2000 True True acd
Test Case 7 2000,200,1000 False True abe
表 2-23(b) 测试用例组 8
表 2-23(a) 测试用例组 8
2.4.1 逻辑覆盖测试第二章 软件测试方法应该注意的是，上面 6种覆盖测试方法所引用的公共程序只有短短
4行，是一段非常简单的示例代码。然而在实际测试程序中，一个简短的程序，其路径数目是一个庞大的数字。要对其实现路径覆盖测试是很难的。所以，路径覆盖测试是相对的，要尽可能把路径数压缩到一个可承受范围。
当然，即便对某个简短的程序段做到了路径覆盖测试，也不能保证源代码不存在其他软件问题了。其他的软件测试手段也必要的，
它们之间是相辅相成的。没有一个测试方法能够找尽所有软件缺陷，只能说是尽可能多地查找软件缺陷。
2.4.2 路径分析测试第二章 软件测试方法着眼于路径分析的测试称为路径分析测试。完成路径测试的理想情况是做到路径覆盖。路径覆盖也是白盒测试最为典型的问题。独立路径选择和 Z路径覆盖是两种常见的路径覆盖方法。
2.4.2.1 控制流图第二章 软件测试方法白盒测试是针对软件产品内部逻辑结构进行测试的，测试人员必须对测试中的软件有深入的理解，包括其内部结构、各单元部分及之间的内在联系，还有程序运行原理等等。因而这是一项庞大并且复杂的工作。为了更加突出程序的内部结构，便于测试人员理解源代码，可以对程序流程图进行简化，生成控制流图（ Control Flow
Graph）。简化后的控制流图是由节点和控制边组成的。
1．控制流图的特点控制流图有以下几个特点：
具有唯一入口节点，即源节点，表示程序段的开始语句；
具有唯一出口节点，即汇节点，表示程序段的结束语句；
节点由带有标号的圆圈表示，表示一个或多个无分支的源程序语句；
控制边由带箭头的直线或弧表示，代表控制流的方向。
2.4.2.1 控制流图第二章 软件测试方法常见的控制流图如图 2-9所示。
图 2-9 常见的控制流图
2.4.2.1 控制流图第二章 软件测试方法包含条件的节点被称为判断节点，由判断节点发出的边必须终止于某一个节点。
2,程序环路复杂性程序的环路复杂性是一种描述程序逻辑复杂度的标准，该标准运用基本路径方法，给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。
给定一个控制流图 G，设其环形复杂度为 V(G)，在这里介绍三种常见的计算方法来求解 V(G)。
(1) V(G)=E-N+2，其中 E是控制流图 G中边的数量,N是控制流图中节点的数目。
(2) V(G)=P+1，其中 P是控制流图 G中判断节点的数目。
(3) V(G)=A，其中 A是控制流图 G中区域的数目。由边和结点围成的区域叫做区域，当在控制流图中计算区域的数目时，控制流图外的区域也应记为一个区域。
2.4.2.2 独立路径测试第二章 软件测试方法从 4.1节逻辑覆盖测试一节中可知，对于一个较为复杂的程序要做到完全的路径覆盖测试是不可能实现的。既然路径覆盖测试无法达到，
那么可以对某个程序的所有独立路径进行测试，也就是说检验了程序的每一条语句，从而达到语句覆盖，这种测试方法就是独立路径测试方法。从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。路径可以用控制流图中的节点序列来表示。
例如，在如图 2-10所示的控制流图中，一组独立的路径是
path1,1 -> 11
path2,1 -> 2 -> 3 -> 4 -> 5 -> 10 -> 1 -> 11
path3,1 -> 2 -> 3 -> 6 -> 8 -> 9 -> 10 -> 1 -> 11
path4,1 -> 2 -> 3 -> 6 -> 7 -> 9 -> 10 -> 1 -> 11
2.4.2.2 独立路径测试第二章 软件测试方法路径 path1,path2,path3,path4组成了控制流图的一个基本路径集。
白盒测试可以设计成基本路径集的执行过程。通常，基本路径集并不唯一确定。
独立路径测试的步骤包括 3个方面：
导出程序控制流图求出程序环形复杂度设计测试用例（ Test Case ）
下面通过一个 C语言程序实例来具体说明独立路径测试的设计流程。这段程序是统计一行字符中有多少个单词，单词之间用空格分隔开。
2.4.2.2 独立路径测试第二章 软件测试方法程序 4-2：
1 main ()
2 {
3 int num1=0,num2=0,score=100;
4 int i;
5 char str;
6 scanf (“%d,%c\n”,&i,&str);
7 while (i<5)
8 {
9 if (str=’T’)
10 num1++;
11 else if (str=’F’)
12 {
13 score=score-10;
14 num2 ++;
15 }
16 i++;
17 }
18 printf (“num1=%d,num2=%d,score=%d\n”,num1,num2,score);
19 }
2.4.2.2 独立路径测试第二章 软件测试方法图 2-10 控制流图示例
1．导出程序控制流图根据源代码可以导出程序的控制流图，如图 2-11所示。每个圆圈代表控制流图的节点，可以表示一个或多个语句。圆圈中的数字对应程序中某一行的编号。
箭头代表边的方向，即控制流方向。
2.4.2.2 独立路径测试第二章 软件测试方法
2.4.2.2 独立路径测试第二章 软件测试方法图 2-11 程序 4-2的控制流图
2．求出程序环形复杂度根据程序环形复杂度的计算公式，求出程序路径集合中的独立路径数目。
公式 1,V(G)=10-8+2，其中 10是控制流图 G中边的数量,8是控制流图中节点的数目。
公式 2,V(G)=3+1，其中 3是控制流图 G中判断节点的数目。
公式 3,V(G)=4，其中 4是控制流图 G中区域的数目。
因此，控制流图 G的环形复杂度是 4。就是说至少需要 4条独立路径组成基本路径集合，并由此得到能够覆盖所有程序语句的测试用例。
2.4.2.2 独立路径测试第二章 软件测试方法
2.4.2.2 独立路径测试第二章 软件测试方法
3．设计测试用例根据上面环形复杂度的计算结果，源程序的基本路径集合中有 4条独立路径：
path1,7->18
path2,7->9->10->16->7->18
path3,7->9->11->15->16->7->18
path4,7->9->11->13->14->15->16->7->18
根据上述 4条独立路径，设计了测试用例组 9，如表 2-24所示。测试用例组 9中的 4个测试用例作为程序输入数据，能够遍历这
4条独立路径。对于源程序中的循环体，测试用例组 9中的输入数据使其执行零次或一次。
2.4.2.2 独立路径测试第二章 软件测试方法测试用例 输入 期望输出 执行路径i str num1 num2 score
Test Case 1 5 ‘T’ 0 0 100 路径 1
Test Case 2 4 ‘T’ 1 0 100 路径 2
Test Case 3 4 ‘A’ 0 0 100 路径 3
Test Case 4 4 ‘F’ 0 1 90 路径 4
表 2-24 测试用例组 9
注意：如果程序中的条件判断表达式是由一个或多个逻辑运算符（ or,and，
not）连接的复合条件表达式，则需要变换为一系列只有单个条件的嵌套的判断。
2.4.2.2 独立路径测试第二章 软件测试方法例如：
程序 4-3：
1 if (a or b)
2 then
3 procedure x
4 else
5 procedure y;
6 … …
对应的控制流图如图 2-12所示，程序行 1的 a,b都是独立的判断节点，还有程序行 4也是判断节点，所以共计 3个判断节点。图 2-12的环形复杂度为 V(G)=3+1，其中 3是图 2-12中判断节点的数目。
2.4.2.2 独立路径测试第二章 软件测试方法图 2-12 程序 4-3的控制流图
2.4.2.3 Z路径覆盖测试第二章 软件测试方法和独立路径选择一样,Z路径覆盖也是一种常见的路径覆盖方法。可以说
Z路径覆盖是路径覆盖面的一种变体。对于语句较少的简单程序，路径覆盖是具有可行性的。但是对于源代码很多的复杂程序，或者对于含有较多条件语句和较多循环体的程序来说，需要测试的路径数目会成倍增长，达到一个巨大数字，以至于无法实现路径覆盖。
为了解决这一问题，必须舍弃一些不重要的因素，简化循环结构，从而极大地减少路径的数量，使得覆盖这些有限的路径成为可能。采用简化循环方法的路径覆盖就是 Z路径覆盖。
所谓简化循环就是减少循环的次数。不考虑循环体的形式和复杂度如何，
也不考虑循环体实际上需要执行多少次，只考虑通过循环体零次和一次这两种情况。这里的零次循环是指跳过循环体，从循环体的入口直接到循环体的出口。通过一次循环体是指检查循环初始值。
根据简化循环的思路，循环要么执行，要么跳过，这和判定分支的效果是一样的。可见，简化循环就是将循环结构转变成选择结构。
1,简述软件测试技术从不同角度加以划分的多种方法。
2,简述静态测试和动态测试的区别。
3,举例说明黑盒测试的几种测试方法。
4,举例说明覆盖测试的几种测试方法。
5,简述白盒测试的相关方法。
6,比较阐述黑盒测试和白盒测试的优缺点。
习题
2.1 软件测试方法概述
2.2 静态测试与动态测试
2.3 黑盒测试
2.4 白盒测试习题本章概要第二章 软件测试方法
软件测试方法概述
静态测试和动态测试
黑盒测试和白盒测试
2.1 软件测试方法概述第二章 软件测试方法软件测试的方法多种多样，可以从不同角度加以分类：
从是否需要执行被测软件的角度，分为静态测试和动态测试；
从是针对系统的外部功能还是针对系统的内部结构的角度，分为黑盒测试和白盒测试；
从软件测试的策略和过程的角度，分为单元测试、集成测试、确认测试、系统测试和验收测试等。
2.1 软件测试方法概述第二章 软件测试方法
1．从是否需要执行被测软件的角度分类从是否需要执行被测软件的角度，软件测试可分为静态测试（ Static
Testing）和动态测试 (Dynamic Testing)。顾名思义，静态测试就是通过对被测程序的静态审查，发现代码中潜在的错误。它一般用人工方式脱机完成，故亦称人工测试或代码评审（ Code Review） ;也可借助于静态分析器在机器上以自动方式进行检查，但不要求程序本身在机器上运行。按照评审的不同组织形式，代码评审又可分为代码会审，走查以及办公桌检查，同行评分 4种。对某个具体的程序，通常只使用一种评审方式。
动态测试是通常意义上的测试，即使用和运行被测软件。动态测试的对象必须是能够由计算机真正运行的被测试的程序，它包含黑盒测试和白盒测试，在 2.3节将会具体介绍这两种方法。
2.1 软件测试方法概述第二章 软件测试方法
2．从软件测试用例设计方法的角度分类从软件测试用例设计方法的角度，可分为黑盒测试（ Black-Box Testing）和白盒测试（ White-Box Testing）。
黑盒测试是一种从用户角度出发的测试，又称为功能测试。数据驱动测试和基于规格说明的测试。使用这种方法进行测试时，把被测试程序当作一个黑盒，忽略程序内部的结构的特性，测试者在只知道该程序输入和输出之间的关系或程序功能的情况下，依靠能够反映这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。简单地说，若测试用例的设计是基于产品的功能，目的是检查程序各个功能是否实现，并检查其中的功能错误，则这种测试方法称为黑盒。
白盒测试基于产品的内部结构来进行测试，检查内部操作是否按规定执行
，软件各个部分功能是否得到充分利用。白盒测试又称为结构测试，逻辑驱动测试或基于程序的测试。即根据被测程序的内部结构设计测试用例，测试者需要预先了解被测试程序的结构。
2.1 软件测试方法概述第二章 软件测试方法
3．从软件测试的策略和过程的角度分类。
按照软件测试的策略和过程分类，软件测试可分为单元测试（ Unit Testing），集成测试（ Integration Testing），确认测试（ Validation Testing），系统测试（ System
Testing）和验收测试（ Verification Testing）。
单元测试是针对每个单元的测试，是软件测试的最小单位。它确保每个模块能正常工作。单元测试主要采用白盒测试方法，用以发现内部错误。
集成测试是对已测试过的模块进行组装，进行集成测试的目的主要在于检验与软件设计相关的程序结构问题。在集成测试过程中，测试人员采用黑盒测试和白盒测试两种方法，来验证多个单元模块集成到一起后是否能够协调工作。
确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。
系统测试的主要任务是检测被测软件与系统的其他部分的协调性，通常采用黑盒测试方法。
验收测试是软件产品质量的最后一关。这一环节，测试主要从用户的角度着手，其参与者主要是用户和少量的程序开发人员，通常采用黑盒测试方法。
2.2 静态测试与动态测试第二章 软件测试方法根据程序是否运行可以把软件测试方法分为静态测试（ Static Testing）和动态测试（ Dynamic Testing）两大类。图 2-1是静态测试与动态测试的比喻图。
图 2-1 静态测试与动态测试的比喻图
2.2.1 静态测试第二章 软件测试方法静态方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序，只对被测程序进行特性分析。因此，静态方法常称为
“分析”，静态分析是对被测程序进行特性分析的一些方法的总称。所谓静态分析，就是不需要执行所测试的程序，而只是通过扫描程序正文，对程序的数据流和控制流等信息进行分析，找出系统的缺陷，得出测试报告。
静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。
2.2.1 静态测试第二章 软件测试方法通常在静态测试阶段进行以下一些测试活动：
检查算法的逻辑正确性，确定算法是否实现了所要求的功能；
检查模块接口的正确性，确定形参的个数、数据类型、顺序是否正确，确定返回值类型及返回值的正确性；
检查输入参数是否有合法性检查。如果没有合法性检查，则应确定该参数是否不需要合法性检查，否则应加上参数的合法性检查；
检查调用其他模块的接口是否正确，检查实参类型、实参个数是否正确，返回值是否正确。若被调用模块出现异常或错误，
程序是否有适当的出错处理代码；
检查是否设臵了适当的出错处理，以便在程序出错时，能对出错部分进行重做安排，保证其逻辑的正确性；
检查表达式、语句是否正确，是否含有二义性。例如，下列表达式或运算符的优先级,<=,=,>=,&&,||,++,--等；
检查常量或全局变量使用是否正确；
检查标识符的使用是否规范、一致，变量命名是否能够望名知义、
简洁、规范和易记；
检查程序风格的一致性、规范性，代码是否符合行业规范，是否所有模块的代码风格一致、规范；
检查代码是否可以优化，算法效率是否最高；
检查代码注释是否完整，是否正确反映了代码的功能，并查找错误的注释。
2.2.1 静态测试第二章 软件测试方法
2.2.1 静态测试第二章 软件测试方法静态分析的差错分析功能是编译程序所不能替代的。编译系统虽然能发现某些程序错误，但这些错误远非软件中存在的大部分错误。目前，已经开发了一些静态分析系统作为软件静态测试的工具，静态分析已被当作一种自动化的代码校验方法。
2.2.2 动态测试第二章 软件测试方法动态方法是通过源程序运行时所体现出来的特征，来进行执行跟踪、时间分析以及测试覆盖等方面的测试。动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例，对其输入与输出的对应关系进行分析，以达到检测的目的。
动态测试方法的基本步骤：
选取定义域的有效值，或选取定义域外的无效值；
对已选取值决定预期的结果；
用选取值执行程序；
执行结果与预期的结果相比，不吻合则说明程序有错。
不同的测试方法各自的目标和侧重点不一样，在实际工作中要将静态测试和动态测试结合起来，以达到更加完美的效果。
在动态测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试。
2.3 黑盒测试方法第二章 软件测试方法黑盒测试（ Black-box Testing）又称为功能测试、数据驱动测试和基于规格说明的测试。是一种从用户观点出发的测试，
主要以软件规格说明书为依据，对程序功能和程序接口进行的测试。
黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。黑盒测试作为软件功能的测试手段，是重要的测试方法。它主要根据规格说明设计测试用例，并不涉及程序内部结构和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。
2.3.1 黑盒测试方法概述第二章 软件测试方法黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。很明显，如果外部特性本身有问题或规格说明书的规定有误，用黑盒测试方法是发现不了的。黑盒测试方法着重测试软件的功能需求，是在程序接口上进行测试，主要是为了发现以下错误：
1.是否有不正确的功能，是否有遗漏的功能；
2.在接口上，是否能够正确地接收输入数据并产生正确的输出结果；
3.是否有数据结构错误或外部信息访问错误；
4.性能上是否能够满足要求；
5.是否有程序初始化和终止方面的错误。
2.3.1 黑盒测试方法概述第二章 软件测试方法黑盒测试有两个显著的特点：
黑盒测试不考虑软件的具体实现过程，当在软件实现的过程发生变化时，测试用例仍然可以使用；
黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。
黑盒测试不仅能够找到大多数其他测试方法无法发现的错误，而且一些外购软件、参数化软件包以及某些自动生成的软件，由于无法得到源程序，在一些情况下只能选择黑盒测试。
2.3.1 黑盒测试方法概述第二章 软件测试方法黑盒测试有两种基本方法，即通过测试和失败测试。
在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何，软件测试人员只是运用最简单，最直观的测试案例。
在设计和执行测试案例时，总是先要进行通过测试，验证软件的基本功能是否都已实现。
在确信了软件正确运行之后，就可以采取各种手段通过搞垮软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。
黑盒测试的具体技术方法主要包括边界值分析法、等价类划分法
、因果图法、决策表法等。这些方法是比较实用的，在项目中采用什么方法，在设计具体的测试方案时自然要针对开发项目的特点对设计方法进行适当的选择。
2.3.2 等价类划分法第二章 软件测试方法
1,等价类划分法概述等价类划分法是黑盒测试用例设计中一种常用的设计方法，它将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性。
等价类划分法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。所谓等价类是指输入域的某个子集合，所有等价类的并集就是整个输入域。在等价类中，各个输入数据对于揭露程序中的错误都是等效的，它们具有等价特性。因此，测试某个等价类的代表值就是等价于对这一类中其他值的测试。也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；
反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。
2.3.2 等价类划分法第二章 软件测试方法软件不能只接收合理有效的数据，也要具有处理异常数据的功能，
这样的测试才能确保软件具有更高的可靠性。
因此，在划分等价类的过程中，不但要考虑有效等价类划分，同时也要考虑无效等价类划分。
有效等价类是指对软件规格说明来说，合理、有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。
无效等价类则和有效等价类相反，即不满足程序输入要求或者无效的输入数据所构成的集合。利用无效等价类可以检验程序异常情况的处理。
使用等价类划分法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，然后列出等价类表。
2.3.2 等价类划分法第二章 软件测试方法输入条件 有效等价类 无效等价类
… … …
… … …
在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表 2-1所示。
表 2-1 等价类表再根据已列出的等价类表，按以下步骤确定测试用例：
为每一个等价类规定一个唯一的编号；
设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类
，重复这个过程，直至所有的有效等价类均被测试用例所覆盖；
设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这个过程，
直至所有的无效等价类均被测试用例所覆盖。
以三角形问题为例，输入条件是：
三个数，分别作为三角形的三条边都是整数取值范围在 1～ 100之间认真分析上述的输入条件，可以得出相关的等价类表
（包括有效等价类和无效等价类），如表 2-2所示。
2.3.2 等价类划分法第二章 软件测试方法
2.3.2 等价类划分法第二章 软件测试方法输入条件 等价类编号 有效等价类 等价类编号 无效等价类三个数 1 三个数
4 只有一条边
5 只有两条边
6 多于三条边整数 2 整数
7 一边为非整数
8 两边为非整数
9 三边为非整数取值范围在
1~100 3
1≤a≤100
1≤b≤100
1≤c≤100
10 一边为 0
11 两边为 0
12 三边为 0
13 一边小于 0
14 两边小于 0
15 三边小于 0
16 一边大于 100
17 两边大于 100
18 三边大于 100
表 2-2 三角形问题的等价类
2.3.2 等价类划分法第二章 软件测试方法
2,常见等价类划分形式针对是否对无效数据进行测试，可以将等价类测试分为标准等价类测试、健壮等价类测试以及对等区间的划分。
(1) 标准等价类测试标准等价类测试不考虑无效数据值，测试用例使用每个等价类中的一个值。通常
，标准等价类测试用例的数量和最大等价类中元素的数目相等。
以三角形问题为例，要求输入三个整数 a,b,c，分别作为三角形的三条边，取值范围在 1～ 100之间，判断由三条边构成的三角形类型为等边三角形、等腰三角形、
一般三角形（包括直角三角形）以及非三角形。在多数情况下，是从输入域划分等价类，但对于三角形问题，从输出域来定义等价类是最简单的划分方法。
因此，利用这些信息可以确定下列值域等价类：
R1={〈 a,b,c〉,边为 a,b,c 的等边三角形 }
R2={〈 a,b,c〉,边为 a,b,c 的等腰三角形 }
R3={〈 a,b,c〉,边为 a,b,c 的一般三角形 }
R4={〈 a,b,c〉,边为 a,b,c 不构成三角形 }
4个标准等价类测试用例如表 2-3所示。
2.3.2 等价类划分法第二章 软件测试方法测试用例 a b c 预期输出
Test Case 1 10 10 10 等边三角形
Test Case 2 10 10 5 等腰三角形
Test Case 3 3 4 5 一般三角形
Test Case 4 1 1 5 不构成三角形表 2-3 三角形问题的标准等价类测试用例
2.3.2 等价类划分法第二章 软件测试方法
(2) 健壮等价类测试健壮等价类测试主要的出发点是考虑了无效等价类。
对有效输入，测试用例从每个有效等价类中取一个值； 对无效输入，一个测试用例有一个无效值，其他值均取有效值。
健壮等价类测试存在两个问题：
需要花费精力定义无效测试用例的期望输出；
对强类型的语言没有必要考虑无效的输入 。
2.3.2 等价类划分法第二章 软件测试方法
(3) 对等区间划分对等区间划分是测试用例设计的非常规形式化的方法。它将被测对象的输入 /输出划分成一些区间，被测软件对一个特定区间的任何值都是等价的。形成测试区间的数据不只是函数 /过程的参数，也可以是程序可以访问的全局变量、系统资源等，这些变量或资源可以是以时间形式存在的数据，或以状态形式存在的输入 /输出序列。
对等区间划分假定位于单个区间的所有值对测试都是对等的，应为每个区间的一个值设计一个测试用例。
举例说明如下：
平方根函数要求当输入值为 0或大于 0时，返回输入数的平方根；
当输入值小于 0时，显示错误信息“平方根错误，输入值小于 0”，并返回 0。
输入区间 输出区间
ⅰ <0 A >=0
ⅱ >=0 B Error
考虑平方根函数的测试用例区间，可以划分出两个输入区间和两个输出区间，如表 2-5所示。
表 2-5 区间划分通过分析，可以用两个测试用例来测试 4个区间：
测试用例 1：输入 4，返回 2 //区间 ⅱ 和 A
测试用例 2：输入 -4，返回 0，输出“平方根错误，输入值小于 0”
//区间 ⅰ 和 B
上例的对等区间划分是非常简单的。当软件变得更加复杂时，对等区间的确定就越难，区间之间的相互依赖性就越强，使用对等区间划分设计测试用例技术的难度会增加。
2.3.2 等价类划分法第二章 软件测试方法
2.3.3 边界值分析法第二章 软件测试方法
1,边界值分析法边界值分析法（ Boundary Value Analysis,BVA）是一种补充等价类划分法的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。在测试过程中，可能会忽略边界值的条件，而软件设计中大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
在实际的软件设计过程中，会涉及到大量的边界值条件和过程，
这里有一个简单的 VB程序的例子：
Dim data(10) as Integer
Dim i as Integer
For i=1 to 10
data(i)=1
Next i
2.3.3 边界值分析法第二章 软件测试方法在这个程序中，目标是为了创建一个拥有 10个元素的一维数组，
看似合理，但是，在大多数 Basic语言中，当一个数组被定义时，其第一个元素所对应的数组下标是 0而不是 1。由此，上述程序运行结束后，数组中成员的赋值情况如下：
data(0)=0,data(1)=1,data(2)=1,...,data(10)=1
这时，如果其他程序员在使用这个数组的时候，可能会造成软件的缺陷或者错误的产生。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
2.3.3 边界值分析法第二章 软件测试方法在应用边界值分析法设计测试用例时，应遵循以下几条原则：
如果输入条件规定了值的范围，则应该选取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。
如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少 1、比最大个数多 1的数作为测试数据。
根据规格说明的每一个输出条件，分别使用以上两个原则。
如果程序的规格说明给出的输入域或者输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个元素和最后一个元素作为测试用例。
如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界值作为测试用例。
分析规格说明，找出其他可能的边界条件。
第二章 软件测试方法
2,边界条件与次边界条件边界值分析法是对输入的边界值进行测试。在测试用例设计中，需要对输入的条件进行分析并且找出其中的边界值条件，通过对这些边界值的测试来查出更多的错误。
提出边界条件时，一定要测试临近边界的有效数据，测试最后一个可能有效的数据，同时测试刚超过边界的无效数据。通常情况下，软件测试所包含的边界检验有几种类型：数值、字符、位置、数量、速度、尺寸等，在设计测试用例时要考虑边界检验的类型特征：第一个 /
最后一个、开始 /完成、空 /满、最大值 /最小值、最快 /最慢、最高 /最低、最长 /最短等。这些不是确定的列表，而是一些可能出现的边界条件。
2.3.3 边界值分析法第二章 软件测试方法
2.3.3 边界值分析法在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户通常最容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到这些问题，但这些边界条件同时确实属于检验范畴内的边界条件，称为内部边界值条件或次边界值条件。主要有下面几种：
第二章 软件测试方法
2.3.3 边界值分析法项 范围或值位（ bit） 0或 1
字节（ byte） 0~255
字（ word） 0~65,535（单字）或 0~4,294,967,295（双字）
千（ K） 1 024
兆（ M） 1 048 576
吉（ G） 1 073 741 824
太（ T） 1 099 511 627 776
数值的边界值检验计算机是基于二进制进行工作的，因此，任何数值运算都有一定的范围限制，如表 2-7所示。
表 2-7 计算机数值运算的范围例如对字节进行检验，边界值条件可以设置成 254,255和 256。
第二章 软件测试方法
2.3.3 边界值分析法字符 ASCII码值 字符 ASCII码值空（ null） 0 A 65
空格（ space） 32 a 97
斜杠（ /） 47 左中括号（ [） 91
0 48 Z 122
冒号（：） 58 Z 90
@ 64 单引号（‘） 96
字符的边界值检验在字符的编码方式中,ASCII和 Unicode是比较常见的编码方式
，表 2-8中列出了一些简单的 ASCII码对应表。
表 2-8 字符的 ASCII码对应表第二章 软件测试方法
2.3.3 边界值分析法在做文本输入或者文本转换的测试过程中，需要非常清晰地了解 ASCII码的一些基本对应关系，例如小写字母 z和大写字母 Z在表中的对应是不同的，这些也必须被考虑到数据区域划分的过程中，从而定义等价有效类，来设计测试用例。
其他边界值检验包括默认值 /空值 /空格 /未输入值 /零、无效数据 /不正确数据和干扰数据等。
在实际的测试用例设计中，需要将基本的软件设计要求和程序定义的要求结合起来，即结合基本边界值条件和子边界值条件来设计有效的测试用例。
第二章 软件测试方法
2.3.3 边界值分析法
3,边界值分析法测试用例以三角形问题为例，要求输入三个整数 a,b,c，分别作为三角形的三条边，取值范围在 1～ 100之间，判断由三条边构成的三角形类型为等边三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。如表 2-9所示给出了边界值分析测试用例。
第二章 软件测试方法
2.3.3 边界值分析法测试用例 a b c 预期输出
Test Case 1 1 50 50 等腰三角形
Test Case 2 2 50 50 等腰三角形
Test Case 3 50 50 50 等边三角形
Test Case 4 99 50 50 等腰三角形
Test Case 5 100 50 50 非三角形
Test Case 6 50 1 50 等腰三角形
Test Case 7 50 2 50 等腰三角形
Test Case 8 50 99 50 等腰三角形
Test Case 9 50 100 50 非三角形
Test Case 10 50 50 1 等腰三角形
Test Case 11 50 50 2 等腰三角形
Test Case 12 50 50 99 等腰三角形
Test Case 13 50 50 100 非三角形表 2-9边界值分析测试用例
2.3.4决策表法第二章 软件测试方法
1,决策表法在所有的黑盒测试方法中，基于决策表（也称判定表）的测试是最为严格、最具有逻辑性的测试方法。决策表是分析和表达多个逻辑条件下执行不同操作情况的工具。由于决策表可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确，在程序设计发展的初期，
决策表就已被当作编写程序的辅助工具了。
决策表通常由四个部分组成，如图 2-2所示。
条件桩：列出了问题的所有条件，通常认为列出的条件的先后次序无关紧要。
动作桩：列出了问题规定的可能采取的操作，这些操作的排列顺序没有约束。
条件项：针对条件桩给出的条件列出所有可能的取值。
动作项：与条件项紧密相关，列出在条件项的各组取值情况下应该采取的动作。
2.3.4决策表法第二章 软件测试方法图 2-2 决策表的组成
2.3.4决策表法第二章 软件测试方法任何一个条件组合的特定取值及其相应要执行的操作称为一条规则，
在决策表中贯穿条件项和动作项的一列就是一条规则。显然，决策表中列出多少组条件取值，也就有多少条规则，即条件项和动作项有多少列。
根据软件规格说明，建立决策表的步骤如下：
① 确定规则的个数。假如有 n个条件，每个条件有两个取值，故有
2n种规则。
② 列出所有的条件桩和动作桩。
③ 填入条件项。
④ 填入动作项，得到初始决策表。
⑤ 化简。合并相似规则（相同动作）。
2.3.4决策表法第二章 软件测试方法以下列问题为例给出构造决策表的具体过程。
如果某产品销售好并且库存低，则增加该产品的生产；如果该产品销售好，但库存量不低，则继续生产；若该产品销售不好，但库存量低，则继续生产；若该产品销售不好，且库存量不低，则停止生产。
2.3.4决策表法第二章 软件测试方法解法如下：
确定规则的个数。对于本题有 2个条件（销售、库存），每个条件可以有两个取值，故有 22=4种规则。
列出所有的条件桩和动作桩。
填入条件项。
填入动作项，得到初始决策表，如表 2-10所示。
每种测试方法都有适用的范围，决策表法适用于下列情况：
规格说明以决策表形式给出，或很容易转换成决策表。
条件的排列顺序不会也不应影响执行哪些操作。
规则的排列顺序不会也不应影响执行哪些操作。
每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。
2.3.4决策表法第二章 软件测试方法规则选项
1 2 3 4
条件：
C1：销售好?
C2：库存低?
T
T
T
F
F
T
F
F
动作：
a1：增加生产
a2：继续生产
a3：停止生产
√ √ √ √
表 2-10 产品销售问题的决策表
2.3.4决策表法第二章 软件测试方法
2,决策表法的应用决策表最突出的优点是，能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。运用决策表设计测试用例，可以将条件理解为输入，将动作理解为输出。
以三角形问题为例，要求输入三个整数 a,b,c，分别作为三角形的三条边，取值范围在 1～ 100之间，判断由三条边构成的三角形类型为等边三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。
2.3.4决策表法第二章 软件测试方法分析如下：
确定规则的个数。例如，三角形问题的决策表有 4个条件，每个条件可以取两个值（真值和假值），所以应该有 24=16种规则。
列出所有条件桩和动作桩。
填写条件项。
填写动作项，从而得到初始决策表。如表 2-11所示。
简化决策表。合并相似规则后得到三角形问题的简化决策表。如表 2-12所示。
2.3.4决策表法第二章 软件测试方法规则选项 1 2 3 4 5 6 7 8
条件：
C1,a,b,c构成一个三角形？
C2,a=b？
C3,b=c？
C4,a=c？
F
T
T
T
F
T
T
F
F
T
F
T
F
T
F
F
F
F
T
T
F
F
T
F
F
F
F
T
F
F
F
F
动作：
a1：非三角形
a2：一般三角形
a3：等腰三角形
a4：等边三角形
a5：不可能
√ √ √ √ √ √ √ √
表 2-11 三角形问题的初始决策表
2.3.4决策表法第二章 软件测试方法规则选项 9 10 11 12 13 14 15 16
条件：
C1,a,b,c构成一个三角形？
C2,a=b？
C3,b=c？
C4,a=c？
T
T
T
T
T
T
T
F
T
T
F
T
T
T
F
F
T
F
T
T
T
F
T
F
T
F
F
T
T
F
F
F
动作：
a1：非三角形
a2,一般三角形
a3,等腰三角形
a4,等边三角形
a5：不可能
√
√ √ √ √ √ √ √
2.3.4决策表法第二章 软件测试方法规则选项 1～8 9 10 11 12 13 14 15 16
条件：
C1,a,b,c构成一个三角形？
C2,a=b？
C3,b=c？
C4,a=c？
F
－
－
－
T
T
T
T
T
T
T
F
T
T
F
T
T
T
F
F
T
F
T
T
T
F
T
F
T
F
F
T
T
F
F
F
动作：
a1：非三角形
a2：一般三角形
a3：等腰三角形
a4：等边三角形
a5：不可能
√
√
√ √ √ √ √ √ √
表 2-12 三角形问题的简化决策表
2.3.4决策表法第二章 软件测试方法测试用例 a b c 预期输出
Test Case 1 10 4 4 非三角形
Test Case 2 4 4 4 等边三角形
Test Case 3 不可能
Test Case 4 不可能
Test Case 5 4 4 5 等腰三角形
Test Case 6 不可能
Test Case 7 5 4 4 等腰三角形
Test Case 8 4 5 4 等腰三角形
Test Case 9 3 4 5 一般三角形根据决策表 2-12，可设计测试用例，如表 2-13所示。
表 2-13 三角形问题的决策表测试用例
2.3.5因果图法第二章 软件测试方法
1,因果图法前面介绍的等价类划分法和边界值分析法都着重考虑输入条件，
而没有考虑到输入条件的各种组合情况，也没有考虑到各个输入条件之间的相互制约关系。因此，必须考虑采用一种适合于多种条件的组合，相应能产生多个动作的形式来进行测试用例的设计，这就需要采用因果图法。因果图法就是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。
在因果图中使用 4种符号分别表示 4种因果关系，如图 2-3所示。用直线连接左右节点，其中左节点 Ci表示输入状态（或称原因），右节点 ei表示输出状态（或称结果）。 Ci和 ei都可取值 0或 1,0表示某状态不出现,1表示某状态出现。
2.3.5因果图法第二章 软件测试方法
（ a）恒等图 2-3 因果图的基本符号
（ b）非
（ c）或 （ d）与
2.3.5因果图法第二章 软件测试方法图 2-3中各符号的含义如下：
图 (a)：表示恒等。若 C1是 1，则 e1也是 1；若 C1是 0，则 e1为 0。
图 (b)：表示非。若 C1是 1，则 e1是 0；若 C1是 0，则 e1为 1。
图 (c)：表示或。若 C1或 C2或 C3是 1，则 e1是 1；若 C1,C2,C3全为 0
，则 e1为 0。
图 (d)：表示与。若 C1和 C2都是 1，则 e1是 1；只要 C1,C2,C3中有一个为 0，则 e1为 0。
在实际问题中，输入状态相互之间还可能存在某些依赖关系，我们称之为约束。例如，某些输入条件不可能同时出现。输出状态之间也往往存在约束，在因果图中，以特定的符号标明这些约束，如图 2-4所示。
2.3.5因果图法第二章 软件测试方法
（ a）异 （ b）或
（ c）惟一图 2-4 约束符号
（ d）要求 （ e）强制
2.3.5因果图法第二章 软件测试方法
2.3.5因果图法第二章 软件测试方法图 2-4中对输入条件的约束如下：
图 (a)：表示 E约束（异）。 a和 b中最多有一个可能为 1，即 a和 b不能同时为 1。
图 (b)：表示 I约束（或）。 a,b和 c中至少有一个必须是 1，即 a、
b和 c不能同时为 0。
图 (c)：表示 O约束（唯一）。 a和 b中必须有一个且仅有一个为 1。
图 (d)：表示 R约束（要求）。 a是 1时,b必须是 1，即 a是 1时,b
不能是 0。
对输出条件的约束只有 M约束。
M约束（强制）：若结果 a是 1，则结果 b强制为 0。
因果图法最终要生成决策表。
2.3.5因果图法第二章 软件测试方法利用因果图法生成测试用例需要以下几个步骤：
分析软件规格说明书中的输入输出条件，并且分析出等价类。分析规格说明中的语义的内容，通过这些语义来找出相对应的输入与输入之间，输入与输出之间的对应关系。
将对应的输入与输入之间，输入与输出之间的关系连接起来，并且将其中不可能的组合情况标注成约束或者限制条件，形成因果图
。
将因果图转换成决策表。
将决策表的每一列作为依据，设计测试用例。
上述步骤如图 2-5所示。
从因果图生成的测试用例中包括了所有输入数据取真值和假值的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。
2.3.5因果图法第二章 软件测试方法某软件规格说明中包含这样的要求：输入的第一个字符必须是 A
或 B，第二个字符必须是一个数字，在此情况下进行文件的修改；
但如果第一个字符不正确，则给出信息 L；如果第二个字符不是数字，则给出信息 M。
2.3.5因果图法第二章 软件测试方法图 2-5 因果图法示例
2.3.5因果图法第二章 软件测试方法解法如下：
分析程序的规格说明，列出原因和结果。
原因,C1----第一个字符是 A
C2----第一个字符是 B
C3----第二个字符是一个数字结果,e1----给出信息 L
e2----修改文件
e3----给出信息 M
2.3.5因果图法第二章 软件测试方法将原因和结果之间的因果关系用逻辑符号连接起来，得到因果图，如图 2-6所示。编号为
11的中间节点是导出结果的进一步原因。
图 2-6 因果图示例
2.3.5因果图法第二章 软件测试方法因为 C1和 C2不可能同时为 1，即第一个字符不可能既是 A又是 B，在因果图上可对其施加 E约束，得到具有约束的因果图，如图 2-7所示。
图 2-7 具有 E约束的因果图
2.3.5因果图法第二章 软件测试方法将因果图转换成决策表，如表 2-14所示。
规则选项 1 2 3 4 5 6 7 8
条件
C1 1 1 1 1 0 0 0 0
C2 1 1 0 0 1 1 0 0
C3 1 0 1 0 1 0 1 0
11 1 1 1 1 0 0
动作
e1 0 0 0 0 1 1
e2 1 0 1 0 0 0
e3 0 1 0 1 0 1
不可能 1 1
测试用例 A5 A# B9 B? X2 Y
%
表 2-14 决策表
2.3.5因果图法第二章 软件测试方法设计测试用例。表 2-14中的前两种情况，因为 C1和 C2不可能同时为 1，所以应排除这两种情况。根据此表，可以设计出 6个测试用例，如表 2-15所示。
编号 输入数据 预期输出
Test Case 1 A5 修改文件
Test Case 2 A# 给出信息 M
Test Case 3 B9 修改文件
Test Case 4 B? 给出信息 M
Test Case 5 X2 给出信息 L
Test Case 6 Y% 给出信息 L和信息 M
表 2-15 测试用例
2.3.6 各种黑盒测试方法的选择第二章 软件测试方法为了最大程度地减少测试遗留的缺陷，同时也为了最大限度地发现存在的缺陷，在测试实施之前，测试工程师必须确定将要采用的黑盒测试策略和方法，并以此为依据制定详细的测试方案。通常，一个好的测试策略和测试方法必将给整个测试工作带来事半功倍的效果。
如何才能确定好的黑盒测试策略和测试方法呢？通常，在确定黑盒测试方法时，应该遵循以下原则：
根据程序的重要性和一旦发生故障将造成的损失程度来确定测试等级和测试重点。
认真选择测试策略，以便能尽可能少地使用测试用例，发现尽可能多的程序错误。因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次测试是不足的，而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度又会带来资源的浪费。因此，
测试需要找到一个平衡点。
以下是各种黑盒测试方法选择的综合策略，可在实际应用过程中参考。
首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，
这是减少工作量和提高测试效率的最有效方法。
在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准
，应当再补充足够的测试用例。
如果程序的功能说明中含有输入条件的组合情况，则应在一开始就选用因果图法。
2.3.7 黑盒测试的优缺点第二章 软件测试方法黑盒测试是一种确认技术，目的是确认“设计的系统是否正确”。黑盒测试是以用户的观点，从输入数据与输出数据的对应关系，也就是根据程序外部特性进行的测试，而不考虑内部结构及工作情况；黑盒测试技术注重于软件的信息域（范围），通过划分程序的输入和输出域来确定测试用例；若外部特性本身存在问题或规格说明的规定有误，则应用黑盒测试方法是不能发现问题的。
黑盒测试的优点如下：
① 适用于各个测试阶段；
② 从产品功能角度进行测试；
③ 容易入手生成测试数据。
黑盒测试的缺点如下：
① 某些代码得不到测试；
② 如果规则说明有误，无法发现；
③ 不易进行充分行测试。
2.4 白盒测试第二章 软件测试方法白盒测试（ White-box Testing）也称作结构测试或逻辑驱动测试，
它是知道产品的内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。按照程序内部的结构测试程序，
检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。白盒测试的主要方法有逻辑覆盖、基本路径测试等，主要用于软件验证。
2.4 白盒测试第二章 软件测试方法通常的程序结构覆盖有：
语句覆盖；
判断覆盖；
条件覆盖；
判断 /条件覆盖；
条件组合覆盖；
路径覆盖。
2.4 白盒测试第二章 软件测试方法语句覆盖是最常见也是最弱的逻辑覆盖准则，它要求设计若干个测试用例，使被测程序的每个语句都至少被执行一次。判定覆盖或分支覆盖则要求设计若干个测试用例，使被测程序的每个判定的真、
假分支都至少被执行一次。但判定含有多个条件时，可以要求设计若干个测试用例，使被测程序的每个条件的真、假分支都至少被执行一次，即条件覆盖。在考虑对程序路径进行全面检验时，即可使用条件覆盖准则。
虽然结构测试提供了评价测试的逻辑覆盖准则，但结构测试是不完全的。如果程序结构本身存在问题，比如程序逻辑错或者遗漏了规格说明书中已规定的功能，那么，无论哪种结构测试，即使其覆盖率达到了百分之百，也是检查不出来的。因此，提高结构测试的覆盖率，可以增强对被测软件的信度，但并不能做到万无一失。
2.4.1 逻辑覆盖测试第二章 软件测试方法白盒测试技术的常见方法之一就是覆盖测试，它是利用程序的逻辑结构设计相应的测试用例。测试人员要深入了解被测程序的逻辑结构特点，完全掌握源代码的流程，才能设计出恰当的用例。根据不同的测试要求，覆盖测试可以分为语句覆盖、判断覆盖、条件覆盖、判断 /条件覆盖、条件组合覆盖和路径覆盖。
下面是一段简单的 C语言程序，作为公共程序段来说明五种覆盖测试的各自特点。
程序 2-1：
1 If (x>100&& y>500) then
2 score=score+1
3 If (x>=1000|| z>5000) then
4 score=score+5
逻辑运算符,&&”表示“与”的关系，逻辑运算符,||”表示“或”的关系
。其程序控制流图如图 2-8所示。
2.4.1 逻辑覆盖测试第二章 软件测试方法图 2-8 程序流程图
2.4.1 逻辑覆盖测试第二章 软件测试方法语句覆盖语句覆盖（ Statement Coverage）是指设计若干个测试用例，程序运行时每个可执行语句至少被执行一次。在保证完成要求的情况下，
测试用例的数目越少越好。
以下是针对公共程序段设计的两个测试用例，称为测试用例组 1。
Test Case 1,x=2000,y=600,z=6000
Test Case 2,x=900,y=600,z=5000
如表 2-16所示，采用 Test Case 1作为测试用例，则程序按路径 a,c,e
顺序执行，程序中的 4个语句都被执行一次，符合语句覆盖的要求。
采用 Test Case 2作为测试用例，则程序按路径 a,c,d顺序执行，
程序中的语句 4没有执行到，所以没有达到语句覆盖的要求。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600，6000 True True ace
Test Case 2 900,600，5000 True False acd
表 2-16 测试用例组 1
2.4.1 逻辑覆盖测试第二章 软件测试方法从表面上看，语句覆盖用例测试了程序中的每一个语句行，好像对程序覆盖得很全面，但实际上语句覆盖测试是最弱的逻辑覆盖方法。例如，第一个判断的逻辑运算符,&&”错误写成,||”，
或者第二个判断的逻辑运算符,||”错误地写成,&&”，这时如果采用 Test Case 1测试用例是检验不出程序中的判断逻辑错误的。
如果语句 3,If (x>=1000|| z>5000) then”错误写成,If
(x>=1500|| z>5000) then”,Test Case 1同样无法发现错误之处。
根据上述分析可知，语句覆盖测试只是表面上的覆盖程序流程，
没有针对源程序各个语句间的内在关系，设计更为细致的测试用例。
2.4.1 逻辑覆盖测试第二章 软件测试方法判断覆盖判断覆盖（ Branch Coverage）是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的真值分支和假值分支至少被执行一遍。在保证完成要求的情况下，测试用例的数目越少越好。判断覆盖又称为分支覆盖。
测试用例组 2：
Test Case 1,x=2000,y=600,z=6000
Test Case 3,x=50,y=600,z=2000
如表 2-17所示，采用 Test Case 1作为测试用例，程序按路径 a,c，
e顺序执行；采用 Test Case 3作为测试用例，程序按路径 a,b,d顺序执行。所以采用这一组测试用例，公共程序段的 4个判断分支 b,c，
d,e都被覆盖到了。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or (z>5000) 执行路径
Test Case 1 2000,600，6000 True True ace
Test Case 3 50,600，2000 False False abd
表 2-17 测试用例组 2
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例组 3：
Test Case 4,x=2000,y=600,z=2000
Test Case 5,x=2000,y=200,z=6000
如表 2-18所示，采用 Test Case 4作为测试用例，程序沿着路径 a，
c,d顺序执行；采用 Test Case 5作为测试用例，则程序沿着路径
a,b,e顺序执行。显然采用这组测试用例同样可以满足判断覆盖。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or (z>5000) 执行路径
Test Case 4 2000,600，2000 True False acd
Test Case 5 2000,200，6000 False True abe
表 2-18 测试用例组 3
2.4.1 逻辑覆盖测试第二章 软件测试方法实际上，测试用例组 2和测试用例组 3不仅达到了判断覆盖要求，
也同时满足了语句覆盖要求。某种程度上可以说判断覆盖测试要强于语句覆盖测试。但是，如果将第二个判断条件 ((x>=1000)or
(z>5000))中的 z>5000错误定义成 z的其他限定范围，由于判断条件中的两个判断式是“或”的关系，其中一个判断式错误是不影响结果的，所以这两组测试用例是发现不了问题的。因此，应该用具有更强逻辑覆盖能力的覆盖测试方法来测试这种内部判断条件。
2.4.1 逻辑覆盖测试第二章 软件测试方法条件覆盖条件覆盖（ Condition Coverage）是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件中的每个判断式的真值和假值至少被执行一遍。
测试用例组 4：
Test Case 1,x=2000,y=600,z=6000
Test Case 3,x=50,y=600,z=2000
Test Case 5,x=2000,y=200,z=6000
如表 2-19所示，把前面设计过的测试用例挑选出 Test Case 1,Test Case 3,Test Case 5组合成测试用例组 4，组中的 3个测试用例覆盖了 4个内部判断式的 8种真假值情况。同时这组测试用例也实现了判断覆盖。但是并不可以说判断覆盖是条件覆盖的子集。
测试用例组 5：
Test Case 6,50,600,6000
Test Case 7,2000,200,1000
如表 2-20(a) 和表 2-20(b)所示，其中表 2-20(a)表示每个判断条件的每个判断式的真值和假值，
表 2-20(b)表示每个判断条件的真值和假值。测试用例组 5中的 2个测试用例虽然覆盖了 4个内部判断式的 8种真假值情况。但是这组测试用例的执行路径是 abe，仅是覆盖了判断条件的 4
个真假分支中的 2个。所以，需要设计一种能同时满足判断覆盖和条件覆盖的覆盖测试方法，
即判断 /条件覆盖测试。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500)
(x>=100
0) (z>5000)
执行路径
Test
Case 1
2000，
600,6000 True True True False ace
Test
Case 3
50,600，
2000 False True False False abd
Test
Case 5
2000，
200,6000 True False True True abe
测试用例 x,y,z (x>100) (y>500)
(x>=100
0) (z>5000)
执行路径
Test
Case 6
50,600，
6000 False True False True abe
Test
Case 7
2000，
200,1000 True False True False abe
表 2-20(a) 测试用例组 5
表 2-19测试用例组 4
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 6 50,600，6000 False True abe
Test Case 7 2000,200，1000 False True abe
表 2-20(b) 测试用例组 5
2.4.1 逻辑覆盖测试第二章 软件测试方法判断 /条件覆盖判断 /条件覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的真假值分支至少被执行一遍，并且每个判断条件的内部判断式的真假值分支也要被执行一遍。
测试用例组 6：
Test Case 1,x=2000,y=600,z=2000
Test Case 6,x=2000,y=200,z=6000
Test Case 7,x=2000,y=600,z=2000
Test Case 8,x=50,y=200,z=2000
如表 2-21(a) 和表 2-21(b)所示，其中表 2-21(a)表示每个判断条件的每个判断式的真值和假值，表 2-21(b)表示每个判断条件的真值和假值。测试用例组 6虽然满足了判断覆盖和条件覆盖，但是没有对每个判断条件的内部判断式的所有真假值组合进行测试。条件组合判断是必要的，因为条件判断语句中的“与”和“或”，
即,&&”和,||”，会使内部判断式之间产生抑制作用。例如,C=A && B中，如果 A为假值，那么 C就为假值，测试程序就不检测 B了,B的正确与否就无法测试了。
同样,C=A || B中，如果 A为真值，那么 C就为真值，测试程序也不检测 B了,B的正确与否也就无法测试了。
2.4.1 逻辑覆盖测试第二章 软件测试方法条件组合覆盖条件组合覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的的内部判断式的各种真假组合可能都至少被执行一遍。可见，满足条件组合覆盖的测试用例组一定满足判断覆盖、条件覆盖和判断 /条件覆盖。
测试用例组 7：
Test Case 1,x=2000,y=600,z=2000
Test Case 6,x=2000,y=200,z=6000
Test Case 7,x=2000,y=600,z=2000
Test Case 8,x=50,y=200,z=2000
如表 2-22(a) 和表 2-22(b)所示，表 2-22(a)表示每个判断条件的每个判断式的真值和假值，表 2-22(b)表示每个判断条件的真值和假值。测试用例组 7虽然满足了判断覆盖、条件覆盖以及判断 /条件覆盖，但是并没有覆盖程序控制流图中全部的 4条路径
（ ace,abe,abe,abd），只覆盖了其中 3条路径（ ace,abe,abd）。软件测试的目的是尽可能地发现所有软件缺陷，因此程序中的每一条路径都应该进行相应的覆盖测试，从而保证程序中的每一个特定的路径方案都能顺利运行。能够达到这样要求的是路径覆盖测试。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500) (x>=1000) (z>5000) 执行路径
Test Case 1 2000,600，6000 True True True True ace
Test Case 8 50,200,2000 False False False False abd
测试用例 x,y,z (x>100)and (y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600,6000 True True ace
Test Case 8 50,200,2000 False False abd
表 2-21(b) 测试用例组 6
表 2-21(a) 测试用例组 6
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500) (x>=1000) (z>5000) 执行路径
Test Case 1 2000,600，6000 True True True True ace
Test Case 6 50,600，6000 False True False True abe
Test Case 7 2000,200，1000 True False True False abe
Test Case 8 50,200，2000 False False False False abd
测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600,6000 True True ace
Test Case 6 50,600,6000 False True abe
Test Case 7 2000,200,1000 False True abe
Test Case 8 50,200,2000 False False abd
表 2-22(b) 测试用例组 7
表 2-22(a) 测试用例组 7
2.4.1 逻辑覆盖测试第二章 软件测试方法路径覆盖路径覆盖（ Path Coverage）要求设计若干测试用例，执行被测试程序时，能够覆盖程序中所有的可能路径。
测试用例组 8：
Test Case 1,x=2000,y=600,z=6000
Test Case 3,x=50,y=600,z=2000
Test Case 4,x=2000,y=600,z=2000
Test Case 7,x=2000,y=200,z=1000
如表 2-23(a) 和表 2-23(b)所示，表 2-23(a)表示每个判断条件的每个判断式的真值和假值，表 2-23(b)表示每个判断条件的真值和假值。测试用例组 8可以达到路径覆盖。
2.4.1 逻辑覆盖测试第二章 软件测试方法测试用例 x,y,z (x>100) (y>500) (x>=1000) (z>5000) 执行路径
Test Case 1 2000,600，6000 True True True True ace
Test Case 3 50,600,2000 False True False False abd
Test Case 4 2000,600，2000 True True True False acd
Test Case 7 2000,200，1000 True False True False abe
测试用例 x,y,z (x>100)and(y>500) (x>=1000)or(z>5000) 执行路径
Test Case 1 2000,600,6000 True True ace
Test Case 3 50,600,2000 False False abd
Test Case 4 2000,600,2000 True True acd
Test Case 7 2000,200,1000 False True abe
表 2-23(b) 测试用例组 8
表 2-23(a) 测试用例组 8
2.4.1 逻辑覆盖测试第二章 软件测试方法应该注意的是，上面 6种覆盖测试方法所引用的公共程序只有短短
4行，是一段非常简单的示例代码。然而在实际测试程序中，一个简短的程序，其路径数目是一个庞大的数字。要对其实现路径覆盖测试是很难的。所以，路径覆盖测试是相对的，要尽可能把路径数压缩到一个可承受范围。
当然，即便对某个简短的程序段做到了路径覆盖测试，也不能保证源代码不存在其他软件问题了。其他的软件测试手段也必要的，
它们之间是相辅相成的。没有一个测试方法能够找尽所有软件缺陷，只能说是尽可能多地查找软件缺陷。
2.4.2 路径分析测试第二章 软件测试方法着眼于路径分析的测试称为路径分析测试。完成路径测试的理想情况是做到路径覆盖。路径覆盖也是白盒测试最为典型的问题。独立路径选择和 Z路径覆盖是两种常见的路径覆盖方法。
2.4.2.1 控制流图第二章 软件测试方法白盒测试是针对软件产品内部逻辑结构进行测试的，测试人员必须对测试中的软件有深入的理解，包括其内部结构、各单元部分及之间的内在联系，还有程序运行原理等等。因而这是一项庞大并且复杂的工作。为了更加突出程序的内部结构，便于测试人员理解源代码，可以对程序流程图进行简化，生成控制流图（ Control Flow
Graph）。简化后的控制流图是由节点和控制边组成的。
1．控制流图的特点控制流图有以下几个特点：
具有唯一入口节点，即源节点，表示程序段的开始语句；
具有唯一出口节点，即汇节点，表示程序段的结束语句；
节点由带有标号的圆圈表示，表示一个或多个无分支的源程序语句；
控制边由带箭头的直线或弧表示，代表控制流的方向。
2.4.2.1 控制流图第二章 软件测试方法常见的控制流图如图 2-9所示。
图 2-9 常见的控制流图
2.4.2.1 控制流图第二章 软件测试方法包含条件的节点被称为判断节点，由判断节点发出的边必须终止于某一个节点。
2,程序环路复杂性程序的环路复杂性是一种描述程序逻辑复杂度的标准，该标准运用基本路径方法，给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。
给定一个控制流图 G，设其环形复杂度为 V(G)，在这里介绍三种常见的计算方法来求解 V(G)。
(1) V(G)=E-N+2，其中 E是控制流图 G中边的数量,N是控制流图中节点的数目。
(2) V(G)=P+1，其中 P是控制流图 G中判断节点的数目。
(3) V(G)=A，其中 A是控制流图 G中区域的数目。由边和结点围成的区域叫做区域，当在控制流图中计算区域的数目时，控制流图外的区域也应记为一个区域。
2.4.2.2 独立路径测试第二章 软件测试方法从 4.1节逻辑覆盖测试一节中可知，对于一个较为复杂的程序要做到完全的路径覆盖测试是不可能实现的。既然路径覆盖测试无法达到，
那么可以对某个程序的所有独立路径进行测试，也就是说检验了程序的每一条语句，从而达到语句覆盖，这种测试方法就是独立路径测试方法。从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。路径可以用控制流图中的节点序列来表示。
例如，在如图 2-10所示的控制流图中，一组独立的路径是
path1,1 -> 11
path2,1 -> 2 -> 3 -> 4 -> 5 -> 10 -> 1 -> 11
path3,1 -> 2 -> 3 -> 6 -> 8 -> 9 -> 10 -> 1 -> 11
path4,1 -> 2 -> 3 -> 6 -> 7 -> 9 -> 10 -> 1 -> 11
2.4.2.2 独立路径测试第二章 软件测试方法路径 path1,path2,path3,path4组成了控制流图的一个基本路径集。
白盒测试可以设计成基本路径集的执行过程。通常，基本路径集并不唯一确定。
独立路径测试的步骤包括 3个方面：
导出程序控制流图求出程序环形复杂度设计测试用例（ Test Case ）
下面通过一个 C语言程序实例来具体说明独立路径测试的设计流程。这段程序是统计一行字符中有多少个单词，单词之间用空格分隔开。
2.4.2.2 独立路径测试第二章 软件测试方法程序 4-2：
1 main ()
2 {
3 int num1=0,num2=0,score=100;
4 int i;
5 char str;
6 scanf (“%d,%c\n”,&i,&str);
7 while (i<5)
8 {
9 if (str=’T’)
10 num1++;
11 else if (str=’F’)
12 {
13 score=score-10;
14 num2 ++;
15 }
16 i++;
17 }
18 printf (“num1=%d,num2=%d,score=%d\n”,num1,num2,score);
19 }
2.4.2.2 独立路径测试第二章 软件测试方法图 2-10 控制流图示例
1．导出程序控制流图根据源代码可以导出程序的控制流图，如图 2-11所示。每个圆圈代表控制流图的节点，可以表示一个或多个语句。圆圈中的数字对应程序中某一行的编号。
箭头代表边的方向，即控制流方向。
2.4.2.2 独立路径测试第二章 软件测试方法
2.4.2.2 独立路径测试第二章 软件测试方法图 2-11 程序 4-2的控制流图
2．求出程序环形复杂度根据程序环形复杂度的计算公式，求出程序路径集合中的独立路径数目。
公式 1,V(G)=10-8+2，其中 10是控制流图 G中边的数量,8是控制流图中节点的数目。
公式 2,V(G)=3+1，其中 3是控制流图 G中判断节点的数目。
公式 3,V(G)=4，其中 4是控制流图 G中区域的数目。
因此，控制流图 G的环形复杂度是 4。就是说至少需要 4条独立路径组成基本路径集合，并由此得到能够覆盖所有程序语句的测试用例。
2.4.2.2 独立路径测试第二章 软件测试方法
2.4.2.2 独立路径测试第二章 软件测试方法
3．设计测试用例根据上面环形复杂度的计算结果，源程序的基本路径集合中有 4条独立路径：
path1,7->18
path2,7->9->10->16->7->18
path3,7->9->11->15->16->7->18
path4,7->9->11->13->14->15->16->7->18
根据上述 4条独立路径，设计了测试用例组 9，如表 2-24所示。测试用例组 9中的 4个测试用例作为程序输入数据，能够遍历这
4条独立路径。对于源程序中的循环体，测试用例组 9中的输入数据使其执行零次或一次。
2.4.2.2 独立路径测试第二章 软件测试方法测试用例 输入 期望输出 执行路径i str num1 num2 score
Test Case 1 5 ‘T’ 0 0 100 路径 1
Test Case 2 4 ‘T’ 1 0 100 路径 2
Test Case 3 4 ‘A’ 0 0 100 路径 3
Test Case 4 4 ‘F’ 0 1 90 路径 4
表 2-24 测试用例组 9
注意：如果程序中的条件判断表达式是由一个或多个逻辑运算符（ or,and，
not）连接的复合条件表达式，则需要变换为一系列只有单个条件的嵌套的判断。
2.4.2.2 独立路径测试第二章 软件测试方法例如：
程序 4-3：
1 if (a or b)
2 then
3 procedure x
4 else
5 procedure y;
6 … …
对应的控制流图如图 2-12所示，程序行 1的 a,b都是独立的判断节点，还有程序行 4也是判断节点，所以共计 3个判断节点。图 2-12的环形复杂度为 V(G)=3+1，其中 3是图 2-12中判断节点的数目。
2.4.2.2 独立路径测试第二章 软件测试方法图 2-12 程序 4-3的控制流图
2.4.2.3 Z路径覆盖测试第二章 软件测试方法和独立路径选择一样,Z路径覆盖也是一种常见的路径覆盖方法。可以说
Z路径覆盖是路径覆盖面的一种变体。对于语句较少的简单程序，路径覆盖是具有可行性的。但是对于源代码很多的复杂程序，或者对于含有较多条件语句和较多循环体的程序来说，需要测试的路径数目会成倍增长，达到一个巨大数字，以至于无法实现路径覆盖。
为了解决这一问题，必须舍弃一些不重要的因素，简化循环结构，从而极大地减少路径的数量，使得覆盖这些有限的路径成为可能。采用简化循环方法的路径覆盖就是 Z路径覆盖。
所谓简化循环就是减少循环的次数。不考虑循环体的形式和复杂度如何，
也不考虑循环体实际上需要执行多少次，只考虑通过循环体零次和一次这两种情况。这里的零次循环是指跳过循环体，从循环体的入口直接到循环体的出口。通过一次循环体是指检查循环初始值。
根据简化循环的思路，循环要么执行，要么跳过，这和判定分支的效果是一样的。可见，简化循环就是将循环结构转变成选择结构。
1,简述软件测试技术从不同角度加以划分的多种方法。
2,简述静态测试和动态测试的区别。
3,举例说明黑盒测试的几种测试方法。
4,举例说明覆盖测试的几种测试方法。
5,简述白盒测试的相关方法。
6,比较阐述黑盒测试和白盒测试的优缺点。
习题
