一种渠道包检测方法、装置、设备及存储介质

技术领域

本发明涉及应用测试技术领域，特别涉及一种渠道包检测方法、装置、设 备及存储介质。

背景技术

随着互联网尤其是移动互联网的发展，渠道包(例如安卓游戏包)的种类 和数量出现了爆炸性的增长，在渠道包正式发布之前需要对渠道包进行检测， 每天都存在大量的渠道包检测需求。渠道包的检测是在规定的情况下，对渠道 包进行一系列的操作，以发现渠道包的缺陷，衡量渠道包的质量，并对渠道包 能否满足设计要求进行评估的过程。

现有技术中，开发人员在漏洞(bug)解决率达标的情况下，就会将渠道包 链接给到测试人员，测试人员会进行一系列的操作，包括安装、测试功能、检 查数据等，来手动检查渠道包的各种信息，包括检查版本号信息、调试入口信 息、引导页信息、渠道信息、消息摘要算法第五版(Message Digest Algorithm， MD5)值和编译脚本信息等，如果所有信息都检测通过，则该渠道包检测通过， 可以进行推送升级。

现有技术的渠道包检测方法具有以下缺点：(1)在检测版本号信息时需要 确定是第几次灰度，还要清楚上一个发布版本的版本号才能计算这个版本的版 本号是否正确，繁琐耗时；(2)由于目前是否开启调试入口是通过构建开关来 控制的，因此在检测调试入口是否开启时，需要根据渠道包链接手动安装该渠 道包来验证，在检测引导页是否开启时，也需要通过安装渠道包来验证，繁琐 耗时；(3)如果当次渠道包信息检测有误，需要开发人员再次给到渠道包链接， 整个检测过程又需要再重复一遍，重复工作量较大，检测效率较低。

发明内容

针对现有技术的上述问题，本发明的目的在于提供一种渠道包检测方法、 装置、设备及存储介质，能够缩短检测时间，提高检测效率，从而加快灰度发 布流程。

为了解决上述问题，本发明提供一种渠道包检测方法，包括：

获取渠道包检测请求，所述渠道包检测请求包括待检测渠道包对应的参数 信息；

根据所述参数信息确定所述待检测渠道包的类型；

根据所述待检测渠道包的类型确定待检测的一个或者多个属性信息；

获取所述一个或者多个属性信息对应的检测策略；

利用所述对应的检测策略对所述一个或者多个属性信息进行检测，得到所 述一个或者多个属性信息对应的检测结果；

将所述一个或者多个属性信息对应的检测结果发送给客户端，以使所述客 户端展示所述检测结果。

本发明另一方面提供一种渠道包检测装置，包括：

参数信息获取模块，用于获取渠道包检测请求，所述渠道包检测请求包括 待检测渠道包对应的参数信息；

类型确定模块，用于根据所述参数信息确定所述待检测渠道包的类型；

属性信息确定模块，用于根据所述待检测渠道包的类型确定待检测的一个 或者多个属性信息；

检测策略获取模块，用于获取所述一个或者多个属性信息对应的检测策略；

检测模块，用于利用所述对应的检测策略对所述一个或者多个属性信息进 行检测，得到所述一个或者多个属性信息对应的检测结果；

发送模块，用于将所述一个或者多个属性信息对应的检测结果发送给客户 端，以使所述客户端展示所述检测结果。

本发明另一方面提供一种电子设备，包括处理器和存储器，所述存储器中 存储有至少一条指令或者至少一段程序，所述至少一条指令或者所述至少一段 程序由所述处理器加载并执行以实现如上述的渠道包检测方法。

本发明另一方面提供一种计算机可读存储介质，所述计算机可读存储介质 中存储有至少一条指令或者至少一段程序，所述至少一条指令或者所述至少一 段程序由处理器加载并执行以实现如上述的渠道包检测方法。

本发明另一方面提供一种计算机程序产品或计算机程序，该计算机程序产 品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。 计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该 计算机指令，使得该计算机设备执行上述的渠道包检测方法。

由于上述技术方案，本发明具有以下有益效果：

