首页 测试 体会 查看内容

关于白盒测试的一些想法

2014-4-25 15:52| 发布者: peter_zhang| 查看: 467| 评论: 0

摘要:   近一年多一直在从事服务端的测试工作,虽然之前也做过两年,但融合了自动化测试和功能测试以及单元测试,所以精力有限,接触到的白盒测试比较碎也比较浅。近期项目进入了调整期,有时间整理下对于项目测试中的代 ...
  近一年多一直在从事服务端的测试工作,虽然之前也做过两年,但融合了自动化测试功能测试以及单元测试,所以精力有限,接触到的白盒测试比较碎也比较浅。近期项目进入了调整期,有时间整理下对于项目测试中的代码测试一些感触。 顺便对未来的工作方向和计划做好准备工作。  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类似的功能版权声明:本文出自 800716 的51Testing软件测试博客:http://www.51testing.com/?359684原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

鲜花

握手

雷人

路过

鸡蛋

扫一扫关注最新动态

毒镜头:老镜头、摄影器材资料库、老镜头样片、摄影
爱评测 aipingce.com  
返回顶部