CN112764796A - 安装包生成系统 - Google Patents

Abstract

本申请实施例提供一种安装包生成系统。该系统包括：用户界面模块、基础服务模块和打包服务模块；其中，用户界面模块展示安装包输入组件和插件输入组件，可供用户提供原始安装包和需要注入的目标插件；基础服务模块获取原始安装包的打包服务基础信息。打包服务模块可在原始安装包重新打包的过程中可将目标插件注入原始安装包，并生成新的安装包。本申请实施例提供的安装包生成系统可向用户提供自主打包服务，用户可根据打包需求提供后续工作所需的目标插件，无需对应用程序进行逻辑改造，实现了后续工作与应用程序开发程序的解耦，有助于提高后续工作效率，降低成本。

Description

安装包生成系统

技术领域

本申请涉及应用程序处理技术领域，尤其涉及一种安装包生成系统。

背景技术

随着通信技术的不断发展，智能终端的应用越来越广，针对智能终端所开发的应用程序(Application，APP)也越来越多。在测试等场景下，需要在应用程序中添加测试插件，以便对应用程序的性能和功能进行测试。但是，现有技术需要应用程序的开发人员配合测试人员对应用程序的代码逻辑进行改造，人工成本高且效率低，因此，需要提供一种支持将测试等工作和应用程序开发工作解耦的技术方案，以提升测试等工作的效率，降低成本。

发明内容

本申请的多个方面提供一种应用程序的安装包生成系统，用以实现打包与应用程序开发工作解耦，进而有助于提升后续利用该系统生成的安装包进行后续工作的效率，降低成本。

本申请实施例提供一种安装包生成系统，包括：用户界面模块、基础服务模块和打包服务模块；

所述用户界面模块，用于展示安装包输入组件和插件输入组件；

所述基础服务模块，用于基于所述安装包输入组件提供的第一安装包和所述插件输入组件提供的目标插件，获取所述第一安装包的打包服务基础信息；

所述打包服务模块，用于基于所述第一安装包的打包服务基础信息，对所述第一安装包进行重新打包，并在重新打包的过程中注入所述目标插件，以生成所述应用程序的第二安装包。

本申请实施例提供的安装包生成系统，包括：用户界面模块、基础服务模块和打包服务模块。其中，用户界面模块展示安装包输入组件和插件输入组件，可供用户提供原始安装包和需要注入的目标插件；基础服务模块获取原始安装包的打包服务基础信息。打包服务模块可在原始安装包重新打包的过程中可将目标插件注入原始安装包，并生成新的安装包。本申请实施例提供的安装包生成系统可向用户提供自主打包服务，用户可根据打包需求提供后续工作所需的目标插件，无需对应用程序进行逻辑改造，实现了后续工作与应用程序开发程序的解耦，有助于提高后续工作效率，降低成本。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的一种安装包生成系统的结构示意图；

图1b为本申请实施例提供的另一种安装包生成系统的结构示意图；

图1c-图1e为本申请实施例提供的一种人机交互界面的结构示意图；

图1f为本申请实施例提供的一种应用程序测试系统的结构示意图；

图2a为本申请实施例提供的另一种应用程序测试系统的结构示意图；

图2b为本申请实施例提供的一种测试交互界面的示意图；

图3为本申请实施例提供的一种应用程序测试方法的流程示意图；

图4为本申请实施例提供的另一种应用程序测试方法的流程示意图；

图5a为本申请实施例提供的一种可执行文件测试方法的流程示意图；

图5b为本申请实施例提供的另一种可执行文件测试方法的流程示意图；

图6为本申请实施例提供的一种应用程序的安装包生成方法的流程示意图；

图7为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

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

针对现有安装包生成方式普适性较低的技术问题，在本申请一些实施例中提供一种安装包生成系统。该系统包括：用户界面模块、基础服务模块和打包服务模块；其中，用户界面模块展示安装包输入组件和插件输入组件，可供用户提供原始安装包和需要注入的目标插件；基础服务模块获取原始安装包的打包服务基础信息。打包服务模块可在原始安装包重新打包的过程中可将目标插件注入原始安装包，并生成新的安装包。本申请实施例提供的安装包生成系统可向用户提供自主打包服务，用户可根据打包需求提供后续工作所需的目标插件，无需对应用程序进行逻辑改造，实现了后续工作与应用程序开发程序的解耦，有助于提高后续工作效率，降低成本。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1a为本申请实施例提供的一种安装包生成系统的结构示意图。如图1a所示，该系统包括：用户界面(User Interface，UI)模块11、基础服务模块12和打包服务模块13。

在本实施例中，用户界面模块11展示安装包输入组件和插件输入组件。用户可通过安装包输入组件提供应用程序的第一安装包，并通过插件输入组件提供目标插件。其中，应用程序的第一安装包为待重新打包的安装包。第一安装包可以为应用程序的原始安装包，也可为经过其它重新打包过程所形成的安装包。

在本实施例中，基础服务模块12维护有安装包打包服务的基础信息，并可触发打包服务模块13执行打包服务。基于此，基础服务模块12可基于安装包输入组件提供的第一安装包和插件输入组件提供的目标插件，获取第一安装包的打包服务基础信息，并将第一安装包的打包服务基础信息提供给打包服务模块13。可选地，基础服务模块12可根据第一安装包的标识和目标插件的标识，获取第一安装包的打包服务基础信息。其中，第一安装包的打包服务基础信息包括：第一安装包的基本信息和目标插件的基本信息等等，但不限于此。其中，第一安装包的基本信息包括：第一安装包的标识、版本号、签名信息、混淆关系信息等等，但不限于此。其中，第一安装包的标识可以为唯一标识一个第一安装包的信息，例如第一安装包的包名等等。目标插件的基本信息包括：目标插件的标识、版本号、签名信息以及混淆关系信息等等，但不限于此。

在本实施例中，打包服务模块13可基于第一安装包的打包服务基础信息对第一安装包进行重新打包，并重新打包的过程中注入目标插件，以生成应用程序的第二安装包。

本实施例提供的安装包生成系统，包括：用户界面模块、基础服务模块和打包服务模块；其中，用户界面模块展示安装包输入组件和插件输入组件，可供用户提供原始安装包和需要注入的目标插件；基础服务模块获取原始安装包的打包服务基础信息。打包服务模块可在原始安装包重新打包的过程中可将目标插件注入原始安装包，并生成新的安装包。本申请实施例提供的安装包生成系统可向用户提供自主打包服务，用户可根据打包需求提供后续工作所需的目标插件，无需对应用程序进行逻辑改造，实现了后续工作与应用程序开发程序的解耦，有助于提高后续工作效率，降低成本。

例如，用户可根据自己的测试需求提供测试插件，本实施例提供的安装包生成系统可将测试插件注入应用程序的第一安装包，生成第二安装包。这样，在运行第二安装包的过程中，便可利用测试插件对第一安装包进行测试，无需应用程序的开发人员对应用程序进行逻辑改造，便可实现对第一安装包的测试，实现了测试工作与应用程序开发工作的解耦，进而有助于提高测试效率，降低测试成本。

另一方面，本实施例提供的安装包生成系统可向用户提供自主打包服务，无需用户具有代码逻辑改造等专业能力，提高了打包的普适性和通用性，可满足普通用户的打包需求。

在本申请实施例中，如图1a所示，用户界面模块11可展示人机交互界面。相应地，人机交互界面包括安装包输入组件和插件输入组件。用户可通过触发安装包输入组件，选择第一安装包的存储路径，进而向安装包生成系统提供第一安装包。可选地，如图1a所示，人机交互界面还可包括：第一安装包上传信息项。相应地，用户可触发第一安装包上传信息项中的“上传”控件，从本地存储的第一安装包中选择待测应用程序的第一安装包，相应地，用户界面模块11可响应于测试人员选择第一安装包的操作，将第一安装包所在的存储地址写入第一安装包上传信息项中，进而获取应用程序的第一安装包。

进一步，在本申请实施例中，安装包生成系统可提供1个或多个插件供用户选择。为了便于描述和区分，在本申请实施例中，将安装包生成系统提供的插件定义为基础插件，并将基础插件的集合定义为基础插件库。可选地，如图1b所示，基础插件库13a可位于打包服务模块13中。其中，基础插件的数量可以为1个或多个。多个是指2个或2个以上。

相应地，如图1c所示，用户界面模块11可提供对应的基础插件选择组件，以供用户选择从安装包生成系统提供的基础插件中选择目标插件。在该实施例中，插件输入组件可实现为：基础插件选择组件。可选地，如图1c所示，用户可触发“选择基础插件”的下拉菜单，从下单菜单显示的基础插件中选择基础插件。对于打包服务模块13来说，还可包括：打包处理模块13b。相应地，打包处理模块13b可根据用户选择的目标基础插件的标识，从基础插件库中获取与该标识对应的目标基础插件，作为上述目标插件。

可选地，在另一些实施例中，安装包生成系统还可向用户提供自主定义插件的功能。相应地，如图1d所示，用户界面模块11还可包括：自定义插件输入组件。用户可通过自定义插件输入组件输入自定义插件。相应地，打包服务模块13还可将用户输入的自定义插件作为目标插件。

在又一些实施例中，安装包生成系统不仅提供1个或多个基础插件供用户选择，还可向用户提供自主定义插件的功能。如图1e所示，用户界面模块11包括：基础插件选择组件和自定义插件输入组件。相应地，打包处理单元13b可根据用户选择的目标基础插件的标识，从基础插件库中获取目标基础插件，并将目标基础插件和用户输入的自定义插件作为目标插件。

