性能测试的概念和场景设计

一、什么是性能

性能的定义：性能是指系统或设备在执行特定任务时的时间效率和资源利用情况。可以从两个主要维度来理解：

1. 时间维度：
   a、响应时间：指系统从接收用户请求到返回结果所需的时间。
   b、吞吐量：指单位时间内系统能处理的请求数量，通常用“业务数/小时”、“业务数/天”等来衡量。
2. 资源维度
   a、CPU使用率：指系统在运行过程中占用的CPU资源。
   b、内存使用：指系统在运行过程中占用的内存资源。
   c、磁盘IO：指系统在读写磁盘时的性能表现。
   **

二、什么是性能测试

性能测试又是什么呢？性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试的过程。这些性能指标包括吞吐量、响应时间、错误率、资源利用率（如CPU使用率、内存占用等）、系统稳定性等诸多方面。

1. 吞吐量（TPS）：
   启动一个压测任务，我们最开始看到的监控数据是性能指标。如下tps曲线图，绘制出来的是不同并发下tps数据，这里主要看的就是增加并发后tps能否平缓增加，如按一定比例上升，服务处理能力还未到瓶颈，如未到性能指标，可继续增压。如果是增加并发量tps不增或者下降，可能服务已经过载。
   
2. 响应时间：
   同时结合一起看的还有响应时间，如果增加并发后，tps增加，响应时间不增加，服务处理能力还未到瓶颈，如果增加并发，tps不增加或者增加缓慢，这种情况响应时间也会增加，因为服务的处理能力一定到最大了，依据并发和响应时间成正比的关系，并发增加的同时响应时间会增加。日常情况下看TP90，TP99，TP999的值。平均响应时间是个平均值，在值不均匀稳定的情况下，很容易把结果值拉低或者拉高。
3. 错误率：
   除了上述指标我们还需要看请求通过率，在压测期间，如果失败的请求数较多，确认压测脚本和参数无误后，再看压测平台日志，是否有异常或错误报出，还有服务的error日志，依次确认失败原因，直到错误率在一个合理的范围内。
   
   

三、性能测试的类型

1. 基准测试
   基准测试是性能测试的第一步，旨在评估系统在无负载或低负载情况下的性能表现。通过基准测试，可以获取系统的基准性能数据，为后续的负载测试、压力测试等提供参考依据。
2. 负载测试
   负载测试是一种性能测试，用于评估系统在不同负载条件下的性能表现。它主要关注系统的吞吐量、响应时间等指标随着负载的增加而产生的变化。例如，授权系统中，增加授权码生成数量（1、100、500、2000、10000），观察系统的响应情况。
   负载测试的目的：确定系统的最大负载能力，即系统能够承受的事务数。同时，也可以找到系统性能开始下降的拐点，为系统的容量规划提供依据。
3. 压力测试
   压力测试是在超过系统正常负载的情况下，对系统进行的测试。它主要用于测试系统在极端条件下的稳定性和可靠性。例如，对一个数据库系统施加超出其设计容量数倍的并发查询请求，观察系统是否会崩溃。
   其目的是检查系统在面临突发的高负载或者异常负载时的应对能力。比如，检测网络服务在遭受DDoS攻击（分布式拒绝服务攻击）模拟场景下的恢复能力，评估系统的容错性和鲁棒性。
4. 4.容量测试
   容量测试侧重于评估系统能够处理的数据量和用户量的极限。它关注的是系统的存储容量、处理能力等方面的极限值。目的是为系统的容量规划提供准确的数据。通过容量测试，可以确定系统需要多少硬件资源来支持未来的业务增长，如需要增加多少服务器、存储设备等。

四、性能测试指标

1. 响应时间（Response Time）
   定义：从用户发起请求到系统返回结果的时间。
   目标：通常要求响应时间在毫秒级别，具体目标根据业务需求确定。

   示例：
   用户登录：≤ 500ms
   数据查询：≤ 1s
   交易处理：≤ 2s

