Preview | VISTA Research Group

用 Agent Skill 重构网页应用测试

Thu, 11 Jun 2026 00:00:00 +0000

如果说过去的自动化测试更像“写好脚本，然后让机器重复执行”，那么这个仓库展示的是另一种思路：让 AI Agent 先像真实用户一样进入浏览器、观察界面、操作产品、读取后端响应与日志，再把值得长期回归的流程沉淀成可复跑脚本。

仓库地址：

1. 这个仓库是什么？

Mencius2023/skills 是一个个人维护的 Claude Code / Agent Skills 集合。当前仓库的核心内容是一个名为 web-app-test 的 skill，用于网页应用自动化测试。

它的目标不是简单提供几个 Playwright 脚本模板，而是定义一套面向 AI Agent 的测试工作流：

用 Playwright 驱动真实浏览器；
模拟真实用户在前端界面中的操作；
连接真实后端，不做 mock；
同时检查 API 返回、HTTP 状态码、后端日志和页面截图；
对值得长期回归的流程，动态沉淀为 Playwright spec；
每轮测试结束后输出 Markdown 测试报告。

这使它更像一个“测试方法论 + 脚手架 + Agent 执行规范”的组合，而不只是一个代码模板仓库。

2. 仓库结构概览

仓库结构很简洁：

skills/
└── web-app-test/
 ├── SKILL.md
 └── templates/
 ├── README.md
 ├── TEST_SPECIFICATION.template.md
 ├── run_regression.template.py
 ├── playwright.config.template.js
 └── standard-flow.spec.template.js

其中最重要的文件有三类：

文件	作用
`README.md`	仓库入口，说明 skill 列表、安装方式和结构约定
`skills/web-app-test/SKILL.md`	核心规范，定义网页应用测试的执行原则、分层策略、动态浏览器测试方法、报告格式等
`templates/`	新项目接入时使用的通用脚手架，落地后生成项目专属的测试规格书、回归运行器和 Playwright 配置

这个设计有一个非常重要的边界：skill 本体是通用资产，项目测试文件是项目专属资产。也就是说，SKILL.md 和 templates/ 留在 skill 仓库中，而某个具体项目的 TEST_SPECIFICATION.md、测试脚本、操作指南等应该落到该项目根目录下的 web-app-test/ 中，并跟随项目自己的 Git 仓库维护。

3. web-app-test 的核心定位

web-app-test 面向的是网页应用质量验证场景。只要用户提出“测网页”“测前端”“浏览器测试”“Playwright”“E2E”“端到端测试”“跑测试”“回归测试”“CI”“提交前检查”等需求，或者改动了前后端代码后想确认功能没有回归，就可以使用这个 skill。

它尤其强调两点：

第一，浏览器测试要连接真实后端。
测试不是拦截请求、伪造数据、只看页面状态，而是尽可能贴近真实用户路径，验证前后端真实集成行为。

第二，AI 不是只执行脚本，而是参与判断。
Agent 在浏览器中截图观察页面，用视觉能力判断 UI 是否符合用户预期，同时结合 API 响应和后端日志确认逻辑路径是否正确。

这和传统 E2E 测试的区别很明显：传统测试通常依赖预先写好的选择器和断言；这个 skill 则把 AI 的现场观察能力纳入测试闭环，用动态执行来抵抗前端界面频繁变化带来的脚本脆弱性。

4. 测试分为两大类

SKILL.md 中最关键的设计，是把测试分成两类，并明确两类脚本采用相反的设计策略。

4.1 程序测试脚本：必须预先设计

这类测试不涉及浏览器，主要直接调用后端模块、API 或构建命令，验证数据层、配置层、核心逻辑、API 契约、前端构建等。

它们是整个测试体系的“稳定底座”，应该在项目接入时就设计好，并且覆盖主要功能：

L0：冒烟测试与基础依赖检查；
L1：前端单元测试；
L2：后端核心功能测试；
L3：前端构建与静态检查；
L5 或等价层级：真实 API 集成测试。

