CN114238144A - 软件组件的测试方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种软件组件的测试方法、装置、设备及存储介质，通过在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和第二软件组件的被测运行程序，该第二软件组件是第一软件组件更新后的软件组件，通过为第二软件组件叠加被测运行程序、添加至少两个测试用例，生成第二软件组件的测试执行程序，最后利用测试执行工具调用测试执行程序提供的测试接口，对第二软件组件进行测试，得到第二软件组件的测试执行结果。该技术方案可以全新的、可靠的、高效的对软件组件进行自动化测试，自动化测试程度高、测试质量能够得到保障，测试准确度高。

Description

软件组件的测试方法、装置、设备及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种软件组件的测试方法、装置、设备及存储介质。

背景技术

软件开发是一项需要创造性的活动，对社会进步和发展具有重要意义，软件开发一般需要需求分析、设计、实现、集成和测试等步骤，是一项较为复杂的系统性工作，随着软件行业进入“互联网+”时代，软件组件技术已经成为解决软件开发中软件复用最为有效的技术手段，其在保证软件产品质量方面至关重要。

现有技术中，软件组件的测试方法通常采用单元测试的方式逐一针对软件组件中的各个部分进行测试，然后通过人工手动的方式，基于各个部分进行组件构建，并在发布后集成到交付的应用中，进而随着交付应用的测试实现对软件组件的测试。

然而，上述软件组件的测试方法需要人工进行软件组件构建、打包、发布等操作，不仅存在人工成本高、出错概率高的问题，而且，软件组件的质量无法保证，存在测试准确度低的问题。

发明内容

本申请提供一种软件组件的测试方法、装置、设备及存储介质，以克服现有软件组件的测试方法存在的人工成本高、出错概率高、测试准确度低的问题。

第一方面，本申请提供一种软件组件的测试方法，包括：

在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，所述第二软件组件是所述第一软件组件更新后的软件组件；

通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序；

利用测试执行工具调用所述测试执行程序提供的测试接口，对所述第二软件组件进行测试，得到所述第二软件组件的测试执行结果。

在第一方面的一种可能设计中，所述在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，包括：

在第一软件组件对应的源代码仓库中的源代码发生变化时，触发所述第一软件组件进行自动化编译、打包，构建所述第二软件组件；

获取所述第一软件组件对应的组件运行时程序；

通过在所述组件运行时程序上加载所述第二软件组件，构建所述第二软件组件的被测运行程序。

在第一方面的另一种可能设计中，所述通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序，包括：

通过预设叠加方式为所述第二软件组件叠加所述被测运行程序，得到所述第二软件组件对应的软件运行程序；

通过预设添加方式在所述软件运行程序中添加所述至少两个测试用例，生成所述第二软件组件的测试执行程序。

在第一方面的再一种可能设计中，所述方法还包括：

对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果；

将所述测试执行结果和所述测试分析结果关联到所述第二软件组件和/或所述源代码仓库。

可选的，所述对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果，包括：

对所述测试执行结果进行分析，确定所述至少两个测试用例的执行成功率；

根据所述至少两个测试用例的执行成功率和预设通过率，确定所述第二软件组件的质量是否达标的测试分析结果。

可选的，所述对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果，包括：

确定所述至少两个测试用例中的至少一个关键测试用例；

基于所述至少一个关键测试用例是否执行成功，确定所述第二软件组件的质量是否达标的测试分析结果。

第二方面，本申请实施例提供一种软件组件的测试装置，包括：

构建模块，用于在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，所述第二软件组件是所述第一软件组件更新后的软件组件；

处理模块，用于通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序；

测试模块，用于利用测试执行工具调用所述测试执行程序提供的测试接口，对所述第二软件组件进行测试，得到所述第二软件组件的测试执行结果。

在第二方面的一种可能设计中，所述构建模块，具体用于：

在第一软件组件对应的源代码仓库中的源代码发生变化时，触发所述第一软件组件进行自动化编译、打包，构建所述第二软件组件；

获取所述第一软件组件对应的组件运行时程序；

通过在所述组件运行时程序上加载所述第二软件组件，构建所述第二软件组件的被测运行程序。

在第二方面的另一种可能设计中，所述处理模块，具体用于：

通过预设叠加方式为所述第二软件组件叠加所述被测运行程序，得到所述第二软件组件对应的软件运行程序；

通过预设添加方式在所述软件运行程序中添加所述至少两个测试用例，生成所述第二软件组件的测试执行程序。

