CN112698852B

CN112698852B - App灰度升级方法、装置、终端设备及计算机可读存储介质

Info

Publication number: CN112698852B
Application number: CN202011375142.8A
Authority: CN
Inventors: 赵鹏松
Original assignee: Xiamen Yealink Network Technology Co Ltd
Current assignee: Xiamen Yealink Network Technology Co Ltd
Priority date: 2020-11-30
Filing date: 2020-11-30
Publication date: 2022-09-20
Anticipated expiration: 2040-11-30
Also published as: CN112698852A

Abstract

本发明提供一种APP灰度升级方法、装置、终端设备及计算机可读存储介质，所述方法包括，经第一通道将APP软件的第一测试版本推送至第一用户端；接收第一用户端回送的第一测试数据，当第一测试数据与第一预设数据匹配时，经第二通道将APP软件的第二测试版本推送至第二用户端；接收第二用户端回送的第二测试数据，当第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户。本发明提供的APP灰度升级方法，通过对用户的预先定义，走不同的升级通道，进而完成Alpha版本及Beta版本的灰度试用；通过管理通道推送配置文件，实现APP终端的某项功能开启或者关闭，减少了终端用户版本频繁升级带来的体验不佳，提高了APP灰度升级的效率。

Description

APP灰度升级方法、装置、终端设备及计算机可读存储介质

技术领域

本发明涉及软件升级技术领域，尤其涉及一种APP灰度升级方法、装置、终端设备及计算机可读存储介质。

背景技术

随着移动端APP软件的大量使用，对APP的升级方法越来越多，其中最为常见的是采用灰度升级的方式，即让少量的客户进行预先升级，验证无问题之后，再进行全网版本的升级，以保证线上服务不出现批量事故。现有技术在进行灰度升级时，往往是在APP软件先发布出去之后才能收集到用户信息，且针对这些用户的下载和升级权限没有进行单独管理，缺乏个性化；同时针对APP的版本升级，现有技术更是没有明确给出灰度升级的规则，在每一次开启或关闭APP终端的某项功能时，只能通过对终端用户版本进行再一次升级才得以实现，升级效率低下，用户体验不佳，且易出现全网批量事故。

发明内容

本发明的目的在于提供一种APP灰度升级方法、装置、终端设备及计算机可读存储介质，该方法在终端APP升级的时候，通过对用户的预先定义，走不同的升级通道，进而完成Alpha版本及Beta版本的灰度试用，规则明确且管理具有针对性；通过管理通道推送配置文件，实现APP终端的某项功能开启或者关闭，减少了终端用户版本频繁升级带来的体验不佳，提高了APP灰度升级的效率，避免全网批量事故。

为了克服上述现有技术中的缺陷，本发明实施例提供了一种APP灰度升级方法，包括：

经第一通道将APP软件的第一测试版本推送至第一用户端；

接收所述第一用户端回送的第一测试数据，当所述第一测试数据与第一预设数据匹配时，经第二通道将APP软件的第二测试版本推送至第二用户端；

接收所述第二用户端回送的第二测试数据，当所述第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户。

进一步地，所述第一测试版本为Alpha版本，所述第二测试版本为Beta版本，所述商业版本为RC商业版本。

进一步地，所述第一测试版本、所述第二测试版本及所述商业版本两两之间不能互相升级。

进一步地，所述APP灰度升级方法，还包括：

当所述第一测试数据与第一预设数据不匹配时，将所述第一测试版本更新后再推送至所述第一用户端，直至所述第一测试数据与所述第一预设数据匹配；及，

当所述第二测试数据与第二预设数据不匹配时，将所述第二测试版本更新后再推送至所述第二用户端，直至所述第二测试数据与所述第二预设数据匹配。

进一步地，所述将所述第一测试版本更新后再推送至所述第一用户端，包括：将所述第一测试版本的升级后的新版本推送至所述第一用户端，或将所述第一测试版本对应的目标版本的配置文件推送至所述第一用户端；

所述将所述第二测试版本更新后再推送至所述第二用户端，包括：将所述第二测试版本的升级后的新版本推送至所述第二用户端，或将所述第二测试版本对应的目标版本的配置文件推送至所述第二用户端。

