CN106371849A - 应用数据的处理方法及装置 - Google Patents

Abstract

本发明公开了一种应用数据的处理方法及装置。其中，该方法包括：获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；将待更新应用数据上传至服务端，并在满足触发条件的情况下，根据待更新应用数据生成应用补丁。本发明解决了相关技术中在对互联网产品进行更新的过程中，生成应用补丁的时机较晚，不利于产品维护的技术问题。

Description

应用数据的处理方法及装置

技术领域

本发明涉及互联网领域，具体而言，涉及一种应用数据的处理方法及装置。

背景技术

互联网产品的维护流程主要包括：开发者在trunk(即游戏程序开发提交的主干代码仓库，包含所有最新提交的更新内容)上不断地提交更新内容，但trunk上的整体稳定性较差。为此，如果需要发布一个稳定的更新版本，例如：游戏服务提供方预计在周四要外放一个新版本，那么周三(即预计发布的前一天)便会在trunk上分出一个release(即在主干代码仓库上设计出的分支，用于发布和维护稳定的外放版本)。在后续时间段内，还是可以随意向trunk上提交更新内容，但是release分支上的内容便不会再随意更改，通常只会进行一些谨慎的，必要的，并经过严格验证的修改。新发布的产品版本便是从这样的release上推出的。

以网络游戏为例，通常每周都会更新一次版本，那么就相应地需要在每周推出一个release分支。所谓版本的更新便是本周release推出的最终版本，与上周release推出并外放的最终版本，会进行一次差异对比，生成patch(即游戏程序补丁，用于游戏程序需要更新内容，patch记录的是游戏程序内各个文件之间对比的差异)。如果客户通过采用patch对本地游戏进行更新，那么游戏客户端便可以由上周的旧版本更新为本周的最新版本。这相邻两个版本的内容差异越大，则生成的patch便会越大；反之，如果这相邻两个版本的内容差异越小，则生成的patch便会越小。

为此，互联网产品都希望能够严格控制每次更新的patch大小，如果patch过大，用户可能会失去等待的耐心，直接放弃使用最新版本，其并不会影响原有的游戏体验。特别是针对移动终端开发的游戏产品，如果下载patch并利用patch对本地游戏客户端进行更新，则还可能需要消耗用户的流量，给用户造成不必要的经济损失。

按照目前常规的游戏产品维护流程，patch都是在推出前的最后一刻才生成的，此时才能够得知patch的大小。如果发现patch的大小超出预期，这时又需要重新确认本周提交的更新内容，是否存在可以删除的内容，抑或是需要确认在打包发送patch的过程中是否发生异常。因此，极大地影响维护进度。

另外，由于游戏产品更新频繁，在维护前一天还需要制定回归测试计划，以覆盖到每一个被修改过的系统。常见的方案是基于需求单或者svn diff记录。

更新发布一个版本就相当于是将上一次发布版本之后，trunk主干上的所有提交内容都发布给用户，这些修改不仅是本身可能存在漏洞(bug)，还可能导致其他系统出现bug。为此，出于质量管理的需要，必须在产品维护前一天，制定一份“回归测试计划”，其内容包括：一条或多条回归测试条目，例如：测试充值功能是否正常可用，测试所有主角模型是否正常等。最终，希望得到的结果是在这份回归测试计划全部执行完毕后，便可以覆盖到本次更新的所有修改内容，以便安全地推出更新版本、避免出现bug。

然而，相关技术中所提供的回归测试方案存在如下缺陷：

(1)基于需求单制定回归测试计划很可能会发生遗漏，其原因在于：对于互联网产品而言，该产品的每一个功能点提交，都需要提交一张需求单。该需求单上写明的内容可以包括但不限于以下至少之一：该需求的目的，提交该需求的人员，实现该需求的人员，测试并跟进该需求的人员以及这些流程点完成的时间，都会记录在需求单内。然而，部分提交内容可能并没有提交对应的需求单，或者，虽然存在已提交的需求单，但是未能正确地估量其所产生的影响。

(2)基于svn diff记录制定回归测试计划虽然不会发生遗漏，但是其产生的记录数量十分庞大，例如：同一文件在一周内可能会被修改并提交数十次。

