快乐每一天。。。
白盒测试概念和方法
上一篇 / 下一篇 2013-04-08 21:49:09 / 天气: 大风 / 心情: 平静 / 个人分类：DIY
一、白盒测试概念
1、定义
白盒测试又称结构测试、透明盒测试、逻辑驱动测试、基于代码的测试。盒子指被测试的软件 ，白盒指盒子是可视的。白盒测试是一种测试用例设计方法，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例。白盒测试主要针对被测程序的源代码，主要用于软件验证，不考虑软件的功能实现，只验证内部动作是否按照设计说明书的规定进行。
2、目的
我们一方面注重软件功能需求的实现，另一方面还要注重程序逻辑细节，主要是因为软件自身的缺陷，具体如下：
1）逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。
2）我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，只有路径测试才能发现这些错误。
3）代码中的笔误是随机且无法杜绝的。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。很多被语法检查机制发现，但是其他的会在测试开始时才会被发现。
4）功能测试本身的局限性。如果程序实现了没有被描述的行为，功能测试是无法发现的，例如病毒，而白盒测试很容易发现它。
3、目标
采用白盒测试必须遵循以下几条原则，才能达到测试的目标：
1）保证一个模块中的所有独立路径至少被测试一次。
2）所有逻辑值均需测试真 (true) 和假 (false) 两种情况。
3）检查程序的内部数据结构，保证其结构的有效性。
4）在上下边界及可操作范围内运行所有循环。
4、黑白灰区别
黑盒测试技术：也称功能测试或数据驱动测试，只关注规格说明中的功能，测试者在程序接口对软件界面和软件功能进行测试，它只检查实现了的功能是否按照“用户需求说明书”的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。主要用于软件确认测试，结合兼容、性能测试等方面，但黑盒测试不能保证已经实现的各个部分都被测试到。黑盒测试适用于各阶段测试。
白盒测试技术：只关注软件产品的测试，深入到代码一级的测试，它是知道产品内部结构，通过测试来检测产品内部动作是否按照“设计规格说明书”的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，主要用于软件验证，不能够确保产品已经实现了规格说明中的所有功能。白盒测试通常用于单元测试。
灰盒测试技术：在白盒测试中交叉使用黑盒测试、在黑盒测试中交叉使用白盒测试的方法。它结合了白盒测试和黑盒测试的要素，涉及输入和输出，但使用关于代码和程序操作等信息设计测试用例。灰盒测试通常用于集成测试。
测试是从用户需求的角度去对软件的质量进行检测。具体使用黑盒测试、白盒测试、灰盒测试，不需要太明确的来划分，我们应该多角度去设计测试用例，多角度去测试软件、发现bug，才是一个测试工程师应该具备的思想。总之，建议测试人员在测试过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充，以保证测试的完整性。
二、白盒测试方法
1、简介
白盒测试主要是检查程序的内部结构、逻辑、循环和路径。测试是基于覆盖全部代码、分支、路径、条件。根据测试程序是否运行，白盒测试分静态白盒测试和动态白盒测试两种。
静态白盒测试也称为结构分析，是在不执行程序的条件下审查软件设计、体系结构和代码，从而找出软件缺陷的过程。测试对象是文档、代码等非计算机执行的部分。在项目中使用静态白盒测试是基于这样的原则：错误发现得越早，改正错误的成本越低，正确改正错误的可能性越大，改正错误时可能引发的其他错误的数量也越少。静态白盒测试方法包括代码检查法、静态结构分析法、静态质量度量法。常用的是代码检查法，这些方法在程序开始编码之后、基于计算机的动态测试开始之前使用。
动态白盒测试也称为结构化测试，是在使用和运行程序的条件下，软件测试员查看代码内部结构和实现方式来确定哪些要测试，哪些不要测试，如何开展测试，怎样设计和执行测试用例。白盒测试的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。动态白盒测试常用的测试用例设计方法有逻辑覆盖法（逻辑驱动测试）和基本路径测试法两种。
下面具体介绍一下三种常用的白盒测试方法：
2、代码检查法
2.1简介
代码检查法主要检查代码和程序设计的一致性，代码结构的合理性，代码编写的标准性、可读性，代码逻辑表达的正确性等方面。检查方式包括桌面检查、代码走查、代码审查三种方式。
目的：检查程序是不是按照某种标准或规范编写的。
目标：发现程序缺陷，改进软件的质量。
需要的文档：程序设计文档、程序的源代码清单、编码规范、代码缺陷检查表等。在进行代码检查时，代码缺陷检查表就是测试用例，检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误。
优缺点：代码检查法能快速找到缺陷，一旦发现错误，能够在代码中对其进行精确定位，从而降低了错误修正的成本。代码检查看到的是问题本身而非问题的征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。
2.2代码审查和走查
两种方法的形成、流程一样，规程、方法不一样。具体来说：
代码审查和走查都是以小组为单位阅读代码，它是一系列规程和错误检查方法的集合。审查或走查小组通常由不需要对程序细节很了解的协调人员、程序的编码人员、程序的设计人员、测试专家四人组成。都是以会议的形式进行。会议理想时间为90-120分钟之间，按照每小时阅读 150行代码的速度进行。对大型软件应安排多个会议同时进行，每个会议处理一个或几个模块或子程序。
代码审查规程和方法：在代码审查会议上，程序作者逐条语句讲述程序的逻辑结构，参与人根据“代码缺陷检查表”分析程序，检查内容包括编码标准规范和错误列表。编码规范是指团队根据自己的经验和风格进行设置的一些规范。错误列表一般是代码潜在的bug，由于某种代码写法虽然没有语法错误，但是可能存在错误，比如会导致线程死锁，这些都是错误列表应该检查的。程序员之间可以隔一定的时间抽取代码进行审查。结束会议后，把这些经验汇成列表，作为下次代码审查的依据，并针对错误修正进行跟踪。输出文档是“代码检查记录表”，此表主要内容日期、住持人、参与人员、范围、发现的问题、问题处理、跟踪检查等。
代码走查规程和方法：在代码走查会议上，参与者参考“设计规格书”使用计算机来执行代码。测试人员准备一些简单的测试用例，它的作用是提供启动代码走查和质疑程序员逻辑思路及其他设想的手段。在会议期间，把测试数据沿程序的逻辑结构走一遍，程序的状态记录在纸或白板上以供监视。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。
2.3桌面检查
桌面检查是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关文档，由于程序员熟悉自己的程序及其程序设计风格，桌面检查由程序员自己进行可以节省时间，但应避免主观片面性。桌面检查的效果逊色于代码检查和走查，但桌面检查胜过没有检查。
3、逻辑覆盖测试
3.1简介
测试覆盖率：用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。 测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。 测试覆盖率包括功能点覆盖率和结构覆盖率，功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。
逻辑覆盖法：以程序内部的逻辑结构为基础的用例设计方法，它通过对程序逻辑结构的遍历实现程序的覆盖。根据覆盖目标的不同，逻辑覆盖分为语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定-条件覆盖（分支-条件覆盖）、条件组合覆盖、路径覆盖六种覆盖测试方法。语句覆盖每条语句至少执行一次。判定覆盖每个判定/分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定-条件覆盖同时满足判定覆盖和条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。它们发现错误的能力呈由弱至强的变化。
3.2举例说明
以下举例说明六种覆盖测试方法：
如源代码（C语言）：
int logicExample(int x, int y)
{
int magic=0;
if(x>0 && y>0)
{
magic = x+y+10; // 语句块1
}
else
{
magic = x+y-10; // 语句块2
}
if(magic < 0)
{
magic = 0; // 语句块3
}
return magic; // 语句块4
}
一般逻辑覆盖测试不会直接根据源代码，而是根据流程图来设计测试用例，在没有设计文档时，要根据源代码画出流程图：
3.2.1语句覆盖
特点：语句覆盖要求设计足够多的测试用例，运行被测程序，使得程序中每条语句至少被执行一次。在本例中，可执行语句是指语句块1到语句块4中的语句。
用例设计：
数据 语句
{x=3, y=3} 1、4
{x=-3, y=0} 2、3、4
通过这两个测试用例即达到语句覆盖的标准（测试用例组不是唯一的）。
优点：可以很直观地从流程图得到测试用例，可以测试所有的执行语句。
缺点：语句覆盖不能准确的判断运算中的逻辑关系错误。假设第一个判断语句if(x>0 && y>0)中的“&&”被错误地写成了“||”，即if(x>0 || y>0)，使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的语句覆盖。在六种逻辑覆盖标准中，语句覆盖标准最弱的。
3.2.2判定覆盖
特点：判定覆盖（分支覆盖）要求设计足够多的测试用例，运行被测程序，使得程序中的每个判断的“真”和“假”都至少被执行一次。即：程序中的每个分支至少执行一次。在本例中共有两个判断if(x>0 && y>0)（记为P1）和if(magic < 0)（记为P2）。
用例设计：数据 P1 P2
{x=3, y=3} T F
{x=-3, y=0} F T
两个判断的取真、假分支都已经被执行过，所以满足了判断覆盖的标准。
优点：由于可执行语句要不就在判定的真分支，要不就在假分支上，判定覆盖比语句覆盖要多几乎一倍的测试路径，所以，只要满足了判定覆盖标准就一定满足语句覆盖标准。因此，判定覆盖比语句覆盖强。
缺点：判定覆盖会忽略条件中取或（or）的情况。假设第一个判断语句if(x>0 && y>0)中的“&&”被程序员错误地写成了“||”，使用上面设计出来的一组测试用例，仍然可以达到100%的判定覆盖，所以判定覆盖也无法发现上述的逻辑错误。
3.2.3条件覆盖
特点：条件覆盖要求设计足够多的测试用例，运行被测程序，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。在本例中有两个判断if(x>0 && y>0)（记为P1）和if(magic < 0)（记为P2），共计三个条件x>0（记为C1）、y>0（记为C2）和magic<0（记为C3）。
用例设计：
数据 C1 C2 C3 P1 P2
{x=3, y=3} T T F T F
{x=-3, y=0} F F T F T
三个条件的各种可能取值都满足了一次，达到了100%条件覆盖的标准，同时也到达了100%判定覆盖的标准。但并不能保证达到100%条件覆盖标准的测试用例（组）都能到达100%的判定覆盖标准，看下面的例子：
数据 C1 C2 C3 P1 P2
{x=3, y=0} T F T F T
{x=-3, y=15} F T F F F
既然条件覆盖标准不能100%达到判定覆盖的标准，也就不一定能够达到100%的语句覆盖标准了。
优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试。
缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。
3.3.4判定-条件覆盖
特点：设计足够多的测试用例，运行被测程序，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值也至少被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准。
用例设计：
数据 C1 C2 C3 P1 P2
{x=3, y=3} T T F T F
{x=-3, y=0} F F T F T
所有条件的可能取值都满足了一次，而且所有的判断本身的判定结果也都满足了一次。
优点：达到100%判定-条件覆盖标准一定能够达到100%条件覆盖、100%判定覆盖和100%语句覆盖。判定-条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
缺点：未考虑条件的组合情况。
3.3.5条件组合覆盖
特点：要求设计足够多的测试用例，运行被测程序，使得被测试程序中每个判定中条件结果的所有可能组合至少执行一次。注意：
1）条件组合只针对同一个判断语句内存在多个条件的情况，让这些条件的取值进行笛卡尔乘积组合。
2）不同的判断语句内的条件取值之间无需组合。
3）对于单条件的判断语句，只需要满足自己的所有取值即可。
用例设计：
数据 C1 C2 C3 P1 P2
{x=3, y=0} T F T F T
{x=-3, y=15} F T F F F
{x=3, y=3} T T F T F
{x=-3, y=0} F F T F T
C1和C2处于同一判断语句中，它们的所有取值的组合都被满足了一次。
优点：多重条件覆盖准则满足判定覆盖、条件覆盖、判定-条件覆盖准则。
缺点：线性地增加了测试用例的数量。但上面的例子中，只走了两条路径a-c-e-f和a-b-d-f，而本例的程序存在三条路径。所以条件组合覆盖不能保证所以的路径被执行。
3.3.6路径覆盖
特点：设计足够的测试用例，运行被测程序，覆盖程序中所有可能的路径。
用例设计：
数据 C1 C2 C3 P1 P2 路径
这条路径不可能实现 T T T T T a-b-d-f
{x=-3, y=3} F T T F T a-c-d-f
{x=3, y=3} T T F T F a-b-e-f
{x=-3, y=15} F T F F F a-c-e-f
所有可能的路径都满足过一次。
优点：这种测试方法可以对程序进行彻底的测试，比前面五种覆盖面都广。100%满足路径覆盖，一定能100%满足判定覆盖标准（因为路径就是从判断的某条分支走的）。
缺点： 100%满足路径覆盖，但并不一定能100%满足条件覆盖（C2只取到了真），也就不能满足100%条件组合覆盖。
经过分析，它们之间的关系可以用下图表示（路径覆盖在该图无法表示）：
从上例可知，单独采用任何一种逻辑覆盖方法都不能完全覆盖所有的测试用例，任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。所以在实际测试用例设计中，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。要根据不同需要和不同测试用例设计特征，将不同的设计方法组合起来，交叉使用，以实现最佳的测试用例输出。
4、基本路径测试法
4.1简介
基本路径测试法包括4个步骤，在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例要保证在测试中程序的每个可执行路径至少执行一次。以下举例具体说明这4个步骤：
4.2举例说明
4.2.1画出控制流图
可将流程图映射到一个相应的流图。
程序的控制流图是对程序流程图简化得到的，它可以更加突出的描述程序控制流的结构。流图只有二种图形符号，圆称为流图的节点，代表一个或多个语句，流程图中一个处理方框序列和一个菱形决测框可被映射为一个节点。箭头称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句。由边和节点限定的范围称为区域，计算区域时应包括图外部的范围。
如图所示：
如果判断中的条件表达式是由一个或多个逻辑运算符 (or, and) 连接的复合条件表达式时，要为每个条件创建一个独立的节点，包含条件的节点被称为判定节点，一个判定节点发出两条或多条边。例如：
1 ）if a or b
2） x
3） else
4 ）y
对应的逻辑为：
4.2.2计算圈复杂度
通过对控制流图的分析和判断来计算环形复杂度。
圈复杂度也成为环形复杂度、程序环境复杂度，是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有路径至少执行一次的测试数量的上界。有以下三种方法计算圈复杂度：
1）流图中区域的数量对应于环型的复杂性。
2）给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中节点的数量。
3）给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定节点的数量。
4.2.3导出独立路径
从程序的环路复杂性可导出程序的独立路径条数。
一条独立路径是指，和其他的独立路径相比，程序中至少引进一个新的处理语句集合或一个新判断条件的程序通路。即独立路径必须至少包含一条在定义路径之前不曾用到的边。如果只是已有路径的简单合并，并未包含任何新边，则不是独立路径。
此例可得出四个独立的路径。V(G)值正好等于该程序的独立路径的条数。
路径1：4-14
路径2：4-6-7-14
路径3：4-6-8-10-13-4-14
路径4：4-6-8-11-13-4-14
4.2.4设计测试用例
根据独立路径，来设计输入数据，使程序分别执行到上面四条路径。
为了确保基本路径集中的每一条路径的执行，根据判断节点给出的条件，选择适当的数据以保证某一条路径被测试到，满足上面例子基本路径集的测试用例是：
5、其他方法
1）静态结构分析：主要是以图形的方式表现程序的内部结构。测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、函数内部控制流图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表（包括控制流分析、数据流分析、接口分析、表达式分析），检查软件是否存在缺陷或错误。
2）静态质量度量法：根据ISO/IEC 9126质量模型作为基础，我们可以构造质量度量模型，用于评估软件的各个方面。该模型从上到下分为3层：质量因素、分类标准和度量规则。度量规则：度量规则使用了代码行数、注释频度等参数度量软件的各种行为属性，度量规则参数表。 分类标准“软件的可维护性采用以下四个分类标准来评估：可分析性、可修改性、稳定性、可测性。每个分类标准由一系列度量规则组成，各个规则分配一个权重，由规则的取值与权重值计算出每个分类标准的取值。质量因素的取值与分类标准的计算方式类似：依据各分类标准取值组合权重方法计算。
3）循环覆盖测试法：目的就是检查循环结构的有效性。通常，循环可以划分为简单循环、嵌套循环、串接循环和 非结构循环4类。
三、总结
在实践中发现，静态白盒测试和基于计算机的动态测试是互补的，缺少任何一种，都会降低错误检查的效率。项目组可根据项目的实际情况，来决定哪种白盒测试方法更适合。
1、定义
白盒测试又称结构测试、透明盒测试、逻辑驱动测试、基于代码的测试。盒子指被测试的软件 ，白盒指盒子是可视的。白盒测试是一种测试用例设计方法，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例。白盒测试主要针对被测程序的源代码，主要用于软件验证，不考虑软件的功能实现，只验证内部动作是否按照设计说明书的规定进行。
2、目的
我们一方面注重软件功能需求的实现，另一方面还要注重程序逻辑细节，主要是因为软件自身的缺陷，具体如下：
1）逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。日常处理往往被很好地了解，而“特殊情况”的处理则难于发现。
2）我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，只有路径测试才能发现这些错误。
3）代码中的笔误是随机且无法杜绝的。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。很多被语法检查机制发现，但是其他的会在测试开始时才会被发现。
4）功能测试本身的局限性。如果程序实现了没有被描述的行为，功能测试是无法发现的，例如病毒，而白盒测试很容易发现它。
3、目标
采用白盒测试必须遵循以下几条原则，才能达到测试的目标：
1）保证一个模块中的所有独立路径至少被测试一次。
2）所有逻辑值均需测试真 (true) 和假 (false) 两种情况。
3）检查程序的内部数据结构，保证其结构的有效性。
4）在上下边界及可操作范围内运行所有循环。
4、黑白灰区别
黑盒测试技术：也称功能测试或数据驱动测试，只关注规格说明中的功能，测试者在程序接口对软件界面和软件功能进行测试，它只检查实现了的功能是否按照“用户需求说明书”的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。主要用于软件确认测试，结合兼容、性能测试等方面，但黑盒测试不能保证已经实现的各个部分都被测试到。黑盒测试适用于各阶段测试。
白盒测试技术：只关注软件产品的测试，深入到代码一级的测试，它是知道产品内部结构，通过测试来检测产品内部动作是否按照“设计规格说明书”的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，主要用于软件验证，不能够确保产品已经实现了规格说明中的所有功能。白盒测试通常用于单元测试。
灰盒测试技术：在白盒测试中交叉使用黑盒测试、在黑盒测试中交叉使用白盒测试的方法。它结合了白盒测试和黑盒测试的要素，涉及输入和输出，但使用关于代码和程序操作等信息设计测试用例。灰盒测试通常用于集成测试。
测试是从用户需求的角度去对软件的质量进行检测。具体使用黑盒测试、白盒测试、灰盒测试，不需要太明确的来划分，我们应该多角度去设计测试用例，多角度去测试软件、发现bug，才是一个测试工程师应该具备的思想。总之，建议测试人员在测试过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充，以保证测试的完整性。
二、白盒测试方法
1、简介
白盒测试主要是检查程序的内部结构、逻辑、循环和路径。测试是基于覆盖全部代码、分支、路径、条件。根据测试程序是否运行，白盒测试分静态白盒测试和动态白盒测试两种。
静态白盒测试也称为结构分析，是在不执行程序的条件下审查软件设计、体系结构和代码，从而找出软件缺陷的过程。测试对象是文档、代码等非计算机执行的部分。在项目中使用静态白盒测试是基于这样的原则：错误发现得越早，改正错误的成本越低，正确改正错误的可能性越大，改正错误时可能引发的其他错误的数量也越少。静态白盒测试方法包括代码检查法、静态结构分析法、静态质量度量法。常用的是代码检查法，这些方法在程序开始编码之后、基于计算机的动态测试开始之前使用。
动态白盒测试也称为结构化测试，是在使用和运行程序的条件下，软件测试员查看代码内部结构和实现方式来确定哪些要测试，哪些不要测试，如何开展测试，怎样设计和执行测试用例。白盒测试的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。动态白盒测试常用的测试用例设计方法有逻辑覆盖法（逻辑驱动测试）和基本路径测试法两种。
下面具体介绍一下三种常用的白盒测试方法：
2、代码检查法
2.1简介
代码检查法主要检查代码和程序设计的一致性，代码结构的合理性，代码编写的标准性、可读性，代码逻辑表达的正确性等方面。检查方式包括桌面检查、代码走查、代码审查三种方式。
目的：检查程序是不是按照某种标准或规范编写的。
目标：发现程序缺陷，改进软件的质量。
需要的文档：程序设计文档、程序的源代码清单、编码规范、代码缺陷检查表等。在进行代码检查时，代码缺陷检查表就是测试用例，检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误。
优缺点：代码检查法能快速找到缺陷，一旦发现错误，能够在代码中对其进行精确定位，从而降低了错误修正的成本。代码检查看到的是问题本身而非问题的征兆。但是代码检查非常耗费时间，而且代码检查需要知识和经验的积累。
2.2代码审查和走查
两种方法的形成、流程一样，规程、方法不一样。具体来说：
代码审查和走查都是以小组为单位阅读代码，它是一系列规程和错误检查方法的集合。审查或走查小组通常由不需要对程序细节很了解的协调人员、程序的编码人员、程序的设计人员、测试专家四人组成。都是以会议的形式进行。会议理想时间为90-120分钟之间，按照每小时阅读 150行代码的速度进行。对大型软件应安排多个会议同时进行，每个会议处理一个或几个模块或子程序。
代码审查规程和方法：在代码审查会议上，程序作者逐条语句讲述程序的逻辑结构，参与人根据“代码缺陷检查表”分析程序，检查内容包括编码标准规范和错误列表。编码规范是指团队根据自己的经验和风格进行设置的一些规范。错误列表一般是代码潜在的bug，由于某种代码写法虽然没有语法错误，但是可能存在错误，比如会导致线程死锁，这些都是错误列表应该检查的。程序员之间可以隔一定的时间抽取代码进行审查。结束会议后，把这些经验汇成列表，作为下次代码审查的依据，并针对错误修正进行跟踪。输出文档是“代码检查记录表”，此表主要内容日期、住持人、参与人员、范围、发现的问题、问题处理、跟踪检查等。
代码走查规程和方法：在代码走查会议上，参与者参考“设计规格书”使用计算机来执行代码。测试人员准备一些简单的测试用例，它的作用是提供启动代码走查和质疑程序员逻辑思路及其他设想的手段。在会议期间，把测试数据沿程序的逻辑结构走一遍，程序的状态记录在纸或白板上以供监视。在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。
2.3桌面检查
桌面检查是一种传统的检查方法，由程序员检查自己编写的程序。程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关文档，由于程序员熟悉自己的程序及其程序设计风格，桌面检查由程序员自己进行可以节省时间，但应避免主观片面性。桌面检查的效果逊色于代码检查和走查，但桌面检查胜过没有检查。
3、逻辑覆盖测试
3.1简介
测试覆盖率：用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。 测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。 测试覆盖率包括功能点覆盖率和结构覆盖率，功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等。
逻辑覆盖法：以程序内部的逻辑结构为基础的用例设计方法，它通过对程序逻辑结构的遍历实现程序的覆盖。根据覆盖目标的不同，逻辑覆盖分为语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定-条件覆盖（分支-条件覆盖）、条件组合覆盖、路径覆盖六种覆盖测试方法。语句覆盖每条语句至少执行一次。判定覆盖每个判定/分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定-条件覆盖同时满足判定覆盖和条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。它们发现错误的能力呈由弱至强的变化。
3.2举例说明
以下举例说明六种覆盖测试方法：
如源代码（C语言）：
int logicExample(int x, int y)
{
int magic=0;
if(x>0 && y>0)
{
magic = x+y+10; // 语句块1
}
else
{
magic = x+y-10; // 语句块2
}
if(magic < 0)
{
magic = 0; // 语句块3
}
return magic; // 语句块4
}
一般逻辑覆盖测试不会直接根据源代码，而是根据流程图来设计测试用例，在没有设计文档时，要根据源代码画出流程图：
3.2.1语句覆盖
特点：语句覆盖要求设计足够多的测试用例，运行被测程序，使得程序中每条语句至少被执行一次。在本例中，可执行语句是指语句块1到语句块4中的语句。
用例设计：
数据 语句
{x=3, y=3} 1、4
{x=-3, y=0} 2、3、4
通过这两个测试用例即达到语句覆盖的标准（测试用例组不是唯一的）。
优点：可以很直观地从流程图得到测试用例，可以测试所有的执行语句。
缺点：语句覆盖不能准确的判断运算中的逻辑关系错误。假设第一个判断语句if(x>0 && y>0)中的“&&”被错误地写成了“||”，即if(x>0 || y>0)，使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的语句覆盖。在六种逻辑覆盖标准中，语句覆盖标准最弱的。
3.2.2判定覆盖
特点：判定覆盖（分支覆盖）要求设计足够多的测试用例，运行被测程序，使得程序中的每个判断的“真”和“假”都至少被执行一次。即：程序中的每个分支至少执行一次。在本例中共有两个判断if(x>0 && y>0)（记为P1）和if(magic < 0)（记为P2）。
用例设计：数据 P1 P2
{x=3, y=3} T F
{x=-3, y=0} F T
两个判断的取真、假分支都已经被执行过，所以满足了判断覆盖的标准。
优点：由于可执行语句要不就在判定的真分支，要不就在假分支上，判定覆盖比语句覆盖要多几乎一倍的测试路径，所以，只要满足了判定覆盖标准就一定满足语句覆盖标准。因此，判定覆盖比语句覆盖强。
缺点：判定覆盖会忽略条件中取或（or）的情况。假设第一个判断语句if(x>0 && y>0)中的“&&”被程序员错误地写成了“||”，使用上面设计出来的一组测试用例，仍然可以达到100%的判定覆盖，所以判定覆盖也无法发现上述的逻辑错误。
3.2.3条件覆盖
特点：条件覆盖要求设计足够多的测试用例，运行被测程序，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。在本例中有两个判断if(x>0 && y>0)（记为P1）和if(magic < 0)（记为P2），共计三个条件x>0（记为C1）、y>0（记为C2）和magic<0（记为C3）。
用例设计：
数据 C1 C2 C3 P1 P2
{x=3, y=3} T T F T F
{x=-3, y=0} F F T F T
三个条件的各种可能取值都满足了一次，达到了100%条件覆盖的标准，同时也到达了100%判定覆盖的标准。但并不能保证达到100%条件覆盖标准的测试用例（组）都能到达100%的判定覆盖标准，看下面的例子：
数据 C1 C2 C3 P1 P2
{x=3, y=0} T F T F T
{x=-3, y=15} F T F F F
既然条件覆盖标准不能100%达到判定覆盖的标准，也就不一定能够达到100%的语句覆盖标准了。
优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试。
缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。
3.3.4判定-条件覆盖
特点：设计足够多的测试用例，运行被测程序，使得被测试程序中的每个判断本身的判定结果（真假）至少满足一次，同时，每个逻辑条件的可能值也至少被满足一次。即同时满足100%判定覆盖和100%条件覆盖的标准。
用例设计：
数据 C1 C2 C3 P1 P2
{x=3, y=3} T T F T F
{x=-3, y=0} F F T F T
所有条件的可能取值都满足了一次，而且所有的判断本身的判定结果也都满足了一次。
优点：达到100%判定-条件覆盖标准一定能够达到100%条件覆盖、100%判定覆盖和100%语句覆盖。判定-条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。
缺点：未考虑条件的组合情况。
3.3.5条件组合覆盖
特点：要求设计足够多的测试用例，运行被测程序，使得被测试程序中每个判定中条件结果的所有可能组合至少执行一次。注意：
1）条件组合只针对同一个判断语句内存在多个条件的情况，让这些条件的取值进行笛卡尔乘积组合。
2）不同的判断语句内的条件取值之间无需组合。
3）对于单条件的判断语句，只需要满足自己的所有取值即可。
用例设计：
数据 C1 C2 C3 P1 P2
{x=3, y=0} T F T F T
{x=-3, y=15} F T F F F
{x=3, y=3} T T F T F
{x=-3, y=0} F F T F T
C1和C2处于同一判断语句中，它们的所有取值的组合都被满足了一次。
优点：多重条件覆盖准则满足判定覆盖、条件覆盖、判定-条件覆盖准则。
缺点：线性地增加了测试用例的数量。但上面的例子中，只走了两条路径a-c-e-f和a-b-d-f，而本例的程序存在三条路径。所以条件组合覆盖不能保证所以的路径被执行。
3.3.6路径覆盖
特点：设计足够的测试用例，运行被测程序，覆盖程序中所有可能的路径。
用例设计：
数据 C1 C2 C3 P1 P2 路径
这条路径不可能实现 T T T T T a-b-d-f
{x=-3, y=3} F T T F T a-c-d-f
{x=3, y=3} T T F T F a-b-e-f
{x=-3, y=15} F T F F F a-c-e-f
所有可能的路径都满足过一次。
优点：这种测试方法可以对程序进行彻底的测试，比前面五种覆盖面都广。100%满足路径覆盖，一定能100%满足判定覆盖标准（因为路径就是从判断的某条分支走的）。
缺点： 100%满足路径覆盖，但并不一定能100%满足条件覆盖（C2只取到了真），也就不能满足100%条件组合覆盖。
经过分析，它们之间的关系可以用下图表示（路径覆盖在该图无法表示）：
从上例可知，单独采用任何一种逻辑覆盖方法都不能完全覆盖所有的测试用例，任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。所以在实际测试用例设计中，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。要根据不同需要和不同测试用例设计特征，将不同的设计方法组合起来，交叉使用，以实现最佳的测试用例输出。
4、基本路径测试法
4.1简介
基本路径测试法包括4个步骤，在程序控制流图的基础上，通过分析程序的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例要保证在测试中程序的每个可执行路径至少执行一次。以下举例具体说明这4个步骤：
4.2举例说明
4.2.1画出控制流图
可将流程图映射到一个相应的流图。
程序的控制流图是对程序流程图简化得到的，它可以更加突出的描述程序控制流的结构。流图只有二种图形符号，圆称为流图的节点，代表一个或多个语句，流程图中一个处理方框序列和一个菱形决测框可被映射为一个节点。箭头称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句。由边和节点限定的范围称为区域，计算区域时应包括图外部的范围。
如图所示：
如果判断中的条件表达式是由一个或多个逻辑运算符 (or, and) 连接的复合条件表达式时，要为每个条件创建一个独立的节点，包含条件的节点被称为判定节点，一个判定节点发出两条或多条边。例如：
1 ）if a or b
2） x
3） else
4 ）y
对应的逻辑为：
4.2.2计算圈复杂度
通过对控制流图的分析和判断来计算环形复杂度。
圈复杂度也成为环形复杂度、程序环境复杂度，是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有路径至少执行一次的测试数量的上界。有以下三种方法计算圈复杂度：
1）流图中区域的数量对应于环型的复杂性。
2）给定流图G的圈复杂度V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中节点的数量。
3）给定流图G的圈复杂度V(G)，定义为V(G)=P+1，P是流图G中判定节点的数量。
4.2.3导出独立路径
从程序的环路复杂性可导出程序的独立路径条数。
一条独立路径是指，和其他的独立路径相比，程序中至少引进一个新的处理语句集合或一个新判断条件的程序通路。即独立路径必须至少包含一条在定义路径之前不曾用到的边。如果只是已有路径的简单合并，并未包含任何新边，则不是独立路径。
此例可得出四个独立的路径。V(G)值正好等于该程序的独立路径的条数。
路径1：4-14
路径2：4-6-7-14
路径3：4-6-8-10-13-4-14
路径4：4-6-8-11-13-4-14
4.2.4设计测试用例
根据独立路径，来设计输入数据，使程序分别执行到上面四条路径。
为了确保基本路径集中的每一条路径的执行，根据判断节点给出的条件，选择适当的数据以保证某一条路径被测试到，满足上面例子基本路径集的测试用例是：
5、其他方法
1）静态结构分析：主要是以图形的方式表现程序的内部结构。测试者通过使用测试工具分析程序源代码的系统结构、数据结构、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、函数内部控制流图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表（包括控制流分析、数据流分析、接口分析、表达式分析），检查软件是否存在缺陷或错误。
2）静态质量度量法：根据ISO/IEC 9126质量模型作为基础，我们可以构造质量度量模型，用于评估软件的各个方面。该模型从上到下分为3层：质量因素、分类标准和度量规则。度量规则：度量规则使用了代码行数、注释频度等参数度量软件的各种行为属性，度量规则参数表。 分类标准“软件的可维护性采用以下四个分类标准来评估：可分析性、可修改性、稳定性、可测性。每个分类标准由一系列度量规则组成，各个规则分配一个权重，由规则的取值与权重值计算出每个分类标准的取值。质量因素的取值与分类标准的计算方式类似：依据各分类标准取值组合权重方法计算。
3）循环覆盖测试法：目的就是检查循环结构的有效性。通常，循环可以划分为简单循环、嵌套循环、串接循环和 非结构循环4类。
三、总结
在实践中发现，静态白盒测试和基于计算机的动态测试是互补的，缺少任何一种，都会降低错误检查的效率。项目组可根据项目的实际情况，来决定哪种白盒测试方法更适合。
TAG:
