一种应用系统迁移性的测试方法及装置与流程

文档序号:12363430阅读:321来源:国知局
一种应用系统迁移性的测试方法及装置与流程

本申请涉及计算机技术领域,尤其涉及一种应用程序的测试方法及装置。



背景技术:

随着互联网的发展,互联网业务的种类和数量均快速增加承载互联网业务的软硬件资源的淘汰周期缩短,经常出现互联网业务的应用系统需要根据情况进行迁移。比如,经过一定时期的使用,当前某个应用系统的处理能力不足以应付增长后的业务数量,或不再适应增多后的业务种类,这种情况下,则需要对承载互联网业务的应用系统进行迁移(常见的迁移方式包括:更新应用程序或更换服务器设备等),以便满足互联网业务的发展变化需求。

在进行应用系统迁移时,迁移后的应用系统能否达到期望的效果,是迁移工作中关注的重要方面。为了确保应用系统迁移后达到期望的效果,通常需要对应用系统的迁移性进行测试。可以将迁移前的应用系统称为原始应用系统,将迁移后的应用系统称为目标应用系统。一种较为简单的应用系统迁移性测试的方式是直接将目标应用系统替换原始应用系统,利用目标应用系统对业务请求进行处理,实现对应用系统迁移性的测试。但这种方式的问题在于是不可取的,如果目标应用系统出现问题,有可能为用户带来不便。所以,可以将原始应用系统处理过的业务请求利用目标应用系统进行处理,实现对应用系统迁移性的测试。

现有技术,在对应用系统迁移性测试过程中,将原始应用系统处理过的全部业务请求利用目标应用系统处理,但是由于原始应用系统的服务器设备(用于承载互联网业务)一般不止一台(比如1000台),在测试应用系统迁移性时一般没有对应数量的服务器设备为测试使用(比如仅有20台)。在这种情况下, 就需要让这20台服务器设备处理1000台服务器设备的业务请求,如果全部处理,则会出现耗时过长的情况,导致迁移性测试的效率较低;如果仅随意选取一部分进行处理,则可能会出现漏掉一些业务种类,降低了业务覆盖面,从而影响到迁移性测试的准确性。



技术实现要素:

本申请实施例提供一种应用系统迁移性的测试方法,用于提高应用系统迁移性的测试效率。

本申请实施例提供一种应用系统迁移性的测试装置,用于提高应用系统迁移性的测试效率。

本申请实施例采用下述技术方案:

一种应用系统迁移性的测试方法,包括:获取原始应用系统处理过的业务请求;对所述业务请求进行聚类,形成至少两个聚类集合,所述聚类集合内的业务请求具有相似的性质;从各个聚类集合中分别选取一定数量的业务请求,从每个聚类集合中选取的业务请求的数量少于该每个聚类集合包含的业务请求的总个数;利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。

一种应用系统迁移性的测试装置,包括:获取单元,用于获取原始应用系统处理过的业务请求;聚类单元,用于对所述业务请求进行聚类,形成至少两个聚类集合,所述聚类集合内的业务请求具有相似的性质;选取单元,用于从各个聚类集合中分别选取一定数量的业务请求,从每个聚类集合中选取的业务请求的数量少于该每个聚类集合包含的业务请求的总个数;测试单元,用于利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:

在应用系统迁移性的测试过程中,在获取原始应用系统处理过的业务请求后,先对业务请求进行聚类,形成至少两个具有相似性质的聚类集合,再从每 个聚类集合中选取少于该每个聚类集合包含的业务请求的总个数,最后利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。如何选取业务请求是提高测试效率的关键,在本申请中,利用聚类选取出的业务请求,即满足了尽量宽广的覆盖面要求,又满足了减少测试数量的需求。一方面,避免了将全部业务请求都做处理,而只处理一部分业务请求,带来的测试效率的提升;另一方面,能够尽量多地覆盖不同性质的业务请求,提高了应用系统迁移性测试的准确性。

附图说明

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

图1为本申请实施例1提供的一种应用系统迁移性的测试方法的具体实现流程示意图;

图2为本申请实施例2提供的一种应用系统迁移性的测试装置的具体结构示意图;

图3为本申请实施例3提供的一种应用程序迁移性的测试流程示意图。

具体实施方式

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

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

实施例1