2. 吞吐量（Throughput）
   定义：系统在单位时间内处理的请求数量。
   目标：根据系统设计容量和业务需求确定。

   示例：
   每秒处理登录请求：≥ 1000次
   每秒处理交易请求：≥ 500次

3. 并发用户数（Concurrent Users）
   定义：系统能够同时处理的用户数量。
   目标：根据业务场景和用户规模确定。

   示例：
   支持并发用户数：≥ 10,000

4. 资源利用率（Resource Utilization）
   定义：系统在运行过程中对硬件资源的使用情况。
   目标：资源利用率应在合理范围内，避免过高或过低。

   示例：
   CPU使用率：≤ 80%
   内存使用率：≤ 70%
   磁盘I/O：≤ 50%
   网络带宽：≤ 60%

5. 错误率（Error Rate）
   定义：系统在处理请求过程中出现错误的比例。
   目标：错误率应尽可能低，通常要求≤ 1%。

   示例：
   登录失败率：≤ 0.5%
   交易失败率：≤ 0.1%

6. 系统稳定性（Stability）
   定义：系统在长时间运行或高负载下的稳定性表现。
   目标：系统应能够持续稳定运行，无崩溃或性能显著下降。

   示例：
   系统持续运行24小时，无崩溃或性能下降。

五、性能测试流程

1. 获取性能需求
   需求一：用户数信息
   a、调查系统当前和未来使用的用户数
   b、调查系统当前和未来的每日、月活跃用户数
   需求二：业务数据量
   调查当前和未来背景数据量
   调查当前和未来业务每天使用的总笔数
   调查当前和未来高峰时业务的总笔数

2. 制定测试计划
   明确测试目标 – 确定要测试的系统或应用的性能指标，如响应时间的具体要求（如平均响应时间不超过2秒）、吞吐量的目标值等。例如，对于域控客户端登陆，在早9点到9点30，需满足1000个账户的登录需求，即需要验证30分后台需要保证处理1000个登录相关事务。
   定义测试范围 – 包括要测试的功能模块（如，授权码生成、查询等）、系统环境（如操作系统、浏览器类型等）以及用户负载类型（如模拟的是普通用户操作还是高并发的机器人操作）。
   选择测试工具和技术 – 根据测试目标和范围选择合适的测试工具。例如，对于Web应用的性能测试，可以选择JMeter、LoadRunner等工具。同时，确定测试的技术方法，如采用黑盒测试还是白盒测试的部分方法来辅助性能测试。

3. 测试环境的搭建
   硬件环境准备 – 确保测试服务器、客户端等硬件设备的配置符合测试要求。例如，如果要测试一个大数据处理系统的性能，需要准备足够内存和存储容量的服务器。
   软件环境配置 – 安装和配置被测系统、相关的数据库、中间件等软件。并且要保证测试工具能够正确地与被测系统进行交互。比如，对于一个基于Java开发的Web应用，需要安装JDK、Web服务器（如Tomcat），并配置好数据库连接等参数。

4. 测试场景设计
   场景设计是性能测试的基石，它应紧密贴合业务实际与用户行为模式。通过模拟高频、高渗透率的用户操作，可以有效放大潜在的性能瓶颈。
   场景设计需确保场景既具有代表性又能全面覆盖关键业务流程，从而精准定位性能问题。
   性能测试一般包括四个场景：基准场景、容量场景、稳定性场景、异常场景。
   针对不同类型的性能测试场景，需清晰界定关键性能指标（KPIs），如内存占用、CPU使用率、网络流量、电池消耗、帧率稳定性、卡顿率以及应用启动时间等。这些指标的选择应基于场景特性和测试目标，确保评估的全面性和针对性。
   

