（接上篇）上篇提到接口自动化工具的优劣，本篇继续自动化旅程，谈谈时下应用最多的自动化类型工具--GUI类型的自动化工具。
      图形用户接口类型的工具，顾名思义，是从页面直接触发命令，完成测试人员手动执行的步骤。相当与一个不需要休息不需要拿薪水的测试人员，每天孜孜不倦的干着重复的事情，却没有任何抱怨一样。不管是我们的QTP还是公司内部自己开发的自动化工具，无非就是先寻找页面上的ID信息或者脚本定位信息或者XPath信息，定位到某一个按钮或者输入框，点击或者输入测试内容，提交后校验页面能够给予的返回信息，不同的脚本传递不同的参数或者点击不同的按钮，校验最后的输出也好，校验页面的错误提示信息也罢，都是以工具替代人工来执行，例如我们可以编写某个系统的门槛用例、冒烟用例的自动化脚本，在开发人员使用自动编译工具生成最新版本的时候，我们自动获取最新版本执行安装，之后执行自动化脚本，在夜里、第一时间掌握版本的实际信息，是否能够转测试成功，是否存在主干流程上不通的情况，如果附带录像回放工具，那这个工具还能帮助开发人员还原当时错误的情况让开发人员“穿越”到之前的情况查看页面出现的BUG，一举多得。
       既然这种工具这么好，那我们赶紧开展哦~~~

       熟练的测试人员都知道这种工具有个很不好的弱点。这种工具过分依赖页面，可以说页面一旦有个风吹草动这个工具生成的脚本就需要更改；一般情况下展开测试自动化都是在项目的后期，基本功能已经无大碍，连续测试过几轮都没有问题，页面也渐渐趋于稳定。所以，采用这种形式的自动化时，测试人员需要做的首件事情就是和开发的SE确定页面和页面控件的ID。其实这些东西我就在这里说说，这个东西实现起来，推动起来是多么难最后还是要修改，被这个脚本折腾吃过苦头的事还历历在目。其实项目开始的时候，领导一声令下要使用GUI工具自动化时就想到这一点，结果就是迭代一推动到迭代二，在推到迭代四，一直到最后要自动化了，下了最后通牒时才给出一个结果。不是开发的SE故意敷衍你，就算迭代一他费好大的劲搞好了又能怎么样呢？众所周知页面这个东西，都是仁者见仁智者见智，更不用资料和UCD的那一帮子整天觉得这个不爽那个不顺眼的，我不是诋毁他们哈，只是觉得页面这个东西，定的太死后面吃亏的是我们自己，包括测试和开发。即便如此，我们实现了自动化，还是给修改带来了很大的工作量。很难保证开发在某一个迭代页面没有动一点东西，只能祈求不要动主干或者不要添加什么ID或者打乱原来的XPath（有些东西开发是没办法给出ID的）。
      再者这个工具有一个弱点，分析不了逻辑，如果一个页面需要逻辑展示或者时下最流行的图形操作，这个自动化真是鞭长莫及，这个分析能够根本不能胜任的，测试人员你还是老老实实的自己构造条件手工测试吧！
      看到了吧，过分依赖页面的自动化工具的下场了吧。

      但是我们不能因噎废食，自动化工具如果不能提高我们的测试效率，那我们凭什么花那么大力气去定规范和写脚本？自动化工具，不管是接口的还是GUI的，其能够存在都是有其道理的。一般情况下接口是不会随便动的开发人员也害怕领导找他的麻烦，改动接口还得联调，又是一个大工作量，所有接口自动化工具生成的脚本稳定，可执行程度高，基本不会出错，如果里面存在缺陷可以很大程度上能够校验出来，缺点是不能结合页面不知道最后集成后会有什么问题；GUI类型的工具强大的地方在端到端的验证，能够像人一样操作被测系统，给测试人员最好的结论，缺点就是维护成本高，易变更（这一点高手测试人员可以尽量减少）。此处比较罗列，想让使用自动化的项目组有个参考，看哪一点舍弃损失最少或者采用哪种收益和成本最大。其实说了这么多，其实自动化工具再好也替代不了人，自动化脚本跑动的脚本依赖用例，用例设计依赖测试人员，用例才是测试根本！
      测试，你做好设计准备了吗？