测开分享会第七期(不同角色快速熟悉性能测试的秘诀)

2022-04-07 10:13:09 浏览数 (1)

在这周一我们举办了测开分享会第七期,现在就由芒果为大家整理这次分享会的知识。本次整理内容包含我们的V咖范斌老师的分享内容,部分提问及回复,还有一部分小伙伴的讨论内容。想要提问或者观看完整问题解答的小伙伴,请积极参与到我们分享会中来,我们的分享会每两周就有一次哟~

分享人:范斌

范斌(FBI),10年性能测试交付、8年管理经验及2年性能测试平台研发。长期致力于性能测试业务模式的拓展及性能测试产品研发工作。目前主要为互联网和传统客户提供测试咨询和测试服务,研发推广性能测试平台。从2008年到2015年,主要负责金融行业的性能测试服务交付和企业内部性能人员团队管理。多次担任性能测试经验分享沙龙嘉宾,同时做为多家培训机构性能培训讲师,深受学员喜爱。

分享主题:不同角色快速熟悉性能测试的秘诀

说到性能测试,大家都认为它是一个角色完成的工作,其实它需要不同角色的参与。同时每个角色在整个过程中要求掌握性能测试相关知识的侧重点是不一样的。如何快速的掌握不同角色需要的性能测试知识呢?本期将会给大家一一分解,从功能测试人员,开发人员,项目及测试经 理类的管理人员,运维人员等,在工作中快速掌握性能测试知识的秘诀。

部分PPT:

答疑与讨论:

雪儿欢:

范老师,刚才说代码方面开发更熟悉,而环境方面运维可能更熟悉,数据库有DBA,那么性能测试工程师的调优是在那些方面呢?

范斌:

那对于的性能测试调优这块来说,其实有几个方面,一个是调优一些思路,我们能够从发起到整体,能够通过性能指标来分析性能问题可能存在的点在哪里。另外一个我们做过一些统计分析,很大部分的性能测试的问题其实都在一些基础参数的一些配置,这个我可以找一些图看看。

上面两张图,其实一张是可以调优的一些方向,第二个就是说我们看到的是调优的一些具体的数据分析。其实我们也可以看到可以参与的,计算机的应用层的,包括操作系统层的。其实我们都可以去做一些分析,完全是不需要开发或者说其他类型的参与。关于操作系统成方面的,其实是可以和运维一起去沟通这一块的内容,包括基础应用软件承担部分。

雪儿欢:

就是拿到指标后,性能测试人员分析大概在那一块有问题,推动相关人员改进的意思么

范斌:

@雪儿欢 部分我们可以做调优的,我们来完成,在特定领域的让其他人员来解决。我们的目标是高效配合好去完成。

雪儿欢:

OK 谢谢老师

moon.sun:

性能测试在功能测试完成之后,性能测试版本是不是应该从功能测试人员那里过去?

范斌:

性能测试过程中,如果有代码的改动可能。功能测试肯定需要去回归的,我们以前做项目就发现,改了那种以后性能是很好,但是功能就存在问题,所以还得回滚。

张露露:

@范斌 范老师重复测试数据对性能测试有影响吗

范斌:

@张露露,尽肯能多的使用不重复的数据,如果只从缓存中获取,那肯定性能会更优的。

策风小k:

@范斌 范老师 对于中途才介入做性能测试的项目,有没有好的切入点?比如如果时间不赶,我们是不是可以先铺性能基线测试这个点着手再慢慢按需开展其它性能测试活动?

范斌:

@策风小k 是指中途要做性能测试?

策风小k:

嗯,对。我想是先做基线,至少了解每次版本迭代性能浮动情况。

范斌:

策风,你是说你这边这个项目突然要做性能测试了,对吧?然后你觉得什么时候切入去做?是这个问题吗?

其实我们在做很多项目的时候都是,没有整体的规划。比如说,我这个项目突然间需求变动,然后可能要设计到性能测试了,然后他就会去提要做这个性能测试。

那如果说你这个系统长期是变更的,那其实我觉得就像你说的,可能在这个系统上线之前或者说在开发完以后可能会做一个极限的测试。那每次变更以后可以根据具体的内容去做一些回归。这个在相同的这种环境下,看对系统影响有多大,看变更后变更的对系统影响有多大。

策风小k:

是这样,我的这边的一个项目呢,就是希望能够开始做性能测试,但是这个也不急,所以我想把这边的一个规划,先做一下。我们如果是中途介入这样子的一个性能测试的话,我应该去怎么从层面上去入手?像我的话,我希望是,一开始先把机械的一些指标先做出来,然后在各个产品线当中去把这块东西推出去,把极限测试最快推出去。然后至少在这个层面上,每次版本的一个迭代我能够了解这个迭代的一个性能的一个浮动情况。那么这是我想第一步切入做的一个事儿,不知道这样子的一个思路可不可以?

对,因为如果是现在是要去开展其他的像压测,或者其他的稳定性的一些测试。我觉得在频率上可能没有做基线测试这么高的一个频率,因为我们毕竟敏捷的一个团队。版本发布相对频繁吗,那么相当于一个压测来讲的话。我不可能这么频繁的去做压测,对吧?从使用的程度上我觉得阿基线为切入点的话,可能对于我现在来讲的话应该是更加合理一点吧。

范斌:

我觉得你这块的就是说,如果你要一个整体的规划,但是不知道什么时候这个系统要做压测,其实是可以做一个基线的测试。其实现在现在有很多的企业,他们其实也不是说我这个系统马上上线的或者什么,就是因为我这个系统已经运行很久很久了,但是我也不知道它的性能。其实他更准确的是想了解我现在涉及到这些系统的性能是容量都是怎么样的;那如果我再做变更以后,能不能满足我新的需求的。这时候我再去做一次性能的回归,这样的话可以。一是想了解性能能否满足需求,另外的话,至少在之前的基线技术上,了解我们系统的伸缩性是如何的。

其实我们性能做的,最主要的还是模拟业务场景这种方式测试。单个接口的并发,其实如果开发了完成我们当然希望开发自己去做掉。或者说如果开发没有时间,我们还有平台,其实也可以通过平台更快的去从技术上了解这个接口,或者说功能的单个并发的情况。

真正业务场景的模拟这种是需要去做分析的,而且这块是根据你的业务的变动,不断的去调整你的业务的场景的比例,这样才能更真实去模拟生的一种情况,这样的话压测的结果才有更好的意义。简单说就是说,比如说你有个功能,其实用的不多,如果说你非要提高他性能。我们一般情况下不会去做更多的优化,因为你在使用过程中,其实它本身涉及的就很少。

策风小k:

嗯,谢谢,明白的。

明镜止水:

@范斌 范老师,请问想成为一名合格的性能测试工程师,需要了解哪些知识?

范斌:

@明镜止水,你的问题,我回头发一个表。这个里面还有很多其他的技术是没有写进去的,主要是看下相关条例,仅供参考

0 人点赞