金融级香火钱分账系统自动化测试实践-代码聚汇网

金融级香火钱分账系统自动化测试实践

不妧

1. 项目背景与核心挑战

作为一名长期从事金融系统测试的工程师，去年我接手了一个特殊的项目——为某大型寺庙的香火钱分账系统设计自动化测试方案。这个看似传统的场景背后，隐藏着堪比金融级系统的复杂架构：

寺庙每天要处理来自不同殿堂（大雄宝殿、观音殿等）的香火钱，支付方式涵盖现金、微信、支付宝、云闪付等多种渠道。这些资金需要按照预设比例实时分账：寺庙留存80%，维护方15%，慈善基金5%。更复杂的是，每逢初一十五或法会期间，系统要承受3000+TPS的交易压力。

核心测试挑战主要集中在三个方面：

支付渠道多样性：需要同时验证电子支付和现金支付流程，特别是老年香客常用的"无感支付"功能
资金合规性：必须确保"钱不沾手"原则，所有资金流转通过银行监管账户闭环完成
宗教场景特殊性：包括功德榜姓名展示的隐私控制、香火钱金额的特殊处理（如0.01元的分账）

2. 技术架构解析

2.1 系统三层架构设计

整个系统采用典型的金融级分层架构：

code复制支付层 → 规则引擎层 → 资金监管层

支付层的关键设计：

每个殿堂有独立的动态收款码（防止香客扫错码）
现金支付通过智能POS机自动关联到对应殿堂
专门为老年香客设计的"无感支付"流程（扫码后自动完成金额输入）

规则引擎层的复杂点在于：

阶梯分账规则（大额捐赠比例会调整）
实时分账触发机制（支付成功即刻分账）
异常处理（如网络中断时的补偿机制）

资金监管层通过银行专用接口实现：

所有资金进入监管账户前不可动用
分账指令通过加密通道传输
每笔交易生成独立的电子凭证

2.2 测试环境搭建要点

我们使用Docker搭建了完整的测试环境：

bash复制# 支付网关模拟器
docker run -d --name payment_mock -p 8080:8080 payment-mock:1.2

# 分账规则引擎测试版
docker run -d --name accounting_engine -p 9090:9090 accounting-engine:test

# 银行接口沙箱环境
docker run -d --name bank_sandbox -p 7070:7070 bank-sandbox:latest

特别注意要配置好各容器的时间同步，因为分账系统对交易时间戳极其敏感。

3. Selenium测试框架实现

3.1 基础测试框架搭建

我们选择Selenium+Pytest的组合，主要考虑点是：

需要模拟真实浏览器操作（特别是支付流程）
支持复杂的参数化测试
良好的断言机制

基础框架结构如下：

code复制tests/
├── conftest.py    # 公共fixture
├── page_objects/  # 页面对象模型
│   ├── payment_page.py
│   └── accounting_page.py
├── test_payment_flow.py  # 支付流程测试
└── test_accounting_rules.py  # 分账规则测试

关键的技术点在于处理动态元素。比如殿堂切换时，收款码会动态变化：

python复制def select_shrine(driver, shrine_name):
    # 等待殿堂选择下拉框加载完成
    WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.CSS_SELECTOR, ".shrine-selector"))
    )
    
    # 选择指定殿堂
    select = Select(driver.find_element(By.CSS_SELECTOR, ".shrine-selector"))
    select.select_by_visible_text(shrine_name)
    
    # 验证收款码已更新
    WebDriverWait(driver, 10).until(
        EC.text_to_be_present_in_element(
            (By.CSS_SELECTOR, ".qr-code-meta"), shrine_name)
    )

3.2 支付链路测试方案

我们设计了完整的支付场景验证矩阵：

测试场景	支付方式	金额范围	验证要点
常规捐赠	微信/支付宝	1-188元	基础支付流程
小额随喜	现金	0.01-1元	分账精度处理
大额功德	银行转账	1000+元	阶梯分账规则
法会专场	所有方式	随机金额	高并发处理

对应的测试用例示例：

python复制@pytest.mark.parametrize("amount,method", test_data)
def test_payment_flow(driver, amount, method):
    # 1. 选择支付方式
    select_payment_method(method)
    
    # 2. 输入金额（现金支付跳过此步）
    if method != "cash":
        enter_amount(amount)
    
    # 3. 提交支付
    submit_payment()
    
    # 4. 验证支付结果
    assert is_payment_success(), f"{method}支付{amount}元失败"
    
    # 5. 验证分账触发
    assert is_accounting_triggered(), "分账未触发"

3.3 分账规则验证方案

