软件测试的新时代

在某些特定的使用场景下，以及在得当的人手中，自动编程能够大幅缩短软件开发的周期。 根据我的经验，其生成的代码在结构化程度和复杂度方面的表现，远不及那些由人工编写、 质量上乘的软件。不过，并非所有软件都堪称完美； 在我看来，只要管理得当，自动编程往往能超越大多数情况下（甚至在良好管理的情况下）由人工精心编写的高质量代码。

然而，在利用人工智能来开发新软件时，质量与时间之间存在着权衡关系。 在一些我所参与开发的项目中，这种权衡往往十分残酷——短短几周内，原本可能耗费数月才能完成的项目， 却能在几周内迅速交付。不过，也有一些领域，大语言模型为自动化流程开辟了全新的、 更为强大的途径，且在质量方面几乎无需妥协。 其中就包括软件测试与质量保证领域。

传统上，软件测试通常依赖于测试套件，而这些测试套件又由本地范围内的测试和集成测试组成——以Redis为例： 一项任务是验证“SET foo 10”是否能被“GET foo”成功匹配并返回结果，而另一项任务则是检验在这种情况下，复制功能是否正常运行。 随后，通过人工执行的测试用例，我们得以发现可运行测试套件中的潜在缺陷。 众所周知，覆盖代码的所有行并不意味着完全覆盖所有可能的状态。 此外，集成测试在结构上也颇具挑战：其中涉及诸多时序问题、环境搭建问题，以及一些仅能通过视觉检查而非自动检测的质量指标， 这使得许多测试机会因时间和后勤条件的限制而未能得到充分挖掘。

大语言模型为现有测试方法提供了全新的解决方案。 其核心思路是：创建一份 Markdown 文件，让 AI 代理以 QA 工程师的身份介入，对新版本进行一系列手动测试。 以DwarfStar（一款针对开放权重大语言模型的推理引擎）为例，我采用了如下方法： 在 Markdown 文件中，要求代理检查在已发布软件版本基础上新增的提交内容。 随后，向模型提供一份需要执行的任务清单，例如：

• 检查分布式推理功能是否能在 MacBook A 和 MacBook B 之间正常运行，确保输出结果一致，且在两台机器上均能顺利运行 GGUF 文件……

• 确保此次发布不会导致任何性能下降或速度变慢。

诸如此类。值得注意的是，在评估性能下降这一环节时，我无需事先告知代理原预期的性能水平， 因为随着新版本的发布和新优化的实施，这一目标会不断变化。 同样地，对于分布式推理的集成测试，文件开头只需提供 SSH 连接地址、所需使用的密钥、路径等信息，无需过多指令。

代理需对这份冗长的 QA 活动清单进行逐一核查，尤其要关注新增的提交内容，从审查变更细节入手，识别出可能受到影响的模块， 从而有针对性地开展 QA 测试，努力定位具体的回归问题。

以 Redis Array 为例，我采用了一种类似的方法：要求代理构建一个基于数组的大型 Redis 应用程序，配置生产环境并实现复制与持久化，模拟应用程序在数天内、在众多用户并发访问下的使用场景， 同时仔细检查是否存在异常情况。

采用这些方法进行测试，还能从更深层次的心理层面提升软件质量——让代理去识别那些可能令人意外、 未被充分文档化，或从用户视角来看整体略显粗糙的新功能。 这些原本需要手动执行的事项，往往在以往的测试中被忽略，甚至常常被直接跳过。

我深信，引入自动 QA 功能有望进一步提升新版本软件的质量标准，或许还能在一定程度上弥补在快速开发过程中，由于自动编程而产生的代码质量参差不齐的问题。

评论