软件白盒测试概述

软件白盒测试的目的

软件白盒测试的特点

软件白盒测试的实施步骤

软件白盒测试的优缺点(1. 优点 2. 缺点)

软件白盒测试的测试方法(1.静态分析法 2.动态分析法)

软件白盒测试法的覆盖标准

如何挑选软件白盒测试工具

软件白盒测试之基本路径测试法(4个步骤： 工具方法：)

软件白盒测试持续改进的关键(初始阶段一： 发展阶段二： 成熟阶段三：)

软件白盒测试概述

软件白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。

用软件白盒测试产生的测试用例能够：

1)保证一个模块中的所有独立路径至少被使用一次;

2)对所有逻辑值均需测试true和false;

3)在上下边界及可操作范围内运行所有循环;

4)检查内部数据结构以确保其有效性。

这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

采用什么方法对软件进行测试呢?常用的软件测试方法有两大类：静态测试方法和动态测试方法。其中软件的静态测试不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试;而软件的动态测试是通过输入一组预先按照一定的测试准则构造的实例数据来动态运行程序，而达到发现程序错误的过程。

软件白盒测试的目的

通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

软件白盒测试的特点

依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

软件白盒测试的实施步骤

1. 测试计划阶段：根据需求说明书，制定测试进度。

2. 测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。

3. 测试执行阶段：输入测试用例，得到测试结果。

4. 测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。

软件白盒测试的优缺点

1. 优点

· 迫使测试人员去仔细思考软件的实现

· 可以检测代码中的每条分支和路径

· 揭示隐藏在代码中的错误

· 对代码的测试比较彻底

· 最优化

2. 缺点

· 昂贵

· 无法检测代码中遗漏的路径和数据敏感性错误

· 不验证规格的正确性

软件白盒测试的测试方法

软件白盒测试的测试方法总体上分为静态方法和动态方法两大类。

1.静态分析法

是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致 , 没有冲突或者没有歧义。

2.动态分析法

的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中 , 最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。

软件白盒测试法的覆盖标准

六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。

如何挑选软件白盒测试工具

软件白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。软件白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。

对开发语言的支持：软件白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C++、Visual C++、Java、Visual J++等。

代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。

·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖(Statement Coverage)的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。

·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖(Decision Coverage)。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。

·条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖(Condition Coverage)的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。

·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。

·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次;其次，程序的判定被分解为通过逻辑操作符(and、or)连接的布尔条件，每个条件对于判定的结果值是独立的。

不同的测试工具对于代码的覆盖能力也是不同的，通常能够支持修正条件判定覆盖的测试工具价格是极其昂贵的。

嵌入式软件的测试：对于嵌入式软件的测试，我们还需要一方面进一步考虑测试工具对于嵌入式操作系统的支持能力，例如DOS、Vxworks、Neculeus、Linux和Windows CE等;另一方面还需要考虑测试工具对于硬件平台的支持能力，包括是否支持所有64/32/16位CPU 和 MCU，是否可以支持 PCI/VME/CPCI 总线。

测试的可视化：软件白盒测试是工作量巨大并且枯燥的工作，可视化的设计对于测试来说是十分重要的。在选购软件白盒测试工具时，应当考虑该款测试工具的可视化是否良好，例如：测试过程中是否可以显示覆盖率的函数分布图和上升趋势图，是否使用不同的颜色区分已执行和未执行的代码段显示分配内存情况实时图表等，这些对于测试效率和测试质量的提高是具有很大的作用的。

软件白盒测试之基本路径测试法

软件白盒测试的测试方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。

其中运用最为广泛的是基本路径测试法。

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。

设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤和一个工具方法：

4个步骤：

1. 程序的控制流图：描述程序控制流的一种图示方法。

2. 程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。

3. 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。

4. 准备测试用例：确保基本路径集中的每一条路径的执行。

工具方法：

图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

程序的控制流图：描述程序控制流的一种图示方法。

圆圈称为控制流图的一个结点，表示一个或多个无分支的语句或源程序语句

流图只有二种图形符号：图中的每一个圆称为流图的结点，代表一条或多条语句。

流图中的箭头称为边或连接，代表控制流

任何过程设计都要被翻译成控制流图。

如何根据程序流程图画出控制流程图?

在将程序流程图简化成控制流图时，应注意：

在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。

边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

软件白盒测试持续改进的关键

单元测试与集成测试三种发展阶段。

初始阶段一：

刚实施或从未实施软件白盒测试的发展阶段，一个企业内只有零星的单元测试或集成测试实践，缺少成功案例。重要特点，公司成员普遍对软件白盒测试缺少概念，大致知道代码审查、单元测试、集成测试该怎么去做，但一涉及具体场景，对某模块实施单元测试或跨模块、跨子系统实施集成测试时，通常茫无头绪，不知从何下手。

发展阶段二：

软件白盒测试过程也逐渐融入研发流程，典型的例子：将软件白盒测试发现的问题纳入统计，研发过程中会以缺陷密度(每千行代码发现多少BUG)作为衡量软件白盒测试是否充分的指标，另外还会以覆盖率指标作为检查个人是否充分测试的依据。个体行为难以转化为组织行为。

