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

  • 关于测试用例 at 2019年12月04日

    使用什么方式去写用例倒没规定,用 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