性能测试中的异常检测方法、装置和计算机设备

技术领域

本申请涉及人工智能技术领域，特别是涉及一种性能测试中的异常检测方法、装置、计算机设备、存储介质和计算机程序产品。

背景技术

在对业务系统的开发过程中，需要对业务系统的代码进行性能测试。在性能测试的过程中，业务系统的表现可能不符合预期，此时需要对系统在性能测试中过程中的运行信息进行检测和采集，以便对业务系统的性能异常进行分析和改进。目前对性能测试中的异常检测方式通常是性能测试人员根据开发者需求对系统进行压力测试后，开发者基于压力测试的结果再确定是否需要进行异常检测。然而，通过测试人员先压力测试，再根据测试结果确定是否再次测试的方式，会导致对异常信息的检测效率下降。

因此，目前对性能测试中的异常检测方法存在检测效率低的缺陷。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高检测效率的性能测试中的异常检测方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

第一方面，本申请提供了一种性能测试中的异常检测方法，所述方法包括：

接收针对目标性能测试的测试指令，从业务系统中包含的多个执行设备中确定出目标执行设备；

发送对应的测试消息至所述目标执行设备，所述测试消息中携带所述目标性能测试对应的测试标识，所述测试消息用于指示所述目标执行设备基于所述测试标识获取对应的测试脚本，并基于所述测试脚本执行所述目标性能测试；

获取所述目标执行设备执行所述目标性能测试过程中当前时间点的运行状态信息，并对所述当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较；所述对应时间点的运行状态预测信息基于目标长短期记忆模型、且在以所述测试脚本为模型输入时的模型输出得到；所述目标长短期记忆模型根据所述测试脚本对应的多个历史测试报告训练得到；

若所述比较结果表征所述当前时间点的所述运行状态信息为异常运行状态信息，采集所述目标执行设备对应的运行快照，并保存所述运行快照。

在其中一个实施例中，所述从所述业务系统中包含的多个执行设备中确定出目标执行设备，包括：

获取所述业务系统中各所述执行设备的设备状态；

将所述设备状态为非故障且空闲状态的执行设备，确定为所述目标执行设备。

在其中一个实施例中，所述发送对应的测试消息至所述目标执行设备，包括：

获取所述目标执行设备对应的设备标识，根据所述设备标识和所述目标性能测试对应的测试标识，生成执行类型的测试消息；

将所述执行类型的测试消息广播至各个所述执行设备，所述执行类型的测试消息用于指示接收到该测试消息的各执行设备比对所述设备标识与自身标识是否一致，在一致的情况下根据所述测试标识获取对应的测试脚本，并基于所述测试脚本执行所述目标性能测试。

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

获取所述测试脚本对应的多个历史测试报告；所述多个历史测试报告包括多个历史时间点测试得到的多个合格运行状态信息；所述多个历史时间点表征所述测试脚本对应的一个测试周期内的多个时间点；

将所述多个历史时间点以及各个历史时间点对应的合格运行状态信息输入待训练长短期记忆模型，由所述待训练长短期记忆模型基于多个历史时间点以及所述多个历史时间点对应的多个合格运行状态信息，输出所述测试脚本对应的各个历史时间点的运行状态预测信息；

根据各个历史时间点的运行状态预测信息与各个时间点的合格运行状态信息的相似度，调整所述待训练长短期记忆模型的模型参数，直至满足训练条件时，得到所述目标长短期记忆模型。

在其中一个实施例中，所述将所述多个历史时间点以及各个历史时间点对应的合格运行状态信息输入待训练长短期记忆模型，包括：

针对每个历史测试报告，获取该历史测试报告中各个历史时间点对应的线程数、内存信息、传输控制协议连接数、响应时间、单位时间业务处理数量、业务处理失败数和请求耗时中的至少一种，作为各个历史时间点对应的合格运行状态信息；

将各个历史时间点对应的合格运行状态信息，输入待训练长短期记忆模型，由所述待训练长短期记忆模型基于各个历史时间点以及所述各个历史时间点对应的所述合格运行状态信息，提取运行状态特征与时间点之间的关系，并基于所述关系输出所述测试脚本对应的各个历史时间点的运行状态预测信息。

在其中一个实施例中，所述对所述当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较，包括：

获取当前时间点的运行状态信息与所述目标长短期记忆模型输出的各个时间点中对应时间点的运行状态预测信息的相似度；

若检测到所述当前时间点对应的的相似度小于预设相似度阈值，确定所述比较结果表征所述当前时间点的运行状态信息为异常运行状态信息。

在其中一个实施例中，所述采集所述目标执行设备对应的运行快照，并保存所述运行快照，包括：

向所述目标执行设备发送文件抓取消息；所述文件抓取消息中包含抓取频率和文件中转站的地址信息，所述文件抓取消息用于指示所述目标执行设备根据所述抓取频率，抓取对应的堆转储文件和线程快照文件，并将所述堆转储文件和所述线程快照文件发送至文件中转站；

其中，所述堆转储文件包括所述目标执行设备执行所述测试脚本时的内存堆栈快照；所述线程快照文件包括所述目标执行设备执行所述测试脚本时处理器对应的每个线程的执行栈；

其中，所述文件中转站用于保存所述堆转储文件和所述线程快照文件至数据库中。

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

获取各目标执行设备的心跳信息，基于所述心跳信息确定各目标执行设备是否故障；

所述发送对应的测试消息至所述目标业务执行设备之后，还包括：

若确定出所述目标执行设备出现故障，根据所述目标业务执行设备的设备标识和测试取消指令，生成对应的测试取消消息；

将所述测试取消消息发送至所述目标执行设备，所述测试取消消息用于指示所述目标执行设备在确定所述设备标识与自身标识一致的情况下停止执行所述目标性能测试。

