CN116414683A - 一种回归测试方法、装置、设备及介质 - Google Patents

Abstract

本公开实施例涉及一种回归测试方法、装置、设备及介质，其中该方法包括：获取目标应用程序的待测组件，待测组件为目标应用程序的代码进行组件化之后的多个组件中的任意一个；确定待测组件的组件类型，并根据组件类型确定对应的回归测试策略；采用待测组件的回归测试策略对待测组件的变更部分进行回归测试。采用上述技术方案，将应用程序的代码的多个组件根据组件类型确定其对应的回归测试策略，并采用不同的回归测试策略对组件的变更部分进行回归测试，实现了通用的多策略精准回归测试，既能够保障质量不劣化，而且节省了回归测试的人力成本，极大提升了回归测试的效率。

Description

一种回归测试方法、装置、设备及介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种回归测试方法、装置、设备及介质。

背景技术

随着智能终端的发展，各类应用程序出现了爆发式的增长，人们也越来越多地使用应用程序满足日常生活中的所需。为了保障应用程序的质量，每次升级新版本之前都会进行功能的回归测试，从而避免新的改动引入问题。

回归测试通常是进行全量回归，随着应用程序的迭代功能越来越多，迭代速度越来越快，短时间内实现全量回归测试比较困难。相关技术中可以通过对更新的部分进行回归测试，缩减回归范围，但是由于测试用例本身侧重交互效果的特性，依然存在测试准确性不高以及效率较低的问题。

发明内容

为了解决上述技术问题，本公开提供了一种回归测试方法、装置、设备及介质。

本公开实施例提供了一种回归测试方法，所述方法包括：

获取目标应用程序的待测组件，所述待测组件为所述目标应用程序的代码进行组件化之后的多个组件中的任意一个；

确定所述待测组件的组件类型，并根据所述组件类型确定对应的回归测试策略；

采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试。

本公开实施例还提供了一种回归测试装置，所述装置包括：

组件模块，用于获取目标应用程序的待测组件，所述待测组件为所述目标应用程序的代码进行组件化之后的多个组件中的任意一个；

类型模块，确定所述待测组件的组件类型，并根据所述组件类型确定对应的回归测试策略；

测试模块，用于采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试。

本公开实施例还提供了一种电子设备，所述电子设备包括：处理器；用于存储所述处理器可执行指令的存储器；所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现如本公开实施例提供的回归测试方法。

本公开实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行如本公开实施例提供的回归测试方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：本公开实施例提供的回归测试方案，获取目标应用程序的待测组件，待测组件为目标应用程序的代码进行组件化之后的多个组件中的任意一个；确定待测组件的组件类型，并根据组件类型确定对应的回归测试策略；采用待测组件的回归测试策略对待测组件的变更部分进行回归测试。采用上述技术方案，将应用程序的代码的多个组件根据组件类型确定其对应的回归测试策略，并采用不同的回归测试策略对组件的变更部分进行回归测试，实现了通用的多策略精准回归测试，既能够保障质量不劣化，而且节省了回归测试的人力成本，极大提升了回归测试的效率。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本公开实施例提供的一种回归测试方法的流程示意图；

图2为本公开实施例提供的另一种回归测试方法的流程示意图；

图3为本公开实施例提供的一种业务组件的回归测试示意图；

图4为本公开实施例提供的一种基础组件的回归测试示意图；

图5为本公开实施例提供的一种回归测试装置的结构示意图；

图6为本公开实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

随着智能终端的发展，各类应用程序出现了爆发式的增长，而应用程序与传统的网页、后端开发相比，在用户遇到线上问题时的解决成本明显偏高，往往需要用户主动升级到新版本才能解决。所以为了保障应用程序的质量，每次升级新版本之前都会进行功能的回归测试，从而避免新的改动引入问题。

