自动化测试的思考和总结之功利篇

上周参加公司的自动化测试研讨会，今年的主题是ROI（投资回报），个人感觉这是一个很严肃的话题，也是领导最关心的一个问题。不过谈测试自动化的投资回 报似乎并不是一件容易的事情。测试自动化本身是一个需要持续投入的系统工程。他并不像开发过程一样那么容易衡量产出和回报。另外，对于测试自动化的投资回 报似乎不应该在一开始提到一个很高的高度。否则对自动化的开展非常不利。

另外，测试自动化并不是简单的把手工的测试转化成自动化的代码或 者脚本这么简单的过程，而是要贯穿在产品的生命周期中，进行不断地执行，只有不断地执行，才能得到收益，根据经验，回归测试的自动化测试用例在不考虑被测 对象改变带来自动化测试脚本维护的前提下，反复执行4-7轮才能收回成本。如果被测对象本身不是十分稳定，或者缺陷比较多，产品不成熟，这个时候介入测试 自动化是非常得不偿失的。

测试自动化在很大程度也依赖于被测对象或者被测设备的稳定性，系统的设计应该考虑到可测试性，Design for Test。测试自动化越早加入到产品的开发周期，成功的机会越大。
关 于测试自动化的效果衡量不是简单的发现了多少缺陷，其实自动化测试并不能比手工测试发现更多的缺陷，如果要发现更多的缺陷，一定要进行必要的手工测试。自 动化测试的效果或者投资回报可以通过其他一些方法进行衡量，比如节省的测试人力成本，可以通过统计手工测试的时间，自动化测试的开发时间，自动化测试的执 行之间，执行次数，刨去维护时间，进行计算得到。另外，还可以从回归测试能加快产品的发布时间上进行衡量。

最后，关于产品的自动化程度， 究竟多少比例的产品需要被自动化，这个取决于产品本身，以及这个产品本身可以被自动化的程度有关系，还要考虑自动化所需要花费的代价。一般来说，不是所有 的测试用例都需要自动化，也不是所有的测试用例都能够自动化。据个简单的例子，有一个测试用例，需要重新启动机房里面一台服务器，常规来说，是不能也不需 要自动化。但是有没有可能自动化呢？肯定有，不过肯定不会为了这个自动化这个测试用例而去花费巨大的代价开发一个机器人帮你完成这个任务。当然这是一个极 端的例子。目的是告诉大家，不是所有的测试用例都需要自动化，也不是所有的用力都能自动化。衡量的依据是不同产品和代价得多少。