在一些实施例中，如图1c-图1e所示，用户界面模块11上显示有应用程序标识列表。进一步，如图1c-图1e所示，打包交互界面上显示有“请选择应用”的提示信息，用户可触发“请选择应用”的下拉菜单。相应地，用户界面模块11响应于用户触发下拉菜单的操作，展示应用程序标识列表(图1c-图1e中未示出)。进一步，用户可从应用程序标识列表中选择其要测试的应用程序标识。相应地，用户界面模块11响应于用户从人机交互界面上的应用程序标识列表中选择应用程序标识的操作，将用户选中的应用程序标识作为待重新打包的应用程序的标识信息。可选地，应用程序标识可为应用程序的名称等，但不限于此。进一步，用户可触发“提交打包”控件，用户界面模块11响应于用户触发提交打包控件的操作，获取第一安装包，并将第一安装包提供给打包服务模块13，打包服务模块13对第一安装包进行重新打包。

在一些实施例中，如图1b所示，基础服务模块12包括：应用管理单元12a、插件管理单元12b和打包任务管理单元12c。其中，应用管理单元12a用于维护应用程序的基本信息以及应用程序与插件配置之间的关联关系。其中，应用程序的基本信息包括：应用程序的名称、应用程序对应的安装包的标识、应用程序所适用的系统类型等等，但不限于此。基于此，基础服务模块12可根据第一安装包的标识，获取第一安装包对应的应用程序的基本信息以及该应用程序与插件配置之间的关联关系。

在本实施例中，插件管理单元12b用于维护插件的基本信息和配置参数，其中插件包括：目标插件以及应用程序的固有插件。其中，插件的基本信息及配置参数包括：插件的名称、签名、混淆关系等等，但不限于此。基于此，插件管理单元12b可根据第一安装包的标识和目标插件的标识，获取目标插件以及第一安装包对应的应用程序的固有插件的基本信息和配置参数。

进一步，打包任务管理单元12c可向打包服务模块13提供对应用程序的第一安装包的打包服务基础信息，并触发打包服务模块13对应用程序的第一安装包进行重新打包。其中，第一安装包的打包服务基础信息包括：第一安装包对应的应用程序的基本信息以及该应用程序与插件配置之间的关联关系，以及目标插件以及第一安装包对应的应用程序的固有插件的基本信息和配置参数，等等，但不限于此。

进一步，基础服务模块12还包括：设备管理单元12d。该设备管理单元12d用于管理使用安装包生成系统的设备列表，并负责与使用安装包生成系统的设备进行交互。

可选地，目标插件可包括：通信插件。设备管理单元12d在与使用安装包生成系统的设备进行交互时，具体用于：通过通信插件调用终端设备安装并运行第二安装包；其中，设备列表包括终端设备的标识。可选地，通信插件可为RPC插件。这样，设备管理单元12d便可通过RPC插件远程调用终端设备，并通过RPC插件控制终端设备安装并运行第二安装包。

进一步，基础服务模块还包括：数据管理单元12e。其中，数据管理单元12e可接收终端设备在运行第二安装包的过程中上报的数据，并对接收到的数据进行分析，和/或将接收到的数据提供给用户界面模块11，以供用户界面模块11进行展示。或者，数据管理单元12e还将对接收到的数据的分析结果提供给用户界面模块11进行展示。

可选地，如图1b所示，基础服务模块12还可包括基础实验室12f。其中，基础实验室12f可提供利用第二安装包进行后续工作的一些应用场景。例如，利用第二安装包对第一安装包进行测试时，基础实验室12f可提供一些测试应用场景，如mock(虚拟)测试场景等等。

在本申请实施例中，打包服务模块13在对第一安装包进行重新打包时，可对应用程序的第一安装包进行编译，得到该应用程序的第一源文件。进一步，打包服务模块13还可将目标插件的源文件注入第一源文件中，以得到修改后的第一源文件，并对修改后的第一源文件进行重新编译，以得到应用程序的第二安装包。

在本实施例中，目标插件的源文件可以为对目标插件进行编译，得到的源文件；或者，目标插件本身可以源文件的形式提供给用户。

在本实施例中，将目标插件的源文件注入应用程序的第一源文件中，得到修改后的第一源文件，并对修改后的第一源文件进行重新编译，得到应用程序的第二安装包。这种应用程序的安装包生成方式，无需开发人员对应用程序的代码逻辑进行改造，可提高打包效率，进而有助于降低打包成本。

在另一些实施例中，应用程序的第一安装包的源文件以及目标插件的源文件不仅包括相应的代码文件，还包括一些资源文件，例如应用程序和插件所涉及的图片、Lib库等，但不限于此。即应用程序的第一源文件包括源代码和资源文件；插件的源文件也包括插件的原始代码和资源文件。基于此，打包服务模块13在对修改后的第一源文件进行重新编译时，可将目标插件的源文件中的原始代码注入第一源文件中的源代码中；并将目标插件的源文件中的资源文件注入编译得到的源文件中的资源文件中。其中，第一源文件中的源代码可以为原始代码、汇编代码或虚拟机字节码，但不限于此。

进一步，目标插件的源文件中的原始代码文件不仅包括该插件对应的实现其功能所需的应用代码，对于一些需要在启动过程中运行的插件还包括启动其功能的启动代码。同理，应用程序的源代码不仅包括实现应用程序的功能所需的应用代码，还包括启动实现该应用程序的功能的启动代码。基于此，在将目标插件的源文件中的原始代码注入第一源文件中的源代码中时，还可在源代码中查找应用程序的应用代码；并将目标插件的应用代码注入应用程序的应用代码中；以及在源代码中查找应用程序的启动代码，并将目标插件中的第一插件的启动代码注入应用程序的启动代码中；其中，第一插件为目标插件中的在启动过程中需要运行的插件。

进一步，考虑到第一安装包的源文件和目标插件的源文件可能存在一些有冲突的文件。例如，第一安装包的源文件中某个文件的文件名与目标插件的源文件中的某个文件的文件名相同；又例如，第一安装包的源文件中某个文件的版本与测试工具的源文件中的某个文件的版本存在冲突等等。基于此，打包服务模块13在进行将目标插件的源文件中的原始代码文件注入第一源文件中的代码文件中时，还可排除其中的文件冲突。同理，打包服务模块13在将目标插件的源文件中的资源文件注入第一安装包的第一源文件中的资源文件中时，也可排除其中的文件冲突。

可选地，人机交互界面还可包括：签名类型信息项(图1c-图1e中未示出)。基于此，用户可根据重新打包需求，选择对应用程序的第二安装包是否签名以及采用哪种签名类型。其中，签名类型可包括1种或多种数字签名类型，例如Keystore文件签名等，但不限于此。进一步，若用户选择Keystore文件签名，还可自主上传自定义的Keystore文件。

在本实施例中，若用户选择对应用程序的第二安装包进行签名，则打包服务模块13在对应用程序的第二安装包的源文件进行重新编译，得到应用程序的第二安装包之后，还可采用用户选定的签名类型对应用程序的第二安装包进行重新签名。

值得说明的是，本申请实施例提供的应用程序的安装包生成发生可适用于各种应用场景中。用户可根据自己的需求，向应用程序中插入可满足其功能需求的插件。例如，在对应用程序进行测试的应用场景中，测试任务可根据测试需求，向将预设的测试工具的源文件注入待测应用程序的第一源文件中，得到修改后的第一源文件；并对修改后的第一源文件进行重新编译，得到待测应用程序的测试包。之后，便可运行该测试包，并在运行测试包的过程中，利用插入的测试工具对应用程序的第一安装包进行测试。在该应用场景中，目标插件为测试工具。下面以目标插件为测试工具为例，对设备管理单元12d与终端设备的交互过程进行示例性说明。

在上述应用场景中，设备管理单元12d还可在调用终端设备运行第二安装包的过程中，控制终端设备利用测试工具对第二安装包进行测试，并得到测试数据。之后，可将测试数据提供给数据管理单元12e，并由数据管理单元12e进行分析，以使测试人员了解第一安装包的性能。进一步，测试人员可将测得的第一安装包的性能反馈给开发人员，以使开发人员能够对第一安装包进行优化，等等，但不限于此。

在本实施例中，可在对第一安装包进行重新打包的过程中植入测试工具，形成第二安装包。这样，测试终端便可在运行第二安装包的过程中，利用测试工具对第一安装包进行测试，得到测试数据。这种应用程序测试方式，无需开发人员对待测应用程序的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

在本申请实施例中，测试工具可包括至少一个测试插件。相应地，设备管理单元12d可控制终端设备利用至少一个测试插件对待测应用程序的第一安装包进行测试。其中，测试人员可根据测试需求，植入各种测试功能的测试插件。进一步，由于测试人员植入的测试插件的启动类型和功能类型，设备管理单元12d控制终端设备利用测试插件对第一安装包进行测试的过程所有不同。下面结合几种可选实施例，对其进行示例性说明。

可选实施例1：至少一个测试插件包括启动类型为外启动的测试插件。对于外启动的测试插件，在不对这类测试插件进行动态开启的情况下，这类测试插件无法执行其测试逻辑。基于此，在本申请实施例中，对于外启动的测试插件，测试人员可通过安装包生成系统向终端设备发送测试指令，该测试指令包括：插件标识和对象标识。其中，插件标识用于标识至少一个测试插件中的一个或多个测试插件；对象标识用于标识应用程序的第一安装包中的待测对象。

