CN107800889B - 呼叫逻辑测试方法和装置 - Google Patents

Abstract

本发明涉及一种呼叫逻辑测试方法和装置，该方法包括：通过呼叫系统数据库中设置的脚本初始化测试数据，所述测试数据为待呼数据；调用导入逻辑将所述待呼数据写入到待呼表中；获取预先设置的过滤器规则表，从所述过滤器规则表中获取待测试的过滤器ID，并查找与所述过滤器ID对应的过滤器规则信息，所述过滤器规则信息包括取数条件；根据所述取数条件从所述待呼表中读取所述待呼数据，根据读取结果对所述导入逻辑和所述过滤器规则信息进行校验测试。降低了生产问题的发生率。

Description

呼叫逻辑测试方法和装置

技术领域

本发明涉及计算机技术领域，特别是涉及一种呼叫逻辑测试方法和装置。

背景技术

随着科学技术的发展，呼叫中心进行电话呼叫时，不需要客服人员通过电话机手动拨号完成呼叫。通常可通过呼叫系统将待呼数据导入到待呼表中，然后由拨号平台根据设置的过滤器规则信息(即指用于从待呼表中读取待呼数据来完成呼叫处理的取数规则)来读取待呼表中的待呼数据，根据读取到的待呼数据来拨打电话。

通常在使用上述呼叫方法时，需要对过滤器规则信息进行测试，以保证能够正确的从呼叫系统的待呼表中读取到待呼数据。然而，对于一个呼叫中心来说，由于涉及的业务类型众多，往往会涉及到几百上千个过滤器规则信息。

传统方法中，在对过滤器规则信息进行测试时，会在拨号平台的测试环境内，准备与该过滤器规则信息对应的测试场景进行测试(每个过滤器规则信息需要准备一个测试场景)。显然，如果针对几百上千个过滤器规则信息都一一准备测试场景，进行全量手工测试耗时非常长。鉴于对版本测试时间的限制，通常只会随机的准备某一些场景进行测试，而无法实现全量测试。这样一来，就很容易造成漏洞，容易发生生产问题。

发明内容

基于此，有必要提供一种能够降低生产问题发生率的呼叫逻辑测试方法和装置。

一种呼叫逻辑测试方法，所述方法包括以下步骤：

通过呼叫系统数据库中设置的脚本初始化测试数据，所述测试数据为待呼数据；

调用导入逻辑将所述待呼数据写入到待呼表中；

获取预先设置的过滤器规则表，从所述过滤器规则表中获取待测试的过滤器ID，并查找与所述过滤器ID对应的过滤器规则信息，所述过滤器规则信息包括取数条件；

根据所述取数条件从所述待呼表中读取所述待呼数据，根据读取结果对所述导入逻辑和所述过滤器规则信息进行校验测试。

在其中一个实施例中，所述根据所述取数条件从所述待呼表中读取所述待呼数据的步骤，包括：

根据所述取数条件中包括的待呼数据状态、专案号和呼叫类型从所述待呼表中读取对应的待呼数据；或

根据所述取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从所述待呼表中读取对应的待呼数据。

在其中一个实施例中，根据读取结果对所述导入逻辑进行校验测试的步骤，包括：

当读取到对应的所述待呼数据时，则判定所述导入逻辑的数据导入功能正常。

在其中一个实施例中，所述方法还包括：

当所述过滤器规则信息对应的过滤器规则类型为首轮呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否小于1，且在所述待呼表中的对应标记字段是否为0，若是，则判定对应的所述过滤器规则信息正确。

在其中一个实施例中，所述方法还包括：

当所述过滤器规则信息对应的过滤器规则类型为多遍次呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否大于0，且在所述待呼表中的对应标记字段是否大于0，若是，则判定对应的所述过滤器规则信息正确。

在其中一个实施例中，所述方法还包括：

