• 建议每天自学到凌晨2点以上坚持完整个试用期。同时和同事们搞好关系。

  • 可以的。
    你可以查一下源码中的 org.apache.jmeter.report.dashboard.ReportGenerator 类, 是通过它生成报告的。
    调用如下:
    ReportGenerator generator = new ReportGenerator(reportFile, null);
    generator.generate();

  • 你好,可以到项目的issue里去提一下问题。
    需要看一下异常是什么才能确定到底缺什么包。

  • 愿意。
    极客时间我买过。
    一个同学的,互帮互助:
    https://www.jianshu.com/p/cd6388627f64

  • 高级岗位:部门Leader,或者团队Leader,或者核心测试开发岗位(至少是在某个领域,要有独立产出的) 。

    中级岗位:能独立负责一个项目的整体测试工作,常规来看,2-3年的从业者 。

    初级岗位:刚入行,或者入行1年左右 。

    这是引用过来的。

  • 仅楼主可见
  • 这几处代码是我当初没有放进去的。主要是因为最后一行:Thread.currentThread().setContextClassLoader(loader); 这会将当前线程的类加载器换成自定义的。
    Jmeter的自己的原有的启动类是需要这个的,为了将lib目录下的jar包的类加载到内存中,但我们平台是不同的,平台的环境里已经存在了绝大部分的类,没必要把lib目录下的所有的jar包都在每一个脚本执行的时候再加载一遍(应该还是占用内存的,即使重复也要来一套,没验证)。

    如果你非要追求Jmeter_Home的那种全量的环境,可以使用脚本模式执行,同时外挂influxDB+Grafana监控,这是满足你的需求的。

    当前平台还不打算搞的所有的lib包还要重复加载一遍。

  • 嗯嗯。也可以。
    我刚刚查了一下测试dubbo的。确实比较复杂。

  • 是吧,平台上传jar包这种操作,是测试自己掌握的。
    不能说平台的管理还搞一堆其他部门的人来染指,那就说不过去了。
    你说的包冲突,频繁上传,都是我们测试来掌握的。

    测试的jar包要稳定,可以先Jmeter工具自身测试验证后,再到平台上来,所以你说的平台频繁启动刷新JRE,是属于过度使用平台了。

  • 看来你这一下提了不少的需求啊,总体的数据结果分析+分布式节点的拆分利用。
    简单聊聊吧。
    数据结果table展示:
    当然这个我还没做,因为Jmeter提供的测试报告是包含这些的。
    你提的应该是抛弃测试报告的时候,这些聚合数据怎么弄?
    我可以给折线图增加这些数据的线啊,Jmeter传统的聚合报告的table展示是有弊端的,因为对比它,折线图不仅能展示趋势,还能包含历史数据,是更优的选择。
    目前我没做因为我用不到99%Line等,还因为没人给我提这种需求。

    分布式节点的拆分利用:
    这个比较复杂了,其实Jmeter自己对这个支持的就不好啊,想一想,如果单独用Jmeter,怎么利用多个slave?还不是要多个master。
    我的平台想要展示不同的slave集群的结果,还要基于Jmeter的API之上,其实是有难度的。
    这个地方我是有想法的,但是还没验证就不在这里说了。
    我的原则是能不改Jmeter的源码就不改,因为它发展的很快,改它源码不合适。
    是有想法的,嗯嗯,如果真有这方面的需求,是可以实现的。

https://www.jianshu.com/p/cd6388627f64
一个测试同学的,互帮互助。