程序员用代码生成器造出系统后为何自动化测试总报错如何高效结合两者减少人工测试成本

先说一个真实场景：小李是某个中厂的 Backend 开发，最近公司推了 AI 代码生成工具，说是能提升效率。他花了两天用代码生成器搭了一个完整的用户管理模块，API 跑得挺顺，接口文档也自动生成完了。结果到了测试阶段，自动化测试一跑，几十条用例几乎全军覆没，报错五花八门——有的说字段找不到，有的说 404，有的直接报空指针。小李整个人都懵了，最后只能手工一条条过，反而比不用代码生成器花的时间还多。

这不是小李一个人的遭遇，这是很多程序员正在踩的坑。今天就来好好聊聊这个问题，顺便把解决方案讲透。

---

一、为什么代码生成器生成的系统，自动化测试总报错？

这个问题不能一概而论，但归根结底有几个核心原因，我先一个个拆开讲。

1. 代码生成器和测试框架的认知”断层”

很多代码生成器在生成代码的时候，根本不知道你用的是哪个测试框架。你用的是 pytest，它给你生成的代码可能是基于 unittest 的风格；你想要用 Mock 来隔离依赖，它生成的代码里全是真实数据库调用。这种认知断层导致测试脚本和生成代码”鸡同鸭讲”，跑起来必然报错。

举个例子，生成器写了一个服务层代码：

class UserService:
    def __init__(self):
        self.db = DatabaseConnection()  # 真实数据库连接
        
    def create_user(self, name, email):
        user = User(name=name, email=email)
        self.db.save(user)  # 直接写数据库
        return user

而你写的自动化测试是用 pytest 加上 unittest.mock 想隔离数据库的：

def test_create_user(mocker):
    mock_db = mocker.patch('myapp.UserService.db')
    service = UserService()
    result = service.create_user("张三", "zhangsan@example.com")
    assert result.name == "张三"

看起来没问题，但实际运行的时候，__init__ 里已经实例化了真实的 DatabaseConnection，mocker 根本拦不住。测试结果必然是空指针或者连接失败。这就是典型的生成代码没考虑到测试隔离的场景。

2. 接口定义和实际实现不一致

代码生成器有个常见的问题——它根据你给的 schema 或者提示词生成代码，但有时候生成的 API 路径、请求参数格式和测试脚本里写的不完全一致。差一个字母、差一个字段名，测试就挂了。

比如生成器根据 user/{id} 生成了路由，但你测试脚本里写的是 users/{user_id}，这种微小的差异在人工看代码的时候很容易发现，但自动化测试一旦跑起来，就会报 404，让人一头雾水。

3. 数据依赖和状态管理混乱

代码生成器生成的代码往往假设了一个”理想环境”，数据库里有干净的数据、配置项都设好了。但自动化测试通常需要控制数据状态，比如每次测试前后要清空表、插入测试数据。如果生成器的代码里没有提供这样的数据管理接口，测试就会因为数据污染而失败。

比如第一条用例插入了用户 A，第二条用例没清理就插入了用户 B，然后查询”所有用户”的时候，结果里带着 A，测试判断逻辑又没考虑到这种场景，直接报错。

4. 生成代码缺乏错误处理和边界情况

很多代码生成器生成的代码是”happy path”——走通正常流程没问题，但遇到异常就崩。自动化测试的一个重要目的就是验证边界情况和异常处理，而生成代码恰恰在这块是弱项。

比如生成器写了一个查询接口：

@app.get("/users/{user_id}")
def get_user(user_id: int):
    user = db.query(User).filter(User.id == user_id).first()
    return user  # 如果用户不存在，直接返回 None

测试脚本期望找不到用户时返回 404，但实际返回的是 200 加上 null，状态码对了但响应体不对，测试照样报错。

5. 测试用例的生成逻辑跟不上代码生成器的迭代速度

代码生成器更新很快，今天生成的代码和明天生成的代码可能结构就不一样。但测试脚本是之前写好的，一旦生成器改了某个类名、方法名或者模块路径，测试脚本里的导入和引用就全部失效了。这种”测试跟不上代码”的现象特别常见。

---

二、如何让代码生成器和自动化测试高效配合？

知道了问题在哪，接下来就是怎么解决。我总结了几条实用的策略，每一条都配了具体的代码示例，你可以直接拿去用。