回归测试通常是进行全量回归，具有时间短任务重的特点，随着应用程序的迭代功能越来越多，迭代速度越来越快，回归测试的范围越来越大，短时间内实现全量回归测试比较困难，导致发版节奏变慢，而如果人工进行测试用例的缩减，又容易出现评估范围不当，导致问题遗漏到线上的风险。相关技术中可以通过对更新的部分进行回归测试，缩减回归范围，但是由于测试用例本身侧重交互效果的特性，依然存在测试准确性不高以及效率较低的问题。

为了解决上述问题，本公开实施例提供了一种回归测试方法，下面结合具体的实施例对该方法进行介绍。

图1为本公开实施例提供的一种回归测试方法的流程示意图，该方法可以由回归测试装置执行，其中该装置可以采用软件和/或硬件实现，一般可集成在电子设备中。如图1所示，该方法包括：

步骤101、获取目标应用程序的待测组件，待测组件为目标应用程序的代码进行组件化之后的多个组件中的任意一个。

其中，目标应用程序可以是任意一个需要进行回归测试的应用程序，具体不限，例如目标应用程序可以是视频应用程序、直播应用程序或阅读应用程序等。本公开实施例中，目标应用程序的当前版本的代码可以经过组件化拆分为多个组件，也即将代码按照功能拆分到不同的仓库中独立开发集成，并且将各组件依次确定为上述待测组件。

步骤102、确定待测组件的组件类型，并根据组件类型确定对应的回归测试策略。

其中，组件类型可以是按照不同的功能对上述多个组件进行分类得到的类型，本公开实施例中组件类型可以包括业务组件、基础组件和外部组件三种类型。业务组件可以理解为应用程序的与用户界面(User Interface，UI)展示直接相关的组件，可以是最上层的组件，业务组件按照业务功能可以包括视频播放页的组件、朋友页的组件和个人页的组件等等。基础组件可以理解为被上述业务组件直接依赖的组件，也即基础组件可以为业务组件提供一些通用的能力，例如网络库或配置服务等等。外部组件可以理解为由外部提供的一些功能组件，例如支付组件等，外部组件可以二进制的形式提供。

回归测试策略可以是用于对代码进行回归测试的具体方式，回归测试可以是在应用程序修改了旧代码后，对新版本的代码重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，本公开实施例中的回归测试是在目标应用程序内的已有功能经过线上用户大量论证不存在明显问题的假设前提之下执行的，如果出现问题则是基于当前变更的部分影响造成的。本公开实施例中回归测试策略可以包括多种，并且回归测试策略可以与上述组件类型相对应，不同组件类型对应的回归测试策略不同。

在本公开实施例中，确定待测组件的组件类型，可以包括：根据待测组件开发时配置的类型标识确定对应的组件类型。

其中，类型标识可以理解为用于区分不同组件的组件类型的标识信息，不同组件类型的类型标识不同，具体表现形式不限，例如可以通过字母或数字等形式表示。在本公开实施例中，待测组件在开发时可以由开发人员确定其组件类型并添加对应的类型标识，回归测试装置在获取待测组件之后可以通过查找确定当前待测组件的类型标识，进而根据类型标识与组件类型之间的对应关系确定待测组件的组件类型。

在本公开实施例中，根据组件类型确定对应的回归测试策略，可以包括：当组件类型为业务组件，则对应的回归测试策略为测试用例推送；当组件类型为基础组件，则对应的回归测试策略为自动化单测；当组件类型为外部组件，则对应的回归测试策略为全量测试。

当组件类型为业务组件，由于业务组件对应的代码改动影响范围小，通常仅与相应业务功能的测试用例直接关联，因此业务组件对应的回归测试策略可以为测试用例推送，测试用例推送可以表示根据代码块与测试用例直接的关联关系查找发生变更的代码块的界面测试用例并推送给测试人员进行回归测试的方式。