(1)本发明的渠道包检测方法，在APP灰度或者正式发布的过程中，通过 测试人员在检测页面输入的待检测渠道包对应的参数信息，先确定待检测渠道 包的类型，进而确定待检测的一个或者多个属性信息，对各个属性信息，分别 利用对应的检测策略进行检测，得到对应的检测结果，并发送给客户端进行展 示。本发明的渠道包检测方法，能够根据待检测渠道包对应的参数信息，自动 检测渠道包信息的正确性，确保渠道包的信息正确和功能完善，检测结果可靠， 还能够缩短检测时间，提高渠道包检测效率，从而加快灰度发布流程。

(2)本发明的渠道包检测方法在一灰阶段、二灰阶段、正式发布阶段都可 以复用，测试人员只需要打开检测页面，填写待检测渠道包对应的参数信息， 点击提交，能快速检测渠道包信息的正确性，无需人工检测，操作简单。如果 渠道包信息有误，只需重新填写参数信息，就能快速重新检测得到结果，并且 检测过程只涉及到纯代码逻辑判断，无需安装应用程序包，检测过程无需移动 设备，检测成本较低。

附图说明

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

图1是本发明一个实施例提供的实施环境示意图；

图2A是本发明一个具体实施例提供的实施环境示意图；

图2B是本发明另一个具体实施例提供的实施环境示意图；

图3是本发明一个实施例提供的渠道包检测方法的流程图；

图4是本发明一个实施例提供的安卓系统APP的渠道信息示意图；

图5A是本发明一个实施例提供的安卓系统渠道包检测的检测页面示意图；

图5B是本发明一个实施例提供的IOS系统渠道包检测的检测页面示意图；

图6是本发明一个实施例提供的待检测的属性信息示意图；

图7A是本发明一个实施例提供的安卓系统渠道包检测的检测结果页面示 意图；

图7B是本发明一个实施例提供的IOS系统渠道包检测的检测结果页面示意 图；

图8是本发明另一个实施例提供的渠道包检测方法的流程图；

图9是本发明一个实施例提供的数据效能对比的对比结果；

图10是本发明一个实施例提供的渠道包检测装置的结构示意图；

图11是本发明一个实施例提供的服务器的结构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、 “第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该 理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例 能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具 有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步 骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或 单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有 的其它步骤或单元。

为了使本发明实施例公开的目的、技术方案及优点更加清楚明白，以下结 合附图及实施例，对本发明实施例进行进一步详细说明。应当理解，此处描述 的具体实施例仅仅用以解释本发明实施例，并不用于限定本发明实施例。首先， 本发明实施例对下述概念进行解释：

号码包：管理端配置文件，号码包中是符合产品某些特定条件用户账号， 例如某些用户连续七天都登陆了某个应用程序(Application，APP)，则可以将 这些用户的账号(如QQ号等)收集起来，作为灰度用户，形成号码包。

渠道包：也可以称为发布包，APP灰度或者正式发布时，APP包会给到各 种各样的渠道，比如说华为、应用宝，各个渠道中的APP包即为渠道包，每一 个渠道对应一个渠道包。在APP灰度时，渠道包也可以称为灰度包。

灰度：APP每个版本迭代(即正式发布)前，都需要进行灰度测试，目前 灰度过程包括多个灰度阶段，灰度阶段升级推送只投放给号码包对应的用户， 供他们升级体验暴露灰度问题。安卓的渠道包名是以.apk结尾，会有1000多个 渠道供用户下载，苹果的渠道包名以.ipa结尾，灰度投递给testflight，正式投递 给appstore。

定包：APP灰度或者正式发布前，如果bug解决率达标，bug回归到位的情 况下，开发人员可以将渠道包信息发给测试人员，测试人员需要检查各种信息， 包括版本号、渠道号、是否开启了调试入口、MD5校验等，检查没问题之后， 可以推送内部升级，内部升级完成后，就会外推给外网号码包用户，这整个过 程叫定包。

参考说明书附图1，其示出了本发明一个实施例提供的渠道包检测方法的实 施环境示意图，如图1所示，该实施环境可以至少包括终端110和服务器120。

所述终端110可以包括智能手机、台式计算机、平板电脑、笔记本电脑、 智能音箱、数字助理、增强现实(Augmented Reality，AR)/虚拟现实 (Virtual Reality，VR)设备、智能可穿戴设备等类型的实体设备，也可以包括 运行于实体设备中的软体，例如应用程序等。所述终端110中可以运行有一个 或者多个客户端，所述客户端可以为一些服务商提供给用户的网页页面，也可 以为这些服务商提供给用户的应用。

