原文：A New Era for Software Testing — antirez.com/news/168 分析完成时间：2026-06-08
核心观点
Redis 作者 Salvatore Sanfilippo (antirez) 提出了一个简洁有力的论点：AI 写代码存在质量妥协，但在 QA 领域不存在。LLM 不是在替代测试，而是在打开一个全新的质量维度。
AI 编程的诚实评估
antirez 的判断非常精确：AI 生成的代码在结构质量和复杂度控制上比不上顶级工程师手写的代码，但比"还不错的手写代码"要好。
我的感觉是，自动编程在大多数情况下（如果管理得当）超过了"还不错的手写代码"的质量。
My feeling is that automatic programming surpasses most of the times (and if well managed) the quality of decently developed hand-written code.
关键转折：QA 是无妥协区
文章的核心洞察在于区分了两种场景：写新代码时存在质量-时间的 tradeoff，但在 QA 领域，LLM 提供的是一种严格更强大的自动化方式，不需要任何妥协。
某些领域里，LLM 开启了一种严格更强大的流程自动化方式，无需在质量上做任何妥协。软件 QA 和测试就是其中之一。
There are domains where LLMs simply open new strictly more powerful ways to automate processes, without any compromise on quality. One of those domains is software QA and testing.
为什么 QA 是无妥协区？
传统测试有个根本性的盲区：100% 的代码行覆盖不等于 100% 的状态覆盖。单元测试和集成测试只能覆盖可编码的断言，但大量质量判断需要人类的眼睛和判断。这些判断以前只能靠人工 QA，而且大多数时候因为时间不够被跳过了。
方法论详解
antirez 的方法出人意料地简单：一个 Markdown 文件，一份 QA 清单，一个能读 diff 的 AI agent。
三步流程：
- 编写 QA Markdown — 在 Markdown 文件中用自然语言定义 QA agent 的角色和任务清单，不需要写代码或断言脚本。
- Diff 驱动聚焦 — Agent 先检查自上次发布以来的所有 commit，理解改动了什么，然后有针对性地设计测试策略。
- 执行并观察 — Agent 在真实环境中执行测试：SSH 到多台机器、检查分布式推理的输出一致性、跑性能基准测试。
核心优势
| 维度 | 传统 QA | antirez 的 AI QA |
|---|---|---|
| 测试设计 | 人工编写测试用例和断言脚本 | 自然语言描述测试意图 |
| 回归基线 | 需要硬编码预期值和阈值 | Agent 自行判断是否异常 |
| 集成测试 | 复杂的测试基础设施和 mock | SSH + 真实环境 |
| Diff 感知 | 手动决定回归测试范围 | 自动分析 commit 针对性测试 |
| 用户体验评估 | 几乎不可能自动化 | 可以让 agent 评估"是否令人困惑" |
| 执行频率 | 发布前人工执行，经常被跳过 | 每次发布自动执行 |
| 边际成本 | 线性增长（人力时间） | 接近零（API 调用费） |
实战案例
DwarfStar — 分布式 LLM 推理引擎
检查分布式推理在 MacBook A 和 MacBook B 之间是否正常工作，输出是否一致，所有 GGUF 文件是否正常推理。速度回归测试不告诉 agent 之前的速度，只要求确认"没有速度退化"。配置方式：文件开头列出 SSH 端点和密钥。
关键点：这些测试以前要么不做，要么需要 antirez 自己手动 SSH 到两台机器上跑一遍。
Redis Arrays — 新数据结构
让 agent 构建一个大型基于数组的 Redis 应用，搭建带有复制和持久化的生产环境，模拟多天多用户的使用场景，在整个过程中检查异常行为。
关键点：这种测试以前需要专门的 QA 环境和大量人力，现在一个 agent 就能搞定。
注意一个微妙但关键的特质：antirez 不是在让 AI 写测试脚本，而是在让 AI 扮演一个 QA 工程师。测试脚本是静态的——它只能检查你预想到的问题；而一个"QA 工程师"是动态的——它能观察、判断、发现你没有预想到的问题。
深度解读
踩中的痛点
antirez 说了所有 QA 工程师听了都会点头的话：“所有以前需要手动执行的事情，大多数时候都被跳过了。” 这就是 QA 领域最残酷的现实。单元测试解决了"可编码"的部分，但还有一大块灰色地带——需要观察、判断、甚至"感觉"的测试——从来没有被自动化过。
被低估的价值：commit 驱动的测试策略
发布前的回归测试范围是一个经典的决策难题。有经验的 QA 工程师会看 diff 来判断风险范围，但这个能力很难标准化。antirez 的方法把这个"diff 到测试范围"的映射交给了 AI——效果可能比大多数中级 QA 工程师更好，因为 AI 能看到完整的 diff 历史，不会因为疲劳而遗漏。
存疑之处
- 幻觉风险：Agent 在复杂环境中是否会"看到"不存在的问题或漏掉真正的问题？
- 判断标准：性能测试中 agent 说"没有退化"，置信度有多高？
- 边界条件：需要深度领域知识才能发现的 bug，agent 能做到什么程度？
- 可重复性：同一个 Markdown 文件跑两次，结果一致吗？
合理的回应是：幻觉问题存在但可控（让 agent 做观察和报告而非推断决策），目标是"比之前的效果更好"（之前经常是零），三种测试方法互补而非替代，且 agent 的每一步操作都有日志，比人工的"我记得好像测过了"可追溯得多。
行业启示
对 QA 工程师
不是"QA 要被 AI 取代"，而是"QA 终于可以做到以前做不到的事了"。QA 工程师的价值会从"执行测试"转向"设计测试策略"——决定 agent 应该检查什么、用什么环境、关注哪些维度。
AI 辅助开发的闭环
antirez 提出了一个有趣的闭环：AI 辅助编程加速了代码产出但可能降低代码质量，而 AI 辅助 QA 可以弥补这个质量下降。如果闭环成立，AI 对软件开发的影响就是一个新的均衡——速度提升，质量通过另一条路径得到保障。
自动 QA 可能提高新版本软件的质量门槛，并可能部分补偿高速自动编程带来的代码质量下降。
The introduction of automatic QA may raise the bar of quality for new releases of software, and maybe partially compensate for the lower quality of the code produced at high speed with the use of automatic programming.
一句话总结
antirez 没有在讨论一个未来愿景。他在描述他现在就在用的方法。这才是这篇文章最值得关注的原因——不是"AI 可能改变 QA"，而是"AI 已经在改变我的 QA 流程，而且效果比传统方法更好"。
金句摘录
覆盖所有代码行并不意味着覆盖了所有可能的状态。
Covering all the lines of the code does not mean covering all the possible states.
所有以前需要手动执行的事情，大多数时候都被跳过了。
All things that needed to be executed manually before, and that most of the times were mostly skipped.
自动 QA 可能部分补偿高速自动编程带来的代码质量下降。
The introduction of automatic QA may raise the bar of quality for new releases of software, and maybe partially compensate for the lower quality of the code produced at high speed with the use of automatic programming.