当组件类型为基础组件，由于基础组件的代码改动影响范围广，大多数业务组件都会依赖它们提供的通用能力，所以导致关联的界面测试用例特别多，导致如果基础组件采用上述测试用例推送的方式，通过界面测试用例基于UI操作进行测试回归测试的成本极高，并且测试的准确性较低，很难有效覆盖到问题点，故而基础组件不适合采用上述测试用例推送的方式，本公开实施例可以设置基础组件的回归测试策略为自动化单测，自动化单测可以表示通过分析代码自动运行并与预期结果进行对比来实现回归测试的方式。

当组件类型为外部组件，由于外部组件大多是以二进制的形式提供的，并且该类组件升级频率低，升级时一般改动较大，因此对应的回归测试策略可以是全量测试，通过为每个外部组件维护对应的测试用例进行回归测试即可。

步骤103、采用待测组件的回归测试策略对待测组件的变更部分进行回归测试。

其中，待测组件的变更部分可以理解为待测组件的代码中发生变更的部分代码，通过仅对代码的变更部分进行回归测试能够实现精准的回归测试，减少回归测试的范围，提升回归测试效率。

在本公开的一种实施方式中，当组件类型为业务组件，采用待测组件的回归测试策略对待测组件的变更部分进行回归测试，可以包括：确定待测组件的变更代码块；基于预先建立的代码块与界面测试用例之间的第一关联关系，确定待测组件的变更代码块的第一界面测试用例；将第一界面测试用例推送至测试人员以对待测组件的变更代码块进行回归测试。

代码块可以理解为待测组件的代码的最小单位。测试用例(Test Case)可以理解为对应用程序进行测试的测试任务的描述，体现测试任务的测试方案、方法、技术和策略，其内容可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。也即，测试用例可以是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实应用程序是否满足某个特定需求。界面测试用例可以是与UI界面的操作相关的测试用例。

第一关联关系可以是在对历史版本的目标应用程序进行回归测试的过程中，采用覆盖率插桩的方式将每个界面测试用例与运行到的代码块进行绑定得到的关联关系，一个界面测试用例可以关联一个或多个代码块。上述第一关联关系的建立过程可以包括：在对历史版本的目标应用程序进行打包时，可以对各组件开启覆盖率插桩，用于收集运行过程中执行到的代码块，也即在各组件的每个代码块入口插入一个桩点位，通过该桩点位调用记录函数在代码块运行到时进行记录；之后针对上述历史版本的目标应用程序可以通过界面测试用例进行回归测试，在每个界面测试用例测试过程中收集每个桩点位的数据，得到运行过程中执行到的覆盖率数据，覆盖率数据中包括运行到的函数的代码块，每个函数可以包括多个代码块，之后可以将各界面测试用例的标识与其对应的运行到的代码块进行绑定，得到代码块与界面测试用例之间的第一关联关系。上述历史版本可以为目标应用程序的当前版本的上一版本。

具体的，当待测组件的组件类型为业务组件，回归测试装置可以基于待测组件的提交标识(CommitId)将当前版本的待测组件与上一版本的待测组件的代码进行比较，确定待测组件发生变更的变更代码块；之后，根据变更代码块通过在第一关联关系中进行查找，确定其对应的第一界面测试用例，之后可以将该第一界面测试用例推送至测试人员，以使测试人员通过该第一界面测试用例对上述变更代码块进行回归测试。

在本公开的另一种实施方式中，当组件类型为基础组件，采用待测组件的回归测试策略对待测组件的变更部分进行回归测试，可以包括：确定所述待测组件的变更代码块对应的变更函数；基于预先建立的函数、运行测试用例以及输出结果之间的第二关联关系，确定所述变更函数的第一运行测试用例以及所述变更函数的第一输出结果；将所述第一运行测试用例中的输入参数输入所述变更函数中，重新运行得到第二输出结果；根据所述第一输出结果和所述第二输出结果对比结果，确定所述待测组件的变更函数的回归测试结果。

