前言

之前在小公司呆了一年半，搭建了 Python 的接口自动化框架，纯代码实现虽说不算简单，但自由度更好，能够更好的调试和添加功能。

之后来到国内某大公司的软件测试工作（外包），到现在也呆了一年半多，公司使用的是零代码关键字驱动的接口自动化测试平台，有点类似于这个平台。写了 30+ 用例，有一些自己的感想，故分享出来

无法转化为自身价值

就算把平台使用得再好，出去了就没有了这样的平台，所有的经验就都失效

公司强调线上作业，在这样的一个前提下，测试人员被迫学习这个接口测试自动化平台的使用。

比较离谱的是，明明市面上有比较好的 JSONPath 定位方式，但平台依然基于 JSONPath 定义了自己的一套语法，这意味着我需要学习它的语法，真的无语。明明看它生成的 Java 代码最后都是使用的 JSONPath。

用户体验不好

感觉就是平台开发者并不清楚用户 (测试人员) 实际的使用场景。当然，我们测试人员编写测试点时，也经常考虑不到用户那么多复杂业务场景。

很多功能操作后的默认状态，和心理预期不符。例如

• 点击『一键调试』之后，编写自动化用例的界面就被覆盖了，需要点击『取消全屏』才能同时看到用例编写界面和调试运行页面。既然是调试，那我一般是对用例执行情况不确定才点的，我希望看到：是否有出错？出错在哪里？能快速定位到脚本位置。
• 调试失败时，JSON 文本过长被隐藏，需要下载压缩包，找到对应文件名才能查看完整的文本。太麻烦了，为什么不直接给这个 JSON 文件的下载链接呢？。出现问题 debug，还得下载压缩包，解压压缩包，比对文件名，找到对应 JSON 文件，太心累了。
• 调试速度极其慢。因为是零代码，每次调试都得将脚本转义成代码，并编译。如果编译报错/执行出错，就需要调整后再次执行。编译的时间又很慢，不断地编写自动化脚本、编译调试、修改脚本、编译调试，浪费了大量的等待时间。Postman 可以断点执行，执行不通过只需要修改后重新执行这一个接口就可以了。

只能用 Java 编写脚本

我用 Python 比较多，也熟悉一点 Java，但真不想写 Java

平台是 Java 实现的，因此『自定义代码』节点只能使用 Java 编写，不支持其他语言。有很多数据准备/数据处理操作是必须要编写『自定义代码』才能完成

1. Java 的语法就比较严格，对于不熟悉的人来说，容易忘掉末尾的 “;” 双引号，每次新增变量都得进行类型定义。
2. 又或者使用到了 Java 中的一些数据结构，需要进行额外的学习才能编写出可用的代码。
3. 最可恶的是，『自定义代码』中无法像编译器中一样，给出代码是否有问题的提醒。这意味着只能在运行时，才能报出编译错误。这对于不熟悉 Java 语言的人来说，太容易发生了。

后记

团队内的接口自动化效果很差。发现的 bug 少，都没有起到最基础的辅助的作用。更像是领导 PPT 上的一项 KPI，只论数量，不论质量。好在领导也清楚 UI 自动化更为鸡肋，没有让我们推行。

正如前辈们所说，接口自动化更看重的是自动化用例的设计能力，而非平台能力。平台底层无非就是数据准备、响应断言、数据提取、线上管理、报告生成，并不能当做护城河。业务千千万，如何把业务高效落实到接口自动化上，才比较值得关注。

所以，不再迷信所谓的自动化平台，Testhome 上也不建议大家分享轮子，用户体验都做不好的情况下，没人用呀，还不如用 postman 方便。累计到 5000、6000 条用例时，维护真的麻烦。

我们的自动化用例更偏向于场景级，是多个接口之间组合调用，而不是单个接口的入参校验。因此会写用例会稍微麻烦一点。

在人力不足、缺少维护的情况下，自动化只能是领导们的 KPI。面试时也许还可以说道说道。