本发明涉及计算机测试技术领域，尤其涉及一种测试用例测试失败后重测试的方法、客户端及服务器。
背景技术：
随着计算机技术的不断发展，各种应用软件也越来越丰富，为了保证应用软件功能的正确性，需要对应用软件进行软件测试。软件测试，是描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程，换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。在软件测试中功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范；测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。现有技术中，通常通过各种测试框架对测试用例进行测试，如单元测试框架junit，junit是一个java编程语言编写的单元测试框架，是java平台最重要的单元测试框架之一，并且是一个家族的统称为xunit单元测试框架中的一个。
在实现本发明过程中，发明人发现现有技术中至少存在如下问题：当前junit如果测试用例集下有测试失败的测试用例需要重新进行测试，需要重测试整个测试用例集中的全部测试用例，在测试用例规模较大、运行场景复杂的环境中每次全部重新测试整个测试用例集，将导致测试效率低下，且产生较大的资源损耗。
技术实现要素：
本发明实施例提供一种测试用例测试失败后重测试的方法、客户端及服务器，实现了仅对需要重测试的测试用例进行重测试。
一方面，本发明实施例提供了一种测试用例测试失败后重测试的方法，包括：
接收客户端发起的多个测试用例的重测试请求；
通过预定的脚本文件，启动对所述重测试请求中多个测试用例的重测试；
针对重测试请求中的每一个测试用例，获取各个测试用例的运行信息日志文件；
基于预定的查找规则，在所述各个测试用例的运行信息日志文件中查找执行失败的测试用例；
对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告。
另一方面，本发明实施例提供了一种测试用例测试失败后重测试的方法，包括：
第一获取单元，用于获取各个测试用例的运行信息日志文件；
第一查找单元，用于基于预定的查找规则，在各个测试用例的运行信息日志文件中查找执行失败的测试用例；
第一执行及回写单元，用于对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
第一生成单元，用于基于所述重测试结果文件中的运行信息，生成重测试报告。
又另一方面，本发明实施例提供了一种测试用例测试失败后重测试的客户端，包括：
接收单元，用于接收客户端发起的多个测试用例的重测试请求；
启动单元，用于通过预定的脚本文件，启动对所述重测试请求中多个测试用例的重测试；
第二获取单元，用于针对重测试请求中的每一个测试用例，获取各个测试用例的运行信息日志文件；
第二查找单元，用于基于预定的查找规则，在所述各个测试用例的运行信息日志文件中查找执行失败的测试用例；
第二执行及回写单元，用于对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
第二生成单元，用于基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告。
上述技术方案具有如下有益效果：解决了现有技术中无法实现仅针对测试失败的测试用例执行重测试的问题，实现了在测试用例集下有测试失败的测试用例需要重新进行测试时，根据用户的需求，简单高效地仅对需要重测试的测试用例进行重测试，从而极大地提高了测试的效率，且极大地降低了系统资源的损耗；同时，能够直观、精确地向测试人员提供有效的测试结果数据；进一步地，节约了测试的成本。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明一个实施例中一种测试用例测试失败后重测试的方法流程图；
图2为本发明另一实施例中一种测试用例测试失败后重测试的方法流程图；
图3为本发明另一实施例中一种测试用例测试失败后重测试的客户端结构示意图；
图4为本发明另一实施例中一种测试用例测试失败后重测试的服务器结构示意图；
图5为本发明一优选实施例中重测试报告示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1所示，为本发明实施例中一种测试用例测试失败后重测试的方法流程图，包括：
101、获取各个测试用例的运行信息日志文件；
102、基于预定的查找规则，在各个测试用例的运行信息日志文件中查找执行失败的测试用例；
103、对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
104、基于所述重测试结果文件中的运行信息，生成重测试报告。
优选地，所述运行信息日志文件中包括日志类型信息、日志生成时间信息、日志路径信息和日志执行结果信息；
其中，所述日志执行结果信息包括运行成功、运行失败和运行错误；
其中，执行失败的测试用例包括运行失败的测试用例和运行错误的测试用例。
可选地，所述获取各个测试用例的运行信息日志文件之前，还包括：
针对每一个测试用例启用一个线程；
通过各个测试用例所启用的线程，对各个测试用例进行测试，并生成各个测试用例的运行信息日志文件；
其中，所述对查找到的各个执行失败的测试用例执行重测试，包括：
创建用于重测试测试用例的线程池；
通过每一个执行失败的测试用例所启用的线程，将每一个执行失败的测试用例提交至所述线程池；
通过所述线程池，对各个执行失败的测试用例执行重测试。
优选地，所述基于所述重测试结果文件中的运行信息，生成重测试报告，包括：
基于所述重测试结果文件中的运行信息，统计重测试的测试用例的数量和各个执行重测试的测试用例的运行结果信息，生成重测试报告；
其中，所述运行结果信息包括重测试的测试用例执行失败的数量、重测试的测试用例名称和执行重测试消耗的时间。
可选地，还包括：
若所述重测试报告中重测试的测试用例执行失败的数量不为零，通过人机交互界面，接收用户的重试指令，根据所述重测试报告中重测试的测试用例名称，对重测试过程中执行失败的测试用例再次进行重测试。
如图2所示，为本发明另一实施例中一种测试用例测试失败后重测试的方法流程图，包括：
201、接收客户端发起的多个测试用例的重测试请求；
202、通过预定的脚本文件，启动对所述重测试请求中多个测试用例的重测试；
203、针对重测试请求中的每一个测试用例，获取各个测试用例的运行信息日志文件；
204、基于预定的查找规则，在所述各个测试用例的运行信息日志文件中查找执行失败的测试用例；
205、对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
206、基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告。
优选地，所述运行信息日志文件中包括日志类型信息、日志生成时间信息、日志路径信息和日志执行结果信息；
其中，所述日志执行结果信息包括运行成功、运行失败和运行错误；
其中，执行失败的测试用例包括运行失败的测试用例和运行错误的测试用例。
可选地，所述接收客户端发起的多个测试用例的重测试请求之前，还包括：
针对每一个测试用例启用一个线程；
通过各个测试用例所启用的线程，对各个测试用例进行测试，并生成各个测试用例的运行信息日志文件；
其中，所述对查找到的各个执行失败的测试用例执行重测试，包括：
创建用于重测试测试用例的线程池；
通过每一个执行失败的测试用例所启用的线程，将每一个执行失败的测试用例提交至所述线程池；
通过所述线程池，对各个执行失败的测试用例执行重测试。
优选地，所述基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告，包括：
基于所述重测试结果文件中的运行信息，统计重测试的测试用例的数量和各个执行重测试的测试用例的运行结果信息，生成所述重测试请求的重测试报告；
其中，所述运行结果信息包括重测试的测试用例执行失败的数量、重测试的测试用例名称和执行重测试消耗的时间。
可选地，还包括：
针对接收到的多个客户端的多个重测试请求，将已生成的各个重测试请求的重测试报告进行合并，生成各个重测试请求的总重测试报告。
可选地，还包括：
在所述脚本文件中预设置重测试次数；
其中，所述基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告之后，还包括：
步骤a、判断当前重测试请求的重测试报告中重测试的测试用例执行失败的数量是否为零；
步骤b、若不为零，根据当前重测试请求的重试报告中重测试的测试用例名称，对重测试过程中执行失败的测试用例再次进行重测试；
步骤c、若再次进行重测试后的重测试报告中，再次重测试的测试用例执行失败的数量不为零，跳转执行步骤b，直至达到预设置的重测试次数或测试用例执行失败的数量为零后结束。
如图3所示，为本发明另一实施例中一种测试用例测试失败后重测试的客户端结构示意图，包括：
第一获取单元31，用于获取各个测试用例的运行信息日志文件；
第一查找单元32，用于基于预定的查找规则，在各个测试用例的运行信息日志文件中查找执行失败的测试用例；
第一执行及回写单元33，用于对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
第一生成单元34，用于基于所述重测试结果文件中的运行信息，生成重测试报告。
优选地，所述运行信息日志文件中包括日志类型信息、日志生成时间信息、日志路径信息和日志执行结果信息；
其中，所述日志执行结果信息包括运行成功、运行失败和运行错误；
其中，执行失败的测试用例包括运行失败的测试用例和运行错误的测试用例。
可选地，还包括：
第一启用单元，用于针对每一个测试用例启用一个线程；
第一测试及生成单元，用于通过各个测试用例各自的线程，对各个测试用例进行测试，并生成各个测试用例各自的运行信息日志文件；
其中，所述第一执行及回写单元，包括：
第一创建模块，用于创建用于重测试测试用例的线程池；
第一提交模块，用于通过每一个执行失败的测试用例的线程，将每一个执行失败的测试用例提交至所述线程池；
第一重测试模块，用于通过所述线程池，对各个执行失败的测试用例执行重测试。
可选地，所述第一生成单元，包括：
第一统计模块，用于基于所述重测试结果文件中的运行信息，统计重测试的测试用例的数量和各个执行重测试的测试用例的运行结果信息，生成重测试报告；
其中，所述运行结果信息包括重测试的测试用例执行失败的数量、重测试的测试用例名称和执行重测试消耗的时间。
可选地，还包括：
接收及重测试模块，用于若所述重测试报告中重测试的测试用例执行失败的数量不为零，通过人机交互界面，接收用户的重试指令，根据所述重测试报告中重测试的测试用例名称，对重测试过程中执行失败的测试用例再次进行重测试。
如图4所示，为本发明另一实施例中一种测试用例测试失败后重测试的服务器结构示意图，包括：
接收单元41，用于接收客户端发起的多个测试用例的重测试请求；
启动单元42，用于通过预定的脚本文件，启动对所述重测试请求中多个测试用例的重测试；
第二获取单元43，用于针对重测试请求中的每一个测试用例，获取各个测试用例的运行信息日志文件；
第二查找单元44，用于基于预定的查找规则，在所述各个测试用例的运行信息日志文件中查找执行失败的测试用例；
第二执行及回写单元45，用于对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；
第二生成单元46，用于基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告。
优选地，所述运行信息日志文件中包括日志类型信息、日志生成时间信息、日志路径信息和日志执行结果信息；
其中，所述日志执行结果信息包括运行成功、运行失败和运行错误；
其中，执行失败的测试用例包括运行失败的测试用例和运行错误的测试用例。
可选地，还包括：
第二启用单元，用于针对每一个测试用例启用一个线程；
第二测试及生成单元，用于通过各个测试用例所启用的线程，对各个测试用例进行测试，并生成各个测试用例的运行信息日志文件；
其中，所述第二执行及回写单元，包括：
第二创建模块，用于创建用于重测试测试用例的线程池；
第二提交模块，用于通过每一个执行失败的测试用例所启用的线程，将每一个执行失败的测试用例提交至所述线程池；
第二重测试模块，用于通过所述线程池，对各个执行失败的测试用例执行重测试。
优选地，所述第二生成单元，包括：
第二统计模块，用于基于所述重测试结果文件中的运行信息，统计重测试的测试用例的数量和各个执行重测试的测试用例的运行结果信息，生成所述重测试请求的重测试报告；
其中，所述运行结果信息包括重测试的测试用例执行失败的数量、重测试的测试用例名称和执行重测试消耗的时间。
可选地，还包括：
合并及生成单元，用于针对接收到的多个客户端的多个重测试请求，将已生成的各个重测试请求的重测试报告进行合并，生成各个重测试请求的总重测试报告。
可选地，还包括：
预设置单元，用于在所述脚本文件中预设置重测试次数；
其中，所述第二生成单元，还包括：
判断模块，用于判断当前重测试请求的重测试报告中重测试的测试用例执行失败的数量是否为零；
第三重测试模块，用于若不为零，根据当前重测试请求的重试报告中重测试的测试用例名称，对重测试过程中执行失败的测试用例再次进行重测试；
循环模块，用于若再次进行重测试后的重测试报告中，再次重测试的测试用例执行失败的数量不为零，跳转执行第三重测试模块，直至达到预设置的重测试次数或测试用例执行失败的数量为零后结束。
本发明实施例上述技术方案具有如下有益效果：解决了现有技术中无法实现仅针对测试失败的测试用例执行重测试的问题，实现了在测试用例集下有测试失败的测试用例需要重新进行测试时，根据用户的需求，简单高效地仅对需要重测试的测试用例进行重测试，从而极大地提高了测试的效率，且极大地降低了系统资源的损耗；同时，能够直观、精确地向测试人员提供有效的测试结果数据；进一步地，节约了测试的成本。
以下结合应用实例对本发明实施例上述技术方案进行详细说明：
本发明应用实例旨在仅对需要重测试的测试用例进行重测试。
如图1所述，所述运行信息日志文件中包括日志类型信息、日志生成时间信息、日志路径信息和日志执行结果信息；其中，所述日志执行结果信息包括运行成功、运行失败和运行错误；其中，执行失败的测试用例包括运行成功的测试用例和运行错误的测试用例。
例如，在测试平台a中，获取各个测试用例的运行信息日志文件，如获取到测试用例testcase1的运行信息日志文件和测试用例testcase2的运行信息日志文件；随后，基于预定的查找规则，如根据运行信息日志文件中执行失败的测试用例的标识信息进行查找的规则，在测试用例testcase1和testcase2的运行信息日志文件中查找执行失败的测试用例；若查找到执行失败的测试用例为testcase1和testcase2，对查找到的执行失败的测试用例testcase1和testcase2执行重测试，并将重测试的测试用例testcase1和testcase2的运行信息回写入重测试结果文件，如重测试结果文件testresults，中；基于重测试结果文件testresults中的运行信息，生成重测试报告。
在一优选实施例中，该方法还包括：针对每一个测试用例启用一个线程；通过各个测试用例所启用的线程，对各个测试用例进行测试，并生成各个测试用例的运行信息日志文件。
例如，在测试平台a中，基于junit测试框架对测试用例进行测试，在测试平台a中通过ant(一个java库和命令行工具)或maven(项目管理工具)方式运行测试用例；针对每一个测试用例启用一个线程，如测试用例包括testcase1和testcase2，则针对testcase1和testcase2分别各自启用一个线程，随后，通过测试用例testcase1和testcase2各自所启用的线程，对测试用例testcase1和testcase2进行测试，若通过ant方式对测试用例testcase1和testcase2进行测试，采用ant的junit-report生成测试用例testcase1和testcase2的运行信息日志文件；若通过maven方式对测试用例testcase1和testcase2进行测试，由于maven运行时扩展了surefire插件(该插件是maven下junit的执行插件)，基于surefire插件，生成测试用例testcase1和testcase2的运行信息日志文件；其中，测试用例testcase1和testcase2的运行信息日志文件中包括日志类型信息、日志生成时间信息、日志路径信息和日志执行结果信息；其中，日志执行结果信息包括运行成功、运行失败和运行错误。
其中，步骤103中所述对查找到的各个执行失败的测试用例执行重测试的步骤，包括：创建用于重测试测试用例的线程池；通过每一个执行失败的测试用例所启用的线程，将每一个执行失败的测试用例提交至所述线程池；通过所述线程池，对各个执行失败的测试用例执行重测试。
例如，接上例，创建用于重测试测试用例的线程池，如threadpool；基于预定的查找规则，如根据testcase1和testcase2的运行信息日志文件中失败的测试用例的标识信息，如测试用例的前缀信息，通过正则匹配的方式进行查找的规则，在测试用例testcase1和testcase2的运行信息日志文件中查找执行失败的测试用例；若查找到执行失败的测试用例为testcase1和testcase2，通过执行失败的测试用例testcase1和testcase2各自所启用的线程，将执行失败的测试用例testcase1和testcase2提交至线程池threadpool；通过线程池threadpool，对执行失败的测试用例testcase1和testcase2执行重测试，并将重测试的测试用例testcase1和testcase2的运行信息回写入重测试结果文件testresults中。
需要说明的是，本领域技术人员可以了解到，junit是一个java语言的单元测试框架，它由kentbeck和erichgamma建立，逐渐成为源于kentbeck的sunit的xunit家族中最为成功的一个，junit是一个开放源代码的java测试框架，用于编写和运行可重复的测试，它是用于单元测试框架体系xunit的一个实例；ant是一个java库和命令行工具，为java技术开发项目提供跨平台构建任务，ant中集成了junit测试的task标签，可以通过ant编写相应的target标签，以实现junit的自动化测试；maven是一个项目管理工具，它包含了一个项目对象模型(projectobjectmodel)，一组标准集合，一个项目生命周期(projectlifecycle)，一个依赖管理系统(dependencymanagementsystem)和用来运行定义在生命周期阶段中插件目标的逻辑，maven可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。
在一优选实施例中，所述基于所述重测试结果文件中的运行信息，生成重测试报告，包括：基于所述重测试结果文件中的运行信息，统计重测试的测试用例的数量和各个执行重测试的测试用例的运行结果信息，生成重测试报告。
其中，所述运行结果信息包括重测试的测试用例执行失败的数量、重测试的测试用例名称和执行重测试消耗的时间。
例如，在测试平台a中，基于重测试结果文件testresults中的运行信息，统计重测试的测试用例的数量和各个执行重测试的测试用例的运行结果信息，生成重测试报告，重测试报告如图5所示。
在一优选实施例中，该方法还包括：若所述重测试报告中重测试的测试用例执行失败的数量不为零，通过人机交互界面，接收用户的重试指令，根据所述重测试报告中重测试的测试用例名称，对重测试过程中执行失败的测试用例再次进行重测试。
例如，在测试平台a中，若重测试报告testresults中重测试的测试用例执行失败的数量不为零，通过人机交互界面，接收用户的重试指令，根据重测试报告testresults中重测试的测试用例名称，如为testcase1，对重测试过程中执行失败的测试用例testcase1再次进行重测试。
通过本实施例，能够根据测试人员的需求，再次执行相应的重测试，进一步地，为能够更准确地执行测试任务提供了重要的保障。
本发明另一实施例提供了一种测试用例测试失败后重测试的客户端，可以实现上述提供的方法实施例，具体功能实现请参见方法实施例中的说明，在此不再赘述。
如图2所示，例如，在测试服务器平台b中，接收客户端发起的多个测试用例的重测试请求，如接受到客户端u1发起的重测试测试用例的请求request1和客户端u2发起的重测试测试用例的请求request2；通过预定的脚本文件，如shell(一种程序设计语言)文件，启动对重测试请求request1和request2各自的测试用例的重测试；随后，针对每一个请求，如针对重测试请求request1，获取重测试请求request1的各个测试用例的运行信息日志文件，基于预定的查找规则，在各个测试用例的运行信息日志文件中查找执行失败的测试用例；对查找到的各个执行失败的测试用例执行重测试，并将各个重测试的测试用例的运行信息回写入重测试结果文件中；基于所述重测试结果文件中的运行信息，生成针对重测试请求request1的重测试报告。其中，在在测试服务器平台b中对每一个请求执行重测试的方式与在测试平台a中执行重测试的方式，在此不再赘述。
通过本实施例，实现了在测试用例集下有测试失败的测试用例需要重新进行测试时，根据用户的需求，简单高效地仅对多个重测试请求的测试用例自动化进行并发重测试，从而极大地提高了测试的效率，且极大地降低了系统资源的损耗；同时，能够直观、精确地向测试人员提供有效的测试结果数据；进一步地，节约了测试的成本。
在一优选实施例中，步骤206基于所述重测试结果文件中的运行信息，生成针对所述重测试请求的重测试报告之后，还包括：针对接收到的多个客户端的多个重测试请求，将已生成的各个重测试请求的重测试报告进行合并，生成各个重测试请求的总重测试报告。
例如，在测试服务器平台b中，将已生成的针对重测试请求request1和重测试请求request2各自的重测试报告进行合并，生成重测试请求request1和重测试请求request2的总重测试报告。
通过本实施例，能够更直观地为测试人员提供测试结果，进一步地，提高了测试人员的测试效率。
其中，还可以通过预定的脚本文件将所述合并后的总重测试报告已邮件的方式发送至预定的目标邮箱。
在一优选实施例中，该方法还包括：在所述脚本文件中预设置重测试次数。
其中，步骤206基于所述重测试结果文件中的运行信息，生成针对所述重测试的重测试报告之后，还包括：步骤a、判断当前重测试请求的重测试报告中重测试的测试用例执行失败的数量是否为零；步骤b、若不为零，根据当前重测试请求的重试报告中重测试的测试用例名称，对重测试过程中执行失败的测试用例再次进行重测试；步骤c、若再次进行重测试后的重测试报告中，再次重测试的测试用例的数量不为零，跳转执行步骤b，直至达到预设置的重测试次数或测试用例执行失败的数量为零后结束。
例如，在测试服务器平台b中，在shell文件中预设置重测试次数，如2次，基于重测试结果文件中的运行信息，生成针对重测试请求，如重测试请求request1，的重测试报告之后，判断重测试请求request1的重试报告中重测试的测试用例执行失败的数量是否为零；若不为零，根据当前重测试请求的重试报告中重测试的的测试用例名称，如testcase3，对重测试过程中执行失败的测试用例testcase3执行第一次重测试，若第一次重测试后的重测试报告中第一次重测试过程中执行失败的测试用例的数量不为零，根据当前重测试请求request1的重试报告中重测试的测试用例名称，如为testcase3，对重测试过程中执行失败的测试用例testcase3执行第二次重测试，根据预定重测试次数为2次，第二次重测试执行完毕，结束针对重测试请求request1的重测试操作；若第一次重测试后的重测试报告中第一次重测试过程中执行失败的测试用例的数量为零，结束针对重测试请求request1的重测试操作。
通过本实施例，通过本实施例，能够根据测试人员的自定义需求，灵活地控制执行重测试的次数，进一步地，为能够更准确地执行测试任务提供了重要的保障。
本发明另一实施例提供了一种测试用例测试失败后重测试的服务器，可以实现上述提供的方法实施例，具体功能实现请参见方法实施例中的说明，在此不再赘述。
应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。
在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。
为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本申请公开的原理和新颖性特征的最广范围相一致。
上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。
本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrativelogicalblock)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrativecomponents)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。
本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(asic)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。
本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动磁盘、cd-rom或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于asic中，asic可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。
在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(dsl)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、dvd、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。