CN109815142B - 一种产品测试方法和装置 - Google Patents

Abstract

本说明书实施例公开了一种产品测试方法和装置，用以解决现有技术中存在的无法对产品进行整体测试的问题。本说明书的方法主要包括：基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，模块代码集合对应所述多个模块的模块代码，测试代码集合对应多个模块中每个模块的测试用例的测试用例代码；将模块代码集合中的模块代码以及测试代码集合中的测试代码分别建立与目标产品的依赖关系；基于预设的编译指令，分别对与目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；基于测试安装包对产品安装包进行测试。从而，可以将模块代码与测试代码视为同一目录级别，实现对产品的整体测试。

Description

一种产品测试方法和装置

技术领域

本说明书涉及计算机软件技术领域，尤其涉及一种产品测试方法和装置。

背景技术

目前，业界所常用的自动化测试方法主要包括：黑盒测试与白盒测试。黑盒测试的测试人员不需要关注代码的测试方法，多为测试人员的测试工作，而白盒测试多为开发者针对代码，编写的单元或模块测试用例。黑盒测试保证的是用户使用功能正常，而白盒测试保证程序执行的每个函数，执行逻辑都与预期结果相同。

然而，针对白盒测试而言，目前只能针对模块进行单独测试，即每个模块基于各自对应的测试用例进行独立测试，而无法对所有模块组装之后的产品进行整体测试。这样的结果会导致产品的每个模块可以在整合之前独立正常运行，但是，在所有模块整合为产品之后，由于接入问题、兼容问题以及考虑不周全的情况而导致产品整体功能无法正常运行。

由此，如何使用白盒测试对产品进行整体测试成为亟待解决的技术问题。

发明内容

本说明书实施例的目的是提供一种产品测试方法和装置，用以解决现有技术中无法实现对产品的整体测试的问题。

为解决上述技术问题，本说明书实施例是这样实现的：

第一方面，提出了一种产品测试方法，包括：

基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

基于所述测试安装包对所述产品安装包进行测试。

第二方面，提出了一种产品测试装置，包括：

代码集合生成模块，用于基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

依赖关系建立模块，用于将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

安装包生成模块，用于基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

测试模块，用于基于所述测试安装包对所述产品安装包进行测试。

第三方面，提出了一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：

基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

基于所述测试安装包对所述产品安装包进行测试。

第四方面，提出了一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：

基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

基于所述测试安装包对所述产品安装包进行测试。

由本说明书实施例提供的以上技术方案可见，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试，提高了测试效率。

附图说明

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

图1是本说明书的一个实施例提供的现有技术中模块测试的原理示意图。

图2是本说明书的一个实施例提供的产品测试方法的步骤示意图之一。

图3是本说明书的一个实施例提供的步骤202在基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合时的具体步骤示意图。

图4是本说明书的一个实施例提供的测试结果以UI界面的形式展示的示意图。

图5是本说明书的一个实施例提供的产品测试方案的流程示意图。

图6是本说明书的再一个实施例提供的产品测试方法的步骤示意图之二。

图7是本说明书的一个实施例提供的产品测试装置的结构示意图。

图8是本说明书的一个实施例提供的产品测试设备的结构示意图。

具体实施方式

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

需要说明的是，模块测试即为单元测试，参照图1所示，为现有技术中模块测试的原理示意图。一般情况下，针对产品所包含的每个模块，都编写有相应的模块代码以及测试用例，例如，模块1对应模块代码1和测试用例1，模块2对应模块代码2和测试用例2，……，模块n对应模块代码n和测试用例n。在测试阶段，多个模块之间只能进行独立的测试，例如，模块1-模块n分别进行单独的测试，即模块1对应的测试用例1生成功能模块测试apk，模块1对应的模块代码1生成功能模块apk，执行者(发布者或是测试人员)基于功能模块测试apk对功能模块apk进行测试。这样，在测试用例通过的时候，可以保证每个模块单独运行，但是，当所测试的这n个模块组成所要发布的产品后，就没有办法保证产品可以正常运行。

这样就需要将所有模块整合在一起，然而，目前的测试方案无法保证产品进行整体测试，因此，本说明书实施例提出了一种新的产品测试方案，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试。

