本文共 1820 字，大约阅读时间需要 6 分钟。

性能测试流程

平常我们做黑盒测试，都会有一套功能测试流程，做性能测试也不例外，性能也会有规范的流程。如下图所示就是我们常规的性能测试流程图。 .1.业务学习：通过查看文档，手工操作系统来了解系统功能。 .2.需求分析：分析系统非功能需求，圈定性能测试范围，了解系统性能指标。 3.工作评估：工作量分解，评估工作量，计划资源投入（即需要多少人力，多少工作日来完成性能测试工作） .4.设计模型：圈定性能测试范围后，把业务模型映射成测试模型。 .什么是测试模型呢？比如我们测试工作中，需要调用一些第三方的服务，如最常见的支付功能，如我们需要实现一个支付订单的功能，但是此时支付那边暂时不能够支持提供服务，那我们为了确保整个性能测试能够正常开展，需要开发一个程序去替代这个支付功能，即Mock程序，这个过程就是设计模型。 在比如我们测试用户加入购物车下单购买商品功能，需要操作用户登录，点击浏览商品，加入购物车，下单等一系列流程，这些流程需要绑定在一起进行测试，这就是测试模型，通俗点讲，性能测试用例设计 + 性能测试实现方案，用例只关注业务，模型还需要关注实现，是否具有可操作性、可验证性等问题，我们需要根据不提供的测试目的组合不同的测试场景。 .5.计划编写计划测试工作，在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险预估、风险应对策略等。 .6.脚本开发：录制或者编写性能测试脚本 .7.测试环境准备：性能测试环境准备包括服务器与负载机两部分，服务器是被测系统运行平台（包括硬件与软件，比如应用服务器需要8Core，32G内存，中间件是JBoss7等），负载机是我们用来产生负载的机器，用来安装负载的工具，运行测试脚本。 .8.测试数据准备：根据数据模型来模拟被测系统的主数据与业务数据（主数据指的是保证业务能够正常运行畅通的基础，比如菜单、用户等数据；业务数据是运行业务产生的数据，比如订单；订单出库需要库存数据，库存数据也是业务数据。我们知道数据量变会引起性能的变化，在测试的时候，往往要准备一些存量/历史业务数据，这些数据需要考虑数量与分布） .9.测试执行：测试执行是性能测试的成败与关键，同样的脚本不同的人执行得出的结果可能差异较大。这样差异主要源于提现在场景设计与测试执行上。 .10.缺陷管理：对性能测试中发现的缺陷进行管理。 .11.性能分析：对性能测试过程中暴露的问题进行分析，找出原因。 .12.性能调优：性能测试工程师与开发人员一起来解决性能问题。 .13.测试报告：测试工作的重要交付件，对测试结果进行报告，主要包括常见的性能指标说明（TPS、RT、CPU Using…) 性能测试主要交付件： 1）测试计划； 2）测试脚本； 3）测试程序； 4）测试报告或者阶段性测试报告； 如果性能测试执行过程较长，换句话说性能测试过程中性能问题较多，经过了多轮的性能调优，需要执行多次回归测试，那么在这个过程中需要提交阶段性测试报告。 .14.评审对性能报告中的内容进行评审，确认问题，评估上线风险。有些系统虽然测试结果不理想，但是基于成本及时间的考虑也会在评审会议中通过从而上线。

性能测试常见的指标

B/S架构-常见性能指标：对于B/S架构的软件，一般会关注如下Web服务器性能指标 C/S架构-常见性能指：对于C/S架构的程序，由于软件后台通常为数据库，所以我们更注重数据库的测试指标除了表格里面的概念，还有部分指标：CPU占用率、内存占用率、数据库连接池等。

性能测试结果分析

1–如何分析性能测试结果 分析在整个性能测试执行期间，测试环境是否稳定正常。 例如，测试期间运行Jmeter的及其CPU占用率经常达到100%（或内存占用很高）、测试网络出现拥塞导致响应延迟、待测系统参数配置错误（JDBC连接池等）… 2-- 检查jmeter测试脚本参数设置是否合理、检查jmeter运行模式是否合理。例如，线程组的参数Ramp-Up Period(in seconds)设置为0或1，jmeter就会瞬间启动该线程组下的所有虚拟用户，会为待测服务器造成巨大的压力，轻则导致服务器响应时长超长，重则导致部分虚拟用户等待响应超时而报错。 3.–检查测试结果是否暴露出了系统瓶颈。性能测试分析的原则：由表及里、由内而外、抽丝剥茧 借助监听器发现性能缺陷 图形结果(Graph Results) 指标概念解释如下：

转载地址：https://blog.csdn.net/weixin_42274846/article/details/127532590 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！