AI 测试进阶路线：从 pytest 自动化到大模型效果评估-平芜编程栈

“AI 测试”这个词在招聘 JD 和团队技术规划里出现得越来越频繁。它的含义比表面看起来更大：一边是“用 AI 做测试”，也就是让大模型参与用例生成、接口测试、异常分析、脚本维护；另一边是“测 AI 产品”，也就是对对话机器人、知识库问答、智能客服、AI Agent 这类应用做功能验证、效果评估和回归保障。两条路线能力要求不同，学习路径也不同。这篇学习指南先把两条主线拆开，再给出从手工测试、自动化测试到 AI 应用测试的分阶段进阶路线，包含环境准备、pytest 示例、大模型 API 接入、评估指标、平台设计和排查清单。目标是一个有 Python 和接口测试基础的人，能照着文章把 AI 辅助测试跑通，并知道自己下一步该补什么。

1. 先分清 AI 测试的两条主线，否则学习路线会走偏

很多人看到“AI 测试”就以为是要学一堆大模型算法，其实测试工程师真正需要的，是先想清楚自己在解决哪一类问题。

1.1 用 AI 做测试：让大模型变成测试生产的加速器

这是离现有测试同学最近的一条线。思路是用大模型的语言理解、代码生成和归纳能力，去替代测试工作中重复、繁琐、易漏的部分。常见场景包括：

根据接口定义或需求描述自动生成测试用例。
根据页面截图或操作日志生成 UI 自动化脚本。
对模糊输出做语义级断言，而不是死板地比对字符串。
失败日志来了以后，自动给出异常原因和修复建议。
维护大量低质量用例时，用模型做去重、分级和失效分析。

这条线的核心能力不是训练模型，而是提示词工程、输出解析、结果可靠性控制，以及把模型的能力接入现有 pytest、Jenkins、测试平台流程里。

1.2 测 AI 产品：把验证重心从功能逻辑迁移到效果评估

这条线面对的是被测试对象发生了变化。传统测试里，输入一个值，预期结果通常是一个确定的值或状态；但对话机器人、RAG 知识库问答、AI Agent 这类系统，输入同样的问题可能得到不同表述但语义一致的答案。

因此测试重点不再是“答得对不对”，而是：

答案是否可靠、是否忠实于资料原文。
检索是否召回了正确上下文。
多轮对话是否保持角色和记忆一致。
Agent 调用工具、执行多步任务时是否在正确的节点做出正确决策。
面对异常输入、隐私问询、诱导性提问时是否不会越权或泄露敏感信息。

这条线更适合已经有自动化测试经验、愿意接触数据标注和评估体系的工程师。它更接近“质量保障”而不是“脚本开发”。

1.3 两条路线的能力差异与学习优先级

对比维度	用 AI 做测试	测 AI 产品
核心对象	测试脚本、测试流程	AI 应用、模型输出、Agent 行为
关键技能	Python、pytest、提示词工程、API 接入	评估集建设、指标设计、结果分析
主要产出	更高效的自动化测试能力	可量化的质量与效果报告
上手难度	较低，适合先练	较高，建议在第一条线跑通后进入
面试价值	证明能改进团队效率	证明能支撑 AI 产品交付质量

实际团队里，两条线经常同时存在。进阶路线的合理顺序是：先掌握传统自动化测试，再学会用大模型增强测试，然后进入 AI 应用效果评估。不要一上来就埋进算法细节。

2. 从手工到自动化的地基，先确认自己站在第几层

AI 测试不是空中楼阁。无论是用 AI 做测试还是测 AI 产品，前提都是有一层可靠的自动化测试基建。连普通接口断言都写不稳，接再好的模型也是放大混乱。

2.1 能力分层模型

可以把测试能力分成四层：

第一层，手工测试：能设计测试场景、理解业务、写用例、执行并判断结果。这一层决定你的业务敏感度。第二层，自动化测试：能写接口测试、UI 自动化、能接入 CI、会排查脚本失败。这一层决定你的工程化能力。第三层，AI 辅助测试：能用大模型生成用例、增强断言、分析失败日志，同时能控制模型输出的不确定性。第四层，AI 应用测试：能建设评估集、制定指标、验证 RAG 与 Agent 系统质量，并搭建一套可持续回归的效果评估体系。

