OTA系统自动化测试方法、装置、系统、设备、存储介质与流程

ota系统自动化测试方法、装置、系统、设备、存储介质
技术领域
1.本发明涉及ota系统测试领域，具体涉及一种ota系统自动化测试方法、系统、设备、存储介质。


背景技术：

2.随着物联网大数据时代的到来，汽车的"属性"正在发生变化,这种改变源于智能的崛起。汽车开始变得不再是一个简单的代步交通工具，它在不断变化，不断成长。车主会时不时地发现汽车给自己带来的小惊喜，它变得更加贴心、安全，甚至有一天它不再需要你的操控就能够自己行驶，从而进一步给驾驶员带来科技感、智能感的提升，而让这一切实现的就是ota(over-the-air technology，空中下载技术)。在国家大力发展新能源汽车的背景下，车载ota技术将在汽车电动化、智能化发展过程中加速普及，整车ota技术的发展是促进网联汽车快速迭代更新的必然趋势。汽车ota最早出现于2012年推出的某些车型上，其更新范围涉及自动驾驶、人机交互、动力、电池系统等领域,通过ota的方式完成钥匙卡漏洞续航里程提升提高最高速度、提升乘坐舒适度等功能或者漏洞的修复。ota带来汽车商业模式变革，ota不仅是车端的能力标配，更是车厂新盈利模式的运营标配。为保证ota系统的测试覆盖度并降低测试的耦合度，同时，提高车辆上市后，用户的体验感，技术的可靠性与稳定性必须在投放市场前得到充分的验证，包括关键控制器的部件验证以及系统的集成验证，而保证的唯一方式就是通过对ota方案进行完整的测试验证。
3.当前的ota的测试方案存在诸多的限制及瓶颈，首先，当前方案基本采用的都是非自动化测试验证方式，即：通过投入人力资源进行手动的测试验证，这样做补不仅带来大量的人力成本，且由于ota的链路测试均涉及下载和安装的，这两个步骤需要耗费大量的时间，从几十分钟到几个小时不等，如此带来的后果将是投入与产出不成正比。其次，当前ota的测试是通过手动或者半自动的测试来完成，其覆盖度低且结果的可靠性差，无法覆盖实车中的各种场景，一些特定的场景在手动测试或者半自动测试的环境下无法满足，测试过程中的许多测试参数精度需要通过精确的定时器来完成，无法通过手动或者半自动的方式来实现。


技术实现要素：

