2007年测试经验总结之白盒测试初步理解

2007年度测试经验总结

白盒测试初步理解51Testing软件测试网[JwZ+Yhfb

一．《软件测试》中对动态白盒测试的定义

根据以往的测试经验，我如果从程序内部逻辑得到信息，来设计我的测试用例，将会提高测试用例的有效性，逐渐感觉如果只按照黑盒测试方法来设计，一方面，从代码的覆盖上来看，有很多测试数据是多余的，另一方面，看到了内部代码我才知道一些隐含的需求也是需要测试的，测试数据又是不够的。所以，如果时间许可，我都会尽量的去理解代码设计，有一段这种经验之后，2007年中期，偶然再一次去阅读《软件测试》这本书，才发现原来我已经向白盒测试靠拢了，请看《软件测试》的76页中对动态白盒测试的定义：“动态的白盒测试是利用查看代码功能和实现方式得到的信息来确定哪些要测试，哪些不要测试，如何开展测试。动态白盒测试的另一个常用名称是结构测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。”所以，我认为自己是有做白盒测试，但是不成熟的白盒测试。验证了自我做测试以来的想法：设计用例的时候，先黑盒后白盒，这才是我心目中真正的测试。

 51Testing软件测试网5O Kp8K:|$@b$g~

二．在文档不全的情况下，黑盒测试也可以从代码中了解

黑盒测试也需要看懂代码，因为输入和输出的获得如果不是从需求和设计文档中而来，那么必须自己看懂代码得到这些信息，不然黑盒测试也不能算是完整。我以前的测试过程中，看代码的目的除了找到输入和输出外，还想寻找一些没有注意到的功能点和其他代码分支，后面这些可以称做白盒测试。

三．系统功能测试中使用黑盒＋白盒

单元测试有白盒也有黑盒，系统测试同样也有白盒和黑盒，可以结合黑盒和白盒方法进行测试用例的设计，如下面的步骤：

a.根据测试需求，运用黑盒测试方法（例如等价类、边界值等），设计出黑盒的测试用例。

b.然后研究代码看被测功能或模块是如何实现的，利用白盒知识增减测试用例，所谓白盒知识是对内部信息等价分配的一种提炼，删除冗余或多余的测试用例，增加黑盒所看不到的测试用例。

在测试的思考过程中，当把被测模块当作一个黑盒子时，需要考虑数据和状态时，从总体观察被测模块在系统中所处的位置，以及该模块的原始数据的来源和输出数据的流向，然后再考虑该模块自身的功能需求；当把被测模块当作一个白盒子时，从程序内部的逻辑设计细节思考。对被测模块越熟悉，测试的准确性和把握性越大。

先黑盒的原因是，可以真正测试功能或模块的用意。如果先白盒，检查代码，就会偏向模块工作方式建立测试用例。

动态白盒测试是非常强大的方法，通过提供关于测试对象的“内部”信息大幅减轻测试工作。了解代码的细节可以消除冗余的测试用例，增加针对原先没有考虑到的区间的测试用例。这两种方式都可以大幅提高测试的成效。

 51Testing软件测试网 N I8o"xSx4K+r q

四．白盒测试方法的初步使用

目前我对白盒测试的六种方法的看法，是根据具体程序流程来选用最合适的方法，最基本的方法是路径覆盖，然后在每条路径上找出每个外部的输入数据，然后再寻找判断语句的每个条件变量的边界值。不过这只是我的初步想法，需要不断通过实际操作来总结经验。

五．试着画数据流程图和程序流程图

白盒测试的前提是看懂程序流程和数据流，我使用了visio工具，方便画出数据流程图和程序流程图。先画被测模块的外部数据流程图，再画被测模块的内部程序流程图。51Testing软件测试网5q2VRpb:v

验证测试是否通过的标准，基本上都是检查数据流的逻辑和走向是否正确，因为功能实现的原理就是数据流的变化。51Testing软件测试网9knFbXd5ss

六．我对后台单元测试的理解

单元测试的对象是一个一个的模块，而模块可以是一个函数，可以是一个可运行的C文件，可以是一个功能模块。单元测试需要驱动模块或打桩模块。在unix的后台系统中，最常见的是低层函数被高层函数调用，可以被认为是底层模块被高层模块调用，如果对底层函数进行单元测试，合理的做法是编写一个测试驱动以独立与程序其他部分的形式测验该模块，驱动模块在底层函数的接口上进行接口测试。51Testing软件测试网#M3]_?Hzn

七．有时候需要舍弃白盒测试

如果你对某个系统不熟悉，而且也没有文档可看，修改的源文件不清楚，需要在短时间内完成测试任务，那么只好舍弃白盒，只用黑盒测试方法，比如说今天的另一个测试任务，修改的地方比较小，但看不到代码，也没有设计文档，所以，这次修改受到的影响范围无法从代码范围内确定，所以只有从黑盒角度出发，选择一些相关的测试需求和测试用例。51Testing软件测试网LO O@$Sr``O

 51Testing软件测试网n'_8j`?%B