性能测试项目实战
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 |
|
|
|