这类测试适合无人值守、批量复跑，也适合 CI。规格书里如果写了用例，却没有对应脚本或可直接运行命令，就会被视为未完成。

4.2 浏览器模拟用户操作：不预先写满，动态沉淀

另一类测试是浏览器 E2E。它使用 Playwright 驱动真实浏览器，模拟用户完整操作流程，并连接真实后端。

但仓库并不主张一开始就把所有浏览器流程都写成 Playwright 脚本。原因很实际：前端页面变化快，选择器、布局、弹窗、流程都可能变，提前写满脚本会带来高维护成本。

因此，web-app-test 的策略是：

默认由 AI 动态接入浏览器；
AI 根据页面截图、源码和用户指南现场判断下一步操作；
每个关键步骤后截图并检查 API / 日志；
功能测完后再判断：这条测试以后是否需要回归？
如果值得长期回归，再沉淀为 Playwright spec；
如果流程细节容易变，但操作路径有参考价值，则沉淀为操作手册，例如 L4_OPERATION_GUIDE.md。

这是一种“先探索，再固化”的测试资产治理方式。

5. 一条完整测试链路是怎样的？

按照 skill 的设计，AI 执行浏览器测试时不是简单点击页面，而是进行一个循环：

观察页面截图
 ↓
理解当前 UI 状态
 ↓
决定下一步用户操作
 ↓
通过 Playwright CLI 执行操作
 ↓
检查 API 响应 / HTTP 状态码
 ↓
读取后端日志
 ↓
再次截图并用视觉能力判断 UI 是否正确
 ↓
记录产物与结论

这个流程有两个验证维度：

验证方式	关注点
API 返回值 + 后端日志	请求是否成功、数据结构是否符合预期、后端路径是否正确执行
截图 + 视觉判断	页面布局、面板状态、主题色、弹窗、画布、生成结果等用户可见体验是否正常

这非常适合测试现代 Web 应用，尤其是那些“接口返回成功但页面实际表现不对”的场景。

6. 测试资产如何落地到项目？

仓库要求具体项目中维护自己的 web-app-test/ 目录：

<被测项目根>/
└── web-app-test/
 ├── TEST_SPECIFICATION.md
 ├── L4_OPERATION_GUIDE.md
 ├── <其他分支文档>.md
 └── scripts/
 ├── run_regression.py
 ├── playwright.config.js
 └── <flow>.spec.js

其中：

TEST_SPECIFICATION.md 是测试规格书，也是所有脚本的唯一索引；
scripts/ 下的每个脚本都必须登记到规格书附录；
不允许出现“孤儿脚本”，即存在于 scripts/ 但在规格书里找不到的脚本；
L4_OPERATION_GUIDE.md 等分支文档用于记录浏览器 UI 操作细节，避免主文档过长。

这个约定解决了一个常见问题：测试脚本散落在项目各处，时间一久没人知道哪些脚本还能跑、覆盖了哪些功能、失败后该如何复现。这里通过规格书统一索引，把测试资产纳入项目治理。

7. 新项目接入流程

当一个项目还没有 web-app-test/，或者已有内容明显来自其他项目时，就需要执行新项目落地流程。

大致步骤如下：

在被测项目根目录创建 web-app-test/ 和 web-app-test/scripts/；
阅读当前项目的前端源码、后端源码、API 文档和用户指南；
从 skill 的 templates/ 中复制模板；
把模板中的 <产品名>、<前端目录>、<后端端口>、<前端健康检查> 等占位符替换成项目真实值；
删除不适用的层级或用例；
补齐程序测试脚本和可执行命令；
将 web-app-test/ 纳入项目自己的版本控制。

模板映射关系如下：

skill 模板	落地到项目中
`templates/TEST_SPECIFICATION.template.md`	`web-app-test/TEST_SPECIFICATION.md`
`templates/run_regression.template.py`	`web-app-test/scripts/run_regression.py`
`templates/playwright.config.template.js`	`web-app-test/scripts/playwright.config.js`
`templates/standard-flow.spec.template.js`	`web-app-test/scripts/<flow>.spec.js`