在第二方面的再一种可能设计中，所述处理模块，还用于：

对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果；

将所述测试执行结果和所述测试分析结果关联到所述第二软件组件和/或所述源代码仓库。

可选的，所述处理模块，具体用于：

对所述测试执行结果进行分析，确定所述至少两个测试用例的执行成功率；

根据所述至少两个测试用例的执行成功率和预设通过率，确定所述第二软件组件的质量是否达标的测试分析结果。

可选的，所述处理模块，具体用于：

确定所述至少两个测试用例中的至少一个关键测试用例；

基于所述至少一个关键测试用例是否执行成功，确定所述第二软件组件的质量是否达标的测试分析结果。

第三方面，本申请提供一种电子设备，包括：存储器和处理器；

所述存储器用于存储可在所述处理器上运行的计算机执行指令；

所述处理器用于执行所述计算机执行指令时实现如上述第一方面及各可能设计所述的方法。

可选地，上述处理器可以为芯片。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，当所述计算机指令被处理器执行时用于实现第一方面所述的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。

本申请实施例提供的软件组件的测试方法、装置、设备及存储介质，通过在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和第二软件组件的被测运行程序，该第二软件组件是第一软件组件更新后的软件组件，通过为第二软件组件叠加被测运行程序、添加至少两个测试用例，生成第二软件组件的测试执行程序，最后利用测试执行工具调用测试执行程序提供的测试接口，对第二软件组件进行测试，得到第二软件组件的测试执行结果。该技术方案可以全新的、可靠的、高效的对软件组件进行自动化测试，自动化测试程度高、测试质量能够得到保障，测试准确度高。

附图说明

图1为本申请提供的软件组件的测试方法所适用的应用场景示意图；

图2为本申请提供的软件组件的测试方法实施例一的流程示意图；

图3为本申请提供的软件组件的测试方法实施例二的流程示意图；

图4为本申请提供的软件组件的测试方法实施例三的流程示意图；

图5为本申请提供的软件组件的测试装置实施例一的结构示意图；

图6为图5所示的软件组件的测试装置的应用示意图；

图7为本申请提供的软件组件的测试装置实施例二的结构示意图；

图8是本申请提供的电子设备实施例的结构示意图。

具体实施方式

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

在介绍本申请的应用场景和技术方案之前，首先对本申请涉及到的部分术语进行介绍：

DevOps：Development和Operations的组合词，是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(quality assurance，QA)部门之间的沟通、协作与整合。

DevOps成熟度：是对项目的研发运营一体化进行评估的一种的能力成熟度模型。

源代码：未被编译的文本形式的代码。

源代码仓库：在源代码的存储和管理系统中的为特定的应用系统划分的存储单元。

软件组件：软件过程中所产生的中间交付物的一种类型，组件通常是对包含特定方法和属性对象的源代码构建后产生的二进制类库文件，组件无法独立运行，通常不直接交付给用户，用于开发者(包括第三方开发者)集成在应用程序中提供部分服务的能力。

组件仓库：存储软件过程中所交付产生的组件的系统，组件发布者可将特定的组件发布至组件仓库，组件使用者可通过组件仓库获取特定的组件进行使用。

配置管理：指对软件研发过程和生命周期进行控制、规范，以达到纪录软件产品演化过程、源代码版本等信息，确保开发者在各阶段都能得到精确产品配置的目的。

版本控制系统：记录一个或若干个源代码文件内容的变化和相应变更后的版本修订情况的系统，如采用Git模式的GitHub、GitLab等系统。

持续交付：一种软件研发交付的过程方法，通常使用自动化的、可持续的方式基于流水线的方式让软件产品的可持续的产出，并在保证软件可以稳定、持续的可以发布的情况。

下述对本申请的应用场景进行解释说明：

软件开发是一项需要创造性的活动，对社会进步和发展具有重要意义，软件开发一般需要需求分析、设计、实现、集成和测试等步骤，是一项较为复杂的系统性工作，随着软件行业进入“互联网+”时代，组件技术已经成为解决软件开发中软件复用最为有效的技术手段，得到了广泛应用。

随着市场对软件产品要求越来越高，在企业级配置管理与持续集成交付过程中越来越注重工程效率的提升，通过研发运营一体化(DevOps)，借助自动化手段和标准化的管理来提升研发效率、降低发布操作成本、保证软件质量。

