企业官网建设流程全解析

## LLM+Agentic AI：模型驱动数字测试自动化框架落地

传统测试与评估（T&E）的痛点从来不是缺少工具，而是需求、设计与验证之间的断层。测试计划写在文档里，用例靠工程师手工翻译，场景与需求之间的溯源依赖经验记忆。DoDI 5000.97发布后，数字工程从口号变成制度要求；NAVWAR 5.0又进一步要求以系统模型作为采办决策的单一事实源。可落到测试环节，大量团队仍停留在用文档管理测试资产的状态。

这种割裂在AI/自主系统面前更加致命——被测对象的行为空间不可穷尽，测试输入呈指数级膨胀，手工“翻译需求”的思路已经走不通。

2026 FORGE Tech Track上展示的模型驱动数字测试框架给出了值得借鉴的路径：用LLM当翻译器，把结构化测试计划直接变成仿真环境可执行的任务配置；再用自主SDET代理生成标准化Gherkin场景。整条链路的核心不是“自动化执行”，而是“自动生成”。

### 从测试计划到仿真场景：LLM不再是聊天框

框架的第一层处理对象是形式化测试计划。这类计划包含需求描述、资源约束、测试目标，但表达方式仍贴近自然语言。以往靠测试工程师逐条阅读，再手动映射到仿真平台的配置项；现在由LLM完成解析与映射。LLM输出的是仿真平台能直接加载的任务配置文件——这等于把“人读文档后写配置”换成“机器读文档后生成配置”。

关键在于输出结构。LLM要生成的配置格式必须被严格约束，否则下游仿真器无法解析。在框架实现里，配置schema由MBSE模型推导而来，每个字段都能关联到系统需求或任务目标。

仿真侧采用降阶模型（ROM），而非全保真模型。全保真仿真精度高，但单次运行成本高，无法覆盖广大的场景组合空间。ROM保留关键行为特征，计算速度快一到两个数量级，让自动生成的场景可以在夜间批量执行。这套“LLM生成+ROM仿真”的组合，把探索式测试从概念变成了工程实践。

### MBSE的追溯闭环

如果只是“LLM能生成场景”，距离可用还很远。测试工程要求每个用例回答“为什么存在”。Framework v2.0在这个框架里负责建立可追溯性链条：任务目标→操作概念→团队行为→系统需求→测试场景→MOP/MOE。六层关系用统一模型表达，每个测试事件都挂在一棵向上可追溯的树上。

这个设计直接服务于Agentic AI——SDET代理在生成测试用例时，不仅能拿到“当前页面长什么样”，还能拿到需求标签在模型中的语义上下文。上下文越精确，生成结果偏离度越低。框架强调“模型驱动”，本质是让LLM在模型划定的轨道内生成，而非自由发挥。

### 自主SDET代理：从辅助到自治

测试生成侧出现了Agentic AI的完整形态。自主SDET代理集成在VS Code的Continue插件中，通过Gemini API端点调用大模型。代理接收三类输入：需求标签、上下文文档、实时页面信息。输出则是完整的、框架合规的Gherkin场景。

场景构建策略值得细看。代理被硬性约束为只能使用标准化“super steps”库——点击、数据录入、验证、数据库操作、导航。这些超级步骤是跨项目沉淀的行为原语，与传统Page Object模式形成对比：Page Object绑定页面细节，super steps绑定操作语义。页面结构千变万化，操作语义相对稳定。

为什么这样设计？LLM生成测试用例时最大的风险是幻觉，即自由编造步骤。允许LLM直接编写Playwright或Selenium调用链，产出的用例很难保证正确性。把生成空间限制在super steps的组合上，LLM的犯错空间被压缩到“选哪些步骤、以什么顺序”这个层次——恰好是LLM最擅长的层次。

下面给出简化示例。SDET代理需要为登录页面生成场景，需求标签是“AUTH-LOGIN-SSO”。

```json

{

"models": [

{

"title": "Gemini T&E Agent",

"provider": "gemini",

"model": "gemini-2.5-pro",

"apiKey": "${GEMINI_API_KEY}",

"apiBase": "https://api.gemini.example.com/v1beta"

}

],

"agents": [

{

"name": "sdet-agent",

"model": "Gemini T&E Agent",

"systemPrompt": "你是一名SDET代理。你的任务是基于需求标签、上下文文档和实时页面信息，生成框架合规的Gherkin场景。规则：1. 只使用super_steps库中的步骤；2. 禁止生成库中不存在的步骤；3. 生成结果必须是完整Gherkin。super_steps库定义见schemas/super_steps_v2.json。",

"tools": [

"read_context",

"inspect_page",

"query_super_steps"

]

}

]

}

```

代理运行时主循环可以用Python简化表达：

```python

def generate_gherkin(requirement_tag: str, context_doc: str, page_info: dict) -> str:

client = GeminiClient(endpoint=GEMINI_API_ENDPOINT, model="gemini-2.5-pro")

super_steps = load_super_steps("schemas/super_steps_v2.json")

prompt = f"""

需求标签: {requirement_tag}

上下文: {context_doc[:2000]}

页面信息: {page_info}

可用步骤: {[s.name for s in super_steps]}

请基于以上信息生成Gherkin场景。只能组合可用步骤，不得自创新步骤。

"""

response = client.generate(prompt)

return validate_gherkin(response, super_steps)

```

最后一行`validate_gherkin`不只是格式校验。它把LLM输出的每一步与super steps库比对，发现库中不存在的步骤直接剔除并触发重试。这个“生成—校验—重试”循环是SDET代理自治性的工程基础。

实际生成的Gherkin场景：

```gherkin

Feature: SSO Login

Scenario: Valid user authenticates via SSO

Given I navigate to "/login"

When I click the element "button[data-testid=sso]"

And I enter data "testuser@example.com" into field "#email"

And I enter data "********" into field "#password"

Then I verify element "a[data-testid=dashboard]" is visible

```

每个步骤都是super steps库中的原子操作，没有一行选择器逻辑泄漏到场景层。等待策略、重试机制、异常处理全部封装在步骤实现内部。

这个模式带来的收益是可维护性。UI只要选择器不变，场景永久有效；选择器变了，只需修改一个步骤实现，所有相关场景同步更新。Framework v2.0已把super steps库的版本管理纳入MBSE模型，步骤变更会触发受影响的场景自动复盘。

### 总结与展望

这套框架把测试设计从“人工智力劳动”降维成“配置+审查”。工程师的角色从写用例变成审查代理生成的用例、维护super steps库、校准ROM模型。测试用例的产能不再线性依赖团队人数。

但必须保持清醒。LLM解析测试计划时仍会产生语义漂移，尤其是隐式约束的识别，目前依赖独立的规则引擎兜底。另一个问题是ROM参数校准——一旦过时，批量生成的高通过率用例会产生“虚假信心”。这些限制决定了Agentic AI在测试领域会先落地在“生成候选—人机复核”的形态，而不是全自动闭环。

数字工程正在把测试从“验证产品”变成“验证模型”。LLM和Agentic AI在链路里承担翻译器与生成器。谁能把需求到测试的追溯链条封进工具链，谁就能占据下一代测试基础设施的主动权。Framework v2.0只是这条路上第一个可用的里程碑。