核心概念
理解 Munk Test 的核心产品概念，以及几条主要工作流是如何配合使用的。
要用好 Munk Test，你不需要学习复杂的测试框架，也不需要了解底层技术架构。你只需要理解几个核心的产品概念：你要测试什么、如何组织正式执行，以及你会得到什么结果。
1. 目标应用 (AppTarget)
AppTarget 告诉 Munk Test 测试的对象是什么。它屏蔽了底层平台的差异，让 AI 能以统一的方式与不同平台的应用进行交互。
- 对于 Web 项目: 它通常是一组 URL（例如
base_url,origin）。 - 对于 Android 项目: 它通常是一个应用包名（例如
com.example.app）。
你只需要定义一次 Target，Munk Test 就会自动负责拉起应用、捕获它的 UI 树并与页面元素交互。
2. 测试用例 (TestCase) 与测试计划 (RequirementPlan)
Munk Test 当前的正式执行工作流围绕结构化测试资产展开。
测试用例 (TestCase)
TestCase 是结构化、可复现的测试定义。当你有明确的验证意图和成功标准时（例如回归测试、录制回放或 CI 流水线），你应该使用它。
- 核心组成:
intent: 描述本次测试的验证意图。expected: 必须满足的预期条件列表（用于最终断言）。runner_goal: Munk Test 需要执行的具体动作。setup（可选）: 在 Runner 开始操作前执行的环境准备步骤，例如发 HTTP 请求、跑 bash 命令，用来准备测试数据或后端状态。
- 主要场景: 配合
munk run case和munk verify change命令使用。
setup 与设置页里的 测试环境（test_env）是配套关系：
TestCase.setup描述「这个 case 启动前要做什么」——目前支持http与command两类步骤。config.yaml的test_env描述「这些步骤允许引用哪些共享资源」——例如具名 HTTP base、允许执行的命令名。
HTTP setup 通过 base 引用已登记的 base；command setup 的可执行文件名必须出现在 allowed_exec 中。共享资源的配置方式见 设置 · 测试环境。
在 Web UI 编辑 case 时，可以在 环境准备 里添加这些步骤。下面分别是 HTTP 请求与命令两类步骤的界面：
测试计划 (RequirementPlan)
RequirementPlan 用来组织多条 TestCase，形成可 review、可执行、可追踪的一份正式测试资产。
- 主要场景: 配合
munk plan、munk run plan和munk verify change工作流使用。 - 为什么重要: 它是团队协作、执行与沉淀测试资产的核心单位。
3. 运行产物 (Artifacts & Runs)
Munk Test 不仅仅会在终端里打印“通过”或“失败”。因为它是一个基于视觉和语义操作的 Agent，所以它的每一次执行（Run）都会在你的本地工作区（通常是 .munk/runs/ 目录下）生成结构化的运行产物 (Artifacts)。
你不需要去翻看枯燥的控制台日志，而是可以直接查看：
report.json: 包含最终的验证结论（passed通过、failed失败 或inconclusive证据不足）。- 运行截图: 动作执行前后的真实屏幕截图，作为视觉证据。
diagnostics.json: 执行过程的详细诊断信息和报错记录。
4. 模型与配置 (Config)
Munk Test 的“大脑”是大语言模型（LLMs），我们强烈推荐使用 Gemma 4 等本地模型，以保持极低的成本和数据隐私。
配置 (Config)（通常是一个 yaml 文件）用来告诉 Munk Test 该使用哪个模型提供商（例如 LMStudio, 直连 API 等）以及如何连接。你几乎会在每一条 Munk 命令中通过 --config 参数传入它，确保 AI 的“大脑”与它的“手脚”（设备运行时）正确连接。
接下来怎么读
理解了这些基础积木后，你可以开始探索具体的工作流：