基于轮询测试的异常检测方法、电子设备及存储介质

摘要

本发明实施例公开了一种基于轮询测试的异常检测方法、电子设备及存储介质，首先客户端可以配置包括参考结果信息和场景测试用例的预期结果文档，然后根据场景测试用例生成轮询请求，并向多个服务器端发送轮询请求，而服务器端根据该轮询请求运行场景测试用例，得到测试结果信息，并将该测试结果信息发送至客户端，客户端接收测试结果信息，并将该测试结果信息与预期结果文档中的参考结果信息进行比对，根据比对结果确定该服务器端的运行状态，最后可以通过对运行状态异常的服务器端进行异常检测，因此，本发明实施例可以实现对服务器端的异常检测，进而避免出现轮询中断或报错信息延迟发送的情况。

权利要求

1.一种基于轮询测试的异常检测方法，其特征在于，包括：客户端配置预期结果文档，所述预期结果文档包括参考结果信息和场景测试用例；

所述客户端根据所述场景测试用例生成轮询请求，向多个服务器端发送所述轮询请求；

所述服务器端根据所述轮询请求运行所述场景测试用例，得到测试结果信息，将所述测试结果信息发送至所述客户端；

所述客户端接收所述测试结果信息，将所述测试结果信息与所述参考结果信息进行比对，根据比对结果确定所述服务器端的运行状态；

当确定所述服务器端的运行状态异常，所述客户端对运行状态异常的所述服务器端进行异常检测，所述客户端根据异常状态码的响应类型对所述测试结果信息进行归类处理，得到多个分类集合，所述客户端根据所述多个分类集合生成异常信息列表，所述客户端将所述异常信息列表发送至管理端。

2.根据权利要求1所述的基于轮询测试的异常检测方法，其特征在于，所述根据比对结果确定所述服务器端的运行状态，包括：获取结果反馈时长，所述结果反馈时长为所述客户端向所述服务器端发送所述轮询请求至所述客户端接收到所述服务器端的所述测试结果信息的总时长；

根据所述结果反馈时长和所述比对结果确定所述服务器端的运行状态。

3.根据权利要求2所述的基于轮询测试的异常检测方法，其特征在于，所述根据所述结果反馈时长和所述比对结果确定所述服务器端的运行状态，包括：所述客户端确定预设反馈时长；

当所述结果反馈时长小于或者等于所述预设反馈时长，且所述比对结果表征所述测试结果信息与所述参考结果信息不一致，确定所述服务器端的运行状态异常。

4.根据权利要求3所述的基于轮询测试的异常检测方法，其特征在于，所述根据所述结果反馈时长和所述比对结果确定所述服务器端的运行状态，包括：当所述结果反馈时长大于所述预设反馈时长，所述客户端停止接收所述服务器端的测试结果信息；

所述客户端确定所述服务器端的运行状态异常。

5.根据权利要求1所述的基于轮询测试的异常检测方法，其特征在于，在所述客户端对运行状态异常的所述服务器端进行异常检测之后，所述方法还包括：所述客户端检测语音合成系统的发版状态，所述语音合成系统为发布所述场景测试用例的平台；

当检测到所述语音合成系统的发版状态更新，所述客户端获取更新后的场景测试用例；

所述客户端利用所述更新后的场景测试用例对所述预期结果文档进行更新。

6.根据权利要求1所述的基于轮询测试的异常检测方法，其特征在于，所述场景测试用例包括节日场景测试用例，所述节日场景测试用例包括第一节日场景测试用例和第二节日场景测试用例；

所述客户端根据所述场景测试用例生成轮询请求，向多个服务器端发送所述轮询请求，包括：所述客户端根据所述第一节日场景测试用例生成第一轮询请求；

所述客户端根据所述第二节日场景测试用例生成第二轮询请求；

所述客户端分别向不同的服务器端均发送所述第一轮询请求和所述第二轮询请求。

7.根据权利要求1所述的基于轮询测试的异常检测方法，其特征在于，所述方法还包括：所述客户端确定报文发送时间；

所述客户端统计轮询次数、异常报错次数和各个所述服务器端的当前剩余空间信息，所述轮询次数为所述客户端向所有所述服务器端发送所述轮询请求的次数，所述异常报错次数为确定各个所述服务器端的运行状态异常的次数，所述当前剩余空间信息为所述服务器端在所述报文发送时间的剩余空间；

所述客户端将所述轮询次数、所述异常报错次数和所述各个所述服务器端的当前剩余空间信息生成目标报文；

所述客户端在所述报文发送时间将所述目标报文发送至管理器。

