您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 专题 > 技术专题 > 正文

单元测试本质:面向逻辑块

发表于:2017-01-09 作者:王彤 来源: kailesoft.com
    单元测试是最早阶段的软件测试,面对的目标最小,可以综合使用黑盒测试方法和白盒测试方法,按理说,单元测试用例的设计应该是最简单的,但实际上,单元测试用例的设计常让人感觉无从下手,这是什么原因?是代码真的不具有“可测性”吗?还是测试思路和方法不对?正确的测试思路和方法是什么?单元测试工具应该具备什么样的功能,才能支持快速地构建测试用例?

    
大道至简,意思是掌握了事物的本质,事情就会变得很简单。反之,如果事情很复杂很麻烦,往往表示没有抓住本质。

    
单元测试的本质是什么?首先要看单元测试的目标是什么。单元测试检测代码功能逻辑,实现高质高效的编程。只要真正做过单元测试的工程师都知道,单元测试要做的,能做的,就是检测代码的功能逻辑,扯上其他东西是没有任何意义的。既然单元测试是对代码功能逻辑的检测,那么,测试用例要做的,就是针对代码的功能逻辑,设定其输入,并判断其输出是否符合预期,从而检测功能逻辑的正确性。功能逻辑是由什么实现的?逻辑块。所以,单元测试的本质,是面向逻辑块,单元测试用例的本质,是逻辑块的输入输出,也就是设定逻辑块的各种可能输入,及对应的预期输出。

    
一旦我们把目光转向逻辑块,所有的事情就会变得简单。来看一个典型示例。“典型”的意思是,如果这个代码不会测,实际项目也就不会测,因为同样的测试问题会大量存在;反过来,如果这个代码可以测得很好很快,那么实际项目的测试就基本上没有问题,因为已经掌握了正确的测试思路和测试方法。这个代码的功能是,取得职位列表,将职位标题拼成短信并发送给用户。参数是一个数据流,包含用户的手机号和想要什么类型的职位等信息,程序从数据库里读取对应的职位列表和一个映射表,映射表用来检查哪些职位已经发送给用户,然后把职位的标题拼成短信并且发送给用户。代码使用C++编写,但它所表达的测试问题和测试思想,则是通用的。

    

    

    请想一想,这个代码的测试思路是什么?也就是说,哪些变量要设置输入,哪些变量要判断输出?如果按照传统的方法,输入是参数,输出是返回值,那基本没法测。但是如果面向逻辑块(上面的代码分为两张图片,第二张图片实现函数的功能逻辑,也就是我们要测的逻辑块),立刻就有了思路:输入是链表对象objList和映射表对象map里的数据,输出是拼接出来的字符串,在两个地方需要判断它的值。

    
具备了面向逻辑块的测试思路,就可以将“可测性”这个词扔进垃圾桶了,除非代码真的糟糕得太过分,否则都不难测。至于代码之间的耦合,那是再正常不过的事情,代码反映了客观事物,客观事物本身就是互相关联的,代码能没有耦合?如果一个函数有多个逻辑块,同样很简单,各个逻辑块分别测试就是了。

    
面向逻辑块,测试用例的数据也很简单,因为逻辑计算涉及到的数据往往很少,且一般是基本类型。上面的示例,数据算是比较麻烦的,多数代码的测试数据量都少于这个示例。虽然这个示例的数据看起来很吓人,又有链表,又有映射表,但实际上,逻辑计算中涉及到的输入就是一些标题(title),字符串而已,也就是说,我们要加入到链表和映射表中的对象指针,不管它的类型多复杂,每个对象只需要设定标题(title)就OK了。至于输出,也不过是字符串。总之,对于这个示例,用例的输入是一系列字符串,输出也是一些字符串。

    
传统单元测试思想,是面向函数,即用例由函数的输入输出构成,这在一些特例中没有问题,例如三角形函数、排序函数之类最底层函数。这些函数,只有一个逻辑块,且逻辑块的输入输出,与函数的输入输出完全一致,当然可以使用函数的输入输出来构建测试用例。传统的单元测试用例设计技术,都拿这些特例作为基础,当面对含有耦合关系的代码时,反而作为特例来处理,要使用编写桩代码、设置模拟对象之类的麻烦方法来解决(实际上很多时候解决不了问题,例如,前面示例中的输出怎么办?)。实际项目中,代码存在耦合关系是常态,完全没有耦合的代码反而很少。这种拿特例当常态,拿常态当特例的方法,在本质上是错误的,因此必然很麻烦,从根本上造成了单元测试难度大、成本高。总之,面向函数来设计单元测试用例,测试将很困难,至于主张单元测试要面向对象、面向模块,那纯粹是胡扯。

    
有了面向逻辑块的测试思想,测试思路是很简单了,但是,如何设置逻辑块的输入值和输出值呢?逻辑块的输入,除了参数、成员变量之类的常规变量,还包括底层输入,即调用底层函数获得的输入,如前面示例中的链表和映射表对象中的数据;很多时候,还包括局部输入,即在被测试代码执行过程中对某些变量的实时赋值,如局部静态输入、中断输入、界面输入等。逻辑块的输出,除了返回值、成员变量之类的常规变量,还包括局部输出,即被测试代码执行过程中对某些变量的实时判断,如前面示例中直接发送出去的短信需要在发送前实时判断。这些问题,恰恰表明了单元测试的另一个简单:选择工具很简单。如果工具不能直接地、方便地设定逻辑块的输入输出,那基本上没法用,或者成本很高(至少十倍以上),因此,选择工具的最主要指标,就是能否直接地、方便地设定逻辑块的输入输出。Visual Unit 4可以通过在表格中填写数据,直接设定逻辑块的输入输出,例如前面的示例,使用Visual Unit 4,只要点点鼠标,在表格中填写一些字符串,就可以构建出链表和映射表中的数据,以及判断所拼接的短信是否正确。

    
也许有人认为,对于前面的示例,如果面向函数,通过设定参数来获得链表和映射表的数据,也可以达到同样的测试效果,甚至可以同时检测代码所调用的其他函数,例如用于解析用户信息的GetUserInfo ()函数,用于从数据库读取职位列表的GetJobList()函数。这种想法是完全错误的,白白浪费时间和精力,为什么?
    1、这些函数可能还没有实现,这在并行开发中很常见;
    2、这些函数或者它们所依赖的函数在测试时可能被隔离,这在大型项目中很常见;
    3、相关设备在测试时可能不存在,例如,单元测试一般不连接数据库;
    4、相关设备无法返回测试需要的数据,例如,一个取环境温度的底层函数,总是返回固定值;
    5、即使以上问题都不存在,通过设置参数来间接获得逻辑块的输入也可能非常困难,例如前面的示例,必须熟悉通讯协议,了解GetUserInfo ()函数的工作过程,并在参数中填写正确的数据流,且数据库里有合适的数据,才可能获得链表和映射表中的数据。

    面向逻辑块,则完全不需要考虑这些问题,无论多大的项目,无论多少人并行开发,都可以在开始编写代码时,就做到边开发边测试。至于底层函数,谁家的孩子谁抱,应该由编写者直接进行测试,这样才能全面地检测它的功能逻辑。


    
总之,单元测试应该面向逻辑块,只有这样,才能迅速产生测试思路,才能快速构建用例数据,才能检测功能逻辑的方方面面,不留死角,而判断一个单元测试工具是否可以高效地应用于实际项目,最主要的指标是能否直接地、方便地设置逻辑块的输入输出。
 
       原文链接:http://www.kailesoft.com/article/329.html