【心得】阿达聊自动化测试

       上一回，说了关于软件测试，这次来聊一下我的自动化。

      我接触自动化是在2010年，在毕业前夕，我就知道了自动化，但是，当时也只是知道而已，没有使用过，更没有在项目中投入使用过。毕业后，来到了上海，进入了第一家公司。进入了一个项目组，组内的测试人员很少，加上我才只有2个人。作为新人，便是从做手工黑盒的测试开始的。那时，开发出来的产品也比较简单，经过了几个月后，测试组的规模也慢慢的增大了，产品的功能也越来越强大，测试也变的越来越复杂，再加上有些客户反映，在长时间使用这个软件或是增加了大量的点的情况下，软件会出现一些稀奇古怪的问题时，领导决定需要增加自动化的测试，于是，我就稀里糊涂的开始了我的自动化测试之路。

【入】

      刚开始的时候，真是什么都不会，好不容易下载好了软件，学会了录制，便开始录制脚本、回放。使用了几天后，惊奇的发现居然还有Expert View这个编辑模式，瞬间感觉操作起来方便了好多，也更加自由的控制脚本了。由于小时候Basic玩的还不错，再加上后来学VB也学的很好，所以上手还是比较快的，一下子就学会了基本的操作。也买了一本书，学了不少的小技巧。一边学习，一边直接在项目中使用测试。学的真的很快，进步也很快。所以，总结出来，这些工具，只有加入到项目中去，学习才能更快，也更有目的性。

      其实QTP上手还是蛮快的，倒腾了几次，基本在使用中，借助的书本、网络、论坛等一些资源，在项目中指定的功能上做自动化已经没有什么太大的障碍了。但是，仅仅的一些简单的录制、修改、回放已经满足不了我的兴趣，将这个工具发挥的更强大成了我的兴趣。

【钻】

于是萌生了一个想法，可不可以将脚本做成全自动化的测试呢？我想让它测试什么模块，设置一下，然后执行它，最后只要看一下它的打印结果，就可以知道测试的结果，这样是多么美好啊。（当然，后来发现这样的想法是可笑的。）

我简单的想了一下，做了下设计：

l  根据功能模块划分，一个模块的测试脚本全都写入一个Action中。

l  然后在外面用一个大的Action包裹起来。

l  脚本包含软件所有的测试点。

于是便开始录制脚本、修改，最后发现了一个致命的错误，测试数据的处理，然后不得不再加上一条“测试数据加入Data Table中进行参数化”，当完成了2-3个模块后，我将脚本运用到测试中，感觉很痛苦，也遇到了不少问题，总结一下：

1.    脚本很大，碎文件也很多，每次复制粘贴就要不少时间。

2.    管理Data Table要好半天，而且哪几条运行，哪几条不要运行，都是通过设置Data Table Iterations来控制，很不方便。

3.    感觉很多东西都是重复的，没怎么重用。

4.    由于模块多，内容多，对象库中的对象也越来越多，管理对象库变的格外痛苦，有些一样的部分都已经XXXXX_8、XXXXX_9了，而且有时候，脚本中的一句语句对应的控件在对象库中找了好半天才找到。

5.    几乎没有用到需要用自动化同时测试两个模块的情况。那个包含所有测试点的设计，完全没有必要。

      这一次算是失败的。

于是，重新设计了一下脚本部分，开始再一次的尝试。

感觉有点钻牛角尖的意思了。

【歧】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

歧途啊~

【毁】

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

【新】

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

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

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

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

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

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

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

【建】

跳槽到了一家外包公司，以前我一直不喜欢外包公司，因为网上总是流传着各色各样外包公司坑人啊、无限制加班还没钱啊、没有五险一金啊什么的负面消息。不过最后我进了一家还算比较满意的公司，主要是，1.项目我比较感兴趣，2.他们想要建QTP自动化，但是没有人会，目前还没建，3.公司有五险一金，4.离家进，5.有午饭吃，6.不用加班，7.工资还行，毕竟年纪还轻，毕业也没多久，就算面试的时候这也能答，那也能说，但是一些公司总是和你说你的工作经验多少多少，公司只能给你多少多少以下，这点让我十分的不爽。不过这家公司到也爽快，可能真的是急需人吧。经过了电话面试、面试、客户面试、人事后，算是进入了。

测试基础自认为学的比较扎实，所以1周后便开始做任务，并提前结束了试用期。

有一个任务是客户想给他们的一个业务流程管理网站BPM建自动化测试，由于表单数量庞大，且每张表单的流程复杂，当一个版本更新后，靠手工进行每张表单的每个流程测试是不可能的，所以需要自动化来进行回归，减少人力。

有了上家公司的经验，这次在正式写脚本前，做了下功课：

l  确认项目的周期，版本更新的频率。

l  确认了一般只改后台代码，不动前台页面。

l  确认了是否有控件不能识别

然后我才开始脚本的编写，基本还是和之前做的差不多，不过这次很详细的划分好了那个VBS文件写哪部分的函数，也参考了一些网上的关于框架的设计，我也参考着自己写了一个“专用框架”。QTP操作一层；对于系统的操作一层；对能复用的地方进行了大量的复用；也是先了签核流程让脚本自己判断并选择方案完成；有了详细的html版本的LOG，并截图和文字记录并茂，。最后，把这些vbs文件都加载进脚本。写脚本只需写一个新建表单，之后的事，就交给了这个“专用框架”完成。签核的事，基本不用再编写脚本，大大提高了脚本的编写速度，而且使用下来，感觉也挺稳定，一直用到了现在。

我个人的总结就是：

l  一定要了解自动化是做什么的。

l  在软件测试理论知识还不是很牢固的情况下，不要进行自动化。

l  在软件版本还没有稳定的情况下，不要进行自动化。

l  系统中测试对象基本可以正常识别的情况下才进行自动化脚本的编写。

l  自动化测试一般情况下是用来证明软件能正常运行，而不是用在证明软件这么操作一定会出错上。

l  注意脚本的衔接，和数据回归，有时候，同一个数据只能用一次。

l  领导不支持的情况下，就算能做，也不要轻易进行自动化。

l  领导完全不明白什么是自动化的情况下，进行自动化要慎重啊~

l  自动化测试最主要的是提高工作效率，正确的使用是，用1天开发一个脚本能用3个月的测试，而不是花3个月开发出一个很牛的脚本来测试1天。

这些就是我目前的一些想法和观点，无关对错。也许一年后，我又会有更新、更加深入的了解。到时候，我会再写一篇，来反驳我现在的这篇的。

希望我写的这篇文章，对想做自动化的，正在做自动化的同学有帮助~

 欢迎志同道合之人一同学习。

QQ：370464196

Email：cydblack@163.com

陈永达