一种基于Srum游戏开发的敏捷测试方法及系统与流程

本申请涉及游戏测试技术领域，尤其涉及一种基于srum游戏开发的敏捷测试方法及系统。

背景技术：

随着4g时代向5g时代的发展，移动设备在大众生活中扮演的角色越来越重要，各类手机app应用而生。近年来，游戏app开发已成为app开发领域的热门之一。相较于普通app，游戏app市场需求变化和更新迭代速度更快。因此，移动app开发竞争要求产品快速适应市场需求，以最短时间抢占市场份额，提高产品竞争性。

目前，对游戏app的测试主要有传统测试和敏捷测试，其中，传统测试需开发代码完成后进入测试阶段，无法体现出“高度迭代、持续集成和反馈”的测试特点。该方法缺点是需求分析和系统设计缺陷发现反馈较晚，无法及时调整需求或设计方式，致使大量时间被消耗，可能会拖延产品交付时间。敏捷测试需融入到整个产品周期，通过持续对软件进行测试，以提高软件质量。该方法具有“尽早介入”，“持续集成测试”，“不过多依赖文档”，“拥抱变化”等特点。在游戏app中场景复杂且规则多变，一方面，没有较详细的测试用例作为引导，可能出现某些路径覆盖不全；另一方面，编写自动化脚本时间成本较大，测试阶段不太适合。

因此，在游戏app测试过程中，如何从游戏app实际应用角度出发，克服传统测试和敏捷测试的缺点，是一项亟待解决的问题。

技术实现要素：

有鉴于此，本申请提供了一种软件测试方法，能够有效的利用传统测试和敏捷测试的优点，并有效的规避了两者的缺点，在测试工作中有效的提高了工作效率，更好的保障了软件的质量。

本申请提供了一种基于srum游戏开发的敏捷测试方法，所述方法包括：

在项目立项后，对整个项目进行需求分析评审；

在srum开发阶段，基于需求分析评审结果生成测试用例；

在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试；

在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试；

在所述全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试；

基于系统结束测试情况，调整封版时间。

优选地，所述在基于系统结束测试情况，调整封版时间后，还包括：

整理测试用例，作为下一个迭代文档沉淀，编写自动化脚本，实现本sprint核心功能。

优选地，所述在所述全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试包括：

在所述全功能测试阶段修复率在75％以上时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试。

优选地，所述基于系统结束测试情况，调整封版时间包括：

当系统结束测试时，若测试情况已达到上线标准，则调整封版时间最多为半天。

优选地，所述基于系统结束测试情况，调整封版时间还包括：

当系统结束测试时，若系统存在严重缺陷，则调整封版时间至少为一天。

一种基于srum游戏开发的敏捷测试系统，包括：

评审模块，用于在项目立项后，对整个项目进行需求分析评审；

生成模块，用于在srum开发阶段，基于需求分析评审结果生成测试用例；

第一测试模块，用于在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试；

第二测试模块，用于在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试；

第三测试模块，用于在所述全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试；

调整模块，用于基于系统结束测试情况，调整封版时间。

优选地，所述的系统，还包括：

整理模块，用于整理测试用例，作为下一个迭代文档沉淀，编写自动化脚本，实现本sprint核心功能。

优选地，所述第二测试模块具体用于：

在所述全功能测试阶段修复率在75％以上时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试。

优选地，所述调整模块具体用于：

当系统结束测试时，若测试情况已达到上线标准，则调整封版时间最多为半天。

优选地，所述调整模块具体还用于：

当系统结束测试时，若系统存在严重缺陷，则调整封版时间至少为一天。

综上所述，本申请公开了一种基于srum游戏开发的敏捷测试方法，当需要对游戏app进行测试时，首先在项目立项后，对整个项目进行需求分析评审，然后在srum开发阶段，基于需求分析评审结果生成测试用例，在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试，在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试，在全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回测测试并基于自动化测试工具完成性能测试，基于系统结束测试情况，调整封版时间，本申请能够有效的利用传统测试和敏捷测试的优点，并有效的规避了两者的缺点，在测试工作中有效的提高了工作效率，更好的保障了软件的质量。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请公开的一种基于srum游戏开发的敏捷测试方法实施例1的流程图；

