接口自动化和GUI自动化工具优劣比较

　　简单的举下例子，我们的增删改查对象基本上是每个系统都会有的。那么我们如何去测试这个接口？其实我们在写自动化脚本的时候需要考虑的东西很多，不过核心的只有那么几点，一是要稳定，二是要可重用。我们的脚本和代码一样，我们在写增加对象的时候需要编写一个逻辑，逻辑中调用开发提供的接口，参数值在我们写具体用例时给予传入，例如边界值等等。整个增加功能我们只需要一个逻辑就可以搞定，节省了时间，脚本还不容易出错，后期即使接口变了，我们只需要改一下逻辑，所有的脚本还是可以正常运行了。这个和编码规范一样，通用的东西写在一个方法里，方便扩展和修改。可以想象一下把restclient做成可以连跑的工具。

　　话又说回来这种工具也是有局限性的，它不关注页面，目前我们市面上能够只提供接口或者api来赚钱的公司毕竟少数，大家还都是做产品的出身，毕竟东西是要拿出去卖钱的，没有页面你让客户看什么？而且这种工具引进项目之后，测试人员没有端到端的打通过产品，还是需要手工在页面上操作，这个工具也不能发现ui和接口未对齐的地方的缺陷。

　　下面我们来谈谈时下应用最多的自动化类型工具--gui类型的自动化工具。

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

　　既然这种工具这么好，那我们赶紧开展哦~~~

　　再者这个工具有一个弱点，分析不了逻辑，如果一个页面需要逻辑展示或者时下最流行的图形操作，这个自动化真是鞭长莫及，这个分析能够根本不能胜任的，测试人员你还是老老实实的自己构造条件手工测试吧！

　　看到了吧，过分依赖页面的自动化工具的下场了吧。

　　测试，你做好设计准备了吗？

====================================分割线================================

最新内容请见作者的github页：http://qaseven.github.io/