基于上述分析，通常采用需求单的方式来制定回归测试计划。例如：根据需求单的记录得知，假设当前已经对a系统进行过修改，那么在回归测试列表中便需要添加对a系统的回归测试。但是，正如上面所指出的问题，在实际操作过程中，有时研发人员仅是手动修改了较少部分代码，而并没有提交对应的需求单；或者，虽然提交了需求单，但是仅描述了对a系统进行过修改。考虑到本次修改还有可能影响到b系统和/或c系统，这时，如果只回归测试a系统，则会遗漏b系统和/或c系统中存在的bug，因而未能正确估量其所产生的影响。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种应用数据的处理方法及装置，以至少解决相关技术中在对互联网产品进行更新的过程中，生成应用补丁的时机较晚，不利于产品维护的技术问题。

根据本发明实施例的一个方面，提供了一种应用数据的处理方法，包括：

获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；将待更新应用数据上传至服务端，并在满足触发条件的情况下，根据待更新应用数据生成应用补丁。

可选地，待更新应用数据包括以下至少之一：第一应用数据相对于第二应用数据新增的数据；第一应用数据相对于第二应用数据删除的数据；第一应用数据相对于第二应用数据修改的数据以及修改的差异信息。

可选地，触发条件包括以下之一：到达预设时长的结束时间点，其中，结束时间点用于触发生成应用补丁；接收到由用户在服务端输入的控制命令转化的控制信号，其中，控制信号用于触发生成应用补丁。

根据本发明实施例的另一方面，还提供了另一种应用数据的处理方法，包括：

接收客户端上传的待更新应用数据，其中，待更新应用数据是通过将第一应用数据与第二应用数据进行比较后得到的，第一应用数据是对客户端上当前主干开发目录下包含的数据内容进行打包处理后得到的数据，第二应用数据是在客户端的分支开发目录下最新发布的数据；根据待更新应用数据生成回归测试列表，并在满足触发条件的情况下，触发客户端根据待更新应用数据生成应用补丁。

可选地，根据待更新应用数据生成回归测试列表包括：利用知识库对待更新应用数据进行分析，查找出与待更新应用数据相关联的至少一个系统模块，将系统模块添加在待测试列表中，生成回归测试列表，其中，知识库包含应用数据与系统模块的关联关系。

可选地，上述系统模块至少包括以下其中之一：聊天系统、交易系统、付费系统、登录系统、联网系统、装备系统、技能系统、任务系统、活动系统以及灵兽系统。

可选地，利用知识库对待更新应用数据进行分析，生成回归测试列表包括：根据待更新应用数据中包含的代码更新数据确定待测试的第一部分应用功能表项；和/或，根据待更新应用数据中包含的策划更新数据确定待测试的第二部分应用功能表项；和/或，根据待更新应用数据中包含的美术资源更新数据确定待测试的第三部分应用功能表项；按照确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一生成回归测试列表。

可选地，根据美术资源更新数据确定第三部分应用功能表项包括：根据美术资源更新数据中包含的场景更新数据获取待测试的第四部分应用功能表项；和/或，根据美术资源更新数据中包含的模型更新数据获取待测试的第五部分应用功能表项；和/或，根据美术资源更新数据中包含的特效更新数据获取待测试的第六部分应用功能表项；和/或，根据美术资源更新数据中包含的用户界面更新数据获取待测试的第七部分应用功能表项；通过获取到的第四部分应用功能表项、第五部分应用功能表项、第六部分应用功能表项以及第七部分应用功能表项中的至少之一确定第三部分应用功能表项。

可选地，触发条件包括以下之一：到达预设时长的结束时间点向客户端发送第一控制命令，其中，第一控制命令用于触发客户端生成应用补丁；接收到用户输入的第二控制命令，其中，第二控制命令用于触发客户端生成应用补丁。

根据本发明实施例的又一方面，还提供了一种应用数据的处理装置，包括：

获取模块，用于获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；比较模块，用于将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；生成模块，用于将待更新应用数据上传至服务端，并在满足触发条件的情况下，根据待更新应用数据生成应用补丁。

可选地，待更新应用数据包括以下至少之一：第一应用数据相对于第二应用数据新增的数据；第一应用数据相对于第二应用数据删除的数据；第一应用数据相对于第二应用数据修改的数据以及修改的差异信息。

可选地，触发条件包括以下之一：到达预设时长的结束时间点，其中，结束时间点用于触发生成应用补丁；接收到由用户在服务端输入的控制命令转化的控制信号，其中，控制信号用于触发生成应用补丁。

根据本发明实施例的再一方面，还提供了另一种应用数据的处理装置，包括：

接收模块，用于接收客户端上传的待更新应用数据，其中，待更新应用数据是通过将第一应用数据与第二应用数据进行比较后得到的，第一应用数据是对客户端上当前主干开发目录下包含的数据内容进行打包处理后得到的数据，第二应用数据是在客户端的分支开发目录下最新发布的数据；处理模块，用于根据待更新应用数据生成回归测试列表，并在满足触发条件的情况下，触发客户端根据待更新应用数据生成应用补丁。

