CN113448854A - 一种回归测试方法和装置 - Google Patents

Abstract

本发明公开了一种回归测试方法和装置，涉及自动程序设计技术领域。该方法的一具体实施方式包括：获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件；根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元；其中，所述关联关系用于记录实现所述业务单元的类文件；对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。该实施方式实现了有针对性、有重点的回归测试，同时可以通过数据埋点实时生成测试报告，方便项目成员查看。

Description

一种回归测试方法和装置

技术领域

本发明涉及自动程序设计技术领域，尤其涉及一种回归测试方法和装置。

背景技术

在软件生命周期的各个阶段，可能会由于软件自身缺陷、用户需求变更等情况，对软件代码进行修改。为了保证代码修改后软件的功能正常，除了对新增功能项进行测试之外，还需要对软件的功能进行全量回归测试。

目前采用的回归测试是全量无差别的回归测试，没有针对性，如果软件的复杂度较高、界面较多，容易遗漏可能受代码修改影响的界面，导致其未被测试。而且测试人员在回归测试过程中，其他项目成员无法获知回归测试的覆盖率，无法确定受代码修改影响的功能是否被测试。

发明内容

有鉴于此，本发明实施例提供一种回归测试方法和装置，通过比较新旧版本代码的差异，得到存在变更的类文件，进而根据关联关系和调用关系，确定受代码变更影响的业务单元，对这些业务单元进行回归测试，实现了有针对性、有重点的回归测试，同时可以通过数据埋点实时生成测试报告，方便项目成员查看。

为实现上述目的，根据本发明实施例的一个方面，提供了一种回归测试方法。

本发明实施例的一种回归测试方法，包括：获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件；根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元；其中，所述关联关系用于记录实现所述业务单元的类文件；对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。

可选地，所述比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件，包括：对所述新版本代码和所述旧版本代码分别进行解析，对应得到第一解析文件和第二解析文件；比较所述第一解析文件和所述第二解析文件中同一个类文件所包含的目标对象是否一致，存在所述目标对象不一致情况的类文件即为存在变更的类文件。

可选地，所述根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元，包括：从所述存在变更的至少一个类文件中选择出当前类文件，重复执行以下步骤，直至最后一个类文件：根据类文件之间的调用关系，查询所述当前类文件调用的其他类文件；根据设定的业务单元与类文件的关联关系，查询与所述当前类文件存在关联关系的第一业务单元，以及与所述其他类文件存在关联关系的第二业务单元，所述第一业务单元和所述第二业务单元构成所述当前类文件变更所影响的业务单元；从所述存在变更的至少一个类文件中选择出下一类文件，将所述下一类文件更新为所述当前类文件。

可选地，所述对所述业务单元进行回归测试，包括：根据设定的业务单元与测试用例之间的对应关系，从测试用例集中选择与所述业务单元相关的测试用例；其中，所述测试用例包括测试参数；根据选择出的所述测试用例中的测试参数，对所述业务单元的业务代码进行执行处理，得到对应的测试数据。

可选地，所述方法还包括：在所述业务单元的业务代码中添加埋点代码；其中，所述埋点代码用于在埋点事件被触发后，采集生成的测试数据。

可选地，所述在所述业务单元的业务代码中添加埋点代码，包括：获取设定的所述业务代码的切入点，其中，所述切入点包括待添加埋点代码的业务函数的标识；根据所述切入点，获取所述业务代码中设置有埋点注解的业务函数，将所述埋点代码添加到设置有埋点注解的业务函数；其中，所述埋点注解包括所述埋点事件以及所述埋点事件要采集的数据项。

可选地，所述根据所述切入点，获取所述业务代码中设置有埋点注解的业务函数，包括：将所述切入点中包括的业务函数的标识与所述业务代码中包括的业务函数的标识进行匹配，获得所述业务代码中设置有埋点注解的业务函数。

可选地，所述测试用例还包括：期望结果；所述根据所述测试数据生成测试报告，包括：根据所述测试用例对应的测试报告名称，确定相应的测试报告模板；将所述测试数据中的执行结果与所述预期结果进行对比，得到比对结果，将所述对比结果写入所述测试报告模板的相应字段。

可选地，所述根据所述测试数据生成测试报告，包括：确定已完成回归测试的业务单元的数量，根据所述数量，计算测试覆盖率；将所述测试覆盖率写入所述测试报告模板的相应字段。

