一种数据处理方法和装置

技术领域

本公开涉及互联网领域，尤其涉及一种数据处理方法、装置、电子设备及存储介质。

背景技术

业务开发迭代过程中，开发出新功能后，需要对新功能进行测试。一般地，可通过灰度发布的形式，使一部分用户使用新功能，根据这部分用户的数据确定是否将新功能发布给全部用户。

以页面交互逻辑为例，传统方案中，在开发出某个新的页面交互功能后，通常需要在前端维护兼容新旧功能的代码逻辑，例如，新功能为点击购买键后，直接进入支付确认界面，旧功能为点击购买键后，先进入商品确认界面，再进入支付确认界面。传统方案的前端代码中兼容新旧功能，在接收到用户点击购买键的信息后，使一部分用户直接进入支付确认界面，另一部分用户先进入商品确认界面，前端不得不维护多套交互逻辑，增加代码的复杂性和维护难度。

发明内容

针对上述技术问题，本公开实施例提供一种数据处理方法，技术方案如下：

根据本公开实施例的第一方面，提供一种数据处理方法，所述方法包括：

获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下

将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；

将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

可选的，所述获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下，包括：

获取第一分支代码，所述第一分支代码为对应新功能逻辑的新代码；

获取第二分支代码，所述第二分支代码为对应旧功能逻辑的旧代码；

将所述第一分支代码部署在第一测试域名下，将所述第二分支代码部署在第二测试域名下。

可选的，所述将不同用户访问请求重定向到所述不同测试域名下，包括：

检测到针对主域名的访问请求，识别所述访问请求对应的用户对象，以确定所述用户对象所属的测试组；

依据所述用户对象所属的测试组，对所述访问请求进行重定向，将所述访问请求所访问的域名更换为定向到所述测试组对应的测试域名。

可选的，所述识别访问请求对应的用户对象，以确定所述用户对象所属的测试组，包括：

针对访问请求所对应的用户对象，获取所述用户对象的帐户ID，查找为所述帐户ID预先分配的测试组，确定为所述用户对象所在的测试组。

可选的，所述识别访问请求对应的用户对象，以确定所述用户对象所属的测试组，包括：

针对访问请求所对应的用户对象，提取所述用户对象的用户特征，基于预先确定的匹配规则对所述用户特征进行匹配，依据匹配结果确定所述用户对象所在的测试组。

可选的，所述将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，包括：

将所述符合预定条件的访问数据所对应的分支代码合并到原始逻辑对应的主代码中，其中，所述主代码被部署在主域名下。

根据本公开实施例的二方面，提供一种数据处理装置，所述装置包括：

代码部署模块，被配置为执行获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下

流量导向模块，被配置为执行将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；

功能确定模块，被配置为执行将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

可选的，所述代码部署模块，被配置为执行：

获取第一分支代码，所述第一分支代码为对应新功能逻辑的新代码；

获取第二分支代码，所述第二分支代码为对应旧功能逻辑的旧代码；

将所述第一分支代码部署在第一测试域名下，将所述第二分支代码部署在第二测试域名下。

可选的，所述流量导向模块，被配置为执行：

检测到针对主域名的访问请求，识别所述访问请求对应的用户对象，以确定所述用户对象所属的测试组；

依据所述用户对象所属的测试组，对所述访问请求进行重定向，将所述访问请求所访问的域名更换为定向到所述测试组对应的测试域名。

可选的，所述流量导向模块，被配置为执行：

针对访问请求所对应的用户对象，获取所述用户对象的帐户ID，查找为所述帐户ID预先分配的测试组，确定为所述用户对象所在的测试组。

可选的，所述流量导向模块，被配置为执行：

针对访问请求所对应的用户对象，提取所述用户对象的用户特征，基于预先确定的匹配规则对所述用户特征进行匹配，依据匹配结果确定所述用户对象所在的测试组。

可选的，所述功能确定模块，被配置为执行：

将所述符合预定条件的访问数据所对应的分支代码合并到原始逻辑对应的主代码中，其中，所述主代码被部署在主域名下。