8.一种电子设备，其特征在于，包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至7中任意一项所述的基于轮询测试的异常检测方法。

9.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，所述程序被处理器执行实现权利要求1至7中任意一项所述的基于轮询测试的异常检测方法。

说明书

基于轮询测试的异常检测方法、电子设备及存储介质

技术领域

[0001] 本发明涉及计算机技术领域，特别是涉及一种基于轮询测试的异常检测方法、电子设备及存储介质。

背景技术

[0002] 相关技术中，轮询测试通常是客户端向服务器端请求数据，如果服务器端没有可以立即返回给客户端的数据，则不会立刻返回一个空结果，而是保持这个请求直至数据到来，然后才会将该数据作为结果返回给客户端，所以这会导致轮询请求停留在请求阶段。因此，当客户端向已下线的服务器端请求数据时，客户端则会一直保持这个请求状态，直到服务器端连接超时后，才会有信息展示出来，因此，往往会出现轮询中断或报错信息延迟发送的情况，甚至出现轮询死机的情况。

发明内容

[0003] 以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

[0004] 本发明实施例提供了一种基于轮询测试的异常检测方法、电子设备及存储介质，能够实现对服务器端的异常检测，避免出现轮询中断或报错信息延迟发送的情况。

[0005] 第一方面，本发明实施例提供了一种基于轮询测试的异常检测方法，包括：

[0006] 客户端配置预期结果文档，所述预期结果文档包括参考结果信息和场景测试用例；

[0007] 所述客户端根据所述场景测试用例生成轮询请求，向多个服务器端发送所述轮询请求；

[0008] 所述服务器端根据所述轮询请求运行所述场景测试用例，得到测试结果信息，将所述测试结果信息发送至所述客户端；

[0009] 所述客户端接收所述测试结果信息，将所述测试结果信息与所述参考结果信息进行比对，根据比对结果确定所述服务器端的运行状态；

[0010] 当确定所述服务器端的运行状态异常，所述客户端对运行状态异常的所述服务器端进行异常检测。

[0011] 在一些实施例，所述根据比对结果确定所述服务器端的运行状态，包括：

[0012] 获取结果反馈时长，所述结果反馈时长为所述客户端向所述服务器端发送所述轮询请求至所述客户端接收到所述服务器端的所述测试结果信息的总时长；

[0013] 根据所述结果反馈时长和所述比对结果确定所述服务器端的运行状态。

[0014] 在一些实施例，所述根据所述结果反馈时长和所述比对结果确定所述服务器端的运行状态，包括：

[0015] 所述客户端确定预设反馈时长；

[0016] 当所述结果反馈时长小于或者等于所述预设反馈时长，且所述比对结果表征所述测试结果信息与所述参考结果信息不一致，确定所述服务器端的运行状态异常。

[0017] 在一些实施例，所述根据所述结果反馈时长和所述比对结果确定所述服务器端的运行状态，包括：

[0018] 当所述结果反馈时长大于所述预设反馈时长，所述客户端停止接收所述服务器端的测试结果信息；

[0019] 所述客户端确定所述服务器端的运行状态异常。

[0020] 在一些实施例，当确定所述服务器端的运行状态异常，所述方法还包括：

[0021] 所述客户端根据异常状态码对所述测试结果信息进行归类处理，得到多个分类集合；

[0022] 所述客户端根据所述多个分类集合生成异常信息列表；

[0023] 所述客户端将所述异常信息列表发送至管理端。

[0024] 在一些实施例，在所述客户端对运行状态异常的所述服务器端进行异常检测之后，所述方法还包括：

[0025] 所述客户端检测语音合成系统的发版状态，所述语音合成系统为发布所述场景测试用例的平台；

[0026] 当检测到所述语音合成系统的发版状态更新，所述客户端获取更新后的场景测试用例；

[0027] 所述客户端利用所述更新后的场景测试用例对所述预期结果文档进行更新。

[0028] 在一些实施例，所述场景测试用例包括节日场景测试用例，所述节日场景测试用例包括第一节日场景测试用例和第二节日场景测试用例；

[0029] 所述客户端根据所述场景测试用例生成轮询请求，向多个服务器端发送所述轮询请求，包括：

[0030] 所述客户端根据所述第一节日场景测试用例生成第一轮询请求；

[0031] 所述客户端根据所述第二节日场景测试用例生成第二轮询请求；

[0032] 所述客户端分别向不同的服务器端均发送所述第一轮询请求和所述第二轮询请求。

[0033] 在一些实施例，所述方法还包括：

[0034] 所述客户端确定报文发送时间；

