AI 测试工具实测：两周用例1小时搞定，军工政企为何首选 CaseRunner？
三个月前，我被叫去支援一个老项目。
项目组给我发了两份文档：需求规格说明书 127 页，接口文档 68 页。“帮我们出套测试用例。”对方说得轻描淡写。
我对着屏幕，光标一闪一闪。脑子里飞速盘算：通读需求大概两天，拆功能点一天，对接口半天，写用例——保守估计，两周起步。
但在那之前，我决定先干一件事。
一、要做一款“能写好用例”的测试工具
软件测试行业有一个很奇怪的现象：工具很多，但真正解决“写用例”、“写好用例”这个核心痛点的很少。
Postman 能帮你调接口，但不帮你写用例。禅道能帮你管用例，但不帮你生成用例。各种自动化框架能帮你执行用例，但编写用例这一步，还是得靠人一个字一个字的敲。
而写用例恰恰是最耗时、最枯燥的部分——读文档、拆功能、对接口、设计入参和预期结果。这跟“点点点”不一样，它需要理解业务，但又重复性极高。
说白了，测试行业不缺“执行的工具”，缺的是“让用例自己长出来的能力”。
今年以来，AI 测试工具开始扎堆出现。目前来看，大致分两派：
一类走开源路线，代表是 TestHub。AI 用例生成、接口测试、UI 自动化、数据工厂——功能全、更新快、社区活跃。适合有技术底子、喜欢折腾的团队。
另一类走专业平台路线，代表是 CaseRunner。它不做大而全，只聚焦一件事：从需求文档到可执行测试用例的全流程自动化。听着窄，但这恰恰是军工、政企等行业最痛的那一刀。

图1 测试工具产品路线对比

两条路没有谁对谁错，但适用场景天差地别。
二、CaseRunner 到底在解决什么问题？
说人话就是：把测试人员从“读文档、写用例”的体力活里捞出来。
打开官网（http://t.cn/AXoQePA3），注册登录，操作流程比你想象的要简单：
第一步：配置 AI 模型。
接上你自己选的大语言模型，给个 API Key 和 Base URL 就行。这相当于给系统装一个“大脑”。

图2.1 进入AI配置界面

      进入 AI 配置页后，
点击右上角的“+”
，新建 LLM 的配置，如图 2.2所示；

图2.2 AI配置页

输入配置名
（可自定义）、
API KEY
（LLM 的密钥）、
Base URL
（模型部署的基地址）、
模型名
（确保输入准确），然后点击
确定
，如图 2.3所示；

图2.3 新增AI配置

第二步：创建工程。
填上被测系统的名称、地址，选一下认证模式。这一步是建立系统跟被测对象之间的“握手”。

图3.1工程管理界面

     输入
系统名称
（可自定义）、
基础 URL
（被测对象的基地址-请确保被测对象的后台已经部署到公网并对外暴露了服务的端口 – 否则只能生成测试用例，不能执行）、
选择被测系统的认证模式
（a.仅登录 – 即仅提供了登录接口，没有提供注册接口，用户的创建由管理员用户完成，需要输入管理员账号和管理员密码; b.无认证 – 即所有的接口不需要鉴权；C.注册+登录，提供了注册接口和登录接口）、
选择 AI 配置
（后续系统调用 LLM 模型，将会使用此配置），
点击“创建”
，如图 3.2所示；

图3.2 新建工程

第三步：上传文档。
把软件需求规格说明书和 API 接口文档拖进去，点击开始初始化。剩下的事情，AI 接棒。
「软件需求规格说明书」被测系统的所有功能模块放在 3.2 CSCI 能力需求下的三级标题，如 3.2.1 用户管理（TYWXNCSRJ-SCI..），以此类推；四级标题及以下不作格式要求；
软件需求规格说明书模板的下载方式如图 4.1所示
；

图4.1软件需求规格说明书模板下载

「软件接口文档」被测系统的所有接口说明放在 3.2 外部接口设计标题下的三级标题，每一个接口对应一个三级标题，如 3.2.1 用户注册接口，3.2.2 用户登录接口，以此类推；
软件接口文档模板的下载方式如图 4.2所示
；

