测试不再写用例，而是定义"意图"

问任何一位测试工程师，他们每天在做什么，答案几乎都会包含这几个词：写用例、执行用例、维护用例。

这套范式运转了几十年，有其合理性。测试用例是对系统行为的精确描述，是验证逻辑的载体，也是团队协作的共同语言。然而随着AI驱动的测试生成能力日趋成熟，一个越来越真实的问题出现了：当机器能够根据代码变更、接口文档或用户行为数据自动生成数百条测试用例时，“写用例”这件事本身的价值在哪里？

这个问题触及的，不只是工具效率，而是测试工作的底层逻辑。

它把两种截然不同的测试思维摆在了同一张桌子上对比：“用例驱动”与“意图驱动”。前者以步骤的完整性为核心，后者以验证目的的清晰性为核心。两者的出发点不同，对工程师能力的要求不同，产出的质量结果也不同。

理解这个转变，不是为了否定用例的价值，而是为了在AI工具重塑测试工作的当下，找到人的判断力真正应该投放的位置。

本文将从以下维度展开：

• 范式的本质差异：用例在描述什么，意图在定义什么
• 价值密度的分野：谁在做高价值的工作，谁在做可替代的工作
• 协作方式的重构：意图驱动如何改变测试与开发的对话
• 风险覆盖的逻辑：从“遍历路径”到“守护边界”
• 能力迁移的路径：从用例工程师到意图架构师

一、范式的本质：用例在描述行为，意图在定义价值

理解两者的差异，从一个具体场景切入最清晰。

用例驱动的写法是这样的： * 打开登录页面 * 输入正确的用户名和密码 * 点击登录按钮 * 验证跳转至首页 * 验证用户名显示在导航栏右上角

这是一份精确的操作说明。它告诉执行者做什么、看什么，但它没有回答一个更根本的问题：这个测试存在的理由是什么？它在守护什么？

意图驱动的表达方式完全不同。它的起点是一句话：「用户在完成身份验证后，应该能够进入属于自己的个性化工作环境，且身份信息应在整个会话中保持一致。」

从这个意图出发，测试生成工具可以自动覆盖：正常登录路径、会话超时后的重新验证、多标签页下的身份一致性、登录状态与本地缓存的同步逻辑……这些用例不是人逐条写出来的，而是从一个清晰的意图声明中派生出来的。

一个测试架构师的核心工作，从“写完这些步骤”变成了“把这个意图表达清楚”。

核心差异：用例是意图的一种实现，而不是意图本身。当工具能够完成“实现”，人的价值就迁移到了“定义”。

二、价值密度：谁的时间花在了刀刃上

一个坦诚的问题：在传统用例驱动模式下，测试工程师每天工作时间的价值密度，是否足够高？

大量从业者的真实状态是：30%的时间在将需求文档翻译成测试步骤，40%的时间在执行和维护用例，20%的时间在处理环境问题和测试数据，真正花在“思考这个功能的质量边界在哪里”的时间，可能不足10%。

这不是工程师的问题，而是范式的问题。用例驱动模式把大量精力导向了执行层的工作，而那恰恰是AI最擅长接管的部分。

某金融科技公司在引入意图驱动测试框架后，测试团队的工作结构发生了显著变化。工程师们不再逐条编写回归用例，而是将精力集中在三件事上：

• 定义核心业务意图：梳理每个功能模块的质量目标，明确“什么样的失败是不可接受的”
• 审查生成用例的覆盖盲区：AI生成的用例覆盖了路径，但边界场景和异常组合仍需人的判断
• 沉淀测试知识：将历史缺陷模式、业务特殊约束和监管合规要求转化为意图声明库

结果是：用例数量增加了三倍，工程师的有效工作时间却减少了。不是因为他们变懒了，而是因为他们终于把时间花在了只有人才能做好的事上。

核心差异：用例驱动把人变成了高成本的脚本生成器，意图驱动把人还原为质量判断者。

三、协作方式：测试与开发的对话语言变了

在用例驱动模式下，测试与开发之间的协作往往在一个尴尬的时间节点发生：功能开发完成之后，测试工程师拿到需求文档，开始写用例，发现理解偏差，再与开发沟通确认。这个模式在时序上天然滞后，质量问题的发现窗口被压缩到了开发周期的末端。

意图驱动测试改变了这个协作时序。它要求测试工程师在需求阶段就介入，用“意图声明”的方式参与需求的定义。

一个具体的场景：某电商团队在讨论“优惠券核销”功能时，产品经理描述了正向流程，开发工程师开始评估技术方案。以往这个阶段测试工程师往往不在场。引入意图驱动框架后，测试工程师在需求会议上提出了一份意图清单：

