聊《测试转大模型一次新的项目切入》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。 摘要从传统软件测试转向 LLM 应用质量保障最大的障碍不是工具链而是思维模式的切换。本文通过一次真实的权限与日志需求评审拆解大模型应用在“Demo 到生产”阶段的边界、取舍与验收标准分享 Agent 测试框架搭建与质量评估的实战经验。最近行业里有个明显的趋势大模型应用正在从 PPT 和 Demo 阶段迅速向生产环境迁移。随之而来的焦虑也转移到了质量和工程化上。以前我们测的是确定性逻辑现在我们要测的是概率性输出、复杂的权限控制以及难以捉摸的日志链路。作为一名在测试领域摸爬滚打多年的老兵我亲历了从 Selenium 到 Appium再到如今面对 LangChain、LlamaIndex 甚至各种 Agent 框架的转型阵痛。很多人问我“测试转大模型到底该学什么”我的回答通常很直接别急着背 Prompt 技巧先学会怎么定义“不确定性”的质量标准。目录从一次需求评审说起边界在哪里AI 辅助测试与自动化用例生成Agent 测试框架的搭建质量评估从“对错”到“好坏”总结测试工程师的独特优势从一次需求评审说起边界在哪里上周参与了一个内部知识库 Agent 的需求评审。产品经理兴致勃勃地展示了 RAG检索增强生成的效果引用准确率看着不错。但在讨论“上线标准”时我注意到了两个被忽略的关键点权限隔离和溯源日志。在传统 Web 测试中权限通常由 RBAC基于角色的访问控制硬编码处理用例好写结果好判断。但在大模型场景中权限是动态的。用户问“上季度财务数据”Agent 需要根据当前用户的 Role ID 去向量数据库检索时进行过滤。如果过滤逻辑失效敏感数据就会泄露。更头疼的是可观测性。当用户反馈“答案不对”或“幻觉严重”时传统日志只能告诉你 API 请求了什么。但我们需要知道1. 检索到了哪些文档片段2. Prompt 是如何组装的3. 模型输出的置信度是多少4. 是否有越权操作这次评审让我意识到测试工程师的价值不再仅仅是找 Bug而是定义系统的边界和可观测性指标。如果你不能在需求阶段把这些非功能性需求转化为可测试的条目后续的开发和测试都会陷入混乱。AI 辅助测试与自动化用例生成既然提到了自动化很多同行第一时间想到的是用 AI 生成测试用例。这确实是个切入点但容易走入误区直接用 LLM 生成断言往往导致用例过于宽泛缺乏针对性。我的做法是用 AI 生成探索性测试的场景人工编写具体的断言逻辑。例如针对上述的知识库 Agent我不会让 AI 直接写“测试权限”。我会让它生成一系列边缘场景用户 A 属于部门 X但尝试访问部门 Y 的文档。用户询问了已删除的文档。并发请求下缓存与实时数据的冲突。然后我利用 Python 脚本结合pytest来执行这些场景。对于大模型的输出传统的assert response expected已经失效我们需要引入语义相似度比较。import pytest from semantic_similarity import cosine_similarity # 假设使用类似库 from openai import OpenAI client OpenAI() def test_permission_boundary(user_role, query, expected_access_level): 测试权限边界确保 Agent 不会返回用户无权访问的信息 response call_agent_api(roleuser_role, promptquery) # 1. 基础格式检查 assert response.status_code 200 # 2. 语义安全检查检测是否包含敏感词或越权信息 sensitive_keywords [confidential, salary, internal_id] content_lower response.text.lower() is_leakage any(kw in content_lower for kw in sensitive_keywords) if expected_access_level deny: # 如果预期拒绝但内容中包含了敏感信息则测试失败 assert not is_leakage, fPermission leak detected in response: {response.text} # 3. 一致性检查重复查询应得到相似答案排除随机性过大 response_2 call_agent_api(roleuser_role, promptquery) sim_score cosine_similarity(response.text, response_2.text) assert sim_score 0.9, Response inconsistency detected这段代码展示了如何将传统的断言思维转化为适应大模型的测试逻辑语义安全 一致性 格式规范。Agent 测试框架的搭建当测试范围扩大到 Agent 时单体测试就不再够了。Agent 通常涉及多步推理、工具调用和状态管理。这时候你需要一个能够追踪整个交互过程的测试框架。我推荐使用基于 LangSmith 或自定义的 Trace 记录器。关键在于每一个 Step检索、思考、调用工具、生成回答都应该是可观测的。在搭建框架时我有三个取舍1. 不要追求 100% 的自动化覆盖率大模型的输出空间太大试图覆盖所有分支是不现实的。重点应放在核心流程和高风险路径。2. 黄金数据集Golden Dataset至关重要建立一套固定的输入输出对用于回归测试。每次模型版本更新或 Prompt 调整都要跑这套数据集观察指标变化。3. 区分“功能性测试”与“质量性测试”功能性测试看 Agent 是否调用了正确的工具质量性测试看 Agent 的回答是否准确、安全、符合语气。质量评估从“对错”到“好坏”这是测试工程师转型中最难的一课。在大模型时代没有绝对的“错”只有“好”与“更好”。我通常采用三层评估体系1. 自动化评分LLM-as-a-Judge利用另一个强大的模型如 GPT-4o 或 Claude 3.5 Sonnet作为裁判根据预定义的 Rubric评分标准对 Agent 的回答打分。* 相关性是否回答了用户的问题* 事实性陈述是否基于检索到的文档* 安全性是否包含有害内容2. 人工抽检Human-in-the-loop自动化评分总有偏差尤其是对于主观性强的任务。每周抽取 5%-10% 的复杂案例进行人工评估并校准自动化的评分标准。3. 业务指标关联最终模型的质量要体现在业务上。比如客服 Agent 的转人工率是否降低内部知识库的搜索满意度是否提升实战建议在简历中不要只写“使用了 LLM 进行评估”而要写“构建了包含 500 条黄金用例的评估流水线将模型幻觉率从 15% 降低至 3%并通过人工抽检校准自动化评分模型的准确率至 90%”。总结测试工程师的独特优势回到开头的问题测试转大模型优势在哪里我认为在于对边界的敏感度和对异常情况的穷举能力。开发人员倾向于 Happy Path而测试人员天生关注 Failure Mode。在大模型应用中Failure Mode 往往是隐秘的权限绕过、提示注入、幻觉扩散。不要把自己局限为“找 Bug 的人”要把自己定位为“大模型应用的守门员”。从需求评审开始介入定义清晰的验收标准从自动化脚本入手建立可观测的测试流水线从评估体系入手量化模型的质量。这条路不容易需要补齐编程能力、熟悉 LLM 原理、掌握评估方法。但只要你保持对技术的敬畏和对质量的执着这场跃迁就是你职业生涯最好的增值机会。---本文基于个人实战经验整理旨在提供思路参考。具体技术选型请根据团队实际架构决定。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