前两层不牢，后两层学起来会非常吃力。建议按顺序补，不要跳级。

2.2 学习环境准备

本地学习环境不需要很高配置。一个常见组合是：

依赖	推荐要求	说明
操作系统	Windows 10/11、macOS、Linux 均可	命令示例按 Linux/macOS 风格给出
Python	3.10 或 3.11	大模型 SDK 对较新版本支持更稳定
pip	最新版	安装第三方库
代码编辑器	VS Code 或 PyCharm	提示词调试需要看响应体
Git	建议安装	脚本和评估集要纳入版本管理
Docker	建议装	统一依赖环境，避免版本污染

创建虚拟环境并安装基础依赖：

mkdir ai-testing-guide cd ai-testing-guide python -m venv venv source venv/bin/activate pip install --upgrade pip pip install pytest requests

这里的关键是先用虚拟环境隔离依赖。AI 测试项目里经常要同时安装 HTTP 客户端、测试框架、模型 SDK 和数据处理库，直接装在全局环境里，大概率会在某个版本升级后互相影响。

如果原始学习材料没有给出明确版本，落地前要先确认当前 Python 和 pytest 版本，再安装对应依赖。建议把依赖记录到文件：

pytest>=7.4 requests>=2.31 openai>=1.0 python-dotenv

再生成锁定文件：

pip freeze > requirements.lock

2.3 最小可用的 pytest 骨架

用 pytest 作为整个学习路线的底座，因为它简洁、生态成熟，也最容易接后续的大模型断言。

# test_example.py import pytest def add(a, b): return a + b def test_add_success(): assert add(2, 3) == 5 def test_add_fail(): assert add(2, 3) != 6

运行：

pytest -v

预期输出中会看到每个用例的执行结果。这个骨架修炼的是“用例编写、断言、失败定位”的基础能力。后续所有 AI 能力都挂在这一层上，脚本写得越清爽，接入大模型时越不容易乱。

3. 实战：用大模型 API 增强测试脚本

跑通普通 pytest 之后，可以开始做第一个 AI 测试练习：让大模型参与测试用例生成和断言判断。

3.1 大模型在测试中的典型用途

比较适合立刻落地的有三个方向：

第一，用例生成。把接口文档、需求描述或历史缺陷描述给模型，让它输出测试点列表或测试代码。适合作为初稿，再由人来审核和补充边界场景。

第二，语义断言。对问答系统、文案生成、多语言翻译这类输出，用模型判断结果是否符合预期语义，而不是精确匹配字符串。

第三，日志分析。出现失败时，把错误日志和上下文喂给模型，让它给出可能原因和检查建议。

在真实项目里，这三个方向可以拆成独立的服务或脚本。刚开始不要做“一口气全自动化”的平台，先从单个脚本验证效果。

3.2 AI 辅助生成测试用例的示例

下面是一个通过请求大模型接口生成测试用例的演示。实际项目务必替换为自己的 API 地址、密钥和模型名称。

# llm_client.py import os import requests def call_llm(prompt: str, temperature: float = 0.0) -> str: url = os.getenv("LLM_API_URL") api_key = os.getenv("LLM_API_KEY") model = os.getenv("LLM_MODEL", "default-model") resp = requests.post( url, json={ "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": temperature, }, headers={"Authorization": f"Bearer {api_key}"}, timeout=30, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

提示词是决定输出质量的关键。一个可复用的模板思路是：给角色、给输入、给格式、给示例。

# generate_cases.py from llm_client import call_llm API_DESC = """ 接口：POST /api/v1/order 参数： - userId: 字符串，必填 - productId: 字符串，必填 - quantity: 整数，1 到 99 - couponId: 字符串，选填 """ PROMPT = f""" 你是一名测试工程师。根据下面的接口描述，生成 8 条测试用例。 要求： 1. 覆盖正常流程、边界值、必填校验、非法参数。 2. 每条用例输出为 JSON 数组，元素包含 case_name、params 和 expected_status。 3. 不要输出 JSON 以外的解释。 接口描述： {API_DESC} """ if __name__ == "__main__": result = call_llm(PROMPT) print(result)

模型输出的 JSON 不一定每次都能直接解析，所以要把解析、重试和人工确认做成固定流程：

