|
背景：迩来正在预备双十一的预备，以是压测就是我们的第一要务。
一、需求调研：（我们公司需求为列简单列出）
- 测试范围：订单流程、搜索等
- 体系架构： gateway 、ES 、MySQL redis
- 业务逻辑 & 数据流向：略
- 测试数据量：商品数目：1w，用户数据：1w
- 外部依赖：调用其他rpc,如user服务，mq等
- 预期指标：
- 1> 业务监控体系，找到业务量峰值，除以机器数目，盘算出单机体系每秒的业务量
- 2> 访问日志统计接口调用量。大概数据库表中查询天天的写入数据量，通过eads就能相识到
- 下令：awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10
- 3> 只知道天天大概的业务总量，（天天的总业务量*80%） / （24 小时*3600 *20%）/ 部
- 署机器数目 / 性能冗余量（30%-50%）
- 业务比例:暂无
- ps1 :性能测试，需求分析特别紧张，一定要知道真实场景，场景不对，就等于白忙活；监控+工具提前都需要预备；
- ps2:真实的压测场景，总会遇到一些问题，产物大概技术就给你说，我有个接口你给我们压压，就是不说我给你压多少；最好大概压的场景和现实的效果有收支，如果真的出了问题，大概要背锅（不外迄今为止没有发生线上严峻的问题，除了一次的优惠券）
二、业务场景：（以我们公司为例）
- 明白我们的测试范围和目的
- 我们是交际电商+活动；促销活动，商品搜索、物流仓储业务，底子消息及推送服务（mq）,订单交易+余额付出，拼店业务+秀场业务
- 知道了这些范围，我们就可以和产物、开发、一起来梳理这些流程：
- 首页：就是登岸，检察活动首页，看是否瓦解
- 商品：商品搜索（数万级别）、检察商品详情
- 订单：选择商品下单，确认订单，利用余额付出；选择商品+购物车，举行下单付出；最后检察订单商品；从拼店入口+选择商品，举行下单
- 付出：接纳余额付出，三方付出暂时没有思量，mook掉了
- 个人中央，签到流程，
- 活动，首页营销活动，领取奖品,斲丧奖品和优惠券
- ps1:APP首页会关心活动首页和活动会有强依赖；商品和搜索、商品详情，参加购物车，甚至下单会发送消息有强依赖；订单、购物车、付出、搜索、用户和交易有强依赖的业务
- ps2:压测前，分析各业务之间强弱依赖关系，不同服务会根据业务属性来举行高度内聚解耦，分别不同功能的优先级和紧张水平
三、链路场景分析：
- 场景和业务都梳理了，我们就需要对它的分析，需要从需求到测试点的覆盖和执行；
- 任务拆解，细化，把场景转化成操纵流程；
- 任务确定时间；测试预备、数据预备、环境预备、瓶颈优化，这些时间都需要思量进去，然后出一个时间；
- 权重分别：哪些紧张，资源方向，另有就是场景比例的投放得当；
四、压测执行：
来源：https://www.cnblogs.com/Slowfish/p/11729280.html | 
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