系统化的、标准化的软件组件测试机制是保证软件产品质量的重要环节，将软件组件测试用于DevOps流水线自动化的持续集成与持续发布过程中，实现对软件组件的自动化测试和分析，是企业保障应用程序可靠性，保证软件产品质量，提高工程效率的重要手段。

由背景技术中介绍可知，现有技术的方案是：采用单元测试的方式对组件的各个部分进行单一测试，通过人工手动方式进行组件构建，并在软件组件发布后集成到交付的应用中，随着交付应用的测试进行测试。这种方案会存在多个缺点，分别如下：

1、自动化程度低，需要人工方式在本地进行构建、打包、发布，操作繁琐，由于软件组件无法独立运行，无法集成到流水线中进行自动化测试，人工手动的方式出错概率较高。

2、缺少软件组件自身的质量保障，由于软件组件本身不具备独立的运行方式，因此，无法直接对软件组件开展对应的集成测试，需要先发布交付组件，再集成至应用中测试，无法保证组件的质量。

3、缺少源代码版本控制，现有技术需要在开发者本地进行，无法跟踪组件测试对应的源代码版本。

4、缺少软件组件版本控制，由于软件组件直接在开发者本地先发布后测试，组件仓库中的版本可能会存在组件发布者多次发布相同版本的情况，从而导致所发布的软件组件版本控制错误。

综上可知，现有软件组件的测试方案存在人工成本高，测试准确度低的问题。

针对上述技术问题，本申请技术方案需要解决的技术问题主要如下：

1、实现对软件组件的自动化集成测试与验证，解决组件因缺少独立运行时而无法进行集成测试的问题，通过对自动化组件的测试进行组件质量控制。

2、实现对软件组件对应测试的源代码的版本控制，通过流水线装置将所测试的组件与对应的源代码双向关联的方式实现对测试组件的源代码版本控制。

3、实现对软件组件对应测试的组件的版本控制，通过流水线装置将所测试的组件进行版本标记，实现所测试组件的版本控制。

本申请的技术构思过程如下：随着研发运营一体化(DevOps)在企业级配置管理与持续集成交付过程中的不断深入发展，通过自动化流水线的方式实现应用的自动化测试变得尤为重要，通过设计并实现一种自动化测试的流水线装置，可用于对软件开发过程所研发出的组件进行自动化的集成测试与验证，并可将该流水线装置集成在软件组件的持续集成与发布的DevOps流水线中，实现从软件组件的源代码触发后执行自动化测试及测试分析，从而保证软件组件的交付质量。

也即，本申请技术方案的目的是为了将软件研发过程的组件进行持续测试，解决软件组件因缺少运行时程序而无法被独立测试、不能进行自动化集成测试的问题。因此，本申请提出了一种全新的对软件组件进行叠加被测运行程序的自动化测试方法，并配套提供了一种实现装置，该装置能够通过识别源代码仓库中的分支模型将源代码进行编译、打包、叠加自动化测试运行时的能力，并调起外部自动化测试装置进行测试验证、自动化结果分析，从而实现对软件组件的自动化测试，大幅提升了软件组件的DevOps的自动化测试程度及质量保障。

针对上述技术构思过程，本申请实施例提供了一种软件组件的测试方法，在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和第二软件组件的被测运行程序，该第二软件组件是第一软件组件更新后的软件组件，通过为第二软件组件叠加被测运行程序、添加至少两个测试用例，生成第二软件组件的测试执行程序，最后利用测试执行工具调用测试执行程序提供的测试接口，对第二软件组件进行测试，得到第二软件组件的测试执行结果。该技术方案可以全新的、可靠的、高效的对软件组件进行自动化测试，自动化测试程度高、测试质量能够得到保障，测试准确度高。

可理解，本申请技术方案的实现主要分为三个部分，分别为软件组件及被测运行程序的构建、软件组件和被测运行程序的叠加、软件组件的自动化测试。该技术方案能够通过识别软件组件对应的源代码仓库中的分支模型将源代码进行编译、打包、叠加组件被测运行程序，调起自动化测试装置(测试执行工具)进行组件测试验证，自动化分析，实现对软件组件的自动化测试，提升软件组件的自动化测试程度和质量保障，并且能够促进企业软件组件测试、发布更加系统化、标准化，提升软件质量，并且在DevOps流水线中集成该装置，也将显著提升企业的工程效率。

可选的，下述首先对本申请技术方案的关键点进行总述：

