第4代白盒测试方法介绍--理论篇

关键词： 白盒测试 第4代 测试方法 4GWM 在线测试 持续测试 灰盒 脚本驱动 脚本桩

摘  要： 本文是第4代白盒测试方法的理论介绍，描述3个关键领域内9项关键特征的概念与固有特征。同时介绍白盒测试发展历程，对比说明第4代白盒测试方法与以往测试方法的异同及优化要素。

缩略语：

4GWM：The 4^th Generation White-box-testing Methodology，第4代白盒测试方法

XP：Extreme Programming，极限编程

TDD：Test Driven Development，测试驱动开发

IID：Incremental and Iterative Development，渐增迭代开发

CSE：Common Script Engine，通用脚本引擎（一种近似于python的脚本语言）

PCO：Points of Control and Observation，观察控制点

TDF：Test Design First，测试设计先行

MCDC：Modified Condition/Decision Coverage

 

1背景

1.1白盒测试的范围

白盒测试是软件测试体系中一个分支，测试关注对象是一行行可见代码，如果代码不可见就不是白盒，是黑盒测试了。白盒测试也通常被认为是单元测试与集成测试的统称，但这个概念是相对的，与当前项目遵循的研发流程有关，某些流程把白盒测试划分为单元测试与集成测试，而另一些流程，把白盒测试划分为模块单元测试、模块系统测试、多模块集成测试，还有一些流程把单元测试与集成测试混为一体，统称为持续集成测试。

随着测试技术的发展，白盒测试的概念也在发生变化，比如，本文提倡一种介于白盒与黑盒之间的灰盒操作模式，针对被测对象同样是可见源码，这时，白盒测试不只是白盒了。尽管如果此，我们仍遵循大家习惯的思维方式——把本文倡导的测试方法仍冠名为：第4代白盒测试方法（4GWM，The 4^th Generation White-box-testing Methodology）。

本文讨论白盒测试方法，范围限定在功能测试之前，针对源码行的所有测试，即，被测对象是看得到的功能源码，每个测试者必须先获得源码才能实施测试。

1.2第1代与第2代白盒测试

说到第4代白盒测试方法，就不能不回顾前几代方法。在测试发展初期，测试工具很不成熟，人们通常以单步调试代替测试，或采用assert断言、print语句等简单方式的组织测试体系，即我们所谓的第1代白盒测试，这一时期的测试是半手工的，没实现自动化，测试效果也严重依赖测试者（或者调试者）的个人能力，缺少统一规范的评判标准。

当然，调试算不算测试在业界尚存争议，单论调试的目的（为了定位问题）与操作方式（过程不可重复），不应把调试看作测试，但调试确能发现软件BUG，显然这也是一种测试手段。本文暂不评判调试用作测试手段是否合理，但有必要先确定调试是测试的某种形式，把它看作特定历史阶段或特定场景下的产物。特定历史阶段大家比较容易理解，调试伴随编程语言是天生的，测试工具却是后天形成，开发人员总喜欢认调试器当亲妈，测试工具则是爱管不管的后妈。特定场景是什么？比如，某种生僻的RTOS平台根本找不到对应测试工具，怎么办？拿调试做测试是无奈之中的必然。这里，我们不否认调试也是一种测试，在此基础上再优化其操作过程，使调试能更好的服务于测试（下文介绍“灰盒调测”还有进一步论述）。

第1代白盒测试方法存在严重缺陷，主要有：测试过程难以重用，成功经验无法拷贝，测试结果也难以评估并用于改进，这些对于团队运作是非常致命的。

到第2代白盒测试，上述主要缺陷得到克服，将测试操作改用一种形式化语言（通常称为测试脚本）来表述，脚本可以组合成用例，用例可组合成测试集，用例与测试集再统一到测试工程中管理，把测试脚本保存到文件，重用问题解决了。另外，代码覆盖率功能使测试结果可以评估，能直观的看到哪些代码或分支未被覆盖，然后有针对性的增加测试设计。目前市面上有大量商用工具，如RTRT、CodeTest、Visual Tester、C++ Tester等都属于这第2代白盒测试工具。

1.3第3代白盒测试方法