图2为本申请公开的一种基于srum游戏开发的敏捷测试方法实施例2的流程图；

图3为本申请公开的一种基于srum游戏开发的敏捷测试系统实施例1的结构示意图；

图4为本申请公开的一种基于srum游戏开发的敏捷测试系统实施例2的结构示意图。

具体实施方式

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

在对本申请的实施例进行详细描述前，首先对srum和敏捷测试进行说明：

srum，是迭代式增量软件开发过程，通常用于敏捷软件开发。

敏捷测试，是测试的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。敏捷测试是遵循敏捷宣言的一种测试实践：1、强调从客户的角度，即从使用系统的用户角度，来测试系统。2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

如图1所示，为本申请实施例1公开的一种基于srum游戏开发的敏捷测试方法的流程图，所述方法可以包括以下步骤：

s101、在项目立项后，对整个项目进行需求分析评审；

当需要对游戏app进行测试时，在项目立项后，测试、技术和产品全程参与整个项目评审和开发过程，对整个项目进行需求分析评审，而不是把测试过程看作是需求分析、系统设计和代码开发之后的一个独立阶段。通过对整个项目进行需求分析评审，能提早发现需求分析和系统设计缺陷并及时反馈，以缩短产品交付时间。

s102、在srum开发阶段，基于需求分析评审结果生成测试用例；

当对整个项目进行需求分析评审后，在srum开发阶段，根据需求分析分析评审结果生成相应的测试用例。即，在生成测试用例时，可以分配不同人员编写高质量且详细的测试用例；各成员完成用例编写后，小组内快速高效的进行测试用例评审，不同人员可及时补充遗漏测试点和注意事项，提高测试用例质量和测试覆盖度。另外，测试团队中每个成员能力不同。一般情况下，测试人员采用交叉或者分功能测试，各个人负责内容不同。因此，高质量的测试用例是后期进入测试实施阶段必不可少的引导文案，也是测试组保质保量交付产品的依据。

s103、在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试；

部分功能开发完成，测试即可尽早介入功能测试阶段。根据已完成功能的测试用例，展开对功能模块测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围，灵活判断回归测试范围，快速迭代交付。

s104、在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试；

在测试进入全功能迭代阶段时，对于已测试通过的功能，及时做好回归测试；对于未测试或测试未完成功能，持续功能测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围。在全功能测试阶段，产品根据当前市场需求增加或变更产品功能，测试和技术要快速接受和拥抱变。技术功能迭代开发后，测试人员需与相关技术和产品沟通，确认需求点和迭代代码影响功能范围，快速确认测试覆盖面和测试点，及时反馈和跟踪问题，同时完善原测试用例集。在测试前期充分的准备基础上，依靠产品需求熟知度和测试过程产品方向把控，提高测试效率，进而在保证产品质量前提下，加快产品上线时间。

s105、在全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试；

当全功能测试阶段修复率满足预设条件时，准入到系统测试阶段。为了衡量游戏app客户端稳定程度和性能指标，系统测试阶段采用快速高效的自动化测试工具，对app版本做特殊场景和常用场景的测试。后期，需进行全功能回归测试，发现全功能期遗漏问题。

s106、基于系统结束测试情况，调整封版时间。

根据系统阶段功能、性能和稳定测试结果，灵活调整封版时间，以缩短交付时间。

综上所述，在上述实施例中，当需要对游戏app进行测试时，首先在项目立项后，对整个项目进行需求分析评审，然后在srum开发阶段，基于需求分析评审结果生成测试用例，在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试，在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试，在全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试，基于系统结束测试情况，调整封版时间，本申请能够有效的利用传统测试和探索式测试的优点，并有效的规避了两者的缺点，在测试工作中有效的提高了工作效率，更好的保障了软件的质量。