第二方面，本申请提供了一种性能测试中的异常检测装置，所述装置包括：

确定模块，用于接收针对目标性能测试的测试指令，从业务系统中包含的多个执行设备中确定出目标执行设备；

发送模块，用于发送对应的测试消息至所述目标执行设备，所述测试消息中携带所述目标性能测试对应的测试标识，所述测试消息用于指示所述目标执行设备基于所述测试标识获取对应的测试脚本，并基于所述测试脚本执行所述目标性能测试；

检测模块，用于获取所述目标执行设备执行所述目标性能测试过程中当前时间点的运行状态信息，并对所述当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较；所述对应时间点的运行状态预测信息基于目标长短期记忆模型、且在以所述测试脚本为模型输入时的模型输出得到；所述目标长短期记忆模型根据所述测试脚本对应的多个历史测试报告训练得到；

采集模块，用于若所述比较结果表征所述当前时间点的所述运行状态信息为异常运行状态信息，采集所述目标执行设备对应的运行快照，并保存所述运行快照。

第三方面，本申请提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述的方法的步骤。

第四方面，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的方法的步骤。

第五方面，本申请提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的方法的步骤。

上述性能测试中的异常检测方法、装置、计算机设备、存储介质和计算机程序产品，通过将测试消息发送至业务系统中的目标执行设备，指示目标执行设备基于测试标识获取测试脚本并启动目标性能测试，将目标性能测试中将当前时间点的运行状态信息与基于目标长短期记忆模型预测的对应时间点的运行状态预测信息比较，若比较结果表征当前时间点的运行状态信息为异常运行状态信息，采集目标执行设备对应的运行快照并保存。相较于传统的在一次压力测试完后再确定是否需要针对异常进行再测试，本方案通过训练目标长短期记忆模型，在目标执行设备执行测试的过程中，在对应时间点及时检测出测试状态发生异常，进而及时抓取对应的运行快照，提高了异常检测的效率。

附图说明

图1为一个实施例中性能测试中的异常检测方法的应用环境图；

图2为一个实施例中性能测试中的异常检测方法的流程示意图；

图3为一个实施例中测试消息发送步骤的流程示意图；

图4为一个实施例中执行设备判断步骤的流程示意图；

图5为一个实施例中训练步骤的流程示意图；

图6为另一个实施例中性能测试中的异常检测方法的流程示意图；

图7为一个实施例中性能测试中的异常检测装置的结构框图；

图8为一个实施例中计算机设备的内部结构图。

具体实施方式

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

本申请实施例提供的性能测试中的异常检测方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与业务系统104进行通信。数据存储系统可以存储业务系统104需要处理的数据。数据存储系统可以集成在业务系统104上，也可以放在云上或其他网络服务器上。终端102可以接收测试指令，并确定业务系统104中的目标执行设备，组装对应的测试消息后发送至业务系统104中的目标执行设备，从而目标执行设备基于测试消息获取测试脚本后开始测试，终端102可以基于目标执行设备在测试过程中各个时间点的运行状态信息与对应时间点的运行状态预测信息的比较结果，确定目标执行设备是否发生异常，并在异常时采集相应的快照，实现对目标执行设备的异常检测。其中，终端102可以但不限于是各种个人计算机和笔记本电脑。业务系统104可以用独立的执行设备或者是多个执行设备组成的集群来实现。

在一个实施例中，如图2所示，提供了一种性能测试中的异常检测方法，以该方法应用于图1中的终端为例进行说明，包括以下步骤：

步骤S202，接收针对目标性能测试的测试指令，从业务系统中包含的多个执行设备中确定出目标执行设备。

其中，业务系统可以是银行业务对应的系统，例如银行的交易业务的系统，业务系统中包括多个执行设备，每个执行设备可以是用于执行业务的设备，例如执行银行交易相关业务。目标性能测试可以是针对业务系统中的各个执行设备的测试。性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试。负载测试能够确定在各种工作负载下的系统性能，主要测试在负载逐渐增加的时候系统的性能指标变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点来获得系统能提供的最大服务级别的测试。

终端可以在接收到测试指令后，启动目标性能测试过程，即对业务系统中的符合要求的执行设备进行上述目标性能测试。其中，上述测试指令可以是周期性自动触发的指令，也可以是用户手动触发的指令。终端接收到对目标性能测试的测试指令后，可以从业务系统中包含的多个执行设备中确定出目标执行设备。其中，目标执行设备可以是符合测试条件的执行设备。

终端可以基于各个执行设备的状态，从多个执行设备中确定出目标执行设备。例如，在一些实施例中，终端可以获取业务系统中各执行设备的设备状态，并将设备状态为非故障且空闲状态的执行设备，确定为目标执行设备。其中，执行设备的状态包括空闲、加锁中、故障和非故障等状态，则终端可以将空闲且非故障的执行设备作为目标执行设备。具体地，终端中可以配置有压力测试平台和任务调度平台对应的应用，若用户在终端中的压力测试平台仅点击“执行”按钮执行压力测试，终端通过任务调度平台获取当前所有非故障的空闲执行设备，从中选取一台作为目标执行设备，并组装指定的执行任务消息格式发往该目标执行设备。另外，用户也可以指定测试具体的执行设备，若用户在压力测试平台选择指定执行设备执行压力测试，则终端可以通过任务调度平台直接组装执行格式的消息发往该执行设备，并执行压力测试。需要说明的是，上述目标执行设备也可以包括多台，终端可以通过任务调度平台进行机器管理，在选定目标执行设备的过程中需要对执行设备的状态做变动，例如将被选中的目标执行设备进行加锁，使其状态变为加锁状态，避免多次使用。终端在可以接收到任务执行装置，即目标执行设备中的任务执行装置发送的解锁消息时，释放对该目标执行设备加的锁，将该设备重新加入可选队列，即可以重新被选择为测试对象。

