字体而已，jmeter 菜单里就可以字体缩小放大,这种纠结于界面显示很 low 的问题就不要拿出来了

使用什么方式去写用例倒没规定，用 xmind 能帮你把条理理清楚；
手工测试用例的分类我觉得用 ui，功能，业务分开写会好很多
如何细化功能点那就要看你对业务了解多少，对用户使用习惯了解多少，对异常场景能想到都少，想的阅读，覆盖点越全

vmware 现在紧缺人才，认证还算吃香

如果你要从代码层次去提高测试效率，那是最有效的。
从测试层面唯一的方法就是提高测试场景覆盖.

?代表什么. 我说的就是你为什么再不同线程里登录不成功的表象.
用什么方法能获取到跨线程组的登录信息其实很多，
比如楼上说的跨线程组传参、
比如 jmeter 的插件里就有这种专门处理跨线程组的。
如果你要手把手的解决方法，对不起.
我主张先自己尝试以下，解决不了了再来问
我给你的是一个思路

1 需求评审，开发测试，相关人员全部参与，从源头上首先尽可能保证少出错
2 充分考虑需求转换测试用例，不是看一条写一条而是针对每一条充分考虑各种正向逆向场景
3 界面、控件功能、业务流程分开，揉在一起是测试用例的大忌
4 测试人员交换评审彼此用例，不同人的思维角度不同能发现新的测试点
5 测试用例一定要评审，只有评审才知道你写的对不对，有没有遗漏，开发是不是如你所想做的或者实现不了你所想的
测试用例是一个测试人员的基本功，如果基本的都做不好，就不要好高骛远去说什么自动化、性能

同上，如果只是要问某种工具怎么去做，那不一定每个人都正好用你的工具。
首先自己学会搜索
其次善用翻墙工具
再其次多看相关文档，尝试自己研究 (当然比较耗时间)

如果是想询问实际工作中遇到难题怎么处理的经验，这个确实是谁也没有的

如果你要求开源，国内知道的确实不多，无非就是禅道。
国内做的比较好的是 tapd(腾讯的)
国外的做的好的 alm(商业里面大而全)
国外的开源工具很多，那个好你的自己去尝试

我写用例会先从 ui，页面控件功能、业务以及与业务有交互的点三个大方向来写，然后会写兼容、自动化、性能、安全角度的测试。你们都忽略了一个最最核心的东西业务。功能和业务应该分开来写才是最合理的。揉在一起写往往会只注意了功能而忽略了业务

同一个线程组里成功了，说明多个请求都是共用的一个登录接口的请求信息
不同线程不成功，那就说明你没获取到上一个登录接口的请求信息或者是没获取对

一个请求之内 jmeter 可以做到长连接，这点不用怀疑.
就如上面林胖所贴的你自己也说了后面的请求，那都不是一个请求了怎么做到长连接

smelody 基本概念你都没弄清楚，去看看 jmeter 里面线程是什么概念，跟 session 什么关系

你对于长连接的理解貌似有误，长连接是在整个 session 会话的过程中，不需要频
繁发起请求而已，会话结束，长连接结束。

你可以去看下 jmeter5.11 的 changelog 看做了那些改动

response 在大并发的时候如果选 xml 生成的数据大小会让你怀疑人生，尽可能的选择 jtl,response 你需要的数据可以根据需要一样提现出来，需要返回什么，判断什么，总要有取舍，不能什么都想要.
性能测试不是自动化测试, 是带着目的或者指标去测试. 什么都想要，什么都要不了。

这种自己尝试下就知道的问题真的有测试过么:
文件夹必须为空
文件目录不要过深
尽量不要用中文做文件名
jtl 数据文件又在哪里

kotlin 有 google 支持，加上本身 kotlin 对 jvm 的支持，以及通吃前后端的特性。
kotlin 发展肯定不会很差

一般在这个目录下有个 chromedriver,可能会有差异 Appium\windows\Appium\node_modules\appium\node_modules\appium-chromedrive,双击查看其版本；去网上下到最新的版本（查看其支持的 chrome 版本) 覆盖掉此目录下的 chromedriver