httprunner 应该还不错

关于 Java 默认的线程池，有一点觉得可以提及，如果 最大线程数 大于 核心线程数，且等待队列可以存储任务，那么当任务把核心线程数占满之后，新来的任务是继续创建线程执行（还没达到最大线程数），还是放入等待队列？
我举个具体例子：core=10,max=20,queueSize=5,现在有 10 个任务正在占用 core 运行了，又来了两个任务，这两个任务是排队还是优先创建新的线程，直到打满到 max 再往队列里塞？

可以试试 metersphere

查查 influxdb 中是否保存了符合你预期的结果

不知道 httprunner 能不能满足你的需要

我们做 web 端主要是为了方便版本管理，可以在线 diff，加批注，对于一些评审类的场景有一些定制，其他方面和脑图软件没多大区别，另外我也做了分时协同，只要两个人不同时编辑就 OK，程序算法上限制同时只能有一个人编辑，然后只要保存，所有打开的人都能立刻看到最新的内容

我们用的也是这个开源组件，在节点数超过 1000 之后，会卡，可以开性能模式，但性能模式目前还在 Beta 版，展示效果还行，但一旦编辑，还是会卡很久

“创建和销毁是非常昂贵的操作”，建议把创建和销毁线程具体哪里昂贵了说一下，可以从操作系统角度深入展开，比如操作系统线程，内存，调度等成本，希望看到您的深入分析。

CompletableFuture 用的比较多。。。，另外，一般都建议用线程池，手动 new Thread 在阿里规范中不推荐，多线程实现的方式还挺多的，比如 Callable 等。。

systemctl daemon-reload 然后 service docker-restart

哈哈，在微信公众号下面我已经提出疑惑了，这里就不再重复了

招前端外包写，自己负责设计 + 后端

这内容咋越看越像 AI 生成的

我们有部分团队是 TDD 模式，具体来说，测试团队写单元测试用例，开发写业务代码，刚好让单测通过，除此之外，传统的系统测试仍然进行

不写比较好

用 monaco 的 diffEditor，右侧有总览

1、以实际需求为驱动来学习，如果没有实际需求，可以参考业内 top 或者大厂的招聘要求，缺啥学啥
2、接下来，可以看看各种技术大会上相关的点，自己能不能做出来，缺点啥，再继续学

用于和上次提交的内容合并，相当于上次没改好，这次改好了，就是 “修正”

有点意思

在我理解，容器云不是某一个具体产品的名字，是一类产品的名字，所以，你具体用的是哪种？

如果你指的是应用部署在容器云上，通过 xshell 方式更新的话，那就是把容器当虚拟机用例，这需要暴露 ssh 的 22 端口，映射为 nodePort 等方式，或者直接通过容器云平台自带的终端来交互

先描述清楚你的问题？

听说好像 Google 就是让高水平的开发去做测试，但也不完全是测试，算是 SRE 团队（只是听说

我们是有产品线采用 DDD 的方式做系统，然后由测试人员在开发写业务代码之前，就先编写 TDD 的用例，开发需要编写刚好让这些用例通过的代码

“毕竟在系统开发出来之前，产品也无法确认系统是否能够完全满足业务需求。” 不满足怎么办？做完了再改吗 ，感觉应该是有更成熟的需求贯彻方案的吧，Scrum 结合快速原型之类的，或者采用 TDD，在最开始就确定测试用例和验收标准，似乎都是可行的方式（但也对团队要求比较高）