白盒测试的一些想法
上一篇 /
下一篇 2014-04-11 16:38:32
/ 个人分类：随笔
近一年多一直在从事服务端的测试工作，虽然之前也做过两年，但融合了自动化测试和功能测试以及单元测试，所以精力有限，接触到的白盒测试比较碎也比较浅。近期项目进入了调整期，有时间整理下对于项目测试中的代码测试一些感触。 顺便对未来的工作方向和计划做好准备工作。
2014年可能需要继续负责服务端项目测试工作，但到底白盒测试和功能测试以及模块测试，自动化测试之间应该如何进行抉择，如何进行搭配，相互补充，来达到项目高质，高效的目的呢？ 站在整个项目的角度，从以下几个维度对白盒测试进行了一些思考：
1. 什么样的项目可以考虑做白盒测试
- 1.1. 大项目，周期比较长（因为需要前期介入review RD代码）
- 1.2. 功能测试不放心的项目，接口比较明确，重要函数做的修改
- 1.3. 对整个项目了解较清晰，时间要求较低
- 1.4. 新项目
- 1.5. 逻辑较复杂的模块
- 1.6. 通用类的
- 1.7. 异步的、多线程的程序
- 1.8. 函数用到的外部数据较多的不适合做，构造起来非常复杂，如大量的信令、词典等
2. 如何结合白盒测试和其它测试方法
首先，需要根据项目特点，比如项目周期，项目难度等来确定测试方法。
然后，如果满足做白盒测试的条件，则需要先确定白盒测试处于项目测试中的什么阶段，如果是迭代或优化类的项目，建议进行分层测试，重点对更新的代码进行白盒测试，其它的进行传统的自动化或手工回归测试。如果是周期比较长的全新项目，可以考虑在RD编码阶段介入，了解接口和底层内部函数构造，为白盒测试做准备。 为了避免白盒测试和功能测试的交叉工作量，可以底层库用白盒测试，上层功能测试用功能测试，在功能测试上就不再关注底层的测试，可借助分层测试思想。
3. 如何降低白盒测试成本
不管从技术还是从周期上，白盒测试成本比较大，所以站在高效和简易的基础上，尽量借助工具来尽量减少白盒测试范围，比如可以借助：
3.1. 手工测试+代码覆盖率测试来覆盖一部分代码
3.2. C代码可以用gdb（其它语言也有）来构造一些比较难引入的上层变量，再结合代码覆盖率来做
3.3. 单测工具，比如cppunit，gtest等来做接口测试 3.4. 其它
我们之前的做法是将模块测试做成自动化CASE，然后新版本来后，进行自动化测试回归，并结合代码覆盖率来出一份覆盖报告（从分支和代码行两个维度），然后再对新升级的代码进行review，并拓展用例来覆盖，如果功能测试实在无法模拟，会采取gtest，最后仍不好模拟会采用gdb挂载的方式
4、 白盒测试收益和风险是什么
- 4.1. 功能测试无法深入到底层的测试上，白盒测试可以
- 4.2. 投入成本较大，收益较小
- 4.3. 通过白盒测试只能发现函数级的错误，较难发现函数接口之间的错误
- 4.4. 时间会增加，覆盖率会增加
- 4.5. 可促进rd的单元测试做的更充分
- 4.6. 短期收益不明显，长远会有收益
5、白盒测试方法
- 5.1. 最基层的函数做详细的测试(倾向于功能)，策略较复杂的做详细测试(倾向于逻辑)，通过自己写5.2. 程序去调用被测函数，外层的通过GDB的方式去测试
- 5.3. 自己写驱动去调用被测程序或构造上下层来验证被测程序
- 5.5. 通过程序包装被测程序，通过多线程的方式去实现多个动作之间的交互
- 5.6. cppunit去做，但调用关系较复杂的测试很难去实现，支持case的管理、验证
- 5.7. 可借助gtest去实现，扩展为和c++test类似的功能
收藏
举报
TAG:
