最近一段时间，我持续预研了多种 AI 辅助测试设计方案，也调研了不少市面上的 AI 测试工具。一个比较现实的感受是：如果只是让 AI 从需求文档直接生成测试点、测试案例，短期看起来很有效，Demo 也很容易做得漂亮，但真正进入银行、保险、证券、电信、能源、政企，或者持续运营多年的互联网核心业务场景后，问题会迅速暴露。

这些场景下，测试设计的核心目标并不只是 “快速生成一批测试案例”，而是长期沉淀一套可复用、可演进、可追溯、可审计的测试资产。

因此，我越来越倾向于认为，AI 辅助测试设计的主路径不应该是：

需求 → AI → 测试案例

而应该是：

需求 → AI → 测试模型 → 算法 → 测试案例

更准确地说，AI 不应该直接接管测试设计的最终决策权。AI 更适合做语义理解、需求拆解、规则抽取、历史资产召回和模型候选生成；而测试覆盖、路径遍历、组合生成、边界值生成、约束求解、覆盖矩阵和审计追踪，应由结构化模型和确定性算法承担。

这背后的核心不是 “AI 能不能写测试案例”，而是 “测试资产应该沉淀在哪里”。

一、直接生成测试案例的问题

直接让 AI 生成测试案例，有明显优势：启动快、成本低、交互自然、初稿生成效率高。对于低风险功能、探索性测试、测试思路启发、案例语言润色，这种方式完全有价值。

但如果它成为主路径，就会遇到几个结构性问题。

第一，覆盖目标不显式。

AI 可以生成很多 “看起来合理” 的测试案例，但测试中心真正关心的是：需求原子是否覆盖，业务规则是否覆盖，异常路径是否覆盖，状态迁移是否覆盖，字段边界是否覆盖，历史缺陷模式是否覆盖，监管或内控要求是否覆盖。

如果这些覆盖目标没有被显式建模，那么案例生成就变成了：

先让 AI 生成，再人工检查漏了什么

这不是严格的测试设计，而是一种事后补洞。

第二，结果可复现性不足。

在高风险业务中，测试资产要能回归、复核、审计和追溯。如果同一份需求，今天生成 20 条案例，明天生成 28 条案例，下周换一个模型版本又生成另一批案例，那么测试人员很难判断：哪些变化是合理的，哪些只是 AI 表达漂移，哪些是遗漏，哪些是重复。

第三，变更影响难以控制。

长期运营系统中，需求经常小步迭代。真正重要的不是每次重新生成一批案例，而是明确知道：

哪些测试资产受影响？
哪些案例需要保留？
哪些案例需要修改？
哪些案例需要废弃？
哪些覆盖目标新增了？
哪些历史缺陷模式需要继续保留？

如果没有中间模型，直接生成式方案很难稳定回答这些问题。

第四，案例文本不是最好的长期资产。

测试案例当然是资产，但它不是最高价值的资产。更高价值的资产应该是需求原子、业务规则、决策表、状态机、流程模型、字段约束、等价类、边界值、测试数据模型、判定准则模型、覆盖矩阵和追溯关系。

测试案例是这些模型和策略在某一时刻的输出。真正应该沉淀的，是能持续生成、解释、校验和演进案例的上游测试知识结构。

二、为什么资产沉淀在传统行业尤其重要

在银行等传统行业里，系统生命周期很长，业务规则复杂，合规要求强，组织协作链条长，人员流动也不可避免。测试资产一旦只沉淀在自然语言案例里，就会出现几个问题。

第一，资产难以复用。

同一个业务规则可能在多个产品、多个渠道、多个系统、多个版本中反复出现。如果资产只是散落在测试案例文本中，后续复用只能依赖关键词搜索和人工经验。

第二，资产难以演进。

业务规则变化时，如果没有规则模型、状态模型和字段模型，就很难做精确的影响分析。最后往往变成 “重新翻需求、重新看案例、重新评审一遍”。

第三，资产难以审计。

审计需要回答的不是 “我们写了多少案例”，而是 “为什么这些案例足够”。这要求测试资产能追溯到需求、规则、流程节点、状态迁移、字段约束、历史缺陷和覆盖准则。

第四，资产难以传承。

