语音功能的稳定性测试方法、装置、设备和计算机存储介质与流程

本申请涉及计算机应用技术领域，特别涉及一种语音识别技术领域下的稳定性测试技术。

背景技术：

为了防止一些功能软件在运行过程中因出现异常导致系统变慢、性能下降、崩溃等不良影响，需要对功能软件进行稳定性测试。稳定性测试通常是通过给被测功能软件一定的压力并持续一段时间，从而检测系统是否能够稳定运行。随着智能语音技术的迅速发展，越来越多的应用程序融入了语音功能，那么在正式上线之前就需要对语音功能进行稳定性测试。

技术实现要素：

有鉴于此，本申请提供了一种针对语音功能的稳定性测试方法、装置、设备和计算机存储介质。

第一方面，本申请提供了一种语音功能的稳定性测试方法，包括：

启动被测试应用的语音功能；

从预先生成的语音指令的音频集合中逐一选择语音指令向所述被测试应用进行播放，直至达到预设的稳定性执行时长；

获取被测试应用在稳定性测试过程中记录的崩溃日志；

对所述崩溃日志进行解析，并依据解析结果判断是否达到稳定性测试标准。

第二方面，本申请提供了一种语音功能的稳定性测试装置，包括：

功能启动单元，用于启动被测试应用的语音功能；

音频播放单元，用于从预先生成的语音指令的音频集合中逐一选择语音指令向所述被测试应用进行播放，直至达到预设的稳定性执行时长；

日志获取单元，用于获取被测试应用在稳定性测试过程中记录的崩溃日志；

解析判断单元，用于对所述崩溃日志进行解析，并依据解析结果判断是否达到稳定性测试标准。

第三方面，本申请提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的方法。

第四方面，本申请提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行上述的方法。

通过本申请提供的技术方案能够实现对语音功能稳定性的自动化测试。并且相比较传统人工下发语音指令进行测试的方式，摆脱了人力束缚，提高了测试效率。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1为本申请所采用的测试框架的示例图；

图2为本申请实施例一提供的主要方法流程图；

图3为本申请实施例二提供的预先生成语音指令的音频集合的方法流程图；

图4为本申请实施例三提供的语音功能的稳定性测试装置结构图；

图5是用来实现本申请实施例的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

通常一个应用程序中某个功能在线上发布之前，会经历两个测试阶段：一个是线下测试阶段，另一个是小流量的线上测试阶段(也称为灰度发布阶段)。本申请中提供的稳定性测试方法应用于线下测试阶段。

传统的针对语音功能的稳定性测试主要是由人工执行，即由测试人员人工向被测试应用发出语音指令，持续预设时长来进行稳定性测试。但受限于人力，人工发出的语音指令有限，不能够充分暴露crash(崩溃)问题。而本申请则提供了一种能够自动实现语音功能稳定性测试的方法，以摆脱人力束缚，以充分地对语音功能进行稳定性测试。

为了方便对本申请的理解，首先对本申请所采用的测试系统架构进行描述。如图1所示，该系统架构可以包括中控设备、音箱和测试机。其中，被测试应用安装并运行于测试机上，该被测试应用中具备语音功能，包括：语音识别、语义理解、语音交互等子功能，并可以根据输入的语音指令进行响应，执行操作。

音箱可以是独立的设备，也可以集成设置于中控设备中。中控设备和测试机之间可以通过网络连接，包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

测试机可以是支持语音功能的各种电子设备，可以是有屏设备，也可以是无屏设备。包括但不限于智能手机、平板电脑、智能音箱、智能电视等等。

中控设备负责执行对测试机中被测试应用的语音功能的稳定性测试。其可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块，在此不做具体限定。中控设备可以是诸如pc、笔记本电脑等计算机设备。

应该理解，图1中的中控设备、音箱、测试机的数目仅仅是示意性的。根据实现需要，可以具有任意数目的中控设备、音箱和测试机。

实施例一、

图2为本申请实施例一提供的主要方法流程图，如图2中所示，该方法可以包括以下步骤：

在201中，启动被测试应用的语音功能。

本步骤中，可以利用自动化测试工具启动被测试应用，然后向被测试应用播放预先生成的唤醒音频，以启动被测试应用的语音功能。