8. 模板目录提供了什么？

templates/ 是这个仓库的可复用脚手架。

8.1 `TEST_SPECIFICATION.template.md`

这是测试规格书模板。它按测试层级组织：

L0 冒烟测试；
L1 前端单元测试；
L2 后端核心功能测试；
L3 前端构建与静态检查；
L4 浏览器 E2E 测试。

L4 又进一步区分：

API 契约：纯 HTTP 请求，预先设计，适合批量复跑；
浏览器流程：默认由 AI 动态操作，测完后按需沉淀。

规格书还包含若干附录，例如：

data-testid 选择器契约；
fixture 数据；
浏览器测试环境配置；
脚本清单。

这让测试文档不只是说明文档，而是测试执行入口、脚本索引和环境手册。

8.2 `run_regression.template.py`

这是非交互式回归运行器，也是 CI 的首选入口。

它按测试金字塔从 L0 到 L4 逐层执行：

L0 冒烟 + 数据完整性
L1 前端单元测试
L2 配置回归 + 离线核心功能
L3 前端生产构建
L4 浏览器 E2E

运行器采用 fail-fast 策略：某一层失败后立即中断并返回退出码。这适合 CI 节省资源。但 skill 同时强调，AI 手动执行测试时不应被 fail-fast 限制，应尽量跑完更多用例，一次性收集完整问题。

8.3 `playwright.config.template.js`

这是 Playwright 配置模板，包含：

baseURL；
Chromium 项目；
viewport；
screenshot 策略；
trace 策略；
HTML 报告目录；
webServer 自动拉起；
是否复用已有前端服务。

它把浏览器测试运行环境规范化，避免每个项目重复配置。

8.4 `standard-flow.spec.template.js`

这是 API 契约与浏览器流程的 spec 骨架。

它把一个 Playwright spec 分成两部分：

API 契约断言：健康检查、配置接口、错误处理、主要端点；
浏览器流程：页面加载、核心业务全流程等稳定路径。

不稳定、易变化的浏览器 UI 交互不会一开始就写进 spec，而是由 AI 动态测试后再决定是否沉淀。

9. 安装与依赖

仓库 README 推荐使用 skills.sh CLI 安装指定 skill：

# 安装到当前项目
npx skills add Mencius2023/skills@web-app-test

# 安装到全局
npx skills add Mencius2023/skills@web-app-test -g -y

也可以手动安装：

git clone https://github.com/Mencius2023/skills.git
cp -r skills/skills/web-app-test ~/.claude/skills/web-app-test

web-app-test 依赖 playwright-cli skill，需要额外安装：

npm install -g @playwright/cli@latest
playwright-cli install
playwright-cli --version

如果不希望全局安装，也可以使用 npx playwright-cli 的方式运行。

10. 测试结束后必须交付 Markdown 报告

这个 skill 对测试交付物有明确要求：每轮测试结束后必须产出 Markdown 测试报告，而不是只在对话里口头总结。

报告建议包含：

测试范围；
通过 / 失败 / 跳过数量；
环境信息；
详细测试结果；
发现的问题；
本轮已修复内容；
新增或更新的自动化脚本；
待用户确认事项。

这一点很重要。因为 AI Agent 执行测试时会产生大量即时判断，如果没有报告固化，测试过程就会变成不可追溯的聊天记录。Markdown 报告把一次测试转化为可归档、可审查、可复盘的工程产物。

11. 失败不是只有“代码 bug”

web-app-test 对失败原因也做了分类：

类型	含义	处理方式
类型 A	测试脚本 fixture、前置条件或断言逻辑有问题	AI 可自行修复测试
类型 B	产品 Feature 发生有意变更，旧测试预期过时	AI 可更新测试预期
类型 C	文档或设计未说明的意外回归	汇报用户，等待确认修复方向

这套分类避免了两个极端：

一看到测试失败就改代码；
一看到测试失败就改测试让它通过。

