接口自动化测试感想
前言
至今为止也做了快一整年的接口自动化了，在融合线上项目中，学习到了很多。抽空记录下这个项目得心路历程。
做这个项目的缘由
早早就听说过测试自动化的顶顶大名，上家公司准备采用RF这样得关键字框架来做一些UI自动化，由于自身缘由，没有参与太多，第一次听闻自动化就是在哪里。自己内心深处也特别想去看看到底测试自动化是什么样子的。是不是就可以摆脱点点点了。感谢当前的公司给与了我一个这样的机会。大boss倾向做出一个测试自动化，我直属leader当然就是做咯，所以就招了我来完成这个项目。
就有了我之前的几偏文章
之前的文章也可以是我心路历程的阶段性体现，从不懂，到学习。去挖掘，去对比，去执行。去传播。
随着了解的越多，发现自己还有着更多的不懂。需要去学习和实践。
接口的理解
这个是理解接口自动化的核心要素，需要知道什么是接口？接口是怎么来的？接口有什么作用？不同的接口有什么区别？接口的必须条件是什么？什么样的接口可以进行自动化测试？
我尝试从自身角度说说我的理解，如果说错了或者不足可以和我交流下，我会修改的。
什么是接口？
其实在百度百科已经说的很清楚了，我以软件为维度来解释，如果是JAVA语言，接口你们可能更多理解为一个类所具有的方法的特征集合，是一种逻辑上的抽象。这个是JAVA语言的定义。如果在一个项目中，前端同学需要你提供接口时，可不能这样回哦。因为在广义的定义中，前端同学要的接口是你controller层中定义的参数和协议。前端同学根据你提供的协议和参数来进行调用传参数。这样的‘接口’在其他编程语言中和路由是非常类似的。又有着不同，路由只有路径没有协议。这样定义的‘接口’，从字面上来看确实更加贴合本意。恰好业界也认可，达成默认共识了。
接口是怎么样来的？
很显然接口是人为更加业务情况定义出来的，不同语言实现方法可能会不同，但是大同小异。我以JAVA为例，定义一个接口你需要确认这个接口采用什么样的协议，是http还是socket。不同的协议调用的基本库不同。假如是http协议，还需要确认请求方式是什么，是get还是post或者其他的方式。如果带有参数，那么参数的定义是怎么样的，数据持久层和数据库表结构设计等等就都慢慢出来了。当这一切都定义好了，那么一个接口也就诞生了。
接口有什么用？
在之前的网页技术当中，因为项目比较小完全可以自己内部循环，不需要这样的‘接口’出现，当后来随着技术的发展，项目体机越来越臃肿，采用了更加合理的层次结构，采用‘接口’来对业务逻辑进行解耦。包括当前较为流行的微服务也是做解耦的，通过接口的定义来实现。
不同接口有什么区别？
接口最大的不同点或者核心点就是在于它实现的协议，当前使用的有tcp/udp，后面衍生了http1.0，http1.1，http2.0，https，还有socket，soup，rpc等等，不同的协议都是针对不同业务的解决方案。
接口的必须条件是什么？
协议，请求方式，参数，这三者应该说是一个接口的组成条件。
什么样的接口可以进行自动化测试？
符合定义规范，例如http中的reastful API。逻辑清晰，有着良好的输入/输出文档。
接口自动化测试的2条支路
支路一
当前很多公司做得接口测试是：根据接口文档或接口服务对当个接口进行设计测试用例，有正向和异常，边界值测试。
好处：对接口覆盖比较全面。
缺点：没有综合考虑性价比，因为单个接口来说，前端和后端都会做很多校验，从测试角度，我们确实需要是验证这些校验是否正确执行，当时投入下去得成本，可能不能获得类似得产出。并且因为完全没有考虑或者说没有条件去考虑到该接口的实现情景上下文的关联关系,也就是说不能从 前端界面-->接口服务处理--->数据库表字段 ,来综合以一个场景化的思维来综合测试接口，这样就基本上很难发现问题。
支路二
走接口串联的路子，按照实际业务需求来设计，准确来说是把手工执行的用例转换为调用接口来执行，这样就可以考虑情景上下文的关联关系。使用接口来完成业务的逻辑测试。
好处：可以相当一部分代替人工回归测试，执行速度快，有一定的质量保证，性价比高。
缺点：缺少单个接口的测试覆盖度，可以会有一定的漏测。接口组合情况多种，测试用例的乱序组合调度需要进行解决。分层结构，结果产出，问题定位都是需要面对的问题。
我的看法
在我实践的项目中，我采用的是支路二，因为投入的成本有限，而且需要快速看到收益。最好好的办法就是，制定自动化的原则，搭建好分层结构，定义好产出。重复发挥手工测试人员的力量。优先把冒烟测试的用例给转换为自动化测试用例。感受到效果再进一步实施。
如果后期项目可以稳定执行下去可以充分在支路二的技术上加入支路一的测试方法，扩充测试覆盖度，是非常不错的。
工欲善其事必先利其器
咱们做软件的，没个利器来干活，估计效率也不高，IDE就不说了，个人喜好即可。关于接口自动化测试，那么需要根据你业务的自身情况和你团队基础来决定。工具选对了可以少走很多弯路的。基于大部分项目都应该是http协议，那么市面上就有很多工具可以选择了，整体可以分为JAVA系，Python系。
讲讲我在当前项目中，工具都使用了那些功能吧，供大家参考。
1、支持命令行CLI运行的方式。-----因为后续接入Jenkins需要。
2、整体框架能够有分层结构，方便调用。-------类似JAVA的分包，也可以调用。能够对用例模块更好的管理。
3、能够有精确的测试报告输出，日志记录和输出。------测试报告是最后的产出，也是定位问题的根本依据。
4、整体工具稳定，可维护。-----正式上线的项目，第一考虑要素是稳定可靠。所以工具最好是在持续维护的，有一定的成功案例和客户群体。
5、工具可扩展，开源协议。------工具没有完美，不同业务可以做少量的二次开发也是可以接受的。
6、可以提供hook之类的调用方式，响应结果支持多种断言。 -----实际业务中，请求和响应有可能需要加密和解密，对断言也有所不同。
基本上就是使用上诉功能了，在实际业务需求中，去尝试，根据接口文档或者抓包情况，来模拟请求，断言结果，根据报告和日志定位问题，串联接口组装成测试用例即可。
感悟
关于接口自动化，算起来已经在业界流行了很多年了。有着非常多的工具和方法来实施，但是真实在项目中的运行情况，在业界好像没有太多消息。现在突然又出现了一波web化的势头，更多的我认为应该回归本源，把基础的接口自动化做好了，做大了，做完善了。再考虑web化的事情吧，没有什么工具是完美的，QTP也凉凉了。只有跟着业务一起走，融合到业务中，才是核心。选择适合自身实际情况的框架，落地实施，才是重点，行动起来，才能有所突破和改变。