[0035] 所述客户端统计轮询次数、异常报错次数和各个所述服务器端的当前剩余空间信息，所述轮询次数为所述客户端向所有所述服务器端发送所述轮询请求的次数，所述异常报错次数为确定各个所述服务器端的运行状态异常的次数，所述当前剩余空间信息为所述服务器端在所述报文发送时间的剩余空间；

[0036] 所述客户端将所述轮询次数、所述异常报错次数和所述各个所述服务器端的当前剩余空间信息生成目标报文；

[0037] 所述客户端在所述报文发送时间将所述目标报文发送至管理器。

[0038] 第二方面，本发明实施例还提供了一种电子设备，包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现第一方面所述的基于轮询测试的异常检测方法。

[0039] 第三方面，本发明实施例还提供了一种计算机可读存储介质，所述存储介质存储有程序，所述程序被处理器执行实现如第一方面所述的基于轮询测试的异常检测方法。

[0040] 本发明实施例至少包括以下有益效果：

[0041] 本发明实施例提出的一种基于轮询测试的异常检测方法，首先客户端可以配置包括参考结果信息和场景测试用例的预期结果文档，然后根据场景测试用例生成轮询请求，并向多个服务器端发送轮询请求，而服务器端根据该轮询请求运行场景测试用例，得到测试结果信息，并将该测试结果信息发送至客户端，客户端将该测试结果信息与预期结果文档中的参考结果信息进行比对，根据比对结果确定该服务器端的运行状态，最后可以通过对运行状态异常的服务器端进行异常检测，实现了对服务器端的异常检测，进而避免出现轮询中断或报错信息延迟发送的情况。

[0042] 本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

[0043] 附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

[0044] 图1为本发明一个实施例提供的基于轮询测试的异常检测方法的流程示意图；

[0045] 图2为图1中步骤104的一种具体方法的流程示意图；

[0046] 图3为图2中步骤202的一种具体方法的流程示意图；

[0047] 图4为图2中步骤202的另一种具体方法的流程示意图；

[0048] 图5为本发明另一个实施例提供的基于轮询测试的异常检测方法的流程示意图；

[0049] 图6为本发明另一个实施例提供的基于轮询测试的异常检测方法的流程示意图；

[0050] 图7为图1中步骤102的一种具体方法的流程示意图；

[0051] 图8为本发明另一个实施例提供的基于轮询测试的异常检测方法的流程示意图；

[0052] 图9为本发明实施例提供的电子设备的结构示意图。

具体实施方式

[0053] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

[0054] 应了解，在本发明实施例的描述中，若干个的含义是一个以上，多个(或多项)的含义是两个以上，大于、小于、超过等理解为不包括本数，以上、以下、以内等理解为包括本数。如果有描述到“第一”、“第二”等只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先
后关系。

[0055] 除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本发明实施例的目的，不是旨在限制本发明。

[0056] 首先，对本申请中涉及的若干名词进行解析：

[0057] 轮询(Polling)又称“程控输入输出”(Programmed input/output)，其是一种CPU(Central Processing Unit，中央处理器)决策如何提供周边设备服务的方式。轮询法的概念是：由CPU定时发出询问，依序询问每一个周边设备是否需要其服务，若需要服务则给予服务，服务结束后再问下一个周边设备，接着不断周而复始。

[0058] 本申请实施例可以基于轮询测试的场景对运行状态异常的服务器端进行异常检测。

[0059] 轮询测试通常是客户端向服务器端请求数据，如果服务器端没有可以立即返回给客户端的数据，则不会立刻返回一个空结果，而是保持这个请求直至数据到来，然后才会将该数据作为结果返回给客户端，所以这会导致轮询请求停留在请求阶段。因此，当客户端向已下线的服务器请求数据时，客户端则会一直保持这个请求状态，直到服务器端连接超时后，才会有信息展示出来，因此，往往会出现轮询中断或报错信息延迟发送的情况，甚至出现轮询死机的情况。基于此，本发明实施例提供了一种基于轮询测试的异常检测方法、电子设备及存储介质，能够实现对服务器端的异常检测，进而避免出现轮询中断或报错信息延迟发送的情况。

[0060] 本发明实施例提供的基于轮询测试的异常检测方法、电子设备及存储介质，具体通过如下实施例进行说明，首先描述本公开实施例中的基于轮询测试的异常检测方法。

[0061] 参照图1，图1为本发明实施例提供的基于轮询测试的异常检测方法的流程示意图，该基于轮询测试的异常检测方法包括但不限于以下步骤101至步骤105。

[0062] 步骤101：客户端配置预期结果文档，预期结果文档包括参考结果信息和场景测试用例；

