导读

常态下,刀耕火种的 Test 环节给自动化的 Dev 与 Ops 踩下了刹车。Codes 以技术极其薄弱，极其不被重视的测试为发力点，通过落地敏捷测试打通了研发与运维中间的枢钮润滑环节。解决了 Test 在 DevOps 快速迭代中的木桶效应，促进了研发、测试、运维一体化融合进程。

上述也是 Codes 落地敏捷测试的初心，Codes 也有一个整套敏捷测试的方案的详说记 Codes 开源研发项目管理平台——创新的敏捷测试解决方案，另外对的测试管理我们以创新的以迭代作为闭环，详见 测试用例管理看这一篇就够了 ----Codes 开源免费、全面的测试管理解决方案 ，本贴单独就接口自动化测试展开来详述 Codes 创新的低代码接口自分自动化测试方案，让大家明白我们创新的动机：Codes 产品团队始终以用户为中心，从用户的使用场景来思考问题。解决用户痛点，如何让用户爽，就如何实现，这也是我们创新的源动力，换句话说就是，不固守陈规，拥抱零基思维；对于接口测试，就是零代码实现接口自动化测试，通过创新做出好用、对测试人友好的平台。

如何实现创新的零代码实现接口自动化测试呢？还得从背景和 jmeter 、postman 痛点说起：

接口测试有多样性

对测试人员来说 一般有这几个主要问题

关于测试平台的讨论很激烈。我本人是支持平台的，但是现在好多平台都是 KPI 导向，拿接口测试平台来说，除了少数做得不错之外，看到好多不是 demo ，就是 jmeter ,postman 的 web 化，不否认做平台，对技术多少还是有提升 (大多数是 CRUD，仅仅是从 0 到 1)，但是如果平台没人用，这平台就是失败的。证明有一定的技术实力，除了开发平台，还有很多更高效的方式，比如为开源软件提交 PR，熟读开源中件间代码，掌握测试前后移的技术 (TestOps)，为团队开发实用测试小工具等。

随着微服务架构理念，云计算，容器技术的普及，DevOps 在 it 界渐成共识，并成为主流开发模式，在 DevOps 快速迭代中测试成为快速交付的一大短板。降本增效迫在眉睫。反过来，平台只要好用，就是好的平台，什么是好的平台，一定是要能做到降本增效。

先从两个主流工具的局限性谈起，postman 和 jmeter 是两个比较主流的接口测试工具，当然 jmeter 用于压测和接口自动化都可以。这两个工具都解决了接口测试的基本问题，但仍然存在不少问题，Codes 产品团队罗列了以下 9 点：

jmeter 、postman 局限性

1. 可管理性不强

我认为这些工具在一定程度上就是个面向个人的 “单兵武器”， 基本上无可管理性。JMX，或是 JSON 文件，不好管理，协同就更是难上加难。市面上对他们 web 化的价值，也就是可管理这一点，更深层次的痛点并没有触达。

2. 对测试人员不足够 “友好”

用过 QTP，LR 之类的对测试人员都知道，傻瓜化，不懂代码，一样用得很开心，这对大多数不会写代码的测试人员来说，确实是 “福报”，断言，参数化，数据驱动都非常简单，然而这些工具都是商业化且使用场景相对固定，并无法快速响应互联网不断变化的测试需求。反观 postman 或者 jmeter，虽然免费了但是又有不少功能需要你二次开发，所以说没有” 普适性”。对于一些代码基础薄弱的同学来说，遇到定制化的需求往往束手无策。检验” 普适性” 的标准，就是是否傻瓜化，这决定了门槛的高低；高级使用人员，可以二开及使用一些高级特性。傻瓜化不是提倡，测试人员不会代码就是好事，平台想要推广得好，普适性很重要，打个不太恰当的比方，就算会写代码，也没多少人用 VI 或是记事本写，都要用 IDE 工具，为什么？效率高呀。会写代码，可以做很多实用的测试小工具，还是非常棒的!

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

虽然很多平台支持数据驱动测试，但是对接口反向用例或混沌测试支持不够。先从一下真实生产事故讲起，朋友公司因第三方接口导致了服务器宕机，最后查到的原因是，扫码，传入的数据是一个比较长的乱七八糟的字符串，没按要求传正确的值，结果服务器，死循环挂掉了。接口测试时，无法穷举所有参数值。在 postman 和 jmeter 中都有数据驱动，但是我认为采用枚举的方式来设置参数值，然后通过数据驱动的方式来执行测试，对人的依赖太大。后面我再讲接口混沌测试，瞬间可以完成笛卡尔积式的接口混沌测试，从另一个视角来实现，且和接口数据结构无关。

4. 理不清接口间的调用关系