4.鉴于以上现有技术的缺点，本发明提供一种ota系统自动化测试方法，以改善现有ota测试需要手动测试验证，耗费大量的人力成本和时间，且无法覆盖实车中各种场景的技术问题。
5.为实现上述目的及其它相关目的，本发明提供一种ota系统自动化测试方法，包括：
6.获取ota系统升级场景信息，所述ota系统升级场景包括正常升级场景信息、异常升级场景信息；
7.根据所述ota系统升级场景信息，获得测试用例；
8.响应测试启动指令，根据ota升级对象获取对应的预先置于云服务器的升级包；
9.根据所述测试用例执行ota升级测试过程，获得测试日志；
10.根据所述测试日志生成所述ota升级测试过程报告，所述ota升级测试过程报告包括正向验证ota升级测试过程报告、逆向验证ota升级测试过程报告。
11.于本技术一实施例中，根据所述测试用例执行ota升级测试过程，获得测试日志，包括ota master单部件测试：
12.刷写前条件验证，所述条件验证包括正向条件验证、逆向条件验证；
13.刷写中处理过程，所述刷写中处理过程包括有诊断请求格式及序列验证、刷写条件反转、故障注入、刷写异常处理机制验证；
14.刷写后处理过程，所述刷写后处理过程包括有ota master状态确认、刷写成功后ecu(electronic control unit，电子控制单元)状态确认、休眠机制记录。
15.于本技术一实施例中，根据所述测试用例执行ota升级测试过程，获得测试日志，包括ota系统级测试：
16.刷写前条件验证，所述刷写前条件验证包括电源信息验证、车辆状态信息验证；
17.刷写中处理过程，所述刷写中处理过程包括有诊断交互过程监测、系统刷写条件反转、系统故障、系统电流消耗检测；
18.刷写后处理过程，所述刷写后处理过程包括有刷写时间记录、版本信息读取及收集、ecu状态确认、系统休眠机制记录。
19.于本技术一实施例中，根据所述测试用例执行ota升级测试过程，获得测试日志，包括：仿真系统执行所述ota升级测试过程，获得仿真系统测试日志；测试台架执行所述ota升级测试过程，获得台架测试日志。
20.于本技术一实施例中，响应测试启动指令，根据ota升级对象获取对应的预先置于云服务器的升级包，包括有：
21.获取预先置于云服务器的升级包前进行通信加密的安全验证；
22.获取预先置于云服务器的升级包时进行数据帧异常检测；
23.获取预先置于云服务器的升级包后进行升级包验签的安全验证；
24.本技术还提供一种ota系统自动化测试装置，场景信息获取模块，所述场景信息获取模块获取ota系统升级场景信息；测试用例获取模块，所述场景信息获取模块根据所述测试用例获取模块获取的ota系统升级场景信息，获得测试用例；升级包获取模块，所述升级包获取模块根据ota升级对象获取对应的升级包；测试执行模块，所述测试执行模块根据所述测试用例执行ota升级测试过程，获得测试日志，根据测试日志生成所述ota升级测试过程报告。
25.本技术还提供一种ota系统自动化测试系统，包括有：云端模块，所述云端模块内预置有不少于一种升级包；控制模块，所述控制模块根据测试用例控制仿真系统执行ota升级测试过程，获得测试日志，生成测试报告。
26.于本技术一实施例中，包括有测试台架，所述测试台架实现多种车型配置与多种场景进行组合形成多种环境，所述控制模块根据测试用例针对多种环境进行自动化测试。
27.本技术还提供一种电子设备，所述电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得
所述电子设备实现上述任一项所述的ota系统自动化测试方法。
28.本技术还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行上述任一项所述的ota系统自动化测试方法。
29.结合现有技术，本发明的有益效果在于：
30.本技术方案能够充分地验证整个ota机制，支持重复验证而且不存在实车测试时将控制器损坏、无问题数据的风险。本技术能够解决从不同的维度对ota的设计方案进行验证，包括ota正向的流程验证、先决条件的验证、人机交互的验证、鲁棒性的验证、ota模式下的车辆功能的验证等，实现全功能及全场景的覆盖测试。
31.本技术自动分析ota过程数据，判断功能正确性、协议一致性、数据加解密、数据校验、业务流程、算法等的实现是否满足系统设计规范，聚焦ota链路的通道测试，覆盖实车上的各种场景。
附图说明
32.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
33.图1为现有技术ota系统测试的示例性示意图；
34.图2为本技术一示例性实施例示出的ota系统自动化测试方法示意图；
35.图3为本技术图2中步骤s240的ota master单部件测试的示例性示意图；
36.图4为本技术图2中步骤s240的ota系统级测试的示例性示意图；
37.图5为本技术图2中步骤s230的示例性示意图；
38.图6为一种示例性ota测试系统框架图；
39.图7为一种测试环境配置示意图；
40.图8为一示例性测试元素创建示意图；
41.图9为一示例性数据监控界面示意图，
42.图10示出了适于用来实现本技术实施例的计算机系统的结构示意图。
具体实施方式
43.以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其它优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。还应当理解，本发明实施例中使用的术语是为了描述特定的具体实施方案，而不是为了限制本发明的保护范围。下列实施例中未注明具体条件的试验方法，通常按照常规条件，或者按照各制造商所建议的条件。
44.当实施例给出数值范围时，应理解，除非本发明另有说明，每个数值范围的两个端点以及两个端点之间任何一个数值均可选用。除非另外定义，本发明中使用的所有技术和科学术语与本技术领域的技术人员对现有技术的掌握及本发明的记载，还可以使用与本发
明实施例中所述的方法、设备、材料相似或等同的现有技术的任何方法、设备和材料来实现本发明。
45.须知，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。
46.ota是指空中下载技术，汽车ota可以通过移动通信的接口实现对软件的远程管理。早期时，ota技术广泛应用于智能手机的软件的升级，后来汽车ota技术在2012年被推出，促进了汽车行业的发展。
47.汽车ota的升级类似于电脑视窗系统的升级或者手机系统的升级，每一次的升级都可以改进、修补漏洞或者获得更多的功能、性能以及视觉效果的提升。自从汽车ota技术出现以后，4s店在汽车升级的环节里就不再是必选题。
48.现在很多的车企都很重视汽车ota技术，现在的汽车ota技术还运用于各种地图、运用程序以及娱乐信息系统等地方，甚至还发展到了电子控制单元。但汽车行业不像其他行业，汽车需要有一定的安全性，如果ota技术出现问题就很有可能导致严重的安全事故，技术的可靠性与稳定性必须在投放市场前得到充分的验证，包括关键控制器的部件验证以及系统的集成验证，而保证的唯一方式就是通过对ota方案进行完整的测试验证。
49.请参考图1，图1现有技术ota系统测试的示例性示意图。
50.汽车ota升级是通过无线信号传输获取升级包后，对汽车的娱乐或电子控制单元进行修改升级。现有的ota测试方案存在诸多的限制和瓶颈，当前方案基本采用的都是非自动化测试验证方式，即：通过投入人力资源进行手动的测试验证，这样做补不仅带来大量的人力成本，且由于ota的链路测试均涉及下载和安装的，这两个步骤需要耗费大量的时间，从几十分钟到几个小时不等，如此带来的后果将是投入与产出不成正比。其次，当前ota的测试是通过手动或者半自动的测试来完成，其覆盖度低且结果的可靠性差，无法覆盖实车中的各种场景，一些特定的场景在手动测试或者半自动测试的环境下无法满足，只有通过仿真的方式进行自动化的测试来实现，另外，测试过程中的许多测试参数精度需要通过精确的定时器来完成，无法通过手动或者半自动的方式来实现。
51.本技术能够解决从不同的维度对ota的设计方案进行验证，包括ota正向的流程验证、先决条件的验证、人机交互的验证、鲁棒性的验证、ota模式下的车辆功能的验证等，真正实现全功能及全场景的覆盖测试。本技术聚焦ota链路的通道测试，针对链路过程中的各种场景，通过建立仿真的节点配合实车真实的节点模式，搭建一套适用通用的测试环境，能够覆盖实车上的各种场景。
52.请参考图2，图2为本技术一示例性实施例示出的ota系统自动化测试方法示意图，具体包括的步骤如下：
53.步骤s210，获取ota系统升级场景信息，所述ota系统升级场景包括正常升级场景信息、异常升级场景信息。
54.本技术不仅仅实现ota系统正向升级的测试，还实现ota系统反向验证。正常升级场景信息即为ota系统升级正向升级按照预定方式升级完成，中间无其他故障打断。异常升级场景信息包括升级中断的各种场景，如网络断开、升级包安装过程中故障等等场景信息，异常升级场景信息用于反向验证ota系统升级出现问题时，ota升级系统是否按照既定程序
进行处理，如网络断开重连后，安装包是否正常继续下载；升级包安装过程中断后，控制器是否自动回滚等，是否符合预期。通过构建不同的异常升级场景信息，可以实现在ota系统层级的测试。
55.步骤s220，根据所述ota系统升级场景信息，获得测试用例。
56.根据ota升级场景信息后，可以确定不同的ota升级场景测试的内容，确定测试用例。本技术一实施例中，对于实现的整体框架，以test center软件作主控软件。
57.步骤s230，响应测试启动指令，根据ota升级对象获取对应的预先置于云服务器的升级包。
58.车辆在进行ota升级时，首先要从云服务器下载对应的升级包，测试系统根据ota升级对象从云服务器中下载对应的升级包，下载前后需要对升级包进行安全验证，以保证车辆数据以及升级包数据的安全性，避免车辆用户或车企受到损失。
59.请参考图5，图5为本技术图2中步骤s230的示例性示意图，介绍了一示例性升级包的安全验证过程。
60.步骤s510，获取预先置于云服务器的升级包前进行通信加密的安全验证。
61.获取升级包前需要首先对通信加密进行安全验证，以保证在获取升级包的过程中通信是安全的。
62.步骤s520，获取预先置于云服务器的升级包时进行数据帧异常检测。
63.下载升级包的过程中需要对数据帧正常检测、异常检测、id检测等，以保证获取过程中的数据安全。
64.步骤s530，获取预先置于云服务器的升级包后进行升级包验签的安全验证。
65.升级包获取后需要进行验签的安全验证，以确保获得的升级包为当前升级对象所对应的升级包。
66.请继续参阅图2，步骤s240，根据所述测试用例执行ota升级测试过程，获得测试日志。
67.本技术的ota升级测试实现灵活的节点配置，激活ecu仿真节点可实现仿真测试，屏蔽仿真节点加入真实ecu实现台架测试，既可以提高测试的效率，又可以实现测试的实车验证。在本技术的一实施例中，实车验证通过设置测试台架，从而设置实车环境，测试台架可以实现多个车型配置与多种场景进行组合而成的多种环境，针对该多种环境再进行自动化测试。
68.请参阅图3，图3为本技术图2中步骤s240的ota master单部件测试的示例性示意图。本技术的ota升级测试，可以实现ota master单部件测试，具体介绍如下：
69.步骤s310，刷写前条件验证，所述条件验证包括正向条件验证、逆向条件验证。
70.在刷写前，需要首先确认ota master是否符合升级的要求，满足升级条件后在进行升级，未满足升级条件时保留升级提醒。
71.步骤s320，刷写中处理过程，所述刷写中处理过程包括有诊断请求格式及序列验证、刷写条件反转、故障注入、刷写异常处理机制验证。
72.刷写过程中，需要根据测试要求进行不同处理，处理过程包括但不限于诊断请求格式及序列验证、刷写条件反转、故障注入、刷写异常处理机制验证。
73.步骤s330，刷写后处理过程，所述刷写后处理过程包括有ota master状态确认、刷
写成功后ecu状态确认、休眠机制记录。
74.请参阅图4，图4本技术图2中步骤s240的ota系统级测试的示例性示意图，在本技术一实施例中，ota升级测试可以实现ota系统级测试，介绍如下：
75.步骤s410，刷写前条件验证，所述刷写前条件验证包括电源信息验证、车辆状态信息验证。
76.刷写前需要首先对车辆的各项信息进行验证，以保证升级过程稳定，如电源信息是否满足升级过程中的电量消耗，车辆状态是否处于车门关闭、尾箱关闭、挂p挡等条件下，确认条件满足预设要求后进行刷写升级。
77.步骤s420，刷写中处理过程，所述刷写中处理过程包括有诊断交互过程监测、系统刷写条件反转、系统故障、系统电流消耗检测。
78.刷写需要根据不同的测试要求进行不同的测试，同时需要记录测试过程中ota链路的各项操作，以便于生成刷写过程测试日志，满足测试需要。
79.步骤s430，刷写后处理过程，所述刷写后处理过程包括有刷写时间记录、版本信息读取及收集、ecu状态确认、系统休眠机制记录。
80.刷写完成后对各项信息进行收集，确认升级完成，便于生成测试日志。
81.请继续参阅图2，步骤s250，根据所述测试日志生成所述ota升级测试过程报告，所述ota升级测试过程报告包括正向验证ota升级测试过程报告、逆向验证ota升级测试过程报告。
82.本技术一实施例中，请参阅图6，图6示出了一种示例性ota测试系统框架图，对于实现的整体框架，以test center软件作主控软件为例。测试管理软件以canoe为例，针对测试其提供环境配置、元素创建、测试监控、用例管理等功能在canoe软件中，可直接操作vt板卡和程控bob实现对电源短路、对地短路、开路；可进行故障注入管脚进行定义和配置，由软件自动读取并生成操作界面；故障注入可以实现手动控制及精确定时控制的自动故障注入；可对需要配置的通道，进行方便快捷进行设置和激活
83.软件功能可对系统界面、模型、硬件进行统一管理和配置；实现模型与硬件资源的映射、保存、修改；可以实时操作、监控模型变量(canoe graphical模块)；可记录实时数据(asc、csv等格式)；可根据用户需求自主创建人机交互界面(canoepanel)；能够集成can、canfd、lin、ethernet等通讯数据库，并对报文的收发进行配置，支持导入*.dbc、*.arxml、*.ldf等多种格式的database文件。
84.测试环境配置硬件配置，请参阅图7，图7示出了一种测试环境配置，canoe提供图形化的硬件配置功能，实现对vt各板卡的属性配置及板卡控制；
85.网络环境配置：创建网络通信和网络管理环境(osek及autosar)，配置网络中需检测和记录报文及数据，如报文时间间隔，预定义的信息等，并可定义针对特定事件的动作及交互信息。
86.请参阅图8，图8示出了一示例性测试元素创建，测试元素创建建立测试序列中所需输入及输出数据数据与硬件io端口的映射关系及数值转化关系，提升测试用例创建的效率。
87.人机交互canoe提供图形化的硬件配置功能，实现对vt各板卡的属性配置及板卡控制，可实现传感器信号仿真，将物理量信号(如转速)转化为电信号输出到硬件系统，具有
手动控制功能。可实现执行器信号采集，采集控制器发出的执行器控制信号，用于模型计算及测试结果判断等。通过canoe panel界面设计可程控电源开关控制、电压控制、最大电流限制，以及模拟kl30、kl15电源测试数据监控canoe提供panel功能，可实现数据监测及测试参数修改，针对车身控制器监控的功能包括：
88.控制信号的仿真，如电源上电/电压控制、车速、发动机转速等参数设置；状态监控，通过报文或硬线监控被测控制器的状态反馈，如电流消耗、故障状态等；同步跟踪和记录所配置的报文及数据。
89.请参与图9，图9示出了一示例性数据监控界面，测试管理，canoe-tfs可实现测试用例管理，用于实现自动/半自动测试序列的组织、用例的运行控制和报告生成(html)：选择需执行的测试用例；显示测试用例执行状态；运行或停止测试用例的执行。
90.使用canoe-tfs的test setup模块构建宏观上测试用例管理和组织的框架，通过文件目录管理和组织车型平台(platform)、测试范畴(system或node)、测试内容及测试对象(dut)等层次化结构，对测试工程所包含细节及测试实施管理基于tester实现。
91.基于adb和opencv的安卓设备程控方案。
92.通过canoe软件，发送adb指令对安卓车机进行程控，获取图片等信息，并通过canoe软件调用opencv库函数，实现对界面字符的处理。
93.opencv全称open source computer vision library，是开源计算机视觉库。它由一系列c函数和少量c 类所组成，实现图像处理和计算机视觉方面的很多通用算法，例如特征检测与跟踪、运动分析、目标分割与识别以及3d重建等。opencv作为基于c/c 语言编写的跨平台开源软件，可以运行在linux、windows、android和mac os操作系统上，同时提供了python、ruby、matlab等语言的接口，实现了图像处理和计算机视觉方面的很多通用算法。opencv的cv模块包含基本的图像处理函数和高级的计算机视觉算法。ml是机器学习库，包含一些基于统计的分类和聚类工具。highgui包含图像和视频输入/输出的函数。cxcore包含opencv的一些基本数据结构和相关函数。在处理计算机视觉中一些很复杂的问题时，可以利用opencv提供的高层函数有效地解决这些问题。opencv有一个强大的函数库，它可以提供基本函数为大多数计算机视觉问题创建一个完整解决方案。
94.基于opencv实现车机屏幕状态监控通过canoe软件，发送adb指令获取娱乐屏中的图片信息，并通过canoe软件调用opencv库函数，实现对界面字符的处理，并结合python实现ui的自动化识别
95.本技术一实施例示出ota系统自动化测试装置，包括场景信息获取模块，所述场景信息获取模块获取ota系统升级场景信息；测试用例获取模块，所述场景信息获取模块根据所述测试用例获取模块获取的ota系统升级场景信息，获得测试用例；升级包获取模块，所述升级包获取模块根据ota升级对象获取对应的升级包；测试执行模块，所述测试执行模块根据所述测试用例执行ota升级测试过程，获得测试日志，根据测试日志生成所述ota升级测试过程报告。
96.本技术一实施例示出了ota系统自动化测试系统，包括有：云端模块，所述云端模块内预置有不少于一种升级包；控制模块，所述控制模块根据测试用例控制仿真系统执行ota升级测试过程，获得测试日志，生成测试报告。包括有测试台架，所述测试台架实现多种车型配置与多种场景进行组合形成多种环境，所述控制模块根据测试用例针对多种环境进
行自动化测试。
97.本技术还提供一种电子设备，所述电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述任一项所述的ota系统自动化测试方法。
98.本技术还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序被计算机的处理器执行时，使计算机执行上述任一项所述的ota系统自动化测试方法。
99.请参考图10，图10示出了适于用来实现本技术实施例的计算机系统的结构示意图。
100.计算机系统1000包括中央处理单元(central processing unit，cpu)1001，其可以根据存储在只读存储器(read-only memory，rom)1002中的程序或者从储存部分1008加载到随机访问存储器(random access memory，ram)1003中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在ram 1003中，还存储有系统操作所需的各种程序和数据。cpu 1001、rom 1002以及ram 1003通过总线1004彼此相连。输入/输出(input/output，i/o)接口1005也连接至总线1004。
101.以下部件连接至i/o接口1005：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(cathode ray tube，crt)、液晶显示器(liquid crystal display，lcd)等以及扬声器等的输出部分1007；包括硬盘等的储存部分1008；以及包括诸如lan(local area network，局域网)卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至i/o接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入储存部分1008。
102.特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本技术的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被中央处理单元(cpu)1001执行时，执行本技术的系统中限定的各种功能。
103.需要说明的是，本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。
104.本技术能够充分地验证整个ota机制，支持重复验证而且不存在实车测试时将控制器损坏、无问题数据的风险；实现底层链路及场景模拟测试，更加轻量化，具备灵活性与扩展性。自动分析ota过程数据，判断功能正确性、协议一致性、数据加解密、数据校验、业务流程、算法等的实现是否满足系统设计规范；灵活的节点配置，激活ecu仿真节点可实现仿真测试，屏蔽仿真节点加入真实ecu实现台架测试；控制测试条件构造异常场景，在整个流程中不同位置设置断点条件验证ota处理逻辑。所以，本发明有效克服了现有技术中的一些实际问题从而有很高的利用价值和使用意义。上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发
明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。