全部科目 > 软件评测师 >
2009年上半年 上午试卷 综合知识
第 61 题
知识点 白盒测试   白盒测试方法   黑盒测试   测试方法   软件测试   软件测试的基本方法  
关键词 白盒测试   测试方法   黑盒测试   软件测试   白盒   测试   黑盒  
章/节 测试技术的分类  
 
 
软件测试的基本方法包括白盒测试和黑盒测试方法/以下关于二者之间关联的叙述，错误的是（61）。
 
  A.  黑盒测试与白盒测试是设计测试用例的两种基本方法
 
  B.  在集成测试阶段是采用黑盒测试与白盒测试相结合的方法
 
  C.  针对相同的系统模块，执行黑盒测试和白盒测试对代码的覆盖率都能够达到100%
 
  D.  应用系统负载压力测试一般采用黑盒测试方法
 
 




 
 
相关试题     白盒测试技术 

  第44题    2010年下半年  
计算以下控制流程图的环路复杂性V(G),正确答案是（44）。

  第60题    2018年下半年  
一个程序的控制流图中有8个节点、12条边,在测试用例数最少的情况下,确保程序中每个可执行语句至少执行一次所需测试用例数的上限是( )。

  第66题    2013年下半年  
以下属于静态测试方法的是(66)。

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



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2023 All Rights Reserved
软考在线版权所有