当所述过滤器规则信息对应的过滤器规则类型为预约呼出时，则校验读取到的所述待呼数据中包含的预约数据是否不为空，且在所述待呼表中的对应标记字段不为空，若是，则判定对应的所述过滤器规则信息正确。

一种呼叫逻辑测试装置，所述装置包括：

待呼数据准备模块，用于通过呼叫系统数据库中设置的脚本初始化测试数据，所述测试数据为待呼数据；

写入模块，用于调用导入逻辑将所述待呼数据写入到待呼表中；

过滤器规则信息获取模块，用于获取预先设置的过滤器规则表，从所述过滤器规则表中获取待测试的过滤器ID，并查找与所述过滤器ID对应的过滤器规则信息，所述过滤器规则信息包括取数条件；

校验测试模块，用于根据所述取数条件从所述待呼表中读取所述待呼数据，根据读取结果对所述导入逻辑和所述过滤器规则信息进行校验测试。

在其中一个实施例中，所述校验测试模块还用于根据所述取数条件中包括的待呼数据状态、专案号和呼叫类型从所述待呼表中读取对应的待呼数据；或根据所述取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从所述待呼表中读取对应的待呼数据。

在其中一个实施例中，所述校验测试模块还用于当读取到对应的所述待呼数据时，则判定所述导入逻辑的数据导入功能正常。

在其中一个实施例中，所述校验测试模块还用于当所述过滤器规则信息对应的过滤器规则类型为首轮呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否小于1，且在所述待呼表中的对应标记字段是否为0，若是，则判定对应的所述过滤器规则信息正确。

在其中一个实施例中，所述校验测试模块还用于当所述过滤器规则信息对应的过滤器规则类型为多遍次呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否大于0，且在所述待呼表中的对应标记字段是否大于0，若是，则判定对应的所述过滤器规则信息正确。

在其中一个实施例中，所述校验测试模块还用于当所述过滤器规则信息对应的过滤器规则类型为预约呼出时，则校验读取到的所述待呼数据中包含的预约数据是否不为空，且在所述待呼表中的对应标记字段不为空，若是，则判定对应的所述过滤器规则信息正确。

上述呼叫逻辑测试方法和装置，通过呼叫系统数据库中设置的脚本初始化测试数据，所述测试数据为待呼数据；调用导入逻辑将所述待呼数据写入到待呼表中；获取预先设置的过滤器规则表，从所述过滤器规则表中获取待测试的过滤器ID，并查找与所述过滤器ID对应的过滤器规则信息，所述过滤器规则信息包括取数条件；根据所述取数条件从所述待呼表中读取所述待呼数据，根据读取结果对所述导入逻辑和所述过滤器规则信息进行校验测试。相当于在呼叫系统数据库层面设置了准备测试数据的脚本、过滤器规则表以及校验测试逻辑，通过配置的过滤器规则表，可以依次地、自动的根据校验测试逻辑对所配置的全部过滤器规则信息进行校验测试，即实现了全量测试，降低了生产问题的发生率。

附图说明

图1为一个实施例中呼叫逻辑测试方法的应用环境示意图；

图2为一个实施例中服务器的内部结构图；

图3为一个实施例中呼叫逻辑测试方法的流程示意图；

图4为一个实施例中呼叫逻辑测试装置的结构示意图。

具体实施方式

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

图1为一个实施例中呼叫逻辑测试方法的应用环境图。如图1所示，服务器110通过网络与终端120进行通信。服务器110通过数据库中预先设置的脚本初始化测试数据，其中，测试数据为待呼数据。调用导入逻辑将待呼数据写入到待呼表中。服务器110从预先设置的过滤器规则表中获取待测试的过滤器ID，并查找与过滤器ID对应的过滤器规则信息，其中，过滤器规则信息包括取数条件。进一步，服务器110根据取数条件从待呼表中读取待呼数据，根据读取结果对导入逻辑和过滤器规则信息进行校验测试。进一步，服务器110会记录测试结果，将测试结果发送至终端120。