如图2所示，为本申请实施例2公开的一种基于srum游戏开发的敏捷测试方法的流程图，所述方法可以包括以下步骤：

s201、在项目立项后，对整个项目进行需求分析评审；

当需要对游戏app进行测试时，在项目立项后，测试、技术和产品全程参与整个项目评审和开发过程，对整个项目进行需求分析评审，而不是把测试过程看作是需求分析、系统设计和代码开发之后的一个独立阶段。通过对整个项目进行需求分析评审，能提早发现需求分析和系统设计缺陷并及时反馈，以缩短产品交付时间。

s202、在srum开发阶段，基于需求分析评审结果生成测试用例；

当对整个项目进行需求分析评审后，在srum开发阶段，根据需求分析分析评审结果生成相应的测试用例。即，在生成测试用例时，可以分配不同人员编写高质量且详细的测试用例；各成员完成用例编写后，小组内快速高效的进行测试用例评审，不同人员可及时补充遗漏测试点和注意事项，提高测试用例质量和测试覆盖度。另外，测试团队中每个成员能力不同。一般情况下，测试人员采用交叉或者分功能测试，各个人负责内容不同。因此，高质量的测试用例是后期进入测试实施阶段必不可少的引导文案，也是测试组保质保量交付产品的依据。

s203、在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试；

部分功能开发完成，测试即可尽早介入功能测试阶段。根据已完成功能的测试用例，展开对功能模块测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围，灵活判断回归测试范围，快速迭代交付。

s204、在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试；

在测试进入全功能迭代阶段时，对于已测试通过的功能，及时做好回归测试；对于未测试或测试未完成功能，持续功能测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围。在全功能测试阶段，产品根据当前市场需求增加或变更产品功能，测试和技术要快速接受和拥抱变。技术功能迭代开发后，测试人员需与相关技术和产品沟通，确认需求点和迭代代码影响功能范围，快速确认测试覆盖面和测试点，及时反馈和跟踪问题，同时完善原测试用例集。在测试前期充分的准备基础上，依靠产品需求熟知度和测试过程产品方向把控，提高测试效率，进而在保证产品质量前提下，加快产品上线时间。

s205、在全功能测试阶段修复率在75％以上时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试；

全功能测试阶段缺陷修复率在75％以上时，准入到系统测试阶段。为了衡量游戏app客户端稳定程度和性能指标，系统测试阶段采用快速高效的自动化测试工具，对app版本做特殊场景和常用场景的测试。后期，需进行全功能回归测试，发现全功能期遗漏问题。

s206、当系统结束测试时，若测试情况已达到上线标准，则调整封版时间最多为半天；

根据系统阶段功能、性能和稳定测试结果，灵活调整封版时间，以缩短交付时间。若版本系统结束时测试情况良好且已达到上线标准，则封版阶段采用最多半天时间过核心功能即可。

s207、当系统结束测试时，若系统存在严重缺陷，则调整封版时间至少为一天；

若版本系统结束时存在缺陷问题较严重情况，则封版需要回归测试严重问题，同时走核心功能，需要至少一天时间。

s208、整理测试用例，作为下一个迭代文档沉淀，编写自动化脚本，实现本sprint核心功能。

测试结束，整理测试用例，作为下一个sprint文档沉淀。此外，测试人员需自动化实现本sprint核心功能，一方面不占用任何一个产品sprint时间，另一方面能缩短下一个sprint对本sprint核心功能回归测试时间。

综上所述，在上述实施例中，融合了传统测试和敏捷测试方法，以详细测试用例引导整个敏捷测试过程，保证了交付产品质量；部分功能开发完成，测试立即进入功能测试迭代期，可快速发现软件开发和产品需求早期的缺点和问题，及时调整整个产品开发走向，避免不必要的时间成本；功能迭代期，需求变更，无需耗时编写测试用例，通过沟通方式确认代码框架和影响范围，边测边出引导测试点，完善测试用例集，加快产品交付时间；一个sprint结束后，自动化实现核心功能，缩短下一个sprint对上一个sprint核心功能的回归测试时间。