可选地，所述方法还包括：判断所述测试覆盖率是否大于等于设定的覆盖率阈值，如果所述测试覆盖率大于或者等于所述覆盖率阈值，则在所述测试报告中添加第一标记；如果所述测试覆盖率小于所述覆盖率阈值，则在所述测试报告中添加第二标记。

可选地，所述获取目标应用的新版本代码与旧版本代码，包括：当检测到代码仓库中目标应用的代码发生变更时，通过构建的同步任务，将所述代码仓库的新版本代码进行同步。

可选地，所述检测到代码仓库中目标应用的代码发生变更，包括：检测到代码仓库中目标应用的触发事件；其中，所述触发事件包括提交事件、推送事件、合并请求事件中的任意一个或者多个。

可选地，所述通过构建的同步任务的步骤之前，所述方法还包括：统计代码变更次数，比较所述代码变更次数与设定变更次数上限的大小；如果所述代码变更次数大于或者等于所述变更次数上限，则使用构建工具构建所述同步任务。

为实现上述目的，根据本发明实施例的另一方面，提供了一种回归测试装置。

本发明实施例的一种回归测试装置，包括：版本比较模块，用于获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件；变更分析模块，用于根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元；其中，所述关联关系用于记录实现所述业务单元的类文件；测试执行模块，用于对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。

可选地，所述版本比较模块，还用于：对所述新版本代码和所述旧版本代码分别进行解析，对应得到第一解析文件和第二解析文件；比较所述第一解析文件和所述第二解析文件中同一个类文件所包含的目标对象是否一致，存在所述目标对象不一致情况的类文件即为存在变更的类文件。

可选地，所述变更分析模块，还用于从所述存在变更的至少一个类文件中选择出当前类文件，重复执行以下步骤，直至最后一个类文件：根据类文件之间的调用关系，查询所述当前类文件调用的其他类文件；根据设定的业务单元与类文件的关联关系，查询与所述当前类文件存在关联关系的第一业务单元，以及与所述其他类文件存在关联关系的第二业务单元，所述第一业务单元和所述第二业务单元构成所述当前类文件变更所影响的业务单元；从所述存在变更的至少一个类文件中选择出下一类文件，将所述下一类文件更新为所述当前类文件。

可选地，所述测试执行模块，还用于根据设定的业务单元与测试用例之间的对应关系，从测试用例集中选择与所述业务单元相关的测试用例；其中，所述测试用例包括测试参数；根据选择出的所述测试用例中的测试参数，对所述业务单元的业务代码进行执行处理，得到对应的测试数据。

可选地，所述装置还包括：埋点模块，用于在所述业务单元的业务代码中添加埋点代码；其中，所述埋点代码用于在埋点事件被触发后，采集生成的测试数据。

可选地，所述埋点模块，还用于获取设定的所述业务代码的切入点，其中，所述切入点包括待添加埋点代码的业务函数的标识；根据所述切入点，获取所述业务代码中设置有埋点注解的业务函数，将所述埋点代码添加到设置有埋点注解的业务函数；其中，所述埋点注解包括所述埋点事件以及所述埋点事件要采集的数据项。

可选地，所述埋点模块，还用于将所述切入点中包括的业务函数的标识与所述业务代码中包括的业务函数的标识进行匹配，获得所述业务代码中设置有埋点注解的业务函数。

可选地，所述测试用例还包括：期望结果；所述测试执行模块，还用于根据所述测试用例对应的测试报告名称，确定相应的测试报告模板；将所述测试数据中的执行结果与所述预期结果进行对比，得到比对结果，将所述对比结果写入所述测试报告模板的相应字段。

可选地，所述测试执行模块，还用于确定已完成回归测试的业务单元的数量，根据所述数量，计算测试覆盖率；将所述测试覆盖率写入所述测试报告模板的相应字段。

可选地，所述装置还包括：标记模块，用于判断所述测试覆盖率是否大于等于设定的覆盖率阈值，如果所述测试覆盖率大于或者等于所述覆盖率阈值，则在所述测试报告中添加第一标记；如果所述测试覆盖率小于所述覆盖率阈值，则在所述测试报告中添加第二标记。

可选地，所述版本比较模块，还用于当检测到代码仓库中目标应用的代码发生变更时，通过构建的同步任务，将所述代码仓库的新版本代码进行同步。

