聊聊那些年做过的接口测试

           以下纯属聊聊过去三年在前公司做过的接口测试，没啥特别的技术含量，可能写的会有点乱 ，只是一些流程，测试方法上的简单总结~~

     ​

           过去三年也是就职于某电商公司，前公司的测试架构简单可分为 前端和后端 ，测试呢，大概有几百人，前后端测试的比例基本大概为1:3 ；后端基本是纯接口测试，基本不用涉及任何的前端界面操作， 然后前端呢，基本上因为这几年来PC,WAP 端的用户量其实很少的，基本都不怎么维护了，所以真正算起来是APP 前端和底层测试了。本人主要是做交易服务底层接口的测试，三年转了三个组， 涉及到了库存，商品，购物车，订单售前售后等 ， 感觉应该算是公司业务最复杂的一个组了；公司底层也分了好多模块： 活动，价格系统，物流等，综合起来，最复杂的业务组应该就是订单组了，订单售后各种状态的流转，和下游各个系统 的交互特别容易出问题~~

          在过去的三年里，也是经历了公司的一次大的代码重构， 直接将后端php写的工程转为java 工程了，接口的入参，出参等都变化了 ； 重构的过程也是历经了一年，不过重构后代码的结构变的清晰了好多，性能经过实践确实也是比前php工程代码的性能 有所提升 ；接口的协议是公司自己开发的一套框架，其实也是类似和dubbo接口一样通过将服务注册到zk ，然后通过proxy 去zk找到相关接口的服务 或者是通过服务器+加端口直接去访问 。

         然后说回之前的一个测试的流程  （项目需求，提测前， 测试，上线）         

          1 、项目需求阶段：

          大项目一般都有专门的项目经理去跟进前端后端的排期，然后我们后端的产品经理会跟前端的产品经理确定需求点，然后跟开发（有时候也会拉上测试）讨论技术方案， 后端的产品写的需求基本上都是维护在一个wiki上，产品经理或者开发也会写清楚后端要涉及那几个工程要改，改了那几个工程的接口，需要后端的接口给到什么字段前端，这些都会提前商量好，所以很多情况下，基本都是后端功能测试完成其实上线很久了，然后前端才会来接入我们的接口 ；

         第二：项目提测阶段：

         确定好需求后， 开发提测前也会找测试简单过一下设计方案，类似要输出什么字段给前端呀，逻辑里面要怎么改呀，调了什么外部接口来拿值呀，需要和哪个外部系统联调呀等等这些都会说清楚 ~~然后~~~ 开发就又开始写bug了   ~ O(∩_∩)O~   ， 之前做的比较不好的地方开发的单测其实没有比较统一的规范，导致其实写的单测覆盖点不一定全，所以基本上感觉接口的质量最主要靠测试来把关的，一不小心测试，开发随时就埋了个大坑，至今深有印象的一个bug是一个加日志的项目， 开发在底层每个接口入口的地方打了一个日志，刚好另外一个计划任务的工程需要调用这个工程的一个清空购物车的接口，日志那一行卡住了，然后导致购物车连续两个小时释放不了库存，然后来了一个P1 故障，然后各种检讨~~~~所以，当开发说，我只是加了一行日志，不用测试的时候，总是感觉瑟瑟发抖~~~~~

​

       第三 :项目测试:

        然后就是轮到我们测试的工作了 ，一直说强调质量前移，不要把所有的上线压力都放在测试，但是这块一直做的不够好，不过也在慢慢的推进 ；之前都是一周发布一次版本，每周三固定发布日期 ，（有时候也会处理一些线上紧急问题啥的，有时候一周五天都在发布，也是蛮坑的~~不过发布从验证到上线基本有一个值班的同学在跟就可以了，值班的同学当周一般项目会安排少一点） 所以项目排期的时候，一般是下周三要上线的项目，我们一般都会预估这周五前能不能完成，（预估的时间因为一起开始做接口测试写自动化脚本不太熟练，可以多加上这部分耗费的时间，排查倒排期的项目）如果不能完成，基本上都是不让上了，这点还是做的挺规范的，然后每周一，二 是回归时间（不过自从我们在测接口功能测试的时候就写自动化脚本去做的时候，基本上回归的时候跑脚本就可以了，回归基本不用怎么做~~） 

     因为每周都有版本要发布，项目排期也比较紧，只有少部分的项目能够在开发提测前就把自动化脚本写好，一般都是开发提测完后， 首先我们会去看开发的代码具体的逻辑改动点 ，然后结合产品的需求文档，结合开发给的提测wiki ,然后开始写接口自动化用例， 目前的接口测试方法都是在自动化框架里面 写脚本来进行接口的功能测试， 每个接口的用例单独维护在一个excel 里面，用例都是直接写在excel 里面（突然发现每个公司的用例管理平台都有点卡，有点不好用~~O(∩_∩)O~ ） ，写完后回归 的时候直接跑这些用例就可以了，这个项目的回归基本不用做了~~