在上述可选实施例1中，目标插件还包括：通信插件。其中，通信插件为待测应用程序提供了应用内部与外部直接交互的沙箱环境，有助于提高测试的便利性。可选地，通信插件可为RPC插件。基于此，设备管理单元12d备可向终端设备发送测试指令，并通过通信插件控制终端设备根据测试指令中的插件标识，从至少一个测试插件中确定目标测试插件，实现对目标测试插件的动态启动。之后，设备管理单元12d可按照目标测试插件的测试逻辑，对第一安装包中与测试指令中的对象标识对应的待测对象进行测试。可选地，设备管理单元12d可通过网页或自动化客户端向终端设备发送测试指令。

进一步，在可选实施例1中，根据目标测试插件的功能类型不同，其对辅助插件的需求也就不同。在一些实施例中，测试人员想要测试待测应用程序的第一安装包在运行一定时间段内的耗电量，或者想要测试待测应用程序在运行时所消耗的内存资源等。对于这些无需测试第一安装包的代码逻辑的测试需求，测试人员可在重新打包过程中，向第一安装包中植入目标测试插件。在这种情况下，目标测试插件无需测试第一安装包的代码逻辑。基于此，设备管理单元12d可控制终端设备直接按照目标测试插件的测试逻辑，对第一安装包的待测对象进行测试。其中，待测对象可以为待测应用程序的第一安装包在运行一定时间段内的耗电量，或者想要测试待测应用程序在运行时所消耗的内存资源等等，但不限于此。

在另一些实施例中，测试人员想要测试待测应用程序的第一安装包的代码逻辑。基于此，在对第一安装包进行重新打包的过程中，植入的测试工具还包括：钩子(HOOK)插件。其中，钩子插件可对其作用对象的运行行为进行监听、拦截，也可对作用对象对应的代码进行修改。基于此，在需要测试第一安装包的代码逻辑的情况下，设备管理单元12d可通过通信插件控制终端设备调用钩子插件获取待测对象的运行状态数据，并将运行状态数据提供给目标测试插件，之后，运行目标测试插件基于运行状态数据对待测对象对应的代码逻辑进行测试。即，将运行状态数据作为目标测试插件的入口参数输入目标测试插件，并在运行目标测试插件的过程中对待测对象对应的代码逻辑进行测试。

可选地，如图1f所示，用户可通过用户界面模块11上的网页或自动化客户端控制终端设备的第二安装包的运行。可选地，测试人员在用户界面模块11上的的网页或自动化客户端上输入控制指令，相应地，设备管理单元12d将控制指令发送给终端设备。其中，控制指令中包括需要使用的目标测试插件。可选地，在需要测试原始APP的代码逻辑的情况下，如图1f所示，设备管理单元12d可对第二安装包中的测试工具进行RPC调用，并通过RPC插件控制终端设备接收控制指令。进一步，设备管理单元12d可控制终端设备基于该控制指令对目标测试插件进行动态启动。进一步，RPC插件控制钩子插件对原始APP的内部应用程序编程接口(Application Programming Interface，API)进行行为监听或修改，得到API的运行状态数据，并将API的运行状态数据作为目标测试插件的入口参数输入目标测试插件，以供目标测试插件对API进行测试，进而得到测试数据。其中，RPC插件和钩子插件为第一安装包的测试提供了沙箱环境，有助于实现生态化测试。

可选实施例2：至少一个测试插件包括启动类型为自启动的测试插件。为了便于描述和区分，在可选实施例2中，将自启动的测试插件定义为目标测试插件。其中目标测试插件的数量可以为1个或多个。进一步，对于目标测试插件对应的第一安装包的测试对象，其测试对象可在植入目标测试插件时，对目标测试插件与第一安装包中的待测对象进行绑定；或者，也可由测试人员通过设备管理单元12d向终端设备发送测试指令来进行指定，其中，测试指令中包括对象标识，该对象标识可标识第一安装包中的待测对象。

对于目标测试插件与第一安装包中的待测对象进行绑定的情况，在运行待测应用程序的第二安装包的过程中，设备管理单元12d可通过通信插件控制终端设备利用目标测试插件对第一安装包中与目标测试插件绑定的待测对象进行测试。

对于设备管理单元12d向终端设备发送测试指令来指定第一安装包的待测对象的情况，设备管理单元12d在对待测应用程序的第一安装包进行重新打包的过程中，所植入的测试工具还包括通信插件。可选地，通信插件可以为RPC插件。相应地，设备管理单元12d向终端设备发送测试指令，该测试指令包括对象标识。相应地，设备管理单元12d可通过通信插件控制终端设备按照目标测试插件的测试逻辑，对第一安装包中与测试指令中的对象标识对应的待测对象进行测试。

进一步，在可选实施例2中，根据目标测试插件的功能类型不同，其对辅助插件的需求也就不同。对于上述可选实施例1中所列举的无需测试第一安装包的代码逻辑的测试需求，测试人员可在重新打包过程中，向第一安装包中植入目标测试插件。在这种情况下，目标测试插件无需测试第一安装包的代码逻辑。基于此，设备管理单元12d可通过通信插件控制终端设备直接利用目标测试插件对第一安装包的待测对象进行测试。其中，待测对象可以为待测应用程序的第一安装包在运行一定时间段内的耗电量，或者想要测试待测应用程序在运行时所消耗的内存资源等等，但不限于此。其中，关于待测对象的确定的实施方式，可参见可选实施例1中的上述内容，在此不再赘述。

在另一些实施例中，测试人员想要测试待测应用程序的第一安装包的代码逻辑。基于此，打包服务模块13在对待测应用程序的第一安装包进行重新打包的过程中，植入的测试工具还包括：钩子插件。基于此，在需要测试第一安装包的代码逻辑的情况下，设备管理单元12d可通过通信插件控制终端设备调用钩子插件获取待测对象的运行状态数据，并将运行状态数据提供给目标测试插件，之后，运行目标测试插件基于运行状态数据对待测对象对应的代码逻辑进行测试。即，将运行状态数据作为目标测试插件的入口参数输入目标测试插件，并在运行目标测试插件的过程中对待测对象对应的代码逻辑进行测试。

在本申请实施例中，无论测试插件的启动类型是自启动，还是外启动，其均可以对待测应用程序的第一安装包进行各种深入测试和分析。例如，可以利用测试插件测试第一安装包的内部接口、修改第一安装包的内容状态、对第一安装包的代码逻辑进行链路追踪或者进行mock(虚拟)测试等等，但不限于此。下面结合几种常见的测试需求，对设备管理单元12d控制终端设备调用钩子插件获取待测对象的运行状态数据的过程进行示例性说明。

测试需求1：测试人员想要测试第一安装包中的某个对象处于某种状态下的测试数据。例如，对于视频类的应用程序，测试人员想要测试播放器处于暂停状态时的运行数据；或者测试播放器处于播放状态时的下载速度；又例如，对于在线购物类的应用程序，测试人员想要测试在添加购物车后购物车的运行数据。在这种测试需求下，目标测试插件可为内部状态测试插件。则设备管理单元12d可通过通信插件控制终端设备将待测对象的内部状态调整为目标状态，其中，目标状态是要求待测对象在测试过程中保持的内部状态；并调用钩子插件获取待测对象在目标状态下的运行状态数据。相应地，设备管理单元12d可通过通信插件控制终端设备将运行状态数据提供给数据管理单元12e。相应地，数据管理单元12e可将运行状态数据作为内部状态测试插件的入口参数，并运行内部状态测试插件，进而得到待测对象处于目标状态下的测试数据。

可选地，在一些实施例中，钩子插件包括内部状态修改指令。该内部状态修改指令中包含目标状态。在这种情况下，设备管理单元12d可通过通信插件控制中国队设备调用钩子插件将待测对象的内部状态修改为目标状态。

在另一些实施例中，钩子插件中不包括内部状态修改指令。在这种情况下，测试人员可通过设备管理单元12d向终端设备发送外部状态修改指令。该外部状态修改指令中包含目标状态。相应地，设备管理单元12d可通过通信插件控制终端设备根据外部状态修改指令，将待测对象的内部状态修改为目标状态。在这种实施方式下，打包服务模块13在对待测应用程序的第一安装包进行重新打包的过程中，所植入的测试工具还包括通信插件。可选地，通信插件可以为RPC插件。相应地，终端设备可通过通信插件接收外部状态修改指令。

测试需求2：测试人员想要测试待测应用程序的第一安装包中的方法逻辑是否可行，或者想要测试待测应用程序的第一安装包中的方法性能，例如方法逻辑的运行速率等等。例如，对于视频类的应用程序，测试人员想要测试使播放器的播放状态修改为暂停状态的方法。又例如，对于在线购物类的应用程序，测试人员想要测试添加购物车的方法。在这种测试需求下，目标测试插件包括方法测试插件，测试指令中还包括方法标识。相应地，设备管理单元12d可通过通信插件控制终端设备根据测试指令中的方法标识，确定与待测对象绑定的待测方法，并在待测对象上模拟与待测方法绑定的触发操作，以使待测方法运行；之后，设备管理单元12d可通过通信插件控制终端设备利用钩子插件获取待测对象在待测方法运行过程中产生的运行状态数据，并将该运行状态数据提供给方法测试插件，供方法测试插件测试待测方法是否可行和/或待测方法的运行性能等等，但不限于此。

