程序猿的办公室有一大神兽，不仅长得萌萌哒，而且人人都爱它。它就是bug的终结者——小黄鸭！黄鸭Debug大法流传于民间，代代相传。这一高深的技艺记载于《程序员修炼之道》一书中，故事中令人捉摸不透的程序猿大神总是带着一个橡皮鸭在身边。每当需要Debug的时候，他就一行一行地解释给小黄鸭听。突然间，小黄鸭发挥神力，与程序猿心神交汇，bug就现身啦！
小黄鸭跟着程序猿风里雨里，并肩作战，没有半句怨言。直到有一天，程序猿良心发现：想我代码千万行，为何不能造出一行能自己debug的代码？于是程序自动化调试逐渐兴起，自动评估和代码纠错正在逐渐为程序员带来福音。编程也即将进入AI时代了。
那么，人工智能可以在多大程度从根本上改变人类的工作方式？它能够变更管理流程吗？人工智能会增加或取代测试人员吗？我们如何在引入人工智能计划的同时确保测试团队继续发挥作用？
为了更好地了解人工智能在整个测试过程中的应用位置，我们需要分解测试人员的各项任务和挑战。我们需要了解每项任务的潜在动机以及它如何与整体测试目标相互作用，以便设想如何在目标仍在服务的同时对过程进行改变和改进。在下文中，我们讨论的是目标，而不是人类测试人员的实际任务。
我们将测试大致分为两种情况：
● 测试新的软件和功能
● 测试现有软件和功能
一. 测试新功能
新功能需要周到的测试。我们必须确保新功能有意义，遵守用户体验设计原则，安全、可靠、高效，并且按预期工作。更正式地说，ISO 25010标准包含8个产品质量的主要特征，我们将单独讨论：
1.功能（完整性，正确性，适当性）
2.性能（时间行为，资源利用率，容量）
3.兼容性（共存，互操作性）
4.可用性（可操作性，可学习性，用户错误保护，用户界面美学，可访问性，可识别性）
5.可靠性（成熟度，可用性，容错性，可恢复性）
6.安全性（保密，完整，不可否认性，可计量性，真实性）
7.可维护性（模块化，可重用性，可分析性，可修改性，可测试性）
8.可移植性（适应性，可安装性，可替换性）
确定正确和完整的功能基本上是一个完全意义上的AI问题，这意味着AI需要至少像人类一样聪明才能做到。例如，在Facebook等社交网站中搜索名字和姓氏时，它应该返回具有指定名称的所有人。在像Ashley Madison这样对隐私敏感的网站上做同样的事情时，这将是一个严重的问题。任何给定的功能是正确还是错误通常都取决于旁观者的角度。这个问题叫做Oracle问题，因为我们需要一个Delphian Oracle来判断某个显示的功能是否正确。这意味着在可预见的未来，我们不能使用人工智能来测试软件功能的正确性。
另一方面，性能标准通常可以以简单且非常通用的方式指定——例如，站点的加载时间不应超过2秒，按下按钮后，反馈时间不应超过500毫秒。因此，AI可以测试性能，事实上，这样做的产品已经可用了。
兼容性有许多不同的含义。一些广泛的兼容性测试实例如：跨浏览器测试、跨设备测试或跨操作测试（主要关注设计和功能） 等都可以轻松实现自动化。而且，我们已经看到了具有兼容性的产品。其他兼容性问题更加微妙、技术导向或具体。在这些情况下，往往因经济原因过高，所以禁止开发专门的AI。
目前的AI系统难以分析软件的可用性，尽管这可能是未来的一个趋势。有趣的是，提高软件的可用性还可以从提高AI系统理解和测试软件的能力，从而进一步激励软件的可用性方面来做。
即使没有AI，也已经存在一些可以分析软件系统可靠性的软件，例如容错和可恢复性。AI只会改进这种分析并产生更好的结果。成熟度和可用性等其他方面与这些系统的长期使用和操作更相关，并且通常难以测试，即使对人类也是如此。
此外，对于安全性而言，已经存在使用现有和众所周知的攻击场景来测试某些方面的软件。除了这种标准攻击之外，一般来说，安全性很难测试。安全分析师通常是高薪专业人士，他们精通各自领域，巧妙地将系统的各个方面结合起来，以发现新的弱点和漏洞。若使用人工智能很难测试业务功能，那么安全性则（除了已知的攻击）是重点的学科，是我们最终需要解决的问题。
可维护性和可移植性通常涉及软件系统的内部方面，与系统的开发和操作非常相关，但几乎没有经过测试。
ISO 25010标准还定义了5种使用质量的特征：
1. 效力
2. 效率
3. 满意度（实用性，信任度，快乐度，舒适度）
4. 风险自由（经济，健康和安全以及环境风险缓解）
5. 覆盖上下文（上下文完整性和灵活性）
很明显，这些特征都与人类与软件交互的结果有关。因此，它们非常个性化，很难以系统的方式进行资格认证和测试。
尽管上述特征对于软件产品都很重要，但它们几乎不能解释该领域中相同数量的测试工作。评价测试结果的数值很难得到，但我们明白测试具有正确和完整的功能才是最需要努力的。不幸的是，这也是在Oracle问题之后，我们无法使用人工智能来协助我们进行测试工作的原因。
二. 测试现有功能
软件与非数字世界中的许多事物截然不同。例如，如果我们修理汽车的前灯，不需要测试喇叭。但是，由于软件具有如此多的不可见和未知的内在依赖性，因此对软件系统的某个部分进行更改，可能会对系统的任何其他部分产生无法预料和意外的负面影响。因此，有必要重新测试已经测试过的和已获批准的功能，即使它没有改变，这样做也是为了确保它确实没有改变。这种形式的测试称为回归测试，它占据了测试工作的很大一部分。
现在，回归测试的一个非常有趣的方面是它已具有测试和批准的功能，这意味着我们可以专注于测试变化，而不是测试正确性。按照这种思路，回归测试不是一种测试形式，而是一种特定形式的变更控制。
开发人员常以版本控制系统的形式使用变更控制。但问题是，这些系统只管理源代码和配置文件等静态文件。
然而，用户受测试的软件是一种动态的东西，存在于计算机的存储器中。程序代码和配置是创建软件动态状态的起点。但是许多成分，例如底层硬件和操作系统的细节、输入数据和用户交互，形成了动态软件状态。虽然源代码和配置类似于建筑物的原始蓝图，但动态状态与实际建筑物相当。该建筑的具体特征取决于更多方面，如建筑材料、绘画、家具、装饰和室内植物，所有这些都不是蓝图的一部分，但所有这些都与建筑的用户体验完全相关。对于软件的动态状态也是如此。
为了解决软件本质（动态状态）不受版本控制系统控制的事实，当前事件的状态是创建和维护自动回归测试的。然后，这些测试将编码软件的动态状态，并因此将其转换为静态伪像，这些伪像可由现有版本控制系统控制。然而，问题是大多数现有的回归测试系统都是按照非常成功的JUnit建模的。这其中继承了一部分，包括检查机制。这种检查机制包括单独的检查（称为断言），它一次检查一个事实。这些事实被认为是难以改变（和不变）的真理。因此，这些测试目前是手动创建和维护的，需要付出大量的精力，并且不适合于检测和允许改变的情况。
但是，这里存在这种方法的替代方案。这些系统的名称包括Golden Master测试，Characterization测试，Approval测试或基于Snapshot的测试，现在很受欢迎。这些测试不仅更容易创建，而且更易于维护，因为检测到的更改可以简单地应用于基础测试（如果需要）。此外，它表明这些测试弥补了一些其他长期存在的回归测试的问题。
使用此测试范例，人工智能可以因此为现有（和批准的）软件版本创建此类的Golden Master测试。在更改软件之后，这些测试将向测试者显示功能的改变（或其缺失）。然后，测试人员只需要检查新功能或检测到对现有功能的更改即可。在许多情况下，这已经大大节省了工作量并且大大降低了风险。这对AI起作用的原因很简单，就是它绕过了Oracle问题。人工智能现在不需要确定特定功能是否正确——它只需要执行软件并记录其行为。
在解决了让人工智能免于测试软件的主要挑战之后，我们现在需要关注剩下的问题。一个是人工智能需要了解如何执行软件。也就是说，如果对以前的动作（可能是空的）和软件的当前状态进行跟踪，那么人工智能需要决定接下来要执行什么样的用户动作。这样制定的问题与玩国际象棋或Go等游戏的问题非常相似。实际上，我们已经有玩电脑游戏的人工智能，并且它已经解决了完全相同的问题。
因此，我们明确了完成这个任务的方法。唯一的区别是如何制定合适的奖励机制。对于计算机游戏，这样的奖励功相当容易：“增加点数”。为了执行不同的商业软件用例，增加点数可能类似于“增加代码覆盖率”或某些类似指标。为人工智能提供典型的使用场景来克服初始挑战，例如猜测正确的用户名/密码组合或查找日期，电子邮件或其他更加模糊的输入数据的有效值（想想SAP事务代码）。
在产生这种记录的过程中，AI已经可以测试软件性能，并具有某方面的可靠性和安全性了。人工智能可能会遇到任何技术错误（oracle这样的错误应该永远不会发生），它可以报告，从而使单独的烟雾测试也过时了。请注意，如上所述，改进软件的可用性也可能会提高人工智能在测试中的性能。
值得注意的是，我们掌握一种自动化测试方法已经很久了，原则上它能够实现相同的结果。它被称为monkey测试。这种方法以猴子定理命名，猴子定理指出打字机上的猴子，随意敲击键盘按键，最终会写出莎士比亚的所有作品。这是个很简单的推理：最终，它会产生所有可能的角色组合。这样的组合可能是莎士比亚的作品，以及其任何可能的变化组合。猴子测试只是将这个定理应用于测试，在GUI上生成随机输入。这已存在于系统中了。使用人工智能，我们只需在合理的时间内提高效率并获得一些有价值的结果。
三. 一个新的测试过程
鉴于前面部分的见解，可以设想一个新的测试过程，如下所示：创建一个新软件。测试人员确保此软件正确完整可用且安全。请注意，前两个任务也可以分配给业务分析师。
然后将该软件提供给人工智能，人工智能通过记录典型的使用场景进行训练，从而知道如何执行该软件。人工智能执行软件并记录充足的不同输入/输出场景，因为Golden Master允许在下一版本的软件中检测到更改。其他质量方面也由人工智能处理，例如：它测试性能、已知的安全攻击和容错。
通过来自人工智能、测试人员、业务分析师、实际用户的反馈，开发人员可以在下一个sprint中改进软件。 Golden Master测试的一个子集可以在每晚或每次提交后执行，为开发人员提供早期反馈。创建下一个版本后，将执行完整的Golden Master测试集，显示行为的每个变化，并批准这些更改和稳定的GUI测试。这也将增加测试覆盖率并显著降低未检测到的更改风险。
测试人员可以自由地专注于新功能和软件行为的变化。注意这也可以更好的实现跟踪以及更容易的软件认证。
此过程将省去测试人员重复又平凡的任务，例如手动回归测试。因此，它将释放测试人员更多的能力，而不是取代他们。这意味着我们把许多测试人员从他们不想做的职业选择中解放出来，让其转向测试自动化。将人工智能应用到这样的测试中，测试人员可以获得很多收益。
四. 长期观点
提议流程的变更使得它们可以通过人工智能当前的功能来实现。研究人员预计，这些功能只会随着时间的推移而改善和扩大。一旦人工智能获得了人类或超人类的能力，就几乎没有人工智能所不能执行的任务了，不论从测试人员到开发人员还是再到管理人员。但目前还不清楚何时会达到这个情况。
但在实现这些功能的过程中，还有许多有趣的里程碑。
一个热门话题是人工智能是否威胁到测试人员的工作。遵循上述思路将产生近乎完整的自动化测试，以及按需生成更多此类测试的功能。这基本上打破了影响分析的问题——找出任何给定变化影响的软件部分。解决此问题允许将人工智能应用于源代码的自适应和生成。考虑自动生成错误补丁，自动消除性能瓶颈或通过重构源代码自动提高源代码的质量，例如：进入更短的方法和类。
没有什么主要的能力是伴随着大爆炸而来的。在我们全面的进行自动驾驶之前，我们得到了协助驾驶程序的帮助，它帮助我们在车道上保持平稳行驶、适应前灯或保持距离。软件的开发和测试也是如此。让人工智能生成或改进代码的一小部分将是生成简单的方法、模块或最终整个系统的第一步。当发生这种情况时，Oracle问题仍然没有得到解决。因此，即使使用这些方法，仍然需要确保生成的功能正确且完整。这个角色是否被称为开发人员，业务分析师或测试人员已超出了我们的猜测。但那些自称为开发者的人应该比那些自称为测试人员的人更担心他们工作的长期前景。
閱讀更多 讀芯術 的文章
