本文介绍通过参数化测试与抽象断言逻辑，将健康/故障两类 mape 测试合并为单一、可维护的 pytest 测试函数，避免硬编码路径和重复调用 calculate_mape_range。

在大型测试套件中，类似 TestMapeHealthy 和 TestMapeFaulty 这样仅因 YAML 路径键名（如 'healthy_test_list' vs 'faulty_test_list'）和断言期望值（== 0 vs > 0）而复制整段测试逻辑的情况，不仅增加维护成本，还易引入不一致缺陷。Pytest 提供了强大而优雅的解决方案：多维度参数化 + 行为抽象。

核心思路是将差异点提取为参数：

• final_key：指定 YAML 中待测列表的键（如 "healthy_test_list" 或 "faulty_test_list"）；
• should_pass：控制断言行为（布尔值，决定是验证“无失败”还是“存在失败”）；
• 其余参数（threshold, window_size, load_config）保持复用。

以下是重构后的推荐写法：

import pytest

@pytest.mark.parametrize("threshold", THRESHOLD_COMPREHENSION)
@pytest.mark.parametrize("window_size", WINDOW_SIZE_COMPREHENSION)
@pytest.mark.parametrize(
    "final_key, should_pass",
    [
        ("healthy_test_list", True),
        ("faulty_test_list", False),
    ],
    ids=["healthy", "faulty"]  # 可选：提升测试报告可读性
)
def test_MAPE(
    self,
    threshold: float,
    window_size: int,
    final_key: str,
    should_pass: bool,
    load_config: dict
):
    # 统一提取 YAML 中的测试文件 ID 对
    test_ids = load_config['test_plan']['test_ids'][VERSION_TAG]['tools']['test_file_ids']
    path_1 = test_ids[final_key][0]
    path_2 = test_ids[final_key][1]

    # 复用核心计算逻辑
    consecutive_failures = self.calculate_mape_range(path_1, path_2, window_size, threshold)

    # 根据 should_pass 动态断言
    if should_pass:
        assert consecutive_failures == 0, (
            f"Expected no consecutive failures for {final_key} with "
            f"threshold={threshold}, window={window_size}, but got {consecutive_failures}"
        )
    else:
        assert consecutive_failures > 0, (
            f"Expected at least one consecutive failure for {final_key} with "
            f"threshold={threshold}, window={window_size}, but got {consecutive_failures}"
        )

✅ 优势说明：

• 零逻辑重复：所有路径解析、计算调用、断言分支均集中于一处；
• 高可扩展性：新增测试变体只需在 parametrize 列表中追加元组，无需新建类或方法；
• 清晰的测试标识：ids 参数让 pytest 报告显示 test_MAPE[healthy-threshold0.1-window5] 等语义化名称；
• 健壮的错误信息：断言失败时附带上下文（阈值、窗口、键名），便于快速定位问题；
• 符合 pytest 最佳实践：利用 fixture 复用配置，参数化驱动行为，避免继承滥用。

⚠️ 注意事项：

• 确保 VERSION_TAG 是模块级常量或通过 fixture 注入（不建议硬编码在测试函数内）；
• 若 calculate_mape_range 是实例方法，请确认该测试函数定义在继承自 TestBase 的类中（如示例中的 TestMapeBase），并使用 self 调用（而非 super()，除非需绕过子类重写）；
• YAML 结构变动时，建议在 load_config fixture 中添加 schema 校验，防止单点失效扩散至全部测试。

通过这一重构，你不仅消除了 90% 的样板代码，更构建了一个面向变化、易于演进的测试架构——这正是高质量自动化测试的核心追求。