我们测了AI 写测试用例的 4 类方案最后发现差距在敢不敢跑给你看过去半年AI 生成测试用例从一个营销词变成了实实在在的产品品类。我们调研并试用了一圈主流方案把它们分成四类传统用例管理工具加 AI代表是 TestRail 这类老牌平台开源一站式平台的 AI 增强代表是 MeterSphere商业自动化工具的 AI 辅助代表是 KatalonAI 原生的测试产品代表是 Testim、mabl 这类海外 SaaS以及国内新起的开源方案 WHartTest。试到最后我们发现判断一个AI 测试产品靠不靠谱只需要问一个问题生成的用例它敢不敢真实执行一遍证明给你看为什么敢不敢跑是分水岭AI 生成用例的通病是看起来很美格式工整、步骤清晰但真要执行就露馅——参数是编的、预期结果不可判定、业务规则是模型臆造的。测试团队买的是能跑的用例不是像用例的文本。多数产品的处理方式是生成完直接交给你人工筛。而 WHartTest 的做法是在生成流程里内建了验证闭环AI 生成接口用例后平台会真实发起请求试跑——通过才算完成失败则由 Agent 分析原因、自动修复后重跑上限 5 次遇到数据依赖缺失的保留用例骨架并登记待补充清单。最终交付的不是一堆待人工验证的草稿而是带着试跑统计、待补充清单、待确认清单比如疑似缺陷的结构化产出。这是生成和生成并验证的区别也是玩具和工具的区别。WHartTest 的技术方案拆解看了一遍它的实现项目在 GitHub 开源Django 5.2 DRF 后端Monorepo 架构几个设计值得展开知识库 RAG 是生成的底座不是附加项。文档入库支持 PDF/Word/Excel/PPT/Markdown 和网页链接分块向量化后检索用的是 Dense BM25 混合检索加 RRF 融合排序再叠可配置的 Reranker。这套组合拳的意义在于参数约束、业务规则这些写在你们内部文档里的知识能被检索出来喂给模型从源头减少幻觉。生成维度是结构化的不是一句提示词。单接口用例按 D1 基本功能 / D2 边界值 / D3 业务规则 / D4 异常场景的维度体系生成D2 的边界值要求有文档证据D3/D4 的业务规则来自知识库和业务描述且防幻觉约束写进了流程。场景用例覆盖 S1-S4生命周期等支持指定登录接口做鉴权前置token 提取注入、DB 校验开关、每接口条数上限。deep 模式下有子代理逐条审批。类似工程里的 code review主 Agent 生成子代理对每条用例做独立审批不通过打回。配合平台级的 MCP 工具人工审批HITL中间件AI 的关键动作都有人把关。UI 自动化直接让 Agent 上真浏览器。这是最近版本刚落地的能力选一个需求模块AI Agent 以真实浏览器探索目标系统的页面 DOM自主提取元素、编排步骤、组装用例并全部落库同样带试跑验证。传统 UI 自动化建设创建页面、提取元素、编排步骤、组装用例四步AI 一步到位。四类方案横评传统工具AITestRail 类开源平台MeterSphere商业自动化KatalonAI 原生Testim/mabl/WHartTestAI 用例生成深度词条级辅助辅助增强录制辅助全流程生成生成后执行验证无无无WHartTest/Testim 支持需求侧能力有但无 AI无 AI 评审无WHartTest 有六维评审私有化本地模型贵支持商业授权WHartTest 支持Testim/mabl 仅 SaaS上手成本低中高WHartTest 低Docker 一键几个主观判断供参考TestRail管理流程成熟但 AI 是贴上去的适合已经在深度使用、不想换平台的团队MeterSphere是优秀的开源接口测试平台但 AI 深度有限UI 自动化还在 Selenium 体系和 AI 原生方案有代差Katalon录制回放扎实团队协作和需求侧是短板授权费用不低Testim/mabl自愈定位等 AI 能力确实领先但 SaaS-only、价格高国内合规场景基本不可用。WHartTest 是四类里唯一同时满足全链路 AI 生成 试跑自证 知识库增强 私有化部署 免费开源的。当然它也有代价你需要自己准备 LLM云端 API 或本地 Ollama自己的算力自己买单。怎么试Docker 一键部署默认端口 8913接上任意 OpenAI 兼容模型就能开始。建议从这两个场景切入把一份真实需求文档传进需求评审模块看六维评分和模块拆分的质量导入一份 OpenAPI/Swagger 接口定义勾选 D1D2 范围开 deep 模式生成一轮重点看试跑通过率和待确认清单里有没有它帮你抓到的真 Bug。第二项是我们认为最能检验平台成色的地方——试跑阶段抓到的疑似缺陷清单比任何演示视频都有说服力。