> 专栏第 1 篇。没有命令。先把立场说清楚，后面每一篇 Skill 才不会被学成孤立的脚本生成器。  
---

周一的站会常常是这样：研发说模型已经把这个迭代的接口和页面都改完了，昨晚还用编程智能体搭了一条新的智能体流程，下午试用，方向不对今晚就删。测试打开三处——禅道里一份上季度的用例，仓库里一批去年还能跑的脚本，平台上一个名叫「全量回归」的任务。三处对不上。页面上一个按钮换了位置，脚本红一片。有人提议再招两个人，把回归加满。

加人能多排两轮手工。它赶不上两件已经发生的事：AI 编程把变更压进一天，智能体按天生成、按天扔掉。测试还按「每个项目配几个人跟着点、跟着改脚本」在排。两条曲线不在一个数量级上。

所以这个专栏先把测试收成一条链路，再谈生成脚本。同一次变更的用例、脚本、任务和报告落在同一处，用 AI 在当天发现问题、当天把该测的跑完。每一步只做一件事，做完才知道下一步缺什么。

## AI 编程现在有多快

一个会用编程智能体的研发，同一天里可以让模型读仓库、改接口、改页面、补上调用，本地跑起来，再把几个小改动一起合进去。过去要排进一个迭代的重构——目录重铺、交互换皮、接口成批生成——现在常常压进一周，赶的时候压进一两天。变更的单位从「这个版本」变成「今天合进去的那一批」。

| 你听到的 | 测试当天要面对的量 |
|----------|-------------------|
| 先让模型出一版，能跑再说 | 接口和页面可以在同一天一起改完 |
| 今天合并了十几个小改动 | 按「全部再点一遍」排，当天排不完 |
| 需求就是聊天记录和一版演示 | 等文档齐了再写用例，这批改动已经又变了 |
| 再开一个编程智能体并行改 | 人还在看上一处 diff，下一处已经合进来了 |

单个稳定产品上，测试部按项目排人仍然成立。多仓库并行、模型在写代码、方向说扔就扔，这三件事叠在一起时，按项目加人的产能跟不上变更。要补上的是一条默认会在当天发生的闭环。

## 智能体正在按天扔掉

日抛是现在很多智能体产品的节奏：一条工作流、一个工具页、一套提示词和工具调用，上午生成，下午给几个人试用，方向不对，第二天目录就删了。文档来不及写，测试部的迭代日历还停在上周。

试用当天，创建、回车、权限、工具有没有调对，这些问题已经发生在用的人身上。两周后的全量回归排上时，这个智能体可能已经不在仓库里。留下的如果只有一份还没排期的计划，这一天等于没有测过。

测试要跟日抛发生在同一天。这次变更写进用例；该自动化的，当天生成脚本并跑；跑红了，当天分清是脚本坏了，还是产品坏了。产品坏了就留下 bug。方向如果明天扔掉，留下的是这一天的证据。

有的智能体明天就会删，不必为它建一套长期回归。那种变更在用例上标成不自动化，写完即停。值得留下的，才进入脚本和任务。这个判断要在当天做出。排期若还停在上周，方向已经扔了。

## 测试用 AI 加快发现，也加快把测试跑完

编程侧已经在用模型写代码。测试侧用同一类能力做两件赶时间的事。

**快速发现问题。** 对着这次 diff、页面和接口，让模型先把行为写成用例，再生成脚本跑一遍。失败当天分类。路径、字段、定位或断言写错，改已经生成的测试脚本再跑。断言和约定一致、实现不对，当场记成 bug，留在这次结果里。合入当天就能看见这个问题。

**快速测试。** 一次变更按用例决定测接口、测一种界面，或两边都测。界面按 surface 只走桌面 Web、App、PC、小程序里的一种。H5 会停并点名自己的命令，不用 Web 脚本去包。脚本齐了就在本地跑完，拿到报告。全量「再点一遍」留到发版再看。日抛的智能体等不到那一轮。

