一种测试数据处理方法、装置、存储介质及设备

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种测试数据处理方法、装置、存储介质及设备。

背景技术

在项目级代码开发完成后，通常会对项目中的软件产品进行测试，以确保软件产品的质量。目前，对于项目数量众多的企业来说，由于每个项目的测试往往涉及到不同团队、不同测试平台等，管理人员难以对测试结果进行整理，因而无法获知各项目的具体测试情况，导致管理效率较低。

发明内容

本申请实施例的目的在于提供一种测试数据处理方法、装置、存储介质及设备，旨在解决相关技术中存在的管理人员难以获知代码测试情况，导致管理效率较低的问题。

第一方面，本申请实施例提供的一种测试数据处理方法，包括：

从多个渠道获取以应用编号及月份为维度的代码测试基础数据；

基于应用编号与负责人之间的对应关系，对所述代码测试基础数据进行加工处理，得到分别以部门、小组、负责人、时间为维度的多种汇总数据；所述多种汇总数据包括表征代码的测试程度的数据，以及表征自动化测试案例的质量的数据；

根据用户的目标指标查询请求，输出目标指标对应的汇总数据，其中，所述目标指标包括从部门、小组、负责人、时间中指定的至少一个维度以及从所述汇总数据的类型中指定的至少一个类型。

在上述实现过程中，从多个渠道获取以应用编号及月份为维度的代码测试基础数据，再利用应用编号与负责人之间的对应关系，将代码测试基础数据进行加工处理成按照部门、小组、负责人、时间为维度的多种汇总数据，之后，在用户请求查询指定维度及指定类型的汇总数据时，输出对应的数据。这样，使得产线测试人员可以直观快速地获知自己及所在团队负责的代码测试情况和产线质量情况，同时也便于管理人员进行规划管理，提升管理效率。

进一步地，在一些实施例中，所述多个渠道包括Libra平台和AutoMan平台。

在上述实现过程中，提供获取代码测试相关的基础数据的可选渠道类型。

进一步地，在一些实施例中，所述从多个渠道获取以应用编号及月份为维度的代码测试基础数据，包括：

周期性从多个渠道获取代码测试基础数据，并将所述代码测试基础数据按照应用编号及月份为维度落库。

在上述实现过程中，通过定时跑代码测试基础数据，并按照应用编号及月份为维度落库，为后续的数据加工处理及汇总数据的展示奠定良好的基础。

进一步地，在一些实施例中，所述将所述代码测试基础数据按照应用编号及月份为维度落库，包括：

基于所述代码测试基础数据的应用编号及月份，生成所述代码测试基础数据对应的唯一标识ID；

判断所述唯一标识ID是否已存在，是则利用所述代码测试基础数据对已存在的唯一标识ID所对应的数据进行批量更新，否则使用批量插入的方式将所述代码测试基础数据落库。

在上述实现过程中，根据应用编号及月份这两个字段组成唯一性约束，以此判断什么时候做插入什么时候做更新，并利用批量处理操作，实现性能的显著提高。

进一步地，在一些实施例中，所述表征代码的测试程度的数据可以包括以下至少一种：全量代码覆盖率、增量代码覆盖率、增量自动化代码覆盖率、接口覆盖率；

所述表征自动化测试案例的质量的数据包括以下至少一种：自动化测试案例的通过率、自动化测试案例的活跃率。

在上述实现过程中，提供可以使得项目测试人员直观地了解代码覆盖情况以及产线质量情况的汇总数据类型。

进一步地，在一些实施例中，所述输出目标指标对应的汇总数据，包括：

通过图的形式输出目标指标对应的汇总数据，并在所述图中显示所述目标指标对应的达标线。

在上述实现过程中，通过设置达标线，方便管理人员了解达标情况，从而提升管理效率。

第二方面，本申请实施例提供的一种测试数据处理装置，包括：

获取模块，用于从多个渠道获取以应用编号及月份为维度的代码测试基础数据；

汇总模块，用于基于应用编号与负责人之间的对应关系，对所述代码测试基础数据进行加工处理，得到分别以部门、小组、负责人、时间为维度的多种汇总数据；所述多种汇总数据包括表征代码的测试程度的数据，以及表征自动化测试案例的质量的数据；