如前所述,互联网业务的应用系统需要根据不同的需求进行迁移,比如,对应用系统中的应用程序或硬件设备进行升级维护等,都需要将原始应用系统提供的功能迁移到目标应用系统上。在进行应用系统迁移时,目标应用系统能否达到期望的效果,是迁移工作中关注的重要方面。在实际应用中,一般由多台硬件设备承载互联网业务,比如,有1000台服务器设备处理线上用户的业务请求,如果需要对这1000台服务器设备中的一种应用程序进行升级。可以分批次对部分服务器中的一种应用程序进行升级,来实现对应用系统迁移性的测试,但是,如果目标应用系统无法达到期望的效果,就有可能为线上用户带来不便(比如,处理业务请求中出现错误等)。所以,可以将目标应用系统在线下对原始应用系统处理过的业务请求进行重新处理,通过对比目标应用系统与原始应用系统对相同业务请求的处理结果,实现对应用系统迁移性的测试。假如有1000台服务器设备处理线上用户的业务请求,以一天(24小时)为例,这1000台服务器设备会处理2亿条业务请求,这2亿条业务请求包括不同的业务种类(业务来源不同、业务类型不同等),然而,用于在线下测试应用系统迁移性的服务器设备,不论从成本考虑,还是从资源利用率考虑,都不可能有同样数量,如果仅用10台服务器设备处理这2亿条业务请求,往往会消耗多余24小时的时间,这就导致了迁移性测试的效率较低;如果从2亿条业务请求中选取一部分进行处理,虽然时间上可以不超过24小时,但是可能会出现漏掉一些业务种类,降低了业务覆盖面,从而影响到迁移性测试的准确性。为了在确保迁移性测试的准确性的前提下,提高迁移性测试的效率,本实施例提供了一种应用系统迁移性的测试方法。该方法的具体流程示意图如图1所示,包括下述步骤:

步骤11,获取原始应用系统处理过的业务请求。

针对步骤11而言,原始应用系统处理过的业务请求,以及处理结果,往往会保存在业务日志中,通过获取业务日志,就可以获取到原始应用系统处理过的业务请求。比如,会有线上日志,用于保存线上业务请求以及对线上业务 的处理结果,可以通过不同的接口,来获取用于保存不同种类的线上业务的日志。

步骤12,对业务请求进行聚类,形成至少两个聚类集合,聚类集合内的业务请求具有相似的性质。

聚类,是指将物理或抽象对象的集合分成由类似的对象组成的多个集合的过程。由聚类所生成的聚类集合是一组对象的集合,这些对象与同一聚类集合中的对象彼此相似,与其他聚类集合中的对象相异。

由此可知,聚类的过程,实际就是将具有相似性质的对象形成一个聚类集合。在本实施例中,聚类的过程,是指将具有相似的性质的业务请求形成一个聚类集合。

对于业务请求而言,其中包含的与聚类相关的业务特征,才能够作为聚类的依据,所以,可以在获取原始应用系统处理过的业务请求后,先过滤掉业务请求中包含的噪音数据(即与聚类无关的业务特征),比如,业务请求中用户添加的备注信息,业务请求的时间信息,备注信息由于是用户自己添加的,时间信息是系统根据接收业务请求的当前时刻生成的,对于聚类结果没有影响,所以过滤掉噪音数据,不仅可以在聚类过程中节省计算资源,更重要的是不对聚类的准确性有干扰。

针对步骤12而言,可以有下述子步骤:

子步骤121,对业务请求中包含的与聚类相关的业务特征进行特征提取。

业务请求中包含的业务特征,存在一些唯一标识,比如,业务流水号(一定是唯一的)、用户标识(每个用户有唯一的标识)。这些唯一标识也是具有相似性质的(如虽然业务流水号不同,但属于相同业务种类),但是如果利用唯一标识进行聚类,势必会影响聚类的结果(相同业务,如果时间上相差多,业务流水号也会相差很多),所以,需要对与聚类相关的业务特征进行特征提取。

对业务请求中包含的与聚类相关的业务特征进行特征提取,可以包括下述至少一种:

对业务请求中包含的与聚类相关的作业特征提取字符串位数;

对业务请求中包含的与聚类相关的类型特征提取全部字符;

对业务请求中包含的与聚类相关的数值特征提取正负性。

具体地,

作业特征可以包括:业务流水号、用户标识等,一般地,业务流水号是根据业务种类、接收业务请求的当前时刻等等,由应用系统生成的字符串,该字符串是唯一的,所以,以业务流水号的字符串本身作为聚类的依据显然会影响聚类结果;同样的,每个用户对应的用户标识也是唯一的,以用户标识的字符串本身作为聚类的依据显然也会影响聚类结果。所以,对于作业特征,可以提取字符串的位数,作为聚类的依据。