根据本公开实施例的第三方面，提供一种电子设备，包括：处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的数据处理方法。

本公开实施例提供了一种数据处理方法、装置、电子设备及存储介质。获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。该方法将不同的分支代码部署在不同环境，避免兼容两种代码逻辑造成整套代码逻辑冗余，难以管理。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开实施例。

此外，本公开实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

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

图1是本公开一示例性实施例示出的数据处理方法一种流程图；

图2是本公开一示例性实施例示出的用户发布方法的一种流程图；

图3是本公开一示例性实施例示出的重定向方法的一种流程图；

图4是本公开一示例性实施例示出的数据处理方法的另一种流程图；

图5是本公开一示例性实施例示出的数据处理装置的一种示意图；

图6是本公开一示例性实施例示出的电子设备的一种示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

业务开发迭代过程中，开发出新功能后，需要对新功能进行测试。一般地，可通过灰度发布的形式，使一部分用户使用新功能，根据这部分用户的数据确定是否发布到全部用户。

以页面交互逻辑为例，传统方案中，在开发出某个新的页面交互功能后，通常需要在前端维护兼容新旧功能的代码逻辑，例如，新功能为点击购买键后，直接进入支付确认界面，旧功能为点击购买键后，先进入商品确认界面，再进入支付确认界面。传统方案的前端代码中兼容新旧功能，在接收到用户点击购买键的信息后，使一部分用户直接进入支付确认界面，另一部分用户先进入商品确认界面，前端不得不维护多套交互逻辑，增加代码的复杂性和维护难度。

为了解决上述问题，本公开提供了一种数据处理方法，以及应用所述数据处理方法的设备，首先对该数据处理方法进行整体说明。参见图1，一实施例提供的数据处理方法包括以下步骤S101～步骤S104，该方法应用于服务器、计算机终端等电子设备。

在步骤S101中，获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下。

本实施例可以应用于AB测试场景，AB测试是灰度发布的一种常用方法。具体来说，为Web或App界面或业务制作两个(A/B)或多个(A/B/n)版本，在同一时间段内让访客群组(目标人群)随机的访问这些版本，收集各群组的用户行为数据和业务数据，最后分析、评估出最好版本，正式采用。

本步骤中，对应不同功能逻辑的分支代码是为Web或App界面或业务流程制作的两个(A/B)或多个(A/B/n)版本。参见图2，为AB测试的示意图，本实施例中，获取开发过程中生成的对应不同功能逻辑的分支代码，其中，对应不同功能逻辑的分支代码是指原始代码基础上，包含新功能逻辑或旧功能逻辑的代码。一个实施例中，开发过程中生成的对应不同功能逻辑的分支代码，通常为对应旧功能逻辑的旧代码和对应新功能逻辑的新代码。应当说明的是，对应功能逻辑的分支代码是指，实现该功能逻辑的分支代码。

图2中，将访问的用户对象进行分流，分别访问旧代码对应的A版本业务和新代码分别对应的B版本业务，基于访问数据分别得到两个版本的评分，进而决定最终使用哪个版本。

举例说明：在开发出某个新的页面交互功能后，通常需要在前端维护兼容新旧功能的代码逻辑，例如，新功能为点击购买键后，直接进入支付确认界面，旧功能为点击购买键后，先进入商品确认界面，再进入支付确认界面。

假设实现整体支付服务的原始代码为A+A1，其中上述旧功能逻辑的代码段为代码段A1，将代码段A1进行修改后，获得实现上述新功能逻辑的代码段为代码段A2。则将代码段A1进行修改后形成两个分支代码。这两个分支代码分别是用于实现新的功能逻辑的分支代码A+A2、和用于实现旧的功能逻辑的分支代码A+A1。

具体而言，本实施例中，可使用Git工具一类的版本控制工具在开发流程中实现分支代码的形成和合并。

其中，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下，即将不同分支代码部署在不同的环境中，后续可将用户流量导向不同环境，这样不需要在线上的一套代码兼容多种功能，也不需要在后续维护、删除代码，更为便捷。