5. 测试脚本的开发
   录制或编写脚本 – 可以使用测试工具提供的录制功能来生成基本的测试脚本。例如，在JMeter中，可以通过代理服务器录制用户在浏览器中的操作行为，生成测试HTTP请求的脚本。对于复杂的业务逻辑，还需要手动编写脚本进行补充和优化。
   脚本参数化和关联 – 参数化是指将脚本中的一些固定值（如用户名、密码等）替换为变量，以便在测试过程中使用不同的值进行测试。关联则是处理脚本中不同请求之间的动态数据传递。例如，在一个用户登录 - 下单的测试场景中，需要将登录后的用户ID等信息关联到下单请求中。

6. 测试执行
   设置测试场景 – 根据测试计划中的负载类型和负载级别，设置不同的测试场景。如设置从低负载（10个并发用户）到高负载（1000个并发用户）的多个场景，每个场景持续一定的时间。
   执行测试脚本 – 启动测试工具，按照设置的场景执行测试脚本。在测试过程中，收集系统的性能数据，如响应时间、吞吐量、资源利用率等。同时，观察系统是否出现错误或异常情况。

7. 测试结果分析
   数据收集与整理 – 收集测试过程中记录的所有性能数据，包括每个请求的响应时间、服务器资源使用情况的统计数据等。将这些数据进行整理，例如，可以制作成表格或者图表的形式，方便后续分析。
   性能瓶颈分析 – 通过分析数据，找出系统性能下降的原因。可能是数据库查询效率低下、网络带宽不足、代码算法复杂等原因导致的。例如，如果发现某个功能的响应时间随着负载增加急剧上升，通过查看数据库查询日志，发现是因为缺少合适的索引导致查询速度变慢。
   生成测试报告 – 测试报告应该包括测试目标、测试环境、测试结果（包括性能指标数据和性能瓶颈分析）以及改进建议等内容。报告要清晰、准确，以便开发人员和管理人员能够理解测试情况并做出决策。

六、测试场景设计

1. 业务场景调查
   (1)关键、核心业务
   从系统亮点出发，以主要的业务逻辑点为第一核心：这些功能对系统或公司来说往往具有举足轻重的地位，无论怎样都必须要优先执行满足这以功能的性能测试
   (2)高访问量的功能点
   系统中表现在系统关键、核心业务前面必须要经过的地方：比如，域控客户端登录时影响域控价值的关键，即需要对登录相关接口进行高并发的验证；而登录涉及到后台freeipa相关数据同步，即需要对freeipa相关的，信息同步、校验等接口进行高并发验证。
   (3)业务复杂度
   往往说来业务逻辑复杂度的都具备1、2点的要素，可能其功能使用的人数较少但是对系统有很严重影响：这些功能由于其业务逻辑具有的复杂度，往往出错的可能性也比较高，所以这些功能也是必须要进行测试的。

2. 实际落地
   在聊四个场景之前我们先聊下性能测试一般流程，流程就是规则，有这个流程后遇到性能测试就不会乱手脚，就可以按这个流程开展工作。关于每个动作需要做什么内容，做性能测试的人一看就知道需要做什么内容，在这里就不展开说明具体内容。我们做好前置条件后，就可以开展场景设计与执行。
   

3. 基准场景
   基准场景就是单个接口进行压测，那么我们应该怎么做基准场景呢？
   测试环境准备
   测试数据准备
   参数准备
   参数化数据
   参数化数据来源需要确保数据的有效性，这些数据需要满足下面两个条件：
   满足生产环境数据分布
   满足性能场景中数据量的要求

4. 压测场景
   通过抽取生产日志，梳理业务逻辑。比如通过 lambda 平台可以获取被压测日志，通过检索条件获取我们想要一段时间的接口数据：也可以在 Nginx 日志中获取相关数据， 可以通过写 python 脚本处理也可以使用 shell 命令获取我们想要的数据。
   注意：如果出现某个请求的高并发时间点和其他的请求不在同一时间点，就一定要做多个场景来模拟，因为场景中的业务模型会发生变化。
   通过上面步骤得出被压测接口的调用量与请求比例，也就可以拿某请求的数量除以总请求数得出每个接口的比例。有了业务比例后接下来我们需要梳理业务场景，用场景覆盖业务比例。