CN117950985A - 搜索引擎的存储性能测试方法及相关设备 - Google Patents

Abstract

本申请公开了一种搜索引擎的存储性能测试方法及相关设备。所述方法包括：基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中所述测试数据源为多种数据源中的其中一种；通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

Description

搜索引擎的存储性能测试方法及相关设备

技术领域

本申请涉及测试技术领域，尤其涉及一种搜索引擎的存储性能测试方法及相关设备。

背景技术

基于搜索引擎的存储数据应用很广泛，底层可以设计多分片、多节点、多副本数来保证存储数据的高可用性。对搜索引擎的存储性能进行测试，对于保证存储数据的高可用性而言，尤为重要。

目前对于搜索引擎的存储性能测试通过人工完成，即由测试人员构造测试数据并手动存储至搜索引擎中，再登录搜索引擎执行查询操作，判断测试数据是否正确、完整的存储到搜索引擎中。然而，人工构造的测试数据单一，无法满足多样化场景下的测试需求；另外，人工测试方式耗时耗力，且存在很多不稳定性，如在登录搜索引擎执行查询操作时，输错登录信息或者查询语句，导致查询结果不准确，进而影响测试结果。

发明内容

本申请实施例的目的提供一种搜索引擎的存储性能测试方法及相关设备。

为了实现上述目的，本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种搜索引擎的存储性能测试方法，包括：

基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

第二方面，本申请实施例提供一种搜索引擎的存储性能测试装置，包括：

构造单元，用于基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

测试单元，用于通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

生成单元，用于基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

第三方面，本申请实施例提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：针对已部署的多种测试数据源中的任一种，测试数据源的数据存储结构，构造测试数据并写入测试数据源中，以便在测试过程中从测试数据源获取测试数据并转储至搜索引擎；由于多种测试数据源分别针对不同的业务场景，通过上述测试方法可以模拟和测试搜索引擎在不同业务场景下的存储性能，确保经过测试的搜索引擎能够满足多样化业务场景下的高可用性需求；在此基础上，利用预设的单元测试框架自带的测试类，执行测试数据源对应的转储任务，从测试数据源中获取测试数据并转储至搜索引擎中，通过查询搜索引擎中存储的数据，并结合转储任务获取的测试数据生成第一测试结果，即可实现对搜索引擎的存储性能的测试；由此，对搜索引擎的测试不需要人工参与，而是利用单元测试框架自带的测试类的自动完成，进而可以减少人力资源、提高测试效率，并且，自动测试过程不受人为因素的影响，可以有效避免因人为疏忽导致的测试不稳定的问题，从而可以提高测试稳定性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的搜索引擎的存储性能测试方法所适用的一种实施环境的示意图；

图2为本申请的一个实施例提供的一种搜索引擎的存储性能测试方法的流程示意图；

图3为本申请的一个实施例提供的一种搜索引擎的存储性能测试过程的示意图；

图4为本申请的一个实施例提供的一种搜索引擎的存储性能测试装置的结构示意图；

图5为本申请的一个实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应理解，这样使用的数据在适当情况下可以互换，以便本申请实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，本说明书和权利要求书中“和/或”表示所连接对象的至少其中之一，字符“/”一般表示前后关联对象是一种“或”的关系。

部分概念说明：

ElasticSearch：简称ES，是一个基于Lucence的搜索服务器。ES提供了一个分布式多用户能力的全文搜索引擎，可基于RESTful Web接口操作ES，也可以利用Java API操作ES。ES是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，具有稳定、可靠、快速、安装使用方便等优点。

ES的映射(Mapping)：类似于静态语言中的数据类型。比如声明一个int类型的变量，那以后这个变量只能存储int类型的数据；比如声明一个double类型的mapping字段，则只能存储double类型的数据。

索引：是映射类型的容器。一个ES的索引类似于关系型数据库，是独立的大量文档集合。一个ES的索引可以包括主索引、mobile索引和push索引，不同索引用于存储的数据不同，都存在当前索引(当前日期后缀)和下一个索引(下一日期后缀)。

python调接口：使用python的请求(requests)模块，针对超文本传输协议(HyperText Transfer Protocol，HTTP)、特定的接口地址、特定的请求体，来发送get、post等请求，实现这些特定的接口功能。

python调重置索引接口：python调重置索引接口，清空指定索引中的数据，其中，指定索引可以包括如下索引中的至少一种：主索引、mobile索引及push索引等。

python调插入存储任务接口：python调newInsertEsTask接口，实现：删除zookeeper存储任务的成功标识，拆分多个转储任务去数据仓库的指定数据表中读取数据转储到搜索引擎的指定索引中。

Zookeeper存储任务：由分布式集群Zookeeper管理并记录转储任务，包括：记录搜索引擎的指定索引对应的多个子任务的各状态：int、running、success；记录指定索引是否转储成功的标志位：succ。通过python请求接口的方式来获取标志位是否成功，通过判断接口响应中是否存在succ来判断转储任务是否成功。

数据源修改接口：配置消息中间件的消息主题的名称、互联网协议(InternetProtocol，IP)地址、用户名、密码、分区数及字段配置信息。其中，字段配置信息包括但不限于：消息中的字段名、写入搜索引擎的字段名、各字段名的含义及各字段名对应的字段类型等。字段配置信息会实时保存至搜索引擎的映射信息中，确保从消费的消息主题中获取到各种已配置的字段，并基于映射信息映射后写入搜索引擎中。

DMP(Data Management Platform)：数据管理平台，它把分散的多方数据进行整合纳入统一的技术平台，并对这些数据进行标准化和细分，让用户可以把这些细分结构推向现有的互动营销环境里。

为了解决目前的人工测试方式存在的耗时耗力、测试不稳定以及无法满足多样化场景下的测试需求的问题，本申请实施例旨在提出一种搜索引擎的存储性能测试方法，针对已部署的多种数据源类型中的任一种测试数据源，按照测试数据源的数据存储结构构造测试数据并写入测试数据源中，以便在测试过程中从测试数据源获取测试数据并转储至搜索引擎；由于多种测试数据源分别针对不同的业务场景，通过上述测试方法可以模拟和测试搜索引擎在不同业务场景下的存储性能，确保经过测试的搜索引擎能够满足多样化业务场景下的高可用性需求；此外，利用预设的单元测试框架自带的测试类，实现对从测试数据源到搜索引擎的数据存储过程的自动测试，无需人工参与，进而减少人力资源、提高测试效率和测试稳定性。