所述服务器120可以包括一个独立运行的服务器，或者分布式服务器，或 者由多个服务器组成的服务器集群，也可以包括提供云服务、云数据库、云计 算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、 内容分发网络(Content DeliveryNetwork，CDN)、以及大数据和人工智能平台 等基础云计算服务的云服务器。所述服务器120可以通过无线或者有线网络与 所述终端110建立通信连接，本发明实施例对此不作限定。

在实际应用中，本发明实施例提供的渠道包检测方法可以应用于目标应用 灰度或者正式发布前的定包过程中，所述目标应用可以为各种类型的应用，包 括游戏类应用、直播类应用、即时通讯类应用和资讯类应用等等。具体地，如 图2A和图2B所示，在利用蓝盾平台对安卓系统和IOS系统(iPhone Operating System，苹果公司的移动操作系统)APP进行打包后，需要更新渠道包链接， 检查新的渠道包的各种信息是否正确，检查没问题之后，再进行发布。

具体地，所述终端110中运行的客户端可以用于提供面向用户的渠道包检 测处理，用户可以在所述客户端输入待检测渠道包对应的参数信息，所述客户 端可以根据所述参数信息生成渠道包检测请求，将所述渠道包检测请求发送给 所述服务器120，所述客户端还可以接收并展示渠道包检测的检测结果。所述客 户端提供面向用户的渠道包检测处理的方式可以包括但不限于应用程序方式、 网页方式等。所述服务器120可以用于实现本发明实施例提供的渠道包检测方 法，得到检测结果，并将所述检测结果发送至所述客户端。在所述服务器120 中实现所述渠道包检测方法，可以减轻终端的数据处理压力，改善面向用户的 终端的设备性能。

需要说明的是，图1仅仅是一种示例。

参考说明书附图3，其示出了本发明一个实施例提供的渠道包检测方法的流 程，该方法可以应用于图1中的服务器中。如图3所示，所述方法可以包括以 下步骤：

S310：获取渠道包检测请求，所述渠道包检测请求包括待检测渠道包对应 的参数信息。

本发明实施例中，所述渠道包检测请求可以由客户端生成并发送，所述参 数信息可以为测试人员通过客户端提供的可视化页面输入的一个或者多个参数 信息，所述参数信息可以包括源程序包链接、渠道包链接、灰度次数以及配置 信息中的一个或者多个信息。其中，渠道包链接为待灰度或者正式发布的目标 应用在各个渠道中APP包的下载链接，所述源程序包链接为打包平台中的APP 包的链接，假设采用蓝盾平台对APP进行打包，那么所述源程序包链接可以为 蓝盾链接，所述灰度次数可以包括多个灰度阶段的灰度次数，所述灰度次数为 各个灰度阶段进行渠道包检测的次数，所述配置信息可以包括是否有引导页的 配置信息。

本发明实施例中，由于安卓系统的APP的渠道种类繁多，如图4所示，包 括应用宝、百度、应用商城等等，而IOS系统的APP的渠道是固定的，灰度投 递给testflight，正式投递给appstore。因此，对安卓系统的渠道包进行检测时， 需要测试人员输入源程序包链接、渠道包链接、一灰次数、二灰次数、三灰次 数以及配置信息，对IOS系统的渠道包进行检测时，不需要测试人员输入渠道 包链接，只需要输入源程序包链接、一灰次数、二灰次数以及三灰次数。

具体地，测试人员在获取到开发人员提供的目标应用的待检测渠道包的信 息后，可以通过客户端提供的可视化页面输入待检测渠道包对应的参数信息， 所述客户端可以根据所述参数信息生成所述待检测渠道包对应的渠道包检测请 求，并发送至服务器。

示例性地，测试人员可以通过访问互联网协议地址，进入客户端提供的可 视化检测页面。由于不同操作系统的渠道包需要检测的信息不完全相同，需要 测试人员输入的参数信息也不完全相同，因此可以为不同操作系统的渠道包提 供不同的检测页面。结合参考说明书附图5A和图5B，所述检测页面500中可 以包括用于输入参数信息的操作控件510，以及用于供用户触发渠道包检测的操 作控件520。如图5A，其示出了安卓系统渠道包检测的检测页面，所述检测页 面中可以包括用于输入蓝盾链接、渠道包链接、一灰次数、二灰次数、三灰次 数和是否有引导页的参数信息的操作控件。如图5B，其示出了IOS系统渠道包检测的检测页面，所述检测页面中可以包括用于输入蓝盾链接、一灰次数、二 灰次数和三灰次数的参数信息的操作控件。测试人员可以根据待检测渠道包的 类型选择在对应的检测页面中输入相应的参数信息，参数填写完成后，测试人 员可以点击检测页面中用于触发渠道包检测的操作控件，即可生成渠道包检测 请求，并将生成的渠道包检测请求发送至服务器。