可选地，所述版本比较模块，还用于检测到代码仓库中目标应用的触发事件；其中，所述触发事件包括提交事件、推送事件、合并请求事件中的任意一个或者多个。

可选地，所述版本比较模块，还用于统计代码变更次数，比较所述代码变更次数与设定变更次数上限的大小；如果所述代码变更次数大于或者等于所述变更次数上限，则使用构建工具构建所述同步任务。

为实现上述目的，根据本发明实施例的再一方面，提供了一种电子设备。

本发明实施例的一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种回归测试方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质。

本发明实施例的一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种回归测试方法。

上述发明中的一个实施例具有如下优点或有益效果：通过比较新旧版本代码的差异，得到存在变更的类文件，进而根据关联关系和调用关系，确定受代码变更影响的业务单元，对这些业务单元进行回归测试，实现了有针对性、有重点的回归测试，同时可以通过数据埋点实时生成测试报告，方便项目成员查看。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明一实施例的回归测试方法的主要步骤的示意图；

图2是根据本发明又一实施例的回归测试方法的主要流程示意图；

图3是本发明实施例的确定类文件变更所影响的业务单元的主要流程示意图；

图4是根据本发明再一实施例的回归测试方法的主要流程示意图；

图5是根据本发明实施例的回归测试装置的主要模块的示意图；

图6是本发明实施例可以应用于其中的示例性系统架构图；

图7是适用于来实现本发明实施例的电子设备的计算机装置的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

下面对本发明涉及的术语进行解释。

埋点：是指针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。比如用户对某个图标点击次数、观看某个视频的时长等。埋点的实质是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。

实施例一

图1是根据本发明一实施例的回归测试方法的主要步骤的示意图。如图1所示，本发明实施例的回归测试方法，主要包括如下步骤：

步骤S101：获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件。代码开发完成后，开发人员会提交代码至代码仓库。当检测到代码仓库中目标应用的代码发生变更时，获取该目标应用的新版本代码和旧版本代码。

将新版本代码和旧版本代码进行对比，确定存在变更的类文件。实施例中，对新版本代码和旧版本代码分别进行解析，对应得到第一解析文件和第二解析文件，之后比较第一解析文件和第二解析文件中同一个类文件所包含的目标对象是否一致，存在目标对象不一致情况的类文件即为存在变更的类文件。

步骤S102：根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元。业务单元为目标应用的一个功能模块，比如登录功能对应登录单元，车险功能对应车险单元。每个类文件负责实现业务单元的一部分功能，并通过关联关系记录实现业务单元的全部类文件。

一个类文件是指一个程序方法的集合，这些程序方法可能会引用到另一个类文件的方法，在引用时会在类文件中声明其引用的其他类文件的名称，通过对第一解析文件和第二解析文件中的所有类文件进行分析，即可得到类文件之间的调用关系。

在确定某个类文件变更所影响的业务单元时，需根据类文件之间的调用关系，查询其调用的其他类文件，之后根据业务单元与类文件之间的关联关系，查询与该类文件存在关联关系的业务单元，以及与其他类文件存在关联关系的业务单元，查询出的这两部分业务单元即为受该类文件变更所影响的业务单元。

步骤S103：对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。该步骤用于在确定出类文件变更所影响的业务单元之后，对该业务单元进行回归测试以及生成测试报告。

为了实时获知回归测试的测试结果，在目标应用的业务单元中预先设置数据埋点，在代码运行到埋点位置时，可以自动采集测试数据。之后根据采集到的测试数据，生成测试报告，将测试报告推送至相关项目成员，以使相关项目成员可以实时获知回归测试的测试结果。其中，数据埋点是指在业务单元的业务代码中插入埋点代码，以使程序运行到埋点代码插入位置时，可以上报数据，以采集该位置的数据。

上述实施例通过比较新旧版本代码的差异，得到存在变更的类文件，进而根据关联关系和调用关系，识别出了受代码变更影响、需要重点测试的业务单元，对这些业务单元进行回归测试，即实现了有针对性、有重点的回归测试。同时通过数据埋点实时生成测试报告，便于项目成员及时获知回归测试的测试结果。

实施例二

图2是根据本发明又一实施例的回归测试方法的主要流程示意图。如图2所示，本发明实施例的回归测试方法，由服务器执行，主要包括如下步骤：

