什么软件公司适合做接口白盒测试？

kelequy · 发表于 2011-8-9 14:36:35

本人做过五年接口白盒测试，这里的接口白盒测试主要是指以模块(Module)为单位，在能看到设计文档和代码的前提下，通过调用模块提供的接口进行的测试。其中使用到的测试方法与功能测试(Functional Test)大抵相同，也是诸如等价类(Equivalent Partitioning)、边界值(Boundary Analysis)、决策表(Decision Table)等等的方法。常听到说白盒测试比黑盒测试的要求较高，但是具体高在哪里就没有详细的讨论。在此我总结我的经验和个人对什么公司适合做接口白盒测试的看法如下

1.专业的白盒测试人员
无论是黑盒测试还是白盒测试，要做好测试，基本的条件有两个：一是测试理论，二是系统/业务知识。当然，有人会说任何人都可以做黑盒功能测试，操作一下谁不会呢？是的，我不反对临时拉人做功能测试，但前提条件是研发人员觉得乱提Bug是可以接受的，产品经理觉得由于大量不是问题的Bug花费时间的风险是可以接受的话，我没有意见。不过，为了专业地测试，那两个基本条件必不可少。测试理论可以令测试人员更有效率地测试，系统/业务知识可以令测试人员正确地测试。这两个条件是步向专业的第一步。
专业的第二步，是准确地描述Bug和重现Bug。准确地描述Bug分为两方面，一是口头交流上，要将问题的来龙去脉的大概说清楚。二是书面上，如测试报告和缺陷管理(Defect Management System)系统上的描述要清楚。有些人嘴上说得好，测试报告或缺陷管理系统上写的又是另一回事，有些人书面上写得好，但是在最需要体现效率的即时沟通上却可以把人说得如堕雾里。重现Bug，这其实是一个很有挑战性的问题，它是检验一个测试人员，尤其是黑盒功能测试人员能力的试金石。软件测试的大师级人物James Bach有博文讨论过这个问题，我在此不再重复。
由于白盒测试需要写测试代码与测试脚本实现测试用例，有时还要写桩模块(Stake Module)与驱动模块(Driver Module)来协助测试，这些工作的特点决定了白盒测试人员需要有以下两种能力来进行专业的测试。一是对软件设计的理解能力，对代码的理解能力，二是自身的软件设计能力与编码能力。接口白盒测试的一大特点是测试人员与开发人员对最终用户在图形界面(Graphics User Interface)上的体检不太清晰。他们工作的依据都是在于系统分析师/设计师的软件需求规格(Requirement Specification)、系统设计等等的文档。在这个层面上，白盒测试比黑盒测试对用户体验的敏感度要弱，想象力要差。因此，白盒测试必需扬长避短，发挥逻辑分析能力的优势，通过对系统的理解与测试对象关联，从而较全面地考虑问题。

2.层次鲜明的产品软件架构
想想看，假如你要测试的模块有五千行代码，当你开始着手搭建测试环境时，发现这个模块需要依赖大量其他模块，而且它们耦合是在模块内部是hard code写死了的，最终搭建好一个可以运行的测试环境需要五万行代码。任何一个负责测试这样一个模块的人都会崩溃的。层次鲜明的软件架构是软件可测的前提，除此之外，良好的文档也是必不可少的。我无意去探讨如何量化软件架构层次鲜明的程度。只是觉得有些基本的东西需要提供出来，接口测试才能更快，更有效地开展。最起码接口说明、状态转换图与流程图、调用示例是可以提供而且基本与代码实现保持一致。如果有专门查询内部状态的接口、获取内部数据的接口就更好了。

要做好白盒接口测试，在设计上需要有将系统拆成模块后还能测试的意识。拆解的模块还能测试，那么第一步是可以编译，再下一步是可以运行，再来是可以获取结果，甚至是可以获取各种状态与数据。整个系统或单个模块的可测性随着条件满足的越多而提升得越多。

3.足够长的产品版本周期
毫无疑问的是，如果要应付紧急的版本发布测试，黑盒功能测试的成本是最低的。因为即使未经过任何培训，临时的测试人员也可以进行最初级的测试。但是接口白盒测试却行不通，由于第一点提到的工作要求，接口白盒测试人员需要训练（无论是培训还是工作实践）后才能开展工作。

另外，按照传统的软件开发瀑布模型，系统的规格说明出来之后，可以开始设计系统测试用例。模块的设计出来之后，可以开始模块的测试用例或集成测试用例。编码完成后，开始单元测试。单元测试完成后便开始集成测试。接着才是系统测试、确认测试等等。那么可以说，模块测试或集成测试的理论准备时间是少于系统测试的。如果准备时间太短，还会造成即使投入更多的人力，也不会提高整体速度，甚至会降低的现象。

因此，足够长的产品版本周期是接口白盒测试的条件之一。

4.足够的白盒测试工具

除了上面提到的准备短的问题之外，接口白盒测试的另一个挑战来自于为了达到覆盖(Coverage)而产生的工作量。一是输入输出参数/结果的覆盖，二是测试对象内部逻辑覆盖。输入输出参数/结果的覆盖的组合条件太多了，如果要人手去逐一列举花费的时间是惊人的。如果有工具辅助自动生成（虽然自动生成的大部分是无用的），以供测试人员去选择是可以节省不少时间的。内部逻辑覆盖就更需要工具来分析代码的逻辑路径、复杂度、程序片等等的东西，这样的分析工作量是写代码两到三倍。没有工具去做这件事，其效率是极其低下的！

不要忘了，还要有一个实用的测试框架，来让开发/测试人员的测试工作更加轻松。否则每个测试的人都要写一个自己的测试框架，一来造成重复工作，二来造成维护成本高企。这些都是软件开发的绊脚石。