[0063] 步骤102：客户端根据场景测试用例生成轮询请求，向多个服务器端发送轮询请求；

[0064] 步骤103：服务器端根据轮询请求运行场景测试用例，得到测试结果信息，将测试结果信息发送至客户端；

[0065] 步骤104：客户端接收测试结果信息，将测试结果信息与参考结果信息进行比对，根据比对结果确定服务器端的运行状态；

[0066] 步骤105：当确定服务器端的运行状态异常，客户端对运行状态异常的服务器端进行异常检测。

[0067] 一可行的实施方式，预期结果文档还可以设置生产环境的IP(Internet Protocol，网际互连协议)地址，其中，生产环境可以包括生产环境服务器主机，而若是生产环境的IP地址失效，预期结果文档可以将该失效的IP地址删除，若是新增了生产环境服务器主机，则可以将其IP地址添加进预期结果文档中，在此不做具体限制。

[0068] 在一实施例中，客户端可以配置包括服务器端IP地址、参考结果信息和场景测试用例的预期结果文档，并根据该场景测试用例生成轮询请求，然后根据该预期结果文档中的服务器端IP地址向对应的服务器端发送轮询请求，而服务器端可以根据轮询请求运行场景测试用例，得到测试结果信息，将测试结果信息发送至客户端，客户端接收测试结果信息，将测试结果信息与参考结果信息进行比对，根据比对结果确定服务器端的运行状态，当确定服务器端的运行状态异常，客户端对运行状态异常的服务器端进行异常检测，因此，本发明实施例可以实现对服务器端的异常检测，进而避免出现轮询中断或报错信息延迟发送的情况。

[0069] 一可行的实施方式，场景测试用例中可以包括场景名称、场景话术以及话术意图等，在此不做具体限制。比如，场景名称为“场景X”，场景话术为“步骤2‑提款金额>账户金额”，话术意图为“输入的金额超过当前账户金额”，则参考结果信息可以为警告消息，比如“账面金额不足”。

[0070] 可以理解的是，预期结果文档中的场景测试用例的数量和参考结果信息的数量均为多个，且场景测试用例与参考结果信息存在对应关系，比如场景测试用例与参考结果信息之间为一一对应关系，或者，参考结果信息与场景测试用例之间为一对多的关系，在此不做具体限制。

[0071] 在一实施例中，客户端可以根据多个场景测试用例生成多个轮询请求，同时发送给多个服务器端，所以，不同的服务器端的轮询请求可以是相同的，也可以不相同，即是说，不同的服务器端运行的场景测试用例可以相同，也可以不同。

[0072] 一可行的实施方式，可以将预期结果文档中的场景测试用例进行优先级排序，根据场景测试用例的优先级生成对应的轮询请求，以此提高服务器端的测试效率。比如，采用“等价类”测试与贪心算法相结合的方法进行场景测试用例优先排序，在此不做具体限制。

[0073] 其中，所谓“等价类”，就是把输入数据的可能值划分为若干的部分，每个部分的数据都和这个部分中的所有数据有相同的性质。基于这个原理：可以确定如果从一个“等价类”的场景测试用例中没有找到缺陷，那么可以合理的认为在这个等价类中其他用例也找不到缺陷。反之亦然。这里根据这个原则，把场景测试用例划分为若干个等价类，然后进行优先级的赋值，使用贪心算法优先选取那些含有最高优先级的场景测试用例“等价类”集合，然后在服务器端运用场景测试用例的过程中，根据运用场景测试用例的过程中发现软件缺陷的场景测试用例“等价类”的情况，改变预期结果文档中场景测试用例的优先级，搜索能够发现缺陷多的场景测试用例“等价类”集。另外，贪心算法是一种不追求最优解，只希望得到较为满意解的方法。由于它省去了为找最优解要穷尽所有可能而必须耗费的大量时间，一般可以快速得到满意的解。贪心算法在选取场景测试用例的过程中，总是优先选取覆盖最多测试覆盖准则的场景测试用例，当所有的测试覆盖准则都被覆盖到时，算法终止。

[0074] 本实施例中，通过采用包括有上述步骤101至步骤105的基于轮询测试的异常检测方法，因此，客户端可以配置包括参考结果信息和场景测试用例的预期结果文档，并根据该场景测试用例生成轮询请求，然后向多个服务器端发送轮询请求，而服务器端可以根据轮询请求运行场景测试用例，得到测试结果信息，将测试结果信息发送至客户端，客户端接收测试结果信息，将测试结果信息与参考结果信息进行比对，根据比对结果确定服务器端的运行状态，当确定服务器端的运行状态异常，客户端对运行状态异常的服务器端进行异常检测，因此，本发明实施例可以实现对服务器端的异常检测，进而避免出现轮询中断或报错信息延迟发送的情况。