将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下，具体而言，可为新旧功能创建两套代码，在这两套代码中，除了实现目标功能的新功能逻辑对应的新代码和旧功能逻辑对应的旧代码外，两套代码中的其他代码都是相同的。例如：某一视频类应用包括视频播放和评论两个功能，其中，对视频播放功能进行了优化，则对于优化前后的视频类应用来说，评论功能的代码是一样的，视频播放功能的代码是不同的：优化前的视频播放功能对应旧代码，而优化后的视频播放功能对应新代码。

在具体部署时，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下，例如：不同分支代码可被部署于不同的服务器，也可部署于相同的服务器，本实施例对此不作限制。

在一实施例中，将分支代码分别部署在对应测试域名的步骤可以是：将分支代码部署在服务器上，并得到具有域名的可访问的网站。其中，同一服务器可以部署一个或多个网站。

步骤S101可以包括但不限于以下方式：

(1-1)获取第一分支代码，所述第一分支代码为对应新功能逻辑的新代码；

(1-2)获取第二分支代码，所述第二分支代码为对应旧功能逻辑的旧代码；

(1-3)将所述第一分支代码部署在第一测试域名下，将所述第二分支代码部署在第二测试域名下。

本公开一实施例中，不同分支代码可分为a分支代码和b分支代码，在将a、b分支代码分别部署到a.xxx.com和b.xxx.com域名下。

在步骤S102中，将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据。

本步骤将不同用户访问请求重定向到所述不同测试域名下，分别收集不同测试域名下的访问数据以确定最终采用的功能逻辑。一个示例中，本步骤分别为新功能逻辑所在的环境和旧功能逻辑所在的环境导入用户流量，以便利用这些用户流量测试哪种功能所达成的效果更为理想。

举例说明：新功能逻辑为点击购买键后，直接进入支付确认界面。旧功能逻辑为点击购买键后，先进入商品确认界面，再进入支付确认界面。将用户流量导入新功能逻辑所在的环境和旧功能逻辑所在的环境，再经过一段时间后，基于预定的评定方式计算出新旧功能的评分，如：计算两个环境下的最终支付率，最终支付率越高，则功能的评分越高；计算两个环境下的支付后的取消率，取消率越低，则功能的评分越高….等等，最终可采用评分较高的那个功能逻辑。

步骤S102可以包括但不限于以下(2-1)、(2-2)。

(2-1)检测到针对主域名的访问请求，识别所述访问请求对应的用户对象，以确定所述用户对象所属的测试组。

(2-2)依据所述用户对象所属的测试组，对所述访问请求进行重定向，将所述访问请求所访问的域名更换为定向到所述测试组对应的测试域名。

一个实施例中，访问请求中包括用户对象的帐户ID，通过识别用户对象的帐户ID所属的测试组，确定测试组对应的测试域名，并将访问请求重定向到测试组对应的测试域名。

上述步骤(2-1)到步骤(2-2)的具体实现过程，可参考图3所示的实施例。

在步骤S103中，将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

步骤S103涉及的预定条件是为评估各功能逻辑是否符合预期期望所设定的条件。

一个示例中，对于新功能或旧功能，预定条件为一周内每天访问的日访问量大于日访问量阈值，若确定一周内每天访问旧功能的日访问量大于日访问量阈值，则将旧功能逻辑对应的分支代码合并到主代码中。又例如：新功能更改了支付页面的跳转方式，希望使用户对象的支付更加迅速，支付成功率更高，但跳转方式的更改也可能增加用户的误支付操作。基于此，可以对用户对象访问过程中涉及的“支付时间”和“支付成功率”和“误支付率”进行综合设定以得到预定条件。

在一个实施例中，测试域名部署了分支代码，访问数据为访问测试域名产生的数据，故可认为访问数据与分支代码具有对应关系。例如，测试域名1部署了分支代码1，访问数据1为访问测试域名1产生的数据，则认为访问数据1对应的分支代码为分支代码1。

在本公开一实施例中，最终采用的功能逻辑所对应的分支代码合并到原始逻辑对应的主代码中，所述主代码被部署在主域名下。

