楼主是一名测试工程师，工作5年之久，从来没有在任何博客或者其他地方发表过文章，也是惭愧之极。最近一段时间一直在研究接口自动化这么一项技术，状态似乎有些疯狂，也基于PHP开发了一套简易的接口自动化框架去实现自己的想法，当然还远远没有完善，可以算是从一个小白到了现在略知一二的地步，现在有一些迫不及待的想把最近最近研究的一些心得发表出来，还望看到的各位能不吝赐教，使得我能够在这条道路上继续前进，在此感谢最近一次面试中，一位CTO给我的指点，没有您，可能我还停留在一个不知也无畏的地步。想要看到这份源码的童鞋们，你们可以联系我，271783386@qq.com，稍后我也会对这部分我最近的理解，写出来，有很多的不足以及错误的方向，童鞋们多多指点，废话不再多说了，进入正题。
首先要谈一下，为什么最近测试界一直在讲自动化，不论是UI，还是接口自动化。那我们首先从接口自动化开始说起。
从最值得应用接口自动化的移动互联网说起，移动互联网的兴起，各类app出现井喷似的增长，包括各类H5的应用，那么在此，我仅仅对基于HTTP请求的外部接口，说一下最近的理解。
基于移动互联网的各类应用，与服务器端（下文统一SERVER端）之间的数据交互，我在这里称之为接口，那么自然而然的就形成了一个庞大的接口群。而接口传递的数据，最终还是体现在了移动应用的界面上，这里我不得不简单的说起功能测试在这一块的一个测试手段。
这里举例某求职软件**直聘的功能，消息模块，就单单拿聊天列表这个功能说起（这也是我最近用的最多的一个功能）。
首先，从功能测试的角度，这块可以大致分为俩个方向去测试，一为与服务端数据交互的数据逻辑正确性，二为app一些特性测试方向，如兼容性、界面、弱电弱网、crash异常情况处理如程序切换对app的影响等等等等，由此可见，在测试此功能的时候，测试的同胞们需要付出多少的工作量，还不包括需求变更以及接口变动，bug修复可以影响的范围等等等等，重复且繁重的工作任务，不仅仅让人会产生一定的厌倦情绪，导致一些漏测的情况出现，直接与产出质量挂钩，背了锅，绩效没了，心情也坏了，得不偿失……在此向奋斗在一线的测试猿/媛们致敬。最近几天，此软件频繁出现的bug，也可以从侧面证明这个事实的存在（顺便提一句，此处消息记录丢失，程序唤醒时异常崩溃现象时有发生，面试邀请发起错误……比较影响用户体验）。
那么问题来了，怎么才能正面减轻测试的部分工作量，提高工作效率，那就是接口自动化测试，把功能测试用例的关于数据正确性校验以及逻辑性校验部分的功能测试用例，演化为接口测试用例，把接口自动化的测试用例维护成一个整体，通过某一个统一的入口文件来控制接口自动化的运行，通过log或者htmlreport报告的形式来展现结果，在接口发布或者版本发布以后，在功能测试之前，通过手动或者自动触发的方式，来运行接口自动化测试用例，争取在功能测试工作开展之前，把基于接口的数据逻辑校验与数据正确性校验这部分工作进行完毕，最大限度的减轻功能测试在这部分任务上的工作量。就拿上述所说的例子来讲，暂且不理这个聊天列表内部实现的逻辑是什么，通过什么样的方式实现的，以及是不是通过第三方的接口来获得数据，我们就把他看作是一个http的接口，接口返回的数据是一个json格式的字符串，里边包含了每个用户的userID跟角色以及聊天内容、时间等数据，我们通过接口得到这部分数据解析以后，完全可以用代码的方式或者其他方式如postman、jmeter、fiddle等工具来验证这个数据的正确性，逻辑的正确性，我们自己的逻辑中包含了自己预期的内容，只要与返回的数据做一个对比，增加我们最近的断言，就可以对这个接口的功能，实现一个比较全面的测试。
说到这里的时候，有一个小小的故事，我感觉需要跟大家分享一下。
在最近一次面试过程中，有一段小插曲比较有趣，当时的面试官是一位测试以及一位开发，在与开发谈及接口测试以及自动化的时候，产生了一个不小的分歧，一度气氛比较僵持，也是我自己比较冲动的原因，在此也由衷的感谢这位开发童鞋，若不是这样一次又一次的争论，我也不能有这些理解，还在这里给大家献丑。
这位开发童鞋当时举了这么一个例子，这里我以第一人称来叙述一下这个例子。
一个成熟的系统，接口成千上万，那么维护这些接口测试用例需要付出多大的工作量，你有没有考虑过，我们也曾经做过接口测试，但是被我们开发给推翻了，我们感觉没用，还不如直接做UI自动化来模拟更切实际。
当时我立刻做出了反驳，这也是我此次面试过程中一个最大的败笔，又开始废话了，对不住各位哈。当时我反驳的理由是，你这一套成熟的系统在一行代码都没有写的时候，你是怎么把他一步步搭建起来的，这是需要时间的。而且UI自动化（当时面试的部门是首页活动的一个部门），活动多的时候界面元素一天好几次变化，就算是大的方向不动，一个页面中最小的div的一个变化，位置变动或者该div组增加或减少一个元素，UI自动化的测试代码都可能跟着变动，而且得出来的测试结果也并不能以此来表述此次测试的结果，那岂不是付出的工作量会更大。
此次面试到此也就结束了，这个例子只是作为一个过渡，接下来想要谈的接口自动化如何实施，其实是基于这一次的谈话，我才能有的体会。关于UI自动化，我了解的不是特别深入，只有一个结论，页面元素不稳定，频繁改版，以及立项初期，慎入。
如上个例子中所说的，成千上万的接口，我们都要一一去自动化么？开发这些接口的人，可能早已经离职，一些老旧的接口，可能连接口规范都没有，随意定义，新人不了解老人的接口逻辑，没办法给出具体的参考，以供测试人员开发相应的接口测试用例，是否还要坚持去做接口测试？
答案其实是否定的，那些老旧的接口，我们只能说力所能及的去做接口测试，而并非全部都要做，没必要为此再付出巨大的人力物力，也是公司所不能承受的，而且老旧的接口，已经成型，使用过了很久，功能性这方面来说，已经很稳定，该暴漏的问题，也差不多都暴漏了，而且这块代码别人去修改的可能性也很小，所以说，没有太大的必要去做这部分的接口测试。
那么，在一个项目中，什么时候引入接口测试？引入接口测试的前提条件又是什么？接口测试的范围有多大？这里我想说一下我自己个人的看法。
引入接口测试的前提条件，是接口规范的落实；
引入接口测试的时机，是落实接口规范以后，就可以立刻着手开展工作；
接口测试的范围，从有了规范开始，以及规范不成熟但是存在的时候（一些可追溯的老旧接口）；
遵守规范，人人有责。
需求评审会议开完之后，测试与开发人员，对于需求都有了一定的了解，需求评审会议结束后测试人员就可以着手去写一些功能的测试用例，开发同事在定义完此次版本需要的接口之后，一定要有接口的规范文档产出，对于什么情况下返回什么样的数据，返回的数据结构是什么样子的，都要有明确的描述。这样一来，负责接口测试的童鞋，就可以根据当前的功能测试用例，有关于接口部分的用例单独列出来，对照接口开发文档，开发相应的接口自动化测试用例，当某一个接口或者全部接口发布以后，运行这些用例，这样既保证了开发与测试的一个同步进行，也减轻了功能测试的工作任务，我认为是比较俩全的策略。
接口测试的一些理解，就到此为止，接下来，我想说一下，我自己在一个php的开源的框架上，二次开发的一套简易的自动化接口测试框架，说一下它的实现原理，代码也比较简单，后续需要不断的完善。
首先呢，我选取了一个比较简单的mvc框架，选取mvc结构的理由，是代码可维护性高，这个有点不用讲，我的目的是，要在这个框架上能做无限的扩展，说不准还开发个用例管理工具、bug跟踪系统、可视化的接口自动化测试工具呢，让大家都可以更简单的把接口自动化搞起来，哈哈，这是后话了。
自动化测试用例的入口文件，为统一的一个入口，这个入口中，去获取了全部的测试用例文件集合，通过反射等手段，拿到了这些文件中的各个方法，也就是单个测试用例，通过特定的方法，一次性全部运行，测试用例中加入了log日志，让每次运行的结果，不论成功还是失败，都在日志中有一个体现。目前就实现了这些基本功能，对于有代码能力的童鞋来说，运用接口自动化已经够了。
接下来，我谈一下这个框架以后的一个实现，我打算加入数据驱动模式，最大限度的减少代码量，提高可维护性，加入html报告，加入邮件发送功能，把每次的运行结果一html的形式在运行完毕后发送到个人邮箱，达到无人职守的状态。再接着往后，如果我精力足够，我想把他发展为一个禅道一样的工具，接入数据库以后，还想实现界面话的自动化接口测试，让全员都可以做接口自动化，这个理想太丰满，有兴趣的童鞋也可以联系我，我们一起来做。
这里还有一个坑没有踏平，就是目前捕捉不到http的timeout异常，有过类似经验的大牛，希望你看到这里的时候，可以给我一些意见，指导我前行。
好了，洋洋洒洒三千多字，就不再废话了，欢迎各位来喷，另外，纯手打，很累，如果啊，我说如果，转载的话，注明一下出处，在此感谢看完的各位童鞋。
