根据压测的场景不同,或者压测的目的不同,我们会选择不一样的压测方式来进行压测,我梳理了下大概的压测的方式,主要有以下三个。
最近一直有人在QQ群或微信群或直接问我关于性能测试实践过程中的一些问题,归纳起来大体侧重以下几个方面: 看不懂或是没看报错信息 工具使用不熟,对很多参数的含义及使用乱用 不会分析具体的接口报文 不会做监控分析 这是这段时间,大家问我的一些问题分类。 我们先来看一下怎么做性能测试 系统的网络拓扑, 在没搞清楚网络拓扑前,请不要说你要做性能测试 目标测试场景在各服务间的数据流或各服务的调用关系 拥有目标服务的相应权限,例如安装、执行某些监控或分析工具的权限、以及修改配置的权限 梳理出目标测试场景
我录制了打开网页的脚本,脚本中只有打开网页一个操作。在脚本中设置了集合点和事务响应时间。在场景运行的时候,可以一次加载50虚拟用户运行场景或者每5秒加载5个用户,共50个虚拟用户运行场景。想要知道这2者的差别。注意:场景设置中设置了Run Until Completion,50个虚拟用户打开网页之后,场景会停止运行。
去年年底开始,很多测试人员抱怨互联网寒冬来袭,抱怨找不到好工作,抱怨要求高,但是我发现,技术好的,找工作甚至找到非常不错的工作还是很轻松的。所以,还是要自身实力强,打铁还需自身硬。
性能测试对于大部分测试人员都是一个神秘地带,因为在很多公司,性能测试都是由一个性能测试团队来做,所以普通测试人员没有机会接触到真实的性能测试,因而很难学习到很多新的测试实践知识。
最近找我咨询性能测试问题的同学挺多,见识了不少案例,发现很多同学对性能测试依然存在很多理解的误区,即使是一些在测试岗位工作多年的资深工程师,依然存在这种情况。
关注“应用程序”的性能,此处的“应用程序”指的是应用程序的所有部分(硬件、操作系统、系统架构、中间件、应用程序、网络等),而非指某一部分。
之前的文章聊聊性能测试开始前的准备工作,聊了一些关于性能测试开始前要做的准备工作。
上一篇文章聊到了性能测试最基本的三个术语:并发、TPS、响应时间,并且以高速收费站的故事为例,详细的分析了这三个术语在实际的应用实践中该如何理解,以及三者之间的关系。
对于一般公司普通测试工程师来说,可能性能测试做的并不是很复杂,可能只是编写下脚本,做个压测,然后输出报告结果,瓶颈分析和调优的事都丢给开发去做。
最近遇到了两个关于性能测试的场景,发现有三个很多人理不清楚的概念:TPS、并发数及线程数。这三者到底有什么关系呢?其实概念是相对简单的,但是在使用的时候,往往会有很多混淆的情况出现。
确定测试范围一般在测试需求分析完成后进行,所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验,有助于在早期阶段发现潜在的测试遗漏;
最近和很多测试同学交流时,发现大家对性能测试基础的一些知识理论比较欠缺,导致在实际的工作实践中遇到了很多不好理解的难题。因此最近在重写性能测试基础理论知识相关内容,也算重新整理自己的思路。
性能测试已经是一个老生常谈的话题了,不同的项目或多或少都会涉及到,但是每个人的经验肯定有所不同。今天我想从以下几个方面分享一下我认为关于性能测试需要重视的要点。
前几天在北京出差时候,微信群有个同学问了一个问题,为什么800并发压测,服务器还没有报错?当时群里其他同学提了很多观点,比如:
按照JMeter官方要求,所有的测试必须在命令行模式下运行,并且在负载测试拐点处、疲劳性测试、强度测试下使用监控工具监控被测端与压测端的状态。 建立性能测试元件 关于性能测试的知识可以参阅我的另一本著作《全栈软件测试工程师宝典》中的第3章内容 1单功能性能测试搭建步骤 1)打开ebusiness_login.jmx。 2)在最后加入一个登出HTTP请求,如图1所示。
昨天帮星球一位同学做了面试求职分析,沟通过程中我问了他一个问题:如何分析性能需求?得到的回答在我看来是存在一些不足的,考虑的不够完善。
系统往往存在不可确定性,因为你无法从当前稳定的状态来判断或者认定系统未来也是稳定的。世界是复杂的,系统具有不可稳定性的状态。这样的案例比比皆是,如某云计算服务厂商大规模瘫痪等等案例。对质量交付团队而言,最大的挑战应该是如何可以让系统持续地具有可稳定的状态。虽然系统具有不可预知性和随机性,现实的情况往往是底层服务出现不稳定性导致上层应用不可以正常地使用,此时往往或者是大多数时候认为是测试没有测试到位导致产生的问题。如假设底层支付的服务出现资源瓶颈,最终导致正常的支付流程出现问题,某些管理者会很偏见的认为质量交付团队没有把某些支付测试场景验证到位而导致的问题。
春节假期响应号召原地过年,抽空看了看一些优秀的工具,选择了一两个进行了更深入的使用,其中一个很重要的就是draw.io画图工具,之前用的是网页版的,现在用的Mac desktop版本。顺便说一句,现在这个工具的网页版有了新名字,叫diagrams.net,但是桌面版用的还是老名字,目前好像没有中文名,团队起名字就是域名,也挺有意思。
上一篇文章聊了如何快速上手压测工作的几个切入点和注意事项,这些内容可以帮助我们更快介入项目。但实际工作中,前期的准备工作也是很繁琐的,其中测试环境和测试数据的准备是前期准备阶段的主要工作。
这是之前介绍过的性能监控平台的整体架构图,想要了解其它部分的搭建,可以查看相关文章《Telegraf安装与简易使用指南》、《InfluxDB安装与简易使用指南》、《Grafana安装与简易使用指南》
测试万能公式:功能测试+兼容性测试+界面测试+性能测试+易用性测试+网络测试+安全性测试. 每个维度可以说四个及以上的测试用例.
关于性能测试之前写过两篇文章,分别讲了新人应该如何自学性能测试以及如何开始上手进行压测,确定目标TPS,参考文章:
我曾经在1月底的时候因为一个随意的想法,去了解了下关于『响应式编程』的一些概念,并且无意间看到了Vert.x
最近有些同学找我咨询关于性能测试计划相关的问题,原因是他们公司要做性能测试,Leader要求写一份性能测试计划,苦于之前没做过相关工作,无从下手。这篇文章,结合我个人的一些经验和总结,聊聊如何制定一份较为全面的性能测试计划。。。
无意中发现了一个巨牛的人工智能教程,忍不住分享一下给大家。教程不仅是零基础,通俗易懂,而且非常风趣幽默,像看小说一样!觉得太牛了,所以分享给大家。点这里可以跳转到教程。
关于性能测试,主要是针对哪个函数调用过多,或者占用太多内存,或者导致太多的磁盘和网络I/O 首先是IPython的%timeit和time.time()两个函数,他们可以用来计算语句和函数的运行时间。 1.cProfile,这是一个内建工具可以看函数的运行时间 2.line_profiler,这个更加细节,可以关注到每行被调用的次数以及每行花费的时间。 3.perf stat命令可以了解最终执行于CPU的指令的个数和CPU缓存的利用率 4.heapy模块,可以追踪内存中的所有对象,这是为了解决内存泄漏,即使是引用计数,也不可避免一些奇怪的内存泄漏。 5.memory_profiler,可以以图的形式展示RAM的使用情况随时间的变化 最后更重要的是,要学会阅读字节码。在优化性能之前,请注意保持代码的正确性。 一些小细节在于,你应该学会将代码需要的任何管理性工作都放在初始化去做,比如内存分配,读取配置文件等等。 在了解这些行为后,可以选择合适的方法去处理问题。 让我们在看看几个python的解释器. 1.Cython 2.Shed Skin 3.Numba 4.Pythran 5.PyPy 其中Cython,Shed Skin,Pythran是基于C的编译,Numba是基于LLVM的编译,属于AOT编译,而PyPy则是代替了虚拟机,还包含了一个内置的JIT。 这建立在一个很重要的前提,这些工具都会提前帮你做好类型检查,这样python内部就不需要做太复杂的类型检查了,自然效率就提高了。
就在几天前,有个同学加我微信,当然我并不惊讶,甚至习以为常(因为总有人加我微信),为什么呢?
性能测试这种测试方式在发生过程中,其中一个过渡性的工作,就是对执行过程中的问题,进行定位,对功能的定位,对负载的定位,最重要的,当然就是问题中说的“瓶颈”,接触性能测试不深,更非专家,自己的理解,瓶颈产生在以下几方面:
本期内容承接上期性能测试误差对比研究(二)及时上上期性能测试误差对比研究(一),脚本采用与(二)相同,原因不赘述了。今天终于要把坑填完了,想想都有点小兴奋。(PS:其实还有四)
作为一枚测试,或多或少都做过or听说过性能测试。说到性能测试,第一印象可能是高大上,因为它涉及到评估系统的性能、稳定性和可靠性。确实,性能测试水很深,如果玩得比较溜就能发展成性能测试专家、架构师级别。
最近刚入职新公司,忙着适应公司的文化、工作流程的一些东西。因为部门要开发性能测试管理平台,今天邮件中我也对性能测试平台的设计提了一些自己的想法。
很多工作两三年的同行都跟我说,认为性能调优没什么用。刚工作的时候我也这样以为,但后来我才知道我当时想法多么的天真。
有做测试的小伙伴留言,说做测试太苦了,问有哪些测试类书籍推荐?今天我整理了测试类的书单。
关于压测这块讲过很多次,我在viptest&七牛云、testerhome&得物等一起举办的企业级沙龙也讲过全链路压测相关,这次直播的主题是老张群里粉丝投票选出来的,可见大家在公司性能落地层面依然存在种种困惑,在直播前,小牛同学也跟我聊了线上压测落地的痛点,小牛目前在一线互联网公司,他给我的感觉是在一个成熟的公司,只要你不停的思考依然可以做很多改进。从我个人实践来看,现在无论是执行、监控、或者是定位配套方案都很多,但对于很多同学来说还是很迷茫,性能测试从执行层面我认为并不难,我觉得有以下几点原因导致不少人不能上手。
DataFactory是一种强大的数据产生器,它允许开发人员和QA很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle
● 稳定性、可靠性、持续性。因为它是一个分布式的网络架构,没有一个中心节点可以被打击或者攻击,所以在整体的技术布置方面有着更强的稳定性、可靠性和持续性。
大家所熟悉的性能测试工具有Loadrunner、JMeter,以及其他小众一些的工具,如Locust、Ngrinder、Gatling等等,那么你们知道这些工具有什么不同吗?为什么有的工具能模拟数千上几万的并发,有的工具单机只能模拟一两千的并发,这其中的原因是什么呢?那么这节课我就来告诉大家,你所不了解性能测试工具的一面:并发模式。
随着5G时代的到来,以及万物互联时代的到来,云应用和云服务会越来越多,数据量会指数级增长。尤其是2020年全球疫情的时代意义,会导致各行各业开始上云。从而会催生出极具个性化的各类产品的诞生。
前面系列已经讲完了硬件选型、部署、调优,在上线之前呢需要进行性能存储测试,本章主要讲述下测试Ceph的几种常用工具,以及测试方法。
现在DevOps已经成了一个非常热门话题,但是又有谁真正理解了DevOps,可能少之又少。上周聆听了茹炳晟老师的在线课程,通过一张图我才发现真正理解了DevOps。
xLua是Unity3D下Lua编程解决方案,自2016年初推广以来,已经应用于十多款腾讯自研游戏,凭借其出色的性能,易用性,扩展性而广受好评。现在xLua开源到github上,希望能对游戏行业有所贡献。 xLua的几项突破 xLua在功能、性能、易用性都有不少突破,这几方面分别最具代表性的是: 1、Unity3D全平台热补丁技术,可以运行时把C#实现(方法,操作符,属性,事件,构造函数,析构函数,支持泛化)替换成lua实现; 2、自定义struct,枚举在Lua和C#间传递无C# gc alloc; 3、
关于性能调优,我先来说说我的感受。Java 性能调优不像是学一门编程语言,无法通过直线式的思维来掌握和应用,它对于工程师的技术广度和深度都有着较高的要求。
项目名称: 某某系统 使用背景: // 用户 协会分会负责人、期刊客户 开发者: 中文集团 测试版本 2.0 项目简介: 学术专著出版平台” 定位是一家图书产品联合创建、销售、返利的平台;平台联合各专业协会、学会、出版社等机构,组织大批专家人才建立“专家指导委员会”,为图书进行策划、上报、审校、出版、运营等服务;主要业务情景是:策划人寻求参编人,共同创建图书及销售,参编人支付参编图书的预购款,该笔资金作为公司运营图书的成本,等待图书出版后,让消费者以个人名片或链接的形式进行购买图书,参编人员不仅可以通过图书评职称、扩大知名度、传播学术价值,另外让参编人通过销售,实现“0”元出书并且获得额外收入;策划人在发展参编和策划人同时,获得相应奖励。
在之前的文章中,关于性能测试分析这块,我贴了一张图,推荐大家可以基于ELK进行日志数据分析;在微服务架构下,ELK是最常用的日志采集存储组件。但不少同学只是听过,对于具体是什么,怎么用比较迷茫;这一篇我从测试开发的使用维度来介绍下ELK。
大家好,我是CC,这是第106篇原创。 在之前的文章中,关于性能测试分析这块,我贴了一张图,推荐大家可以基于ELK进行日志数据分析;在微服务架构下,ELK是最常用的日志采集存储组件。但不少同学只是听过,对于具体是什么,怎么用比较迷茫;这一篇我从测试开发的使用维度来介绍下ELK。
领取专属 10元无门槛券
手把手带您无忧上云