步骤S201：在目标应用各业务单元的业务代码中添加埋点代码。其中，埋点代码用于在埋点事件被触发后，采集生成的测试数据。埋点事件用于追踪或记录用户操作行为或者业务过程，实施例中，埋点事件可以为一种用户操作行为，如单击行为、双击行为，也可以为一个业务过程，如注册账户、登录账户、观看视频等。

实施例中，该步骤可以通过以下过程实现：获取设定的业务代码的切入点，该切入点包括待添加埋点代码的业务函数的标识；之后根据切入点，获取业务代码中设置有埋点注解的业务函数，并将埋点代码添加到设置有埋点注解的业务函数。上述过程实现了埋点代码的自动写入，无需人工参与，降低了业务代码与埋点代码的耦合性。

其中，埋点注解可以包括埋点事件以及埋点事件要采集的数据项。示例性地，以单击行为作为埋点事件，该埋点事件要采集的数据项可以为点击时间、点击位置、产生点击行为的用户的用户名、密码等。

在一可选的实施例中，在获取业务代码中设置有埋点注解的业务函数时，可以通过将切入点中包括的业务函数的标识与业务代码中包括的业务函数的标识进行匹配得到。

步骤S202：检测代码仓库中目标应用的代码变更情况，获取目标应用的新版本代码与旧版本代码。检测代码仓库中目标应用的触发事件，如果检测到触发事件，则说明存在代码变更情况。之后通过构建同步任务，将代码仓库的新版本代码同步至服务器，将对应的旧版本代码也存储至该服务器。该处理可以自动完成代码同步，保证能够及时获取到最新代码，提高测试效率。

日常应用中，通常由多个开发人员共同进行目标应用的代码开发，因此可以采用分布式版本控制系统Git实现项目版本管理。具体地，开发人员可以在自己机器上创建分支，修改代码，进而在自己创建的分支上提交代码、合并分支等操作。故实施例中，触发事件可以是提交事件、推送事件、合并请求事件中的任意一个或者多个。

在构建同步任务时，可以基于持续集成工具Jenkins实现。其中，Jenkins用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能，其功能包括持续的软件版本发布/测试项目，以及监控外部调用执行的工作。由于Jenkins提供远程触发支持，只要接收到远程触发消息就会执行同步任务，比人工手动同步更高效，比定时同步更实时。

在一优选的实施例中，为了合理利用服务器资源，可以在代码变更次数达到变更次数上限后，在构建同步任务，进而触发代码同步。具体地，统计代码变更次数，比较代码变更次数与设定变更次数上限(可以自定义设置)的大小；当代码变更次数大于或者等于变更次数上限时，则使用构建工具构建同步任务。

步骤S203：比较新版本代码与旧版本代码的差异，得到存在变更的至少一个类文件。该步骤中对新、旧版本代码分别进行解析，得到对应的解析文件，之后比较两个解析文件中同一个类文件所包含的目标对象是否一致，此处的目标对象可以为变量、方法，如果不一致，则记录该类文件。通过比对两个解析文件中全部类文件，即可得到全量的存在变更的类文件列表。

比如，目标应用新版本的安装包为new.apk，旧版本的安装包为old.apk，则对new.apk和old.apk分别进行解压缩，得到各自内部的classes.dex文件。之后对两个classes.dex文件分别进行解析，获取各自定义的所有类，然后对比新、旧版本中代表同一个类的变量、方法是否一致，如果不一致，记录下这个类。通过对比所有的类，就可以得到全量、存在变更的类文件列表。

其中，dex文件是安卓平台的一种文件格式，该文件包含所有的程序代码，可以被客户端中的虚拟机环境识别，并进行加载执行。可以理解的是，如果新版本对应的classes.dex文件解析后，相比旧版本存在增加的类(或者减少的类)，说明该类是新增类(或者删除类)，同样记录该类。

步骤S204：根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定类文件变更所影响的业务单元。所有类中，每个类负责实现业务单元的部分功能，比如recode.java类对应钱包明细单元，code.java类对应钱包二维码单元，settings.java代表设置模块，将这些业务单元与类文件的关联关系预先保存到服务器。如果比对过程中发现code.java类发生变更，则可以确定钱包二维码单元受到变更影响，需要进行回归测试。

另外，如前所述，一个类文件可能会引用到另一个类文件的方法，在引用时会在类文件中声明其引用的其他类文件的名称，通过对classes.dex文件的所有类进行分析，即可得到类文件之间的调用关系。该步骤的具体实现见图3以及相关说明。