测试需求3：测试人员想要对第一安装包中的调用关系进行链路追踪，来实现第一安装包的链路排查、性能优化等。在这种应用需求下，目标测试插件可包括路径追踪插件。相应地，设备管理单元12d可通过通信插件控制终端设备调用钩子插件获取待测对象在与其上下文对象进行调用过程中产生的运行状态数据。其中，待测对象的上下文对象包括：与待测对象存在直接调用关系的对象和与待测对象存在间接调用关系的对象。例如，假设待测对象为模块A，模块A调用依赖B，依赖B调用依赖C，则模块A的上下文对象可以为依赖A和依赖C。

相应地，设备管理单元12d还可通过通信插件控制终端设备将待测对象在与其上下文对象进行调用过程中产生的运行状态数据提供给数据管理单元12e。相应地，数据管理单元12e可将运行状态参数作为路径追踪插件的入口参数，运行路径追踪插件对待测对象在与其上下文对象之间的链路进行追踪和分析。

测试需求4：在一些应用场景下，测试人员想要测试一些在待测应用程序中不容易构造或者比较复杂的对象。例如，测试人员想要测试待测应用程序在运行过程中，某个页面处于崩溃状态时整个应用程序的运行状况；又例如，在在线支付类的应用程序中，存在很多的第三方的接口会用于代付、转账等，当第三方提供的测试环境不稳定时，在线支付类的应用程序的效能就会受到影响，在这种应用场景下，测试人员还可以模拟第三方接口不稳定的情况；等等。

在上述测试需求下，目标测试插件还包括：虚拟测试插件。在本实施例中，设备管理单元12d可通过通信插件控制终端设备利用虚拟测试插件产生mock测试所需的虚拟环境，并控制待测对象在虚拟环境中运行；之后，利用钩子插件获取待测对象在虚拟环境下的运行状态数据。可选地，设备管理单元12d可通过通信插件控制终端设备将运行状态数据提供给虚拟测试插件，以供虚拟测试插件基于这些运行状态数据对待测对象进行虚拟测试。

值得说明的是，在本实施例中，应用程序可以为APP或客户端。其中，应用程序的实现形态不同，终端设备的实现形式也就不同。若应用程序为APP，则终端设备可以为智能手机、可穿戴设备等；若待测应用程序为适用于客户端，则终端设备可以为台式电脑、笔记本电脑等等，但不限于此。

本申请实施例提供的安装包生成系统可部署于一台或多台计算机设备上。其中，计算机设备具有一定数据处理能力和通信能力，其可以为单一服务器设备，也可以云化的服务器阵列，或者为云化的服务器阵列中运行的虚拟机(Virtual Machine，VM)。另外，服务端设备也可以指具备相应服务能力的其他计算设备，例如电脑等终端设备(运行服务程序)等，例如测试人员的电脑等等。

除了上述安装包生成系统之外，本申请实施例还提供应用程序测试系统。如图2a所示，该系统包括：测试终端20a和服务端设备20b。其中，图2a所示的测试终端20a和服务端设备20b的实现形式只是示例性说明，并不对其进行限定。

在本实施例中，测试终端20a是指测试人员使用的，可以安装并运行待测应用程序的第一安装包和第二安装包的计算机设备，例如可以是智能手机、平板电脑、个人电脑、穿戴设备等。其中，待测应用程序的第一安装包为开发人员所开发的面向普通用户的安装包，一般为待测应用程序的第一安装包。在应用程序测试场景中，待测应用程序的第二安装包，也可称为测试包，可为测试人员根据自己的测试需求向第一安装包中植入对应的测试工具后形成的安装包。

在本实施例中，测试终端20a通常包括至少一个处理单元和至少一个存储器。处理单元和存储器的数量取决于测试终端20a的配置和类型。存储器可以包括易失性的，例如RAM，也可以包括非易失性的，例如只读存储器(Read-Only Memory，ROM)、闪存等，或者也可以同时包括两种类型的。存储器内通常存储有操作系统(Operating System，OS)、一个或多个应用软件，例如与服务端设备20b对应的即时通信类软件，也可以存储有程序数据等。除了处理单元和存储器之外，测试终端20a也会包括网卡芯片、IO总线、音视频组件等基本配置。可选地，根据测试终端20a的实现形式，测试终端20a也可以包括一些外围设备，例如键盘、鼠标、输入笔、打印机等。这些外围设备在本领域中是众所周知的，在此不做赘述。

在本实施例中，服务端设备20b是指具有一定数据处理能力和通信能力的计算机设备。服务端设备20b可以为单一服务器设备，也可以云化的服务器阵列，或者为云化的服务器阵列中运行的虚拟机(Virtual Machine，VM)。另外，服务端设备也可以指具备相应服务能力的其他计算设备，例如电脑等终端设备(运行服务程序)等，例如测试人员的电脑等等。

在本实施例中，测试终端20a和服务端设备20b之间可以是无线或有线连接。可选地，服务端设备测试终端20a可以通过移动网络和服务端设备20b通信连接，相应地，移动网络的网络制式可以为2G(GSM)、2.5G(GPRS)、3G(WCDMA、TD-SCDMA、CDMA2000、UTMS)、4G(LTE)、4G+(LTE+)、5G、WiMax等中的任意一种。可选地，测试终端20a也可以通过蓝牙、WiFi、红外线等方式和服务端设备20b通信连接。

在本实施例中，服务端设备20b存储有待测应用程序的第二安装包。基于此，服务端设备20b可从其存储器中获取待测应用程序的第二安装包，并将该第二安装包发送给测试终端20a。其中，待测应用程序的第二安装包是对待测应用程序的第一安装包进行重新打包得到的，且第二安装包包含在重新打包的过程中植入的测试工具。

可选地，服务端设备20b存储有多种应用程序的第二安装包，其中包括本实施例提供的待测应用程序的第二安装包。其中，多种是指2种或2种以上。进一步，服务端设备20b可存储应用程序的第二安装包列表。测试人员可根据当前测试需求，从应用程序对应的第二安装包列表中选择要测试的第二安装包。例如，如图2b所示，在本实施例中，服务端设备20b可提供测试交互界面。可选地，测试交互界面上包括应用程序选择信息项。例如，图2b所示的“请选择应用”的提示信息，测试人员可触发应用程序选择信息项的下单菜单来查看服务端设备20b所提供的应用程序标识列表，如图2b所示的“应用A、B、C”。进一步，测试人员可从应用程序标识列表中选择其要测试的应用程序。如图2b所示，测试人员选择应用B作为待测应用程序。相应地，服务端设备20b响应于测试人员从应用程序标识列表中选中应用程序标识的操作，从本地存储的应用程序的第二安装包中，获取与测试人员选定的应用程序标识对应的第二安装包作为待测应用程序的第二安装包，并将该第二安装包发送给测试终端20a。例如，图2b所示，服务端设备20b从本地存储的应用程序的第二安装包中，获取与应用B的第二安装包作为待测应用程序的第二安装包，并将应用B的第二安装包发送给测试终端20a。可选地，应用程序标识可为应用程序的名称、功能描述等，但不限于此。

相应地，测试终端20a接收服务端设备20b发送的待测应用程序的第二安装包，并运行该第二安装包。进一步，由于第二安装包中植入有测试工具，则测试终端20a在运行待测应用程序的第二安装包的过程中，可利用测试工具对待测应用程序的第一安装包进行测试，进而得到测试数据。

可选地，测试终端20a可将得到的测试数据发送给服务端设备20b。相应地，服务端设备20b接收测试数据，并基于该测试数据对第一安装包的性能进行分析，以使测试人员可了解待测应用程序的第一安装包的性能。进一步，测试人员可将测得的第一安装包的性能反馈给开发人员，以使开发人员能够对待测应用程序的第一安装包进行优化，等等，但不限于此。

在本实施例中，服务端设备在对待测应用程序的第一安装包进行重新打包的过程中植入测试工具，形成待测应用程序的第二安装包。这样，测试终端便可在运行待测应用程序的第二安装包的过程中，利用测试工具对第一安装包进行测试，得到测试数据。这种应用程序测试方式，无需开发人员对待测应用程序的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

在本实施例中，服务端设备20b可对待测应用程序的第一安装包进行重新打包，并在重新打包的过程中植入测试工具。服务端设备20b在对待测应用程序的第一安装包进行重新打包的具体实施方式，可参见上述实施例的相关内容，在此不再赘述。

相应地，测试终端20a接收待测应用程序的第二安装包，并安装该第二安装包。其中，测试终端20a安装第二安装包，可由测试人员操作测试终端20a进行安装，也可由测试人员通过服务端设备20b对测试终端20a进行远程过程调用(Remote procedure call，RPC)来控制测试终端20a安装待测应用程序的第二安装包。

进一步，测试终端20a运行待测应用程序的第二安装包，便可在待测应用程序的第二安装包的运行过程中，利用其中的测试工具对待测应用程序的第一安装包进行测试。可选地，服务端设备20b可通过RPC插件向测试终端20a发送运行指令，以使测试终端20a运行待测应用程序的第二安装包。其中，关于服务端设备20b控制测试终端20a在运行第二安装包的过程中，对第一安装包进行测试的具体实施方式，可参见上述实施例的相关内容，在此不再赘述。

除了上述应用程序测试系统实施例之外，本申请实施例还提供应用程序测试方法，下面分别从测试终端和服务端设备的角度，分别进行示例性说明。

图3为本申请实施例提供的一种应用程序测试方法的流程示意图。该方法适用于测试终端。如图3所示，该方法包括：

301、运行待测应用程序的第二安装包；该第二安装包是对待测应用程序的第一安装包进行重新打包得到的，且第二安装包包含在重新打包过程中植入的测试工具。

