接口覆盖测试方法、系统、计算机设备和存储介质与流程

本发明涉及网络数据处理技术领域，尤其涉及一种接口覆盖测试方法、系统、计算机设备和存储介质。

背景技术：

软件测试(英语：softwaretesting)，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

目前，在软件测试开发过程中，针对模拟线上运行的测试方法，通常使用测试工具。通过运用测试工具，可以达到提高测试效率的目的。测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。

但是，目前通常使用的测试工具，对于api(应用程序编程)接口一般使用jmeter等工具测试；对于非标准接口，一般直接编写代码进行测试；测试工具不能同时兼容api接口和未提供标准接口的代码接口，兼容性低，需要依赖人工介入调整，且测试用时较长和效率低。

技术实现要素：

有鉴于此，有必要针对现有测试过程中api接口和代码接口兼容性低的问题，提供一种接口覆盖测试方法、系统、计算机设备和存储介质。

一种接口覆盖测试方法，包括如下步骤：

调取任务组，根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；

将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；

调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；

从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。

在其中一个实施例中，所述调取任务组，根据预设的时间阈值对任务组中的任务进行分类剥离，并按生成时间排序构成一组定时任务包括：

通过jenkins工具识别所述时间阈值后生成任务的时间节点，并设置一查询脚本对所述时间节点进行查询，调用所述查询脚本连接所述jenkins工具对分类剥离后的任务的时间节点进行监控，当所述时间节点与所述时间阈值一致时，继续对所述任务组进行分类剥离，当所述时间节点与所述时间阈值不一致时，重新修订所述时间阈值。

在其中一个实施例中，在所述将所述定时任务的业务代码进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理，生成接口类型测试的配置文件包括：

对所述业务代码进行数据的初始化处理得到接口识别代码；

将所述接口识别代码输入到所述配置文件中，所述配置文件内包含接口种类、生成时间、存储位置；

所述业务框架对所述接口识别代码进行封装构成一接口识别框架，所述接口识别框架用于对所述接口的类型进行识别。

在其中一个实施例中，所述执行接口测试包括：

启动所述业务框架中的主类main()方法对所述配置文件进行读取，并对所有过程数据进行清洗、初始化；

调用所述业务框架中的各个子类，采用子类setup()方法对经过所述主类main()方法清洗、初始化后得到的数据进行再次清洗，并进行接口测试，得到相应子类的测试结果；

在所述主类main()方法中，使用htmltestrunner工具把所述子类的测试结果进行整合，并以html格式输出整合结果。

在其中一个实施例中，所述从所述数据库中获取测试结果，包括：

从所述数据库中读取原始jmeter测试脚本，对所述原始jmeter测试脚本进行解析，并将所述原始jmeter测试脚本中的测试场景分离出来；

获取所述定时任务中与所述原始jmeter测试脚本相互关联的测试场景，用所述与原始jmeter测试脚本相互关联的测试场景替换所述原始jmeter测试脚本中分离出来的测试场景后生成新的jmeter测试脚本；

根据所述新的jmeter测试脚本对所述业务框架中的数据进行识别得出测试结果。

在其中一个实施例中，在所述主类main()方法对所述配置文件进行读取过程中，所述主类main()方法装载需要执行的子类到测试套件中进行顺序调用；

所述测试套件是测试用例的集合,任意一个所述测试套件包括一组测试用例；

若一组测试用例中的任意两个测试用例在业务场景上有依赖关系，则将所述两个测试用例放到一个测试套件中执行。

在其中一个实施例中，若所述定时任务执行成功,则通过htmltestrunner工具中的html表格将所述定时任务执行成功的信息传递到客户端，所述客户端通过访问带有所述html表格的页面获知所述定时任务执行成功的信息；

若所述定时任务执行失败，则启动所述业务框架重新生成新配置文件。

一种接口覆盖测试系统，包括如下单元：

任务排序单元，设置为调取任务组、根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；

任务处理单元，设置为将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；

结果生成单元，设置为调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；

结果判断单元，设置为从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。

