电商高并发高库存系统测试总结
一、压测：
- 高并发下接口能不能扛住（吞吐量、响应时间、错误率）
- 高并发下库存会不会超卖 / 少卖（数据一致性）
- 峰值流量下系统会不会崩（稳定性、限流、熔断、降级）
- 极端场景是否兜底（超时、重试、幂等、分布式锁）
1. 基准压测
- 单接口：商品列表、商品详情、库存查询、下单、扣减库存、支付回调
- 目标：
- RT：99 线 < 200ms（核心接口）
- 错误率：0
- 无超时、无 5xx
2. 混合场景压测（最真实）
- 浏览列表 → 详情 → 加购 → 下单 → 扣库存 → 支付
- 逐步加压：100→500→1000→2000→5000 TPS
找到： - 拐点（QPS 上不去、RT 暴涨）
- 极限承载
3. 长时间稳定性压测
- 7×24h 压测
- 观察：内存泄漏、句柄泄漏、连接池耗尽、日志暴涨、数据库慢查询累积
二、高库存 & 超卖重点测试
1. 库存扣减正确性
- 正常下单扣库存
- 未支付超时关单，库存回滚
- 支付成功 / 失败回调，库存只扣一次
- 并发同时扣同一个商品库存
- 最终库存 = 初始库存 - 真实支付成功订单数
- 绝对不能超卖（库存为负）
- 不能少卖（有库存却下不了单）
2. 并发扣库存压测
- 单商品库存 100
- 同时发起 200/500/1000 并发下单请求
- 结果必须：
- 最多成功 100 单
- 其余全部 “库存不足”
- DB 最终库存 = 0
3. 兜底方案测试
- Redis 库存预扣 + 数据库最终扣减
- 分布式锁（Redlock/Redis 锁 / 数据库锁）
- 接口幂等：重复下单 / 重复回调不重复扣库存
- 重试、超时、失败补偿机制
三、高可用 & 容错测试
- 限流测试
- 超过阈值直接拒绝，返回友好提示，不打崩系统
- 熔断测试
- 下游（支付 / 物流）超时 / 报错 → 熔断，不级联故障
- 降级测试
- 高峰期关闭非核心接口：推荐、积分、优惠券等
- 故障演练
- Redis 宕机 / 主从切换
- DB 宕机、慢查询、死锁
- MQ 堆积、消息丢失、重复消费
四、典型电商场景用例
- 商品详情高并发查询（缓存命中 / 穿透 / 击穿）
- 购物车高并发读写
- 普通商品批量下单（多用户、多商品）
- 热点单品超高并发下单
- 未支付订单自动取消，库存回滚
- 支付成功 / 失败异步回调
- 库存同步（后台改价改库存 + 前端实时展示）
- 超高峰流量突增（流量毛刺）
- 部分服务宕机时，核心链路可用
五、常用技术栈
- 压测工具：JMeter、Gatling、k6、Locust
- 缓存：Redis（分布式锁、库存、计数器）
- 消息队列：异步解耦、削峰、库存回滚
- 数据库：分库分表、事务、行锁、唯一索引
- 监控：Prometheus + Grafana、SkyWalking、Pinpoint
六、测试点总结
（一）电商核心功能模块
-
用户模块
-
商品 / 搜索 / 分类
-
购物车
-
订单 / 结算
-
支付
-
库存 / 库存联动
-
售后 / 退款
-
后台管理（商家 / 运营）
-
优惠券 / 活动 / 积分
-
消息 / 日志 / 权限
（二）每个模块重点测试点
1. 用户模块
-
注册：手机号 / 邮箱格式、验证码、重复注册、密码强度
-
登录：正常 / 异常、验证码错误、锁定机制
-
退出：清除登录态
-
个人信息：修改昵称、头像、地址 CRUD
-
地址：默认地址、最多地址限制、省市区三级联动
-
安全：修改密码、找回密码、绑定手机
2. 商品、列表、详情、搜索
-
商品列表：分页、排序（价格 / 销量 / 新品）、筛选
-
商品详情：标题、价格、库存、规格、图文详情
-
多规格：颜色、尺寸、套餐切换，价格 / 库存联动
-
收藏 / 取消收藏
-
搜索：关键词、空搜索、特殊字符、无结果提示、历史搜索
-
分类：一级 / 二级 / 三级分类跳转正确
3. 购物车
-
添加商品：成功 / 库存不足 / 下架商品
-
修改数量：增加、减少、超限控制
-
勾选 / 全选 / 反选
-
商品下架、库存不足自动置灰
-
商品价格变更提示
-
清空、删除、失效商品清理
-
购物车合计金额计算正确
4. 订单 & 结算
-
去结算：勾选商品进入确认单
-
收货地址选择
-
订单确认页：商品、数量、单价、运费、优惠、实付正确
-
提交订单：订单状态流转：
- 库存充足 / 不足
- 商品价格变动校验
- 重复提交拦截
-
待付款 → 待发货 → 待收货 → 已完成 → 已取消
-
取消订单：订单列表：筛选、搜索、分页
- 未支付可取消
- 已支付不能随意取消（需走售后）
-
订单详情：日志、物流、商品信息
5. 支付功能
-
支持的支付方式（微信 / 支付宝 / 余额 / 银行卡）
-
支付成功 / 失败 / 取消 / 关闭
-
支付超时订单自动关闭
-
重复支付拦截
-
支付回调幂等（同一条回调不重复处理）
-
余额支付：余额充足 / 不足
6. 库存
-
下单预扣库存
-
支付成功正式扣减
-
未支付取消 / 超时关闭：库存回滚
-
退款成功：库存返还
-
多规格独立库存
-
库存 = 0 无法下单
-
超卖控制（功能层面也要校验）
7. 售后、退款、退货
-
仅退款、退货退款
-
可售后时间段限制
-
商家审核：同意 / 拒绝
-
用户填写物流单号
-
退款金额计算正确
-
退款成功后资金原路返回
-
退款后库存返还
8. 营销活动（优惠券、满减、积分）
-
优惠券：领取、使用、过期、不可叠加提示
-
满减：满 X 元减 Y 元
-
运费减免
-
优惠计算顺序：
商品总价 → 满减 → 优惠券 → 运费 → 实付
-
一个订单只能用一张券
-
退款后优惠券是否返还
9. 后台管理系统（运营 / 商家端）
-
商品管理：新增、编辑、上下架、库存修改、规格
-
订单管理：查询、发货、备注、售后审核
-
库存管理：库存修改、日志
-
权限管理：不同角色看到不同菜单
-
运营后台：优惠券创建、活动配置
-
日志：操作日志、异常日志
10. 异常 & 边界
-
网络中断、重复提交
-
商品下架、价格变更、库存不足
-
跨页面、跨设备操作（如 PC 下单、手机支付）
-
并发下单（功能层面也要校验拦截）
-
边界值：0 元商品、1 件库存、最大购买数
（三）电商功能测试核心流程（最常用主流程）
-
注册 / 登录
-
浏览商品 → 加入购物车
-
购物车结算
-
提交订单
-
支付
-
商家发货
-
用户确认收货
-
申请退款 → 审核通过 → 退款成功 → 库存返还
七、分布式锁 / 行锁：
行锁：单机数据库里的锁，锁住一行数据，防止同库内并发修改冲突。
分布式锁：跨机器、跨服务的全局锁，解决分布式系统并发冲突。
（一）行锁：
1、定义：MySQL InnoDB 引擎的行级锁，只锁某一行数据，不锁整张表。
2、什么时候生效：
必须满足两个条件：
- 操作 InnoDB
- WHERE 条件走 唯一索引 / 主键
UPDATE stock SET num = num - 1
WHERE product_id = 1001 AND num > 0;
这行 SQL 执行时，会自动加行锁。
3、优点：
- 轻量
- 并发好
- 数据库自带，不用额外组件
4、缺点：
只在一个数据库里有效！
- 分库分表 → 无效
- 多个服务实例 → 控制不住
- Redis 预扣库存 → 管不到
（二）分布式锁
1、定义：跨多个服务器、多个服务、多个数据库的全局唯一锁。常用实现：Redis 分布式锁。
2、为什么要用：
因为现在电商都是：
- 多台应用服务器
- 集群部署
- 分库分表
- Redis 缓存库存
- NX：只有不存在才能设置成功 = 抢锁
- EX：锁超时时间，防止死锁
- 只有抢到锁的请求，才能执行扣库存
4、优点：
- 跨服务、跨机器、跨库都能控制
- 高并发性能好
- 秒杀、抢券、下单扣库存必备
5、缺点：
- 引入额外组件（Redis）
- 要处理锁超时、误删、锁重入问题
6、总结：
分布式锁是分布式系统中跨实例的全局互斥锁，常用 Redis 实现，通过 SET NX 命令加锁，保证同一时间只有一个请求能修改库存，解决高并发下超卖问题。
7、一句话：
行锁：数据库单行锁 → 单机有效 分布式锁：全局锁 → 集群 / 高并发有效 电商扣库存：分布式锁为主，行锁兜底，保证不超卖
浙公网安备 33010602011771号