用AI做测试 - LLM总括

蓝字

我们常听到“工具变革”“LLM 赋能测试”等新名词，但如果我们对测试本身的理解还停留在“验证功能是否正确”的阶段，那么再强大的工具也难以产生真正的价值。

测试不是“对”与“错”的判断

很多测试人员，特别是在经验逐渐积累的过程中，会不自觉地将测试等同于“确认需求是否被实现”“功能是否符合预期”。这种认知没错，但它太过狭窄。

测试更像是一种探索与认知活动，它的目的是帮助我们理解产品两端的内容：我们打算构建什么（想象）与我们实际构建了什么（实现）。测试活动的核心任务，是不断对齐这两者的偏差。

当我们把测试看作认知工具而非验证手段，我们的测试思路、策略、甚至工具选型，都会随之发生变化。

想象与实现的鸿沟

产品开发中，"我们想要做的"与"我们最终做出来的"，往往不是同一回事。需求表达的模糊、设计方案的妥协、编码过程中的误解，都可能导致最终产出偏离了最初意图。

测试的存在，就是为了发现这种偏差，让它在进入用户视野前被看见、被修复。

换句话说，测试是一种“对齐行为”——在想象与实现之间架桥。理解这一点，是通往更高层次测试思维的关键。

多样的测试活动，对应多样的风险

为了发现这些偏差，我们需要构建多样化的测试活动，而不是依赖单一流程或工具。功能测试关注行为一致性，性能测试关注系统边界，探索性测试则善于揭示未知问题。

不同测试活动，关注的风险也不一样。有些揭示系统性问题，有些揭示边缘场景，有些则针对业务流程的完整性。只有当我们用多种方式去审视产品，我们才能更全面地理解它，降低那些“意料之外”的风险。

工具是手段，不是主角

工具的出现，是为了扩展测试人员的能力，而不是取代判断。

无论是自动化脚本、性能测试平台，还是今天讨论的大语言模型（LLM），它们都只是我们认知世界的延长装置。工具能让我们看得更快、更远，但如果我们看问题的角度是错的，那再强大的工具也只会放大误差。

因此，在引入新工具前，我们更需要回到一个根本问题：我们到底想用它解决什么？

LLM：认知型协助的新可能

大语言模型与传统工具最大的区别在于：它不仅执行命令，还能协助你思考。

在测试中，它的优势不在于“跑测试”，而在于辅助我们生成、转换、增强认知内容。例如：

生成测试数据、边界条件、测试思路清单；

转换原始日志、错误堆栈为结构化信息；

增强已有测试用例，为覆盖不足之处提出建议；

这些不是“自动化”意义上的执行操作，而是典型的“认知性任务”，过去依赖测试人员花大量脑力与时间完成，如今可以通过 LLM 快速生成草稿，测试人员只需判断与调整。

区域效应模型：精准插入，而非全权交付

很多人在使用 LLM 时容易犯一个错误：把它当万能专家，抛出一个复杂任务让它全权处理。这种方式往往带来幻觉、不准确、甚至完全跑偏的输出。

更合理的使用方式，是采用**“区域效应模型（Area of Effect Model）”的思路：将 LLM 投入那些边界明确、任务清晰、结果可判断**的局部任务中，效果往往更好。

比如，给它一段已有测试用例，让它扩展更多场景；或给它一段错误日志，让它尝试总结主要报错点。这些都是小范围高价值的插入点，能让 LLM 作为“辅助认知工具”真正发挥作用。

小案例

在一次真实的接口测试中，我们团队需要为某组 API 快速生成一批边界测试数据。传统做法要先查接口文档、再手写多种值组合。我们尝试将接口描述输入 LLM，让它生成一组典型与极端数据。

结果如何？LLM 在几秒钟内生成的内容，覆盖了我们人工大半天工作的80%。经过人工快速筛选与调整，这份数据集很快就被用于测试，并在过程中暴露了两个罕见边界缺陷。

它不是替代我们，但显著提高了效率，降低了认知负担。这就是 LLM 在测试中的最佳使用方式。

理性看待 LLM 的风险与边界

当然，LLM 并非没有问题。它可能“胡编乱造”，可能不理解上下文逻辑，甚至有时候语气自信却事实错误。我们不该对它抱有神化幻想。

因此，建议的做法是：

小任务分解：只交给它处理可控的小任务；

人工审阅把关：人类判断永远不可或缺；

逐步试用迭代：先在非关键流程中实验其效果；

当我们把它当作“聪明助手”而非“万能工具”，才能真正从中获益。

测试的未来，是认知方式的升级

回到文章开头，我们再问一次：测试的本质是什么？是验证功能？还是对产品想象与实现过程的深入理解？

如果你开始相信是后者，那么你就已经具备了理解并使用 LLM 的基础认知。而接下来的问题，只是：你愿不愿意从一个小小的任务开始尝试？

LLM 不会替你工作，但它能拓展你的认知半径，降低你的思考成本。这就是测试人在 AI 时代里，最值得掌握的一项新技能。