它要求 Agent 先判断根因，再决定是修脚本、改预期，还是报告真实 bug。

12. 这个仓库适合什么场景？

这个 skill 尤其适合以下场景：

前后端分离的 Web 应用；
页面交互复杂、纯 API 测试覆盖不够的产品；
需要频繁回归但 UI 又经常变化的项目；
有 LLM 生成结果、输出不完全确定的应用；
希望把 AI Agent 纳入测试流程的团队；
想把测试规格、脚本、报告统一治理的项目。

相对不适合的场景包括：

纯后端库，没有浏览器交互；
产品极小、没有持续回归需求；
团队只需要传统 CI 单元测试，不需要 AI 现场判断；
无法提供真实后端或测试环境的项目。

13. 这个设计最有价值的地方

我认为这个仓库最值得借鉴的不是具体代码量，而是它对 AI Agent 测试角色的重新定义。

它没有把 Agent 当作“自动生成 Playwright 脚本的工具”，而是把 Agent 放进一个完整测试生命周期：

理解项目
 → 维护测试规格
 → 启动真实环境
 → 动态操作浏览器
 → 结合视觉、API、日志判断问题
 → 分类处理失败
 → 沉淀可复用脚本
 → 输出 Markdown 报告

这使测试从“一堆脚本”变成了“一套可演进的工程流程”。

14. 可以继续增强的方向

从博客解读视角看，这个仓库后续还可以补充一些内容，让它更容易被外部用户采用：

增加一个完整示例项目，展示从模板落地到报告产出的全过程；
提供一份真实的 TEST_SPECIFICATION.md 示例；
补充 GitHub Actions / CI 配置示例；
增加 FAQ，例如如何处理登录态、鉴权、外部服务调用、LLM 超时；
明确许可证，便于他人复用；
提供更多 skill，例如 API 测试、文档测试、性能冒烟测试等。

这些不是当前仓库的缺陷，而是一个个人 skill 集合走向通用工具包时自然会遇到的下一步。

15. 总结

Mencius2023/skills 当前体量不大，但它提出了一个很有实践价值的方向：让 AI Agent 不只是写测试，而是参与测试设计、执行、判断和资产沉淀。

其中的 web-app-test skill 把网页应用测试拆成两条线：

稳定、底层、可无人值守的程序测试，必须预先设计；
脆弱、界面相关、需要用户视角判断的浏览器测试，先由 AI 动态执行，再按需沉淀为脚本。

这种分工非常贴合现实中的 Web 应用测试难题：核心逻辑要稳定回归，界面流程又不能被过度僵化的脚本绑死。

如果你正在尝试把 Claude Code、Playwright 和 AI Agent 工作流结合起来，用于前端 / 全栈项目测试，这个仓库值得一读。它的价值不在于提供了多少现成代码，而在于提供了一套可落地、可演进、可追溯的 Agentic Testing 方法论。

参考链接

仓库首页：
web-app-test skill：
SKILL.md：
模板目录：
TEST_SPECIFICATION.template.md：
run_regression.template.py：
playwright.config.template.js：
standard-flow.spec.template.js：

3D Battlefield Local Update Benchmark

Wed, 10 Jun 2026 00:00:00 +0000

适用对象：城市战场仿真场景中“三维战场场景局部更新”功能的回归测试

输入：无人机 / 无人狗等侦察源采集的侦察录像（及位姿元数据）

待测能力：基于侦察数据，检测战场局部变化，并将原有三维场景同步更新（几何替换、目标插入/删除、动态目标同步、语义/通行性更新），实现态势实时刷新。

1. 通用约定与指标体系

1.1 设计原则

覆盖性

变化类型覆盖“正变化(新增)、负变化(消失)、形变(损毁)、动态(时敏)、语义(通行性)、地表(高程)”六大维度。

可量化

每类想定都附带真值(Ground Truth)定义与数值化通过门限，避免“看起来更新了”这类主观判断。

抗作弊