其中，自动化测试工具可以采用诸如appium。appium是一个自动化测试开源工具，支持ios平台和android平台上的原生应用、web应用和混合应用。通过appium工具，图1中的主控设备可以启动测试机中的被测试应用。

根据被测试应用的语音功能所采用的唤醒关键词，可以预先采用语音合成技术生成唤醒音频。例如，以百度系应用为例，其语音功能所采用的唤醒关键词为“小度小度”，则可以采用语音合成技术生成“小度小度”对应的唤醒音频，然后向被测试应用播放该唤醒音频，从而唤醒被测试应用的语音功能。

在202中，从预先生成的语音指令的音频集合中逐一选择语音指令向被测试应用播放，直至达到预设的稳定性执行时长。

在本申请中，可以预先生成包含很多语音指令的音频集合，这些语音指令能够触发被测试应用的语音功能对该语音指令进行识别和解析后，执行相应的操作。关于该音频集合的生成方法将在后续实施例二中进行详细描述。

在测试过程中，逐一从音频集合中选择语音指令向被测试应用播放。选择的方式可以是随机选择，也可以按照一定的顺序来选择。

通常对于应用中的语音功能而言，是分为多种应用场景的。以地图类应用为例，可以包括：地理位置点查询场景、导航到地理位置点的场景、通行时长预估场景、路线查询场景，等等。用户可能连续在不同场景输入语音指令，例如，首先在地理位置点查询场景使用一次或两次的语音指令，然后接续路线查询场景使用一次或两次的语音指令，再接续导航到地理位置点的场景一次语音指令。为了在测试过程中尽量符合大多数用户的实际使用状况，可以预先对音频集合中的语音指令划分到不同的语音场景，然后可以按照语音场景的顺序，逐一从各语音场景的语音指令中选择语音指令。

其中，语音场景的顺序可以随机生成，也可以依据历史记录中各语音场景的使用频率来排序，例如按照从高到底的顺序来排序，还可以人为指定语音场景的顺序，等等。

假设共有10个语音场景，则可以从第1个语音场景开始，先从该第1个语音场景的语音指令中选择一个进行播放，然后从第2个语音场景的语音指令中选择一个进行播放，再从第3个语音场景的语音指令中选择一个进行播放……然后从第10个语音场景的语音指令中选择一个进行播放。如果此时仍未达到预设的稳定性执行时长，再循环到第1个语音场景的语音指令中选择一个进行播放……直至达到预设的稳定性执行时长。

当然，除了上面例子中的方式之外，也可以采用其他播放方式。例如，从第1个语音场景开始选择10个，第2个语音场景选择10个……，即每个语音场景选择10个依次播放，直至达到预设的稳定性执行时长。再例如，从第1个语音场景开始逐一播放该语音场景中所有的语音指令，再逐一播放第2个语音场景中所有的语音指令……直至达到预设的稳定性执行时长。

当达到预设的稳定性执行时长后，停止播放语音指令，本次稳定性测试结束。上述稳定性执行时长可以是由测试人员根据对被测试应用的稳定性测试要求设置的。

在203中，获取被测试应用在稳定性测试过程中记录的crash日志。

在各语音指令的播放过程中，被测试应用会对语音指令进行识别、解析并执行相应操作。与此同时，被测试应用会记录crash日志。crash日志通常会包含crash进程信息(例如crash进程的文件名、版本号等)、异常代码的信息、crash堆栈信息等。

在204中，对crash日志进行解析，并依据解析结果判断是否达到稳定性测试标准。

本步骤中，可以利用符号表文件，对crash日志进行解析，得到其中的crash堆栈信息。然后将对被测试应用进行的最新线上测试得到的崩溃堆栈信息与解析得到的crash堆栈信息进行比对。

其中，符号表是内存地址与函数名、文件名、行号的映射表。可以利用符号表对应用发生crash的程序堆栈进行解析，从而精确定位应用发生crash的代码位置。线上测试指的就是上面已经提到的，通常测试所包含两个阶段中的线上小流量测试。通过线上小流量测试也会产生crash堆栈信息。通过比较本次线下稳定性测试得到的crash堆栈信息和最新线上测试得到的crash堆栈信息，就能够得到是否存在新增crash，以及新增crash的信息。

