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

我们 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 对像，直观又易于理解

做工具还是要创新

不断迭代改进，目前在忙工单管理，和 redmine 搬家， 工作日历，后续再加。codes 待办目前主是我的事项

后续加工作日历，会议这些就有体现了或直接在日历上体现待办，
要做的还很多，不断迭代