最新最强的单元测试工具--VcTester上场了

来源:http://www.guanqinbiaoye.com 作者:计算机操作 人气:160 发布时间:2020-01-24
摘要:详情请登陆:    1、工具简单介绍:     VcTester是与VC(注:Visual   C++及Visual  Studio开发套件是微软发布的产品)配套使用的新一代单元测试工具,分共享版与商用版两大系列,其主要

详情请登陆:  
  1、工具简单介绍:  
  VcTester是与VC(注:Visual   C++及Visual   Studio开发套件是微软发布的产品)配套使用的新一代单元测试工具,分共享版与商用版两大系列,其主要功能包括:脚本化测试驱动(包括修改变量与调用函数)、脚本桩、支持持续集成测试、测试覆盖率统计(仅商用版本)、生成测试报告(仅商用版本)等。  
  VcTester共享版由CSE共享软件基金(CSF,CSE   Shareware   Foundation)赞助开发,拥有自主版权,共享版系列版本按最终用户许可协议(EULA,End-User   License   Argeement)方式授权,终端用户可免费获取、免费使用。  
  2、相关评价:  
  VcTester除了白盒测试工具所具有的常规功能如:测试驱动、函数打桩、测试覆盖率统计(商用版本)、生成测试报告(商用版本)、测试消息编辑器/解析器(商用版本)外,VcTester还集成了第四代白盒测试的核心思想。共享版本可免费获得,相比同类测试工具,它的最大特点是在线测试,包括对变量的在线修改和函数在线调用、测试结果在线评估及改进。在线测试提供了所见即所得的操作模式,因为直观易用,符合程序员的思维习惯,相信该工具会给大家带来耳目一新的感觉。

关键词: 白盒测试 第4代 测试方法 4GWM 在线测试 持续测试 灰盒 脚本驱动 脚本桩

摘  要: 本文是第4代白盒测试方法的理论介绍,描述3个关键领域内9项关键特征的概念与固有特征。同时介绍白盒测试发展历程,对比说明第4代白盒测试方法与以往测试方法的异同及优化要素。

缩略语:

4GWM:The 4th Generation White-box-testing Methodology,第4代白盒测试方法

XP:Extreme Programming,极限编程

TDD:Test Driven Development,测试驱动开发

IID:Incremental and Iterative Development,渐增迭代开发

CSE:Common Script Engine,通用脚本引擎(一种近似于python的脚本语言)

PCO:Points of Control and Observation,观察控制点 

TDF:Test Design First,测试设计先行

MCDC:Modified Condition/Decision Coverage

 

1背景

1.1   白盒测试的范围

白盒测试是软件测试体系中一个分支,测试关注对象是一行行可见代码,如果代码不可见就不是白盒,是黑盒测试了。白盒测试也通常被认为是单元测试与集成测试的统称,但这个概念是相对的,与当前项目遵循的研发流程有关,某些流程把白盒测试划分为单元测试与集成测试,而另一些流程,把白盒测试划分为模块单元测试、模块系统测试、多模块集成测试,还有一些流程把单元测试与集成测试混为一体,统称为持续集成测试。

随着测试技术的发展,白盒测试的概念也在发生变化,比如,本文提倡一种介于白盒与黑盒之间的灰盒操作模式,针对被测对象同样是可见源码,这时,白盒测试不只是白盒了。尽管如果此,我们仍遵循大家习惯的思维方式——把本文倡导的测试方法仍冠名为:第4代白盒测试方法(4GWM,The 4th Generation White-box-testing Methodology)。

本文讨论白盒测试方法,范围限定在功能测试之前,针对源码行的所有测试,即,被测对象是看得到的功能源码,每个测试者必须先获得源码才能实施测试。

1.2第1代与第2代白盒测试

说到第4代白盒测试方法,就不能不回顾前几代方法。在测试发展初期,测试工具很不成熟,人们通常以单步调试代替测试,或采用assert断言、print语句等简单方式的组织测试体系,即我们所谓的第1代白盒测试,这一时期的测试是半手工的,没实现自动化,测试效果也严重依赖测试者(或者调试者)的个人能力,缺少统一规范的评判标准。

