五种 Agentic 模式赋能自动化测试的实践解析

twc829

316人浏览 · 2026-03-22 11:43:29

twc829 · 2026-03-22 11:43:29 发布

五种 Agentic 模式赋能自动化测试的实践解析

一、什么是 Agentic 模式

Agentic 模式是构建智能体应用的设计蓝图，它定义了智能体如何分解任务、协作执行和迭代优化。与简单的"聊天机器人"不同，采用 Agentic 模式设计的智能体能够无缝接入私有测试生态，实现效率跃升。

本文将详细解析反思、提示链、规划、并行处理和路由五种核心 Agentic 模式，为智能体设计提供可落地的工程方法。

二、反思模式：从"粗糙初稿"到"精雕细琢"

核心机制

反思模式通过自我修正的闭环循环，让 Agent 从"一次性输出"升级到"迭代打磨"。其核心是评估和优化的闭环：生成 → 评估 → 改进 → 再评估，直到满足标准。

应用场景：回归测试计划生成

class EvaluationStatus(enum.Enum):
    PASS = "PASS"
    FAIL = "FAIL"

class Evaluation(BaseModel):
    evaluation: EvaluationStatus
    feedback: str  # 改进建议
    reasoning: str  # 评估依据

def generate_test_plan(change_log: str, feedback=None) -> dict:
    """生成回归测试计划"""
    prompt = f"基于变更日志生成回归测试计划..."
    if feedback:
        prompt += f"\n结合反馈优化: {feedback}"
    # 调用 LLM 生成计划
    return plan

def evaluate(plan: dict, jacoco_data: list) -> Evaluation:
    """基于 JaCoCo 风险评估计划可行性"""
    # 提取风险点，检查时长、覆盖度等指标
    return Evaluation(evaluation=status, feedback=feedback, reasoning=reasoning)

# 反思循环
max_iterations = 3
current_plan = generate_test_plan(CHANGE_LOG)
while current_iteration < max_iterations:
    evaluation_result = evaluate(current_plan, JACOCO_DATA)
    if evaluation_result.evaluation == EvaluationStatus.PASS:
        break
    else:
        current_plan = generate_test_plan(CHANGE_LOG, feedback=evaluation_result.feedback)

价值对比

传统方式	反思模式
依赖经验猜测	数据驱动自纠
容易多跑无用功	动态调整避免冗余
人工评审耗时	自动化迭代优化

三、提示链模式：智能体的"接力赛"

核心机制

将复杂任务拆解成一系列预定义的、顺序化的步骤，前一步的输出作为后一步的输入。每个阶段专注单一职责，确保流程可靠可控。

应用场景：从用户故事到测试用例

# 步骤1：完善用户故事
prompt1 = PromptTemplate(
    input_variables=["user_story"],
    template="""基于用户故事，完善描述并生成详细的 Acceptance Criteria。
确保 AC 覆盖功能、非功能（性能、安全）、正向/负向场景。
用户故事：{user_story}"""
)
refined_story = (prompt1 | llm1).invoke({"user_story": user_story})

# 步骤2：基于完善后的故事生成测试用例
prompt2 = PromptTemplate(
    input_variables=["refined_story"],
    template="""基于完善后的 story 及其 AC，生成全面的测试用例列表。
每个测试用例包含：测试ID、描述、前置条件、步骤、预期结果。
完善后的story：{refined_story}"""
)
test_cases = (prompt2 | llm2).invoke({"refined_story": refined_story})

设计要点

阶段划分清晰：规划 → 验证 → 执行
信息传递准确：前一步输出结构化，便于后一步解析
职责单一：每个 LLM 调用聚焦特定任务

四、规划模式：“总导演 + 剧组工作人员”

核心机制

规划模式包含三个核心角色：

总导演（Planner）：分解任务为动态子任务列表
工作人员（Workers）：执行具体子任务
剪辑师（Synthesizer）：整合结果并反思

应用场景：UI 自动化测试