相应地，服务器接收到所述渠道包检测请求后，可以对所述渠道包检测请 求进行解析，得到待检测渠道包对应的各个参数信息。

S320：根据所述参数信息确定所述待检测渠道包的类型。

本发明实施例中，由于安卓系统的渠道包对应的参数信息与IOS系统的渠 道包对应的参数信息不相同，安卓系统的渠道包需要检测的信息与IOS系统的 渠道包需要检测的信息也不相同，因此，需要先根据输入的参数信息确定所述 待检测渠道包是安卓系统的渠道包还是IOS系统的渠道包，以对不同类型的渠 道包进行不同信息的检测。

在一个可能的实施例中，所述根据所述参数信息确定所述待检测渠道包的 类型可以包括：

如果所述参数信息包括渠道包链接，则确定所述待检测渠道包为第一类渠 道包；

如果所述参数信息不包括渠道包链接，则确定所述待检测渠道包为第二类 渠道包；

其中，所述第一类渠道包和所述第二类渠道包对应于不同的操作系统。

具体地，当确定所述待检测渠道包对应的各个参数信息后，可以判断所述 参数信息是否包括渠道包链接，当所述参数信息包括渠道包链接时，可以判定 所述待检测渠道包为第一类渠道包，当所述参数信息不包括渠道包链接时，可 以判定所述待检测渠道包为第二类渠道包，其中，所述第一类渠道包可以为安 卓系统的渠道包，所述第二类渠道包可以为IOS系统的渠道包。

S330：根据所述待检测渠道包的类型确定待检测的一个或者多个属性信息。

本发明实施例中，如图6所示，如果所述待检测渠道包为第一类渠道包， 即安卓系统的渠道包，则待检测的属性信息可以包括版本信息、配置信息、MD5 信息和渠道信息等，所述配置信息可以包括调试入口信息、引导页信息和灰度 开关信息等。如果所述待检测渠道包为第二类渠道包，即IOS系统的渠道包， 则待检测的属性信息可以包括版本信息、配置信息和编译脚本信息等，所述配 置信息可以包括调试入口信息、引导页信息和灰度开关信息等。

需要说明的是，在一些可能的实施例中，所述属性信息还可以包括其它类 型的属性信息，所述配置信息也还可以包括其它类型的配置信息，本发明实施 例对此不作限定。

S340：获取所述一个或者多个属性信息对应的检测策略。

本发明实施例中，对于各个属性信息，可以预先设置对应的检测策略。

S350：利用所述对应的检测策略对所述一个或者多个属性信息进行检测， 得到所述一个或者多个属性信息对应的检测结果。

本发明实施例中，对各个属性信息进行检测时，可以利用对应的检测策略 分别进行检测，下面分别对各个检测策略进行详细描述。

在一个可能的实施例中，所述属性信息可以为版本信息。所述利用所述对 应的检测策略对所述一个或者多个属性信息进行检测，得到所述一个或者多个 属性信息对应的检测结果可以包括：

当所述属性信息为版本信息时，获取待检测渠道包的渠道包链接和所述参 数信息中的灰度次数；

根据所述渠道包链接确定所述待检测渠道包对应的目标应用，以及所述待 检测渠道包的第一版本号；

获取所述目标应用的最新已发布程序包的第二版本号；

根据所述灰度次数和所述第二版本号确定所述待检测渠道包的第三版本 号；

如果所述第一版本号和所述第三版本号相同，则判定版本信息的检测结果 为检测通过；

如果所述第一版本号和所述第三版本号不相同，则判定版本信息的检测结 果为检测不通过。