分账规则的验证是核心难点，特别是金额拆分精度问题。我们采用数值近似断言：

python复制def assert_accounting_split(amount):
    expected = {
        'temple': amount * 0.8,
        'maintainer': amount * 0.15,
        'charity': amount * 0.05
    }
    
    actual = get_accounting_result(amount)
    
    # 使用math.isclose处理浮点数精度
    for key in expected:
        assert math.isclose(
            actual[key], 
            expected[key],
            abs_tol=0.001  # 允许1分钱误差
        ), f"{key}分账金额不符"

针对0.01元这种极端情况，我们特别设计了四舍五入规则：

python复制def test_penny_accounting():
    result = calculate_split(0.01)
    assert result['temple'] == 0.01  # 寺庙获得全部
    assert result['maintainer'] == 0
    assert result['charity'] == 0

4. 专项测试实践

4.1 资金安全测试

我们通过Selenium操控银行模拟器完成闭环验证：

正向流程测试：

python复制def test_fund_flow(driver):
    # 1. 发起支付
    make_payment(100)
    
    # 2. 验证监管账户入账
    assert bank_api.get_balance("监管账户") == 100
    
    # 3. 验证分账完成
    wait_for_accounting()
    assert bank_api.get_balance("寺庙账户") == 80
    assert bank_api.get_balance("维护方账户") == 15
    assert bank_api.get_balance("慈善账户") == 5

逆向操作防御测试：

python复制def test_reverse_operation(driver):
    # 尝试从子账户提现
    with pytest.raises(BankAPIError):
        bank_api.withdraw("慈善账户", 5)
    
    # 验证余额未变
    assert bank_api.get_balance("慈善账户") == 0

4.2 容灾测试方案

我们模拟了多种异常场景：

故障类型	模拟方法	预期行为
网络中断	切断测试容器网络	交易进入pending状态
支付超时	Mock延迟响应	自动重试机制触发
对账失败	篡改测试数据	告警触发并锁定账户

核心恢复机制测试：

python复制def test_network_recovery():
    # 1. 模拟网络中断
    disconnect_network()
    
    # 2. 发起支付
    make_payment(100)
    
    # 3. 恢复网络
    reconnect_network()
    
    # 4. 验证补偿机制
    assert is_transaction_recovered(), "交易未恢复"

4.3 多终端数据一致性

使用Selenium Grid同时操控：

香客手机端（查看功德榜）
寺庙后台（经营分析）
银行管理系统（资金流水）

验证点包括：

交易金额一致性
交易时间同步性
分账结果一致性

核心验证代码：

python复制def test_data_consistency():
    # 在手机端发起支付
    mobile_driver.make_payment(100)
    
    # 验证后台数据
    assert admin_page.get_latest_amount() == 100
    
    # 验证银行流水
    assert bank_api.get_last_transaction().amount == 100
    
    # 验证三端时间差小于5秒
    assert abs(
        mobile_driver.get_payment_time() - 
        bank_api.get_transaction_time()
    ) < 5

5. 测试效果与经验总结

5.1 量化成果

经过3个月的自动化测试实施：

效率提升：分账验证时间从72小时人工核账缩短至3分钟自动完成
错误发现：累计发现边界值问题23处，资金闭环漏洞5个
稳定性提升：法会期间系统零故障，最高承受5000+TPS压力

5.2 关键经验

支付测试经验：

老年用户测试要特别注意：
- 字体大小（至少24px）
- 操作步骤不超过3步
- 错误提示要有语音播报

现金支付测试技巧：

python复制def test_cash_payment():
    # 通过串口模拟POS机信号
    serial.write(b"INSERT_CASH 100")
    assert is_payment_success()

宗教场景特别注意事项：

功德榜隐私控制：

python复制def test_privacy_control():
    # 验证匿名开关
    toggle_anonymous(True)
    make_payment(100)
    assert "匿名" in get_donor_list()

特殊金额处理：
- 6.66元、8.88元等吉利数字要特别测试
- 最大金额限制（通常不超过9999元）

性能测试经验：

法会前必做：

bash复制# 模拟3000TPS压力
locust -f payment_test.py --users 3000 --spawn-rate 100

监控关键指标：
- 分账延迟（需<1分钟）
- 支付成功率（需>99%）
- 系统资源占用（CPU<70%）

这个项目给我的最大启示是：即使是看似传统的宗教场景，也需要金融级的系统设计和测试方案。通过自动化测试，我们不仅保障了系统稳定性，还意外发现了年轻香客支付体验的优化点，最终使90后香客的支付成功率从82%提升到99.2%。