首先感谢公司，只来了一年，我接触了两种自动化工具，一种是测试接口的，一种是直接从GUI下发的。翻开目前存在的测试资料，能够被企业级应用的自动化工具类型也无非就这两种方式，深入接触了之后，觉得两种方式各有千秋，也各自能够完成自己的使命。当然了，这两种工具公司内部开发，也只能在内部平台上使用。不过没什么，学习了方法和过程，就向看惯了五岳、黄山一样。
      接口测试工具：首先这种方式测试人员自己就可以编写工具，开发人员有一套编码规范，在设计阶段就会提供北向或者南向接口，每个迭代会发布接口属性列表，告诉前端页面开发，我们的这个怎么调用。一般项目比较大一点时，前期都是需要先将后台稳定，过两个迭代才将页面集成进来。可是在没有页面的情况下，测试人员不能根据手工测试，需要自己给接口传参数来测试结果。测试人员在用例撰写完成后，就需要编写脚本了，因为在没有页面的情况下，我们的测试执行就全靠它了。
      简单的举下例子，我们的增删改查对象基本上是每个系统都会有的。那么我们如何去测试这个接口？其实我们在写自动化脚本的时候需要考虑的东西很多，不过核心的只有那么几点，一是要稳定，二是要可重用。我们的脚本和代码一样，我们在写增加对象的时候需要编写一个逻辑，逻辑中调用开发提供的接口，参数值在我们写具体用例时给予传入，例如边界值等等。整个增加功能我们只需要一个逻辑就可以搞定，节省了时间，脚本还不容易出错，后期即使接口变了，我们只需要改一下逻辑，所有的脚本还是可以正常运行了。这个和编码规范一样，通用的东西写在一个方法里，方便扩展和修改。可以想象一下把restclient做成可以连跑的工具。
      下面简单谈谈这种接口测试的适用范围和优势，接口测试更好的适应在中间件开发团队以及更页面弱相关的项目中，首先我们不需要关心页面实现是个什么样子，我们只提供接口，我们关心的接口能否正确的接纳信息并给予正确的返回，其实我们现在还没有页面来调用我们，连我们自己都不知道页面长什么样子，但是我们要保证页面集成之后我们的接口是没有问题的。对于测试人员的角度来看，这种工具有很多好处，一是逻辑抽象化容易，其基本上和写单元测试用例类型，只不过测试对象不是一个函数或者类，是一个功能点罢了，二是这种工具写好的脚本稳定性很高，不受页面变化的影响，后台接口的变更频率比前端页面小的多。
       话又说回来这种工具也是有局限性的，它不关注页面，目前我们市面上能够只提供接口或者API来赚钱的公司毕竟少数，大家还都是做产品的出身，毕竟东西是要拿出去卖钱的，没有页面你让客户看什么？而且这种工具引进项目之后，测试人员没有端到端的打通过产品，还是需要手工在页面上操作，这个工具也不能发现UI和接口未对齐的地方的缺陷。
      那么下面的一种工具就能够满足要求了，那就是GUI的自动化工具，它能直接模拟测试人员触发功能按钮，端到端的测试交付的功能，我们常见的QTP也是属于这一类的。不过这种自动化工具也是有其长处和短处的，具体如何取舍，下一篇再聊！