策略一：在代码生成阶段就引入”测试友好”的设计约束

这是最根本的解决办法——不要等代码生成完了再想办法测试，而是在让代码生成器生成代码的时候，就把测试需求一起说清楚。

比如你用 Prompt 让生成器生成代码时，加上这样的要求：

请生成一个用户管理服务，要求：
1. 数据库连接通过构造函数注入，方便测试时 Mock
2. 提供 clear_all_users() 方法用于测试数据清理
3. 错误处理要完善，用户不存在时返回 None 而不是抛异常
4. 使用依赖注入模式，不要硬编码全局单例

生成出来的代码就会是测试友好的版本：

from typing import Optional, List
from dataclasses import dataclass
from contextlib import contextmanager

@dataclass
class User:
    id: int
    name: str
    email: str

class UserRepository:
    """数据访问层，实际项目中可以是数据库、API 等"""
    def __init__(self):
        self._users = {}
        self._next_id = 1
    
    def save(self, user: User) -> User:
        user.id = self._next_id
        self._users[self._next_id] = user
        self._next_id += 1
        return user
    
    def find_by_id(self, user_id: int) -> Optional[User]:
        return self._users.get(user_id)
    
    def find_all(self) -> List[User]:
        return list(self._users.values())
    
    def clear_all(self):
        """专门用于测试的数据清理"""
        self._users.clear()
        self._next_id = 1

class UserService:
    """业务逻辑层，通过依赖注入接收仓库"""
    def __init__(self, user_repo: UserRepository):
        # 关键：通过参数注入而不是硬编码
        self._repo = user_repo
    
    def create_user(self, name: str, email: str) -> User:
        if not name or not email:
            raise ValueError("name and email are required")
        user = User(name=name, email=email)
        return self._repo.save(user)
    
    def get_user(self, user_id: int) -> Optional[User]:
        return self._repo.find_by_id(user_id)
    
    def list_users(self) -> List[User]:
        return self._repo.find_all()

有了这样的设计，测试起来就从容多了。你看这个测试脚本：

import pytest
from myapp.user_service import UserService, UserRepository

class TestUserService:
    """用 fixture 管理测试数据，每次测试都干净的环境"""
    
    @pytest.fixture
    def user_repo(self):
        """每次测试都创建新的空仓库"""
        return UserRepository()
    
    @pytest.fixture
    def service(self, user_repo):
        """注入测试用的仓库实例"""
        return UserService(user_repo)
    
    def test_create_user(self, service):
        user = service.create_user("张三", "zhangsan@example.com")
        assert user.name == "张三"
        assert user.email == "zhangsan@example.com"
        assert user.id is not None
    
    def test_get_user_not_found(self, service):
        user = service.get_user(999)
        assert user is None
    
    def test_list_users_isolation(self, service, user_repo):
        # 第一条用例插入数据
        service.create_user("用户A", "a@test.com")
        # 新 service 实例，新仓库，数据是干净的
        fresh_service = UserService(UserRepository())
        assert fresh_service.list_users() == []

注意看 test_list_users_isolation 这个方法——它验证的就是”数据隔离”问题。每次测试用新的 UserRepository，互不干扰，这就是依赖注入的好处。

策略二：用 Pytest 的 Fixtures 统一管理测试数据和 Mock

很多程序员写自动化测试的时候，习惯在每条用例里手动创建对象、手动 Mock，这样代码重复且容易出错。Pytest 的 Fixture 机制可以把这些公共逻辑抽出来统一管理。

下面是一个完整的示例，展示了如何用 Fixture 解决代码生成器常见的测试问题：

import pytest
from unittest.mock import MagicMock, patch
from myapp.user_service import UserService, UserRepository
from myapp.api import create_app  # 假设有一个 FastAPI/Flask 应用

# ==================== 数据 Fixtures ====================

@pytest.fixture
def sample_users():
    """准备测试用的样本数据"""
    return [
        {"name": "张三", "email": "zhangsan@example.com"},
        {"name": "李四", "email": "lisi@example.com"},
        {"name": "王五", "email": "wangwu@example.com"},
    ]

@pytest.fixture
def user_repo():
    """创建一个空的 UserRepository 实例"""
    return UserRepository()