步骤S204，发送对应的测试消息至目标执行设备，测试消息中携带目标性能测试对应的测试标识，测试消息用于指示目标执行设备基于测试标识获取对应的测试脚本，并基于测试脚本执行目标性能测试。

其中，测试消息可以是与目标执行设备对应的消息。不同执行设备可以携带不同的设备标识。并且每次测试也可以携带有对应的测试标识，测试标识对应有本次测试对应的案例，案例中可以包括测试过程，被测试的设备和测试脚本的相关信息等。终端可以基于各个执行设备的设备标识以及测试标识生成测试信息。并将测试消息发送至对应的目标执行设备。目标执行设备可以接收该测试消息，并基于测试消息中的测试标识，获取对应的测试脚本，从而目标执行设备可以基于测试脚本执行上述目标性能测试。其中，上述测试脚本可以存储在数据库中，目标执行设备可以根据测试标识从数据库中获取对应的测试脚本。

步骤S206，获取目标执行设备执行目标性能测试过程中当前时间点的运行状态信息，并对当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较；对应时间点的运行状态预测信息基于目标长短期记忆模型、且在以测试脚本为模型输入时的模型输出得到；目标长短期记忆模型根据测试脚本对应的多个历史测试报告训练得到。

其中，目标执行设备可以基于测试脚本，执行上述目标性能测试。例如，目标执行设备中配置有执行任务装置，目标执行设备可以通过执行任务装置，调用Jmeter进行上述基于测试脚本的目标性能测试。其中，Jmeter是Apache组织基于Java开发的压力测试工具，用于对软件做压力测试。其中，目标执行设备获取测试脚本后，可以对其jmx结构进行解析和处理。其中，Jmx脚本是一种xml文档，记录了要发起的线程组信息、请求信息等。目标执行设备可以对jmx的结果进行解析，并基于后续使用对结构进行一定处理后，调用上述Jmeter进行上述性能测试。其中，上述对jmx的结构处理，可以是为了使目标信号执行设备可以将基于测试脚本的性能测试过程中，每个测试步骤通过终端进行展示，即目标执行设备通过对jmx脚本进行一定处理后，可以通过终端观察目标执行设备执行所述目标性能测试的测试过程。目标执行设备执行上述目标性能测试过程中，会以时间为单位产生多个时间点的运行状态信息。终端可以获取目标执行设备在执行上述目标性能测试过程中的当前时间点的运行状态信息，该运行状态信息可以实时从目标执行设备中获取。终端可以将当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较。其中，上述对应时间点的运行状态预测信息可以基于目标长短期记忆模型预测得到，例如终端可以通过将测试脚本输入目标长短期记忆模型，由目标长短期记忆模型基于测试脚本预测在该测试中各个时间点对应的运行状态预测信息，从而得到多个时间点的运行状态预测信息，并且这些时间点可以是一个测试周期内的时间点。其中，终端可以通过上述测试脚本对应的多个历史测试报告训练得到目标长短期记忆模型。例如终端通过将测试脚本对应的多个历史测试报告中各个时间点的运行状态特征信息输入待训练的长短期记忆模型，使得待训练的长短期记忆模型提取时间和运行状态特征之间的关系，最终得到可以预测上述测试脚本对应的测试中各个时间点的运行状态的目标长短期记忆模型。

步骤S208，若比较结果表征当前时间点的运行状态信息为异常运行状态信息，采集目标执行设备对应的运行快照，并保存运行快照。

其中，终端可以通过对比上述当前时间点的运行状态信息和对应时间点的运行状态预测信息，得到对应的比较结果。终端可以基于该比较结果确定目标执行设备当前时间点的运行状态信息是否为异常运行状态信息，并在检测到异常运行状态信息时，启动采集目标执行设备对应的运行快照的过程。其中，运行快照可以包括多种，例如HeapDump(堆转储)文件和JavaCore(线程快照)文件等。终端采集完成运行快照后，可以将获取到的运行快照进行存储，例如存储到数据库中。其中，HeapDump文件是一个二进制的文件，保存了某一时刻JVM(JavaVirtualMachine，Java虚拟机)堆中对象使用情况，是指定时刻的Java堆栈快照，是一种镜像文件；JavaCore文件主要保存的是Java应用各线程在某一时刻的运行的位置，即JVM执行到哪一个类、哪一个方法、哪一个行上。他是一个文本文件，打开后可以看到每一个线程的执行栈，以stack trace(堆栈轨迹)的显示。通过对JavaCore文件的分析可以分析得到应用是否“卡”在某个点上，是否长期得不到响应导致系统崩溃。JVM指Java虚拟机，有自身完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。需要说明的是，在一些实施例中，终端还可以在检测到预设数量的时间点的运行状态信息均为异常运行状态信息时，才确定启动采集上述运行快照的过程。终端还可以在测试结束后基于测试过程中目标执行设备的执行过程、各个时间点的运行状态信息和上述运行快照等，生成本次测试的测试报告，并且还可以将测试报告进行展示。例如用户可以在终端中输入测试报告对应的标识，从而终端可以从数据库中查询得到对应的测试报告并进行展示。

上述性能测试中的异常检测方法中，通过将测试消息发送至业务系统中的目标执行设备，指示目标执行设备基于测试标识获取测试脚本并启动目标性能测试，将目标性能测试中将当前时间点的运行状态信息与基于目标长短期记忆模型预测的对应时间点的运行状态预测信息比较，若比较结果表征当前时间点的运行状态信息为异常运行状态信息，采集目标执行设备对应的运行快照并保存。相较于传统的在一次压力测试完后再确定是否需要针对异常进行再测试，本方案通过训练目标长短期记忆模型，在目标执行设备执行测试的过程中，在对应时间点及时检测出测试状态发生异常，进而及时抓取对应的运行快照，提高了异常检测的效率。