实施例一

参照图2所示，为本说明书实施例提供的产品测试方法的步骤示意图，该产品测试方法的执行主体可以是具有编程语言执行能力的计算机设备，例如，电脑、手机、智能穿戴设备、IPad等。该产品测试方法可以包括以下步骤：

步骤202：基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码。

所述目标产品可以是开发的由多个代码语言以及虚拟模块组成的各类计算机、网络产品，例如，APP，网站、各类集成有软件设备的硬件设备等，本说明书实施例并不对此进行限定。

应理解，传统的模块开发过程中，尤其是在打包时，仅打包一个产物，即模块代码集合，例如module.aar；而区别于现有技术的是，本说明书实施例该步骤202会打包两个产物，即模块代码集合和测试代码集合，例如：module.aar和moduleTest.aar。而且，针对现有技术中的模块代码集合，其应该是某一个模块的所有代码集合。而本步骤202中模块代码集合，是目标产品的所有模块的代码集合；测试代码集合，是目标产品的所有模块对应的测试用例的代码集合。

其中，模块代码集合和/或测试代码集合作为打包产物，其格式后缀可以是aar，也可以是例如jar等其它格式后缀，本说明书实施例并不对此进行限定。

可选地，在本说明书实施例中，参照图3所示，步骤202在基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合时，可具体执行为以下步骤：

步骤302：基于目标产品开发的多个模块，将目录结构中测试用例对应的目录修改为与模块目录并列的测试用例目录。

其实，在针对目标产品开发模块时，并不对模块的开发进行干预，而可以对测试用例的开发进行干预，即调整该目标产品的目录结构。具体实现时，并不对目录结构中模块目录进行修改，而仅是对原来附属在模块目录下，作为模块目录的子目录的测试用例对应的目录进行调整，将测试用例对应的目录修改为与模块目录的目录级别并列的测试用例目录。这样，不再将测试用例视为模块的一部分，而是将测试用例视为与模块并列的同一级别。

步骤304：建立所述测试用例目录与所述模块目录的依赖关系。

应理解，在对目录结构进行调整之后，改变了测试用例对应的目录与模块目录的级别关系，而为了保证后续可以正常调用修改后的目录结构，还需要利用依赖方法，建立所述测试用例目录与所述模块目录的依赖关系。

本说明书实施例所涉及的依赖方法可以是基于预设依赖格式或是预设依赖语句执行，例如，“implementation”依赖语句，其实还可以通过其它依赖语句，本说明书实施例在此不做赘述。

步骤306：基于调整后的目录结构，生成模块代码集合以及测试代码集合。

可选地，在生成测试代码集合时，除了将目标产品的所有模块对应的测试代码打包到一起，还包括：

生成适配不同产品测试场景的测试属性库；其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

应理解，在针对单个模块进行测试时，其模块场景有限，然而，在针对由多个模块组成的目标产品进行测试时，其产品测试场景会很多，因此，为了适配不同产品测试场景，可以基于进程差异化、线程逻辑差异化等产品表现形态生成对应不同测试场景的测试属性，然后创建包含多个测试属性的测试属性库。从而，可以在后续测试时，适配不同的产品测试场景。

步骤204：将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系。

可选地，步骤204在将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系时，可具体执行为以下步骤：

第一步，基于预设第一依赖格式，建立所述模块代码集合中的模块代码与所述目标产品之间的依赖关系；

第二步，基于预设第二依赖格式，建立所述测试代码集合中的测试代码与所述目标产品之间的依赖关系；

其中，所述预设第一依赖格式与所述预设第二依赖格式相同或不同。

具体地实现时，可以提取出模块开发过程中打包得到的模块代码集合中的模块代码，以及测试代码集合中的测试代码，在主工程下，分别基于各自对应的依赖方法，建立模块依赖：即模块代码集合中的模块代码与目标产品之间的依赖关系，以及建立测试依赖：即测试代码集合中的测试代码与所述目标产品之间的依赖关系。

