性能测试流程

性能测试的流程

做事我们要讲究方法，注重效益，例如生成企业会有流水线。做性能测试也一样，我们也要有规范的流程，完全符合项目的管理流程

1. 业务学习：通过查看文档，手工操作系统来了解系统功能
2. 需求分析：分析系统非功能需求，圈定性能测试范围，了解系统性能指标
3. 工作评估：工作量分解，评估工作量，计划资源投入
4. 设计模型：圈定性能测试范围后，把业务模型映射成测试模型

什么是测试模型呢？比如一个支付系统需要与银行系统进行交互（充值或者转出）由于银行不能够提供支持，我们会开发程序去代替银行系统（这就是挡板程序，Mock程序），保证此功能的性能测试能够展开，这个过程就叫设计测试模型

通俗点说就是，性能测试用例设计+性能测试实现方案 ，用例只关注业务，模型还需要关注如何实现，是否具有可操作性，可验证性等问题，最后我们还得根据不同的测试目的组合成不同的测试场景。

1. 计划编写:计划测试工作，在文档中列出测试范围，人力投入，持续时间，工作内容，风险评估，风险应对策略等。
2. 脚本开发：录制或编写性能测试脚本，开发测试挡板程序，开发测试程序等。有时候没有第三方工具可用，甚至需要开发测试程序或者工具。
3. 测试环境准备：性能测试环境准备包括服务器与负载机两部分，服务器是被测系统的运行平台（包括硬件与软件，比如服务器需要8Core，32G内存，中间件是Jboss7等)；负载机是用来产生负载的机器，用来安装负载工具，运行测试脚本。
4. 测试数据准备：根据数据模型来准备被测系统的主数据与业务数据（主数据是保证业务能够运行顺畅的基础，比如菜单，用户等数据：业务数据是运行业务产生的数据，比如订单；订单出库需要库存数据，库存数据也是业务数据。我们知道数据量变动会引起性能变化，在测试的时候往往需要准备一些存量/历史业务数据，这些数据需要考虑数量与分布。
5. 执行测试：测试执行是性能测试成败的关键，同样脚本不同的人员执行得出的结果差异较大。这些差异主要体现在场景设计与测试执行上
6. 缺陷管理：对性能测试过程中发现的缺陷进行管理
7. 性能分析：对性能测试过程中暴露出来的问题进行分析，找出原因
8. 性能调优：性能测试工程师与开发人员一起解决性能问题
9. 测试报告：测试工作的重要交付，对测试结果进行报告

性能测试主要交付件：

• 测试计划
• 测试脚本
• 测试程序
• 测试报告或阶段性报告
  如果性能测试执行过程较长，换句话说性能测试过程中问题比较多，经过了多轮的性能调优，需要执行多次回归测试，那么在这个过程中需要提交阶段性测试报告

14. 评审：对性能报告中的内容进行评审，确认问题，评估上线风险，有些系统虽然测试结果不理想，但基于成本及时间的考虑也会在评审会议中通过从而上线

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

性能测试上手难度比较高，是一门融合测试，开发，运维，需求调研，架构，协调管理等综合技能的学科，掌握一门性能测试工具对性能测试来说只是万里长征的第一步，没有一定的需求，开发和运维专业能力，往往会吃一些苦头。

性能测试的几大难点：

1. 需求分析
2. 场景设计
3. 性能诊断调优
4. 环境搭建和模拟
   往往很多性能测试从业者在需求分析方面没有做到位，不能精准的预估用户的行为；在场景上不能复现用户的操作，无法把需求体现在脚本和场景设计上，无法模拟真实的系统负载，这种状态下做出的性能测试往往结果良好，上线出问题，导致整个团队狼狈不堪，整个公司手忙脚乱。

下面讲解性能测试的重要关注点（成功与失败的要素）：

1. 评估系统，需求分析

对性能测试进行需求分析，通常情况下我们的功能测试人员会直接依赖需求人员或者项目经理的口述或者缺陷文档。实际上我们需要自己来引导相关运维人员和需求人员来给出具体的需求数据，得出我们真实的性能需求

对于初次上线的系统，我们需要用同行的系统数据，进行用户行为分析和商业数据结构的估算为前提。利用性能估算法推算。得到负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助做出决策。

对于已经上线的系统，我们可以通过运维人员获取TPS和时间的比例分布图，用户数和时间分布图，数据库ER关系图，容量数据等，直接精准得出目前的系统的用户行为和业务的数据关系，进而得出我们需要的性能需求。

2. 场景设计，用例设计

充足的需求调研和分析之后，我们要在测试场景中尽可能真实的复原系统负载。

通过需求我们要决定哪些功能要参与性能执行，如何参与？这就是用例设计

如何有效的组织测试用例的设计就是场景需要做的事情，按业务分布，业务量，业务时段，业务角色来综合分配用户数，执行时间，执行比例等。看似简单，实际操作起来还是比较麻烦的。

3. 测试执行，是否通过

