JMeter之性能测试流程及性能测试关注点

性能测试流程

通常我们做功能测试，都有有一套测试测试，做性能测试也不例外，我们也有规范的流程，完成符合项目的管理流程图。如下图所示就是常规的性能测试流程图。

在这里插入图片描述
那么我们来看一下，性能测试每个环节，我们都应该做些什么？

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

性能测试成功与失败的要素

性能测试上手难度较多高，是一门融合测试、开发、运维、需求调研、架构、协调管理等综合技能的学科，性能测试有几大难点：
（1）需求分析；
（2）场景设计；
（3）性能诊断调优；
（4）环境搭建和模拟；

有很多性能从业者在需求分析方面没有做到位，不能准确地预估用户行为；在场景上不能复现用户操作，无法把需求提现在脚本和场景设计上，无法模拟真实的系统负载，导致系统上线之后，出现性能问题，整个公司手忙脚乱。

很多性能测试的初学者总是觉得性能测试就是会用JMeter或者Loadrunner性能测试工具，写个脚本弄几台服务器应付，出个报告就行了。通过关注并发多少，响应时间多少，系统是否能跑通等问题。认为并发越大，响应时间越快，则性能就一定越好，实际上我们需要对系统进行一系列复杂精密的工作才能开始性能测试执行，经过N次回归，找到瓶颈原因，优化再验证。

下面我们来讲一下性能测试关注点：

评估系统，需求分析
对系统测试进行需求分析，通常情况下我们很多功能测试人员会直接依赖需求人员或者项目经理的口述或者有缺陷的文档。实际上，大多数情况下我们需要自己来引导相关的运维人员和需求人员给出具体的需求数据，并对数据进行二次分析，得出我们真是的性能需求。
对于初次上线的项目，我们需要用同行的系统数据，进行用户行为分析和商业数据结果的估算前提，利用性能估算推算，得到负荷和响应时间数据可以用于验证所计划的模型的能力，并帮助做为决策。
对于已上线的系统，我们可以获取TPS和时间比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据等，直接精确得出目前系统的用户行为和业务数据关系，进而得出我们需要的性能需求。
场景设计、用例设计
充足的调研与分析之后，我们需要在场景中尽可能真实的复原系统负载。通过我们要决定哪些功能要参与哪些性能执行，如何参与？这就是用例设计。
如何有效的组织测试用例就是场景要做的事情，按业务分布、业务量、业务时段、业务角色来综合分配用户数、执行时间、执行比例等。看似简单，实际操作起来比较麻烦。
测试执行、是否通过：
模拟不同负载执行测试场景来识别系统弱点；做好各种监控、甄别各种问题；验证系统的稳定性。下面是我们在执行中需要关注的指标，如图：
性能诊断优化
性能诊断知识面要求甚广，依靠团队的力量才能够高效的完成诊断工作。性能测试从业者要具备良好、敏感的性能意识，能够把问题初步分类，协助各开发团队完成问题定位、分析调优。所以首先要是一个好的协调者，还是一个技术面广的技术人员，具备跨领域知识，如开发、运维、数据库、缓存等。