测试中的自动化与自动化测试

翻开任何一个关于测试的著作，常常有很大篇幅的自动化测试工具和理论，写一篇自己关于测试和自动化的理解，欢迎砸砖。。。渴求砸砖，您的反馈是我下一篇最强大的动力

在我看来，自动化和测试其实是两个并不相关的东西，其中的重合部分构成自动化测试。而我很反对将测试＝自动化测试，同样反对自动化＝自动化测试。。。

自动化在工作中的核心思想在我看来，套用IBM的话，是on　change
而测试工具在工作中的核心核心思想是CUT COST

自动化应该无处不在，举些工作中自动化的例子
。　每天需要打开若干个固定的网页，一个方法是用bookmark+homepage,也可以用BAT启动FIREFOX打开
。　对通过dev自测的版本测试，一个脚本就是从服务器上下版本，mount和自动安装，自动CM各类基线文件和安装脚本，重启。。。。。。
。　对某些反复进行的测试编写测试脚本，如测试数据清空和重载，数据自动导出，数据自动比较，回归测试工具编写，系统数据扫描和比较。。。。。。。。
。　数据库大数据量生成
。　长时间进程实时检测
。　服务的回归测试

简而言之，如果工作中反复进行一项操作，那就把它自动化，预留合适的配置或者接口，把变化留给它们，把不变留给程序。不要让人工作机器擅长的时间，同样不要让机器作人工擅长的事情，人最擅长沟通和创新，以及判断。比方说用例设计（我作过一个用例设计工具，结果非常不好），TROUBLE SHOOTING，人际交往，计划分配和跟踪等等。

而专用测试工具的应用如
。　填报BUG
。　回归测试执行
。　大UI数据量和客户端性能测试

对测试工具应用的界限就是成本小于收入的情况下，通常有
。　自己无法实现或者成本太高，如性能测试录制、控制和并发实现
。　需求和测试及开发追踪
。　测试管理
。　回归功能测试
。　BUG填写

而判断一个事情是人工作，自定义工具作，GUI工具作，性能工具作甚至是EXCEL或者其他工具作，就是LEADER的作用了。

最后一句总结就是：
多用工具，但是不要让工具的结果代替您的判断和信息的交流