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

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

    再加一个从另一个或多个迭代中 加一定过滤条件中分用例到当前迭代
    然后统计时把轮区能分开就 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 待办目前主是我的事项

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

  • 功能没看过他的, 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 的上层目的,你移动了,所以我们找不到这目录,后续脚本我们加一个检测 ,发现目录不存在,提示是不是要重安装

  • 不用来回搬,一次选型选好 😄