输出模块，用于根据用户的目标指标查询请求，输出目标指标对应的汇总数据，其中，所述目标指标包括从部门、小组、负责人、时间中指定的至少一个维度以及从所述汇总数据的类型中指定的至少一个类型。

第三方面，本申请实施例提供的一种电子设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面任一项所述的方法的步骤。

第四方面，本申请实施例提供的一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，使得所述计算机执行如第一方面任一项所述的方法。

第五方面，本申请实施例提供的一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行如第一方面任一项所述的方法。

本申请公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本申请公开的上述技术即可得知。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种测试数据处理方法的流程图；

图2为本申请实施例提供的一种汇总数据的展示结果的示意图；

图3为本申请实施例提供的一种测试数据处理装置的框图；

图4为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

如背景技术记载，相关技术中存在着管理人员难以获知代码测试情况，导致管理效率较低的问题。基于此，本申请实施例提供一种测试数据处理方案，以解决上述问题。

接下来对本申请实施例进行介绍：

如图1所示，图1是本申请实施例提供的一种测试数据处理方法的流程图，所述方法可以应用于企业的数据管理系统。该系统用于对各个项目的代码测试相关数据进行收集、处理并展示。

所述方法包括：

在步骤101、从多个渠道获取以应用编号及月份为维度的代码测试基础数据；

本步骤中提到的代码测试基础数据可以是指用于计算与代码测试相关的各种指标的基础数据。该代码测试基础数据是从多个渠道获取得到的，这里的多个渠道可以是供技术人员评测项目代码时使用的多个平台，其可以包括Libra平台、AutoMan平台等。Libra平台是一个代码覆盖率收集平台，其可以收集代码覆盖率数据并进行展示，具体地，Libra平台一般通过ASM(一个Java字节码操控框架，能够以二进制形式修改已有类或者动态生成类)完成对软件包中class文件字节码的操作，获知哪些行的代码被执行到，从而获取代码覆盖情况。因此，从Libra平台可以获取到表征代码覆盖情况的基础数据，如手动执行的代码覆盖率、自动化执行的代码覆盖率等。AutoMan平台是一个完整的页面自动化平台，其可以使得测试案例、测试脚本、执行报表在一个统一的在线平台进行维护和查看，产线测试人员会将写好的测试案例放到AutoMan平台去执行，以获取测试案例的通过率以及失败案例，从而节省工作时间。因此，从AutoMan平台可以获取到表征自动化测试案例测试情况的基础数据，如自动化测试案例总数、失败案例数、接口被自动化测试案例覆盖的个数等。

在一些实施例中，本步骤可以包括：周期性从多个渠道获取代码测试基础数据，并将所述代码测试基础数据按照应用编号及月份为维度落库。也就是说，可以生成一个JOB定时跑数据，该JOB可以按照预设的时间周期，自动查询多个平台公开的API，以获取代码测试基础数据，并将获取到的代码测试基础数据按照应用编号及月份为维度存于数据库中。其中，应用编号指的是APPID，也称应用ID，在企业中，产品涉及的功能一般是按系统分的，每个系统下又有多个APPID，每个APPID都有对应的代码仓库。各平台提供的代码测试基础数据中通常会带有APPID和时间这两种数据，因此，按照应用编号及月份为维度落库，方便数据的统计。跑数据的时间周期可以是1天，也可以是12小时、6小时等等，其可以根据具体场景的需求进行设置。另外，落库后，这些代码测试基础数据可以记录于多张明细表中，为后续的数据加工处理及汇总数据的展示奠定良好的基础。

进一步地，在一些实施例中，前面提到的将所述代码测试基础数据按照应用编号及月份为维度落库可以包括：基于所述代码测试基础数据的应用编号及月份，生成所述代码测试基础数据对应的唯一标识ID；判断所述唯一标识ID是否已存在，是则利用所述代码测试基础数据对已存在的唯一标识ID所对应的数据进行批量更新，否则使用批量插入的方式将所述代码测试基础数据落库。在实际应用中，多个渠道产生的代码测试基础数据的数据量是非常大的，若针对每个数据均生成一个数据库记录，处理效率较低，因此，本实施例引入针对大数据量的批量插入更新机制，先根据应用编号及月份生成唯一标识ID，该唯一标识ID可以认为是按照应用编号及月份这两个字段组合起来的唯一型约束，之后，判断该唯一标识ID是否已存在，若是，表明本周期的这一代码测试基础数据应是数据库中某个已有数据的更新数据，因而可以执行批量更新操作；若否，表明本周期的这一代码测试基础数据与数据库中其他数据在应用编号和月份至少一方面是不同的，因而可以执行批量插入操作。如此，通过批量处理，实现性能的显著提高。