[0075] 在一种可能的实现方式中，本发明实施例还引入了结果反馈时长，通过结果反馈时长和比对结果确定服务器端的运行状态。参照图2，图2为本发明实施例提供的确定服务器端的运行状态的流程示意图，上述步骤104中，根据比对结果确定服务器端的运行状态，具体可以包括以下步骤201至步骤202。

[0076] 步骤201：获取结果反馈时长，结果反馈时长为客户端向服务器端发送轮询请求至客户端接收到服务器端的测试结果信息的总时长；

[0077] 步骤202：根据结果反馈时长和比对结果确定服务器端的运行状态。

[0078] 本实施例中，通过采用包括有上述步骤201至步骤202的基于轮询测试的异常检测方法，因此，客户端可以获取结果反馈时长，其中，结果反馈时长为客户端向服务器端发送轮询请求至客户端接收到服务器端的测试结果信息的总时长，接着根据结果反馈时长和比对结果确定服务器端的运行状态，以避免出现客户端发送轮询请求的服务器端已下线的情况，进而避免出现轮询中断或报错信息延迟发送的情况，也避免了轮询死机等情况。

[0079] 在一种可能的实现方式中，对于确定服务器端的运行状态来说，本发明实施例中引入预设反馈时长。然后，根据预设反馈时长、结果反馈时长和比对结果确定服务器端的运行状态。参照图3，图3为本发明实施例提供的确定服务器端的运行状态的具体流程示意图，上述步骤202中，根据结果反馈时长和比对结果确定服务器端的运行状态，具体可以包括以下步骤301至步骤302。

[0080] 步骤301：客户端确定预设反馈时长；

[0081] 步骤302：当结果反馈时长小于或者等于预设反馈时长，且比对结果表征测试结果信息与参考结果信息不一致，确定服务器端的运行状态异常。

[0082] 一可行的实施方式，预设反馈时长可以为1秒、3秒或者其他时长，可以根据实际情况设定，在此不做具体限制。

[0083] 一可行的实施方式，预设反馈时长可以根据用户使用习惯、测试任务类型、服务器端的任务排队情况、服务器端的资源配置量、服务器端的资源已使用量、服务器端的接口使用量、服务器端的接口符合性、服务器端的制式支持情况、客户端的资源配置量、客户端的资源已使用量、客户端的接口使用量、客户端的接口符合性、客户端的制式支持情况等进行自主学习，进而不断调整，在此不做具体限制。

[0084] 本实施例中，通过采用包括有上述步骤301至步骤302的基于轮询测试的异常检测方法，因此，客户端可以确定预设反馈时长，将预设反馈时长与结果反馈时长进行对比，当结果反馈时长小于或者等于预设反馈时长，且比对结果表征测试结果信息与参考结果信息不一致，确定服务器端的运行状态异常，因此，本发明实施例可以设定预设反馈时长，使得客户端及时发现运行状态异常的服务器端，进而及时对运行状态异常的服务器端进行异常检测，以便于管理端可以及时对该运行状态异常的服务器端进行修复。另外，本发明实施例还可以通过设定预设反馈时长以提高轮询测试的效率，降低CPU资源的开销。

[0085] 在一实施例中，客户端可以确定预设反馈时长，将预设反馈时长与结果反馈时长进行对比，当结果反馈时长小于或者等于预设反馈时长，且比对结果表征测试结果信息与参考结果信息一致，确定服务器端的运行状态正常，接着客户端又重新向运行状态正常的服务器端发送轮询请求，再次获取结果反馈时长，并以原本的预设反馈时长与该结果反馈时长进行对比，或者重新确定预设反馈时长，以更新后的预设反馈时长与该结果反馈时长进行对比，当结果反馈时长小于或者等于预设反馈时长，且比对结果表征测试结果信息与参考结果信息不一致，确定服务器端的运行状态异常，客户端对运行状态异常的服务器端进行异常检测；当结果反馈时长小于或者等于预设反馈时长，且比对结果表征测试结果信息与参考结果信息一致，确定服务器端的运行状态正常，客户端又重新向运行状态正常的服务器端发送轮询请求，周而复始，在此不再赘述，本发明实施例对此不做具体限制。