按理说，第2代白盒测试工具已经很完善了，那第3代又是什么？

软件测试是一门复杂科学，支持自动测试与覆盖率评估后不见得就能成功实施白盒测试，尤其重要的是，第2代白盒测试解决了重复测试问题，但没解决持续测试问题。简单来说，重复测试使测试操作能以规范格式记录，当被测对象没变化（或变化很少）时，测试用例是可重用的，但如果源码大幅调整（甚至重构），或者按迭代模式不停追加新功能时，如何维持用例同步增长，并与源码一起同步更新，已经不是简单的增强用例复用能力就能解决的。因为代码更新与用例更新交织进行，测试用例与被测源码一样对等的成为日常工作对象，必然促使原有工作模式与测试方法产生变革，概括而言，白盒测试过程要从一次测试模式过渡到持续测试模式。

第3代白盒测试工具以xUnit为代表，包括JUnit、DUnit、CppUnit等，当然，我们列举xUnit工具，并不说这些第3代工具就比第2代工具要好。事实上，目前xUnit工具在功能上普遍赶不上第2代商用工具，许多xUnit工具甚至连基本的覆盖率都支持不了，况且，xUnit使用被测代码的编程语言写用例，普遍效率低下。这里，我们区别第2代方法与第3代方法，主要是测试理念上差别，而不以工具差别为基准，因为工具配套跟进还与诸多现实因素相关，是另一层面话题。

1.4第4代白盒测试方法的产生背景

xUnit是XP实践的重要支撑工具，XP作为一种软件开发方法论，总体虽然敏捷，但很脆弱，它对 程序员 非常友好，但对组织不是。以xUnit为代表的XP测试实践同样表现出这一特质，据已有案例分析，XP持续集成在java项目中成功的很多，C++有一些， C语言项目就很少了，为什么编程语言对持续集成的影响如此深远？

第4代白盒测试尝试解决软件测试的深层次矛盾：测试的投入产出比问题。大家知道，研发资源总是有限的，你可以把测试人员与开发人员的比例配到1:1，也可以配到2:1，甚至5:1，但你做不到10:1、100:1，如果你有钱，也有人，完全可以按100:1或更高比例配置，这时所有测试瓶颈都没了，你可以让测试人员边喝咖啡边干活，因为每新写1行代码总有人编出100行脚本测试它，还怕产品不稳定吗？不过，疯子才会这么做，比尔盖兹有的是钱，一年捐款十多亿美金，但不见得微软旗下产品就经常让测试人员比开发人员多出一倍。我的意思是，测试资源必然是受限的，这个前提下我们才讨论第1代、第2代白盒测试向第3代、第4代演化的必要性。基于同样原理的xUnit工具，针对不同开发语言效果截然不同，这说明什么？说明这种实践的瓶颈仍在投入产出比上，也就是上面所说的1:1效果，还是2:1，抑或是5:1效果。

高效平台下的高效工具可以大幅提高测试效率，测试投入与开发投入之比小于1:1就能保证测试质量，项目就成功了，而低效平台下的低效工具，必然要投入更多测试资源（比方5:1）才能保证效果，拐点就在这儿，哪个公司禁得起5:1的测试投入？！从这个意上说，推出第4代白盒测试方法意义重大，我们要尝试解决决定项目成败的拐点问题。

事先申明一下，下文涉及持续集成与测试先行（或称测试驱动开发，TDD）实践，虽然这两者都是XP的重要组成部分，但我们无意宣扬XP，事实上，真正能适应XP的项目范围并不宽，跳过需求与预设计直接启动项目的做法，足以让客户敬而生畏，把文档丢给狮子，那是无政府主义散兵游勇行径。不过，XP确有许多闪闪发光的实践，持续集成只要运用恰当还是不错的模式，测试先行的理念也不赖，只要不过度实施就好。

2什么是第4代白盒测试方法

第4代白盒测试方法（4GWM）针对前几代测试方法不足提出，许多理念仍继承第2代与第3代测试方法。下表简要的列出第1代到第4代白盒方法的主要差别：

	是否评估测试效果	是否自动测试	是否持续测试	是否调测一体