@pytest.fixture
def user_service(user_repo):
    """注入 UserRepository，创建 UserService"""
    return UserService(user_repo)

# ==================== API 测试 Fixtures ====================

@pytest.fixture
def client(user_service):
    """创建测试用 API Client，注入 mock 服务"""
    app = create_app()
    
    # 注入测试用的 service 实例
    app.dependency_overrides[UserService] = lambda: user_service
    
    with app.test_client() as test_client:
        yield test_client
    
    # 清理 dependency_overrides
    app.dependency_overrides.clear()

# ==================== 测试用例 ====================

class TestUserCreation:
    """测试用户创建功能"""
    
    def test_create_user_success(self, user_service, sample_users):
        user = user_service.create_user(
            sample_users[0]["name"], 
            sample_users[0]["email"]
        )
        assert user.id is not None
        assert user.name == "张三"
    
    def test_create_user_duplicate_email(self, user_service):
        user_service.create_user("张三", "zhangsan@example.com")
        with pytest.raises(ValueError, match="email already exists"):
            user_service.create_user("张三2", "zhangsan@example.com")

class TestUserAPI:
    """测试 API 接口"""
    
    def test_get_user_404(self, client):
        """不存在的用户应该返回 404"""
        response = client.get("/users/999")
        assert response.status_code == 404
    
    def test_create_user_api(self, client, sample_users):
        response = client.post(
            "/users",
            json={"name": "张三", "email": "zhangsan@example.com"}
        )
        assert response.status_code == 201
        data = response.get_json()
        assert data["name"] == "张三"
        assert "id" in data
    
    def test_list_users_endpoint(self, client, user_service, sample_users):
        """先创建用户，再查询，验证列表"""
        for u in sample_users:
            user_service.create_user(u["name"], u["email"])
        
        response = client.get("/users")
        assert response.status_code == 200
        data = response.get_json()
        assert len(data) == 3

这个示例里，client fixture 解决了 API 测试最难的问题——如何在测试中注入依赖、隔离外部环境。你只要理解了这套模式，后面的测试就都能套用。

策略三：用 Contract Testing 代替全量集成测试

很多团队在代码生成器生成系统之后，习惯于写大量的端到端集成测试——真的连数据库、真的调接口、真的跑完整流程。这种测试维护成本极高，而且代码生成器一旦改了某个内部实现，测试就全挂了。

更聪明的做法是用 Contract Testing（契约测试）。它的核心思想是：测试接口规范（请求/响应的格式），而不是测试具体实现。这样不管代码生成器怎么改内部逻辑，只要接口不变，测试就永远通过。

下面是具体的实现方式：

# contracts/user_api_contract.py
"""用户 API 的契约定义——只规定接口的形状，不关心实现"""

from typing import TypedDict
import pytest
from openapi_spec_validator import validate_spec

class UserResponse(TypedDict):
    id: int
    name: str
    email: str
    created_at: str

class CreateUserRequest(TypedDict):
    name: str
    email: str

# 定义 API 契约
USER_API_CONTRACT = {
    "get_user": {
        "method": "GET",
        "path": "/users/{user_id}",
        "expected_status_when_found": 200,
        "expected_status_when_not_found": 404,
        "response_fields_when_found": ["id", "name", "email", "created_at"],
        "response_fields_when_not_found": ["error", "message"],
    },
    "create_user": {
        "method": "POST",
        "path": "/users",
        "request_fields": ["name", "email"],
        "expected_status_on_success": 201,
        "expected_status_on_validation_error": 422,
        "response_fields_on_success": ["id", "name", "email", "created_at"],
    },
    "list_users": {
        "method": "GET",
        "path": "/users",
        "expected_status": 200,
        "response_is_list": True,
        "list_item_fields": ["id", "name", "email", "created_at"],
    },
}

