支持对应用的安装包进行自动化验证的方法和系统

摘要

本公开提供了一种支持对应用的安装包进行自动化验证的方法和系统。所述方法可以包括：在打包装置处对所述安装包的包信息进行配置并打包；响应于触发自动化验证，向验证装置发送配置的包信息和包地址；以及在验证装置处响应于接收到包信息和包地址，下载安装包并自动执行包信息验证。

说明书

技术领域

本公开涉及电子技术领域，更具体地，涉及一种支持对应用的安装包进行自动化验证。

背景技术

随着电子设备的快速发展，通常需要预装多种应用以便用户使用。然而，对于提供应用的应用提供方而言，为了将应用预装在电子设备中以更好地推广所述应用，往往需要商务专员针对不同品牌、不同型号或不同渠道的电子设备人工提供不同版本的应用安装包，且在进行预装之前，往往还需要测试人员手动地对所提供的应用安装包进行验证和用户场景测试。这样导致对安装包进行验证的过程费时费力，且效率低下。

发明内容

有鉴于此，本公开提供了一种支持对应用的安装包进行自动化验证的方法和系统，使得能够及时响应于预装需求，自动快速验证包信息，并可以执行用户场景测试，从而无需测试人员参与，提高了系统的效率。

本公开的一个方面提供了一种支持对应用的安装包进行自动化验证的方法，包括：在打包装置处对所述安装包的包信息进行配置并打包；响应于触发自动化验证，向验证装置发送配置的包信息和包地址；以及在验证装置处响应于接收到包信息和包地址，下载安装包并自动执行包信息验证。

根据本公开的实施例，所述自动执行包信息验证包括：对下载的安装包进行解压，提取包信息；以及将提取的包信息与接收的包信息进行比较，验证所述包信息是否正确。

根据本公开的实施例，所述方法还包括：响应于触发用户场景自动化测试，利用调试工具将来自打包装置的安装包安装到用户设备中，并通过模拟用户场景对所述安装包进行用户场景自动化测试。

根据本公开的实施例，所述方法还包括：通过URL向验证装置发送配置的包信息和包地址。

本公开的另一方面提供了一种支持对应用的安装包进行自动化验证的系统，包括：打包装置，用于对所述安装包的包信息进行配置并打包，并且响应于触发自动化验证，向验证装置发送配置的包信息和包地址；以及验证装置，用于响应于接收到包信息和包地址，下载安装包并自动执行包信息验证。

根据本公开的实施例，所述验证装置进一步被配置为：对下载的安装包进行解压，提取包信息；以及将提取的包信息与接收的包信息进行比较，验证所述包信息是否正确。

根据本公开的实施例，所述系统还包括用户场景自动化测试装置，用于响应于触发用户场景自动化测试，利用调试工具将来自打包装置的安装包安装到用户设备中，并通过模拟用户场景对所述安装包进行用户场景自动化测试。

根据本公开的实施例，所述打包装置进一步被配置为通过URL向验证装置发送配置的包信息和包地址。

本公开的另一方面提供了一种支持对应用的安装包进行自动化验证的系统，包括：存储装置，配置为存储应用的安装包的包信息；第一处理装置，配置为对来自存储装置的包信息进行配置并打包，并响应于触发自动化验证，向第二处理装置发送配置的包信息和包地址；以及第二处理装置，配置为响应于从第一处理装置接收到包信息和包地址，下载安装包并自动执行包信息验证。

本公开的另一方面提供了一种计算机可读存储介质，其上存储有可执行指令，其中该指令被第一处理器执行时使第一处理器：对应用的安装包的包信息进行配置并打包，并且响应于触发自动化验证，发送配置的包信息和包地址；以及该指令被第二处理器执行时使第二处理器：响应于接收到包信息和包地址，下载安装包并自动执行包信息验证。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，由于根据本公开实施例的支持对应用的安装包进行自动化验证的方法和系统可以响应于触发自动化验证向验证装置发送配置的包信息和包地址，因此至少部分地解决现有技术中遇到的验证安装包和用户场景测试的过程费时费力且效率低下的问题，并因此可以实现能够及时响应于预装需求自动快速验证包信息的技术效果。

此外，由于根据本公开实施例的支持对应用的安装包进行自动化验证的方法和系统还可以利用调试工具将来自打包装置的安装包安装到用户设备中，并通过模拟用户场景对安装包进行用户场景自动化测试，使得无需测试人员参与测试，并提高了工作效率。

另一方面，由于根据本公开实施例的支持对应用的安装包进行自动化验证的方法和系统可以将与不同渠道相对应的渠道号打包在安装包中，也就是说，针对不同渠道发布的安装包具有不同的渠道号，这样便于跟踪软件在不同渠道的推广情况和测试情况，从而为后续的更新和完善软件产品提供了信息支持。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示出了可以应用根据本公开实施例的支持对应用的安装包进行自动化验证的方法的示例性系统架构；

图2示意性示出了根据本公开实施例的支持对应用的安装包进行自动化验证的系统的框图；

图3示出了根据本公开实施例的支持对应用的安装包进行自动化验证的系统的另一具体实施方式；