应理解，在该步骤204中，第一步与第二步的执行顺序并不作限定，可以先执行第一步的依赖关系建立操作，再执行第二步的依赖关系建立操作；也可以先执行第二步的依赖关系建立操作，再执行第一步的依赖关系建立操作；或者，也可以同时执行第一步的依赖关系建立操作和第二步的依赖关系建立操作。

而预设第一依赖格式可以与步骤304中的依赖格式类似，同理，预设第二依赖格式也可以与步骤304中所涉及的依赖格式类似。

步骤206：基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包。

具体实现时，可以基于预设的编译指令，分别打包出待发布的产品安装包以及与该产品安装包对应的测试安装包。其中，所述产品安装包是基于预设的编译指令，对与所述目标产品建立依赖关系的模块代码(模块代码集合中的所有模块代码)进行解析生成；所述测试安装包是基于预设的编译指令，对与所述目标产品建立依赖关系的测试代码(测试代码集合中的所有测试代码)进行解析生成。

应理解，本说明书实施例并不对预设的编译指令的格式进行限定，可以是例如“grade assemble AndroidTest”的编译指令格式。

步骤208：基于所述测试安装包对所述产品安装包进行测试。

可选地，在本说明书实施例中，步骤208在基于所述测试安装包对所述产品安装包进行测试时，可以具体执行为以下步骤：

第一步，安装所述测试安装包以及产品安装包。

具体实现时，可以在本设备上安装待发布的产品安装包以及测试安装包，其实，也可以在本设备以外的可以执行安装、测试功能的计算机设备上安装。例如，目标产品是手机APP，那么，可以将该产品安装包以及测试安装包安装到相应的测试手机上。再如，目标产品是电脑APP，那么，可以将该产品安装包以及测试安装包安装到相应的测试电脑上。

第二步，运行预设的测试指令，对所述目标产品进行整体测试。

具体实现时，可以运行预设的测试指令，基于安装好的测试安装包对产品安装包对应的目标产品进行整体测试。

可选地，在进行整体测试时，还可以从测试属性库中选择适配当前产品测试场景的测试属性，并基于该测试属性，对目标产品进行整体测试。

例如，产品测试场景为进入首页，那么，在对目标产品基于该产品测试场景进行测试时，可以选择进入首页的方法对应的测试属性。

可选地，本说明书实施例中，在对目标产品进行整体测试完成后，所述产品测试方法还包括：

输出并展示测试结果；其中，所述测试结果以命令行或UI界面的形式展示。

应理解，在输出并展示测试结果时，具体可以通过工具或是命令行进行调取，查看测试结果。而工具或是命令行的格式可以C++语言，或是其它可实现的编程语言。本说明书实施例并不对此进行限定。

具体地，参照图4所示，为测试结果以UI界面的形式展示的示意图，该示意图中，左边框中展示了调取语句，以及测试项，右边框中展示了测试结果，其中，该图4所示该产品的测试项中第一个测试场景以及第三个测试场景测试成功，而第二个测试场景测试失败。

在本说明书实施例上述技术方案中，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试。

进一步，参照图5所示，为本说明书实施例所涉及的产品测试方案的流程示意图，该图5中示出的目标产品中包含有9个模块，每个模块对应有相应的模块代码以及测试用例，经过本说明书实施例中的目录结构调整以及依赖关系的处理，在经过编译之后，得到产品安装包apk和测试安装包apk；之后，执行者可以将该产品安装包apk以及测试安装包apk安装到相应的执行设备上，运行测试指令，基于测试安装包apk对目标产品进行线上测试，并在测试无误后，发布产品安装包。

其实，在本说明书实施例中，所测试的产品安装包与待发布的产品安装包是相同的，在对产品安装包进行测试没有问题后，可以将该产品安装包发布，供用户安装使用。

下面通过具体的实例对本说明书实施例所涉及的产品测试方案进行详述。

参照图6所示，该产品测试方法可以是对应用在手机上的游戏APP这一目标产品进行测试，并在测试通过后进行发布。

具体可以参照图6所示的以下步骤：

步骤602：开发游戏APP的模块。

假设该游戏APP中包含6个模块，那么，可以按照现有的开发方式，开发得到6个模块，即可以编译得到6个模块对应的模块代码：模块代码1-模块代码6。