开始认识到单元测试该由开发人员去做

多数尚处于混沌境界的企业会认为，单元测试应由测试人去做，可能会觉得开发人员自己编码又自己测试会陷入惯性思维，测试效果不佳。但让测试人员现实操作几次，又会冒出几个难以逾越的问题，首先是测试效率，测试人员不熟悉代码，他上手把源码读懂然后想办法做测试，要知道，单元测试面对众多琐碎的函数，随意一个开发人员一天就能写一堆新函数，所以，测试人员若把单元测试做好，通常要比开发人员自测多付10倍的精力，这一情况很致命，单元测试必然难以为继。其次，测试人员做单元测试，经常不能断定某种现象是不是问题，还得找相应开发人员去定位，问题定位了，修正问题又是个麻烦，测试人员不拥有给产品编码的权限，大量时间又浪费在反复沟通上。

会发现只拿覆盖率评估测试是否充分是不够的

引入业界工具实施覆盖率测试，当一个企业软件白盒测试做到一定程度时，会陷入一个困惑：拿覆盖率评估测试充分与否是否足够?为覆盖率而覆盖率，目标太容易达成，运行一两个高层次的业务调用，覆盖率很快就上去了，也即，如果有人想作弊，他完全可以只写很少用例就让覆盖率满足要求。有人就这个问题进一步思考，又产生另一个困惑：软件白盒测试到底测什么?测看得到的代码吗?代码覆盖率直观的表达了可见代码是否跑到，但如果规格有要求又忘实现了，覆盖率能说明什么?

不同员工做软件白盒测试，效果差别巨大。

这种现象是每个公司都会遇到的，在软件白盒测试推行初期表现尤为明显。能力强的就是很少漏测，很少遗漏问题到后续阶段，能力差的，尽管他很努力的想把每件事做好，漏测总还很多。

会有软件白盒测试无用论产生

产生软件白盒测试无用论，多半不是从理论上反对软件白盒测试，而是实践走不通，做了不少单元测试，效果不佳，发现问题留于表面，深层次逻辑问题或接口问题发现不了，所以就认定软件白盒测试没多大用处。

软件白盒测试能否成功很大程度上依赖于牛人经理或牛人QA

软件白盒测试推行初期经常，执行力强一些的经理或QA，软件白盒测试可以推行成功，执行力弱一些的就不成功。不少企业因为尝试几次单元测试都失败了，就全盘放弃白盒，只做黑盒测试了。

有一些企业坚持下来，在一两个项目组取得成功，然后针对性的优化组织机构，比如设置专门工作推动组，建设软件白盒测试专家资源池，为各个项目提供测试引导人员，进一步优化流程，把软件白盒测试的监控点纳入流程来控制。当一个企业的组织机构与流程逐步完善，软件白盒测试能否成功就较少依赖于个别牛人了。

阶段化实施软件白盒测试，测试用例无法维护

集中一段时间编码，编码完了再集中一段时间做单元测试，单元测试完了开始集成，这时又集中时间做一次集成测试，这是多数企业实施软件白盒测试的模式。这一模式下，单元测试或集成测试只是特定时间段内(比如一个版本周期内的一两星期中)才实施的活动，但产品修改代码却是时时刻都在进行的，毫无疑问的会带来一个深刻问题：用例维护与产品代码维护不同步!所以，大家就经常会看到，某个产品的第一个版本可以把单元测试完整实施一遍，而此后时不时为解决问题改代码，或为追加功能改代码，单元测试很难继续，常导致单元测试只在V1版本做一遍，其后V2、V3等版本无法再做。

或许有人会觉得，为让软件白盒测试在版本周期内坚持做下去，不见非得引入持续集成吧?试想一下，从编码到版本进入维护，开发人员独立无干扰的编码时间有多少?而从两两开始集成之后，又占去多少时间?无疑后者占去大部分时间。如果开始集成后的每次版本修改都有测试跟进，大家岂非天天写测试用例，这不是持续集成是什么?如果不想天天补充用例，隔周、隔月，或隔一个版本补充用例，怎知你增补的用例会覆盖全部变动过的代码?

嵌入式产品的单元测试该不该上单板?这个问题更多的可归结为实践上可不可行，从理论上讲没人规定单元测试就不能上单板。但现实操作中，通信产品上单板做单元测试大部分都失败。

依据实践的推论，通信软件的单元测试应在仿真环境下按纯软件的方式去做，集成测试倒是可以上单板，在真实环境下去做。

成熟阶段三：

设计用例的效率提高了，做测试不再是沉重负担。开发人员自测也上升到个人意愿，即使领导不强制，流程也不限定软件白盒测试必须要做，开发人员仍自愿去做测试。软件白盒测试已成员工的普遍行为与自发行为。

一批软件白盒测试专家，他们很清楚哪些被测对象是可以做软件白盒测试的，哪些不大容易做。即使处于软件白盒测试最高境界，也并非所有系统都适合完整的做测试，尤其那些严重依赖特定硬件环境的软件层，当白盒专家识别出哪些模块不宜做单元测试或集成测试后，他会考虑替代方案，比如加强代码审查、加强同行评审、为特定接口追加模拟器设计等。