导到 CODES 中吧 然后非叶子节点 变为目录， 可以点目录来看 ，相当于 把脑图拆分了多个小脑图了 下图 1 就是导进来的

也可以脑图中右键执行

然后可以切换到标准用例的脑图视图，左边显示为目录

改了提交审批中，谢谢指正

我们 18 年开始写的 ，去年商业化了 以前叫 itest ，现在叫 Codes ， 本地安装，不限功能 30 人免费 可以随便用，要是有兴趣试一试 ，我可发你手册
https://space.bilibili.com/3493269541488976 这是我们 B 站上录的一些视频

https://testerhome.com/topics/39189 也可以看看 CODES

我还有一个 Codes 敏捷测试解决方案
https://codes-work.oss-cn-zhangjiakou.aliyuncs.com/codes_base/codes%E4%B8%80%E7%AB%99%E5%BC%8F%E6%95%8F%E6%8D%B7%E6%B5%8B%E8%AF%95%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88.pdf

https://www.oschina.net/news/276224/codes-4-3-1-released Codes 重新定义 SaaS 模式的研发管理平台开源版 4.3.1 发布 可以看看 Codes 自己搞成本太高，
codes
云端认证 + 程序及数据本地安装 + 不限功能 + 30 人免费

有想法 有行动力 ，以后一定有好的发展

早破早立 测试的天花板摆在那种 多一个新的岗位挑战一下 成了就成功转型 ，有测试思维的产品不多得

好东西

你用容器 IP 有问题 你现在 OK 下次重启了 IP 可能变了 ，要是用 compose 你直接用服务名 ，要是用的原生的 docker 可以用 link ，link 不推荐使用哈

比如 我 codes ,用 link 连 codes_redis_server 和 codes_mysql_server 这两个是我在启 mysql 和 redis 时，--name 指定的容器名 ，然后 WEB 中用这个名来 linker , 配置文件中就用这个 Link 名，
docker run -d --name codes_web_server -p 0.0.0.0:${conf_port}:8032 -p 8064:8064 -p 8063:8063 --link codes_mysql_server:codes_mysql_server --link codes_redis_server:codes_redis_server registry.cn-zhangjiakou.aliyuncs.com/codes_work/codes_serve:${version}

只要和领导搞好关系 活少 出事也不用背窝

管理的前提是公司给的薪资还可以才谈得上管理，要不然很多管理落不了地
另外，管理在小公司真心用不上，都是干活的
大公司才能谈管理，且在你的管理之下团队效率有量化的得到了提升
如果做管理之后技能差了也没关系，你要业务上成为专家，还是有竞争力的
如果只是分分活，写写总结，业务水平也没上去 ，那裁员时第一个就是裁你

非常好的总结

我前面回过，可以从己执行的用例例中选，有一系列的条件，以及从己执行过的轮次中选，总之不能让人一个一个去选，必须支持按条件批量

测试只是门槛低，但不代表要求低，在研发团队中，测试是最累的且相对工资是最低的。做一个自己纵向横向都不错，，有产品意识 +PM 意识的测试 拿的一样不行，走技术路线，testOps 方向也不低的，纯点工，当然不值几个钱，不管你做了多少年

不加解密不行呀，这压测试结果可能失真，有些加解费 CPU ，去掉他测试的结果是失真的，

后续再补充吧，不过再补育也是这种风格的。我们也有用户手册，不般不对外，除非有人要，一个软件如果要看文档才会用，这软件是失败的

刚看到您贴的图，应是你后来提交的，

看我上面的图，可以选己分配和没分配过的，以及左面是需求 都可以过滤，只要加上

再加一个从另一个或多个迭代中 加一定过滤条件中分用例到当前迭代
然后统计时把轮区能分开就 OK 了

当前分配用例，条件有很多，不用一个一个去选，设置了查询条件就可以了全部分配
，因为每个迭代，肯定有对应的需求，需求定了，也就是左边的树，再加己分配和没分配的过滤，这很好就区分出来
,还可加用例的状态