步骤604：修改目录结构中模块目录与测试用例目录的级别关系。

具体地，参照以下传统目录结构：

——Module

————src

———————AndroidTest

———————main

其中，Module目录(模块目录)可以视为一级目录，该Module目录下面又包含二级目录，即src目录(代码目录)；该src目录下面又包含三级目录：AndroidTest目录(测试代码目录)、main目录(模块代码目录)。由此可知，AndroidTest目录与main目录是作为三级目录并列存在于Module目录下面的，即测试用例是依附在模块下的，属于模块的一部分。

为了改变现有的这种附属关系，可以将测试用例调整为与模块并列的目录结构。具体参照以下本说明书实施例修改后的目录结构：

——Module

————src

———————main

——ModuleTest

————src

———————main(之前的AndroidTest中的代码)

其中，ModuleTest目录(测试用例目录)为与Module目录(模块目录)同一级别的一级目录；在Module目录下面包含二级目录：即src目录(代码目录)；该src目录下面又包含三级目录：main目录(模块代码目录)；同理，在ModuleTest目录下面包含二级目录：即src目录(代码目录)；该src目录下面又包含三级目录：main目录(测试代码目录)。这样，ModuleTest目录与Module目录成为并列存在的目录。

步骤606：建立所述测试用例目录与所述模块目录的依赖关系。

由于在步骤605中改变了目录结构，即将测试用例目录修改为与模块目录并列的目录形式。为了便于后续在测试时模块依然可以正常调用测试用例进行测试，需要建立测试用例目录与模块目录之间的依赖关系。

具体参照以下依赖格式：

“moduleTest implementation‘module'”

从而，建立ModuleTest目录与Module目录之间的依赖关系。

步骤608：生成模块代码集合以及测试代码集合。

其实，相应地，还可以编译得到与这6个模块对应的测试用例：测试用例1-测试用例6。而在编译这6个测试用例时，需要基于上述调整后的目录结构中测试用例目录，编译相应的测试用例。

具体地，可以基于调整后的目录结构，打包生成模块代码集合，例如：module.aar，以及测试代码集合，例如：moduleTest.aar。

其实，该过程可以理解为是模块编译过程，将各个模块对应的模块代码编译打包生成模块代码集合，以及，将各个模块对应的测试用例的测试代码编译打包生成测试代码集合。

步骤610：生成适配不同产品测试场景的测试属性库。

其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

步骤612：分别建立所述模块代码集合中的模块代码与所述目标产品的依赖关系，以及所述测试代码集合中的测试代码与所述目标产品的依赖关系。

具体地，基于步骤608打包生成的模块代码集合以及测试代码集合，在主工程状态下，使用以下依赖格式：

“implementation”

分别建立模块代码集合中的模块代码与所述目标产品的依赖关系，以及所述测试代码集合中的测试代码与所述目标产品的依赖关系。

例如：“androidTestImplementation‘moduleTest.aar’

implementation‘module.aar'”。

在针对模块1建立依赖关系时，可以编写依赖格式为：

“androidTestImplementation‘moduleTest1.aar’

implementation‘module1.aar'”；

在针对模块2建立依赖关系时，可以编写依赖格式为：

“androidTestImplementation‘moduleTest2.aar’

implementation‘module2.aar'”；

在针对模块n建立依赖关系时，可以编写依赖格式为：

“androidTestImplementation‘moduleTestn.aar’

implementation‘modulen.aar'”。

步骤614：基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包。

具体地，该步骤614可以基于以下编译指令格式：

“grade assemble AndroidTest”

分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，分别打包生成两个apk文件，例如，可以分别为release.apk与releaseTest.apk；其中，release.apk可以为产品安装包，releaseTest.apk可以为测试安装包。

步骤616：安装所述测试安装包以及产品安装包。

具体地，可以将生成的产品安装包以及测试安装包，通过以下安装指令：

“adb install release.apk

adb install releaseTest.apk”

安装到相应的执行设备上，例如，安装到手机上，或安装到电脑上。

步骤618：运行预设的测试指令，对所述目标产品进行整体测试。