依据比对得到的新增crash，就能够判断是否达到稳定性测试标准。例如，可以判断新增crash的数量是否大于或等于预设的数量阈值，如果是，确定未达到稳定性测试标准，否则确定达到稳定性测试标准。根据不同被测试应用、不同开发者的要求等，对于新增crash数量的要求也不尽相同。但通常情况下，是不允许出现新增crash的，也就是说，上述预设的数量阈值取1，一旦出现新增crash，就确定未达到稳定性测试标准。

但也存在一些例外，例如，对于一些长期存在的、无法解决的crash，可以容忍其存在。如果新增crash仅仅是这一类crash，则也可以认为达到稳定性测试标准。

若未达到稳定性测试标准，可以提示或触发对被测试应用的语音功能的质量(qa)优化，并在优化结束后再次执行上述稳定性测试方法，直至达到稳定性测试标准。在本申请中对于质量优化的具体方式并不加以限制，可以采用现有技术中已经存在的任意质量优化方法。

若达到稳定性测试标准，则可以将该待测试应用的语音功能进行线上小流量测试，即灰度测试。若灰度测试也通过，则可以进行正式的线上发布。

对于上述稳定性测试，可以产生测试报告供测试人员查看。其中测试报告中可以包含诸如新增crash的情况、测试时长、播放的语音指令等等信息。

实施例二、

图3为本申请实施例二提供的预先生成语音指令的音频集合的方法流程图，如图3中所示，该方法可以包括以下步骤：

在301中，从被测试应用的语音功能的历史解析日志中，获取解析成功的指令。

利用大数据技术获取被测试应用的语音功能的历史解析日志，即被测试应用的解析服务器对用户输入的大量语音指令进行识别和解析后得到的日志，从中可以获取解析成功的指令，即解析结果(文本形式)。

所谓解析成功的指令可以是解析得到的指令符合被测试应用的指令要求，能够被被测试应用执行的指令内容。而对于不符合被测试应用的指令要求、不能够被被测试应用执行的指令内容则不会被采纳以用于后续稳定性测试。

在302中，从解析成功的指令中获取出现频率达到预设频率要求的高频指令。

由于解析成功的指令可能是海量的，但往往常用的指令数量级在百个。因此，在本步骤中，从解析成功的指令中选出高频指令。例如选择出现频率超过预设频率阈值的指令作为高频指令，再例如选择出现频率排在前200个的指令作为高频指令。

在303中，对高频指令进行语音合成得到语音指令，构成语音指令的音频集合。

采用语音合成技术对高频指令进行语音合成后，得到各语音指令，这些语音指令就构成了上述的音频集合用以进行实施例一中的稳定性测试。

更进一步地，还可以继续执行304中，将音频集合中的语音指令划分为预设的语音场景。或者，也可以在步骤302之后，对高频指令划分为预设的语音场景，然后再执行303，这样语音指令也就能够对应各语音场景。

然后就能够分场景存储上述音频集合中的各语音指令。

除了本实施例中生成用于稳定性测试的音频集合之外，也可以采用其他方式，例如收集线上大量用户针对被测试应用输入的语音指令，从中筛选出质量满足要求的语音指令构成音频集合。例如筛选出发音清晰、意图明确的语音指令。

以上是对本申请所提供方法进行的详细描述，下面结合实施例对本申请提供的装置进行详细描述。

实施例三、

图4为本申请实施例三提供的语音功能的稳定性测试装置结构图，该装置设置并运行于图1中所示的中控设备中。可以是可以位于中控设备的应用，或者还可以为位于中控设备的应用中的插件或软件开发工具包(softwaredevelopmentkit，sdk)等功能单元。如图4中所示，该装置可以包括：功能启动单元10、音频播放单元20、日志获取单元30和解析判断单元40，还可以进一步包括音频生成单元00。其中各组成单元的主要功能如下：

音频生成单元00，用于从被测试应用的语音功能的历史解析日志中，获取解析成功的指令；从解析成功的指令中获取出现频率达到预设频率要求的高频指令；对高频指令进行语音合成得到语音指令，构成语音指令的音频集合。

功能启动单元10，用于启动被测试应用的语音功能。

具体地，功能启动单元10可以利用自动化测试工具启动被测试应用；向所述被测试应用播放预先生成的唤醒音频，以启动被测试应用的语音功能。

音频播放单元20，用于从预先生成的语音指令的音频集合中逐一选择语音指令向所述被测试应用进行播放，直至达到预设的稳定性执行时长。

