非常好的总结

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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