在步骤102、基于应用编号与负责人之间的对应关系，对所述代码测试基础数据进行加工处理，得到分别以部门、小组、负责人、时间为维度的多种汇总数据；所述多种汇总数据包括表征代码的测试程度的数据，以及表征自动化测试案例的质量的数据；

在实际应用中，各个平台提供的代码测试基础数据是对应的平台根据各自的统计规则记录的明细数据，这些明细数据无法直观地展示出用户需要获知的代码测试情况，而且整理过程也非常繁琐。基于此，本实施例在获取到代码测试基础数据后，对其进行加工处理，按部门、小组、负责人、时间去统计成汇总数据，以便于用户及时、清晰地了解代码测试情况。

本步骤中提到的加工处理至少包括了按照部门、小组、负责人、时间为维度的统计处理，以及从基础数据到汇总数据的计算处理。该多种汇总数据包括表征代码的测试程度的数据，以及表征自动化测试案例的质量的数据，也就是说，该汇总数据有多种类型，每种类型可以对应一种用于表征代码的测试程度或者用于表征自动化测试案例的质量的指标。

在一些实施例中，该表征代码的测试程度的数据可以包括以下至少一种：全量代码覆盖率、增量代码覆盖率、增量自动化代码覆盖率、接口覆盖率；该表征自动化测试案例的质量的数据包括以下至少一种：自动化测试案例的通过率、自动化测试案例的活跃率。代码覆盖率是软件测试中的一种度量，描述程序中源代码被测试的比例和程度，而全量代码覆盖率指的是针对某时刻全部源码所对应的代码覆盖率，增量代码覆盖率指的是针对某段时间或版本所产生的增量代码所对应的代码覆盖率。另外，代码覆盖率通常表示测试案例通过手动测试和自动化测试所覆盖的代码百分比，而增量自动化代码覆盖率指的是通过自动化测试的测试案例覆盖增量代码的比例。接口覆盖率是指接口被自动化测试案例覆盖的比例，例如，项目中有10个接口，而其中8个接口被自动化测试案例覆盖，那么其接口覆盖率就是80％。自动化测试案例的通过率是指创建的自动化测试案例中执行通过的案例数占总案例数的比例，而自动化测试案例的活跃率是指创建的自动化测试案例中活跃案例(指最近一段时间内经常执行的案例)占总案例数的比例。

这几种数据都是比例型的数据，比的前项(即分子)和后项(即分母)可以由代码测试基础数据得到，例如，从AutoMan平台获取到的代码测试基础数据可以包括自动化测试案例总数和失败案例数，则通过这两种数据，可以计算出成功案例数作为比的前项，再结合自动化测试案例总数作为比的后项，从而统计出自动化测试案例的通过率。将代码测试基础数据统计成这几种汇总数据，可以使得项目测试人员直观地了解代码覆盖情况以及产线质量情况。当然，在其他实施例中，该汇总数据还可以包括其他类型的数据，本申请对此不作限制。

本实施例中，将代码测试基础数据加工处理成按部门、小组、负责人、时间等多个维度的汇总数据，是基于应用编号与负责人之间的对应关系来实现的。该对应关系是已有信息，通常来说，每个APPID对应的负责人信息是记录在系统中的，以起到跟进任务到每个负责人的作用。由于代码测试基础数据是按APPID为维度落库的，因此，根据APPID与负责人之间的对应关系，可以将代码测试基础数据转换成按照负责人进行分组的形式，并统计成以负责人为维度的汇总数据。而每个负责人隶属于哪个小组及哪个部门对于系统来说也是原本就有记录的信息，因此，可以进一步统计出以小组和部门为维度的汇总数据。另外，由于代码测试基础数据还按月份为维度落库，因此，可以统计出以时间，如月份、季度等为维度的汇总数据。例如，针对自动化测试案例的通过率，在获取到基础数据后，可以按照小组、月份去统计每个月的成功案例数，进而得到针对各小组按月汇总的自动化测试案例通过率。

