摘要：测试管理平台里躺着几百条功能用例，写的是「操作步骤 + 预期结果」，靠人执行。想接入 TestStar AI UI，从哪下手？本文给一条完整的接入路径：先按「界面变动频率 × 预期类型 × 覆盖端」把存量用例分三类，再按 7 步走完单条用例的接入（挑试点 → 用例改造 → 预期拆分 → 环境准备 → 双轨验证 → 接定时任务 → 人工执行降频），最后给放量节奏和验收线。配可直接抄走的用例改造对比和预期拆分示例。
本篇是 TestStar AI 测试实战 #8 。该不该上，看 番外1 · 选型四问；
谁更需要，看 番外 2 AI UI 测试：哪些行业真愿意掏钱，哪些只是看看？
这篇回答：已经决定要上，存量功能用例怎么接进来。
写在前面
系列写到这，缺口只剩一个。
番外 1 答了「该不该上」，番外 2 答了「哪些行业真需要」。但两个番外都停在同一个地方：四问过了、行业对上了，然后呢？
大部分团队的现状是：测试管理平台里躺着几百条功能用例------写的是「操作步骤 + 预期结果」，靠人手工执行，发版前回归一轮。这些存量怎么接入 AI UI 测试？
先说一个好消息：功能用例离 AI 执行只差半步。
手工功能用例本来就是自然语言写的------「打开订单管理页，筛选状态为已取消的订单，预期列表只显示已取消订单」。这和 AI UI 步骤的形态天然接近。真正缺的只有两样：步骤里的关键元素 （告诉模型在哪里找）和 预期结果的执行方式拆分（哪些走接口、哪些看屏幕）。
先纠正一个常见误解：接入不是把每条用例都交给 AI 跑。 接入的本质是：对每一条存量用例，重新选择它该怎么执行------交给 AI、预期拆给接口、继续人工，或者借机清掉。
所以这篇的顺序是：先分类（哪些接哪些不接），再讲单条用例怎么接（7 步），最后讲放量节奏和验收线。
不点名公司，数字给量级不给精确值，和前两篇番外同一口径。
一、接入前：先盘点，别动手
把存量功能用例清单导出来，按三个维度过一遍：
| 维度 | 问什么 | 为什么重要 |
|---|---|---|
| 界面变动频率 | 这条用例覆盖的页面，上个季度改了几版？ | 变动高 = 人工回归最痛的地方，AI 价值最大 |
| 预期类型 | 预期主要在验数据，还是验页面表现？ | 验数据的走接口断言，验视觉语义的才给 AI |
| 覆盖端 | Web 为主，还是 Web + Android + iOS 多端？ | 多端同流程是 AI 步骤复用的甜区（实战 #6） |
三个维度过完，存量用例自然分成三类：
| 类别 | 特征 | 处置 |
|---|---|---|
| A · 直接入 | 步骤可描述 + 预期偏页面表现/业务语义 + （最好）多端 | 优先接入，AI 执行 |
| B · 拆分接入 | 预期一半数据一半页面 | 数据预期抽到接口断言，UI 部分给 AI |
| C · 暂不接入 | 含验证码/人脸/画布等反自动化环节；纯数据校验；已过时/重复的用例 | 前两类用别的方式验，第三类借机清理 |
比例上别追求「全接入」。一个典型的存量池里，A 类往往只占两三成------这不是接入失败，是正常形状。C 类里的「纯数据校验」用例，接口毫秒级给出精确答案，让 AI 看屏幕反而又慢又抖；「过时/重复」用例则是很多团队常年不敢清的债，这次盘点顺手清掉，本身就是收益。
图注：功能用例盘点 · 变动频率 × 预期类型 × 覆盖端，分出直接接入 / 拆分接入 / 暂不接入
二、单条用例怎么接：7 步
分类完了，A 类里挑出试点，单条用例的接入按 7 步走。
Step 1 · 挑试点（≤ 5 条）
第一批试点挑的标准，不是「最重要的」，是「最容易判断对错的」：
- 步骤数适中（5--10 步），太短没有接入价值，太长排查困难；
- 页面结构稳定，但文案/布局近一年改过至少两次（证明人工回归的维护痛真实存在）；
- 执行这条用例的测试同学非常熟悉这条业务路径------AI 跑出分歧时，他能一眼判断是 AI 错还是页面错；
- 避开登录/验证码/支付等强风控环节（这类环节用接口或留人工，见第四节）。
Step 2 · 用例改造：补上关键元素
手工用例已经是自然语言，改造只做一件事：给每一步补上关键元素。看一个真实形态的对比：
markdown
【测试管理平台里的原始用例】
1. 打开登录页
2. 输入账号密码
3. 点击登录
4. 预期：登录成功，显示用户名
【逐句照搬（错误做法）】
打开登录页 → 输入账号密码 → 点击登录 → 验证显示用户名
问题：「登录页」「登录按钮」都是文案级锚点，
改版后按钮变成「立即进入」、入口挪到个人中心，整条失败
【TestStar 步骤（推荐写法）】
步骤 1：在「登录页」完成账号登录，账号 test001
关键元素：账号输入框、密码输入框、登录提交按钮
步骤 2：验证登录成功，页面进入工作台并显示当前用户身份
关键元素：顶部导航右侧用户昵称区域推荐写法的要点（和 实战 #5 · 页面知识库 同一套）：
- 每步两行：一行业务意图（做什么），一行关键元素（在哪里）；
- 意图层写「完成账号登录」，不写「点击登录按钮」------改版后按钮文案变成「立即进入」，意图照样能对上；
- 关键元素选该页面上语义稳定的区域（「顶部导航右侧用户昵称区域」比「欢迎文案」活得久）；
- 接一条，顺手把这条的关键元素登记进页面知识库------后面改版自愈、其他用例复用，都靠这份登记。这是接入过程附带的资产，别跳过。
Step 3 · 预期拆分：数据走接口，视觉语义走 AI
把原用例的「预期结果」逐条过一遍，按本质分给不同执行者：
| 预期本质 | 接入后归谁 | 例子 |
|---|---|---|
| 数据正确性 | 接口 / DB 断言 | 登录后用户状态、下单后余额 |
| 页面结构 | 接口可判则接口，否则 AI | 某记录是否出现在列表 |
| 视觉一致性 | AI | 布局没错位、卡片渲染正常 |
| 业务语义 | AI（配合知识库） | 「审批通过」状态标识正确 |
拆分前后对比：
markdown
【拆分前：预期全交给 AI 看屏】
1. 提交转账表单
2. AI 看屏：转账金额是不是 1000？ ← 模型调用，慢
3. AI 看屏：余额是不是少了 1000？ ← 模型调用，且结论可能抖
4. AI 看屏：成功提示出现了吗？ ← 模型调用
【拆分后】
1. 提交转账表单（AI 步骤）
2. 调 /api/account/balance 拿余额
3. 断言：余额 == 转账前余额 - 1000 ← 接口断言，毫秒级、精确
4. AI 看屏：转账成功提示出现 ← 1 次模型调用，只判视觉语义经验值：一条用例的模型调用控制在 2 次以内。拆完超了，说明还有数据预期混在 UI 里。
Step 4 · 环境准备：账号、数据、可复现
AI 执行对环境的要求比人更「较真」：账号要在、数据要在、状态要能回到起点。人工执行时这些靠人随机应变，AI 不会。每条用例接入前确认三件事：
- 专用测试账号，不被其他人改密码、改权限；
- 数据可复现------这条用例依赖的前置数据，怎么造、怎么回滚，写清楚（番外选型四问的第 3 问，落地就在这）；
- 入口稳定------如果用例要从某个入口进，确认这个入口不会今天有明天无。
环境不稳的用例，先修环境再接入。AI 不会让脏环境变干净，只会让脏环境的问题更快暴露------这本身是收益，但会吓到第一次看报告的人。
Step 5 · 双轨验证：AI 执行 vs 人工执行
接入期间原有的人工执行不停。同一条用例，AI 跑一遍、人跑一遍，并行 1--2 周，比对三样东西：
| 比对项 | 看什么 | 不一致的处置 |
|---|---|---|
| 结论一致率 | AI 和人是否同过同败 | 连续一周 ≥ 95% 再谈降频人工 |
| 失败归因 | AI 报失败时，是页面真有问题，还是步骤歧义 | 步骤歧义回 Step 2 调写法 |
| 耗时与调用数 | 单条用例时长、模型调用次数 | 超 2 次调用回 Step 3 重拆 |
双轨期额外产出一份资产：失败分类记录------AI 的每一次失败都归了类（真失败 / 步骤歧义 / 偶发误点 / 环境问题），这份记录比接入本身更值钱，它同时是后续自愈和人工复核的依据。
Step 6 · 接定时任务 + 定兜底规则
双轨验证过了，接入定时任务。这一步的配套（[实战 #3 · 自愈层](#3 · 自愈层 "#") 和实战 #4 的能力在这一步兑现）：
- 定时频率：高变动页面日级，其余周级起步，别一上来全日级烧 Token；
- 失败兜底规则 ，三条写下来贴群里：
- 同一用例连续失败 2 次 → 自动转人工（测试，不是开发）；
- 关键路径 → AI + 接口双跑，任一失败即整体失败；
- 报告发出前 → 值班测试群里回「已审」，没签字不计入通过；
- 报告有人看：第一份自动报告发出来那天，确认至少有一个人从头到尾读完------报告没人看的自动化等于没有。
Step 7 · 人工执行降频
双轨稳定后，这条用例的人工执行从「每次发版全量跑」降下来：
- 降级路径：全量执行 → 抽检（AI 跑完抽 20% 人工复核）→ 只在 AI 失败转人工时介入；
- 人的时间花到哪去：探索性测试、AI 失败复核、用例维护------这三件事才是人工在 AI UI 体系里的位置；
- 用例不删：功能用例在测试管理平台里保留，只是执行方式变了------审计、追溯、新人学习都还靠它。
人工降频是接入的终点，不是开始。没走完双轨就让人放手，等于把回归质量押在没验证过的系统上。
图注：单条用例接入 7 步 · 挑试点 → 用例改造 → 预期拆分 → 环境 → 双轨 → 定时 → 人工降频
三、放量节奏和验收线
单条用例的 7 步走通后，放量按三阶段：
| 阶段 | 存量接入量 | 扩量条件 |
|---|---|---|
| 第 1 阶段 | ≤ 5 条 A 类 | 7 步全部走通，失败分类各类都能覆盖 |
| 第 2 阶段 | ≤ 10 条 | 假红率 < 5%，双轨一致率 ≥ 95% |
| 第 3 阶段起 | 每周 +20 条 | 定时任务稳定、报告签字流程正常 |
每阶段扩量前过一遍验收线：
| 指标 | 建议验收线 | 低于这条线说明 |
|---|---|---|
| 失败可分类率 | ≥ 90% | 失败分类没建好，扩量 = 制造噪音 |
| 假红率 | 稳态 < 5% | 步骤写法有问题，回 Step 2 |
| 双轨结论一致率 | ≥ 95% | 预期拆分有问题，回 Step 3 |
| 单用例模型调用 | ≤ 2 次 | 成本会失控，回 Step 3 |
| 报告签字率 | 100% | 兜底规则没落地，回 Step 6 |
怎么读：验收线是刹车不是 KPI。线破了，先停放量、回对应步骤修，而不是带着问题扩量------带着问题扩的量，最后都要加倍收回来。
四、哪些用例暂不接入
四类边界，提前写清楚，避免「全面 AI 化」的叙事压力绑架接入节奏：
- 强反自动化环节：验证码、滑块、人脸、强风控------AI 步骤跳过这些环节，用接口或人工覆盖；
- 纯画布 / WebGL / 反爬页面：AI 看的是像素，不懂业务，见番外 2 弱需求清单；
- 纯数据校验用例：接口毫秒级精确验证，交给 AI 又慢又抖------这类用例的正确归宿是接口自动化，不是 AI UI；
- 过时 / 重复用例 ：盘点时借机清理，别让它们进接入名单------接入一个死用例，等于给死流程上了永动机。
多端的情况单独说一句：App 端的功能用例接入，优先级反而可以更高------Android / iOS（含鸿蒙）同流程的场景，一份 AI 步骤覆盖多端，是人工多端各跑一遍做不到的复用（实战 #6 的主论点）。如果你存量里 App 用例占比高，从多端共用流程开始接，收益最直接。
五、收束：一页带走
接入前：按「变动频率 × 预期类型 × 覆盖端」分三类------直接接入 / 拆分接入 / 暂不接入，别追求全接入。
单条 7 步：挑试点 → 用例改造（意图 + 关键元素）→ 预期拆分（数据走接口）→ 环境准备 → 双轨验证 → 定时任务 + 兜底规则 → 人工执行降频。
放量：5 / 10 / 20 三阶段，每阶段过验收线再扩。
不接清单：反自动化、画布、纯数据校验、过时用例------提前写下来，挡住「全面 AI 化」的叙事压力。
最后一个提醒 ：接入过程附带产出两份长期资产------页面知识库的元素登记 和 失败分类记录。前者让后面所有用例的维护成本下降，后者让团队的 AI 判断力沉淀下来。就算某条用例最后决定不接，这两份资产也已经落袋。
图注：功能用例接入一页带走 · 分类 → 7 步 → 放量 → 不接清单
写在最后
这篇补上系列的最后一块：存量功能用例怎么接。
- AI UI 测试从 Demo 到生产：一个常被忽略的架构层
- AI UI 测试火，不代表你也该上------先答这 4 题
- AI UI 测试：哪些行业真愿意掏钱，哪些只是看看？
- TestStar AI 测试实战 5：页面知识库
- TestStar AI 测试实战 6：多端 UI 测试怎么少维护
关注作者，后续继续写自愈边界、产品边界等实战篇。
你团队存量功能用例大概多少条、人工回归一轮要多久？欢迎留言------下一篇按评论区最典型的规模，算一笔 AI UI 接入前后的时间账。
版权声明：本文为作者原创，首发 CSDN。转载注明出处。