可选地，处理模块，用于利用知识库对待更新应用数据进行分析，查找出与待更新应用数据相关联的至少一个系统模块，将系统模块添加在待测试列表中，生成回归测试列表，其中，知识库包含应用数据与系统模块的关联关系。

可选地，系统模块至少包括以下其中之一：聊天系统、交易系统、付费系统、登录系统、联网系统、装备系统、技能系统、任务系统、活动系统以及灵兽系统。

可选地，处理模块包括：确定单元，用于根据待更新应用数据中包含的代码更新数据确定待测试的第一部分应用功能表项；和/或，根据待更新应用数据中包含的策划更新数据确定待测试的第二部分应用功能表项；和/或，根据待更新应用数据中包含的美术资源更新数据确定待测试的第三部分应用功能表项；生成单元，用于按照确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一生成回归测试列表。

可选地，确定单元包括：获取子单元，用于根据美术资源更新数据中包含的场景更新数据获取待测试的第四部分应用功能表项；和/或，根据美术资源更新数据中包含的模型更新数据获取待测试的第五部分应用功能表项；和/或，根据美术资源更新数据中包含的特效更新数据获取待测试的第六部分应用功能表项；和/或，根据美术资源更新数据中包含的用户界面更新数据获取待测试的第七部分应用功能表项；确定子单元，用于通过获取到的第四部分应用功能表项、第五部分应用功能表项、第六部分应用功能表项以及第七部分应用功能表项中的至少之一确定第三部分应用功能表项。

可选地，触发条件包括以下之一：到达预设时长的结束时间点向客户端发送第一控制命令，其中，第一控制命令用于触发客户端生成应用补丁；接收到用户输入的第二控制命令，其中，第二控制命令用于触发客户端生成应用补丁。

在本发明实施例中，采用对当前主干开发目录下包含的数据内容进行打包处理得到的第一应用数据，并将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较以获取待更新应用数据，以及在满足触发条件的情况下，根据待更新应用数据生成应用补丁的方式，通过设置触发条件，使得互联网产品的项目研发人员可以任意查看应用补丁相关内容的目的，从而实现了可以任意设定查看应用补丁相关内容的时机，通过知识库的分析，智能生成回归测试列表，使得回归测试内容不易遗漏，达到了加快产品维护进度以及提升产品维护效率的技术效果，进而解决了相关技术中在对互联网产品进行更新的过程中，生成应用补丁的时机较晚，不利于产品维护的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的应用数据的处理方法的流程图；

图2是根据本发明实施例的另一种应用数据的处理方法的流程图；

图3是根据本发明实施例的应用数据的处理装置的结构框图；

图4是根据本发明实施例的另一种应用数据的处理装置的结构框图；

图5是根据本发明优选实施例的另一种应用数据的处理装置的结构框图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明实施例，提供了一种应用数据的处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的应用数据的处理方法的流程图，如图1所示，该方法包括如下步骤：

步骤S12，获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；

互联网产品在主干开发目录(即trunk)下包含的数据内容可以包括但不限于：代码、美术资源、策划数据，这些内容均属于源文件，并未经过加密处理，而且源文件的数量繁多，无法直接提供给用户，因此，需要对当前trunk下包含的数据内容进行打包处理，既实现了对当前trunk下包含的数据内容进行加密处理又实现了对当前trunk下包含的数据内容进行压缩处理。

步骤S14，将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；

与相关技术中所提供的将当前分支开发目录(release)下的应用数据与距离当前时间点最近的前一次发布的release下的应用数据进行比对，生成patch和diff的方式不同，本发明实施例是采用trunk打包版本与距离当前时间点最近的前一次发布的release下的应用数据进行比对，生成patch和diff，即待更新应用数据。

步骤S16，将待更新应用数据上传至服务端，并在满足触发条件的情况下，根据待更新应用数据生成应用补丁。

通过上述步骤，可以采用对当前主干开发目录下包含的数据内容进行打包处理得到的第一应用数据，并将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较以获取待更新应用数据，以及在满足触发条件的情况下，根据待更新应用数据生成应用补丁的方式，通过设置触发条件，达到了使得互联网产品的项目研发人员可以任意查看应用补丁相关内容的目的，从而实现了可以任意设定查看应用补丁相关内容的时机，加快产品维护进度以及提升产品维护效率的技术效果，进而解决了相关技术中在对互联网产品进行更新的过程中，生成应用补丁的时机较晚，不利于产品维护的技术问题。