• 「同一用户不应能对同一订单重复核销优惠券」
• 「优惠券金额超出订单总价时，用户应得到明确反馈而非静默失败」
• 「并发场景下优惠券的原子性应有明确保障」

这些意图声明，直接推动了开发侧对接口幂等性和并发锁设计的提前讨论。缺陷被发现在设计阶段，而不是测试阶段。

核心差异：用例是开发完成后的质量检查，意图是开发开始前的质量契约。前者发现问题，后者预防问题。

四、风险覆盖：从“遍历路径”到“守护边界”

传统用例设计的隐性逻辑是遍历：把所有能想到的操作路径都覆盖一遍，覆盖率越高越好。这个逻辑在资源无限的理想世界里没有问题，但在真实的工程环境中，它带来了一个严峻的问题：用例数量的膨胀，并不等比带来风险覆盖的提升。

大量用例在重复验证同类路径，而真正危险的边界场景——异常数据组合、并发竞态条件、跨系统的数据一致性——却因为“不好写”或“不容易想到”而长期处于测试盲区。

意图驱动的风险视角是不同的。它不问“哪些路径需要被走到”，而问“哪些失败是不可接受的”。这个问法天然引向了边界，而不是中心。

一个支付系统的测试负责人将这种转变描述为：从“画地图”变成“守关口”。用例驱动是把整个地图尽可能走全，意图驱动是找出那几个真正不能失守的关键节点，然后对它们进行深度验证。

前者追求面的完整性，后者追求点的牢固性。在风险高度集中的业务系统中，后者往往能用更少的资源捕捉到更危险的缺陷。

核心差异：路径遍历带来覆盖面的宽度，守护边界带来风险防控的深度。两者并非对立，但在资源有限时，深度优先的判断往往更接近质量的本质。

五、能力迁移：从用例工程师到意图架构师

这个转变对测试工程师的能力要求，是一次真实的升级，而不只是换个工具。

用例工程师的核心技能是：理解需求、分解步骤、设计数据、编写断言。这些技能是必要的基础，但在意图驱动框架下，它们成了工具应该处理的部分，而不是人应该专注的部分。

意图架构师需要具备的能力，更接近于业务分析师与风险评估师的融合：

• 业务语义理解：能够从用户视角描述功能的核心价值，而不是从操作视角描述功能的执行步骤
• 失败模式建模：能够预判这个功能在什么条件下会以什么方式失败，并将这种判断转化为可量化的意图声明
• 测试知识工程：能够将历史经验、业务约束和合规要求结构化地沉淀为可复用的意图库，而不是散落在个人记忆中

这些能力的培养，不能只依赖工具的使用。它需要测试工程师主动深入业务，参与需求讨论，积累对系统边界的直觉判断。

核心差异：用例工程师的价值在于执行的准确性，意图架构师的价值在于判断的深度。前者可以被工具替代，后者是工具的方向盘。

结尾：转型不是抛弃，是升维

读到这里，你可能会有一个现实的疑问：我的团队还没有成熟的AI测试生成工具，也没有系统的意图框架，这些讨论是否太超前？

不超前。因为意图驱动的思维方式，并不依赖特定工具才能开始实践。

即使在完全依赖手工编写用例的团队里，你也可以从今天开始做一件事：在每条用例的前面，加一行注释——“这条用例存在的理由是什么？它在守护哪个业务价值？”这个习惯看起来微小，但它会让工程师开始用意图的视角审视自己的工作，也会让团队积累起对质量目标的共同认知。

几点具体的行动建议：

• 在需求评审阶段引入意图清单：要求测试工程师在需求评审会上产出一份“质量意图声明”，而不是等待开发完成后再开始写用例。这个习惯会把测试的价值前置到最需要它的地方。
• 建立意图库而非只维护用例库：开始整理团队历史缺陷背后的意图模式，将它们归纳为可复用的意图声明。这份资产的价值，会随着时间和经验的积累持续增长，不会因为工具迭代而失效。
• 用“失败不可接受性”重新排列测试优先级：不再以用例覆盖率为核心指标，而是识别出系统中“失败代价最高”的场景，确保这些场景的意图被清晰定义、被充分验证。
• 让工程师参与业务，而不只是测试业务：鼓励测试工程师深入产品讨论，了解用户真实的使用场景和痛点。意图的质量，根植于对业务的理解深度。

用例不会消亡，它只是从人的主要产出，变成了意图的自然派生物。

真正消亡的，是那种“把步骤写全就算完成工作”的心理满足感。取而代之的，是一种更难获得、也更有价值的成就感：你清晰地知道自己在守护什么，而不只是在执行什么。

这才是测试工作真正的专业性所在。