每个场景都强制保留静默对照区(无变化区域)，专门检验模块“是否乱改未变化的部分”——这是态势更新最危险的失效模式。

难度分层

从单一清晰变化 → 弱信号/强干扰 → 退化感知 → 复合密集,形成梯度

可复现

所有摆放、动线、航线用统一坐标与参数描述,UE内可一次性复刻。

1.2 坐标与标注约定

采用本地 ENU 坐标系：原点取地块西南角，X 轴指东、Y 轴指北、Z 轴朝上，单位米。
地块尺寸记为 $W \times D$（东西 × 南北）。点位记为 (x, y, z)，航点同。
每个变化实例须导出真值条目：{id, 类别, 中心点(x,y,z), 朝向yaw, 包围盒尺寸(l,w,h), 损毁等级, 出现/消失标志, 轨迹(若动态)}。
真值由 UE 场景脚本直接导出（场景即真值来源），无需人工再标注。

1.3 侦察源能力假设（用于统一录制条件设定，可按实际平台标准调整）

平台	传感器	典型作业参数	用途
无人机(旋翼)	EO 4K@30fps + 云台，选配 IR/多光谱	飞行高度 30–120 m AGL，巡航 3–8 m/s，盘旋凝视	区域测绘、顶视/斜视、运动目标跟踪
无人狗(地面)	EO + 选配 LiDAR，传感器高 $\sim 0.5$ m	1–2 m/s，可抵近/入室	低矮工事贴地侦察、内部走廊、坑深桥况近测

1.4 损毁分级标准

等级	名称	判定特征
D0	无损	结构与外立面完好
D1	轻度	门窗/外立面/装饰破损，承重结构完好
D2	中度	局部墙体穿孔或单层塌落，结构基本完好
D3	重度	多层或承重构件受损、局部坍塌、瓦砾外溢
D4	摧毁	整体坍塌为瓦砾堆，原结构不可辨

1.5 统一指标定义

（1）变化检测匹配

预测变化实例与真值实例匹配，当且仅当：中心距 $\leq d_{\text{match}}$ 且类别一致（或三维 IoU $\geq 0.3$）。

建议 $d_{\text{match}} = 1.0$ m（静态）/ $2.0$ m（时敏目标）。

（2）检测层

$$\text{Precision} = \frac{TP}{TP + FP},\text{Recall} = \frac{TP}{TP + FN},F1 = \frac{2\,\text{Precision} \cdot \text{Recall}}{\text{Precision} + \text{Recall}}$$

（3）定位精度

$$e_{\text{pos}} = \left\| \mathbf{p}_{\text{pred}} - \mathbf{p}_{\text{gt}} \right\|_{2},e_{\text{yaw}} = \left| \,\text{wrap}\left( \theta_{\text{pred}} - \theta_{\text{gt}} \right)\, \right|$$

（4）几何重建精度

三维包围盒交并比与点云/网格 Chamfer 距离：

$$\text{IoU}_{3D} = \frac{V_{\text{pred}} \cap V_{\text{gt}}}{V_{\text{pred}} \cup V_{\text{gt}}}$$$$d_{CD}\left( S_{1},S_{2} \right) = \frac{1}{\left| S_{1} \right|}\sum_{x \in S_{1}} \min_{y \in S_{2}}\left\| x - y \right\|_{2}^{2} + \frac{1}{\left| S_{2} \right|}\sum_{y \in S_{2}} \min_{x \in S_{1}}\left\| x - y \right\|_{2}^{2}$$

（5）地表高程精度

$$\text{RMSE}_{z} = \sqrt{\frac{1}{N}\sum_{i = 1}^{N}\left( z_{i}^{\text{pred}} - z_{i}^{\text{gt}} \right)^{2}}$$

（6）时敏目标跟踪

位置 RMSE、速度误差 $e_{v} = \left\| \mathbf{v}_{\text{pred}} - \mathbf{v}_{\text{gt}} \right\|$、ID 切换次数、检测时延 $T_{\text{lat}}$（目标进入视野到被建立航迹的时间），并用 MOTA/MOTP 汇总。

