Visual Unit是款專門為c語言和C++語言程序員們打造的單元測試工具。它具有強(qiáng)大的自動(dòng)打樁、自動(dòng)生成測試代碼和用例框架、可視化編輯測試用例功能，再也不用自己去寫測試的驅(qū)動(dòng)代碼，大幅度地提高了測試效率和時(shí)間成本，非常適用于程序員。

軟件功能

自定義的完成對項(xiàng)目的添加、也支持對配置文件、文件的屬性等添加設(shè)置

只要測試成功，即可完成對測試結(jié)果的查看

支持對需要的語言選擇，包括了編譯器的內(nèi)置

調(diào)試的功能強(qiáng)大，對函數(shù)的指針進(jìn)行查看

自動(dòng)的完成對各種需要的數(shù)據(jù)進(jìn)行使用，并且可以參見內(nèi)置的函數(shù)進(jìn)行數(shù)值的輸入

對數(shù)組參數(shù)的處理支持，也可以將需要的數(shù)組進(jìn)行更改成為NULL

而且可以直接的在表格里面進(jìn)行操作，這樣就無需進(jìn)行例代碼的改用

軟件特色

對異常的情況進(jìn)行快速的進(jìn)行捕獲，對斷言進(jìn)行忽略

可以將斷言轉(zhuǎn)換成為你需要的測試斷言

對用例數(shù)據(jù)的自動(dòng)折構(gòu)異常進(jìn)行查看

單用例執(zhí)行時(shí)間超過設(shè)定時(shí)報(bào)告錯(cuò)誤

數(shù)據(jù)的深度比較，包括了打印層數(shù)的查看

可以對測試的數(shù)據(jù)進(jìn)行輸入，包括了轉(zhuǎn)定義main函數(shù)的功能

數(shù)組限制，只要不對設(shè)置進(jìn)行影響，即可文本那成對輸入、輸出的項(xiàng)數(shù)值選擇

自動(dòng)用例數(shù)上限的設(shè)置，測試輸出數(shù)據(jù)上限的限制

使用方法

1、添加項(xiàng)目

2、添加配置文件

3、設(shè)置文件屬性

4、打開Test.cs Source Code開始測試，查看測試結(jié)果，Success!

安裝說明

已安裝更舊版本的用戶，請不要卸載。VU4相對于舊版本，改進(jìn)非常之大，因此無法與VU3兼容（不能打開VU3工程），因此，用VU3測試的項(xiàng)目請繼續(xù)使用VU3完成測試。VU4和VU3互不干擾。

安裝后即為演示版，可以測試示例代碼，初步了解基本功能和使用方法。

運(yùn)行環(huán)境

支持語言

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、重新開發(fā)了調(diào)試功能。改為利用成熟IDE來實(shí)現(xiàn)調(diào)試，功能較完善，也符合一般用戶的使用習(xí)慣。參見啟動(dòng)調(diào)試。

2、之前的兩種調(diào)試方式無法達(dá)到令人滿意的應(yīng)用體驗(yàn)，不再保留。

3、提升了集成測試功能：測試輸出增加了顯示函數(shù)調(diào)用狀態(tài)（打樁、設(shè)置了底層輸入或調(diào)用實(shí)際代碼）功能，以及顯示子函數(shù)代碼執(zhí)行狀態(tài)的功能。參見代碼窗口。

4、增加了執(zhí)行單一用例功能(只執(zhí)行表格中選中的用例，并測試輸出界面的當(dāng)前用例)。 請參考執(zhí)行測試。

常見問題

Visual Unit10倍效率從何而來?

VU4完全表格驅(qū)動(dòng)，不用寫測試代碼。請看下面的測試示例，測試涉及到：底層輸入(調(diào)用底層函數(shù)產(chǎn)生的數(shù)據(jù))、局部輸出(執(zhí)行過程中判斷變量)、對象指針鏈表、對象指針映射表。使用VU4，點(diǎn)幾下鼠標(biāo)，在表格填幾行數(shù)據(jù)就OK了，別的工具要寫多少代碼?且哪個(gè)能判斷局部輸出?豈止是十倍效率。這個(gè)示例未涉及到局部輸入(中斷輸入、界面輸入、靜態(tài)輸入等)，其設(shè)置也一樣。有些工具宣稱自動(dòng)生成用例完成測試，那不是高效率，那是高忽悠，工具不可能自動(dòng)了解代碼功能，因此不可能生成有意義的用例。VU4任意設(shè)置邏輯塊的輸入輸出，一個(gè)函數(shù)多個(gè)邏輯塊可以對應(yīng)多個(gè)表格，天下沒有難測的代碼!

