AI在多大程度上会从根本上改变我们的工作方式？变更管理流程怎么样？AI会增加或取代测试人员吗？我们如何引入人工智能计划并确保我们在旅途中将测试团队与我们一起带走？
虽然生物学通常会激发人类的创新，但它很难直接实现。鸟类教会人类飞行是可能的，并激发人类创造力几个世纪。但是今天的飞机和直升机的设计与他们的生物角色模型没有多少共同之处。随着人类学习和应用原则，我们会根据我们的需求进行调整。我们不再为可能越过障碍物的车辆创造机械支腿，而是为障碍物铺设了道路，为我们的轮式交通铺平了道路 - 这种交通工具更快更有效率。
对于我们的人工智能测试工作也是如此：他们几乎不会成为人类测试工作的忠实再创造。为了更好地了解AI在整个测试过程中的应用位置，我们需要分解测试人员的各项任务和挑战。就像马达不能直接替代肌肉一样，我们需要了解每项任务的潜在动机以及它如何与整体测试目标相互作用，以便我们可以设想如何在目标仍在服务的同时改进和改变过程。因此，在下文中，我们讨论的是目标，而不是人类测试人员的实际任务。
在非常粗略的层面上，测试可以分为两种情况：
测试新的软件和功能
测试现有的软件和功能
测试新功能新功能需要周到的测试。我们必须确保新功能有意义，遵守用户体验设计原则，安全可靠，高效，并且通常按预期工作。[3] [4]更正式地说，ISO 25010标准[1] 包含8个产品质量的主要特征，我们将单独讨论：
功能（完整性，正确性，适当性）
性能（时间行为，资源利用率，容量）
兼容性（共存，互操作性）
可用性（可操作性，可学习性，用户错误保护，用户界面美学，可访问性，可识别性）
可靠性（成熟度，可用性，容错性，可恢复性）
安全性（保密性，完整性，不可否认性，责任性，真实性）
可维护性（模块化，可重用性，可分析性，可修改性，可测试性）
便携性（适应性，可安装性，可替换性）
断言正确和完整的功能基本上是一个AI完全问题[2]，这意味着AI需要至少像人类一样聪明才能做到[3]。例如，在Facebook等社交网站中搜索名字和姓氏时，它应该返回具有指定名称的所有人。在像Ashley Madison这样对隐私敏感的网站上做同样的事情[4]时，这将是一个严重的问题。任何给定的功能是正确还是错误通常都在旁观者的眼中。这个问题叫做oracle问题[5] 因为我们需要一个Delphian Oracle来判断某个显示的功能是否正确。这意味着在可预见的未来，我们不能使用AI来测试软件功能的正确性[6]。
另一方面，性能标准通常可以通过简单且非常通用的方式指定 - 例如，站点的加载时间不应超过2秒，按下按钮后，反馈不应晚于500毫秒。因此，AI可以测试性能，事实上，这样做的产品已经可用[7]。
兼容性可以有许多不同的含义。一些广泛的兼容性测试实例 - 如跨浏览器测试，跨设备测试或跨操作测试（主要关注设计和功能） - 可以轻松实现自动化[8]。而且，我们已经看到了产品[9]。其他兼容性问题更加微妙，技术导向或具体。在这些情况下开发专门的AI往往因经济原因而过高。
目前的AI系统目前难以分析可用性，尽管这可能是未来的一个有希望的风险。有趣的是，提高软件的可用性还可以提高AI系统理解和测试软件的能力，从而进一步激励这样做。
即使没有AI，也已经存在可以分析软件系统可靠性的某些方面的软件，例如容错和可恢复性。AI只会改进这种分析并产生更好的结果。成熟度和可用性等其他方面与这些系统的长期使用和操作更相关，并且通常难以测试 - 即使对于人类也是如此。
此外，为了安全起见，已经存在使用现有和众所周知的攻击场景来测试某些方面的软件。除了这种标准攻击之外，一般来说，安全性很难测试。安全分析师通常是高薪专业人士，他们精通各自领域，巧妙地将系统的各个方面结合起来，以发现新的弱点和漏洞。如果使用人工智能很难测试业务功能，那么安全（除了已知的攻击）是皇家学科，最后将会解决。
可维护性和可移植性通常是软件系统的更多内部方面，与系统的开发和操作非常相关，但几乎没有经过测试。
ISO 25010标准还定义了5种使用质量的特征：
效用
效率
满意度（实用性，信任，快乐，舒适）
免于风险（经济，健康和安全以及环境风险缓解）
上下文覆盖（上下文完整性和灵活性）
很明显，这些特征都与人类与软件交互的结果有关。因此，它们非常个人化，很难以系统的方式进行资格认证和测试。
同样清楚的是，尽管上述特征对于软件产品都很重要，但它们几乎不能解释该领域中相同数量的测试工作。数字很难得到，但似乎很清楚，测试正确和完整的功能是最大的努力。不幸的是，这也是在Oracle问题之后，我们说我们无法使用AI来帮助我们的方面。
但不是那么快：测试软件正确功能的很大一部分不是在新软件上完成，而是在现有软件上完成。也许这可以以某种方式解决问题？
测试现有功能软件与我们在非数字世界中遇到的许多事情非常不同。例如，如果我们修理汽车的前灯，我们不需要测试喇叭。但是，由于软件具有如此多的不可见和未知的相互依赖性，因此对软件系统的某个部分进行更改可能会对系统的任何其他部分产生无法预料和无意的副作用。因此，有必要重新测试已经测试和批准的功能，即使它没有改变，只是为了确保它确实没有改变。这种形式的测试称为回归测试，它构成了大量的整体测试工作。
现在，回归测试的一个非常有趣的方面是它已经过测试和批准的功能，这意味着我们可以专注于测试变化，而不是测试正确性 。按照这种思路，回归测试不是一种测试形式，而是一种特定形式的变更控制。开发人员已经经常以版本控制系统的形式使用变更控制。问题是，这些系统只管理源代码和配置文件等静态工件。
然而，用户遇到并受测试的软件是一种动态的东西，存在于计算机的存储器中。程序代码和配置是创建软件动态状态的起点。但是更多的成分，例如底层硬件和操作系统的细节，输入数据和用户交互，形成了动态软件状态。虽然源代码和配置类似于建筑物的原始蓝图，但动态状态与实际建筑物相当。该建筑的具体特征取决于更多方面，如建筑材料，绘画，家具，装饰和室内植物，所有这些都不是蓝图的一部分，但所有这些都与建筑的用户体验完全相关。
为了解决所遇到的软件本质（动态状态）不受版本控制系统控制的事实，当前的事态是创建和维护自动回归测试。然后，这些测试将编码软件的动态状态，并因此将其转换为静态伪像，这些伪像可由现有版本控制系统控制。然而，问题是大多数现有的回归测试系统都是在非常成功的JUnit之后建模的。这个继承人的一部分包括检查机制。这种检查机制包括单独的检查（称为断言），它一次检查一个事实。这些事实被认为是艰难（和不变的）真理。因此，这些测试目前是手动创建和维护的，需要付出很多努力， 变化。
但是，存在这种方法的替代方案。这些系统的名称包括Golden Master测试，Characterization测试[10]，Approval测试[11]或基于Snapshot的测试[12] ，现在正在流行。这些测试不仅更容易创建，而且更易于维护，因为检测到的更改可以简单地应用于基础测试（如果需要）。此外，它表明这些测试弥补了一些其他长期存在的回归测试问题[13]。
使用此测试范例，AI可以因此为现有（和批准的）软件版本创建此类Golden Master测试。在更改软件之后，这些测试然后将向人类测试者显示功能的改变（或其缺失）。然后，人类测试人员只需要检查新功能或检测到对现有功能的更改。在许多情况下，这已经大大节省了工作量并且风险大大降低。这对AI起作用的原因很简单，就是它绕过了oracle问题。AI现在不需要确定特定功能是否正确 - 它只需要执行软件并记录其行为。
解决了让人工智能免于测试软件的主要挑战，我们现在能够转向一些剩余的挑战。即使我们能以某种方式神奇地解决oracle问题，这些也是我们将面临的额外挑战。一个是AI需要了解如何执行软件。也就是说，给定先前动作的（可能是空的）跟踪以及软件的当前状态，AI需要决定接下来要执行的用户动作。这样制定的问题与玩Chess或Go等游戏的问题非常相似。实际上，我们已经有玩电脑游戏的AI，必须解决完全相同的问题。因此，我们有一条如何完成任务的明确途径。唯一的区别是如何制定合适的奖励功能。对于电脑游戏，这样的奖励功能相当简单：“增加点数。”为了执行商业软件的不同用例，这可能类似于“增加代码覆盖率”或某些类似度量。提供AI学习的典型使用场景的记录将克服初始挑战，例如猜测正确的用户名/密码组合或查找日期，电子邮件或其他更加模糊的输入数据的有效值（想想SAP事务代码）。
在产生这种记录的过程中，AI已经可以测试性能以及可靠性和安全性的某些方面，如上所述。它会遇到的任何技术错误（oracle是这样的错误应该永远不会发生的事实），它可以报告，使单独的烟雾测试也过时了。请注意，如上所述，改进软件的可用性可能也会提高AI在测试中的性能。
值得注意的是，我们已经和很长一段时间都有一种自动化测试方法，原则上它能够实现相同的结果。它被称为猴子测试。这种方法以猴子定理命名，猴子定理指出打字机上的猴子，随意敲击随机钥匙，最终会写出莎士比亚的所有作品。推理很简单：在永恒中，它会产生所有可能的角色组合。一个这样的（长）组合将是莎士比亚的作品，以及其任何可能的变化。猴子测试只是将这个定理应用于测试，在GUI上生成随机输入。已经存在系统[14]。使用AI，我们只需在合理的时间内提高效率并获得一些有价值的结果，而不是永恒。
一个新的测试过程鉴于前面部分的见解，可以设想一个新的测试过程，如下所示：创建一个新软件。人工测试人员确保此软件正确且完整且可用且安全。请注意，前两个任务也可以分配给业务分析师的角色。然后将该软件提供给AI，AI通过记录典型的使用场景进行训练，从而知道如何执行该软件。AI执行软件并记录足够多的不同输入/输出场景，因为Golden Master允许在下一版本的软件中检测到更改。其他质量方面也由AI负责，例如，它测试性能，已知安全攻击和容错。
使用来自AI，测试人员/业务分析师以及实际用户的反馈，开发人员可以在下一个sprint中改进软件。Golden Master测试的一个子集可以在每晚或每次提交后执行，为开发人员提供早期反馈。创建下一个版本后，将执行完整的Golden Master测试集，显示行为的每个变化，并允许轻松批准这些更改和稳定的GUI测试[15]。这也将增加测试覆盖率并显着降低未检测到的更改风险。然后，测试人员可以自由地专注于新功能和软件行为的变化。请注意，这也可以实现更好的跟踪（谁批准了哪些更改？）以及更轻松的软件认证。
此过程将释放测试人员重复和平凡的任务，例如手动回归测试。因此，它将增加测试人员，而不是取代他们。我们在这里谈论的基本上是无代码和自动自动化 - 这两个流行语多年来一直困扰着测试自动化工具领域，但结果却是工具供应商未能实现的承诺。这意味着我们将许多测试人员从他们不想做的职业选择中解放出来 - 转向测试自动化。将AI应用到这样的测试中，测试人员可以获得很多收益，但实际上没什么可失去的。
长期观点建议的流程变更使得它们可以通过AI当前的功能来实现。研究人员预计，这些功能只会随着时间的推移而改善和扩大。一旦AI获得了人类或超人类的能力，实际上AI就无法执行任务，从测试人员到开发人员再到管理人员[16]。但目前还不清楚何时会达到这个标志。在实现这些功能的道路上，还有许多有趣的里程碑。
一个正在进行的讨论是AI是否威胁到测试人员的工作。遵循上述思路将产生近乎完整的自动化测试，以及按需生成更多此类测试的功能。这基本上打破了影响分析的问题 - 找出任何给定变化影响的软件部分。解决此问题允许将AI应用于源代码的自适应和生成。考虑自动生成错误补丁，自动消除性能瓶颈或通过重构源代码自动提高源代码质量，例如更短的方法和类。
大爆炸没有重要的能力。在我们进行全面的自动驾驶之前，我们提供了驾驶员帮助，帮助我们保持在车道上，适应前灯或保持距离。软件的开发和测试也是如此。让AI生成或改进代码的一小部分将是生成简单方法，模块或最终整个系统的第一步。当发生这种情况时，oracle问题仍然没有得到解决。因此，即使使用这些方法，仍然需要确保生成的功能正确且完整。这个角色是否被称为开发人员，业务分析师或测试人员是我的猜测。但在我看来，那些自称为开发者的人应该比那些自称为测试人员的人更担心他们的工作长期前景。