（7）静默区稳定性（关键防作弊指标）

未变化区域被错误修改的占比：

$$S_{\text{drift}} = \frac{\text{被修改的未变化体素}\text{(}\text{或面积}\text{)}}{\text{未变化区域总量}}$$

要求越小越好。

（8）时效性

端到端更新时延 $T_{\text{update}}$：从单次侦察数据就绪到场景完成局部更新所耗时间（区分离线批处理模式与近实时模式）。

（9）鲁棒性保持率（退化条件场景）

$$\rho = \frac{\text{得分}_{\text{退化条件}}}{\text{得分}_{\text{基准条件}}}$$

1.6 通过门限

指标	建议门限
静态变化检测 F1	$\geq 0.85$
时敏目标检测召回	$\geq 0.90$
损毁分级（±1 级容差）准确率	$\geq 0.90$；严格准确 $\geq 0.70$
静态目标位置误差	中位 $\leq 0.5$ m，95 分位 $\leq 1.0$ m
朝向误差	$\leq 15^{\circ}$
几何 $\text{IoU}_{3D}$（损毁体/工事体）	$\geq 0.50$
地表高程 $\text{RMSE}_{z}$	$\leq 0.30\,\mathrm{m}$
TST 位置 RMSE / 速度误差	$\leq 1.0\,\mathrm{m} / \leq 1.0\,\mathrm{m}\cdot\mathrm{s}^{-1}$
TST 检测时延 / ID 切换	$\leq 2\,\mathrm{s} / \leq 1$ 次·目标$^{-1}$·分钟$^{-1}$
静默区稳定性 $S_{\text{drift}}$	$\leq 2\%$
鲁棒性保持率 $\rho$	$\geq 0.75$
端到端更新时延 $T_{\text{update}}$（近实时模式）	$\leq 5$ s（按需设定）

1.7 评分与判定

每个场景按其权重指标归一到 0–100 分，单场景 $\ge 70$ 记为通过。
Benchmark 综合分 = 各场景加权平均。
否决项：S4（时敏目标）与 S9（复合密集）设下限，任一低于 50 分则整体判不通过——因为这两项直接对应“实时态势”的核心价值。

2. 场景想定

S1 建筑物损毁

测试能力：几何形变检测、损毁等级判定、瓦砾/碎片建模、原有三维网格的局部替换。

场景范围：$180 \times 180$ m 城市街区。沿街布置 7 栋建筑（3–8 层混合），含主街、人行道、行道树。

基线（更新前）场景：所有建筑 D0 完好；街道整洁无碎片。

验证指标与通过判据：

损毁分级 ±1 级准确率 $\geq 0.90$，且 B1/B2/B3 的严格分级至少 2/3 正确。
形变体 $\text{IoU}_{3D} \geq 0.5$；瓦砾堆体积误差 $\leq 25\%$；B2 楼高下降量误差 $\leq 1.0$ m。
B0 静默稳定性 $S_{\text{drift}} \leq 2\%$（误把完好楼改成损毁即判该项失败）。

未损毁状态（baseline）

D2中度损毁状态

D3重度损毁状态

D4摧毁状态

S2 新增野战工事与掩体

测试能力：低矮小目标的新增检测、分类、尺寸/朝向估计与插入定位；区分人工工事与天然/废弃堆积物。

场景范围：$220 \times 160$ m 城郊接合带，含开阔空地、矮墙、3 栋平房。

基线场景：空地无任何工事。

验证指标与通过判据：

工事新增检测召回 $\geq 0.85$，分类准确 $\geq 0.85$。
位置误差中位 $\leq 0.5$ m；堑壕/HESCO 长度误差 $\leq 15\%$；朝向误差 $\leq 15^{\circ}$。
干扰项不被标为“新增工事”（误报即扣分）；废弃水泥堆静默稳定。

新增工事前（baseline）

新增工事后

S3 目标消失 / 移除（负变化）