​

     然后就是接口测试，手工测试方式有几种，第一 ，基于公司的协议框架，每个工程的启动的时候，都可以启动一个网页版的接口测试界面，自动去加载这个工程的代码的sdk包识别出来接口的每个方法，输入接口参数去调用就可以了； 第二种方法就是用jemeter 来测试接口，这个jemeter的插件是我组的一个测试大神弄出来的，然后被我组的开发老大挖去做资深开发去了，然后就轮到大家要测试他写的需求了~~O(∩_∩)O ~~说好的一起吐槽开发呢~~jemeter 插件 网上也有很多介绍，例如：https://www.cnblogs.com/yulia/p/6825027.html 这个 ；也看过这个大神写的插件源码，好像代码量不大，现在都想研究下也找不到源码了~~囧~~~ ，用jemeter来测试接口主要是方便平常有些调试，排查问题免不了要手工去调用，这需要在jemeter 目录的lib文件里面把工程的sdk包放进去，每个人本地都有一个jemeter，自己想放什么版本都可以，不会互相冲突， 然后上线的时候， 我们需要通过跳板机去 验收接口 ，也是可以通过jemeter去调用 ；做接口性能测试的时候也会有用到jemeter ,不过需要另外写脚本 ； 之前工程代码还是php的时候，是http的接口，也用过postman ,soapUI 来测试，公司也有测试接口的平台，但是一般都不怎么用公司的平台，也不知道为啥之前，，可能觉得不好用~~哈哈哈~后来公司的接口测试平台也没人维护了，然后之前做接口平台的人专门来搞一个自动化框架了，算是做的比较完善了，然后之后我们的接口测试一直都是在框架中来做了 ~~   

     
      第三 :上线 ，回归完成之后，周三会上预发布，预发布产品，测试，开发都会去验收， 接口的验收可以通过跳板机连接线上服务器ip来验收，上线是灰度发布的过程，一般发布第一批的时候测试会去看日志， 日志里面有没有报错信息这些， 看监控，订单呀，购物车的流量有没有下跌呀这些类似~~一般发现有问题几分钟内无法排查的必须马上把代码回滚了~~这些好像区别不大~~

​

       然后来聊聊日常的接口自动化测试~~ 在前公司三年，做了三年的接口测试，业务驱动，需求很多，商品，购物车，订单，总是有做不完的需求，并且属于比较核心的域，容易出问题，很多时候，出故障往往是底层接口比较多 ，界面上一般不会有太大的问题 ； 从接口底层开始测试其实也可以避免在界面测试的时候遇到的一些奇奇怪怪的问题；以前做的接口自动化测试也分了几个阶段：

      1、端到端测试 ： 从一开始，基于php写的代码的接口或者一开始java工程 的接口， 我们都是自己搭的框架，就简单的testng+jsonAssert  来做， jsonAssert 这个jar包也是挺好用的，可以对json 进行宽松匹配，严谨匹配 ，有序无序匹配等， 然后我们会把接口的入参，预期出参整一个json 都放到excel里面， 预期的数据库的表其实也可以转成一个json串 填到excel里一列，脚本里面 把数据库表的值读出来和excel校验就可以了，也可以使用mybatis 来写数据库语句， 但是好像之前都不怎么用mybatis ； 写表这块对于接口测试 比较重要，所以之前的用例基本涉及到读表或者写表的都会有相关的校验点 ；或者把接口的返回字段和数据库表的字段进行对比 ；做的比较多的校验是返回结果和写表读表 ，  后来不直接读表读es了，就通过mock ES 的返回来做了，但是es 的数据库源其实还是来源于我们自己的表 ，redise 用的是 jedis-2.9.0.jar 包的一些方法 ,  缓存读取用的是Memcache 的XMemcached 客户端读取的（see:https://blog.csdn.net/heiyueya/article/details/64441901?utm_source=blogxgwz9）

           当时自己是在下单组，下单这个工程比较特殊，它里面的接口 竟然没有一个是要写表的，都是读取的外部接口，例如掉商品的，价格系统的，活动的，钱包的，订单的，反正它就是不写表， 当时 做端到端测试都是直接造好了商品数据，活动数据这些，然后自动化的数据都是用这些维护好的数据，然后直接在公司的唯一一套回归环境来跑，数据库全公司各个系统的人都可以看到，这样就会导致数据经常会被改，即使标注了不能改~~ 做端到端的自动化比较简单，因为数据都是造好的，写起来比较省事，有一个好处是在回归的时候跑的时候能够发现其他系统的问题，但是不好的地方是维护起来不方便，老是要维护数据，不稳定~~

