用途：按既定测试计划端到端执行，并生成一份简洁而全面的结果文档（JSON 与人类可读的 Markdown 摘要）。适用于运行测试计划、执行 QA 工作流等场景。
主要能力与流程：
- 分段策略：先对计划每一节做合理性检查，若不合理提出最小修复建议并记入 suggested_adjustments；
- 状态准备：核验前置条件，执行最小纠正动作，若无法满足则标记 BLOCKED 并给出原因；
- 严格按计划执行，记录精确输入与原始输出；
- 与预期比对，判定状态 PASS | FAIL | BLOCKED；
- 记录时间、ID、日志、环境差异等简短备注；保留调整记录（不丢失编辑或顺序变更）。
用法：从参数读取环境配置；如需检查 Docker 服务，可使用 docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" | head -20；按需进行服务健康检查。执行时严格遵循计划各节，只允许最小修复并记录；优先做小调整而非跳过步骤；非必要不重排顺序，若重排须记录；除非失败会硬性阻断后续步骤，否则失败后继续执行。每个测试步骤需记录：步骤描述/目标、全部输入、实际输出、预期与实际对比、通过/失败结论及理由。
输出：写入 <out-dir>/test-results.json，包含 metadata（sut、env、plan_sections、timestamp）、sections（id、title、precheck_ok、pre_state、inputs、outputs、expected、comparison、status、suggested_adjustments、notes）与 overall（pass_rate、failing_or_blocked_sections、verdict）；同时在 JSON 旁写一份 Markdown 可读摘要。
质量要求：全面且有条理，遗漏测试步骤会削弱流程价值；通过/失败判定须客观、以证据而非假设为依据；即使不在计划内，也记录意外发现；文档需详细到可复现。
限制：未提供具体依赖、安装命令、支持的测试框架或平台信息；也未提供收费、价格与效果数据，暂未提供。