TestStar | 接入 AIUI 测试 30 天后，我学到的唯一一件事：别拿别人的数算自己的账

u010750578

86人浏览 · 2026-09-09 20:31:32

u010750578 · 2026-09-09 20:31:32 发布

摘要：08 讲了功能用例怎么接，#9 讲了平台里有什么——但读者最关心的是：接进去到底省多少、踩过什么坑、会不会假绿。这篇不给你数字（没有放之四海皆准的真实数据，每个项目都不同），给一套 30 天量账方法：基线怎么采、4 个核心指标怎么定义、4 周数据怎么收、怎么算 ROI、哪些统计陷阱不能踩。最后给采购 / 测试负责人 / 测开三组速读。

本篇是 TestStar AI 测试实战 #10。
怎么接，看实战 #8 · 功能用例接入 TestStar；
平台里有什么，看实战 #9 · 功能巡礼；
这篇回答：接进去之后，怎么量、怎么算、怎么看。

写在前面

前两篇之后被问得最多的是：

“听起来挺好，但 ROI 算不过来——接进去到底能省多少？”

讲道理回答不了这个问题。算账只能拿数据说。

但我没法给你一个"标准答案"。原因很简单——

没有放之四海皆准的真实数据。

每个项目的存量规模、维护债量级、团队人数、发版节奏都不一样。你拿别人的数套自己的项目，要么低估、要么高估，算出来的 ROI 都是错的。

所以这篇不给数字（也不会编），给一套你自己量账的方法——基线怎么采、4 个指标怎么定义、4 周数据怎么收、怎么算、哪些陷阱要避开。拿这套去你自己的项目跑 30 天，拿到的数才是真数。

公开行业数据会引用（World Quality Report 2025、BrowserStack 2026、Tricentis 2026 等），但这是行业趋势锚点，不是你项目的答案。

和番外 2 同一口径：量级 + 趋势比单点数字更可靠，单点数字必须自带前提条件——换团队换业务不成立的情况本文都写明。

一、为什么不能用别人的数字

1.1 项目变量太多

哪怕同一个团队两个项目，30 天账都会差几倍：

变量	量级影响
存量功能用例规模	50 条 vs 500 条，AI 接管范围差 10 倍
维护债量级（脚本月失效率）	10% vs 40%，AI 价值差 4 倍
业务复杂度（多端、强风控、画布占比）	决定哪些用例能接 C 类比例
团队规模	决定人工成本的「分母」——5 人团队和 50 人团队，1 个测试 1 天成本权重不同
月度发版次数	月 1 次的项目接入成本都收不回，月 8 次的项目 3 个月回本

别人告诉你「每月省 56%」——他没说他的存量多大、维护债多高、发版几次。对你来说就是噪音。

1.2 公开行业数据不是项目答案

来源	数字	用途
World Quality Report 2025	约 89% 试点 / 约 15% 规模化	行业趋势锚点，说明「试的人多，做成的人少」
BrowserStack 2026	约 94% 用 / 约 12% 完全自主	同上
Tricentis 2026	64% 金融 / 63% 零售承认未充分测试就发版	说明维护债是普遍现象，不是某团队特例

这些数字能说服老板「这事值得上」，但不能说服老板「你这项目能省多少」——后者要你自己的数。

二、30 天里到底该量什么：4 个核心指标

每条指标都必须有明确的定义 + 量法 + 量几次 + 谁来量。下面给模板。

2.1 指标 ①：回归一轮耗时

定义：从「开始跑测试」到「拿到完整报告」的总时间。

项	怎么记
口径	完整发版回归一轮（不是单条用例）
起点	测试经理拉分支、开始部署测试环境那一刻
终点	报告发出、缺陷流转单创建完那一刻
量几次	接 AI 前量至少 2 次（避免单次波动），接 AI 后量至少 2 次
谁来量	测试经理本人 + 团队一致的口径
易踩的坑	双轨期人工+AI 都跑，总时间不降反升——别用双轨期算账，要用「AI 单跑 + 抽检」稳定后的数据

2.2 指标 ②：单条用例平均时长

定义：单条用例从开始执行到拿到结论的中位数（避免离群值拉偏）。

项	怎么记
口径	中位数（不是平均数）
量几次	每条用例跑 5 遍，取中位
拆分记录	AI 用例要分项记：步骤执行 / 接口断言 / 模型调用 / 收尾
易踩的坑	接口断言藏在 UI 里会让 AI 慢 3-5 倍——单条用例时长明显偏长，先查有没有数据断言没拆出来

2.3 指标 ③：月度 Token 成本

定义：30 条 AI 用例 / 月 × 单条 token 消耗 × 单价。

项	怎么记
口径	全量账单（含重试、含冷启动、含知识库命中后）
不要只记	「冷启动一次多少 token」——那不能算月度成本
量几次	第 1 周全量、第 4 周全量，对比看是涨是跌
易踩的坑	月初冷启动 vs 月中热缓存，差 5-10 倍——记账要分这两档，不混在一起

2.4 指标 ④：假绿率

定义：报告全绿但实际有 bug 上线 = 假绿。

项	怎么记
口径	以「线上发现的 bug」反推——而不是靠自我声明「我们没假绿」
量几次	30 天内发版次数决定——发版 4 次就是 4 个样本
易踩的坑	幸存者偏差——你只看到 AI 管的 30 条没假绿，但 C 类（不接入的）80 条根本不在统计范围内

> **【插图1 · 11-30day-dashboard.png】**

图注：4 个核心指标 · 定义 / 量法 / 陷阱

三、4 周数据收集节奏

30 天不是一次跑完看结果——分 4 周，每周的「该量的数」不同。