302、在运行第二安装包的过程中，利用测试工具对第一安装包进行测试，以得到测试数据。

在本实施例中，测试终端可以是智能手机、平板电脑、个人电脑、穿戴设备等。其中，待测应用程序的第一安装包为开发人员所开发的面向普通用户的安装包，待测应用程序的第二安装包为测试人员根据自己的测试需求向第一安装包中植入对应的测试工具后形成的安装包。

在本实施例中，待测应用程序可以为APP或客户端。其中，待测应用程序的实现形态不同，测试终端的实现形式也就不同。若待测应用程序为适用于智能手机、可穿戴设备的APP，则测试终端可以为智能手机、可穿戴设备等；若待测应用程序为适用于台式电脑、笔记本等的客户端，则测试终端可以为台式电脑、笔记本电脑等等，但不限于此。

在本实施例中，测试终端安装有待测应用程序的第二安装包。测试终端可运行该第二安装包，并在运行第二安装包的过程中，利用第二安装包中的测试工具对待测应用程序的第一安装包进行测试，进而得到测试数据。

可选地，测试终端可将得到的测试数据发送给服务端设备。相应地，服务端设备接收测试数据，并基于该测试数据对第一安装包的性能进行分析，以使测试人员可了解待测应用程序的第一安装包的性能。进一步，测试人员可将测得的第一安装包的性能反馈给开发人员，以使开发人员能够对待测应用程序的第一安装包进行优化，等等，但不限于此。

在本实施例中，服务端设备可以为单一服务器设备，也可以云化的服务器阵列，或者为云化的服务器阵列中运行的虚拟机(Virtual Machine，VM)。另外，服务端设备也可以指具备相应服务能力的其他计算设备，例如电脑等终端设备(运行服务程序)等，例如测试人员的电脑等等。

基于此，对于待测应用程序为适应于电脑、工作站等的客户端的情况，测试终端也可为测试人员所使用的电脑。在这种情况下，测试终端可基于该测试数据对第一安装包的性能进行分析，以使测试人员可了解待测应用程序的第一安装包的性能。进一步，测试人员可将测得的第一安装包的性能反馈给开发人员，以使开发人员能够对待测应用程序的第一安装包进行优化，等等，但不限于此。在该实施方式中，可选地，测试终端存储有多种应用程序的第二安装包，其中包括本实施例提供的待测应用程序的第二安装包。其中，多种是指2种或2种以上。进一步，测试终端可存储应用程序的第二安装包列表。测试人员可根据当前测试需求，从应用程序对应的第二安装包列表中选择要测试的第二安装包。相应地，测试终端响应于测试人员从应用程序标识列表中选中应用程序标识的操作，从本地存储的应用程序的第二安装包中，获取与测试人员选定的应用程序标识对应的第二安装包作为待测应用程序的第二安装包。可选地，应用程序标识可为应用程序的名称、功能描述等，但不限于此。

在本实施例中，在对待测应用程序的第一安装包进行重新打包的过程中植入测试工具，形成待测应用程序的第二安装包。这样，测试终端便可在运行待测应用程序的第二安装包的过程中，利用测试工具对第一安装包进行测试，得到测试数据。这种应用程序测试方式，无需开发人员对待测应用程序的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

在一种实施例中，若待测应用程序的第二安装包是由服务端设备对待测应用程序的第一安装包进行重新打包形成的，则在步骤301之前，服务端设备将待测应用程序的第二安装包下发给测试终端。相应地，测试终端接收该第二安装包，并安装该第二安装包。

在另一种实施例中，若待测应用程序的第二安装包是由测试终端对待测应用程序的第一安装包进行重新打包形成的，则在步骤301之前，测试终端还可对待测应用程序的第一安装包进行重新打包。其具体实施方式，可参见上述实施例的相关内容，在此不再赘述。

进一步，测试终端可安装待测应用程序的第二安装包。其中，测试终端安装第二安装包，可由测试人员操作测试终端进行安装。或者，基于上述应用程序测试系统架构，也可由测试人员通过服务端设备对测试终端进行远程过程调用(Remote procedure call，RPC)来控制测试终端安装待测应用程序的第二安装包。

进一步，测试终端运行待测应用程序的第二安装包，便可在待测应用程序的第二安装包的运行过程中，利用其中的测试工具对待测应用程序的第一安装包进行测试。可选地，服务端设备可通过RPC插件向测试终端发送运行指令，以使测试终端运行待测应用程序的第二安装包。其中，对于利用测试工具对待测应用程序的第一安装包进行测试的具体实施方式可参见上述实施例的相关内容，在此不再赘述。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述测试终端执行应用程序测试方法中的步骤。

基于图2a所示的系统架构，本申请实施例还提供一种应用程序测试方法，该方法适用于服务端设备。现结合图4对该方法进行示例性说明。如图4所示，该方法包括：

401、获取待测应用程序的第二安装包；该第二安装包是对待测应用程序的第一安装包进行重新打包得到的，且第二安装包包含在重新打包过程中植入的测试工具。

402、将第二安装包发送给测试终端，以供测试终端在运行第二安装包的过程中，利用测试工具对第一安装包进行测试。

在本实施例中，服务端设备存储有待测应用程序的第二安装包。基于此，服务端设备可获取待测应用程序的第二安装包，并将该第二安装包发送给测试终端。其中，待测应用程序的第二安装包是对待测应用程序的第一安装包进行重新打包得到的，且第二安装包包含在重新打包的过程中植入的测试工具。

可选地，服务端设备存储有多种应用程序的第二安装包，其中包括本实施例提供的待测应用程序的第二安装包。其中，多种是指2种或2种以上。进一步，服务端设备可存储应用程序的第二安装包列表。测试人员可根据当前测试需求，从应用程序对应的第二安装包列表中选择要测试的第二安装包。相应地，服务端设备响应于测试人员从应用程序标识列表中选中应用程序标识的操作，从本地存储的应用程序的第二安装包中，获取与测试人员选定的应用程序标识对应的第二安装包作为待测应用程序的第二安装包，并将该第二安装包发送给测试终端。

相应地，测试终端接收服务端设备发送的待测应用程序的第二安装包，并运行该第二安装包。进一步，由于第二安装包中植入有测试工具，则测试终端在运行待测应用程序的第二安装包的过程中，可利用测试工具对待测应用程序的第一安装包进行测试，进而得到测试数据。

可选地，测试终端可将得到的测试数据发送给服务端设备。相应地，服务端设备接收测试数据，并基于该测试数据对第一安装包的性能进行分析，以使测试人员可了解待测应用程序的第一安装包的性能。进一步，测试人员可将测得的第一安装包的性能反馈给开发人员，以使开发人员能够对待测应用程序的第一安装包进行优化，等等，但不限于此。

在本实施例中，服务端设备在对待测应用程序的第一安装包进行重新打包的过程中植入测试工具，形成待测应用程序的第二安装包。这样，测试终端便可在运行待测应用程序的第二安装包的过程中，利用测试工具对第一安装包进行测试，得到测试数据。这种应用程序测试方式，无需开发人员对待测应用程序的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

在本实施例中，服务端设备可对待测应用程序的第一安装包进行重新打包，并在重新打包的过程中植入测试工具。进一步，如图1c所示，服务端设备在对待测应用程序的第一安装包进行重新打包时，可将待测应用程序的第一安装包和测试工具分别进行编译，得到第一安装包的源文件和测试工具的源文件。进一步，服务端设备可将测试工具的源文件注入第一安装包的源文件中，得到待测应用程序的第二安装包的源文件；进一步，服务端设备对待测应用程序的第二安装包的源文件进行重新编译，得到待测应用程序的第二安装包。其中，关于服务端设备对待测应用程序的第一安装包进行重新打包的具体实施方式可参见上述系统实施例的相关内容，在此不再赘述。

在另一些实施例中，服务端设备在测试终端运行第二安装包之前，还可响应于测试人员提交测试指令的操作，将测试指令发送于测试终端，该测试指令包含对象标识和插件标识，以供测试终端根据测试指令对第一安装包进行测试。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述服务端设备执行应用程序测试方法中的步骤。

本申请实施例除了提供应用程序测试方法之外，还提供适用于对任何可执行文件进行测试的方法，其中可执行文件可为网页、小程序等对应的可执行文件，但不限于此。下面分别从测试终端和服务端设备的角度，对本申请实施例提供的可执行文件测试方法进行示例性说明。

图5a为本申请实施例提供的一种可执行文件测试方法的流程示意图。该方法适用于测试终端。如图5a所示，该方法包括：

501、运行原始可执行文件对应的目标可执行文件；该目标可执行文件是向所述原始可执行文件中植入测试工具后的文件。

502、在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试。

在本实施例中，测试终端可以是智能手机、平板电脑、个人电脑、穿戴设备等。其中，原始可执行文件为开发人员所开发的面向普通用户的安装包，目标可执行文件为测试人员根据自己的测试需求向原始可执行文件中植入对应的测试工具后形成的可执行文件。

在本实施例中，待测应用程序可以为网页或小程序。其中，待测应用程序的实现形态不同，测试终端的实现形式也就不同。若待测应用程序为适用于智能手机、可穿戴设备的小程序或网页，则测试终端可以为智能手机、可穿戴设备等；若待测应用程序为适用于台式电脑、笔记本等的网页，则测试终端可以为台式电脑、笔记本电脑等等，但不限于此。

