摘要：07 说过 TestStar 是「平台不是工具」——那平台里到底有什么？这篇不做功能列表，跟一条用例走完整个产品：从测试经理打开 TestStar 写第一条用例，到发版前凌晨自动跑、早上拿到报告、决定能不能发版，每一步对应什么功能、解决什么具体问题、配什么微例子。最后给一份能力清单，方便按图索骥。
本篇是 TestStar AI 测试实战 #9。 平台视角，见 实战 #7 · AI UI 演示能过，为什么不能每天自动跑？； 怎么用起来，见 实战 #8 · 功能用例接入 TestStar； 这篇回答剩下的问题：平台里有什么，每个能力解决什么。
写在前面
07 说 TestStar 是「平台」——坐落在视觉 AI 执行层之上，管「跑、钱、稳、失败谁跟」。但这篇不重复那个结论。换一个角度：跟一条用例从「写」到「治」走一遍。
走完一遍你会发现，平台里的能力不是按技术分类堆的，而是按用例生命周期排的——
| 写 | 用例从哪来、怎么写得稳 | 模板导入、意图驱动、关键元素 + 知识库 |
| 跑 | 多端怎么跑、Token 怎么不爆 | 多端复用、定时任务、Token 治理、实时日志 |
| 报 | 红了怎么办、哪些能救 | 失败分类、自愈、分段断言 |
| 治 | 报告给谁看、能不能发版 | 缺陷流转、兜底规则、发版判定 |
每个功能配一段微例子——具体场景，具体怎么用。别到这一步才发现「原来能做这个」。
下面那条 19 步 SQL 控制台用例和 07 同一根线，跟着它走完。
一、写：把用例写到稳
测试经理打开 TestStar，第一件事不是写用例，是把存量接进来。再之后才是写新用例。这一段三个能力，让「写」这件事不靠灵光一现。
1. 模板导入 + 外部用例树转换
是什么：把测试管理平台（TestRail / 禅道 / 自研）里的功能用例、需求文档里的验收点，按一定规则批量导入成 TestStar 可执行的 AI 步骤。导入完成后保留树形结构和原 ID，追溯链不断。
解决什么：从零写 200 条 AI 步骤不现实。导入让团队站在已有用例资产上起步，不用推倒重来。08 那篇讲的功能用例接入，前置条件就是这一项。 
微例子：禅道里 200 条功能用例，导出 Excel，按「步骤 / 预期」两列识别；导入 TestStar 后 195 条识别正确，5 条步骤歧义的标黄让测试经理手动确认——15 分钟 vs 从零写 5 天。 
2. 意图驱动步骤在这里插入图片描述
是什么：步骤写「做什么」不写「怎么点」。在「订单管理」页筛选状态为已取消的订单 是意图；点击 #filter-cancel 是定位。意图驱动让步骤 改版后还能对上，因为它锚的不是 DOM 节点，是业务语义。
解决什么：脚本维护债的本质——产品一句话改版，脚本全红。意图驱动是 实战 #5 · 页面知识库 的步骤层基础。
微例子：某次改版，把「订单管理」改成了「订单中心」，筛选按钮从右上挪到了顶部 Tab。脚本时代全部失败，AI 步骤因为只写了「筛选状态为已取消」意图，9 条用例 8 条自愈、1 条人工调。
3. 关键元素 + 页面知识库
是什么：每个 AI 步骤配一行「关键元素」——告诉模型在哪里找该元素。关键元素登记进页面知识库以后，全员复用，改版时一处更新全场生效。
解决什么：单纯写意图，模型不知道「这个元素具体长什么样」。关键元素给模型一个语义稳定的定位字典：不靠 ID、不靠文案，靠位置 + 类型（「订单管理页 → 筛选区 → 状态多选 → 取消选项」）。改版后 ID 变了、文案变了，字典里的语义还能匹配。
微例子：银行 App 的「转账确认」按钮，每季度换一次图标和文案。知识库里登记「底部主操作区，确认语义按钮」，三次改版 AI 没动用例；只把样式变了的关键元素更新一次到知识库。 
图注：用例生命周期四段 · 写 / 跑 / 报 / 治，每段对应一组能力
二、跑：让每天凌晨能跑得动
用例写好了，挂在定时任务上，每天凌晨自己跑。这一段四个能力，让「跑」这件事多端、便宜、可控。
4. 多端步骤复用
是什么：同一套业务步骤，Web / Android / iOS / 鸿蒙都跑。TestStar 在底层做端映射——一个步骤在 Web 是点按钮，在 Android 是 Tap 控件，在 iOS 是 Accessibility 操作，业务步骤只写一次。
解决什么：Appium 三端各写一套、元素定位各不相同——维护债翻三倍。多端复用是 实战 #6 的核心收益，团队存量里 App 用例占比高的，从这里切入性价比最高。
微例子：信贷审批流程「客户经理提交额度调整 → 风控审核 → 客户签字」」，以前 Web + Android + iOS 三端共 9 条用例、3 套步骤。接入后3 条用例共用 1 套业务步骤，维护工作量降到 1/3。
5. Token 治理（冷热缓存 + 账单）
是什么：AI 步骤的 token 消耗，按冷启动 / 热缓存 / 知识库命中分档；每条用例跑完都有详细账单——哪一步花了多少、命中率多少、能压到哪里。
解决什么：AI UI 最常见的成本失控——50 条用例定时任务一天烧掉几千块，对完账不知道钱花在哪。Token 治理不是「少花钱」，是看清钱花在哪、压到该压的地方。详细账本见 实战 #4 · Token 治理。
微例子：07 那条 19 步用例，冷启动 ~48 万 token，开热缓存后 ~5.4 万，命中知识库后再压到 ~5.7 万。账单精确到每步——7 步是 Token 大头，因为它们打了 N 次重试。
6. 定时任务 + 单条调试 + 批量执行 + 实时日志
是什么：单条用例在编辑器里随时跑一遍看效果；选定一组批量跑；接定时任务（cron）每天凌晨自动触发；执行中进控制台看实时日志、截图、模型判断。
解决什么：演示和生产的差距就在这里。演示是一个人盯着一台电脑跑，生产是无人盯。TestStar 把演示的调试体验搬到生产侧——出问题时，回放看到底是哪一步错、模型看到了什么、为什么点了这里。
微例子：凌晨 3 点的定时任务里某条用例失败，早上值班打开日志看——第 12 步模型把「确认」按钮识别成了「取消」，附有截图 + 模型思考过程。10 分钟定位问题、归类「步骤歧义」、回 Step 2 调写法。在这里插入图片描述
7. 控制台实时日志
是什么：执行过程中每一步的状态、截图、token 消耗、模型思考、断言结果实时展示。不只是跑完看报告，跑的过程也能看。
解决什么：报告是事后视角，问题是当时发生的。实时日志让调试时间从半小时压到 10 分钟。
三、报：让红的那条有人跟
报告发出来那一刻，问题从模型层转到团队层。这一段三个能力，让「红」可分类、可救、可解释。
8. 失败分类
是什么：每一条红色都打一个标签——真失败 / 步骤歧义 / 偶发误点 / 环境问题 / 数据问题，分类分类是 TestStar 的标配，每条红单都自动归类，分类准确率随时间提升。
解决什么：报告里 30 个红没人敢看——因为你分不清哪个该修、哪个该重跑、哪个该改步骤。失败分类是报告可读的前置条件，见 实战 #3 · 自愈层。
微例子：50 条用例凌晨跑了 38 个红，自动分类——8 个真失败、18 个步骤歧义、7 个偶发误点、5 个环境问题。测试经理 30 分钟内处理完，每一类走不同处置流——真失败建缺陷、步骤歧义回 Step 2、偶发误点重跑、环境问题查基础设施。
9. 自愈（该救的救，不该救的不救）
是什么：步骤歧义类失败，TestStar 自动尝试三种救法——重跑一次、换关键元素定位、回退到知识库的旧版定位——救回的标记为绿色，不救的才走人工。
解决什么：脚本时代的「改版即全红」，在 AI 时代不应该重演。自愈不是无脑重试，是带分类的重试：环境问题不重试（重试还是错的）、步骤歧义重试（界面加载慢或模型偶发）、真失败不重试（修了才能过）。自愈救回率约 60%，不该救的从不强行救（07 那篇有数据）。
微例子：银行 App 改版那 8 条红色——5 条被自愈救回（重跑 + 换定位）、2 条步骤歧义回 Step 2 调写法、1 条真失败转缺陷。
10. 接口 / UI 分段断言
是什么：一条用例的断言，按本质分给不同执行者。数据正确性走接口 / DB（毫秒级、精确、可复现），视觉一致性和业务语义走 AI（慢、带概率、抖）。UI 执行 + 接口断言混着用。
解决什么：把所有断言都让 AI 看屏，单条用例慢 3-5 倍、报表不可复现。分段断言是 08 那篇的核心动作之一——见「Step 3 预期拆分」。
微例子：转账用例的「余额是否减少 1000」原本让 AI 看屏，跑 18 秒、有时结论抖；拆分后调 /api/account/balance 接口断言，毫秒级、永远精确，单条用例时长从 18 秒降回 5 秒。
四、治：让报告发出去有结论
报告不是终点，是治理的起点。这一段三个能力，让报告有人看、能流转、敢判定。
11. 缺陷流转
是什么：失败分类里真失败类的，自动建工单（对接 Jira / 飞书项目 / 自研平台），带上下文——截图、模型思考、重跑记录、复现步骤。不是 AI 自动建缺陷，是 AI 把现场还原清楚、人类决定是不是缺陷。
解决什么：AI 报红没人修——因为「现场」只有模型看过。缺陷流转把「现场」打包成工单，开发 / 测试拿到不需要再问「怎么复现」。
微例子：自动建的缺陷单附 4 张关键截图 + 「第 12 步模型识别错误 + 元素定位上下文 + 截图坐标」，开发 5 分钟复现、修复时间从平均 2 天压到 4 小时。
12. 兜底规则 + 通知 + 发版判定
是什么：三条写下来的兜底规则，跑在平台上自动生效：
解决什么：假绿的本质是概率——模型对断言判断有概率，假绿是「哪天发生」不是「会不会发生」。兜底规则 + 发版判定，让整套自动化敢被信。
微例子：上周某次发版，凌晨报告 32 条全绿；早上 9 点报告里一条关键路径用了双跑规则，接口断言失败，整体判失败，发版自动暂停。开发查下来是支付通道的环境问题，没发上去。
五、能力清单：一张表带走
按用例生命周期分四组，方便按问题查功能：
写到一半
| 模板 + 需求文档导入 / 用例树转换 | 从存量起步，不从零写 | #8 功能用例接入 |
| 意图驱动步骤 | 改版后步骤仍能对上 | #5 页面知识库 |
| 关键元素 + 页面知识库 | 定位字典，复用 + 自愈 | #5 页面知识库 |
跑的那一刻
| 多端步骤复用 | 三端一套业务步骤 | #6 多端测试 |
| Token 治理（冷热缓存 + 账单） | 看清钱花在哪 | #4 Token 治理 |
| 定时任务 + 单条调试 + 批量 | 演示体验搬进生产 | #7 平台视角 |
| 控制台实时日志 | 跑的过程也能看 | — |
跑完的报告
| 失败分类 | 红单可读 | #3 自愈层 |
| 自愈（按分类重试） | 不该救的不强行救 | #3 自愈层 |
| 接口 / UI 分段断言 | 数据精确、视觉语义可扛 | #8 Step 3 |
报告发出去之后
| 缺陷流转 | 现场打包成工单 | #3 自愈层 |
| 兜底规则 + 通知 | 假绿有人兜 | #8 Step 6 |
| 发版判定 | 自动化敢被信 | #7 平台视角 |
图注：12 项能力 × 用例生命周期 · 一图带走
六、几个常见疑问
Q1：TestStar 自研浏览器吗？
不。07 说过了——TestStar 不自研浏览器、不训模型，接执行层。在上面做的是平台，管跑、钱、稳、失败谁跟。
Q2：所有功能都要用吗？
不必。接入门槛只需要「写 + 跑」两组——意图驱动 + 多端复用，跑得起来就入门了。Token 治理、失败分类、自愈、分段断言都是规模化时再补的能力。一次性上 12 项反而会因为配套不齐互相打架。
Q3：开源吗？
不。07 那篇明说过了——了解靠演示，不靠扫仓库。这篇不展开。
Q4：演示和生产的差距具体在哪？
演示看「能不能点对」，生产看「红了谁修、错了能不能拦、钱花得清不清楚、失败能不能复现」。这四件事每一件都对应 12 项能力里的具体一项。
七、几句能记住的
留言：你团队目前最卡的是哪一段——写不动、跑不动、报告没人看、还是不敢拿结果决策？下一篇按读者占比最多的场景展开。
写在最后
- AI UI 测试从 Demo 到生产：一个常被忽略的架构层
- AI UI 测试火，不代表你也该上——先答这 4 题
- 番外 2 · 行业受众地图：哪些行业真愿意掏钱
- TestStar AI 测试实战 5：页面知识库
- TestStar AI 测试实战 6：多端 UI 测试怎么少维护
- TestStar AI 测试实战 7：AI UI 演示能过，为什么不能每天自动跑？
- TestStar AI 测试实战 8：功能用例接入 TestStar
关注作者，后续继续写自愈边界、产品边界等实战篇。