应理解，本申请实施例提供的搜索引擎的存储性能测试方法可以由电子设备或者安装在电子设备中的软件执行。此处所谓的电子设备可以包括终端设备，比如智能手机、平板电脑、笔记本电脑、台式计算机、智能语音交互设备、智能家电、智能手表、车载终端、飞行器等；或者，电子设备还可以包括服务器，比如独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。

以下结合附图，详细说明本申请各实施例提供的技术方案。

首先结合图1对本申请实施例提供的技术方案所适用的实施环境进行说明。应理解，本申请实施例提供的技术方案适用于图1所示的实施环境只是一种示例性的说明，并不应理解为对本申请实施例提供的技术方案所适用的实施环境的限定。

如图1所示，一种实施环境包括：不同的测试数据源、数据管理应用以及搜索引擎等。

不同测试数据源的存储结构不同，进而所能存储的数据不同。不同的测试数据源用于存储不同类型的测试数据，以供模拟不同业务场景下产生的数据。具体地，不同的测试数据源可以包括离线数据源和实时数据源，其中，离线数据源用于存储和提供离线测试数据，实时数据源用于存储和提供实时测试数据。

数据管理应用是指预先部署的用于实现数据管理的应用程序(Application，APP)。通过数据管理应用可为不同测试数据源创建对应的转储任务。转储任务用于从所对应的测试数据源中获取相应类型的测试数据并转储至搜索引擎中。具体地，通过数据管理任务可创建离线数据源对应的转储任务(以下简称为离线转储任务)和实时数据源对应的转储任务(以下简称为实时转储任务)。

其中，离线转储任务用于从离线数据源获取离线测试数据并转储至搜索引擎中。通过执行离线转储任务，可以模拟在离线业务场景下向搜索引擎存储离线数据的过程；进一步，查询离线数据源中存储的数据，并结合离线转储任务获取的离线测试数据，可以准确评估搜索引擎在离线业务场景下的存储性能，得到相应的测试结果。

实时转储任务用于从实时数据源获取实时测试数据并转储至搜索引擎中。通过执行实时转储任务，可以模拟在实时业务场景下向搜索引擎存储实时数据的过程；进一步，查询实时数据源中存储的数据，并结合实时转储任务获取的实时测试数据，可准确评估搜索引擎在实时业务场景下的存储性能，得到相应的测试结果。

基于上述实施环境，本申请实施例提供一种搜索引擎的存储性能测试方法，该方法利用预设的单元测试框架自带的测试类，实现对上述转储任务的自动执行及对搜索引擎的自动查询，从而实现对搜索引擎的转储性能的自动化测试，测试过程无需人工参与，进而减少人力资源、提高测试效率和测试稳定性。

请参见图2，为本申请的一个实施例提供的一种搜索引擎的存储性能测试方法的流程示意图，该方法可以包括如下步骤：

S202，基于测试数据源的数据存储结构，构造测试数据并写入所对应的测试数据源中。

测试数据源的数据存储结构用于表示描述测试数据源存储数据的方式。这里测试数据源为多种测试数据源中的其中一种。

每种测试数据源用于存储一种类型的测试数据。具体地，多种测试数据源包括实时数据源和离线数据源，实时数据源用于存储实时测试数据，离线数据源用于存储离线测试数据。

离线数据源可以具有采用各种能够用于存储离线数据的数据源，具体可根据实际需要进行选择，本申请实施例对此不作限定。可选地，考虑在通常的离线业务场景下，大多是从数据仓库(如Hive)中读取存储的离线数据并存储到搜索引擎中，为了更好地模拟和测试离线业务场景下向搜索引擎存储离线数据的过程，离线数据源可以包括数据仓库中的指定数据表。相应地，离线测试数据可以通过如下方式构造并写入离线数据源中：解析指定数据表的表结构，得到指定数据表的字段信息；基于字段信息，构造离线测试数据并写入指定数据表中。其中，指定数据表的表结构用于表示指定数据表存储数据的方式，具体可以包括但不限于表名、表中的字段信息(如字段名、字段类型、宽度等)、主键等。

例如，通过解析指定数据表的表结构，确定出指定数据表用于记录用户的基本信息，具体包括用户标识(user_id)、姓名、年龄、住址、手机号等字段，那么，可虚构多个用户的基本信息作为离线测试数据并写入到指定数据表中。表1示出了一种指定数据表及其记录的多条离线测试数据，指定数据表中的每一条记录即为一条离线测试数据。

表1

用户标识	姓名	年龄	住址	手机号
					0001	user1	23	Beijing	131****1010
0002	user2	30	Shanghai	185****2111
					0003	user3	35	Shenzhen	136****1110

实时数据源可以具有采用各种能够用于存储和提供实时数据的数据源，具体可根据实际需要进行选择，本申请实施例对此不作限定。可选地，由于测试环境不能连接生产环境，消费生产环境中的真实用户数据，为了模拟实时业务场景下的实时数据的产生过程，实时数据源可以包括消息中间件。相应地，实时测试数据可通过如下方式构造并写入实时数据源中：获取历史用户行为数据，其中，历史用户行为数据为通过对指定前端应用埋点得到；基于消息中间件对应的消息体结构和历史用户行为数据，构造消息作为实时测试数据并发布到消息中间件，其中，消息用于描述用户对指定前端应用的实时访问行为。

消息中间件对应的消息体结构用于描述消息中间件存储的消息的内容，具体可以包括但不限于主题名称、IP地址、字段信息(如字段名、字段类型)等。实际应用中，消息中间件的类型可以根据实际需要进行选择，如kafka等，本申请实施例对此不作限定。

例如，假设消息中间件对应的消息体结构包括：主题名称(topicCode)、消息中间件的IP地址(host)、用户名(userName)、密码(password)、用户标识(user_id)、手机号(phone)、埋点标识等。基于获得的历史用户行为数据可构造如下实时测试数据：

实时测试数据1：用于描述王先生访问了指定前端应用及李先生的个人信息；