1、一种可用于软件持续集成流水线中的装置，可检测软件组件的源代码版本仓库，在指定源代码版本仓库的指定分支的源代码发生变化时，触发软件组件自动化构建模块接受指定后获取指定源代码版本仓库中的指定分支的软件组件的源代码，对其进行编译、打包，产生软件组件，以用于后续测试。

2、一种可用于软件持续集成流水线中的装置，可为软件组件自动化构建所产生的软件组件叠加测试运行时程序，触发软件组件被测运行程序自动化构建模块接受指定后获取指定源代码版本仓库中的指定分支的软件组件被测运行程序的源代码，加载软件组件后，对其进行编译、打包、部署，产生软件组件对应的测试执行程序用于后续测试。

3、一种可用于软件持续集成流水线中的装置，可向自动化测试工具发送信号，对软件组件被测运行程序进行自动化测试，基于对软件组件被测运行程序的测试，实现对软件组件的自动化测试。

4、一种可用于软件持续集成流水线中的装置，可在自动化测试工具执行测试后，记录、分析软件组件被测运行程序对软件组件的测试结果，并将测试分析结果与软件组件进行关联标记。

5、一种软件组件及被测运行程序构建触发方法，可集成在软件持续集成流水线中对软件组件进行测试，通过检测软件组件的代码提交、分支合并等步骤后，触发软件组件的自动化编译、打包的构建操作，在组件构建操作的同时或构建后获取软件组件被测运行程序的源代码进行自动化编译、打包。

6、一种对软件组件进行自动化测试的方法，通过对软件组件进行叠加被测运行程序，通过被测运行程序直接或动态加载的方式开展对软件组件的自动化测试。

7、一种软件组件自动化测试后的标记方法，通过测试接口调起被测运行程序中已加载的需要测试的组件进行测试，记录或反馈测试结果，将测试结果与软件组件进行关联标记。

8、一种对软件组件进行自动化测试的方法，在软件组件的测试执行程序中提供可供外部自动化测试工具对接调用的接口，通过编程或导入的方式将对软件组件的功能测试导入到软件组件被测运行程序中，生成软件组件的测试执行程序，与对接调用的接口进行匹配用于对软件组件开展测试。

示例性的，图1为本申请提供的软件组件的测试方法所适用的应用场景示意图。参照图1所示，该应用场景示意图可以包括：开发人员使用的多个终端设备(示例性的，终端设备111和终端设备112)、与每个终端设备连接的电子设备12。

在实际应用中，研发人员可以在终端设备上开发代码，生成源码文件。具体的，研发人员可以在终端设备上编写代码，也可以从其他设备(例如，电子设备)上获取源代码仓库(可以是开源库或闭源库)中的部分代码，并对其进行改进，生成源代码文件，使得软件组件对应的源代码仓库中的代码发生变化。可理解，本申请实施例并不对源代码文件的生成方式或生成过程进行限定。

可选的，在本申请的实施例中，电子设备可以执行本申请的技术方案，即，电子设备可以检测第一软件组件对应的源代码仓库中的代码是否发生变化，并在发生变化时构建第二软件组件和第二软件组件对应的被测运行程序，进而生成第二软件组件的测试执行程序，最后通过测试执行程序对第二软件组件进行测试，得到第二软件组件的测试执行结果。

可选的，在本申请的实施例中，该应用场景示意图中还可以包括用户使用的终端设备，示例性的，包括：终端设备113和终端设备114。该终端设备113和终端设备114可以从电子设备12的源代码仓库中获取已发布的软件组件，以便实现某些应用的业务功能。

可以理解的是，图1示出的场景示意图仅是一种示例性说明。在实际应用中，该场景示意图上还可以包括其他设备，例如，存储设备等，具体可以根据实际需求进行调整，本申请实施例并不对其进行限定。

在上述图1所示的场景示意图中，本申请实施例并不限定各设备的具体表现形式，例如，电子设备21可以是计算机设备、服务器，该终端设备可以是手机、平板电脑，PC终端等，此处不再一一举例说明。

可理解，在实际应用中，终端设备也可以执行本申请的技术方案并实现代码发布的目的，本申请实施例并不对其进行限定。

下面，结合上述图1所示的场景示意图，通过具体实施例对本发明的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请提供的软件组件的测试方法实施例一的流程示意图。如图2所示，该软件组件的测试方法可以包括如下步骤：

S201、在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序。

其中，该第二软件组件是第一软件组件更新后的软件组件。

