【歧】

　　这次的脚本的大概几个部分：

　　● 测试脚本都写在一个Action中，一个模块一个脚本。

　　● 测试的数据通过新建一个Excel文档提供，不使用Data Table，一行一个数据，脚本判断该行的执行列为1，则执行这个测试用例。

　　● 还有一个Excel文档，专门是用来控制脚本的配置和运行，如：“运行类型选项，是按次数运行，还是到了某个时间点就停止，还是不停运行”、“是否触发某个动作，还是只是新建”等等这样的配置项。

　　● 再加上一个txt文档，来记录运行时，我需要记录的log。

　　● 最后脚本编写好后，尽量不动脚本，需要调的，只是那些Excel文档。

　　于是，我便在工作空闲的时候，更加投入到所谓的“完美自动化”编写中。经过一段时间的编写，也有所成果，经过调整Excel，能够执行多种不一样的测试，很有成就感，便更加努力编写。

　　但是在工作中，问题还是来了：

　　1、我发现当新的产品更新了，我的脚本就报废了，如果要对新的产品进行自动化，就要花费不少时间对脚本中的代码进行更新，对数据库中的对象进行更新。

　　2、后来发现，产品会经常根据客户的要求做定制，悲剧啊~不得已，将一些对象的名称，软件标题等一些东西也进行了参数化。

　　3、还发现如果有个什么特定数据下的测试任务，有的则是特定的组合操作，发现我的脚本根本不会做到那么细致，也不可能做到那么细致。当遇到这样的情况时，是重新写一个新的临时的脚本作为测试用的脚本呢？还是增加脚本的配置项，是个很头疼的选择问题。如果选择新建临时的，又需要写脚本的时间，而且我之前写的脚本的作用就更小了。如果改原来的，发现也是需要花一定时间来编辑脚本。怎么着都得不偿失。

　　4、脚本复杂后，还很容易出错，有的时候还会出现一些稀奇古怪的错误，一旦出错，就很难进行修改。

　　5、如果有一个函数需要改动（如登录函数），因为每个脚本都使用了这个函数，所以需要打开每一个脚本进行修改，太麻烦了。

　　6、我一直想着，只要这个“完美自动化”出现，那以后版本更新后，跑一下它，所有功能点都测过一遍了，可现实发现，更新后，脚本就几乎瘫痪了，和我心中的那个“完美”，似乎差的有点太远了。

　　改的时候，有时候会想，还不如重新做呢，但看着那3000+行的代码，又十分的不舍得啊。就这样，像是走火入魔一般，想着我的“完美自动化”，脚本功能写的越来越细，维护难度也越来越大。

　　歧途啊~

【毁】

　　也许真的是天意，老天都看不下去了，一天，我正在做测着测试工作，突然间，操作系统就报错崩溃了，同时听到了硬盘读盘卡盘一样的噪音。重启电脑，发现再也读不了我那硬盘了。经过了好几个小时的尝试，无奈以失败告终。于是，我自己收集整理的第一批学习资料，和我的那个“完美自动化”一起，消失的一干二净。

【新】

　　经过了这一次教训，我知道了，以后写脚本，一定要多保存几个地方，这样一台电脑报销了，也不用担心。

　　同时，我也总结了一下关于我的“完美测试脚本”，发现问题太多，完全就是，背离了自动化测试本来的意义，完全是在向一条大错特错的道路上在狂奔着。自动化测试，本来就是用来解放人力，将一些繁重，繁琐的工作交给脚本自己来完成，节约时间才是关键，而我一直在做的是，花五个小时开发脚本，然后运行5分钟来测试一个手工20分钟的测试内容。

　　于是，我决定重新再学习一次软件测试的基础知识，这次的学习，之前一些没有看懂的知识一下子就理解了，对自动化测试也有了更新的理解。

　　随后，我重新写了测试脚本，这次的脚本便的简单多了，除了沿用了上次版本对于数据和控制写入Excel中这点，对需要写脚本的功能点也进行了筛选，选择了主要的功能点进行脚本的编写，不再对那些细小，冷僻的功能进行脚本的编写。脚本主要做的功能也不再是追求“完美”，而是只做回归测试和长拷。反复重用的函数写在外部VBS文件中，用Function Library进行加载使用，减少了反复复制粘贴的麻烦。代码也更加直接和简洁。似乎稀奇古怪的报错和卡壳也少了。

　　之后使用中，又发现了如脚本拷到别的电脑上时无法使用，本地地址和相对地址的问题，更新了几次脚本。

　　随后做了一段时间的性能测试（这个这里不讲了，随后再写一篇细说）和对该脚本的维护。

　　在2012年过完年由于一些原因就跳槽了。