其中，变更函数可以理解为待测组件中发生变更的函数，一个函数可以对应多个代码块，代码块可以对应一个函数中的一个分支，因此当一个函数中的至少一个代码块发生变更，则该函数为变更函数。运行测试用例可以是与代码的运行过程相关的测试用例，与上述界面测试用例不同，可以函数为维度，通过分析代码结构并构造其输入参数，以使后续运行后得到其对应的输出结果，每个函数可以对应一个运行测试用例。

第二关联关系可以理解为基于历史版本的目标应用程序确定的函数、运行测试用例以及输出结果之间的关联关系，具体构建过程可以包括：基于历史版本的目标应用程序，生成全量代码对应的运行测试用例，以函数为维度，将运行测试用例中的输入参数输入各函数的代码中运行之后得到其对应的输出结果，将每个运行测试用例、函数以及对应的输出结果之间的对应关系确定为上述第二关联关系。上述历史版本可以为目标应用程序的当前版本的上一版本。

具体的，当待测组件的组件类型为基础组件，回归测试装置可以基于待测组件的提交标识将当前版本的待测组件与上一版本的待测组件的代码进行比较，确定待测组件发生变更的变更代码块，进而确定各变更代码块对应的变更函数；之后可以根据变更函数在预先建立的第二关联关系查找，确定变更函数对应的第一运行测试用例以及第一输出结果；提取第一运行测试用例中的输入参数，将该输入参数输入该变更函数中重新运行，得到相同的入参情况下的第二输出结果；将第一输出结果和第二输出结果进行对比，根据对比结果确定待测组件的变更函数的回归测试结果。

可选的，根据第一输出结果和第二输出结果对比结果，确定待测组件的变更函数的回归测试结果，可以包括：如果第一输出结果与第二输出结果对比结果为相同，则确定待测组件的变更函数的回归测试结果为测试通过；否则，确定待测组件的变更函数的回归测试结果为测试不通过。也即，针对待测组件的变更函数，如果相同的输入参数，第二输出结果与之前记录的第一输出结果相同，则确定回归测试结果为测试通过；否则，确定回归测试结果为测试不通过。

当组件类型为外部组件时，回归测试装置可以直接获取对应的全量测试用例，将该测试用例推送给测试人员，以使测试人员通过该测试用例对上述外部组件进行回归测试，这里的测试用例可以是上述界面测试用例。

本公开实施例提供的回归测试方案，获取目标应用程序的待测组件，待测组件为目标应用程序的代码进行组件化之后的多个组件中的任意一个；确定待测组件的组件类型，并根据组件类型确定对应的回归测试策略；采用待测组件的回归测试策略对待测组件的变更部分进行回归测试。采用上述技术方案，将应用程序的代码的多个组件根据组件类型确定其对应的回归测试策略，并采用不同的回归测试策略对组件的变更部分进行回归测试，实现了通用的多策略精准回归测试，既能够保障质量不劣化，而且节省了回归测试的人力成本，极大提升了回归测试的效率。

在一些实施例中，当待测组件的组件类型为业务组件时，回归测试方法还可以包括：当基于所述第一关联关系未能确定所述第一界面测试用例时，则确定所述变更代码块为新增代码块；采用覆盖率插桩的方式确定所述新增代码块的第二界面测试用例；将所述第二界面测试用例推送至测试人员进行回归测试；在确定所述新增代码块的回归测试结果为测试通过之后，将所述新增代码块与所述第二界面测试用例之间的关联关系添加至所述第一关联关系中。

当待测组件的组件类型为业务组件，回归测试装置如果基于变更代码块在第一关联关系中未能查找到对应的第一界面测试用例，则可以将变更代码块确定为新增代码块，对于该新增代码块可以对目标应用程序的当前代码采用覆盖率插桩的方式确定对应的第二界面测试用例，此时确定的第二界面测试用例可以是历史的界面测试用例中的一个，也可以是新的界面测试用例；之后可以将新增代码块的第二界面测试用例推送给测试人员进行回归测试，在确定新增代码块的回归测试结果为测试通过之后可以将新增代码块与第二界面测试用例之间的关联关系添加至上述第一关联关系中，更新第一关联关系以备后续使用。