可选地，上述待更新应用数据可以包括但不限于以下至少之一：

(1)第一应用数据相对于第二应用数据新增的数据；

(2)第一应用数据相对于第二应用数据删除的数据；

(3)第一应用数据相对于第二应用数据修改的数据以及修改的差异信息。

上述待更新应用数据记录了即每个文件具体修改了哪些内容，其可以包括但不限于：增加了哪些文件，删除了哪些文件，修改了哪些文件以及修改的具体内容差异。

可选地，上述触发条件可以包括但不限于以下之一：

条件一、到达预设时长的结束时间点，其中，结束时间点用于触发生成应用补丁；

例如：在客户端上设定每间隔预设时长(例如：5s)可以触发客户端内部根据patch和diff打包成应用补丁。

条件二、接收到由用户在服务端输入的控制命令转化的控制信号，其中，控制信号用于触发生成应用补丁。

当待更新应用数据被上传至服务端后，服务端可以通过前台显示页面将待更新应用数据呈现给测试人员，如果测试人员需要查看应用补丁的安装包大小，则可以手动输入控制命令，以控制客户端根据待更新应用数据生成应用补丁。

利用trunk上定时自动打包并生成trunk patch的技术或利用服务端下发的控制信号打包并生成trunk patch的技术，使得项目组中的各个成员均可随时关注到当前patch的大小，具体提交了哪些内容，从而提前发现问题，以减少维护日前最后一刻再发现patch存在异常的窘迫。

根据本发明实施例，还提供了另一种应用数据的处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图2是根据本发明实施例的另一种应用数据的处理方法的流程图，如图2所示，该方法包括如下步骤：

步骤S22，接收客户端上传的待更新应用数据，其中，待更新应用数据是通过将第一应用数据与第二应用数据进行比较后得到的，第一应用数据是对客户端上当前主干开发目录下包含的数据内容进行打包处理后得到的数据，第二应用数据是在客户端的分支开发目录下最新发布的数据；

步骤S24，根据待更新应用数据生成回归测试列表，并在满足触发条件的情况下，触发客户端根据待更新应用数据生成应用补丁。

在优选实施过程中，上述触发条件可以包括但不限于以下之一：

条件一、到达预设时长的结束时间点向客户端发送第一控制命令，其中，第一控制命令用于触发客户端生成应用补丁；

即服务端在确定接收到客户端上传的待更新应用数据之后，可以定时自动触发客户端根据待更新应用数据生成应用补丁。

条件二、接收到用户输入的第二控制命令，其中，第二控制命令用于触发客户端生成应用补丁。

即服务端也可以在用户输入控制命令后，触发客户端根据待更新应用数据生成应用补丁。

可选地，在步骤S24中，根据待更新应用数据生成回归测试列表可以进一步按照以下方式执行：

利用知识库对待更新应用数据进行分析，查找出与待更新应用数据相关联的至少一个系统模块，将系统模块添加在待测试列表中，生成回归测试列表，其中，知识库包含应用数据与系统模块的关联关系。

在优选实施过程中，上述系统模块可以包括但不限于以下其中之一：

聊天系统、交易系统、付费系统、登录系统、联网系统、装备系统、技能系统、任务系统、活动系统以及灵兽系统。

可选地，在步骤S24中，利用知识库对待更新应用数据进行分析，生成回归测试列表可以包括以下执行步骤：

步骤S241，根据待更新应用数据中包含的代码更新数据确定待测试的第一部分应用功能表项；和/或，根据待更新应用数据中包含的策划更新数据确定待测试的第二部分应用功能表项；和/或，根据待更新应用数据中包含的美术资源更新数据确定待测试的第三部分应用功能表项；

步骤S242，按照确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一生成回归测试列表。

在优选实施例中，客户端可以将待更新应用数据上传至服务端的数据仓库后，服务端可以基于知识库对patch和diff数据进行数据分析。知识库是针对数据分析与数据挖掘所提出的。patch&diff属于底层的、低粒度的信息，其不易于被测试者阅读与理解，难以开展测试工作。但是如果能够基于预先设定完成并保持维护更新的知识库，为测试者开展测试工作提供引导。

例如：patch内包含的一条文件修改信息是xinshoucun.scene文件被修改，diff显示xinshoucun.scene文件内多出几行代码。而知识库内预先记录有场景a和场景b均是使用该scene文件的，那就可以通过数据分析得到，测试人员可能需要对场景a和场景b执行回归测试。

