本文不想讨论自动化测试的利弊;Web测试和性能测试也不是本文的讨论范畴,本文只讨论单元测试以及集成测试阶段的问题;只谈了JUnit的一些缺陷以及我们是否有更好的选择,以及开发者的测试是否能让测试人员也能玩得动呢。如果你没兴趣,不防就此别过,以免你后悔。
言归正传,说到用JUnit进行单元测试,对于Java开发人员来说再熟悉不过了,即使
没有用过,也一定听过吧。
在项目的过程中,如果你是开发人员,你也许有这样的想法:偶们知道用JUnit来写单元测试的好处,可偶们没时间写;功能够用了,可还是繁琐;一开始还用的,可后来忙于改代码,接口改动又大,也就没时间坚持用下去了。
如果你是测试人员,你或许会这样想:偶觉得开发人员写的单元测试可能过于粗略,很可能有些边界没检查到,但我对Java不太熟悉,无法通过修改他们的测试代码来进行更完善的测试,只能”通过现象猜本质“了--在功能测试阶段,多点几下鼠标也就可能出错了。
哦,也许我猜错了,我怎么能懂得测试人员的心思呢,实际上我都不是一个称职的测试人员。
我们来看看JUnit都有哪些令人不爽的地方:
1、繁琐,维护的成本不低。XP提倡为每个方法都加一个测试方法,不少XP的追随者也是真能做到的。但当项目的代码行达到50万以上时,为每个方法增加一个测试方法,令人不爽的是:需要几乎跟源码一样多的测试代码,甚至更多。唉,老大,不是我不想做,我是做不完啊。
2、测试代码的质量不好检查。如果你是一个敬业的人,相信不会有这样的问题,但是人都有惰性,尤其是日复一日地重复写代码的你,当面临加班写测试代码和回家看球赛的选择时,我想还是选看球赛的人大有人在--反正简单得很,不会出错的。关键的是:头儿不会知道的。
3、在单元测试阶段的效果比较明显,在其它测试阶段几乎就难于胜任了。也难怪,望文生意:JUnit本来就是Java Unit测试嘛,你XXX要求还真高。
关键不是我要求高,是我们这些coding的”共同敌人“要求高啊,所以,问题不能不解决。于是,就有一些”先驱们“做了一些尝试:
一、Software Agitator
什么是Software Agitator?当年JUnit的缔造者Kent Beck的又一力作,它是一个自动的运行软件代码并提供软件代码行为观察报告的一种方法,它帮助开发人员单元测试他们的代码,而不用手动编写测试代码,使用该方法,开发人员将创造出更好、更容易维护和健康的软件,产生很少的bug,具有更高的生产效率,因为他们花了很少的时间去分析失败和改写他们的代码。
Software Agitator的主要特性有:
1、自动生成测试数据、自动创建智能的Mock 对象,提供尽可能多的代码覆盖。
2、全面的报告:代码覆盖率、报告方法、输出、语句行和条件覆盖率。
3、超过200个Factory库,也可以通过简单的Java API 延伸factory控制输入数据和
转化数据格式。
4、支持TDD(测试驱动开发)
5、支持JUnit等。
6、支持Regression测试(也就老外这么多名词,说白了就是测试用例在不同的项目中
重复利用)。
7、存储信息在XML文件里(包括用例、报告),不需要数据库。
8、自动检测代码标准违规。
9、完全集成Eclipse开发环境。
显然,Agitator的功能非常强大,阵对性强,个人觉得起码有如下好处:
1、基于XML来描述用例信息比robot和Quest Test都易于使用,这使测试人员都能参与其中。题外话:我一直想不通robot和Quest Test为何要自己发明一套自己的脚本?除了自我封闭、排除异己之外,实在没有其它有说服力的道理可言。
2、它能大大减轻了开发人员的重复劳动,这是开发人员不能坚持用JUnit进行测试的罪魁啊,基本上弥补了JUnit的缺陷,真不愧为JUnit的始俑者。一句话:懒人只需要一个理由。
3、测试报告全面,而且是xml形式的。通过测试报告也能比较可靠地检查质量。
Agitator的缺陷也明显:
1、不适合于Web测试和GUI测试。
2、它不是免费的,这是最大的缺点了吧,如果能象JUnit那样免费。。。。。。我想得也太 美了:(
可惜拿不到Agitator的试用版,不然,能做些例子,但能给我们不少启发:
1、测试框架需要进一步减轻开发人员的工作量
2、测试用例的开放性(XML格式)。别只顾自己玩代码,让开发经验欠缺的测试人员也玩玩 如何?自动化测试有必要学习其他脚本语言吗?除了商业利益的因素外,没有任何令人信服的理由。
3、测试的智能化:全面的报告,支持Regression测试,自动定时执行等等。
是啊,真的是个好东东啊。难道就没有其它免费的吗?我还真没发现,如果你知道,请告诉我,谢谢。
不过,如果你能读到这,为了报答你的拜读之情,就介绍一款免费的测试框架,以致不会令你太失望。
文章来源于领测软件测试网 https://www.ltesting.net/