用AI做测试-用好大模型，要过三道关

蓝字

在大语言模型（LLM）快速融入软件测试的今天，我们都在追问一个问题：测试工程师到底该如何正确使用它？

这不是一个“用或不用”的选择题，而是一个“怎么用”的方法题。如果你已经尝试让 LLM 帮你生成测试用例、编写脚本或分析代码，却发现效果并不理想——很可能不是工具的问题，而是你与它之间的“协作方式”出了问题。

要让大模型真正服务于测试实践，有三道关卡必须闯过：心态（Mindset）、技巧（Technique）、上下文（Context）。

心态决定模型的边界

技术从来不是独立存在的，它依赖于使用它的人。

当我们谈论“测试人员使用大模型”的能力时，心态是最容易被忽略、却最关键的那一环。很多人对 LLM 抱有一种“替代工具”的想象——认为它应该取代人类的思考、生成最优答案。但事实是，它更像是一个“智能助手”，需要你的引导、校验和协作。

具备正确的心态，首先意味着对测试工作的价值有清晰认知：测试不是在做填空题，而是在探索风险。而 LLM 能做的，是帮助我们识别盲点、拓宽思路、提高效率，而不是接管整个流程。

换句话说，如果你希望 LLM 替你思考，它只会越来越像一个“废话制造机”；但如果你希望它和你一起思考，它才会展现出真正的潜力。

技巧，是提示词里的“功夫”

许多测试工程师在使用 LLM 的过程中，会产生这样的困惑：同样一个问题，为什么别人问得效果比我好？

核心在于提示词（prompt）的技巧。

提示词，不是简单的“你说一句我说一句”，而是需要精心设计的交互语言。好的提示词应该具备三个特征：目标清晰、结构明确、上下连贯。比如，不是说“帮我写个测试用例”，而是“根据以下登录页面功能需求，生成 3 个边界场景的 UI 自动化测试用例，使用 Gherkin 格式”。

你提供得越明确，模型的响应越可控；你引导得越精细，模型的产出越接近“专业水准”。

而在这背后，prompt 工程已经不再是聊天技巧，而是一种新的“编程语言”——需要反复调试、总结经验、并结合业务上下文去设计。

没有上下文，就没有意义

模型输出的质量，决定性因素并不只是提示词，而是上下文。

我们在测试中习惯从“需求”出发，而模型只能从“你告诉它的内容”出发。也就是说，如果没有足够上下文，它并不知道你想测的是什么、测的范围有多大、风险在哪里。

比如你问：“这段代码有没有问题？”模型只能根据语言规则去分析；但如果你提供“这段代码实现了订单支付的逻辑，要求在用户余额不足时抛出异常并记录日志”，它的回答就会更具针对性。

这就是为什么“垃圾输入，垃圾输出”在 LLM 使用中格外显著。

要让模型在测试中产生实际价值，你需要学会提供“有信息密度”的上下文，比如业务流程描述、已知缺陷背景、测试对象的技术架构，甚至是某个项目的过往 bug 类型。这些都能帮助模型生成更贴合实际的内容。

用好LLM,三者缺一不可。