性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)

Posted 软件测试和生活

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)相关的知识,希望对你有一定的参考价值。

解读自己实践的真实项目性能测试,及性能测试报告的产出逻辑,包含SQL解析、进程状态、性能测试执行,和报告产出思路


朋友们知道我做过的性能测试项目多,所以,时常会问我帮忙解决工作中,遭遇的性能测试问题


解决问题的过程本身是一个深入学习的过程


回想过往,若是要在功能测试、自动化测试、性能测试、安全测试,这4个领域选择一个,我觉得自己最擅长和带给自己最多挑战和成就感的是:性能测试


年龄大了,不知道外面的世界怎样了,但有些,是可以以不变应万变的

套用现在很时髦的词,我管“这些”叫:性能测试的思维

或者理解为,性能的本质,以及测试的本质


本篇我将结合自己的真实性能测试案例,把我理解的性能测试表达出来(仅代表个人观点和认知能力,不敢班门弄斧,望大佬们不吝赐教)


本篇内容:

  • 性能测试报告的下载

  • 参数化 & SQL解析

  • 执行时机 & 进程的状态

  • 性能测试环境 & 网络

  • 编写性能测试报告



性能测试报告的下载

链接: https://pan.baidu.com/s/1Rth9c_YVy-APUcbLZi0Mhg

提取码: wuzx

在【性能测试】文件夹下,对应的文件名:

《golang版主控程序-性能测试报告.pdf》


如出现网盘链接失效情况,可在后台回复【1】或戳【免费资源】获取更新后的下载链接,如下图所示:

性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)


有关项目背景、分析、测试环境、监控指标、场景执行等,在性能测试报告上已有呈现,不再赘述


性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)


参数化 & SQL解析

在报告的第1节【概述&分析】中,得知业务功能涉及数据库的查询,关于索引的性能我在之前的文章已有描述,参考:

《》--- 学习mysql的索引和存储引擎,验证索引的性能,和数据库调优的基本原则


根据调优原则,code作为常用到的where字段,最好在该字段上建立索引,且结合公司业务,药品信息通常是固定的,建议使用MyISAM存储引擎


数据容量非常少,才800多条数据,测试对象是一台设备的主控程序,没有并发,所以场景执行只设置了1个虚拟用户(是的,有的性能测试没有并发)


重点说下参数化,虽然不参数化,在业务上也能通过,但这涉及SQL语句的硬解析和软解析,所以,为了达到更加贴合实际应用场景的目的,我在脚本中对数据进行了参数化处理


SQL语句发送给数据库服务器,数据库服务器要对SQL语句进行以下这些过程的处理:

  • 语法检查(syntax check),检查SQL的拼写是否合法

  • 语义检查(semantic check),检查SQL语句中的访问对象是否存在及该用户是否具备相应的权限

  • SQL语句进行解析(prase),利用内部算法对SQL进行解析,生成解析树(parse tree)及执行计划(execution plan)

  • 执行SQL,返回结果(execute and return)


然而,在上述第3步,对SQL语句进行解析的过程,数据库服务器会利用内部的hash算法来取得该SQL的hash值,然后在library cache里查找是否存在该hash值


如果存在,则将此SQL与cache中的值进行比较


相同,则利用已有的解析树与执行计划,从而省略了优化器的相关工作,即进行软解析的过程

否则,优化器将进行创建解析树、生成执行计划的动作,即进行硬解析

创建解析树、生成执行计划对于SQL的执行来说是开销昂贵的动作,所以,应当极力避免硬解析,尽量使用软解析

所以,我们在进行性能测试时,如果涉及SQL语句执行,就算不影响业务执行,能参数化的也尽量做参数化处理


p.s.有些业务必须参数化,比如注册的用户名,不允许重名,必须参数化处理


性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)


执行时机 & 进程的状态


再看性能测试报告中,第4节【场景执行要求】,有很多步骤我说明了要放置2min,待CPU和内存的波动趋于平稳,有些部分甚至要求重启


其实,这涉及进程的创建流程和状态知识


进程(Process)是计算机中的程序关于某数据集合上的一次运行活动,是系统进行资源分配和调度的基本单位

进程,是程序在计算机中的一次执行过程


进程在处理器CPU内核上交替运行,状态不断地发生变化,常见的进程状态划分方法,有【三态】和【五态】,下图是【进程的三态模型】


性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)


进程的【五态】是在【三态】的基础上,多了【新建】和【终止】这两个状态


每台计算机上都运行着很多进程,所有的进程都要“争夺”处理器CPU内核完成对应的操作,处理器CPU内核划分了很多时间片,那么,从进程的状态变化上看,服务进程刚启动,往往会由于没有立即得到分配的时间片,而处于【就绪】状态而非【运行】状态