具体地，预设的测试指令可以指令格式可以参考如下：

“adb shell aminstrument-w-r-e debug false-e class

‘path1’packageTest/androidx.test.runner.AndroidJUnitRunner”

其中，path1为测试目标产品时对应的路径，packageTest为生成的测试安装包对应的apk包名。

步骤620：输出并展示测试结果。

具体地，可以通过相应调用工具或者命令行，输出并展示测试结果。其中，所述测试结果以命令行或UI界面的形式展示。

在本说明书实施例上述技术方案中，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试。

实施例二

图7为本说明书的一个实施例提供的产品测试装置700的结构示意图。请参考图7，在一种软件实施方式中，所述产品测试装置700可包括：

代码集合生成模块702，用于基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

依赖关系建立模块704，用于将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

安装包生成模块706，用于基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

测试模块708，用于基于所述测试安装包对所述产品安装包进行测试。

在本说明书实施例上述技术方案中，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试。

可选地，作为一个实施例，所述代码集合生成模块702在基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合时，具体用于：

基于目标产品开发的多个模块，将目录结构中测试用例对应的目录修改为与模块目录并列的测试用例目录；

建立所述测试用例目录与所述模块目录的依赖关系；

基于调整后的目录结构，生成模块代码集合以及测试代码集合。

本说明书实施例所涉及的依赖方法可以是基于预设依赖格式或是预设依赖语句执行，例如，“implementation”依赖语句，其实还可以通过其它依赖语句，本说明书实施例在此不做赘述。

应理解，本说明书实施例并不对预设的编译指令的格式进行限定，可以是例如“grade assemble AndroidTest”的编译指令格式。

在本说明书实施例的再一种具体实现方式中，所述代码集合生成模块702在生成测试代码集合时，还用于：

生成适配不同产品测试场景的测试属性库；其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

在本说明书实施例的再一种具体实现方式中，依赖关系建立模块704在将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系时，具体用于：

基于预设第一依赖格式，建立所述模块代码集合中的模块代码与所述目标产品之间的依赖关系；

基于预设第二依赖格式，建立所述测试代码集合中的测试代码与所述目标产品之间的依赖关系；

其中，所述预设第一依赖格式与所述预设第二依赖格式相同或不同。

应理解，预设第一依赖格式可以与建立所述测试用例目录与所述模块目录的依赖关系时所涉及的依赖格式类似，同理，预设第二依赖格式也可以与建立所述测试用例目录与所述模块目录的依赖关系时所涉及的依赖格式类似。

在本说明书实施例的再一种具体实现方式中，所述测试模块708在基于所述测试安装包对所述产品安装包进行测试时，具体用于：

安装所述测试安装包以及产品安装包；

运行预设的测试指令，对所述目标产品进行整体测试。

在本说明书实施例的再一种具体实现方式中，所述产品测试装置700还包括：

输出模块，用于输出并展示测试结果；

其中，所述测试结果以命令行或UI界面的形式展示。

应理解，在输出并展示测试结果时，具体可以通过工具或是命令行进行调取，查看测试结果。而工具或是命令行的格式可以C++语言，或是其它可实现的编程语言。本说明书实施例并不对此进行限定。

其实，本说明书实施例的产品测试装置还可执行图1-图6中产品测试装置(或设备)执行的方法，并实现产品测试装置(或设备)在图1-图6所示实施例的功能，在此不再赘述。

实施例三

本申请实施例还提供了一种产品测试设备，图8为本申请实施例提供的产品测试设备的结构示意图。如图8所示，产品测试设备可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上的处理器801和存储器802，存储器802中可以存储有一个或一个以上存储应用程序或数据。其中，存储器802可以是短暂存储或持久存储。存储在存储器802的应用程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对产品测试设备中的一系列计算机可执行指令。更进一步地，处理器801可以设置为与存储器802通信，在产品测试设备上执行存储器802中的一系列计算机可执行指令。产品测试设备还可以包括一个或一个以上电源803，一个或一个以上有线或无线网络接口804，一个或一个以上输入输出接口805，一个或一个以上键盘806等。