类型特征可以包括:业务状态、业务类型、业务来源等,一般地,业务类型、业务来源等,都是预设的、固定不变的代号,业务状态是应用系统根据完成情况生成的标记。比如:支付业务010001、转账业务010002;PC端业务pc、移动终端业务mobile;初始化I、成功S、失败F等。这些字符串都可以作为聚类的依据。所以,对于作业特征,可以提取全部字符。

数值特征可以包括:业务请求中的数量,一般地,业务请求中的数量是根据业务请求中的数量生成的,比如10(充值10个游戏币)、-2(消耗2个)等。这些字符串本身作为聚类的依据是没有意义的,但是所表示的正负性是有意义的,所以,对于数值特征,可以提取正负性。比如0、1、2分别表示0、负数、正数。

子步骤122,确定指定数量的聚类中心。

在对业务请求聚类开始之前,可以先确定出至少两个聚类中心,以便将业务请求进行聚类,形成至少两个聚类集合。

确定指定数量的聚类中心,可以包括:

根据业务请求中包含的与聚类相关的业务特征,确定指定数量聚类中心;或

根据目标应用系统在单位时间内的处理能力,确定指定数量聚类中心。

具体地,

聚类的意义在于对具有相似的性质的业务请求进行聚类,形成聚类集合,而业务请求中包含的与聚类相关的业务特征恰恰是区别是否具有相似的性质的依据,所以可以根据这些业务特征,来确定出指定数量的聚类中心。比如,可以根据作业特征中的业务流水号、用户标识,类型特征中的业务状态、业务类型、业务来源,数值特征的正负性,进行组合,确定出指定数量的聚类中心。

在测试应用系统迁移性的过程中,会有一个测试的期限(1天、1周),为了在有限的时间内,涵盖尽量宽广的业务覆盖面,可以按照下述公式计算出目标应用系统在单位时间内的处理能力:

K=n/t×T;其中,n表示目标应用系统处理完成的n个业务请求,t表示目标应用系统处理完成n个业务请求的耗时,T代表测试的期限;K表示目标应用系统在T时间段内的最大处理数量。

比如,1台服务器设备1秒钟,处理了1000条业务请求,那么该服务器设备在24小时内的最大处理数量为:1000/1×24×60×60=8640000(条)

子步骤123,根据特征提取结果与聚类中心的距离,对业务请求进行聚类。

执行子步骤121后得到了特征提取结果,执行子步骤122后确定出了执行数量的聚类中心,就可以根据特征提取结果与聚类中心的距离,对业务请求进行聚类了。

根据特征提取结果与聚类中心的距离,对业务请求进行聚类,可以包括:

利用汉明距离计算提取出的全部字符与聚类中心的距离;

利用标准欧氏距离计算提取出的字符串位数以及正负性与聚类中心的距离;

根据计算出的与聚类中心的距离,对所述业务请求进行聚类。

具体地,汉明距离是指将一个字符串变换成另外一个字符串所需要替换的字符个数。例如:

010001与010002之间的汉明距离是1;

4007与3008之间的汉明距离是2。

在子步骤121中已经介绍,类型特征中的业务类型、业务来源等,都是预设的、固定不变的代号,业务状态是应用系统根据完成情况生成的标记。比如:支付业务010001、转账业务010002;PC端业务pc、移动终端业务mobile;初始化I、成功S、失败F等。这些类型特征都是固定不变的,所以可以通过汉明距离计算提取出的全部字符与聚类中心的距离。

利用汉明距离计算提取出的全部字符与聚类中心的距离可以按照如下公式算计:

M1=(x1x2x3…xn),M2=(y1y2y3…yn),定义相似度计算公式:

<mrow> <mi>sim</mi> <mrow> <mo>(</mo> <msub> <mi>M</mi> <mn>1</mn> </msub> <mo>,</mo> <msub> <mi>M</mi> <mn>2</mn> </msub> <mo>)</mo> </mrow> <mo>=</mo> <mn>1</mn> <mo>-</mo> <mrow> <mo>(</mo> <munderover> <mi>&Sigma;</mi> <mrow> <mi>k</mi> <mo>=</mo> <mn>1</mn> </mrow> <mi>n</mi> </munderover> <msub> <mi>x</mi> <mi>k</mi> </msub> <mo>&CirclePlus;</mo> <msub> <mi>y</mi> <mi>k</mi> </msub> <mo>)</mo> </mrow> <mo>/</mo> <mi>n</mi> </mrow>