本申请的技术方案主要针对：在应用通过但不限于DevOps持续集成流水线中对代码提交、分支合并等步骤进行持续集成时，可以触发软件组件的自动化编译、打包等构建操作，在软件组件构建操作的同时或构建后获取该软件组件的被测运行程序的源代码进行自动化编译、打包，以此为软件组件叠加被测运行程序，并将软件组件的被测运行程序进行自动化部署。

在本申请的实施例中，将原始软件组件称为第一软件组件，将更新后的软件组件称为第二软件组件，且，“第一”和“第二”仅表示软件组件的不同，不表示顺序。

示例性的，在本申请的实施例中，电子设备可以实时或周期性的检测第一软件组件对应的源代码仓库中的源代码是否发生变化，具体的，可以检测第一软件组件对应的源代码仓库中指定分支的代码变动情况，例如，代码提交、分支合并、代码删除等情况。

示例性的，在第一软件组件对应的源代码仓库中的源代码发生变化时，便可以触发第一软件组件的自动更新，生成第二软件组件。

进一步的，在第二软件组件的构建过程中或者在第二软件组件构建完成后，也可以同时构建第二软件组件的被测运行程序，为第二软件组件的测试提供前提条件。

S202、通过为第二软件组件叠加被测运行程序、添加至少两个测试用例，生成第二软件组件的测试执行程序。

在本实施例中，通过为需要测试的第二软件组件叠加第二软件组件对应的被测运行程序，由第二软件组件的被测运行程序提供运行时，并提供对应的测试接口，通过测试接口调起被测运行程序中已加载的需要测试的组件进行测试。

通常情况下，由于软件组件是软件过程中所产生的中间交付物的一种类型，其无法独立运行，所以，针对第二软件组件，首先为需要测试的第二软件组件叠加上述被测运行程序生成可运行程序，然后在可运行程序的多个监测点处分别添加测试用例，生成第二软件组件的测试执行程序。

S203、利用测试执行工具调用上述测试执行程序提供的测试接口，对第二软件组件进行测试，得到第二软件组件的测试执行结果。

在本申请的实施例中，在第二软件组件对应的测试执行程序部署完成后，会触发测试执行工具执行对应的测试用例，由测试执行工具向第二软件组件对应的测试执行程序所提供的测试接口进行调用，并在测试执行工具回调第二软件组件对应的测试执行程序时，执行对第二软件组件的测试，并对所测试的功能进行记录或反馈测试结果，得到第二软件组件的测试执行结果。

本申请实施例提供的软件组件的测试方法，在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和第二软件组件的被测运行程序，该第二软件组件是第一软件组件更新后的软件组件，通过为第二软件组件叠加被测运行程序、添加至少两个测试用例，生成第二软件组件的测试执行程序，最后利用测试执行工具调用测试执行程序提供的测试接口，对第二软件组件进行测试，得到第二软件组件的测试执行结果。该技术方案可以全新的、可靠的、高效的对软件组件进行自动化测试，自动化测试程度高、测试质量能够得到保障，测试准确度高。

在上述实施例的基础上，图3为本申请提供的软件组件的测试方法实施例二的流程示意图。如图3所示，上述S201可以通过如下步骤实现：

S301、在第一软件组件对应的源代码仓库中的源代码发生变化时，触发第一软件组件进行自动化编译、打包，构建第二软件组件。

示例性的，在本申请的实施例中，在检测到第一软件组件对应的源代码仓库指定分支的代码发生变动时，例如，代码提交、分支合并操作，触发对第二软件组件的构建，具体的，通过对第一软件组件进行编译、打包等，生成第二软件组件。

S302、获取第一软件组件对应的组件运行时程序。

可选的，在第二软件组件构建时，或者，在第二软件组件构建完成后，获取上述第一软件组件对应的组件运行时程序，具体的，该组件运行时程序可以是第一软件组件对应的源代码仓库中的指定分支的代码。

可理解，本申请实施例并不对获取组件运行时程序的时机进行限定，其可以根据实际场景确定，此处不作限定。

S303、通过在该组件运行时程序上加载第二软件组件，构建第二软件组件的被测运行程序。

在本步骤中，电子设备在获取的组件运行时程序上加载上述构建的第二软件组件，从而实现第二软件组件的被测运行程序的构建。

可理解，在第二软件组件的被测运行程序构建后，便可以对其进行自动化部署，提供可被执行测试的接口，供测试执行工具(自动化测试工具)进行测试。

可选的，在本申请的实施例中，上述S202可以通过如下步骤实现：