在一个实施例中，发送对应的测试消息至目标执行设备，包括：获取目标执行设备对应的设备标识，根据设备标识和目标性能测试对应的测试标识，生成执行类型的测试消息；将执行类型的测试消息广播至各个执行设备，执行类型的测试消息用于指示接收到该测试消息的各执行设备比对设备标识与自身标识是否一致，在一致的情况下根据测试标识获取对应的测试脚本，并基于测试脚本执行目标性能测试。

本实施例中，上述业务系统中的执行设备还可以包括设备标识。由于业务系统中执行设备有多个，终端需要通过设备标识，将测试消息发送至对应的目标执行设备。例如，如图3所示，图3为一个实施例中测试消息发送步骤的流程示意图。终端中可以配置有压力测试平台和任务运行状态判断平台等，测试人员可以通过压力测试平台发起测试请求，任务运行状态判断平台也可以根据目标执行设备的状态发送对应的请求，例如发送抓取运行快照文件的请求等。终端可以基于这些请求生成对应类型的消息，并广播至上述各个执行设备。终端可以获取目标执行设备的设备标识，并根据该设备标识和目标性能测试对应的测试标识，生成执行类型的测试消息，并将执行类型的测试消息广播至各个执行设备。从而上述业务系统中各个执行设备会接收到广播出来的测试消息，并将该测试消息中的设备标识与自身的设备标识进行比对，若比对一致，说明该测试消息是发给本机的，此时该目标执行设备可以基于测试消息中的测试标识，获取对应的测试脚本，并基于测试脚本执行目标性能测试。

其中，上述执行类型表示执行设备接收到该类型的测试消息并且确定时发往本机的消息时，启动目标性能测试的测试过程。终端还可以生成其他类型的测试消息并广播至目标执行设备。例如，在一个实施例中，终端还可以获取上述各目标执行设备的心跳信息，并基于心跳信息确定各目标执行设备是否故障。若终端在发送上述对应的测试消息至目标业务执行设备后，确定出目标执行设备出现故障，则终端可以根据目标执行设备的设备标识和测试取消指令，生成对应的测试取消消息。目标执行设备接收到测试取消消息后，可以检测测试取消消息中设备标识是否与自身的设备标识一致，并在检测到一致的情况下停止执行上述目标性能测试。另外，终端还可以基于上述设备标识生成采集运行快照文件对应的消息，使得目标执行设备在确定所述设备标识与自身标识一致的情况下采集对应运行快照。

具体地，对于执行类型的测试消息，若测试人员在终端中仅点击执行”按钮执行目标性能测试，则终端可以获取当前业务系统中所有非故障的空闲设备，从中选取一台，并通过上述任务调度平台，基于用户的需求，结合设备标识和测试标识组装测试消息，并广播至上述业务系统中的各个执行设备的执行任务装置。若测试人员在终端中选择指定目标执行设备执行目标性能测试，终端可以通过任务调度平台直接组装对应的测试消息并发往目标执行设备。另外，对于取消类型的测试取消消息，测试人员可以在终端中点击“停止执行”的按钮，使得终端可以基于需要取消的目标执行设备的设备标识，生成对应的测试取消消息，并通过广播方式发往目标执行设备，使其停止目标性能测试。另外，终端还可以接收目标执行设备的状态自检信息，目标执行设备每两分钟上传一次自身的运行状态信息，若终端检测到连续两个心跳间隔内，目标执行设备未上送其运行状态信息，终端可以通过任务调度平台发送上述测试取消消息，使得目标执行设备结束执行上述目标性能测试的测试过程，并释放该目标执行设备。对于抓取类型的消息，终端可以在检测到异常运行状态信息时，根据异常的目标执行设备的设备标识生成对应的抓取消息，并广播至业务系统中，使得目标执行设备接收到上述抓取消息后，通过执行任务装置按照一定频率抓取上述javacore和heapdump文件，发送到指定位置，防止因容器重启导致文件损失。

具体地，如图4所示，图4为一个实施例中执行设备判断步骤的流程示意图。上述业务系统中各个执行设备中配置有执行任务装置和Jmeter环境的云容器。执行设备在接收到上述终端发送的各个类型的消息时，可以首先判断消息内的设备标识是否为本机的标识，若是则本机进入判断消息类别的流程，并根据消息类别执行对应的流程；若执行设备判断不是本机标识，可以结束本次消息并不作处理。若存在目标执行设备检测到消息类型为执行类型，则目标执行设备可以根据该消息中的测试标识，查询数据库中保存的测试案例解析的结果，获取解析得到的jmx结构，从而得到测试脚本，并通过对上述jmx结构进行一定处理后，使得终端可以获取到目标执行设备执行目标性能测试的过程信息，目标执行设备可以调用上述Jmeter进行目标性能测试，测试结束后，目标执行设备可以将测试报告发往指定位置，例如发送至终端中，并在终端中进行展示。若消息类型为取消执行，目标执行设备可以结束当前正在处理的Jmeter进程，并登记任务结束，发送解锁消息至终端，使得终端释放该目标执行设备。若消息类型为抓取类型，即获取运行快照文件，目标执行设备可以按照一定频率获取上述javacore和heapdump文件。其中，上述频率可以是在测试计划新增时设置的频率，例如可以是一分钟采集一次。

通过上述实施例，终端可以基于目标执行设备的状态生成不同类型的消息，并广播至目标执行设备，使得目标执行设备可以根据实时接收到的消息执行对应的流程，提高了性能测试的效率。

