你安装时 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 ， 一直都在的，同年代的工具，好多现在都不维护了，我们是打不死的小强

apache 2.0 开源协议， 不可能限制用户呀。只是开源版目前只有测试管理和缺陷管理

test link 页面太老了

可以用 codes（商业版 30 个用户免费，不限功能 本地安装） ，也可以用他的开源社区版
https://testerhome.com/opensource_projects/codes
codes 以迭代的方式来组织测试 ，比如一个迭代下 要执行 2000 个用例，都分配到这个迭代下，再分配执行人

多了一层迭代的抽像 方便管理，不用像 testlink 多建多个计划，还不方便统一管理

执行用例时也很方便，左边只显示当前执行人所分配用例对应的需求，双击可查看需求明细，左边需求树还显示执行情况

分配执行人时 ，也很方便 ，左边需求树上 显示分配的情况

也有脑图用例

回归测试时 用批量执行视图很方便

还可 EXCEL 线下执行 或是修改后 同步到线上

https://testerhome.com/topics/30495 测试架构师如何解读测试平台的各种争议 这个贴子可能对你选型有点参考。
新手的话建义选用对小白友好的，比如 codes 支持低代码做接口测试，当然也可以写代码

拖拉的方式编排接口业务场景

自动推导接口依赖拓补关系图，让接口关系不再是黑匣子,便捷的接口调用链

CI CD 也是拖的方式 编排流水线

icodes.work

icodes.work 可注册和下载

5 月底或 6 月初

开源社区版近期发布，商业版 30 个用户永久免费

需要把工具放到工程化中来看 且被使用才能产生价值 ，只是为了 KPI 的工具 确实没什么用 ,当然做一个工具提升一下编码能力也是 OK 的 ，有些人呢做一个 demo 就当时面试时的谈资了 有点可笑

icodes.work 不限功能 只限用户数 10 个用户免费 不够可申请 ,且是安装在你本地 下面是 windows 版 最多 2 G 内存就行
https://download.icodes.work/codes_base/Codes1.0.0GA_home-SetupBindMysql8TomcatJreRedis.zip

系统级的搞破坏也算呀

目的不同，对象也不同
chaos(混沌测试) 是系统级别的 fuzz(模糊测试) 都是函数或者类级别的
fuzz testing(模糊测试) 是为了发现安全漏洞，内存泄露，以及其他冲突问题
haos testing(混沌测试) 是为了验证系统的弹性能力，错误容忍能力，以及自愈能力

https://testerhome.com/topics/30495 完全可以用我这里的 接口混沌测试，你只要配置参数规侧 ；我来排列组合后去调用
只需要配置好混沌规则 ，然后以 “撞库” 的形式排列组合，替换掉正向接口用例中的参数值去执行撞库，瞬间完成接口健壮性测试 “撞库时” 先单个一个一个去换， 然后再排例组合。

做了不等于做好了 ! 没有可改进的，没有可再优化的?

自动化用例一定要保证每个用例可以单独执行,简单的依赖就是我昨天说的 ,场景就是把多个接口用例编排为场景
也就是接口用例是原子的, 可复用他们来构造业务场景
说起来抽象 试试 itest work 你就明白 了

和是不是压测没关系 压测和接口测试时他的依赖你必须跑呀，再说了出了问题你分析他的调用链么,如果慢的话 。就拿你的 B 来说 要是压 A 受 B 的影响 , B 很慢也能找原因的 ,照你说的方式你只压 A 性能很好 ,到了生产环境真实是要调 B 的 , B 把 A 拖慢了 ,是不是也要找你 ,谁压的 。压测 我要是要压单一接口估计还得要开发配合, 要是我我不管这些 肯定是按真实场景压 ,要是慢能找到原因就行 ,或是让开发自己去找。 要不然生产慢得要死 是不是要找你麻 烦。一句话压也是要按真实的场景 (或是依赖) 去压。准确来说是压以 A 接口为入口的接口, A 依赖的接口都要一起压了 ，致于是哪个该死的接口拖慢了 A 你能找出来更好 ,找不出来 就让开发来,不是用调用链吗,这很好分析出来，没问就让开发去排查

接口用例是接口用例 他们是独立的 运行的时候自动按参数依赖执行前置用例


接口间只要存在参数引用，就必须存在依赖关系，完全可以根据依赖关系推导出来，执行顺序，执行 A 接口时他引用了 B 接口的参数 你只执行的是 A 但会自动帮你先执行 B 然后才执行 A 。下面这图引用了其他接口提取的参数 就建立了他们的依赖关系 ，我认为接口的依赖关系在开发的时候 就决定了他们的关系 依赖是客观存在的 不是测试的时候才存在 ,所以只要按业务要求做好相关相关的引用就行了 ，平台给你推荐他们的关系拼按依赖帮你把所依赖的也执行了

根本不需要你来关注依赖 详见下面贴子 ，这里有关于接口测试的创新的想法

https://testerhome.com/topics/30495