快速完成高標(biāo)準(zhǔn)覆蓋歐美航空標(biāo)準(zhǔn)MC/DC覆蓋很強(qiáng)很科學(xué)，可是廣受質(zhì)疑，因?yàn)樘�難了，但使用VU4，則一點(diǎn)也不難。VU4針對未覆蓋的邏輯單位，自動(dòng)計(jì)算出近似用例及修改提示，根據(jù)提示修改近似用例，就可以找出隱藏很深的用例實(shí)現(xiàn)覆蓋。完成高標(biāo)準(zhǔn)覆蓋又是一個(gè)效率瓶頸，不過對VU4來說，卻是一項(xiàng)拿手好戲，進(jìn)一步拉大測試效率的領(lǐng)先距離。

舒服地高效地編寫代碼邏輯塊可視編程，提交前完成覆蓋，只進(jìn)行粗線條調(diào)試。這就是Easy TDD，舒服而高效的編程模式。

VU4自動(dòng)示出程序行為：什么輸入執(zhí)行什么代碼產(chǎn)生什么輸出。寫幾行代碼就觀察程序行為，看程序所做的跟你所想的是否一致、思路是否有偏差、錄入是否有錯(cuò)誤，這樣編寫代碼尤其是復(fù)雜的邏輯計(jì)算代碼，舒服而高效。

編寫邏輯塊應(yīng)該用可視編程，其他代碼可以先不測試，以保持原來的習(xí)慣以及專注。VU4自動(dòng)統(tǒng)計(jì)近期編寫或修改的函數(shù)，提交代碼到版本管理工具前，或模塊的編寫告一段落時(shí)，再把沒測的跑一下看一下，并完成覆蓋，相當(dāng)于代碼的復(fù)查。

平常的調(diào)試，可以只用來跟蹤大的流程，不必調(diào)試邏輯塊。后期發(fā)現(xiàn)了bug，調(diào)試只用來粗略定位，例如判斷是哪個(gè)函數(shù)的問題，然后補(bǔ)充用例數(shù)據(jù)，修改代碼并使單元測試通過，問題就解決了。

下圖示出代碼編寫過程中對程序行為的觀察。本來以為功能都實(shí)現(xiàn)了，可是結(jié)果不對，為什么呢?如果代碼是你寫的，一下子就看出原因來了：指針偏移后沒有恢復(fù)。圖中，黑色代碼是當(dāng)前輸入下執(zhí)行的代碼。寫幾行代碼就可以觀察程序行為，這就是可視編程。

下圖是提交前完成覆蓋的界面，對于圖示的沒有邏輯計(jì)算的代碼，不用做任何工作，直接執(zhí)行一下就可以完成覆蓋。也可以把近期更新的函數(shù)一次性執(zhí)行，然后查看黃燈和紅燈函數(shù)。

Visual Unit單元測試實(shí)踐的主要問題與解決

一、 單元測試概述

1.1 什么是單元測試

單元測試，就是針對代碼單元的獨(dú)立測試。為什么需要單元測試呢?這是代碼的基本特性決定了的。代碼有一個(gè)基本特性，就是對數(shù)據(jù)分類處理。

代碼通常會有很多的判定。一個(gè)判定，就是一次分類。嵌套的判定，會使分類次數(shù)的翻倍。

如果我們在寫代碼的時(shí)候，有一個(gè)分類漏掉了，就會產(chǎn)生一個(gè)Bug;如果一個(gè)分類，雖然寫了代碼，但是處理不正確，也會產(chǎn)生一個(gè)Bug。一個(gè)函數(shù)要沒有錯(cuò)誤，必須做到兩點(diǎn)：1，對數(shù)據(jù)的分類必須完整;2，每一個(gè)分類的處理必須正確。做到了這兩點(diǎn)，就可以說，代碼的功能邏輯是正確的。

那么，如何檢測代碼的功能邏輯是否正確呢?

調(diào)試，是臨時(shí)的，且不完整的，例如，一個(gè)函數(shù)有十種輸入，調(diào)試能覆蓋五六種就不錯(cuò)了。而系統(tǒng)測試，并不針對某個(gè)具體的函數(shù)，不關(guān)注某個(gè)函數(shù)的功能邏輯是否正確。

