大模型调用量暴涨1000倍！你的测试用例，还在靠“手工搬运”吗？

关注 霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集

上周五下午四点，我正在改一个没什么人看的内部文档，突然被拉进一个紧急群聊。群里测试组的老K连发三条语音，语气像丢了孩子：“完了完了，大模型接口调用量上周冲到日均500万了，我们那200条手工用例还在SVN里躺着，一条条复制粘贴到Postman跑，已经连续加了三天班了。”

我盯着屏幕愣了两秒。不是因为500万，而是因为“200条手工用例”和“SVN”这两个词同时出现在2024年的聊天记录里。

问题到底卡在哪
先别急着说“我们也这样”。看一下实际场景就明白了。

大模型应用的测试，跟传统后端接口测试有个本质区别：输出不确定，但行为必须稳定。

你用Postman调一次/chat接口，输入“介绍一下北京”，大模型返回一段描述天安门的文字。你把这段文字复制到Excel里，打了个√。第二天同样的请求，它可能先说烤鸭，再说故宫——内容变了，但功能没错。你的“断言”怎么写？直接比较字符串？显然不行。

所以很多团队的“测试用例”根本不是自动化脚本，而是一堆手动执行的“对话模板+人工肉眼判断”。每换一个模型版本，就把这堆模板从头到尾点一遍，看回答“大差不差”就放过。

这种模式在每天几百次调用时勉强能忍。但当公司做了个Agent应用爆了，日调用量从5000飙升到500万，问题就炸了：

模型一周迭代两次，每次回归要人工看300条对话
线上出现badcase，无法快速转化为自动化用例
新来的实习生花了两周才学会“怎么正确地点开那200个模板”
我们踩过的坑
我所在的小组去年也遇到这个坎。当时我做的是一个RAG问答系统，调用量三个月涨了80倍。测试组三个人，每天的工作就是打开一个内部聊天页面，对着一个预置的问题列表逐条提问，然后凭经验判断答案质量。

有个问题我记得很清楚：“公司年会的报销流程是什么？”——答案是固定的，因为知识库里就那一份文档。但模型有时会自己发挥，把去年的流程也扯进来。我们用最笨的办法：把标准答案的关键词写在旁边，肉眼核对。

直到某天线上被用户投诉，说答案里出现了“根据2022年通知”，而那个通知已经作废了。测试组复查后发现，那条用例他们跑过，但当时“看着差不多就过了”。

就是因为这个事，我们才开始认真改流程。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

解决方案：从搬运工到自动化
废话不多说，直接上我们现在的做法。不是最优解，但亲测能把测试效率从“3人日”变成“5分钟”。

第一步：用例结构化存储
别再往Excel里写中文了。用一个JSONL文件存用例，每行一个：

{"id": "case_001", "query": "公司请假流程是什么？", "expect": {"keywords": ["审批", "HR系统", "3天以上"]}, "type": "keyword"}
{"id": "case_002", "query": "帮我写一封申请报销的邮件", "expect": {"contains": ["报销", "附件", "财务部"]}, "type": "keyword"}
{"id": "case_003", "query": "昨天上海的温度", "expect": {"logic": "should_be_number_range", "min": -10, "max": 45}, "type": "range"}
关键点：断言规则要和数据在一起。每条用例知道自己是校验关键词还是数值范围，还是更复杂的语义相似度。

第二步：写一个测试执行器
别再用Postman了。一个简单的Python脚本就能搞定：

import json
import requests
from sentence_transformers import SentenceTransformer, util

加载用例

with open('test_cases.jsonl', 'r') as f:
cases = [json.loads(line) for line in f]

初始化语义模型（用于模糊断言）

sim_model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')

def run_test(case):
resp = requests.post('https://your-llm-endpoint/chat', json={'prompt': case['query']})
answer = resp.json()['answer']

if case['type'] == 'keyword':
for kw in case['expect']['keywords']:
assert kw in answer, f"缺失关键词: {kw}"

elif case['type'] == 'range':
# 提取数字（简化版）
numbers = [int(s) for s in answer.split() if s.isdigit()]
assert numbers, "没有找到数字"
assert case['expect']['min'] <= numbers[0] <= case['expect']['max']

elif case['type'] == 'similarity':
# 语义相似度断言
sim = util.pytorch_cos_sim(sim_model.encode(case['expect']['ref_answer']),
sim_model.encode(answer))
assert sim > case['expect']['threshold'], f"语义相似度太低: {sim}"

print(f"✓ {case['id']} 通过")

for case in cases:
run_test(case)
这个脚本跑一遍200条用例，加上网络耗时，大概40秒。关键是——完全自动化，任何人一键运行。

第三步：接入CI，每次模型更新自动回归
把上面那个脚本扔进GitHub Actions或者Jenkins，设置触发条件：每次模型服务有新镜像推送到registry，自动跑全量测试用例，结果发到钉钉/飞书群。

我们现在的流程是：

算法组发版新模型
CI触发，跑1500条用例（积累到现在）
5分钟后群里收到报告：“通过1487条，失败13条，详情见附件”
算法组开始查为什么那13条变了
整个过程不需要测试组任何人动手。测试组现在的精力放在两件事上：补充用例（把线上badcase转成用例），以及调整断言阈值（因为模型变强了，旧的关键词匹配可能过于严格）。

一些具体的技巧
技巧1：用“影子模式”生成用例

线上真实请求是宝藏。我们写了一个服务，随机采样5%的真实用户对话，连同模型当时的回答一起保存下来。然后人工审核这些对话，挑出其中“答案明显正确”的，直接转成测试用例。三个月攒了800多条高质量用例，人工成本远低于自己编。

技巧2：断言要分层

硬性规则（必须包含某些关键词、不能出现敏感词）——用规则断言
软性质量（答案是否相关、是否完整）——用语义相似度，但阈值不要设太高，0.7左右就够
事实准确性（比如日期、数字）——用正则提取+逻辑判断，不要依赖语义
技巧3：容忍模型的“合理变化”

一条用例失败了，先别急着改代码。我们遇到过一个case：问“公司几点上班”，旧模型回答“9点”，新模型回答“上午9:00（弹性工作制，最晚10点）”。关键词匹配会失败，但事实上新答案更好。这时候不是修bug，而是升级断言规则。

效果怎么样
我们这套东西跑了半年，测试组从3个人缩减到1.5个人（那0.5是兼着做别的），回归测试时间从6小时变成5分钟。更重要的是，线上投诉率下降了70%——因为每次模型更新前，那些“看着差不多”的边界问题都会被自动化用例挡下来。

所以回到标题：调用量暴涨1000倍不是问题，问题是你的测试手段还停留在手工搬运时代。别等线上出大事了才想起来改。

哦对了，那个发语音的老K，现在每天准时六点下班。前两天还发朋友圈晒新买的Switch卡带。

推荐学习
基于知识图谱的测试用例生成方法， 利用知识图谱生成更全面更精准的测试用例。扫码进群，报名学习。

关于我们
霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。