每个 Task 在合并之前都会自动经过测试—既包括范围较窄的单元测试，也包括对运行中的应用进行验证的更全面的端到端测试。Testing 视图展示的是某个项目的测试，与任何单个 Task 无关。

Testing

Task 详情中的测试

在 Task 的详情视图中，Test 步骤显示项目单元测试的结果（通过多少、失败多少，以及所有失败的输出），E2E 步骤显示端到端场景的结果—即在实际运行的应用中模拟用户操作。如果 Test 或 E2E 失败，Fix 步骤会拿到失败详情，尝试纠正问题，然后重新测试；这一过程可自动重复数次。如果在允许的尝试次数之后测试仍然失败，该 Task 会变为 failed，失败详情会保留在其中。

Testing 视图及其标签页

默认情况下，Testing 视图有三个内部标签页：History — Dashboard、History — Modules 和 Unit Tests。另有更多标签页—Setup、Dashboard、Verdicts、E2E Plans、Scenarios、Integration Tests、Release Tests 和 E2E Cockpit—它们存在，但在导航自定义中启用之前处于隐藏状态。

Unit Tests 标签页

Unit Tests 标签页包含 Run unit tests 按钮、上次运行的汇总（通过、失败、跳过）、Run History 表（日期、通过、失败、总数、耗时），右侧则是所选运行中的各项测试，并带有 Passed、Failed 等筛选器。点击 Run History 中的某次运行即可列出其中的测试；筛选为 Failed 可阅读每个失败测试的错误信息。未能完成的运行会被标记为 crashed，并附有原因和 Ask AI to fix 按钮。

Verify 判定

测试之后，Verify 步骤会重新检查 Task 的每条验收标准，并记录三种判定之一：

• passed — 检查已运行，且与预期相符。
• failed — 检查已运行，但与预期不符；输出中说明了运行了什么、预期是什么以及实际返回了什么。
• unverifiable — 该检查完全无法运行（例如需要一个不可用的运行中实例）。这绝不会使 Task 失败；该项会被列为等待手动验证。

Build & Start/Stop

可以触发项目的构建，然后在其专用端口上启动或停止它的运行实例—与 Pipeline 在 Task 期间为 E2E 测试启动的隔离实例相互独立。

实时状态与终端输出

一眼即可看出实例正在运行、正在构建还是已停止，并可实时查看其终端/控制台输出—有助于确认构建是否成功，或诊断构建失败的原因。

停止正在运行的测试

可以随时直接在 Testing 视图中停止长时间运行的单元测试套件，而无需等待其结束。如果在测试运行期间重启了 AITM 服务器，该运行会被安全地中断—下次启动时不会卡在“running”状态；服务器会检测并清除该状态。

测试的 CPU/RAM 联合预算

单元测试和 E2E 测试共享同一份整体 CPU 和内存预算，该预算会自动适应 AITM 所在服务器的规模。测试按顺序运行，使其合计资源占用不会使主机过载—这可防止因同时运行多个测试负载而导致的崩溃。

E2E 判定历史

针对该项目记录的每一次端到端测试运行都保存在 Verdicts 标签页（默认隐藏）中，包含其判定结果（通过、功能缺陷、环境错误等）以及一条可回溯滚动的时间线，用于查看测试健康状况随时间的变化趋势。

Bug 指示器下拉菜单

顶部栏中的 Bug 指示器下拉菜单最多显示最近的 10 个 Bug，即使项目的 Bug 历史很长，也能保持快速且易读。它始终显示 Open Bug Section 链接—即使最近条目列表为空—因此该下拉菜单不会走进死胡同；无论有多少条最近条目，都只需点击一下即可进入完整的 Bug 列表。