可以理解，终端120包括但不限于各种个人计算机、智能手机、平板电脑、笔记本电脑、便携式穿戴设备等，在此不一一列举。

图2示出了一个实施例中的服务器110的内部结构示意图，该服务器包括通过系统总线连接的处理器、非易失性存储介质、内存储器和网络接口。其中，该服务器的非易失性存储介质存储有操作系统、数据库和一种呼叫逻辑测试装置，数据库用于存储数据，如过滤器规则表等。该呼叫逻辑测试装置用于实现一种呼叫逻辑测试方法。该处理器用于提供计算和控制能力，支撑整个服务器的运行。服务器中的内存储器为非易失性存储介质中的呼叫逻辑测试装置的运行提供环境，该内存储器中可储存有计算机可读指令，该计算机可读指令被所述处理器执行时，可使得所述处理器执行一种呼叫逻辑测试方法。网络接口用于与终端进行网络通信。本领域技术人员可以理解，图2中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

如图3所示，在一个实施例中，提供了一种呼叫逻辑测试方法，现以该方法应用于服务器为例进行举例说明，该方法具体包括以下步骤：

步骤302，通过呼叫系统数据库中设置的脚本初始化测试数据，测试数据为待呼数据。

本实施例中，在呼叫系统的数据库中设置了呼叫逻辑测试装置。

呼叫逻辑测试装置会运行数据库中预先设置的脚本，通过该脚本准备测试数据(即初始化测试数据)。其中，准备的测试数据为待呼数据，即为待进行呼叫的数据。

可以理解，准备的待呼数据可以是覆盖了所有场景的数据。

步骤304，调用导入逻辑将待呼数据写入到待呼表中。

进一步，呼叫逻辑测试装置会调用呼叫系统中设置的导入逻辑，通过该导入逻辑将待呼数据写入到待呼表中。

其中，将待呼数据导入到待呼表时，导入逻辑会分析待呼数据，并针对待呼数据中的预设参数的值在待呼表中的对应字段进行对应标记。其中，预设参数包括专案号、有效回访的呼出次数、进行预约操作的时间和预约拨打时间、待呼数据状态、呼叫类型中的至少一种。比如，导入逻辑分析待呼数据，确定待呼数据属于专案001，则将待呼数据写入待呼表时，会在待呼表对应于专案号的字段标记上专案号001。又比如，当分析待呼数据，确定呼叫类型为预约类，且预约拨打时间为17：00，则在待呼表对应于呼叫类型的字段标记上预约类的标识，并在预约拨打时间进行格式转换，在待呼表中对应于预约拨打时间的字段标记上格式转换后的时间。

步骤306，获取预先设置的过滤器规则表，从过滤器规则表中获取待测试的过滤器ID，并查找与过滤器ID对应的过滤器规则信息，过滤器规则信息包括取数条件。

具体地，呼叫系统数据库中预先设置了过滤器规则表。

其中，过滤器规则表中包括过滤器ID和对应的过滤器规则信息。过滤器ID用于唯一标识过滤器规则信息。

可以理解，过滤器规则信息是指用于从待呼表中读取待呼数据来完成呼叫处理的取数规则。过滤器规则信息包括取数条件。其中，取数条件，即指以sql脚本的形式表达的取数逻辑。可以理解，查找到的取数条件与拨号平台中的过滤器取数逻辑一致。

过滤器规则信息还可以包括过滤器名称、关联的专案号、过滤器规则类型等信息。进一步，过滤器规则类型包括首轮呼出、多遍次呼出以及预约呼出。其中，首轮呼出的过滤器规则，是指提取出历史的有效回访次数为零的待呼数据的过滤器规则。进一步，有效回访次数为零，包括之前的无效呼出和未呼出的。多遍次呼出的过滤器规则，是指提取出历史的有效回访的呼出次数为至少一次的待呼数据的过滤器规则。预约呼出的过滤器规则，是指提取出预约了呼叫时间的待呼数据的过滤器规则。

