首页 > 编程知识 正文

性能测试是怎么做的,性能测试流程图

时间:2023-05-05 18:43:04 阅读:113395 作者:3442

下午访问测试交流组时,谈了性能测试。 然后一个小组的成员说他们在用他们使用的loadrunner创造性能。 那时,我觉得这个故事有点偏颇。 我也是探索性能测试道路的前进者。

确实,我们在做性能测试工作的时候,需要借助工具的辅助来完成一些工作,但是loadrunner性能测试! 或者性能测试工具性能测试,工具总是一种

辅助工具,不能用工具进行性能测试! 希望你看看这里的童鞋(很多认知是测试实用的银耳汤),改变这个观念。

现在,让我们来讨论完整的性能测试过程。

PS:文末附上性能测试思维导图

一、准备工作

1、系统基础功能验证

性能测试适合在哪个阶段进行? 切口很重要! 通常,只有在系统基础功能测试验证完成且系统稳定时,才会进行性能测试。 否则,性能测试是没有意义的。

2、测试团队组建

根据该项目的具体情况,构建几个性能测试team。 其中DBA是必不可少的。 然后,需要支持前端、后端等的1到几名系统开发人员,以及性能测试设计和分析人员、脚本开发

和执行者; 在正式开始工作之前,必须对脚本开发和执行者进行培训,或者由有经验的人负责。

3、工具的选择

综合考虑系统设计、工具成本、测试团队技能,选择合适的测试工具,至少应满足以下几点:

支持web (此处以web系统为例)系统性能测试,支持http和https协议

工具在Windows平台上运行

支持监视webserver、前端和数据库的性能计数器

4、预先的业务场景分析

为了建立对系统性能的直观认识和分析,分析了系统的重要性和常用业务场景模块,进行了针对性的分析,为下一步的测试计划设计做准备。

二、测试计划

在测试计划阶段最重要的是分析用户方案并确定系统的性能目标。

1、性能测试领域分析

根据项目背景、对业务的理解,确定本次性能测试需要解决的问题; 测试系统能否满足实际运行时的需要,还是当前系统在哪些方面制约了系统的性能,或者是哪些系统因素导致的

系统跟不上业务的发展吗? 确定测试领域,具体问题具体分析。

2、用户场景剖析和业务建模

根据系统业务、用户活动时间、访问频率、场景交互等各方面的分析,整理业务场景表。 当然,其中最好详细描述用户的操作场景、步骤,为测试脚本的开发提供依据。

3、确定性能目标

首先确定了本次性能测试的应用领域,然后针对具体领域的热点,确定性能目标(指标); 其中,需要结合与其他业务部门的沟通协商和当前系统的响应时间等数据进行确定

最终必须达到的响应时间和系统资源利用率等目标例如:

从登录请求到登录成功的页面响应时间不能超过2秒;

报告审核提交的页面响应时间不得超过5秒;

文件上传、下载页面的响应时间不超过8秒

服务器CPU平均利用率低于70%,内存利用率低于75%

在各业务系统响应时间和服务器资源使用情况不同的测试环境下,各指标随负荷变化等;

4、制定测试计划的实施时间

预先设定本次性能测试的各子模块的开始时间、生产、参加者等。

三、测试脚本设计与开发

在性能测试中,测试脚本的设计和开发占很大的时间比重。

1、测试环境设计

除了验证系统在实际操作环境中的性能外,这次性能测试的目标是考虑不同的硬件配置是否是制约系统性能的重要因素。 因此,在测试环境中,需要部署多个不同的测试环境。

使用不同的硬件配置检查APP应用系统的性能,分析不同配置下系统的测试结果,得到最佳结果(最适合当前系统的配置)。

这里所说的配置大致如下。

数据库服务器

APP应用服务器

负载模拟器

软件运行环境、平台

测试环境中的测试数据包括需要测试的业务场景、数据以多长时间执行备份迁移、该业务场景涉及哪些表、每次操作如何写入数据、写入多少条数据、需要多少

为了保持测试环境中数据的一致性而测试数据等。

您可以在首次生成测试数据时本地导出和存储数据,并在每次测试开始前导入数据以保持一致性。

2、测试场景设计

去事业部工作

门沟通以及以往用户操作习惯,确定用户操作习惯模式,以及不同的场景用户数量,操作次数,确定测试指标,以及性能监控等。

3、测试用例设计

确认测试场景后,在系统已有的操作描述上,进一步完善为可映射为脚本的测试用例描述,用例大概内容如下:

用例编号:查询表单_xxx_x1(命名以业务操作场景为主,简洁易懂即可)

用例条件:用户已登录、具有对应权限等。。。

操作步骤:

①进入对应页面。。。。。。

②查询相关数据。。。。。。

③勾选导出数据。。。。。。

④修改上传数据。。。。。。

PS:这里的操作步骤只是个例子,具体以系统业务场景描述;

4、脚本和辅助工具的开发及使用

按照用例描述,可利用工具进行录制,然后在录制的脚本中进行修改;比如参数化、关联、检查点等等,最后的结果使得测试脚本可用,能达到测试要求即可;

PS:个人而言,建议尽量自己写脚本来实现业务操作场景,这样对个人技能提升较大;一句话:能写就绝不录制!!!

 

四、测试执行与管理

在这个阶段,只需要按照之前已经设计好的业务场景、环境和测试用例脚本,部署环境,执行测试并记录结果即可。

1、建立测试环境

按照之前已经设计好的测试环境,部署对应的环境,由运维或开发人员进行部署,检查,并仔细调整,同时保持测试环境的干净和稳定,不受外来因素影响。

2、执行测试脚本

这一点比较简单,在已部署好的测试环境中,按照业务场景和编号,按顺序执行我们已经设计好的测试脚本。

3、测试结果记录

根据测试采用的工具不同,结果的记录也有不同的形式;现在大多的性能测试工具都提供比较完整的界面图形化的测试结果,当然,对于服务器的资源使用等情况,可以利用一些计数器或

第三方监控工具来对其进行记录,执行完测试后,对结果进行整理分析。

 

五、测试分析

1、测试环境的系统性能分析

根据我们之前记录得到的测试结果(图表、曲线等),经过计算,与预定的性能指标进行对比,确定是否达到了我们需要的结果;如未达到,查看具体的瓶颈点,然后根据瓶颈点的具体数据,

进行具体情况具体分析(影响性能的因素很多,这一点,可以根据经验和数据表现来判断分析)。

2、硬件设备对系统性能表现的影响分析

由于之前设计了几个不同的测试环境,故可以根据不同测试环境的硬件资源使用状况图进行分析,确定瓶颈是再数据库服务器、应用服务器抑或其他方面,然后针对性的进行优化等操作。

3、其他影响因素分析

影响系统性能的因素很多,可以从用户能感受到的场景分析,哪里比较慢,哪里速度尚可,这里可以根据258原则对其进行分析;

至于其他诸如网络带宽、操作动作、存储池、线程实现、服务器处理机制等一系列的影响因素,具体问题具体分析,这里就不一一表述了。

4、测试中发现的问题

在性能测试执行过程中,可能会发现某些功能上的不足或存在的缺陷,以及需要优化的地方,这也是执行多次测试的优点。

 

六、性能测试思维导图

以上就是一个较简单,完整的性能测试过程,当然其中很有很多值得分析和探讨的内容,限于篇幅和时间问题,这里不一一赘述,以后会慢慢对性能测试执行、瓶颈分析、优化的内容不断

补充,也希望看到的童鞋可以提出建议和指正,如有兴趣,可加入博客主页的群链接,一起交流关于软件测试的相关技术和经验。。。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。