Jmeter性能测试 —— 性能测试的流程和术语_请选择 metersphere 性能测试模块正确的工作流程(1)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

3、确定性能目标
前面已经确定了本次性能测试的应用领域，接下来就是针对具体的领域关注点，确定性能目标（指标）；其中需要和其他业务部门进行沟通协商，以及结合当前系统的响应时间等数据来进行确定
最终我们需要达到的响应时间和系统资源使用率等目标；比如：
①登录请求到登录成功的页面响应时间不能超过2秒；
②报表审核提交的页面响应时间不能超过5秒；
③文件的上传、下载页面响应时间不超过8秒；
④服务器的CPU平均使用率小于70%，内存使用率小于75%；
⑤各个业务系统的响应时间和服务器资源使用情况在不同测试环境下，各指标随负载变化的情况等；
4、制定测试计划的实施时间
预设本次性能测试各子模块的起止时间，产出，参与人员等等

三、性能测试方案设计

1、测试环境设计

本次性能测试的目标是需要验证系统在实际运行环境中的性能外，还需要考 虑到不同的硬件配置是否会是制约系统性能的重要因素。因此在测试环境中，需 要部署多个不同的测试环境，在不同的硬件配置上检查应用系统的性能，并对不同配置下系统的测试结果进行 分析，得出最优结果（最适合当前系统的配置）。

这里所说的配置大概是如下几类：

①数据库服务器

②应用服务器

③负载模拟器

④软件运行环境，平台

测试环境测试数据，可以根据系统的运行预期来确定，比如需要测试的业务场景， 数据多久执行一次备份转移，该业务场景涉及哪些表，每次操作数据怎样写入， 写入几条，需要多少的 测试数据来使得测试环境的数据保持一致性等等；

可以在首次测试数据生成时，将其导出到本地保存，在每次测试开始前导入数据， 保持一致性。

2、测试场景设计

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

3、测试用例设计

确认测试场景后，在系统已有的操作描述上，进一步完善为可映射为脚本的测试用例描述。

用例大概内容如下：

用例编号：查询表单_xxx_x1（命名以业务操作场景为主，简洁易懂即可）

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

操作步骤：

①进入对应页面。。。。。。
②查询相关数据。。。。。。
③勾选导出数据。。。。。。
④修改上传数据。。。。。。

四、测试脚本开发

1、根据性能测试用例的描述，根据公司的实际情况完成测试脚本的开发：
     ① 公司有接口设计文档
　　　直接把测试用例中需要用到的接口通过接口文档提供的信息录入到性能测试工具。
     ② 公司无接口设计文档
　　   可利用录制工具进行录制或者结合抓包工具进行手工编写脚本。
2、在工具中完成测试脚本后，进行对性能测试脚本的调试与调优操作（如：关联、参数化、检查点设置、脚本逻辑设置等）

五、测试执行和管理

1、建立测试环境
按照之前已经设计好的测试环境，部署对应的环境，由运维或开发人员进行部署，检查，并仔细调整，同时保持测试环境的干净和稳定，不受外来因素影响。
2、测试数据准备
可以利用测试脚本自动生成业务测试数据、利用工具生成数据或者导入生产环境的业务数据等方式
3、执行测试脚本
这一点比较简单，在已部署好的测试环境中，按照业务场景和编号，按顺序执行我们已经设计好的测试脚本
4、测试结果记录
根据测试采用的工具不同，结果的记录也有不同的形式；现在大多的性能测试工具都提供比较完整的界面图形化的测试结果，当然，对于服务器的资源使用等情况，可以利用一些计数器或第三方监控工具来对其进行记录，执行完测试后，对结果进行整理分析。

六、测试分析

1、测试环境的系统性能分析
根据我们之前记录得到的测试结果（图表、曲线等），经过计算，与预定的性能指标进行对比，确定是否达到了我们需要的结果；如未达到，查看具体的瓶颈点，然后根据瓶颈点的具体数据，进行具体情况具体分析（影响性能的因素很多，这一点，可以根据经验和数据表现来判断分析）
2、硬件设备对系统性能表现的影响分析
由于之前设计了几个不同的测试环境，故可以根据不同测试环境的硬件资源使用状况图进行分析，确定瓶颈是再数据库服务器、应用服务器抑或其他方面，然后针对性的进行优化等操作
3、其他影响因素分析

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

七、测试调优和解决

1、确定问题
应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。
数据库配置：经常引起整个系统运行缓慢，一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的
操作系统配置：不合理就可能引起系统瓶颈。
硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点
网络：网络负载过重导致网络冲突和网络延迟。
2、确定问题产生的原因
当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？ 是客户端还是服务器出现问题？ 系统硬件配置是否够用？实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？
通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因
3、确定调整目标和解决方案
一般由性能测试团队中的DBA、核心开发、运维根据测试的实际情况进行确定并出详细的解决方案进行评审，比如添加服务器方式、调整代码架构等
4、测试解决方案
对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）
5、分析调优结果
系统调优是否达到或者超出了预定目标，系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了

性能测试术语

负载：

对被测系统不断施加压力，直到性能指标超过预期或某项资源使用达到饱和， 以验证系统的处理极限，为系统性能调优提供依据，如模拟100个用户进行发帖 操作

并发：

①狭义上的并发：所有用户在同一时间点进行同样的操作，一般指同一类型的业 务场景，比如1000个用户同时登录系统；

②广义上的并发：多个用户与系统发生了交互,这些业务场景可以是相同的也可以是不同的,交叉请求和处理较多,比如1000个用户登录系统后，部分在查询、 部分在下单等

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！