进一步地，所述将所述第一测试版本的升级后的新版本推送至所述第一用户端，包括：将所述第一测试版本的升级后的新版本对应的URL地址，或包含所述URL地址的二维码推送至所述第一用户端；

所述将所述第二测试版本的升级后的新版本推送至所述第二用户端，包括：将所述第二测试版本的升级后的新版本对应的URL地址，或包含所述URL地址的二维码推送至所述第二用户端。

本发明实施例还提供了一种APP灰度升级装置，包括：

第一通道测试模块，用于经第一通道将APP软件的第一测试版本推送至第一用户端；

第二通道测试模块，用于接收所述第一用户端回送的第一测试数据，当所述第一测试数据与第一预设数据匹配时，经第二通道将APP软件的第二测试版本推送至第二用户端；

商业版本发布模块，用于接收所述第二用户端回送的第二测试数据，当所述第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户。

进一步地，APP灰度升级装置，还包括：

日志管理模块，用于接收用户端测试所述APP软件不同版本时反馈的日志信息；

对象存储服务模块，用于存储所述APP软件不同版本的安装包。

本发明实施例还提供了一种终端设备，包括：

一个或多个处理器；

存储器，与所述处理器耦接，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上任一项所述的APP灰度升级方法。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上任一项所述的APP灰度升级方法。

相对于现有技术，本发明至少存在如下有益效果：

本发明实施例提供的APP灰度升级方法在对终端APP进行升级时，通过对用户的预先定义，走不同的升级通道，进而完成Alpha版本及Beta版本的灰度试用，用户管理具有针对性且规则明确；管理员通过升级通道推送配置文件，实现APP终端的某项功能开启或者关闭，减少了终端用户版本频繁升级带来的体验不佳，提高了APP灰度升级的效率，避免全网批量事故。

附图说明

图1是本发明某一实施例提供的APP灰度升级方法的流程示意图；

图2是本发明某一实施例提供的不同用户与各个通道版本之间的对应关系图；

图3是本发明某一实施例提供的APP灰度升级方法的步骤程序框图；

图4是本发明某一实施例提供的终端用户APP主动点击更新和升级的组件交互图；

图5是本发明某一实施例提供的服务器推送版本到终端用户的组件交互图；

图6是本发明又一实施例提供的APP灰度升级装置的结构示意图；

图7是本发明又一实施例提供的APP终端设备管理结构示意图。

具体实施方式

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

应当理解，文中所使用的步骤编号仅是为了方便描述，不对作为对步骤执行先后顺序的限定。

应当理解，在本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

第一方面：

请参阅图1，本发明实施例提供了一种APP灰度升级方法，包括：

S10、经第一通道将APP软件的第一测试版本推送至第一用户端；

S20、接收所述第一用户端回送的第一测试数据，当所述第一测试数据与第一预设数据匹配时，经第二通道将APP软件的第二测试版本推送至第二用户端；

S30、接收所述第二用户端回送的第二测试数据，当所述第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户。

在本发明实施例中，需要说明的是，第一测试版本为Alpha版本，第二测试版本为Beta版本，商业版本为RC商业版本。其中，Alpha版本是整个软件开发周期中的第一个主要阶段，该版本通常会送交到开发软件的组织或社群中的各个软件测试者，用作内部测试，该版本的特点是存在很多bug，性能不稳定，需要不断的添加新功能。Beta版本作为软件开发周期的第二个阶段，相对于Alpha版本来说，Beta版本的bug有所减少，且性能会稳定一些，同样需要经过不断地测试，不断添加新功能以提高其性能。RC商业版本在经过多个Beta版本的测试后逐渐稳定，在该版本的基础上几乎不会再另外添加新的功能，修复完bug之后即可作为正式的商业版本进行全网发布。

