“每个线程组线程数的比例,jmeter 原生本身会做控制,这个并不需要平台介入吧”,据我了解,Jmeter 本身控制不了比例,能控制的仅是数量。平台需要根据比例计算出数量,传给 Jmeter 让其执行。
这种解决办法也有吧,一个线程组一个脚本,多个脚本同时执行达到多个线程组同时进行的效果,这也是可以的,可以避开问题,曲线救国吧。
目前没做这么细。
每个 slave 执行的是相同的脚本,像线程数,步长等等都是一样的,本身 Jmeter 并没有 master 配置一个总的线程数,其他 slave 去平分这些线程数的概念(或者权重平分),都是 master 打算要执行一个脚本,其他 slave 都是按照这个来执行,这是两种压力设计,很明显你说的这种 Jmeter 本身就没有。
你说的这种其实要考虑的很多,比如一个脚本内配置了多个线程组,每个线程组的线程数都不一样,那你说的 “直到达到指定线程数量” 要做的就比较多了,比如要保持住每个线程组线程数的比例,要同步增加,或者说 “指定线程数量” 要细分化,即对每一个线程数都要有一个指定的线程数量,这样如果几个线程组还行,如果千百个线程组,你这要如何细分。这就是举个例子吧,意思是说实际要做的没有那么简单。
Jmeter 这种压力设计是有它的考虑的,我也认为是最省事的。
平台目前不想颠覆 Jmeter 的理念,平台的核心目前还是保持住 Jmeter 的所有特性,是保持,不是另立门户。
你好,感谢对平台的肯定。
定时任务这块如果是要结合 web 平台来做,肯定是需要代码量的,这部分我还没开发。如果是基于 Jmeter 的,那么使用 Jmeter-Home 应该是可以的(这你也试过了可以,感谢),因为使用 Jmeter-Home 的原理就是执行 Jmx 脚本,和使用源生 Jmeter 是一样一样的。
放弃 Jmeter5 是因为我当初在测试的时候,发现 Jmeter 5 对参数化文件支持的不好,具体我也忘记了,我们就是普通的使用回车换行的参数化文件,但那天是遇到了问题一直报请求失败,当时还没有调试脚本的功能,追查了很久发现回退 Jmeter 版本就没问题了,所以就一直保留 Jmeter4 的 api 方式,一直不升级。
以上是对你问题的一些回答吧,下面我扯点儿别的。
这个功能已经废弃。后续都删掉。
云服务器和本地服务器很类似吧。建议你本地搭完环境之后和你们运维合作,搭建阿里云服务器。
因为涉及服务器的开销价钱,用户权限,端口权限,磁盘文件大小等等。
虎躯一震。
代码 review 主观性很强,一人一个看法很正常。
所以这就需要有一个拿结论的人,一般是经理甚至总监,一个人就够了。
review 主要是看代码规范,如魔鬼数字,注释,过长的方法,公共方法的抽取,定义公共变量,是否按要求提示,异常的捕获,父类子类继承覆盖等等。其次还要看关键算法,举例比如是向后循环还是向前循环更优,用什么数据结构更好,是不是用多线程异步执行等等。还要看对系统的影响,比如内存占用是不是合理,内存回收策略,CPU 会不会高占用,对 GC 的影响等等。还要看架构的使用,比如查询比较这种可以直接使用数据库查询出来而不能程序遍历比较,常驻内存数据可以放到外部存储,异步队列执行,异常重启数据的恢复等等。
要举例的太多太多,往往你说的否定我写的,我否定你写的这类都是在代码规范上较劲儿,看着还是比较低端的。相信成熟的 review 中,整个 team 都会沉浸在技术的最优解上,劲儿往一处使,都会有收获。
但是这种 review 也有几个弊端,一是容易看出来一个人的水平高低,这对领导往往是致命的。二是比较费时间,节奏不好很容易开成大会浪费生命无意义。所以没有 review 我表示理解。
对于测试来说,review 都是开发自己的事情,我比较无所谓。
高 CPU 消耗是说 slave 负载机的瓶颈一般是 CPU,或者网络带宽。
master 可以是 Jmeter_HOME 也可以是 服务器进程,两者可以选择,可以配置。
我的平台主要是让 Jmeter 的单机或者分布式更方便使用,目前并不会提高性能。
Jmeter 无论单机还是 slave 就是一个 Java 进程,按照调优 JVM 的方式调优就好了。
没影响。
负载机是高 CPU 消耗的应用,除非机器 CPU 核心特别多如 32 核及以上,可以使用多进程,像你的 8C16G 的单进程就可以了,是没必要搞单 IP 多端口的多个 slave 进程的。
当然你们可以多尝试尝试。
查看结果树应该没问题,主要是另外两个监听属于插件,删掉就可以了。
平台自带监听,比 jp@gc 的监听要和谐一些(自认为功能也好了不少 )。
很燃,很棒。