知识库的内容可以随时迭代和补充。即，在任何情况下都可以对知识库的内容进行增加、修改和删减。考虑到游戏产品一直在迭代，因此，知识库也需要随之保持迭代。

在优选实施例中，知识库包含代码文件与系统模块的对应关系，由修改的代码文件可以分析出受到影响的系统模块，从而得出建议回归测试列表中的第一部分应用功能表项。

上述系统模块针对不同游戏产品，其情况各有差异，例如：充值系统模块是游戏产品中一个相对独立的子系统，而为了实现这个子系统，则需要编写多个代码文件。

以游戏产品为例，游戏环境内的装备系统、技能系统、任务系统、活动系统以及灵兽系统均属于系统模块，并且每个系统模块均可以包含多个代码文件。

其次，知识库还包含策划数据文件与系统模块的对应关系，由修改的策划数据文件可以分析出受到影响的系统模块，从而得出建议回归测试列表中的第二部分应用功能表项。

在游戏产品内，代码逻辑与策划数据是相互分离的，都是产品文件的一部分。通过代码文件可以实现执行游戏内特定功能的逻辑，而通过策划数据文件可以向逻辑中填充具体的数据，以实现特定功能的实际运行。

进一步地，知识库还包含美术资源文件与游戏中具体对象的对应关系。由修改的美术资源文件可以分析出受到影响的系统模块，从而得出建议回归测试列表中的第三部分应用功能表项。

美术资源文件属于底层概念。游戏中具体对象属于游戏层面的概念，即游戏内的对象，游戏对象通常对应多个美术资源文件。

游戏中具体对象可以包括但不限于：场景、主角模型、NPC模型、坐骑模型、特效、音效。需要说明的是，不同类型的游戏产品所对应的游戏中具体对象不同。

回归测试列表内包括许多表项，其中，针对实现不同功能的模块会分别生成对应的表项，构成回归测试列表的一部分。通过上述分析确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一可以构成完整的回归测试列表。

需要说明的是，由于策划数据、程序代码以及美术资源这三个部分需要分别管理且数据格式存在显著差异，因此，在上述优选实施例中可以将其划分为策划数据、程序代码以及美术资源三个部分去分别执行。然而，由于这三个部分的本质均属于计算机文件，其为互联网产品的物理部分，因此，在具体实施过程中还可以采用策划数据与程序代码相互结合为一体，或者，使用命令行形式，均可以按照上述方式通过维护知识库，基于计算机层面的文件与产品层面的对象之间的映射关系，生成对应的回归测试列表。

可选地，在步骤S241中，根据美术资源更新数据确定第三部分应用功能表项可以包括以下执行步骤：

步骤S2411，根据美术资源更新数据中包含的场景更新数据获取待测试的第四部分应用功能表项；和/或，根据美术资源更新数据中包含的模型更新数据获取待测试的第五部分应用功能表项；和/或，根据美术资源更新数据中包含的特效更新数据获取待测试的第六部分应用功能表项；和/或，根据美术资源更新数据中包含的用户界面更新数据获取待测试的第七部分应用功能表项；

步骤S2412，通过获取到的第四部分应用功能表项、第五部分应用功能表项、第六部分应用功能表项以及第七部分应用功能表项中的至少之一确定第三部分应用功能表项。

在优选实施例中，由修改的场景文件可以分析得出游戏中受到影响的场景名称及编号；由修改的模型文件可以分析得出游戏中受到影响的角色或NPC名称及编号；由修改的特效文件可以分析得出游戏中该特效挂接的模型、技能或场景；由修改的UI文件可以分析得出受到影响的系统界面，从而得出建议回归测试列表中的第三部分应用功能表项。

此外，在服务端上，patch信息前台页面展示可以分为patch组成和回归测试列表两个部分。回归测试列表中的每条记录可以由组内不同成员点击确认。被点击确认的记录如果后续再次被分析得出受到影响，则会再次变为未确认状态。由此回归工作可以提前进行，基于系统分析得到的回归测试建议提前去执行确认，如果后续该系统对象或模块再次受到影响，该条确认会复原未确认状态，而后续没有受影响的系统对象或模块则始终保持确认状态，为提前回归，避免回归压力大量积攒于最后一刻提供了一定可能性。

通过上述分析，可以得到如下结论：

(1)基于代码模块知识库的数据分析，需维护代码文件与系统模块的字典映射关系(一对多或多对多)，输入本次patch的代码修改列表，即可分析得出需要进行回归测试的系统模块列表。有些特殊的代码文件可能影响到多个系统模块，例如：记录常量的代码文件，这样的文件将基于其diff信息，具体到代码行的层面去分析，同时需要维护关于代码行关键字与系统模块的对应关系。

