LLM 驱动的自动化测试系列（13）：Flaky Test 不是重跑几次就能解决的分类问题

引言

在持续集成与持续交付（CI/CD）的流水线中，自动化测试是保障软件质量的关键环节。然而，一种名为“Flaky Test”（不稳定测试）的现象常常困扰着工程团队。Flaky Test 指的是那些在相同代码、相同环境下，有时通过有时失败的测试用例。面对Flaky Test，许多工程师的第一反应是“重跑几次”，如果重跑后通过，便暂时搁置；如果持续失败，则可能将其标记为“失败”而忽略其不稳定性。

这种“重跑即解决”的思路，本质上是将Flaky Test视为一个简单的、二元的“通过/失败”分类问题。但事实是，Flaky Test 的根源复杂多样，可能是竞态条件、时序依赖、外部服务波动、资源竞争或环境差异等。简单重跑无法揭示其根本原因，导致问题反复出现，消耗大量调试时间，并侵蚀团队对测试结果的信任。

随着大语言模型（LLM）能力的提升，我们有了一个新的工具来应对这一挑战。LLM 能够理解非结构化的文本信息，如测试日志、错误堆栈、代码片段等，并从中提取模式和线索。本文将探讨如何利用 LLM 驱动的方法，对 Flaky Test 进行深度分析和智能分类，从而超越简单的重跑，走向精准治理。

原理要点

LLM 驱动 Flaky Test 分类的核心思想，是将 LLM 作为一个强大的“分析引擎”和“模式识别器”。其工作原理基于以下几点：

1. 上下文理解：LLM 能够处理和理解测试失败时产生的丰富上下文信息，包括完整的错误日志、测试代码、相关源代码、甚至构建环境描述。这些信息是传统规则引擎难以全面捕捉的。
2. 模式匹配与推理：通过训练或提示（Prompting），LLM 可以学习识别不同类别 Flaky Test 的典型特征模式。例如，日志中出现“Timeout”、“Connection refused”可能指向网络或时序问题；出现“AssertionError”但数据随机可能指向状态污染。
3. 分类与归因：LLM 可以根据分析结果，将 Flaky Test 归类到预定义的类别中，如“时序问题（Timing Issue）”、“资源竞争（Resource Contention）”、“外部依赖不稳定（Unstable External Dependency）”、“环境差异（Environment Variance）”等，并给出可能的根本原因推测。

这种方法将 Flaky Test 的处理从“经验驱动”转向“数据与智能驱动”，为后续的修复策略提供了更清晰的指引。

实战步骤

下面是一个通用的、基于 LLM 的 Flaky Test 自动化分类流程示例。该流程可以集成到 CI 系统或测试框架中。

步骤一：收集测试失败上下文

当测试失败时，系统自动收集以下信息：

• 完整的测试日志（stdout/stderr）
• 测试失败时的堆栈跟踪（Stack Trace）
• 相关的测试代码片段
• （可选）构建/运行环境的基本信息（如操作系统、依赖版本）

步骤二：构建分析提示（Prompt）

将收集到的上下文信息组织成结构化的文本，输入给 LLM。提示词需要明确任务、提供分类标准和要求。

你是一个资深测试工程师和调试专家。请分析以下失败的测试用例信息，并将其归类到以下类别之一：

分类标准：
1.  **时序问题**：日志中包含超时（timeout）、等待（wait）、竞态条件（race condition）相关线索。
2.  **资源竞争**：日志中包含锁（lock）、同步（synchronization）、资源不足（out of memory, disk）相关线索。
3.  **外部依赖**：日志中包含网络错误（connection error, timeout）、第三方服务调用失败相关线索。
4.  **环境差异**：日志中包含路径（path）、配置（config）、环境变量（environment variable）相关线索。
5.  **其他/未知**：无法明确归类。

请输出你的分析结果，格式如下：
- 分类：[类别]
- 置信度：[高/中/低]
- 关键线索：[引用日志中的关键句子]
- 建议排查方向：[简要建议]

测试失败日志：
[此处插入完整的测试日志和堆栈跟踪]

相关测试代码：
[此处插入相关的测试代码片段]

步骤三：调用 LLM 进行分析

通过 API 调用 LLM 服务（如本地部署的开源模型或云端 API），传入构建好的提示词。

# 伪代码示例：调用 LLM API 进行分析
import requests

def analyze_flaky_test(log_content, code_snippet):
    prompt = build_prompt(log_content, code_snippet)  # 构建上述提示词
    response = requests.post(
        "
        json={
            "model": "your-model-name",
            "messages": [{"role": "user", "content": prompt}]
        }
    )
    analysis_result = response.json()['choices'][0]['message']['content']
    return parse_analysis_result(analysis_result)  # 解析LLM返回的文本

步骤四：处理分析结果并记录

解析 LLM 返回的结构化结果（可以通过正则或简单文本解析提取），并将分类结果、置信度、关键线索等信息记录到测试管理系统或数据库中。这为后续的测试用例优化、修复优先级排序提供了数据支持。

常见坑与排查清单

在实际应用 LLM 驱动分类时，需注意以下问题：

1. 日志信息不足：如果测试日志过于简略，LLM 缺乏分析依据。
   • 排查：确保 CI 系统配置为输出详细日志，包括调试级别（debug level）信息。
2. LLM 理解偏差：LLM 可能误解日志或给出错误分类。
   • 排查：对 LLM 的输出进行人工抽样审核，持续优化提示词（Prompt Engineering）。可以引入“二次验证”机制，让 LLM 对自己的分类理由进行解释。
3. 分类标准不清晰：预定义的分类类别重叠或模糊，导致 LM 分类混乱。
   • 排查：定期回顾和更新分类标准，结合团队实际遇到的 Flaky Test 案例进行细化。
4. 成本与性能：频繁调用 LLM API 可能产生较高成本或延迟。
   • 排查：仅对失败的、尤其是重复失败的测试用例进行分析。可以考虑使用更轻量级的本地模型进行初步筛选。
5. 上下文长度限制：完整的日志和代码可能超过 LLM 的上下文窗口。
   • 排查：对日志进行智能截断，保留错误核心部分和最近的日志行。使用代码摘要工具提取关键代码片段。

小结

Flaky Test 的治理是一个持续的过程。传统的重跑和手动调试方法效率低下且治标不治本。引入 LLM 驱动的自动化分类方法，能够利用其强大的自然语言理解能力，从海量测试日志中智能识别不稳定测试的根源模式，将其归类到不同的问题类型中。

这不仅为工程师提供了更精准的排查方向，加速了修复进程，更重要的是，它推动了测试质量保障从“被动响应”到“主动预防”的转变。通过积累 LLM 分析的历史数据，团队可以进一步识别出高频出现的 Flaky Test 模式，从而在测试设计、代码编写和 CI 环境配置层面进行系统性改进，最终构建更稳健、更可信的自动化测试体系。