将神经元挤压到狭窄的空间：QA 中的人工智能

今天，基于神经网络的人工智能正处于一个非常有趣的发展阶段。它显然已经起飞：我们看到从读取CT扫描到采摘水果的许多应用。但采用率差异很大。推荐引擎、客户支持机器人和其他被称为“互联网 AI”的东西相当普遍;我们在生活中随处可见它。然而，大多数领域，包括软件测试，还没有完全实现。

是什么让人工智能被广泛采用，是什么让它陷入困境？让我们来看看我们自己的领域，软件测试。具体来说，我想看看神经网络如何生成自动化测试，以及在我们的领域大规模采用人工智能存在哪些障碍。我将首先关注问题和困难，不是因为我试图成为半空的玻璃杯，而是因为出错的事情总是告诉我们更多关于系统如何运作的信息，而不是正确的事情。

一旦我们完成了生成测试，我想看看人工智能在其他领域的应用，比如医学——那里有很多工作要做，尤其是阅读扫描。也许他们有类似的成长痛苦？最后，为了鸟瞰，我将看看一个完全不同的行业，它已经成熟和巩固。它的经验能告诉我们今天人工智能的发展吗？

有了这个角度，也许我们可以停止困扰新技术的炒作/幻灭钟摆，也许可以瞥见人工智能的发展方向。

确认

在我们继续之前，我要感谢纳塔利娅·波利亚科娃和阿尔乔姆·埃罗申科为我提供了这篇文章的时间和专业知识。但是，所写一切的责任完全在于我。

另外，非常感谢Danil Churakov在此（和其他）帖子中提供的精彩图片！

生成测试：现在的位置

今天，ChatGPT，GitHub Copilot和其他AI驱动的工具被广泛用于编写代码和测试，我们最近对此进行了一次非常有趣的采访。然而，人们仍然大多是手工编写自动化测试，神经网络的使用主要是情境化的。他们在这一领域达到目标的速度仍然远低于人类的标准。 2020 年末的一篇论文预测了测试中 62% 的断言陈述，这绝对是一个值得吹嘘的结果。根据GitHub Copilot的常见问题解答，它的建议在26%的时间内被接受。人们常说，它最好的用途是作为谷歌和StackOverflow的更快替代品。所以 - 情境用法。目前，软件QA中的AI还不能与营销等领域拥有相同的水平，在市场营销中，神经网络创建的数字营销和数据分析策略实际上优于人类创建的数字营销和数据分析策略。但是，请记住，GPT-4 可能会改变情况。

这些问题从何而来？让我们四处打听并做一些实际研究。我和我经验丰富的测试人员同事谈过，也修改了Machinet，这是一个非常流行的IDEA插件，可以生成单元测试。

我们使用的神经网络对于其预期应用非常有用。Machinet可能是作为开发人员助手而不是通用工具创建的。他们的座右铭听起来绝对像是针对开发人员而不是QA：“让我们面对现实吧。单元测试是一件苦差事。只需自动化即可。这是有道理的——通常是开发人员编写单元测试。对于没有深入了解测试的人来说，该工具做得很好。只有当我们从 QA 的角度来看待结果时，故障才会变得可见。那么存在哪些问题呢？

A. 问题

工作中的网络

过度承保

Machinet 插件完成了它的工作，并且做得很彻底 - 它确保覆盖 if-else 分支、使用不同的数据类型、检查字符限制等。事实上，它完成的工作太彻底了，可以生成太多的测试，而不考虑资源负载。例如，检查字段是否接受任何字符并检查它是否将字符串长度限制为 255 个字符可以在单个测试中轻松完成 - 但 Machinet 为每种情况生成了一个单独的测试。另一个示例涉及由多个 API 方法使用的数据检索功能。生成的测试将涵盖每个方法中的函数，并且将为函数本身创建一个单独的测试。同样，我们显然得到了过度的报道。

印象是，如果我们有几个相交的数据集，插件将尝试覆盖所有可能的交集。假设您正在测试一个电子商务网站，并且您有多种交付选项（客户取货、付款类型等）。使用Machinet，所有可能的组合都可能会被测试，而人类测试人员可以使用决策表来涵盖真正重要的组合。但是，这样做可能需要未输入神经网络的上下文数据。

代码重复

一个相关的问题是代码重复。我们正在测试一个需要填充对象的集合，它必须在 4 个不同的测试中使用。每个测试都从头开始重新创建集合，而不是将其移动到单独的字段或函数中。此外，代码中已经存在一个用于生成集合的函数，它执行的操作与测试中所做的基本相同，但插件没有使用它。神经网络能很好地使用本地的东西？很容易说，嗯，这是网络以前从未遇到过的独特情况。但这并不像神经网络在识别它以前见过的独特猫照片时会遇到任何困难。这是一个有趣的问题，我们将在下面回到。