图4示意性示出了根据本公开实施例的支持对应用的安装包进行自动化验证的方法的流程图；

图5示意性示出了根据本公开实施例的支持对应用的安装包进行自动化验证的方法的一种具体实现方式；

图6示意性示出了根据本公开实施例的对应用的安装包进行用户场景自动化测试的操作的过程图；以及

图7示出了适于用来实现本公开实施例的终端设备的计算机系统的结构示意图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。这里使用的词语“一”、“一个(种)”和“该”等也应包括“多个”、“多种”的意思，除非上下文另外明确指出。此外，在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

附图中示出了一些方框图和/或流程图。应理解，方框图和/或流程图中的一些方框或其组合可以由计算机程序指令来实现。这些计算机程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器，从而这些指令在由该处理器执行时可以创建用于实现这些方框图和/或流程图中所说明的功能/操作的装置。

因此，本公开的技术可以硬件和/或软件(包括固件、微代码等)的形式来实现。另外，本公开的技术可以采取存储有指令的计算机可读介质上的计算机程序产品的形式，该计算机程序产品可供指令执行系统使用或者结合指令执行系统使用。在本公开的上下文中，计算机可读介质可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，计算机可读介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。计算机可读介质的具体示例包括：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；和/或有线/无线通信链路。

本公开的实施例提供了一种支持对应用的安装包进行自动化验证的方法和系统，该方法能够及时响应于预装需求，自动快速验证包信息，并可以自动执行用户场景测试而无需测试人员参与，因而可以提高工作效率。

图1示出了可以应用根据本公开实施例的支持对应用的安装包进行自动化验证的方法的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本公开实施例所提供的支持对应用的安装包进行自动化验证的方法的一般由服务器105执行，相应地，支持对应用的安装包进行自动化验证的系统一般设置于服务器105中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2示意性示出了根据本公开实施例的支持对应用的安装包进行自动化验证的系统200的框图。

如图2所示，根据该实施例的系统200可以包括打包装置210和验证装置220。

具体地，打包装置210可以对安装包的包信息进行配置并打包，并且响应于触发自动化验证，向验证装置220发送配置的包信息和包地址。例如，在备选实施例中，打包装置210可以进一步被配置为通过URL向验证装置220发送配置的包信息和包地址。在一个实施例中，触发自动化验证的触发事件可以包括例如用户点击自动化测试按钮的事件或指示打包完成的信号。

验证装置220可以响应于接收到包信息和包地址，下载安装包并自动执行包信息验证。在一个实施例中，验证装置220可以配置为根据包地址下载安装包，对下载的安装包进行解压，从而提取包信息。此外，验证装置220可以配置为将提取的包信息与接收的包信息进行比较，验证包信息是否正确。也就是说，如果两个包信息相同，则认为验证成功，否则认为验证失败。

此外，该系统200还可以备选地包括用户场景自动化测试装置，配置为响应于触发用户场景自动化测试，利用调试工具将安装包安装到用户设备中，并通过模拟用户场景对安装包进行用户场景自动化测试。所述安装包可以是由用户场景自动化测试装置从打包装置210接收到的安装包。备选地，当将所述用户场景自动化测试装置与验证装置220实现为一体机时，所述安装包可以是验证装置220根据包地址下载到的安装包。在一个实施例中，触发用户场景自动化测试的事件可以是由用户设定的，例如，可以包括打包装置完成对安装包的包信息的打包或者验证装置验证通过包信息等。也就是说，一旦打包装置完成对安装包的包信息的打包，便可以触发用户场景自动化测试装置执行对安装包的用户场景自动化测试。也可以在验证装置验证通过包信息之后，触发户场景自动化测试装置执行对安装包的用户场景自动化测试。前者独立于对包信息进行自动化验证的操作，使得可以分别独立地或同时地执行对包信息进行自动化验证的操作以及对安装包进行用户场景自动化测试的操作，从而可以有效利用系统资源并更快地执行测试。后者是依附于验证通过，该方法使得仅对验证通过的安装包进行用户场景自动化测试，节约了测试资源。应注意，触发条件不限于此，还可以针对不同的使用需求设置其他触发条件。

以上描述了根据本公开实施例的支持对应用的安装包进行自动化验证的系统的一种具体实现方式。除了上述实现方式之外，根据本公开实施例的支持对应用的安装包进行自动化验证的系统还可以实现为其他多种装置。

作为一个示例，图3示出了根据本公开实施例的支持对应用的安装包进行自动化验证的系统的另一具体实施方式。该系统可以实现为包括以下组件的系统300：存储装置310，配置为存储应用的安装包的包信息，例如，包信息1、包信息2和包信息n等；第一处理装置320，配置为对来自存储装置的包信息进行配置并打包，并响应于触发自动化验证，向第二处理装置230发送配置的包信息和包地址；以及第二处理装置230，配置为响应于从第一处理装置接收到包信息和包地址，下载安装包并自动执行包信息验证。

