S.l.e!ep.￠%

原文PDF： http://m.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 )?
摘 要 ： 軟件測試中大量使用了單元測試工具軟件． 但是這些單元測試工具基本上沒有考慮在微軟基本類庫
編程情 況下 的應(yīng) 用問題 ． 使得其應(yīng)用 中有許多 問題 出現(xiàn) 。指 出軟件單元測試工具 在微軟基本 類庫編程 中 出
現(xiàn) 的使 用問題 ， 并提 出解決這些 問題 的基本思路 。?
關(guān)鍵詞 ： 單元測試工具； 微軟基礎(chǔ)類庫； 編程
中圖分類號： 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?? 引?? 言
伴隨著計算機制造業(yè)水平 的突飛猛進， 計算
機軟件的應(yīng)用范圍不斷擴大 ， 軍用電子設(shè)備中軟
件的份量越來越重 。現(xiàn)在在一個電子設(shè)備 中想
不使用軟件已經(jīng)變得幾乎不可能， 軟件帶來的靈
活性和設(shè)備量的減少是開發(fā)者無法拒絕 的， 而像
操作情報臺這樣 的終端設(shè)備已經(jīng)成為軟件 的代
名詞 ， 離開軟件設(shè)計者 已經(jīng)無從下手。軟件與硬
件一樣 ， 質(zhì)量 問題也是形影不離的， 并且具有更
大的不確定性和破壞性 。軟件測試是發(fā)現(xiàn)軟件
質(zhì)量問題 的基本方法之一 ， 軟件測試因此得到了
普遍的重視 。?
1?? 軟件單元測試
軟件單元測試是軟件測試最基本的測試 階
收稿 日期 ：2 0 0 3一l O—O 5?
段 ， 軟件單元又是軟件開發(fā)過程 中最小的可進行
測試的代碼。軟件單元測試要完成的工作主要
包括功能測試 和結(jié)構(gòu)測試 。功能測試要進行數(shù)
據(jù)的符合性檢查 、 邊界數(shù)據(jù)檢查 ， 結(jié)構(gòu)測試主要
進行覆蓋率測試， 如果有代碼在投入使用前從來
沒有運行過， 那是誰也不放心的。不管是什么級
別的軟件 ， 單元測試都是必須進行的， 級別越高，?
結(jié)構(gòu)覆蓋測試的要求越高， 測試的工作量越大。?
2?? 軟件單元測試工具
由于 目前軟件代碼的數(shù)量越來越多， 一個軟
件程序 中的軟件單元也越來越多 ， 完全利用手工
進行軟件單元測試需要增加更多的軟件測試員
和測試時間。同時， 現(xiàn)代編程技術(shù)的發(fā)展也使軟
件單元測試 自動化工具的實現(xiàn)成為可能， 這些 自?
動化 工具就是軟件單元測試工具 。目前 國內(nèi)的

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

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