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

测试转大模型：从问题定位到方案成型

news 2026/6/20 19:48:02

聊《测试转大模型：从问题定位到方案成型》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

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

摘要：做了几年测试，突然发现手里那套接口自动化和UI脚本，在面对大模型项目时有点使不上劲。不是技术过时，而是评估对象变了——从“是否返回200”变成了“回复是否有道理”。这篇文章我会从团队落地的实际视角，聊测试人员怎么在模型项目里找到位置，重点说说日志设计、协作方式和可维护性这三个绕不开的坑。

1. 测试岗位的新变化

以前做测试，大部分时间花在写case、跑case、修case上。功能测试关心按钮能不能点，接口测试关心状态码和数据格式。转到大模型项目后，这些东西依然有用，但远远不够。

举个例子：我们团队上个月上线一个客服助手，测试过程中发现同样的问题“订单没收到”，模型有时回复“请提供订单号”，有时回复“您是否使用优惠券”。两个回答从语法上看都没错，但一致性差，用户体验割裂。这种情况传统断言根本抓不住——你不能断言“必须包含订单号”，因为模型根据上下文会变化。

新岗位要求你多理解三件事：

输入的变化：prompt怎么写、上下文多长、有没有示例。
输出的边界：模型可能生成幻觉（编造订单号），也可能拒绝回答。
协作的节奏：算法同学经常改模型参数，测试同学得快速评估影响范围，不能用传统“等开发提测”的方式。

我看到不少测试同事初期很焦虑，觉得模型不透明。其实换个角度想：你之前不也把接口当黑盒测？现在只是黑盒更大、更随机。关键是把评估标准和日志设计先对齐，而不是先追求自动化。

2. AI 辅助测试

别一上来就想让AI自动写case跑case，那容易翻车。我的建议是先用AI辅助测试思维——比如让模型帮你生成数据、补充边界、分析失败原因。

真实场景：我们需要测一个新闻摘要模型，人工想测试数据太累。我就写了个脚本，拿几篇真实文章，让ChatGPT生成不同风格的摘要，然后手工挑出质量低劣的例子作为对抗测试集。这一招比单纯多写case有效得多。

踩坑记录：一开始我让AI直接生成测试断言，结果它经常生成“期望结果：模型应该回答X”。但模型输出是概率性的，根本不能做相等断言。后来改成生成“期望方向：包含关键词、不包含负面情绪”这种软断言，才勉强能用。

团队协作上的建议：AI辅助产出的东西要标准化。我们定了一个规则——所有AI生成的测试用例，前面加一个meta字段记录来源和生成参数：

{ "meta": { "generator": "gpt-4", "prompt_template": "summary_test_v2", "temperature": 0.7, "human_reviewed": true }, "test_case": { "input": "原文...", "expected_behavior": "摘要应保留时间、地点、事件" } }

这样无论是谁生成的，后续维护时都能查到底，避免“AI写的没人敢改”的尴尬。

3. 自动化用例生成

AI辅助最终要走向自动化。我的路径是：从手工转半自动，再过渡到全自动回归。

先看一个简单的自动化生成脚本（适合从prompt出发生成单轮问答测试）：

import openai import json def generate_test_cases(requirement_text, count=5): prompt = f""" 基于以下需求描述，生成{count}条测试用例。 每条用例包含：字段input（用户输入）、expected_focus（预期回答应包含的关键点）。 要求覆盖正常场景、边界场景、异常场景。 需求：{requirement_text} 直接输出JSON数组，不要解释。 """ resp = openai.ChatCompletion.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], temperature=0.6 ) cases = json.loads(resp.choices[0].message.content) # 自动添加生成记录 for c in cases: c["_generated_by"] = "auto_script_v1" c["_source_req"] = requirement_text[:50] return cases

这个脚本我会放在CI/CD里，每次需求文档更新时触发，然后人工抽检。抽检通过后，用例进入正式回归库。

可维护性要注意两点：

模板化：生成prompt里不要硬编码模型名，写成变量。我们踩过亏——模型升级后生成风格变了，不得不重新调参。
日志化：每条用例的生成参数、模型版本、人工审核记录都要落到日志。事后发现问题才能追溯是生成算法错了还是源头需求错了。

我的做法是单独建一个`test_case_generation_log`表，字段包括：时间、requirement_hash、model、temperature、用例id、human_verdict。这样和算法同学扯皮时有据可依。

4. Agent 测试框架

多轮对话、工具调用、记忆管理——Agent测试比单轮复杂得多。团队落地时，如果日志设计不好，测试结果根本没法看。

先说我踩过的坑：最初我们只在assert里打印“passed/failed”，结果模型回复略微偏向但依然正确时，断言失败。后来改成记录完整交互栈，才看清问题。

下面是一个简化的Agent测试日志记录类：

import json import uuid from datetime import datetime class AgentTestLogger: def __init__(self, agent_name, test_id=None): self.agent_name = agent_name self.test_id = test_id or str(uuid.uuid4())[:8] self.session = [] def record_turn(self, user_input, agent_reply, context_before, expected_claim=None, assertion_result=None): entry = { "timestamp": datetime.utcnow().isoformat(), "test_id": self.test_id, "input": user_input, "output": agent_reply, "context_snapshot": context_before, # 对话历史摘要 "expected": expected_claim, "passed": assertion_result } self.session.append(entry) def dump(self, filepath): with open(filepath, "a") as f: f.write(json.dumps(self.session) + "\n")

使用场景：每次调用Agent接口前创建一个logger，多轮对话结束后把session写入JSON Lines文件。日志里加`test_id`是为了关联后续的质量评估。

协作建议：这个文件要统一格式，算法同学可以直接拿去做badcase分析。我们约定用`yyyy-mm-dd_agent-test`的命名规则，每天生成一个。之前有人用Excel，有人用txt，最后汇总时完全没法合并。

可维护性方面：Agent测试用例的配置参数（比如max_turns、memory_size）不要写在代码里。我们改用YAML配置文件，测试脚本只负责执行和记录日志。这样换模型或调参数时，改配置文件就行，不需要动代码。

5. 质量评估

自动化测试只是第一步，质量评估才是产出的价值体现。大模型项目的评估不能只看“正确率”，因为正确率定义本身就很模糊。

我们的做法是建立一个多层次评估体系：

自动层：BLEU、ROUGE、BERTScore等指标，跑完回归自动计算，和基线对比。
半自动层：用规则+模型打分，比如检查回复是否包含禁止词、是否超时。
人工层：每天抽检10%的badcase，由测试人员标注“合理/不合理/无法判断”。

重点说下日志怎么支持评估。在自动回归阶段，每条测试结果会追加一个`quality_metrics`字段：

{ "test_id": "a1b2c3", "input": "退款多久到账", "output": "通常3-5个工作日", "metrics": { "temporal_consistency": 0.82, "hallucination_risk": 0.03, "fluency": 0.95 }, "baseline": { "model": "gpt-3.5-turbo", "date": "2026-06-15" } }

这样如果需要回查某次模型更新导致质量下降，可以直接SQL过滤`hallucination_risk > 0.5`的用例，快速定位。

简历建议：如果你在面试时能说“我设计了一套质量门禁，包含自动指标+人工抽检，并统一了日志格式让算法团队能直接消费”，这比单纯说“我用过BLEU”有说服力得多。