第 1 周：基线

目标：把接 AI 前的真实状态量清楚。

量什么	怎么做
回归一轮耗时	完整跑 2 次（最好跨发版周期）
单条用例耗时	抽样 30 条（按维护债高低分层），每条跑 5 遍取中位
月度 Token	现在是 0（还没接 AI），但记录团队的「手工+脚本」耗时作为对比基线
假绿率	翻近 3 个月发版记录，反推漏检的 bug 数

产出物：1 张「基线表」——4 个指标各自的当前值 + 量法说明。这张表就是后面算 ROI 的分母。

第 2 周：双轨期

目标：接 AI 后第一个真实数据点。注意这周不能拿来算账。

量什么	怎么做
回归一轮耗时	这周会变长（人工+AI 都跑）——这周不算进 ROI，只记下来
单条用例耗时	AI vs 人工两条线分别记
失败可分类率	最重要——决定能不能扩量
自愈率	第一次真实数字，可能很低（<10%）正常

核心动作：每周回顾失败分类，至少能归 5 类（真失败/步骤歧义/偶发误点/环境/数据）才能进第 3 周。

第 3 周：扩展期

目标：放量到目标量的 1/3，看数据和流程能不能扛住。

量什么	怎么做
回归一轮耗时	开始有意义地下降
单条用例耗时	拆分接口断言后通常降一半
月度 Token	这周总耗 × 4 = 月度预测（注意冷热比）
假绿率	关键路径强制双跑才开始统计有意义

第 4 周：稳定期

目标：第一个可以算 ROI 的数据点。

量什么	怎么做
回归一轮耗时	拿来算 ROI 的数——和第 1 周基线对比
单条用例耗时	同样对比
月度 Token	同样预测
假绿率	这 4 周样本数够不够做判断

> **【插图2 · 11-week-rhythm.png】**

图注：30 天分 4 周 · 每周的量法不同

四、怎么算账：公式 + 假设

4.1 时间账公式**

月度节省工时 = (基线回归耗时 - 第 4 周回归耗时) × 月度发版次数

注意：
- 不是「单条用例时长 × 用例数 × 发版次数」——单条时长被分母算偏
- 「回归一轮耗时」才是真分母
- 双轨期（第 2 周）不算

算账前 3 个必须明确的假设：

你的月度发版次数——少于 3 次的项目别上，接入成本收不回（详见 #8）；
你的存量用例规模——A 类直迁占比 < 20% 的项目 AI 价值有限（详见 #8）；
你的脚本维护债——月失效率 < 15% 的项目没有维护债可解（见番外 2 行业地图）。

3 个假设任一不满足，ROI 算出来再漂亮都是错的。

4.2 Token 账公式**

月度 Token 成本 = 单条用例 token × AI 用例数 × 月度发版次数

单条用例 token 拆开记：
- 冷启动 token 数
- 热缓存 token 数（一般是冷启动 1/5–1/10）
- 知识库命中后 token 数（再压 1/5–1/3）

算账前必须问厂商 2 个问题：

单价是按输入 + 输出分别算，还是合并？——影响账单 30-50%
重试是否单独计费？——容易藏的一个成本项

4.3 ROI 公式**

月度节省金额 = 月度节省工时 × 测试同学小时成本
ROI = 月度节省金额 / (平台月费 + 接入人力摊销)

注意：
- 「接入人力摊销」按 12 个月分摊，别一次算进 ROI
- ROI < 1 的项目老实承认 ROI 不行，别美化
- 测试负责人的时间也算钱——很多项目算 ROI 时漏了这条

五、几个统计陷阱（不踩）

5.1 双轨期不能算进 ROI

第 2 周「人工+AI 都跑」总耗时增加。这段时间是接入成本，不算省——要算 AI 单独跑（不加人工）稳定后的数。

5.2 C 类不在统计范围

你接入 30 条 AI 用例，剩下 250 条手工或脚本——这 250 条不算 AI 的功劳。口径写清楚，别让老板以为 AI 管了 280 条。

5.3 自愈率 ≠ 救所有失败

自愈 35% 听起来高，但 30 条用例红了 23 条 → 自愈救回 8 条 → 剩下 15 条走人工。讲「自愈率」必须配讲「剩下 65% 去了哪」——否则给老板假象。

5.4 假绿幸存者偏差

30 天 0 假绿是好数字——但要诚实标注：只对 AI 管的 30 条负责，剩下 250 条没在数据内。

5.5 中位数 ≠ 平均数

单条用例时长 1.2 分钟，可能是中位数 1.2（多数用例 1-2 分钟），也可能是平均数 1.2（少数用例 30 秒，多数 8 秒，被 1 个 30 分钟的离群值拉偏）。用中位数，告诉老板。

六、给三类读者的速读

6.1 给采购 / CIO（决策视角）

2 个数字决定 ROI：

数字	含义	怎么估
月度发版 ≥ 3 次	否则接入成本收不回	数近半年发版记录
UI 维护债 ≥ 20%	否则 AI 没有可解的问题	抽样 50 条脚本看失效率

两个数字都满足——再继续。任一不满足，先别上。 这不是工具采购，是流程改造。

6.2 给测试负责人（执行视角）

3 个验收线决定能不能扩量（08 已讲过，重复一下）：

指标	验收线	低于该线的处置
失败可分类率	≥ 90%	失败分类没建好，停放量
假红率	< 5%	步骤歧义多，回 Step 2 改写法
双轨一致率	≥ 95%	预期拆分有问题，回 Step 3

30 天里最值钱的一个动作：强制报告签字。哪怕只是 IM 群回「已审」两个字——这俩字把假绿率从「可能偶尔」压到「几乎不会」。