# 用 Pytest 参数化测试契约
@pytest.mark.parametrize("contract_name, contract", USER_API_CONTRACT.items())
def test_api_contract(client, contract_name, contract):
    """统一的契约测试框架"""
    if contract_name == "get_user":
        # 测试不存在的用户
        resp = client.get("/users/9999")
        assert resp.status_code == contract["expected_status_when_not_found"]
        data = resp.get_json()
        for field in contract["response_fields_when_not_found"]:
            assert field in data, f"缺少字段: {field}"
    
    elif contract_name == "create_user":
        # 测试校验错误
        resp = client.post("/users", json={})
        assert resp.status_code == contract["expected_status_on_validation_error"]
        
        # 测试成功创建
        resp = client.post("/users", json={
            "name": "测试用户",
            "email": "test@example.com"
        })
        assert resp.status_code == contract["expected_status_on_success"]
        data = resp.get_json()
        for field in contract["response_fields_on_success"]:
            assert field in data, f"缺少字段: {field}"
    
    elif contract_name == "list_users":
        resp = client.get("/users")
        assert resp.status_code == contract["expected_status"]
        data = resp.get_json()
        assert isinstance(data, list)
        if data:
            for field in contract["list_item_fields"]:
                assert field in data[0], f"列表项缺少字段: {field}"

这套契约测试的好处是：代码生成器怎么改内部实现都无所谓，只要接口符合契约，测试就通过。这对于频繁使用代码生成器的团队特别有价值。

策略四：生成测试用例本身——让代码生成器帮你写测试

这是最近比较新的思路。既然代码生成器能生成业务代码，为什么不能让它生成对应的测试代码呢？很多现代 AI 编程工具（比如 GitHub Copilot、Cursor、SawCode 等）都能根据业务代码自动生成测试。

但这里有个关键技巧——不要让 AI 一次性生成所有测试，而是让它先生成测试骨架，你填充业务逻辑：

# 步骤一：让 AI 生成测试骨架
"""基于 UserService 生成对应的测试文件"""

import pytest
from myapp.user_service import UserService

# 这里让 AI 根据上面的 UserService 类，生成测试框架
# AI 应该生成类似这样的内容：

class TestUserService:
    def setup_method(self):
        """每个测试前的准备"""
        self.service = UserService(
            user_repo=MagicMock()  # 先 Mock，后续填充真实逻辑
        )
    
    def test_create_user_should_set_id(self):
        """AI 生成的测试骨架"""
        # 测试逻辑待填充
        pass
    
    def test_get_user_should_return_none_when_not_found(self):
        """AI 生成的测试骨架"""
        pass
    
    def test_list_users_should_return_empty_list_when_no_users(self):
        """AI 生成的测试骨架"""
        pass

# 步骤二：你填充测试逻辑
import pytest
from unittest.mock import MagicMock
from myapp.user_service import UserService, User

class TestUserService:
    def setup_method(self):
        self.mock_repo = MagicMock()
        self.service = UserService(user_repo=self.mock_repo)
    
    def test_create_user_should_set_id(self):
        self.mock_repo.save.return_value = User(
            id=1, name="张三", email="zhangsan@example.com"
        )
        user = self.service.create_user("张三", "zhangsan@example.com")
        assert user.id == 1
        self.mock_repo.save.assert_called_once()
    
    def test_get_user_should_return_none_when_not_found(self):
        self.mock_repo.find_by_id.return_value = None
        result = self.service.get_user(999)
        assert result is None
        self.mock_repo.find_by_id.assert_called_once_with(999)
    
    def test_list_users_should_return_empty_list_when_no_users(self):
        self.mock_repo.find_all.return_value = []
        result = self.service.list_users()
        assert result == []

这样既利用了 AI 的生成能力，又保证了测试质量是你来把控的。

策略五：建立代码生成器 + 自动化测试的 CI/CD 流水线

很多团队的问题不是测试写不好，而是根本没时间写测试——因为开发流程里没有”自动生成测试”这一步。正确的做法是把代码生成和测试生成整合到 CI/CD 流程中：

# .github/workflows/test.yml
name: Test After Code Generation

on:
  push:
    branches: [main]
  workflow_dispatch:  # 允许手动触发

jobs:
  generate-and-test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      
      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest pytest-mock Faker
  
      - name: Generate code with AI tool
        run: |
          # 调用你的代码生成工具
          python scripts/generate_system.py \
            --module user_management \
            --output-dir src/
      
      - name: Generate tests from generated code
        run: |
          # 根据生成的代码自动生成测试
          python scripts/generate_tests.py \
            --source src/user_management/ \
            --output tests/
      
      - name: Run tests
        run: |
          pytest tests/ -v --tb=short
  
      - name: Generate test report
        if: always()
        run: |
          pytest tests/ --junitxml=report.xml
          coverage run -m pytest tests/
          coverage report