上述方案中，当业务组件的变更部分为新增部分时，可以针对新增部分重新确定对应的界面测试用例，并更新代码块和界面测试用例之间的第一关联关系，使得后续可以基于更新后的第一关联关系进行业务组件的回归测试，能够提升回归测试的准确性。

在一些实施例中，当待测组件的组件类型为基础组件时，回归测试方法还可以包括：当基于所述第二关联关系未能确定所述第一运行测试用例时，则确定所述变更函数为新增函数，创建所述新增函数对应的第二运行测试用例；将所述第二运行测试用例推送至测试人员进行回归测试；在确定所述新增函数的回归测试结果为测试通过之后，获取所述新增函数的输出结果，将所述新增函数、所述第二运行测试用例以及其输出结果之间的关联关系添加至所述第二关联关系。

当待测组件的组件类型为基础组件，回归测试装置如果基于变更函数在第二关联关系中未能查找到对应的第一运行测试用例，则变更函数为新增函数，自动生成该新增函数的第二运行测试用例，并将第二运行测试用例推送至测试人员进行回归测试；在测试人员确定新增函数的回归测试结果为测试通过之后，可以获取新增函数的输出结果，该输出结果可以是将第二运行测试用例的输入参数输入新增函数中得到，将新增函数、第二运行测试用例以及输出结果之间的关联关系添加至上述第二关联关系中，更新第二关联关系以备后续使用。

上述方案中，当基础组件的变更函数为新增函数时，可以针对新增函数生成对应的运行测试用例，并更新第二关联关系，使得后续可以基于更新后的第二关联关系进行基础组件的回归测试，能够提升回归测试的准确性。

接下来通过一个具体的示例对本公开实施例中的回归测试方法进行进一步说明。示例性的，图2为本公开实施例提供的另一种回归测试方法的流程示意图，如图2所示，回归测试过程可以包括：

步骤201、封版打包。

在开发应用程序的过程中，开发人员针对应用程序的代码可以进行组件化，得到多个组件，并且确定每个组件的组件类型，并配置对应的类型标识进行区分。

应用程序在封版以后，可以触发回归测试的打包，打包完成后，回调相关信息到保障平台中，本公开实施例的回归测试装置即为该保障平台，之后可以建立对应的测试计划。回调的信息中可以包括当前安装包基于的壳工程(即主仓)的提交标识以及版本号，主仓对应的所有组件的提交标识和版本号。

步骤202、创建测试计划。

在测试计划中，针对不同的组件类型可以设置不同的回归测试策略，进而基于对应的回归测试策略触发不同的回归测试过程，也即触发对应的质量保障流程。本公开实施例中所述组件类型可以包括业务组件、基础组件和外部组件三种类型。

步骤203、校验组件类型。

回归测试装置可以将应用程序的每个组件确定为待测组件，根据其类型标识判断其对应的组件类型，当组件类型为业务组件，可以执行步骤204；当组件类型为基础组件，可以执行步骤205；当组件类型为外部组件，可以执行步骤206。

步骤204、测试用例推送。

如果待测组件的组件类型是业务组件，则可以触发测试用例推送的回归测试流程。

在步骤204之前，可以基于历史版本的应用程序执行界面测试用例，通过覆盖率插桩的方式收集测试过程中执行到的覆盖率数据，也即每个界面测试用例执行到的代码块，在结束后将每个界面测试用例的唯一标识与对应的代码块进行绑定，待所有测试执行完成后，存储代码块与界面测试用例之间的第一关联关系，也即生成推荐模型。之后可以基于上述第一关联关系执行业务组件的回归测试。