{"host":"${指定中间件的IP地址}:9092",

"topicCode":"${topicA}",

"userName":"${user1}",

"password":"${pass1}",

"message":

{\"user_id\":\"10000022\",\"type\":\"track\",\"event\":\"qw123as\",\"userName\":\"王先生\",\"distinct_id\":\"10000022\",

\"title\":\"autoTest1\",\"phone\":\"13800001111\",\"time\":${nowTime}}

实时测试数据2：用于描述李先生访问了指定前端应用及李先生的个人信息；

{"host":"${指定中间件的IP地址}:9092",

"topicCode":"${topicB}",

"userName":"${user1}",

"password":"${pass1}",

"message":

{\"user_id\":\"10000023\",\"type\":\"track\",\"event\":\"qw1010as\",\"userName\":\"李先生\",\"distinct_id\":\"10000023\",

\"title\":\"autoTest2\",\"phone\":\"13800001112\",\"time\":${nowTime}}

实时测试数据3：用于描述赵先生访问了指定前端应用及李先生的个人信息；

{"host":"${指定中间件的IP地址}:9092",

"topicCode":"${topicC}",

"userName":"${user1}",

"password":"${pass1}",

"message":"{\"user_id\":\"10000024\",\"type\":\"track\",\"userName\":\"赵先生

",\"distinct_id\":\"10000024\",\"title\":\"autoTest3\",\"phone\":\"13800001113\",\"time\":${no wTime}}

实时测试数据4：用于描述魏先生访问了指定前端应用及李先生的个人信息；

{"host":"${指定中间件的IP地址}:9092",

"topicCode":"${topicC}",

"userName":"${user1}",

"password":"${pass1}",

"message":"{\"user_id\":\"10000025\",\"type\":\"track\",\"userName\":\"魏先

\",\"distinct_id\":\"10000025\",\"title\":\"autoTest4\",\"phone\":\"13800001114\",\"time\":${nowTime}}

S204，通过预设单元测试框架的测试类，执行测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据。

其中，每个测试数据源具有对应的转储任务，以模拟从该测试数据源获取测试数据并转储至搜索引擎的过程。对于每个测试数据源而言，该测试数据源对应的测试任务从该测试数据源中获取相应类型的测试数据并转储至搜索引擎中。

预设单元测试框架可以采用各种具有测试功能的框架，具体可根据实际需要进行选择，本申请实施例对此不作限定。可选地，预设单元测试框架可以是基于编程语言python的单元测试框架unittest，它能够很好的与自动化测试相结合，并由独立的测试报告框架，实现简单。

测试类是指预设单元测试框架下用于测试的方法类。测试类可以根据预设单元测试框架适用的编程语言预先编写得到。测试类中可定义多个接口，每个接口实现的功能不同，例如包括但不限于如下接口中的至少两种：用于查询搜索引擎的查询索引接口、用于清空索引的重置索引接口、用于执行转储任务的插入存储任务接口、用于配置消息体结构的数据源修改接口等。通过执行测试类中的相应接口，可以执行不同测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据。

S206，基于转储任务获取的测试数据和搜索引擎中存储的数据，生成第一测试结果。

具体地，对于离线数据源而言，在执行离线转储任务并查询搜索引擎中存储的离线测试数据，基于离线转储任务从离线数据源获取的离线测试数据和搜索引擎中存储的离线测试数据，可以准确评估搜索引擎在离线业务场景下的存储性能，得到相应的测试结果。

搜索引擎在离线业务场景下的存储性能受到多种因素的影响，比如转储离线数据的准确性、在不同情况下对同一离线数据进行转储的差异性、对离线数据源中的数据修改的同步响应性等等。基于此，可从不同的方面对搜索引擎在离线业务场景下的存储性能进行测试。下面以多种离线转储测试为例进行说明。当然，应理解，如下几种离线转储测试只是一种示例性说明，并不应理解为对本申请实施例提供的技术方案所能实现的离线存储性能测试场景的限定。

离线测试1：测试搜索引擎转储离线数据的准确性。

在该项离线测试中，第一测试结果包括离线转储测试结果，离线转储测试结果用于表示搜索引擎对离线数据的转储性能，其可以反映搜索引擎转储离线数据的准确性。离线数据源对应的转储任务包括离线转储任务，离线转储任务用于从指定数据表读取离线测试数据并转储至搜索引擎的指定索引中。

具体地，上述S204可以包括：步骤A11，调用测试类的插入存储任务接口执行离线转储任务；步骤A12，调用测试类的查询索引接口，查询指定索引中存储的数据。进一步，上述S206可以包括：步骤B11，通过比对离线转储任务获取的离线测试数据与指定索引中存储的数据，生成离线转储测试结果。其中，指定索引可以包括搜索引擎中的一个或多个搜索，比如以搜索引擎ES为例，指定索引可以包括ES中的主索引、push索引和mobile索引中的至少一个。

示例地，以上述表1所示的指定数据表为例，假设离线转储任务为从指定数据表中获取全部的离线测试数据并转储至搜索引擎的指定索引中；在调用插入存储任务接口执行离线转储任务成功之后，调用查询索引接口；若查询到指定索引中存储的数据仅包含user1和user2的信息，那么，可确定搜索引擎未通过该项离线测试，进而生成表示测试未通过的离线转储测试结果；若查询到指定索引中存储的数据包含user1、user2以及user3的信息、且每条用户信息与指定数据表中相应的数据信息一致，那么，可确定搜索引擎通过该项离线测试，进而生成表示测试通过的离线转储测试结果。

离线测试2：测试搜索引擎对于不同离线转储任务的转储性能差异。

在该项离线测试中，第一测试结果包括第一离线测试测试结果，其中，第一离线测试结果用于表示搜索引擎对应不同离线转储任务的转储性能差异。

具体地，离线数据源对应的转储任务可以包括第一离线转储任务和第二离线转储任务，第一离线转储任务为定时创建的离线转储任务，第一离线转储任务和第二离线转储任务均用于从指定数据表中读取第一离线测试数据并转储至搜索引擎的指定索引中。其中，第一离线测试数据可以包括指定数据表中的部分或全部离线测试数据。

相应地，上述S204可以包括：步骤A21，在检测到第一离线转储任务创建完成后，通过数据管理应用运行第一离线转储任务，以及在第一离线转储任务执行成功后调用测试类的查询索引接口，查询指定索引中的第一数据量；步骤A22，调用测试类的重置索引接口，清空指定索引中的数据；步骤A23，调用测试类的插入存储任务接口执行第二离线转储任务，以及在第二离线转储任务执行成功后调用查询索引接口，查询指定索引中的第二数据量。进一步，上述S206可以包括：步骤B21，基于第一数据量与第二数据量之间的偏差，生成第一离线测试结果。其中，偏差越大，表明搜索引擎对于不同离线转储任务的转储性能越差；反之，表明测试搜索引擎搜索引擎对于不同离线转储任务的转储性能越好。

示例地，以预设的单元测试框架为基于编程语言python的单元测试框架unittest为例，测试类可以包括class A_Total_Test，该测试类用于测试第一离线转储任务和第二离线转储任务分别得到的指定索引中数据量之间的偏差。待测试的搜索引擎为ES，指定索引包括ES中的主索引、push索引和mobile索引，主索引用于存储用户标识、手机号、身份证号、家庭住址等；push索引用于存储用户的注册天数、合同号等；mobile索引用于存储用户标识、手机号、通用唯一标识码(Universally Unique Identifier，UUID)。第一离线转储任务是由分布式调度平台(如zookeeper)定时创建的自动转储任务，该自动转储任务从指定数据表中读取指定的离线测试数据，分别存储至相应的索引中。

首先，在检测到第一离线转储任务创建之后，通过数据管理应用(如dmp应用)运行第一离线转储任务；之后，通过调接口方式查询第一离线转储任务是否执行成功，比如通过上述测试类的请求(requests)模块调此案接口，其中，接口地址＝http://{dmpwork的域名}/work/getZkConfig、请求方式get，获得响应值后转为字典，从字典中获得主索引、mobile索引、push索引各自的标志位，succ代表转储成功，running或init则代表未转储成功。由于第一离线转储任务的执行过程需要一定时间，所以可控制每隔一定时间调一次接口，循环调多次，直到查询到3个索引各自的成功标识或者循环调接口次数超过预设次数时停止。

若未获取到3个索引各自的成功标识，则为每个索引对应的变量赋值0，即total_1＝0、total_2＝0、total_3＝0，并记录到测试报告中；其中，total_1为主索引对应的变量，表示第一离线转储任务后主索引中的数据量；total_2为执行第一离线转储任务后push索引对应的变量，表示push索引中的数据量；total_3为mobile索引对应的变量，表示第一离线转储任务后mobile索引中的数据量。

在获取到3个索引的成功标志位之后，调用上述测试类的查询索引接口，分别查询主索引、push索引、mobile索引，获取到各索引中的数据量，并赋值给各索引对应的变量，即根据主索引中的数据量为total_1赋值，根据push索引中的数据量为total_2赋值，根据mobile索引中的数据量为total_3赋值。具体地，使用requests模块调查询索引接口，请求地址＝ES的ip，9200端口号，例如：针对主索引，用requests模块调查询索引接口，地址＝http://{ES的ip}:9200/dmp.cmc_{当前日期}/_search/，请求体＝{"query":{"match_all":{}}}，post请求，请求头header包含Authorization信息，Authorization需要用到base64模块的b64encode方法把ES集群的用户名和密码做base64编码，获取到响应值转为json，取出该json中total字段值保存到变量total_1中；类似地，分别获取到mobile索引和push索引各自中的数据量，并分别赋值到total_2和total_3。

接着，调用上述测试类的重置索引接口，清空3个索引中的数据。例如，针对主索引，通过requests模块调查询索引接口，接口地址＝http://{dmpwork的域名}/newWorkNewESIndex？indexType＝master，请求方式get，assertEqual响应值code＝200及msg＝成功，若assertEqual成功，则继续后续步骤，失败则停止后续步骤执行，记录到html测试报告中。对于mobile索引和push索引也是一样的处理方式，只是接口地址的indexType不同，分别为mobile，push。

进一步，调用插入存储任务接口，例如：针对主索引，通过requests模块调接口，地址＝http://{dmpwork的域名}/newInsertEsIndex？indexType＝master，请求方式get，assertEqual响应值code＝200及msg＝成功，若assertEqual成功，则继续后续步骤，失败则停止后续步骤执行。对于mobile索引和push索引也是一样的处理方式，只是接口地址的indexType不同，分别为mobile，push。

进一步，再次调用查询索引接口，查询主索引、push索引和mobile索引各自中的数据量，并分别赋值给变量total_a、total_b、total_c；其中，total_a为主索引对应的变量，表示第二离线转储任务后主索引中的数据量；total_b为执行第二离线转储任务后push索引对应的变量，表示push索引中的数据量；total_c为mobile索引对应的变量，表示第二离线转储任务后mobile索引中的数据量。

最后，计算变量total_1和total_a各自的值之间的偏差是否小于5％，计算变量total_2和total_b各自的值之间的偏差是否小于5％，以及计算变量total_3和total_c各自的值之间的偏差是否小于5％；若三个偏差均小于5％，则确定搜索引擎通过离线测试2，进而生成表示测试通过的第一离线测试结果；若任一偏差大于或等于5％，则搜索引擎未通过离线测试2，进而生成表示测试未通过的第一离线测试结果。

离线测试3：测试搜索引擎对离线数据源中的数据修改的同步响应性。

在该项离线测试中，第一测试结果包括第二离线测试结果，第二离线测试结果用于表示搜索引擎对离线数据源的转储性能。离线数据源对应的转储任务包括第三离线转储任务，第三离线转储任务用于从指定数据表读取第二离线测试数据并转储至搜索引擎的指定索引中。其中，第二离线测试数据可以包括指定数据表中的部分或全部离线测试数据。第二离线测试数据与第一离线测试数据可以相同或不同。

相应地，上述S204可以包括：步骤A31，对指定数据表中的离线测试数据执行修改操作；步骤A32，调用测试类的插入存储任务接口执行第三离线转储任务，以及在第三离线转储任务执行成功后调用测试类的查询索引接口，查询指定索引中存储的数据。进一步，上述S206可以包括：步骤B31，基于查询到的数据和修改操作所修改的离线测试数据，生成第二离线测试结果。

示例地，以预设的单元测试框架为基于编程语言python的单元测试框架unittest为例，测试类可以包括class C_OfflineUser_Test，该测试类用于测试对指定数据表中离线测试数据的修改能否准确同步至搜索引擎中，以便准确评估搜索引擎对离线数据源中的数据修改的同步响应性。

首先，通过数据仓库的IP地址、用户名、密码及仓库标识、端口号等参数连接数据仓库，向指定数据表中插入用户user_id＝10000011的用户数据，若插入失败，则生成测试未通过的第二离线测试结果；若插入成功，则继续执行下一步骤。向指定数据表中插入用户数据可通过insert语句实现。

删除指定数据表中的用户user_id＝10000012的用户数据，若删除失败，则生成测试未通过的第二离线测试结果；若插入成功，则继续执行下一步骤。从指定数据表中删除用户数据可通过delete语句实现。

接着，调用重置索引接口，情况指定索引中的数据。例如，针对主索引，通过requests模块调用重置索引接口，接口地址http://{dmpwork的域名}/newWorkNewESIndex？indexType＝master，请求方式get，assertEqual响应值code＝200及msg＝成功，若assertEqual成功，则继续后续步骤，失败则停止后续步骤执行。对于mobile索引和push索引也是一样的处理方式，只是接口地址的indexType不同，分别为mobile、push。

进一步，调用插入存储任务接口执行第三离线转储任务。例如：针对主索引，通过requests模块调插入存储任务接口，接口地址＝http://{dmpwork的域名}/newInsertEsIndex？indexType＝master，请求方式get，assertEqual响应值code＝200及msg＝成功，若assertEqual成功，则继续后续步骤，失败则停止后续步骤执行。对于mobile索引和push索引也是一样的处理方式，只是接口地址的indexType不同，分别为mobile、push。

进一步，调接口方式查询第三离线存储任务是否成功，若成功则继续后续步骤；若失败则生成测试未通过的第二离线测试结果。

进一步，调用查询索引接口，分别查询主索引、push索引及mobile索引各自中存储的数据。例如：针对主索引，通过requests模块调查询索引接口，接口地址＝http://{ES集群的ip}:9200/dmp.cmc_{当前日期}/_search/，请求体＝{"query":{"bool":{"filter":[{"term":{"user_id":"10000011"}}]}}}，post请求，请求头header包含Authorization信息，Authorization需要用到base64模块的b64encode方法把ES集群的用户名和密码做base64编码，获取到响应值转为json，用原插入的sql中的每一个字段与该json值做对比，assertEqual为真，则生成测试通过的第二离线测试结果；为假，则生成测试未通过的第二离线测试结果。

进一步，将指定数据表恢复到修改之前的状态，即重新向指定数据表中插入user_id＝10000012的用户数据，并删除用户user_id＝1000011的用户数据。

对于实时数据源而言，在执行实时转储任务并查询搜索引擎中存储的离线测试数据，通过比对实时转储任务从离线数据源获取的实时测试数据和搜索引擎中存储的实时测试数据，可以准确评估搜索引擎在实时业务场景下的存储性能，得到相应的测试结果。

搜索引擎在实时业务场景下的存储性能也受到多种因素的影响，比如转储离线数据的准确性、映射准确性等等。基于此，可从不同的方面对搜索引擎在实时业务场景下的存储性能进行测试。下面以两种实时转储测试为例进行说明。当然，应理解，如下两种实时转储测试只是一种示例性说明，并不应理解为对本申请实施例提供的技术方案所能实现的实时存储性能测试场景的限定。

实时测试1：测试搜索引擎转储实时数据的准确性。

在该项实时测试中，第一测试结果包括实时测试结果，实时测试结果用于表示所述搜索引擎对实时数据源的转储性能，其可以反映搜索引擎转储实时数据的准确性。实时数据源对应的转储任务包括实时转储任务，实时转储任务用于消费消息中间件的实时测试数据并转储至搜索引擎的指定索引中。

具体地，上述S204可以包括：步骤A41，通过测试类的请求模块向数据管理应用发送任务执行请求，任务执行请求用于请求数据管理应用执行实时转储任务；步骤A42，在所实时转储任务执行完成之后，调用测试类的查询索引接口，查询指定索引中存储的数据。进一步，上述S206可以包括：步骤B41，通过比对查询到的数据和实时转储任务获取的实时测试数据，生成实时测试结果。

示例地，以预设的单元测试框架为基于编程语言python的单元测试框架unittest为例，测试类可以包括class D_RealUser_Test，该测试类用于测试从消息中间件消费的实时测试数据能否准确转储到搜索引擎的指定索引中，以便准确评估搜索引擎对实时数据源的转储性能。

首先，通过requests模块向dmp应用发送post请求，以请求dmp应用消费消息中间件中的实时测试数据并转储至搜索引擎的指定索引中。例如，请求地址＝{dmp应用的域名}/mq/publish/kafka？num＝1，assertEqual响应值code＝200及msg＝成功，若assertEqual成功，则继续后续步骤；若assertEqual失败，则重试10次，成功则停止重试或者超过10次也停止重试。

接着，调用查询索引接口，查询指定索引中存储的数据。例如：针对主索引，使用实时转储任务获取的实时测试数据的标识和接口地址＝http://{ES集群的ip}:9200/dmp.cmc_{当前日期}/_search/，请求体＝{"query":{"bool":{"filter":[{"term":{"user_id":"10000022"}}]}}}，将获取到响应值转为json，验证查询结果与实时转储任务获取的实时测试数据中字段值做对比，比如userName、phone等多字段依次比较是否相等，若相等，则生成测试通过的实时测试结果；否则，生成测试未通过的实时测试结果。

实时测试2：测试搜索引擎在实时业务场景下的映射准确性。

由于搜索引擎是按照预先配置的映射信息将实时数据映射存储至指定索引中的，因而搜索引擎的测试准确性会影响搜索引擎转储实时数据的准确性。为此，实时测试2可在实时测试1之前进行。

具体地，在通过上述S204执行实时数据源对应的转储任务并查询待测试的搜索引擎中存储的数据执行实时数据源对应的转储任务之前，本申请实施例提供的搜索引擎的存储性能测试方法还可以包括：调用测试类的数据源修改接口，对消息体结构中的字段配置信息执行修改操作；通过数据管理应用将修改后的字段配置信息同步至搜索引擎的映射信息中，映射信息用于将从消息中间件消费的实时测试数据映射到搜索引擎中；调用测试类的查询映射接口，查询搜索引擎的映射信息；基于查询得到的映射信息和消息体结构中修改后的字段配置信息，生成第二测试结果，第二测试结果用于表示搜索引擎的映射性能。

示例地，以预设的单元测试框架为基于编程语言python的单元测试框架unittest为例，测试类可以包括class B_Mapping_Test，该测试类用于测试修改消息体结构中的字段配置信息是否能够准确同步到搜索引擎的映射信息中，以便准确评估搜索引擎在实时业务场景下的映射准确性。

首先，通过requests模块调用数据源修改接口，通过put请求方式，在消息体结构的字段配置信息中增加字段名autoTestTagZd、该字段名的含义以及字段类型(keyword)，其中，请求地址＝http://{dmp的域名}/tags/actualtype，assertEqual响应值code＝200及msg＝成功，若assertEqual成功，则继续后续步骤；若assertEqual失败，则生成表示测试失败的第二测试结果。以及，通过数据管理应用将修改后的字段配置信息同步至搜索引擎的映射mapping信息中。

接着，通过requests模块调用查询映射接口，查询搜索引擎的映射信息。具体地，请求地址＝http://{ES集群的ip}:9200/dmp.cmc_{当前日期}/_mapping，get请求，请求头header包含Authorization信息，Authorization需要用到base64模块的b64encode方法把ES集群的用户名和密码做base64编码，获取到响应值转为json，判断该json中是否存在字段autoTestTagZd，assertTrue方法为真，则生成测试通过的第二测试结果；否则，生成测试未通过的第二测试结果。

通过requests模块调用数据源修改接口，通过put请求方式，在消息体结构的字段配置信息中删除一个已有的字段test1。具体地，请求方式为put请求，请求地址＝http://{dmp的域名}/tags/actualtype，assertEqual响应值code＝200及msg＝成功；若assertEqual成功，则继续后续步骤；若assertEqual失败，则停止后续步骤执行，并生成测试失败的第二测试结果。

接着，通过requests模块调用查询映射接口，查询搜索引擎的映射信息。具体地，请求地址＝http://{ES集群的ip}:9200/dmp.cmc_{当前日期}/_mapping，get请求，请求头header包含Authorization信息，Authorization需要用到base64模块的b64encode方法把ES集群的用户名和密码做base64编码，获取到响应值转为json，判断该json中是否存在字段test1；若存在字段test1，则生成表示测试未通过的第二测试结果；若不存在字段test1，则生成测试通过的第二测试结果。

值的说明的是，上述几种测试可以并行执行，也可以顺序进行。示例地，为了避免不同测试过程相互干扰，以确保测试可靠性和准确性，上述几种测试可以按照如下顺序执行：离线测试1->离线测试2->实时测试2->离线测试3->实时测试1。

可选地，在上述S206之后，本申请实施例提供的搜索引擎的存储性能测试方法还可以包括：将第一测试结果写入测试报告中；以及，通过持续集成工具，定时将测试报告推送给目标用户。当然，可以理解的是，第二测试结果也可以写入测试报告中。

测试报告用于反映对搜索引擎的存储性能进行测试的测试情况。测试报告可采用各种适当的格式，比如超文本标记语言(Hyper Test Markup Language，HTML)格式。目标用户可以包括测试人员、使用搜索引擎的相关业务方等，本申请实施例对此不作限定。

持续集成工具可以采用本领域常用的各种具有持续重复工作能力的软件工具，比如Jenkins等，由此可以实现对测试报告的定时推送，使得目标用户能够及时、直观地获知搜索引擎的存储性能测试情况，以便更好地优化搜索引擎的存储性能。

实际测试过程中，上述整个测试过程也可以依赖持续集成工具执行。下面结合图3，对搜索引擎的存储性能测试过程进行说明。如图3所示，离线数据源包括数据仓库中的指定数据表，实时数据源包括消息中间件，搜索引擎中包含主索引、push索引和mobile索引。

首先，通过持续集成工具测试搜索引擎对于不同离线转储任务的转储性能差异。

该测试过程包括：通过数据管理应用执行定时创建的第一离线转储任务，以从指定数据表中获取第一离线测试数据并转储至搜索引擎的3个索引中；在第一离线转储任务执行成功之后，通过持续集成工具调用测试类的查询索引接口，查询搜索引擎的3个索引各自存储的数据量；之后，通过持续集成工具调用测试类的重置索引接口，清空3个索引各自存储的数据；进一步，通过持续集成工具创建并执行第二离线转储任务，以再次从指定数据表中获取第一离线测试数据并转储至搜索引擎的3个索引中；在第二离线转储任务执行成功之后，通过持续集成工具再次调用测试类的查询索引接口，查询搜索引擎的3个索引各自存储的数据量；进一步，针对每个索引，验证两次查询该索引得到的数据量之间的偏差是否满足偏差要求，若偏差小于5％，则确定该偏差满足偏差要求；若偏差大于或等于5％，则确定该偏差不满足偏差要求；最后，若3个索引对应的偏差均满足偏差要求，则生成通过该项测试的相应测试结果并写入测试报告中；若任一个索引对应的偏差不满足偏差要求，则生成未通过该项测试的相应测试结果并写入测试报告中。

然后，通过持续集成工具测试测试搜索引擎在实时业务场景下的映射准确性。

该测试过程包括：通过持续集成工具对调数据源接口对消息中间件的消息体结构中的字段配置信息进行修改，比如增加A字段、删除B字段等；之后，通过数据管理应用将修改后的字段配置信息同步至搜索引擎的映射信息中；进一步，通过持续集成工具调用测试类的映射接口，查询搜索引擎的映射信息是否被正确同步；若搜索引擎的映射信息包括A字段、且不包括B字段，则生成通过该项测试的相应测试结果并写入测试报告中；否则，生成未通过该项测试的测试结果并写入测试报告中。

接着，通过持续集成工具测试搜索引擎对离线数据源中的数据修改的同步响应性。

该测试过程包括：通过持续集成工具对指定数据表进行修改，比如插入用户m对应的离线测试数据、删除用户n对应的用户数据；通过持续集成工具调用重置索引接口，清空搜索引擎的3个索引存储的数据；之后，通过持续集成工具执行第三离线转储任务(图中未示出)，以从指定数据表中读取全部离线测试数据并转储至搜索引擎的各个索引中；进一步，通过持续集成工具调用测试类的查询索引接口，查询各索引中存储的数据；若查询到的数据中包括用户m对应的离线测试数据且不包括用户n对应的离线测试数据，则生成通过该项测试的相应测试结果并写入测试报告中；否则，则生成未通过该项测试的相应测试结果并写入测试报告中。

而后，通过持续集成工具测试测试搜索引擎转储实时数据的准确性。

该测试过程包括：通过持续集成工具调用重置索引接口，清空搜索引擎的3个索引存储的数据；之后，通过数据管理应用从消息中间件依次消费实时测试数据1～实时测试数据5并转储至搜索引擎的各个索引中；接着，通过持续集成工具调用测试类的查询索引接口，查询各索引中存储的数据；若搜索引擎中存储有实时测试数据1～实时测试数据5，则生成通过该项测试的相应测试结果并写入测试报告；否则，生成未通过该项测试的相应测试结果并写入测试报告中。

最后，通过持续集成工具定时向目标用户推送测试报告。

本申请的一个或多个实施例提供的搜索引擎的存储性能测试方法，针对已部署的多种测试数据源中的任一种，测试数据源的数据存储结构，构造测试数据并写入测试数据源中，以便在测试过程中从测试数据源获取测试数据并转储至搜索引擎；由于多种测试数据源分别针对不同的业务场景，通过上述测试方法可以模拟和测试搜索引擎在不同业务场景下的存储性能，确保经过测试的搜索引擎能够满足多样化业务场景下的高可用性需求；在此基础上，利用预设的单元测试框架自带的测试类，执行测试数据源对应的转储任务，从测试数据源中获取测试数据并转储至搜索引擎中，通过查询搜索引擎中存储的数据，并结合转储任务获取的测试数据生成第一测试结果，即可实现对搜索引擎的存储性能的测试；由此，对搜索引擎的测试不需要人工参与，而是利用单元测试框架自带的测试类的自动完成，进而可以减少人力资源、提高测试效率，并且，自动测试过程不受人为因素的影响，可以有效避免因人为疏忽导致的测试不稳定的问题，从而可以提高测试稳定性。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本申请实施例还提供一种搜索引擎的存储性能测试装置。请参见图4，为本申请的一个实施例提供的一种搜索引擎的存储性能测试装置400的结构示意图，该装置400可以包括：

构造单元410，用于基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

测试单元420，用于通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

生成单元430，用于基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

可选地，所述测试数据源包括离线数据源，所述离线数据源包括数据仓库中的指定数据表；

所述构造单元具体用于：

解析所述指定数据表的表结构，得到所述指定数据表中的字段信息；

基于所述字段信息，构造离线测试数据并写入所述指定数据表中。

可选地，所述离线数据源对应的转储任务包括第一离线转储任务和第二离线转储任务，所述第一离线转储任务为定时创建的离线转储任务，所述第一离线转储任务和所述第二离线转储任务均用于从所述指定数据表读取第一离线测试数据并转储至所述搜索引擎的指定索引中；所述第一测试结果包括第一离线测试结果，所述第一离线测试结果用于表示所述搜索引擎对于不同离线转储任务的转储性能差异；

所述测试单元420具体用于：

在检测到所述第一离线转储任务创建完成后，通过数据管理应用运行所述第一离线转储任务，以及在所述第一离线转储任务执行成功后调用所述测试类的查询索引接口，查询所述指定索引中的第一数据量；

调用所述测试类的重置索引接口，清空所述指定索引中的数据；

调用所述测试类的插入存储任务接口执行所述第二离线转储任务，以及在所述第二离线转储任务执行成功后调用所述查询索引接口，查询所述指定索引中的第二数据量；

所述生成单元430具体用于：

基于所述第一数据量与所述第二数据量之间的偏差，生成所述第一离线测试结果。

可选地，所述离线数据源对应的转储任务包括第三离线转储任务，所述第三离线转储任务用于从所述指定数据表读取第二离线测试数据并转储至所述搜索引擎的指定索引中；所述第一测试结果包括第二离线测试结果，所述第二离线测试结果用于表示所述搜索引擎对所述离线数据源的转储性能；

所述测试单元420具体用于：

对所述指定数据表中的离线测试数据执行修改操作；

调用所述测试类的插入存储任务接口执行所述第三离线转储任务，以及在所述第三离线转储任务执行成功后调用所述测试类的查询索引接口，查询所述指定索引中存储的数据；

所述生成单元430具体用于：

基于查询到的数据和所述修改操作所修改的离线测试数据，生成所述第二离线测试结果。

可选地，所述测试数据源包括实时数据源，所述实时数据源包括消息中间件；

所述构造单元具体用于：

获取历史用户行为数据，所述历史用户行为数据为通过对指定前端应用埋点得到；

基于所述消息中间件对应的消息体结构和所述历史用户行为数据，构造消息作为实时测试数据并发布到所述消息中间件，所述消息用于描述用户对所述指定前端应用的实时访问行为。

可选地，所述实时数据源对应的转储任务包括实时转储任务，所述实时转储任务用于消费所述消息中间件的实时测试数据并转储至所述搜索引擎的指定索引中；所述第一测试结果包括实时测试结果，所述实时测试结果用于表示所述搜索引擎对所述实时数据源的转储性能；

所述测试单元420具体用于：

通过所述测试类的请求模块向数据管理应用发送任务执行请求，所述任务执行请求用于请求所述数据管理应用执行所述实时转储任务；

在所述实时转储任务执行完成之后，调用所述测试类的查询索引接口，查询所述指定索引中存储的数据；

所述生成单元430具体用于：

通过比对查询到的数据和所述实时转储任务获取的实时测试数据，生成所述实时测试结果。

可选地，所述测试单元420还用于：

执行所述实时数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据执行实时数据源对应的转储任务之前，调用所述测试类的数据源修改接口，对所述消息体结构中的字段配置信息执行修改操作；

通过数据管理应用将修改后的所述字段配置信息同步至所述搜索引擎的映射信息中，所述映射信息用于将从所述消息中间件消费的实时测试数据映射到所述搜索引擎中；

调用所述测试类的查询映射接口，查询所述搜索引擎的映射信息；

所述生成单元430还用于：基于查询得到的映射信息和所述消息体结构中修改后的字段配置信息，生成第二测试结果，所述第二测试结果用于表示所述搜索引擎的映射性能。

可选地，所述装置400还包括：

写入单元，用于将所述第一测试结果写入测试报告中；

推送单元，用于通过持续集成工具，定时将所述测试报告推送给目标用户。

显然，本申请实施例提供的搜索引擎的存储性能测试装置能够作为图2所示的搜索引擎的存储性能测试方法的执行主体，例如图2所示的搜索引擎的存储性能测试方法中，步骤S202可由图4所示的搜索引擎的存储性能测试装置中的构造单元410执行，步骤S204可由图4所示的搜索引擎的存储性能测试装置中的测试单元420执行，步骤S206可由图4所示的搜索引擎的存储性能测试装置中的生成单元430执行。

根据本申请的另一个实施例，图4所示的搜索引擎的存储性能测试装置中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其他实施例中，搜索引擎的存储性能测试装置也可以包括其他单元，在实际应用中，这些功能也可以由其他单元协助实现，并且可以由多个单元协作实现。

根据本申请的另一个实施例，可以通过在包括中央处理单元(CentralProcessing Unit，CPU)、随机存取存储介质(Random Access Memory，RAM)、只读存储介质(Read-Only Memory，ROM)等处理元件和存储元件的例如计算机的通用计算设备上，运行能够执行如图2所示的相应方法所涉及的各步骤的计算机程序(包括程序代码)，来构造如图4中所示的搜索引擎的存储性能测试装置，以及来实现本申请实施例的搜索引擎的存储性能测试方法。所述计算机程序可以记载于例如计算机可读存储介质上，并通过计算机可读存储介质转载于电子设备中，并在其中运行。

图5是本申请的一个实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成搜索引擎的存储性能装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

上述如本申请图2所示实施例揭示的搜索引擎的存储性能装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central ProcessingUnit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图2的方法，并实现搜索引擎的存储性能装置在图2、图3所示实施例的功能，本申请实施例在此不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图2所示实施例的方法，并具体用于执行以下操作：

基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (10)

1.一种搜索引擎的存储性能测试方法，其特征在于，包括：

基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

2.根据权利要求1所述的方法，其特征在于，所述测试数据源包括离线数据源，所述离线数据源包括数据仓库中的指定数据表；

所述基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，包括：

解析所述指定数据表的表结构，得到所述指定数据表中的字段信息；

基于所述字段信息，构造离线测试数据并写入所述指定数据表中。

3.根据权利要求2所述的方法，其特征在于，所述离线数据源对应的转储任务包括第一离线转储任务和第二离线转储任务，所述第一离线转储任务为定时创建的离线转储任务，所述第一离线转储任务和所述第二离线转储任务均用于从所述指定数据表读取第一离线测试数据并转储至所述搜索引擎的指定索引中；所述第一测试结果包括第一离线测试结果，所述第一离线测试结果用于表示所述搜索引擎对于不同离线转储任务的转储性能差异；

所述通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，包括：

在检测到所述第一离线转储任务创建完成后，通过数据管理应用运行所述第一离线转储任务，以及在所述第一离线转储任务执行成功后调用所述测试类的查询索引接口，查询所述指定索引中的第一数据量；

调用所述测试类的重置索引接口，清空所述指定索引中的数据；

调用所述测试类的插入存储任务接口执行所述第二离线转储任务，以及在所述第二离线转储任务执行成功后调用所述查询索引接口，查询所述指定索引中的第二数据量；

所述基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果，包括：

基于所述第一数据量与所述第二数据量之间的偏差，生成所述第一离线测试结果。

4.根据权利要求2所述的方法，其特征在于，所述离线数据源对应的转储任务包括第三离线转储任务，所述第三离线转储任务用于从所述指定数据表读取第二离线测试数据并转储至所述搜索引擎的指定索引中；所述第一测试结果包括第二离线测试结果，所述第二离线测试结果用于表示所述搜索引擎对所述离线数据源的转储性能；

所述通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，包括：

对所述指定数据表中的离线测试数据执行修改操作；

调用所述测试类的插入存储任务接口执行所述第三离线转储任务，以及在所述第三离线转储任务执行成功后调用所述测试类的查询索引接口，查询所述指定索引中存储的数据；

所述基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果，包括：

基于查询到的数据和所述修改操作所修改的离线测试数据，生成所述第二离线测试结果。

5.根据权利要求1所述的方法，其特征在于，所述测试数据源包括实时数据源，所述实时数据源包括消息中间件；

所述基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，包括：

获取历史用户行为数据，所述历史用户行为数据为通过对指定前端应用埋点得到；

基于所述消息中间件对应的消息体结构和所述历史用户行为数据，构造消息作为实时测试数据并发布到所述消息中间件，所述消息用于描述用户对所述指定前端应用的实时访问行为。

6.根据权利要求5所述的方法，其特征在于，所述实时数据源对应的转储任务包括实时转储任务，所述实时转储任务用于消费所述消息中间件的实时测试数据并转储至所述搜索引擎的指定索引中；所述第一测试结果包括实时测试结果，所述实时测试结果用于表示所述搜索引擎对所述实时数据源的转储性能；

所述通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，包括：

通过所述测试类的请求模块向数据管理应用发送任务执行请求，所述任务执行请求用于请求所述数据管理应用执行所述实时转储任务；

在所述实时转储任务执行完成之后，调用所述测试类的查询索引接口，查询所述指定索引中存储的数据；

所述基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果，包括：

通过比对查询到的数据和所述实时转储任务获取的实时测试数据，生成所述实时测试结果。

7.根据权利要求5所述的方法，其特征在于，在执行所述实时数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据执行实时数据源对应的转储任务之前，所述方法还包括：

调用所述测试类的数据源修改接口，对所述消息体结构中的字段配置信息执行修改操作；

通过数据管理应用将修改后的所述字段配置信息同步至所述搜索引擎的映射信息中，所述映射信息用于将从所述消息中间件消费的实时测试数据映射到所述搜索引擎中；

调用所述测试类的查询映射接口，查询所述搜索引擎的映射信息；

基于查询得到的映射信息和所述消息体结构中修改后的字段配置信息，生成第二测试结果，所述第二测试结果用于表示所述搜索引擎的映射性能。

8.一种搜索引擎的存储性能测试装置，其特征在于，包括：

构造单元，用于基于测试数据源的数据存储结构，构造测试数据并写入所述测试数据源中，所述测试数据源为多种数据源中的其中一种；

测试单元，用于通过预设单元测试框架的测试类，执行所述测试数据源对应的转储任务，并查询待测试的搜索引擎中存储的数据，所述转储任务用于从所述测试数据源中获取测试数据并转储至所述搜索引擎中；

生成单元，用于基于所述转储任务获取的测试数据和所述搜索引擎中存储的数据，生成第一测试结果。

9.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至7中任一项所述的方法。