今晚和大家讨论自动化测试如何做，感触颇多，我们现在的脚本，主要用来做什么，又应该用来做什么。
这里仅仅发表下我的一家之言。
目前我们的模式，我们的脚本主要用来做回归测试，而不能在日常项目中直接使用自动化脚本完成全部测试工作，我总结了下，主要原因有四
一、业务变化快
二、项目日常时间紧
三、编写脚本成本高
四、先期无法自我保证脚本的正确
我们的业务经常变，而且变化很快，有时候，在项目前期没有设计好，在开发的过程中都可能修改表结构，这导致我们在需求上就不明确了；而且项目日常时间比较紧，不管是编写ruby脚本或者是webx脚本，都需要耗费大量时间准备数据和编写脚本，一般一个脚本的产出，需要耗费很长的时间；最主要的是针对一个变动的应用，我们编写完脚本之后，只有开发提交了代码我们才可能跑通我们的测试脚本，当我们发现跑我们的脚本出了问题，我们又有多少理由完全相信这就是开发的代码出错了而不是我们出错了？
当然，我们现在的脚本扛起了回归测试的重任，不能否认，我们的自动化是做得非常成功的，而且现在的每日回归，脚本代替了手工操作，完成了我们曾经无法完成的任务。
这边我想对自动化脚本进行更深一层的探索，如果我们的测试工作要全部实现自动化，那自动化要怎么做。
我个人感觉，首先，这些自动化脚本要有以下几个特点
一、脚本很容易根据业务编写出来
二、脚本与系统的依赖低，系统在设计出来之前，可以顺利完成脚本的编写
三、脚本编写时间短，我觉得这个指标是一个脚本的编写到调试跑通，所耗工时应该在我们手工跑下这个用例的时间的三倍时间内
四、脚本执行速度高，一个脚本执行一遍，需为人工执行一次用例时间的1/5之内
五、可以快速定位执行中发现的问题
我们需要新的测试手段来实现它，我感觉这是套方法应该可以同时在gui和webx层切换的测试的工具，它独立于要测试的系统，集成客户端的浏览器核心，基于网络协议截取html，js等代码并进行分析，可以生成编写脚本页面，快速编写脚本，同时，可以在系统中载入浏览器核心，快速运行所需要跑的脚本，并获取传送给服务器的数据，打包传送给服务器……
望大家多多指导，谢谢。
