导读
先从 玩技博客 上关于测试平台的话题谈起，再来谈谈接口测试的痛点是什么，然后是我的接口测试的解决方案。希望通过本篇的论述，大家对什么是好的平台能达成统一的认识，且通过创新做出好用，对测试人友好的平台。
最近 玩技博客 上，关于测试平台的讨论很激烈。我本人是支持平台的，但是现在好多平台都是 KPI 导向，拿接口测试平台来说，除了少数做得不错之外，看到好多不是 demo ，就是 jmeter ,postman 的 web 化，不否认做平台，对技术多少还是有提升 (大多数是 CRUD，仅仅是从 0 到 1)，但是如果平台没人用，这平台就是失败的。证明有一定的技术实力，除了开发平台，还有很多更高效的方式，比如为开源软件提交 PR，熟读开源中件间代码，掌握测试前后移的技术 (TestOps)，为团队开发实用测试小工具等。文章源自玩技e族-https://www.playezu.com/185867.html
随着微服务架构理念，云计算，容器技术的普及，DevOps 在 it 界渐成共识，并成为主流开发模式，在 DevOps 快速迭代中测试成为快速交付的一大短板。降本增效迫在眉睫。反过来，平台只要好用，就是好的平台，什么是好的平台，一定是要能做到降本增效。文章源自玩技e族-https://www.playezu.com/185867.html
先从两个主流工具的局限性谈起，postman 和 jmeter 是两个比较主流的接口测试工具，当然 jmeter 用于压测和接口自动化都可以。这两个工具都解决了接口测试的基本问题，但仍然存在不少问题，我罗列了以下 7 点：文章源自玩技e族-https://www.playezu.com/185867.html
1. 可管理性不强
我认为这些工具在一定程度上就是个面向个人的 “单兵武器”， 基本上无可管理性。JMX，或是 JSON 文件，不好管理，协同就更是难上加难。市面上对他们 web 化的价值，也就是可管理这一点，更深层次的痛点并没有触达。文章源自玩技e族-https://www.playezu.com/185867.html
2. 对测试人员不足够 “友好”
用过 QTP，LR 之类的对测试人员都知道，傻瓜化，不懂代码，一样用得很开心，这对大多数不会写代码的测试人员来说，确实是 “福报”，断言，参数化，数据驱动都非常简单，然而这些工具都是商业化且使用场景相对固定，并无法快速响应互联网不断变化的测试需求。反观 postman 或者 jmeter，虽然免费了但是又有不少功能需要你二次开发，所以说没有” 普适性”。对于一些代码基础薄弱的同学来说，遇到定制化的需求往往束手无策。检验” 普适性” 的标准，就是是否傻瓜化，这决定了门槛的高低；高级使用人员，可以二开及使用一些高级特性。傻瓜化不是提倡，测试人员不会代码就是好事，平台想要推广得好，普适性很重要，打个不太恰当的比方，就算会写代码，也没多少人用 VI 或是记事本写，都要用 IDE 工具，为什么？效率高呀。会写代码，可以做很多实用的测试小工具，还是非常棒的!文章源自玩技e族-https://www.playezu.com/185867.html
3. 对接口反向用例或混沌测试支持不够
虽然很多平台支持数据驱动测试，但是对接口反向用例或混沌测试支持不够。先从一下真实生产事故讲起，朋友公司因第三方接口导致了服务器宕机，最后查到的原因是，扫码，传入的数据是一个比较长的乱七八糟的字符串，没按要求传正确的值，结果服务器，死循环挂掉了。接口测试时，无法穷举所有参数值。在 postman 和 jmeter 中都有数据驱动，但是我认为采用枚举的方式来设置参数值，然后通过数据驱动的方式来执行测试，对人的依赖太大。后面我再讲接口混沌测试，瞬间可以完成笛卡尔积式的接口混沌测试，从另一个视角来实现，且和接口数据结构无关。文章源自玩技e族-https://www.playezu.com/185867.html
4. 理不清接口间的调用关系
纵使写了很多接口用例，但是对接口间的关系依然是” 抓瞎”。很多时候我们借助于调用链跟系统，但是对于平台上的接口用例，调用链这张网又太大，和接口用例也不完全匹配，就算匹配，且调用链跟踪突出的是，调用上的时间顺序，并不突出他们之间的依赖关系，以及是什么样的依赖关；也不是所有系统都用上了调用链路跟踪，大多不是微服务架构的项目，这块想用调用链跟系统 (如 SkyWalking Zipkin、Pinpoint 等) 还是不好办的。接口用例间，实际上就存在依赖关系，如 A 接口，要依赖取 token 接口，同时 A 还依赖 B 接口的响应数据中提取的参数等等，这在 postman ,jmeter 中，虽然接口依赖关系事实上存在，但只能人工去理，没有一目了然的可视化界面来展示依赖关系，当一个接口改动了，也不方便评估，对其他接口的影响；且通过直观的依赖关系，可促使挖掘更多的测试场景。文章源自玩技e族-https://www.playezu.com/185867.html
5. 低代码模式对测试能效提出更高的要求
研发都低代码了，接口测试却还没有低代码，变相抬高了接口测试门槛，当然这个对于测试来说要求也比较高，事实上这也不利于提效。肯定有人要反对了，测开就是要写代码呀，能写代码这很好呀，明确的说，这是五年前流行的观点了，我们要的不是代码的堆砌，而是高质量的有效代码；测开会写代码，做出来的产品和解决能效之间并不是等号！脱离方法论，脱离工程文化等能加快交付途径的方方面面，只是 “秀代码”,没多大价值。既然要做平台，出发点肯定是团队提效，而不是单兵作战；另外从公司团队组建的角度来说，也不可能全是测开，平台化如果不考虑业务测试的融入，不考虑对非测开人员的 “普适性”，就没法解决木桶效应的问题，我认为这个平台是失败的，不管如何分工，团队的整体能效没上去，这平台就是测开自嗨的平台。现在开发都在提低代码了，开发效率会大大提升，测试的压力更大，测试也要低代码化，才能也一起提效，否则测试这块的短板更短，下面我也会再讲讲对于测试低代码化的一些思考。文章源自玩技e族-https://www.playezu.com/185867.html
现在大家对低代码的讨论非常多，看低的也大有人在，我这里就不展开说了，但有一点我认为低代码会成为趋势，无服务对低代码更是推波助澜。目前比较火的低代码平台，比较有名的都是国外的，微软也有低代码平台。拿我我们公司的低代码平台来说，刚毕业的新人，入职三天，就能实现业务开发了，效率还是杠杠的！且通过注解，单元测试不需要写一行代码了，加少量的注解就可以了，比手写 junit 测试类，省至少 2 倍的时间 。文章源自玩技e族-https://www.playezu.com/185867.html
6. 接口测试场景，没有接口测试执行时的的调用链跟踪
执行接口测试场景时,要是中间出错，排错不方便，手动一个一个去跟，要是场景中接口多，有点 “晕”。还有某些接口中提取参数，在接口的执行日志中，没有详细的的看到提取表达式，以及表达式在执行时，提取到的值是什么。文章源自玩技e族-https://www.playezu.com/185867.html
7. 内置函数太少，对于点工不太友好
如常用的加解密，一些系统函数，一些运算等，当然可以写插件等，但这对点工来说，非常不友好，内置多，拿来就用还是爽。
上面是我个人认为的接口测试中最痛的点，我看到的接口测试平台，不解决这些刚需，只是通过 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 .对接口间的关系理不清
前面的论述，就不重复了，接口间只要存在参数引用，就必须存在依赖关系，完全可以根据依赖关系推导出来，在接口测试场景中，只要选择了一些用例，自动加入依赖的接口用例，并排好执行顺序。同时还能自动检查循环依赖。
不但可以查看依赖拓补，还可以在维护接口用例时，自动检查循环依赖，如检测到，给出提示
这是用户的一个真实接口依赖关系，itest 自动推导出来的
自动循环依赖，如下图给出了具体的循环依赖信息
5. 研发都低代码了，接口测试却还没有低代码
这其实变相抬高了接口测试门槛，同时也不利于提效。这块的争议最多，不再累述。可能测试人员，平时写代码少，低代码会使一些人觉得剥夺他们写代码的权利；也有人说低代码，容易让大家变成工具的奴隶，低代码只是为了提效，把重复工作工具化，并不禁锢使用人员的思想，从公司的角度来说，老板希望你把时间花在，重要的事情上， 重复的事情，工具化，平台化。
比如初级一点的，可以在断言以及提取参数时，通过拖拽的方式，高级玩法就是 bpm 那样的编排，就像工作流一样，拖拉的方式来编排，通过编排实现接口业务场景的测试。另外，还可以重用接口用例，把他转化为 JMX 文件，这样一个用例或是场景，接口测试可用，压测也重用接口用例，以一当二用。
6 接口测试场景，没有接口测试执行时的的调用链跟踪
直接上图，场景执行完，要是有问题，通过执行的执行链跟踪，也就是通常的调用链跟踪,便于排错，如出错，还可从调用链上从出错的节点一下,手动触发接着执行，且是在同一数据上下文，在调用连上点接口名，可查看，该接口在执行时具体的出入参等信息
下图为，提取参数，给其他接口使用，在接口日志中详细记录了提取表达式及提取值
提取表达式为 :$.total:v_total;$.rows[1].packageName:v_pkNa
提取了两个变量 (出参)，下图为接口日志中，出参输出值
7 内置了常用的 45 个函数
写到这里也几千字了,这只是我个人之言，不对之处欢迎大家讨论拍砖，看 玩技博客 上关于平台的讨论，很是激烈；我在这里抛砖引玉，只要是有益的讨论，对行业也是有利，如果能让大家静下心来，一起来探讨什么是好的接口测试平台，也是好事。少卷一些，少一些 KPI，做真正好用的对测试人友好的测试平台还是很香的。
好些人做平台是为了面试时加分，或是多些谈资，这太急功近利了；我看过好多只是个 demo 的平台，在这里我就不一一列举代码地址了，多数是为了加群吸粉，这留得住人吗！！我表示嗤之以鼻！一个好的面试官用一个烂平台也忽悠不了他，有能力，不管是编码能力，还是综合能力强，有很多方方面面来体现，这里就不展开说了。
这贴子肯定少不了争议，欢迎大家加入 玩技博客 反智讨论群，我也在群里方便大家来讨论，本人是开源免费的 www.itest.work (域名有时不稳定 120.78.0.137 可访问),一站式敏捷测试管理平台作者, 让测试变得简单、敏捷！是 itestwork 的执念。写这贴子，也是有感而发，我们一直在改进的路上，3 年了一直在维护中，上面的痛点，必须要全面解决；当前正在丰富压测模块及实现可视化接口编排 大家可以期待。
官网访问地址：www.itest.work (域名有时不稳定 120.78.0.137 可访问),软件功能测试用例模板
未知地区 1F
有理有据，无力反驳……如果能提供代码方式编写用例，在平台又可以管理测试任务和报告就更赞了。最好是拖拽式，先录制，然后编排。实现接口数据和接口用例分离，业务流程和接口用例分离，通过编排来组合，又低代码，又解耦，又便于维护拖拽，编排还必须配套方便的调试模式。没有 debug，出问题都不知道怎么调试。而且一旦业务场景复杂了，低代码的形式只会让事儿更加复杂，需要构造不同的模块，模块还不能复用。对这个补充非非常好同意，低代码平台，我们这边整过。
发现对于没有代码逻辑思路的测试同学来说，低代码写出来的用例质量一直会很低。但是写代码的用例质量，写个半年一年，基本合格。
而且写代码的同学，可以通过培训加速提高到合格线。
说白了，写自动化用例基本上都是套路 + 关键函数，有点技术含量的全部封装出来即可。请问接口依赖拓扑是怎么实现的，非常好奇接口间只要存在参数引用 事实上就存在依赖关系，然后就可以推导出来了除了拖拽那个 (可能会限制测试思维，这个和业务需求还是有点不同)，其他都赞同。
低代码的本质是应用场景的极致抽象并且模板化的过程，其实没准大家写代码的时候就有这思维。
固化的测试方法先天就适合模板化。
个人觉得平台能提供 “用到的技术模板”、“测试方法模板”、“业务模板”、“流程模板” 这几个模板服务，让用户可以方便定制自己的测试流程，查询调用封装好的业务，自动 or 手动选择封装好的通用测试方法，结合技术模板，达到快速产出的目的，就算能用的平台。如果是针对 key 如果一样还能获取到，但是可能会遇到 key 不一样的情况，但是 value，请问你这边怎么处理的没太明白你的意思，itest work 中，A 接口提取了响应数据中的 某个值取名为 A ，这个 A 是不能重或的，，别的接口只是引用，和 key 没关系呀， 不同的接口,KEY 可能是 name ,等，我们不关记他的 Key ，只关心，他引用的变量。如下图，第一个图和第二个图都引用了 packageId 这个变量，和 key 无关呀。不知你说的 key 是参数名不，且我们支持 XXX.XX.XX 这种对向属性的 key
看完前几天争论那么多的帖子，看到楼主这个贴简直就是如沐春风，收益良多我就是感于之前的讨论，觉得我要说些什么… 你是恒温家里的陈小猫吗。。。恒温家的应该改叫张小猫，而你家的才是陈小猫，谁让你是陈大猫呢～感谢其实低代码高代码还是得从需求出发， 如果平台业务固定，用户代码基础较低，那么像答主这样的平台是受欢迎的。但遇到业务迭代大，用户基础好，平台维护慢的话可能反而没人用。维护慢就是平台维护的问题了，而不是平台没有用 。本质上还是投入产出，看哪个合算这个回复打 100 分 哈哈 个人不太喜欢平台化来做接口测试，原因就是太不灵活了。
接口测试，最关键的就是输入输出，伴随着一些前置、后置的处理，像答主这种做成插件化的，如果少量处理还好，多了起来的话，想想在本地写好源码，没得调试，还要去到平台，跑了还不一定能通过，如此折腾，是有多蛋疼。大家有多少人的接口测试是不能简单的验证输入输出的？有多少需要测试异步调用， 批处理任务以及需要验证数据库和中间件结果的？插件化后，调试确实是一个问题。后续，这块我们文档补充全，只要按文档来，我们来回调，对使用者来说就是个回调函数，目前这块文档还没写得很细。您提的调试提醒了我，后面我在上传插件后，加一个测试 ，输入相关数据，可以测试插件本身， 在测试时，单独把这个测试线程的日志写为一个独立文件，可下下来看。可以认真讨论 就很好 非常中肯的评论，共识多多itestwork 貌似不支持数据库校验？这个刚开发完，下周就 OK 了，我们实现方式和 其他不能，数据库校验做成一个服务,SQL 你自己写，以插件形式，插进来，我们后置来调用打错了是说 我们实现方式和 其他不同，上面不是能 期待，之前就是因为不支持数据库校验就一直没用之前也可以用，只是后置插件你要自己实现，这前手册没写这 如何用，后续手册中我们写详细 点，下周的版本，你就不用写只要写 SQL 就行，我们自动把他当成一个插件（但是你一行 JAVA 代码不用写），然后调完接口 A，再调这个服务就行，后续通过这个服务来检查，如果你想在 A 接中后就检查，还是要写插件，在插件中，调用这个服务看平台的定义，比如提供基本能力的平台，或者提供调度。我们这边就是个调度平台。接口脚本都写在代码里，放 git。什么是馄饨测试，混沌工程调用接口时，制造混乱，也是混沌的概念呀，叫接口混沌测试有何不妥是的，我这边测试也是写在脚本里面，平台只是做展示和调度功能。支持，少卷一些，多做一点实际有用的才是正道itest 这个平台，好是好，就是什么都想做，感觉不好。
项目管理，需求管理，测试任务管理，人员管理，测试用例管理，bug 管理，指标统计都可以放在一起，都是属于测试管理层面的事情，一站式很好。
但是为什么要把测试执行和自动化测试集成到里面呢 ？ 环境管理、脚本编写、自动化接口测试，这是具体执行层面的东西，混进来之后反而造成了这个平台的混乱。
本来测试执行层面的事情都不是一个工具或者平台可以搞定的事情，itest 怎么可能都搞得进来。目前 itest 上面集成接口测试之后，就把自己限制在很小的一个 web 接口测试范围了。接口的范围太大了，CLI 接口、SNMP 接口、NetConf 接口等等，除了接口测试以外呢 ？ GUI 测试、场景测试、嵌入式测试…..都包含进来吗 ？
任何一个产品都少不了几种测试手段或者工具，强大到如 jenkins 这样的工具，也只是提供集成接口来进行工具之间的衔接，而不是全部囊括。
什么都想干反而可能搞不好，就算想都做，最好把自己的平台做成一个工具集，可选的插入式集成。实际不乱，建项目时，选择的是一站式模板，可以改的，接口测试，就看不到手工测试的东东了，后续我们可以让用户制制显示的页面 ，他关注什么，显示什么，不关注的功能，他看不到。
关于接口测试，免费版就只做 HTTP 的，后续可能有 RPC 的，GUI 现在及将来也不会碰，性价比低。后续 CD CI 集成以及代码扫描都要实现
什么都想干反而可能搞不好，就算想都做，最好把自己的平台做成一个工具集，可选的插入式集成。这个建议非常好，免费版这个不改的，正在实现的商版是这样做的 “目前 itest 上面集成接口测试之后，就把自己限制在很小的一个 web 接口测试范围了 ” 人是活的，工具是死的，从来没有人被工具限定 楼主，你知道为什么这么多年了都没有一个能统一江湖的测试平台吗？你好！ 你这问题和本贴要表达的没一分钱关系。 如果你硬要曲解 一站式为一统江湖，只能表示无话可说！car的 4S 都有丰田家的，本田家的且还有众多的专修店的存在，就算有 6S ,10S 专修店也一样会存在。一统江湖我认为是狂妄的想法，且很不现实。
这是不是个错别字谢谢指正，确实是，马上改 fixed 作者你好，我比较好奇的是你是如何实现接口间的关系梳理的，是用户先写用例，然后你根据用例反向生成关系图，还是在哪里可以维护这份关系图呢？先写用例，在写用例的时候，你只要存在参数引用，就是存在依赖关系，如 A 接口，引用了 B 接口提取的参数，或是 A 接口引用了 C 接口取到的 token 也算是存在 依赖 。然后我反推出来，和调用链不太一样的用例编排，这块我考虑到的是元操作是否支持稍后的编排，是否会有依赖，前置后置怎么做，是否有机制保证编排好后能够运行下来
有没有好的 bmp 的开源项目供学习下 我们都实现了，自己实现的 。之前也是找开源的，没找到，所以自己写，搞了一年，现在基本上完事了。在最后的测试阶段我们公司就是接口调完后返回的是修改了几个，数据有没有写正确还得用 SQL 去查找
然后接口依赖也要去数据库找数据做变量，神了 itest 如果你需要到数据中验证，你可以通过 itest 的 api 生成功能。建好数据源后，写 SQL 就行，sql 变为服务 (接口)。然后在你需要在接口测试中， 写一个接口用例，然后不管是执行完要验证数据，还是执行前，从 DB 中提取数据 都 OK ，引用这个 接口用例的数据就行了
为什么不直接像 jmeter 那样，直接在断言中写 SQL 呢，写是把 SQL 变为一个服务 (接口),主要是为了重用 真是澄清了最近几年测试平台的官方定义，测试内卷的本质就是一群非科班计算机人干这外包测试，一心想学开发，于是就学了 CRUD 本领后开始写 web 系统，贴了个标签 “XX 测试平台”,各种公众号，博客园疯狂发文，搞的业内都一会写测试平台去标注一个测试人员水平的指标了，可仔细看后，发现就是一个框架 web 系统，只是传统工具的 web 化，并没有反映出其测试思想，测试理念；咋一看，很酷，跟真的开发对比一下，开发水平又差很远；测试不好好干测试，确标榜着测试头衔，干些开发的事，不去思考，测试平台到底需要解决真实测试行业，公司内部测试现况的事情，工具需要具备实用性，而不是多华丽，技术栈多高端；越来越发现，测试人太浮躁了，真正测试架构师在哪里？这个快速更替的职位，我们最多就是从国外的测试博文翻译应用而已，而不是有测试理念上的创新，测试专利，新的测试思维；看了 itest,恍然给自我一丝测试未来的好景，每一个功能都是从一线反馈实用，非常沉稳，希望像博主这种心怀测试情感的人越来越多，真正让国内的测试人员同开发人员在一个水平线上，是个对等的职位空间，拉起测试人的职业逼格，itest,come on!讲解痛点很深入， 解决方法很有新意， 为楼主点赞， 已经关注了 itest， 近期会试用下， 感谢分享。我们一直在改进的路上，基本上周周发版，都是按用户的的馈改的。本周增加一个小功能 swagger 导入且导入时，按参数类型自动设置值，后面我们录制功有要作，且回放时，自动在所在参数后加随机数 又补充了第 6 点 增加了接口测试场景执行时的调用链目前 github 上各种接口自动化测试平台层出不穷，各说各的好，实在无从下手。
随着项目开发模式、架构的不断演变，测试平台也会更新换代，谁又能保证这个平台的生命力有多久呢测试平台的架构足够好， 满足好维护，好扩展的话，可随业务再加新功能，或是更改原有功能 。可随项目开发模式，架构因变而变，这就需要测试平台有一个好的架构师来设计底坐，只是测试开的水平，来做平台这就可能难办。最终都是为了服务业务~
每个测试平台都是好意的，也都是真心实意的，我把一切往好的看；
我也搞测试平台，但是并不是单纯服务于当前项目，而是服务于公司的测试人员，把工具加以整合，加以利用；
毕竟测试需要传承，平台也是一个传承之地；研效改进的致命陷阱:忽略开发者体验 https://mp.weixin.qq.com/s/DylM-QNloraY0MQzL6oUyw 非常认同这个，总结得 很好，出自 thoughtwork 大师之手,对于测试平台同样道理，测试人员的体验且工具是要提效，不是增加负担的。个人认为平台的作用更应该关注重管理轻业务
管理包括 测试任务管理 交付物管理 测试用例管理 测试报告等等 流程性的东西 方便对测试工作进行统一的跟踪管理 也可以作为测试人员效能的考察工具
测试执行因为测试方式不同 很难用一个工具统一起来 尤其是自动化和性能
不管是接口自动化还是 UI 自动化 自己去做都比不上市面上流行的成熟工具
但是使用成熟的工具 又不如自己写代码来的更方便和灵活
测试平台包含自动化更多的是对当前测试人员技能水平普遍比较低和对工作效率、时间进度要求越来越高的各种现状的妥协
作用正如低代码平台对开发的期望 简单功能能 hold 住 但是复杂场景还是要写代码 导致处于一种很尴尬矛盾的状况
自动化工具也是 但是做测试平台的人的代码能力普遍不高 提供的平台的自动化功能和易用性都比较差 更多是一些普通功能的 web 化 简单的测试点点或者配置一下可以做到 复杂功能搞不定 有代码能力的测试人员又不屑于用这种比较死板的方式写脚本 推广效果不好
破解这个问题 感觉希望有更多更成熟和强大的专业开发团队做类似的平台 就想目前的低代码产品 好的产品越来越多 功能越来越强 不能指望每个公司随便拉几个人整一套 搞出大量雷同又弱鸡的所谓测试平台用来刷 KPI 用的人怨声载道 实际效果很差 非常不错的回复，共同点非常多，只对这一句个有点稍微不同的看法” 个人认为平台的作用更应该关注重管理轻业务 ”
重管理没错，业务也要有，不过难两全，业务侧主要是方便使用的人，管理不是天天用平台的人。我个人的看法是，首先不要增加在平台上办业务的人的负担，简单好用，同时，又能从多个维护为管理提供全面的支撑数据，把流程性的东东，在平台中标准化，融入到业务中，不能太僵化，不过要做好真的很难，只服务自己公司的平台还好办，做一个能产品真的很难做好，只能说尽量用一些通用的原则。对的 我主要想表达的是 既然有心把自动化的功能包含上 要不就不做 要不就做到好用和易用 不要为了追求系统的大而全 整个拖后腿的自动化出来 给整个系统的推广带来阻力 适得其反学习下平台的终极目标是插件化，比如 Jenkins，vscode 等是的，让大家来开发插件，不过插件要好用 如果只是插上来一堆工具集，没打通，就不得行挺不错的点工，感觉大部分都不需要写小工具，求问：你们测试中都谢了哪些小工具一年搬几 W 块砖，还是要把重复的事工具化，只要提升工作效率，工具就有价值，KPI 导向的除外
且通过注解，单元测试不需要写一行代码了，加少量的注解就可以了，比手写 junit 测试类，省至少 2 倍的时间 。
提问：题主能给个例子看看吗~一些理念，看是否可以借鉴下，平台可以增加接口工程类的导入、管理&执行，目前已经满足大部分界面的修改的用户逻辑了，高端的用户还是使用一些编码的进行进行用例个性化的编写和管理，平台只需要按框架给出，剩下的让他们执行，再往后面的点想，提供可外部调用的执行接口及基本信息的返回，把接口测试做成一个测试能力，可以集成到任意你想集成的地方，如日常巡检，提测上线，灰度发版等各种认为执行接口测试有益的地方。非常中肯又很有建设性的建议。目前只是增加了根据 swagger url 同步，postman ,jmeter 的导入， 且也支持通过编码，写插件，以及断言等，只是是 JAVA 的；商业版我们有开放平台，实现对外 API 开放对，除此之外正在实现 web hook 机制 方便和第三方系统互动，现在和 jenkins 是联通。 后续还有很多要改进的地方，一直在不断优化。 您的建议，我们最终都会实现请问下楼主，不同项目的登录接口，可能验证码机制不一样，这个问题如何兼容呢不存在兼容问题，不同的接口，用不同的验证机制，如有些要 token .有些要签名，不同的接口，用不能的验证方式就行。没看懂你的问题，认证可以是全局配置，也可以是接口间依赖来解决
仅楼主可见登录接口前面加依赖接口（不同的验证的前置接口）就行了，不管是同一项目，还是不同项目，呱唧 1800 次”混沌测试”完成 执行结果 通过 给大佬报个 bug，官网下载的测试计划和几个文件下载出来有问题：
好像文件出问题了，回头我看看fiexd