另外,服务进程的初始化,也要耗费时间和计算机资源。如果服务进程还处于【就绪】状态,或正处于初始化状态,我们的负载压力就已经到达并要求服务程序响应,那么,测试结果肯定会有偏差,并且,执行时机也不好把控和重现


当然,处理器CPU内核是很高效的,切换状态的时间非常短暂,可能对我们的性能测试结果并不会造成什么影响


总之,为了尽量避免不必要的干扰项,我们最好按照固定的步骤去执行我们的性能测试。所以,我的执行步骤会有要求重启,和放置2min待CPU和内存的波动趋于平稳,再进行执行性能测试



性能测试环境 & 网络


肯定有小伙伴和我一样,遇到过这样没有需求、没有指标、没有参考数据、没有环境等等的性能测试项目


如果有在行的领导和同事或先例,工作进展肯定能顺畅不少

但是如果没有,我们一定要和派发给我们任务的上司,多沟通,了解上司让我们做这件事情的真实需求是怎样的,目标是什么


有了明确的需求,我们才能更好的知道,选择哪种手段去达成这个目标。就像我之前在一本书中看到的:


老板让你买张票,你要知道老板的目标是,去客户的公司做培训

知道了目标,如要确保老板明天能够准时出现在客户公司做培训。那哪种手段方便有效就选择哪种,比如坐飞机去可能需要当天晚上客户派人接送,这就要求跟客户公司接洽好,别出现老板飞到对方的地方,茫然四顾无人接洽的情况,还有住宿问题,也需要沟通。火车则可能晚上睡一觉就到了,实际可控和有保障

如果没有任何一种手段能够保障老板明天准时到达,就得跟老板汇报,然后提出建议,是否跟客户沟通改时间

这才是真正知道目标是什么


将手段当作目标,或代替目标,是我们常见的错误,这就是把动作当作了目标,而没有理解动作的目的

我们很容易把目标搞错,比如读书本来是为了增长见识,提升认知,但不知不觉间,把书读完变成了目标


回到我们的性能测试项目,对于我们要进行性能测试的服务器,和我们所用的负载机,我们一定要做到心中有数



一定不要这么鲁莽,磨刀不误砍柴工


性能测试环境,最好是我们自己来搭建和部署,要到服务器后,如果是个大虚拟机,我们可以自己重做虚拟机,让机器仅供自己做性能测试使用,尽量去贴合实际运行环境的配置和架构部署


我做的这个性能测试项目,主控程序的运行环境是Windows的,所以我找了一台相同配置的机器


对于负载机,一定要和服务器分开如果测试目标不涉及模拟实际网络场景,最好保证服务器和负载机在同一局域网内,或者贴合实际网络场景


我办公的Mac电脑是WiFi连接,用作负载机。Windows电脑用作服务器,是网线连接,如果直接运行,网络肯定是通的能运行。但我最后用的是网线,尽量让网络符合实际运行场景


p.s.在公司里面,如果你的电脑WiFi连接可以百度,网线连接发现怎么样都百度不了,不要抓狂,试试能不能ping通你的服务器,如果能就说明网络是通的,只是不让你访问外网而已,比如访问外网百度(具体原因可以咨询公司网络相关的同事~)



编写性能测试报告


以往写性能测试报告,我会从网上下载一个合适的模版,电脑上也囤积了不少,放灰,但又没有断舍离清理掉


面对一份报告或一个工作任务,我们不免有些完美主义,亦或是出于证明自己的愿望,希望把事情做好,做漂亮~


但由于之前的积累和功底不够,在爬取Mr Right的过程中,时常被搜索引擎茫茫的信息量所淹没,耗费了大量的时间,并且效率低下,反而还得不到很好的产出结果


完成比完美更重要


回顾性能测试报告的编写,我觉得没必要过多受限于报告模版的框架,我就想着怎么写能够更清晰地表达自己的观点,怎么写更容易让该测试报告的读者理解


我们要有自信,我就是我自己的Mr Right~


把握住,我的这份报告的目的是什么,给谁看,要体现什么样的过程,得出什么样的测试结论,下回同事按我的报告和思路进行测试,是不是可以得到同样的测试结果

简洁,高效,突出重点,不要耗费了大量的时间和精力,却做了不讨好的事情~

以上是关于性能测试的思维没打开,很多同学可能一开始就错了(内附真实项目性能测试报告)的主要内容,如果未能解决你的问题,请参考以下文章

测试周期内测试进度报告规范

注册起名选头像,也许起步就错了——自媒体有坑,得绕①

老徐杂谈:作为一个测试人员,思维比技术重要!

康一康!接口测试与性能测试的区别瞧过来~

女程序员这么少是因为怕秃头?如果你这样想,那就错了...

给学性能测试的朋友一份思维导图