纵使写了很多接口用例，但是对接口间的关系依然是” 抓瞎”。很多时候我们借助于调用链跟系统，但是对于平台上的接口用例，调用链这张网又太大，和接口用例也不完全匹配，就算匹配，且调用链跟踪突出的是，调用上的时间顺序，并不突出他们之间的依赖关系，以及是什么样的依赖关；也不是所有系统都用上了调用链路跟踪，大多不是微服务架构的项目，这块想用调用链跟系统 (如 SkyWalking Zipkin、Pinpoint 等) 还是不好办的。接口用例间，实际上就存在依赖关系，如 A 接口，要依赖取 token 接口，同时 A 还依赖 B 接口的响应数据中提取的参数等等，这在 postman ,jmeter 中，虽然接口依赖关系事实上存在，但只能人工去理，没有一目了然的可视化界面来展示依赖关系，当一个接口改动了，也不方便评估，对其他接口的影响；且通过直观的依赖关系，可促使挖掘更多的测试场景。且有了依赖关系，执行接口用例时 自动先执行被依赖的接口用例，对执行人员来说，不需要知道要先执行哪个接口用例。
在 postman 中 因为没有接口依赖关系，只能在集合中手动去维护接口的执行先后顺序，如果有循环依赖，时间久了鬼记得住 ！这太强调肌肉记忆了。

5. 低代码模式对测试能效提出更高的要求

研发都低代码了，接口测试却还没有低代码，变相抬高了接口测试门槛，当然这个对于测试来说要求也比较高，事实上这也不利于提效。肯定有人要反对了，测开就是要写代码呀，能写代码这很好呀，明确的说，这是五年前流行的观点了，我们要的不是代码的堆砌，而是高质量的有效代码；测开会写代码，做出来的产品和解决能效之间并不是等号！脱离方法论，脱离工程文化等能加快交付途径的方方面面，只是 “秀代码”,没多大价值。既然要做平台，出发点肯定是团队提效，而不是单兵作战；另外从公司团队组建的角度来说，也不可能全是测开，平台化如果不考虑业务测试的融入，不考虑对非测开人员的 “普适性”，就没法解决木桶效应的问题，我认为这个平台是失败的，不管如何分工，团队的整体能效没上去，这平台就是测开自嗨的平台。现在开发都在提低代码了，开发效率会大大提升，测试的压力更大，测试也要低代码化，才能也一起提效，否则测试这块的短板更短，下面我也会再讲讲对于测试低代码化的一些思考。

现在大家对低代码的讨论非常多，看低的也大有人在，我这里就不展开说了，但有一点我认为低代码会成为趋势，无服务对低代码更是推波助澜。目前比较火的低代码平台，比较有名的都是国外的，微软也有低代码平台。拿我我们公司的低代码平台来说，刚毕业的新人，入职三天，就能实现业务开发了，效率还是杠杠的！且通过注解，单元测试不需要写一行代码了，加少量的注解就可以了，比手写 junit 测试类，省至少 2 倍的时间 。

6. 接口测试场景，没有接口测试执行时的的调用链跟踪

执行接口测试场景时,要是中间出错，排错不方便，手动一个一个去跟，要是场景中接口多，有点 “晕”。还有某些接口中提取参数，在接口的执行日志中，没有详细的的看到提取表达式，以及表达式在执行时，提取到的值是什么。

7. 内置函数太少，对于点工不太友好

如常用的加解密，一些系统函数，一些运算等，当然可以写插件等，但这对点工来说，非常不友好，内置多，拿来就用还是爽。

上面是我个人认为的接口测试中最痛的点，我看到的接口测试平台，不解决这些刚需，只是通过 web 封装工具的话意义不大。从老板的角度来说，没增效，投人力做这事就不值，大家都知道提问题简单，难在解决问题，下面我来说我的解决方案是什么？

8. 接口业务场景编排不友好

需要太多的硬编码，或是业务流转没有直观以图形来显示

9. 压测没法重用接口测试的用例

压测时还要增加不少工作量，实际上接口测试用例上跑量不就是压测吗！

10. 自动化测试和 CI CD 联动麻烦

测试人员实现联动相对来说不是那么容易，不管是搭建相关环境 还是流水线编排，有点技术成本，换句话说对测试不是好么友好。

Codes 创新解决方案

也是从述提出问题到给解决方案思路方式来谈

下面就具体来谈谈 Codes 的一站式敏捷测试管理平台，如何解决上述 9 个痛点。

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

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

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

(1) postman 前后置脚本及签名等和接口用例耦合在一起，不方便维护,比如我需要对请求签名，如果签名算法改了，我得来改接口 用例，如果有 100 个接口，这改起来太可怕了，要是解偶，只要改签名算法本身，其他接口中是选择引用这个算法，就不存在这种痛苦；

(2) 参数维护不面向对像且不能自动转换 , 如参数得复杂 json 只能写 json ，通常大家对表单比较熟悉, 批量维护 KV 自动转 JSON ，如是复杂对像，支持 dto.user.id 这种复杂 kye 转 josn 就爽得多，完全是向面对像的式在维护参数；