在本实施例中，测试终端存储有目标可执行文件。测试终端可运行目标可执行文件，并在运行目标可执行文件的过程中，利用目标可执行文件中的测试工具对原始可执行文件进行测试，进而得到测试数据。其中，关于测试工具的实现形式以及利用测试工具对原始可执行文件进行测试的具体实施方式，均可参见上述利用测试工具对待测应用程序的第一安装包进行测试的相关内容，在此不再赘述。

可选地，测试终端可将得到的测试数据发送给服务端设备。相应地，服务端设备接收测试数据，并基于该测试数据对原始可执行文件的性能进行分析，以使测试人员可了解待测应用程序的原始可执行文件的性能。进一步，测试人员可将测得的原始可执行文件的性能反馈给开发人员，以使开发人员能够对原始可执行文件进行优化，等等，但不限于此。

在本实施例中，服务端设备可以为单一服务器设备，也可以云化的服务器阵列，或者为云化的服务器阵列中运行的虚拟机(Virtual Machine，VM)。另外，服务端设备也可以指具备相应服务能力的其他计算设备，例如电脑等终端设备(运行服务程序)等，例如测试人员的电脑等等。

基于此，对于可执行文件为适应于电脑、工作站等的客户端的情况，测试终端也可为测试人员所使用的电脑。在这种情况下，测试终端可基于该测试数据对原始可执行文件的性能进行分析，以使测试人员可了解原始可执行文件的性能。进一步，测试人员可将测得的原始可执行文件的性能反馈给开发人员，以使开发人员能够对原始可执行文件的第一安装包进行优化，等等，但不限于此。

在本实施例中，在原始可执行文件中植入测试工具，形成目标可执行文件。这样，测试终端便可在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试，得到测试数据。这种可执行文件测试方式，无需开发人员对可执行文件的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

在一种实施例中，若目标可执行文件是由服务端设备对待测应用程序的第一安装包进行重新打包形成的，则在步骤501之前，服务端设备将目标可执行文件下发给测试终端。相应地，测试终端接收目标可执行文件，并运行目标可执行文件。

在另一种实施例中，若目标可执行文件是由测试终端对原始可执行文件进行重新打包形成的，则在步骤501之前，测试终端还可对原始可执行文件进行重新打包。其中，测试终端对原始可执行文件进行重新打包的主要步骤如下：

S1：将原始可执行文件和测试工具分别进行编译，得到原始可执行文件的源文件和测试工具的源文件。

S2：将测试工具的源文件注入原始可执行文件的源文件中，得到目标可执行文件的源文件。

S3：对目标可执行文件的源文件进行重新编译，得到目标可执行文件。

其中，本实施例中步骤S1-S3的具体实施方式均可参见上述对待测应用程序的第一安装包进行重新打包的相关内容，在此不再赘述。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述测试终端执行可执行文件测试方法中的步骤。

图5b为本申请实施例提供的另一种可执行文件的测试方法的流程示意图。该方法适用于服务端设备。如图5b所示，该方法包括：

S501、获取原始可执行文件对应的目标可执行文件；目标可执行文件是向原始可执行文件植入测试工具后的文件。

S502、将目标可执行文件发送给测试终端，以供测试终端在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试。

在本实施例中，服务端设备存储有目标可执行文件。基于此，服务端设备可获取目标可执行文件，并将目标可执行文件发送给测试终端。其中，目标可执行文件是向原始可执行文件植入测试工具后形成的文件。

可选地，服务端设备存储有多种可执行文件，其中包括本实施例提供的目标可执行文件。其中，多种是指2种或2种以上。进一步，服务端设备可存储可执行文件标识列表。测试人员可根据当前测试需求，从可执行文件标识列表中选择要测试的可执行文件。相应地，服务端设备响应于测试人员从可执行文件标识列表中选中可执行文件标识的操作，从本地存储的可执行文件中，获取与测试人员选定的可执行文件标识对应的可执行文件作为目标可执行文件。

相应地，测试终端接收服务端设备发送的目标可执行文件，并运行该目标可执行文件。进一步，由于目标可执行文件中植入有测试工具，则测试终端在运行目标可执行文件的过程中，可利用测试工具对原始可执行文件进行测试，进而得到测试数据。

可选地，测试终端可将得到的测试数据发送给服务端设备。相应地，服务端设备接收测试数据，并基于该测试数据对原始可执行文件的性能进行分析，以使测试人员可了解原始可执行文件的性能。进一步，测试人员可将测得的原始可执行文件的性能反馈给开发人员，以使开发人员能够对原始可执行文件的进行优化，等等，但不限于此。

在本实施例中，服务端设备在原始可执行文件中植入测试工具，形成目标可执行文件。这样，测试终端便可在目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试，得到测试数据。这种测试方式，无需开发人员对目标可执行文件的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

相应地，本申请实施例还提供一种存储有计算机指令的计算机可读存储介质，当计算机指令被一个或多个处理器执行时，致使一个或多个处理器执行上述服务端设备执行可执行文件测试方法中的步骤。

图6为本申请实施例提供的一种应用程序的安装包生成方法的流程示意图。如图6所示，该方法包括：

601、对应用程序的第一安装包进行编译，得到该应用程序的第一源文件。

602、将目标插件的源文件注入第一源文件中，以得到修改后的第一源文件。

603、对修改后的第一源文件进行重新编译，以得到应用程序的第二安装包。

在本实施例中，目标插件的源文件可以为对目标插件进行编译，得到的第一源文件；或者，目标插件本身可以源文件的形式提供给用户。

在本实施例中，将目标插件的源文件注入应用程序的第一源文件中，得到修改后的第一源文件，并对修改后的第一源文件进行重新编译，得到应用程序的第二安装包。这种应用程序的安装包生成方式，无需开发人员对应用程序的代码逻辑进行改造，可提高打包效率，进而有助于降低打包成本。

在一些实施例中，应用程序的第一安装包的源文件以及目标插件的源文件不仅包括相应的代码文件，还包括一些资源文件，例如应用程序和插件所涉及的图片、Lib库等，但不限于此。即应用程序的第一源文件包括源代码和资源文件；插件的源文件也包括插件的原始代码和资源文件。基于此，步骤603的另一种可选实施方式为：将目标插件的源文件中的原始代码注入第一源文件中的源代码中；并将目标插件的源文件中的资源文件注入编译得到的源文件中的资源文件中。其中，第一源文件中的源代码可以为原始代码、汇编代码或虚拟机字节码，但不限于此。

进一步，目标插件的源文件中的原始代码文件不仅包括该插件对应的实现其功能所需的应用代码，对于一些需要在启动过程中运行的插件还包括启动其功能的启动代码。同理，应用程序的源代码不仅包括实现应用程序的功能所需的应用代码，还包括启动实现该应用程序的功能的启动代码。基于此，在将目标插件的源文件中的原始代码注入第一源文件中的源代码中时，还可在源代码中查找应用程序的应用代码；并将目标插件的应用代码注入应用程序的应用代码中；以及在源代码中查找应用程序的启动代码，并将目标插件中的第一插件的启动代码注入应用程序的启动代码中；其中，第一插件为目标插件中的在启动过程中需要运行的插件。

值得说明的是，本申请实施例提供的应用程序的安装包生成发生可适用于各种应用场景中。用户可根据自己的需求，向应用程序中插入可满足其功能需求的插件。例如，在对应用程序进行测试的应用场景中，测试任务可根据测试需求，向将预设的测试工具的源文件注入待测应用程序的第一源文件中，得到修改后的第一源文件；并对修改后的第一源文件进行重新编译，得到待测应用程序的测试包。之后，便可运行该测试包，并在运行测试包的过程中，利用插入的测试工具对应用程序的第一安装包进行测试。其具体测试过程均可参见上述实施例的相关内容，在此不再赘述。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤401和402的执行主体可以为设备A；又比如，步骤401的执行主体可以为设备A，步骤402的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如401、402等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。

图7为本申请实施例提供的一种计算机设备的结构示意图。如图7所示，设备包括：存储器70a和处理器70b。

以下结合设备的不同实施例，对上述计算机设备的工作流程进行介绍。

第一、当计算机设备为终端设备时，存储器70a，用于存储待测应用程序的第二安装包和计算机程序；该第二安装包是对待测应用程序的第一安装包进行重新打包得到的，且第二安装包包含在重新打包过程中植入的测试工具。

处理器70b耦合至存储器70a，用于执行计算机程序以用于：运行待测应用程序的第二安装包；并在运行第二安装包的过程中，利用测试工具对第一安装包进行测试，以得到测试数据。

在一种实施例中，测试工具包括：至少一个测试插件。处理器70b在利用测试工具对第一安装包进行测试，具体用于：在运行第二安装包的过程中，利用至少一个测试插件对第一安装包进行测试，以得到测试数据。

进一步，处理器70b在利用至少一个测试插件对第一安装包进行测试时，具体用于：获取测试指令，该测试指令包含对象标识和插件标识；根据插件标识，从至少一个测试插件中确定目标测试插件；以及按照目标测试插件的测试逻辑，对第一安装包中与对象标识对应的待测对象进行测试。

可选地，若终端设备和服务端设备为不同的物理设备，则测试工具还包括：通信插件；相应地，处理器70b在获取测试指令时，具体用于：通过通信插件接收服务端设备发送的测试指令。可选地，通信插件是RPC插件。

在一些实施例中，测试工具还包括：钩子插件。其中，处理器70b在按照目标测试插件的测试逻辑对第一安装包中与对象标识对应的待测对象进行测试时，具体用于：在需要测试第一安装包的代码逻辑的情况下，调用钩子插件获取待测对象的运行状态数据；将运行状态数据提供给目标测试插件，并运行目标测试插件以测试待测对象对应的代码逻辑。