要檢測某個(gè)函數(shù)的功能邏輯，就必須要依照分類列出數(shù)據(jù)，檢測代碼是否對每一個(gè)分類都做了處理，而且每一個(gè)分類的處理是否正確。

——這就是單元測試。

1.2 單元測試的基本方法

由上面的分析可以看出，單元測試的基本方法就是：依數(shù)據(jù)的分類列出輸入，執(zhí)行被測試程序，然后，判斷輸出是否符合預(yù)期。

單元測試能達(dá)到什么樣的效果呢?那就是：無論別人怎么樣，我總是對的!

這里的“別人”，是指關(guān)聯(lián)代碼。“我”，是指當(dāng)前正在編寫或測試的代碼。單元測試要做到的是，無論關(guān)聯(lián)代碼是否有錯(cuò)，都要保證我是對的。具體來說，我要考慮關(guān)聯(lián)代碼會產(chǎn)生什么樣的數(shù)據(jù)，這些數(shù)據(jù)要如何分類處理，只要我的分類和處理是正確的，那么，無論別人怎么樣，我總是對的。

1.3 單元測試的效益

單元測試的效益可以說是立竿見影，并且會推動(dòng)整個(gè)開發(fā)過程的改進(jìn)。

首先，單元測試可以保證代碼的質(zhì)量。因?yàn)橹挥袉卧獪y試，能夠全面檢測代碼單元的功能邏輯，排除代碼中大量的、細(xì)小的錯(cuò)誤。

其次，排錯(cuò)成本最小。如果在編碼階段同時(shí)進(jìn)行單元測試，排錯(cuò)成本可以忽略不計(jì)。但若到了后期，排錯(cuò)成本可能會增長上百倍，要是產(chǎn)品已經(jīng)到了用戶手里，那造成的損失就更難說了。

第三，提升開發(fā)效率。單元測試可以讓程序行為一目了然，也就是程序行為可視化。什么叫程序行為呢?就是什么輸入下，會執(zhí)行哪些代碼，會產(chǎn)生什么輸出。如下圖，黑色的代碼是當(dāng)前輸入下所執(zhí)行代碼。

如果我們寫幾行代碼，就可以看到程序的行為，相當(dāng)于寫文章時(shí)上下文可見，這可以促進(jìn)我們的開發(fā)思維。如果我們的思維有了偏差，也可以及時(shí)發(fā)現(xiàn)。如果代碼中有了錯(cuò)誤，也可以隨時(shí)排除。

那么，是不是整個(gè)項(xiàng)目的所有代碼都做了單元測試，才能得到這些效益呢?不是的。80:20規(guī)則，在軟件開發(fā)過程中也存在。也就是說，80%的代碼錯(cuò)誤，可能存在于20%的代碼中;80%的編碼、調(diào)試成本，可能會消耗在20%的代碼上。這20%，就是算法密集度高的代碼，也就是功能邏輯復(fù)雜的代碼。

這些代碼可能只有20%，但是卻可能包含了80%的錯(cuò)誤，消耗了80%的編碼、調(diào)試時(shí)間，即使只對這部分代碼進(jìn)行單元測試，在提升產(chǎn)品的質(zhì)量和開發(fā)效率方面，也會產(chǎn)生立竿見影的效果。

第四，自動(dòng)回歸。如果沒有單元測試，系統(tǒng)測試發(fā)現(xiàn)了錯(cuò)誤，當(dāng)然要修改代碼，而修改代碼可能引入新的錯(cuò)誤，又要進(jìn)行全面的系統(tǒng)測試，這樣就可能陷入循環(huán)，這通常也是項(xiàng)目延期的主要原因。

如果有了單元測試，修改代碼時(shí)可以通過回歸測試馬上檢測是否引入了新的錯(cuò)誤。所謂回歸，就是回復(fù)到原來正確的狀態(tài)。

正是回歸測試，使單元測試對整個(gè)開發(fā)過程的改進(jìn)都產(chǎn)生積極影響，使項(xiàng)目適應(yīng)頻繁變化的需求。單元測試是敏捷開發(fā)的基礎(chǔ)和核心，反過來說，有了單元測試，開發(fā)過程會自動(dòng)趨于敏捷。單元測試也降低了后期測試的壓力。