规格先写在 OpenSpec 里。`proposal.md`、`design.md`、`specs/`、`tasks.md` 定下这次做什么，Skill 再按这份规格去建工作区、写用例、生成脚本。同一份 Skill 可以放进 Claw，也可以放进其它能调用 Skill 的工具。换工具不改步骤。

快要有落点。模型一个下午可以写出一仓库互相指不上的文件，发现得快，散得也快。链路把速度关在固定次序里：先用例，再脚本；红了只改测试脚本；产品问题留下来；任务只跑已经生成的脚本。AI 用在发现和执行上，用例、脚本、报告仍能在目录里指认。

## 维护税从半天变成一周

测试同学对「脚本会坏」并不陌生。以前研发改一个控件、挪一条路由、换一处文案，定位器红一片，平台上的任务要重跑，还要花时间分清：是产品变了，还是脚本脆。线性脚本扛过这笔税，自动化平台也扛过。平台把「在本地改脚本」换成「在平台上改用例，再等执行队列」，税还在，只是换了地方交。

模型写码之后，一周里可以做完过去要排一个迭代的重构：目录重铺、交互换皮、接口成批生成。专人跟着修脚本、跟着改平台用例，队列会堵住。研发要么干等，要么绕开。把自愈放进链路，是承认脚本会坏，并且规定坏了之后谁可以改哪一类文件、改到什么程度必须停。接口脚本在生成执行里最多修 3 轮。已经红了的桌面 Web 脚本走 `/autotest-ui-heal`，只改 `autotest/ui/tests/` 里已有的文件。产品行为不对的时候，结果里留下失败，断言保持原样。

| 变更体量 | 靠人跟着改的下场 |
|----------|------------------|
| 局部控件、局部文案 | 花半天能改完，团队还扛得住 |
| 一周内大面积重构 | 专人改脚本和平台用例跟不上，门禁会被绕开 |

## 三笔账

周报里往往同时有三句话：回归越来越贵；流水线是绿的，线上仍能炸出本该拦住的洞；缺陷单关了，下个迭代还在同一处摔。这是三本不同的账。

| 账 | 你以为买到了 | 实际常买到 |
|----|--------------|------------|
| 时间账 | 更多回归轮次 | 夜间全量、白天排队。跑得更长，仍说不清这次变更该测哪一层 |
| 信任账 | 更多绿勾 | 绿说明这批脚本这次跑过了。它不说明该有的脚本已经齐，也不说明产品行为是对的 |
| 记忆账 | 更多已关闭的缺陷单 | 单子会关。用例和脚本如果没有同一条补上的出口，下次还在原处摔 |

再招两个人把回归加满，时间账可以暂时多跑几轮，人还是跟着改，长期更贵。信任账几乎不动：绿勾变多，齐套和真实缺陷仍写在同一列里。记忆账几乎不动：缺陷关了，用例和脚本仍散在三处。

智能测试先改这三本账的记法。执行机器可以再换一台，记法不变，三笔账还是原来的三笔。

记法换成这样：

- **时间。** 一次变更先按 PR 或规格写用例，再决定写接口、写桌面 Web、两边都写，或这次不自动化。不把「全部再点一遍」当成唯一安排。
- **信任。** 能不能进入下一步，看范围内脚本齐不齐。通过率留给发版。生成和自愈过程里发现的真实问题留在结果里。
- **记忆。** 用例、脚本、任务、报告都落在仓库的 `autotest/` 里。补一次测试，能指着目录说清补的是哪一层。

## 只再生成一堆脚本，链路还是断的

自动化擅长把已经写好的步骤重复跑。模型也很会在一次对话里写出很多文件。文件多，仍然回答不了这几句：

