大多数测试管理工具都有 REST API，有的还做得不错。但"有 API"和"能让 AI 智能体安全地操作它"，是两条不同的门槛。TestPulse 1.0.0 刚发布，开源、AGPLv3 协议，项目、版本化测试用例、套件、运行、报告、Jira 连接器一应俱全，但真正值得说的是它怎么对待 AI 智能体。
一个智能体要动你的测试套件，需要的东西并不玄乎：
- 它自己的身份，而不是共用的服务账号，这样每个动作都能追溯到具体执行者
- 权限按人的方式划范围，而不是"有 API key 就全给"
- 调用失败后能重试，又不会重复创建数据
- 输出能被真正解析和操作——是键，不是看不懂的内部 ID
这些都不算稀奇，但默认就带上的产品几乎没有。所以 TestPulse 从第一天就把它们做了进去。
MCP 服务器里到底有什么
TestPulse 在 /mcp 暴露一个 MCP 服务器，和 REST API 在同一个二进制里——不是独立服务，也不是插件。认证方式和 REST 完全一致：一个 Bearer token，绑定到单个项目和单个角色；或者不绑定，按创建者当前权限行事，每次调用都重新解析。
一共 14 个工具，刻意做得粗粒度——不是每个 REST 端点的 CRUD 镜像，也不是几个包办一切的巨型工作流工具：
- upsert_test_case、upsert_step_group、upsert_test_suite、update_suite_membership
- bulk_add_cases、create_test_run、record_result、update_run_item_status
- search、get_details、get_run_progress、list_run_items
- list_unit_test_results、list_projects
删除操作只走 REST，这是故意的——不存在删除工具。
其中三个工具（upsert_test_case 的创建路径、bulk_add_cases、create_test_run）接受可选的 idempotencyKey。如果调用超时，你用同一个键重试，服务器会返回原始结果，而不是创建重复数据。键按调用方和工具划分作用域，24 小时后过期，只有成功的调用才会被缓存，所以重试失败的（校验或权限）调用永远是安全的。
两次调用的演示
设计时反复回到的场景是："读取 requirements.md，在 TestPulse 里创建一个测试套件。"
通过 MCP 连接的智能体两次调用就能完成：
- upsert_test_suite——创建套件
- bulk_add_cases——原子化地填充它。一个格式错误的用例会让整批失败，不会出现半创建状态
这种原子性比听起来更重要。另一种做法是循环调用单个创建用例接口，当第 14 个调用因为 schema 问题失败时，你面对的是一个填了一半的套件，得慢慢排查。
其余部分，简单说
核心测试管理：项目、版本化测试用例（每次编辑生成新版本，而非覆盖）、套件、带开启/关闭生命周期的运行、JUnit XML 导入，原生插件覆盖 pytest、Maven、Gradle、Jest、Go、.NET、GoogleTest、Jasmine、Mocha 和 Vitest。
身份：本地认证加会话、作用域 API token、SSO/OIDC、项目级 RBAC。报告：通过率趋势、不稳定用例检测。迁移：从 TestRail、Qase、Zephyr Scale、Kiwi TCMS、Xray 和 Tuskr 做结构化导入。部署：单个 Go 二进制、Postgres、多架构 distroless 镜像，docker compose up 即可评估，生产环境用 Helm chart。
想试的话，克隆仓库、进目录，用 deploy/compose 下的 docker-compose.yml 起服务，就能得到一个带示例项目的运行实例——上面每个 MCP 工具立刻有真实数据可操作，无需额外配置。这是一个 1.0，不是完成品，反馈、issue 和 PR 都欢迎。
热门跟贴