性能测试方案该如何写，如果规避性能测试中常见问题

性能测试方案该如何写，如果规避性能测试中常见问题

性能测试方案常见问题

需求以及测试目的不明确，应付了事

具体体现：

1、需求不明确就开始进行
2、仪式性的做一下，没有深入分析非功能需求

方案中没有考虑环境差异,导致发生问题

具体体现：

1、硬件或者使用的基础软件存在差异
2、磁盘速度，网络延迟存在较大差异
3、生产环境资源较好，整体性能却出现负提升（例如：内存较大，核心多，可能导致对应管理模块开销较大）

没有场景设计，或压力场景设计与实际存在差异

具体体现：

1、实际有多种类型的页面操作，但是测试只执行了单一的页面操作，漏掉更加复杂的处理。
2、测试场景中场景比例与生产环境场景比例不符
3、参数化设计与实际不符，没有合理考虑缓存或缓冲
4、在模拟用户行为的压测脚本中没有合理设置思考时间
5、用户的停留时间超过测试时的预期，在多页面迁移时这些迁移信息累积在会话中，导致使用内存超出预估

报告难以理解，缺少用户关注内容

具体体现：

1、无法理解业务目的和客户对系统担忧，报告中无具体体现
2、没有结合业务目标制定测试策略，测试计划
3、不是从系统而是从服务或者接口角度设定客观性能指标
4、无法说明测试结果是否满足性能指标
5、没有对系统瓶颈以及问题规避措施进行说明
6、没有测试测试数据

没有测试计划，或测试计划不能按时完成

具体体现：

1、没有对较为耗时的工作合理预估
2、出现问题后不能合理调整计划，应对风险
3、出现问题后不能有效推动问题解决

性能测试方案该如何写

要聊性能测试方案如何写之前一定要先清楚性能测试到底是什么，对于性能测试人员看似很简单的很幼稚的一个问题，但其实这个概念里已经对性能测试方案中所有需要考虑的内容给出了纲领性的意见，那么什么是性能测试？

什么是性能测试

性能测试是针对系统的业务特性，建立合理的性能威胁模型与性能指标，并制定性能测试策略和监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足业务要求。明确的性能测试的概念我们来说一下一个好的性能方案到底需要包含哪些内容。

性能方案要有业务特性的描述

业务特性的梳理和描述是对当前系统情况的全面理解和挖掘，主要目的是明确是否需要做性能测试和确立性能点，明确该测什么、在什么样的硬件环境，以及什么样的基础数据下进行测试，期望值即性能的指标要是多少。测试期望值也会根据情况评估，要求被测系统能满足将来一定时间段的压力。

性能方案要有基于业务描述推导出的威胁模型与指标要求

什么是性能威胁模型

性能威胁模型是对真实业务场景的抽象，其主要包含业务模型和扰动模型。 业务模型可以说明哪个业务并发多，哪个业务并发少，各个业务之间的比例是什么，这样做压力模型时就要控制好这样的比例。对真实的线上业务进行模拟。 扰动模型说的是可能对性能情况产生扰动的系统事件和外部报错，比较常见的如系统中的某些定时任务。

性能指标需要包含哪些

描述时间特性的指标

系统或产品在执行某个功能是，从开始到获取到结果所需要的时间

描述容量的指标

容量主要是反馈系统或产品能够承受的最大并发用户数，最大能处理的请求极限，以及系统可能存在的最大数据容量和数据处理容量

描述资源利用性的指标

资源利用率主要考察系统所采用的个各种资源的利用程度，需要注意的是这里说的资源并不特指硬件资源，而是只支持整个系统运行程序的一起软件/硬件资源，比如cpu利用率，内存，磁盘，带宽，存储命中率，数据库线程数，Jvm等。这些指标理论上应该是合理的，符合系统实际情况的，而不是胡乱拍一些指标

性能方案要有对场景条件的描述