[0086] 举一示例，假设预设反馈时长为3秒，若客户端在预设反馈时长内接收到测试结果信息，则说明结果反馈时长小于或者等于预设反馈时长，那么客户端可以根据测试结果信息和参考结果信息确定服务器端的运行状态，当比对结果表征测试结果信息与参考结果信息一致，确定服务器端的运行状态正常；当比对结果表征测试结果信息与参考结果信息不一致，确定服务器端的运行状态异常，本发明实施例对此不做具体限制。

[0087] 在另一种可能的实现方式中，对于确定服务器端的运行状态来说，参照图4，图4为本发明实施例提供的确定服务器端的运行状态的具体流程示意图，上述步骤202中，根据结果反馈时长和比对结果确定服务器端的运行状态，具体可以包括以下步骤401至步骤402。

[0088] 步骤401：当结果反馈时长大于预设反馈时长，客户端停止接收服务器端的测试结果信息；

[0089] 步骤402：客户端确定服务器端的运行状态异常。

[0090] 本实施例中，通过采用包括有上述步骤401至步骤402的基于轮询测试的异常检测方法，当结果反馈时长大于预设反馈时长，客户端停止接收服务器端的测试结果信息，客户端可以确定服务器端的运行状态异常，因此，本发明实施例可以避免客户端发送轮询请求的服务器端已下线的情况，进而避免出现轮询中断或报错信息延迟发送的情况，也避免了轮询死机等情况。

[0091] 一可行的实施方式，预设反馈时长可以为1秒、3秒或者其他时长，可以根据实际情况设定，在此不做具体限制。

[0092] 一可行的实施方式，预设反馈时长可以根据用户使用习惯、测试任务类型、服务器端的任务排队情况、服务器端的资源配置量、服务器端的资源已使用量、服务器端的接口使用量、服务器端的接口符合性、服务器端的制式支持情况、客户端的资源配置量、客户端的资源已使用量、客户端的接口使用量、客户端的接口符合性、客户端的制式支持情况等进行自主学习，进而不断调整，在此不做具体限制。

[0093] 举一示例，假设预设反馈时长为1秒，若客户端在预设反馈时长内没有接收到测试结果信息，则说明结果反馈时长大于预设反馈时长，因此，客户端可以停止接收服务器端的测试结果信息，并确定该服务器端的运行状态异常，因此，本实施例可以避免客户端发送轮询请求的服务器端已下线的情况，进而避免出现轮询中断或报错信息延迟发送的情况，也避免了轮询死机等情况。

[0094] 当确定服务器端的运行状态异常，参照图5，图5为本发明实施例提供的发送异常信息列表的具体流程示意图，该基于轮询测试的异常检测方法具体可以包括以下步骤501至步骤503。

[0095] 步骤501：客户端根据异常状态码对测试结果信息进行归类处理，得到多个分类集合；

[0096] 步骤502：客户端根据多个分类集合生成异常信息列表；

[0097] 步骤503：客户端将异常信息列表发送至管理端。

