• Jmeter 测试的一些技术 at July 15, 2021

    500 用户并发请求一分钟,实际的场景应该是我们的老师要上线上课了,大量用户登录并进入教室的场景,需求应该是不崩,且响应时间在几秒内吧,比如,5 秒?

    这个还是有点模糊。可以再具体一点,比如预计大概会有多少用户进入教室,进入教室是 1 分钟内全部进入完毕吗?响应时间几秒内这个和你们交互也有关系,按照你们 app 交互设计,大概几秒以上会有不大好的体验?个人理解,性能场景设计的终点,就是要摸清系统要达到多少 TPS 才能满足实际业务的需要。增加虚拟用户增大压力,只是会增加响应时间,也就是体验上变慢,实际系统 TPS 达到上限就基本不会再增加了,变慢的本质是请求收到后都进去排队,而非立即处理了。

    第二个问题,我问我们的开发应该是没有这种冷库机制,可能有分库分表的设计,但是我们的用户 id 都是递增生成的,我并不知道具体的分库分表逻辑

    建议可以去了解下分库分表怎么分的。如果是按照 id 区间分,那有可能新的 id 所在表数据少,查询就会快一些,具体快多少要看你的表数据多大,如果命中索引,一般速度差别不会太大。

    本质还是看重复 id 和非重复 id,背后执行的内容差异是否会引起性能差异,假设没有缓存都是落库查询,那就和你们数据库设计强相关,要看你们数据库设计上,不同 id 对应的查询,是否会有比较大的变化。

  • 暂时还没确定,预计 7-8 月会开始卖,请留意社区置顶帖和公众号就好。

  • Jmeter 测试的一些技术 at July 14, 2021

    ” 500 用户并发请求 1 分钟 “这种场景,是不是本身就是一个伪命题呢?

    这个严格意义不算是性能场景,因为没有响应时间的要求,没法反推系统的 TPS 需要达到多少才能满足。

    在不考虑缓存的情况下,我用同一个 userId,100 个线程同时请求登录接口,和 100 个不同的 userId 同时请求登录接口,制造的压力效果是一样的吗?

    有没有缓存只是一个方面,关键是看系统在重复 id 情况下,是否每次请求做的事情,和不重复 id 做的一样。如果一样,压力应该就基本一致。举个极端点的例子,100 个不同的 userId,如果放在同一个表,且数据规模基本一致,那基本上就是一致的。但如果背后是分布在不同的数据库表,而且有的放在冷库冷表里(简单点说就是查询速度会慢不少)。那即使没有缓存,性能表现也可能会有比较大的差别。

    个人观点,性能测试场景设计,需要尽量和真实场景一致是最好的,毕竟背后的系统深入了说涉及的东西挺多,比如查询结果的大小差异,也会影响性能表现。所以谁都说不准为了省事调整了场景后,是否会导致性能表现失真,尽量模拟真实场景反而是最简单有效的。

  • Jmeter 测试的一些技术 at July 14, 2021

    感觉你这个需求有点奇怪。

    一般都是通过性能测试并调整系统,来达到 TPS 50 的,你这样刚好反过来,是怎么调整性能测试方式,让 TPS 达到 50 。性能脚本只需要模拟真实压力场景即可,这样出来的才是真实性能指标。

    PS:我一般看系统 TPS 值,看的是虚拟用户数维持在一个水平的情况下,同一时间 TPS 的值。基本不怎么看聚合报告里的平均 TPS 值。

  • Selenium4 前线快报 at July 14, 2021

    Selenium 4 中的 IDE 不仅仅是一个基本的播放和记录测试工具。与 Firefox 一起,它可用于 Chrome 浏览器(作为 Chrome 扩展程序)。

    这句话读起来怪怪的,是机翻?

  • 第二个点认同。

    这个我觉得这个看实际需要把,各有各的道理。如果很关注入库正确性,最好是查下数据库。

  • Jmeter 测试的一些技术 at July 12, 2021

    这个情况,可以用 存草稿 功能来保存。

  • Jmeter 测试的一些技术 at July 12, 2021

    1、你说的同步计时器,是 Synchronizing Timer 吗?
    2、如果同步计时器,指的是上面这个控件,那这个场景只有 1 个请求,好像没有设置同步计时器的必要(单线程情况下,本身就是一个请求收到返回结束后,下一个请求才开始发出)。能否把完整的同步计时器配置发下?有尝试过去掉同步计时器吗?

  • Jmeter 测试的一些技术 at July 12, 2021

    是不是没写完?

    不明白为什么仅一次控制器控制登陆接口无效

    不知道你说的无效,指的是不是设置了仅一次控制器,但登陆接口并不是只被调用一次?如果是,我解释下,仅一次指的是每个线程里仅执行一次此动作,相当于 for 循环里,只有第一次循环执行,后续不再执行。与之对应的是默认每个线程循环执行所有动作,直到到达时间要求或者其他限制条件。

    如果你有多个线程,实际就会不止执行一次了。如果要线程数量无关地只执行一次,类似方案二这样的方法会更合适。

    有兴趣可以看下官方文档的说明:https://jmeter.apache.org/usermanual/component_reference.html?#Once_Only_Controller

    一般来说 TPS 跟并发数有关

    你这里的并发数指的是 Jmeter 的并发线程数吗?如果是,这个和我理解刚好相反,tps 和 Jmeter 的并发线程数无关,只会和应用服务性能有关。只是现象上如果并发数过小,会导致应用服务的各个线程并非持续处于负荷状态,所以计算出来的 tps 会比极限值小。“并发为 1” 和 “1 秒只有一辆车过” 是两个不同的概念,并发为 1,但服务器性能高,响应时间为 100ms,那 1 秒可以处理 10 个请求,一样可以产生 10TPS。

  • 这个具体要看你找的工作的 jd 要求了。

    个人常问的一般有几个,仅供参考:
    1、你用的这个 基于 robot framework 开发的一个第三方工具 ,大致的原理是?是否有可能搬运到新公司用?
    2、你使用的 UI 自动化工具(如 appium、selenium)背后的大致原理是什么,比如从 findElementByXX 到获得返回值,背后发生了什么。
    3、现有多少用例、一次执行大概多久、执行频率多高、稳定性多高?落地运行 UI 自动化用例过程中,对于提高稳定性,你之前是怎么做的,效果如何?
    4、你觉得你现在做的 UI 自动化,有哪些做得好的,有什么做得不足的,不足的点有什么改善想法?

  • 大多投递议题的,基本都直接发到投递议题的入口了,截止目前已经收到十多个议题了。

    这里没啥回帖不一定代表热度不高。

  • 看了下末尾的思考,有几个点说下我的不同见解:

    1、测试开发后续不会越来越少,只是纯做工具平台的越来越少。测试开发慢慢已经从工具平台开发,变为能运用技术解决测试效能问题的岗位了。往后更需要的是更强的解决问题的能力(能运用技术去解决本身就是更强的能力了),而不仅仅是开发工具平台。

    2、devops 方向,看描述更多指的是运维开发。这方面接触不多,不作评价。

    3、单独从技术方面说,个人觉得,大数据和 AI 在未来是趋势,尤其大数据(目前其实挺多公司的运营指标等都是基于大数据来出的了)。目前其实挺多时候大数据的质量还是没有特别好的保障的(报表延迟、内容不大对、响应报表需求慢等),只是现在直接基于大数据做比较核心业务的功能比较少,出问题也不至于是最高级别问题,所以不少公司还不大愿意投大精力去改善这部分质量而已。

    4、从个人发展角度,技术总归是有天花板的,而且由于技术发展非常快且颠覆性强(比如移动互联网,以前做服务端的经验放到移动端基本用不上),所以有些技术就算再熟悉,一旦过时价值就低很多了。所以如果放未来 5 年规划来说,更建议是走管理方向,或者至少是团队 leader 方向,这个天花板才更高。如果只是说 2-3 年内规划,选择有前景的技术方向也是听不错的。

  • 建议你找到你工作上需要用到什么,再针对性学习。比如现在 ui 自动化的落地还有什么问题需要解决,或者除了 ui 自动化还有什么地方需要提效,大概需要什么技术。

    学了但用不上,自然觉得价值低,而且效率也不高,熟练度也不高,成为不了真正的技能。

    比如我之前需要二次开发用例管理平台,就重新复习了 java,学习了前端的 vue+react。后面需要做云真机,又去学习了云真机要用到的相关框架工具(这个得靠自己调研和同行交流,没有啥现成的材料可以直接学习)。学完再用到,不仅更牢固,而且产生的价值也更高

  • 你这个立即停止,线程应该没法满足。

    1、目前应该没怎么提供直接停止线程的方法,大多是在线程内部执行时通过一些轮询来确认是否有停止记号,如果有记号就线程自己停掉,没记号就继续执行。
    2、另外,python 的线程由于解释器有 GIL 限制,和其它编程语言不大一样,实际并没法通过多线程用到 cpu 的多核性能,有点像是 伪并发 。所以 python 并行多任务大多用的多进程,多线程用得比较少一些,一般只会用在异步任务(比如等待网络 io)。不过看你这个场景应该用不着榨干性能,应该还好。

    你这个场景,建议可以考虑改为用多进程(multiprocessing)?多进程的话通过 kill 发不同的信号量,可以做到仅给退出信号(类似 ctrl+c),或者强制直接杀死进程(操作系统直接杀,进程自己没有拒绝权利,比较符合你说的这个要求)。

  • 啥意思?

  • Error: timeout of 240000ms exceeded

    意思是某个处理已经达到 240 秒(4 分钟)极限超时时间,但还是没有返回。

    背后可能是系统卡死、uiautomation 进程卡死等,这块需要结合 andorid logcat 日志才能分析定位。但和你 systemPort 应该没啥关系

  • 以下个人理解:

    数据仓库,属于大数据的概念,指的应该是存储基本所有待分析的有价值的数据的位置。一般用 Hive 等大型数据库存储。所有的分析报表都从数仓出来,所有有价值的业务数据最终都汇总到数仓存储。
    数据工厂,或者叫造数据平台,指的是测试过程中快速造数据的工具
    数据中台,属于大中台概念的一部分,指的是大数据的所有操作(包括数仓、数据处理、报表等)都集中到一个大服务中完成。日常的业务需求(比如新建一个报表,新接入一个数据源)都在数据中台中进行配置即可。与之对应的概念有业务中台、测试中台等

    至于数仓怎么测试,目前我也没接触过,但艾辉老师的《机器学习测试入门与实践》有大致提了下,可以看看了解下。

  • wireshark 可以抓到,但抓到你也不一定能解析或者模拟。它用的可能是自定义协议,或者类似 proto buffer 这类没有协议解析工具没法正常解析的协议。

    其实前面的同学已经给了几个可行的方案了,只是基本都绕不开开发的。推荐你还是找你们开发聊一下吧。

  • 这个理解没错。

    主要是支付的交互不是简单的一个接口就搞定的事情,毕竟涉及安全 + 异步(一般支付背后涉及很多方,耗时很难确定,所以都是做成异步式交互的),所以需要先搞清楚你们系统的交互。要不找不到对应在哪里 mock 掉它。

    另外,抓不到包应该不是因为加密,加密只会让你看不懂,不会抓不到(如果加密后会导致抓包工具抓不到,网络传输一样也会识别错误,因为协议本身定义的部分,怎么加密都是不能改的)。抓不到一般就是抓包方式和传输协议不一致了。

    比如微信 app 支付这种方式,下图这个位置的交互,很可能就不是走 http(据我所知,微信 app 和微信服务端,走的都是 tcp ,正常微信发消息的通讯交互,你用基于 http proxy 抓包的工具,如 charles、fiddler ,也一样抓不到)。

  • 有其它办法,比如直接仿照系统的业务处理逻辑再写一遍,开发怎么产生数据的,造数平台也一样逻辑去产生,但这么做成本太高了。

    相对而言,用接口等系统提供给外部调用的入口来造数,相对维护成本低不少。而且流程性接口用例本身就是自动化测试的产物,用来造数据属于水到渠成,也没有太多为了造数据而额外付出的成本。

    或者你也可以先分享下你们的现状,以及你们现在人工造数据大概是怎么做的?

  • 请描述清楚你的问题,插件的定义太广泛了。。。

  • 那就爱莫能助了,和第三方支付的交互一般都不止一处的,不找开发确认清楚交互,比较难绕过。

    或者可以试试用 UI 自动化来绕过呗。

  • 但不是每次点击都有内容输入

    有内容输入说明是有可能成功的。你对比看下成功的和不成功的,有没有什么差异?

  • 你有能力直接看项目代码来了解交互也可以,但问开发效率更高,而且后面遇到阻碍也容易找开发协助处理(比如鉴权太复杂,模拟成本很高,让开发开个可以跳过鉴权的后门,成本会低很多)。

    我理解这只是一个比较简单的合作而已,你们是有什么特殊情况,必须纯测试团队解决这个问题吗?

  • 我指的是你的系统交互,不是用户交互。即你们的业务系统是怎么和第三方系统交互的,涉及哪些端、哪些接口等。

    给你一个微信支付里的示例(只是微信支付提供的其中一种接入方式,具体你们怎么接入的,你还是问你们自己开发吧):

    https://pay.weixin.qq.com/wiki/doc/apiv3/open/pay/chapter2_5_2.shtml#part-5

    PS:微信 app 和微信服务端交互走的是基于 tcp 长连接的自定义协议,普通 http proxy 这种抓包是抓不到的。