在实际应用中，对安卓系统的渠道包和IOS系统的渠道包均需要检测版本 信息，因为版本号一旦错误，就会导致外网用户升级不上，这是很严重的错误， 因此必须要确保版本号准确无误。当所述待检测渠道包为第一类渠道包，即安 卓系统的渠道包时，所述渠道包链接可以根据渠道包检测请求中的参数信息确 定，当所述待检测渠道包为第二类渠道包，即IOS系统的渠道包时，所述渠道 包链接可以从testflight或者appstore中获取，具体的，当目标应用灰度时从 testflight中获取，当目标应用正式发布时，从appstore中获取。

所述第一版本号为待检测渠道包实际的版本号，可以根据所述渠道包链接 直接确定。示例性地，假设渠道包链接可以表示如下：http://d1dir1.qq.com/egame/ qgame/5.7.0/1025/qgame_5.7.0.476.1025_rbb7230_secondgray_release.apk，则可以 确定所述第一版本号为5.7.0.476.1025。

所述第二版本号为目标应用上一个版本发布包的版本号，由于每个版本发 布前都会将对应的版本、渠道和渠道包链接进行对应的脚本文件上传到内容分 发网络(Content Delivery Network，CDN)服务器中，因此，可以从 download_url.json.js()文件中拉取官网渠道中所述目标应用的发布包版本号，即 为第二版本号。

由于在研发过程中对版本号的确定是遵循一定的规律的，例如上一个版本 发布包的版本号是5.6.0.478.1015，那么新版本的一灰包的版本号就是 5.7.0.480.1020，二灰包的版本号是5.7.0.482.1025，正式发布的版本号是 5.7.0.484.1030，因此，可以根据参数信息中的灰度次数，以及上一个版本发布 包的版本号来计算待检测渠道包理论的版本号，即第三版本号。再将待检测渠 道包实际的版本号与理论的版本号进行比较，如果相同，则表明待检测渠道包 版本号正确，版本信息的检测结果为检测通过；如果不相同，则表明待检测渠 道包版本号不正确，版本信息的检测结果为检测不通过。

在一个可能的实施例中，所述属性信息可以为配置信息。所述利用所述对 应的检测策略对所述一个或者多个属性信息进行检测，得到所述一个或者多个 属性信息对应的检测结果可以包括：

当所述属性信息为配置信息时，确定待检测的目标配置信息；

获取所述参数信息中的源程序包链接，基于所述源程序包链接确定构建所 述源程序包时的信息配置表；

根据所述信息配置表确定所述目标配置信息对应的配置数据；

如果所述配置数据满足预设条件，则判定配置信息的检测结果为检测通过；

如果所述配置数据不满足预设条件，则判定配置信息的检测结果为检测不 通过。

在实际应用中，对安卓系统的渠道包和IOS系统的渠道包均需要检测配置 信息，包括检测调试入口信息、引导页信息和灰度开关信息中的一个或者多个。

具体地，可以直接调用打包平台(例如蓝盾平台)的相应接口，来获取构 建所述源程序包时的信息配置表，从所述信息配置表中查询目标配置信息对应 的配置数据，即构建所述源程序包时的开关配置，如果调试入口开关、引导页 开关或者灰度开关是关闭(打开)的，那么源程序包的调试入口、引导页或者 灰度开关就是关闭(打开)的，由于渠道包跟源程序包的开关配置信息保持一 致，因此渠道包的调试入口、引导页或者灰度开关也是关闭(打开)的。

在一个可能的实施例中，可以获取所述参数信息中的配置信息，判断各个 所述目标配置信息的配置数据是否与所述参数信息中的配置信息相匹配，如果 匹配，那么判定所述目标配置信息的配置数据满足预设条件，目标配置信息的 检测结果为检测通过；如果不匹配，那么判定所述目标配置信息的配置数据不 满足预设条件，目标配置信息的检测结果为检测不通过。

示例性地，假设引导页信息的配置数据为引导页开关打开，所述参数信息 中的配置信息为“是否有引导页：是”，那么可以判定所述引导页信息的配置 数据与所述参数信息中的配置信息匹配，所述引导页信息的配置数据满足预设 条件，所述引导页信息的检测结果为检测通过。

在另一个可能的实施例中，可以判断各个所述目标配置信息的配置数据是 否为预设配置信息，如果为预设配置信息，那么判定所述目标配置信息的配置 数据满足预设条件，目标配置信息的检测结果为检测通过；如果不为预设配置 信息，那么判定所述目标配置信息的配置数据不满足预设条件，目标配置信息 的检测结果为检测不通过。其中，所述预设配置信息可以根据实际情况进行设 置，例如可以设置为调试入口关闭、引导页打开，在各个灰度阶段设置灰度开 关打开，在正式发布阶段设置灰度开关关闭，等等，本发明实施例对此不作限 定。