很多核心业务系统依赖老员工的经验。人员变化后，测试设计能力容易断层。如果经验没有沉淀为结构化模型，而只是散落在案例、文档和个人脑子里，那么 AI 生成再多案例，也很难真正提升组织能力。

第五，AI 本身也需要高质量资产反哺。

如果企业想持续提升 AI 辅助测试设计能力，就必须有高质量的 Golden Set、需求 - 模型 - 案例映射、覆盖矩阵、人工评审记录和历史缺陷关联。这些都不是一次性文本案例能充分承载的。

所以，在这类组织里，AI 测试设计的目标不应只是 “提升本次测试设计效率”，而应是：

每做一次测试设计，都让组织的测试知识资产变厚一点

三、更合理的架构：AI 建模，算法生成，资产沉淀

更适合高风险业务的 AI 测试设计架构，可以抽象为：

需求文档
→ 需求原子化
→ 历史资产召回
→ AI 生成测试模型候选
→ 人工评审与模型校验
→ 覆盖目标计算
→ 算法生成测试设计项
→ 案例模板渲染
→ 覆盖矩阵与追溯关系输出
→ 测试资产库沉淀

这里最关键的变化是：AI 输出的不是最终答案，而是结构化模型候选。

这些模型可以包括：

需求原子模型
业务规则模型
决策表模型
状态迁移模型
流程模型
字段约束模型
等价类模型
边界值模型
参数组合模型
异常路径模型
判定准则模型
测试数据需求模型
覆盖目标模型

测试案例则由算法从模型中生成。

例如：

• 决策表生成规则行覆盖、条件覆盖、MC/DC 或组合覆盖案例；
• 状态机生成状态覆盖、迁移覆盖、N-switch 覆盖案例；
• 字段约束生成等价类和边界值案例；
• 多参数模型生成 pairwise 或 t-wise 组合案例；
• 业务流程模型生成主路径、分支路径、异常路径和回退路径案例；
• 判定准则模型生成可审计的预期结果和断言。

这样，测试案例不再是 AI “想出来” 的文本，而是从可审查、可追溯、可复用的测试模型中推导出来的结果。

四、资产沉淀应该沉淀什么

如果只沉淀最终测试案例，资产价值仍然有限。更理想的测试资产库应该至少包含以下几类内容。

第一类是需求语义资产。

包括需求原子、业务动作、业务对象、字段、约束、规则、异常、前置条件、后置条件、可观测结果等。这些是从自然语言需求到测试设计的桥梁。

第二类是测试模型资产。

包括决策表、状态机、流程图、规则集、字段约束、等价类、边界值、组合参数模型、判定准则模型等。这些是测试设计的核心知识载体。

第三类是覆盖策略资产。

包括不同业务类型适用的覆盖准则。例如核心交易类更关注状态迁移和异常回滚，数据接入类更关注字段校验和数据组合，风控规则类更关注决策表、边界值和规则冲突。

第四类是案例模板资产。

包括标准测试步骤模板、预期结果模板、数据准备模板、接口调用模板、批处理验证模板、数据库校验模板、消息队列校验模板等。

第五类是追溯关系资产。

包括需求到模型、模型到覆盖目标、覆盖目标到案例、案例到缺陷、缺陷到规则修订的链路。这类资产决定了测试体系是否真的可审计。

第六类是评测资产。

包括 Golden Set、人工标注结果、模型抽取准确率、覆盖率、漏测率、重复率、人工修改率、缺陷发现率、评审通过率等。没有评测资产，AI 测试设计很难持续改进。

五、AI 的最佳位置：不是替代测试设计，而是增强测试资产生产

在这个架构里，AI 仍然很重要，但它的职责边界需要重新定义。

AI 适合做：

需求拆解
规则抽取
字段识别
异常场景识别
历史资产召回
模型候选生成
模型差异解释
案例语言润色
覆盖缺口提示
评审问题生成

算法适合做：

路径遍历
组合生成
边界值生成
等价类展开
约束求解
覆盖矩阵计算
追溯关系生成
增量影响分析
重复案例消解

人类专家适合做：

业务判断
模型确认
规则取舍
风险分级
覆盖策略审批
判定准则合理性确认
最终质量负责