了解复杂代码

神经网络生成的自动化测试在涵盖简单的模块化代码片段时处于最佳状态。当然，如果所有代码都以这种方式编写，那就太好了，但这可能是不可能的或不可行的。当您需要涵盖冗长而复杂的业务逻辑时，机器生成的测试的可靠性会受到很大影响。当然，它们会被生成，但很难弄清楚它们是否正确地覆盖了东西，或者它是否只是随机的东西，几乎不能指望用于烟雾测试。

了解上下文

在谈到过度覆盖时，我已经谈到了这一点：网络并不真正知道该方法的用途，因此无法根据这些知识进行优化。例如，人类测试人员知道，如果我们在 Java 中测试 API 方法，我们应该检查空值;如果不是 API，则可以跳过此操作。我们看到的网络似乎不会做出这样的决定。

外部工具和模式的使用

我们还注意到，Machinet 使用硬编码值填充集合，而不是使用库随机生成数据。我不知道这是否是一个过分的要求，但有一个相关的问题：我们使用的神经网络在外部依赖关系方面做得不好，使用模式也是一个问题。

清理

最后，网络生成的代码肯定需要彻底审查。当然，所有由人类编写的代码也需要审查，这是标准做法，基于AI的工具的创建者总是警告这一点。在开发此类工具时，绝对必须牢记这一点：会有很多来回，使编辑变得容易应该是首要考虑因素。但这可能是一个问题还有另一个原因。正如我所说，Machinet 似乎针对那些可能不太熟悉测试的开发人员;因此，审查机器工作的人可能无法纠正我刚才谈到的所有缺陷。

问题背后的原因

因此，当需要深入了解本地项目时，我们一直在使用的工具并不那么好，不“理解”他们正在测试的方法的上下文，他们不擅长在重复或资源使用方面优化代码，他们最擅长简单和模块化的代码，他们创建的代码也往往是这样。

乍一看，这些似乎是相当深层次的问题，但也许这是因为我们在谈论“理解”而不是在谈论数据。毫不奇怪，如果没有对 RAM 和 CPU 使用率的数据进行训练，网络就无法根据资源消耗优化代码。ChatGPT 不了解您的特定项目，因为它没有接受过培训。最后，这些障碍不是代码固有的，这只是一个经济学问题：在特定数据集上训练网络是否可行。

更深层次的原因本身就是代码吗？

然而，这里有一个更深层次的问题：代码与人类语言不同。这个问题已经得到了很好的研究，并且已经为自然语言开发的算法绊倒了一段时间。如果我们将自然语言与您主要“按原样”使用的工具进行比较，那么编程语言就是您用来构建工具的工具，以构建工具来构建工具。它更加嵌套。

对XKCD最好的问候

程序员编写的每个新函数或变量都有自己的名称，这些名称可能会变得非常长且难以理解 - 特别是Java因VariableNamesThatLookAndFeelLikeTrainWrecks而臭名昭著。

这意味着，例如，Ubuntu 的源代码可以比大量的英语文本语料库多两个数量级的独特“单词”（嗯，标记）。这是一个非常大且非常稀疏的词汇;对于任何算法来说，这两者都是坏消息。生僻词意味着要学习的数据较少，词汇量会影响算法的速度和内存要求。

这些嵌套词汇表也非常本地化。您在项目中使用的大多数单词永远不会看到外部。这就是封装的重点：突出的东西越少，代码就越容易使用。因此，您拥有特定于应用程序甚至开发人员的词汇表。此外，人们使用的工具也在不断变化，这也催生了新的词汇。除此之外，还有风格：我们编写的代码可能非常固执己见。那是你刚刚写的Pythonic吗？还是你还在拖着你旧的Java习惯？同样的问题可以用不同的方式解决，造成进一步的混乱。

因此，想象一下您的技术堆栈。你有你的语言（也许是几种语言），你的框架，你的数据库，你在前端和后端拥有的所有库，以及你使用的模式，以及开发人员的特质。所有这些交叉上下文都严重限制了任何特定AI驱动工具的类似代码的数量。因此，难怪这些工具在生成复杂代码时会遇到麻烦。

问题很深，但还不够深

当然，这是一个问题，但远非不可克服。问题是，在由语言、框架、项目等定义的上下文中，代码实际上比人类语言重复得多（另请参阅此处）。而那个重复的部分是占主导地位的部分。一项研究发现，大量 JavaScript 文件包含 2 万个唯一标识符，但其中只有 4k 个负责所有事件中的 10%。