需要说明的是，这里的过滤器规则表中的信息与拨号平台中的过滤器信息一致。可以理解，因为是要对实际的拨号平台中的过滤器信息进行测试，因此，进行测试使用的过滤器规则表的信息需要与实际的过滤器信息一致，才能够起到测试的目的。

进一步，呼叫逻辑测试装置会获取预先设置的过滤器规则表。并从过滤器规则表中获取待测试的过滤器ID。并查找与过滤器ID对应的过滤器规则信息。

其中，过滤器规则表中的过滤器ID为一个或多个。

具体地，当有多个过滤器ID时，则可以是根据过滤器ID的顺序依次选取出过滤器ID进行依次测试。也可以是，根据过滤器ID对应的过滤器规则类型，以过滤规则类型为单位来进行依次测试，即先测试完一个过滤器规则类型的过滤器规则信息，再测试下一个过滤器规则类型的过滤器规则信息。还可以是，随机获取过滤器ID进行测试，直接测试完所有的过滤器ID对应的过滤器规则信息。这里，对获取待测试的过滤器ID的方式不作限定。

步骤308，根据取数条件从待呼表中读取待呼数据，根据读取结果对导入逻辑和过滤器规则信息进行校验测试。

呼叫逻辑测试装置会根据取数条件从待呼表中读取待呼数据。并根据读取结果对导入逻辑和过滤器规则信息进行校验测试。

其中，读取结果包括读取到对应的待呼数据或读取不到对应的待呼数据。可以理解，在读取不到对应的待呼数据时，则说明呼叫系统的导入逻辑的数据导入功能异常，即没有把待呼数据导入到待呼表，所以导致无法读取到对应的待呼数据。

进一步，当读取到待呼数据时，则可以判定导入逻辑的数据导入功能正常，即导入逻辑能够将待呼数据导入到待呼表中。更进一步，当读取到待呼数据时，还可以进一步判断过滤器规则信息是否正确。具体地，可以获取校验该过滤器规则信息的校验逻辑，根据该校验逻辑和通过过滤器规则信息中的取数条件所读取到的待呼数据，来判断过滤器规则信息是否正确。

进一步，呼叫逻辑测试装置还可以记录测试结果，将测试结果发送至终端。

本实施例中，通过呼叫系统数据库中设置的脚本初始化测试数据，测试数据为待呼数据；调用导入逻辑将待呼数据写入到待呼表中；获取预先设置的过滤器规则表，从过滤器规则表中获取待测试的过滤器ID，并查找与过滤器ID对应的过滤器规则信息，过滤器规则信息包括取数条件；根据取数条件从待呼表中读取待呼数据，根据读取结果对导入逻辑和过滤器规则信息进行校验测试。相当于在呼叫系统数据库层面设置了准备测试数据的脚本、过滤器规则表以及校验测试逻辑，通过配置的过滤器规则表，可以依次地、自动的根据校验测试逻辑对所配置的全部过滤器规则信息进行校验测试，即实现了全量测试，降低了生产问题的发生率。此外，不需要一个过滤器规则信息准备一个测试环境，大大加快了测试效率，即保证了全量测试的同时又提高了测试效率。

在一个实施例中，根据取数条件从待呼表中读取待呼数据的步骤，包括：根据取数条件中包括的待呼数据状态、专案号和呼叫类型从待呼表中读取对应的待呼数据；或根据取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从待呼表中读取对应的待呼数据的步骤。

具体地，在一个实施例中，取数条件包括待呼数据状态、专案号和呼叫类型。其中，待呼数据状态包括已读取和未读取。专案号指过滤器规则信息所属的专案的唯一标识，即应用该过滤器规则信息读取哪个专案的待呼数据。专案即指对业务进行的立案命名。呼叫类型包括预约类和非预约类。