步骤S205：对业务单元进行回归测试，并在回归测试过程中，通过为业务单元设置的数据埋点采集测试数据。对业务单元进行回归测试的具体实现为：根据设定的业务单元与测试用例之间的对应关系，从测试用例集中选择与业务单元相关的测试用例；之后根据选择出的测试用例包含的信息，对业务单元的业务代码进行执行处理，得到对应的测试数据。

上述回归测试的过程实现了自动回归测试，无需人工参与，提高测试效率。实施例中，测试用例可以包括测试参数、期望结果，还可以包括外部调用数据(即执行业务代码所需要的外部数据)。

在回归测试中，由于为业务单元设置了数据埋点，在埋点事件被触发时，上报数据至服务器，由服务器采集测试数据。

步骤S206：根据测试数据，生成测试报告后，输出测试报告。为了自动生成测试报告，可以预先为各测试用例配置测试报告模板。在得到测试数据后，可以根据测试用例对应的测试报告名称，确定相应的测试报告模板；之后将测试数据中的执行结果与预期结果进行对比，得到比对结果，将对比结果写入测试报告模板的相应字段。

比如，假设回归测试使用的测试用例为测试用例1，而测试用例1配置的测试报告模板为模板1，则将测试数据的执行结果与测试用例1中的预期结果比对后，将比对结果写入模板1的相应字段(比如测试结果字段)。示例性地，执行结果与预期结果一致，则测试结果字段为测试通过；如果执行结果与预期结果不一致，则测试结果字段为测试失败。

在一优选的实施例中，为了防止遗漏需要重点测试的业务单元，可以自动、实时统计测试覆盖率。具体地，在回归测试执行完成后，统计已完成回归测试的业务单元的数量(下文称为第一数量)，根据该第一数量和步骤S204确定的业务单元的数量(下文称为第二数量)，计算测试覆盖率，并将测试覆盖率写入测试报告模板的相应字段(比如测试覆盖率字段)。其中，测试覆盖率的计算公式为：

测试覆盖率＝第一数量/第二数量*100％

公式1

示例性地，假设步骤S204确定出的业务单元为业务单元A、业务单元B、业务单元C和业务单元D，假设业务单元A和业务单元B进行了回归测试，数据埋点接口会采集数据上传到服务器，服务器标记业务单元A和业务单元B已经完成回归测试，并按照公式1计算测试覆盖率为2/4*100％＝50％。

在另一优选的实施例中，为了清楚的获知测试覆盖情况，可以在测试报告中添加标记来进行区分。具体地，判断测试覆盖率是否大于等于设定的覆盖率阈值，如果测试覆盖率大于或者等于覆盖率阈值，则在测试报告中添加第一标记；如果测试覆盖率小于覆盖率阈值，则在测试报告中添加第二标记。其中，第一标记用于标识测试覆盖率满足需求，第二标记用于标识测试覆盖率不满足需求。

图3是本发明实施例的确定类文件变更所影响的业务单元的主要流程示意图。如图3所示，本发明实施例的确定类文件变更所影响的业务单元(即步骤S102、步骤S204)，主要包括如下步骤：

步骤S301：将存在变更的至少一个类文件添加到变更类文件集，从变更类文件集中选择出当前类文件。初始化变更类文件集，将存在变更的全部类文件添加到变更类文件集，之后可以随机选择一个类文件作为当前类文件。

步骤S302：根据类文件之间的调用关系，查询当前类文件调用的其他类文件。比如，类文件1包含方法1和方法2，方法1引用类文件2中的方法3，方法2引用类文件3中的方法4，则可知类文件1调用的其他类文件即类文件2和类文件3。

步骤S303：根据设定的业务单元与类文件的关联关系，查询与当前类文件存在关联关系的第一业务单元，以及与其他类文件存在关联关系的第二业务单元，获得当前类文件变更所影响的业务单元。第一业务单元和第二业务单元构成当前类文件变更所影响的业务单元。假设类文件1实现了业务单元1的部分功能，类文件2和类文件3实现了业务单元2的部分功能，则可知类文件1变更所影响的业务单元为业务单元1和业务单元2。

步骤S304：判断当前类文件是否为变更类文件集的最后一个文件，如果当前类文件不是变更类文件集的最后一个文件，则执行步骤S305；如果当前类文件是变更类文件集的最后一个文件，则结束本流程。

