Visual Unit(C/C++单元测试工具)

Visual Unit是款专门为c语言和C++语言程序员们打造的单元测试工具。它具有强大的自动打桩、自动生成测试代码和用例框架、可视化编辑测试用例功能，再也不用自己去写测试的驱动代码，大幅度地提高了测试效率和时间成本，非常适用于程序员。

软件功能

自定义的完成对项目的添加、也支持对配置文件、文件的属性等添加设置

只要测试成功，即可完成对测试结果的查看

支持对需要的语言选择，包括了编译器的内置

调试的功能强大，对函数的指针进行查看

自动的完成对各种需要的数据进行使用，并且可以参见内置的函数进行数值的输入

对数组参数的处理支持，也可以将需要的数组进行更改成为NULL

而且可以直接的在表格里面进行操作，这样就无需进行例代码的改用

软件特色

对异常的情况进行快速的进行捕获，对断言进行忽略

可以将断言转换成为你需要的测试断言

对用例数据的自动折构异常进行查看

单用例执行时间超过设定时报告错误

数据的深度比较，包括了打印层数的查看

可以对测试的数据进行输入，包括了转定义main函数的功能

数组限制，只要不对设置进行影响，即可文本那成对输入、输出的项数值选择

自动用例数上限的设置，测试输出数据上限的限制

使用方法

1、添加项目

2、添加配置文件

3、设置文件属性

4、打开Test.cs Source Code开始测试，查看测试结果，Success!

安装说明

已安装更旧版本的用户，请不要卸载。VU4相对于旧版本，改进非常之大，因此无法与VU3兼容（不能打开VU3工程），因此，用VU3测试的项目请继续使用VU3完成测试。VU4和VU3互不干扰。

安装后即为演示版，可以测试示例代码，初步了解基本功能和使用方法。

运行环境

支持语言

C语言及C++语言。

编译器

目前支持的编译器包括：

VC6.0、VC2003、VC2005、VC2008、VC2010、VC2012、VC2013、VC2015、VC2017；

mingw gcc 4/5、mingw g++ 4/5；

cygwin gcc4、cygwin g++4；

支持Qt（4.x及5.x，编译器为VC或mingw g++）。

更新日志

-----------V4.5 更新 (20190307)-----------

1、重新开发了调试功能。改为利用成熟IDE来实现调试，功能较完善，也符合一般用户的使用习惯。参见启动调试。

2、之前的两种调试方式无法达到令人满意的应用体验，不再保留。

3、提升了集成测试功能：测试输出增加了显示函数调用状态（打桩、设置了底层输入或调用实际代码）功能，以及显示子函数代码执行状态的功能。参见代码窗口。

4、增加了执行单一用例功能(只执行表格中选中的用例，并测试输出界面的当前用例)。 请参考执行测试。

常见问题

Visual Unit10倍效率从何而来?

VU4完全表格驱动，不用写测试代码。请看下面的测试示例，测试涉及到：底层输入(调用底层函数产生的数据)、局部输出(执行过程中判断变量)、对象指针链表、对象指针映射表。使用VU4，点几下鼠标，在表格填几行数据就OK了，别的工具要写多少代码?且哪个能判断局部输出?岂止是十倍效率。这个示例未涉及到局部输入(中断输入、界面输入、静态输入等)，其设置也一样。有些工具宣称自动生成用例完成测试，那不是高效率，那是高忽悠，工具不可能自动了解代码功能，因此不可能生成有意义的用例。VU4任意设置逻辑块的输入输出，一个函数多个逻辑块可以对应多个表格，天下没有难测的代码!

快速完成高标准覆盖欧美航空标准MC/DC覆盖很强很科学，可是广受质疑，因为太难了，但使用VU4，则一点也不难。VU4针对未覆盖的逻辑单位，自动计算出近似用例及修改提示，根据提示修改近似用例，就可以找出隐藏很深的用例实现覆盖。完成高标准覆盖又是一个效率瓶颈，不过对VU4来说，却是一项拿手好戏，进一步拉大测试效率的领先距离。

舒服地高效地编写代码逻辑块可视编程，提交前完成覆盖，只进行粗线条调试。这就是Easy TDD，舒服而高效的编程模式。

VU4自动示出程序行为：什么输入执行什么代码产生什么输出。写几行代码就观察程序行为，看程序所做的跟你所想的是否一致、思路是否有偏差、录入是否有错误，这样编写代码尤其是复杂的逻辑计算代码，舒服而高效。

编写逻辑块应该用可视编程，其他代码可以先不测试，以保持原来的习惯以及专注。VU4自动统计近期编写或修改的函数，提交代码到版本管理工具前，或模块的编写告一段落时，再把没测的跑一下看一下，并完成覆盖，相当于代码的复查。