示例性的，图3为本公开实施例提供的一种业务组件的回归测试示意图，如图3所示，图中展示了当组件类型为业务组件时的回归测试过程，具体可以包括：根据业务组件的提交标识将当前版本的待测组件的代码与上一版本的业务组件的代码进行比较，确定代码发生变更的变更代码块；当变更代码块为发生修改和/或删除的代码块，利用上述推荐模型中的第一关联关系可以确定变更代码块对应的界面测试用例并加入到测试计划中推荐给测试人员，以使测试人员对变更代码块进行回归测试；而当变更代码块为新增代码块，可以获取测试人员录入的新的界面测试用例或者基于覆盖率插桩的方式重新确定新增代码块与之前的一个界面测试用例的关联关系，并将新增代码块的界面测试用例推荐给测试人员进行回归测试，如果测试通过则可以将新增代码块与其对应的界面测试用例之间的关系添加至上述第一关联关系中。

针对上述变更代码块，如果测试不通过，可以提交漏洞(bug)，针对变更代码块或新增代码块进行修改，再次进行测试，直到测试通过。在业务组件的变更代码块均测试通过之后，可以继续对下一个业务组件进行回归测试，并且测试过程中不断更新上述第一关联关系，等待下一次使用。

步骤205、自动化单测。

如果待测组件的组件类型是基础组件，则触发自动化单测的回归测试流程。

在步骤205之前，可以提前基于历史版本的应用程序，生成全量代码的自动化单测的运行测试用例，运行测试用例以函数为维度，分析代码结构构造其输入参数，运行后记录其对应的输出结果，存储函数、运行测试用例以及输出结果之间的第二关联关系。之后可以基于上述第二关联关系执行基础组件的回归测试

示例性的，图4为本公开实施例提供的一种基础组件的回归测试示意图，如图4所示，图中展示了当组件类型为基础组件时的回归测试过程，具体可以包括：根据基础组件的提交标识将当前版本的待测组件的代码与上一版本的基础组件的代码进行比较，确定代码发生变更的变更代码块所对应的变更函数；针对变更函数，利用第二关联关系确定之前的运行测试用例，在机器上运行输入相同的输入参数，看同样的输入参数，此时的第二输出结果与之前的第一输出结果是否一致，如果一致，则确定该变更函数测试通过；如果不一致，则确定该变更函数测试不通过，并记录下新旧结果。

如图4所示，当利用第二关联关系未确定之前的运行测试用例时，则变更函数为新增函数，可以自动生成对应的运行测试用例，并记录对应的输出结果。针对上述测试不通过的变更函数的运行测试用例以及新增函数的运行测试用例，可以消息的形式推送至测试人员进行人工确认，判断是否通过，如果是，则可以更新上述第二关联关系；如果否，则可以提交漏洞(bug)，针对测试不通过的变更函数或新增函数可以返回进行代码修改，再次进行测试，直到测试通过。在基础组件的变更函数均测试通过之后，可以继续对下一个基础组件进行回归测试，并且测试过程中不断更新上述第二关联关系，等待下一次使用。

步骤206、全量测试。

如果待测组件的组件类型是外部组件，则可以直接将对应的全量的测试用例添加到测试计划中，交由测试人员进行全量测试。

步骤207、是否通过。

上述步骤204、步骤205、步骤206之后均可以执行步骤207，判断回归测试结果是否为通过，当应用程序中全部组件的回归测试结果均为测试通过时，可以执行步骤208；如果任意一个组件的回归测试结果为测试不通过，可以执行步骤209。

步骤208、发版。

步骤209、提交漏洞。

步骤210、修改代码。

步骤201之后可以返回执行步骤203，继续进行回归测试，直到应用程序包括的全部组件的回归测试结果为测试通过，则测试计划结束，应程序的当前版本回归测试完成，可以进行发版。

本方案中提供了一种通用的基于代码变更的多策略精准质量保障体系，针对应用程序的不同组件类型设置不同的回归测试策略，不仅能够实现仅对变更代码影响范围的精准测试，还可以针对不同组件类型的特性实现更加准备的回归测试，从而达到在保障质量不劣化的前提下提高测试效率的目的，并且能够节省回归人力，解决回归压力大的问题。

