软件测试技术在人机对话系统中的应用研究

林晓欲,Yuan Tommy，雷倩茹

(1.洛阳光电技术发展中心，河南 洛阳 471000；2.约克大学 计算机科学学院，英国 约克 YO10 5GH)

0 引 言

人工智能技术毫无疑问地被列为即将改变世界的突破性技术之一。而人机对话[1]是人工智能领域的一个子方向，通俗地讲就是让人可以通过人类的语言(即自然语言:文字、语音，甚至两者皆含)与计算机进行交互，来完成确定任务的人与计算机之间的信息交换过程。[2]

人机对话系统陆续上线使用，越来越贴近人类的工作、学习和生活，其类型多种多样，状态各异，对话目标也各不相同，已经渗透到社会的方方面面。人机对话系统的复杂性和普遍性也使人们意识到其质量保证的重要性。

人机对话系统的本质是软件通过一定的载体来达到其目标。传统软件的质量保证通常通过软件测试来实现。人机对话系统既符合软件产品的基本属性，又具有其固有特点。针对其特点，如何运用软件测试技术研究出一种有效的方法开展测试，来达到对人机对话系统软件质量保证的目标,成为人机对话系统相关研究的热点和难点。

本文结合传统的软件测试方法，将8种基本对话类型按照实现用途归结为4类，并分析4类对话系统的特征，提出针对性的测试方法和思路。将软件测试技术用于英国约克大学开发研究的某人机辩论系统中，通过测试工作，发现该系统的一些缺陷，提出了改进建议。通过具体的对话系统测试实践，验证了测试方案的有效性，为后续研究提供了基础。

1 对话系统

1.1 基本对话类型

从文献[3]资料中已经认识到的7种人类基本类型的对话是：说服、调查(询问)、发现、谈判、信息查询、审议、争论。这7种是基于参与者有明确目标的，即任务型对话系统，如果再加上开放域对话，即聊天，那么基本的对话类型为8种，如表1所示。

目前，人机对话系统根据基本对话类型和实现用途进行归类，可以分为4类：问答、任务驱动的多轮对话、推荐和开放域聊天。

(1)问答：接近一个自然语言理解加信息检索的过程，侧重于一问一答，即直接根据用户的问题给出精准的答案。基本对话类型中的发现、调查和信息查询与该功能相对应。

(2)任务驱动的多轮对话：由于用户需求比较复杂，有很多限制条件，可能需要分多轮进行陈述，所以更是一个决策过程，需要机器在对话过程中不断根据当前的状态决策下一步应该采取的最优动作(如提供结果、询问特定限制条件、澄清或确认需求等)，从而最有效地辅助用户完成服务获取或解决问题。基本对话类型中的说服、谈判、商议和争论与该功能相对应。

(3)推荐：根据当前的用户需求和历史的用户画像主动推荐用户可能感兴趣的信息或者服务。基本对话类型与该功能没有直接相关，可以说是对对话系统的技术衍生。常言道，需求不存在因为技术不存在。在当今信息爆发的时代，推荐技术在帮助用户寻找信息、帮助服务商寻找客户的环节中扮演了举足轻重的地位。

(4)开放域聊天：在用户没有明确的信息或服务获取需求时系统做出的回应。自然语言聊天在现有的人机对话系统中，主要起到拉近距离、建立信任关系、情感陪伴、顺滑对话过程(如在任务类对话无法满足用户需求时)和提高用户粘性的作用。基本对话类型中的聊天与该功能对应。

1.2 对话系统工作过程

常见的对话系统工作过程主要为：系统首先理解人类发出的信息，将其表示为一种内部状态，然后根据对话状态的政策采取相应的行动，最后将行动转化为一种自然语言的表现形式，如图1所示。主要由以下部分组成：自然语言理解(Natural Language Understanding，NLU)、对话状态跟踪(Dia-logue State Tracking，DST)、对话策略学习(Dialogue Policy Learning,DPL)、自然语言生成(Natural Language Generation，NLG)[4]。其中DST和DPL统称为对话管理(Dialogue Management，DM)[5]，即根据对话历史信息，决定对用户的反应。

图1 对话系统工作过程Fig.1 Dialogue system working process

1.3 软件测试方法[6]

由于软件开发人员思维上的主观局限性，且软件系统的复杂性，软件非常容易出错。而软件一旦发生故障，造成的后果可能非常严峻。减少软件缺陷、提高软件质量是一项艰巨的任务。