进一步，若目标测试插件包括内部状态测试插件，则处理器70b在调用钩子插件获取待测对象的运行状态数据时，具体用于：将待测对象的内部状态调整为目标状态，目标状态是要求待测对象在测试过程中保持的内部状态；调用钩子插件获取待测对象在目标状态下的运行状态数据。

其中，处理器70b在将待测对象的内部状态调整为目标状态时，具体用于：在钩子插件中包含内部状态修改指令的情况下，调用钩子插件将待测对象的内部状态修改为目标状态；在钩子插件中不包含状态修改指令的情况下，根据外部状态修改指令，将待测对象的内部状态修改为目标状态；其中，内部状态修改指令和外部状态修改指令中包含目标状态。

可选地，若目标测试插件包括方法测试插件，则处理器70b在调用钩子插件获取待测对象的运行状态数据时，具体用于：根据测试指令中的方法标识，确定与待测对象绑定的待测方法；在待测对象上模拟与待测方法绑定的触发操作，以使待测方法运行；利用钩子插件获取待测对象在待测方法运行过程中产生的运行状态数据。

可选地，若目标测试插件包括路径追踪插件，则处理器70b在调用钩子插件获取待测对象的运行状态数据时，具体用于：调用钩子插件获取待测对象在与其上下文对象进行调用过程中产生的运行状态数据。

可选地，若目标测试插件包括虚拟测试插件，则处理器70b在调用钩子插件获取待测对象的运行数据时，具体用于：利用虚拟测试插件产生虚拟测试所需的虚拟环境，并控制待测对象在虚拟环境中运行；利用钩子插件获取待测对象在虚拟环境下的运行状态数据，以供虚拟测试插件对待测对象进行虚拟测试。

在一些实施例中，若终端设备和服务端设备不是同一物理设备，则终端设备还包括：通信插件70c。处理器70b还用于：通过通信插件70c接收服务端设备下发的待测应用程序的第二安装包；以及通过通信插件70c将测试数据上报给服务端设备，以供服务端设备基于测试数据对第一安装包进行性能分析。

在另一些实施例中，终端设备和服务端设备为同一物理设备，例如测试人员的电脑等，终端设备还包括显示器70d。显示器70d可展示测试交互界面。处理器70b在运行待测应用程序的第二安装包之前，还用于：响应于测试人员从测试交互界面上的应用程序标识列表中选择应用程序标识的操作，从存储器70a中存储的应用程序的第二安装包中，获取与测试人员选定的应用程序标识对应的第二安装包作为待测应用程序的第二安装包。

在又一些实施例中，终端设备和服务端设备为同一物理设备，例如测试人员的电脑等。处理器70b还可对待测应用程序的第一安装包进行重新打包。相应地，处理器70b在对待测应用程序的第一安装包进行重新打包时，具体用于：将第一安装包和测试工具分别进行编译，得到第一安装包的源文件以及测试工具的源文件；将测试工具的源文件注入第一安装包的源文件中，得到第二安装包的源文件；对第二安装包的源文件进行重新编译，得到第二安装包。

相应地，处理器70b在将测试工具的源文件注入第一安装包的源文件中时，具体用于：将测试工具的源文件中的原始代码文件注入第一安装包的源文件中的代码文件中；将测试工具的源文件中的资源文件注入第一安装包的源文件中的资源文件中。

在本实施例中，在对待测应用程序的第一安装包进行重新打包的过程中植入测试工具，形成待测应用程序的第二安装包。这样，终端设备便可在运行待测应用程序的第二安装包的过程中，利用测试工具对第一安装包进行测试，得到测试数据。这种应用程序测试方式，无需开发人员对待测应用程序的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

第二，当图7所示的计算机设备为服务端设备时，服务端设备还包括通信组件70c。其中，存储器70a，用于存储待测应用程序的第二安装包和计算机程序。其中，第二安装包是对待测应用程序的第一安装包进行重新打包得到的，且第二安装包包含在重新打包过程中植入的测试工具。

处理器70b耦合至存储器70a，用于执行计算机程序以用于：从存储器70a中获取待测应用程序的第二安装包；并通过通信插件70c将第二安装包发送给测试终端，以供测试终端在运行第二安装包的过程中，利用测试工具对第一安装包进行测试。

在一些实施例中，服务端设备还用于对待测应用程序的第一安装包进行重新打包。相应地，处理器70b在对待测应用程序的第一安装包进行重新打包时，具体用于：将第一安装包和测试工具分别进行编译，得到第一安装包的源文件以及测试工具的源文件；将测试工具的源文件注入第一安装包的源文件中，得到第二安装包的源文件；对第二安装包的源文件进行重新编译，得到第二安装包。其中，处理器70b对待测应用程序的第一安装包进行重新打包的具体实施方式，可参见上述计算机设备为终端设备时，处理器70b对待测应用程序的第一安装包进行重新打包的相关内容，在此不再赘述。

在另一些实施例中，处理器70b在测试终端运行第二安装包之前，还用于：响应于测试人员提交测试指令的操作，通过通信插件将测试指令发送于测试终端，测试指令包含对象标识和插件标识，以供测试终端根据测试指令对第一安装包进行测试。可选地，通信插件为RPC插件。

本实施例提供的服务端设备，将包含测试工具的测应用程序的第二安装包提供给测试终端。这样，测试终端便可在运行待测应用程序的第二安装包的过程中，利用测试工具对第一安装包进行测试，得到测试数据。这种应用程序测试方式，无需开发人员对待测应用程序的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

第三、当图7所示的计算机设备为另一种终端设备时，其中，存储器70a，用于存储原始可执行文件对应的目标可执行文件和计算机程序；目标可执行文件是向原始可执行文件中植入测试工具后的文件。

处理器70b耦合至存储器70a，用于执行计算机程序以用于：运行目标可执行文件；并在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试。其中，处理器70b利用测试工具对原始可执行文件进行测试的具体实施方式可参见上述利用测试工具对第一安装包进行测试的相关内容，在此不再赘述。

在一些实施例中，处理器70b还用于向可执行文件的原始可执行文件中植入测试工具。进一步，处理器70b在向可执行文件的原始可执行文件中植入测试工具时，具体用于：将原始可执行文件和测试工具分别进行编译，得到原始可执行文件的源文件以及测试工具的源文件；将测试工具的源文件注入原始可执行文件的源文件中，得到目标可执行文件的源文件；对目标可执行文件的源文件进行重新编译，得到测试文件。其中，处理器70b向可执行文件的原始可执行文件中植入测试工具的具体实施方式可参见上述图7中处理器70b对第一安装包进行重新打包的相关内容，在此不再赘述。

在本实施例中，在原始可执行文件中植入测试工具，形成目标可执行文件。这样，终端设备便可在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试，得到测试数据。这种可执行文件测试方式，无需开发人员对可执行文件的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

第四，当图7为本申请实施例提供的另一种服务端设备时，存储器70a，用于存储原始可执行文件对应的目标可执行文件和计算机程序；该目标可执行文件是向原始可执行文件中植入测试工具后的文件。

处理器70b耦合至存储器70a，用于执行计算机程序以用于：从存储器70a中获取目标可执行文件；并通过通信组件70c将目标可执行文件发送给测试终端，以供测试终端在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试。

在一些实施例中，处理器70b还用于向原始可执行文件中植入测试工具。进一步，处理器70b在向原始可执行文件中植入测试工具时，具体用于：将原始可执行文件和测试工具分别进行编译，得到原始可执行文件的源文件以及测试工具的源文件；将测试工具的源文件注入原始可执行文件的源文件中，得到目标可执行文件的源文件；对目标可执行文件的源文件进行重新编译，得到目标可执行文件。

本实施例提供的服务端设备，将包含测试工具的目标可执行文件提供给测试终端。这样，测试终端便可在运行目标可执行文件的过程中，利用测试工具对原始可执行文件进行测试，得到测试数据。这种可执行文件测试方式，无需开发人员对原始可执行文件的代码逻辑进行改造，可提高测试效率，进而有助于降低测试成本。

第五，在一些实施例中，图7中的处理器70b还可用于：对应用程序的第一安装包进行编译，得到应用程序的第一源文件；将目标插件的源文件注入第一源文件中，以得到修改后的第一源文件；以及对第一源文件进行重新编译，以得到应用程序的第二安装包。

在一些实施例中，处理器70b在将目标插件的源文件注入第一源文件中时，具体用于：将目标插件的源文件中的原始代码注入第一源文件中的源代码中；并将目标插件的源文件中的资源文件注入第一源文件中的资源文件中。

进一步，处理器70b在将目标插件的源文件中的原始代码注入第一源文件中的源代码中时，具体用于：在源代码中查找应用程序的应用代码；并将目标插件的应用代码注入应用程序的应用代码中；以及在源代码中查找应用程序的启动代码，并将目标插件中的第一插件的启动代码注入应用程序的启动代码中；其中，第一插件为在启动过程中需要运行的插件。

在又一些实施例中，目标插件为测试工具。处理器70b在得到应用程序的第二安装包之后，还用于：运行第二安装包；并在运行第二安装包的过程中，利用测试工具对第一安装包进行测试，以得到测试数据。其中，处理器70b利用测试工具对第一安装包进行测试的具体实施方式可参见上述实施例的相关内容，在此不再赘述。