# scripts/generate_tests.py
"""根据生成的源代码自动生成测试框架"""

import ast
import os
import re
from pathlib import Path

def analyze_module(module_path: str) -> dict:
    """分析模块，提取类和函数信息"""
    with open(module_path, "r") as f:
        tree = ast.parse(f.read())
    
    classes = []
    functions = []
    
    for node in ast.walk(tree):
        if isinstance(node, ast.ClassDef):
            methods = [m.name for m in node.body if isinstance(m, ast.FunctionDef)]
            classes.append({"name": node.name, "methods": methods})
        elif isinstance(node, ast.FunctionDef) and node.name != "__init__":
            args = [a.arg for a in node.args.args if a.arg != "self"]
            functions.append({"name": node.name, "args": args})
    
    return {"classes": classes, "functions": functions}

def generate_test_file(module_path: str, analysis: dict) -> str:
    """生成测试文件内容"""
    lines = [
        '"""自动生成测试文件 - 请勿手动修改"""',
        'import pytest',
        'from unittest.mock import MagicMock',
        '',
        '',
    ]
    
    for cls in analysis["classes"]:
        lines.append(f'class Test{cls["name"]}:')
        lines.append(f'    """{cls["name"]} 的自动化测试"""')
        lines.append(f'    def setup_method(self):')
        lines.append(f'        """每个测试前的初始化"""')
        
        # 根据类名推断构造函数
        mock_name = cls["name"][0].lower() + cls["name"][1:]
        lines.append(f'        self.{mock_name} = MagicMock()')
        lines.append(f'        self.service = {cls["name"]}(self.{mock_name})')
        lines.append('')
        
        for method in cls["methods"]:
            if method == "__init__":
                continue
            lines.append(f'    def test_{method}(self):')
            lines.append(f'        """测试 {cls["name"]}.{method}"""')
            lines.append(f'        # TODO: 根据业务逻辑填充测试用例')
            lines.append(f'        pass')
            lines.append('')
    
    return "\n".join(lines)

def main():
    source_dir = "src/user_management"
    output_file = "tests/test_user_management.py"
    
    analysis = analyze_module(os.path.join(source_dir, "__init__.py"))
    test_content = generate_test_file(source_dir, analysis)
    
    os.makedirs(os.path.dirname(output_file), exist_ok=True)
    with open(output_file, "w") as f:
        f.write(test_content)
    
    print(f"✅ 测试文件已生成: {output_file}")
    print(f"📊 分析了 {len(analysis['classes'])} 个类，生成 {len(test_content)} 行测试代码")

if __name__ == "__main__":
    main()

有了这套流水线，每次代码生成器生成新代码之后，测试框架会自动生成，然后自动跑，有报错立即通知你。人工只需要填测试逻辑就行，省去了大量的重复劳动。

---

三、减少人工测试成本的实际操作建议

讲完技术方案，再说几个实操层面的建议，这些是很多程序员容易忽略的。

1. 建立”生成代码测试检查清单”

每次让代码生成器生成代码之后，用这个清单快速检查：

□ 依赖是否通过构造函数注入？（而不是硬编码）
□ 是否有 clear/reset 方法用于测试数据清理？
□ 错误处理是否完善？（空值、异常、边界条件）
□ API 返回格式是否一致？（统一的 JSON 结构）
□ 是否有对应的单元测试文件？
□ 是否有 API 契约定义？
□ 关键业务逻辑是否覆盖了正向和反向用例？
□ 是否有性能相关的测试？（大数据量下的表现）

这个清单不需要每条都 100% 满足，但至少能帮你快速定位问题所在。

2. 用覆盖率报告指导测试重点

自动化测试不是越多越好，而是越准越好。用覆盖率报告告诉你哪些代码需要重点测试：

# pytest.ini
[pytest]
addopts = 
    --cov=myapp
    --cov-report=html:coverage_report
    --cov-report=term-missing
    --cov-fail-under=80
    -v

# 运行后会自动生成 HTML 覆盖率报告
# 报告里会告诉你哪些行没有被测试覆盖

把覆盖率目标设在 80% 左右，既能保证基本覆盖，又不会为了追求 100% 覆盖率而写大量无意义的测试。

