• 这种根本都不叫坑,一个界面显示而已不影响jmeter的丝毫使用,看上去不好看而已。
    jmeter如果真正看过每个菜单,知道每个菜单下大概是什么东西,根本都不会问这种问题。
    这就是jmeter跟本都不熟悉,看到一个问题,就想着问,不想着自己去看看可能是什么原因。
    很多问题jmeter本身就有解决方案,只是看你懒不懒愿不愿意自己花功夫,而是等现成的

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

  • 关于测试用例 at December 04, 2019

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

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

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

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

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

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

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

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

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