S304、通过预设叠加方式为第二软件组件叠加被测运行程序，得到第二软件组件对应的软件运行程序。

可选的，电子设备可以为需要测试的第二软件组件叠加被测运行程序。可选的，预设叠加方式可以包括在被测运行程序中直接引用和动态引用两种方式。

其中，直接引用是指在被测运行程序的编译构建过程中，直接将第二软件组件叠加到被测运行程序中，得到第二软件组件对应的软件运行程序。

动态引用是指在第二软件组件和第二软件组件的被测运行程序分别构建完，再动态的加载将第二软件组件叠加到被测运行程序中。

S305、通过预设添加方式在软件运行程序中添加所述至少两个测试用例，生成所述第二软件组件的测试执行程序。

示例性的，为了对软件组件进行测试，还需要在第二软件组件对应的软件运行程序中添加用于监测第二软件组件的功能的至少两个测试用例。可选的，测试用例的预设添加方式可以至少包括：编程方式和外部导入测试用例方式。

其中，编程方式可以是在编写软件运行程序时直接在每个监测点分别添加测试用例，从而生成该第二软件组件的测试执行程序。

外部导入测试用例方式是指在软件运行程序的每个监测点分别导入之前写好的测试用例，进而生成该第二软件组件的测试执行程序。

在本实施例中，测试执行程序可以提供测试接口，通过该测试接口可调起第二软件组件的功能测试用例的执行，并在每个测试用例执行后，记录或反馈对应的第二软件组件的功能测试结果。

可理解，在本申请实施例的一种可能设计中，该软件组件的测试方法可以包括上述S301至S303以及上述S202和S203组成的技术方案；在本申请实施例的另一种可能设计中，该软件组件的测试方法可以包括上述S201、S304、S305以及S203组成的技术方案；在本申请实施例的再一种可能设计中，该软件组件的测试方法可以包括上述S301、S302、S303、S304、S305以及S203组成的技术方案。本实施例并不限定实现方案的具体实现，其可以根据实际情况确定，此处不作赘述。

本申请实施例提供的软件组件的测试方法，通过构建第二软件组件以及第二软件组件的被测运行程序，而且为第二软件组件叠加上述被测运行程序、添加至少两个测试用例，生成第二软件组件的测试执行程序，为后续第二软件组件的测试奠定了基础。

在上述实施例的基础上，图4为本申请提供的软件组件的测试方法实施例三的流程示意图。如图4所示，该软件组件的测试方法还可以包括如下步骤：

S401、对测试执行结果进行分析，得到第二软件组件的质量是否达标的测试分析结果。

可选的，电子设备可以根据预设通过率或关键测试用例的执行结果对第二软件组件的测试执行结果进行分析，判断第二软件组件的质量是否达到预设指标，进而得到测试分析结果。

作为一种示例，该S401可以通过如下步骤实现：

对上述测试执行结果进行分析，确定上述至少两个测试用例的执行成功率，根据上述至少两个测试用例的执行成功率和预设通过率，确定第二软件组件的质量是否达标的测试分析结果。

可选的，至少两个测试用例的执行成功率是指所有测试用例中执行成功的测试用例数量与测试用例总数量的比值。若上述至少两个测试用例的执行成功率大于或等于预设通过率，则确定第二软件组件的质量达标；若上述至少两个测试用例的执行成功率小于预设通过率，则确定第二软件组件的质量不达标。

作为另一种示例，该S401可以通过如下步骤实现：

确定至少两个测试用例中的至少一个关键测试用例，基于该至少一个关键测试用例是否执行成功，确定第二软件组件的质量是否达标的测试分析结果。

可选的，假设在软件运行程序中添加的至少两个测试用例中有至少一个测试用例是关键测试用例，例如，指示第二软件组件是否能够正常运行的测试用例。可选的，若至少一个测试用例均能执行成功，则确定第二软件组件的质量达标，若至少一个测试用例存在执行失败的测试用例，则确定第二软件组件的质量不达标。

S402、将测试执行结果和测试分析结果关联到第二软件组件和/或源代码仓库。

可选的，为了能够在后续明确不同版本的软件组件，实现对软件组件的版本控制，可以对第二软件组件进行标记，并将得到的测试执行结果和测试分析结果关联到第二软件组件和/或该第二软件组件的源代码仓库。

