性能测试fangan
| XX 5.0系统 性能测试方案 |
修订历史记录
1 项目概述
1.1 背景说明
1.2 测试目的
为保证在日常运行及大型活动期间，稳定运行、应用快速，对进行性能测试，验证系统是否能够达到业务所需的性能指标，同时发现系统中存在的性能瓶颈，并进行改进，起到优化系统的目的。主要包括以下几个方面：
- 评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力。
- 识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
- 系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
- 检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
- 验证稳定性和可靠性：在一定生产负荷下执行测试一定的时间，用以评估系统稳定性和可靠性。
1.3 参考文档
2 测试环境
2.1性能测试环境拓扑图
2.2服务器配置
| 服务器 | 数量 | 硬件配置 | 软件环境 | 作用 |
| 压测机1台 | 1 | 8C16G | linux | 加压 |
| 应用服务器 | （mzapipress：4台，UAC：2台） | 8C 16G*6 | Tomcat | 应用服务器 |
| 数据库服务器 | 1 | 8C16G | mysql | 数据库 |
| redis | 1 | 8G集群版（2节点） | 缓存服务器 | |
| ES | 1 | ？ | ？ | |
| MQ | 1 | 共用PRE环境 | ||
| nginx | 1 | 共用PRE环境 | ||
| 文件服务器 | 1 | PRE服务 |
备注：服务器配置根据业务需要申请
3 测试数据
3.1基础数据准备
脱敏、同步线上数据，保证被压测系统数据库量级和线上一致，
目前压测环境23万用户数据，线上1000万不都是活跃用户，有效用户数23万已足够
3.2 入参数据准备
根据不同的业务场景，对应的具体接口入参可以从数据库提取、代码生成、计数器、随机数等方式来进行参数化，数据唯一性接口保证每次访问入参不重复，避免数据缓存造成压测误差
查询接口：在swagger中找到对应的api，通过参数去数据库导出入参数据。
写接口：根据业务需求造出对应入参数据。
4 指标测试目标要求
4.1 性能指标
| 类别 | 工具 | 判断维度 | 通过 | 备注 |
| 接口性能 | Jmeter | TPS | 参照4.2公式 | |
| 超时概率 | 小于0.5‰ | |||
| 错误概率 | 小于0.5‰ | |||
| 响应时间 | <200ms |
4.2 性能指标计算公式
若在每天的某一时段里有很大的访问量，其他时间相对较少，可以用简单峰值法、二八法或九一法。
举例：
下图为2021年2月3日三亚地区推广力度较大的活动峰值数据，计算举例：
数据依据：活动流量，2月3号11点到12点一小时内访问量（打开次数）从1100激增到峰值52329，用户数从1500增加到峰值27198，一天内总访问量为9.04万，11点到13点之间总访问量为7.56万，总访问人数4.88万。平均页面停留时长20S
计算方法：根据活动集中访问的特殊性，按1/9原则计算活动并发数（90%用户量集中在10%时间内完成），52329*90%/3600*10%=130.825个/s，
按2/8原则计算日常并发数： (9.04万*80%)/（8小时*20%*3600）=12.5个/s，
预估：预估两年内小程序用户数从1000万以30%的增长速度，并发数若要满足未来两年业务需求，活动应满足130.825*（1.3*1.3）=约221个/s，日常满足12.5*1.3*1.3=约21个/s
平均响应时间计算：响应时间的2-5-8原则，取2秒体验要求，减去网络及各节点时间损耗，接口响应时间<200ms为达标
TPS=并发数/平均响应时间，当前至少要满足131/0.2=655TPS，两年后：221/0.2=1105TPS，以上指标为最低tps要求。
错误率：（失败交易数/交易总数）*100%，参考标准：一般成功率不低于99.4%,成功率99.7%为达标
4.3 折算公式
根据节点数、配置、以及性能瓶颈三个维度去估算出压测/线上系数比n(1)，目前压测环境和生产环境节点配置一致，数据库及rides配置略低，若压测环境满足业务需求，则理论上生产环境能支撑相同压力
验证：同一个接口在同等并发下统计各环境tps，验证压测/线上tps系数比是否等于n(1)
4.4 系统资源使用指标
| 资源 | 监控资源 | 通过 | 备注 |
| CPU | CPU sys% | 小于或者等于30% | CPU指标主要指的CPU利用率，包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。 |
| CPU利用率一般维持在70%左右的水平，高峰期达到90%的水平，是不浪费资源，并比较稳定的。 | |||
| CPU sys%小于或者等于30%, | |||
| CPU wait%小于或者等于5%。 | |||
| CPU wait% | 小于或者等于5% | CPU Load要小于CPU 核数。 | |
| System\Processor Queue Length | CPUload<4 | ||
| 内存 | SWAP利用率 | SWAP交换空间利用率要低于70% | 太多的交换将会引起系统性能低下。 |
| 硬盘 | Physical Disk\% Disk Time Logical Disk\% Disk Time | 小于等于80% | 正常值<10，此值过大表示耗费太多 时间来访问磁盘，可考虑增加内存、 更换更快的硬盘、优化读写数据的算 法。若数值持续超过80 (此时处理器 及网络连接并没有饱和)，则可能是内 存泄漏。 |
5 测试策略
测试概述：
- 以各组实际需求，迭代上线前测试产品提出性能测试需求的接口
- 每月进行接口分析，进行接口筛选，进行单接口性能测试
- 活动期间，按活动需求进行性能测试
- 常规迭代接口并发用户不少于200,50并发为一个梯度进行加压，其他线上活动按活动类型做预估判断
- 指标值确定，迭代接口指标按经验值，单接口压测写接口1000，查询接口2000；活动接口以活动类型，参考历史最高值，并按4.2计算方法进行测算
- 测试场景，根据业务需求做以下场景测试
5.1 基准测试
5.1.1 测试说明
| 目的 |
|
| 方法 |
|
5.2 压力测试
5.2.1 测试说明
| 目的 |
|
| 方法 |
|
5.2.2 测试场景
不断加大并发数、同时监控CPU,内存，CPUload，带宽，TCP连接数等各项性能指标，当某一指标达到瓶颈记录此时的并发数及性能瓶颈。
5.3 负载测试
5.3.1 测试说明
| 目的 |
|
| 方法 |
|
5.3.2 测试场景
不断加大并发数，当RT和TPS出现交叉拐点时记录此时对应的并发数、RT、TPS及相应的性能资源参数。负载测试结果可在5.2压力测试结果文件中分析出最优性能，故此步测试可省略。
5.4 组合场景并发测试
5.4.1 测试说明
| 目的 |
|
| 方法 |
|
5.4.2 测试场景
根据业务场景合理设计各个接口压力比，在确定比例之后，通过jmeter按比例施加压力，来检测系统在混合场景下性能。
5.5 稳定性测试
按照日常平均使用量的80%，根据实际运行峰值时间段进行7*24小时测试，且资源利用率符合4.2节定义的标准。
5.6单台服务探容测试
| 目的 |
|
| 方法 |
|
6测试范围
6.1 活动接口
综合活动、大型线上活动主要接口，并发数较高、调用率较高的接口，大型活动MZapi所有接口。
6.2 常规迭代接口
和各业务组SDM、TPM一起确认覆盖核心、关键、常用业务，从中提取接口。
6.3混合场景读写接口
根据APM监控，截取一段时间内实际业务调用频率TOP10接口、tps为TOP10接口，响应时长top10。
7进度安排，实际按月或线上活动需求填写
| 序号 | 角色 | 工作项 | 预计开始时间 | 预计完成时间 | 交付产物 |
| 一轮测试 | |||||
| 开发/运维 | 环境搭建 | 环境准备 | |||
| 1 | 测试 | 方案 | 性能测试方案 | ||
| 2 | 测试 | 脚本 | 性能测试脚本 | ||
| 3 | 测试 | 数据 | 数据 | ||
| 4 | 测试 | 运行脚本 | 执行压测 | ||
| 5 | 测试 | 报告 | 一轮性能测试报告 | ||
| 6 | 测试 | 优化 | 需要优化的接口清单 | ||
| 二轮测试 | |||||
| 1 | 开发 | 优化 | 优化 | ||
| 测试 | 运行脚本 | 执行压测 | |||
| 2 | 测试 | 报告 | 测试报告 | ||
| 3 | 测试 | 监测 | 稳定性测试（持续监测系统情况，有问题及时修复） | ||
| 4 | 测试 | 报告 | 稳定性测试报告 | ||
8性能测试工具
- 性能压试工具：JMETER，必要时进行分布式压测
- 监控工具：APM监控平台、Linux 监控命令
- 分析工具：jvisualvm、Jprofiler、Linux分析命令
9风险分析
| 序号 | 风险类型 | 描述 | 等级 | 缓解策略 |
| 1 | 过程风险 | 由于加大并发导致接口大批量报错，压测无法进行下去 | 高 | 遇到阻塞问题及时抛出问题一起排查，推动艰难的及时找sdm沟通 |
| 2 | 环境风险 | 由于场景功能问题或对接系统环境达不到压测要求，致使调用接口不可用，导致的压测场景无法执行。 | 高 | 在环境部署完成后先进行基准测试，保证环境可用。 对接系统环境协调，尽量能满足压测调用 |
| 3 | 人员风险 | 开发调优资源不足，调优不能及时保障进度 测试人员兼做功能测试，测试进度会相互影响 | 中 | 根据测试方案时间安排，如有冲突提前报备 |
| 4 | 其他风险 | 由于不可预测原因导致压测不能按计划完成 | 中 | 每日同步性能压测进度，有风险及时抛出 |