在一个具体的实施例中，产品测试设备包括存储器、处理器和存储在所述存储器上并可在所述处理器上运行的计算机可执行指令，所述计算机可执行指令被所述处理器执行时实现以下流程：

基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

基于所述测试安装包对所述产品安装包进行测试。

可选地，所述计算机可执行指令被所述处理器执行时，基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合，具体包括：

基于目标产品开发的多个模块，将目录结构中测试用例对应的目录修改为与模块目录并列的测试用例目录；

建立所述测试用例目录与所述模块目录的依赖关系；

基于调整后的目录结构，生成模块代码集合以及测试代码集合。

本说明书实施例所涉及的依赖方法可以是基于预设依赖格式或是预设依赖语句执行，例如，“implementation”依赖语句，其实还可以通过其它依赖语句，本说明书实施例在此不做赘述。

应理解，本说明书实施例并不对预设的编译指令的格式进行限定，可以是例如“grade assemble AndroidTest”的编译指令格式。

可选地，所述计算机可执行指令被所述处理器执行时，在生成测试代码集合时，还包括：

生成适配不同产品测试场景的测试属性库；其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

可选地，所述计算机可执行指令被所述处理器执行时，将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系，具体包括：

基于预设第一依赖格式，建立所述模块代码集合中的模块代码与所述目标产品之间的依赖关系；

基于预设第二依赖格式，建立所述测试代码集合中的测试代码与所述目标产品之间的依赖关系；

其中，所述预设第一依赖格式与所述预设第二依赖格式相同或不同。

应理解，预设第一依赖格式可以与建立所述测试用例目录与所述模块目录的依赖关系时所涉及的依赖格式类似，同理，预设第二依赖格式也可以与建立所述测试用例目录与所述模块目录的依赖关系时所涉及的依赖格式类似。

可选地，所述计算机可执行指令被所述处理器执行时，基于所述测试安装包对所述产品安装包进行测试，包括：

安装所述测试安装包以及产品安装包；

运行预设的测试指令，对所述目标产品进行整体测试。

可选地，所述计算机可执行指令被所述处理器执行时，还包括：

输出并展示测试结果；其中，所述测试结果以命令行或UI界面的形式展示。

应理解，在输出并展示测试结果时，具体可以通过工具或是命令行进行调取，查看测试结果。而工具或是命令行的格式可以C++语言，或是其它可实现的编程语言。本说明书实施例并不对此进行限定。

在本说明书实施例上述技术方案中，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试。

实施例四

进一步地，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机可执行指令，所述计算机可执行指令被处理器执行时实现以下流程：

基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

基于所述测试安装包对所述产品安装包进行测试。

可选地，所述计算机可执行指令被处理器执行时，基于目标产品开发的多个模块，生成模块代码集合以及测试代码集合，具体包括：

基于目标产品开发的多个模块，将目录结构中测试用例对应的目录修改为与模块目录并列的测试用例目录；

建立所述测试用例目录与所述模块目录的依赖关系；

基于调整后的目录结构，生成模块代码集合以及测试代码集合。

本说明书实施例所涉及的依赖方法可以是基于预设依赖格式或是预设依赖语句执行，例如，“implementation”依赖语句，其实还可以通过其它依赖语句，本说明书实施例在此不做赘述。

应理解，本说明书实施例并不对预设的编译指令的格式进行限定，可以是例如“grade assemble AndroidTest”的编译指令格式。

可选地，所述计算机可执行指令被处理器执行时，在生成测试代码集合时，还包括：

生成适配不同产品测试场景的测试属性库；其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

可选地，所述计算机可执行指令被处理器执行时，将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系，具体包括：

基于预设第一依赖格式，建立所述模块代码集合中的模块代码与所述目标产品之间的依赖关系；

基于预设第二依赖格式，建立所述测试代码集合中的测试代码与所述目标产品之间的依赖关系；

其中，所述预设第一依赖格式与所述预设第二依赖格式相同或不同。

应理解，预设第一依赖格式可以与建立所述测试用例目录与所述模块目录的依赖关系时所涉及的依赖格式类似，同理，预设第二依赖格式也可以与建立所述测试用例目录与所述模块目录的依赖关系时所涉及的依赖格式类似。