示例性地，假设引导页信息的配置数据为引导页开关打开，引导页信息对 应的预设配置信息为引导页打开，那么可以判定所述引导页信息的配置数据满 足预设条件，所述引导页信息的检测结果为检测通过。

在一个可能的实施例中，所述属性信息可以为MD5信息。所述利用所述对 应的检测策略对所述一个或者多个属性信息进行检测，得到所述一个或者多个 属性信息对应的检测结果可以包括：

当所述属性信息为MD5信息时，获取所述参数信息中的渠道包链接和源程 序包链接；

基于所述渠道包链接获取所述待检测渠道包，基于所述源程序包链接获取 所述待检测渠道包对应的源程序包；

分别计算所述待检测渠道包的MD5值和所述源程序包的MD5值；

如果所述待检测渠道包的MD5值和所述源程序包的MD5值相同，则判定 MD5信息的检测结果为检测通过；

如果所述待检测渠道包的MD5值和所述源程序包的MD5值不相同，则判 定MD5信息的检测结果为检测不通过。

在实际应用中，对安卓系统的渠道包还需要检测MD5信息。具体地，可以 根据测试人员输入的渠道包链接和源程序包链接，调用打包平台(例如蓝盾平 台)的相应接口和requests库将待检测渠道包和源程序包分别下载下来，然后调 用计算MD5值的接口分别计算两个包的MD5值，如果两个包的MD5值相同， 表示两个包一致，MD5信息的检测结果为检测通过；如果两个包的MD5值不 相同，表示两个包不一致，MD5信息的检测结果为检测不通过。

在一个可能的实施例中，所述属性信息可以为渠道信息。所述利用所述对 应的检测策略对所述一个或者多个属性信息进行检测，得到所述一个或者多个 属性信息对应的检测结果可以包括：

当所述属性信息为渠道信息时，获取所述参数信息中的渠道包链接和灰度 次数；

根据所述灰度次数确定所述待检测渠道包的第一渠道信息；

根据所述渠道包链接确定所述待检测渠道包的第二渠道信息；

如果所述第一渠道信息和所述第二渠道信息相同，则判定渠道信息的检测 结果为检测通过；

如果所述第一渠道信息和所述第二渠道信息不相同，则判定渠道信息的检 测结果为检测不通过。

在实际应用中，对安卓系统的渠道包还需要检测渠道信息，所述渠道信息 可以根据测试人员填写的参数信息直接进行判断。

具体地，所述第一渠道信息为待检测渠道包理论的渠道信息，可以根据灰 度次数确定。示例性地，假设测试人员填写的灰度次数为1、0、0，说明现在处 于一灰阶段，所述第一渠道信息应该为firstgray，如果测试人员填写的灰度次数 为1、1、0，说明现在处于二灰阶段，所述第一渠道信息应该为secondgray，如 果测试人员填写的灰度次数为1、2、0，说明现在还是二灰阶段，经历了一次换 包流程，所述第一渠道信息还是secondgray。

所述第二渠道信息为待检测渠道包实际的渠道信息，可以根据所述渠道包 链接直接确定。示例性地，假设渠道包链接可以表示如下：http://d1dir1.qq.com/ egame/qgame/5.7.0/1025/qgame_5.7.0.476.1025_rbb7230_secondgray_release.apk， 则可以确定所述第二渠道信息为secondgray。

如果所述第一渠道信息和所述第二渠道信息相同，说明待检测渠道包的渠 道信息正确，渠道信息的检测结果为检测通过；如果所述第一渠道信息和所述 第二渠道信息不相同，说明待检测渠道包的渠道信息错误，渠道信息的检测结 果为检测不通过。

在一个可能的实施例中，所述属性信息可以为编译脚本信息。所述利用所 述对应的检测策略对所述一个或者多个属性信息进行检测，得到所述一个或者 多个属性信息对应的检测结果还可以包括：

当所述属性信息为编译脚本信息时，获取所述参数信息中的源程序包链接；

基于所述源程序包链接确定构建所述源程序包时采用的编译脚本；

如果所述编译脚本是预设编译脚本，则判定编译脚本信息的检测结果为检 测通过；