测试能力：负变化检测（最易被忽略）；区分“被遮挡”与“真消失”。

场景范围：$150 \times 150$ m 院落与停车区。

基线场景：停放车辆、临时帐篷、沙袋掩体、矮墙。

验证指标与通过判据：

移除检测召回 $\geq 0.85$、精确率 $\geq 0.85$。
遮挡误判率：被遮挡但仍存在的目标被误报为“消失”的比例 $\leq 10\%$。
沙袋掩体静默稳定 $S_{\text{drift}} \leq 2\%$。

目标消失前（baseline）

目标消失

S4 时敏目标

测试能力：动态目标实时检测、连续跟踪、轨迹与速度估计、场景的近实时同步更新、军/民目标区分。

场景范围：$300 \times 200$ m，含一条东西主干道、一个十字路口、一个广场。

基线场景：道路空旷无车。

动态动线（时间以侦察开始为 $t=0$）：

装甲车：沿主干道巡航；减速停车 5 s 后再启动（考验航迹保持与“停止≠消失”）。
皮卡：从巷口驶出，至路口右转向东，在广场停车，随后 3 名人员下车向四周疏散（5–8 m）。
步兵班：沿北侧建筑阴影行进，疏散队形(间隔 3–5 m)。
民用车（干扰，非军事目标）慢速通过,应被正确区分或按既定规则处理。

验证指标与通过判据：

各运动目标检测召回 $\geq 0.90$；检测时延 $T_{\text{lat}} \leq 2$ s。
位置 RMSE $\leq 1.0$ m；速度误差 $\leq 1.0$ m/s；V1 停车段不得误判为“目标消失”。
ID 切换 $\leq 1$ 次/目标/分钟；MOTA $\geq 0.70$。
军/民分类正确（民用车不进入军事时敏目标列表，或按规则降权）。
场景内动态目标的位姿刷新频率满足近实时门限（如 $\geq 1$ Hz，按需）。

S5 伪装、隐蔽与诱饵

测试能力：抗虚警能力 + 检出隐蔽真目标；区分真目标与诱饵。

场景范围：$200 \times 180$ m，含树林边缘、建筑阴影带。

验证指标与通过判据：

隐蔽真目标(火炮)召回 $\geq 0.80$。
诱饵误判率（把诱饵当真目标高置信上报） $\leq 20\%$。
天然灌木虚警率 $\leq 10\%$；烟幕区不产生几何乱更新。

带有伪装、诱饵的场景

S6 道路与通道变化（通行性语义）

测试能力：通行性语义更新（可通行 ↔ 受阻）、路障/弹坑/断桥识别。

场景范围：$280 \times 120$ m，含主路、跨河、两侧建筑。

基线场景：道路畅通、桥梁完好。

验证指标与通过判据：

障碍/损毁检测召回 $\geq 0.90$。
路段通行性状态判定正确率 $\geq 0.90$（每个路段标注通行/受阻/断绝三态）。
弹坑直径误差 $\leq 20\%$；桥梁断面被正确识别且更新为“断绝”。

道路变化前（baseline）

道路变化后

S7 地形与地表变化

测试能力：地表网格/高程的局部更新、弹坑与焦土/碎片场建模。

场景范围：$200 \times 200$ m 开阔地，边缘有片状植被。

基线场景：相对平整地表、完整植被。

验证指标与通过判据：

地表高程 $\text{RMSE}_{z} \leq 0.30\,\mathrm{m}$。
弹坑定位误差 $\leq 0.5$ m、体积误差 $\leq 25\%$、检出 $\geq 4/5$。
焦土区范围 $\text{IoU} \geq 0.6$ 且纹理类别(焦土)判定正确；倒伏植被被更新。

平整地表（baseline）

带有弹坑的地表

S8 退化感知条件下的鲁棒性

测试能力：在烟尘、雨雾、弱光、夜间、逆光等条件下保持检测/更新能力。

