51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: sincky
打印 上一主题 下一主题

全面介绍单元测试 -转贴

[复制链接]

该用户从未签到

21#
发表于 2006-12-25 17:08:51 | 只看该作者
感觉没有实质性的东西啊,实用的有吗?
回复 支持 反对

使用道具 举报

该用户从未签到

22#
发表于 2006-12-28 16:48:18 | 只看该作者
好贴
回复 支持 反对

使用道具 举报

该用户从未签到

23#
发表于 2007-4-7 13:34:20 | 只看该作者
还没看完,都觉得受益非浅,非常感谢,
回复 支持 反对

使用道具 举报

该用户从未签到

24#
发表于 2007-4-19 12:06:15 | 只看该作者
能不能推荐些java的单元测试工具
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2007-4-21 16:20:42 | 只看该作者
收藏收藏收藏收藏收藏
回复 支持 反对

使用道具 举报

该用户从未签到

26#
发表于 2007-4-27 17:41:38 | 只看该作者

楼主太厉害了

楼主对测试有深刻的认识看来,谢谢sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2007-5-14 10:32:13 | 只看该作者
很详细,顶下,
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2007-5-15 08:03:59 | 只看该作者

好贴哦!

你能再帮我找些有关C或C++的测试用例吗?谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2007-5-15 16:41:57 | 只看该作者
sdlkfj3   好帖子  顶顶
回复 支持 反对

使用道具 举报

该用户从未签到

30#
发表于 2007-5-21 08:53:53 | 只看该作者

学习了

谢谢。GOOD
回复 支持 反对

使用道具 举报

该用户从未签到

31#
发表于 2007-5-24 16:42:31 | 只看该作者
我什么时候能这样呢!
回复 支持 反对

使用道具 举报

该用户从未签到

32#
发表于 2007-7-2 12:11:13 | 只看该作者
不用下载,很好,保存了以后看。多谢
回复 支持 反对

使用道具 举报

该用户从未签到

33#
发表于 2007-7-3 14:51:49 | 只看该作者

回复 #1 sincky 的帖子

很长,但是看完了,好文章。
回复 支持 反对

使用道具 举报

该用户从未签到

34#
发表于 2007-7-3 18:10:51 | 只看该作者
很好,刚好用上
回复 支持 反对

使用道具 举报

该用户从未签到

35#
发表于 2007-7-19 20:05:02 | 只看该作者
看了,觉得还是有点点收获的~
回复 支持 反对

使用道具 举报

该用户从未签到

36#
发表于 2007-7-21 21:17:10 | 只看该作者
学习
回复 支持 反对

使用道具 举报

该用户从未签到

37#
发表于 2007-7-24 14:57:24 | 只看该作者
写得非常不错,只是学生想对老是提出两个小问题:
1由谁测试?单元测试与其他测试不同,单元测试可看作是编码工作的一部分,应该由程序员完成,也就是说,经过了单元测试的代码才是已完成的代码,提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。

UT到底该由程序员完成还是测试员完成,这只能说是互有利弊。如果是程序员,那很有可能会按照自己的习惯思维去测试,而很难全面的找出BUG;如果是测试员,虽能够比之程序员找出更多的BUG,但没有程序员的参与,往往无法高效的完成工作。所以我的建议是,应该由双方同事参与完成。


2关于桩代码,老纳认为,单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码,

在实际过程中,你往往需要编写驱动函数和桩函数,这是无法避免的,我们应该结合实际情况而决定对中间层的定位。

sdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

38#
发表于 2007-7-24 18:02:39 | 只看该作者
to liulinzhu (猪哥) :
您说得太对了。我是这篇文章的作者,这文章写于差不多两年前,当时对解决可测性难题没有好的办法,并且由于在实际工作中,感觉编写桩代码太费时了,如果由工具生成空桩,又可能导致程序的行为完全不同而使测试没有意义,所以主张由程序员实施单元测试,由底向上开发,避免编写桩代码。这些主张在不是很大的项目中,还是可行的,因为我所写的,都是经过自己实践的。但对于大型团队大型项目来说,则不现实,这一年多,我接触了一些大公司的大项目,很多认识已经完全不同了。希望有机会好好聊聊。
回复 支持 反对

使用道具 举报

该用户从未签到

39#
发表于 2007-7-25 08:44:55 | 只看该作者

回复 #38 VisualUnit 的帖子

太看得起我啦,在测试行业你都老一辈的人了,我只是个新手而已,应该向你多多请教,多多学习啊!
回复 支持 反对

使用道具 举报

该用户从未签到

40#
发表于 2007-7-30 23:27:11 | 只看该作者
我在单元测试上也是个新手,前些日子对一些项目进行单元测试的尝试,个人认为单元测试还是可行的。但是单元测试不可过分依赖于工具,最重要的还是靠自己的双手!
我所进行的单元测试项目是C#开发的,由于项目架构得还不错,当然也是一个小型的专业应用软件了,整个项目里面产生了3个DLL,以及一些自定义的插件,当然还有一些继承于FORM的窗体代码了。经过测试,我认为单元测试并不需要对每一个.cs文件都去测,至少可以这样来区分:DLL文件是要测的,里面几乎都是精华,控件也是需要测试的,这样可以减轻功能测试(其实我更乐意把它叫做“集成测试”)的负担,也利于及早发现功能性问题。而继承于FORM的代码我建议不要拿来做单元测试,放到功能测试中去做更为适合。
说实在的,基于一些原因,我并不能持久地开展测试工作,看法有误的地方还请各位看客读者手下留鸡蛋。。
其实测试人员做单元测试并不是十分的难,至少起步并不十分的难,但是要深入进去那就。。。至少懂得编码是必不可少的。
最后,还有一点儿要说给初入行的兄弟姐妹,搞测试的不要只埋着攻功能测试,而忽略了编码能力的提升,因为我们做测试的,不要过多指望在你测试之前所有的文档、资料、程序都是一切就绪的,项目往往很赶时间,所以过地苛求别人提供文档、资料的,并不那么现实,自己能读懂代码,摸清功能我认为是更好不过的了。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-13 04:21 , Processed in 0.072973 second(s), 20 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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