​

       2、然后就有了用线上数据的方案 ，刚好是因为这个工程比较特殊，不用读表写表， 开发做了一个从线上捞日志的平台，批量把每一次接口的请求入参和出参 ，还有接口调用外部接口的传参和外部接口的返回都拿到 ，然后按接口维度护放到csv文件，这个日志平台也可以根据不同的条件，例如各种不同活动类型，不同商品数据等，做这个平台其实开发当初的初衷只是为了方便排查线上问题 ；  然后后来主要的功能就是用来捞日志导出csv 文件来做自动化了， 一次一般可以导出 几千条请求，这些请求免不了有重复的 ， 我们拿到日志的接口入参作为自动化case 的入参，拿到 接口的出参作为预期返回 ；拿到这次请求调用的外部接口 返回的json串 作为mock 的返回数据，  每一次请求都有一个唯一的traceId 标识 ，这样就完成了一次完整的请求 （前提是这个接口不用读表，有缓存，队列那些）。因为我们的脚本都是写好的了，只要业务逻辑不变，case一般都没有多大问题，每个接口都可以导出几千条请求，刚好可以用来做回归测试，没有了造数据的麻烦 ，也没有了数据 被改的困扰 ；  不过缺点是 ：适用不用读表的工程，读表的因为没有测试环境的数据库和线上的不一样， 比较难做到同步，  还有其实用线上捞数据应该要脱敏的，当时没有去做~~

 这个方案的一个大概的流程图是这样的：

​

         3、本地启动服务测试， 其实这个方案就是目前还在用的方案， 用了公司平台组的一个比较完善的自动化框架（据说准备开源~~），支持UI 自动化，接口自动化等 ，支持多种协议，其实每个组还是要搭建自己的工程目录，然后导入框架的一些jar包 用到里面的一些公共方法 ， 其实我所在的组也算是这个框架的最开始的用户，他们给与了很多的技术上的支持，无条件支持业务组的需求~~~O(∩_∩)O哈哈~  ， 这个自动化方案有点类似开发做单测，但是不用在开发的代码里面来做测试， 将工程的代码打service的jar  包，然后在本地pc机器启动工程的服务 （这样不用将部署到linux机器上）,  然后debug的时候导入源码包就可以以直接本地debug了，写自动化脚本遇到问题debug十分方便， 也不用远程连接到linux机器 ，  然后例如buy工程需要调用 活动系统的接口，我们会将活动系统的接口mock掉 ，配置中心也是直接mock掉的， 这些服务的启动是框架实现的，不过用起来还是需要每个组自己配置，这里就不展开了 ；  

             由于之前php 转java 测试后，好多工程几百个接口场景都没有做自动化，然后我们都是把开发的代码拉下来，一个接口一个接口去看代码的实现逻辑，要调用的哪些外部接口，每种场景需要mock 什么数据，这个接口读了什么表，写了什么表，基本上一个接口写下来，对业务也是很了解了，当时是一边做需求，一边抽空把之前重构后的每一个接口涉及到的场景都用自动化去实现了，不用特地去整理用例，写的时候看代码的过程就知道要设计哪些场景了，毕竟关于接口的业务文档其实很多都是没有的，代码就是最接近线上的真实业务的体现 ，当我们把组内涉及到的每个接口涉及到的场景都用脚本写完了之后，大概用了三个月左右的时间， 6个工程大概 5000个左右的case，  这样给后续的接口测试带来了很大的方便，当有涉及到接口优化的时候，直接跑之前已经写好的case就可以了；或者需求有改动的时候，其实只需要在接口上加场景就可以了， 效率会有一定的提升 ； 这种方式的好处就是 把外部接口的返回都mock了，不用担心数据被改，服务返回不稳定导致case 出错， 还是可以发现一些问题 ；不好的地方就是因为调外部接口都是mock调的，有时候调用外部接口传参传少了如果不去校验其实不好发现，（这个其实可以通过Mockito的包里面有个ArgumentCaptor 方法可以捕获 入参，see:  https://yanbin.blog/mockito-capture-method-paramters/#more-7737）不方便联联调 。但是因为我们是底层，只要我们确认我们的字段返回符合需求，一般不会有太大的问题。

​

          4、之后想要做到接口精准测试 ，目前还没怎么开始做，有一个大概的方案，可以写一个接口去读取开发 每个分支和另外一个分支，例如master的不同点 ,其实就是我们平常用的git diff 命令，但是可以写代码导入git 的jar包来实现（org.eclipse.jgit-4.10.0.201712302008-r.jar ， <groupId>org.eclipse.jgit</groupId>，<artifactId>org.eclipse.jgit</artifactId>） ，里面 的类 org.eclipse.jgit.api.Git 下面 的多个方法 就是平常用的git 命令的一些方法，  将拿到的git diff 的信息保存下来，每一个改动点都追溯到上一层调用方法， 直到最上一层方法不被其他方法调用 ； 拿到的涉及到改动的所有接口 和方法，自动去匹配触发调用我们已经写好的接口自动化用例 ，这样可以用来开发的冒烟，  我们可以根据程序识别出来的开发改动到的接口和方法，有针对性的去测试，也能预防开发改动到公共方法 的时候，有接口是漏掉要测试的~~

        接口测试还有很多可以做好的地方，目前我也是处于一知半解，只是把之前做过东西大概写一下，可能写的有不对的地方，欢迎指出一起讨论啦~~~~

        文字好像有点多 ~~endning~~~~~

         ​