(2)基于策划数据模块知识库的数据分析，需要维护策划数据文件与系统模块的字典映射关系(一对多或多对多)，输入本次patch的数据修改列表，即可分析得出需要回归测试的系统模块列表。对于一些通用的列表，例如：NPC列表，reward列表，则需要基于diff信息，将粒度细化到数据行的层面去分析，同时需要维护关于数据行与系统对象的对应关系，而对于新增的数据行，直接按照知识库配置的通用规则显示即可。

(3)基于美术资源知识库的数据分析，需要维护各类美术资源与系统模块或游戏中具体对象的关联关系，数据的源头来自策划数据与其他包含有对应关系的美术资源，而具体如何去定义和查询，形成关联结果的编码算法需要在该系统中编写。有的可能只需查询一张数据表即可获得回归测试建议，有的则需要查询多张列表和其他美术资源。

对于“与其他包含了对应关系的美术资源”而言，假设存在一个特效文件，其为美术资源，另外还有一个模型文件，其挂接该特效，则这个模型也是美术资源。这个模型文件便包含有与该特效存在对应关系的美术资源。如果需要在游戏中实际测试这个特效，该特效是不能凭空出现的，而需要通过查询另一个模型文件，会发现该特效挂接到了该模型上，那么回归测试建议便是在游戏中找到该模型，然后才能测试该特效。

综上所述，基于知识库的patch分析得出回归测试列表，虽然维护迭代知识库需要消耗一定成本，但是产生的回归建议列表对质量保障具有极高的价值，从而使得回归测试更加具有针对性，提升了维护工作效率，同时也避免造成任何回归测试遗漏。

根据本发明实施例，提供了一种应用数据的处理装置的实施例，图3是根据本发明实施例的应用数据的处理装置的结构框图，如图3所示，该装置包括：获取模块10，用于获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；比较模块20，用于将第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；生成模块30，用于将待更新应用数据上传至服务端，并在满足触发条件的情况下，根据待更新应用数据生成应用补丁。

可选地，上述待更新应用数据可以包括但不限于以下至少之一：

(1)第一应用数据相对于第二应用数据新增的数据；

(2)第一应用数据相对于第二应用数据删除的数据；

(3)第一应用数据相对于第二应用数据修改的数据以及修改的差异信息。

上述待更新应用数据记录了即每个文件具体修改了哪些内容，其可以包括但不限于：增加了哪些文件，删除了哪些文件，修改了哪些文件以及修改的具体内容差异。

可选地，上述触发条件可以包括但不限于以下之一：

条件一、到达预设时长的结束时间点，其中，结束时间点用于触发生成应用补丁；

例如：在客户端上设定每间隔预设时长(例如：5s)可以触发客户端内部根据patch和diff打包成应用补丁。

条件二、接收到由用户在服务端输入的控制命令转化的控制信号，其中，控制信号用于触发生成应用补丁。

当待更新应用数据被上传至服务端后，服务端可以通过前台显示页面将待更新应用数据呈现给测试人员，如果测试人员需要查看应用补丁的安装包大小，则可以手动输入控制命令，以控制客户端根据待更新应用数据生成应用补丁。

根据本发明实施例，还提供了另一种应用数据的处理装置的实施例，图4是根据本发明实施例的另一种应用数据的处理装置的结构框图，如图4所示，该装置包括：接收模块40，用于接收客户端上传的待更新应用数据，其中，待更新应用数据是通过将第一应用数据与第二应用数据进行比较后得到的，第一应用数据是对客户端上当前主干开发目录下包含的数据内容进行打包处理后得到的数据，第二应用数据是在客户端的分支开发目录下最新发布的数据；处理模块50，用于根据待更新应用数据生成回归测试列表，并在满足触发条件的情况下，触发客户端根据待更新应用数据生成应用补丁。

在优选实施过程中，上述触发条件可以包括但不限于以下之一：

条件一、到达预设时长的结束时间点向客户端发送第一控制命令，其中，第一控制命令用于触发客户端生成应用补丁；

即服务端在确定接收到客户端上传的待更新应用数据之后，可以定时自动触发客户端根据待更新应用数据生成应用补丁。

条件二、接收到用户输入的第二控制命令，其中，第二控制命令用于触发客户端生成应用补丁。

即服务端也可以在用户输入控制命令后，触发客户端根据待更新应用数据生成应用补丁。