步骤S305：从变更类文件集中选择出下一类文件，将下一类文件更新为当前类文件，执行步骤S302。该步骤用于从变更类文件集中不重复地选择下一类文件，并将其更新为当前类文件，以重复执行步骤S302-步骤S305。

实施例三

图4是根据本发明再一实施例的回归测试方法的主要流程示意图。如图4所示，本发明实施例的回归测试方法，主要包括以下步骤：

步骤S401：Jenkins工具从代码仓库中同步新版本代码。需求业务人员提出开发需求给开发人员，开发人员根据开发需求进行开发，提交新版本代码至Git代码仓库。Jenkins工具自动从Git代码仓库中同步代码。

步骤S402：Jenkins工具启动编译过程，对新版本代码进行编译，生成新的应用安装包。

步骤S403：Jenkins工具将新的应用安装包上传至对比服务器。其中，对比服务器用于根据关联关系、调用关系分析得到受类文件变更影响的业务单元，这些业务单元即需要重点进行回归测试的业务单元。比如修改了一个位置定位的函数类，假设在地图单元、导航单元都引用到了这个函数类，则需要重点回归测试地图单元和导航单元的功能。

步骤S404：对比服务器将新的应用安装包与旧版本代码对应的应用安装包进行差别比对，得到存在变更的至少一个类文件。该步骤的具体实现见步骤S203，此处不再赘述。

步骤S405：对比服务器根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定类文件变更所影响的业务单元。该步骤的具体实现见步骤S204，此处不再赘述。

步骤S406：对比服务器将受变更影响的业务单元设定为重点测试项，设定数据埋点采集需求。对比服务器对重点回归测试的业务单元设定一个数据埋点采集的需求，用于得到回归测试的测试覆盖率。

步骤S407：对比服务器生成待重点测试的业务单元清单，将业务单元清单提交至管理服务器。实施例中，业务单元清单包括需要重点测试的业务单元的功能项。

步骤S408：测试人员从管理服务器获取业务单元清单，之后对业务单元清单中的业务单元进行回归测试，在回归测试过程中触发数据埋点，将测试数据反馈至管理服务器。

该步骤即实现了有针对性的回归测试。测试人员对目标应用进行回归测试的过程中，会触发目标应用内部预先设置好的业务单元的数据埋点，进而将测试数据反馈给管理服务器。可以理解的是，该步骤中测试人员手动实现的回归测试也可以基于步骤S205自动实现。

步骤S409：管理服务器根据测试数据，生成测试报告。该步骤的具体实现见步骤S206，此处不再赘述。测试报告生成后，可以由管理服务器将测试报告推送至项目成员。比如推送至需求业务人员，以使需求业务人员实时获知测试结果。

该实施例可以自动识别出受代码修改影响的业务单元，并自动生成需要重点测试的业务单元清单，提供给测试人员测试，在测试过程中自动触发埋点数据上报功能，实现了自动、实时地统计回归测试的测试覆盖率。

图5是根据本发明实施例的回归测试装置的主要模块的示意图。

如图5所示，本发明实施例的回归测试装置500，主要包括：

版本比较模块501，用于获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件。代码开发完成后，开发人员会提交代码至代码仓库。当检测到代码仓库中目标应用的代码发生变更时，获取该目标应用的新版本代码和旧版本代码。

将新版本代码和旧版本代码进行对比，确定存在变更的类文件。实施例中，对新版本代码和旧版本代码分别进行解析，对应得到第一解析文件和第二解析文件，之后比较第一解析文件和第二解析文件中同一个类文件所包含的目标对象是否一致，存在目标对象不一致情况的类文件即为存在变更的类文件。

变更分析模块502，用于根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元。业务单元为目标应用的一个功能模块，比如登录功能对应登录单元，车险功能对应车险单元。每个类文件负责实现业务单元的一部分功能，并通过关联关系记录实现业务单元的全部类文件。

一个类文件是指一个程序方法的集合，这些程序方法可能会引用到另一个类文件的方法，在引用时会在类文件中声明其引用的其他类文件的名称，通过对第一解析文件和第二解析文件中的所有类文件进行分析，即可得到类文件之间的调用关系。