进一步，呼叫逻辑测试装置会根据取数条件中包括的待呼数据状态、专案号和呼叫类型从待呼表中读取对应的待呼数据。具体地，可以是读取与取数条件中包括的专案号对应的处于未读取状态的预约类或非预约类的待呼数据。可以理解，至于根据这三个因素(待呼数据状态、专案号和呼叫类型)提取待呼数据的先后顺序不作限定。比如，A、B和C三个筛选因素，可以先筛选符合A的待呼数据，然后进一步从符合A的待呼数据中筛选出符合B的待呼数据，更进一步，再进一步筛选出符合B的待呼数据中筛选出符合C的待呼数据作为最终读取的待呼数据。可以理解，A、B和C的筛选顺序可以调换，这里对此不做限定，仅满足能够根据这三个因素来读取待呼数据即可。

在另一个实施例中，取数条件除了待呼数据状态、专案号、呼叫类型以外，还包括有效回访的呼出次数，有效回访的呼出次数为整数。其中，有效回访，是指达到预设条件的呼出。比如，呼叫时通话时长超过预设时长即为有效回访。还可以是其他预设条件，这里对此不做限定。取数条件中设置的呼叫次数包括零次或一次及以上。

可以理解，呼叫次数为零次时，则表明尚未对待呼数据进行有效呼出或尚未对待呼数据发起呼叫，即为首轮呼出。呼叫次数为一次及以上，则表明之前对待呼数据已经呼叫过了，可能由于一些业务需求，需要对待呼数据进行多遍次呼叫，则会将已经有过呼叫历史的待呼数据重新导入到待呼表中进行多遍次呼叫，并于待呼表中对应标记上呼叫次数。

本实施例中，呼叫逻辑测试装置会根据取数条件中包括的待呼数据状态、专案号、呼叫类型和呼叫次数从待呼表中读取对应的待呼数据。具体地，可以是读取与取数条件中专案号对应的处于未读取状态的预约类或非预约类的、且满足取数条件中的呼叫次数的待呼数据。同样的，至于根据这四个因素(待呼数据状态、专案号、呼叫类型和呼叫次数)提取待呼数据的先后顺序不作限定。

在一个实施例中，在读取到待呼数据后，还会对过滤器规则信息进行校验。该方法还包括：获取校验该过滤器规则信息的校验逻辑，根据该校验逻辑和通过过滤器规则信息中的取数条件所读取到的待呼数据，来校验过滤器规则信息是否正确。

在一个实施例中，获取校验该过滤器规则信息的校验逻辑的步骤，包括：获取与过滤器ID绑定的过滤器规则信息校验逻辑。

具体地，服务器中预先设置了过滤器规则信息校验逻辑与过滤器ID之间的绑定关系，根据该绑定关系，获取与过滤器ID绑定的过滤器规则信息校验逻辑。

在另一个实施例中，获取校验该过滤器规则信息的校验逻辑的步骤，包括：检测过滤器规则信息对应的过滤器规则类型，获取与该过滤器规则类型对应的过滤器规则信息校验逻辑。

具体地，通过过滤器规则表，查找过滤器规则信息对应的过滤器规则类型。并根据预设的过滤器规则类型和过滤器规则信息校验逻辑之间的对应关系，获取与查找到的过滤器规则类型对应的过滤器规则信息校验逻辑。如前文所述，过滤器规则类型包括首轮呼出、多遍次呼出和预约呼出。可以理解，还可以根据实际需要设置对应的过滤器规则类型。通过过滤器规则类型层级来设置对应的过滤器规则信息校验逻辑，而不用针对各个过滤器规则信息一一设置对应的校验逻辑，避免了代码的冗余。