软件测试是为了发现软件产品所存在的任何意义上的软件缺陷，从而纠正这些软件缺陷，使软件系统更好地满足用户的需求[7]。从哲学观点看，分析问题和解决问题的方法有两种：白盒方法和黑盒方法。软件测试沿用哲学思想，将测试方法也分为白盒测试方法和黑盒测试方法。

白盒测试(White Box Testing)[8]又称结构测试或者逻辑驱动测试，是把测试对象看作一个打开的盒子，如图2所示。白盒测试需要测试软件产品的内部结构和处理过程，不需要测试软件产品的功能。白盒测试方法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试等。

图2 白盒测试Fig.2 White box testing

黑盒测试(Black Box Testing)[9]又称功能测试或者数据驱动测试，是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子，如图3所示。软件测试人员从用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现。黑盒测试的类型有功能、性能、接口、兼容性、易用性等。黑盒测试方法的覆盖标准为需求覆盖。

图3 黑盒测试Fig.3 Black box testing

2 人机对话系统测试策略

2.1 对话系统应用程序的特点

对话系统应用程序是一系列按照特定顺序组织的计算机数据和指令的集合，既符合软件的基本特点，也具有其特殊性，主要有：不确定性和概率性、对大数据具有依赖性、随机性的输入/输出、难以预测所有应用场景、需要从过去的行为中不断自我学习。具体表现是：

(1)对话系统是由巨大而多样的数据驱动的，在做出任何决定之前都需要进行处理；这些数据可以是任何格式，如文本、语音、图像、视频等，来源也各不相同；这些数据可能是一次性摄入的，也可能是一个连续的过程；数据是人机对话系统所采取的任何预测、决定或行动的基础。

(2)对话系统是机器学习系统，系统通过学习、训练来执行某些动作。根据需要和上下文，这些算法可能在种类和复杂性上有所不同，可以组合多个算法来给出特定的期望输出。

(3)与第三方系统有丰富的接口，通常被应用于其他更大的应用程序以满足最终的业务目标。

2.2 测试策略[10]

2.2.1 基本测试策略

人机对话的核心是利用对历史数据的处理训练，得出可以在将来数据上有良好输出的模型[11]。所以，对于测试而言，应该关心数据模型在对待正常数据、边界数据、异常数据作为输入时，模型的输出是否能够符合期望；数据模型在经过训练后，用测试集数据预测的正确率如何。因此，应开展数据测试、分层测试、训练集和测试集对比测试。

(1)开展数据测试。用等价类划分、边界值分析等方法进行功能测试，尤其是边界、异常数据测试，如输入与训练时一样的数据、与训练时完全不同的数据、训练时的边界值等，看是否达到期望输出；以此来验证模型对数据的容错能力，算法是否能够通过迭代和对比来减少误差；验证系统能够接受来自各种来源和各种格式的数据；验证所摄入的数据是按照目标系统所期望的格式转换。

(2)开展分层测试。针对人机对话系统的复杂性，对模型进行分层测试。模型工作的过程是：数据引入、数据处理(清洗、拆分、拼接等)、特征工程、模型训练、模型上线。通过测试分层后每一个部分的功能、性能和各层的接口实现对模型的测试。

(3)开展训练集和测试集对比测试。对话策略学习的算法主要是机器根据数据特征和特征的权重来预测一个行为，是一个结果概率。因此，使用训练数据集来理解和建模系统行为，并使用测试数据来验证系统的准确性或响应也是一种测试方法。

值得注意的是，传统的测试需要有准确的预期结果，这是逻辑思维的结果。而人机对话(除了问答)往往没有准确的预期结果，也不需要保证每次数据的正确性。应该考察即便数据有一点问题，最后得出的模型效果还不差这样的结果；需要验证随着数据规模的增长，数据结果的正确性和优化效果。因此，对人机对话系统测试的思路应该从注重“逻辑分析”转换到“知识学习能力的验证”上。

主要测试类型有：

(1)功能测试：用等价类划分、边界值分析等方法进行数据、模型过程的功能划分，测试功能的正确实现；模型是否能够根据处理数据的量从少到多而自动不断优化、调整输出。

(2)性能测试：用场景法确定不同的性能需求，测试模型在处理数据时的效率(学习过程、cpu占用率、内存消耗等)；在同一平台通过不断点击运行，以及快速退出和快速进入，处理大量数据、空数据等观察性能指标的变化等。

(3)接口测试：测试模型分层后数据的正确转换和传输；测试模型输入输出的正确性。

(4)易用性测试：测试模型是否有良好的用户交互；测试具体使用时，是否有良好的告知用户的提示，不能一直处于安装或等待状态等；测试模型是否有人性化的参数调整入口，供运营人员以及测试人员对上线后、上线前进行调整。

