如果 2 开，确实要选技术，只是用只要好用就 OK 。选型的话，不二开和技术无关，只和能不能解决需求有关，别急，我们新版就会出来
前后端，这些都不是事，，也不是什么高深技术，坐等新版
loadrunner 10 年前的技术了，现在不一样有人用得欢吗

用 itest 呀 看看这就明白 itest 的创新 https://testerhome.com/topics/30495

MS 没一点创新 不如用 postman ，起步 4C8G ，，itest 1c2g 就够

这就是脑图的本真用法，没有前置也没有步骤和预期；想要标准用例，转为标准时可以改 或是用这个第三方开源插件
https://testerhome.com/topics/34094 ，这就是别人写的用脑图写标准用例，转为 itest excel 导入模板的格式，再导入到 ITEST 中

没写，功有是有的，先在全局设置中配置好规则，然后建接口场景，在场景中就可以用上，或进 Q 群问

如果你认为是广告,我无力反驳。我主要是看贴主，有这块的管理问题，我简单分享一下，ITEST ，也不收费，免费用，好东西分享一下，测试人员，不应该多些好奇心，多了解一些工具么，我是本着真正敏捷测试落地的好东西和得大家分享，你无视就行。

itest work
第 1 步写脑图用例

第 2 步把脑图用例同步为标准用例，同步的时候要选一个迭代

第 3 步，在脑图上执行用例 或是在迭代下执行用例（也可以以第 4 第 5 步的方式执行更便于管理 ）

第 4 步，分配迭代下，不同的人执行不同的用例。更细化管理测试迭代，一个迭代有可以几 100 上到几 1000 用例，
按功能分配不同的人执行不同的用例

第 5 步,在迭代下以需求树执行用例，需求树进行了过滤，只显示执行人所分配的用例所对应的需求

第 6 查看迭代执行用例情况及 BUG 情况

iest work 是免费的，一个月发两到 3 版，官网及在线体验
www.itest.work

哈哈，不错。itest 就是不支持用脑图写标准用例，要这样用，只能自行扩展。itest 坚持脑图的本真用法，保持脑图的简洁。存在就是合理的，有这场景的，可以用你这工具转为 EXCEL 后再导入 itest 中，后续我们可把你这个集成进去，就不用再 EXCEL 了，只直导入到 itest 中。兄弟这水平不错，不爽就自动动手

但这标题，会让人误解，和 itest 没关系

客户端的场景 不明白什么意思。itest 里有接口场景里 ,目前只要是 HTTP 的接口就支持，我没理解是客户端场景；我的理解和打包没关系，我们也支持写插件上传上去，这不就是打包吗，打包只是技术实现手段。

这和 ITEST 有什么关系，你用别的接口工具， 这也要你处理呀。再说了，这在 ITEST 中，如果 A 接口有这些依赖，只要你的接口依赖别的接口的输出就行了，A 接口可以依赖一堆接口，只要存在参数引用 。你用 POST man 也要处理前置呀，

下图中，都不需要人为去管理前置，itest 自动帮你管理好，

公积积的待办撤销业务，你都不需要管前置的事，只要在撤销接口中引用其他接口的输出参数
不会用还说是 itest 的事

那没明白你的问题， 写代码就好? 我这就不一一说了，我这贴子写得很清楚 https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议
另外，从公司的角度是要提效，不是让你写代码。

“ 接口测试的准备数据要用 UI 自动化来准备 ” 这一句我表示看不明白，且也支持数据驱动，有问题欢迎随时沟通也用 ITEST Q 群（22569636）

你说的 itest 不是 itest work 测试管理平台中的 itest

从贴子来看，只是集成开源的，做了一个框架，都不能称为平台。做平台是要降本提效，只是为了平台而平台，开始领导会支持你，后面没产生价值，第一个要干掉的就是你！ 建议不从 0 开始，要么用成熟稳定的，开不开源都 OK ， 关键是要经常更新，一个搞一个平台，工作量摆在那里，没法做好的 .itest work 我们这平台，接口测试都搞了两年多，且是专职开发团队维护。

fiexd

有机会肯定要转 怕什么 crud 没什么难的，先转了再说 不要怕和开发 PK ，能 PK 的过测试就行，再多搞几年开发子能 PK 了，多好的机会

好像文件出问题了，回头我看看

itest work 你可以试试， 截图就是 itest work

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

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

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 转标准用例，然后再以脑图视图显示

导入后，的标准用例

导出后的脑图视图

脑图视图全屏

脑图上执行用例