在一个实施例中，还包括：获取测试脚本对应的多个历史测试报告；多个历史测试报告包括多个历史时间点测试得到的多个合格运行状态信息；多个历史时间点表征测试脚本对应的一个测试周期内的多个时间点；将多个历史时间点以及各个历史时间点对应的合格运行状态信息输入待训练长短期记忆模型，由待训练长短期记忆模型基于多个历史时间点以及多个历史时间点对应的多个合格运行状态信息，输出测试脚本对应的各个历史时间点的运行状态预测信息；根据各个历史时间点的运行状态预测信息与各个时间点的合格运行状态信息的相似度，调整待训练长短期记忆模型的模型参数，直至满足训练条件时，得到目标长短期记忆模型。

本实施例中，终端可以预先训练出目标LSTM(Long Short Term Memory，长短期记忆)模型。其中，一个执行设备对应的一个测试脚本可以对应一个目标长短期记忆模型，即每个执行设备可以对应多个测试脚本对应的目标长短期记忆模型。对于上述测试脚本，在训练过程中终端可以获取上述测试脚本对应的多个历史测试报告。其中，多个历史测试报告中包括多个历史时间点测试得到的多个合格运行状态信息。合格运行状态信息表示目标执行设备的运行状态符合预期。上述多个历史时间点表示测试脚本对应的一个测试周期内的多个时间点，例如从测试开始到测试结束的时间段内的各个时间点。

终端可以获取待训练的长短期记忆模型，并将上述多个历史时间点以及各个历史时间点对应的合格运行状态信息输入待训练的长短期记忆模型，由待训练长短期记忆模型基于多个历史时间点以及多个历史时间点对应的多个合格运行状态信息，输出上述测试脚本对应的各个历史时间点的运行状态预测信息。终端可以根据上述模型输出的各个历史时间点的运行状态预测信息与对应的各个时间点的合格运行状态信息的相似度，调整待训练长短期记忆模型的模型参数，直至满足训练条件时，得到目标长短期记忆模型。其中，上述运行状态信息可以包括多种类型的运行状态，各类运行状态可以作为模型预测时的特征信息。例如，在一个实施例中，将多个历史时间点以及各个历史时间点对应的合格运行状态信息输入待训练长短期记忆模型，包括：针对每个历史测试报告，获取该历史测试报告中各个历史时间点对应的线程数、内存信息、传输控制协议连接数、响应时间、单位时间业务处理数量、业务处理失败数和请求耗时中的至少一种，作为各个历史时间点对应的合格运行状态信息；将各个历史时间点对应的合格运行状态信息，输入待训练长短期记忆模型，由待训练长短期记忆模型基于各个历史时间点以及各个历史时间点对应的合格运行状态信息，提取运行状态特征与时间点之间的关系，并基于关系输出测试脚本对应的各个历史时间点的运行状态预测信息。本实施例中，上述各个历史测试报告中可以包括各个历史时间点对应的线程数、内存信息、传输控制协议连接数、响应时间、单位时间业务处理数量、业务处理失败数和请求耗时中的至少一种，终端可以获取上述至少一种运行状态，作为各个历史时间点对应的合格运行状态信息。从而终端可以将上述各个历史时间点的合格运行状态信息输入待训练的长短期记忆模型中，对待训练的长短期记忆模型进行训练，得到目标长短期记忆模型。

具体地，对于交易业务系统，由于不同交易的外围节点不同，例如不同交易业务通信时使用的方式不同等，使得运行特征会有所差异，终端可以累积一定量的测试报告，保证数据充足，以确保提取特征的准确度。例如，对于一支交易的完成，需要由多个应用多个节点合作完成。对于一支交易内部的节点来说，它的外围节点包含了链路的上游节点、链路的下游的节点，自身节点之间的交互，如数据库、消息中间件等。根据交易完成链路的差异，外围节点存在一定的差异。其中，单个业务可以对应单个测试脚本，终端可以获取单个业务对应的多个历史的测试报告，并从测试报告中提取wait线程数、内存、TCP(TransmissionControl Protocol，传输控制协议)连接数、响应时间、TPS(TransactionPerSecond，每秒事务处理量)、失败交易数、请求耗时等作为特征，并将这些特征的取值和时间序列的关系输入上述待训练LSTM，提取相关特征与时间的关系。终端可以根据该关系，对指定交易节点的执行设备的性能有一定的预测能力。

其中，以交易特征为例，终端训练得到上述LSTM的过程包括：步骤1、使用数据处理工具获取不同交易的压测数据，如压测时间、线程数、持续时间、连接时长、延迟时间、响应时间等，对每个交易取上述特征，构建为一条数据。如交易1：(取款,3,600s,0.01s,0.01s,0.02s)分别对应(交易名称、线程数、持续时间、连接时长、延迟时间、响应时间)步骤2、因为交易信息为非板块化数据，不利于分析和处理，因此将其转换为结构化数据。建立交易信息的数据字典将其转换为结构化数据。具体如下表所示：

终端可以将步骤1的交易数据转换为：交易1：(1,3,600s,0.01s,0.01s,0.02s)。步骤3：通过步骤1、步骤2获取了交易信息，构成了交易数据特征表，以该表数据建立多维数据轴。其中，维度为压测时间、线程数、持续时间、连接时长、延迟时间、响应时间，并用表中各交易的数据构建交易特征分布坐标系。交易数据特征表如下所示：

数据获取过程中，终端可以获取到交易的历史数据，如交易名称、线程数、持续时间、连接时长、延迟时间、响应时间，可以反映交易的各项特征的变化情况，构建交易历史数据表：