如图3所示，为本申请实施例1公开的一种基于srum游戏开发的敏捷测试系统的结构示意图，所述系统可以包括：

评审模块301，用于在项目立项后，对整个项目进行需求分析评审；

当需要对游戏app进行测试时，在项目立项后，测试、技术和产品全程参与整个项目评审和开发过程，对整个项目进行需求分析评审，而不是把测试过程看作是需求分析、系统设计和代码开发之后的一个独立阶段。通过对整个项目进行需求分析评审，能提早发现需求分析和系统设计缺陷并及时反馈，以缩短产品交付时间。

生成模块302，用于在srum开发阶段，基于需求分析评审结果生成测试用例；

当对整个项目进行需求分析评审后，在srum开发阶段，根据需求分析分析评审结果生成相应的测试用例。即，在生成测试用例时，可以分配不同人员编写高质量且详细的测试用例；各成员完成用例编写后，小组内快速高效的进行测试用例评审，不同人员可及时补充遗漏测试点和注意事项，提高测试用例质量和测试覆盖度。另外，测试团队中每个成员能力不同。一般情况下，测试人员采用交叉或者分功能测试，各个人负责内容不同。因此，高质量的测试用例是后期进入测试实施阶段必不可少的引导文案，也是测试组保质保量交付产品的依据。

第一测试模块303，用于在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试；

部分功能开发完成，测试即可尽早介入功能测试阶段。根据已完成功能的测试用例，展开对功能模块测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围，灵活判断回归测试范围，快速迭代交付。

第二测试模块304，用于在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试；

在测试进入全功能迭代阶段时，对于已测试通过的功能，及时做好回归测试；对于未测试或测试未完成功能，持续功能测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围。在全功能测试阶段，产品根据当前市场需求增加或变更产品功能，测试和技术要快速接受和拥抱变。技术功能迭代开发后，测试人员需与相关技术和产品沟通，确认需求点和迭代代码影响功能范围，快速确认测试覆盖面和测试点，及时反馈和跟踪问题，同时完善原测试用例集。在测试前期充分的准备基础上，依靠产品需求熟知度和测试过程产品方向把控，提高测试效率，进而在保证产品质量前提下，加快产品上线时间。

第三测试模块305，用于在全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试；

当全功能测试阶段修复率满足预设条件时，准入到系统测试阶段。为了衡量游戏app客户端稳定程度和性能指标，系统测试阶段采用快速高效的自动化测试工具，对app版本做特殊场景和常用场景的测试。后期，需进行全功能回归测试，发现全功能期遗漏问题。

调整模块306，用于基于系统结束测试情况，调整封版时间。

根据系统阶段功能、性能和稳定测试结果，灵活调整封版时间，以缩短交付时间。

综上所述，在上述实施例中，当需要对游戏app进行测试时，首先在项目立项后，对整个项目进行需求分析评审，然后在srum开发阶段，基于需求分析评审结果生成测试用例，在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试，在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试，在全功能测试阶段修复率满足预设条件时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试，基于系统结束测试情况，调整封版时间，本申请能够有效的利用传统测试和探索式测试的优点，并有效的规避了两者的缺点，在测试工作中有效的提高了工作效率，更好的保障了软件的质量。

如图4所示，为本申请实施例2公开的一种基于srum游戏开发的敏捷测试系统的结构示意图，所述系统可以包括：

评审模块401，用于在项目立项后，对整个项目进行需求分析评审；

当需要对游戏app进行测试时，在项目立项后，测试、技术和产品全程参与整个项目评审和开发过程，对整个项目进行需求分析评审，而不是把测试过程看作是需求分析、系统设计和代码开发之后的一个独立阶段。通过对整个项目进行需求分析评审，能提早发现需求分析和系统设计缺陷并及时反馈，以缩短产品交付时间。