# Step 1: 生成测试计划
prompt_planner = (
    "Create a step-by-step plan for UI automation testing.\n"
    "Decompose into dynamic sub-tasks, assign to worker types:\n"
    "- DOMAnalyzer: 分析页面元素风险\n"
    "- ScriptGenerator: 生成测试脚本\n"
    "- BrowserRunner: 跨浏览器执行\n"
    "- VisualReporter: 生成可视化报告"
)
plan = ollama_generate(prompt_planner)

# Step 2: 执行子任务
for step in plan.get("steps", []):
    assigned_to = step.get("assigned_to")
    if assigned_to == "DOMAnalyzer":
        output = analyze_dom(step)
    elif assigned_to == "ScriptGenerator":
        output = generate_scripts(step, prev_output)
    # ... 其他 worker
    worker_outputs[task_id] = output

# Step 3: 整合与反思
synthesizer_prompt = f"""
Synthesize outputs into final UI test plan.
Check compatibility >95%, stability high?
Suggest replan if not.
Outputs: {worker_outputs}
"""
final_plan = ollama_generate(synthesizer_prompt)

优势

减少单次 LLM 调用的认知负荷
支持动态调整工作流程
复杂任务分解后推理质量更高

五、并行处理模式：Map-Reduce 加速

核心机制

将大任务拆分成相互独立的子任务，分发给多个智能体并发执行，最后聚合结果。类似 Map-Reduce 过程，可显著提高测试效率。

应用场景：电商 App 功能测试

async def parallel_tasks() -> str:
    topic = "e-commerce app functionality testing"
    prompts = [
        "Generate test report for user registration/login module...",
        "Generate test report for product search module...",
        "Generate test report for shopping cart module...",
        "Generate test report for payment module..."
    ]
    
    # Map 阶段：并发执行
    tasks = [generate_content(prompt) for prompt in prompts]
    results = await asyncio.gather(*tasks)
    
    # Reduce 阶段：聚合结果
    test_reports = '\n'.join(results)
    aggregation_prompt = f"""
    Based on the following test reports, create a cohesive summary.
    Include Markdown table: Module, Status, Bug Count, Key Metrics, Suggestions.
    {test_reports}
    """
    return (aggregation_prompt | llm).invoke({"test_reports": test_reports})

性能对比

执行方式	时间复杂度	适用场景
串行执行	O(n)	任务间有依赖
并行处理	O(max(task_time)) + O(reduce)	独立子任务

六、路由模式：智能分流与专精处理

核心机制

路由智能体充当"超级调度员"，根据输入特征将任务分发给下游 specialized 智能体。小问题用小模型，大问题用大模型，实现"分而治之"。

应用场景：Bug 智能分诊

class Category(enum.Enum):
    UI = "ui"
    API = "api"
    PERFORMANCE = "performance"
    UNKNOWN = "unknown"

class RoutingDecision(BaseModel):
    category: Category
    reasoning: str

# Step 1: 路由分类
prompt_router = PromptTemplate(
    template="""分析 bug ticket，确定分类：
- ui: UI/前端问题（渲染卡顿、元素错位）
- api: API/后端问题（认证失败、接口错误）
- performance: 性能问题（加载慢、高延迟）
- unknown: 不明确或多类别

Bug Ticket: {query}
输出 JSON: {\"category\": \"...\", \"reasoning\": \"...\"}"""
)
routing_decision = (prompt_router | llm).invoke({"query": user_query})

# Step 2: 专精处理
if routing_decision.category == Category.UI:
    response = ui_specialist.handle(query)
elif routing_decision.category == Category.API:
    response = api_specialist.handle(query)
elif routing_decision.category == Category.PERFORMANCE:
    response = perf_specialist.handle(query)

成本优化策略

任务复杂度	路由目标	模型选择
简单分类	路由层	轻量模型（8B）
UI 诊断	UI Specialist	中等模型（32B）
复杂性能分析	Performance Specialist	大模型（120B）

七、模式选择指南

模式	适用场景	核心优势
反思	需要迭代优化的任务	自我修正，质量提升
提示链	可线性分解的任务	流程可控，职责清晰
规划	复杂多步骤任务	动态调整，分工协作
并行处理	独立子任务集合	效率最大化
路由	多类型输入处理	专精优化，成本可控