请参阅图2，该图为本实施例提供的不同用户与各个通道的版本之间的对应关系图，步骤S10-S30中所提到的第一通道、第二通道及第三通道分别指的是该图中的试用通道、快速通道和稳定通道；其中，试用通道主要给试用用户试用，即步骤S10中所述的第一用户端，此类客户可以是项目组内的开发人员，测试人员，甚至是自己公司用户，抢先体验终端版本的最新功能，Alpha版本的推送，默认走该通道；快速通道主要给合作伙伴测试试用，即步骤S20中所述的第二用户端，所述合作伙伴可以是部分合作代理商，协作测试的企业用户，Beta版本的推送，默认走该通道，当然也可以向试用通道推送该版本。而稳定通道主要是给商用客户使用，是最终的稳定版本，可以全网客户使用。商业版本的推送，默认走该通道，也可以向快速通道，试用通道推送版本。用户群体的划分和在默认的情况下各自升级到对应的版本，这样就保证了各个用户群体，在默认的情况下，各自优先下载到的版本。如表1所示，Alpha版本只能走试用通道、，Beta版本可以有试用通道和快速通道两种选择，而RC商业版本则可以经过三条通道中的任意一条推送给全网用户。

APP版本	试用通道	快速通道	稳定通道
				Alpha	√	X	X
Beta	√	√	X
				RC(商业版本)	√	√	√

表1

在实施本发明实施例的方法时，首先，管理员会经过试用通道将Alpha版本推送至内测用户的APP，然后等待用户测试的结果，等接收到用户回送的测试结果时，会和实现设置的期望值作比较，判断测试结果是否达到预期，只有在达到预期值时，才会经快速通道将APP软件的Beta版本推送至合作伙伴用户的APP，然后等待合作伙伴用户测试的结果，同样地，当接收到的用户对Beta版本的测试结果能够达到期望值时，就可以经稳定通道推送APP软件的商业版本至所有用户，即全网推送稳定的RC商业版本。

本发明实施例提供的APP灰度通过对用户的预先定义，走不同的升级通道，进而完成Alpha版本及Beta版本的灰度试用，用户管理具有针对性且规则明确；通过升级通道推送配置文件，实现APP终端的某项功能开启或者关闭，减少了终端用户版本频繁升级带来的体验不佳，提高了APP灰度升级的效率，避免全网批量事故。

第二方面：

请参阅图3，本发明某一实施例提供了APP灰度升级方法的步骤程序框图；具体步骤如下：

(1)APP终端软件准备好之后，开始进行选择试用客户升级版本，一般情况下厂商先发布Alpha版本，把该版本经过试用通道推送出去，在试用通道内的用户，会接受到该版本更新，终端用户升级该版本，进行功能相关验证，是否达到预期指标。不在试用通道内的用户，收不到此版本。

(2)如果试用的质量未达到预期，那么后台管理员再更新Alpha版本，在试用通道再发布Alpha的更新版本，该通道内的试用用户继续试用，直到满足试用的预期指标。

(3)当Alpha版本达到试用指标时，那么厂商发布Beta版本就会推送到快速通道，在快速通道内的用户，会接收到该版本更新，对应的终端用户升级该版本，进行功能相关验证，看是否达到预期指标。不在快速通道内的用户，收不到此Beta版本，但需要说明的是，如果管理员向试用通道推送此版本，那么试用通道用户也可以收到此版本；

(4)如果Beta版本在快速通道内试用验证未达到预期指标，则再更新发布Beta版本，直到满足预期指标；

(5)当Beta版本达到试用指标时，那么厂商发布商业版本，灰度升级结束，可以全网推送商业版本。

此外，在本实施例中，还需要指出的是，关于一开始如何定义某用户在哪个通道，本实施例主要是通过给不同的用户二维码或者下载的URL连接来实现，如果一开始用户拿到的是Alpha版本，则默认在试用通道，拿到的是Beta版本，则默认在快速通道，拿到的是RC商业版本，默认在稳定通道。在厂商发布软件或者选择内测的时候，可以自行定义给客户什么样子的版本，可以根据客户的业务需求灵活设置。

至于版本如何升级的问题，首选需要明确，APP软件的版本一般是X.X.X-Alpha(Alpha后缀表示是Alpha版本)，X.X.X-Beta(Beta后缀表示是Beta版本)，X.X.X(没有后缀表示RC商业版本)；不同版本的升级逻辑如下：X越大表示软件版本越新，第一位X优先级>第二位X优先级>第三位X优先级。当X的位数都一样的时候，优先级的顺序为：RC(结尾没有后缀)>Beta>Alpha。