如果所述编译脚本不是预设编译脚本，则判定编译脚本信息的检测结果为 检测不通过。

在实际应用中，对IOS系统的渠道包还需要检测编译脚本信息。具体地， 可以直接调用打包平台(例如蓝盾平台)的相应接口，来获取构建所述源程序 包时采用的编译脚本，判断所述编译脚本是否为预设编译脚本，如果所述编译 脚本是预设编译脚本，则判定编译脚本信息的检测结果为检测通过；如果所述 编译脚本不是预设编译脚本，则判定编译脚本信息的检测结果为检测不通过。 其中，所述预设编译脚本为构建所述源程序包时理论上应该使用的编译脚本。

S360：将所述一个或者多个属性信息对应的检测结果发送给客户端，以使 所述客户端展示所述检测结果。

本发明实施例中，服务器可以将各个属性信息对应的检测结果发送给客户 端，所述客户端接收到所述检测结果后，可以通过可视化页面快速清晰地进行 展示。示例性地，如图7A和图7B所示，所述客户端可以通过结果展示页面分 别展示各个属性信息对应的检测结果。如图7A，其示出了安卓系统渠道包检测 的检测结果页面，所述检测结果页面中可以包括MD 5检测、版本号检测、渠道 检测、调试入口、引导页开关以及灰度开关的检测结果；如图7B，其示出了IOS 系统渠道包检测的检测结果页面，所述检测结果页面中可以包括版本号检测、 编译脚本检测以及调试入口的检测结果。

在一个可能的实施例中，结合参考说明书附图8，测试人员可以通过所述可 视化页面中各个属性信息对应的检测结果，快速确定所述待检测渠道包是否检 测通过。具体的，当各个属性信息对应的检测结果均为检测通过时，所述待检 测渠道包检测通过，当存在一个属性信息对应的检测结果为检测不通过时，所 述待检测渠道包检测不通过。当所述待检测渠道包检测通过时，即可快速在管 理端配置升级信息，发布所述待检测渠道包，达到快速灰度的目的。当所述待 检测渠道包检测不通过时，可以重新获取并填写待检测渠道包对应的参数信息， 即可重新进行检测，直到检测通过。

现有技术中一种检测方法为根据渠道包链接自动安装程序包，然后利用检 测工具QTA自动校验对应的控件参数。对现有技术的渠道包检测方法和本发明 实施例提供的渠道包检测方法进行数据效能对比实验，假设对700个渠道包进 行检测，结果如图9所示，从图中可以看到本发明实施例中的检测方法效果明 显，每个阶段渠道包检测所需的时间均远少于现有技术的检测方法所需的时间。

此外，实验中还发现本发明实施例提供的渠道包检测方法还可以检查出其 他渠道包信息问题，例如：1.外链地址是采用超链接的模式，开发人员在某一个 版本灰度时只是改变了外链的地址，但是点击外链跳转的那个链接没有改变， 导致下载的包还是之前的定包版本。2.外网下载链接的包渠道信息不对，不应该 为base，正确的应该是firstgray/secondgray/default或者是一些应用市场的渠道 名。

综上所述，本发明的渠道包检测方法，在APP灰度或者正式发布的过程中， 通过测试人员在检测页面输入的待检测渠道包对应的参数信息，先确定待检测 渠道包的类型，进而确定待检测的一个或者多个属性信息，对各个属性信息， 分别利用对应的检测策略进行检测，得到对应的检测结果，并发送给客户端进 行展示。本发明的渠道包检测方法，能够根据待检测渠道包对应的参数信息， 自动检测渠道包信息的正确性，确保渠道包的信息正确和功能完善，检测结果 可靠，还能够缩短检测时间，提高渠道包检测效率，从而加快灰度发布流程。

另外，本发明的渠道包检测方法在一灰阶段、二灰阶段、正式发布阶段都 可以复用，测试人员只需要打开检测页面，填写待检测渠道包对应的参数信息， 点击提交，能快速检测渠道包信息的正确性，无需人工检测，操作简单。如果 渠道包信息有误，只需重新填写参数信息，就能快速重新检测得到结果，并且 检测过程只涉及到纯代码逻辑判断，无需安装应用程序包，检测过程无需移动 设备，检测成本较低。

参考说明书附图10，其示出了本发明一个实施例提供的一种渠道包检测装 置1000的结构。如图10所示，所述装置1000可以包括：