确定最终采用的功能逻辑后，删除未采用的功能逻辑所对应的代码，并将最终采用的功能逻辑对应的代码合并到主代码中。本实施例提供的方法将不同的分支代码部署在不同环境，避免相关技术在同一环境兼容两种代码逻辑造成整套代码逻辑冗余，难以管理。

图3是根据一示例性实施例示出的另一种数据处理方法的流程图，该数据处理方法可以用于服务器，并建立在图1所示方法的基础上，如图3所示，步骤S102可以包括以下步骤S301-S302。

在步骤S301中，检测到针对主域名的访问请求，识别所述访问请求对应的用户对象，以确定所述用户对象所属的测试组。

在本公开一实施例中，识别所述访问请求对应的用户对象，以确定所述用户对象所属的测试组，具体可以包括：针对访问请求所对应的用户对象，获取所述用户对象的帐户ID，查找为所述帐户ID预先分配的测试组，即为用户对象所属的测试组。

例如：检测到针对主域名的访问请求后，识别出该访问请求所对应的用户对象的帐户ID是002。而帐户ID001-0010都被预先分配到测试组A，则可确定该访问请求对应的用户对象属于测试组A。

在本公开另一实施例中，识别所述访问请求对应的用户对象，以确定所述用户对象所属在的测试组，还可包括：针对访问请求所对应的用户对象，提取所述用户对象的用户特征，基于预先确定的匹配规则对所述用户特征进行匹配，依据匹配结果确定所述用户对象所在的测试组。

例如：检测到针对主域名的访问请求后，识别出该访问请求所对应的用户对象的年龄特征是22岁。在预先确定的匹配规则中，年龄特征在20-30岁会被分配到测试组B，则可确定该访问请求对应的用户对象属于测试组B。

在步骤S302中，依据所述用户对象所属的测试组，对所述访问请求进行重定向，将所述访问请求所访问的域名更换为定向到所述测试组对应的测试域名。

本实施例中，服务器接收到针对主域名的访问请求后，对该访问请求进行重定向，使所述访问请求指向用户对象所在的测试组对应的测试域名，以此为新功能逻辑和旧功能逻辑所在的环境导入用户流量，并基于用户流量产生的各项数据对新功能逻辑和旧功能逻辑进行评估。

业务开发迭代过程中，开发出新功能后，需要对新功能的逻辑(以下称为新功能逻辑)进行测试。一般地，可通过灰度发布的形式，使一部分用户对象访问业务时使用新功能逻辑，另一部分用户对象访问业务时使用旧功能逻辑。根据这两部分用户对象的访问数据确定是否将新功能逻辑发布到全部用户对象，本实施例基于预先设定的测试组使一部分用户对象访问业务时使用新功能逻辑，另一部分用户对象访问业务时使用旧功能逻辑，相对于传统方式来说，不需要编写同时兼容新功能逻辑和旧功能逻辑的整套代码，实现过程更为便捷。

参见图4，为本公开实施例数据处理方案的整体流程示意图，将业务逻辑A(A方案)对应的A分支代码和业务逻辑B(B方案)对应的B分支代码分别部署到不同的测试域名，在用户对象访问主域名时，按照用户对象所在的测试组将用户对象的访问请求进行重定向，重定向后，可控制各个用户对象基于自己所在的测试组访问测试域名，即实现灰度发布。

在一些实施例中，用户对象可以是对用户具有标识作用的信息集合，例如用户帐户。

需要注意的是，用户对象的访问请求也可以不被重定向，例如：若用户对象J既不属于分组A，也不属于分组B，则用户对象J的访问请求不会被重定向，该用户对象J仍旧会访问主域名xxx.com。

测试域名A.xxx.con和B.xxx.com在经过各个用户对象的访问后，可以得到访问数据，基于一段时间的访问数据，可得到不同测试域名所对应分支代码的测试结果。例如，更改了支付页面的跳转方式，通过测试表明，更改后比起更改前，用户对象的支付更加迅速，支付成功率更高，可以使用更改后方案。根据测试结果，可将新功能逻辑(更改后方案)对应的分支代码合并到主代码中，并停止重定向，使所有用户对象直接访问主域名。之后所有用户对象都将使用同样的功能方案。

