第2章：组件化测试的架构分层

2.1 三层架构的边界定义

组件化测试的核心在于将测试行为按照测试目标与被测对象粒度进行纵向切割，形成三个逻辑清晰、职责互斥的测试层。每一层拥有独立的边界定义和测试契约，避免跨层耦合导致的测试脆弱性问题。

2.2 顶层测试：端到端集成验证

边界定义：“黑盒”行为验证。测试不感知组件内部实现，仅通过公开接口触发业务流程。

• 核心职责：验证多个组件的交互链路完整性，确认业务异常与边界案例在完整链路中的表现。
• 依赖关系：依赖所有下层组件的稳定版本，通过mock或stub替代外部依赖（如数据库、第三方服务）。
• 控制流：从入口组件发起请求，沿业务链路逐级传递，最终验证输出结果。
• 数据流：使用预设的静态数据集或工厂模式生成测试数据，不依赖中间层产生的动态数据。

2.3 中间层测试：模块编排与策略验证

边界定义：“灰盒”交互验证。测试关注组件的编排能力、策略选择与异常恢复逻辑。

• 核心职责：验证模块调度、路由逻辑、限流/熔断策略、超时重试机制等非功能性逻辑。
• 依赖关系：依赖基础层组件的桩实现（stub），不依赖真实的基础设施。
• 信任链路：假设顶层测试已通过，中间层测试不再重复验证；但中间层测试的结果是底层测试的输入前提。
• 方案权衡：中间层测试最难维护，因为策略变化频繁，需要在“覆盖率”和“维护成本”之间做取舍。

2.4 基础层测试：原子能力正确性保障

边界定义：“白盒”单元验证。测试覆盖到函数、工具类、数据模型等最小可测单元。

• 核心职责：验证网络请求封装的正确性、序列化/反序列化逻辑、数据校验规则、加密/解密算法。
• 依赖关系：无外部依赖。所有外部资源均被替换为内存中的桩对象。
• 信任链路：基础层测试是所有上层测试的信任基石。如果基础层测试失败，上层测试的重现可能不可靠。
• 验收标准：行覆盖率达到85%以上；分支覆盖率达到70%以上；所有边界异常（如网络超时、空指针、非法参数）均被覆盖。

2.5 分层职责划分与依赖矩阵

测试层	被测对象粒度	测试类型	核心信任依赖	典型异常范围
顶层测试	多组件链路	端到端	中间层测试通过	跨组件超时、数据不一致、事件丢失
中间层测试	单组件/模块	集成/策略	基础层测试通过	路由错误、策略未生效、状态机异常
基础层测试	函数/类/工具	单元	无（自包含）	边界值溢出、空指针、序列化失败

2.6 三层的控制流与数据流依赖结构

下面这张图展示了三个测试层之间的控制流方向（从顶层到底层）和数据流依赖关系（从底层到顶层）。箭头方向代表“信任”或“依赖”的方向。

2.7 方案权衡：覆盖率 vs 成本 vs 维护性

维度	顶层测试	中间层测试	基础层测试
实现成本	高（需搭建完整链路）	中（需桩接口）	低（单元测试框架即可）
运行速度	慢（秒级）	中（毫秒级）	快（微秒级）
故障定位精度	模糊（仅知道链路失败）	中等（可定位到模块）	精确（精确到函数）
维护频次	低（接口稳定则少改）	高（策略变动频繁）	低（原子行为稳定）
推荐比例	10%	30%	60%

2.8 落地步骤：从基础层向顶层逐步构建

1. Step 1：定义基础层测试用例库，包含所有工具类、数据模型、网络封装函数。
2. Step 2：编写基础层测试，确保所有边界值（如空输入、非法字符、超大数据量）都被覆盖。
3. Step 3：创建中间层桩接口，隔离基础层测试的真实实现；编写策略编排测试。
4. Step 4：集成中间层测试与基础层桩，验证模块调度正确性。
5. Step 5：使用mock服务搭建端到端测试环境。
6. Step 6：编写顶层测试场景（正常流程+异常流程+边界流程）。

# 典型的mock服务启动命令（仅作为方案落地的示例，非主体内容）
mockserver -serverPort 1080 -logLevel INFO

# 基础层测试的桩接口示例（YAML配置形式）
stub:
  - path: /api/internal/validate
    method: POST
    response:
      status: 200
      body: '{"valid": true}'

2.9 验收标准

• 每层测试之间不存在跨层直接调用（例如顶层测试不调用基础层测试的私有方法）。
• 所有中间层测试都依赖一个或多个基础层桩，且桩的返回值覆盖所有正常与异常分支。
• 顶层测试运行时间不超过5分钟；中间层测试不超过30秒；基础层测试不超过10秒。
• 信任链验证：若基础层测试全部通过，中间层测试的运行失败率应低于2%（排除策略本身的逻辑变更问题）。
• 架构评审通过，且团队内至少80%的开发者能清晰描述三层的边界与依赖关系。