终端可以将交易历史数据以响应时间为标签，其余特征以日期升序构建训练数据对(X_train,Y_train)。构建循环神经网络LSTM模型，与其他传统神经网络不同的是它对于多个输入数据不是独立的，在每一次计算后会把结果和下一个输入一起传入下个计算单元,对隐藏层可简单表示为g(x)＝σ(W(x+a)+b)。因此能够实现对过去数据的“记忆”，而对未来做更准确的预测。通过传入交易历史数据，通过LSTM模型学习历史数据减小对响应时间的预测误差。以步骤1的历史数据表数据为例，终端可以构建训练数据：将取款响应时间作为标签Y，Y取值序列为：Y1,Y2,...＝[0.98，0.975，...]。将取款交易压测时间、线程数、持续时间、连接时长、延迟时间、响应时间以日期升序作为特征X，X的取值序列为：X1,X2,...＝[(30,200,0.02,0.01,1,2022-aa-bb),(30,200,0.01,0.02,1,2022-aa-(bb+1)),...]。

从而终端可以建立LSTM模型及其学习过程，如图5所示，图5为一个实施例中训练步骤的流程示意图。LSTM可简单表示为g(x)＝σ(Wx+b)，通过传入(X,Y)数据对后神经网络输入层可表示为a＝σ(WX+b)，隐藏层为g(x)＝σ(W(X+a)+b)，其中σ为LSTM的输入门与遗忘门参数，合并为σ表示。通过BP反向传播，每一轮学习过程中使参数σ，W，b呈梯度下降直到收敛，此时模型便构建好了。对于要预测结果Y的新数据X，传入X后得g(X)＝σ(WX+b)，即可求得需预测的结果Y＝g(X)，即响应时间未来走势特征，也可以称为运行状态预测信息。终端可以根据上一步获得的运行状态预测信息根据输入生成随时间变化的数据，利用特征提取器将新元数据转成特征矩阵，利用余弦相似度算法计算中两份元数据的距离，并归一化到[0，1]之间的相似度。若相似度超过90％则认为节点交易正常，否则认为是发生交易异常，发送告警等待处理。其公式如下所示：

其中，x是交易的特征矩阵，y是配置中心新推送的新定义特征矩阵，||x||表示曾经发生交易的特征矩阵的欧几里得范数，||y||表示当前正在进行交易的特征矩阵的欧几里得范数，x

通过上述实施例，终端可以基于单个业务的测试脚本对应的历史测试报告，提取其中的多个时间点的特征，训练得到目标长短期记忆模型，从而终端可以基于目标长短期记忆模型对目标执行设备的运行状态进行预测，提高了性能测试的效率。

在一个实施例中，对当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较，包括：获取当前时间点的运行状态信息与目标长短期记忆模型输出的各个时间点中对应时间点的运行状态预测信息的相似度；若检测到当前时间点对应的的相似度小于预设相似度阈值，确定比较结果表征当前时间点的运行状态信息为异常运行状态信息。

本实施例中，终端对目标执行设备在目标性能测试的过程中的运行状态进行检测，以判断目标执行设备的运行状态是否正常。终端可以将上述测试脚本输入目标长短期记忆模型，由目标长短期记忆模型输出测试脚本对应的各个时间点的运行状态预测信息，终端可以获取各个时间点的运行状态预测信息与当前时间点的运行状态信息的相似度，具体地，可以是余弦相似度。若终端检测到当前时间点与对应时间点的运行状态信息的相似度小于预设相似度阈值，则终端可以确定比较结果为当前时间点的运行状态信息为异常运行状态信息。另外，在一些实施例中，终端还可以在检测到预设时间段内各个时间点的相似度均小于预设相似度阈值时，确定比较结果表征当前时间点的运行状态信息为异常运行状态信息，即终端可以获取目标性能测试过程中多个时间点的运行状态信息，并分别与对应时间点的运行状态预测信息进行比较，当比较得到的相似度均小于预设相似度阈值，确定目标执行设备进入异常状态。其中，上述相似度具体可以是余弦相似度，终端可以通过检测运行状态信息与运行状态预测信息之间的余弦相似度，确定运行状态信息是否异常。

通过本实施例，终端可以基于目标长短期记忆模型，在目标执行设备进行目标性能测试过程中检测是否出现运行状态异常，提高了性能测试的效率。

在一个实施例中，采集目标执行设备对应的运行快照，并保存运行快照，包括：向目标执行设备发送文件抓取消息；文件抓取消息中包含抓取频率和文件中转站的地址信息，文件抓取消息用于指示目标执行设备根据抓取频率，抓取对应的堆转储文件和线程快照文件，并将堆转储文件和线程快照文件发送至文件中转站；其中，堆转储文件包括目标执行设备执行测试脚本时的内存堆栈快照；线程快照文件包括目标执行设备执行测试脚本时处理器对应的每个线程的执行栈；其中，文件中转站用于保存堆转储文件和线程快照文件至数据库中。

本实施例中，终端在检测到目标执行设备出现运行状态异常信息时，采集目标执行设备的相关运行快照文件。终端确定需要采集运行快照文件时，可以向目标执行设备发送文件抓取消息，其中文件抓取消息可以基于目标执行设备的设备标识、抓取频率和文件中转站的地址信息生成，目标执行设备接收到文件抓取消息后，可以在确定消息中的设备标识是本机的标识的情况下，基于其中的抓取频率，抓取对应的堆转储文件和线程快照文件，并将堆转储文件和线程快照文件按照消息中的地址信息发送至文件中转站。其中，上述堆转储文件可以是上述HeapDump文件，包括目标执行设备执行测试脚本时的内存堆栈快照；上述线程快照文件可以是上述JavaCore文件，包括目标执行设备执行测试脚本时处理器对应的每个线程的执行栈。文件中转站接收到上述各个运行快照文件后，可以保存堆转储文件和线程快照文件至数据库中。