import json from llm_client import call_llm raw = call_llm(PROMPT) try: cases = json.loads(raw) except json.JSONDecodeError: # 给一次重试机会，仍失败则抛出，便于人工介入 raw = call_llm(PROMPT + "\n只输出合法 JSON，不要包含 markdown 代码块。") cases = json.loads(raw) for case in cases: print(case["case_name"], case["params"], case["expected_status"])

这里要解释一个容易误解的点：模型生成的用例价值在于“发现测试视角”，而不是“替代测试判断”。它可能漏掉业务规则里隐含的状态约束，所以所有生成结果都要经过评审再进入自动化集。

3.3 AI 断言与规则断言的取舍

判断方式	适合场景	风险	使用建议
规则断言	状态码、字段类型、枚举值、金额、时间格式	对语义无法判断	能用规则就用规则
AI 断言	文案语义、客服回复、摘要质量、翻译一致性	输出不稳定、成本高	用于无法规则化的场景
混合断言	先规则过滤，再 AI 复核	链路复杂	生产环境推荐方式

判断顺序建议是：先做规则断言，确定状态码、字段存在性、类型、关键枚举；再做 AI 断言，处理语义是否一致。不要把状态码这种高确定性判断交给大模型，否则每次执行都付出模型调用成本，还引入误判概率。

一个混合断言示例：

import requests from llm_client import call_llm def test_chatbot_reply_semantic(): question = "公司年假从哪天开始算？" answer = requests.post( "http://127.0.0.1:8080/ask", json={"question": question}, timeout=10, ).json()["answer"] # 规则层：答案不能为空 assert answer and len(answer.strip()) > 0 # AI 层：判断是否回答了年假起始时间 prompt = f"""请判断下面的回答是否回答了“公司年假从哪天开始算”这一问题。 如果回答中包含了具体日期或规则说明，输出 PASS；否则输出 FAIL。只输出 PASS 或 FAIL。 回答：{answer} """ verdict = call_llm(prompt, temperature=0.0) assert "PASS" in verdict.upper()

这个模式的价值在于：当系统输出变化了风格但语义正确时，不会像传统断言那样误报失败；但代价是每次执行都要等模型返回，所以只建议在关键场景使用，并控制用例规模。

4. 进阶：测 AI 应用不只是验证功能，还要做效果评估

当团队开始交付大模型产品或功能时，测试的重心会明显变化。单靠“能跑通”已经不够，客户可能更关心回答质量、检索准确率和是否胡说八道。

4.1 LLM 应用测试难点在哪里

传统接口测试的核心假设是“输入确定、输出确定”。LLM 应用打破了这一假设，带来三个直接挑战：

第一，结果不确定性。相同输入在不同时间可能得到不同回答，无法直接把公司数据库里的精确值拿来比。第二，评估标准模糊。什么样的回答算“正确”取决于业务定义，企业知识库问答和营销文案生成的标准完全不同。第三，测试空间爆炸。提示词、知识库、模型版本、温度参数、多轮上下文组合起来，用例数量远超手工维护范围。

所以测试策略要从“验证正确性”变成“评估质量并守住最低标准”。

4.2 效果评估指标体系与评估集建设

以下指标是搭建评估体系时最常见的一组：

指标	含义	计算或判断方式	适合场景
准确率 Accuracy	正确回答占全部样本比例	人工或模型标注后统计	分类、抽取、标准问答
召回率 Recall	应命中的信息命中多少	判断检索结果是否包含关注点	知识库检索
忠实度 Faithfulness	回答是否忠于资料	判断回答内容是否有原文依据	RAG 问答
相关性 Relevance	回答与问题相关程度	打分或模型判定	对话、问答
平均分 Mean Score	专家或模型评分均值	1 分到 5 分	内容生成质量

评估集是这套体系的地基。建设时要遵守几个原则：

覆盖业务高频问题、边界输入、对抗输入和典型故障样本。
每条样本都要有标准答案或评分标准，不能只有输入没有预期。
评估集与开发用的样例集隔离，避免模型在训练或调优时“见到答案”。
版本化管理评估集，因为模型版本更新后需要做同样的回归对比。

一个最小评估集结构可以这样组织：

[ { "id": "case_001", "question": "报销超过多少钱需要走二级审批？", "ground_truth": "超过 5000 元需要走二级审批", "expected_doc": "documents/finance_approval.md" } ]