其中xk,yk分别表示M1和M2中第k个分量,要么为1要么为0,为模二加运算,M1与M2其中之一是确定出的聚类中心的特征。

比如,可以确定聚类中心的业务类型为支付业务010001,某一业务请求的业务类型是转账业务010002,则n=6;x1=x3=x4=x5=0,x2=x6=1;y1=y3=y4=y5=0,y2=1,y6=2,sim=1-1/6=0.83。

在子步骤121中同样已经介绍,作业特征中的业务流水号、用户标识,提取字符串的位数。数值特征中的业务请求中的数量,提取正负性。由于提取结果都能够代表业务请求的性质,所以可以通过标准欧式距离计算提取出的字符串位数以及正负性与聚类中心的距离。

两个n维向量1(x11,x12…x1n)与2(x21,x22…x2n)间的标准化欧氏距离的公式:

<mrow> <msub> <mi>d</mi> <mn>12</mn> </msub> <mo>=</mo> <msqrt> <munderover> <mi>&Sigma;</mi> <mrow> <mi>k</mi> <mo>=</mo> <mn>1</mn> </mrow> <mi>n</mi> </munderover> <msup> <mrow> <mo>(</mo> <mfrac> <mrow> <msub> <mi>x</mi> <mrow> <mn>1</mn> <mi>k</mi> </mrow> </msub> <mo>-</mo> <msub> <mi>x</mi> <mrow> <mn>2</mn> <mi>k</mi> </mrow> </msub> </mrow> <msub> <mi>S</mi> <mi>k</mi> </msub> </mfrac> <mo>)</mo> </mrow> <mn>2</mn> </msup> </msqrt> </mrow>

其中,Sk为分量k的标准差,比如k=1,S1为x11与x21的标准差。

最后,根据计算出的与聚类中心的距离,对业务请求进行聚类。

具体地,可以根据计算出的与聚类中心的距离,以及预设的距离阈值,对业务请求进行聚类。

步骤12根据业务请求中包含的与聚类相关的业务特征,对业务请求进行聚类,使具有相似性质的业务请求形成一个聚类集合。在实际应用中,可以将不同的业务场景形成若干个聚类集合。

步骤13,从各个聚类集合中分别选取一定数量的业务请求,从每个聚类集合中选取的业务请求的数量少于该每个聚类集合包含的业务请求的总个数。

各个聚类集合都具有不同的性质,步骤13对于业务请求的选取方式的意义在于,一方面,选取的结果覆盖了各种不同的性质,解决了出现随意选一部分后导致的漏掉一些性质的业务请求。另一方面,在满足覆盖各种不同的性质的要求前提下,选取出的数量变少,解决了全部选取出现的数量庞大的问题;所以通过执行步骤13选取出的业务请求,既可以满足覆盖各种不同的性质的要求,有可以满足较少业务请求数量的需求。

步骤14,利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。

目标应用系统对选取的业务请求进行处理后,得到的处理结果,可以与原始系统对选取的业务请求进行处理后,得到的处理结果进行对比,来实现对应用系统迁移性的测试。测试的目的,不仅可以获知目标应用系统是否满足迁移后的需求;也可以测试出目标系统的问题。比如,目标应用系统存在一定的缺陷,就可以利用本实施例提供的方法,测试出缺陷的具体位置;目标应用系统中的应用程序有了升级,就可以利用本实施例提供的方法,测试出升级后的应用程序是否满足对于升级的期望。

采用实施例1提供的该方法,在应用系统迁移性的测试过程中,在获取原始应用系统处理过的业务请求后,先对业务请求进行聚类,形成至少两个具有 相似性质的聚类集合,再从每个聚类集合中选取少于该每个聚类集合包含的业务请求的总个数,最后利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。如何选取业务请求是提高测试效率的关键,在本申请中,利用聚类选取出的业务请求,即满足了尽量宽广的覆盖面要求,又满足了减少测试数量的需求。一方面,避免了将全部业务请求都做处理,而只处理一部分业务请求,带来的测试效率的提升;另一方面,能够尽量多地覆盖不同性质的业务请求,提高了应用系统迁移性测试的准确性。

需要说明的是,实施例1所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法的各步骤也可以由不同设备作为执行主体。比如,步骤11和步骤12的执行主体可以为设备1,步骤12和步骤13的执行主体可以为设备2;又比如,步骤11的执行主体可以为设备1,步骤12至步骤14的执行主体可以为设备2;等等。

实施例2

基于相同的发明构思,实施例2提供了一种应用系统迁移性的测试装置,用于。如图2所示,该装置包括:

获取单元21,可以用于获取原始应用系统处理过的业务请求;

聚类单元22,可以用于对所述业务请求进行聚类,形成至少两个聚类集合,所述聚类集合内的业务请求具有相似的性质;

选取单元23,可以用于从各个聚类集合中分别选取一定数量的业务请求,从每个聚类集合中选取的业务请求的数量少于该每个聚类集合包含的业务请求的总个数;

测试单元34,可以用于利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。

在一种实施方式中,聚类单元22,可以用于:

对所述业务请求中包含的与聚类相关的业务特征进行特征提取;

确定指定数量的聚类中心;

根据特征提取结果与聚类中心的距离,对所述业务请求进行聚类。

在一种实施方式中,,聚类单元22,可以用于执行下述至少一种操作:

对所述业务请求中包含的与聚类相关的作业特征提取字符串位数;

对所述业务请求中包含的与聚类相关的类型特征提取全部字符;

对所述业务请求中包含的与聚类相关的数值特征提取正负性。

在一种实施方式中,聚类单元22,可以用于:

利用汉明距离比较算法计算提取出的全部字符与聚类中心的距离;

利用标准欧氏距离比较算法计算提取出的字符串位数以及正负性与聚类中心的距离;

根据计算出的与聚类中心的距离,对所述业务请求进行聚类。

在一种实施方式中,聚类单元22,可以用于:

根据所述业务请求中包含的与聚类相关的业务特征,确定指定数量聚类中心;或

根据目标应用系统在单位时间内的处理能力,确定指定数量聚类中心。

采用实施例2提供的该装置,在应用系统迁移性的测试过程中,在获取原始应用系统处理过的业务请求后,先对业务请求进行聚类,形成至少两个具有相似性质的聚类集合,再从每个聚类集合中选取少于该每个聚类集合包含的业务请求的总个数,最后利用目标应用系统对选取的业务请求进行处理,实现对应用系统迁移性的测试。如何选取业务请求是提高测试效率的关键,在本申请中,利用聚类选取出的业务请求,即满足了尽量宽广的覆盖面要求,又满足了减少测试数量的需求。一方面,避免了将全部业务请求都做处理,而只处理一部分业务请求,带来的测试效率的提升;另一方面,能够尽量多地覆盖不同性质的业务请求,提高了应用系统迁移性测试的准确性。

实施例3

基于相同的发明构思,实施例3提供了一种应用程序迁移性的测试方法,用于提高应用程序迁移性的测试效率。该方法的示意图如图3所示,包括下述步骤:

步骤31,获取原始应用系统处理过的N个业务请求。

步骤32,删除N个业务请求中包含的与聚类无关的特征信息。

步骤33,对N个业务请求中包含的与聚类相关的特征信息做特征提取。

步骤34,根据N个业务请求中包含的与聚类相关的业务特征,确定指定数量聚类中心。

步骤35,利用汉明距离以及标准欧氏距离,计算特征提取结果与聚类中心的距离。

步骤36,根据计算出的与聚类中心的距离,对N个业务请求进行聚类,形成M个聚类集合。

步骤37,从M个聚类集合的每个聚类集合中,分别选取1个业务请求,总计选取M个业务请求,M<N。

步骤38,利用目标应用系统对M个业务请求进行处理后得到处理结果,与原始系统对M个业务请求进行处理后得到处理结果,进行对比,实现对应用系统迁移性的测试。

采用实施例3提供的该方法,在应用系统迁移性的测试过程中,在获取原始应用系统处理过的N个业务请求后,先对N个业务请求进行聚类,形成M个具有相似性质的聚类集合,再从每个聚类集合中,选取1个聚类集合,总计M个业务请求。最后利用目标应用系统对M个业务请求进行处理,实现对应用系统迁移性的测试。如何选取业务请求是提高测试效率的关键,在本实施例中,从每个聚类集合中选取1个业务请求,即满足了尽量宽广的覆盖面要求,又满足了减少测试数量的需求。一方面,避免了将全部业务请求都做处理,而 只处理一部分业务请求,带来的测试效率的提升;另一方面,能够尽量多地覆盖不同性质的业务请求,提高了应用系统迁移性测试的准确性。。

本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

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

本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1