进一步地，呼叫逻辑测试装置根据该过滤器规则信息校验逻辑和读取到的待呼数据对过滤器规则信息进行校验。具体地，校验通过该过滤器规则信息中的取数条件读取到的待呼数据的信息以及在待呼表中对应的标记字段是否满足过滤器规则信息校验逻辑中的预设条件。其中，待呼数据的信息包括有效回访的呼出次数和/或预约数据。不同的过滤器规则信息校验逻辑中的预设条件不同。达到了预设条件，则说明过滤器规则信息读取到的待呼数据是正确的。即过滤器规则信息能够正确的读取到待呼数据。

在一个实施例中，当过滤器规则类型为首轮呼出时，则校验读取到的待呼数据中包含的有效回访的呼出次数是否小于1，且校验该待呼数据在待呼表中对应于有效回访的呼出次数的标记字段是否为0。当读取到待呼数据中包含的有效回访的呼出次数小于1，且在待呼表中对应于呼出次数的标记字段为0，则判定对应的过滤器规则信息正确。

在一个实施例中，当过滤器规则信息对应的过滤器规则类型为多遍次呼出时，则校验读取到的待呼数据中包含的有效回访的呼出次数是否大于0，且在待呼表中对应于有效回访的呼出次数的对应标记字段是否大于0。当读取到待呼数据中包含的有效回访的呼出次数大于0，且在待呼表中对应于呼出次数的标记字段大于0，则判定对应的过滤器规则信息正确。

进一步，在一个实施例中，当读取到待呼数据中包含的有效回访的呼出次数大于0，且在待呼表中对应于呼出次数的标记字段大于0时，还可以进一步校验待呼数据中包含的有效回访的呼出次数与待呼表中对应于呼出次数的标记字段是否一致，若是，则判定对应的过滤器规则信息正确。

在一个实施例中，当过滤器规则信息对应的过滤器规则类型为预约呼出时，则校验读取到的待呼数据中包含的预约数据是否不为空，且在待呼表中对应于预约数据的标记字段不为空，若是，则判定对应的过滤器规则信息正确。其中，预约数据包括预约拨打时间。进一步，预约数据还可以包括进行预约操作的时间。比如，操作人员15：00进行预约操作，预约到17：00来针对待呼数据发起呼叫。则15：00即为进行预约操作的时间，17：00即为预约拨打时间。

如图4所示，在一个实施例中，提供了一种呼叫逻辑测试装置400，该装置包括待呼数据准备模块402、写入模块404、过滤器规则信息获取模块406以及校验测试模块408，其中：

待呼数据准备模块402，用于通过呼叫系统数据库中设置的脚本初始化测试数据，测试数据为待呼数据。

写入模块404，用于调用导入逻辑将待呼数据写入到待呼表中。

过滤器规则信息获取模块406，用于获取预先设置的过滤器规则表，从过滤器规则表中获取待测试的过滤器ID，并查找与过滤器ID对应的过滤器规则信息，过滤器规则信息包括取数条件。

校验测试模块408，用于根据取数条件从待呼表中读取待呼数据，根据读取结果对导入逻辑和过滤器规则信息进行校验测试。

在一个实施例中，校验测试模块408还用于根据取数条件中包括的待呼数据状态、专案号和呼叫类型从待呼表中读取对应的待呼数据；或根据取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从待呼表中读取对应的待呼数据。

在一个实施例中，校验测试模块408还用于根据取数条件中包括的待呼数据状态、专案号和呼叫类型从待呼表中读取对应的待呼数据；或根据取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从待呼表中读取对应的待呼数据。

在一个实施例中，校验测试模块408还用于当读取到对应的待呼数据时，则判定导入逻辑的数据导入功能正常。

在一个实施例中，校验测试模块408还用于当过滤器规则信息对应的过滤器规则类型为首轮呼出时，则校验读取到的待呼数据中包含的有效回访的呼出次数是否小于1，且在待呼表中的对应标记字段是否为0，若是，则判定对应的过滤器规则信息正确。

