接口自动化测试——前言

            最近又有一个项目完成，终于得空可以写写代码，探索一下接口测试的奥秘。

            由于笔者也是第一次尝试写接口自动化的脚本，以前一直停止于UI自动化的层面，UI自动化响应时间慢，取元素之难，也是让人叹为观止，虽然推出了各种优化工具，比如说，cucumer，rf等等的一些工具，简化了UI自动化的难度，但是一个iframe的修改从而引起不断的调整页面元素，甚至于一大段代码重写还是让人难以避免，这也是笔者前段时间写着写着就不想写的原因，付出与回报确实不成正比。

             然后笔者时常需要到客户现场做性能测试，从而接触到了jmeter，使用jmeter进行压力测试，也知道了压力测试的核心，是对接口进行施压，进而观察内存、cpu、io等情况，对系统进行全方位的优化，把并发数从20推送到了100，也算是小有成就，然后想着用jmeter来实现接口自动化，却发现好虽好，但是毕竟是压力测试工具，是无法实现接口的联动性的。我们正常工作的时候，会发现一个问题，开发改动了一个地方的代码，从而引起了其他地方的代码的变化，导致了线上bug的爆发，无口厚非，这个与架构师的架构师脱不开关系的，但是作为测试，却也有难以逃脱的责任。然后笔者就放弃了jmeter，从而走向了接口测试的核心，httpclient

           从应用层走向底层，果然是需要勇气的，笔者封装好了取接口的httpclient的代码，又在设计模板，读取excel的模板，并生成excel的测试报告，然后到了excel的时候，笔者想到，后台开发同学的代码提交的时候是否每次可以写上接口的名字，这样，他们修改了代码，我们也能从接口中获知，到底涉及到了多少模块，甚至于说接口自动重新跑一边。这个对于目前的项目或者我来说，可能是一个前进的方向，笔者前段时间设想着取接口的方法，后来终于大彻大悟，明白了接口如何获取，原先的想法是在服务器端用代码取到经过网卡的接口，从而捕捉到接口存放起来，当然，这是一条最为保险的方法，可惜实施起来，发现难度太大了，各种代码分析完之后，却未能实现一点点突破。然后笔者却看到了开发同学的debug的日志，发现其中有很多的.do内容，笔者立刻想到是不是开发同学所有写的接口都会经过debug打印到日志中的，后来发现开发同学确实是有这个习惯的，那么，此时，监控网卡就变成了日志分析，还有就是通过页面分模块直接取接口，从两方面来实现接口内容的完整性，这样会比监控网卡更简便点。更直接的，监控会不会影响服务器的性能，这也是很大的问题。