ai自动化测试技术原理与平台搭建

测试团队想用大模型做用例生成、失败归因或元素定位，真正卡住的通常不是原理，而是跑起来之后的那些脏活：请求超时怎么设、并发一高就限流、模型挂了怎么降级、跑完一轮怎么判断比手工强。这篇按搭建顺序把关键环节和判断标准列一遍，具体数字都去站内对应页面核对。

测试团队想用大模型做用例生成、失败归因或元素定位，真正卡住的通常不是原理，而是跑起来之后的那些脏活：请求超时怎么设、并发一高就限流、模型挂了怎么降级、跑完一轮怎么判断比手工强。这篇按搭建顺序把关键环节和判断标准列一遍，具体数字都去站内对应页面核对。

先说明一个前提：下面讲的是自建平台的工程路径，不是选型结论。如果你团队只有一两个人、被测系统还很不稳定，先把执行层跑通再考虑接模型，否则你会在调提示词和查环境问题之间来回消耗。

先分清 AI 在测试链路里到底站哪一环

模型能干的其实就四件事：生成用例草稿、解释失败日志、推断元素定位、补全断言。它不负责执行，也不负责最终判定通过与否。执行层仍然是脚本驱动加断言库加报告器，AI 只插在「写之前」和「挂之后」两个位置。把这条想清楚，后面所有接口设计都不会跑偏。

• 强依赖精确数值校验的场景：比如账务对账、金额结算，用规则脚本更稳，模型算不准
• 合规审计要求每一步可复现的场景：模型输出带随机性，很难逐次复现同一份结果
• 被测系统界面仍在频繁大改的场景：定位推断刚调好就失效，维护成本反而更高
• 需要长期无人值守跑批的场景：建议先让 AI 只出草稿，人工审完再进主用例库

平台骨架：一次请求从发起到入库要经过什么

一次调用走四段链路：取上下文、调模型、结构化产出、落库并关联版本。其中最容易被低估的是取上下文这一步，很多团队一上来就把整个用例库拼进提示词，结果又慢又不准，还会把无关信息带进结果里。正确做法是先检索再拼接，分层组织上下文。

产出必须强制结构化，不然下游没法自动入库。字段至少要包含用例标题、前置条件、步骤、预期结果和置信度标记。每次调用同时把输入指纹、模型标识、耗时、token 用量落一条记录，后面对账和复现都靠它。这块和站内讲 Agent 调 API 的工程做法是同一套思路，可以对照看。

稳定性工程：超时、并发、降级三件事的先后顺序

顺序建议是先定超时，再压并发，最后做降级。反过来做会出现降级逻辑没机会触发的情况。超时要分层设：连接超时、读取超时、整体超时各一档，别只配一个全局值，否则长文本生成会被误杀，短请求又会拖很久。具体分档数值可以按站内讲超时配置那篇的思路套用到你的场景。

1. 第一层：连接超时只覆盖建连阶段，设短一些；验证方式是本地断网或指向不可达地址，看是否按预期快速失败
2. 第二层：读取超时覆盖模型返回过程，按你的最长输出长度估一个大致的上限；验证方式是故意让模型输出长内容，看是否被提前切断
3. 第三层：整体超时包住重试在内的总时长；验证方式是把上游依赖拖慢，看整条链路是否在预期时间内退出
4. 批次并发先小批次跑，观察限流报错再往上加；遇到限流用指数退避加排队，不要靠立即重试硬顶
5. 降级开关主模型不可用切备用源，备用源也没有就退回规则模板出草稿，并在结果上明确标注本轮是降级产出

还有一条容易被忽略：每条链路都要有幂等设计。重投或超时重试不能重复写库，最好用输入指纹做唯一约束。否则你会看到同一批用例在库里出现多份，评测时的覆盖率数字就全乱了。

日志与评测：怎么判断这套东西真的有用

日志至少记六个字段：请求指纹、模型标识、prompt 版本、耗时、token 用量、结果状态。缺任何一个，后面想复盘「到底是慢还是贵」都无从下手。prompt 版本尤其重要，它决定了你改了提示词之后还能不能把两批结果分开对比。

• 人工采信率：生成的草稿有多少条被人直接采纳或小改后采纳，这是最贴近价值的一项
• 用例覆盖率增量：同一需求下，AI 辅助后多覆盖了哪些之前漏掉的场景分支
• 单条可用用例成本：把调用花费摊到被采纳的用例上，比看总花费更有意义
• 回归一致性：同一批样本重复跑，结果波动太大会让上面三项都不可信

改提示词之后必须跑回归：固定一批用例反复跑，看人工采信率和覆盖率有没有变化，而不是凭感觉说变好了。评测集要冻结版本，换模型或改提示词都在同一批样本上比。样本量不够的时候，结论只能当参考，不要拿它去说服别人。具体每个环节的观测口径和当时的样本规模，可以到 /tools/speed-test速度与稳定性检测 这类工具页配合着看。