图5为本公开实施例提供的一种回归测试装置的结构示意图，该装置可由软件和/或硬件实现，一般可集成在电子设备中。如图5所示，该装置包括：

组件模块501，用于获取目标应用程序的待测组件，所述待测组件为所述目标应用程序的代码进行组件化之后的多个组件中的任意一个；

类型模块502，确定所述待测组件的组件类型，并根据所述组件类型确定对应的回归测试策略；

测试模块503，用于采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试。

可选的，所述类型模块502包括第一单元，用于：

根据所述待测组件开发时配置的类型标识确定对应的组件类型。

可选的，所述组件类型包括业务组件、基础组件和外部组件三种类型。

可选的，所述类型模块502包括第二单元，用于：

当所述组件类型为所述业务组件，则对应的回归测试策略为测试用例推送；

当所述组件类型为所述基础组件，则对应的回归测试策略为自动化单测；

当所述组件类型为所述外部组件，则对应的回归测试策略为全量测试。

可选的，当所述组件类型为所述业务组件，所述测试模块503具体用于：

确定所述待测组件的变更代码块；

基于预先建立的代码块与界面测试用例之间的第一关联关系，确定所述待测组件的变更代码块的第一界面测试用例；

将所述第一界面测试用例推送至测试人员以对所述待测组件的变更代码块进行回归测试。

可选的，所述装置还包括第一更新模块，用于：

当基于所述第一关联关系未能确定所述第一界面测试用例时，则确定所述变更代码块为新增代码块；

采用覆盖率插桩的方式确定所述新增代码块的第二界面测试用例；

将所述第二界面测试用例推送至测试人员进行回归测试；

在确定所述新增代码块的回归测试结果为测试通过之后，将所述新增代码块与所述第二界面测试用例之间的关联关系添加至所述第一关联关系中。

可选的，当所述组件类型为所述基础组件，所述测试模块503具体用于：

确定所述待测组件的变更代码块对应的变更函数；

基于预先建立的函数、运行测试用例以及输出结果之间的第二关联关系，确定所述变更函数的第一运行测试用例以及所述变更函数的第一输出结果；

将所述第一运行测试用例中的输入参数输入所述变更函数中，重新运行得到第二输出结果；

根据所述第一输出结果和所述第二输出结果对比结果，确定所述待测组件的变更函数的回归测试结果。

可选的，所述测试模块503具体用于：

如果所述第一输出结果与所述第二输出结果对比结果为相同，则确定所述待测组件的变更函数的回归测试结果为测试通过；否则，确定所述待测组件的变更函数的回归测试结果为测试不通过。

可选的，所述装置还包括第二更新模块，用于：

当基于所述第二关联关系未能确定所述第一运行测试用例时，则确定所述变更函数为新增函数，创建所述新增函数对应的第二运行测试用例；

将所述第二运行测试用例推送至测试人员进行回归测试；

在确定所述新增函数的回归测试结果为测试通过之后，获取所述新增函数的输出结果，将所述新增函数、所述第二运行测试用例以及其输出结果之间的关联关系添加至所述第二关联关系。

本公开实施例所提供的回归测试装置可执行本公开任意实施例所提供的回归测试方法，具备执行方法相应的功能模块和有益效果。

本公开实施例还提供了一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现本公开任意实施例所提供的回归测试方法。

图6为本公开实施例提供的一种电子设备的结构示意图。下面具体参考图6，其示出了适于用来实现本公开实施例中的电子设备600的结构示意图。本公开实施例中的电子设备600可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图6示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本公开实施例的回归测试方法中限定的上述功能。

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

