测试架构师如何解读测试平台的各种争议

导读

      先从 TesterHome 上关于测试平台的话题谈起，再来谈谈接口测试的痛点是什么，然后是我的接口测试的解决方案。希望通过本篇的论述，大家对什么是好的平台能达成统一的认识，且通过创新做出好用，对测试人友好的平台。

      最近 TesterHome 上，关于测试平台的讨论很激烈。我本人是支持平台的，但是现在好多平台都是 KPI 导向，拿接口测试平台来说，除了少数做得不错之外，看到好多不是 demo ，就是 jmeter ,postman 的 web 化，不否认做平台，对技术多少还是有提升(大多数是 CRUD，仅仅是从 0 到 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 封装工具的话意义不大。从老板的角度来说，没增效，投人力做这事就不值，大家都知道提问题简单，难在解决问题，下面我来说我的解决方案是什么？

 解决方案

下面就来谈谈我设计的一站式敏捷测试管理平台，针对我罗列的五个痛点是如何解决的。

 1 关于管理协作，只要是平台化，天然就解决这问题。

2 对测试人员友好，主要是可用性，可维护性。

   postman 和 jmeter 虽然受到普遍的欢迎，但从自动化角度来说存在一些硬伤，我举两个设计上的具体例子:

        (1) postman 前后置脚本及签名等和接口用例耦合在一起，不方便维护,比如我需要对请求签名，如果签名算法改了，我得来改接口 用例，如果有 100 个接口，这改起来太可怕了，要是解偶，只要改签名算法本身，其他接口中是选择引用这个算法，就不存在这种痛苦；
      (2)参数维护不面向对像且不能自动转换 , 如参数得复杂 json 只能写 json ，通常大家对表单比较熟悉, 批量维护 KV 自动转 JSON ，如是复杂对像，支持 dto.user.id 这种复杂 kye 转 josn 就爽得多，完全是向面对像的式在维护参数；
 
      直接上图我是怎么解决的？

      下图就是插件化解耦，维护好相关插件，在接口用例中，只是下拉选而已。

       

 

 
          参数维护方便很多,个人非常不喜欢 json schema 的方式，KV 可方便转复杂 JSON ，又可下接写复杂 JSON，这才是照顾使用人的效率和提升便利，XXX.XXX.XXX 这种才是以面向前对像的思维维护参数，且更切近表单属性。
 

3 对接口反向用例或混沌测试支持不够。

一说反向测试大家第一反应是，通过数据驱动来测试，如果复杂 JSON 数据结构，数据驱动按传统的方式，对测试人员来说一点不方便，这两个我们都是这样来解决的接口反向或是混沌测试，只需要配置好混沌规则 ，然后以“撞库”的形式排列组合，替换掉正向接口用例中的参数值去执行撞库，瞬间完成接口健壮性测试“撞库时”先单个一个一个去换， 然后再排例组合。

 
看下混沌工程的执行结果：

     数据驱动，也是按面向对像的方式，方便复杂 JOSN 的结构，传统的数据驱动，只方便 KV 方式，复杂对像，表达起来费劲，我们依然采用 xxx.xx.xx 这种对像属性访问形式。依然采用 xxx.xx.xxx 这种对像属性访问形式，即支持简单 KV ，又能一行表示一个 json 对像，直观又易于理解



 4 对接口间的关系理不清

前面的论述，就不重复了，接口间只要存在参数引用，就必须存在依赖关系，完全可以根据依赖关系推导出来，在接口测试场景中，只要选择了一些用例，自动加入依赖的接口用例，并排好执行顺序。同时还能自动检查循环依赖。

不但可以查看依赖拓补，还可以在维护接口用例时，自动检查循环依赖，如检测到，给出提示

 

自动循环依赖，如下图给出了具体的循环依赖信息

 

5 研发都低代码了，接口测试却还没有低代码

   这其实变相抬高了接口测试门槛，同时也不利于提效。这块的争议最多，不再累述。可能测试人员，平时写代码少，低代码会使一些人觉得剥夺他们写代码的权利；也有人说低代码，容易让大家变成工具的奴隶，低代码只是为了提效，把重复工作工具化，并不禁锢使用人员的思想，从公司的角度来说，老板希望你把时间花在，重要的事情上， 重复的事情，工具化，平台化。

比如初级一点的，可以在断言以及提取参数时，通过拖拽的方式，高级玩法就是 bpm 那样的编排，就像工作流一样，拖拉的方式来编排，通过编排实现接口业务场景的测试。另外，还可以重用接口用例，把他转化为 JMX 文件，这样一个用例或是场景，接口测试可用，压测也重用接口用例，以一当二用。

 

        写到这里也几千字了,这只是我个人之言，不对之处欢迎大家讨论拍砖，看 TesterHome 上关于平台的讨论，很是激烈；我在这里抛砖引玉，只要是有益的讨论，对行业也是有利，如果能让大家静下心来，一起来探讨什么是好的接口测试平台，也是好事。少卷一些，少一些 KPI，做真正好用的对测试人友好的测试平台还是很香的。

好些人做平台是为了面试时加分，或是多些谈资，这太急功近利了；我看过好多只是个 demo 的平台，在这里我就不一一列举代码地址了，多数是为了加群吸粉，这留得住人吗！！我表示嗤之以鼻！一个好的面试官用一个烂平台也忽悠不了他，有能力，不管是编码能力，还是综合能力强，有很多方方面面来体现，这里就不展开说了。

这贴子肯定少不了争议，欢迎大家加入 TesterHome 反智讨论群，我也在群里方便大家来讨论，本人是开源免费的 www.itest.work ,一站式敏捷测试管理平台作者, 让测试变得简单、敏捷！是 itestwork 的执念。写这贴子，也是有感而发，我们一直在改进的路上，3 年了一直在维护中，上面的痛点，必须要全面解决；当前正在丰富压测模块及实现可视化接口编排 大家可以期待。

官网访问地址：www.itest.work