一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被一个或多个所述处理器执行时，使得一个或多个所述处理器执行上述接口覆盖测试方法的步骤。

一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个所述处理器执行上述接口覆盖测试方法的步骤。

上述接口覆盖测试方法、装置、计算机设备和存储介质，包括调取任务组，根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。本技术方案针对现有测试过程中api接口和代码接口兼容性低，需要借助人工手段进行调整的问题，通过任务组进行定时筛分，启用业务框架对业务代码进行整理生成配置文件，从而达到对api接口和代码接口的全覆盖。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。

图1为本发明的一种接口覆盖测试方法的整体流程图；

图2为本发明的一种接口覆盖测试方法中的任务排序过程示意图；

图3为本发明的一种接口覆盖测试方法中的接口测试过程的流程图；

图4为本发明的一种接口覆盖测试系统的结构图。

具体实施方式

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

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。

图1为本发明一个实施例中的接口覆盖测试方法的流程图，如图1所示，一种接口覆盖测试方法，包括以下步骤：

s1、调取任务组，根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；

预设的时间阈值是根据每一个任务生成时的时间长短进行设置，在任务存储到数据库中时自动产生，但是预设的时间阈值可能会因为产生的记录错误或者多个任务存储到数据库中而引起的高并发事件，会导致每个任务生成或者结束的时间节点与预设的时间阈值不一致；因此对于预设的时间阈值还需要进行进一步的修订。

s2、将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；

该配置文件的内容中可以包括数据类型、数据生成时间和数据存储位置等；当配置文件生成好之后只需调取配置文件即可实现对api数据和代码接口的测试。

s3、调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；

对配置文件进行处理主要是根据需要进行测试的api数据和/或代码数据进行适配性选择配置文件的内容，比如原配置文件中内容中设置了数据生成时间这一内容，但是需要进行测试的api数据或者代码数据对测试时间没有限制，则将数据生成时间这一内容从配置文件中剔除以增加配置文件运行的效率。

s4、从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。

如果定时执行成功则证明采用本方法可以实现对api数据和代码数据的接口全部覆盖；否则需要重新执行s1～s3步骤，并且对时间阈值、配置文件等进行适用性修改。

本申请通过上述方法步骤，实现对一组包含有api数据和代码数据的业务框架进行接口测试时，能够准确的覆盖适应api接口和代码接口从而使数据测试完全自动化，减少了人工的介入。

本实施例中，预设的时间阈值是根据任务组中各个任务的生成时间进行计算得出的，可以使用apriori算法算法对时间阈值进行设定，apriori算法是一种需要多次迭代的算法，经过扫描一次数据库，统计数据库中单个项目的计数，将满足最小支持度要求的单个项目提取成1个频繁项集l1，并将频繁项目l1作为下一次扫描的基础项目。然后重复扫描数据库，第(k-1)次扫描生成(k-1)个频繁项集l后，第k次扫描时先通过连接操作将lk-1中的项集生成k-项候选集ck，再通过剪枝操作删除ck中不满足最小支持度计数的项集，从而得到频繁项集lk。重复扫描数据库，从该集合里产生下一级候选项集，直到不产生新的候选项集为止。

在进行任务剥离的过程中可以将时间阈值设定为一个变量，即增加一个权重对时间阈值进行修正，当时间阈值小于任务生成时间时，需要对时间阈值进行增加，即可以将时间阈值带入到一个误差修正模型中进行训练。该误差修正模型可以采用均方根误差rmse来进行计算，也可以采用granger表述定理对误差进行修正。

在对定时任务进行分类组装时，业务框架通过调取存储在数据库中的预设的api数据形式和代码数据形式进行比对，将带有api数据的任务和带有代码数据的任务进行封装成一个数据组。在进行测试时，需要对数据组中是否包含api数据和代码数据进行复验，如果复验时发现数据组中只有一种数据形式，则需要对业务框架中数据获取模块进行修正。