可选地，处理模块50，用于利用知识库对待更新应用数据进行分析，查找出与待更新应用数据相关联的至少一个系统模块，将系统模块添加在待测试列表中，生成回归测试列表，其中，知识库包含应用数据与系统模块的关联关系。

在优选实施过程中，上述系统模块可以包括但不限于以下其中之一：

聊天系统、交易系统、付费系统、登录系统、联网系统、装备系统、技能系统、任务系统、活动系统以及灵兽系统。

可选地，图5是根据本发明优选实施例的另一种应用数据的处理装置的结构框图，如图5所示，处理模块50包括：确定单元500，用于根据待更新应用数据中包含的代码更新数据确定待测试的第一部分应用功能表项；和/或，根据待更新应用数据中包含的策划更新数据确定待测试的第二部分应用功能表项；和/或，根据待更新应用数据中包含的美术资源更新数据确定待测试的第三部分应用功能表项；生成单元502，用于按照确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一生成回归测试列表。

可选地，确定单元500包括：获取子单元(图中未示出)，用于根据美术资源更新数据中包含的场景更新数据获取待测试的第四部分应用功能表项；和/或，根据美术资源更新数据中包含的模型更新数据获取待测试的第五部分应用功能表项；和/或，根据美术资源更新数据中包含的特效更新数据获取待测试的第六部分应用功能表项；和/或，根据美术资源更新数据中包含的用户界面更新数据获取待测试的第七部分应用功能表项；确定子单元(图中未示出)，用于通过获取到的第四部分应用功能表项、第五部分应用功能表项、第六部分应用功能表项以及第七部分应用功能表项中的至少之一确定第三部分应用功能表项。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (18)

1.一种应用数据的处理方法，其特征在于，包括：

获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；

将所述第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；

将所述待更新应用数据上传至服务端，并在满足触发条件的情况下，根据所述待更新应用数据生成应用补丁。

2.根据权利要求1所述的方法，其特征在于，所述待更新应用数据包括以下至少之一：

所述第一应用数据相对于所述第二应用数据新增的数据；

所述第一应用数据相对于所述第二应用数据删除的数据；

所述第一应用数据相对于所述第二应用数据修改的数据以及修改的差异信息。

3.根据权利要求1所述的方法，其特征在于，所述触发条件包括以下之一：

到达预设时长的结束时间点，其中，所述结束时间点用于触发生成所述应用补丁；

接收到由用户在所述服务端输入的控制命令转化的控制信号，其中，所述控制信号用于触发生成所述应用补丁。

4.一种应用数据的处理方法，其特征在于，包括：

接收客户端上传的待更新应用数据，其中，所述待更新应用数据是通过将第一应用数据与第二应用数据进行比较后得到的，所述第一应用数据是对所述客户端上当前主干开发目录下包含的数据内容进行打包处理后得到的数据，所述第二应用数据是在所述客户端的分支开发目录下最新发布的数据；

根据所述待更新应用数据生成回归测试列表，并在满足触发条件的情况下，触发所述客户端根据所述待更新应用数据生成应用补丁。

5.根据权利要求4所述的方法，其特征在于，根据所述待更新应用数据生成所述回归测试列表包括：

利用知识库对所述待更新应用数据进行分析，查找出与所述待更新应用数据相关联的至少一个系统模块，将所述系统模块添加在待测试列表中，生成所述回归测试列表，其中，所述知识库包含应用数据与系统模块的关联关系。

6.根据权利要求5所述的方法，其特征在于，所述系统模块至少包括以下其中之一：

聊天系统、交易系统、付费系统、登录系统、联网系统、装备系统、技能系统、任务系统、活动系统以及灵兽系统。

7.根据权利要求5所述的方法，其特征在于，利用知识库对所述待更新应用数据进行分析，生成所述回归测试列表包括：

根据所述待更新应用数据中包含的代码更新数据确定待测试的第一部分应用功能表项；和/或，根据所述待更新应用数据中包含的策划更新数据确定待测试的第二部分应用功能表项；和/或，根据所述待更新应用数据中包含的美术资源更新数据确定待测试的第三部分应用功能表项；

按照确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一生成所述回归测试列表。

8.根据权利要求7所述的方法，其特征在于，根据所述美术资源更新数据确定所述第三部分应用功能表项包括：

根据所述美术资源更新数据中包含的场景更新数据获取待测试的第四部分应用功能表项；和/或，根据所述美术资源更新数据中包含的模型更新数据获取待测试的第五部分应用功能表项；和/或，根据所述美术资源更新数据中包含的特效更新数据获取待测试的第六部分应用功能表项；和/或，根据所述美术资源更新数据中包含的用户界面更新数据获取待测试的第七部分应用功能表项；

