标签:bsp 紧急 数据量 垃圾 order 方案 重试 info 防火墙
一、前言
因为之前有学习到Jmeter相关内容,现在想总体整理一下性能测试内容。
二、性能测试流程导图
三、相关设计文档
1.系统架构图:了解被测系统的技术架构,包括从客户端到DB的周转流程、应用服务器、中间件等;
2.网络拓扑图:和系统架构图类似,这个更多的是体现在不同层级之间的网络拓扑关系,也可以和系统架构图结合在一起,根据项目具体情况而定;
3.需求说明文档:了解被测系统的业务流程,不同模块之间的关系,便于后面业务场景建模;
4.接口设计文档:大多性能测试都是用过调用模块间的API来进行模拟并发,了解业务模型对应的API,包括协议类型、方法、传参类型、入参、出参等信息是很必要的;
5.数据库表设计文档:测试过程中产生的数据会写入哪个库哪个表,不同的API参数会对哪张表甚至哪个字段产生什么影响,熟悉“数据流”是很必要的一件事情;
四、确认性能指标or目的
1、测试目的
测试目的 | 说明 |
并发测试 | 测试系统在一定条件下可承受的最大并发数 |
容量测试 | 测试系统在一定配置下的最大服务能力 |
配置测试 | 验证系统在不同配置下的性能表现,为性能调优和扩容提供重要参考 |
验收测试 | 验证系统在一定压力下长时间整处理请求的能力,一般时间越长,系统稳定性越好 |
稳定性测试 | 验证系统在一定压力下长时间正确处理请求的能力,一般事件越长,系统稳定性越好 |
多节点测试 | 验证系统在服务群下的一个负载均衡能力 |
2、测试指标
指标名称 | 指标数据 | 指标说明 |
TRS | 100 | 每秒事务数,很重要的一个指标,衡量系统的处理能力 |
RT | 95%、99%、99.99% | 百分比请求的响应时间,即n%以内的RT请求响应时间是多少,百分比越高,RT越低,系统越稳定 |
error | 0.1%、0.01% | 错误率,即可接受的请求失败的占比 |
Cache | 90%、95% | 缓存命中率:命中率越高,使用缓存的收益越高,系统的性能越好 |
CPU | 75%、90% | CPU使用率,一般来说75%是一个阈值,超过85%就需要重点关注 |
三、性能测试环境
1、被测系统环境:FAT(生产环境)、UAT(验收环境)、预发布环境等;
2、环境类型:docker容器、虚拟机或者其他类型;
3、web/app/service/db等服务器配置,比如nCnG;
4、配置信息
配置名称 | 配置信息 |
JVM堆内存分配 | JVM的堆配置的内存大小 |
最大连接数 | 中间件、DB的最大连接数 |
线程池配置 | 线程池数量、回收策略等 |
timeout | 超时时间 |
异常/错误重试次数 | 请求异常或错误时的重试策略、次数 |
5、服务器/DB登录账号、密码,服务部署路径、日志路径等;
6、挡板/Mock:某些依赖关系较复杂的系统或者模块,是否需要挡板?如果需要挡板,是来提供?
四、预埋数据
1、基础数据:比如电商系统的库存数、SKU、用户信息等;
2、预埋/铺底数据:根据生产实际的数据量对测试环境的DB进行数据预埋,尽量和生产保持一致或可以等量换算(对应的BD实例名);
3、测试数据:测试数据如何生成?数据生成规则,比如加解密、随机生成等;
4、垃圾数据:每轮测试产生的垃圾数据如何隔离或清理;
5、数据脱敏:如果是在生产环境进行压测,如何进行数据脱敏或者数据隔离防污染策略。
五、接口说明
被测系统业务场景对应接口协议类型,比如:
协议类型 | 所需提供的信息 |
HTTP | 方法、参数类型、host、 port、path、请求响应报文等 |
SCOKET | host、port、请求响应报文等 |
DUBBO | 服务注册类型(zookeeper)、版本、timeout、重试次数、最大连接数、同步/异步、接口名、方法、参数类型、value等 |
六、测试开始前确认
1、容器:镜像克隆成功,服务部署完成,且完成功能性校验;
2、压测机:测试机准备完成,并完成性能测试环境的调试验证;
3、工具:相关监控工具等部署设置完成,比如服务器监控工具、DB监控工具等;
4、网络:网络连接通畅(如果有防火墙策略,运维同事应在测试方案评审开始前准备完成,并告知相关人员调试验证);
5、数据:基础数据、预埋数据、测试数据准备完成(正确+可用+数据量级达标);
七、需求变更说明
1、涉及范围:需求变更类型(业务场景、功能变更等)、环境交付日期、服务器地址、配置信息变更等;
2、提前说明:变更导致延期交付或提前交付的具体工时(可以精确到半天或小时),最晚多久,需要提前通知;
3、应对策略:针对不同变更类型、影响范围、风险程度、时间等因素评估如何处理,比如:打回、需求顺延排期等;
八、交付日期和deadline
1、交付预期时间:方便性能测试同事根据需求紧急情况、优先级等预估工时,进行工作排期;
2、deadline:即生产发布时间,根据交付时间和生产发布时间,确认具体的工作安排(比如从交付到上线只有一周,如何完成任务拆分和细化,不同人员安排不同工作,里程碑等);
以上内容,仅供参考,具体的测试需求,还需要根据具体的项目类型、团队人员构成、职责等进行合理灵活的取舍。
参考文章:https://mp.weixin.qq.com/s/h0nUKu3LCuQppsuRN-klcQ
标签:bsp 紧急 数据量 垃圾 order 方案 重试 info 防火墙
原文地址:https://www.cnblogs.com/zhaocbbb/p/12891915.html