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

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

有点意思

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

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

先描述清楚你的问题？

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

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

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

先活下去再考虑趋势吧

剩下 90 分是一点办法也没有（狗头保命

dump 一下线程，看看这些是哪个线程池启动的，找到这个线程池创建的地方，看看有没有销毁逻辑，这种情况大概率是没有销毁机制的，一般需要主动调用线程池的 shutdown 方法或者将 allowCoreThreadTimeout 设置为 true

metersphere 的开源版，github 和 gitee 上都有
建议就采用 springboot 程序常见的分目录就好，可以找个脚手架项目的源码下载下来看看，比如小诺框架

智谱清言 清华的
kimi 最近广告挺多

获得推荐和 GVP 还不太一样，GVP 要求更高，但也值得鼓励！
GVP 要求如下

基础设施跟得上的话，可以考虑手自一体，手工用例就是自动化用例，以关键字驱动方式运行，避免重复劳动。

之前有在 MTSC 上分享过我们的实践，希望能有启发/

我们用禅道管理用例。
歪个楼：楼主考虑过手自一体化吗？手工用例也是自动化用例。
一系列问题：手工用例是不是资产？这些用例最多运行过多少次？超过 2 次的比例有多少？
如果用例步骤类似这种和协议强相关的话，要不要考虑直接做自动化呢？用自动化来建设功能

一般提到自动化，先考虑分层，做 UI 还是接口？或者两者都做
UI APP 好像有个 appium，但我不是搞这个的，不太清楚，web 端的可以考虑 selenium、playwrigt、cypress
接口自动化，也有平台/脚本两种玩法，平台可以试试 MeterSphere，开源版就满足需求了，脚本的话就是自己用一些 http 的请求库，以代码方式组织用例

有一种情况叫做，我不知道别人不知道。比如您这里的：“仪表盘用的官网模板（截图里面的 json 文件）”，我现在想帮您解决问题的话，您是希望我从官网重新下载一份，完整复现一下吗？您作为问题提出方，是否有义务提供更多的信息呢？

发挥独特价值

让我们先猜猜您是如何配置的

啥叫用例覆盖率？用例覆盖了多少功能？还是用例覆盖了多少代码？如果单论代码覆盖，行覆盖，分支覆盖，MCDC 覆盖分别怎么样？怎么采集？回到用例覆盖的功能，什么才能算用例覆盖了功能？是正向都写了，还是逆向也写了，异常考虑全了没？进一步的，调用链路覆盖情况怎么样？光覆盖的指标都多了去了。。。，在考虑个执行效率，执行周期，问题发现频率，误报率等等。。。。

因为回帖格式默认是 markdown，星号是特殊标记格式。。。

ansible 它不香嘛