软件测试的新纪元：AI如何提升QA质量

软件测试的新纪元

antirez 1小时前 · 1946次阅读。在某些用例中，在合适的人手中，自动编程能大幅加速软件编写。根据我的经验，其输出在结构质量和复杂性经济性上，并未达到最佳手写代码的水平。然而，并非所有软件都出类拔萃，我的感觉是，自动编程大多时候（如果管理得当）能超越中等水平的手写代码质量。

然而，在使用AI编写新软件时，质量与时间之间存在权衡。在我开发的某些项目中，这种权衡可能极为残酷——即原本需要数月才能完成的项目，在几周内就能完成。然而，在某些领域，LLM打开了全新的、严格意义上更强大的自动化流程方式，而无需在质量上妥协。其中一个领域就是软件质量保证（QA）和测试。

传统上，软件测试通过由局部测试和集成测试组成的测试套件来进行（以Redis为例：测试SET foo 10是否会被GET foo => 10匹配是一回事；测试复制在此场景下是否正常工作又是另一回事）。此外，还有通常手动执行的QA验收测试，它们能捕获可运行测试套件中的漏洞。众所周知，覆盖所有代码行并不等于覆盖所有可能的状态。而且集成测试在结构上很困难：存在大量时序问题、设置问题，以及某些只能通过视觉检查而无法自动验证的质量输出，这些测试机会往往因时间或后勤限制而未被充分利用。

LLM在现有测试方法论之上提供了一种新的QA方式。其思路是创建一个Markdown文件，要求AI代理作为QA工程师，对新版本执行一系列手动测试。例如，针对DwarfStar（一个面向开源权重大模型的推理引擎），我采用了以下方法。在Markdown文件中，代理被要求检查相比于已发布版本，软件项目新增了哪些提交。然后模型会被告知一系列需要执行的操作，比如：

- 检查分布式推理是否能在MacBook A和MacBook B上正常工作，确保输出一致，推理能在两台机器上的所有GGUF文件中运行…… - 确保此版本不包含任何速度回退。

诸如此类。值得注意的是，在速度回退部分，我不需要告诉代理之前预期的速度是多少，因为这是一个随新版本和新优化而变化的动态目标。同样，分布式推理的集成测试也不需要大量指令；文件开头只有SSH端点、要使用的密钥、路径等。

代理被要求特别根据新增的提交来检查一系列QA活动，首先检查变更并识别可能受影响的部分，从而让QA验收专门针对性地发现特定回退。

在Redis Arrays项目中，我使用了类似的方法，要求代理构建一个基于数组的大型Redis应用，搭建包含复制和持久化的生产环境，模拟应用运行数天并有大量用户的使用情况，检查是否有异常。

采用这些方法的测试还可能深入到软件质量的心理层面，要求代理识别所有可能让用户感到惊讶、文档不足或整体敷衍的新功能。这些以前都需要手动执行，并且大多数时候都被跳过了。

我感觉自动QA的引入可能会提高软件新版本的质量门槛，并可能部分弥补因使用自动编程高速生成代码而导致的质量下降。