图2为本发明在一个实施例中的任务排序过程示意图，如图所示，在所述调取任务组，根据预设的时间阈值对任务组中的任务进行分类剥离，并按生成时间排序构成一组定时任务过程中，包括：

通过jenkins工具识别所述时间阈值后生成任务的时间节点，并设置一查询脚本对所述时间节点进行查询，调用所述查询脚本连接所述jenkins工具对分类剥离后的任务的时间节点进行监控，当所述时间节点与所述时间阈值一致时，继续对所述任务组进行分类剥离，当所述时间节点与所述时间阈值不一致时，重新修订所述时间阈值。

jenkins是一个开源软件项目，是基于java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

在本实施例中，使用jenkins对时间阈值与任务时间节点进行比照时，所应用的查询脚本是对jenkins的主节点和从节点均能进行查询的查询脚本，具体的在应用jenkins对主节点和从节点进行查询时是通过服务器对主节点或者从节点进行控制。服务器接收到一个前端模块发送的查询节点的请求，然后响应该请求，并建立起服务器与该查询脚本之间通信联系，通过服务器控制从节点与主节点的连接进程，来确定主节点和从节点的连接状态。如果查询到的主节点和从节点的连接进程则说明该查询脚本处于正常运行的状态；如果查询不到主节点和从节点的连接状态则说明该查询脚本处于断开状态，此时需要对查询脚本进行重新配置。

本实施例，通过jenkins对时间阈值与任务时间节点进行比照，能够更好的修正时间阈值使其与时间节点相互匹配。

在一个实施例中，在所述将所述定时任务的业务代码进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理，生成接口类型测试的配置文件，包括：

对所述业务代码进行数据的初始化处理得到接口识别代码；

初始化处理主要是将业务代码中无用的数据进行清除和整理，减少业务代码中数据量，这样可以减少一层业务框架中数据总量从而实现快速封装。

将所述接口识别代码输入到所述配置文件中，所述配置文件内包含接口种类、生成时间、存储位置；

其中，接口类型包括api接口和代码接口，生成时间可以按照从远到近的顺序也可以按照从近到远的顺序进行配置，同时也可以将同一生成时间的数据进行分割或者组合生成数据组，根据数据组的生成时间来生成配置文件。所述业务框架对所述接口识别代码进行封装构成一接口识别框架，所述接口识别框架用于对所述接口的类型进行识别。

识别框架对接口进行识别主要是对api函数进行识别来识别出api接口，而对于代码接口则是通过识别特征字符来进行识别。

本实施例中，在对业务代码进行处理时应用sql语言，sql即结构化查询语言(structuredquerylanguage)，是一种特殊目的的编程语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统；同时也是数据库脚本文件的扩展名。sql语言无论是种类还是数量都是繁多的，很多语言也是经常要用到的，sql查询语言就是一个典型的例子，无论是高级查询还是低级查询，sql查询语言的需求是最频繁的。

应用sql语言在对业务代码进行初始化整理时，先对已有的业务代码进行清除去除历史数据，然后开始创建新的数据库，向新建立的数据库中添加业务代码，对一组业务代码按照所存位置，主数据文件的初始大小，主数据文件增长的最大值和主数据文件的增长率进行对业务代码的细分。一组业务代码经过细分后生成多个子业务代码包，再对子业务代码包进行api接口的识别。

本实施例，通过sql语言对业务代码的初始化整理，能够有效增强对api接口的识别率。

在其中一个实施例中，采用bat脚本将接口识别代码输入到配置文件中。bat脚本也被称为批处理脚本。

批处理就是对某对象进行批量的处理，通常被认为是一种简化的脚本语言，它应用于dos和windows系统中。批处理文件的扩展名为bat。目前比较常见的批处理包含两类：dos批处理和ps批处理。ps批处理是基于强大的图片编辑软件photoshop的，用来批量处理图片的脚本；而dos批处理则是基于dos命令的，用来自动地批量地执行dos命令以实现特定操作的脚本。更复杂的情况，需要使用if、for、goto等命令控制程式的运行过程，如同c、basic等高级语言一样。如果需要实现更复杂的应用，利用外部程式是必要的，这包括系统本身提供的外部命令和第三方提供的工具或者软件。批处理程序虽然是在命令行环境中运行，但不仅仅能使用命令行软件，任何当前系统下可运行的程序都可以放在批处理文件中运行。