图4.2软件接口文档下载

      准备好两份文档之后，
点击快速开始
，然后
上传上述两份文档
到对应的位置，点击
“开始初始化”
，如图 4.3所示；

图4.3快速开始

      点击后，自动跳转到进度监控面板查看整个系统的执行管线进度，如图 4.4中左侧仪表盘所示，具体执行任务可以看右侧仪表盘中的进度或右上角任务中心；

图4.4 进度看板

第四步：生成并执行。
系统自动产出测试用例，你勾选，点击执行，结果和通过率一目了然。最后还能导出测试报告。

图5.1生成测试用例

      点击侧边栏的
“测试用例”
，
点击某个批次
，然后可
勾选状态为“未执行”的测试用例
，然后点击
“执行”
，如图 5.2所示；

图5.2执行测试用例

      测试用例执行完毕后，点击侧边栏的
“测试任务”
，
点击具体的某个执行任务
，可以查看测试用例的执行结果，点击某个具体的结果，可以查看接口的真实响应，以及可以
选择性导出测试报告
，如图 5.3所示；

图5.3 测试任务

这套流程的核心逻辑其实是人机分工：AI 负责理解文档、拆解功能、拆解接口、关联功能和接口、生成用例，人负责做判断和决策。不是替代测试工程师，而是把最累的那部分工作接过去。
三、为什么军工客户选它，而不是别家？
CaseRunner 背后是武汉迎风聚智科技，一家国有参股的高新技术企业。它的客户名单里有装备发展部、工信部、海关总署、住建部等国家部委，也覆盖了航空、航天、船舶、兵器、电子等领域的军工科研院所。

图6.1 CaseRunner网站

起初我有点好奇：市面上能做 AI 用例生成的工具并不少，为什么这些客户偏偏选了它？
后来仔细看了它的产品逻辑，真正的门槛不在“AI 生成”这个标签上，而在三条不太容易一眼看到的硬功夫上：
第一条，合规。
军工软件测试，文档格式、内容完整性、签署流程，全都有硬性规定，必须对标 GJB438C 国军标。大多数通用的 AI 测试工具根本不知道这些标准的存在——不是不想做，是不知道要做什么。CaseRunner 的团队在检测技术领域深耕多年，对国军标的理解，不是靠几个月的研发能追上的。
第二条，追溯。
军工项目的需求变更管理极其严格。需求改了，哪些用例受影响，必须精确到每一条，说清楚、写明白。CaseRunner 建了一条从需求到功能、从功能到接口、从接口到用例的完整追溯链。需求一变，受影响的用例自动标记出来。这不是一个“锦上添花”的功能——在军工验收场景里，它是必须过的门槛。
第三条，数据安全。
这个不用多说。军工客户对数据安全的敏感度不是“上云”两个字能打发的。CaseRunner 支持私有化部署，数据不出企业内网。
这三条，跟“开源”“社区生态”“插件丰富”完全不在同一个赛道上。它不是比 TestHub 更好，而是根本解决的是不同的问题。

四、怎么选？
如果你正在挑选 AI 测试工具，不妨问自己三个问题：
•你的团队有能力自研自维吗？
有，开源路线很灵活；没有，专业平台更省心。
•你的客户或行业有合规要求吗？
有，必须走专业路线；没有，开源足够用了。
•你对用例追溯性的要求有多高？
“有个大概就行”还是“每一笔都要说得清”？
说白了，选工具不是选最好的，是选最适合你当前阶段的那一个。TestHub 在开源社区快速迭代，功能覆盖广、灵活性高，适合互联网和企业通用场景。CaseRunner 在合规、追溯、数据安全上做得深，适合军工、政企、金融等严肃场景。
没有高下之分，适用场景不同而已。
回到开头那个场景。
那个老项目，我最后不是花了两周，是不到一小时就拿到了第一版测试用例。然后我花了一整个上午审核、微调——不是 AI 写得不好，是我不敢不审。
但审完之后，我不得不承认一件事：AI 生成的覆盖率，比我自己手写的高。
AI 不会取代测试工程师。但会用 AI 的测试工程师，会取代不会用的。