1. 工作区在不在，前后端路径还指不指得对。
2. 用例写在本地。本课程不把用例交到外部系统。
3. 这条用例要测接口、测桌面 Web、两边都测，还是这次不需要自动化。
4. 红了是脚本写错，还是产品行为不对。写错可以改已经生成的测试脚本。产品错了就记下来，停止把这条改绿。
5. 范围内该有的脚本齐了没有。齐了，才把它们收成一条任务。
6. 跑任务的时候只跑、只记、只出一份报告。修脚本是另一站的事。

这六句没有固定顺序时，脚本越多，越不知道哪一份算数。生成得快，散得也快。先收成链路，就是让这六句按固定次序发生，每一步做完留下能指认的文件，下一步只看上一步缺了什么。

顺序就这一条：

```
没有目录就先建
路径旧了只刷新路径
本地用例
按用例写接口脚本，或写桌面 Web 脚本
已有 Web 脚本红了，走 `/autotest-ui-heal`
该有的脚本齐了，覆盖率才算到
编成一组，跑出一份报告
跑完可以再看四项度量，度量不改「能不能挂任务」
```

这次不需要自动化的用例，写完就停。查外部任务、建外部任务不在本课程，不发起请求。

## 谁来跑，谁来维护

| | 负责 | 做到什么程度 |
|--|------|----------------|
| 研发 | 按命令完成这次变更的用例、脚本、任务和执行 | 点名哪条命令，就只做那一件事。缺哪一层，就补哪一层 |
| 测开 | 把「怎样算走对了」收成 Skill、门禁和边界 | 维护命令，使每层的判定稳定。不替每个仓库把页面点一遍 |

测试执行由研发在命令里完成。测开维护的是方法：什么时候该停，什么文件允许改，什么数字不能拿来挡下一步。

功能测试还在。有的变更要人看产品、做探索，判断结果是「这次不自动化」，链路就在用例处结束。大模型测评、智能体测评、性能专项仍要专人做，它们不在这条链路里。这条链路解决的是：交付所需的那一层测试执行，有一条可以重复走的路。

## 读完应能说清的四句

1. AI 编程把变更压进一天，智能体按天生成、按天扔掉。测试用 AI 在同一天发现问题、把该测的跑完。按项目加人、靠专人跟着改脚本，时间账、信任账、记忆账会一起变贵。
2. 脚本要落在固定目录里，并且先有用例，再决定写接口，还是写桌面 Web。
3. 研发自己发命令。测开维护命令、门禁和边界。
4. 能不能进入下一步，看该有的脚本齐不齐。真实 bug 留在结果里。通过率是发版要看的数字。

## 对着自己的项目答三句

1. 若老板说「再招两个测试，把回归加满」：时间账能多跑几轮，信任账和记忆账几乎不动。你用哪一句向非技术的老板解释「不够用」指的是产能模型，不是某个人不够勤快？
2. 你们最近一次补测试，用例和脚本是先后出现的，还是脚本先出现、用例事后补？
3. 脚本红了，断言和约定一致、产品行为不对时，你们会改断言换一个绿勾，还是把 bug 留在结果里？

周一的站会常常是这样：研发说模型已经把这个迭代的接口和页面都改完了，昨晚还用编程智能体搭了一条新的智能体流程，下午试用，方向不对今晚就删。测试打开三处——禅道里一份上季度的用例，仓库里一批去年还能跑的脚本，平台上一个名叫「全量回归」的任务。三处对不上。页面上一个按钮换了位置，脚本红一片。有人提议再招两个人，把回归加满。

为什么要先把测试收成一条链路

测试

职业发展

新闻资讯

AI编程将变更压缩至一天，智能体按天生成与废弃。测试需在同一天发现问题并完成验证。传统按项目加人、专人改脚本的模式难以应对，应构建固定链路：先用例，再脚本，脚本红仅修测试，产品问题留证。此方法优化时间、信任与记忆三笔账，脚本落于固定目录，研发发命令，测开维护边界。

代码解释

智能体

AI编程

路由

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

为什么要先把测试收成一条链路-腾讯云开发者社区-腾讯云

为什么要先把测试收成一条链路

为什么要先把测试收成一条链路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