(5)兼容性测试：测试不同的操作系统下运行对话系统的兼容性；测试软件与其他软件共同运行的情况。

2.2.2 特殊测试策略

(1)问答系统DM测试策略

问答系统DM主要实现过程是：在问句的类型识别与分类的基础上，进行文本的检索[12]以及知识库的匹配。也就是分为问题分析、信息检索、答案抽取三部分。其路径排列的数量非常大，因此，在测试中不可能运行路径的每一种组合，所以要进行针对性测试，通过对系统业务需求和业务流程的分析，从宏观角度考虑用例应该包括哪些基本流和备选流。通过用例场景[13]来描述流经用例的路径，继而确定从用例开始到结束遍历这条路径上所有的基本流和备选流，形成比较高的场景覆盖率，指导测试的实施，以保证软件的质量。

测试首先抽取业务流程图，即从系统需求说明书或相关文档中提取出相关的业务流程，形成业务流程图；其次，确定关系图，即根据具体的业务流程图，画出基本流和备选流的关系图；然后，确定触发条件，即经过以上对系统(子系统)的运作流程的分析，根据业务流程图，按照传统的用例分析方法分析出每个基本流与备选流的触发条件；最后，进行场景分析，即根据确定的基本流和备选流的关系，再加上确定的触发条件的描述，确定出不同的用例场景。

测试类型与基本测试类型相同。需特别说明，在功能测试时，通过备选流的测试，保证对系统异常情况的测试覆盖。

(2)多轮对话系统DM测试策略

多轮对话系统DM就是在NLU(领域分类和意图识别、槽填充)的基础上，进行对话状态的追踪(DST)以及对话策略的学习(DPL)，以便于DPL阶段策略的学习以及NLG阶段澄清需求、引导用户、询问、确认、对话结束语等。

产生的状态数跟意图和槽值对的数成指数关系，与问答系统DM测试策略相同。同样通过用例场景来描述流经用例的路径，形成比较高的场景覆盖率，以保证软件的质量。

其特殊性在于，存在上下文处理及决策过程，由于多轮交互时，有很多信息在交互的上文中已经出现，用户不会再在当前的问题中进行重复，所以需要一个上下文的记忆模块，根据所有对话历史信息推断当前对话状态St和用户目标。常用的方法是运用人工规则、生成式模型、判别式模型、Web Rank等，因此，对这部分的测试可以与基本测试策略相同。

测试方法为问答系统DM测试方法与基本测试方法结合。测试实现为问答系统DM测试实现与基本测试实现结合。

(3)推荐系统DM测试策略

推荐系统DM就是进行用户兴趣的匹配以及推荐内容评分、排序和筛选等，以便于NLG阶段生成更好的给用户推荐的内容。对推荐系统测试可以算作大数据测试和算法测试。

基于大数据算法的测试方法可以用结果反馈的方式去测试，即对结果进行实时监控，发现异常后及时反馈；也可以自己构造一些数据，然后用算法去跑自己构造的数据，检查结果是否正确。

推荐系统的测试实现方式分别为：从所有的结果当中进行抽样，然后进行基本的业务测试；自己构造测试数据，然后对这些数据的输出结果进行测试；基于效果的监控，通过监控算法上线后点击率、平均浏览时长、平均停留时长、留存情况、覆盖率等常用的评估指标是否有上升。

(4)开放域聊天系统DM测试策略

聊天系统DM就是对上下文进行序列建模、对候选回复进行评分、排序和筛选等，以便于NLG阶段生成更好的回复。其本质与多轮对话系统相同。

测试方法为问答系统DM测试方法与基本测试方法结合。测试实现为问答系统DM测试实现与基本测试实现结合。

3 对某人机对话系统的测试实践

3.1 被测软件概述

约克大学人工智能小组开发的“人机对话系统”对话模型DE[14]是建立在正式辩论系统DC的基础上的辩论系统模型。该系统旨在提高辩论系统基本对话模型在辩论过程中发现错误论点和常见错误的能力。

设计者使用Java编程语言构建了一个功能完整的原型，对对话模型DE进行操作。这个系统可以让用户与其就有争议的问题进行辩论。

系统有五个主要部分：界面部分、对话部分、承诺部分、计划部分和知识库部分。系统设计时对表达方式、库集规则、对话规则进行了规定。该辩论系统架构如图4所示。

图4 某辩论系统架构Fig.4 Debate system architecture

3.2 测试内容与方法

辩论系统本质上是一个以说服为目的的多轮对话系统，所以参考本文2.2节的测试策略开展测试。