在确定某个类文件变更所影响的业务单元时，需根据类文件之间的调用关系，查询其调用的其他类文件，之后根据业务单元与类文件之间的关联关系，查询与该类文件存在关联关系的业务单元，以及与其他类文件存在关联关系的业务单元，查询出的这两部分业务单元即为受该类文件变更所影响的业务单元。

测试执行模块503，用于对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。该步骤用于在确定出类文件变更所影响的业务单元之后，对该业务单元进行回归测试以及生成测试报告。

为了实时获知回归测试的测试结果，在目标应用的业务单元中预先设置数据埋点，在代码运行到埋点位置时，可以自动采集测试数据。之后根据采集到的测试数据，生成测试报告，将测试报告推送至相关项目成员，以使相关项目成员可以实时获知回归测试的测试结果。其中，数据埋点是指在业务单元的业务代码中插入埋点代码，以使程序运行到埋点代码插入位置时，可以上报数据，以采集该位置的数据。

另外，本发明实施例的回归测试装置500还可以包括：埋点模块和标记模块(图5中未示出)。其中，埋点模块，用于在所述业务单元的业务代码中添加埋点代码；其中，所述埋点代码用于在埋点事件被触发后，采集生成的测试数据。

标记模块，用于判断所述测试覆盖率是否大于等于设定的覆盖率阈值，如果所述测试覆盖率大于或者等于所述覆盖率阈值，则在所述测试报告中添加第一标记；如果所述测试覆盖率小于所述覆盖率阈值，则在所述测试报告中添加第二标记。

从以上描述可以看出，通过比较新旧版本代码的差异，得到存在变更的类文件，进而根据关联关系和调用关系，确定受代码变更影响的业务单元，对这些业务单元进行回归测试，实现了有针对性、有重点的回归测试，同时可以通过数据埋点实时生成测试报告，方便项目成员查看。

图6示出了可以应用本发明实施例的回归测试方法或回归测试装置的示例性系统架构600。

如图6所示，系统架构600可以包括网络601、602和服务器603、604、605。网络601用以在服务器603和服务器604之间提供通信链路的介质，网络602用以在服务器604和服务器605之间提供通信链路的介质。网络601、602可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

服务器603、604、605可以是提供各种服务的服务器。例如服务器603可以从代码仓库同步新版本代码，将新版本代码编译、打包后上传至服务器604。服务器604可以比较新版本代码与旧版本代码的差异，确定存在变更的类文件，以及受类文件变更影响的业务单元，生成待回归测试的业务单元清单，并发送至服务器605。服务器605基于业务单元清单进行回归测试，生成测试报告。

需要说明的是，本申请实施例所提供的回归测试方法一般由服务器604和605执行，相应地，回归测试装置一般设置于服务器604和605中。

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

根据本发明的实施例，本发明还提供了一种电子设备和一种计算机可读介质。

本发明的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例的一种回归测试方法。

本发明的计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现本发明实施例的一种回归测试方法。

下面参考图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等等，或者上述的任意合适的组合。

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

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括版本比较模块、变更分析模块和测试执行模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，版本比较模块还可以被描述为“获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件；根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元；其中，所述关联关系用于记录实现所述业务单元的类文件；对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。

根据本发明实施例的技术方案，通过比较新旧版本代码的差异，得到存在变更的类文件，进而根据关联关系和调用关系，确定受代码变更影响的业务单元，对这些业务单元进行回归测试，实现了有针对性、有重点的回归测试，同时可以通过数据埋点实时生成测试报告，方便项目成员查看。

上述产品可执行本发明实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例所提供的方法。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (17)

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

获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件；

根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元；其中，所述关联关系用于记录实现所述业务单元的类文件；

对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。

2.根据权利要求1所述的方法，其特征在于，所述比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件，包括：

对所述新版本代码和所述旧版本代码分别进行解析，对应得到第一解析文件和第二解析文件；

比较所述第一解析文件和所述第二解析文件中同一个类文件所包含的目标对象是否一致，存在所述目标对象不一致情况的类文件即为存在变更的类文件。

3.根据权利要求1所述的方法，其特征在于，所述根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元，包括：

从所述存在变更的至少一个类文件中选择出当前类文件，重复执行以下步骤，直至最后一个类文件：

根据类文件之间的调用关系，查询所述当前类文件调用的其他类文件；

