自动化不是灵丹妙药(转)

上一篇 / 下一篇  2009-02-16 15:26:31 / 个人分类:Automation Testing

一天和同事聊天,他试图实现一个功能,让一个程序在系统重启后能自动启动,并且加载指定的配置。

  我分析了一下发现实现这个功能会比较复杂,主要是涉及多处配置文件的修改。回头再看看,发现这个系统很少会重启,可能一年就4,5次。于是我建议他放弃这个想法。因为维护配置文件会成为一个负担,考虑到系统重启的频率,这会是得不偿失。

  但是看来他并不以为然。他说他的目标是这些配置工作完全不用人来参与,“最好是在家里动一个手指所有的配置工作都自动化的为我做好了”。看到他信心满怀的样子,我不愿意扫他兴。但我相信如果即使有一天他真正实现了这个目标,维护这个自动化系统也会让他寝食难安。

  这样悲观的看法,我想在两三年前我肯定没有。那个时候我像他一样对“自动化”抱有无限美好的期望,好像只要测试自动化了,软件测试工作马上变得和“公务员一样轻松”,只需要动一下指头,所有的testcase都自动化得跑起来。

  但随着做了更多的自动化测试项目,也看了更多的成功和失败的案例。对自动化的特点了解得来越多,对自动化的期望也在一直不断的下降。

  这种看法的变化,我倒觉得是越来越贴近真实的“自动化测试”。

  如果要充分利用一个工具,一定要了解其特点。现在在业界,自动化软件测试就像一个人见人爱的香馍馍。自动化测试好像已经和“高科技”,“高测试效率”,“成熟的测试team”…这些褒义词联系了起来。在这种一边倒的氛围下,自动化程序的缺点和不足和必须要付出的代价被掩盖了起来。

  认识自动化的不足,我觉得首先要转变的一个想法是“自动化测试并不是用来发现bug的”。原因很简单,自动化测试基于testcase,但所有的bug中只有大约1/4是仅仅按照testcase来测试就能发现的,其它的bug,来自于聪明的“人”的经验,分析,发散思维和说不清道不明的“灵光一闪”,而这些特性对于自动化程序来说完全是无能为力。所以,幻想“动一下手指”,所以的bug都被自动化程序发现出来是完全不可能实现的。

  自动化另外一个特点是自动化本身也是程序,也需要投入大量的人力来实现。一个软件买出的copy越多,它的价值越大。对于自动化测试程序来说,它运行的次数越多,它的价值越大。有下面一些原因都可能减少自动化测试程序运行的次数,甚至导致自动化项目的失败。

  1)测试产品功能或界面变化频繁

  2)自动化的case本身不需要频繁的测试,比如安装过程或者一些非核心的功能

  3)自动化程序不稳定,容易跑“死”掉

  看到了一些自动化测试程序因为这些原因而效果大打折扣,我对“自动化一切”的热度慢慢退烧了。

  最后一个需要注意的自动化测试程序的特点是,自动化测试程序不是商业产品,它的用户都是专业人士,所以它不用商业产品那样高的扩展性,灵活性,可配置性,友好的交互性。因为这些特性的得来是要付出高昂的代价的,那就是人力投入和软件的复杂度大大增加。对于设计师来说,如果要在这些特性和简单中选择的话,一定要选择简单。

  1)对于错误处理要简单直接,而不要灵活和聪明。打印错误并直接退出是最好的选择,不要试图猜测错误的根源并试图从错误恢复。这里包括用户输入,环境错误等。

  2)对于环境设置,要求单纯一些,不要去兼容环境变化。一般来说测试环境都是有测试人员在维护。试图兼容环境可能导致代码大大增加。

  3)对于自动化测试的代码来说,也不要用太炫的设计技巧和复杂的设计模式。因为自动化测试的代码最好能被使用它的测试人员读懂,甚至能做简单的修改和排错,这样能提高自动化测试的次数。

  对自动化期望不能太高和自动化程序不要设计得太完美,是我对自动化测试程序设计和使用过程中获得的最深刻的体会。

本文出自lifr的51Testing软件测试博客:http://www.51testing.com/?764


TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar