本发明涉及计算机软件领域，具体而言，涉及一种代码覆盖率测试结果的处理方法及装置。
背景技术：
：相关技术中，在测试中的代码覆盖率是指在运行测试用例过后，已经覆盖的代码行数，然后再采用已经覆盖的代码行数除以测试对象总体包含的代码行数即为本次测试的代码覆盖率。假设测试对象是一个函数，而这个函数总共拥有100行代码，当所有的测试用例执行完毕后，已经覆盖了60行代码，而还有40行的代码没有被覆盖到,那么这个函数的代码覆盖率便是60％。需要说明的是，上述示例中提到的代码行仅为一种较为常用的度量方式。下面将对常用的几种用于表示代码覆盖程度的度量方式进行介绍：1)语句覆盖(StatementCoverage)又被称为行覆盖(LineCoverage)，段覆盖(SegmentCoverage)，基本块覆盖(BasicBlockCoverage)，此为最常用也是最常见的一种覆盖方式，其度量被测代码中每个可执行语句是否被执行到了。这里指的是“可执行语句”，因此，便不会包括如C++语言的头文件声明、代码注释、空行等。此种覆盖方式仅统计能够执行的代码已经被执行了多少行。需要注意的是，单独一行的花括号{}也常常被统计进去。语句覆盖通常被认定为“最弱的覆盖”，其仅负责覆盖代码中的执行语句，却无需考虑各种分支的组合。这种语句覆盖方式的缺陷在于：耗费时间和精力，但是，所得到的测试效果的不明显，难以发现代码测试中存在的问题。2)判定覆盖(DecisionCoverage)又被称为分支覆盖(BranchCoverage)，所有边界覆盖(All-EdgesCoverage)，其用于度量程序中每一个判定的分支是否都被测试完成。3)条件覆盖(ConditionCoverage)用于度量判定中的每个子表达式结果true和false是否被测试完成。例如：语句ifa>0orb>0，这是一个组合条件，如果条件成立，则既有可能满足a>0，也有可能满足b>0，这两者被称为整个条件语句的子条件。在某些情况下，测试人员需要明确知道软件执行代码究竟是因为哪个子条件满足而完成测试。需要说明的是，“条件覆盖”与“判定覆盖”相比，执行力度更强，其原因在于：条件覆盖需要使得每个判定过程中的每个判定条件均得到了两个不同的判定结果；相反地，判定覆盖则更关心整个条件是否成立，而无法确保每个判定条件均得到了两个不同的判定结果。4)路径覆盖(PathCoverage)又被称为断言覆盖(PredicateCoverage)，其用于度量是否函数的每一个分支都被执行完成，即所有可能的分支都被执行一遍。然而，当执行语句中有多个分支嵌套时，需要对多个分支进行排列组合，易造成测试路径随着分支的数量指数级别增加。在执行代码测试中的单元测试时，代码覆盖率通常被作为衡量代码测试成功率的重要指标，甚至，采用代码覆盖率来考核测试任务的完成情况，例如：代码覆盖率需要达到80％或90％。目前，针对代码覆盖率的测试工具主要包括但不限于：python语音中配置的coverage库，java中配置的相对应的库，lpc语言，这些测试工具均支持对代码覆盖率的检测。然而，现有的代码覆盖率测试工具仅能够描述对特定静态文件的覆盖情况，其测试前提在于：在测试一个或多个代码文件的覆盖情况时，这些代码文件是不能发生更改的。但是，在代码开发的过程中，研发人员经常会对一个代码文件进行反复修改，以达到功能迭代、修正bug等目的。并且，研发项目的复杂度越高，其对应代码文件的修改的次数也会随之增多。在任何研发阶段开始进行的代码覆盖率测试，都无法确保当前测试的代码文件为最终版本，后续不会再对此代码文件进行修改。除此之外，基于协同工作方面的考虑，针对同一份代码文件可能会有多个人在进行修改，等到特定研发阶段再对各自修改的部分进行合并。一旦合并这些修改部分也即意味着代码文件发生变化。另外，如果在执行代码覆盖率测试的过程中，测试程序发生异常退出或者其运行的测试环境发生硬件故障，则意味着已经得到的代码测试的覆盖情况可能丢失，由此将会导致复杂度较高的开发项目所进行的一周，甚至数周之久的代码测试工作付之东流。针对上述的问题，目前尚未提出有效的解决方案。技术实现要素：本发明实施例提供了一种代码覆盖率测试结果的处理方法及装置，以至少解决相关技术中所提供的代码覆盖率测试方式仅能够描述对特定静态代码文件的覆盖情况，而无法满足动态更新的代码文件的测试需求的技术问题。根据本发明实施例的一个方面，提供了一种代码覆盖率测试结果的处理方法，包括：获取与当前执行的代码覆盖率测试任务对应的代码覆盖率测试结果；将代码覆盖率测试结果导出至预设存储区域，其中，预设存储区域用于对代码覆盖率测试结果进行持久化存储。可选地，获取代码覆盖率测试结果包括：从终端的内存中读取代码覆盖率测试结果，其中，终端用于执行代码覆盖率测试操作。可选地，将代码覆盖率测试结果导出至预设存储区域包括：确定待使用的数据导出格式，其中，数据导出格式至少包括：代码覆盖率测试任务对应的svn版本号、代码覆盖率测试任务的任务编号、代码覆盖率测试任务对应的原始代码文件的校验码、原始代码文件的代码行数、代码覆盖率测试结果的压缩编码方式；根据数据导出格式和代码覆盖率测试结果生成预设类型存储文件；将预设类型存储文件导出至预设存储区域。可选地，在将代码覆盖率测试结果导出至预设存储区域之后，还包括：确定终端完成重新启动；判断代码覆盖率测试任务是否已经完成测试；如果否，则从预设存储区域内获取预设类型存储文件；从预设类型存储文件中还原出代码覆盖率测试结果，并将代码覆盖率测试结果导入至内存。可选地，在将代码覆盖率测试结果导出至预设存储区域之后，还包括：确定当前存在对代码覆盖率测试任务对应的原始代码文件执行的更新操作；根据原始代码文件与已更新代码文件之间的差异部分代码生成与已更新代码文件对应的更新后的代码覆盖率测试结果。可选地，根据差异部分代码生成更新后的代码覆盖率测试结果包括：获取原始代码文件、已更新代码文件以及代码覆盖率测试结果；将原始代码文件与已更新代码文件进行比对，确定差异部分代码；根据差异部分代码在原始代码文件的代码行与已更新代码文件的代码行之间建立对应关系；通过对应关系生成更新后的代码覆盖率测试结果。根据本发明实施例的另一方面，还提供了一种代码覆盖率测试结果的处理装置，包括：第一获取模块，用于获取与当前执行的代码覆盖率测试任务对应的代码覆盖率测试结果；处理模块，用于将代码覆盖率测试结果导出至预设存储区域，其中，预设存储区域用于对代码覆盖率测试结果进行持久化存储。可选地，第一获取模块，用于从终端的内存中读取代码覆盖率测试结果，其中，终端用于执行代码覆盖率测试操作。可选地，处理模块包括：第一确定单元，用于确定待使用的数据导出格式，其中，数据导出格式至少包括：代码覆盖率测试任务对应的svn版本号、代码覆盖率测试任务的任务编号、代码覆盖率测试任务对应的原始代码文件的校验码、原始代码文件的代码行数、代码覆盖率测试结果的压缩编码方式；第一生成单元，用于根据数据导出格式和代码覆盖率测试结果生成预设类型存储文件；处理单元，用于将预设类型存储文件导出至预设存储区域。可选地，上述装置还包括：第一确定模块，用于确定终端完成重新启动；判断模块，用于判断代码覆盖率测试任务是否已经完成测试；第二获取模块，用于在判断模块输出为否时，从预设存储区域内获取预设类型存储文件；还原模块，用于从预设类型存储文件中还原出代码覆盖率测试结果，并将代码覆盖率测试结果导入至内存。可选地，上述装置还包括：第二确定模块，用于确定当前存在对代码覆盖率测试任务对应的原始代码文件执行的更新操作；生成模块，用于根据原始代码文件与已更新代码文件之间的差异部分代码生成与已更新代码文件对应的更新后的代码覆盖率测试结果。可选地，生成模块包括：获取单元，用于获取原始代码文件、已更新代码文件以及代码覆盖率测试结果；第二确定单元，用于将原始代码文件与已更新代码文件进行比对，确定差异部分代码；建立单元，用于根据差异部分代码在原始代码文件的代码行与已更新代码文件的代码行之间建立对应关系；第二生成单元，用于通过对应关系生成更新后的代码覆盖率测试结果。在本发明实施例中，采用获取与当前执行的代码覆盖率测试任务对应的代码覆盖率测试结果，并将代码覆盖率测试结果导出至预设存储区域的方式，通过预设存储区域对代码覆盖率测试结果进行持久化存储，达到了针对在执行代码覆盖率测试的过程中，测试程序发生异常退出或者其运行的测试环境发生硬件故障的情况，代码覆盖率测试测试的中间结果可以实时存储至预设存储区域，以便在测试程序或者其运行的测试环境被修复后，通过对运行测试的终端进行重启可以恢复先前已经得到的代码覆盖率测试结果的目的，从而实现了继续完成代码覆盖率测试。极大地增加了代码覆盖率测试工作的抗风险性的技术效果，进而解决了相关技术中所提供的代码覆盖率测试方式仅能够描述对特定静态代码文件的覆盖情况，而无法满足动态更新的代码文件的测试需求的技术问题。附图说明此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：图1是根据本发明实施例的代码覆盖率测试结果的处理方法的流程图；图2是根据本发明实施例的代码覆盖率测试结果的处理装置的流程图；图3是根据本发明优选实施例的代码覆盖率测试结果的处理装置的流程图。具体实施方式为了使本
技术领域：
的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。根据本发明实施例，提供了一种代码覆盖率测试结果的处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。图1是根据本发明实施例的代码覆盖率测试结果的处理方法的流程图，如图1所示，该方法可以包括如下步骤：步骤S12，获取与当前执行的代码覆盖率测试任务对应的代码覆盖率测试结果；步骤S14，将代码覆盖率测试结果导出至预设存储区域，其中，预设存储区域用于对代码覆盖率测试结果进行持久化存储。采用上述步骤，可以实现通过预设存储区域对代码覆盖率测试结果进行持久化存储，达到了针对在执行代码覆盖率测试的过程中，测试程序发生异常退出或者其运行的测试环境发生硬件故障的情况，代码覆盖率测试测试的中间结果可以实时存储至预设存储区域，以便在测试程序或者其运行的测试环境被修复后，通过对运行测试的终端进行重启可以恢复先前已经得到的代码覆盖率测试结果的目的，从而实现了继续完成代码覆盖率测试。极大地增加了代码覆盖率测试工作的抗风险性的技术效果，进而解决了相关技术中所提供的代码覆盖率测试方式仅能够描述对特定静态代码文件的覆盖情况，而无法满足动态更新的代码文件的测试需求的技术问题。可选地，在步骤S12中，获取代码覆盖率测试结果可以进一步包括以下执行步骤：步骤S121，从终端的内存中读取代码覆盖率测试结果，其中，终端用于执行代码覆盖率测试操作。为了应对测试程序发生异常退出或者其运行的测试环境发生硬件故障等突发状况，应当尽量确保代码覆盖率测试结果持久化。即，可以对代码覆盖率测试过程中已经得到的代码覆盖率测试结果进行导出存盘，并且在需要恢复覆盖率测试结果时，还可以重新加载代码覆盖率测试结果。具体地，可以通过提供应用程序编程接口(API)读取内存中记录的特定代码文件的代码覆盖率测试结果。可选地，在步骤S14中，将代码覆盖率测试结果导出至预设存储区域可以包括以下执行步骤：步骤S141，确定待使用的数据导出格式，其中，数据导出格式至少包括：代码覆盖率测试任务对应的svn版本号、代码覆盖率测试任务的任务编号、代码覆盖率测试任务对应的原始代码文件的校验码、原始代码文件的代码行数、代码覆盖率测试结果的压缩编码方式；步骤S142，根据数据导出格式和代码覆盖率测试结果生成预设类型存储文件；步骤S143，将预设类型存储文件导出至预设存储区域。在优选实施例中，可以通过提供API对内存中记录的特定代码文件的代码覆盖率测试结果进行序列化导出，其中，序列化的数据格式可以根据特定需求预先配置完成。序列化导出的含义是指将内存中存储的数据按照预设格式存储至预设存储区域(例如：本地的物理硬盘或互联网的安全网盘)。考虑到内存中的数据存储是临时的，程序结束运行后就不复存在了。而物理硬盘或安全网盘上的数据存储是持久的。因此，指定上述格式的过程即为“序列化”。具体地，序列化的数据格式示例如下：##Desc/*Desc部分包含了该代码文件的基本信息*/svn_ver391430/*svn_ver表示覆盖率任务的对应的svn版本号*/cover_ver808/*cover_ver表示本次代码覆盖率测试任务的编号*/md5de2970093ec13afb43ebe38a3e27534e/*md5是该代码文件的校验码，用来验证文件是否相同*/total_linecnt2534/*total_linecnt表示该代码文件的总行数*/##Bitmap/*Bitmap部分表示已经存储的与代码文件对应的代码覆盖率测试结果，其为本申请最关键的部分*/00020000000000000000000000000000E514001A10000000000000000000E100000000000000000000000000000000000000000000000000000000000000000000008100000C00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002A60CA05408E10000000000000000000000000000000000000000000000000000000000000C00000000000000000000000000000000000008E0000000000000000000000000000000000000000000000080280000000000000000000000000000000000000000000000000000000000000000000000000000上述字符串存储了该示例中对应于2534行的代码覆盖率测试结果，即每一行代码是否已经被覆盖。为了节省存储空间，该示例中并没有采用一个字符对应一行代码的覆盖结果，而是采用了压缩编码的方式，压缩后的结果大概是每行有64个字符，每个字符实际上可以对应存储四行代码的代码覆盖率测试结果(相当于压缩率为25％)。在处理器通过对上述字符串进行解压缩运算后便可还原出内存中存储的数据格式。上述示例最终可以输出成预设类型存储文件(例如：.cov文件)。在执行代码覆盖率测试的过程中，需要定时将代码覆盖率测试结果导出至上述预设存储区域，以及因测试过程结束导致测试程序退出时，也需要将代码覆盖率测试结果导出至上述预设存储区域。需要说明的是，为了能够避免在设定的相邻两次导出时间之间，因测试程序发生异常退出或者其运行的测试环境发生硬件故障等突发状况造成这两次导出时间之间得到的代码覆盖率测试数据发生丢失，因此，可以采用以下两种改进方式来降低测试数据发生丢失的可能性：方式一、为降低异常故障所导致的测试数据丢失，可以将相邻两次定时存盘的时间间隔缩短，提升定时存盘的存储频率。方式二、提供主动存盘的功能接口。例如：测试人员在测试完重要流程后，可以主动点击“存盘”接口，其相当于在编写word文档的过程中，由操作人员主动触发的存储(ctrl+s)功能。可选地，在步骤S14，将代码覆盖率测试结果导出至预设存储区域之后，还可以包括以下执行步骤：步骤S15，确定终端完成重新启动；判断代码覆盖率测试任务是否已经完成测试；步骤S16，如果否，则从预设存储区域内获取预设类型存储文件；步骤S17，从预设类型存储文件中还原出代码覆盖率测试结果，并将代码覆盖率测试结果导入至内存。在优选实施例中，通过API可以将上述.cov文件存储的代码覆盖率测试结果还原至内存中，作为当前最新的代码覆盖率测试结果。在运行测试程序的终端重新启动时，如果检测到尚未完成的代码覆盖率测试任务，则在对代码文件进行校验后，从预设存储区域自动恢复与该代码文件对应的代码覆盖率测试结果。可选地，在步骤S14，将代码覆盖率测试结果导出至预设存储区域之后，还可以包括以下执行步骤：步骤S18，确定当前存在对代码覆盖率测试任务对应的原始代码文件执行的更新操作；步骤S19，根据原始代码文件与已更新代码文件之间的差异部分代码生成与已更新代码文件对应的更新后的代码覆盖率测试结果。当一个代码文件发生更新的时候，需要将原代码文件对应的代码覆盖率测试结果映射到更新后的代码文件上。上述代码文件更新可以包括但不限于以下至少之一：(1)热更新，是指在应用程序运行的过程中，不依赖关闭、重启该应用程序而达到修改程序功能的目的，其在软件开发的过程中经常被使用到。(2)svn分支切换，是指在团队协同工作模式下，同一份代码文件可能需要被若干研发人员或测试人员所修改，换言之，当一名测试人员正在对代码文件执行代码覆盖率测试的过程中，其他研发人员或测试人员也在对该代码文件进行修改，并且必须要根据这些修改对代码文件进行更新，否则将阻碍尚未执行的代码覆盖率测试任务。此时，便需要切换svn分支，更新至包含其他研发人员或测试人员的最新修改记录的分支。这实际上是会改变代码文件内容的。上述两种代码文件更新方式由于已经改变了当前正在测试的代码文件的文件结构(主要体现在代码文件的行号发生变化)，因此，会使得之前测试记录的代码覆盖率测试结果发生紊乱。完成映射的过程可以包括：对于每个正在测试的代码文件，均需要存储一份与该代码文件对应的副本。当代码文件发生更新后，通过调用映射指令，将原代码文件上记录的源代码与新后的代码文件上记录的源代码进行比对，输出两份代码文件的差异部分(例如：可以使用unix系统下的diff程序来辅助分析以获取该差异部分)。根据diff程序的辅助分析结果与当前存储的代码覆盖率测试结果进行映射调整。由于diff程序和代码覆盖率测试结果都是基于行来实现的，因此，这个映射过程具备可实施性，由此来确保先前得到的代码覆盖率测试结果不会因代码文件发生更新而丢失。考虑到测试人员在执行代码覆盖率测试过程中，无法及时获知当前测试的代码文件是否发生变化，因此，只要能够确定在测试过程中执行过热更新指令或者是svn分支切换指令，则无论代码文件是否因此发生改变，都需要执行一次映射操作。可选地，在步骤S19中，根据差异部分代码生成更新后的代码覆盖率测试结果可以包括以下执行步骤：步骤S191，获取原始代码文件、已更新代码文件以及代码覆盖率测试结果；步骤S192，将原始代码文件与已更新代码文件进行比对，确定差异部分代码；步骤S193，根据差异部分代码在原始代码文件的代码行与已更新代码文件的代码行之间建立对应关系；步骤S194，通过对应关系生成更新后的代码覆盖率测试结果。在具体执行映射操作的过程中，已知信息可以包括：修改前的原始代码文件(oldfile)，修改后的已更新代码文件(newfile)以及对应于oldfile的代码覆盖率测试结果(coverage_of_oldfile)。首先，通过diff程序分析得到预测的diff分析结果，以确定oldfile与newfile之间存在的差异，即，哪些代码行不一致。其次，通过解析上述diff分析结果，最终输出oldfile中的各行代码与newfile中的各行代码之间的对应关系表(linemapping)，其可以抽象成如表1所呈现的格式：表1oldfilenewfile行号112无3243……NN+2然后，先根据coverage_of_oldfile可以确定在oldfile中的哪些行代码已经被覆盖，再根据上述对应关系表linemapping，便可以生成与newfile对应的代码覆盖率测试结果coverage_of_newfile。至此，newfile与coverage_of_newfile便可以配套使用，以完成映射计算的整个过程。通过代码覆盖率测试结果的映射方式。在执行代码覆盖率测试的过程中，即便因工作需要对代码文件进行更新，仍然可以继续完成代码覆盖率测试，而无需重新开始。根据本发明实施例，还提供了一种代码覆盖率测试结果的处理装置的实施例，图2是根据本发明实施例的代码覆盖率测试结果的处理装置的流程图，如图2所示，该装置可以包括：第一获取模块10，用于获取与当前执行的代码覆盖率测试任务对应的代码覆盖率测试结果；处理模块20，用于将代码覆盖率测试结果导出至预设存储区域，其中，预设存储区域用于对代码覆盖率测试结果进行持久化存储。可选地，第一获取模块10，用于从终端的内存中读取代码覆盖率测试结果，其中，终端用于执行代码覆盖率测试操作。可选地，图3是根据本发明优选实施例的代码覆盖率测试结果的处理装置的流程图，如图3所示，处理模块20可以包括：第一确定单元200，用于确定待使用的数据导出格式，其中，数据导出格式可以包括但不限于：代码覆盖率测试任务对应的svn版本号、代码覆盖率测试任务的任务编号、代码覆盖率测试任务对应的原始代码文件的校验码、原始代码文件的代码行数、代码覆盖率测试结果的压缩编码方式；第一生成单元202，用于根据数据导出格式和代码覆盖率测试结果生成预设类型存储文件；处理单元204，用于将预设类型存储文件导出至预设存储区域。可选地，如图3所示，上述装置还可以包括：第一确定模块30，用于确定终端完成重新启动；判断模块40，用于判断代码覆盖率测试任务是否已经完成测试；第二获取模块50，用于在判断模块输出为否时，从预设存储区域内获取预设类型存储文件；还原模块60，用于从预设类型存储文件中还原出代码覆盖率测试结果，并将代码覆盖率测试结果导入至内存。可选地，如图3所示，上述装置还可以包括：第二确定模块70，用于确定当前存在对代码覆盖率测试任务对应的原始代码文件执行的更新操作；生成模块80，用于根据原始代码文件与已更新代码文件之间的差异部分代码生成与已更新代码文件对应的更新后的代码覆盖率测试结果。可选地，如图3所示，生成模块80可以包括：获取单元800，用于获取原始代码文件、已更新代码文件以及代码覆盖率测试结果；第二确定单元802，用于将原始代码文件与已更新代码文件进行比对，确定差异部分代码；建立单元804，用于根据差异部分代码在原始代码文件的代码行与已更新代码文件的代码行之间建立对应关系；第二生成单元806，用于通过对应关系生成更新后的代码覆盖率测试结果。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。以上所述仅是本发明的优选实施方式，应当指出，对于本
技术领域：
的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。当前第1页1 2 3