antirez的新博客：软件测试的新时代-----------------------在某些用例中，如果使用得当，自动化编程可以极大加快软件编写速度。以我的经验来看，它产出的代码在结构质量以及复杂度控制的精简程度上，仍达不到最优秀的手写软件水准。不过，并非所有软件都是精品。我感觉，在大多数情况下，如果管理得当，自动化编程生成代码的质量会超过一般水平、正常开发出来的手写代码。

不过，用 AI 编写新软件时，质量与时间之间存在一种取舍。在我开发过的某些项目中，这种取舍非常明显：原本可能需要数月才能完成的项目，几周内就能做完。然而，也有一些领域，LLM 开启了全新的、更强大的流程自动化方式，而且不会在质量上有所妥协。软件 QA 与测试就是这样的领域之一。

传统上，软件是通过测试套件来测试的，这些测试套件由局部作用域测试和集成测试组成。以 Redis 为例：测试 SET foo 10 后 GET foo 是否返回 10 是一回事；测试在这种情况下复制功能是否正常工作，则是另一回事。除此之外，还有通常由人工执行的 QA 检查，用来发现可运行测试套件中的漏洞。众所周知，覆盖所有代码行并不意味着覆盖所有可能的状态。此外，集成测试在结构上就很困难：其中涉及许多时序问题、环境搭建问题，以及某些只能通过目视检查、无法自动验证的质量输出。这些因素使得大量测试机会因为时间或后勤限制而没有真正被利用起来。

LLM 在现有测试方法之上，为 QA 提供了一种新的方式。思路是创建一个 Markdown 文件，在其中要求一个 AI agent 扮演 QA 工程师，对新版本执行一系列手动测试。比如，在 DwarfStar 这个开放权重 LLM 推理引擎中，我采用了如下方法：在 Markdown 文件里，要求 agent 检查当前软件项目相对于已发布版本新增了哪些提交。然后告诉模型需要执行的一系列事项，例如：

检查分布式推理是否能在 MacBook A 和 MacBook B 之间正常工作，确保输出连贯，确保我们在两台机器上的所有 GGUF 文件都能正常推理，等等。确保这个版本没有速度回退。

诸如此类。值得注意的是，在速度回退这一项中，我不需要告诉 agent 之前预期的速度是多少，因为这是一个会随着新版本和新优化不断变化的目标。同样，分布式推理的集成测试也不需要太多说明：文件开头只需要提供 SSH 端点、要使用的密钥、路径等信息。

我会要求 agent 检查一长串 QA 活动，尤其要结合新增提交来检查：先审查变更，识别可能受到影响的部分，然后让 QA 流程专门针对潜在的具体回归问题进行测试。

在 Redis Arrays 的案例中，我也使用了类似方法：要求 agent 构建一个大型的、基于数组的 Redis 应用，搭建带有复制和持久化的生产环境，模拟该应用在多用户环境下运行数天，并检查是否出现异常。

使用这些方法进行测试，还可以进一步进入软件质量中更偏“心理感受”的层面：要求 agent 识别所有可能让用户感到意外、文档说明不足，或者从用户视角看起来比较粗糙的新功能。这些事情过去都需要人工执行，而大多数时候其实都会被跳过。

我感觉，自动化 QA 的引入可能会提高软件新版本的质量门槛，并且也许能在一定程度上弥补使用自动化编程高速产出代码时所带来的代码质量下降问题。AI创造营