|
|
|
|
|
代码检查包括桌面检查、代码审查和走查等，主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面；发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。
|
|
|
|
|
|
|
|
这是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。
|
|
|
|
由于程序员熟悉自己的程序及其程序设计风格，桌面检查由程序员自己进行可以节省很多的检查时间，但应避免主观片面性。
|
|
|
|
|
|
代码审查是由若干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。
|
|
|
|
代码审查分两步：第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。例如，对某个局部性小问题修改方法的讨论，可能发现与之牵连的其他问题，甚至涉及到模块的功能说明、模块间接口和系统总体结构的大问题，从而导致对需求的重定义、重设计和重验证，进而大大改善了软件质量。
|
|
|
|
在会前，应当给审查小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高审查的实效。
|
|
|
|
这个常见错误清单也称为检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供再审查时使用。
|
|
|
|
|
|
|
|
第一步也是把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机，即首先由测试组成员为所测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。
|
|
|
|
人们借助测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，能够发现更多的问题。
|
|
|
|
代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。
|
|
|
|
在实际使用中，代码检查能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷，而且代码检查看到的是问题本身而非征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。
|
|
|
|
代码检查可以使用测试软件进行自动化测试，以利于提高测试效率，降低劳动强度，或者使用人工进行测试，以充分发挥人力的逻辑思维能力。
|
|
|
|
|
|
. 检查变量的交叉引用表：重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列、临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用。
|
|
|
|
. 检查标号的交叉引用表：验证所有标号的正确性，检查所有标号的命名是否正确，转向指定位置的标号是否正确。
|
|
|
|
. 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，确认每次所调用的子程序、宏、函数是否存在，检验调用序列中调用方式与参数顺序、个数、类型上的一致性。
|
|
|
|
. 等价性检查：检查全部等价变量的类型的一致性，解释所包含的类型差异。
|
|
|
|
. 常量检查：确认常量的取值和数制、数据类型，检查常量每次引用同它的取值、数制和类型的一致性。
|
|
|
|
. 标准检查：用标准检查工具软件或手工检查程序中违反标准的问题。
|
|
|
|
|
|
. 比较控制流：比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并修正错误。
|
|
|
|
. 选择、激活路径：在程序员设计的控制流图上选择路径，再到实际的控制流图上激活这条路径。如果选择的路径在实际控制流图上不能被激活，则源程序可能有错。
|
|
|
|
. 对照程序的规格说明，详细阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，从它们的差异中发现程序的问题和错误。
|
|
|
|
. 补充文档：桌面检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。管理部门也可以通过审查桌面检查文档，了解模块的质量、完全性、测试方法和程序员的能力。
|
|
|
|
根据检查项目可以编制代码规则、规范和检查表等作为测试用例，如编码规范、代码检查规则、缺陷检查表等。
|
|
|
|
|
|
编码规范是程序编写过程中必须遵循的规则，一般会详细规定代码的语法规则、语法格式等，如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在代码检查中，需要依据被测软件的特点，选用适当的标准与规则规范。在使用测试软件进行自动化代码检查时，测试工具一般会内置许多的编码规则，例如，Parasoft公司用于C/C++语言测试的C++Test，内置了5类规则：通用规则、C++编码规则、C编码规则、Meyers-Klaus规则和自定义规则。我们需要根据编程语言以及被测程序的特点，挑选适当的规则进行检查。
|
|
|
|
例如，在测试中，可以选择下表中的规则进行自动化测试，在此基础上使用桌面检查、代码走查、代码审查等人工检查的方法仔细检查程序的结构、逻辑等方面的缺陷。
|
|
|
|
|
|
|
|
|
|
在进行人工代码检查时，代码缺陷检查表是我们用到的测试用例。
|
|
|
|
代码缺陷检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误，如下所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
②当对另一个模块的每一次调用时，全部所需的参数传送给每一个被调用的模块吗？
|
|
|
|
|
|
④对关键的被调用模块的意外情况（如丢失、混乱）有处理吗？
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对应于不同的编程语言，代码缺陷检查表的具体内容将会不同。例如，针对广泛使用的C/C++语言，可以参照下表所示的代码缺陷检查表。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
程序的结构形式是白盒测试的主要依据。研究表明程序员38%的时间花费在理解软件系统上，因为代码以文本格式被写入多重文件中，这是很难阅读理解的，需要其他一些东西来帮助人们阅读理解，如各种图表等，而静态结构分析满足了这样的需求。
|
|
|
|
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表，可以清晰地标识整个软件系统的组成结构，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。
|
|
|
|
其中函数调用关系图通过应用程序中各函数之间的调用关系展示了系统的结构。通过查看函数调用关系图，可以检查函数之间的调用关系是否符合要求，是否存在递归调用，函数的调用层次是否过深，有没有存在孤立的没有被调用的函数。从而可以发现系统是否存在结构缺陷，发现哪些函数是重要的，哪些是次要的，需要使用什么级别的覆盖要求……
|
|
|
|
模块控制流图是与程序流程图相类似的由许多节点和连接结点的边组成的一种图形，其中一个节点代表一条语句或数条语句（图中的各种图形符号代表不同的意义），边表示节点间的控制流向，它显示了一个函数的内部逻辑结构。如下图一所示是测试工具Logiscope所使用的基本图例，如下图二（a）、（b）、（c）所示是典型逻辑结构所对应的控制流图基本结构。
|
|
|
|
|
|
|
|
|
|
|
|
模块控制流图可以直观地反映出一个函数的内部逻辑结构，通过检查这些模块控制流图，能够很快发现软件的错误与缺陷。
|
|
|
|
例如：如下图所示是某GIS软件中某个函数的模块控制流图。
|
|
|
|
|
|
|
|
该函数的结构存在重大缺陷：首先，我们可以看到在该函数中存在无法执行的死代码，即图中最右边的孤立出口。其次，该函数有多达8个出口，其中一个属于无法到达的出口。由于可能没有在所有的出口进行动态内存的释放与回收操作，因此这样的结构存在内存泄漏的可能。
|
|
|
|
如下图所示是某MIS软件中某个函数的模块控制流图。
|
|
|
|
|
|
|
|
|
|
首先，该函数有多个出口，存在内存泄漏的可能。其次，该函数结构复杂，有超过10个逻辑判断结点，在这些结点上出现逻辑错误的概率将大大增加，将降低其可靠性，而且过多的逻辑判断结点可能会破坏对CPU操作进行优化的处理，影响其运行性能。
|
|
|
|
|
|
根据ISO/IEC 9126国际标准的定义，软件的质量包括以下六个方面：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
以ISO 9126质量模型作为基础，我们可以构造质量度量模型，用于评估软件的每个方面。例如，按以下方法构造的质量模型可以度量程序的可维护性（maintainability）。首先，该模型从上到下分为3层：质量因素（factors）、分类标准（criteria）和度量规则（metrics）。其中质量因素对应ISO 9126质量模型的质量特性，分类标准对应ISO 9126质量模型的子特性，度量规则用于规范软件的各种行为属性。其次，按以下方式定义各参数及计算公式。
|
|
|
|
|
|
度量规则使用了代码行数、注释频度等参数度量软件的各种行为属性，具体参数定义如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
每个分类标准由一系列度量规则组成，各个规则分配一个权重，由规则的取值与权重值计算出每个分类标准的取值。各分类标准组成如下表所示。
|
|
|
|
|
|
|
|
各分类标准的结果按以下标准区分等级，如下表一至如下表十二所示。
|
|
|
|
function_TESTABILITY=DRCT_CALLS+LEVL+PATH+PARA
|
|
|
|
|
|
function_TESTABILITY的等级划分
|
|
|
|
function_STABILITY=NBCALLING+RETU+DRCT_CALLS+PARA
|
|
|
|
|
|
|
|
function_CHANGEABILITY=PARA+LVAR+VOCF+GOTO
|
|
|
|
|
|
function CHANGEABILITY的等级划分
|
|
|
|
function_ANALYZABILITY=VG+STMT+AVGS+COMF
|
|
|
|
|
|
function_ANALYZABILITY的等级划分
|
|
|
|
relativeCall_ANALYZABILITY=STRU_CPX+LEVELS
|
|
|
|
|
|
relativeCall ANALYZABILITY的等级划分
|
|
|
|
relativeCall_STABILITY=CALL_PATHS+HIER_CPX
|
|
|
|
|
|
relativeCall_STABILITY的等级划分
|
|
|
|
relativeCall_TESTABILITY=TESTBTY+CALL_PATHS
|
|
|
|
|
|
relativeCall_TESTABILITY的等级划分
|
|
|
|
这样，依据这些标准和最终测试结果，可将代码的质量分成四个等级。
|
|
|
|
①优秀（EXCELLENT）：符合本模型框架中的所有规则。
|
|
|
|
|
|
|
|
|
|
其中前三者被认为是可以接受的，最后一个等级则是不可接受的。
|
|
|
|
|
|
质量因素的取值与分类标准的计算方式相似：依据各分类标准取值组合权重方法来计算，如下表所示。
|
|
|
|
|
|
|
|
同样，依据质量因素取值，也将其分成四个等级：优秀（EXCELLENT）、良好（GOOD）、一般（FAIR）和较差（POOR），其中前三者被认为是可以接受的，最后一个等级则是不可接受的。
|
|
|
|
如下表一和如下表二所示为function_MAINTAINABILITY和relative Call_MINTA-INABILITY的等级划分。
|
|
|
|
|
|
|
|
function_MAITAINABILITY的等级划分
|
|
|
|
|
|
|
|
relativeCall_MAINTAINABILITY的等级划分
|
|
|
|
将上述质量模型应用于被测程序后，就可以通过量化的数据对软件的质量进行评估了。
|
|
|
|
|
|
白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：
|
|
|
|
|
|
|
|
|
|
|
|
但是对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。而且即使精确地实现了白盒测试，也不能断言测试过的程序完全正确。如下图所示的穷举测试流程图，其中包括了一个执行达20次的循环，它所包含的不同执行路径数高达520条，假使有这么一个测试程序，对每一条路径进行测试需要1ms，假设一天工作24小时，一年工作365天，若要对它进行穷举测试，也需要3024年的时间。
|
|
|
|
|
|
|
|
以上的情况说明，实现穷举测试的工作量过大，需要的时间过长，实施起来是不现实的。任何软件开发项目都要受到期限、费用、人力和机时等条件的限制，尽管我们以为为了充分揭露程序中的所有隐藏错误，彻底的做法是针对所有可能的数据进行测试，但事实告诉人们，这样做是不可能的。
|
|
|
|
在测试阶段既然穷举测试不可行，为了节省时间和资源，提高测试效率，就必须精心设计测试用例，也就是从数量巨大的可用测试用例中精心挑选少量的测试数据，使得采用这些测试数据就能够达到最佳的测试效果。
|
|
|
|
本节和下节将介绍几种实用的白盒测试用例设计方法：逻辑覆盖法和基本路径测试法。
|
|
|
|
逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖。它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖（SC）、判定覆盖（DC）、条件覆盖（CC）、条件判定组合覆盖（CDC）、多条件覆盖（MCC）和修正判定条件覆盖（MCDC）。
|
|
|
|
为便于理解，我们使用如下所示的程序（用C语言书写），如下图所示的是其流程图。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此，语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。
|
|
|
|
为了使上述程序中的每条语句都能够至少执行一次，我们可以构造以下测试用例即可实现：
|
|
|
|
|
|
从程序中的每条语句都得到执行这一点看，语句覆盖的方法似乎能够比较全面地检验每一条语句，但是语句覆盖对程序执行逻辑的覆盖很低，这是其最严重的缺陷。
|
|
|
|
假如，这一程序段中判定的逻辑运算有问题，例如，判定的第一个运算符“&&”错写成运算符“||”，或第二个运算符“||”错写成运算符“&&”，这时使用上述的测试用例仍然可以达到100%的语句覆盖，上述的逻辑错误无法发现。
|
|
|
|
|
|
|
|
比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
|
|
|
|
除了双值的判定语句外，还有多值判定语句，如case语句，因此判定覆盖更一般的含义是：使得每一个判定获得每一种可能的结果至少一次。
|
|
|
|
以上述代码为例，构造以下测试用例即可实现判定覆盖标准：
|
|
|
|
|
|
|
|
应该注意到，上述两组测试用例不仅满足了判定覆盖，而且满足了语句覆盖，从这一点看，判定覆盖要比语句覆盖更强一些。但是同样地，假如这一程序段中判定的逻辑运算有问题，如下表所示，判定的第一个运算符“&&”错写成运算符“||”或第二个运算符“||”错写成运算符“&&”，这时使用上述的测试用例可以达到100%的判定覆盖，仍然无法发现上述的逻辑错误。因此需要更强的逻辑覆盖标准。
|
|
|
|
|
|
|
|
|
|
在设计程序中，一个判定语句是由多个条件组合而成的复合判定，在如上图所示参考例子流程图的程序中，判定（a）AND（b OR c）包含了三个条件：a, b和c。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
|
|
|
|
按照这一定义，上述例子要达到100%的条件覆盖，可以使用以下测试用例：
|
|
|
|
|
|
|
|
仔细分析可以发现，上述用例在满足条件覆盖的同时，把判定的两个分支也覆盖了，这样是否可以说，达到了条件覆盖也就必然实现了判定覆盖呢？
|
|
|
|
|
|
|
|
|
|
我们会发现覆盖了条件的测试用例并没有覆盖分支，如下表所示。为解决这一矛盾，需要对条件和分支兼顾。
|
|
|
|
|
|
|
|
|
|
条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。
|
|
|
|
对于如上图所示的例子，选用以下的两组测试用例可以符合条件判定组合覆盖标准：
|
|
|
|
|
|
|
|
但是条件判定组合覆盖也存在一定的缺陷，例如，判定的第一个运算符“&&”错写成运算符“||”或第二个运算符“||”错写成运算符“&&”，如下表所示，这时使用上述的测试用例仍然可以达到100%的条件判定组合覆盖，上述的逻辑错误无法发现。
|
|
|
|
|
|
|
|
|
|
多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
|
|
|
|
对于如下图所示的例子，判定语句中有三个逻辑条件，每个逻辑条件有两种可能取值，因此共有23=8种可能组合，如下表所示的测试用例保证了多条件覆盖。
|
|
|
|
|
|
|
|
|
|
|
|
由上可知，当一个程序中判定语句较多时，其条件取值的组合数目是非常大的。
|
|
|
|
|
|
修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的bool条件，每个条件对于判定的结果值是独立的。
|
|
|
|
对于如下图所示的例子，可以设计如下表中的8个用例，在此基础上，按照MCDC的要求选择需要的用例。
|
|
|
|
|
|
|
|
|
|
|
|
从表中我们可以看出，布尔变量a可以通过用例1和5达到MCDC的要求（用例2和6或用例3和7也可以满足相应要求），变量b可以通过用例2和4达到MCDC的要求，变量c可以通过用例3和4达到MCDC的要求，因此使用用例集｛1，2，3，4，5｝即可满足MCDC的要求。显而易见，这不是惟一的用例组合。
|
|
|
|
|
|
上节的例子是个比较简单的程序段，只有两条路径。但在实际问题中，一个不太复杂的程序，其路径的组合都是一个庞大的数字。如下图所示的穷举测试程序竟有520条路径，要在测试中覆盖这样多的路径是不现实的。
|
|
|
|
|
|
|
|
为解决这一难题，需要把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。本节介绍的基本路径测试就是这样一种测试方法，它在程序控制流图的基础上，通过分析控制流图的环路复杂性，导出基本可执行路径的集合，然后据此设计测试用例。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。
|
|
|
|
|
|
控制流图是描述程序控制流的一种图示方式。其中基本的控制结构对应的图形符号如下图所示。在如下图所示的图形符号中，圆圈称为控制流图的一个结点，它表示一个或多个无分支的语句或源程序语句。
|
|
|
|
|
|
|
|
如下图（a）所示的是一个程序的流程图，它可以映射成如下图（b）所示的控制流程图。
|
|
|
|
|
|
|
|
这里我们假定在流程图中用菱形框表示的判定条件内没有复合条件，而一组顺序处理框可以映射为一个单一的结点。控制流程图中的箭头（边）表示了控制流的方向，类似于流程图中的流线，一条边必须终止于一个结点，但在选择或者是多分支结构中分支的汇聚处，即使汇聚处没有执行语句也应该添加一个汇聚结点。边和结点圈定的部分叫区域，当对区域计数时，图形外的部分也应记为一个区域。
|
|
|
|
如果判断中的条件表达式是复合条件，即条件表达式是由一个或多个逻辑运算符（or、and、nand和nor）连接的逻辑表达式，则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断。例如，对应如下图所示的复合逻辑下的控制流图（a）的复合条件的判定，应该画成如下图（b）所示的控制流图。条件语句if a and b中条件a和条件b各有一个只有单个条件的判断结点。
|
|
|
|
|
|
|
|
|
|
程序的环路复杂性即McCabe复杂性度量，在进行程序的基本路径测试时，从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
|
|
|
|
独立路径是指包括一组以前没有处理的语句或条件的一条路径。从控制流图来看，一条独立路径是至少包含有一条在其他独立路径中从未有过的边的路径。例如，在如下图（b）中所示的控制流图中，一组独立的路径如下：
|
|
|
|
|
|
|
|
|
|
|
|
path3：1—2—3—6—8—9-10—1—11；
|
|
|
|
path4：1—2—3—6—7—9—10—1—11。
|
|
|
|
从此例中可知，一条新的路径必须包含有一条新边。路径1—2—3—4—5—10—1—2—3—6—8—9—10—1—11不能作为一条独立路径，因为它只是前面已经说明了的路径的组合，没有通过新的边。
|
|
|
|
路径path1、path2、path3和path4组成了如上图（b）所示控制流图的一个基本路径集。只要设计出的测试用例能够确保这些基本路径的执行，就可以使得程序中的每个可执行语句至少执行一次，每个条件的取真和取假分支也能得到测试。基本路径集不是惟一的，对于给定的控制流图，可以得到不同的基本路径集。
|
|
|
|
通常环路复杂性还可以简单地定义为控制流图的区域数。这样对于如上图（b）所示的控制流图，它有4个区域，环路复杂性V（G）=4，它是构成基本路径集的独立路径数的上界，可以据此得到应该设计的测试用例的数目。
|
|
|
|
|
|
基本路径测试法适用于模块的详细设计及源程序，其主要步骤如下：
|
|
|
|
. 以详细设计或源代码作为基础，导出程序的控制流图；
|
|
|
|
|
|
|
|
. 生成测试用例，确保基本路径集中每条路径的执行。
|
|
|
|
下面以一个求平均值的过程averagy为例，说明测试用例的设计过程。用PDL语言描述的averagy过程如下所示。
|
|
|
|
|
|
|
|
|
|
利用在如下图一所示的控制流图的图形符号、如下图二所示的程序流图和对应的控制流图和如下图三所示的复合逻辑下的控制流图给出的符号和构造规则生成控制流图。对于上述过程，对将要映射为对应控制流图中一个结点的PDL语句或语句组，加上用数字表示的标号。加了标号的PDL程序及对应的控制流图如下图四和如下图五所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
利用在前面给出的计算控制流图环路复杂性的方法，算出控制流图G的环路复杂性。如果一开始就知道判断结点的个数，甚至不必画出整个控制流图，就可以计算出该图的环路复杂性的值。对于如下图所示的控制流图，可以算出：
|
|
|
|
|
|
|
|
V（G）=6（区域数）=5（判断结点数）+1=6。
|
|
|
|
|
|
针对如上图所示的averagy过程的控制流图计算出的环路复杂性的值，就是该图已有的线性无关基本路径集中路径数目。该图所有的6条路径如下所示。
|
|
|
|
|
|
|
|
|
|
|
|
［path5］1—2—3—4—5—6—8—9—2…
|
|
|
|
［path6］1—2—3—4—5—6—7—8—9—2…
|
|
|
|
路径4、5、6后面的省略号（…）表示在控制结构中以后剩下的路径是可选择的。在很多情况下，标识判断结点，常常能够有效地帮助导出测试用例。在上例中，结点2、3、5、6和10都是判断结点。
|
|
|
|
（4）生成测试用例，确保基本路径集中每条路径的执行
|
|
|
|
根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到。满足上述基本路径集的测试用例如下所示。
|
|
|
|
［path1］输入数据：value［k］＝有效输入，限于k
|
|
|
|
|
|
|
|
注意：不能孤立地进行测试，应当作为路径4、5、6测试的一部分来测试。
|
|
|
|
［path2］输入数据：value［1］=-999；
|
|
|
|
|
|
［path3］输入数据：试图处理101个或更多的值，而前100个应当是有效的值；
|
|
|
|
|
|
［path4］输入数据：value［i］=有效输入，且i<100；
|
|
|
|
|
|
|
|
［path5］输入数据：value［i］=有效输入，且i<100；
|
|
|
|
|
|
|
|
［path6］输入数据：value［i］=有效输入，且i<100
|
|
|
|
|
|
每个测试用例执行之后，与预期结果进行比较。如果所有测试用例都执行完毕，则可以确信程序中所有的可执行语句至少被执行了一次。但是必须注意的是，一些独立的路径（如此例中的路径1），往往不是完全孤立的，有时它是程序正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。
|
|
|
|
|
|
|
|
域测试（Domain Testing）是一种基于程序结构的测试方法。Howden曾对程序中出现的错误进行分类，他将程序错误分为域错误、计算型错误和丢失路径错误三种，这是相对于执行程序的路径来说的。我们知道，每条执行路径对应于输入域的一类情况，是程序的一个子计算。如果程序的控制流有错误，对于某一特定的输入可能执行的是一条错误路径，这种错误称为路径错误，也叫做域错误。如果对于特定输入执行的是正确路径，但由于赋值语句的错误致使输出结果不正确，则称此为计算型错误。
|
|
|
|
另外一类错误是丢失路径错误。它是由于程序中的某处少了一个判定谓词而引起的。域测试主要是针对域错误进行的程序测试。
|
|
|
|
域测试的“域”是指程序的输入空间。域测试方法基于对输入空间的分析。自然，任何一个被测程序都有一个输入空间。测试的理想结果就是检验输入空间中的每一个输入元素是否都产生正确的结果。而输入空间又可分为不同的子空间，每一子空间对应一种不同的计算。在考察被测试程序的结构以后，我们就会发现，子空间的划分是由程序中分支语句中的谓词决定的。输入空间的一个元素，经过程序中某些特定语句的执行而结束（当然也可能出现无限循环而无出口），那都是满足了这些特定语句被执行所要求的条件的。
|
|
|
|
域测试正是在分析输入域的基础上，选择适当的测试点以后进行测试的。
|
|
|
|
域测试有两个致命的弱点，一是为进行域测试对程序提出的限制过多，二是当程序存在很多路径时，所需的测试点也就很多。
|
|
|
|
|
|
符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也是因此而得名的。这里所说的符号值可以是基本符号变量值，也可以是这些符号变量值的一个表达式。这样，在执行程序过程中以符号的计算代替了普通测试执行中对测试用例的数值计算。所得到的结果自然是符号公式或是符号谓词。更明确地说，普通测试执行的是算术运算，符号测试执行的则是代数运算。因此符号测试可以认为是普通测试的一个自然的扩充。
|
|
|
|
符号测试可以看作是程序测试和程序验证的一个折衷方法。一方面，它沿用了传统的程序测试方法，通过运行被测程序来验证它的可靠性。另一方面，由于一次符号测试的结果代表了一大类普通测试的运行结果，实际上是证明了程序接受此类输入后，所得输出是正确的还是错误的。最为理想的情况是，程序中仅有有限的几条执行路径。如果对这有限的几条路径都完成了符号测试，我们就能较有把握地确认程序的正确性了。
|
|
|
|
从符号测试方法的使用来看，问题的关键在于开发出比传统的编译器功能更强，能够处理符号运算的编译器和解释器。
|
|
|
|
目前符号测试存在一些未得到圆满解决的问题，如下所示。
|
|
|
|
|
|
当采用符号执行方法进行到某一分支点处，分支谓词是符号表达式，这种情况下通常无法决定谓词的取值，也就不能决定分支的走向，需要测试人员做人工干预，或是执行树的方法进行下去。如果程序中有循环，而循环次数又决定于输入变量，那就无法确定循环的次数。
|
|
|
|
|
|
数据项的符号值可能是有二义性的。这种情况通常出现在带有数组的程序中。
|
|
|
|
|
|
|
|
如果I=J，则C=3；否则，C=2+A。但由于使用符号值运算，这时无法知道I是否等于J。
|
|
|
|
|
|
符号测试中经常要处理符号表达式。随着符号执行的继续，一些变量的符号表达式会越来越庞大。特别是当符号执行树很大，分支点很多时，路径条件本身变成一个非常长的表达式。如果能够有办法将其化简，自然会带来很大好处。但如果找不到化简的办法，那将给符号测试的时间和运行空间带来大幅度的增长，甚至使整个问题的解决遇到难以克服的困难。
|
|
|
|
|
|
分析程序中的路径是指：检验程序从入口开始，执行过程中经历的各个语句，直到出口。这是白盒测试最为典型的问题。着眼于路径分析的测试可称为路径测试。完成路径测试的理想情况是做到路径覆盖。对于比较简单的小程序实现路径覆盖是可能做到的。但是如果程序中出现多个判断和多个循环，可能的路径数目将会急剧增长，达到天文数字，以至于实现完全路径覆盖是不可能做到的。
|
|
|
|
为了解决这一问题，我们必须舍掉一些次要因素，对循环机制进行简化，从而极大地减少路径的数量，使得覆盖这些有限的路径成为可能。我们称简化循环意义下的路径覆盖为Z路径覆盖。
|
|
|
|
这里所说的对循环化简，是指限制循环的次数。无论循环的形式和实际执行循环体的次数多少，我们只考虑循环一次和零次两种情况。即只考虑执行时进入循环体一次和跳过循环体这两种情况。如下图（a）和（b）所示表示了两种最典型的循环控制结构。前者先作判断，循环体B可能执行（假定只执行一次），也可能不执行。这就如同如下图（c）所示的条件选择结构一样。后者先执行循环体B（假定也执行一次），再经判断转出，其效果也与（c）中给出的条件选择结构只执行右支的效果一样。
|
|
|
|
|
|
|
|
对于程序中的所有路径可以用路径树来表示，具体表示方法这里忽略。当得到某一程序的路径树后，从其根结点开始，一次遍历，再回到根结点时，把所经历的叶结点名排列起来，就得到一个路径。如果我们设法遍历了所有的叶结点，就得到了所有的路径。
|
|
|
|
当得到所有的路径后，生成每个路径的测试用例，就可以做到Z路径覆盖测试。
|
|
|
|
|
|
程序变异方法与前面提到的结构测试和功能测试都不一样，它是一种错误驱动测试。所谓错误驱动测试，是指该方法是针对某类特定程序错误的。经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围尽可能地缩小，以利于专门测试某类错误是否存在。这样做的好处在于，便于集中目标于对软件危害最大的可能错误，而暂时忽略对软件危害较小的可能错误。这样可以取得较高的测试效率，并降低测试的成本。
|
|
|
|
错误驱动测试主要有两种，即程序强变异和程序弱变异。为便于测试人员使用变异方法，一些变异测试工具被开发出来。关于程序变异测试方法，请参见清华大学出版社出版的《软件测试技术》一书。
|
|
|
