原文PDF： http://www.shnenglu.com/Files/sleepwom/單元測試工具在MFC編程中的使用問題.rar

2 0 0 4年 1 0月
第 2 7卷第 5期
艦 船 電 子 對 抗
SHI PBOARD? ELECTRON1 C? C0UNTERM EASURE
OC t ． 2 0 0 4?
V0 1 ． 2 7?? No ．5?
單元測試工具在 MF C編程 中的使用問題
傅? 毅
( 船舶重工集 團公司 7 2 3所 ， 揚州 2 2 5 0 0 1 )?
摘 要 ： 軟件測試中大量使用了單元測試工具軟件． 但是這些單元測試工具基本上沒有考慮在微軟基本類庫
編程情 況下 的應 用問題 ． 使得其應用 中有許多 問題 出現 。指 出軟件單元測試工具 在微軟基本 類庫編程 中 出
現 的使 用問題 ， 并提 出解決這些 問題 的基本思路 。?
關鍵詞 ： 單元測試工具； 微軟基礎類庫； 編程
中圖分類號： TP 3 1 1 ． 5 6?? 文獻標識碼 ： B?? 文章編號： C N 3 2 — 1 4 1 3 ( 2 0 0 4 ) 0 5 — 0 0 4 6 — 0 3?

Pr o bl e ms?? o f?? Un i t?? Te s t?? To o l s?? Op e r a t i ng?? i n?? M FC? Ed i t i ng?? Ro ut i n e?
FU? Yi?
( The?? 7 23?? I ns t i t u t e?? of?? CS I C， Ya ng z h ou?? 2 2 50 01， Chi na )?
Abs t r a c t ： I n?? s of t wa r e?? t e s t s ， uni t?? t e s t?? t o ol s?? a r e?? wi de l y?? u s e d， b ut?? t he?? a pp l i c a t i o n?? o n?? e di t i ng?? r ou -?
t i ne?? wi t h?? Mi c r o s of t?? f ou nd a t i o n?? c l a s s?? i s?? n o t?? c o ns i de r e d?? a?? l o t?? i n?? t he?? de v e l o pme n t?? of?? t he s e?? uni t?
t e s t?? t oo l s， s o me? p r o bl e ms?? ma y?? oc c u r?? d ur i n g?? t e s t s?? wi t h?? t h e?? t o ol s ．Th i s?? a r t i c l e?? pr e s e n t s?? t h e?
p r ob l e ms?? a pp e a r e d?? i n? t h e?? t e s t?? o n?? M FC e d i t i ng?? r ou t i ne?? a nd? b r i ng s?? f o r wa r d? a?? ba s i c? wa y?? t o?
s o l ve?? t h e?? p r ob l e ms ．?
Ke y wo r d：un i t?? t e s t?? t o ol ； Mi c r os of t?? f o und a t i o n?? c l a s s； e di t i ng?? r o u t i ne?

0?? 引?? 言
伴隨著計算機制造業水平 的突飛猛進， 計算
機軟件的應用范圍不斷擴大 ， 軍用電子設備中軟
件的份量越來越重 。現在在一個電子設備 中想
不使用軟件已經變得幾乎不可能， 軟件帶來的靈
活性和設備量的減少是開發者無法拒絕 的， 而像
操作情報臺這樣 的終端設備已經成為軟件 的代
名詞 ， 離開軟件設計者 已經無從下手。軟件與硬
件一樣 ， 質量 問題也是形影不離的， 并且具有更
大的不確定性和破壞性 。軟件測試是發現軟件
質量問題 的基本方法之一 ， 軟件測試因此得到了
普遍的重視 。?
1?? 軟件單元測試
軟件單元測試是軟件測試最基本的測試 階
收稿 日期 ：2 0 0 3一l O—O 5?
段 ， 軟件單元又是軟件開發過程 中最小的可進行
測試的代碼。軟件單元測試要完成的工作主要
包括功能測試 和結構測試 。功能測試要進行數
據的符合性檢查 、 邊界數據檢查 ， 結構測試主要
進行覆蓋率測試， 如果有代碼在投入使用前從來
沒有運行過， 那是誰也不放心的。不管是什么級
別的軟件 ， 單元測試都是必須進行的， 級別越高，?
結構覆蓋測試的要求越高， 測試的工作量越大。?
2?? 軟件單元測試工具
由于 目前軟件代碼的數量越來越多， 一個軟
件程序 中的軟件單元也越來越多 ， 完全利用手工
進行軟件單元測試需要增加更多的軟件測試員
和測試時間。同時， 現代編程技術的發展也使軟
件單元測試 自動化工具的實現成為可能， 這些 自?
動化 工具就是軟件單元測試工具 。目前 國內的

