体验不太好 还在实验阶段， 滚动问题反馈给他们开发部了 UI 操作也是比较慢的 (平均 2s 完成一个操作，比 playwright 慢太多了)，只能识别到可见范围内的元素，不在范围内的找不到 依我看目前还不能满足大型商用软件，简单的 ToC 是可以的，等他们后续版本吧，看能不能解决基本的操作 bug，流畅度，还有就是值支持前端语言 node.js 等，不支持后端的 python,java

你们用什么系统管理测试用例的呀？

躺平了一年

我们也在用 palyWright 不过只是用在 UI 上了，接口我们用的 httpmock

谢谢上面的回复，假如我多轮次，所有用例都执行了一次，这时候每条用例都标记过状态了
那我下一次开始分用例时 就不能按状态/已分配 分了，希望能有个功能一键设置用例状态 是否分配

能满足部分需求，多轮次 期望这样
1.比如一共 1 万条 case，这个迭代 V1,抽调 P1 级别的用例共一千条分给 10 个测试执行
2.v2 迭代 分配其余 9000 个用例中的 2000 个用例，就这样大概用几个迭代 把所用用例都分一次
这就需要 每个迭代分出去的用例与 未分配过的用例区分开，才能再下个迭代方便的挑选未分配过的用例

codes 我简单用了下

我也有这样的疑惑，一直在找寻支持回归测试的 测试管理平台，目前没有发现这样的东西

学习了

直接在 cmd 运行你那条命令试试

首先：
1.你的监听 是重写的 testng 监听吗？
2.报告模板是不是有 2 个，肯定至少有 2 个，才产生了 2 个报告

业务这块 有复杂的 也有简单的，就是对数据读取后加工后，最后调 openAPi 完成处理

别沉啊

太真实了 点赞

我们做了生产的服务监控，其实只是监控服务，周期啊 频率啊 自己控制，不要产生业务数据，不要给生产增加负担
目前我是一分钟轮训查询一个服务状态的，遇到服务异常 调云平台的电话服务打电话过来

贴图看不清，模糊

吃瓜

顶起！

你压阶梯和压普通 2 种线程并发量肯定是不一样的，当然吞吐量不一样啊，关注性能的话，还是关注 tps 更直接，吞吐量还受网络因素影响

学习了

可以试试用 docker，当然这也要看你内存有多少，能启多少个容器，应该能成倍提高效率

我们系统刚好相似，各个审批节点的人不同，先查询当前节点审批人，从系统接口找到这个人登录审批，或者从文件中读取审批人，总之每次审批完进入详情去读取下一个人，直到审批结束

谢谢解答

谢谢解答哈

什么公司呀

主要是 IOS 消息的接收，我们是做的日本市场，他们基本上用的 IOS