可选地，所述计算机可执行指令被处理器执行时，基于所述测试安装包对所述产品安装包进行测试，包括：

安装所述测试安装包以及产品安装包；

运行预设的测试指令，对所述目标产品进行整体测试。

可选地，所述计算机可执行指令被处理器执行时，还包括：

输出并展示测试结果；其中，所述测试结果以命令行或UI界面的形式展示。

应理解，在输出并展示测试结果时，具体可以通过工具或是命令行进行调取，查看测试结果。而工具或是命令行的格式可以C++语言，或是其它可实现的编程语言。本说明书实施例并不对此进行限定。

在本说明书实施例上述技术方案中，通过将目标产品的所有模块对应的模块代码打包，以及所有模块对应的测试代码打包，并分别建立模块代码与目标产品的依赖关系，以及测试代码与目标产品的依赖关系，从而将模块代码与测试代码视为同一目录级别，并基于建立依赖关系后的模块代码和测试代码分别生成产品安装包和测试安装包，从而，可以基于测试安装包对产品安装包进行产品整体测试。

其中，所述的计算机可读存储介质包括只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等。

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

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

Claims (8)

1.一种产品测试方法，包括：

基于目标产品开发的多个模块，将目录结构中测试用例对应的目录修改为与模块目录并列的测试用例目录；

建立所述测试用例目录与所述模块目录的依赖关系，所述依赖关系用于测试时正常调用测试用例目录进而正常调用测试用例进行测试；

基于调整后的目录结构，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

基于所述测试安装包对所述产品安装包进行测试。

2.如权利要求1所述的方法，其特征在于，在生成测试代码集合时，还包括：

生成适配不同产品测试场景的测试属性库；其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

3.如权利要求1所述的方法，其特征在于，将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系，具体包括：

基于预设第一依赖格式，建立所述模块代码集合中的模块代码与所述目标产品之间的依赖关系；

基于预设第二依赖格式，建立所述测试代码集合中的测试代码与所述目标产品之间的依赖关系；

其中，所述预设第一依赖格式与所述预设第二依赖格式相同或不同。

4.如权利要求1-3任一项所述的方法，其特征在于，基于所述测试安装包对所述产品安装包进行测试，具体包括：

安装所述测试安装包以及产品安装包；

运行预设的测试指令，对所述目标产品进行整体测试。

5.如权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

输出并展示测试结果；其中，所述测试结果以命令行或UI界面的形式展示。

6.一种产品测试装置，包括：

代码集合生成模块，用于基于目标产品开发的多个模块，将目录结构中测试用例对应的目录修改为与模块目录并列的测试用例目录；建立所述测试用例目录与所述模块目录的依赖关系，所述依赖关系用于测试时正常调用测试用例目录进而正常调用测试用例进行测试；基于调整后的目录结构，生成模块代码集合以及测试代码集合；其中，所述模块代码集合对应所述多个模块的模块代码，所述测试代码集合对应所述多个模块中每个模块的测试用例的测试用例代码；

依赖关系建立模块，用于将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系；

安装包生成模块，用于基于预设的编译指令，分别对与所述目标产品建立依赖关系的模块代码以及测试代码进行解析，生成产品安装包和测试安装包；

测试模块，用于基于所述测试安装包对所述产品安装包进行测试。

7.如权利要求6所述的装置，其特征在于，所述代码集合生成模块在生成测试代码集合时，还用于：

生成适配不同产品测试场景的测试属性库；其中，所述测试属性库至少基于以下参数之一或组合创建：进程差异化、线程逻辑差异化。

8.如权利要求6所述的装置，其特征在于，所述依赖关系建立模块在将所述模块代码集合中的模块代码以及所述测试代码集合中的测试代码分别建立与所述目标产品的依赖关系时，具体用于：

基于预设第一依赖格式，建立所述模块代码集合中的模块代码与所述目标产品之间的依赖关系；

基于预设第二依赖格式，建立所述测试代码集合中的测试代码与所述目标产品之间的依赖关系；

其中，所述预设第一依赖格式与所述预设第二依赖格式相同或不同。

Images