根据设定的业务单元与类文件的关联关系，查询与所述当前类文件存在关联关系的第一业务单元，以及与所述其他类文件存在关联关系的第二业务单元，所述第一业务单元和所述第二业务单元构成所述当前类文件变更所影响的业务单元；

从所述存在变更的至少一个类文件中选择出下一类文件，将所述下一类文件更新为所述当前类文件。

4.根据权利要求1所述的方法，其特征在于，所述对所述业务单元进行回归测试，包括：

根据设定的业务单元与测试用例之间的对应关系，从测试用例集中选择与所述业务单元相关的测试用例；其中，所述测试用例包括测试参数；

根据选择出的所述测试用例中的测试参数，对所述业务单元的业务代码进行执行处理，得到对应的测试数据。

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

在所述业务单元的业务代码中添加埋点代码；其中，所述埋点代码用于在埋点事件被触发后，采集生成的测试数据。

6.根据权利要求5所述的方法，其特征在于，所述在所述业务单元的业务代码中添加埋点代码，包括：

获取设定的所述业务代码的切入点，其中，所述切入点包括待添加埋点代码的业务函数的标识；

根据所述切入点，获取所述业务代码中设置有埋点注解的业务函数，将所述埋点代码添加到设置有埋点注解的业务函数；其中，所述埋点注解包括所述埋点事件以及所述埋点事件要采集的数据项。

7.根据权利要求6所述的方法，其特征在于，所述根据所述切入点，获取所述业务代码中设置有埋点注解的业务函数，包括：

将所述切入点中包括的业务函数的标识与所述业务代码中包括的业务函数的标识进行匹配，获得所述业务代码中设置有埋点注解的业务函数。

8.根据权利要求4所述的方法，其特征在于，所述测试用例还包括：期望结果；

所述根据所述测试数据生成测试报告，包括：

根据所述测试用例对应的测试报告名称，确定相应的测试报告模板；

将所述测试数据中的执行结果与所述预期结果进行对比，得到比对结果，将所述对比结果写入所述测试报告模板的相应字段。

9.根据权利要求8所述的方法，其特征在于，所述根据所述测试数据生成测试报告，包括：

确定已完成回归测试的业务单元的数量，根据所述数量，计算测试覆盖率；

将所述测试覆盖率写入所述测试报告模板的相应字段。

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

判断所述测试覆盖率是否大于等于设定的覆盖率阈值，如果所述测试覆盖率大于或者等于所述覆盖率阈值，则在所述测试报告中添加第一标记；

如果所述测试覆盖率小于所述覆盖率阈值，则在所述测试报告中添加第二标记。

11.根据权利要求1至11的任一项所述的方法，其特征在于，所述获取目标应用的新版本代码与旧版本代码，包括：

当检测到代码仓库中目标应用的代码发生变更时，通过构建的同步任务，将所述代码仓库的新版本代码进行同步。

12.根据权利要求11所述的方法，其特征在于，所述检测到代码仓库中目标应用的代码发生变更，包括：

检测到代码仓库中目标应用的触发事件；其中，所述触发事件包括提交事件、推送事件、合并请求事件中的任意一个或者多个。

13.根据权利要求11所述的方法，其特征在于，所述通过构建的同步任务的步骤之前，所述方法还包括：

统计代码变更次数，比较所述代码变更次数与设定变更次数上限的大小；

如果所述代码变更次数大于或者等于所述变更次数上限，则使用构建工具构建所述同步任务。

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

版本比较模块，用于获取目标应用的新版本代码与旧版本代码，比较所述新版本代码与所述旧版本代码的差异，得到存在变更的至少一个类文件；

变更分析模块，用于根据设定的业务单元与类文件的关联关系，以及类文件之间的调用关系，确定所述类文件变更所影响的业务单元；其中，所述关联关系用于记录实现所述业务单元的类文件；

测试执行模块，用于对所述业务单元进行回归测试，在回归测试过程中，通过为所述业务单元设置的数据埋点采集测试数据，之后根据所述测试数据生成测试报告。

15.根据权利要求14所述的装置，其特征在于，所述版本比较模块，还用于：

对所述新版本代码和所述旧版本代码分别进行解析，对应得到第一解析文件和第二解析文件；

比较所述第一解析文件和所述第二解析文件中同一个类文件所包含的目标对象是否一致，存在所述目标对象不一致情况的类文件即为存在变更的类文件。

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

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-13中任一所述的方法。

17.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-13中任一所述的方法。

Images