多商户系统的测试复杂度，远高于单商户。
单商户只需要验证一条交易链路是否通顺；多商户要同时验证商家入驻审核、商品审核、分账计算、数据隔离、支付回调、退款回退等多条链路，任何一个环节出问题，都可能引发资金风险、合规风险或数据串号事故。很多团队做多商户项目时，靠人工点点点回归，上线前加班测，结果上线后还是频频出问题：商家越权查看数据、分账金额算错、退款后佣金没回退、审核状态流转异常。
本质原因是：多商户的业务节点多、状态链路长，纯人工回归覆盖不全，且每次版本迭代重复工作量巨大。建立一套自动化测试 + 标准化上线校验流程，是保障多商户系统稳定的必经之路。
这篇文章结合 LikeShop 多商户标准版的业务模块，从测试分层、核心场景用例、上线校验流程三个维度，讲一套可落地的测试体系搭建方案，附核心用例与校验脚本。
一、多商户系统的测试特殊性与设计原则
1.1 为什么多商户测试更难
和单商户相比，多商户有几个独有的测试重灾区：
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 商品审核与上下架
覆盖商家提交、平台审核、驳回修改、强制下架链路。
核心测试点：
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 数据隔离与越权校验
这是多商户独有的必测项，也是最容易出安全事故的地方。
核心测试点：
越权校验示例：
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 数据库校验
4.3 核心链路冒烟测试
上线后立即跑一遍核心主链路，确保基础功能可用：
4.4 安全与合规校验
4.5 性能与可用性校验
五、落地建议与避坑
5.1 落地节奏：从核心到全面
不用一开始追求 100% 覆盖率，按优先级逐步建设：
5.2 常见坑
测试数据不隔离：自动化用例共用测试商家，互相干扰，结果不稳定。
避坑：每个用例创建独立测试数据，执行完清理，或用独立测试库。
只测正常流程，不测异常：只测支付成功，不测回调失败、重复回调、部分退款。
避坑：异常场景占 bug 的 70%，必须重点覆盖边界与异常。
自动化跑过就算完，不核对数据库：接口返回成功，数据库字段不对，后续流程全错。
避坑：关键操作后加数据库断言，校验状态、金额、日志是否正确写入。
上线校验走形式：checklist 随便打勾，出问题才发现配置没切。
避坑：校验项责任到人，关键配置双人复核，保留校验记录。
5.3 工具选型建议
- 接口自动化：Python + pytest 灵活度高，适合定制化；Postman + Newman 上手快，适合小团队；
- 数据库校验：写固定 SQL 脚本，每次发版自动执行输出校验报告；
- 持续集成：接入 CI/CD，每次合并代码自动跑单元测试 + 核心接口回归。
结语
多商户系统的稳定性，不是上线前测出来的，是靠标准化的测试体系保障的。
LikeShop 多商户标准版本身已经有成熟的业务流程，但二开和迭代过程中，很容易引入新的 bug。建立一套「单元测试打底 + 接口自动化主回归 + 上线前 checklist 兜底」的测试体系，虽然前期需要投入一些时间，但长期来看，每次发版的回归成本会大幅下降，线上事故率也会明显降低。
对电商系统来说，稳定性就是最好的用户体验。尤其是涉及资金和商家数据的多商户场景，测试体系建得越扎实，业务跑起来越安心。