参数信息获取模块1010，用于获取渠道包检测请求，所述渠道包检测请求 包括待检测渠道包对应的参数信息；

类型确定模块1020，用于根据所述参数信息确定所述待检测渠道包的类型；

属性信息确定模块1030，用于根据所述待检测渠道包的类型确定待检测的 一个或者多个属性信息；

检测策略获取模块1040，用于获取所述一个或者多个属性信息对应的检测 策略；

检测模块1050，用于利用所述对应的检测策略对所述一个或者多个属性信 息进行检测，得到所述一个或者多个属性信息对应的检测结果；

发送模块1060，用于将所述一个或者多个属性信息对应的检测结果发送给 客户端，以使所述客户端展示所述检测结果。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功 能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由 不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以 上描述的全部或者部分功能。另外，上述实施例提供的装置与相应方法实施例 属于同一构思，其具体实现过程详见对应方法实施例，这里不再赘述。

本发明一个实施例还提供了一种电子设备，该电子设备包括处理器和存储 器，该存储器中存储有至少一条指令或者至少一段程序，该至少一条指令或者 该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的渠道 包检测方法。

存储器可用于存储软件程序以及模块，处理器通过运行存储在存储器的软 件程序以及模块，从而执行各种功能应用以及数据处理。存储器可主要包括存 储程序区和存储数据区，其中，存储程序区可存储操作系统、功能所需的应用 程序等；存储数据区可存储根据所述设备的使用所创建的数据等。此外，存储 器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个 磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器还可 以包括存储器控制器，以提供处理器对存储器的访问。

本发明实施例所提供的方法实施例可以在终端、服务器或者类似的运算装 置中执行，即上述电子设备可以包括终端、服务器或者类似的运算装置。以运 行在服务器上为例，如图11所示，其示出了本发明实施例提供的运行渠道包检 测方法的服务器的结构示意图。该服务器1100可因配置或性能不同而产生比较 大的差异，可以包括一个或一个以上中央处理器(Central Processing Unit，CPU) 1110(例如，一个或一个以上处理器)和存储器1130，一个或一个以上存储应 用程序1123或数据1122的存储介质1120(例如一个或一个以上海量存储设备)。 其中，存储器1130和存储介质1120可以是短暂存储或持久存储。存储在存储 介质1120的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中 的一系列指令操作。更进一步地，中央处理器1110可以设置为与存储介质1120 通信，在服务器1100上执行存储介质1120中的一系列指令操作。服务器1100 还可以包括一个或一个以上电源1160，一个或一个以上有线或无线网络接口 1150，一个或一个以上输入输出接口1140，和/或，一个或一个以上操作系统1121， 例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等 等。

输入输出接口1140可以用于经由一个网络接收或者发送数据。上述的网络 具体实例可包括服务器1100的通信供应商提供的无线网络。在一个实例中，输 入输出接口1140包括一个网络适配器(Network Interface Controller，NIC)，其 可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，输 入输出接口1140可以为射频(RadioFrequency，RF)模块，其用于通过无线方 式与互联网进行通讯，所述无线通信可以使用任一通信标准或协议，包括但不 限于全球移动通讯系统(Global System of Mobilecommunication，GSM)、通用 分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code DivisionMultiple Access，WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短 消息服务(Short Messaging Service，SMS)等。

本领域普通技术人员可以理解，图11所示的结构仅为示意，服务器1100 还可包括比图11中所示更多或者更少的组件，或者具有与图11所示不同的配 置。

本发明一个实施例还提供了一种计算机可读存储介质，所述计算机可读存 储介质可设置于电子设备之中以保存用于实现一种渠道包检测方法相关的至少 一条指令或者至少一段程序，该至少一条指令或者该至少一段程序由该处理器 加载并执行以实现上述方法实施例提供的渠道包检测方法。

可选地，在本发明实施例中，上述存储介质可以包括但不限于：U盘、只 读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本发明一个实施例还提供了一种计算机程序产品或计算机程序，该计算机 程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储 介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理 器执行该计算机指令，使得该计算机设备执行上述各种可选实现例中提供的渠 道包检测方法。

需要说明的是：上述本发明实施例先后顺序仅仅为了描述，不代表实施例 的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要 求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不 同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描 绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某 些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

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

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过 硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于 一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或 光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的 精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的 保护范围之内。