多商户系统的测试复杂度，远高于单商户。
单商户只需要验证一条交易链路是否通顺；多商户要同时验证商家入驻审核、商品审核、分账计算、数据隔离、支付回调、退款回退等多条链路，任何一个环节出问题，都可能引发资金风险、合规风险或数据串号事故。很多团队做多商户项目时，靠人工点点点回归，上线前加班测，结果上线后还是频频出问题：商家越权查看数据、分账金额算错、退款后佣金没回退、审核状态流转异常。
本质原因是：多商户的业务节点多、状态链路长，纯人工回归覆盖不全，且每次版本迭代重复工作量巨大。建立一套自动化测试 + 标准化上线校验流程，是保障多商户系统稳定的必经之路。
这篇文章结合 LikeShop 多商户标准版的业务模块，从测试分层、核心场景用例、上线校验流程三个维度，讲一套可落地的测试体系搭建方案，附核心用例与校验脚本。
一、多商户系统的测试特殊性与设计原则
1.1 为什么多商户测试更难
和单商户相比，多商户有几个独有的测试重灾区：
- 数据隔离风险：商家 A 能否看到商家 B 的商品、订单、结算数据，是最容易出事故的点；
- 资金链路复杂：平台佣金、商家货款、分销佣金三方分账，退款时还要原路回退，一分钱都不能差；
- 状态链路长：入驻审核、商品审核、订单流转、结算提现，每个环节都有状态机，非法跳转就是 bug；
- 角色权限多：平台管理员、商家运营、商家财务、普通用户，不同角色权限边界容易出问题；
- 并发场景多：多个商家同时上下架商品、同时提现、同时退款，容易出现并发 bug。
1.2 测试体系设计原则
针对这些特点，测试体系遵循三个原则：
- 核心链路自动化：入驻、商品、订单、支付、分账、退款这些核心主流程，全部接口自动化，每次发版全量回归；
- 数据隔离必校验：所有查询接口默认做越权校验，作为必跑用例；
- 上线前必走 checklist：自动化覆盖主流程，人工补查配置、权限、合规项，形成标准化校验流程。
二、测试体系分层设计
采用四层测试金字塔，越底层越自动化，越上层越偏向业务场景与人工校验。
/ 上线前人工校验 \
/ 场景回归测试 \
/ 接口自动化 \
/ 单元测试 \
2.1 第一层：单元测试（开发自测）
覆盖核心服务层的计算逻辑，比如分账比例计算、状态流转校验、佣金计算。
- 范围：Service 层核心方法、工具类、状态机；
- 目标：保证单个函数逻辑正确，边界条件覆盖完整；
- 工具：Java 版用 JUnit + Mockito，PHP 版用 PHPUnit。
示例：分账计算单元测试
@SpringBootTest
public class SplitAccountServiceTest {
@Autowired
private SplitAccountService splitAccountService;
@Test
public void testSplitCalculate_normal() {
// 订单100元，平台佣金5%
SplitResult result = splitAccountService.calculate(
new BigDecimal("100.00"),
new BigDecimal("0.05"));
// 平台佣金5元，商家货款95元
assertEquals(new BigDecimal("5.00"), result.getPlatformAmount());
assertEquals(new BigDecimal("95.00"), result.getMerchantAmount());
assertEquals(new BigDecimal("100.00"), result.getTotalAmount());
}
@Test
public void testSplitCalculate_decimalPrecision() {
// 测试小数精度：99.99元 * 5%
SplitResult result = splitAccountService.calculate(
new BigDecimal("99.99"),
new BigDecimal("0.05"));
// 四舍五入保留两位
assertEquals(new BigDecimal("5.00"), result.getPlatformAmount());
assertEquals(new BigDecimal("94.99"), result.getMerchantAmount());
}
}
2.2 第二层：接口自动化测试（核心回归）
这是整个体系的主力，覆盖所有核心接口，每次发版自动跑一遍。
- 范围：商家入驻、商品管理、订单交易、支付回调、分账结算、退款、权限校验；
- 工具：Postman 集合 + Newman、Python + pytest + requests、JMeter 均可；
- 目标：主流程 100% 覆盖，每次迭代回归不低于 80%。
2.3 第三层：业务场景回归测试
模拟真实用户完整操作链路，端到端验证。
- 范围：用户下单 → 支付回调 → 商家发货 → 用户确认 → 结算 → 商家提现 全链路；
- 方式：关键节点人工校验 + 自动化跑通主路径，复杂场景人工补充；
- 重点：资金对账、状态流转、数据一致性。
2.4 第四层：上线前标准化校验
专门针对上线前的最终检查，覆盖环境、配置、数据库、安全、性能，是上线前的最后一道防线。
三、核心业务场景自动化用例设计
多商户的自动化测试，重点抓六个核心场景，覆盖了 80% 的高频故障点。
3.1 商家入驻与审核流程
覆盖从提交申请、系统校验、平台审核、驳回重提、审核通过初始化全链路。
核心测试点：
- 提交入驻：必填项校验、营业执照格式校验、资质缺失拦截；
- 审核状态流转：草稿 → 待审核 → 审核通过 / 驳回，非法状态跳转拦截；
- 驳回重提：驳回后修改资料重新提交，状态正确流转；
- 店铺初始化：审核通过后，店铺、运费模板、默认角色、结算账户是否正确生成。
接口自动化示例（pytest）：
import pytest
import requests
BASE_URL = "[http://test-api.example.com/admin](http://test-api.example.com/admin)"
class TestMerchantApply:
def test_apply_success(self):
"""正常提交入驻申请"""
data = {
"shop_name": "测试店铺001",
"company_name": "测试有限公司",
"license_no": "91330100MA2XXXXXX",
"contact_mobile": "13800138000",
"category_id": 1
}
res = requests.post(f"{BASE_URL}/merchant/apply", json=data)
assert res.status_code == 200
assert res.json()["code"] == 0
assert res.json()["data"]["audit_status"] == 1 # 待审核
def test_audit_reject_and_resubmit(self):
"""驳回后重提"""
# 1. 驳回
res = requests.post(f"{BASE_URL}/merchant/audit/reject", json={
"merchant_id": 1001,
"reason": "资质照片不清晰"
})
assert res.json()["data"]["audit_status"] == 2 # 已驳回
# 2. 重提
res = requests.post(f"{BASE_URL}/merchant/resubmit", json={
"merchant_id": 1001,
"license_img": "new_license.jpg"
})
assert res.json()["data"]["audit_status"] == 1 # 重新待审核
3.2 商品审核与上下架
覆盖商家提交、平台审核、驳回修改、强制下架链路。
核心测试点：
- 商家提交商品，状态变为待审核，前台不可见；
- 平台审核通过，商品上架，前台正常展示；
- 平台驳回，商家收到原因，修改后可重提；
- 平台强制下架，商品前台不可见，商家不可直接上架；
- 前台查询硬校验：仅返回
audit_status = approved且店铺正常的商品。
3.3 订单交易与分账计算
这是资金核心，必须逐笔校验，差一分钱都不行。
核心测试点：
- 下单成功，分账快照正确生成，平台佣金、商家货款金额准确；
- 不同类目佣金比例不同，分账按对应类目计算；
- 订单包含多个商家商品时，按商家拆分分账；
- 分账快照永久不变，中途调整佣金比例不影响历史订单。
数据库校验脚本示例：
-- 校验订单分账金额是否正确：平台+商家 = 订单实付
SELECT
o.order_sn,
o.pay_amount,
os.platform_amount,
os.merchant_amount,
(os.platform_amount + os.merchant_amount) AS split_total,
CASE
WHEN ABS(o.pay_amount - (os.platform_amount + os.merchant_amount)) < 0.01
THEN '正常'
ELSE '金额不符'
END AS check_result
FROM ls_order o
JOIN ls_order_settle os ON o.id = os.order_id
WHERE o.pay_status = 1
ORDER BY o.id DESC
LIMIT 100;
3.4 支付回调与退款回退
支付回调是最高危的环节，也是自动化测试的必选项。
核心测试点：
- 正常回调：验签通过，订单状态更新、分账状态更新、库存扣减正确；
- 重复回调：幂等校验，多次回调不重复处理；
- 全额退款：分账原路回退，平台佣金、商家货款同步退回，库存回补；
- 部分退款：按比例回退分账金额，计算精度正确。
3.5 数据隔离与越权校验
这是多商户独有的必测项，也是最容易出安全事故的地方。
核心测试点：
- 商家账号只能查看自己店铺的商品、订单、结算数据；
- 商家 A 修改商家 B 的商品/订单，接口返回无权限；
- 前台商品列表不会返回未审核、已下架、已关闭店铺的商品；
- 平台管理员可查看全平台数据，操作留痕。
越权校验示例：
def test_merchant_data_isolation():
"""商家A尝试查看商家B的订单，应被拦截"""
# 用商家A的token请求商家B的订单详情
headers = {
"Authorization": "Bearer " + merchant_a_token}
res = requests.get(
f"{BASE_URL}/shop/order/detail?id={order_id_of_merchant_b}",
headers=headers
)
# 应该返回无权限或不存在，不能返回数据
assert res.json()["code"] != 0
assert "无权限" in res.json()["msg"] or "不存在" in res.json()["msg"]
3.6 结算与提现
覆盖周期结算、提现申请、审核打款全链路。
核心测试点：
- 结算跑批正确：已过售后期的订单进入结算，退款订单自动扣回；
- 可提现余额计算准确：已结算 - 已提现 - 冻结中 = 可用余额；
- 提现冻结：审核通过后冻结对应金额，避免重复提现；
- 提现驳回：冻结余额自动退回可用余额。
四、上线前标准化校验流程
自动化测试覆盖了功能逻辑，但上线前还要做一轮全维度校验，确保环境、配置、数据、安全全部到位。建议做成固定 checklist，每次上线逐项打勾。
4.1 环境与配置校验
| 校验项 | 校验内容 |
|---|---|
| 运行环境 | PHP/Java 版本、扩展、数据库版本是否符合要求 |
| 配置文件 | 生产环境数据库、Redis、支付密钥是否正确切换 |
| 域名与HTTPS | 域名解析正常、证书有效、无混合内容 |
| 静态资源 | 静态资源地址正确、CDN 缓存刷新 |
| 定时任务 | 结算跑批、订单超时、库存回补等任务是否正常启用 |
| 第三方对接 | 支付、短信、物流、分账通道是否切到生产环境 |
4.2 数据库校验
- 表结构一致性：对比测试库与生产库表结构，新增表、字段、索引是否同步；
- 升级脚本检查：本次发版的 SQL 脚本是否全部执行，执行结果无报错；
- 基础数据校验：配置表、字典表、区域表、类目表数据完整；
- 历史数据兼容：升级后历史订单、商家、商品状态正常，不出现大面积异常。
4.3 核心链路冒烟测试
上线后立即跑一遍核心主链路，确保基础功能可用：
- 前台：商品列表、详情、加入购物车、提交订单；
- 支付：模拟支付回调，确认订单状态更新、分账生成；
- 商家端：商品管理、订单查看、结算查看；
- 平台端：商品审核、商家管理、订单查看；
- 退款：发起一笔退款，确认分账回退、库存回补。
4.4 安全与合规校验
- 后台接口鉴权正常，未登录、无权限不可访问；
- 敏感信息脱敏：手机号、身份证、银行卡号不明文展示；
- SQL 注入、XSS 基础防护校验；
- 支付回调验签正常，伪造请求无法通过。
4.5 性能与可用性校验
- 首页、商品列表、下单接口响应时间在可接受范围内；
- 数据库连接池、Redis 连接正常，无明显慢 SQL；
- 错误日志无持续异常报错；
- 服务器 CPU、内存、磁盘使用率正常。
五、落地建议与避坑
5.1 落地节奏：从核心到全面
不用一开始追求 100% 覆盖率，按优先级逐步建设：
- 第一阶段：先覆盖支付、订单、分账、退款核心资金链路；
- 第二阶段：覆盖入驻、商品、结算、提现主流程；
- 第三阶段：补充边缘场景、异常用例、性能压测。
5.2 常见坑
测试数据不隔离：自动化用例共用测试商家，互相干扰，结果不稳定。
避坑：每个用例创建独立测试数据，执行完清理，或用独立测试库。只测正常流程，不测异常：只测支付成功，不测回调失败、重复回调、部分退款。
避坑：异常场景占 bug 的 70%，必须重点覆盖边界与异常。自动化跑过就算完，不核对数据库：接口返回成功，数据库字段不对，后续流程全错。
避坑：关键操作后加数据库断言，校验状态、金额、日志是否正确写入。上线校验走形式：checklist 随便打勾，出问题才发现配置没切。
避坑：校验项责任到人，关键配置双人复核，保留校验记录。
5.3 工具选型建议
- 接口自动化：Python + pytest 灵活度高，适合定制化；Postman + Newman 上手快，适合小团队；
- 数据库校验：写固定 SQL 脚本，每次发版自动执行输出校验报告；
- 持续集成：接入 CI/CD，每次合并代码自动跑单元测试 + 核心接口回归。
结语
多商户系统的稳定性，不是上线前测出来的，是靠标准化的测试体系保障的。
LikeShop 多商户标准版本身已经有成熟的业务流程，但二开和迭代过程中，很容易引入新的 bug。建立一套「单元测试打底 + 接口自动化主回归 + 上线前 checklist 兜底」的测试体系，虽然前期需要投入一些时间，但长期来看，每次发版的回归成本会大幅下降，线上事故率也会明显降低。
对电商系统来说，稳定性就是最好的用户体验。尤其是涉及资金和商家数据的多商户场景，测试体系建得越扎实，业务跑起来越安心。
