技术方向：自动化测试 / DevOps
关键词：日本代购、一站式日淘、雅虎代拍、煤炉自动代拍

一、测试分层策略

很多人一上来就想搞E2E测试，觉得跑通完整流程才够“真实”。

但说实话，测试金字塔这么多年还没过时，原因很简单——不同层级的测试各有分工，缺了哪一层都不稳。

来看这张金字塔图：

┌─────────────────────────────────────────────────────────┐
│ 测试金字塔                                           │
├─────────────────────────────────────────────────────────┤
│ E2E测试（少量） → 完整业务流程验证                     │
│ 集成测试（中等） → API接口 + 数据库交互                 │
│ 单元测试（大量） → 函数级逻辑验证                       │
└─────────────────────────────────────────────────────────┘

单元测试打底，数量最多，跑得最快。

集成测试负责接口和数据库这一层。

E2E只跑最关键的几条业务路径，数量最少。

这套分层逻辑，放到日淘系统里就是：

• 单元测试测价格计算、折扣规则这些核心函数；
• 集成测试测订单API和数据库写入是否正常；
• E2E测试模拟用户从搜索商品、加购到下单的完整流程。

二、单元测试（pytest）

单元测试我们就用pytest，这也是Python社区的主流选择。

看一个订单服务的例子：

# test_order_service.py
import pytest
from unittest.mock import Mock, patch

class TestOrderService:
    def test_calculate_total_price(self):
        """测试价格计算逻辑"""
        service = OrderService()
        items = [
            {'price': 1000, 'quantity': 2},
            {'price': 500, 'quantity': 1}
        ]
        result = service.calculate_total(items)
        assert result == 2500

    def test_apply_discount(self):
        """测试折扣计算"""
        service = OrderService()
        assert service.apply_discount(10000, 0.1) == 9000
        assert service.apply_discount(5000, 0) == 5000

    @patch('services.order.OrderRepository')
    def test_create_order(self, mock_repo):
        """测试订单创建"""
        service = OrderService(mock_repo)
        order = service.create_order(
            user_id='user_001',
            items=[{'id': 'item_1', 'price': 2000}]
        )
        assert order['user_id'] == 'user_001'
        assert order['total'] == 2000
        mock_repo.sa ve.assert_called_once()

注意最后那个@patch装饰器。

我们用Mock代替了真实的仓库层，这样测试只关注Service本身的逻辑，不依赖数据库。

干净利落。

三、集成测试

集成测试重点在于验证接口和数据库之间的协作是否正常。

用FastAPI的TestClient就非常方便：

# test_integration.py
import pytest
from fastapi.testclient import TestClient
from main import app

client = TestClient(app)

class TestOrderAPI:
    def test_create_order_endpoint(self):
        """测试创建订单API"""
        response = client.post(
            "/api/orders",
            json={
                "user_id": "test_user",
                "items": [{"id": "item_1", "price": 3000}]
            },
            headers={"Authorization": "Bearer test_token"}
        )
        assert response.status_code == 200
        data = response.json()
        assert data['status'] == 'success'
        assert 'order_id' in data

    def test_get_order_status(self):
        """测试获取订单状态"""
        response = client.get("/api/orders/order_001/status")
        assert response.status_code == 200
        assert 'status' in response.json()

这里我们用了Bearer Token模拟认证，测试的是真实的HTTP端到端逻辑，包括路由、中间件、序列化等。

但数据库仍然是测试库（通过测试配置切换），不会影响生产数据。

四、E2E测试（Playwright）

E2E测试用Playwright来模拟真实用户操作。

下面这个用例模拟一次完整的下单流程：

# test_e2e.py
from playwright.sync_api import Page, expect

def test_order_flow(page: Page):
    """端到端测试：完整下单流程"""
    # 1. 访问首页
    page.goto("https://bidfins.com")
    # 2. 搜索商品
    page.fill('input[placeholder="搜索商品"]', "キャンプ用品")
    page.click('button[type="submit"]')
    # 3. 进入商品详情
    page.click('.product-item:first-child')
    # 4. 加入购物车
    page.click('button:has-text("加入购物车")')
    # 5. 确认购物车
    page.click('a:has-text("去结算")')
    # 6. 提交订单
    page.click('button:has-text("提交订单")')
    # 7. 验证结果
    expect(page.locator('.order-success')).to_be_visible()

每一步都对应着用户在浏览器里的实际点击，最后验证订单成功页面出现。

这种测试跑得慢，但能发现从UI到后端到数据库的一系列问题。

五、CI/CD流水线（GitHub Actions）

光有测试不行，得自动跑起来。

用GitHub Actions配置流水线，让每次提交都自动执行这些测试，通过后才能部署：

# .github/workflows/ci.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest pytest-cov
      - name: Run unit tests
        run: pytest tests/unit --cov=. --cov-report=xml
      - name: Run integration tests
        run: pytest tests/integration
      - name: Upload coverage
        uses: codecov/codecov-action@v3
  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Deploy to production
        run: |
          echo "Deploying to production server..."
          # 实际部署脚本

可以看到，我们分了两步：先跑测试（单元+集成），测试通过后才执行部署。

而且只对main分支做自动部署，develop分支只跑测试。

六、性能测试

对日淘系统来说，大促时流量会冲得很高，所以性能测试不能少。

用Locust可以模拟多用户并发访问：

# test_performance.py
from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def view_homepage(self):
        self.client.get("/")

    @task(2)
    def search_product(self):
        self.client.get("/searchkeyword=キャンプ")

    @task(1)
    def view_product(self):
        self.client.get("/product/test-item-001")

这里给首页浏览、搜索、商品详情分别设置了不同的权重（3:2:1），模拟真实用户的行为分布。

七、测试覆盖率与质量门禁

最后一项硬要求：覆盖率低于80%就算不通过，直接在管道里阻断。

同时生成HTML报告方便查看：

# 设置质量门禁
pytest --cov=. --cov-fail-under=80
# 生成测试报告
pytest --html=report.html --self-contained-html

建议把这个门禁放在CI管道的单元测试步骤之后，这样只要覆盖率不达标，后续步骤就不会执行。

从经验来看，80%是一个比较合理的门槛——既不会太低导致漏测，也不会太高逼得大家去写无意义的断言。

整套体系搭建下来，从单测到E2E，从性能到覆盖率，层层把关，日淘系统的质量就有了基本的保障。

剩下的就是在实际迭代中不断补充测试用例，让测试真正成为开发的“安全网”。