当然,调试算不算测试在业界尚存争议,单论调试的目的(为了定位问题)与操作方式(过程不可重复),不应把调试看作测试,但调试确能发现软件BUG,显然这也是一种测试手段。本文暂不评判调试用作测试手段是否合理,但有必要先确定调试是测试的某种形式,把它看作特定历史阶段或特定场景下的产物。特定历史阶段大家比较容易理解,调试伴随编程语言是天生的,测试工具却是后天形成,开发人员总喜欢认调试器当亲妈,测试工具则是爱管不管的后妈。特定场景是什么?比如,某种生僻的RTOS平台根本找不到对应测试工具,怎么办?拿调试做测试是无奈之中的必然。这里,我们不否认调试也是一种测试,在此基础上再优化其操作过程,使调试能更好的服务于测试(下文介绍“灰盒调测”还有进一步论述)。

第1代白盒测试方法存在严重缺陷,主要有:测试过程难以重用,成功经验无法拷贝,测试结果也难以评估并用于改进,这些对于团队运作是非常致命的。

到第2代白盒测试,上述主要缺陷得到克服,将测试操作改用一种形式化语言(通常称为测试脚本)来表述,脚本可以组合成用例,用例可组合成测试集,用例与测试集再统一到测试工程中管理,把测试脚本保存到文件,重用问题解决了。另外,代码覆盖率功能使测试结果可以评估,能直观的看到哪些代码或分支未被覆盖,然后有针对性的增加测试设计。目前市面上有大量商用工具,如RTRT、CodeTest、Visual Tester、C++ Tester等都属于这第2代白盒测试工具。

1.3第3代白盒测试方法

按理说,第2代白盒测试工具已经很完善了,那第3代又是什么?

软件测试是一门复杂科学,支持自动测试与覆盖率评估后不见得就能成功实施白盒测试,尤其重要的是,第2代白盒测试解决了重复测试问题,但没解决持续测试问题。简单来说,重复测试使测试操作能以规范格式记录,当被测对象没变化(或变化很少)时,测试用例是可重用的,但如果源码大幅调整(甚至重构),或者按迭代模式不停追加新功能时,如何维持用例同步增长,并与源码一起同步更新,已经不是简单的增强用例复用能力就能解决的。因为代码更新与用例更新交织进行,测试用例与被测源码一样对等的成为日常工作对象,必然促使原有工作模式与测试方法产生变革,概括而言,白盒测试过程要从一次测试模式过渡到持续测试模式。

第3代白盒测试工具以xUnit为代表,包括JUnit、DUnit、CppUnit等,当然,我们列举xUnit工具,并不说这些第3代工具就比第2代工具要好。事实上,目前xUnit工具在功能上普遍赶不上第2代商用工具,许多xUnit工具甚至连基本的覆盖率都支持不了,况且,xUnit使用被测代码的编程语言写用例,普遍效率低下。这里,我们区别第2代方法与第3代方法,主要是测试理念上差别,而不以工具差别为基准,因为工具配套跟进还与诸多现实因素相关,是另一层面话题。

1.4第4代白盒测试方法的产生背景

xUnit是XP实践的重要支撑工具,XP作为一种软件开发方法论,总体虽然敏捷,但很脆弱,它对程序员非常友好,但对组织不是。以xUnit为代表的XP测试实践同样表现出这一特质,据已有案例分析,XP持续集成在java项目中成功的很多,C++有一些, C语言项目就很少了,为什么编程语言对持续集成的影响如此深远?

第4代白盒测试尝试解决软件测试的深层次矛盾:测试的投入产出比问题。大家知道,研发资源总是有限的,你可以把测试人员与开发人员的比例配到1:1,也可以配到2:1,甚至5:1,但你做不到10:1、100:1,如果你有钱,也有人,完全可以按100:1或更高比例配置,这时所有测试瓶颈都没了,你可以让测试人员边喝咖啡边干活,因为每新写1行代码总有人编出100行脚本测试它,还怕产品不稳定吗?不过,疯子才会这么做,比尔盖兹有的是钱,一年捐款十多亿美金,但不见得微软旗下产品就经常让测试人员比开发人员多出一倍。我的意思是,测试资源必然是受限的,这个前提下我们才讨论第1代、第2代白盒测试向第3代、第4代演化的必要性。基于同样原理的xUnit工具,针对不同开发语言效果截然不同,这说明什么?说明这种实践的瓶颈仍在投入产出比上,也就是上面所说的1:1效果,还是2:1,抑或是5:1效果。

