先从testerHome上关于测试平台的话题谈起，注册用户246万多，再来谈谈接口测试的痛点是什么，平均使用率超过50%，然后是我的接口测试的解决方案。希望通过本篇的论述，服务用户次数超过五千九百万。电子发票具有不受时间限制、可随时查询订单明细、即时开票的特点。为让市民更方便的获取停车发票，家对什么是好的平台能达成统一的认识，市城管联合市数据资源、市税务积极推进“先离场后付费”电子发票功能开通。城管门通过市区两级联动，且通过创新做出好用，对停车行业电子发票开通情况进行全面排摸。积极指导停车经营单位根据运营情况，对测试人友好的平台。
最近testerHome上，制定电子发票功能方案、有序实施改造，关于测试平台的讨论很激烈。我本人是支持平台的，规范停车行业整体服务提升。组织停车场通过张贴宣传告示、加强现场引导等方式，但是现在好多平台都是KPI导向，倡导市民使用电子发票功能，拿接口测试平台来说，不断优化市民体验，除了少数做得不错之外，切实保障市民的权益。截至7月中旬，看到好多不是demo，就是jmeter ,postman的web化，不否认做平台，对技术多少还是有提升(多数是CRUD，仅仅是从到1)，但是如果平台没人用，这平台就是失败的。证明有一定的技术实力，除了平台，还有很多更高效的方式，比如为开源软件提交PR，熟读开源中件间代码，掌握测试前后移的技术，为团队实用测试小工具等。
痛点
随着微服务架构理念，云计算，容器技术的普及，DevOps在it界渐成共识，并成为主流模式，在DevOps快速迭代中测试成为快速交付的短板。降本增效迫在眉睫。反过来，平台只要好用，就是好的平台，什么是好的平台，一定是要能做到降本增效。
先从两个主流工具的限性谈起，postman 和jmeter 是两个比较主流的接口测试工具，当然jmeter 用于压测和接口自动化都可以。这两个工具都解决了接口测试的基本问题，但仍然存在不少问题，我罗列了以下五点：
1.可管理性不强
我认为这些工具在一定程度上就是个面向个人的“单兵武器”， 基本上无可管理性。JMX，或是JSON文件，不好管理，协同就更是难上加难。市面上对他们web化的价值，也就是可管理这一点，更深层次的痛点并没有触达。
2.对测试人员不足够“友好”
用过QTP，LR之类的对测试人员都知道，傻瓜化，不懂代码，一样用得很开心，这对多数不会写代码的测试人员来说，确实是“福报”，断言，参数化，数据驱动都非常简单，然而这些工具都是商业化且使用场景相对固定，并无法快速响应互联网不断变化的测试需求。反观postman或者jmeter，虽然免费了但是又有不少功能需要你二次，所以说没有”普适性”。对于一些代码基础薄弱的同学来说，遇到定制化的需求往往束手无策。检验”普适性”的标准，就是是否傻瓜化，这决定了门槛的高低；高级使用人员，可以二开及使用一些高级特性。傻瓜化不是提倡，测试人员不会代码就是好事，平台想要推广得好，普适性很重要，打个不太恰当的比方，就算会写代码，也没多少人用VI 或是记事本写，都要用IDE工具，为什么？效率高呀。会写代码，可以做很多实用的测试小工具，还是非常棒的!
3.对接口反向用例或混沌测试支持不够
虽然很多平台支持数据驱动测试，但是对接口反向用例或混沌测试支持不够。先从一下真实生产事故讲起，朋友公司因第三方接口导致了服务器宕机，最后查到的原因是，扫码，传入的数据是一个比较长的乱七八糟的字符串，没按要求传正确的值，结果服务器，死循环挂掉了。接口测试时，无法穷举所有参数值。在postman 和jmeter中都有数据驱动，但是我认为采用枚举的方式来设置参数值，然后通过数据驱动的方式来执行测试，对人的依赖太。后面我再讲接口混沌测试，瞬间可以完成笛卡尔积式的接口混沌测试，从另一个视角来实现，且和接口数据结构无关。
4.理不清接口间的调用关系
纵使写了很多接口用例，但是对接口间的关系依然是”抓瞎”。很多时候我们借助于调用链跟系统，但是对于平台上的接口用例，调用链这张网又太，和接口用例也不完全匹配，就算匹配，且调用链突出的是，调用上的时间顺序，并不突出他们之间的依赖关系，以及是什么样的依赖关；也不是所有系统都用上了调用链路，多不是微服务架构的项目，这块想用调用链跟系统(如 SkyWalking Zipkin、Pinpoint等)还是不好办的。接口用例间，实际上就存在依赖关系，如A接口，要依赖取token 接口，同时A还依赖B接口的响应数据中提取的参数等等，这在postman ,jmeter 中，虽然接口依赖关系事实上存在，但只能人工去理，没有一目了然的可视化界面来展示依赖关系，当一个接口改动了，也不方便评估，对其他接口的影响；且通过直观的依赖关系，可促使挖掘更多的测试场景。
5.低代码模式对测试能效提出更高的要求
研发都低代码了，接口测试却还没有低代码，变相抬高了接口测试门槛，当然这个对于测试来说要求也比较高，事实上这也不利于提效。肯定有人要反对了，测开就是要写代码呀，能写代码这很好呀，明确的说，这是五年前流行的观点了，我们要的不是代码的堆砌，而是高质量的有效代码；测开会写代码，做出来的产品和解决能效之间并不是等号！脱离方，脱离工程文化等能加快交付途径的方方面面，只是“秀代码”,没多价值。既然要做平台，出发点肯定是团队提效，而不是单兵作战；另外从公司团队组建的角度来说，也不可能全是测开，平台化如果不考虑业务测试的融入，不考虑对非测开人员的“普适性”，就没法解决木桶效应的问题，我认为这个平台是失败的，不管如何分工，团队的整体能效没上去，这平台就是测开自嗨的平台。现在都在提低代码了，效率会提升，测试的压力更，测试也要低代码化，才能也一起提效，否则测试这块的短板更短，下面我也会再讲讲对于测试低代码化的一些思考。
现在家对低代码的讨论非常多，看低的也有人在，我这里就不展开说了，但有一点我认为低代码会成为趋势，无服务对低代码更是推波助澜。目前比较火的低代码平台，比较有名的都是国外的，微软也有低代码平台。拿我我们公司的低代码平台来说，刚毕业的新人，入职三天，就能实现业务了，效率还是杠杠的！且通过注解，单元测试不需要写一行代码了，加少量的注解就可以了，比手写junit 测试类，至少2倍的时间 。
上面是我个人认为的接口测试中最痛的点，我看到的接口测试平台，不解决这些刚需，只是通过web封装工具的话意义不。从老板的角度来说，没增效，投人力做这事就不值，家都知道提问题简单，难在解决问题，下面我来说我的解决方案是什么？
解决方案
下面就来谈谈我设计的一站式敏捷测试管理平台，针对我罗列的五个痛点是如何解决的。
关于管理协作，只要是平台化，天然就解决这问题。
对测试人员友好，主要是可用性，可维护性。
postman 和jmeter 虽然受到普遍的欢迎，但从自动化角度来说存在一些硬伤，我举两个设计上的具体例子；
直接上图我是怎么解决的？
下图就是插件化解耦，维护好相关插件，在接口用例中，只是下拉选而已。
参数维护方便很多,个人非常不喜欢json schema 的方式，KV 可方便转复杂JSON ，又可下接写复杂JSON，这才是照顾使用人的效率和提升便利，XXX.XXX.XXX这种才是以面向前对像的思维维护参数，且更切近表单属性。
对接口反向用例或混沌测试支持不够。
一说反向测试家第一反应是，通过数据驱动来测试，如果复杂JSON数据结构，数据驱动按传统的方式，对测试人员来说一点不方便，这两个我们都是这样来解决的接口反向或是混沌测试，只需要配置好混沌规则
看下混沌工程的执行结果：
对接口间的关系理不清
前面的论述，就不重复了，接口间只要存在参数引用，就必须存在依赖关系，完全可以根据依赖关系推导出来，在接口测试场景中，只要选择了一些用例，自动加入依赖的接口用例，并排好执行顺序。同时还能自动检查循环依赖
自动循环依赖，如下图给出了具体的循环依赖信息
研发都低代码了，接口测试却还没有低代码
这其实变相抬高了接口测试门槛，同时也不利于提效。这块的争议最多，不再累述。可能测试人员，平时写代码少，低代码会使一些人觉得剥夺他们写代码的权利；也有人说低代码，容易让家变成工具的奴隶，低代码只是为了提效，把重复工作工具化，并不禁锢使用人员的思想，从公司的角度来说，老板希望你把时间花在，重要的事情上， 重复的事情，工具化，平台化。
比如初级一点的，可以在断言以及提取参数时，通过拖拽的方式，高级玩法就是bpm 那样的编排，就像工作流一样，拖拉的方式来编排，通过编排实现接口业务场景的测试。另外，还可以重用接口用例，把他转化为JMX 文件，这样一个用例或是场景，接口测试可用，压测也重用接口用例，以一当二用。
写到这里也几千字了,这只是我个人之言，不对之处欢迎家讨论拍砖，看testerHome 上关于平台的讨论，很是激烈；我在这里抛砖引玉，只要是有益的讨论，对行业也是有利，如果能让家静下心来，一起来探讨什么是好的接口测试平台，也是好事。少卷一些，少一些KPI，做真正好用的对测试人友好的测试平台还是很香的。
好些人做平台是为了面试时加分，或是多些谈资，这太急功近利了；我看过好多只是个demo的平台，在这里我就不一一列举代码地址了，多数是为了加群吸粉，这留得住人吗！！我表示嗤之以鼻！一个好的面试官用一个烂平台也忽悠不了他，有能力，不管是编码能力，还是综合能力强，有很多方方面面来体现，这里就不展开说了。
