性能测试项目实战
1.背景
公司之前的测试团队做API的⾃动化测试都是使⽤JMeter等⼯具来进⾏，这样的话测试效率⽽⾔不是那么很⾼，⽽且在扩展性⽅⾯不是很有竞争⼒的。所以开发了新的测试平台，但是考虑到公司的测试⼈员有1000⼈，那么就需要验证1000⼈同时使⽤测试平台，是否会出现平台⽆响应以及崩溃（雪崩）的情况。
2.性能测试过程
2.1测试前期准备（前置工作）
| 序号 | 工作内容 | 负责人 | 时间 | 备注 |
| 1 | 测试场景的梳理 | 小A | 2022.02.18---2022.02.18 | |
| 2 | 资源的采购（阿里云服务器，配置与生产环境一致） | 小B | 2022.02.18---2022.02.18 | |
| 3 | 目标的输出 | 小C | 2022.02.18---2022.02.18 | |
| 4 | 测试数据的准备 | 小C | 2022.02.18---2022.02.19 | 100000条数据 |
| 5 | 人员不够 | 测试经理协调 | 2022.02.18---2022.02.18 |
2.2测试工具的引入
基于梳理的业务场景和服务底层稳定性体系的保障，性能测试⼯具的选择具体如下：
| 序号 | 工具 | 选择理由 | 备注 |
| 1 | JMeter | 开源，可以做常规以及并发测试 | |
| 2 | Locust | 开源，基于协程，来测试服务稳定性 | 验证服务是否会出现崩溃 |
| 3 | JVM监控工具 | 检测服务是否会出现OOM内存溢出 | |
| 4 | Grafana&InfluxDB | 数据可视化报表展示 |
2.3测试计划
2.3.1背景
公司之前的测试团队做API的⾃动化测试都是使⽤JMeter等⼯具来进⾏，这样的话测试效率⽽⾔不是那么很⾼，⽽且在扩展性⽅⾯不是很有竞争⼒的。所以开发了新的测试平台，但是考虑到公司的测试⼈员有1000⼈，那么就需要验证1000⼈同时使⽤测试平台，是否会出现平台⽆响应以及崩溃（雪崩）的情况。
2.3.2人员配备
| 序号 | 工作内容 | 负责人 | 时间 | 备注 |
| 1 | 测试场景的梳理 | 小A | 2022.02.18---2022.02.18 | |
| 2 | 资源的采购（阿里云服务器，配置与生产环境一致） | 小B | 2022.02.18---2022.02.18 | |
| 3 | 目标的输出 | 小C | 2022.02.18---2022.02.18 | |
| 4 | 测试数据的准备 | 小C | 2022.02.18---2022.02.19 | 100000条数据 |
| 5 | 人员不够 | 测试经理协调 | 2022.02.18---2022.02.18 |
2.3.3技术（工具）选择
| 序号 | 工具 | 选择理由 | 备注 |
| 1 | JMeter | 开源，可以做常规以及并发测试 | |
| 2 | Locust | 开源，基于协程，来测试服务稳定性 | 验证服务是否会出现崩溃 |
| 3 | JVM监控工具 | 检测服务是否会出现OOM内存溢出 | |
| 4 | Grafana&InfluxDB | 数据可视化报表展示 |
2.3.4测试范围
| 序号 | 场景 | 目标 | 负责人 | 时间 | 完成情况 | 备注 |
| 1 | 测试并发登录 | 满足100人同时登录 | 小A | 2022.02.18---2022.02.19 | 完成 | |
| 2 | 产品列表加载 | 同时满⾜50个⼈加载,响应时间⼩ 于5秒 | 小A | 2022.02.18---2022.02.19 | 完成 | |
| 3 | 产品搜索 | 同时满⾜50个⼈加载,响应时间⼩ 于5秒 | 小A | 2022.02.18---2022.02.19 | 完成 | |
| 4 | 同时⽀持执⾏API测试 ⽤例 | 响应时间⼩于5秒,最⼤并发100 | 小B | 2022.02.18---2022.02.19 | 完成 | |
| 5 | 上传⽂件最⼤⽀持2G | 不能出现OOM | 小B | 2022.02.18---2022.02.19 | 完成 | |
| 6 | ⽀持持续的发送API请 求 | 验证服务的稳定性 | 小B | 2022.02.18---2022.02.19 | 完成 |
2.3.5测试风险
目前测试暂无风险
2.4测试设计与开发
2.4.1JMeter工具
测试并发登录
2.4.2Locust开发（持续发送API请求）
#! /usr/bin/env python
# -*- coding:utf-8 -*-
#author:特昂糖
import time
from locust import HttpUser,task,between
class QuickStartUser(HttpUser):
host = 'http://47.95.142.233:8000'
min_wait = 3000
max_wait = 6000
def login(self):
r=self.client.post(
url='/login/auth/',
json={"username":"******","password":"*****"})
return r.json()['token'] @task
def api(self):
r=self.client.post(
url='/interface/run/api/32',
headers={'Authorization':'JWT {token}'.format(token=self.login())})
assert r.status_code==200
2.5测试执行与管理
登录场景
2.6测试报告（分析）
2.6.1参与人员
| 测试人员 | 版本 | 备注 |
| 小A,小B,小C,小D | V1.3.1 |
2.6.2报告汇总
测试并发登录
测试结论：结果结果不符合预期，在100⽤户并发登录的情况下，响应时间最⼤是31.88s。 过程数据 错误汇总| 序号 | 错误类型 | 错误日志 |
| 1 | Java.lang.OutOfMemoryError | 详细的错误⽇志信息 |
| 2 | TimeOutExpection | |
测试风险
| 序号 | 风险描述 | 备注 |
| 1 | 并发⽤户数载100的时候是满⾜要求，但是在110的时候，响应时间不满⾜，可能会给⽤户的 体验很差劲。 | |
| 2 | 在20次的测试中，存在1次的上传⽂件失败，概率是5% | |
测试结论
依据上述的结果，整体测试结论具体汇总如下：
| 序号 | 并发登录 | 是否通过 | 备注 |
| 1 | 测试100人并发登录 | 不通过 | |
| 2 | |||
| 3 |