开发想表达的，应该是少了一些串起来的业务流程用例,你的用例如果都只是单功能的，这只相当于只有单接口测试，你还得有基于业务场景的测试呀。功能测试也一个道理，为了用例的复用，可以把单功能用例，组合为业务场景用例

这就是把单功能用例转为业务场景用例

https://testerhome.com/topics/30495 不会写代码，可以用 itest ，断言以及提取变量都是拖

不写代码才是方便，拖拉生成断言，拖拉提取参数，肯定比手写方便，

一是如果这个参数的入参不止提取的值呢，比如说 token，登录接口提取了 token，但是请求的时候前面需要加 bearer 才行，又或者某个入参是多个提取参数的组合。

这个完全支持 ，在引用的地方，再拼接你要加上去的，或是再用内置函数处理，可以 函数套函数

二是我不知道您这个接口的提取参数作用域是多大，假如说在一些流程用例场景时，某个用例的提取参数需要在下一个用例使用，不知道这时候是否支持，这种情况还是挺多见的。

这个当然也是必须支持的呀，第二个图就有，在 json 中用我们的语法写也是 OK 的

然后我看了您的这个平台，接口采用 KV 形式写用例的，我最早也是这样设计的，对 json 做一个格式化解析。但说实话，遇到复杂的 json，特别是 jsonArray 和 jsonobject 的多层嵌套，维护起来特别麻烦，最终呈现还是 json 方便，所以后来就放弃了这条路。

不只是 KV，我们有编辑器模式 ， jsonArray 和 jsonobject　在编辑模式用

ms 还真没有这个

这种拖拉的更爽，数据结构复杂，写个 xpath,jsonpath 也不方便的，不像简单 KV

我登录进去看了看没看出来，低代码，低在哪里，最起码断言，参数提取不用写代码，才能说低代码吧，

原始脑图

这是我实现的，xmind 转 excel

这是 xmind 转标准用例，然后再以脑图视图显示

导入后，的标准用例

导出后的脑图视图

脑图视图全屏

脑图上执行用例

excel 在线转 xmind：因为测试都是用 excel 写的 case .
都用 excel 写了，要是我实现，我根本不转，就是存标准的用例，只是显示时加一个脑图显示模式完事 ，然后转换为 png 的图，再插入回 excel

你要是限定在河北石家庄 , 这都不算二线，为什么不看看，其他二线呢，

1：关于老是接口变更，如果接口是基于 swagger 的还好，可以有技术手段，同步到接口测试用例中
2：接口最好是基于录制来生成，省些事
3：维护接口的成本高，如果支持断言，参数提取拖拉，再加上有调用链，还是方便多了
不过不稳定期，不要忙着上接口，相对稳定了，再来做接口测试，维护量小得多
可以看看我写的这个https://testerhome.com/topics/30495 ，里面有些东东，可能有些用

用 shell 的里 sed 去 改

严重同意

成都测试圈 也还行吧，要不是有疫情，我们也搞一些沙龙，18 年搞了一次，20 年也搞了一次，看来你没找到成都的测试组织 呵呵

itest work 测试用例管理，缺陷管理，接口测试都有

非常不错

登录接口前面加依赖接口（不同的验证的前置接口）就行了，不管是同一项目，还是不同项目，

不存在兼容问题，不同的接口，用不同的验证机制，如有些要 token .有些要签名，不同的接口，用不能的验证方式就行。没看懂你的问题，认证可以是全局配置，也可以是接口间依赖来解决

投入 4 个人月，致少 10 W 的成本没了，效果如何还不好说

要想降本增效，降低使用门槛，对测试小白友好，只对 jmeter 包个 WEB 没用的，不如直接原生的 jmeter ， 要降低门槛 ，就得可以录制，加拖拉方式设置断言，以及参数提取，然后通过可视化拖拉方式编排接口业务场景。如下图这种

还有可能,https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议 我这里写的，对小白友好，

接口测试可以看看 https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议

非常中肯又很有建设性的建议。目前只是增加了根据 swagger url 同步，postman ,jmeter 的导入， 且也支持通过编码，写插件，以及断言等，只是是 JAVA 的；商业版我们有开放平台，实现对外 API 开放对，除此之外正在实现 web hook 机制 方便和第三方系统互动，现在和 jenkins 是联通。 后续还有很多要改进的地方，一直在不断优化。 您的建议，我们最终都会实现

手动点赞

很充实，向大佬学习

很不错，乐见百花齐放