具体地，在目标性能测试过程中，终端可以根据目标长短期记忆模型，判断目标执行设备的运行状态信息与运行状态预测信息进行比较，若存在较大偏差则终端可以通过任务调度平台发起文件抓取消息，要求目标执行设备通过执行任务装置抓取javacore和heapdump文件，通过短信、邮件的方式提醒联系开发人员及时跟进。其中，上述javacore和heapdump文件可以被发往文件中转平台，文件中转平台可以存放任务执行装置完成压力测试的压测报告及接收到抓取javacore和heapdump文件消息时将按照指定频率抓取的文件，从而可以避免因容器重启损失相关文件。其中，上述文件来源于目标执行设备中的任务执行装置。

通过本实施例，终端可以在目标执行设备异常时，通过文件抓取消息令指示抓取目标执行设备中的运行快照文件，使得相关测试开发人员可以基于运行快照文件进行分析和改进，从而提高了性能测试的效率。

在一个实施例中，如图6所示，图6为另一个实施例中性能测试中的异常检测方法的流程示意图。本实施例中，终端中可以设置有压力测试平台、任务调度平台、运行状态判断平台等。业务系统中的各个执行设备可以配置有任务执行装置。其中，各个测试人员可以是各个测试人员。终端可以在压力测试平台的前端页面供测试人员登录，提供测试人员发起目标性能测试的渠道。测试人员可以在此平台管理测试案例，包含有常规的案例增加、案例删除、拷贝现有案例、根据实际压力测试需求对测试案例参数做调整、导出现有案例文件等。该平台同时提供每一次压力测试的压力报告供测试人员下载，帮助测试人员了解每一次压力测试情况。平台为测试人员展示所有运行正常的机器，测试人员可根据实际需要选择设备执行压力测试，也由任务调度平台调度选择压力测试的设备。

具体地，压力测试平台内包含有四个栏目，分别是：测试脚本、测试任务、执行机、指标库。测试脚本栏目内给用户展示了用户权限内的所有脚本。测试人员可以在终端中增加测试案例，测试人员登录压力测试平台后，在测试计划页面新增测试计划，输入版本、应用名称、测试计划名称即可。编辑详情后将原始的jmx脚本拖入，压力测试平台会解析原始jmx并在前端展示，例如，压测测试平台解析原始jmx文件后获得相应的压测基础参数信息，如线程组用户数、延迟线程创建时间、压测持续时间、压测执行次数、压测请求的路径、端口、相关组件等等。终端对原始jmx的处理完成了两个内容：压力测试人员原本通过可视化模式发起压测，在压测过程中能看到压测的情况，在压测执行装置上执行压力测试为非可视化模式，无法正常观测。通过对jmx的处理，增加了相应组件，保证了新系统和原始jmeter提供一致的可视化服务。通过对jmx的处理，后台可实时获取到压测的数据可用于趋势相似度判断。由此将测试人员的测试案例保存到了后台。终端中还可以进行测试案例的编辑，测试人员登录压力测试平台后，点击选择测试计划，点击详情后可浏览到该测试计划的整体结构，每个组件的配置，测试人员通过点击组件名称可查看组件的详情，可在页面中手工输入修改后的参数，点击保存即可将测试案例覆盖为新的，后台将解析的结果存入数据库中，供后续使用。测试人员还可以进行测试案例删除，测试人员登录压力测试平台后，点击选择测试计划，点中删除按钮，完成测试人员案例的删除。由于权限控制，除非压力测试平台管理员，否则其他人无权修改或删除其他人的测试计划。测试人员可以通过终端发起目标性能测试，测试人员登录压力测试平台后，选择测试计划旁边的执行按钮，即可发起压力测试，此时由任务调度平台选择机器执行压力测试。测试人员还可以终止目标性能测试，测试人员登录压力测试平台后，出于各种考虑决定停止压力测试，可以点击测试计划右侧的停止执行按钮，终端中的任务调度平台将采用广播方式向压力测试机器发送停止指令，结束压力测试。测试人员还可以在终端中进行历史报告浏览，测试人员可根据压力发起测试的时间获取指定的压力测试报告，了解历史压力测试情况。并且还可以进行文件抓取频率配置，终端通过任务运行状态平台判断节点运行过程中性能出现较大的偏差时，会向任务调度中心发消息抓取相关的javacore和heapdump文件，测试人员可根据自身的需要配置，默认时间为一分钟采集一次。

其中，上述终端可以是一种调度机，调度机可以接收测试人员在浏览器发起的请求，若测试人员指定机器运行压测则直接将请求发往指定机器；若测试人员未指定机器运行压测则根据机器集群的机器运行情况选择机器压测，并将选定的压测机器信息写入数据库，便于后续追踪。并且，调度机可以使用广播机制将消息发往所有执行机，执行机根据消息内的执行机器信息判断是否为本机执行。执行机可以是上述业务系统中的目标执行设备。执行机启动时将运行相关信息写入数据库中，从而测试人员可以在终端的前端页面查看。执行机在接收调度机的命令时，判断选中的执行机器是否为本机，若是本机执行则更新本机的状态为使用中并对测试计划，例如上述Jmx的测试脚本，做出修改，并且执行机还可以补充后端监听器和BeanShell脚本，完成后执行机启动新的测试计划，测试完成后更新执行机状态为空闲，将测试生成的文件发往指定位置，例如发往文件中转站，便于测试人员在前端查看。其中，执行机的状态包括空闲、使用中和故障等状态。后端监听器可以是上述Jmeter的内部功能，可将测试计划的汇总数据写入Influxdb(时序数据库)中，数据包含有：交易笔数、成功交易数、失败交易数、响应时间等。BeanShell是使用Java语言编写的轻量级的脚本语言，通过Beanshell可执行Java代码完成一定的逻辑计算。