本实施例，通过bat脚本进行批量化的处理文件能够实现多个api接口和代码接口的同时测试，以实现在高并发条件下接口测试仍然具有稳定性。

在其中一个实施例中，采用shell脚本将接口识别代码输入到配置文件中。

shell脚本是与windows/dos下的批处理脚本bat类似的脚本，也就是用各类命令预先放入到一个文件中，方便一次性执行的一个程序文件，主要是方便管理员进行设置或者管理用的。但是它比windows下的批处理更强大，比用其他编程程序编辑的程序效率更高，它使用了linux/unix下的命令。

本实施例，由于使用了shell脚本是接口测试不仅能够适应windows系统同时也能够适应linux/unix增加了接口测试的系统普适性。

本实施例中，bat脚本或者shell脚本对经过sql语言处理过的子业务代码包进行再次封装生成代码集，并将代码集带入到配置文件中进行分类比对首先是接口种类即分为api接口和代码接口，然后是每个代码集生成的时间，最后是代码集的存储位置。

在配置文件将代码集中的数据进行整理，并按照配置文件的分类进行储存，同时业务框架对识别代码进行分类封装构成一层识别框架。在进行接口测试时，调取识别框架进行测试识别，如果测试结果出现问题则可以更改配置文件来对代码集进行修订。

图3为本发明在一个实施例中的接口测试过程的流程图，如图所示，包括：

s201、启动所述业务框架中的主类main()方法对所述配置文件进行读取，并对所有过程数据进行清洗、初始化；

在java语言中，一般程序将main函数作为程序的入口，程序是从main函数开始执行的。除了applet这个类不需要main函数，常用语程序测试。main函数的格式为：publicstaticvoidmain(string[]args)。

s202、调用所述业务框架中的各个子类，采用子类setup()方法对经过所述主类main()方法清洗、初始化后得到的数据进行再次清洗，并进行接口测试，得到相应子类的测试结果；

在应有main()方法进行数据清洗时，先对数据生成的时间进行识别，即根据时间阈值对数据进行分类，将在时间阈值之前生成的数据作为历史数据进行清除处理，并且去除不需要的字段，确定缺失值范围，填充缺失内容；其中填充确实内容主要是采用三种以业务知识或经验推测填充缺失值，以同一指标的计算结果(均值、中位数、众数等)填充缺失值，以不同指标的计算结果填充缺失值，清除处理完成后设该状态为初始化状态。

s203、在所述主类main()方法中，使用htmltestrunner工具把所述子类的测试结果进行整合，并以html格式输出整合结果。

在应用子类setup()方法对经过主类main方法清洗、初始化的数据进行再次清洗时，需要对逻辑错误清洗，其主要包括去重、去除不合理数值和修正矛盾内容。其具体步骤为，在test_xxx()中进行业务代码的调用，通过查询数据库结果或者通过查询日志进行结果比对，在teardown()方法中进行针对此业务的数据清理。

本实施例通过对接口测试过程中，进行主类main()方法对数据进行一次清洗初始化，再通过子类setup()方法对数据进行二次清洗，增加了数据的识别性，使封装好的业务框架能够更好的适应api接口和代码接口的测试。

本实施例中的，业务框架优选采用pythonunittest框架对代码进行初始化处理。其中，unittest中最核心的四部分是：testcase，testsuite，testrunner，testfixture，

(1)一个testcase的实例就是一个测试用例。测试用例就是指一个完整的测试流程，包括测试前准备环境的搭建(setup)，执行测试代码(run)，以及测试后环境的还原(teardown)。元测试(unittest)的本质也就在这里，一个测试用例是一个完整的测试单元，通过运行这个测试单元，可以对某一个问题进行验证；