本申请实施例提供的软件组件的测试方法，通过对测试执行结果进行分析，得到第二软件组件的质量是否达标的测试分析结果，将测试执行结果和测试分析结果关联到第二软件组件和/或源代码仓库，实现了对软件组件的版本控制，避免了所发布的软件组件版本控制错误的问题。

可选的，在上述方法实施例的基础上，下述以要实现的功能为基础设计了一种软件组件的测试装置，该装置包括的各模块均是以对应的功能进行命名。可理解，在实际应用中，下述各模块可以独立设计，也可以集成到一个模块中进行设计，本实施例不对其进行限定。

示例性的，图5为本申请提供的软件组件的测试装置实施例一的结构示意图。图6为图5所示的软件组件的测试装置的应用示意图。如图5和图6所示，该软件组件的测试装置可以包括：

源代码变更检测模块501，用于检测软件组件对应的源代码仓库中特定分支下的源代码变动情况，当源代码发生变动时调起自动化构建模块502。

自动化构建模块502，用于获取指定源代码仓库下的指定分支的源代码，并对获取到的源代码进行编译、打包操作，完成软件组件的构建、组件运行时程序的加载，以及组件运行时被测运行程序的构建。

软件组件被测运行程序叠加模块503，用于获取叠加运行时所在的源代码仓库下的指定分支的源代码，为自动化构建模块502所产生的待测试组件运行时程序叠加被测运行程序(例如：叠加运行时所在的源代码仓库存储组件样例工程，将组件样例工程作为组件的运行时叠加程序)，实现了组件运行时被测运行程序的构建。

组件运行程序自动化部署模块504，用于利用自动化构建模块构建的组件运行时被测运行程序，自动化部署组件运行时程序，软件被测运行程序提供测试接口、添加组件功能测试用例，其为该第二软件组件产生测试执行程序时使用。

自动化测试调度模块505，用于向外部的自动化测试工具发送信号，使得自动化测试工具执行组件测试用例，实现对软件组件运行时程序进行自动化测试，并记录组件功能测试结果。

软件组件自动化标记模块506，用于从自动化测试调度模块505获取自动化测试结果，分析自动化测试结果，并将测试分析结果与软件组件和/或软件组件的源代码仓库进行关联标记。

在本实施例中，该装置可应用于DevOps自动化持续集成与持续发布过程中对软件组件进行自动化测试的场景，用于解决软件组件因缺少独立运行时而无法进行集成测试的问题，该装置可从源代码为起点，实现对软件组件的自动化集成测试与验证，进而提升了对软件组件质量控制，以及提升了软件研发与测试效率，为应用组件的可靠性、可追溯性提供了重要保障。

具体的，该软件组件的测试装置具有下列优点：

1、自动化触发、流水线式执行

在持续集成交付流水线中可基于源代码的变动进行检测，自动化触发对软件组件的构建、打包、测试，并自动化叠加软件组件测试运行程序。自动化过程无需研发人员参与，可靠无差错，保证了版本控制的高效性和可靠性。

2、提升质量保障能力

实现了从软件组件源代码变动到软件组件发布的强质量管控，通过叠加软件组件的被测运行程序提升了质量保障能力，对软件组件的测试提前到组件构建的环节中，避免了先发布组件再进行测试的问题，有效提升了软件组件的质量保障能力。

3、系统化、规范化

该方案具有规范化、系统化和自动化的特点。在软件组件的构建与测试过程中，无人工参与版本控制过程，有效避免了研发人员的误操作，使得版本控制与质量得到保障。

下述为本申请方法实施例对应的装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图7为本申请提供的软件组件的测试装置实施例二的结构示意图。如图7所示，该软件组件的测试装置可以包括：

构建模块701，用于在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，所述第二软件组件是所述第一软件组件更新后的软件组件；

处理模块702，用于通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序；

测试模块703，用于利用测试执行工具调用所述测试执行程序提供的测试接口，对所述第二软件组件进行测试，得到所述第二软件组件的测试执行结果。

在本申请实施例的一种可能设计中，所述构建模块701，具体用于：

在第一软件组件对应的源代码仓库中的源代码发生变化时，触发所述第一软件组件进行自动化编译、打包，构建所述第二软件组件；

获取所述第一软件组件对应的组件运行时程序；

通过在所述组件运行时程序上加载所述第二软件组件，构建所述第二软件组件的被测运行程序。

在本申请实施例的另一种可能设计中，所述处理模块702，具体用于：

通过预设叠加方式为所述第二软件组件叠加所述被测运行程序，得到所述第二软件组件对应的软件运行程序；