在步骤103、根据用户的目标指标查询请求，输出目标指标对应的汇总数据，其中，所述目标指标包括从部门、小组、负责人、时间中指定的至少一个维度以及从所述汇总数据的类型中指定的至少一个类型。

本步骤中提到的目标指标包括从部门、小组、负责人、时间中指定的至少一个维度以及从汇总数据的类型中指定的至少一个类型。这里提到的汇总数据的类型可以具有不同的颗粒度，例如，在一些场景中，该汇总数据可以包括代码覆盖率、接口覆盖率、自动化测试案例的通过率及活跃率这四种类型，在另外一些场景中，该代码覆盖率又可以细分为全量代码覆盖率、增量代码覆盖率、增量自动化代码覆盖率这三种类型。该目标指标可以由汇总数据的维度及类型进行任意组合，例如，该目标指标可以是某个小组整体的代码覆盖率，也可以是某个小组下每个负责人负责的APPID的增量代码覆盖率，或者还可以是指定部门在指定月里的所有AB类应用的APPID的增量代码覆盖率以及没有触达的类的数量等等。在用户请求查询目标指标时，系统可以从已经统计好的汇总数据中提取出相应的数据进行输出展示，如此，使得产线测试人员可以直观快速地获知自己及所在团队负责的代码测试情况和产线质量情况，同时也便于管理人员进行规划管理。

在一些实施例中，本步骤中提到的输出目标指标对应的汇总数据可以包括：通过图的形式输出目标指标对应的汇总数据，并在所述图中显示所述目标指标对应的达标线。也就是说，系统可以将用户请求查询的汇总数据以图的形式进行展示，并设置达标线，这样，便于用户快速地了解达标情况。以目标指标是某个部门中各小组当月的增量代码覆盖率为例，假设该部门中有四个小组，这四个小组当月的增量代码覆盖率分别是86％、80％、93％、88％，系统通过柱形图展示该目标指标对应的汇总数据时，根据针对该目标指标的要求设定对应于85％的达标线，这样，管理人员可以根据该图，快速确定第二个小组未达标，其余小组达标，如此，提升管理效率。

另外，在实现时，考虑到部分目标指标之间具有递进关系，因此，系统在输出目标指标对应的汇总数据时，可以在输出界面中设置对应于其他汇总数据的跳转入口。例如，系统通过柱形图展示各小组当月的增量代码覆盖率的汇总数据时，用户可以在该柱形图中点击某个指定小组对应的区域，以使系统展示该指定小组中各组员当月的增量代码覆盖率的汇总数据。当然，在其他实施例中，系统如何展示汇总数据可以根据具体场景的需求进行相应设置，本申请对此不作限制。

本申请实施例，从多个渠道获取以应用编号及月份为维度的代码测试基础数据，再利用应用编号与负责人之间的对应关系，将代码测试基础数据进行加工处理成按照部门、小组、负责人、时间为维度的多种汇总数据，之后，在用户请求查询指定维度及指定类型的汇总数据时，输出对应的数据。这样，使得产线测试人员可以直观快速地获知自己及所在团队负责的代码测试情况和产线质量情况，同时也便于管理人员进行规划管理，提升管理效率。

为了对本申请的方案做更为详细的说明，接下来介绍一具体实施例：

在项目数量众多的企业中，产线测试人员往往不知道自己及所在团队负责的代码测试情况和产线质量情况，管理人员也难以对产线测试进度进行有效管理。基于此，本实施例提供一种测试数据展示平台，用以解决这一问题。该测试数据展示平台执行以下内容：

首先，创建一个JOB定时去跑数据，每天1到2次，所获取的基础数据与代码覆盖率、自动化案例的通过率、活跃率及接口覆盖率相关，其中，与代码覆盖率相关的基础数据从Libra平台获取，与自动化案例的通过率、活跃率及接口覆盖率相关的基础数据从AutoMan平台获取；

