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 待办目前主是我的事项

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

功能没看过他的, UI 风格学了他的，没学到位

你也顺道帮我们发现了一个 BUG 我们要改为手动拷也没有换行

我记得你是 docker-compose 版本，升级也要用 compose 的脚本

我们官网 上有 联系方式，有 Q 群（2155613）也有微信群
邮箱：luorui@icodes.work

电话 (罗先生)：18608008443

你这里 有一个空格，不要手动拷，网站适配了手机有空行，要用我们边上放的复制按钮拷

cat ,more 多的是呀

可以升级 1.1.0GAU2

1、 工时填报和工时日志显示填报人

BUG
1、需求分类，上移时，之前展开的分类，不能展开
2、切换项目时，风险没同步切换

正在实现实现下面这 5 个功能

1、迭代中统计用例覆盖率
2、需求描述可配置模板，按模板来初始化显示
3、迭代增加一个统计 ，迭代下用例对应需求，各需求用例情况（用例数，覆盖率，执行情况）
4、 迭代下加一个发布计划，并可审批，含一些发布文档
5、工作负载和任务甘特图支持分页

这个看你的选择了，从功能上，CODES 项目管理，测试管理有。也可以理解为 CODES 是国产 JIRA 替代之一，但 codes 和 jira 不完全等同。我说了不算，可以 POC 对比一下

他们自己的 BUG 都不用 MS 管理 用 TAPD
codes 团队都是用 codes ，自己都不用，这如何谈以用户为中心

你安装时 IP 配错了，安装时让输 IP 你输了 127.0.0.1 ，前后端分离的 ，你输这 IP 只能安装了 CODES 的服务器上能用 CODES , 前端要根据这 IP 应访问后端 ，可以进 CODES 群，交流，
可以这样看一下 cd $CODES_HOME/www/codes
看 config.json Ip 肯定是 127.0.0.1 ，这不对的

2、在登录页面停留几秒后，又重定向到http://192.168.0.11:8010/codes/#/mainPage/workPlatformMrg页面

这一步 你输http://192.168.0.11:8010 重定向登录页是对的，但是不会过到工作台去
您这是什么浏览器 ？

在http://192.168.0.11:8010/codes/#/mainPage/workPlatformMrg页面刷新后，左侧菜单会显示不全
在登录页跳不到这里呀，按这现像，是退出了，没有了权限信息 所以 菜单没了，
确信没有人用这帐号登录吧，要是有人登录了，你这帐户就被踢下线了，就算踢也有提示呀

emm ~
wget -q -O codes_config.tar.gz https://download.icodes.work/codes_base/codes_config-$version_upgrade.tar.gz{}
下载后压缩，后将 codes_config 文件夹移到/code 下，再重新执行 sh install.sh 如上问题能解决

这样不定 OK ,第一次安装进，IP 和端口输对了没有，安装完，要写文件，如果没写成功 安装脚本误以为是升级，不会再更新配置文件，可以按安装脚本中的 sed 手动改配置主要是 IP 和端口

也是按你接口原来的断言呀

/etc/profile 这个文件 有两个变量，CODES_HOME 和 CODES_VERSION 要删了，然后 source /etc/profile

再把 原来的安装目录删了 ，然后重登录另一个 SSH 窗口，重安装， 因为你原来的窗口的上下文读到 CODES_HOME source 也不会对当前窗口生效，所以要开一个新的，重执行安装就 OK 了 建议用 docker-compose 版本

你上面报这个错，是因为你手动移了目录，再安装时我们只要发现你有 CODES_HOME 变量就认为你安装了然后执行升级操作，升级前会备份到到 CODES_HOME 的上层目的，你移动了，所以我们找不到这目录，后续脚本我们加一个检测 ，发现目录不存在，提示是不是要重安装

不用来回搬，一次选型选好

首先codes 式一站式研发管理平台，和 MS 的测试平台没有可比性
第二 硬要放一起比，从创新来说，我们有很多他创新，比如低代码 CI CD ，拖拉等，BUG 管理我们可以设置流程，测试管理我们是敏捷测试，技术上，业务上我们很多创新，2G 内存就可以跑得起 CODES；MS 2G 能跑不，另外他们就是 jmeter 包壳 有什么创新？ 测试管理就是 testlink 改版，有什么创新？像统计分析 MS 的 没法和 CODES 比吧，只 会抄没有创新，说明产品人员没有自己的理念，当然他开源运营得很成功
第三 我们这产位定位不一样，我说了不算，你可深入 POC 一下，只有使用了才有发言权 '
第四 从 codes 的前身 itest 第一个版本，到 codes 我们完全平滑升级，因为我们在设计的时候，全局设计；，有用户买了 MS 一年不敢升级，为什么 ? 就是产品没有顶层设计，做到到哪抄到哪，所以经常改得没法向下兼容，或是大改带来不稳定性 ；

不是同一类产品 没法比的，你问了，我不回也不行，还是要自己 POC 一下；另外我们全套研发管理平台也不贵对用户友好，30 人免费，不限功有，UI 我们后续也要做的，他有的我们都要有 。且我们推敏捷测试，MS 推持续测试，在我看来 持续测试是个伪命题，这里就不展开讲了，后续可以就这个再探讨。看看我们的这贴子就是我们对接口自动化的一些见解

测试架构师如何解读测试平台的各种争议

最后 付一段 别人的留言，测试开发技术公众号下的一 MS 贴子的

后续如果有时间用户也有需求的话，我们可以提供从 MS 一键搬家，当前在忙 redmine 搬家中

18 开始写 itest 代码， 5 年后 2023 年 itest 变为 codes ， 一直都在的，同年代的工具，好多现在都不维护了，我们是打不死的小强