目前，对人机系统的测试研究，无论是方法还是标准都处于探索阶段，还未形成规范和标准，因此，本次测试是一次研究性的测试。由于该系统的输入为列表选择输入，输出为文字输出，因此，本次测试涉及对话系统中的对话状态跟踪和对话策略学习，不涉及语音识别和文字输入，不涉及语音输出。

本次人机对话系统测试应符合以下技术要求：

(1)系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖；

(2)测试用例的输入应至少包括有效等价类值和边界数据值；

(3)测试系统的输出及其格式；

(4)对不同的实际问题应外加相应的专门测试。

考虑测试投入，结合软件特点，制定对应的测试策略如下：

(1)根据重要程度，排定测试的优先顺序为：功能性测试、易用性测试、兼容性测试、维护性测试；

(2)与委托方沟通项目建设经验，针对委托方关注的业务内容进行重点测试；

(3)根据对软件特点进行分析，应重点针对人机对话系统中决策的转换场景进行测试；

(4)使用历史已有的测试数据辅助测试分析；

(5)对测试中提出的软件问题，应与软件承研单位充分沟通、确认。

经分析，本次测试需要开展的测试类型为功能性测试(包括接口测试)、易用性测试、维护性测试和兼容性测试。

对界面部分、对话部分、承诺部分、计划部分、知识库部分、输入、知识响应、规则等以及识别出来的重要场景进行测试项分解，并进行易用性、维护性和兼容性分析，结果如表2所示。

测试内容充分性分析：

(1)对软件中的功能需求及非功能需求进行全面分析，并结合用户提出的需求，共整理出19项测试需求，对应19个测试项目，细化为64个测试子项，实现测试需求对可测软件需求100%覆盖。

(2)描述测试环境与实际运行环境一致，满足测试要求。

3.3 测试环境

测试环境配置如表3所示。

人机对话系统在计算机系统中完成其功能，本次测试环境为计算机系统，因此，测试环境与真实环境一致，无环境差异。

表2 功能测试需求分解Table 2 Test demand decomposition

表3 动态测试环境配置列表Table 3 Dynamic test environment configuration list

3.4 测试设计

对于确定的测试内容，按照分解的测试子项设计测试用例。每个单独的测试都进行了详细描述。测试用例的基本表达如表4所示。

表4 测试用例Table 4 Test cases

注：>表示当前活动的角色。

3.5 测试执行

按照测试用例的描述执行测试。

3.6 测试总结

本次测试运行测试用例125例，借用133个对话场景[15]，开展了功能性(含接口)、易用性、兼容性、维护性测试，覆盖了用户提出的需求。

被测软件在系统智能、用户体验、系统价值和用户界面几个方面均满足使用要求，特别是DE对话模型和所采取的策略实现了开发目的；被测软件具有良好的兼容性和可维护性。

测试过程中提出软件问题5个，其中功能性2个、易用性3个，均为一般性问题。问题具体描述为：

问题1：测试人员扮演支持CP方，在经过多轮辩论后，同意了对方的观点(反方)，这时候裁判并没有进行裁决，而是让辩论继续。测试人员认为此测试结果与需求不一致。

问题2：帮助菜单中的部分功能未实现。

问题3：辩论过程中，运用“I don’t think” 或者“Why”作为论述开始时，界面表示中不容易找到支持观点的陈述。

问题4：辩论过程中，运用“I don’t think” 或者“Why”作为论述开始时，可在用户观点和机器观点里进行多项选择，系统不能及时给出限制提示。

问题5：帮助菜单内容多次点击会在屏幕上多个显示，系统不能进行限制。

与开发方进行沟通，对于问题1，开发方认为该系统设计的目的是用于教学的辩论系统，所以在辩论策略设计上还考虑了辩论内容覆盖的全面性，基于这个考虑，裁判进行裁决的时机会跟真实辩论过程不同。针对该问题，开发方会在相应文件中进行说明。此外，接受其余4个问题并进行改进。

4 总 结

本文通过研究不同对话系统的特点，提出相应的软件测试方法和思路。经研究表明，传统的测试类型同样适用于人机对话系统测试，但是在测试策略制定时，需要考虑由于人机对话系统中用到大量机器学习方法，这部分测试应针对其特点，在测试用例设计时，改变传统的需要准确预期结果的思路，重心放在模型能力的验证上。

通过对某人机辩论系统的测试实践，验证了方法和思路的可操作性。测试结果表明，测试方法可行，测试思路正确，对提高软件质量有突出的贡献。此测试可以作为人机对话系统测试的基础。

同时，本文提出的方法和思路还需要开展更深入、充分的研究和试验，并应用到人机对话系统的评估中。