在一个实施例中，校验测试模块408还用于当过滤器规则信息对应的过滤器规则类型为多遍次呼出时，则校验读取到的待呼数据中包含的有效回访的呼出次数是否大于0，且在待呼表中的对应标记字段是否大于0，若是，则判定对应的过滤器规则信息正确。

在一个实施例中，校验测试模块408还用于当过滤器规则信息对应的过滤器规则类型为预约呼出时，则校验读取到的待呼数据中包含的预约数据是否不为空，且在待呼表中的对应标记字段不为空，若是，则判定对应的过滤器规则信息正确。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种呼叫逻辑测试方法，所述方法包括以下步骤：

通过呼叫系统数据库中设置的脚本初始化测试数据，所述测试数据为待呼数据；

调用导入逻辑将所述待呼数据写入到待呼表中；

获取预先设置的过滤器规则表，从所述过滤器规则表中获取待测试的过滤器ID，并查找与所述过滤器ID对应的过滤器规则信息，所述过滤器规则信息包括取数条件；

根据所述取数条件中包括的待呼数据状态、专案号和呼叫类型从所述待呼表中读取对应的待呼数据；或，根据所述取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从所述待呼表中读取对应的待呼数据；

根据读取结果对所述导入逻辑和所述过滤器规则信息进行校验测试。

2.根据权利要求1所述的方法，其特征在于，根据读取结果对所述导入逻辑进行校验测试的步骤，包括：

当读取到对应的所述待呼数据时，则判定所述导入逻辑的数据导入功能正常。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

当所述过滤器规则信息对应的过滤器规则类型为首轮呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否小于1，且在所述待呼表中的对应标记字段是否为0，若是，则判定对应的所述过滤器规则信息正确。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

当所述过滤器规则信息对应的过滤器规则类型为多遍次呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否大于0，且在所述待呼表中的对应标记字段是否大于0，若是，则判定对应的所述过滤器规则信息正确。

5.根据权利要求2所述的方法，其特征在于，所述方法还包括：

当所述过滤器规则信息对应的过滤器规则类型为预约呼出时，则校验读取到的所述待呼数据中包含的预约数据是否不为空，且在所述待呼表中的对应标记字段不为空，若是，则判定对应的所述过滤器规则信息正确。

6.一种呼叫逻辑测试装置，其特征在于，所述装置包括：

待呼数据准备模块，用于通过呼叫系统数据库中设置的脚本初始化测试数据，所述测试数据为待呼数据；

写入模块，用于调用导入逻辑将所述待呼数据写入到待呼表中；

过滤器规则信息获取模块，用于获取预先设置的过滤器规则表，从所述过滤器规则表中获取待测试的过滤器ID，并查找与所述过滤器ID对应的过滤器规则信息，所述过滤器规则信息包括取数条件；

校验测试模块，用于根据所述取数条件中包括的待呼数据状态、专案号和呼叫类型从所述待呼表中读取对应的待呼数据；或根据所述取数条件中包括的待呼数据状态、专案号、呼叫类型和有效回访的呼出次数从所述待呼表中读取对应的待呼数据；根据读取结果对所述导入逻辑和所述过滤器规则信息进行校验测试。

7.根据权利要求6所述的装置，其特征在于，所述校验测试模块还用于当读取到对应的所述待呼数据时，则判定所述导入逻辑的数据导入功能正常。

8.根据权利要求7所述的装置，其特征在于，所述校验测试模块还用于当所述过滤器规则信息对应的过滤器规则类型为首轮呼出时，则校验读取到的所述待呼数据中包含的有效回访的呼出次数是否小于1，且在所述待呼表中的对应标记字段是否为0，若是，则判定对应的所述过滤器规则信息正确。

9.一种服务器，其特征在于，包括存储器和处理器，所述存储器中存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行权利要求1至5中任一项所述方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至5中任一项所述方法的步骤。