其次，将获取到的基础数据按月及APPID为维度来落库，为后续检查不同APPID按时间的趋势展示内容做准备；

然后，把数据库中的基础数据加工处理成按部门、小组、负责人、时间等多个维度的汇总数据，为后续月报数据展示做数据准备；

最后，针对展示页面开发接口，以使得产线测试人员及管理人员可以通过相应接口查看汇总数据，并且，设置报警处理逻辑，例如，根据预先设置的条件确定哪些小组的增量代码覆盖率没有达标，并将其展示在月报汇总图上，具体地，通过设置达标线，管理人员可以通过该达标线，快速发现哪些小组达标，哪些没有达标。

如图2所示，图2是本实施例提供的一种汇总数据的展示结果的示意图，该汇总数据是某个小组在指定月份中每个人负责的APPID的全量代码覆盖率的汇总数据。该展示结果不仅以表格的形式进行展示，还以图的形式进行展示。通过该展示结果，管理人员可以了解该小组中各人的代码测试情况，进而为调整管理策略提供了数据支持。

本实施例的这一测试数据展示平台，至少具有以下优点：提供每个月针对小组，部门，及具体到人的每个APPID的全量代码覆盖率情况，增量代码覆盖率情况，增量自动化代码覆盖率情况，展示每个小组的整体APPID的覆盖率情况及整体部门的覆盖率情况，便于管理人员的管理；提供按月汇总的每个小组的所有APPID的覆盖率情况，及每个APPID的历史月份趋势情况，以使产线测试人员可以直观快速地了解自己负责部分的代码覆盖率情况；提供按月汇总的自动化测试案例的通过率，活跃率及新增案例情况，使得管理人员可以及时了解产线质量情况。

与前述方法的实施例相对应，本申请还提供测试数据处理装置及其应用的终端的实施例：

如图3所示，图3是本申请实施例提供的一种测试数据处理装置的框图，所述装置包括：

获取模块31，用于从多个渠道获取以应用编号及月份为维度的代码测试基础数据；

汇总模块32，用于基于应用编号与负责人之间的对应关系，对所述代码测试基础数据进行加工处理，得到分别以部门、小组、负责人、时间为维度的多种汇总数据；所述多种汇总数据包括表征代码的测试程度的数据，以及表征自动化测试案例的质量的数据；

输出模块33，用于根据用户的目标指标查询请求，输出目标指标对应的汇总数据，其中，所述目标指标包括从部门、小组、负责人、时间中指定的至少一个维度以及从所述汇总数据的类型中指定的至少一个类型。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

本申请还提供一种电子设备，请参见图4，图4为本申请实施例提供的一种电子设备的结构框图。电子设备可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中，通信总线440用于实现这些组件直接的连接通信。其中，本申请实施例中电子设备的通信接口420用于与其他节点设备进行信令或数据的通信。处理器410可以是一种集成电路芯片，具有信号的处理能力。

上述的处理器410可以是通用处理器，包括中央处理器(CPU，Central ProcessingUnit)、网络处理器(NP，Network Processor)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。

存储器430可以是，但不限于，随机存取存储器(RAM，Random Access Memory)，只读存储器(ROM，Read Only Memory)，可编程只读存储器(PROM，Programmable Read-OnlyMemory)，可擦除只读存储器(EPROM，Erasable Programmable Read-Only Memory)，电可擦除只读存储器(EEPROM，Electric Erasable Programmable Read-Only Memory)等。存储器430中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器410执行时，电子设备可以执行上述图1方法实施例涉及的各个步骤。

可选地，电子设备还可以包括存储控制器、输入输出单元。

所述存储器430、存储控制器、处理器410、外设接口、输入输出单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线440实现电性连接。所述处理器410用于执行存储器430中存储的可执行模块，例如电子设备包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户创建任务以及为该任务创建启动可选时段或预设执行时间以实现用户与服务器的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

可以理解，图4所示的结构仅为示意，所述电子设备还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

本申请实施例还提供一种存储介质，所述存储介质上存储有指令，当所述指令在计算机上运行时，所述计算机程序被处理器执行时实现方法实施例所述的方法，为避免重复，此处不再赘述。

本申请还提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行方法实施例所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。