当前位置：首页 > news >正文

测试转大模型：一篇讲清核心用法

news 2026/6/29 8:26:38

这篇不先堆名词。我们把《测试转大模型：一篇讲清核心用法》拆成几级台阶，看完至少知道下一步该学什么、该练什么。

摘要

本文概述文章目标、核心观点和实践价值。

做了五年传统功能测试，最近半年一直在啃 AI 相关的业务。很多同行问我：“现在转大模型测试，是不是得先精通 Python 或者去学深度学习算法？”

我的回答很直接：不用。甚至如果你抱着“我要成为算法工程师”的心态去转，大概率会卡在第一步就放弃。

大模型（LLM）测试的本质，不是去测模型本身的数学精度，而是测应用层的稳定性、幻觉控制以及业务逻辑的正确性。对于测试同学来说，这是一次从“确定性系统”向“概率性系统”思维的跃迁。

这篇文章不谈虚的，只讲我从传统 QA 转型过程中，真正用到的工具链、学习顺序以及那些容易踩的坑。

测试岗位的新变化：从黑盒到“不可知论”

在传统 Web 或 App 测试中，输入 A 必然得到输出 B。但在 LLM 应用中，同样的 Prompt，可能因为 Temperature 参数微调，或者底层模型的版本迭代，得到完全不同的回复。

这种非确定性是测试面临的最大挑战。

我见过不少同事一开始试图用传统的断言（Assert）去校验 LLM 的输出，比如assert response == "Hello"。这在 LLM 场景下几乎必败，因为模型可能会说“你好呀”、“嗨，有什么可以帮你”。

所以，转型的第一步不是学代码，而是改变校验思维：
1.不再追求精确匹配：转向语义相似度（Semantic Similarity）。
2.关注边界与幻觉：测试的重点从“功能对不对”转移到“它会不会胡说八道”以及“在极端输入下是否会崩溃”。

AI 辅助测试：别只把它当聊天机器人

很多测试同学用 AI 是为了写周报或者解释代码，这太浪费了。在质量保障环节，AI 最大的价值在于测试资产的生产。

1. 自动化用例生成

传统自动化测试写用例很痛苦，尤其是面对复杂的业务逻辑。现在，我们可以让 LLM 基于 PRD 或接口文档，批量生成测试场景。

比如，我有一个电商订单模块的需求描述，我可以让 AI 列出所有异常路径：库存不足、支付超时、并发下单等。

# 示例：使用 LangChain 构建一个简单的测试场景生成器 from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate # 初始化模型 llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.7) # 定义提示词模板 prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个资深测试专家。请根据以下需求描述，生成 5 个针对边界条件的测试用例，包括前置条件、操作步骤和预期结果。"), ("human", "需求描述：{requirement}") ]) chain = prompt | llm # 执行生成 response = chain.invoke({"requirement": "用户购买限时折扣商品，库存有限，支持并发抢购"}) print(response.content)

避坑指南：生成的用例一定要人工复核。AI 擅长发散思维，但容易忽略具体的业务规则细节（比如某个特定状态码的处理）。

2. 测试数据构造

造数据一直是测试的痛点，尤其是涉及多表关联、敏感信息脱敏的场景。

与其写繁琐的 SQL 脚本，不如让 AI 根据你的 Schema 生成 Mock 数据。你可以要求它：“生成 10 条符合 JSON Schema 的用户数据，其中 2 条邮箱格式错误，2 条年龄为负数，用于异常测试。”

这样既解决了数据多样性问题，又覆盖了边界情况。

Agent 测试框架：自动化新范式

当测试任务变得复杂，比如需要“登录 -> 搜索商品 -> 加入购物车 -> 提交订单”，传统脚本虽然能做，但维护成本高。

引入Agent（智能体）概念后，我们可以用自然语言描述测试意图，由 Agent 自主规划步骤并执行。目前比较成熟的框架有LangGraph或AutoGen。

以 LangGraph 为例，它可以构建一个有状态的测试循环：

from langgraph.graph import StateGraph, END # 定义状态结构 class TestState(TypedDict): user_action: str current_page: str is_success: bool def login_agent(state: TestState): # 模拟执行登录动作 print(f"Agent logging in with state: {state['user_action']}") return {"current_page": "dashboard", "is_success": True} def verify_order_agent(state: TestState): # 模拟验证订单 if state['current_page'] == 'checkout': return {"is_success": True} return {"is_success": False} # 构建图 workflow = StateGraph(TestState) workflow.add_node("login", login_agent) workflow.add_node("verify", verify_agent) workflow.set_entry_point("login") workflow.add_edge("login", "verify") workflow.add_edge("verify", END) app = workflow.compile()

关键点：Agent 测试的核心优势在于容错性。如果某一步失败（如元素未找到），Agent 可以尝试重试或换个策略，而不是像 Selenium 脚本那样直接报错中断。这对于测试不稳定的 UI 组件特别有效。

质量评估：LLM Evaluation 是必经之路

测试做完，怎么证明质量达标？这里必须引入LLM as a Judge的概念。

我们不能靠眼睛看，需要一套自动化的评估管线（Evaluation Pipeline）。常见的评估维度包括：

正确性（Correctness）：答案是否符合事实？
一致性（Consistency）：多次提问同一问题，回答是否稳定？
安全性（Safety）：是否包含敏感词、偏见或攻击性内容？

我们可以搭建一个简单的评估脚本，利用 GPT-4 作为裁判，去打分其他小模型的输出。

def evaluate_response(reference_answer, model_output): prompt = f""" 参考正确答案：{reference_answer} 模型生成答案：{model_output} 请从 1-5 分对模型答案的质量进行评分，并给出理由。 1分：完全错误 5分：完美匹配且无冗余 """ # 调用评估模型 judge_response = chat_model.invoke(prompt) return parse_score(judge_response)

实战建议：不要一开始就搞复杂的 RAG 评测集。先建立一个小规模的“黄金测试集”（Golden Dataset），包含 50-100 个典型业务场景的标准问答对。每次模型更新或 Prompt 调整后，跑一遍这个集子，看分数波动。

总结：学习路线与心态调整

回顾我的转型路径，建议大家按照以下顺序进阶，不要贪多：

1.阶段一：理解原理。搞懂什么是 Token、Temperature、Context Window。不需要会训练模型，但要懂参数对输出的影响。
2.阶段二：掌握工具链。熟练使用 LangChain 或 LlamaIndex 搭建简单的 QA 应用，学会编写结构化 Prompt。
3.阶段三：构建评估体系。建立自己的 Golden Dataset，实现自动化回归测试。
4.阶段四：深入架构。了解 RAG 的检索增强机制，测试重点从“应用层”下沉到“检索层”的相关性和召回率。

最后一点心态建议：
不要因为不会写复杂的深度学习算法而焦虑。在大模型应用落地的最后一公里，懂业务逻辑、懂用户体验、懂如何系统性地验证不确定性的测试工程师，比只会调参的算法初级工程师更有价值。

保持好奇，多动手折腾几个 Demo，你会发现这条路比想象中要宽广得多。