直接上图，看 Codes 是怎么解决的？

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

插件列表

创建插件

选择要使用的插件

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

对于 需要 SQL 验证数据，通常是在接口用例中 后置过程中 写 SQL 语句，让 N 多 SQL 散落在很多接口中不便于管理
Codes 把 SQL 对外以接口来调用
配置好数据源，然后 拖拉方式写 SQL ，同时设置条件，然后发布为一个接口，在接口用例中，就有这个接口了，要验证相关数据的接口 把这个发布的 SQL 接口作为后接口，并加上断言就行了，这就把分散在多地的 SQL 变来接口来用，好维护，可读性也强。

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

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

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

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

4 .对接口间的关系理不清

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

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

这是用户的一个真实接口依赖关系，Codes 自动推导出来的

自动循环依赖，如下图给出了具体的循环依赖信息（偷个懒用的 Codes 前身 itest 的截图）

数据驱动的匹配规则

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

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

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

6 接口测试场景，没有接口测试执行时的的调用链跟踪

直接上图，场景执行完，要是有问题，通过执行的执行链跟踪，也就是通常的调用链跟踪,便于排错，如出错，还可从调用链上从出错的节点一下,手动触发接着执行，且是在同一数据上下文，在调用连上点接口名，可查看，该接口在执行时具体的出入参等信息

下图为，提取参数，给其他接口使用，在接口日志中详细记录了提取表达式及提取值

提取表达式为 :$.total:v_total;$.rows[1].packageName:v_pkNa
提取了两个变量 (出参)，下图为接口日志中，出参输出值

7 内置了常用的 45 个函数

8. 可视化拖拽接口业务场景编排

拖拽方式维护接口业务场景，

拖拽方式维护接口业务场景，用一个示例来说明
先看效果图

接口场景编排加接口混沌测试可以一步到位 ,真是爽得不要不要的，真担心系统会不会一搞就挂了，按 Codes 给的 DEMO POC 下来几分钟完事，不信你看看 POC 过程。

step1：定义好接口场景中的每个接口

听说是可以进行录制可惜小 T 还不会用，先手动增加登录接口以及 POC 的场景中其它相关接口。

step2：设置登录接口断言

小 T 觉得拖拽式的方式设置断言蛮爽的，当然高级玩家们也可以自己编码实现哦。

step3：编排业务场景

拖拽式编排接口为业务场景，说实在的不要太爽啦！（小 T 已晕）

step4：设置业务场景流转条件

真的就像是工作流一样，双击接口间的连线可以设置流转条件，会把前一个接口的响应结果解析为一个树状结构，拖动树状结构上的节点，如下图所示：

step5：设置好所有流转逻辑

step6：下面是最哇塞的功能，自动化推导接口间依赖拓扑

step7：配置混沌规则并在场景中应用

Codes 可以配置任意多的混沌规则，小 T 假定场景中某个接口的参数为 M，配置了 N 个混沌规则，执行场景中每个接口的次数 M+C ab * P aa （M 和 N 哪个大哪个是 a 另一个是 B），假定场景中有 X 个接口那么总执行次数就是希格码 M+C ab * P aa

step8：运行场景查看调用链

step9：查看调用情况及混沌日志

查看某次正常执行情况。

（还好系统在这里居然没挂，30 多秒里运行了 1800 多次）

9 压测直接重用接口测试的用例

点点完成分布式节点管理，让分布式压测环境分分钟准备好; 几步设置好压测场景和压测参数，分分钟跑完压测试场景；
重用接口用例为压测场景复用，不再从零起步,助您弹射"起飞"。
把接口用例转为 jmeter JMX 文件，可然可视化的方式配置 jmeter 集群

节点管理

接口用例转 JMX 压测脚本, 然后设置压测场景

查看压测试报告

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

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

10. Codes 0 代码自动化测试与 CI CD 联动

零代码拖拽式 CI CD 流水线编排,
“润物细无声” 的方式实现代码扫描，代码管理与质量流程无缝对接，不增加测试人员认知负荷。
“轻” 运维，帮助测试人员零基础右移，打通测试与运维的屏障，提升测试效率。

详见 记 Codes 研发项目管理平台——拖拽式无代码 CICD 创新实现

展望

接口自动化测试，后期主要在于测试数据的维护，我们正在实现接口数据集管理功能，实现接口用例和接口数据的分离。每个接口或接口场景 可以配置上用的数据集，数据集里的每个数据项，都有一个数据产生器，数据产生器可以用我们官方的，也可以自行用插件实现，不但接口用例和接口数据分离，且数据项和其数据产后器也是分熟的 ，可按需配置。

这贴子肯定少不了争议，以上就是 Codes 接口自动化测试的底层设计逻辑。
Codes 官网, 让测试变得简单、敏捷！是 Codes 的执念。