高效平台下的高效工具可以大幅提高测试效率,测试投入与开发投入之比小于1:1就能保证测试质量,项目就成功了,而低效平台下的低效工具,必然要投入更多测试资源(比方5:1)才能保证效果,拐点就在这儿,哪个公司禁得起5:1的测试投入?!从这个意上说,推出第4代白盒测试方法意义重大,我们要尝试解决决定项目成败的拐点问题。

事先申明一下,下文涉及持续集成与测试先行(或称测试驱动开发,TDD)实践,虽然这两者都是XP的重要组成部分,但我们无意宣扬XP,事实上,真正能适应XP的项目范围并不宽,跳过需求与预设计直接启动项目的做法,足以让客户敬而生畏,把文档丢给狮子,那是无政府主义散兵游勇行径。不过,XP确有许多闪闪发光的实践,持续集成只要运用恰当还是不错的模式,测试先行的理念也不赖,只要不过度实施就好。

2什么是第4代白盒测试方法

第4代白盒测试方法(4GWM)针对前几代测试方法不足提出,许多理念仍继承第2代与第3代测试方法。下表简要的列出第1代到第4代白盒方法的主要差别:

 

 

是否评估测试效果

是否自动测试

是否持续测试

是否调测一体

第1代白盒测试方法

第2代白盒测试方法

第3代白盒测试方法

第4代白盒测试方法

 

上表中,“是否评估测试效果”指是否有覆盖率或其它评估测试效果的指标,“是否自动测试”指是否形式化描述测试操作并将它用于再次测试,“是否持续测试”指是否以按持续集成的模式开展测试,“是否调测一体”指是否将测试设计高效的融入产品编码与调试的日常实践之中。

第2代白盒测试与第3代的分水岭在于“是否持续集成”,或许您会说,我的项目也是经常出版本,反复追加测试用例的呀,请注意,这是两个概念,Joel测试——改进代码的12个步骤中有一条:“编写新代码之前先修复故障吗?”,先修复故障是质量优先的项目,否则进度优先,这是两种完全不同的行事风格,前者时时测试,始终每写一两个函数就补全相关测试用例,测试实践是融入开发全过程的,而后者依时间表行事,测试仅是特定阶段里的任务。

对了,测试方法怎么跟软件开发方法扯上了?因为测试不是孤立的,测试是否有效强烈依赖于软件工程方法,就像早期的开发语言,只有assert语句与测试相关,发展到现有的C#,单元测试框架也是该语言的固有组件了。测试脚本也是一种产品代码,测试方法实际与软件开发方法密不可分的,这在第3代与第4代白盒测试中体现得很充分。

第4代白盒测试方法相对第3代方法,增加了将测试过程(包括测试设计、执行与改进)高效的融入开发全过程,这里,“高效的”是关键词,那如何才算高效呢?我们先简单了解4GWM在3个关键领域的9项关键特征,如下:

A.      第一关键域:在线测试

1、  在线测试驱动

2、  在线脚本桩

3、  在线测试用例设计、运行,及评估改进

B.      第二关键域:灰盒调测

4、  基于调用接口

5、  调试即测试

6、  集编码、调试、测试于一体

C.      第三关键域:持续测试

7、  测试设计先行

8、  持续保障信心

9、  重构测试设计

3为什么持续集成

为什么要持续集成?这个问题太重要了,我们专门拎出来讲,请大家先不急于跳过本章去看4GWM的9个关键特征怎么定义的。

本文由威尼斯游戏网站发布于计算机操作,转载请注明出处:最新最强的单元测试工具--VcTester上场了

关键词:

最火资讯