ExploitGym测试体系拆解：单元测试与集成测试如何保障分布式评测框架的可靠性

ExploitGym 是一个基于真实世界漏洞构建的大规模基准测试平台，用于评测 AI Agent 的漏洞利用（Exploit）开发能力。它的评测流程涉及任务容器编排、防火墙隔离、LLM 代理网关等多个分布式组件，任何一环出错都会影响评测结果的可信度。本文将拆解 ExploitGym 的测试体系，看看单元测试（Unit Test）与集成测试（Integration Test）是如何分层协作，保障这套分布式评测框架可靠运行的。

🧩 ExploitGym 是什么？

ExploitGym 的核心工作流可以概括为：

1. Controller 控制器（src/cybergym/server/controller.py）根据任务信息创建/销毁/重启 Docker 任务容器；
2. Firewall 防火墙（src/cybergym/firewall/proxy.py）基于 Squid 代理实现出站白名单隔离，防止 Agent 容器"作弊"联网；
3. LLM Proxy（src/cybergym/llm_proxy/server.py）为 Agent 提供统一的模型调用入口，并做预算管控；
4. 任务覆盖三大领域：用户态程序（data/tasks/user/）、Google V8 引擎（data/tasks/v8/）和 Linux 内核（data/tasks/kernel/），当前 v1.0 版本包含 869 个实例。

正因为评测链路横跨多个进程、多个容器，测试保障就格外重要。ExploitGym 采用pytest框架，所有测试集中在 tests/ 目录。

⚙️ 测试体系总览：一份 pytest.ini 定规则

全局测试配置写在 pytest.ini 中，关键有三处：

• testpaths = tests：统一测试入口；
• 命名约定：test_*.py文件、Test*类、test_*函数；
• 自定义标记integration：

markers = integration: marks tests as integration tests (require Docker and real images)

这个标记是整个测试分层的核心：带integration标记的用例需要真实的 Docker 守护进程和任务镜像，其余全部是纯 Mock 的单元测试。由此衍生出两套运行姿势：

# 快速反馈：只跑单元测试（每次提交都跑） pytest tests/ -m "not integration" # 完整验证：包含集成测试（需要 Docker） pytest tests/server/test_integration.py -v -m integration

测试依赖声明在 pyproject.toml 中，包括pytest和pytest-asyncio，后者用于覆盖 Controller 中的异步清理循环等并发逻辑。

🔬 单元测试：用 Mock 把每个组件隔离开

单元测试的目标是"快而稳"：不依赖网络、不依赖 Docker、不依赖外部服务。ExploitGym 的实现方式很典型——把外部边界全部打桩（Mock）。

1️⃣ 服务器生命周期测试：Mock 掉 Docker

tests/server/test_controller.py 是体量最大的单元测试文件（1100+ 行），测试对象是ServerManager的核心方法，如create_server、delete_server、restart_server、health_check。

它的巧妙之处在于 fixture 设计：mock_docker_client会同时 patchcontroller和task_handler两个模块中的get_docker_client，把两条调用路径接到同一个MagicMock 上，模拟出一个带 IP 地址的假容器。这样就能在不启动任何容器的情况下，断言：

• 容器创建参数是否正确；
• 服务器过期（TTL）清理循环是否按预期销毁容器；
• 线程安全与并发操作是否可靠；
• 容器不存在等异常分支的错误处理。

2️⃣ 接口层测试：TestClient 直测 FastAPI 路由

tests/server/test_main.py 使用 FastAPI 的TestClient直接对 HTTP 端点发起请求，但底层的ServerManager被替换为 Mock 对象。这种"接口真实、依赖伪造"的方式，能在毫秒级验证请求参数校验、响应结构（如ServerInfo、ServerHealthResponse）和 4xx 错误码是否符合契约。

3️⃣ 密钥与 Token 测试：安全逻辑零容忍

分布式评测中，Controller 启动时生成 token salt、flag seed 和 API key，两端必须一致才能签发任务 token。相关测试分布在：

• tests/server/test_token.py：验证 flag 生成的确定性（相同 seed + task_id 必须产出相同 flag）和格式规范；
• tests/evaluation/test_controller_secrets.py：验证"参数优先于环境变量、缺失即报错"的密钥解析规则，确保没有任何硬编码回退值。

4️⃣ 防火墙、LLM 代理与其他组件

• tests/firewall/test_proxy.py：用tmp_path临时文件测试 Squid 白名单加载逻辑，覆盖注释行、空行、.domain前缀保留、文件缺失抛错等边界；
• tests/llm_proxy/test_server.py：通过构造最小 FastAPI 应用 +BudgetAuthMiddleware，验证 LLM 代理的路由匹配（哪些路径放行推理、哪些拦截）与预算鉴权；
• tests/evaluation/test_intermediate_stats.py：验证运行中用量快照逻辑，且用量查询失败不致命；
• tests/task/test_kernel_workspace.py：验证内核任务工作区构建——vulnerability.md默认拷贝、patch.diff和pov均为可选开关，保证 Agent 拿到的信息符合题目设定。

🐳 集成测试：真实 Docker 容器跑完整链路

单元测试再完善，也只能证明"每个零件没坏"。集成测试（tests/server/test_integration.py）回答的问题是"装配在一起还能不能跑"。它的几个设计细节值得学习：

1. 优雅降级：check_docker_availablefixture 先docker.from_env()+ping()，环境里没有 Docker 就直接pytest.skip，而不是报错，方便在无 Docker 的机器上跑单元测试；
2. 真实镜像：使用真实任务镜像cybergym/arvo:36476-vul.exp.none端到端验证 token 生成 → 容器创建 → 健康检查 → 命令执行 → 自动过期的完整工作流；
3. 资源复用与清理：shared_server_manager采用module级作用域共享实例，测试结束后统一销毁容器；docker_cleanupfixture 兜底强制移除残留容器，避免污染环境；
4. 多 Agent 并发：专门覆盖多个 Agent 同时持有容器的场景，这正是分布式评测的真实负载模型。

🚀 测试运行指南：3 条命令快速上手

结合 tests/server/README.md 的说明，推荐这样组织测试节奏：

# ① 日常开发：全部单元测试（秒级反馈） pytest tests/ -v -m "not integration" # ② 拉取集成测试所需镜像 docker pull cybergym/arvo:36476-vul.exp.none # ③ CI 或发版前：跑集成测试 pytest tests/server/test_integration.py -v -m integration

集成测试失败时的排查顺序也很实用：docker ps看守护进程 →docker images | grep arvo看镜像 →docker container prune -f清理残留 → 加-s参数查看测试输出。

该 README 还给出 CI/CD 的最佳实践：单元测试跑在每次提交，集成测试跑在 PR 或定时构建——用-m "not integration"排除重资源用例，让快反馈循环保持轻快。

📌 小结

ExploitGym 的测试体系给了分布式评测框架一个清晰的可靠性答案：

分层隔离让开发者在日常提交中获得秒级反馈，又保留了对真实运行环境的最终验证手段——这正是评测类基础设施敢于承载数百个漏洞任务并行评测的底气所在。如果你想深入某条链路，可以从 tests/ 目录对应子目录直接读起，每个文件开头的 docstring 都写明了测试目标与运行方式。