本文从性能测试基础理论，真实的后台测试实践举例，常见性能问题举例三个方面，帮你快速入门后台性能测试
性能测试的目的
性能测试需求来源
在项目测试的过程中，经常会收到或评估出如下需求：
- XX天要做活动，流量要翻十倍
- 这次项目加了个XX功能，需要压一下
- 做了个性能优化，看看效果怎么样
- 做了个新系统，性能要测一下
- 这个模块并发有风险，要压一下看看
- 这个模块有几个参数需要压一下调整下
常见的性能测试目的
在正常请求流量下，系统的各个性能指标：
- 平均响应时间，响应时间分布，超时率
- 根据线上部署情况，CPU，内存，磁盘io，网络等硬件资源使用情况
- 请求成功率
系统能够承受的极限压力，以及系统性能瓶颈: - 极限压力指的是在满足运维指标的情况下，系统能承受的每秒最大请求数（平响，成功率）
- 极限峰值压力，极限持续压力
系统稳定性: - 在多并发情况下，系统可能存在异常
- 在长时间运行的情况下，系统可能出现异常
- 在大量异常请求或异常响应情况下，系统可能出现异常
性能测试设计
做性能测试设计，首先问自己4步:
- How – 怎么压
- 起多大压力？怎么起压力？压多长时间？
- Who – 要压谁
- 压测对象是什么，模块？系统？
- What – 压什么请求
- 压测接口有哪些？
- 压测请求怎么构造？
- Where – 压什么环境
- 线上环境？线下环境？
- 压测环境怎么保证真实?
How-怎么压-根据目的确定方案
在正常请求流量下，系统的各个性能指标：
- 方案最简单明确，按需求压力进行加压，观察收集各个指标即可
- 需求流量分析结果设计流量(线上流量、产品开发评估、漏斗模型等)
- 各个性能指标的获取
- 平均响应时间/吞吐量：压测工具
- 机器指标： 负载监控：cpu 、内存、硬盘io、网络 io
- 业务指标： 业务日志
系统能够承受的极限压力，以及系统性能瓶颈:
阶梯加压法，通过调整请求并发数逐步提高压力，收集系统信息获取系统每秒处理请求数，平均响应时间和成功率系统稳定性：
- 使用一定qps（极限/日常）
- 提高并发数
- 长时间压力下
- 异常请求或后端返回情况下
What-压测什么请求
根据线上流量情况设计:
- 处理线上混合流量时系统情况：登录服务重构
- 系统性能回归常用：增长平台性能优化
根据需求流量分析结果设计:
- 新系统：足迹地图服务上线
- 活动：地图国庆/春节活动
Who-压测对象是谁
根据发压对象，调整压测方案
- 国庆活动：活动整体系统，从入口层发压
- 新模块上线：模块级压测
Where-压测什么环境
线上性能测试：准确、风险大
线下完整系统的性能测试：成本极高，相对准确
线下子系统的性能测试：最常用，准确性较差
线下模块级性能测试：通常用来预估
线下性能测试
线下测试环境与线上环境一致 = 几乎不可能
了解部署可能的差异对系统性能的影响，尽量接近线上环境
机器性能：与线上同配置（CPU/内存）、机器类型相同（tkex中选择生产环境负载）
网络情况：部署地域、发压&被压机器同地域
配置参数：日志级别、连接池大小……
数据库，redis等其它公共模块的版本，配置等
最重要的一点：不要请求到线上环境！！！包括各种连接下游配置、mysql、redis等存储
线上性能测试
- 线上性能测试优势:
- 精准得出性能测试结果
- 线下没有成本搭建性能测试系统时
- 系统级发现模块间链接问题
- 需要解决的问题
- 数据影响、流量影响、外部影响、系统服务拒绝风险
- 数据影响：指压测产生的数据对线上影响
- 方案1：数据清理
- 方案2：数据隔离（逻辑隔离，物理隔离）
- 流量影响：指线上流量和压测流量共用一个模块互相影响
- 线上切流量
- 压测流量标识
- 外部影响：线上压测影响外部基础服务或下游业务方
- 专有逻辑打桩mock
- 系统服务拒绝风险：压挂了怎么办
- 阶梯控制压力、做好预案、流量低峰进行
性能测试方案
性能测试方案应该包含的内容：
- 设计目标：实现的功能、性能目标
- 系统环境：
- 被测系统与周边模块的联系（拓扑图）、被测系统所在机器的软硬件参数、测试环境的部署
- 接口或模块的压测目标：
- 线上接口访问量统计、压测场景分析、被测接口功能梳理、各接口压测目标
- 数据、脚本的准备：压力词表产出方式、压力计算、压力工具、服务支持（主要是需要开发做的）、计划的压测过程
- 压测数据收集及系统监控
- 风险评估：潜在的对其他系统的影响（如线上）、线下压测存在的不可抗力的不准确性、无法提前避免的情况
- 如何决定压测环境的部署方式？
- 目标和对应的测试环境：
- 测试迭代会不会导致系统性能下降->线下单台
- 新模块的稳定性及极限压力->线下等比例缩放或线上
- 流量飙升->线下等比例缩放或线上
- 如何产出压测词表？
- 按接口分别配置压力
- 混压还是单压
- 接口内区分不同类请求（真实数据还是数据构造）
- 避免命中缓存热点或数据库热点
性能测试执行
性能测试执行包括：
- 测试工具准备：压测工具、第三方依赖mock、环境监控配置（007）
- 测试词表（测试数据）准备：编写脚本拉取线上日志做处理、编写脚本直接构造测试词表、跑脚本插库、写redis queue
- 测试环境搭建：严格按照测试方案搭建测试环境、注意不要配置连到线上、涉及请求第三方提前沟通、测试连通性，包括压测工具正确性（观察error日志）、注意服务的启动参数是否跟线上一致（cpu、内存等）
- 起压：按照测试方案起压、时刻观察系统状态（系统监控、负载监控、error日志，业务日志）
- 性能问题初步分析及定位：响应时间变长（cpu、内存、慢sql、数据库监控、业务日志、error日志）、模块挂掉（ cpu、内存、error日志）、返回报错（error日志）
性能测试报告
性能测试报告应该包含如下内容（包括但不限于）:
- 性能测试方案&测试建模：作为链接或者附件放在测试报告里
- 测试结论：被测系统是否满足性能要求、如果不满足，你的建议是什么、对于线上部署的建议（机器配置、数据库/redis配置、配置参数）
- 压测结果：压测得到的吞吐量、平均相应时间、超时率等
- 问题列表&优化方案：
- 发现了什么问题，如何解决的，解决前后性能对比，可能的话可以进行多轮测试
- 如果有自己的分析，可以加上自己的分析过程
- 监控情况
测试报告示例：
xx五一活动压测实践
需求背景
在五一出行高峰，基于IP使用、导航功能场景规划活动，希望借力五一自然流量高峰，提升IP使用人数及天频。活动包括两部分：
趣味H5小游戏「前进吧，导航官」，引导用户在游戏中完成IP设置；
APP端内「集福利拼图得出行礼包」活动，吸引导航用户参与，提升导航功能渗透，进而提升月人天。
两个活动通过拼图发放连结，福利拼图可在小游戏中获得、也可在使用语音导航中获得。
压测场景分析
基于测试建模和服务拓扑关系，进行压测接口和接口功能梳理。
确定需要压测的接口/场景
确定要压测的接口，主要从以下3个方面考虑：
访问量大的接口：进入活动页面就会访问的接口
活动主页 info接口
活动奖品领取 grant接口
本次新增接口：本次拼图为新增功能，相关接口
拼图信息、拼图分享码生成、领取拼图、赠送拼图等
本次改动较多接口：抽奖接口
以下为本次压测的具体压测接口和场景：
确定压测目标
根据产品给出的量级预估
产品预估量级：每天大概Xw的曝光UV，PV可能Xw
预估公式：PV/（83600） 3 = Xqps
参考往期活动
21年国庆活动info接口最高qps为X
21年十二月活动info接口最高qps为X
本次活动流量预估
产品给PV值很低，本次活动无业务流量峰值（固定时间开奖、提现等），参考往期活动峰值和经验，压测目标暂定访问量大的接口>Xqps，其他接口>Xqps，即满足需求
实际最高QPS：info接口 Xqps
压测环境
压测环境：本次压测在测试环境进行
链路压测方案
方案一：去掉下游依赖，mock
方案二：直接请求or改造下游服务
方案选择
积分、商城服务（无修改）：直接请求
画像服务（有修改）：请求本次画像测试环境
登录、稽查服务：mock
压测工具&压测用例编写
使用现有平台或工具均可
优测平台：https://utest.21kunpeng.com/home
新活动（无线上数据），编写用例直接构造测试词表
压测用例编写举例
测试场景一：合成拼图lottery接口
场景分析：合成拼图的前提条件是需要有拼图碎片，所以需要先构造拼图数据（词表）
数据构造方法：1、写脚本插入写入；2、调抽奖接口获取
采用方法：经过分析，调接口构造数据的方法最简单：单独配置一个抽奖玩法，每次抽奖获取合成所需的8张拼图
测试场景二：导航官酷跑后发奖grant接口
场景分析：导航官酷跑游戏，先调用info接口，获取本次酷跑地图（在多少米获取金币），酷跑结束后，调用grant接口领取金币奖励。Grant接口的请求参数，需要使用之前info接口的返回值。
常见的性能问题举例
数据库相关问题
数据库连接池设置不合理/未设置/失效
问题举例：五一活动中数据库连接池设置被误删除
问题现象：qps压不上去/错误率上升，error日志：数据库连接失败等
数据库索引问题：未使用索引，索引字段使用类型错误
问题举例：五一活动中查询活动id字段，应使用string类型，实际使用int类型
问题现象： qps压不上去，平均相应时间变长，数据库存在慢查询、CPU过高
数据库索引问题：索引设计过多，导致插入过慢
问题举例：春节活动发现发奖代理db插入较慢，发现建表时字段设计过大，索引设计多，导致插入一行占用空间带
数据库表分区问题：未按照分区字段查询，导致全表扫描
问题举例：五一活动查询抽奖表，该表按照user_id分区，但使用的是id作为查询条件
问题现象：qps压不上去，平均相应时间变长，数据库存在慢查询、CPU过高
接口逻辑问题
返回数据问题：
问题举例：首页、抽奖等接口返回回包过大（大于500kB）：通过前端添加请求参数，过滤本次活动无用数据
问题现象：回包过大
无关逻辑/调用：
问题举例：春节活动无需用户画像功能，在代码中依然调用了该功能
调用第三方问题
调用第三方服务错误：
问题举例：调用画像服务接口错误，调用了内部接口，性能无法满足对外服务要求
问题现象：qps压不上去/错误率上升，error日志：调用画像接口失败