生成模块402，用于在srum开发阶段，基于需求分析评审结果生成测试用例；

当对整个项目进行需求分析评审后，在srum开发阶段，根据需求分析分析评审结果生成相应的测试用例。即，在生成测试用例时，可以分配不同人员编写高质量且详细的测试用例；各成员完成用例编写后，小组内快速高效的进行测试用例评审，不同人员可及时补充遗漏测试点和注意事项，提高测试用例质量和测试覆盖度。另外，测试团队中每个成员能力不同。一般情况下，测试人员采用交叉或者分功能测试，各个人负责内容不同。因此，高质量的测试用例是后期进入测试实施阶段必不可少的引导文案，也是测试组保质保量交付产品的依据。

第一测试模块403，用于在部分功能测试阶段，基于已完成功能的测试用例，展开对功能模块测试；

部分功能开发完成，测试即可尽早介入功能测试阶段。根据已完成功能的测试用例，展开对功能模块测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围，灵活判断回归测试范围，快速迭代交付。

第二测试模块404，用于在全部功能提测后进入全功能迭代阶段，基于不同功能模块的测试情况，分别进行回归测试或功能测试；

在测试进入全功能迭代阶段时，对于已测试通过的功能，及时做好回归测试；对于未测试或测试未完成功能，持续功能测试，及时发现功能缺陷或需求漏洞，快速反馈信息至技术和产品，实时跟踪bug情况，确认bug影响范围。在全功能测试阶段，产品根据当前市场需求增加或变更产品功能，测试和技术要快速接受和拥抱变。技术功能迭代开发后，测试人员需与相关技术和产品沟通，确认需求点和迭代代码影响功能范围，快速确认测试覆盖面和测试点，及时反馈和跟踪问题，同时完善原测试用例集。在测试前期充分的准备基础上，依靠产品需求熟知度和测试过程产品方向把控，提高测试效率，进而在保证产品质量前提下，加快产品上线时间。

第三测试模块405，用于在全功能测试阶段修复率在75％以上时，准入系统测试阶段，进行全功能回归测试并基于自动化测试工具完成性能测试；

全功能测试阶段缺陷修复率在75％以上时，准入到系统测试阶段。为了衡量游戏app客户端稳定程度和性能指标，系统测试阶段采用快速高效的自动化测试工具，对app版本做特殊场景和常用场景的测试。

调整模块406，用于当系统结束测试时，若测试情况已达到上线标准，则调整封版时间最多为半天；

根据系统阶段功能、性能和稳定测试结果，灵活调整封版时间，以缩短交付时间。若版本系统结束时测试情况良好且已达到上线标准，则封版阶段采用最多半天时间过核心功能即可。

调整模块406，还用于当系统结束测试时，若系统存在严重缺陷，则调整封版时间至少为一天；

若版本系统结束时存在缺陷问题较严重情况，则封版需要回归测试严重问题，同时走核心功能，需要至少一天时间。

整理模块407，用于整理测试用例，作为下一个迭代文档沉淀，编写自动化脚本，实现本sprint核心功能。

测试结束，整理测试用例，作为下一个sprint文档沉淀。此外，测试人员需自动化实现本sprint核心功能，一方面不占用任何一个产品sprint时间，另一方面能缩短下一个sprint对本sprint核心功能回归测试时间。

综上所述，在上述实施例中，融合了传统测试和敏捷测试方法，以详细测试用例引导整个敏捷测试过程，保证了交付产品质量；部分功能开发完成，测试立即进入功能测试迭代期，可快速发现软件开发和产品需求早期的缺点和问题，及时调整整个产品开发走向，避免不必要的时间成本；功能迭代期，需求变更，无需耗时编写测试用例，通过沟通方式确认代码框架和影响范围，边测边出引导测试点，完善测试用例集，加快产品交付时间；一个sprint结束后，自动化实现核心功能，缩短下一个sprint对上一个sprint核心功能的回归测试时间。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。