性能测试-如何开展

 一、需求调研：（我们公司需求为列简单列出）

• 测试范围：订单流程、搜索等
• 系统架构： 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:压测前，分析各业务之间强弱依赖关系，不同服务会根据业务属性来进行高度内聚解耦，划分不同功能的优先级和重要程度

三、链路场景分析：

• 场景和业务都梳理了，我们就需要对它的分析，需要从需求到测试点的覆盖和执行；
• 任务拆解，细化，把场景转化成操作流程；
• 任务确定时间；测试准备、数据准备、环境准备、瓶颈优化，这些时间都需要考虑进去，然后出一个时间；
• 权重划分：哪些重要，资源偏向，还有就是场景比例的投放得当；

四、压测执行：

• 以上工作做得差不多，还是需要拉一个会议讨论下，需要各方面的支持资源都需要沟通好
•