首先感谢公司，只来了一年，我接触了两种自动化工具，一种是测试接口的，一种是直接从GUI下发的。翻开目前存在的测试资料，能够被企业级应用的自动化工具类型也无非就这两种方式，深入接触了之后，觉得两种方式各有千秋，也各自能够完成自己的使命。当然了，这两种工具公司内部开发，也只能在内部平台上使用。不过没什么，学习了方法和过程，就向看惯了五岳、黄山一样。
接口测试工具：首先这种方式测试人员自己就可以编写工具，开发人员有一套编码规范，在设计阶段就会提供北向或者南向接口，每个迭代会发布接口属性列表，告诉前端页面开发，我们的这个怎么调用。一般项目比较大一点时，前期都是需要先将后台稳定，过两个迭代才将页面集成进来。可是在没有页面的情况下，测试人员不能根据手工测试，需要自己给接口传参数来测试结果。测试人员在用例撰写完成后，就需要编写脚本了，因为在没有页面的情况下，我们的测试执行就全靠它了。
简单的举下例子，我们的增删改查对象基本上是每个系统都会有的。那么我们如何去测试这个接口？其实我们在写自动化脚本的时候需要考虑的东西很多，不过核心的只有那么几点，一是要稳定，二是要可重用。我们的脚本和代码一样，我们在写增加对象的时候需要编写一个逻辑，逻辑中调用开发提供的接口，参数值在我们写具体用例时给予传入，例如边界值等等。整个增加功能我们只需要一个逻辑就可以搞定，节省了时间，脚本还不容易出错，后期即使接口变了，我们只需要改一下逻辑，所有的脚本还是可以正常运行了。这个和编码规范一样，通用的东西写在一个方法里，方便扩展和修改。可以想象一下把restclient做成可以连跑的工具。
下面简单谈谈这种接口测试的适用范围和优势，接口测试更好的适应在中间件开发团队以及更页面弱相关的项目中，首先我们不需要关心页面实现是个什么样子，我们只提供接口，我们关心的接口能否正确的接纳信息并给予正确的返回，其实我们现在还没有页面来调用我们，连我们自己都不知道页面长什么样子，但是我们要保证页面集成之后我们的接口是没有问题的。对于测试人员的角度来看，这种工具有很多好处，一是逻辑抽象化容易，其基本上和写单元测试用例类型，只不过测试对象不是一个函数或者类，是一个功能点罢了，二是这种工具写好的脚本稳定性很高，不受页面变化的影响，后台接口的变更频率比前端页面小的多。
话又说回来这种工具也是有局限性的，它不关注页面，目前我们市面上能够只提供接口或者API来赚钱的公司毕竟少数，大家还都是做产品的出身，毕竟东西是要拿出去卖钱的，没有页面你让客户看什么？而且这种工具引进项目之后，测试人员没有端到端的打通过产品，还是需要手工在页面上操作，这个工具也不能发现UI和接口未对齐的地方的缺陷。
那么下面的一种工具就能够满足要求了，那就是GUI的自动化工具，它能直接模拟测试人员触发功能按钮，端到端的测试交付的功能，我们常见的QTP也是属于这一类的。不过这种自动化工具也是有其长处和短处的，具体如何取舍呢？
下面我们来谈谈时下应用最多的自动化类型工具--GUI类型的自动化工具。
图形用户接口类型的工具，顾名思义，是从页面直接触发命令，完成测试人员手动执行的步骤。相当与一个不需要休息不需要拿薪水的测试人员，每天孜孜不倦的干着重复的事情，却没有任何抱怨一样。不管是我们的QTP还是公司内部自己开发的自动化工具，无非就是先寻找页面上的ID信息或者脚本定位信息或者XPath信息，定位到某一个按钮或者输入框，点击或者输入测试内容，提交后校验页面能够给予的返回信息，不同的脚本传递不同的参数或者点击不同的按钮，校验最后的输出也好，校验页面的错误提示信息也罢，都是以工具替代人工来执行，例如我们可以编写某个系统的门槛用例、冒烟用例的自动化脚本，在开发人员使用自动编译工具生成最新版本的时候，我们自动获取最新版本执行安装，之后执行自动化脚本，在夜里、第一时间掌握版本的实际信息，是否能够转测试成功，是否存在主干流程上不通的情况，如果附带录像回放工具，那这个工具还能帮助开发人员还原当时错误的情况让开发人员“穿越”到之前的情况查看页面出现的BUG，一举多得。
既然这种工具这么好，那我们赶紧开展哦~~~
熟练的测试人员都知道这种工具有个很不好的弱点。这种工具过分依赖页面，可以说页面一旦有个风吹草动这个工具生成的脚本就需要更改；一般情况下展开测试自动化都是在项目的后期，基本功能已经无大碍，连续测试过几轮都没有问题，页面也渐渐趋于稳定。所以，采用这种形式的自动化时，测试人员需要做的首件事情就是和开发的SE确定页面和页面控件的ID。其实这些东西我就在这里说说，这个东西实现起来，推动起来是多么难最后还是要修改，被这个脚本折腾吃过苦头的事还历历在目。其实项目开始的时候，领导一声令下要使用GUI工具自动化时就想到这一点，结果就是迭代一推动到迭代二，在推到迭代四，一直到最后要自动化了，下了最后通牒时才给出一个结果。不是开发的SE故意敷衍你，就算迭代一他费好大的劲搞好了又能怎么样呢？众所周知页面这个东西，都是仁者见仁智者见智，更不用资料和UCD的那一帮子整天觉得这个不爽那个不顺眼的，我不是诋毁他们哈，只是觉得页面这个东西，定的太死后面吃亏的是我们自己，包括测试和开发。即便如此，我们实现了自动化，还是给修改带来了很大的工作量。很难保证开发在某一个迭代页面没有动一点东西，只能祈求不要动主干或者不要添加什么ID或者打乱原来的XPath（有些东西开发是没办法给出ID的）。
再者这个工具有一个弱点，分析不了逻辑，如果一个页面需要逻辑展示或者时下最流行的图形操作，这个自动化真是鞭长莫及，这个分析能够根本不能胜任的，测试人员你还是老老实实的自己构造条件手工测试吧！
看到了吧，过分依赖页面的自动化工具的下场了吧。
但是我们不能因噎废食，自动化工具如果不能提高我们的测试效率，那我们凭什么花那么大力气去定规范和写脚本？自动化工具，不管是接口的还是GUI的，其能够存在都是有其道理的。一般情况下接口是不会随便动的开发人员也害怕领导找他的麻烦，改动接口还得联调，又是一个大工作量，所有接口自动化工具生成的脚本稳定，可执行程度高，基本不会出错，如果里面存在缺陷可以很大程度上能够校验出来，缺点是不能结合页面不知道最后集成后会有什么问题；GUI类型的工具强大的地方在端到端的验证，能够像人一样操作被测系统，给测试人员最好的结论，缺点就是维护成本高，易变更（这一点高手测试人员可以尽量减少）。此处比较罗列，想让使用自动化的项目组有个参考，看哪一点舍弃损失最少或者采用哪种收益和成本最大。其实说了这么多，其实自动化工具再好也替代不了人，自动化脚本跑动的脚本依赖用例，用例设计依赖测试人员，用例才是测试根本！
测试，你做好设计准备了吗？
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
