51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 4311|回复: 0
打印 上一主题 下一主题

[原创] 单元测试要点

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-9-4 18:09:01 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
单元测试的效益
1)保证代码质量:集成和系统测试无法完成代码单元的输入覆盖,未覆盖的输入可能隐藏大量细小的错误,只有单元测试可以解决这个问题。
2)降低排错成本:排错成本随时间的推移直线上升,把错误消灭在初生之时成本最低。
3)提高开发效率:代码单元在开始编写时,即可不依赖于其他代码单独运行,并展现其行为,可以集中思维,降低编程难度,大幅减少调试,提高生产率。
4)开发周期可控:即使代码按进度完成,未测试代码隐含的大量错误使产品稳定下来的周期远超预期,造成项目延期和成本高企。单元测试把难于计划的后期排错工作转换为可以计划的常规工作,避免把问题遗留并集中爆发。
5)修改自动回归:即使是最小修改也可能引入错误,单元回归测试可以自动检测,避免小量修改可能导致大量的系统级调试与测试。
6)解放核心产能:避免骨干成员陷入反复调试排错维护泥潭,专注于创造性工作。
7)改进绩效考核:用经过测试的合格代码量来衡量开发绩效,而不是质量未知的未测试代码。
总之,单元测试是高效的开发过程质量控制机制,可以帮助企业保证产品质量、降低成本、提高生产率、缩短开发周期、赢得市场先机,提升竞争力。

单元测试的目标
哪些代码占开发成本的大部分?函数,尤其是较复杂的函数,其编写调试排错占了整体开发成本的大部分,面向对象开发亦如此。单元测试所要解决的就是这些代码的质量和开发效率。单元测试的首要目标是:
1)对较复杂函数实现输入覆盖,保证其质量。
2)提高较复杂函数的开发效率,大幅减少调试,尤其是效率很低的嵌入式调试。

单元测试的基本方法
将输入分类(等价类),设定对应的正确输出,执行测试,由工具自动判断实际输出是否相符,这是单元测试的基本方法。
工具不可能自动了解程序的设计功能,因此,要达到起码的测试效果,用例必须由能够了解代码功能者人工设计,
自动生成用例是一个简单的技术,但只能作为一个补充。工具的价值在于完成太费人工和人工难于做到的工作,例如:解决可测性问题、生成驱动、桩、底层模拟、统计覆盖率、协助找出遗漏用例、自动判断测试结果、描述程序行为、生成测试报告等。

单元测试的难题
可测性差:高耦合造成的可测性差是单元测试第一难题。不幸的是,程序是客观事物的反映,客观事物本来就互相关联、互相纠缠,代码之间的大量耦合无法避免。
失真:作为基本测试技术,自动打桩通常是不得已的选择,必然造成失真,使测试难于进行。
不可控:底层代码包括平台代码的有些行为在测试环境下无法控制。
工作量大:编写测试代码耗费大量劳力。
打扰:编程需要专注,程序员最恨被干扰。
覆盖率低:衡量测试效果的基本指标是覆盖率,覆盖率具有逾后逾难的特点,要想实现完整的覆盖,仅仅统计覆盖率是不够的。
没时间:项目很紧张,工程师很忙。

单元测试的工具要求
工具应能解决前述难题,单元测试才是可行和高效益的。
解决可测性差:自动处理复杂的文件关系,自动打桩解耦合,自动解决可测性问题。
解决失真与不可控:无需编程即可完整模拟底层函数的行为。
解决工作量大:自动生成驱动代码和其他支持代码,自动解决平台兼容问题。
解决打扰:除根据功能设定用例外,其他工作自动完成。功能的细化就是用例,因此这是一种设计行为,可以促进编程,不会造成打扰。
解决覆盖率低:具有基于现有用例找出遗漏用例的功能,才能实现高覆盖。
解决没时间:支持可视编程,开发过程中,代码单元随时运行,程序行为可视(程序行为是指什么输入执行哪些代码产生什么输出),使单元测试不再是一种负担,而是促进开发、提升生产率、降低劳动强度的工具。

单元测试失败的原因
目标过于宽泛:单元测试是独立的测试,把集成后才易于发现的问题牵扯到单元测试中来,是得不偿失的,且极易导致失去主要目标,最后不了了之。
工具不能适应:例如可测性差是上规模项目的必然属性,希望通过改进流程提高可测性,牵涉太广,难度太大,这种问题应该由工具自动解决。
时机选择错误:单元测试应用程序员在编码同时完成,而不是等编码完后由不熟悉代码的测试人员完成。即使在编码后测试,也应该谁写的代码谁测试。测试部门可以做补充和审查,以解决开发思维和测试思维重叠引起的用例不完整问题。

单元测试实施要点
不要等待:无论项目处于什么阶段,单元测试都可以切入,但越早越好,不要等待。
选择工具:理论上,单元测试可以不用工具或自行开发简单工具,但让昂贵的程序员编写大量毫无创造性的测试代码,解决各种测试难题,就像让教授看大门一样,是极大浪费,也会引起抵 制。不要指望用工具来代替人的智慧,但要让工具来发挥人的智慧。要用实际的项目来评估工具,简单的示例与实际应用是两码事,操场上选不出千里马。
高层重视:没有高层的重视和推动,单元测试将阻力重重。
目标明确:首先把较复杂的函数级代码测试好,这些都做不到,奢谈其他毫无意义。
循序渐进:首先在小范围施行,取得成功经验后再全面推广。
寻求支持:服务好的工具厂商可以提供全面支持,包括培训、现场支持,甚至具体到某种情形下如何设计用例都会解答。

[ 本帖最后由 VisualUnit 于 2009-9-4 18:22 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-5-4 09:28 , Processed in 0.067187 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表