通过上述实施例，终端通过训练目标长短期记忆模型，在目标执行设备执行测试的过程中，在对应时间点及时检测出测试状态发生异常，进而及时抓取对应的运行快照，提高了异常检测的效率。并且能够有效地降低性能测试的门槛，测试人员无需在多个系统内了解压测信息，实现了在一个系统内整合性能测试常用信息，做到了清晰直观展示被压测服务器的资源使用情况、性能测试发起的笔数、成功率等，也能够在一定程度上释放压测人员的机器，做到既能保证压测的发起，也能完成其他的工作内容，避免机器性能的问题影响工作。并且，上述云容器具有易收缩、扩容简单的特点，相比于个人机器能够更好的适应性能测试的需求。

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

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的性能测试中的异常检测方法的性能测试中的异常检测装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个性能测试中的异常检测装置实施例中的具体限定可以参见上文中对于性能测试中的异常检测方法的限定，在此不再赘述。

在一个实施例中，如图7所示，提供了一种性能测试中的异常检测装置，包括：确定模块500、发送模块502、检测模块504和采集模块506，其中：

确定模块500，用于接收针对目标性能测试的测试指令，从业务系统中包含的多个执行设备中确定出目标执行设备。

发送模块502，用于发送对应的测试消息至目标执行设备，测试消息中携带目标性能测试对应的测试标识，测试消息用于指示目标执行设备基于测试标识获取对应的测试脚本，并基于测试脚本执行目标性能测试。

检测模块504，用于获取目标执行设备执行目标性能测试过程中当前时间点的运行状态信息，并对当前时间点的运行状态信息与对应时间点的运行状态预测信息进行比较；对应时间点的运行状态预测信息基于目标长短期记忆模型、且在以测试脚本为模型输入时的模型输出得到；目标长短期记忆模型根据测试脚本对应的多个历史测试报告训练得到。

采集模块506，用于若比较结果表征当前时间点的运行状态信息为异常运行状态信息，采集目标执行设备对应的运行快照，并保存运行快照。

在一个实施例中，上述确定模块500，具体用于获取业务系统中各执行设备的设备状态；将设备状态为非故障且空闲状态的执行设备，确定为目标执行设备。

在一个实施例中，上述发送模块502，具体用于获取目标执行设备对应的设备标识，根据设备标识和目标性能测试对应的测试标识，生成执行类型的测试消息；将执行类型的测试消息广播至各个执行设备，执行类型的测试消息用于指示接收到该测试消息的各执行设备比对设备标识与自身标识是否一致，在一致的情况下根据测试标识获取对应的测试脚本，并基于测试脚本执行目标性能测试。

在一个实施例中，上述装置还包括：训练模块，用于获取测试脚本对应的多个历史测试报告；多个历史测试报告包括多个历史时间点测试得到的多个合格运行状态信息；多个历史时间点表征测试脚本对应的一个测试周期内的多个时间点；将多个历史时间点以及各个历史时间点对应的合格运行状态信息输入待训练长短期记忆模型，由待训练长短期记忆模型基于多个历史时间点以及多个历史时间点对应的多个合格运行状态信息，输出测试脚本对应的各个历史时间点的运行状态预测信息；根据各个历史时间点的运行状态预测信息与各个时间点的合格运行状态信息的相似度，调整待训练长短期记忆模型的模型参数，直至满足训练条件时，得到目标长短期记忆模型。

在一个实施例中，上述训练模块，具体用于针对每个历史测试报告，获取该历史测试报告中各个历史时间点对应的线程数、内存信息、传输控制协议连接数、响应时间、单位时间业务处理数量、业务处理失败数和请求耗时中的至少一种，作为各个历史时间点对应的合格运行状态信息；将各个历史时间点对应的合格运行状态信息，输入待训练长短期记忆模型，由待训练长短期记忆模型基于各个历史时间点以及各个历史时间点对应的合格运行状态信息，提取运行状态特征与时间点之间的关系，并基于关系输出测试脚本对应的各个历史时间点的运行状态预测信息。

在一个实施例中，上述检测模块504，具体用于获取当前时间点的运行状态信息与目标长短期记忆模型输出的各个时间点中对应时间点的运行状态预测信息的相似度；若检测到当前时间点对应的的相似度小于预设相似度阈值，确定比较结果表征当前时间点的运行状态信息为异常运行状态信息。

在一个实施例中，上述采集模块506，具体用于向目标执行设备发送文件抓取消息；文件抓取消息中包含抓取频率和文件中转站的地址信息，文件抓取消息用于指示目标执行设备根据抓取频率，抓取对应的堆转储文件和线程快照文件，并将堆转储文件和线程快照文件发送至文件中转站；其中，堆转储文件包括目标执行设备执行测试脚本时的内存堆栈快照；线程快照文件包括目标执行设备执行测试脚本时处理器对应的每个线程的执行栈；其中，文件中转站用于保存堆转储文件和线程快照文件至数据库中。

在一个实施例中，上述装置还包括：故障检测模块，用于获取各目标执行设备的心跳信息，基于心跳信息确定各目标执行设备是否故障。

在一个实施例中，上述装置还包括：停止测试模块，用于若确定出目标执行设备出现故障，根据目标业务执行设备的设备标识和测试取消指令，生成对应的测试取消消息；将测试取消消息发送至目标执行设备，测试取消消息用于指示目标执行设备在确定设备标识与自身标识一致的情况下停止执行目标性能测试。

上述性能测试中的异常检测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种性能测试中的异常检测方法。该计算机设备的显示单元用于形成视觉可见的画面，可以是显示屏、投影装置或虚拟现实成像装置。显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述的性能测试中的异常检测方法。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述的性能测试中的异常检测方法。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的性能测试中的异常检测方法。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

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

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