从我们平常生活当初，接触比较接近自动化的东西就是游戏的外挂，他能够控制一个角色在一个指定的游戏ui中重复的做几件东西。这个的优点就是能够很大程度的摆脱了一些枯槁重复的人手工作，让玩游戏的人可以花更多的精力在一些有趣的游戏任务上。但是缺点也很明显，好比很多回合制的游戏都做一些答题类的东西抵制外挂，这体现了脚本的死板的一面。
而这种拥有循环和简单的判断的代码或者工具功能其实就已经达到了自动化的初级阶段－脚本化。我们可以这么理解，脚本化的流程就是我们制作了很多的测试用例脚本，当我们需要回归测试或者简单的压力测试的时候，就调用这些脚本来简化我们的工作。更特殊的情况是在android的产品里面的单元测试包也是处于脚本化的阶段。好比下面的脚本。
脚本1：
set testfile2 [open $testfile a+]
set tellfile [tell $testfile2]
puts $testfile2 "1,2,3,4,5,6,7,8,9,10"
puts $testfile2 "10,9,8,7,6,5,4,3,2,1"
close $testfile2
脚本2：
set testfile2 [open $testfile]
seek $testfile2 $tellfile
#此处打印新输入的信息。
puts seektell===[read $testfile2]
close $testfile2
第一个脚本做的是记录文体变动前的一个光标位置，同时输入2行信息。
第二个脚本就是把输入的两行信息进行读取出来。
这个模式一般我是使用在自动安装软件的时候，当安装完毕后，检查下软件是否安装成功，通过截取安装过程的日志来进行判断。好比脚本1我们只需要记录光标位置，去除输入的信息，等待安装自动打印信息和安装完毕后，我们再通过脚本2获取安装的信息，然后通过正则表达式进行匹配日志里的成功和失败的日志。
当我们处于脚本化阶段的话，上面这个流程我们需要做那些操作呢？
1. 启动脚本1的光标记录功能记录日志尾部的日志。
2. 启动自动安装的脚本。
3. 当判断自动安装的进程不存在之后，启动脚本2进行获取信息匹配是否安装成功。
当脚本能够把这三个流程操作进行自动化后，我们就获取了一整套的自动安装和判断结果的用例。此时，我们需要做的手工操作的事情是：
1. 我们手工去拷贝到或者安排执行脚本的执行机。
2. 我们手工去启动脚本。
3. 我们判断执行结果之后把结果进行统计发给相关关注人。
4. 我们需要知道开发什么时候打包好版本，才去启动以上的步骤。
5. 我们通过肉眼去查看打包的完整性，通过次来判断要不要启动自动安装脚本。
可见，在脚本写好之后，我们发现很多东西我们其实还是要通过人工去判断，可以看出，假如说只靠写的脚本自动化的话，我们其实效率上没有比手工执行多出多大的优势，而好处就是我们能够跟挂外挂那样不用在安装版本的时候盯着执行机的屏幕去查看过程，可以去干别的事情，差不多了就回来检查脚本返回的结果。
所以做到脚本化的程度后，我们还需要解决的事情有执行时间，执行结果统计，大幅度摆脱人工干预，分配环境等各方面。这个阶段在我做自动化小兵的时候，经常可能自己写了好多代码好多脚本的时候，一个前辈就告诉我现在其实我们一定程度上还是手工黑盒的测试。而需要把这些往自动化发展的话，就要把脚本化转为程序化的过程。
