机器人来了！测试对话接口的方法

本文要点

• 对话接口的测试需要用系统的方法，因为它们不是一个单独的一层或单独的系统，而是将交互组件和服务拼接在一起

• 测试应该准备好接受自然的非线性和语言的细微差别

• 在处理对话接口时，得依靠您的 API 测试技能，它们是大量的 API！

• 对话是灵活的，因此系统需要从某个地方获得适应性。这些接口主要由 AI/ML 组件支持，所以要在系统中找出 AI 组件

• 测试对话接口更多的是关于用户体验和系统对用户的适应性，而不是关于遵从一组严格的需求

去年的圣诞购物排行榜上，智能音箱、智能助手和其他类似的东西占据了首位。它们有什么共同点? 它们都是基于语音的计算接口，随着它们的出现，可能会出现一波新的应用程序 (称之为技能、例程和操作)。所有这些都需要使用适当的方法进行测试，以适应它们的特殊性和上下文。由于技术一直在发展，有一些需要调整 (测试策略、测试方法、验证标准)，而有一些可以重用 (例如 API 测试方法和工具)，最后但并非最不重要的是，有一些需要学习新东西 (例如测试人工智能模型和组件)。

本文结合了我的演讲《对话接口——机器人的测试！》。我在 2019 年瓦伦西亚举行的欧洲测试大会 上呈现过本次演讲的。

这些年来对话接口是如何发展起来的

对话接口并不是什么新鲜事物，至少我是这么认为的。如果我要正式定义它们，它们表示基于自然语言的任何形式的计算机用户接口 (无论是书面的还是口头的)。至少可以说，人们早在几十年前就已经设想了这样的接口，比如回想一下 HAL 9000，它是 1968 年的一部电影中设想出来的。对我来说，这是最早的对话接口的例子之一，它是个语音助手。

电影很好很赞，但是我们都知道很多时候电影是以一种一厢情愿的方式呈现事物，像 HAL 9000 这样的接口也是如此。对话接口的情况也是如此，为了成功，需要尽可能减少交互的摩擦力。换句话说，对话接口要求系统变得具有相当的适普性，并且足够强大，以支持“翻译”工作。

多年来，计算系统变得越来越小，同时也提高了它们的处理能力，同时连接得越来越多。这使得我们可以在口袋里或家里或办公室的某个地方拥有足够强大的计算元素，它们能小到不会打扰我们。我很确定这对任何读者来说都不是什么新鲜事，因为我们都经历过物联网对话或“连接着什么”的场景。这些也表明，有着相同的驱动力催生出对话接口，并且很多时候它们相互支持和补充。

近年来，随着越来越多的人拥有功能日益强大的手机，从而为对话接口真正走到台前提供了完美的环境。人工智能的进步也是一个强有力的支撑，可靠的语音识别和处理正需要它。

近年来，对话接口开始成为现实 (不仅仅是一个电影道具)，然后变得越来越精致。拥有一个日益连接的世界也很有帮助，因为在大多数情况下，对话接口为智能“事物”和设备提供了与我们交互的入口点。

测试对话接口的主要挑战

挑战? 有很多，而且出自不同的角度。

编程及其测试是在清晰和明确的逻辑前提下逐步发展的。在这种情况下，输入值是明确的。与此同时，自然语言则要含糊得多，而且在语法和语义上要灵活得多。这就是测试对话接口最重要的挑战之一。当测试这样的接口时，输入是自然语言，我们人类很喜欢有多种表达方式，于是就有了同义词和我们的表情。在这种情况下，测试从纯逻辑转换为了更接近模糊逻辑和概率云的东西。

由于对话接口的目的是为了提供一种自然的交互，因此对它的测试还需要对人类社会和交互方式有大量的同理心和非常深入的理解。在这个领域，我将把文化方面归入进来，包括讲话的副语言方面 (即所有发生在语音信息之外的交流，以语音调制和级别编码)。这些元素提供了额外的复杂性，很多时候做这份测试工作的人需要考虑这些方面。我认为，公平地说，测试对话接口也可以看作是调优，以便通过图灵测试。

测试这些接口时面临的另一个挑战是系统的分布式体系结构。大多数情况下，具有这种接口的系统是分布式服务的集合，通过 API 调用将它们粘合在一起。这并不是什么新鲜事物，但是它可以很快就变得很复杂，同时它可以转移测试工作的重点，最终成了测试其他系统及其交互，而不是最初的预期。

输入的一致性也是一个挑战。为了最小化可变性，我们需要确保输入尽可能可重复，而声音很容易就会有变化，基于这一事实就有了这一挑战。

在挑战列表最后一项但同样很重要的，我认为是性能，因为这可能很难确定。接口的性能由什么决定？它混合了易用性、灵活性、延迟和可伸缩性等因素，这里只提到了性能方面的部分因素，这些因素会影响用户对整个对话接口及其目的的感知。

我们如何应对这些挑战

首先，我认为重要的是要走出舒适区，接受不确定性和复杂性。这意味着在我们习惯于使用固定的和定义良好的值的情况下，使用置信区间进行操作。这是必要的，因为单词和短语可以有多种含义，而且几乎一直都可以用多种方式建模并表达相同的意思 (对话接口的基本构建块)。