在一些实施方式中，客户端、服务器可以利用诸如HTTP(HyperText TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：获取目标应用程序的待测组件，所述待测组件为所述目标应用程序的代码进行组件化之后的多个组件中的任意一个；确定所述待测组件的组件类型，并根据所述组件类型确定对应的回归测试策略；采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

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

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (12)

1.一种回归测试方法，其特征在于，包括：

获取目标应用程序的待测组件，所述待测组件为所述目标应用程序的代码进行组件化之后的多个组件中的任意一个；

确定所述待测组件的组件类型，并根据所述组件类型确定对应的回归测试策略；

采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试。

2.根据权利要求1所述的方法，其特征在于，确定所述待测组件的组件类型，包括：

根据所述待测组件开发时配置的类型标识确定对应的组件类型。

3.根据权利要求1或2所述的方法，其特征在于，所述组件类型包括业务组件、基础组件和外部组件三种类型。

4.根据权利要求3所述的方法，其特征在于，根据所述组件类型确定对应的回归测试策略，包括：

当所述组件类型为所述业务组件，则对应的回归测试策略为测试用例推送；

当所述组件类型为所述基础组件，则对应的回归测试策略为自动化单测；

当所述组件类型为所述外部组件，则对应的回归测试策略为全量测试。

5.根据权利要求4所述的方法，其特征在于，当所述组件类型为所述业务组件，采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试，包括：

确定所述待测组件的变更代码块；

基于预先建立的代码块与界面测试用例之间的第一关联关系，确定所述待测组件的变更代码块的第一界面测试用例；

将所述第一界面测试用例推送至测试人员以对所述待测组件的变更代码块进行回归测试。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

当基于所述第一关联关系未能确定所述第一界面测试用例时，则确定所述变更代码块为新增代码块；

采用覆盖率插桩的方式确定所述新增代码块的第二界面测试用例；

将所述第二界面测试用例推送至测试人员进行回归测试；

在确定所述新增代码块的回归测试结果为测试通过之后，将所述新增代码块与所述第二界面测试用例之间的关联关系添加至所述第一关联关系中。

7.根据权利要求4所述的方法，其特征在于，当所述组件类型为所述基础组件，采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试，包括：

确定所述待测组件的变更代码块对应的变更函数；

基于预先建立的函数、运行测试用例以及输出结果之间的第二关联关系，确定所述变更函数的第一运行测试用例以及所述变更函数的第一输出结果；

将所述第一运行测试用例中的输入参数输入所述变更函数中，重新运行得到第二输出结果；

根据所述第一输出结果和所述第二输出结果对比结果，确定所述待测组件的变更函数的回归测试结果。

8.根据权利要求7所述的方法，其特征在于，根据所述第一输出结果和所述第二输出结果对比结果，确定所述待测组件的变更函数的回归测试结果，包括：

如果所述第一输出结果与所述第二输出结果对比结果为相同，则确定所述待测组件的变更函数的回归测试结果为测试通过；否则，确定所述待测组件的变更函数的回归测试结果为测试不通过。

9.根据权利要求7所述的方法，其特征在于，所述方法还包括：

当基于所述第二关联关系未能确定所述第一运行测试用例时，则确定所述变更函数为新增函数，创建所述新增函数对应的第二运行测试用例；

将所述第二运行测试用例推送至测试人员进行回归测试；

在确定所述新增函数的回归测试结果为测试通过之后，获取所述新增函数的输出结果，将所述新增函数、所述第二运行测试用例以及其输出结果之间的关联关系添加至所述第二关联关系。

10.一种回归测试装置，其特征在于，包括：

组件模块，用于获取目标应用程序的待测组件，所述待测组件为所述目标应用程序的代码进行组件化之后的多个组件中的任意一个；

类型模块，确定所述待测组件的组件类型，并根据所述组件类型确定对应的回归测试策略；

测试模块，用于采用所述待测组件的回归测试策略对所述待测组件的变更部分进行回归测试。

11.一种电子设备，其特征在于，所述电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述权利要求1-9中任一所述的回归测试方法。

12.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序用于执行上述权利要求1-9中任一所述的回归测试方法。

Images