通过获取到的第四部分应用功能表项、第五部分应用功能表项、第六部分应用功能表项以及第七部分应用功能表项中的至少之一确定所述第三部分应用功能表项。

9.根据权利要求4所述的方法，其特征在于，所述触发条件包括以下之一：

到达预设时长的结束时间点向所述客户端发送第一控制命令，其中，所述第一控制命令用于触发所述客户端生成所述应用补丁；

接收到用户输入的第二控制命令，其中，所述第二控制命令用于触发所述客户端生成所述应用补丁。

10.一种应用数据的处理装置，其特征在于，包括：

获取模块，用于获取当前主干开发目录下包含的数据内容进行打包处理，得到待比较的第一应用数据；

比较模块，用于将所述第一应用数据与分支开发目录下最新发布的第二应用数据进行比较，获取待更新应用数据；

生成模块，用于将所述待更新应用数据上传至服务端，并在满足触发条件的情况下，根据所述待更新应用数据生成应用补丁。

11.根据权利要求10所述的装置，其特征在于，所述待更新应用数据包括以下至少之一：

所述第一应用数据相对于所述第二应用数据新增的数据；

所述第一应用数据相对于所述第二应用数据删除的数据；

所述第一应用数据相对于所述第二应用数据修改的数据以及修改的差异信息。

12.根据权利要求10所述的装置，其特征在于，所述触发条件包括以下之一：

到达预设时长的结束时间点，其中，所述结束时间点用于触发生成所述应用补丁；

接收到由用户在所述服务端输入的控制命令转化的控制信号，其中，所述控制信号用于触发生成所述应用补丁。

13.一种应用数据的处理装置，其特征在于，包括：

接收模块，用于接收客户端上传的待更新应用数据，其中，所述待更新应用数据是通过将第一应用数据与第二应用数据进行比较后得到的，所述第一应用数据是对所述客户端上当前主干开发目录下包含的数据内容进行打包处理后得到的数据，所述第二应用数据是在所述客户端的分支开发目录下最新发布的数据；

处理模块，用于根据所述待更新应用数据生成回归测试列表，并在满足触发条件的情况下，触发所述客户端根据所述待更新应用数据生成应用补丁。

14.根据权利要求13所述的装置，其特征在于，所述处理模块，用于利用知识库对所述待更新应用数据进行分析，查找出与所述待更新应用数据相关联的至少一个系统模块，将所述系统模块添加在待测试列表中，生成所述回归测试列表，其中，所述知识库包含应用数据与系统模块的关联关系。

15.根据权利要求14所述的装置，其特征在于，所述系统模块至少包括以下其中之一：

聊天系统、交易系统、付费系统、登录系统、联网系统、装备系统、技能系统、任务系统、活动系统以及灵兽系统。

16.根据权利要求14所述的装置，其特征在于，所述处理模块包括：

确定单元，用于根据所述待更新应用数据中包含的代码更新数据确定待测试的第一部分应用功能表项；和/或，根据所述待更新应用数据中包含的策划更新数据确定待测试的第二部分应用功能表项；和/或，根据所述待更新应用数据中包含的美术资源更新数据确定待测试的第三部分应用功能表项；

生成单元，用于按照确定出的第一部分应用功能表项、第二部分应用功能表项以及第三部分应用功能表项中的至少之一生成所述回归测试列表。

17.根据权利要求16所述的装置，其特征在于，所述确定单元包括：

获取子单元，用于根据所述美术资源更新数据中包含的场景更新数据获取待测试的第四部分应用功能表项；和/或，根据所述美术资源更新数据中包含的模型更新数据获取待测试的第五部分应用功能表项；和/或，根据所述美术资源更新数据中包含的特效更新数据获取待测试的第六部分应用功能表项；和/或，根据所述美术资源更新数据中包含的用户界面更新数据获取待测试的第七部分应用功能表项；

确定子单元，用于通过获取到的第四部分应用功能表项、第五部分应用功能表项、第六部分应用功能表项以及第七部分应用功能表项中的至少之一确定所述第三部分应用功能表项。

18.根据权利要求13所述的装置，其特征在于，所述触发条件包括以下之一：

到达预设时长的结束时间点向所述客户端发送第一控制命令，其中，所述第一控制命令用于触发所述客户端生成所述应用补丁；

接收到用户输入的第二控制命令，其中，所述第二控制命令用于触发所述客户端生成所述应用补丁。