Vibe Testing ？为什么说某些智能化测试或许只是在“赛博许愿”罢了

当去年Dewin横空出世后，业界就冒出了“给 LLM 丢个 PRD 就自动生成测试用例”的各种案例，甚至有老板们开始畅想AI4SE实现研发交付过程的端到端全过程自动化，可以进一步“降本增笑”了。但真当实操起来，却发现生成的用例要么漏洞百出，要么沦为无法执行的 “空架子”，然后开始抱怨LLM幻觉太多—— 这不是智能化，更像是一场自我安慰的 “赛博许愿”。为何 LLM 在测试领域的表现总是差强人意？多 Agent 协作能否打破困局？真正的 “氛围测试”（Vibe Testing）又该如何落地？本文将带你撕开 “AI 万能论” 的面纱，探寻测试智能化的真实路径。

赛博许愿案例2则

在vibe testing中，仿佛有了LLM加持就无所不能了。以下是笔者看到的一些测试智能化的方案。

场景1：光丢一个PRD给LLM让它生成测试用例

我们先抛开LLM, 假设读者今天要去面试一个初级测试岗位的应聘人员，你向对方提出了如下一个问题

Q: 给你一个PRD,你会怎么进行测试分析？还会参考哪些方面的信息？

但凡这个面试的同学是稍微有点经验的，就至少会提到以下的几点，

1） 需求条目化与上下文

首先需求自身不是孤立的，存在于上下文中。如某次业务改造的story,往往只是一个更大范围的需求epic的一小部分。其它的部分可能是在本次改造中由别人来测试，或者是已经在之前的版本中实现了（当然理论上还有可能尚未实现的）。

【华为云技术分享】【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词_epic feature story task-CSDN博客

【华为云技术分享】【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词_epic feature story task-CSDN博客

测试人员在理解这个PRD中的需求时，其它既有相关联的需求是重要的上下文。你就给LLM一个本次改造的PRD,其它都让它脑补？

2）术语和关联信息

另外，也有同学提到过，他们的PRD中，经常会有，“参见XXX”,”同XXX”等。当然还会有更多的内部私有的术语、黑话和约定俗成的潜知识。也就是存在一个衍生阅读、展开理解的过程。这对于正确、完整地理解这个需求也是至关重要地。

3） 而从历史的角度来看，某个PRD需要修改系统、模块、功能点，往往在历史已经经历了多次修改。这一次改动也只是更多一次修改而已。这些历史修改和针对这些历史修改所设计的用例，也是很重要的参考信息。而针对某些特定功能的历史缺陷、必测要点等等，也是可以作为测试设计进行测试点展开时的参考内容。

当然，以上这些可能还只是这位应聘人员的回答的一部分。可能他还能说出更多的内容。那么问题来了，如果面试了另外一个测试人员，他回答说“我就是认真仔细分析了PRD的每一句话，然后运用边界值、等价类等测试设计方法产生测试用例。” 这样的人你作为面试官会让他通过嘛？大概率是不会吧。

图片

那么如果来面试的是一个只费电不吃饭领工资的数字员工，你为啥就喜滋滋地录用了呢？因为电费老板出是嘛？反正是白给的，不要白不要。

笔者把这种现象描述为“在赛博垃圾堆里捡垃圾“。如同2024年中下时做过的IDE中只给被测方法的代码进行单元测试用例的生成，在实际项目中，这种方式下一次生成成功(编译通过+执行通过+有断言)的概率为0%！最主要的原因是当时的AI插件都只抓取了被测方法体的代码给LLM进行单测用例生成，但凡有个外部依赖必定生成失败。

场景2：用OpenAPI spec就要求生成接口自动化用例

这个问题笔者在之前的《为什么说只发送接口说明给LLM要求生成单接口用例是在“耍流氓”？》文章中已经讨论过了。由于接口描述中缺少了非常关键地信息如入参约束(默认只有是否必填)、业务枚举值、业务边界等，LLM生成地用例大概率也是“样子货”。