总之通过沟通 我明白了需求

这就是 CODES 迭代的东东了，分用例的时候，可以按需求 按测试结果等分，这现在的功能就是这样；

后续我们再加一个从另一个或多个迭代中 加一定过滤条件中分用例到当前迭代

1、从执行角度，迭代中测试的视角是不是计划更好一点，就是上面的这个回归？因为这时候用例更像是一个用例库，是一个供选择的资源池；

从计划就有我上面说的管理问题，我个人认为不要拘泥于理论或是概念，只要方便管理，就 OK ，是不是库不重要，关键能从多个渠道选用例来回归就好。
且不能只能测试的视角来看，要从整个研发的视角来看

2、从质量角度，由于用例多轮的执行，迭代的质量数据应该是汇总的多轮次的执行数据 ；
我只是没说而己，这当然不影吶统计，只要数据库库里，想统计这很好办，就怕没有数据 ，要统计

codes 我上述的将要做的，满足需求不?

codes 安装简单 笔记本就 OK 2G 内存就行了 没别的要求，不管是 windws 还是 linux 都一键安装 0 配置

忘了说了 CODES 你可把迭代中的用例 导出来　离线执行回归 再以导入的方式同步结果到线上，不会新增用例，只是同步结果到线上

codes 是迭代 + 测试用例的管理方式，也是一样的问题，用例倒是能勾选执行失败的用例，但是多轮次的话，只能新增一个迭代。但是这样又违背迭代的概念了
我们迭代是有两个层面的迭代，一个是按版本，一个是按时间，不管那一种 新的迭代 你得建的，要不然测试结果不好区分
刚好您问到了这问题，最近我们的计划应能满足你
我们计划 在迭代下，你可按条件把当前把一些用例选出来，然后自动生成一个回归的场景，挂到当前迭代下，这样你就不用建迭代了，相当于，一个迭代下，用例支持多轮执地且执行结果是分开的，在迭下下多一个 TAB 回归测试， 只是每建一次分配，你要取一个回归的名字。

在当前你可用场景来做回归，我们在建场时，支持从别的场景复制用例，然后你再把这场景分到当前迭代下

另外
codes 的迭代和 testlink 等的计划不一样
用例分配到迭代下后，再分配不同的人员执行不同的用例
传统的计划 如果我有 10 人执行用例，你要建 10 个计划，根本不方理管理
codes 多了一层迭代，一方便分配要执行的用例，二可以多人在一个迭代下，执行不同的测试用例，相于于分了"任务"

且迭代下不只是用例，还有 BUG ，任务等

有了迭代这个中间抽像层，方便管理
执行人员，进来缺省是自己名下的用例，且左边只显示 只显示当前人员所分配用例对应的需求，需求树上显示执行情况边上的分数就是执行比例，打钩表示完成，双击还可查看需求明细，

另个还方便查看各人的进度和总进度

这是迭代分工

nice

postman ,ms ,apipost,apifox 等都有这个问题
参数维护不面向对像且不能自动转换 , 如参数得复杂 json 只能写 json ，通常大家对表单比较熟悉, 批量维护 KV 自动转 JSON ，如是复杂对像，支持 dto.user.id 这种复杂 kye 转 josn 就爽得多，完全是向面对像的式在维护参数

参数维护方便很多,个人非常不喜欢 json schema 的方式，KV 可方便转复杂 JSON ，又可直接写复杂 JSON，这才是照顾使用人的效率和提升便利，XXX.XXX.XXX 这种才是以面向前对像的思维维护参数，且更切近表单属性。

这是 CODES 的方式

数据驱动，也是按面向对像的方式，方便复杂 JOSN 的结构，传统的数据驱动，只方便 KV 方式，复杂对像，表达起来费劲，我们依然采用 xxx.xx.xx 这种对像属性访问形式。依然采用 xxx.xx.xxx 这种对像属性访问形式，即支持简单 KV ，又能一行表示一个 json 对像，直观又易于理解

做工具还是要创新