这其实是一种更合理的人机分工：

AI 处理语义，模型承载知识，算法保证覆盖，人类负责判断。

六、方案 A 和方案 B 的真正差异

两种方案的差异，不是 “是否使用 AI”，而是 “AI 产出的东西是否能够成为长期资产”。

直接生成式方案的主要产物是案例文本。它更像是一次性生产。

模型驱动式方案的主要产物是测试模型、覆盖目标、追溯关系和案例集合。它更像是资产化生产。

可以这样对比：

维度	需求 → AI → 案例	需求 → AI → 模型 → 算法 → 案例
主要产物	测试案例文本	测试模型 + 覆盖矩阵 + 案例
AI 角色	案例生成者	语义建模助手
覆盖能力	依赖模型发挥，事后检查	基于模型和准则，构造性生成
可复现性	相对弱	模型固定后较强
变更影响分析	困难	可基于模型差异计算
资产复用	以文本复用为主	以规则、模型、模板复用为主
审计追踪	较弱	更强
初期成本	低	高
长期 ROI	不稳定	更适合长期沉淀

所以，方案 B 的价值不是 “生成更多案例”，而是把每一次测试设计活动都转化为可复用的组织知识资产。

七、落地时不要一开始做重型平台

需要注意的是，模型驱动路线并不意味着一开始就建设一个完整、复杂、重型的 MBT 平台。那样很容易投入过大，见效过慢。

更现实的落地路径是从轻量资产开始。

第一阶段，选择规则清晰、重复度高、风险较高的场景。例如：

接口测试
数据接入
字段校验
批处理规则
状态流转
交易流程
风控规则
参数组合
监管报送

第二阶段，先沉淀轻量模型。

例如需求原子、字段约束、决策表、状态迁移、等价类、边界值、判定准则模板、覆盖矩阵。不要一开始追求所有业务都完整建模。

第三阶段，建设 “需求 - 模型 - 案例 - 缺陷” 的闭环。

每次人工评审、缺陷发现、案例修改，都反向更新模型和规则。这样 AI 才能越用越好，而不是每次都重新从需求文本里猜。

第四阶段，再做平台化和自动化。

当模型规范、覆盖策略、模板和评测体系稳定后，再考虑自动生成、自动导入测试管理平台、自动生成覆盖报告、自动做变更影响分析。

八、什么场景适合这种路线

并不是所有团队都需要模型驱动方案。

如果是一次性项目、低风险功能、简单 CRUD、探索性测试，直接让 AI 生成案例可能已经足够。

但如果符合以下特征，模型驱动路线的价值会明显提高：

业务生命周期长
需求变更频繁
测试资产规模大
合规审计要求强
历史案例复用诉求高
核心业务风险高
人员流动带来知识断层
已有功能条目、规则库或 MBT 资产基础
希望建设组织级测试设计能力

银行测试中心、保险核心系统、证券交易系统、支付清算、电信计费、能源调度、政企业务平台，以及互联网公司的支付、风控、交易、履约、广告投放等核心链路，都更接近这类场景。

九、最终结论

AI 辅助测试设计的价值，不应该只看 “本次生成了多少案例”，而应该看它是否帮助组织沉淀了可复用的测试知识资产。

在高风险、长生命周期、强审计的业务场景中，直接让 AI 生成测试案例，很容易变成一次性文本生产；而 “AI 建模 + 算法生成 + 资产沉淀” 的路线，虽然启动更慢、工程门槛更高，但更符合长期治理逻辑。

因此，AI 测试设计的关键问题不是：

AI 能不能写测试案例？

而是：

AI 生成的东西，能不能进入组织的测试资产体系？

如果不能沉淀、不能复用、不能追溯、不能评测、不能演进，那么 AI 生成得再快，也只是提高了一次性产出的速度。

如果能把需求理解、规则抽取、模型构建、覆盖生成、案例渲染、评审反馈、缺陷回流都纳入资产闭环，那么 AI 才真正有机会改变测试设计的生产方式。

一句话总结：

让 AI 处理语义，让模型沉淀资产，让算法保证覆盖，让人类负责判断。
这才是高风险业务中更可持续的 AI 测试设计路线。