模拟不同负载执行场景来识别系统弱点，做好各种监控，甄别各种问题，验证系统的稳定性，下面是我们在执行时常见的需要关注的指标：

• 响应时间(RT)
• 吞吐量（TPS)
• 事务成功率
• 硬件指标（CPU，内存，存储，网络）
• 稳定性
• 内存有无泄漏
• 其他（数据库，中间件，缓存，JVM）

4. 性能诊断优化

性能诊断知识面要求甚广，系统日益复杂，靠单打独斗的日子已经过去了，依靠团队的力量才能高效完成诊断任务。性能测试从业者要具备良好，敏感的性能意识，能够把遇到的问题初步分类，协助开发团队完成问题定位，分析调优。

性能测试相关术语

• 负载：模拟业务操作对服务器造成压力的过程，比如模拟100个用户进行发帖
• 性能测试：模拟用户负载来测试系统在负载情况下，系统的响应时间，吞吐量等指标，是否满足性能要求
• 负载测试：在一定软硬件环境下，通过不断加大负载，来确定在满足性能指标情况下能够承受的最大用户数。简单说，简单说，我们可以帮我们对系统进行定容定量，找出系统性能的拐点，给予生产环境规划建议，这里的性能指标包括TPS（每秒事务数），RT（事务平均响应时间） CPU using(CPU 利用率），Mem(内存使用情况）等软硬件指标。从操作层面上来说。负载测试也是一种性能测试手段。
• 配置测试：为了合理的调配资源，提高系统运行效率，通过测试手段来获取，验证，调整配置信息的过程。通过这个过程我们可以收集到不同配置反应出来的性能，从而为设备选择，设备配置提供参考。
• 压力/强度测试：在一定的软硬件环境下，通过高负载的手段来使服务器的资源（服务器资源，硬件资源）处于极限状态，测试系统在极限状态下长时间运行是否稳定，确定是否稳定的指示包括TPS，RT,CPU Using,Mem Using等。
• 稳定性测试：在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否稳定，着重的是满足性能要求的情况下，系统的稳定性，比如响应时间是否稳定，TPS 是否稳定，一般我们会在满足性能要求的负载情况下加大1.5 到2倍的负载量进行测试
• TPS ：每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性指标。一个事务是一个业务量的单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把多个子操作计为一个事务。比如一笔电子支付操作，在后台系统中可能会经历会员系统，财务系统，支付系统。会记系统，银行网关等，但对于用户来说只想知道整比支付花费了多长时间。
• RT/ART :响应时间／平均响应时间，指一个事务花费多长时间完成（多长时间响应客户请求） 为了使这个响应时间更具代表性，会统计更多的响应时间然后取平均值，既得到了事务平均响应时间（ART）
• PV 每秒用户访问页面的次数，此参数用来分析平均每秒有多少用户访问页面。
• 虚拟用户数：模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。
• 并发：并发分为狭义和广义两类。狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般指同一类型的业务，或者所有的用户完全进行一样的操作，目的是测试数据库和程序对并发操作的处理。广义的并发，即多个用户对系统发出了请求或者进行了操作，但这些请求或者操作可以是不同的。对整个系统而言，仍然有很多用户同时进行操作。狭义的并发强调对系统的请求操作是完全相同的，多用于性能测试，负载测试，压力测试，稳定性测试场景。广义并发并不限制对系统的请求操作，多用于混合场景，稳定性测试。
• 场景：性能测试过程是为了模拟真实用户的业务处理过程。场景中包含了待执行脚本，脚本组，并发用户数，负载生成器，测试目标，测试执行时的配置条件等。
• 思考时间：模拟正式用户早实际操作时的停顿间隔时间，从业务角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。
• 标准差：该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差，TPS 标准差，等。

性能测试通过的标准

常规通过标准如下表所示：

类别	判断维度	不通过	通过	备注
	超时效率	大于0.5%	小于0.5%	性能测试团队根据通过标准，判定被测性能点不通过，没有绝对的标准，由专家组或项目组的负责人来评判
通用互联网服务端性能	错误概率	大于0.5%	小于0.5%	网页响应时间一般根据（1,3,5 原则来判断）
通用互联网服务端性能	TPS	小于期望高峰值	大于期望高峰值	网页响应时间一般根据（1,3,5 原则来判断）
通用互联网服务端性能	CPU利用率	大于期望时间	小于期望时间	网页响应时间一般根据（1,3,5 原则来判断）
通用互联网服务端性能	响应时间	大于期望时间	小于期望时间	网页响应时间一般根据（1,3,5 原则来判断）
通用互联网服务端性能	Load	平均每核CPU的Load大于1	平均每核CPU的Load小于1	网页响应时间一般根据（1,3,5 原则来判断）
通用互联网服务端性能	JVM /内存使用率	大于80%	大于80%	网页响应时间一般根据（1,3,5 原则来判断）
通用互联网服务端性能	Full GC 频率	平均小于半小时一次	平均大于半小时一次	网页响应时间一般根据（1,3,5 原则来判断）
前端页面性能	YSlow	YSlow评定为C级以下	YSlow评定为C级以上