为了帮助理解本发明实施例中所述的升级逻辑，表2给出了用户升级版本号，表3给出了六次版本的升级情况，下面将结合表2-3进行说明：

用户名称	版本号
		A	1.0.1-Alpha
B	1.0.1-Beta
		C	1.0.1

表2

表3

例如有ABC三个用户，他们当前使用的版本如表2所示。若这个时候项目管理第一次向试用通道发布了1.0.2-Alpha版本，第二次向快速通道发布了1.0.2-beta版本，第三次向试用和快速通道发布了1.0.3-Beta版本，第四次向稳定通道发布了1.0.3版本，第五次向全网所有通道发布了1.0.4版本，第六次向向试用通道发布了1.0.5-Alpha版本，那么ABC用户升级版本如表3所示：

第一次向试用通道发布了1.0.2-Alpha版本，只有A用户可以接收到更新的指令，而B、C用户收不到更新指令，因此A用户更新到1.0.2-Alpha版本，B、C保持原版本不变；

第二次向快速通道发布了1.0.2-beta版本，只有B用户可以接收到更新的指令，而A、C用户收不到更新指令，因此B用户更新到1.0.2-beta版本，A、C保持不变；

第三次向试用和快速通道发布了1.0.3-Beta版本,A、B用户可以接收到更新的指令，而C用户收不到更新指令，因此A、B用户更新到1.0.3-Beta版本，C保持不变；

第四次向稳定通道发布了1.0.3版本,只有C用户可以接收到更新的指令，而A、B用户收不到更新指令，因此C用户更新到1.0.3版本，A、B保持不变；

第五次向全网所有通道发布了1.0.4版本，A、B、C用户均可以接收到更新的指令，全部更新为1.0.4版本；

第六次向试用通道发布了1.0.5-Alpha版本，只有A用户可以接收到更新的指令，而B、C用户收不到更新指令，因此A用户更新到1.0.5-Alpha版本，B、C保持原版本不变。

第三方面：

当系统部署之后，有两种场景，一个是终端用户在APP手动点击版本升级，另外一个是管理员发布了APP软件版本，或者将一个配置文件推送到终端更新，管理员把版本推送到APP终端用户，提醒用户APP有新版本更新。

请参阅图4，本发明某一实施例提供了终端用户在APP手动点击版本升级相应服务的组件交互图，终端用户主动点击APP进行升级的操作如下：

(1)用户在APP软件点击更新，发送Http请求给接入服务；

(2)接入服务判断是来自哪个通道，连接到对应的通道管理服务，默认情况下该终端的报上来的自身是Alpha版本的话，就是走的试用通道，如果是Beta版本，则走的是快速通道；

(3)通道管理服务向数据库查询，有没有新版本；

(4)如果有新版本，则返回告诉通道管理，对应的版本号，和下载URL连接，如果没有新版本，则通知通道管理，此通道没有新版本；

(5)通道管理服务告知终端新APP版本的下载地址；

(6)用户终端向OSS存储服务，下载APP软件包。

第四方面：