场景范围：复用 S1（损毁）或 S4（运动目标）的布局,仅叠加环境条件;真值变化集合固定不变（例如固定为“一栋 D3 损毁 + 一辆 V1 运动车”），以便横向对比。

条件矩阵（同一真值集合分别复测）：

白天晴（基准）
黄昏弱光
夜间（需开启 IR/低照度）
局部烟幕
雨雾
扬尘

验证指标与通过判据：

对每个退化条件计算鲁棒性保持率 $\rho \geq 0.75$。
夜间条件下目标召回 $\geq 0.70$。
烟幕/雨雾区域不得产生“凭空生成”的几何（虚假更新 FP 不随能见度下降而激增）。

3. 汇总表

编号	场景	核心测试能力	关键指标	通过门限(建议)
S1	建筑损毁与分级	形变检测、损毁分级、网格替换	分级准确率、$\text{IoU}_{3D}$	±1级 $\geq 0.90$，$IoU \geq 0.5$
S2	新增工事掩体	新增小目标检测/分类/定位	召回、分类、位置误差	F1 $\geq 0.85$，位置 $\leq 0.5$ m
S3	目标消失	负变化检测、遮挡判别	移除召回、遮挡误判率	召回 $\geq 0.85$，误判 $\leq 10\%$
S4	时敏运动目标	实时检测/跟踪/测速/同步	RMSE、时延、ID切换	RMSE $\leq 1.0$ m，时延 $\leq 2$ s 【否决】
S5	伪装与诱饵	抗虚警 + 检出隐蔽真目标	隐蔽召回、诱饵误判、虚警	召回 $\geq 0.80$，诱饵误判 $\leq 20\%$
S6	道路通行性	通行性语义更新	通行态判定正确率	$\geq 0.90$
S7	地形地表	高程/mesh局部更新	$\text{RMSE}_{z}$、弹坑体积	$\text{RMSE}_{z} \leq 0.3\,\mathrm{m}$
S8	退化感知鲁棒性	烟尘/弱光/夜间稳健性	保持率 $\rho$	$\geq 0.75$

Preview | VISTA Research Group

用 Agent Skill 重构网页应用测试

1. 这个仓库是什么？

2. 仓库结构概览

3. web-app-test 的核心定位

4. 测试分为两大类

4.1 程序测试脚本：必须预先设计

4.2 浏览器模拟用户操作：不预先写满，动态沉淀

5. 一条完整测试链路是怎样的？

6. 测试资产如何落地到项目？

7. 新项目接入流程

8. 模板目录提供了什么？

8.1 TEST_SPECIFICATION.template.md

8.2 run_regression.template.py

8.3 playwright.config.template.js

8.4 standard-flow.spec.template.js

9. 安装与依赖

10. 测试结束后必须交付 Markdown 报告

11. 失败不是只有“代码 bug”

12. 这个仓库适合什么场景？

13. 这个设计最有价值的地方

14. 可以继续增强的方向

15. 总结

参考链接

3D Battlefield Local Update Benchmark

1. 通用约定与指标体系

1.1 设计原则

1.2 坐标与标注约定

1.3 侦察源能力假设（用于统一录制条件设定，可按实际平台标准调整）

1.4 损毁分级标准

1.5 统一指标定义

（1）变化检测匹配

（2）检测层

（3）定位精度

（4）几何重建精度

（5）地表高程精度

（6）时敏目标跟踪

（7）静默区稳定性（关键防作弊指标）

（8）时效性

（9）鲁棒性保持率（退化条件场景）

1.6 通过门限

1.7 评分与判定

2. 场景想定

S1 建筑物损毁

S2 新增野战工事与掩体

S3 目标消失 / 移除（负变化）

S4 时敏目标

S5 伪装、隐蔽与诱饵

S6 道路与通道变化（通行性语义）

S7 地形与地表变化

S8 退化感知条件下的鲁棒性

3. 汇总表

8.1 `TEST_SPECIFICATION.template.md`

8.2 `run_regression.template.py`

8.3 `playwright.config.template.js`

8.4 `standard-flow.spec.template.js`