热更新测试方法及装置、电子设备、存储介质与流程

1.本技术涉及计算机技术领域，特别是涉及热更新测试方法及装置、电子设备、存储介质。


背景技术：

2.如今，手机游戏已经成为一种越来越普遍的娱乐形式，随着游戏市场规模的不断扩大，游戏行业的竞争也日益激烈。为了保住留存，吸引更多的玩家，大部分游戏都会采用周版本的方式来更新游戏内容(即每7天更新一次游戏内容)，确保玩家在不更新游戏应用程序的版本的情况下，也可以体验到更多新的内容；此种在不发布新版本的情况下，更新应用程序内容的更新方式为热更新。
3.目前，对应用程序的热更新测试方式，一般是基于svn(subversion，开放源代码的版本控制系统)仓库进行热更新测试。
4.程序设计人员需要将代码提交到svn仓库进行测试，当已有热更内容在进行测试时，在后提交的热更内容无法单独完成外放，需要等待在先提交的热更内容完成测试后一起外放，测试效率低下。此外，由于测试完成后，需要程序设计人员重新编译外放包体，若此时程序设计人员误提交代码，则会导致错误内容被外放，造成产品质量风险。


技术实现要素：

5.鉴于上述问题，提出了本技术以便提供克服上述问题或者至少部分地解决上述问题的热更新测试方法及装置、电子设备、存储介质，包括：
6.一种热更新测试方法，所述方法包括：
7.响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；
8.将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；
9.在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
10.可选地，所述响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件，还包括：
11.判断所述热更新指令是否携带热更新单号信息；
12.若是，则获取与所述热更新单号信息对应的热更新修复代码；
13.根据所述热更新修复代码生成对应的热更新修复文件。
14.可选地，在将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体之前，还包括：
15.创建与当前热更新周期对应的热更新修复分支，所述热更新修复分支对应的基线
包体是上一个热更新周期结束时得到的用于外放的包体。
16.可选地，所述在所述热更新修复包体测试成功后，生成与所述热更新修复文件对应的、用于外放的目标包体，包括：
17.在所述热更新修复包体测试成功后，接收针对所述热更新修复文件的合入请求；
18.基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
19.可选地，所述合入请求携带所述热更新单号信息，所述基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体，包括：
20.判断所述热更新单号信息对应的热更新需求单的状态信息是否为测试成功；
21.若是，则基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
22.可选地，在所述基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体之后，还包括：
23.将所述目标包体发送至相应的目标服务器，以触发所述目标服务器根据所述目标包体对应用程序进行热更新。
24.可选地，所述将所述目标包体发送至相应的目标服务器，还包括：
25.判断所述目标包体对应的热更新需求单的状态信息是否为测试成功；
26.若是，则将所述目标包体发送至相应的目标服务器。
27.可选地，所述方法还包括：
28.在所述热更新修复包体测试失败后，回退所述svn仓库中与所述热更新指令对应的代码。
29.可选地，所述响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件，还包括：
30.若所述热更新指令没有携带热更新单号信息，则生成第一提示信息，所述第一提示信息用于指示所述热更新指令存在错误。
31.一种热更新测试装置，所述装置包括：
32.热更新修复文件生成模块，用于响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；
33.热更新修复包体生成模块，用于将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；
34.目标包体生成模块，用于在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
35.可选地，所述热更新修复文件生成模块，还包括：
36.第一判断模块，用于判断所述热更新指令是否携带热更新单号信息；
37.热更新修复代码获取模块，用于若是，则获取与所述热更新单号信息对应的热更新修复代码；
38.热更新修复文件确定模块，用于根据所述热更新修复代码生成对应的热更新修复
文件。
39.可选地，所述装置还包括：
40.热更新修复分支创建模块，用于创建与当前热更新周期对应的热更新修复分支，所述热更新修复分支对应的基线包体是上一个热更新周期结束时得到的用于外放的包体。
41.可选地，所述目标包体生成模块，包括：
42.合入请求接收模块，用于在所述热更新修复包体测试成功后，接收针对所述热更新修复文件的合入请求；
43.热更新修复文件合入模块，用于基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
44.可选地，所述合入请求携带所述热更新单号信息，所述热更新修复文件合入模块，包括：
45.第二判断模块，用于判断所述热更新单号信息对应的热更新需求单的状态信息是否为测试成功；
46.文件合入模块，用于若是，则基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
47.可选地，所述装置还包括：
48.目标包体外放模块，用于将所述目标包体发送至相应的目标服务器，以触发所述目标服务器根据所述目标包体对应用程序进行热更新。
49.可选地，所述目标包体外放模块，还包括：
50.第三判断模块，用于判断所述目标包体对应的热更新需求单的状态信息是否为测试成功；
51.目标包体发送模块，用于若是，则将所述目标包体发送至相应的目标服务器。
52.可选地，所述装置还包括：
53.失败回退模块，用于在所述热更新修复包体测试失败后，回退所述svn仓库中与所述热更新指令对应的代码。
54.可选地，所述热更新修复文件生成模块，还包括：
55.错误提示模块，用于若所述热更新指令没有携带热更新单号信息，则生成第一提示信息，所述第一提示信息用于指示所述热更新指令存在错误。
56.一种电子设备，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的热更新测试方法的步骤。
57.一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如上所述的热更新测试方法的步骤。
58.本技术具有以下优点：
59.在本技术的实施例中，响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。本技术
实施例可以集svn仓库和git仓库所长，实现既符合大部分用户使用svn仓库的习惯，又能通过git仓库的分支管理功能，提高测试效率、降低外放包体出现代码错误的几率。
附图说明
60.为了更清楚地说明本技术的技术方案，下面将对本技术的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
61.图1为本技术实施例的一种热更新测试方法的步骤流程图；
62.图2为本技术一实施例中包体管理的示意图；
63.图3为本技术一实施例中热更新修复包体生成过程的示意图；
64.图4为本技术一实施例中测试流程的示意图；
65.图5为本技术实施例的一种热更新测试装置的结构框图。
具体实施方式
66.为使本技术的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本技术作进一步详细的说明。显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
67.首先对本技术实施例中涉及的名词和术语进行说明，本技术实施例中涉及的名词和术语适用于如下的解释。
68.热更新：是在不发布新版本的情况下，利用代码机制修改游戏内容，做到对外服内容的动态修改。
69.svn：是subversion的缩写，是一个开放源代码的集中式版本控制系统。
70.git：是一个开源的分布式版本控制系统。
71.gitlab：是一个用于仓库管理系统的开源项目，使用git作为代码管理工具，并在此基础上搭建起来的web服务。
72.现有的热更新测试方式是基于单一的svn仓库进行的，当同时存在多个热更新需求时，svn切分支成本高，效率低。导致并行处理难，热更新测试效率低下。同时，在热更新测试完成后，需要程序设计人员重新编译外放包体，在此过程中缺乏相应的监控措施，容易导致错误的未经过测试的内容被外放，造成产品质量风险。
73.鉴于此，本技术实施例提供了一种热更新测试方法，以克服现有技术的缺陷。
74.参照图1，示出了本技术一实施例提供的一种热更新测试方法的步骤流程图。该方法可以应用于热更新测试系统，热更新测试系统可以包括多个终端设备、svn仓库以及git仓库；svn仓库和git仓库对应相同的应用程序。
75.其中，终端设备可以是台式电脑、笔记本电脑、平板电脑、智能手机、个人数字助理等电子设备。终端设备可以安装并运行供应用程序开发人员使用的客户端，以便于应用程序开发人员对目标应用程序进行维护和更新。svn仓库作为目标应用程序的日常代码维护仓库，而git仓库作为目标应用程序的热更新专用仓库。
76.该方法具体可以包括如下步骤：
77.步骤101，响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；
78.步骤102，将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；
79.步骤103，在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
80.在本技术实施例中，响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。本技术实施例可以集svn仓库和git仓库所长，实现既符合大部分用户使用svn仓库的习惯，又能通过git仓库的分支管理功能，提高测试效率、降低外放包体出现代码错误的几率。
81.下面，将对本示例性实施例中热更新测试方法作进一步地说明。
82.在步骤101中，响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件。
83.在本技术实施例中，热更新测试系统可以通过无线网络或有线网络与运行目标应用程序的目标服务器连接。当应用程序开发人员确定目标应用程序存在热更新需求时，应用程序开发人员中的策划人员可以针对目标应用程序的各个热更新需求提交相应的热更新需求单，由程序设计人员针对各个热更新需求编写相应的热更新修复代码。程序设计人员在热更新修复代码编写完成后，通过相应的终端设备向svn仓库发送热更新指令，以将其编写完成的热更新修复代码提交至svn仓库。
84.热更新测试系统在检测到针对svn仓库的热更新指令后，根据热更新指令生成对应的热更新修复文件，以便后续对该热更新修复文件进行测试、打包等步骤。
85.为了使热更新测试过程的信息透明化，便于热更新测试过程的信息同步。在本技术一可选实施例中，上述根据所述热更新指令生成对应的热更新修复文件的过程，具体可以包括：
86.判断所述热更新指令是否携带热更新单号信息；
87.若是，则获取与所述热更新单号信息对应的热更新修复代码；
88.根据所述热更新修复代码生成对应的热更新修复文件。
89.在本技术实施例中，需要保证提交至svn仓库的热更新修复代码有单可寻，因此，需要判断热更新指令是否携带热更新单号信息；若热更新指令携带有热更新单号信息，则可以根据热更新单号信息获取对应的热更新修复代码，进而通过执行生成脚本，生成热更新单号信息对应的热更新修复文件。
90.具体地，程序设计人员在提交热更新修复文件时，需要指定该热更新修复文件对应的热更新需求，即指定该热更新修复文件对应的热更新需求单。因此，可以通过判断热更新指令对应的提交日志中是否存在热更新单号信息，来判断热更新指令是否携带热更新单
号信息。
91.需要说明的是，同一个热更新单号信息对应同一个热更新需求，同一个热更新单号信息可以对应多个热更新指令，也就是说，同一个热更新单号信息可以对应多个热更新修复代码。因此，可以获取到与热更新指令中的热更新单号信息关联的所有热更新修复代码，并基于获取到的热更新修复代码生成该热更新单号信息对应的热更新修复文件。
92.示例性地，程序设计人员a针对某个热更新需求，修改了a.py文件的10-12行代码；程序设计人员b针对同一个热更新需求，同步修改了a.py文件的15-16行代码；因此，程序设计人员a和程序设计人员b向svn仓库发送的热更新指令携带有相同的热更新单号信息。若程序设计人员a向svn仓库发送热更新指令的时间晚于程序设计人员b；在检测到程序设计人员a发送的针对svn仓库的热更新指令时，通过该热更新指令对应的热更新单号信息，可以获取到热更新修复代码包括a.py文件的10-12行代码以及a.py文件的15-16行代码；最后，通过生成脚本生成对应的热更新修复文件。
93.进一步地，若所述热更新指令没有携带热更新单号信息，则生成第一提示信息，所述第一提示信息用于指示所述热更新指令存在错误。
94.在本实施例中，当程序设计人员在提交热更新修复文件时，若没有指定对应的热更新需求单，即热更新指令没有携带热更新单号信息，此时，将生成第一提示信息，该第一提示信息用于指示热更新指令存在错误；更具体地，该第一提示信息可以用于指示热更新指令缺少热更新单号信息。该第一提示指令可以展示在该热更新指令对应的终端设备的显示屏中，以便相应的程序设计人员进行修改后重新提交。
95.在步骤102中，将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序。
96.本技术实施例通过git仓库来管理目标应用程序的热更新；因此，在生成热更新修复文件后，需要将热更新修复文件发送至git仓库对应的热更新修复分支中，以触发gitlab结合该热更新修复分支对应的基线包体，生成待测试的热更新修复包体。需要说明的是，该热更新修复分支是git仓库热更新修复主分支的一个副本。一个热更新需求对应一个热更新修复分支。
97.在本技术一可选实施例中，在上述将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体之前，还包括：
98.创建与当前热更新周期对应的热更新修复分支，所述热更新修复分支对应的基线包体是上一个热更新周期结束时得到的用于外放的包体。
99.其中，用于外放的包体是指热更新过程中，发送至运行应用程序的目标服务器的包体。在每一个热更新周期结束时都可以得到该结束的热更新周期的用于外放的包体。在本实施例中，将每个热更新周期结束时得到的用于外放的包体作为其相邻的下一个热更新周期的基线包体。
100.本实施例在当前热更新周期的上一个热更新周期结束时，即在当前热更新周期开始时，即在程序设计人员使用的终端设备本地创建当前热更新周期对应的热更新修复分支，该热更新修复分支对应的基线包体即为上一个热更新周期结束时得到的用于外放的包
体。需要说明的是，在其他示例中，还可以在当前热更新周期中产生热更新需求时再创建当前热更新周期对应的热更新修复分支；本技术对此不做限制。
101.可以理解，在一个热更新周期中，基线包体是不变的；即一个热更新周期中，不同热更新需求对应不同的热更新修复分支，但不同的热更新修复分支对应的基线包体是相同的。
102.在步骤103中，在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
103.在本技术实施例中，当热更新修复包体测试成功后，可以基于该热更新修复包体对应的热更新修复文件，将该热更新修复文件合入git仓库对应的主分支，并生成相应的、用于外放的目标包体。可以理解，该git仓库对应的主分支在合入该热更新修复文件之前，其对应的包体与目标服务器所使用的包体一致。
104.示例性地，在生成待测试的热更新修复包体后，程序测试人员可以将待测试的热更新修复包体同步到其使用的终端设备中，以在其使用的终端设备中对待测试的热更新修复包体进行测试。
105.当测试成功时，程序测试人员可以通过其使用的终端设备发送用于表征测试成功的反馈信息。当热更新测试系统接收到该反馈信息时，可以确定该反馈信息对应的热更新修复包体，并基于该热更新修复包体对应的热更新修复文件，将该热更新修复文件合入git仓库对应的主分支，并生成相应的、用于外放的目标包体。
106.在一可选实施例中，上述在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体的过程，包括：
107.在所述热更新修复包体测试成功后，接收针对所述热更新修复文件的合入请求；
108.基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
109.本实施例中，目标包体的生成需要基于接收到的合入请求，该合入请求一般由程序设计人员通过其使用的终端设备发送。以便程序设计人员进行进一步确定是否继续生成相应的目标包体。
110.示例性地，当热更新修复包体测试成功后，该热更新修复包体对应的程序设计人员使用的终端设备可以展示测试成功的反馈信息，例如，可以通过热更新修复包体对应的热更新需求单的状态来展示测试结果。当程序设计人员查看到热更新修复包体测试成功的反馈信息时，可以进一步判断是否需要生成该热更新修复包体的热更新文件对应的目标包体；在程序设计人员确定需要生成目标包体时，可以通过其使用的终端设备发送合入请求，以触发热更新测试系统将对应的热更新修复文件合入git仓库对应的主分支，再打包生成对应的目标包体。
111.进一步地，为了防止程序设计人员针对未测试成功或未测试的热更新文件发送合入请求，导致错误代码被外放，造成产品质量风险，在本技术一可选实施例中，合入请求需要携带相应的热更新单号信息，上述基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体，包括：
112.判断所述热更新单号信息对应的热更新需求单的状态信息是否为测试成功；
113.若是，则基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分
支，并生成相应的、用于外放的目标包体。
114.热更新单号信息和热更新需求单具有一一对应的关系，本实施例可以通过合入请求携带的热更新单号信息确定对应的热更新需求单，进而判断热更新需求单的状态信息是否为测试成功，若是，则可以获取热更新单号信息对应的热更新修复文件，并将该热更新修复文件合入git仓库对应的主分支，再生成相应的、用于外放的目标包体。
115.进一步地，在本技术一可选实施例中，在生成目标包体后，可以将目标包体发送至目标服务器，以对目标应用程序进行热更新，因此，上述方法还可以包括：
116.将所述目标包体发送至相应的目标服务器，以触发所述目标服务器根据所述目标包体对应用程序进行热更新。
117.为了防止目标包体中的热更新修复文件在发送至目标服务器之前发生变化，导致目标包体存在错误，在本技术一可选实施例中，在将所述目标包体发送至相应的目标服务器之前，还包括：
118.判断所述目标包体对应的热更新需求单的状态信息是否为测试成功；
119.若是，则将所述目标包体发送至相应的目标服务器。
120.本技术实施例在将目标包体发送至相应的目标服务器之前，根据目标包体对应的热更新修复文件，确定该目标包体对应的热更新需求单，进而判断热更新需求单是否为测试成功，若是，则将目标包体发送至相应的目标服务器。
121.进一步地，上述方法还可以包括：
122.在所述热更新修复包体测试失败后，回退所述svn仓库中与所述热更新指令对应的代码。
123.在本技术实施例中，当热更新修复包体测试失败后，可以在相应的程序设计人员使用的终端设备和/或程序测试人员使用的终端设备显示测试失败信息，并对已提交至svn仓库中的与该热更新修复包体对应的热更新代码，进行回退处理，以防止svn仓库的最终状态存在未通过测试的代码。
124.本技术实施例通过响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。本技术实施例可以集svn仓库和git仓库所长，实现既符合大部分用户使用svn仓库的习惯，又能通过git仓库的分支管理功能，提高测试效率、降低外放包体出现代码错误的几率。
125.为使本领域技术人员更好地理解本技术实施例，下面将结合图2至图4，从包体管理、热更新修复包体生成过程以及测试流程来说明本技术实施例中热更新测试方法。
126.如图2所示，图2示出了本技术一实施例中包体管理的示意图。为了将热更内容(即热更新需求)独立出来转移至git仓库中进行管理，本技术实施例引入基线包的概念。以周更新为例，在当周维护内容完成后，基线包便不再更改，后续所有的热更内容则通过patch文件(即热更新修复文件)+基线包合并的方式来生成。包体管理涉及基线包仓库、patch包仓库、测试仓库和外放包仓库，具体如下：
127.基线包仓库：每周外放分支都会有一个对应的文件夹用于保存所有过程包体，如
图2中的release_20210714、release_202107287。每个文件夹中存储其相应的所有的过程包体。测试过程中，过程包体会不断递增，当周维护内容全部完成后，会切出最后的基线包，也称base包。此后该分支上不再进行包体编译，如图中的release_20210728-xxx18，就是release_20210728分支上最后打出的基线包。
128.patch包仓库：用于保存所有待测试patch包体(即热更新修复包体)，每个patch包体都是由程序设计人员提交的patch文件+基线包生成。程序测试人员可以从patch包仓库中指定需要同步patch包，以用于内部测试。patch包之间内容独立，互不影响；
129.测试仓库：用于映射程序测试人员测试所需的各类包体。包括基线包仓库中最新包体(qcrelease)，以用于日常测试；包括目标服务器正在运行的包体(release)，以用于在热更时构建与目标服务器相同的环境；以及包括patch包仓库中用于在测试热更内容时，所需同步的热更包体(patch)。
130.外放包仓库：用于存储目标服务器所使用的包体，在有新内容外放的时候会自动更新；如图2所示，初始状态下目标服务器所用的包体为release_20210728-xxx18，当外放过一个热更内容后，自动更新为所对应的热更包release_20210728-xxx01p。
131.如图3所示，图3示出了本技术一实施例中热更新修复包体生成过程的示意图。
132.本示例中的patch包体(即热更新修复包体)采用基线包+patch文件的方式生成，其中，svn仓库为日常代码维护仓库，日常的提交均在svn仓库下进行；git仓库为热更专用仓库，所有的热更内容都会提交到git仓库上进行打包测试，每个维护分支都会对应一个基准的master分支(即主分支)，如图中的[master]release_20210728。patch包体生成的基本过程如下：
[0133]
1、程序设计人员提交修复bug(漏洞)所需的修复代码(即热更新修复代码)至svn仓库，提交时log(日志)内容中会指定单号(即热更新单号信息)，如#10379。需要说明的是，热更新过程中不会在svn仓库上进行包体编译工作，因此，此时提交的修复代码仅用于生成patch文件，不会影响到基线包的内容。
[0134]
2、执行patch生成脚本，根据指定单号生成对应的patch文件；该脚本会根据单号找到svn log中所有关联的文件，并还原对应的路径结构。例如，使用单号#10379提交了2个文件a和b，则脚本会生成对应的路径文件logic/entities/a.py和logic/game/b.py；进而结合文件a和文件b生成patch文件，即patch_10379.py。
[0135]
生成patch文件的同时，脚本会从远端git仓库中自动切出对应的热更修复分支(即热更新修复分支)，如图中的[10379_for_release_20210728]；程序设计人员在生成本地patch文件后就可推送对应的patch文件至该分支；
[0136]
3、推送完成后会自动触发gitlab的ci机制(一种自动编译机制)，拉取基线包(如图中的[10379_for_release_20210728])结合patch文件，生成待测试的patch包体。
[0137]
如图4所示，图4示出了本技术一实施例中测试流程的示意图，包括如下过程：
[0138]
1、程序设计人员提交修复代码至svn仓库；在提交修复代码时，检查log中是否含有单号，以及单号的类型、状态、跟进人，确保提交内容有单可寻、有人跟进。
[0139]
2、执行patch生成脚本生成patch文件，同时从远端git仓库中切出热更修复分支；
[0140]
3、提交patch文件至本地热更修复分支，实时同步到远端git仓库，触发gitlab打包，生成patch包体，进而由远端git仓库推送至patch包仓库，作为待测试的包体；
[0141]
4、程序测试人员从patch包仓库同步要测试的patch包体至本地进行测试；
[0142]
5、测试完成后，由程序设计人员发起merge request(合入请求)，合入请求审核通过后，修复代码从热更修复分支合入master，触发gitlab打包，生成外放包体(即目标包体)；其中，合入请求审核时，检测对应分支提交内容的需求单状态，确保仅有测试完成的内容才可合入master。
[0143]
6、将外放包体上传至外服平台(即目标服务器)，执行外放操作，至此测试内容完成。其中，在将外放包体上传至外服平台前，需要检测包体内所有patch文件对应需求单状态，确保所有外放内容均已完成测试，无错误提交内容。
[0144]
本技术实施例通过采用两个独立的版本控制仓库，所有的热更需求都是一个独立的测试分支，杜绝了相互影响的可能，具有并行效率高的特点。本技术实施例的外放包仓库和patch仓库相互独立，确保只有完成测试的内容才会进入到master分支；同时会更加外放情况同步更新外放包体，程序测试人员可以非常方便地获取到外放包体，用于重现异常，因此回退成本低。本技术实施例所有的热更内容均在分支上进行，只有当测试成功后才会合入master；并且在合入master之前需要程序测试人员发送合入请求，并确保合入master的代码都测试成功，起到双重验证的作用。本发明实施例在提交代码至svn仓库时进行单号检查，确保提交的代码有单可寻；以及上述所述的提交代码的双重验证，可以避免程序测试人员需要反复确认和同步的过程，做到信息的透明。
[0145]
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本技术实施例并不受所描述的动作顺序的限制，因为依据本技术实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本技术实施例所必须的。
[0146]
参照图5，示出了本技术的一种热更新测试装置实施例的结构框图，在本技术实施例中，所述装置具体可以包括如下模块：
[0147]
热更新修复文件生成模块501，用于响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；
[0148]
热更新修复包体生成模块502，用于将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；
[0149]
目标包体生成模块503，用于在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
[0150]
可选地，所述热更新修复文件生成模块501，还包括：
[0151]
第一判断模块，用于判断所述热更新指令是否携带热更新单号信息；
[0152]
热更新修复代码获取模块，用于若是，则获取与所述热更新单号信息对应的热更新修复代码；
[0153]
热更新修复文件确定模块，用于根据所述热更新修复代码生成对应的热更新修复文件。
[0154]
可选地，所述装置还包括：
[0155]
热更新修复分支创建模块，用于创建与当前热更新周期对应的热更新修复分支，
所述热更新修复分支对应的基线包体是上一个热更新周期结束时得到的用于外放的包体。
[0156]
可选地，所述目标包体生成模块503，包括：
[0157]
合入请求接收模块，用于在所述热更新修复包体测试成功后，接收针对所述热更新修复文件的合入请求；
[0158]
热更新修复文件合入模块，用于基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
[0159]
可选地，所述合入请求携带所述热更新单号信息，所述热更新修复文件合入模块，包括：
[0160]
第二判断模块，用于判断所述热更新单号信息对应的热更新需求单的状态信息是否为测试成功；
[0161]
文件合入模块，用于若是，则基于所述合入请求，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。
[0162]
可选地，所述装置还包括：
[0163]
目标包体外放模块，用于将所述目标包体发送至相应的目标服务器，以触发所述目标服务器根据所述目标包体对应用程序进行热更新。
[0164]
可选地，所述目标包体外放模块，还包括：
[0165]
第三判断模块，用于判断所述目标包体对应的热更新需求单的状态信息是否为测试成功；
[0166]
目标包体发送模块，用于若是，则将所述目标包体发送至相应的目标服务器。
[0167]
可选地，所述装置还包括：
[0168]
失败回退模块，用于在所述热更新修复包体测试失败后，回退所述svn仓库中与所述热更新指令对应的代码。
[0169]
可选地，所述热更新修复文件生成模块501，还包括：
[0170]
错误提示模块，用于若所述热更新指令没有携带热更新单号信息，则生成第一提示信息，所述第一提示信息用于指示所述热更新指令存在错误。
[0171]
在本技术实施例中，热更新修复文件生成模块响应于针对svn仓库的热更新指令，根据所述热更新指令生成对应的热更新修复文件；热更新修复包体生成模块将所述热更新修复文件发送至git仓库对应的热更新修复分支中，以结合所述热更新修复分支对应的基线包体，生成待测试的热更新修复包体；所述svn仓库和所述git仓库对应相同的应用程序；目标包体生成模块在所述热更新修复包体测试成功后，将所述热更新修复文件合入所述git仓库对应的主分支，并生成相应的、用于外放的目标包体。本技术实施例可以集svn仓库和git仓库所长，实现既符合大部分用户使用svn仓库的习惯，又能通过git仓库的分支管理功能，提高测试效率、降低外放包体出现代码错误的几率。
[0172]
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0173]
本技术实施例还公开了电子设备，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的热更新测试方法的步骤。
[0174]
本技术实施例还公开了计算机可读存储介质，所述计算机可读存储介质上存储计
算机程序，所述计算机程序被处理器执行时实现如上所述的热更新测试方法的步骤。
[0175]
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
[0176]
本领域内的技术人员应明白，本技术实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本技术实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0177]
本技术实施例是参照根据本技术实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0178]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0179]
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0180]
尽管已描述了本技术实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本技术实施例范围的所有变更和修改。
[0181]
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
[0182]
以上对本技术所提供的一种热更新测试方法及装置、电子设备和存储介质，进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的方法及其核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本技术的限制。