第 5期? 傅毅 ： 單元測試工具在 MF C編程 中的使用問題? 4 7?
c／ c++語言體系的單元測試工具有 Ca n t a t a +
+ 、Ve c t o r c a s t 、C + + Te s t 、Tbr u n、Ra t l on a l?
Te s t?? Re a l?? Ti me等 。?
這些工具的基本工作原理為 ： 針對被測試的
單元代碼 ， 生成一個測試外殼 ， 這個測試外殼加
上被測試單元構成一個可以獨立運行的程序 ， 測
試外殼包含有驅動代碼 、 樁代碼、 測試數據、 數據
驗證代碼、 運行軌跡記錄代碼。外殼中的這些代
碼相當于都是測試工具替測試人員完成的工作。?
測試數據一般是開放的， 其他部分就跟不 同
的具體工具有關 ， 有的開放程度大一些 ， 有 的基
本不開放。選擇開放程度大的工具靈活性較強，?
適用范 圍大 一些 ， 但對測試人員的要求要高一
些 ； 開放程度低的類 似于傻瓜型， 使用 中局 限較
大。如果要選購單元測試工具 ， 應該選擇開放程
度大的單元測試工具 ， 畢竟適用范圍和靈活性是
第一位的， 并且軟件測試工具均是 國外 的產品，?
價格十分昂貴。這些工具的介紹資料均會把 自?
己的優點充分發揮， 但對工具的使用局限和短處
根本不提。?
如果使用這些工具 ， 就會發現工具之間的功
能和性能是有懸殊差距的 ， 而這些差距利用演示
例子是很難察覺的， 但是如果把工程代碼作為例
子 ， 就會發現其中的差異。畢竟工程代碼是相當?
復雜的， 用來判斷測試工具 的實際能力是最好的
檢驗手段。?
3?? MFC編程
微軟基礎類庫( MF C： Mi c r o s o f t?? F o u n d a t i o n?
Cl a s s ) 是微軟為 Wi n d o ws程序員提供的一個面
向對象 的 Wi n d o ws編程 接 口， 它 大 大簡化 了?
Wi n d o ws 編程工作。使用 MF C類庫的好處是 ：?
首先， MF C提供 了一個標準化的結構 ， 這樣開發
人員不必從 頭設計創建 和管理 一個標 準 wi n —?
d o ws 應用程序所需的程序 ， 而是“ 站在巨人肩膀
上” ， 從一個 比較高的起點編程 ， 故節省了大量的
時間； 其次 ， 它提供了大量的代碼 ， 指導用戶編程
時實現某些技術和功能。?
MF C庫充分利用 了 Mi c r o s o f t 開發人員多
年開發 Wi n d o ws程序 的經驗 ， 并可以將這些經
驗融入到你 自己開發的應用程序 中去。對用戶
來說 ， 用 MFC開 發 的最 終應 用程 序具 有標 準
的、 熟悉的 Wi n d o ws界面， 這樣的應用程序易學
易用 ； 另外 ， 新的應用程序還能立 即支持所有標
準 Wi n d o ws特性 ， 而且是用普通的、 明確定義的
形式 。事實上 ， 也就是在 Wi n d o ws應用程序界
面基礎上定義了一種新的標準——MF C標準。?
4?? 單元測試工具與 MF C編程框架
的沖突
編程確實方便又省事 ， 可是單元測試工具卻
慢了一拍 。目前的單元測試工具基本上都沒有
考慮 MFC編程下的單元測試問題 ， 也就是說單
元測試工具在 MF C編程環境下有可能英雄無
用武之地 。問題出在單元測試工具 自動生成的
測試外殼上 ， 這個測試外殼 的程序結構類似于控
制臺程序 ， ma i n( ) 函數是程序入 口， 而 MFC是
基于消息機制的面向對象的編程結構 ， 這兩個結
構是完全不同的。?
要想在這種情況下使用單元測試工具， 在用
MF C編程時要注意遵循一些原則， 否則有可能
使單元測試無法進行 ， 或者說無法利用工具來 自?
動進行， 造成有工具用不上， 這是非常被動的， 應
該盡量避免。?
5?? 編寫代碼時考慮可測試性
編程時與圖形界面有許多交互過程 ， 如提取
更新數據等。對數據進行邏輯運算 ， 在編程時要
把與圖形界面的交互過程與邏輯運算過程清楚
地分開 ， 同時在邏輯運算部分不要使用 MF C類
的類型數據 ， 只使用標準 C的語法 ， 因為單元測
試工具碰 到 MF C類 型也 沒辦法 順利 處理 ， 這
樣 ， 單元測試工具就可以較好地發揮作用。?
一
般來說 ， 邏輯運算部分是軟件 的重點 ， 容
易出錯并且必須在測試時重點關注， 是軟件單元
測試的工作量所在 。這部分的代碼一般 比較復
雜 ， 白盒測試 、 黑盒測試都要做得很徹底才行 ， 而
圖形界面交互等的代碼一般十分簡單明了， 基本
都是現成的代碼 ， 從流程圖上看基本就是一條直
線到底 的結構 ， 可測可不測 ， 手工測試都不會有

