一、需求调研：（我们公司需求为列简单列出）
- 测试范围：订单流程、搜索等
- 系统架构： 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:压测前，分析各业务之间强弱依赖关系，不同服务会根据业务属性来进行高度内聚解耦，划分不同功能的优先级和重要程度
三、链路场景分析：
- 场景和业务都梳理了，我们就需要对它的分析，需要从需求到测试点的覆盖和执行；
- 任务拆解，细化，把场景转化成操作流程；
- 任务确定时间；测试准备、数据准备、环境准备、瓶颈优化，这些时间都需要考虑进去，然后出一个时间；
- 权重划分：哪些重要，资源偏向，还有就是场景比例的投放得当；
四、压测执行：
- 以上工作做得差不多，还是需要拉一个会议讨论下，需要各方面的支持资源都需要沟通好
