“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 风格给出Python3.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 版本再安装对应依赖。建议把依赖记录到文件pytest7.4 requests2.31 openai1.0 python-dotenv再生成锁定文件pip freeze requirements.lock2.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: fBearer {api_key}}, timeout30, ) 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}, timeout10, ).json()[answer] # 规则层答案不能为空 assert answer and len(answer.strip()) 0 # AI 层判断是否回答了年假起始时间 prompt f请判断下面的回答是否回答了“公司年假从哪天开始算”这一问题。 如果回答中包含了具体日期或规则说明输出 PASS否则输出 FAIL。只输出 PASS 或 FAIL。 回答{answer} verdict call_llm(prompt, temperature0.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 基础列表推导、字典、文件读写、异常处理、包管理。pytestfixture、参数化、断言、失败截图、生成报告。接口测试requests 发送 GET/POST、鉴权、签名、超时处理。UI 自动化Playwright 或 Selenium 至少掌握一种。工程能力Git 分支、Docker 镜像、Jenkins 定时任务。这个阶段的输出物是一个能在本地和 CI 都跑通的接口自动化项目。7.2 阶段二完成 AI 辅助测试小项目目标是把大模型接入测试流程并控制结果可靠性。建议任务写一个 llm_client封装模型调用、超时、重试。根据接口文档生成测试用例并实现 JSON 解析。对问答系统做混合断言规则层加 AI 层。记录每次模型判断结果统计 AI 断言与人工结论的一致率。这个阶段的输出物是一个“接口文档入、可执行用例出、结果带 AI 判断”的脚本项目。不要急着做平台。7.3 阶段三建立 AI 应用评估体系目标是从“能不能跑”进阶到“质量好不好”。建议任务整理 100 条业务问答样本建评估集。定义准确率、召回率、忠实度、相关性指标。写一个评估脚本跑完自动生成指标报告。对比两个模型版本或两版知识库的分数差异。如果负责 Agent 项目把工具调用参数校验也放进回归用例。这个阶段的输出物是一份可复现的评估报告团队成员只要执行一条命令就能看到质量变化。7.4 学习自检清单检查项完成标准pytest 基础能写 fixture 和参数化用例接口自动化能独立跑通一个带鉴权的接口项目大模型 API 接入能用脚本调用并解析结构输出提示词规范输出格式可预期失败有重试混合断言规则断言优先AI 断言兜底评估集有隔离版本含标准答案指标报表每次评估能产生可对比的分数平台落地评估集先于平台模块边界清晰最后强调一个判断AI 测试真正难的不是让大模型替你做所有事情而是你能把“什么该交给 AI、什么不该交给 AI、结果如何验证”设计清楚。对新手最有价值的练习不是追着新模型工具跑而是把一个联合 Inventory 接口测试脚本从普通断言改造成混合断言再把评估过程沉淀为可重复运行的脚本。这条路跑通之后无论是转“用 AI 做测试”还是深入“测 AI 产品”你都已经有了明确的能力抓手。 
长河君 · 2026/9/7 16:43:13 · 阅读 1.2k 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 风格给出Python3.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 版本再安装对应依赖。建议把依赖记录到文件pytest7.4 requests2.31 openai1.0 python-dotenv再生成锁定文件pip freeze requirements.lock2.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: fBearer {api_key}}, timeout30, ) 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}, timeout10, ).json()[answer] # 规则层答案不能为空 assert answer and len(answer.strip()) 0 # AI 层判断是否回答了年假起始时间 prompt f请判断下面的回答是否回答了“公司年假从哪天开始算”这一问题。 如果回答中包含了具体日期或规则说明输出 PASS否则输出 FAIL。只输出 PASS 或 FAIL。 回答{answer} verdict call_llm(prompt, temperature0.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 基础列表推导、字典、文件读写、异常处理、包管理。pytestfixture、参数化、断言、失败截图、生成报告。接口测试requests 发送 GET/POST、鉴权、签名、超时处理。UI 自动化Playwright 或 Selenium 至少掌握一种。工程能力Git 分支、Docker 镜像、Jenkins 定时任务。这个阶段的输出物是一个能在本地和 CI 都跑通的接口自动化项目。7.2 阶段二完成 AI 辅助测试小项目目标是把大模型接入测试流程并控制结果可靠性。建议任务写一个 llm_client封装模型调用、超时、重试。根据接口文档生成测试用例并实现 JSON 解析。对问答系统做混合断言规则层加 AI 层。记录每次模型判断结果统计 AI 断言与人工结论的一致率。这个阶段的输出物是一个“接口文档入、可执行用例出、结果带 AI 判断”的脚本项目。不要急着做平台。7.3 阶段三建立 AI 应用评估体系目标是从“能不能跑”进阶到“质量好不好”。建议任务整理 100 条业务问答样本建评估集。定义准确率、召回率、忠实度、相关性指标。写一个评估脚本跑完自动生成指标报告。对比两个模型版本或两版知识库的分数差异。如果负责 Agent 项目把工具调用参数校验也放进回归用例。这个阶段的输出物是一份可复现的评估报告团队成员只要执行一条命令就能看到质量变化。7.4 学习自检清单检查项完成标准pytest 基础能写 fixture 和参数化用例接口自动化能独立跑通一个带鉴权的接口项目大模型 API 接入能用脚本调用并解析结构输出提示词规范输出格式可预期失败有重试混合断言规则断言优先AI 断言兜底评估集有隔离版本含标准答案指标报表每次评估能产生可对比的分数平台落地评估集先于平台模块边界清晰最后强调一个判断AI 测试真正难的不是让大模型替你做所有事情而是你能把“什么该交给 AI、什么不该交给 AI、结果如何验证”设计清楚。对新手最有价值的练习不是追着新模型工具跑而是把一个联合 Inventory 接口测试脚本从普通断言改造成混合断言再把评估过程沉淀为可重复运行的脚本。这条路跑通之后无论是转“用 AI 做测试”还是深入“测 AI 产品”你都已经有了明确的能力抓手。