因此，这不是数据（我们的代码）的深层问题，而是数据如何组织以及如何将其输入工具的问题。也许可以通过使用一种训练子词而不是单词的算法来解决。这样的算法不必处理数百万字长的词汇表，但它会更耗费资源。或者，也许是关于拥有一个可以足够快地重新估计的模型，以便它可以适应您的本地环境。或者，也许我们应该将上下文信息（如注释）提供给算法。无论如何，答案始终是关于我们如何组织数据以及处理数据的速度。

馈送网络

缩小：人工智能的演变

让我们试着把这些问题放在正确的角度，看看它们与人工智能在其他领域必须克服的困难相比如何。

无论如何，神经网络的历史围绕着在更短的时间内处理更多的数据。这是我一开始不太明白的：对于神经网络，数量就是质量;数据越多，答案就越复杂和准确。

几乎只要有计算机，人们就一直在尝试构建神经网络，但在大部分时间里，人工智能被不同的学校主导，即“基于规则”的方法：告诉你的系统规则并观察它的工作;如果失败 - 请咨询专家，制定新规则。相比之下，神经网络根据它们处理的数据自己找出规则。那么，为什么网络只是在过去一二十年才“起飞”呢？因为那时我们获得了大规模的数据存储（特别是云）、疯狂的大量生成数据（通过物联网等）和巨大的处理能力（尤其是 GPU 计算）;就在那时，发生了几项创新，大大提高了深度神经网络的训练效率，从 2000 年代中期的 Geoffrey Hinton 的工作到 2018 年变压器的发明。长话短说，可以快速处理大量数据。

但仅仅拥有算法和硬件可能还不够。医疗保健是一个收集和存储大量数据的领域，一直在寻找尖端技术，并吸引大量投资。因此，在某些地方和某些领域（如眼科），人工智能已经进入日常使用也就不足为奇了。然而，在广泛采用之前还有很长的路要走。在医疗保健领域，与编程不同，确实存在优于人类的模型，但它们大多停留在开发阶段，并且在实施中不断失败。

原因是，与用于训练模型的集合相比，现实生活中的数据是“脏的”。目前，医院的数据都以不同的方式收集和存储，医院通常有几个系统，除了通过pdf文件外，它们不会相互通信。当然，数据基础设施因医院而异，因此您无法构建任何大规模数据集。此外，患者可能与用于训练模型的人口统计数据不同。此外，从业者使用的一些信号没有数字化，这降低了模型的比较效率。在本地数据集上训练模型时，存在患者保密问题。

进入狭窄的空间

一般来说，有两种方法可以绕过这些障碍：使模型适合现实生活中的使用给我们带来的狭窄空间，或者扩大空间。

用于训练医疗保健中表现最佳的模型的大型数据集是通过由于专有原因无法在现实生活中重现的步骤创建的。因此，可以在局部环境中校准模型以提高其准确性，而合成数据集可用于保护机密性。

但是，如果不改变用于收集和存储数据的基础设施，所有这些都不可能非常有效。现有的系统必须能够相互连接，数据应该像STRIDES倡议所提议的那样存储在异地，最重要的是，它必须变得更加统一。

不出所料，代码和医疗保健中采用问题背后的原因非常不同。解决方案则不然。我们可以预期这些模型在重新训练以适应当地环境方面会变得更便宜、更有效。我们可以改变组织数据的方式。为了使网络更高效地处理代码和测试，我们需要更标准化的编写和存储方式。我们认为的“干净代码”的许多实践旨在使代码对人类更具可读性。也许我们现在需要的是使其对神经网络更具可读性的方法。

或者也许它更简单。如果神经网络可以生成简单、重复的代码，并且善于用测试来覆盖它——那么也许我们让它们做工作的两面，完全忘记干净的编码实践，而是专注于控制输出的方法。

总结

当一项新技术出现时，有两种采用途径：首先，该技术试图适应经济中已经存在的一些角色;然后，经济发生变化，以适应新技术的全面发展。第二条路径意味着创建一个基础设施网络来支持该技术。如果你有汽车，你也会得到新道路的大规模建设，你会得到立法的变化，等等。如果你想要电动汽车，你需要充电器。

这是目前在QA中AI之前的两条道路，可以帮助将技术与支持它所需的基础设施相结合：

1. 制作能够更好地适应当地环境的人工智能驱动工具，能够在特定项目和技术堆栈上学习的工具

2. 使测试的组织方式适应神经网络的要求

审核编辑：郭婷