4.3 RAG 应用测试的检查点

RAG（检索增强生成）是当前企业 AI 应用最常见的技术形态。测试时要分成两段看：检索段和生成段。

检索段要验证：

查询改写是否正确，尤其是模糊问法、错别字、同义词。
Top N 结果里是否包含正确资料。
多轮对话中追问时，检索条件是否正确继承上下文。

生成段要验证：

回答是否引用了检索到的内容，还是模型凭训练记忆自由发挥。
如果资料中没有答案，系统是明确拒绝，还是强行编造。
引用来源编号是否与真实文档对应。
有没有把不同文档的信息错误拼接成新结论。

这部分的回归流程可以做成：跑一组固定评估集，记录检索命中率和回答忠实度，每次模型或知识库更新后对比分数。分数下降就说明改动有质量风险，需要回滚或调整。

4.4 AI Agent 行为测试的核心关注点

AI Agent 比单轮问答复杂，因为它有工具调用、多步计划和状态记忆。测试重点包括：

工具调用是否正确：传入参数是否合法、选择工具是否合理。
多步计划是否收敛：在有限步骤内完成任务，而不是长时间循环。
错误恢复能力：工具返回异常后，Agent 是否会重新规划或请求澄清。
权限边界：是否会在对话诱导下调用未授权操作。

一个基础的 Agent 测试用例可以这样抽象：

def test_agent_tool_parameter_valid(): result = run_agent("帮我查一下订单 2024001 的物流状态") assert result["tool"] == "query_logistics" assert result["tool_params"]["order_id"] == "2024001"

这类断言关注“决策是否正确”，而不是最终话术。相比文本断言，它更稳定，也更容易定位问题出在规划层还是执行层。

5. AI 自动化测试平台的模块设计与技术选型

当脚本数量多了、评估集大了，自然会走向平台化。很多团队想直接搭“AI 自动化测试平台”，但失败往往不是因为代码写不出来，而是没想清楚平台要解决什么核心问题。

5.1 平台需要哪几个核心模块

一个可用的 AI 测试平台至少包含六块：

模块	职责	关键设计点
用例管理	存储和版本化管理测试用例、测试步骤	支持标签、责任人、关联需求
执行引擎	跑 pytest、UI 脚本、评估脚本	支持并发、超时、重试
AI 评估服务	调用大模型做语义判断、打分	温度参数、结构化输出、结果缓存
评估集管理	存放问题、标准答案、参考文档	支持版本和导流隔离
报告中心	展示测试结果、指标变化趋势	对比不同模型、不同知识库版本
调度中心	触发回归、接入 CI/CD	支持定时任务和消息队列

平台的核心不是“把 AI 包装得越玄越好”，而是要把评估结果沉淀下来，让每次改动都能量化对比。

5.2 技术选型建议

以下选型只作为常见实践参考，落地前要根据团队现有技术栈调整：

模块	可选技术	选择理由
后端	Spring Boot 或 FastAPI	团队熟练度优先
前端	Vue3 或 React	不需要特殊能力，看团队情况
测试执行	pytest + pytest-xdist	主流、生态丰富
数据存储	MySQL + 对象存储	元数据和测试报告分层
缓存	Redis	缓存模型判断结果，降低成本
消息队列	RabbitMQ 或 Kafka	异步执行大规模评估任务
模型调用	OpenAI 兼容 HTTP 接口	方便替换不同模型

架构上建议把“执行测试”和“调用大模型评估”拆成两个服务。这样评估服务的限流、超时、重试策略可以单独维护，不会拖垮测试执行。

5.3 落地时最容易失败的三个环节

第一，平台先于评估体系。没有稳定的评估集和指标，就急着搭平台，最后平台上只有执行记录，没有质量结论。正确顺序是先有评估集和指标，再上平台。

第二，忽略模型输出格式的脆弱性。直接把模型返回文本当标记位用，一旦模型加了说明文字就全报错。正确做法是要求 JSON 结构化输出，并写一层解析容错。

第三，把所有断言都换成 AI。AI 判断不是免费的，成本和误判率都会被放大。能用规则断言的地方坚决用规则。

6. 常见坑与排查路径

