前言
之前在小公司呆了一年半，搭建了 Python 的接口自动化框架，纯代码实现虽说不算简单，但自由度更好，能够更好的调试和添加功能。
之后来到国内某大公司的软件测试工作（外包），到现在也呆了一年半多，公司使用的是零代码关键字驱动的接口自动化测试平台，有点类似于这个平台。写了 30+ 用例，有一些自己的感想，故分享出来
无法转化为自身价值
就算把平台使用得再好，出去了就没有了这样的平台，所有的经验就都失效
公司强调线上作业，在这样的一个前提下，测试人员被迫学习这个接口测试自动化平台的使用。
比较离谱的是，明明市面上有比较好的 JSONPath 定位方式，但平台依然基于 JSONPath 定义了自己的一套语法，这意味着我需要学习它的语法，真的无语。明明看它生成的 Java 代码最后都是使用的 JSONPath。
用户体验不好
感觉就是平台开发者并不清楚用户 (测试人员) 实际的使用场景。当然，我们测试人员编写测试点时，也经常考虑不到用户那么多复杂业务场景。
很多功能操作后的默认状态，和心理预期不符。例如
- 点击『一键调试』之后，编写自动化用例的界面就被覆盖了，需要点击『取消全屏』才能同时看到用例编写界面和调试运行页面。既然是调试，那我一般是对用例执行情况不确定才点的，我希望看到：是否有出错？出错在哪里？能快速定位到脚本位置。
- 调试失败时，JSON 文本过长被隐藏，需要下载压缩包，找到对应文件名才能查看完整的文本。太麻烦了，为什么不直接给这个 JSON 文件的下载链接呢？。出现问题 debug，还得下载压缩包，解压压缩包，比对文件名，找到对应 JSON 文件，太心累了。
- 调试速度极其慢。因为是零代码，每次调试都得将脚本转义成代码，并编译。如果编译报错/执行出错，就需要调整后再次执行。编译的时间又很慢，不断地编写自动化脚本、编译调试、修改脚本、编译调试，浪费了大量的等待时间。Postman 可以断点执行，执行不通过只需要修改后重新执行这一个接口就可以了。
只能用 Java 编写脚本
我用 Python 比较多，也熟悉一点 Java，但真不想写 Java
平台是 Java 实现的，因此『自定义代码』节点只能使用 Java 编写，不支持其他语言。有很多数据准备/数据处理操作是必须要编写『自定义代码』才能完成
- Java 的语法就比较严格，对于不熟悉的人来说，容易忘掉末尾的 “;” 双引号，每次新增变量都得进行类型定义。
- 又或者使用到了 Java 中的一些数据结构，需要进行额外的学习才能编写出可用的代码。
- 最可恶的是，『自定义代码』中无法像编译器中一样，给出代码是否有问题的提醒。这意味着只能在运行时，才能报出编译错误。这对于不熟悉 Java 语言的人来说，太容易发生了。
后记
团队内的接口自动化效果很差。发现的 bug 少，都没有起到最基础的辅助的作用。更像是领导 PPT 上的一项 KPI，只论数量，不论质量。好在领导也清楚 UI 自动化更为鸡肋，没有让我们推行。
正如前辈们所说，接口自动化更看重的是自动化用例的设计能力，而非平台能力。平台底层无非就是数据准备、响应断言、数据提取、线上管理、报告生成，并不能当做护城河。业务千千万，如何把业务高效落实到接口自动化上，才比较值得关注。
所以，不再迷信所谓的自动化平台，Testhome 上也不建议大家分享轮子，用户体验都做不好的情况下，没人用呀，还不如用 postman 方便。累计到 5000、6000 条用例时，维护真的麻烦。
我们的自动化用例更偏向于场景级，是多个接口之间组合调用，而不是单个接口的入参校验。因此会写用例会稍微麻烦一点。
在人力不足、缺少维护的情况下，自动化只能是领导们的 KPI。面试时也许还可以说道说道。
我们现在就是用的低代码平台，其实也就是对接口请求以及一些校验的封装，感觉使用时重点在对业务流程的理解，减少了代码能力要求，但是使用起来由于封装并不方便，优点还是自动化测试那一套可复用什么的，相较于手写自动化那一套除了对使用人员的要求降低以外，实际也感觉不到什么优点
自己的代码能力还得自己找时间找项目保持
首先，我不看好各种 xx 测试平台；其次，一边说 “无法转化为自身价值”，一边吐槽 “需要进行额外的学习才能编写出可用的代码”，似乎有点双标……
单反公司这个平台的代码开源给到你，你就不会说不好用了
槽神
回复
这里不冲突吧？
- "无法转化为自身价值” 吐槽的是类似 “基于 JSONPath 定义了自己的一套语法"的行为。
- "需要进行额外的学习才能编写出可用的代码" 吐槽的是低成本的事用高成本的方式实现。
两件事用一个形象类比的话，
就是 挤奶工一般都是先用大拇指和食指合拢卡住乳头基部, 堵住奶头腔与乳池间的孔, 以防乳汁回流。然后轻巧而有力的依次将中指、无名指、小指向手心收压, 促使乳汁排出。
现在管理改了这套动作，你每次挤奶时需要先用上工厂自研发的堵奶夹，然后双手挤压，全世界就你这家工厂有这个夹，导致我后期总结的经验无用。还有，你这堵奶夹无法适配所有奶牛，导致我每次得去根据每头牛的奶大小去调节和优化，就这成本很高
我个人觉得吐槽得还挺实际的，这是有实际用过平台的人
测试平台有测试平台的好处，只是你们的测试平台需要优化改进的地方很多。纯代码的自动化测试到最终的出口基本也是会集成为一个测试平台进行低代码运行，原因是纯代码他人使用成本高且无法公用协作，作为公司层面去想肯定会更认可一个好的测试平台或工具，特别是能统一管理和高覆盖 才是最终目标
一直无法理解为什么默认测试没有代码能力，各种给测试用的低代码平台和测平台本质上就是 kpi 产物，你看下面描述的：
1、点击『一键调试』之后，编写自动化用例的界面就被覆盖了，需要点击『取消全屏』才能同时看到用例编写界面和调试运行页面。既然是调试，那我一般是对用例执行情况不确定才点的，我希望看到：是否有出错？出错在哪里？能快速定位到脚本位置。
2、调试失败时，JSON 文本过长被隐藏，需要下载压缩包，找到对应文件名才能查看完整的文本。太麻烦了，为什么不直接给这个 JSON 文件的下载链接呢？。出现问题 debug，还得下载压缩包，解压压缩包，比对文件名，找到对应 JSON 文件，太心累了。
这两个是给人用的功能吗？
l98
回复
低代码使用成本确实降低了，可以让更多人参与到编写自动化用例中。
但是，断点调试、检查点智能设置、响应智能提取 这些能提高编写效率的功能都不具备，编写一条自动化用例还是很麻烦（特别是业务复杂，几十个参数传递时，找参数很麻烦）
以前是怎么用，在低代码平台上，还是同样的操作步骤，并没有很大改善（就感觉测试人员的难受之处，工具开发人员并没有体会到）
小人物
回复
是的。工具是专门一个部门开发，其他几个部门强制使用。领导有一些 KPI 覆盖率的要求
另外，领导提的需求，都得 3～4 个月实装，我们这些底层测试人员提的优化需求，大多数都否决或者排期很晚。匿名打差评都会找到你私聊。
可能商业工具更在乎用户体验？现在对这些内部工具的易用性不敢恭维
38.33
回复
没办法，只能说工具有好的有拉跨的 那得看公司选择了 你可以去想办法二次开发，也是一种提升 所有的自动化测试基本最终都会是集成为一个平台 你也可以把你的纯代码的封装成一个测试平台 如果比公司的好用也是一大成就
好像就叫 apitest，体验太差了，一个用例编辑就能有四层页面深度，实际用起来还是点得发昏，还好跑了
测试框架 + jupyter，直接在 ide 上写，jupyter 上跑完事，产品研发测试都可用
私以为测试平台的核心价值是 “数据度量”，而不是一个 web 版的 postman。
我认为不管你现在用纯代码也好，用配置文件也好，如果一直可以坚持用下去，那么最终会成为一个平台，放在业务开发上来说，很多细分领域的低代码平台已然很成熟, 大到金蝶云低代码， 小到那些拖拉拽的小应用。而对于测试层面来讲其实底层组件非常适合固化，例如一个步骤执行大概可以分为： 前置动作 - 步骤执行 - 后置动作， 抽象出中间的步骤，具体实现拿出来例如 http/mqtt/ws/modbus 等等。固化后的组装，数据传递则组成了一个场景用例，我认为这是一个非常适合平台化的场景，至于好用不好用，这些都是设计问题都是可以迭代之后改的，没有一个工具从出生就是非常好用的。
另外一个方面接口测试等自动化测试其实在现实的开发测试场景中占的比重并不是特别大，且如果作为一个能力孤岛也无法发挥出其重要作用，这就需要有效能度量，三方对接，采集监控，覆盖率采集，任务调度等等互相依托才可以发挥最大的作用。
举一个实际的例子：
一个公司使用 pytest allure 做自动化测试，那么他要解决以下问题：
- 使用者人人都熟练 git 的基本操作（即使封装成配置文件执行，也避免不了提交代码）
- 使用者人人都本地部署一套环境，且大部分的人需要会写 python（暂时不考虑代码质量）
- 假设使用 jenkins 做 ci，那么生成的 allure 报告需要支持一键重试。 3.1 当你写的用例多切覆盖到业务组比较多的时间，大家仅仅会重试自己的用例，也要支持动态筛选。 3.2 当你的脚本有误的时候，你需要重新提交代码，并且支持手动触发异常用例重试。
- 如果你的用例很多，你要支持并发执行用例且要支持 allure 报告合并。
- 你需要将结果落盘，分析数据/趋势。
可以发现这几个基础的问题有很多都涉及到持久化数据，以及代码能力。持久化数据之后最简单的写个页面展示， 代码能力方面，由于自动化测试的代码一直都在变，谁能保证自动化代码没有异常，而平台核心驱动代码可以一直不变，变得是用例配置，可以理解为用用例的配置去测试了平台核心驱动的代码，当用例越多那么平台就越可靠，不会出现使用产品来测试脚本的尴尬情况。
且当然以上这些基本的问题仅出于仅仅是测试这个角色在用的情况下，当一个用例作为监控/待办工具下，其他的角色（产品经理/研发）都会遇到更多的问题， 综上不管怎么样 拥有一个大家可以访问的页面是肯定的事情，至于平不平台，就要看这个东西大家的依赖程度，依赖越深，迭代越多，你这页面越复杂，慢慢也就成了一个平台。
ps: 附上我司的自动化测试
有没有可能是因为现在市面上滥竽充数的平台太多了，才导致平台无用论。有没有可能低代码平台能兼容代码的优点和管理不足，成本高的缺点
Ayo
回复
我有一点自己的拙见，这里面是存在俩个问题导致觉得使用困难
1.大部分使用低代码平台的同学是没有自己二开的权限和能力的，即便自己发现了问题可能也无法解决
2.低代码平台是直接拿的开源的或者是商业的，无法及时响应应用到自己公司项目的使用问题
sir
回复
在我们公司只要你做的事情对公司有价值，额外抽调一些开发人力去偶尔支持一下也是可以的，一般的测试平台不算是一个非常复杂的系统可能一小会就可以解决。如果公司连这点人力都不肯出那说明这种平台在咱们公司也没啥存在的必要。
我个人是觉得脚本都写的 6 的，无非是工程化差了点，所用的一些库有些区别，其他都是大差不差的，在现有整体平台搭建起来的情况下 改改 bug 应该没有什么问题。
另外我觉得对于个人而言，如果一直抱着使用者这种思路去工作，没有对工具的好奇心，可能最终也只会用工具了。