在其它一些实施例中，若计算机设备和服务端设备不是同一物理设备，则计算机设备可为终端设备，还包括：通信组件70c。处理器70b还用于：通过通信组件70c接收服务端设备下发的待测应用程序的第二安装包；以及通过通信组件70c将测试数据上报给服务端设备，以供服务端设备基于测试数据对第一安装包进行性能分析。

在另一些实施例中，计算机设备和服务端设备为同一物理设备，例如测试人员的电脑等，计算机设备还包括显示器70d。显示器70d可展示测试交互界面。处理器70b在运行待测应用程序的第二安装包之前，还用于：响应于测试人员从测试交互界面上的应用程序标识列表中选择应用程序标识的操作，从存储器70a中存储的应用程序的第二安装包中，获取与测试人员选定的应用程序标识对应的第二安装包作为待测应用程序的第二安装包。

本实施例提供的计算机设备，可将目标插件的源文件注入应用程序的第一源文件中，得到修改后的第一源文件，并对修改后的第一源文件进行重新编译，得到应用程序的第二安装包。这种应用程序的安装包生成方式，无需开发人员对应用程序的代码逻辑进行改造，可提高打包效率，进而有助于降低打包成本。

本申请实施例提供的计算机设备，还可包括：电源组件70c。若计算机设备为终端设备，例如电脑等，计算机设备还可包括：音频组件70f等可选组件。图7中仅示意性给出部分组件，并不意味着服务端设备必须包含图7所示全部组件，也不意味着服务端设备只能包括图7所示组件。

在本申请实施例中，存储器用于存储计算机程序，并可被配置为存储其它各种数据以支持在其所在设备上的操作。其中，处理器可执行存储器中存储的计算机程序，以实现相应控制逻辑。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本申请实施例中，通信插件被配置为便于其所在设备和其他设备之间有线或无线方式的通信。通信插件所在设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，4G，5G或它们的组合。在一个示例性实施例中，通信插件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信插件还可基于近场通信(NFC)技术、射频识别(RFID)技术、红外数据协会(IrDA)技术、超宽带(UWB)技术、蓝牙(BT)技术或其他技术来实现。

在本申请实施例中，显示器可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

在本申请实施例中，电源组件被配置为其所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

在本申请实施例中，音频组件可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信插件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。例如，对于具有语言交互功能的电子设备，可通过音频组件实现与用户的语音交互等。

需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (19)

1.一种安装包生成系统，其特征在于，包括：用户界面模块、基础服务模块和打包服务模块；

所述用户界面模块，用于展示安装包输入组件和插件输入组件；

所述基础服务模块，用于基于所述安装包输入组件提供的第一安装包和所述插件输入组件提供的目标插件，获取所述第一安装包的打包服务基础信息；

所述打包服务模块，用于基于所述第一安装包的打包服务基础信息，对所述第一安装包进行重新打包，并在重新打包的过程中注入所述目标插件，以生成所述应用程序的第二安装包。

2.根据权利要求1所述的系统，其特征在于，所述基础服务模块包括：应用管理单元、插件管理单元和打包任务管理单元；

其中，所述应用管理单元，用于根据所述第一安装包的标识，获取所述第一安装包对应的应用程序的基本信息以及所述应用程序与插件配置之间的关联关系；

所述插件管理单元，用于根据所述第一安装包的标识和所述目标插件的标识，获取目标插件以及所述应用程序的固有插件的基本信息及配置参数；

所述打包任务管理单元，用于向所述打包服务模块提供所述第一安装包的打包服务基础信息，并触发所述打包服务模块对所述第一安装包进行重新打包。

3.根据权利要求1所述的系统，其特征在于，所述插件输入组件包括：基础插件选择组件，以供所述用户通过所述基础插件选择组件选择目标基础插件。

4.根据权利要求3所述的系统，其特征在于，所述打包服务模块，所述打包服务模块包括：打包处理模块和基础插件库；

所述打包处理模块，用于根据所述用户选择的目标基础插件的标识，从所述基础插件库中获取所述目标基础插件，作为所述目标插件。

5.根据权利要求1所述的系统，其特征在于，所述插件输入组件包括：自定义插件输入组件，以供所述用户通过所述自定义插件输入组件输入自定义插件；

所述打包服务模块还用于：将所述用户输入的自定义插件作为所述目标插件。

6.根据权利要求3所述的系统，其特征在于，所述插件输入组件还包括：自定义插件输入组件，以供所述用户通过所述自定义插件输入组件输入自定义插件。

7.根据权利要求6所述的系统，其特征在于，所述打包服务模块，所述打包服务模块包括：打包处理模块和基础插件库；

所述打包处理模块，用于根据所述用户选择的目标基础插件的标识，从所述基础插件库中获取所述目标基础插件，并将所述目标基础插件和所述自定义插件作为所述目标插件。

8.根据权利要求1所述的系统，其特征在于，所述基础服务模块还包括：设备管理单元；

其中，所述设备管理单元，用于管理使用所述安装包生成系统的设备列表，并负责与使用所述安装包生成系统的设备进行交互。

9.根据权利要求8所述的系统，其特征在于，所述目标插件包括：通信插件；

所述设备管理单元在与使用所述安装包生成系统的设备进行交互时，具体用于：通过所述通信插件调用终端设备安装并运行所述第二安装包；其中，所述设备列表包括所述终端设备的标识。

10.根据权利要求9所述的系统，其特征在于，所述基础服务模块还包括：数据管理单元；

所述数据管理单元，用于接收所述终端设备在运行所述第二安装包的过程中上报的数据，并对接收到的数据进行分析和/或将所述接收到的数据提供给所述用户界面模块，以供所述用户界面模块进行展示。

11.根据权利要求9所述的方法，其特征在于，所述目标插件还包括：测试工具；

所述设备管理单元还用于：在调用所述终端设备运行所述第二安装包的过程中，控制所述终端设备利用所述测试工具对所述第一安装包进行测试，以得到测试数据。

12.根据权利要求11所述的系统，其特征在于，所述测试工具包括：至少一个测试插件；所述设备管理单元在控制所述终端设备利用所述测试工具对所述第一安装包进行测试时，具体用于：

通过所述通信插件控制所述终端设备根据测试指令中的插件标识，从所述至少一个测试插件中确定目标测试插件；以及控制所述终端设备按照所述目标测试插件的测试逻辑，对所述第一安装包中与所述测试指令中的对象标识对应的待测对象进行测试。

13.根据权利要求12所述的系统，其特征在于，所述测试工具还包括：钩子插件；所述设备管理单元在控制所述终端设备按照所述目标测试插件的测试逻辑对所述第一安装包中与所述对象标识对应的待测对象进行测试时，具体用于：

在需要测试所述第一安装包的代码逻辑的情况下，通过所述通信插件控制所述终端设备调用所述钩子插件获取所述待测对象的运行状态数据；以及控制所述终端设备将所述运行状态数据提供给所述目标测试插件，并运行所述目标测试插件以测试所述待测对象对应的代码逻辑。

14.根据权利要求13所述的系统，其特征在于，若所述目标测试插件包括内部状态测试插件，则所述设备管理单元在控制所述终端设备调用所述钩子插件获取所述待测对象的运行状态数据时，具体用于：

通过所述通信插件控制所述终端设备将所述待测对象的内部状态调整为目标状态，所述目标状态是要求所述待测对象在测试过程中保持的内部状态；并控制所述终端设备调用所述钩子插件获取所述待测对象在所述目标状态下的运行状态数据。

15.根据权利要求14所述的系统，其特征在于，所述设备管理单元在控制所述终端设备将所述待测对象的内部状态调整为目标状态时，具体用于：

在所述钩子插件中包含内部状态修改指令的情况下，通过所述通信插件控制所述终端设备调用所述钩子插件将所述待测对象的内部状态修改为所述目标状态；

在所述钩子插件中不包含状态修改指令的情况下，通过所述通信插件控制所述终端设备根据外部状态修改指令将所述待测对象的内部状态修改为所述目标状态；

其中，所述内部状态修改指令和所述外部状态修改指令中包含所述目标状态。

16.根据权利要求13所述的系统，其特征在于，若所述目标测试插件包括方法测试插件，则所述设备管理单元在控制所述终端设备调用所述钩子插件获取所述待测对象的运行状态数据时，具体用于：

控制所述终端设备根据所述测试指令中的方法标识，确定与所述待测对象绑定的待测方法；并控制所述终端设备在所述待测对象上模拟与所述待测方法绑定的触发操作，以使所述待测方法运行；以及控制所述终端设备利用所述钩子插件获取所述待测对象在所述待测方法运行过程中产生的运行状态数据。

17.根据权利要求13所述的系统，其特征在于，若所述目标测试插件包括路径追踪插件，则所述设备管理单元在控制所述终端设备调用所述钩子插件获取所述待测对象的运行状态数据时，具体用于：

通过所述通信插件控制所述终端设备调用所述钩子插件获取所述待测对象在与其上下文对象进行调用过程中产生的运行状态数据。

18.根据权利要求13所述的系统，其特征在于，若所述目标测试插件包括虚拟测试插件，则所述设备管理单元在控制所述终端设备调用所述钩子插件获取所述待测对象的运行数据时，具体用于：

通过所述通信插件控制所述终端设备利用虚拟测试插件产生虚拟测试所需的虚拟环境，并控制所述待测对象在所述虚拟环境中运行；并控制所述终端设备利用所述钩子插件获取所述待测对象在所述虚拟环境下的运行状态数据，以供所述虚拟测试插件对待测对象进行虚拟测试。

19.根据权利要求9-18任一项所述的系统，其特征在于，所述通信插件为RPC插件。

Images