(2)而多个测试用例集合在一起，就是testsuite，而且testsuite也可以嵌套testsuite；

(3)testloader是用来加载testcase到testsuite中的。

(4)texttestrunner是来执行测试用例的，其中的run(test)会执行testsuite/testcase中的run(result)方法；

(5)测试的结果会保存到texttestresult实例中，包括运行了多少测试用例，成功了多少，失败了多少等信息。

在一个实施例中，所述从所述数据库中获取测试结果，包括：

从所述数据库中读取原始jmeter测试脚本，对所述原始jmeter测试脚本进行解析，并将所述原始jmeter测试脚本中的测试场景分离出来；

本实施例中，jmeter是apache组织开发的基于java的压力测试工具。用于对软件做压力测试，它最初被设计用于web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、java小服务程序、cgi脚本、java对象、数据库、ftp服务器等等。jmeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，jmeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，jmeter允许使用正则表达式创建断言。

获取所述定时任务中与所述原始jmeter测试脚本相互关联的测试场景，用所述与原始jmeter测试脚本相互关联的测试场景替换所述原始jmeter测试脚本中分离出来的测试场景后生成新的jmeter测试脚本；

本实施例中，对测试场景进行替换生成新的jmeter测试脚本是通过对原始jmeter测试脚本与测试场景的时间或者事件关系进行映射来实现jmeter测试脚本与测试场景的关联，再将测试场景中与原始jmeter测试脚本不符的地方补充到jmeter测试脚本形成新的jmeter测试脚本。

根据所述新的jmeter测试脚本对所述业务框架中的数据进行识别得出测试结果。

本实施例中，新的jmeter测试脚本对业务框架中的数据识别主要是识别数据中是否存在着api函数，如果存在着api函数则说明是api接口，反之为代码接口。

在一个实施例中，在所述主类main()方法对所述配置文件进行读取过程中，所述主类main()方法装载需要执行的子类到测试套件中进行顺序调用；测试套件是测试用例的集合,任意一个测试套件包括一组测试用例；

若一组测试用例中的任意两个测试用例在业务场景上有依赖关系，则将所述两个测试用例放到一个测试套件中执行。

本实施例，通过将具有依赖关系的业务场景进行合并成一个测试套件可以减少测试场景数量加快接口测试的效率。

在一个实施例中，若所述定时任务执行成功,则通过htmltestrunner工具中的html表格将所述定时任务执行成功的信息传递到客户端，所述客户端通过访问带有所述html表格的页面获知所述定时任务执行成功的信息；

若所述定时任务执行失败，则启动所述业务框架重新生成新配置文件。

本实施例，通过htmltestrunner工具中的html表格能够直观的将测试结果展示出来方便测试人员及时得到检测结果。

在一个实施例中，提供了一种接口覆盖测试系统，如图4所示，包括如下单元：

任务排序单元，设置为调取任务组、根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；

任务处理单元，设置为将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；

结果生成单元，设置为调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；

结果判断单元，设置为从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。

在一个实施例中，提出了一种计算机设备，包括存储器和处理器，存储器中存储有计算机可读指令，计算机可读指令被处理器执行时，使得处理器执行计算机可读指令时实现以下步骤：调取任务组，根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。

在一个实施例中，提出了一种存储有计算机可读指令的存储介质，计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行以下步骤：调取任务组，根据预设的时间阈值对任务组中的任务按照生成时间的时间节点进行分类剥离，并以生成时间排序构成一组定时任务；将所述定时任务的业务代码按照api数据和代码数据进行分类组装并分配到业务框架中，所述业务框架获取所述业务代码并进行数据处理后生成对接口进行接口测试的配置文件；调用处理后的所述业务代码和所述配置文件，执行接口测试后通过识别所述业务框架中的数据后生成测试结果并将其写入数据库；从所述数据库中获取测试结果并判断所述定时任务的执行是否成功。所述存储介质可以为非易失性存储介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，readonlymemory)、随机存取存储器(ram，randomaccessmemory)、磁盘或光盘等。

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

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