这里的条件包括软硬件环境、网络情况、铺底数据、测试执行策略、压力补偿等内容。在场景执行之前，这些条件应该是确定，且被详细记录的。因为在性能测试时任何一项条件的变更都可能会对测试结果产生影响，详细的记录这些信息也为后续出现问题时的分析比较打下基础，这里需要特殊注意的是有时候性能测试需要重复进行多次，那么就需要在每一次测试后，能够有快速“复位”到初 始测试环境的机制。这个复位机制越简单有效越好，最好能达到所谓“一键复位”的程度， 从而最大限度地降低手工复位的工作量。

性能方案要有对场景的描述

性能测试场景说的是，在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略（跑什么业务，压力怎么给）、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

性能场景有这几个分类。

基准性能场景：

这里要做的是单交易的容量，为混合容量做准备（不要跟我说上几个线程跑三五遍脚本叫基准测试，在我看来，那只是场景执行之前的预执行，用来确定有没有基本的脚本和场景设计问题，不能称之为一个分类）。

容量性能场景

这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个，在概念部分就不细展开了，我会在后面的文章中详细说明。

稳定性性能场景：

稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人的心理安全感。

异常性能场景：

要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常下系统的处理能力

性能方案需要有监控策略

性能监控需要实时观察性能测试过程中各项指标是否正常，包括应用服务器、数据库、中间件、网络等方面，保证测试前提，记录测试数据，输出监控结果。更重要的是，监控的过程是发现系统瓶颈的过程，是性能分析、性能通过与否、性能报告输出等环节的基础和依赖。

监控需要使用不同的工具，结合系统日志、应用和服务器所反映的多项指标，记录监控数据。

监控类别	监控指标
服务器	具体包括CPU、Memory、Load、I/O、Disk等。
数据库	具体包括缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数等。
中间件	具体包括线程数、连接数、日志输出等。
网络	具体包括防火墙、网卡、网线、吞吐量、吞吐率等。
应用服务	具体包括JVM内存使用和回收、JAVA内存使用、FullGC频率、JAVA类装入和卸载、日志、线程运行状态(阻塞、等待、正常运行)等。
测试机资源	具体包括CPU、Memory、网络、日志输出、磁盘空间、负载生成器评估等。
性能监控指标	具体包括用户执行情况、场景状态、事务响应时间、TPS、Load、CPU分析图表等。

性能报告需要有对性能瓶颈的判断以及调优方法

判断系统瓶颈并进行调优是性能测试重要目的之一，也是最能体现性能测试人员价值和功底的环节。性能瓶颈分析的思路是，针对不同的系统以及测试目标，不同的测试关注点（Rt，错误率，Tps，资源等），以及性能指标的具体体现，采用“拆分问题，隔离分析”的方法进行分析，即逐步定位、从外到内、从表及里、逐层分解、隔离排除。具体可以按照以下顺序进行开展

1、判断中间件是否存在瓶颈（中间件中jvm配置，数据库配置等）

2、查看应用打印出来的日志，是否存在报错，或超时等信息

3、判断应用本身是否存在性能瓶颈（比如业务逻辑，慢sql，线程池设置，算法等）

4、判断服务的提供者是否存在性能瓶颈（即服务的被调用方是否存在性能瓶颈）

5、相关联的底层服务或应用是否存在性能瓶颈（比如文件服务，数据库服务等）

性能报告需要有性能结果的描述

性能结果如何来定义呢？有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中了。这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。不管在形式上有什么变化，结果的本身都要做到有根有据， 条理清楚，层次分明。这样大家才会被你和你展示的数据所说服。具体来讲，你需要让读者：同意你的理论方法和测试过程，信服你的推理分析，理解问题的核心原因，同意你的建议和方案；

性能测试过程中没有计划的跟踪与风险管理

性能测试计划是对确定要实施的测试内容制定具体的时间计划，人力计划等，并在过程中对既定的时间点进行保障，确保每个计划能都按时的完成。风险管理呢也是确保计划能够按时完成的一种手段，其主要方法为风险识别，风险评估，以及风险控制