[0098] 一可行的实施方式，异常状态码可以是包含异常的HTTP(Hyper Text Transfer Protocol，超文本传输协议)状态码，其中，HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，其中，关于响应的HTTP状态码可以分为五类，即信息响应
(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误(500–599)，比如，200‑请求成功，301‑资源(网页等)被永久转移到其它URL(Uniform Resource Location，统一资源定位符)，404‑请求的资源(网页等)不存在，500‑内部服务器错误等等，在此不再一一列举。因此，异常的HTTP状态码可以分成信息响应(100–199)、重定向(300–399)，客户端错误(400–499)和服务器错误(500–599)，在此不做具体限制。

[0099] 一可行的实施方式，根据异常状态码对测试结果信息进行归类处理，可以又很多实施方式，比如，根据异常状态码的响应类型把测试结果信息分为四类，即信息异常类、重定向类、客户端错误类以及服务器错误类。

[0100] 一可选的实施方式，客户端将异常信息列表发送至管理端，可以有很多实时方式，比如客户端可以通过邮件或者短信的方式将异常信息列表发送至管理端，在此不做具体限制。

[0101] 一可选的实施方式，客户端可以在一次轮询结束(即某次向多个服务器端发送完轮询请求，且在预设反馈时长内接收到该多个服务器端的测试结果信息)之后再将异常信息列表发送至管理端，也可以在多次轮询结束后再将异常信息列表发送至管理端，可以根据实际情况设定，在此不做具体限制。

[0102] 本实施例中，通过采用包括有上述步骤501至步骤503的基于轮询测试的异常检测方法，因此，客户端可以根据异常状态码对测试结果信息进行归类处理，得到多个分类集合，然后根据多个分类集合生成异常信息列表，最后将该异常信息列表发送至管理端，以使管理端可以根据该异常信息列表对运行状态异常的服务器端进行修复。

[0103] 一可行的实施方式，客户端可以将结果反馈时长大于预设反馈时长所对应的服务器端的相关信息(比如IP地址等)加入异常信息列表，以便于管理端可以根据该异常信息列表对运行状态异常的服务器端进行修复。另外，当客户端确定该运行状态异常的服务器端为已下线的服务器端，可以从异常信息列表中删除该服务器端的相关信息，同时，还可以在预期结果文档中删除该服务器端的IP地址等信息。

[0104] 在一种可能的实现方式中，在客户端对运行状态异常的服务器端进行异常检测之后，本发明实施例还引入了语音合成系统的发版状态来获取更新后的场景测试用例，然后利用更新后的场景测试用例更新预期结果文档。参照图6，图6为本发明实施例提供的更新预期结果文档的流程示意图，该基于轮询测试的异常检测方法还可以包括以下步骤601至步骤603。

[0105] 步骤601：客户端检测语音合成系统的发版状态，语音合成系统为发布场景测试用例的平台；

[0106] 步骤602：当检测到语音合成系统的发版状态更新，客户端获取更新后的场景测试用例；

[0107] 步骤603：客户端利用更新后的场景测试用例对预期结果文档进行更新。

[0108] 一可行的实施方式，语音合成系统的发版状态的更新状态是动态的，比如在元旦当天，语音合成系统发布了场景测试用例A，过了X天之后，语音合成系统发布了场景测试用例B，其中，X为自然数，比如，1、2或者5等等。

[0109] 一可行的实施方式，语音合成系统还可以用于合成语音场景话术，并发布对应于语音场景话术的场景测试用例，而客户端可以对利用该场景测试用例生成对应的轮询请求，向多个服务器端发送该轮询请求，以使服务器端根据该轮询请求中的场景测试用例进行测试，通过测试结果信息获取场景话术情况。另外，基于语音合成系统的场景测试用例可以实现对通过语音合成系统所合成的语音进行质量评价，比如，通过判断比对结果中的测试结果信息与在一些实施例，参考结果信息是否一致，确定语音合成系统所合成的语音质量的达标情况，在此不做具体限制。

[0110] 本实施例中，通过采用包括有上述步骤601至步骤603的基于轮询测试的异常检测方法，因此，客户端可以在客户端对运行状态异常的服务器端进行异常检测之后，检测语音合成系统的发版状态，其中，语音合成系统为发布场景测试用例的平台，当检测到语音合成系统的发版状态更新，客户端可以获取更新后的场景测试用例，并利用更新后的场景测试用例对预期结果文档进行更新，以便于提高测试效率，同时也可以避免出现漏测的情况。

[0111] 在一可能的实现方式中，在场景测试用例包括节日场景测试用例，且节日场景测试用例包括第一节日场景测试用例和第二节日场景测试用例的情况下，参照图7，图7为本发明实施例提供的向服务器端发送轮询请求的流程示意图，上述步骤102中，客户端根据场景测试用例生成轮询请求，向多个服务器端发送轮询请求，具体可以包括以下步骤701至步骤703。

[0112] 步骤701：客户端根据第一节日场景测试用例生成第一轮询请求；

[0113] 步骤702：客户端根据第二节日场景测试用例生成第二轮询请求；

[0114] 步骤703：客户端分别向不同的服务器端均发送第一轮询请求和第二轮询请求。

[0115] 本实施例中，通过采用包括有上述步骤701至步骤703的基于轮询测试的异常检测方法，在场景测试用例包括节日场景测试用例，且节日场景测试用例包括第一节日场景测试用例和第二节日场景测试用例的情况下，客户端可以根据第一节日场景测试用例生成第一轮询请求，然后根据在一些实施例，第二节日场景测试用例生成第二轮询请求，最后分别向不同的服务器端均发送在一些实施例，第一轮询请求和在一些实施例，第二轮询请求，本发明实施例对此不做具体限制。

[0116] 一可选的实施方式，第一节日场景测试用例可以是元旦场景测试用例(即元旦当天的场景测试用例)，也可以是元宵场景测试用例，也可以其他日子的场景测试用例，在此不再一一例举。同样地，第二节日场景测试用例也可以是元旦场景测试用例(即元旦当天的场景测试用例)，也可以是元宵场景测试用例等，而且第一节日场景测试用例与第二节日场景测试用例可以不相同。

[0117] 在一可能的实现方式中，本发明实施例还引入了客户端在报文发送时间将目标报文发送至管理器。参考图8，图8为本发明实施例提供的发送目标报文的流程示意图，该基于轮询测试的异常检测方法还可以包括以下步骤801至步骤804。

[0118] 步骤801：客户端确定报文发送时间；

[0119] 步骤802：客户端统计轮询次数、异常报错次数和各个服务器端的当前剩余空间信息；

[0120] 其中，轮询次数为客户端向所有服务器端发送轮询请求的次数，异常报错次数为确定各个服务器端的运行状态异常的次数，当前剩余空间信息为服务器端在报文发送时间的剩余空间；

[0121] 步骤803：客户端将轮询次数、异常报错次数和各个服务器端的当前剩余空间信息生成目标报文；

[0122] 步骤804：客户端在报文发送时间将目标报文发送至管理器。

[0123] 一可行的实施方式，报文发送时间可以是固定时间，也可以是非固定时间，比如，固定时间可以是每8小时为一次报文发送时间，在该8小时内统计对于所有服务器端的轮询次数、异常报错次数以及各个服务器端的当前剩余空间信息等等，本实施例对此不做具体限制。

[0124] 本实施例中，通过采用包括有上述步骤801至步骤804的基于轮询测试的异常检测方法，首先，客户端可以确定报文发送时间，然后统计轮询次数、异常报错次数和各个服务器端的当前剩余空间信息，接着将轮询次数、异常报错次数和各个服务器端的当前剩余空间信息生成目标报文，最后在报文发送时间将目标报文发送至管理器，因此，本发明实施例可以通过向管理器发送目标报文以加强企业的信息记录，节省大量人力和时间成本。

[0125] 在一实施例中，可以根据上述异常检测方法创建函数之间的逻辑关系以执行不同的功能，比如函数A用于向多个服务器端发送轮询请求，并接收服务器端根据轮询请求返回的测试结果信息，函数B用于将测试结果信息与参考结果信息进行比对，若比对结果表征测试结果信息与参考结果信息不一致，根据异常状态码对测试结果信息进行归类处理，得到多个分类集合，根据多个分类集合生成异常信息列表，然后调用函数C通过邮件或者短信将异常信息列表发送至管理器，本发明实施例对此不做具体限制。

[0126] 可以理解的是，虽然上述各个流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本实施例中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

[0127] 一可行的实施方式，在本申请的各个具体实施方式中，当涉及到需要根据目标对象属性信息或属性信息集合等与目标对象特性相关的数据进行相关处理时，都会先获得目标对象的许可或者同意，而且，对这些数据的收集、使用和处理等，都会遵守相关国家和地区的相关法律法规和标准。此外，当本申请实施例需要获取目标对象属性信息时，会通过弹窗或者跳转到确认页面等方式获得目标对象的单独许可或者单独同意，在明确获得目标对象的单独许可或者单独同意之后，再获取用于使本申请实施例能够正常运行的必要的目标对象相关数据。

[0128] 参照图9，图9为本发明实施例提供的电子设备的结构示意图。电子设备1000包括：存储器1001、处理器1002及存储在存储器1001上并可在处理器1002上运行的计算机程序，计算机程序运行时用于执行上述的基于轮询测试的异常检测方法。

[0129] 处理器1002和存储器1001可以通过总线或者其他方式连接。

[0130] 存储器1001作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序，如本发明实施例描述的基于轮询测试的异常检测方法。处理器1002通过运行存储在存储器1001中的非暂态软件程序以及指令，从而实现上述的基于轮询测试的异常检测方法。

[0131] 存储器1001可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储执行上述的基于轮询测试的异常检测方法。此外，存储器1001可以包括高速随机存取存储器1001，还可以包括非暂态存储器1001，例如至少一个储存设备存储器件、闪存器件或其他非暂态固态存储器件。在一些实施方式中，存储器1001可选包括相对于处理器1002远程设置的存储器1001，这些远程存储器
1001可以通过网络连接至该电子设备1000。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

[0132] 实现上述的基于轮询测试的异常检测方法所需的非暂态软件程序以及指令存储在存储器1001中，当被一个或者多个处理器1002执行时，执行上述的基于轮询测试的异常检测方法。

[0133] 本公开实施例描述的实施例是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。

[0134] 本领域技术人员可以理解的是，图1‑8中示出的技术方案并不构成对本公开实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。

[0135] 以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

[0136] 本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

[0137] 本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

[0138] 应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

[0139] 在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

[0140] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

[0141] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

[0142] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式
体现出来，该计算机软件产品存储在一个存储介质中，包括多指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read‑Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序的介质。

[0143] 以上参照附图说明了本公开实施例的优选实施例，并非因此局限本公开实施例的权利范围。本领域技术人员不脱离本公开实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本公开实施例的权利范围之内。