Posted on 2009-01-29 18:10
S.l.e!ep.¢% 阅读(2297)
评论(4) 编辑 收藏 引用 所属分类:
test
原文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 结束语
目前 , 软件测试逐 步进 入程序 开发 的工程
中, 单元测试工具也开始使用, 但要把这些工具
充分利用 , 编程时必须有所考虑。要编写可测试
性强的代码, 避免 出现不 可测试的代码 , 同时这
也不完全是为了照顾工具 , 本身可测试性强的代
码就是可靠性好的代码 、 问题少的代码 、 维护代
价小的代码。而不可测试的代码, 几乎就是出问
题的代名词。