在测试过程中，音频播放单元20逐一从音频集合中选择语音指令向被测试应用播放。选择的方式可以是随机选择，也可以按照一定的顺序来选择。

作为一种优选的实施方式，音频集合中的语音指令预先被划分为预设的语音场景；这种情况下，音频播放单元20按照语音场景的顺序，逐一从各语音场景的语音指令中选择语音指令。其中，语音场景的顺序可以随机生成，也可以依据历史记录中各语音场景的使用频率来排序，例如按照从高到底的顺序来排序，还可以人为指定语音场景的顺序，等等。

日志获取单元30，用于获取被测试应用在稳定性测试过程中记录的crash日志。

解析判断单元40，用于对crash日志进行解析，并依据解析结果判断是否达到稳定性测试标准。

具体地，解析判断单元40可以包括：解析子单元41和判断子单元42。

其中，解析子单元41，用于利用符号表文件，对crash日志进行解析，得到crash堆栈信息。

判断子单元42，用于将对被测试应用进行的最新线上测试得到的crash堆栈信息与解析子单元41解析得到的crash堆栈信息进行比对；依据比对得到的新增crash，判断是否达到稳定性测试标准。

具体地，判断子单元42可以判断新增崩溃的数量是否大于或等于预设的数量阈值，如果是，则确定未达到稳定性测试标准，否则确定达到稳定性测试标准。

如果未达到稳定性测试标准，该装置可以提示或触发对被测试应用的语音功能的质量(qa)优化，并在优化结束后再次执行上述稳定性测试方法，直至达到稳定性测试标准。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图5所示，是根据本申请实施例的语音功能的稳定性测试方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图5所示，该电子设备包括：一个或多个处理器501、存储器502，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示gui的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图5中以一个处理器501为例。

存储器502即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的语音功能的稳定性测试方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的语音功能的稳定性测试方法。

存储器502作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的语音功能的稳定性测试方法对应的程序指令/单元。处理器501通过运行存储在存储器502中的非瞬时软件程序、指令以及单元，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的语音功能的稳定性测试方法。

存储器502可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据该电子设备的使用所创建的数据等。此外，存储器502可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器502可选包括相对于处理器501远程设置的存储器，这些远程存储器可以通过网络连接至该电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

该电子设备还可以包括：输入装置503和输出装置504。处理器501、存储器502、输入装置503和输出装置504可以通过总线或者其他方式连接，图5中以通过总线连接为例。

输入装置503可接收输入的数字或字符信息，以及产生与该电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置504可以包括显示设备、辅助照明装置(例如，led)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(lcd)、发光二极管(led)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用asic(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(pld))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

由以上描述可以看出，本申请提供的方法、装置、设备和计算机存储介质可以具备以下优点：

1)本申请提供了一种能够自动进行语音功能稳定性测试的方法，相比较人工下发语音指令进行测试的方式，摆脱了人力束缚，提高了测试效率。

2)在整个稳定性测试过程中，从启动被测试应用、唤醒语音功能、播放语音指令以及判断是否符合稳定性测试标准均无需人工参与，完整地实现了稳定性测试的自动化流程。

3)本申请中通过从语音功能的历史解析日志中获取高频指令，并进行语音合成得到用于测试的语音指令，一方面实现了语音指令的自动生成，另一方面使得测试能够更加充分地覆盖常用的使用场景。

4)本申请中能够分场景播放语音指令来进行稳定性测试，一方面能够更贴合用户的实际使用状况，另一方面，能够更加充分地对语音功能进行稳定性测试。经试验，实际测试场景可以从10种扩展到200种，甚至更多。

5)本申请通过获取稳定性测试过程中的崩溃日志，从中解析出crash堆栈信息，将其与被测试应用进行的最新线上测试得到的crash堆栈信息进行比对，依据比对得到新增crash。这种方式获得新增crash的效率高，且能够将crash问题暴露的时间从灰度阶段(即线上测试阶段)提前到线下测试阶段。

6)通过对新增crash的数量进行判断，能够快速确定待测试应用的语音功能的稳定性是否达到稳定性测试标准。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

起点商标作为专业知识产权交易平台，可以帮助大家解决很多问题，如果大家想要了解更多知产交易信息请点击 【在线咨询】或添加微信 【19522093243】与客服一对一沟通，为大家解决相关问题。

此文章来源于网络,如有侵权,请联系删除