4 8?? 艦 船 電 子 對 抗? 第 2 7卷
什么難度 。?
這里說 的是 圖形界面交互 的情況， MF C編
程中還有其他類似的情況 ， 都應該如此處理 。這
樣單元測試就可 以順利進行， 否則單元測試會變
得極其復雜 ， 甚至無法測試。?
6?? 舉例說明?
這是一個采用 MF C對話框結構編程的程
序， 程序從 3個編輯框 中提取數據， 把最大的數
據輸 出顯示在第 4個編輯框 中。這是一個非常
簡單 的、 程序員 只寫 了幾行代碼的 Wi n d o ws程
序。既使是如此簡單的程序 ， 編程時要是沒有按
照上面說 的方法去做 ， 單元測試已經無法用單元
測試工具 自動進行了。?
先看無法測試的寫法 ：?
i nt?? CEx a mpl e Dl g： ： myu ni t ( )?
{?
i nt?? a， b， c， d， e；?
Up d at e Da t a ( TRUE)；?
a = 1 " 1 3 ． 一
i 1；?
b—m_
i 2；?
c— m _
i 3：?
d? 一 ( a > b) ? a： b；?
e 一 ( d > c ) ? d： e ；?
ret Urn e：?
}?
這個 函數中既有交互取數的過程 ， 又有邏輯
運算 的過 程， 混在 一起 。在這 個 函數 中，Up —?
d a t e Da t a ( TRUE) 這句從 編輯框 中取 數的語 句
是 MF C所特有 的， 就這么一個語句已經把我所
知道的單元測試工具全部打倒在地。要想利用
工具來進行黑盒測試就必須修改代碼 。?
修改后的代碼 ：?
i nt?? CEx a mpl e Dl g：： my un i t ( )?
{?
Up d a t e Da t a( TRUE)；?
r e t ur n?? my e a s y( m_i l， m_i 2， m_i 3) ；?
}?
i n t?? CEx a mpl e Dl g： ： my e a s y( i n t?? a，i nt?? b，i nt?? c )?
{?
i n t?? d， e；?
d一 ( a > b) ? a： b；?
e 一 ( d > c ) ? d： c ；?
ret urn e；?
}?
修改后 的代碼增加了一個函數 ， 把從編輯框
中取數和邏輯運算分開。my u n i t ( ) 負責取數 ， 非
常簡單 ， 通過人工代碼走查就 可以達到測試 目
的。my e a s y()進行邏輯 運算， 采用 標準 的 C?
語言， 沒有 MF C語句 ， 單元測試工具 可以盡情
發揮 ， 測試變得十分 明確， 測試工具的局限也被
避開了。在用 MF C編程時 ， 類似情形 很多， 都
應該采用這種方法進行處理 ， 使單元測試變得單
純 ， 否則， 最基本的單元測試也變得非常困難 。?
7?? 結束語
目前 ， 軟件測試逐 步進 入程序 開發 的工程
中， 單元測試工具也開始使用， 但要把這些工具
充分利用 ， 編程時必須有所考慮。要編寫可測試
性強的代碼， 避免 出現不 可測試的代碼 ， 同時這
也不完全是為了照顧工具 ， 本身可測試性強的代
碼就是可靠性好的代碼 、 問題少的代碼 、 維護代
價小的代碼。而不可測試的代碼， 幾乎就是出問
題的代名詞。?