其次，在我自己的例子中，是制定一个测试策略，它包括一个清晰的远景和任务声明，以及一个不断扩展的构建块和依赖关系地图。这使得测试人员不会忘记他们的目标，结果花了大量的时间测试系统中不是很重要的部分，或者甚至不在他们的控制之下的部分。制定一个测试策略，可以帮助我更好地理解所测试的是什么以及我所处理的系统类型。它们是相关的，因为基于静态规则的接口与基于 AI/ML 模型的接口的处理方式不同，比如那些使用自然语言处理服务或情感分析作为控制变量的接口。

获得技术上的帮助，并追求内置于被测系统的可测试性，也有很大的帮助。对我来说，这意味着包括拥有大量的检查点和日志记录点，以及可编程访问的非耦合接口。正如我在我的演讲中提到的，当涉及到测试对话接口时，API 测试 工具 和方法有很大的用处。这意味着像 Postman、Swagger 和大量的脚本编写可以帮助确保可重复的测试和探索整个系统的良好可视性。说到这里，我想到了使用 Postman 集合以一种易于与整个团队共享的方式记录交互场景，然后通过 Python 脚本以输入和序列的不同方式执行这些集合。

前面我提到了模糊性这一方面，解决这个挑战的一个方法是关注转换，而不是状态。任何接口的目标都是引导用户通过一个流程，达到一个目标。在这个视图中，流中的单个状态 (或停止) 不如不同状态之间的转换重要。我很快就了解到，在测试聊天机器人和语音助手接口时，确保正在发生转换比覆盖状态更重要。这来自于个人经验，我遇到过一个场景，作为一名用户被卡在一个死胡同里，不得不离开应用程序，因为我的输入不匹配该应用所期望的任何输入值 (同时应用程序也没有提供任何指导信息，告诉我预期输入应该是什么)。在这样的场景中，我意识到，当使用对话接口时，用户体验得益于有从一种状态切换到另一种状态的选择权。

我们学到了什么

测试是有趣事情，需要持续地学习！这是我得到的第一个教训，随着我对越来越多不同类型的系统进行测试，多年来这一认识不断得到加强。更具体地说，与测试对话接口相关，我了解到工具应该适应上下文，要探索许多方面的技术，而通用系统化思维是一个很有用的研究领域。

在测试对话接口时，我得到的一个教训是，总是要问自己：“我现在测试的这个组件是在团队的控制之下，还是向其他服务提供者提供免费测试?”这一点很重要，因为我意识到，我投入了大量时间来测试对话接口的我们无法控制的某些方面。

我早期得到的另一个教训是不要被人工智能或机器学习组件吓倒。我尊重它们，并理解在它们的背后，有一些可以作为黑盒子来处理的模型，它们具有一定程度的决定论。这来自于对临界值 (考虑属于或不属于分类域的值的阈值) 的理解，每个人工智能或机器学习支持的组件都有它，而跨边界操作决定了它们的行为。从测试的角度来看，这意味着为决策点的每一边制定等价分区，并从每个分区测试尽可能多的值。例如，当我在打招呼的时候，我通常会在积极和消极两个方面尝试至少十个选项，同时，对于每个意图，我都会尝试想出尽可能多的同义词和相同意义的短语。通过这种方法，我试图涵盖人工智能或机器学习预期输入的可变性方面。

测试对话接口所需的技能以及如何开发这些技能

我认为以 API 测试技能集作为起点是一个不错的选择。在我看来，这行得通，因为从技术角度来看，可以将对话接口类比为精心设计的 API 调用编排。

同理心是另一个重要的因素，因为自然语言是一种更为亲密的交互方式 (与图形用户界面相比)，而将自己置于目标用户位置，以及用户周围重要代理 (例如面向儿童的应用程序的父母) 的位置，需要有相当程度的同理心。同时，作为一名测试人员，还应该查看指定的路径，以确保应用程序不仅对用户是友好的，对在整个生命周期中运行和支持它的人员 (例如支持代理、后台运维人员) 都是友好的。这一点也很重要，因为如果从 API 测试技能集开始，那么在该上下文中，很多时候用户都是系统或开发人员，而对话接口大部分时间都是针对不太懂技术的用户的。

你还需要掌握建模技能，以便可以创建意图、转换和相关触发器的映射，这些映射将一起定义对话接口流。

我真的希望在阅读这篇文章之后，您会对对话接口产生更加浓厚的兴趣。意识到事情总是在变化是件好事，我相信测试人员已经为这样的应用程序做好了准备。如果我要挑选这篇文章的重点，那就是它们对同理心和灵活性的需要，以及即使在这种新环境中 API 测试工具仍然非常有用的好消息。

关于作者

Lucian Adrian是一名软件测试人员，目前正在 R/GA 享受使用新技术的乐趣。他具备广泛的软件应用测试经验，从网络和嵌入式软件，到移动应用程序和可选的接口 (如语音，AR, VR，混合现实)。他最近的兴趣是探索用户、计算机接口和数据驱动方法之间的交互。你可以通过 Twitter ( @lucianadrian ) 或他的 博客 联系他。

查看英文原文： Bots Are Coming! Approaches for Testing Conversational Interfaces