自动化不是灵丹妙药

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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