单元测试工具在 MF C编程 中的使用问题 [转] （花了钱在网上下载的一篇文章，郁闷）

原文PDF： http://www.cppblog.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   结束语
目前 ， 软件测试逐 步进 入程序 开发 的工程
中， 单元测试工具也开始使用， 但要把这些工具
充分利用 ， 编程时必须有所考虑。要编写可测试
性强的代码， 避免 出现不 可测试的代码 ， 同时这
也不完全是为了照顾工具 ， 本身可测试性强的代
码就是可靠性好的代码 、 问题少的代码 、 维护代
价小的代码。而不可测试的代码， 几乎就是出问
题的代名词。