要知道，测试自动化所花费的时间是测试本身的3到10倍，如果再加上测试自动化本身的实现带来的bug，自动化花费的时间是测试本身的5到10倍。而我们现实的情况是，我们本来就没有足够的时间完成测试。所以现在如果把大量的精力和时间用在测试自动化上，那就会大量挤压本身应该完成的测试。而测试自动化能够找到的问题远远少于测试本身。想想这个投入和产出，就知道寄希望于重复来发现问题，是多么的愚蠢了。

　　所以必须清楚地界定回归测试的范畴，那就是，基本功能测试，基本的！

　　还有什么case渴望自动化呢？

　　- 必须执行多次的测试。比如，要开关1000次的测试，不可能要一个人对着开关真的摁上1000次，那太残忍了。

　　- 要24小时运行的测试。比如，稳定性测试，需要连续24小时甚至72小时运行某些行为。要人来操作也不大现实。

　　- 还有呢，就是只有机器能完成的测试，比如1秒内开关20次，人的反应不够快。

　　下面说说哪些测试是不适合自动化的。

　　和其他自动化一样，我们需要分清楚人和机器的区别。有些事情是机器擅长的，人不擅长的，可以考虑自动化。而有些事情是人擅长的，机器不擅长的，则不考虑自动化。

　　就软件测试而言，大部分的工作都是需要人的全力参与的。因为软件测试不仅仅是执行测试，而理解需求、设计测试、总结测试结果、软件质量评估，占了更多的测试时间，这些我们当然是不可能实现自动化的，因为这需要大量的智慧，且无法重复。

　　那么就仅仅针对执行测试来说吧。机器是没有感觉的，也不会总结经验。只有人亲自参与测试，执行case，才能体会到当用户来使用这个软件产品的时候，会是什么感觉。他们也将体会到这个软件最大的问题在哪里，系统的软肋在哪里，需要如何改进测试计划，以便能发现更多的问题。

　　就拿我最熟悉的动态路由来说吧。这些软件代码都已经很成熟了，执行买来的路由协议测试套件，一个bug也找不出来。因为这些协议已经很成熟了，移植过来的代码也被广泛地使用过，其稳定性和可靠性无需我们一测再测。可是我们依然发现了很多其他的问题。

　　为什么呢？因为移植本身会带来问题，与操作系统和协议栈的接口变了，配置方式也变了，配置文件改了，和其他相关模块的接口也不一样了，甚至还增加了新的接口。测试人员本来并不知道这些问题，是在测试过程中，逐渐发现并了解的。所以就增加了配置，路由模块与协议栈，路由模块与其他模块交互方面的测试case，而对协议本身的测试就不再需要了。这些问题和改进，都是测试人员手工测试的结果。是需要靠人的智慧来感受和总结的。

　　所以，新的功能测试必须由人来执行测试，并且在执行过程中逐步修改测试计划，同时给出对软件的质量评估。我认识几个非常资深的测试人员，他们总是能发现比别人更多的bug，他们有很好的测试习惯。这些好的测试习惯使得他们对软件出现的问题更加敏锐。

　　我曾经参加过一个很精彩的测试技巧和自动化培训，那个培训老师有一句话给我留下了深刻的印象，就是“要尽量不用自动化测试”。我想，在这个动辄谈“自动化”的年代，这句话是在告诉我们，只有清楚地知道自动化测试的作用和局限性，聪明地使用自动化测试，而不是为自动化所累，才是智慧的行为。