所述存储装置可以包括各种形式的存储器如非易失性或易失性存储器，例如是电可擦除可编程只读存储器(EEPROM)、闪存、和/或硬盘驱动器。存储器可以包括计算机程序，该计算机程序包括代码/计算机可读指令，其在由第一处理装置和/或第二处理装置执行时使得可以执行例如本公开所描述的方法及其任何变型。

所述第一和/或第二处理装置均可以是单个中央处理单元(CPU)，但也可以包括两个或更多个处理单元。例如，处理装置可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))。处理装置还可以包括用于缓存用途的板载存储器。

图4示意性示出了根据本公开实施例的支持对应用的安装包进行自动化验证的方法的流程图。

如图4所示，该方法包括在操作S410，在打包装置处对所述安装包的包信息进行配置并打包。

然后，在操作S420，响应于触发自动化验证，向验证装置发送配置的包信息和包地址。例如，可以通过URL向验证装置发送配置的包信息和包地址。

在操作S430，在验证装置处响应于接收到包信息和包地址，下载安装包并自动执行包信息验证。在一个实施例中，所述自动执行包信息验证可以包括：对下载的安装包进行解压，提取包信息；以及将提取的包信息与接收的包信息进行比较，验证所述包信息是否正确。

此外，所述方法还可以备选地包括：响应于触发用户场景自动化测试，利用调试工具将来自打包装置的安装包安装到用户设备中，并通过模拟用户场景对所述安装包进行用户场景自动化测试。这样使得测试过程无需测试人员参与测试，并且可以提高工作效率。

图5示意性示出了根据本公开实施例的支持对应用的安装包进行自动化验证的方法的一种具体实现方式。

如图5所示，打包装置可以实现为内容管理系统(Content Management System，CMS)的打包系统，并且通过诸如Jenkins的开源软件平台实现验证装置。具体地，首先在操作P51，在CMS打包系统里配置各厂商的安装包信息，例如，合作伙伴信息、渠道号、版本号以及所支持的的软件开发工具包和目标软件开发工具包等。也就是说，针对不同渠道发布的安装包具有不同的渠道号，这样便于跟踪软件在不同渠道的推广情况和测试情况，从而为后续的更新和完善软件产品提供了信息支持。接着，在操作P53，在打包成功后，触发自动化测试，通过链接(诸如，URL)把配置好的包信息和包地址给到诸如Jenkins的验证装置。通过将配置好的包信息和包地址发送给验证装置，可以使验证装置模拟验证安装包的准确性，从而保证较高的安装成功率，增强用户体验。随后，在操作P55，验证装置可以通过使用诸如python的高级程序设计语言，来根据接收到的包地址将安装包下载到本地，并根据正则表达式匹配出包的名称，版本等信息，即，提取包信息。例如，可以通过命令解析器(CommandLine Interface shell，CLI shell)对安装包进行解压，并利用java对解压包的文件进行读取。与此同时，可以通过正则表达式提取关键字段，即，安装包的包信息。在操作S57，验证装置将提取的包信息与从CMS接收的包信息进行比较，以便执行验证。如果匹配，则验证通过，否则会返回失败。最终，在操作P59，将针对安装包的验证结果返回给CMS管理平台。

以上描述了根据本公开实施例的支持对应用的安装包进行自动化验证的方法的一种具体实现方式。应注意，本公开不限于此，且可以在本公开的范围内包括各种变型、修改和省略。

图6示意性示出了根据本公开实施例的对应用的安装包进行用户场景自动化测试的操作的过程图。

如图6所示，首先在操作P61，获取安装包。例如，可以包括从诸如CMS打包装置获取安装包。备选地，在将验证装置和用户场景自动化测试装置实现为一体机的情况下，如果在对安装包的包信息执行自动化验证时已经获得了安装包，则可以省略此步骤。随后在操作P63，通过调试程序将安装包安装到用户设备中。例如，通过诸如安卓调试桥的调试程序将安装包安装到用户设备中。接着，在操作P65，执行用户场景自动化测试，并生成测试结果。具体地，可以利用页面控件进行点击，以查看预期的元素存在与否。例如，可以模拟核心业务的流程，诸如，选择商品、点击加入购物车、提交订单。利用测试框架来保证每个用户场景之间的执行都是相对独立的，每次都会初始化前置条件例如用帐号登录。测试过程会检查搜索、商品详情、登录、购物车等核心场景。在执行所有用例后，生成的数据通过<tr>、<table>、<td>等标签按照表格方式展现出来，以便查看用户场景是否执行成功。备选地，可以以html的方式展示通过率。在操作P67，根据所述测试结果，生成测试报告。最后在操作P69，将用户场景自动化测试报告发送给管理平台以便进行呈现。通过对应用的安装包进行用户场景自动化测试，可以模拟用户终端下载安装包并使用应用的过程，对安装包的开发功能(尤其是对于核心功能)进行测试，从而改善提高用户在实际应用中的软件体验。

以上描述了根据本公开实施例的对应用的安装包进行用户场景自动化测试的操作。应注意，本公开不限于此，且可以在本公开的范围内包括各种变型、修改和省略。

下面参考图7，其示出了适于用来实现本公开实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM 703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

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

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送对象获取请求的单元”。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。