请参阅图5，本发明某一实施例提供了服务器推送APP版本更新相应服务的组件交互图，其中，服务器推送APP版本更新说明如下：管理员打包新版本版本之后，把APP软件包放到OSS存储服务上，并通过推送服务，把版本下发到各个通道，或者管理员编写一个配置文件，通过推送服务推给终端APP，终端APP接收到配置文件之后，本地APP进行配置更新(例如当前对服务的音频Codec-A类型进行了优化，为了避免全网事故，这个时候只需要通过配置文件推送，让快速和稳定通道客户终端APP关闭这个类型的音频Codec-A，试用通道用户开启，进行优先试用，这样就无需厂商再发布一个APP软件版本，让用户更新升级版本。此外，正常情况下APP软件支持音频Codec的种类有很多种，服务器支持也有很种，两个只要有交集，就能协商出一个大家都有的Codec(一般选择第一个，主要看配置排序或者协商优先级策略)，这样就能够播放音视频了。

进一步地，本发明实施例中，服务器推送APP版本提醒用户更新的操作如下：

(1)推送服务把版本下发到通道管理服务，或者一个配置文件(二者的原理一样)；

(2)通道管理服务根据管理员要求，要下发到哪些通道，是试用通道，快速通道，还是稳定通道，通道管理选择对应的通道，把版本推送到接入服务；

(3)接入服务通知终端用户有新的APP软件版本更新，提示信息推送到终端用户上，告知终端新APP版本的下载地址；

(4)终端用户点击升级，通过通道服务，询问该新的APP版本下载地址，不需要在走接入服务(少了走了一个服务，效率更高)；

(5)通道服务向数据库查询该新版本号的下载地址；

(6)数据库返回下载地址，告诉通道服务；

(7)通道服务告诉终端用户该APP版本的下载地址链接；

(8)用户终端向OSS存储服务，下载APP软件包。

第五方面：

本发明的某一个实施例中，对于版本升级优先级定义的问题，可以通过强制Alpha，Beta，RC版本之间不能互相升级进行管控，即Alpha版本只能在Alpha之间升级，不能升级到Beta，Beta版本亦是如此。采用这种强制管控，能够有效防止内部版本流到市场上，以免造成商业机密的泄露。

第六方面：

请参阅图6，本发明实施例还提供了一种APP灰度升级装置100，包括：

第一通道测试模块01，用于经第一通道将APP软件的第一测试版本推送至第一用户端；

第二通道测试模块02，用于接收所述第一用户端回送的第一测试数据，当所述第一测试数据与第一预设数据匹配时，经第二通道将APP软件的第二测试版本推送至第二用户端；

商业版本发布模块03，用于接收所述第二用户端回送的第二测试数据，当所述第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户。

需要说明的是，第一通道、第二通道及第三通道分别指的是试用通道、快速通道和稳定通道；其中，试用通道主要给试用用户试用，此类客户可以是项目组内的开发人员，测试人员，甚至是自己公司用户，抢先体验终端版本的最新功能，Alpha版本的推送，默认走该通道；快速通道主要给合作伙伴测试试用，所述合作伙伴可以是部分合作代理商，协作测试的企业用户，Beta版本的推送，默认走该通道，当然也可以向试用通道推送该版本。而稳定通道主要是给商用客户使用，是最终的稳定版本，可以全网客户使用。商业版本的推送，默认走该通道，也可以向快速通道，试用通道推送版本。用户群体的划分和在默认的情况下各自升级到对应的版本，这样就保证了各个用户群体，在默认的情况下，各自优先下载到的版本。

在本发明实施例中，首先，管理员会经过试用通道将Alpha版本推送至内测用户的APP，然后等待用户测试的结果，等接收到用户回送的测试结果时，会和实现设置的期望值作比较，判断测试结果是否达到预期，只有在达到预期值时，才会经快速通道将APP软件的Beta版本推送至合作伙伴用户的APP，然后等待合作伙伴用户测试的结果，同样地，当接收到的用户对Beta版本的测试结果能够达到期望值时，就可以经稳定通道推送APP软件的商业版本至所有用户，即全网推送稳定的RC商业版本。

请参阅图7，本发明某一实施例还提供了一种APP终端设备管理对应的功能模块图，包括管理中心模块、日志管理模块和OSS模块；

其中，管理中心模块又包括了用户管理、企业管理、接入服务、数据库DB及通道管理，通道管理模块对应上述的三个通道(试用通道、快速通道和稳定通道)，通道管理服务主要用来维护各个通道，保持和终端APP的连接，可以通过该通道，从服务器上把APP软件推送到终端用户，终端用户也可以通过该通道主动拉取服务器上的软件版本。用户管理来管理个人用户，企业管理来管理各个企业，接入服务(也叫接入网关)提供给APP终端的连接，DB数据库按照业务需要自行选择类型。日志管理模块主要是用来收集APP上报反馈的日志；OSS模块，即对象存储服务(Object Storage Service，OSS)是一种海量、安全、低成本、高可靠的云存储服务，适合存放任意类型的文件。其容量和处理能力弹性扩展，多种存储类型供选择，全面优化存储成本，在本实施例中主要用来存储APP的软件包。需要说明的是，如果对用户群体再细分的话，可以使用四个通道，增加内部通道，专门供内部“共用测试”，但是一般情况下三个通道已足够。

第七方面：

本发明某一实施例还提供了一种终端设备，包括：

一个或多个处理器；

存储器，与所述处理器耦接，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述任一项实施例所述的APP灰度升级方法。

处理器用于控制该计算机终端设备的整体操作，以完成上述的APP灰度升级方法的全部或部分步骤。存储器用于存储各种类型的数据以支持在该计算机终端设备的操作，这些数据例如可以包括用于在该计算机终端设备上操作的任何应用程序或方法的指令，以及应用程序相关的数据。该存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随机存取存储器(Static Random Access Memory，简称SRAM)，电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，简称EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，只读存储器(Read-Only Memory，简称ROM)，磁存储器，快闪存储器，磁盘或光盘。

终端设备可以被一个或多个应用专用集成电路(Application Specific1ntegrated Circuit，简称AS1C)、数字信号处理器(Digital Signal Processor，简称DSP)、数字信号处理设备(Digital Signal Processing Device,简称DSPD)、可编程逻辑器件(Programmable Logic Device，简称PLD)、现场可编程门阵列(Field ProgrammableGate Array，简称FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行如上述任一项实施例所述的APP灰度升级方法，并达到如上述方法一致的技术效果。

第八方面：

本发明某一实施例还提供了一种包括程序指令的计算机可读存储介质，该程序指令被处理器执行时实现如上述任一项实施例所述的APP灰度升级方法的步骤。例如，该计算机可读存储介质可以为上述包括程序指令的存储器，上述程序指令可由计算机终端设备的处理器执行以完成如上述任一项实施例所述的APP灰度升级方法。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。

Claims

1.一种APP灰度升级方法，其特征在于，包括：

经第一通道将APP软件的第一测试版本推送至第一用户端；

接收所述第二用户端回送的第二测试数据，当所述第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户；其中，

所述第一测试版本为Alpha版本，所述第二测试版本为Beta版本，所述商业版本为RC商业版本；

所述Alpha版本用于在所述第一通道进行升级，所述Beta版本用于在所述第一通道或所述第二通道进行升级，所述RC商业版本用于在所述第一通道、所述第二通道或所述第三通道进行升级。

2.根据权利要求1所述的APP灰度升级方法，其特征在于，所述第一测试版本、所述第二测试版本及所述商业版本两两之间不能互相升级。

3.根据权利要求1所述的APP灰度升级方法，其特征在于，还包括：

4.根据权利要求3所述的APP灰度升级方法，其特征在于，

所述将所述第一测试版本更新后再推送至所述第一用户端，包括：

将所述第一测试版本的升级后的新版本推送至所述第一用户端，或将所述第一测试版本对应的目标版本的配置文件推送至所述第一用户端；

所述将所述第二测试版本更新后再推送至所述第二用户端，包括：

将所述第二测试版本的升级后的新版本推送至所述第二用户端，或将所述第二测试版本对应的目标版本的配置文件推送至所述第二用户端。

5.根据权利要求4所述的APP灰度升级方法，其特征在于，

所述将所述第一测试版本的升级后的新版本推送至所述第一用户端，包括：

将所述第一测试版本的升级后的新版本对应的URL地址，或包含所述URL地址的二维码推送至所述第一用户端；

所述将所述第二测试版本的升级后的新版本推送至所述第二用户端，包括：

将所述第二测试版本的升级后的新版本对应的URL地址，或包含所述URL地址的二维码推送至所述第二用户端。

6.一种APP灰度升级装置，其特征在于，包括：

商业版本发布模块，用于接收所述第二用户端回送的第二测试数据，当所述第二测试数据与第二预设数据匹配时，经第三通道推送APP软件的商业版本至所有用户；其中，

7.根据权利要求6所述的APP灰度升级装置，其特征在于，还包括：

8.一种终端设备，其特征在于，包括：

一个或多个处理器；

存储器，与所述处理器耦接，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1至5任一项所述的APP灰度升级方法。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述的APP灰度升级方法。