举个例子，要测试一个退单的接口，就需要通过数据库造数或者调用下单的接口先准备数据，然后再调用退单接口进行测试。当然前面还要完成登录/token等必须必要的操作。而如果只是让LLM根据OpenAPI spec去为退单接口生成一条调用数据或者是像模像样的python代码。这也只能是局部的代码续写而已，而不是所谓的用例生成。

那怎么实现“氛围测试”，而不是“许愿式测试呢” ？

在测试用例生成环节，笔者认为可以通过如下的若干个Agent的协作来完成。

需求Agent-> 测试点生成Agent-> 用例扩写Agent

当然，再有一个调度Agent来总负责调度整个任务的完成。

需求Agent

主要负责需求的完整性和完备性。模仿产品经理和开发/测试团队之间的需求澄清环节的工作。负责从知识库中召回如下的信息

1） 该需求的上下文(epic-feature-story)及其对应的PRD – 需求知识库

2） 补充获取PRD中的链接、“参见”等外部上下文

3） 召回各个PRD中的业务概念、业务枚举值-业务基本概念知识库

4） 明确该需求所涉及到的系统、模块、功能点

输出：补充完备后的需求内容

测试点生成Agent

主要负责产出测试要点(一句话)。模仿测试设计人员画测试脑图的工作。再分为3个环节

拆分– 召回– 生成– 合并

1)拆分：如果需求Agent产出的内容涉及范围过多，可以进行拆分。也就是“分块”进行测试用例设计。

2)召回：对于拟进行测试设计的需求内容进行召回所需的知识。

A、测试用例：根据分块需求涉及到的上下文需求，召回其对应的既有测试用例

B、 测试用例：根据功能点、分块需求中的业务关键字等召回相关的测试用例

C、 缺陷：前述需求、业务中的已知缺陷和关联用例

3）生成：根据前述内容来生成测试要点的思维导图结构

输出：结构化的测试要点

4）合并：合并所有的生成结果

5） 用例筛选

根据生成的用例进行筛减，给定用例召回同系统下相似用例，并判断是否一致。一致的话，复用既有用例

用例扩写Agent

目前为止，生成的所谓用例其实就只是“一句话”的测试要点而已，并不是具有可执行度的带有具体步骤和数据的所谓的“测试用例”。

因此，下一个阶段就是所谓的“用例扩写”，将一句话的测试要点“扩写”成完整的测试用例并（经过人工确认）提交到测试平台中完成用例生成的过程

这一部分可以参考笔者之前写的《为什么测试智能化推荐从"用例续写"开始》一文。

如果再把整个过程进一步进行抽象，笔者认为实现端到端的vibe testing 需要有如下两类的基础设施建设。

1）有一个包括了系统全生命周期数据的数字孪生 (digital twin)

数字孪生是 Vibe Testing 得以精准运行的基石。它完整复刻了系统从需求设计、开发编码到上线运维的全流程数据，涵盖功能需求文档、底层代码逻辑、历史运行日志以及用户行为轨迹等。通过对这些数据的整合与分析，数字孪生能够构建出系统的完整数据，为后续的系统改造、开发、测试和运维排障提供及时、准确的数据和分析结果。

2）有任务规划 - 分析 - 执行 - 结果的反馈环并持续迭代

目前LLM通过function call/tooling等模块逐渐具备了对物理世界反馈的感知能力。类似的，这一反馈环是 Vibe Testing 保持动态优化的核心机制。在任务规划阶段，结合业务目标与系统特点，制定初步的测试策略；进入分析阶段，借助 AI 对测试用例进行审查与优化，提升其全面性与有效性；执行测试过程中，实时监控进展与结果，精准捕捉问题；最后在结果反馈阶段，深入剖析问题根源，并将这些信息及时反馈至任务规划与测试用例生成环节，对测试策略与用例进行调整和优化。

如此循环往复，使得 Vibe Testing 能够不断适应系统的功能迭代与业务需求的变化。例如，当软件新增功能模块时，通过反馈环的快速响应，及时调整测试策略，补充新的测试用例，确保新增功能的质量，同时避免对原有功能产生影响，实现测试质量与效率的持续提升。

从这这个层面来看，之前DevOps的基础设施建设其实是智能化的基础。