网易测试经理对白盒测试的一些看法与总结

Time will tell.

之前一直从事服务端的测试工作，虽然以前做过几年时间，但融合了自动化测试和功能测试以及单元测试。精力有限，接触到的白盒测试比较浅。近期项目进入了调整期，有时间整理下对于项目测试中的代码测试一些感触。 顺便对未来的工作方向和计划做好准备工作。

那么，到底白盒测试和功能测试以及模块测试、自动化测试之间应该如何进行抉择，如何进行搭配、互补，来达到项目高质，高效的目的呢？ 站在整个项目的角度，从以下几个维度对白盒测试进行了一些思考：

1、什么项目可以考虑白盒测试

1. 大项目，周期比较长（因为需要前期介入review RD代码）
2. 功能测试不放心的项目，接口比较明确，重要函数做的修改
3. 对整个项目了解较清晰，时间要求较低
4. 新项目
5. 逻辑较复杂的模块
6. 通用类的
7. 异步的、多线程的程序
8. 函数用到的外部数据较多的不适合做，构造起来非常复杂，如大量的信令、词典等

2、如何结合白盒测试和其它测试方法

首先，需要根据项目特点，比如项目周期，项目难度等来确定测试方法。

然后，如果满足做白盒测试的条件，则需要先确定白盒测试处于项目测试中的什么阶段，如果是迭代或优化类的项目，建议进行分层测试，重点对更新的代码进行白盒测试，其它的进行传统的自动化或手工回归测试。

如果是周期比较长的全新项目，可以考虑在RD编码阶段介入，了解接口和底层内部函数构造，为白盒测试做准备。

为了避免白盒测试和功能测试的交叉工作量，可以底层库用白盒测试，上层功能测试用功能测试，在功能测试上就不再关注底层的测试，可借助分层测试思想。

3、如何降低白盒测试成本

不管从技术还是从周期上，白盒测试成本比较大，所以站在高效和简易的基础上，尽量借助工具来尽量减少白盒测试范围，比如可以借助：

1. 手工测试 + 代码覆盖率测试来覆盖一部分代码
2. C代码可以用gdb（其它语言也有）来构造一些比较难引入的上层变量，再结合代码覆盖率来做
3. 单测工具，比如cppunit，gtest等来做接口测试
4. 其它
   我们之前的做法是将模块测试做成自动化CASE，然后新版本来后，进行自动化测试回归，并结合代码覆盖率来出一份覆盖报告（从分支和代码行两个维度），然后再对新升级的代码进行review，并拓展用例来覆盖，如果功能测试实在无法模拟，会采取gtest，最后仍不好模拟会采用gdb挂载的方式

4、 白盒测试收益和风险

1. 功能测试无法深入到底层的测试上，白盒测试可以
2. 投入成本较大，收益较小
3. 通过白盒测试只能发现函数级的错误，较难发现函数接口之间的错误
4. 时间会增加，覆盖率会增加
5. 可促进rd的单元测试做的更充分
6. 短期收益不明显，长远会有收益

5、白盒测试方法

1. 最基层的函数做详细的测试(倾向于功能)，策略较复杂的做详细测试(倾向于逻辑)，通过自己写5.2. 程序去调用被测函数，外层的通过GDB的方式去测试
2. 自己写驱动去调用被测程序或构造上下层来验证被测程序
3. 通过程序包装被测程序，通过多线程的方式去实现多个动作之间的交互
4. cppunit去做，但调用关系较复杂的测试很难去实现，支持case的管理、验证
5. 可借助gtest去实现，扩展为和c++test类似的功能

---

以上内容就分享到这里，学习犹如逆水行舟，不进则退。

关注工纵号【白码会说】，有不定期活动软件测试自动化书籍抽奖小福利。及学习资
源和面试资源。

推荐一个Python自动化资料学习扣裙：175317069。有视频学习资源分享，也有行业
技术人分析解答。