通过预设添加方式在所述软件运行程序中添加所述至少两个测试用例，生成所述第二软件组件的测试执行程序。

在本申请实施例的再一种可能设计中，所述处理模块702，还用于：

对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果；

将所述测试执行结果和所述测试分析结果关联到所述第二软件组件和/或所述源代码仓库。

可选的，所述处理模块702，具体用于：

对所述测试执行结果进行分析，确定所述至少两个测试用例的执行成功率；

根据所述至少两个测试用例的执行成功率和预设通过率，确定所述第二软件组件的质量是否达标的测试分析结果。

可选的，所述处理模块702，具体用于：

确定所述至少两个测试用例中的至少一个关键测试用例；

基于所述至少一个关键测试用例是否执行成功，确定所述第二软件组件的质量是否达标的测试分析结果。

本申请实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessing unit，CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘solid state disk(SSD))等。

图8是本申请提供的电子设备实施例的结构示意图。如图8所示，该电子设备可以包括：处理器801和存储器802。

其中，存储器802用于存储可在所述处理器801上运行的计算机执行指令；处理器801用于执行所述计算机执行指令时实现如上述方法实施例的技术方案。

可选的，该电子设备还可以包括：通信接口803和系统总线804，存储器802和通信接口803通过系统总线804与处理器801连接并完成相互间的通信，通信接口803用于和其他设备进行通信。

可选的，通信接口803具体可以通过收发器实现。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(random access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

系统总线804可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

上述的处理器可以是通用处理器，包括中央处理器CPU、网络处理器(networkprocessor，NP)等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可选的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现上述方法实施例的技术方案。

可选的，本申请实施例还提供一种运行指令的芯片，所述芯片用于执行上述方法实施例的技术方案。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述方法实施例的技术方案。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

1.一种软件组件的测试方法，其特征在于，包括：

在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，所述第二软件组件是所述第一软件组件更新后的软件组件；

通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序；

利用测试执行工具调用所述测试执行程序提供的测试接口，对所述第二软件组件进行测试，得到所述第二软件组件的测试执行结果。

2.根据权利要求1所述的方法，其特征在于，所述在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，包括：

在第一软件组件对应的源代码仓库中的源代码发生变化时，触发所述第一软件组件进行自动化编译、打包，构建所述第二软件组件；

获取所述第一软件组件对应的组件运行时程序；

通过在所述组件运行时程序上加载所述第二软件组件，构建所述第二软件组件的被测运行程序。

3.根据权利要求1所述的方法，其特征在于，所述通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序，包括：

通过预设叠加方式为所述第二软件组件叠加所述被测运行程序，得到所述第二软件组件对应的软件运行程序；

通过预设添加方式在所述软件运行程序中添加所述至少两个测试用例，生成所述第二软件组件的测试执行程序。

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

对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果；

将所述测试执行结果和所述测试分析结果关联到所述第二软件组件和/或所述源代码仓库。

5.根据权利要求4所述的方法，其特征在于，所述对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果，包括：

对所述测试执行结果进行分析，确定所述至少两个测试用例的执行成功率；

根据所述至少两个测试用例的执行成功率和预设通过率，确定所述第二软件组件的质量是否达标的测试分析结果。

6.根据权利要求4所述的方法，其特征在于，所述对所述测试执行结果进行分析，得到所述第二软件组件的质量是否达标的测试分析结果，包括：

确定所述至少两个测试用例中的至少一个关键测试用例；

基于所述至少一个关键测试用例是否执行成功，确定所述第二软件组件的质量是否达标的测试分析结果。

7.一种软件组件的测试装置，其特征在于，包括：

构建模块，用于在第一软件组件对应的源代码仓库中的源代码发生变化时，构建第二软件组件和所述第二软件组件的被测运行程序，所述第二软件组件是所述第一软件组件更新后的软件组件；

处理模块，用于通过为所述第二软件组件叠加所述被测运行程序、添加至少两个测试用例，生成所述第二软件组件的测试执行程序；

测试模块，用于利用测试执行工具调用所述测试执行程序提供的测试接口，对所述第二软件组件进行测试，得到所述第二软件组件的测试执行结果。

8.一种电子设备，其特征在于，包括：存储器和处理器；

所述存储器用于存储可在所述处理器上运行的计算机执行指令；

所述处理器用于执行所述计算机执行指令时实现如上述权利要求1至6任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如上述权利要求1至6任一项所述的方法。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述权利要求1至6任一项所述的方法。

Images