平常的调试，可以只用来跟踪大的流程，不必调试逻辑块。后期发现了bug，调试只用来粗略定位，例如判断是哪个函数的问题，然后补充用例数据，修改代码并使单元测试通过，问题就解决了。

下图示出代码编写过程中对程序行为的观察。本来以为功能都实现了，可是结果不对，为什么呢?如果代码是你写的，一下子就看出原因来了：指针偏移后没有恢复。图中，黑色代码是当前输入下执行的代码。写几行代码就可以观察程序行为，这就是可视编程。

下图是提交前完成覆盖的界面，对于图示的没有逻辑计算的代码，不用做任何工作，直接执行一下就可以完成覆盖。也可以把近期更新的函数一次性执行，然后查看黄灯和红灯函数。

Visual Unit单元测试实践的主要问题与解决

一、 单元测试概述

1.1 什么是单元测试

单元测试，就是针对代码单元的独立测试。为什么需要单元测试呢?这是代码的基本特性决定了的。代码有一个基本特性，就是对数据分类处理。

代码通常会有很多的判定。一个判定，就是一次分类。嵌套的判定，会使分类次数的翻倍。

如果我们在写代码的时候，有一个分类漏掉了，就会产生一个Bug;如果一个分类，虽然写了代码，但是处理不正确，也会产生一个Bug。一个函数要没有错误，必须做到两点：1，对数据的分类必须完整;2，每一个分类的处理必须正确。做到了这两点，就可以说，代码的功能逻辑是正确的。

那么，如何检测代码的功能逻辑是否正确呢?

调试，是临时的，且不完整的，例如，一个函数有十种输入，调试能覆盖五六种就不错了。而系统测试，并不针对某个具体的函数，不关注某个函数的功能逻辑是否正确。

要检测某个函数的功能逻辑，就必须要依照分类列出数据，检测代码是否对每一个分类都做了处理，而且每一个分类的处理是否正确。

——这就是单元测试。

1.2 单元测试的基本方法

由上面的分析可以看出，单元测试的基本方法就是：依数据的分类列出输入，执行被测试程序，然后，判断输出是否符合预期。

单元测试能达到什么样的效果呢?那就是：无论别人怎么样，我总是对的!

这里的“别人”，是指关联代码。“我”，是指当前正在编写或测试的代码。单元测试要做到的是，无论关联代码是否有错，都要保证我是对的。具体来说，我要考虑关联代码会产生什么样的数据，这些数据要如何分类处理，只要我的分类和处理是正确的，那么，无论别人怎么样，我总是对的。

1.3 单元测试的效益

单元测试的效益可以说是立竿见影，并且会推动整个开发过程的改进。

首先，单元测试可以保证代码的质量。因为只有单元测试，能够全面检测代码单元的功能逻辑，排除代码中大量的、细小的错误。

其次，排错成本最小。如果在编码阶段同时进行单元测试，排错成本可以忽略不计。但若到了后期，排错成本可能会增长上百倍，要是产品已经到了用户手里，那造成的损失就更难说了。

第三，提升开发效率。单元测试可以让程序行为一目了然，也就是程序行为可视化。什么叫程序行为呢?就是什么输入下，会执行哪些代码，会产生什么输出。如下图，黑色的代码是当前输入下所执行代码。

如果我们写几行代码，就可以看到程序的行为，相当于写文章时上下文可见，这可以促进我们的开发思维。如果我们的思维有了偏差，也可以及时发现。如果代码中有了错误，也可以随时排除。

那么，是不是整个项目的所有代码都做了单元测试，才能得到这些效益呢?不是的。80:20规则，在软件开发过程中也存在。也就是说，80%的代码错误，可能存在于20%的代码中;80%的编码、调试成本，可能会消耗在20%的代码上。这20%，就是算法密集度高的代码，也就是功能逻辑复杂的代码。

这些代码可能只有20%，但是却可能包含了80%的错误，消耗了80%的编码、调试时间，即使只对这部分代码进行单元测试，在提升产品的质量和开发效率方面，也会产生立竿见影的效果。

第四，自动回归。如果没有单元测试，系统测试发现了错误，当然要修改代码，而修改代码可能引入新的错误，又要进行全面的系统测试，这样就可能陷入循环，这通常也是项目延期的主要原因。

如果有了单元测试，修改代码时可以通过回归测试马上检测是否引入了新的错误。所谓回归，就是回复到原来正确的状态。

正是回归测试，使单元测试对整个开发过程的改进都产生积极影响，使项目适应频繁变化的需求。单元测试是敏捷开发的基础和核心，反过来说，有了单元测试，开发过程会自动趋于敏捷。单元测试也降低了后期测试的压力。