3. 分层测试，不要什么都用集成测试

很多团队习惯用集成测试覆盖一切，但实际上应该分层：

测试层级	目的	速度	成本
单元测试	验证单个函数/类的逻辑	快	低
契约测试	验证接口规范	中	中
集成测试	验证模块间协作	慢	高
E2E 测试	验证完整用户流程	最慢	最高

代码生成器生成的代码，重点放在单元测试和契约测试上，这两个层次维护成本低、反馈快，性价比最高。集成测试和 E2E 测试用少量核心场景覆盖即可。

4. 记录”测试失败根因”，反哺代码生成器

每次测试失败，不要只是修代码就完了。要把失败原因记录下来，分类整理：

失败类型统计（月度报告）：

┌─────────────────────────┬────────┬──────────┐
│ 失败类型                │ 数量   │ 占比     │
├─────────────────────────┼────────┼──────────┤
│ 字段名不匹配            │ 23     │ 35%      │
│ 依赖注入问题            │ 18     │ 27%      │
│ 数据隔离问题            │ 12     │ 18%      │
│ 错误处理缺失            │ 8      │ 12%      │
│ 其他                    │ 5      │ 8%       │
└─────────────────────────┴────────┴──────────┘

这些数据可以用来优化代码生成器的 Prompt，比如发现”字段名不匹配”最多，就加强对生成器接口定义一致性的约束。

---

四、一个完整的实战案例

最后讲一个真实的完整案例，让你感受一下这套方法落地后是什么效果。

某团队用代码生成器生成了一套订单管理系统，最初测试失败率高达 70%。他们做了以下调整：

调整前：

# 生成器直接输出的代码（问题很多）
class OrderService:
    def __init__(self):
        self.db = get_db_connection()  # 硬编码数据库连接
        self.cache = get_cache()        # 硬编码缓存
    
    def create_order(self, user_id, items):
        order = Order(user_id=user_id, items=items)
        self.db.insert(order)
        self.cache.set(f"order_{order.id}", order)
        return order

# 对应的测试（完全没法跑）
def test_create_order():
    service = OrderService()  # 连不上数据库，直接报错
    order = service.create_order(1, [{"product": "书", "qty": 2}])
    assert order.id is not None

调整后：

# 重构后的代码（测试友好）
class OrderService:
    def __init__(self, db=None, cache=None):
        self.db = db or DatabaseConnection()
        self.cache = cache or CacheClient()
    
    def create_order(self, user_id, items):
        if not items:
            raise ValueError("订单不能为空")
        order = Order(user_id=user_id, items=items)
        self.db.insert(order)
        self.cache.set(f"order_{order.id}", order)
        return order
    
    def clear_test_data(self):
        """测试专用：清理数据"""
        self.db.execute("DELETE FROM orders")
        self.cache.flush()

# 对应的测试（清晰可靠）
class TestOrderService:
    @pytest.fixture
    def mock_db(self):
        return MagicMock()
    
    @pytest.fixture
    def mock_cache(self):
        return MagicMock()
    
    @pytest.fixture
    def service(self, mock_db, mock_cache):
        return OrderService(db=mock_db, cache=mock_cache)
    
    def test_create_order_success(self, service, mock_db, mock_cache):
        mock_db.insert.return_value = Order(id=100, user_id=1, items=[{"product": "书", "qty": 2}])
        order = service.create_order(1, [{"product": "书", "qty": 2}])
        assert order.id == 100
        mock_db.insert.assert_called_once()
        mock_cache.set.assert_called_once()
    
    def test_create_order_empty_items(self, service):
        with pytest.raises(ValueError, match="订单不能为空"):
            service.create_order(1, [])
    
    def test_api_contract(self, client):
        resp = client.post("/orders", json={
            "user_id": 1,
            "items": [{"product": "书", "qty": 2}]
        })
        assert resp.status_code == 201
        assert resp.get_json()["id"] is not None

调整之后，测试通过率从 30% 提升到了 95%，而且后续维护成本大幅降低。

---

代码生成器和自动化测试不是对立的，它们完全可以成为好搭档。关键是要在生成代码的时候就考虑到测试需求，用正确的架构设计减少后续测试的阻力，再用合适的测试策略控制成本。当你把这套方法跑通之后，会发现开发效率确实能提升不少。