按照精确度、召回率那些指标看呗，如果总体已经符合要求了就不提，不符合的话把不符合的 case 整理出来，统一提

我也有写过类似的工具，不过生成的是自己框架的 json 文件，最近写用例录制的人又多了，感觉就像一个循环一样

我用 bloomrpc 和 grpcox

针对流量录制后的用例，是可以配置 setup 和 teardown 的，因为这里是进行的录制，所以理论上是最好不要有纯点点点测试不了的部分，正常情况下就是最开始的数据准备和最后的数据清理了，因为我这边是按照我自己的测试框架的结构去生成录制后的 json 文件，所以可以在回放前进行 json 文件的修改来达到自己的目的（可以用 httprunner 来理解，录制生成了一个符合他框架的 yaml，然后如果进行 yaml 的修改只要符合格式要求就是可以正常回放的）

马克一下

目前我们也没用到啥，不过分支扫描是可以的

用的 7.9

有些工具是内部的，其他可以看我的 github

对，是用老版本然后自己导插件进去的，因为部署到了内网，具体版本号我得上班看一下

在服务器上部署 jenkins 和生成报告，jenkins 别放在本地

感觉别做，问题不在平台上，后三点不是平台能解决的，前两点也不是必须要平台

厉害的执行力，后面抓包生成用例哪里很用共鸣，不过我是直接 mitmdump 抓包后提取需要的参数去组合成 yaml 文件

还可以和开发沟通后针对测试环境整一个

多条路子多点机会

宠物繁殖批发

大佬新年多多指教

新年继续⛽️

老导师不请自来

厉害厉害，令人羡慕的产出

这个具体得问你们项目经理了，一般就是用 git 啦

感谢提示，目前我们执行测试的时候会使用预发布和测试环境，不会对真实用户对数据有影响
关于备份等组件的相关方案打算和运维，DBA 一起讨论一下，看看他们给专业的建议，我们自己也去了解一下

我之前是手工测试完成后，选择去看开发代码，找自己有没有没想到的逻辑，逐步补充自己的业务思维

个人看法是二者没有必要分这么清晰，离开业务的测试开发生产的工具没有价值，离开工具的业务测试会有可能被不断积累的业务导致生产力浪费

如果自己公司业务测试能逐步理出可自动化的流程，或者需要一些提高生产力的工具，这个时候让更懂业务的测试做兼职测试产品的角色，更懂代码的测试去进行测试开发，工具出来了大家一起继续业务测试，这样多好

请问一下--agentport 是怎么使用，目前在本地试用的时候直接用 goc build --agentport=:1000 或者 goc build --agentport=1000，执行编译的文件后在注册服务那边都没看到端口被指定，还是随机的端口，是我使用错了吗