以页面交互逻辑为例，传统方案中，在开发出某个新的页面交互功能后，通常需要在前端维护兼容新旧功能的代码逻辑，例如，新功能逻辑为点击购买键后，直接进入支付确认界面，旧功能逻辑为点击购买键后，先进入商品确认界面，再进入支付确认界面。传统方案的前端代码中兼容新旧功能，在接收到用户对象点击购买键的信息后，使一部分用户对象直接进入支付确认界面，另一部分用户对象先进入商品确认界面，前端不得不维护多套交互逻辑，增加代码的复杂性和维护难度。

传统方案在同一套代码中兼容不同功能逻辑，代码的复杂性和维护难度较高。本公开实施例提供的数据处理方法将对应不同功能逻辑的分支代码部署在不同环境(测试域名)，同时通过重定向用户访问请求的方式向不同环境导入用户流量，通过所导入的用户流量产生的访问数据，得到不同功能逻辑的测试效果。该方案将不同的分支代码部署在不同环境，可实现一套代码包含一种功能逻辑，避免传统方案造成的代码逻辑冗余，难以管理。

相应于上述方法实施例，本公开实施例还提供一种数据处理装置，参见图5所示，所述装置可以包括：

代码部署模块510，被配置为执行获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下；

流量导向模块520，被配置为执行将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；

功能确定模块530，被配置为执行将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

可选的，所述代码部署模块，被配置为执行：

获取第一分支代码，所述第一分支代码为对应新功能逻辑的新代码；

获取第二分支代码，所述第二分支代码为对应旧功能逻辑的旧代码；

将所述第一分支代码部署在第一测试域名下，将所述第二分支代码部署在第二测试域名下。

可选的，所述流量导向模块，被配置为执行：

检测到针对主域名的访问请求，识别所述访问请求对应的用户对象，以确定所述用户对象所在的测试组；

依据所述用户对象所属的测试组，对所述访问请求进行重定向，将所述访问请求所访问的域名更换为定向到所述测试组对应的测试域名。

可选的，所述流量导向模块，被配置为执行：

针对访问请求所对应的用户对象，获取所述用户对象的帐户ID，查找为所述帐户ID预先分配的测试组，确定为所述用户对象所在的测试组。

可选的，所述流量导向模块，被配置为执行：

针对访问请求所对应的用户对象，提取所述用户对象的用户特征，基于预先确定的匹配规则对所述用户特征进行匹配，依据匹配结果确定所述用户对象所在的测试组。

可选的，所述功能确定模块，被配置为执行：

将所述符合预定条件的访问数据所对应的分支代码合并到原始逻辑对应的主代码中，其中，所述主代码被部署在主域名下。

本公开实施例还提供一种电子设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现前述数据处理方法，所述方法包括：

获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下

将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；

将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

图6示出了根据本公开的一示例性实施例的基于主设备侧电子设备的示意结构图。请参考图6，在硬件层面，该电子设备包括处理器602、内部总线604、网络接口606、内存605以及非易失性存储器610，当然还可能包括其他业务所需要的硬件。处理器602从非易失性存储器610中读取对应的计算机程序到内存605中然后运行，在逻辑层面上形成执行数据处理方法的装置。当然，除了软件实现方式之外，本公开并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本公开实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现任一前述的数据处理方法，一个实施例中，所述方法包括：

获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下；

将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；

将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

本公开实施例还提供一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现任一前述的数据处理方法，一个实施例中，所述方法包括：

获取对应不同功能逻辑的分支代码，将所述对应不同功能逻辑的分支代码分别部署在不同测试域名下；

将不同用户访问请求重定向到所述不同测试域名下，并分别收集不同测试域名下的访问数据，对比所述不同测试域名下的访问数据并确定符合预定条件的访问数据；

将所述符合预定条件的访问数据所对应的分支代码合并到主代码中，并取消对用户访问请求的重定向操作。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁存储设备存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

以上所述仅是本公开实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本公开实施例的保护范围。