作者说的很清楚,如果要用 locust 做高压力测试就堆硬件,毕竟硬件比人工便宜。如果硬件资源有限制,则推荐 Jmeter。
如果你在一个领域上没有做到出类拔萃,想换一个领域做到出类拔萃,这是很难让人相信的。
失败了再爬起来,在职场是非常非常非常难的,职业生涯建议还是滚雪球,雪球大了再换方向。
还有,你这是跳城市,比跳槽风险高多多了,基本跳城市的都要从头再来。
你这在跳城市中属于正常现象,希望你的信心还要保持,别灰心,要坚持。
头回听说还有弄的细了不行的。
接口测试,你就是往最细了弄实际上也是粗的。
严格要求自己吧。
用例设计这块也分主次吧,核心功能先过了再说。你说的那些什么传错类型等等的边界,可以和开发一起看一下代码实现,假如开发使用的公共方法都校验过了,那么对于重复逻辑的测试负担会减轻不少,可以将这部分测试职责放给代码的审计/review 上,靠开发自己的代码质量来保证接口质量。
腾出时间后,赶紧把@Jerry li 所说的实现了。
看了半天没看到有核心竞争力,缺点却显而易见。
产品也搞了好几年了,没见你介绍自己引以为傲的产品介绍,诉我直言,你在公司里一直是小白兔吗?
你想到的危机都是很对的。
送你个建议吧,越是迷茫越要学习。
你的学习强度还是太弱了,什么时候像高三的学习强度,你就能找到工作了。(注意是学习不是加班)。
和人沟通讲究先抑后扬,你上来就委曲求全开发真就合计你是舔狗了,就像谢娜怼她的官方粉丝一样,以后往死了用你还鄙视你。
不是说这些话术不对,而是有点儿太 low 了。
以我的做法,肯定是要喷这个开发,让他知道我们测试不是好惹的,然后做人留一线日后好相见,抬一手,然后这个事情最好让自己领导和开发领导都清楚过程,把事情做漂亮。
还开发私自提交搞出 bug,测试还要一起加班,也太 low 了,测试可以加班,但是不是你开发让我加班的,你能给我调休或者加班费吗,你有这个权力吗,我就没有其他事情了吗,这种事情肯定要搞到各方领导都知道的,要不然师出无名。
最后,建议这种公司的测试注意自我学习,提高自身能力,及时跳槽,因为能搞出这种话术的,连基本的心理都搞不明白,说白了就是连舔都不会舔,啥也学不到。
舔开发没用,要舔的是 KPI,共勉。
学习了,想到了几点:
其实我觉得,测开往往就是一个兼职的岗位,平时的主要工作还是各种实际落地的测试任务,测开的工作往往是测试人的锦上添花,因为你脱离了测试任务和全职测开可能会造成闭门造车的尴尬。
同时全职的测开岗位还需要有产品经理吧,是整个一套的项目开发流程的,评价全职测开的 KPI 就和评价开发的 KPI 几乎一样了。
这也分岗位分工的。
可能我要说一些不一样的。
开发的兄弟还是很心虚的,所以请你吃了饭。试问一下,如果问题砸下来,你不离职,那这个雷就是开发扛了。
你周围的人不会告诉你实情的,哪有那么简单的弱网络环境更新不了,异常在哪里打出来看看,网络到底弱到什么程度会出问题,网络好了能不能恢复更新,开发是不是换东西了导致问题,强制更新失败后为什么不能回退到之前版本让基本功能可用。
你这周围也没啥牛人也没啥好人,都是江湖客,没啥伤心的。
JAVA 的内存释放也不是绝对的,相互指向是无法释放的; ----这句还是斟酌一下吧,早就没这个问题了。
了解一下 treeMap,直接就是排序的。
这道题应该直接就很暴力就行了,得到 csv 方格中的内容后,就使用正则表达式匹配统计数量。
原因是 3 个统计词循环次数很少。
注意的是 csv 文件的编码格式要和统计计算使用的编码格式相同。
读取 CSV 文件,甚至可以直接用读文本那种一行一行读就可以了,不用考虑方格格式。
这道题可能是要问你对分词的理解(solr,lucence)。
不过以你现在所述,还用不上分词。
看一下 Sentinel,应该直接满足你上面这些。(https://mp.weixin.qq.com/s/yCRPr_U0XlBMoVLTXNFj4Q)
另外广告一下,多谢:
https://www.jianshu.com/p/cd6388627f64 一个测试同学的,互帮互助。
如果真是垃圾,那不说 5K 了,5 都是多了。
首先这个教程好不好不是宣传出来的,建议可以把提纲教案列出标题,大家看一下。
其次放出来一些体验课,让大家体验一下。
建议靠口碑把教程发扬光大,而不是靠扣帽子。
教材/架构素材是基础,老师也很关键啊,就比如梅西和武磊同时教足球,价钱肯定不一样。
老师多少也介绍一下吧,看看这 5K 到底花在了哪。
线上的课程太多了,而一般不会这么贵的,有些蹊跷啊。
https://www.jianshu.com/p/cd6388627f64
一个测试同学的,互帮互助。
服务器进程内启动 JMeter,意思是使用 Jmeter 的 API 来启动脚本。

能解释一下是什么意思么?