AI 测试项目踩坑概率最高的几个点，基本都集中在不确定性、依赖和数据上。

6.1 大模型输出不稳定导致用例误报

现象：同一个用例这次跑通过，下次跑失败，断言结果飘忽不定。

可能原因：模型温度设置过高；提示词里没有明确输出格式；系统回答本身有随机性；解析逻辑对模型返回格式假设过严格。

处理方式：

把 temperature 设为 0，降低采样随机性。
明确要求只输出 PASS 或 FAIL，或输出 JSON。
对解析失败做一次“修正提示词重试”。
允许在判定时保留模糊匹配，比如包含关键字即通过，但要在报告里标出。

排查顺序是：先确认当前大模型响应内容，再确认解析逻辑，最后才考虑改提示词。

6.2 依赖版本不一致导致脚本不可复现

现象：本机能跑，CI 上跑不了；或者换台机器就报 SDK 兼容错误。

可能原因：依赖没有锁定版本；Python 版本不同；没有用虚拟环境。

处理方式：使用 requirements.lock 或 Poetry 锁定版本；用 Docker 统一镜像；CI 里先执行版本校验。

python --version pip show pytest pip check

这三条命令可以快速定位大部分环境不一致问题。

6.3 评估集存在数据污染

现象：模型更新后所有指标突然大幅上升，但上线后线上效果并没有变好。

可能原因：训练或调试时把评估集里的问题喂给了模型；评估集长期不更新，模型在 benchmark 上过拟合；评估样本太少，波动被放大。

处理方式：评估集与调优集物理隔离；定期补充新样本；记录每次评估的样本数量和版本；分数异常变化时要人工抽检原始回答。

6.4 并发执行触发限流和超时

现象：大批量评估任务同时跑，模型接口频繁报 429 或超时。

可能原因：没有控速；没有超时；没有重试；评估任务一次性堆积。

处理方式：

增加限流模块，按 token 或请求数控制速率。
requests 设置 timeout，超时后重试 2 到 3 次。
评估结果缓存，同样的问题不重复调用模型。
大批量任务走消息队列异步执行。

6.5 快速排查链路表

问题现象	常见原因	检查命令或位置	处理建议
用例结果随机波动	模型温度过高或提示词不严格	打印模型原始响应	调温度为 0，固定输出格式
启动即报 Import 错误	依赖版本冲突或环境混乱	pip check	重建 venv，使用锁定文件
平台显示通过但线上变差	评估集数据污染	检查评估集与调优集是否隔离	重新划分评估集并人工抽检
模型接口一直超时	限流、网络或负载问题	查看响应状态码和耗时	加超时、重试、缓存、队列
用 AI 断言后用例变慢	每条用例都调模型	统计执行耗时	先规则过滤，再 AI 复核

排查的逻辑顺序是：输入是否正确，环境是否一致，配置是否生效，模型响应是否符合预期，最后才是流程设计问题。

7. 可直接照做的进阶路线和练习清单

把前面内容压缩成一条可执行路线，建议按三个阶段推进。每个阶段都不要追求多，而要把最小闭环跑完。

7.1 阶段一：补齐基础能力

目标是把传统自动化测试练到稳定水平。

练习项：

Python 基础：列表推导、字典、文件读写、异常处理、包管理。
pytest：fixture、参数化、断言、失败截图、生成报告。
接口测试：requests 发送 GET/POST、鉴权、签名、超时处理。
UI 自动化：Playwright 或 Selenium 至少掌握一种。
工程能力：Git 分支、Docker 镜像、Jenkins 定时任务。

这个阶段的输出物是一个能在本地和 CI 都跑通的接口自动化项目。

7.2 阶段二：完成 AI 辅助测试小项目

目标是把大模型接入测试流程，并控制结果可靠性。

建议任务：

写一个 llm_client，封装模型调用、超时、重试。
根据接口文档生成测试用例，并实现 JSON 解析。
对问答系统做混合断言，规则层加 AI 层。
记录每次模型判断结果，统计 AI 断言与人工结论的一致率。

这个阶段的输出物是一个“接口文档入、可执行用例出、结果带 AI 判断”的脚本项目。不要急着做平台。

7.3 阶段三：建立 AI 应用评估体系

目标是从“能不能跑”进阶到“质量好不好”。