报错信息的处理方法、装置、服务器和可读存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种报错信息的处理方法、装置、服务器和可读存储介质。


背景技术：

2.在游戏制作以及运行的过程中，游戏玩法逻辑大部分是由脚本代码完成编译的，玩家在游戏中会有很多特殊的操作行为，可能会导致各种各样的脚本报错，产生报错信息。开发人员根据这些报错信息需要及时的完成修复工作，以提升游戏质量。
3.现有技术中，报错信息在产生之后，一般需要开发人员去登录全球广域网(world wide web，web)平台数据库，查看报错信息，然后根据个人职责，认领其所负责的报错信息，然后再进行修复。
4.但是，现有技术的这种方式，实际上整个修复过程都是需要负责修复的开发人员主动介入的，每一个开发人员不可能都实时的去登录查看报错信息，来主动认领其所负责的报错信息，导致报错信息无法被及时的察觉，修复工作滞后，修复效率慢。


技术实现要素：

5.本技术提供一种报错信息的处理方法、装置、服务器和可读存储介质，用于解决现有脚本报错的修复效率低的问题。
6.第一方面，本技术实施例提供一种报错信息的处理方法，包括：
7.获取存储在目标服务器中的目标游戏的报错信息，从所述报错信息中提取得到报错文件和所述报错文件的文件路径；
8.根据所述文件路径，确定所述报错文件的文件信息，所述文件信息中至少包括处理所述报错信息的目标对象；
9.将所述报错信息、文件信息推送至目标群组和/或所述目标对象，所述目标群组中至少包括所述目标对象。
10.在第一方面的一种可能设计中，所述从所述报错信息中提取得到报错文件和所述报错文件的文件路径，包括：
11.根据所述报错信息，获取所述报错文件和所述报错文件的绝对路径；
12.将所述绝对路径中的地址前缀滤除，得到所述报错文件的文件路径。
13.在第一方面的另一种可能设计中，所述根据所述文件路径，确定所述报错文件的文件信息，包括：
14.根据所述文件路径，在预设版本库中查找得到所述报错文件的文件信息。
15.在第一方面的再一种可能设计中，所述将所述报错信息、文件信息推送至目标群组和/或所述目标对象，包括：
16.获取所述报错信息的优先级；
17.根据所述优先级，对所述报错信息进行排序，得到排序之后的报错信息；
18.将所述文件信息和排序之后的报错信息推送至所述目标群组和/或目标对象。
19.在第一方面的又一种可能设计中，所述获取所述报错信息的优先级，包括：
20.对所述报错信息进行分类，得到分类后的报错信息；
21.对分类后的报错信息进行统计，确定所述分类后的报错信息出现的频率；
22.根据所述频率，确定所述报错信息的优先级，所述优先级为指示所述目标对象处理所述报错信息的优先级。
23.在第一方面的又一种可能设计中，所述对所述报错信息进行分类，得到分类后的报错信息，包括：
24.获取所述报错信息的分支来源、报错信息的平台来源、目标游戏的游戏架构、报错信息的处理状态和目标游戏的服务端进程类别中的至少一种；
25.根据所述报错信息的分支来源、报错信息的平台来源、目标游戏的游戏架构、报错信息的处理状态和目标游戏的服务端进程类别中的至少一种，对所述报错信息进行分类，得到分类后的报错信息。
26.在第一方面的又一种可能设计中，所述将所述报错信息、文件信息推送至目标群组和/或所述目标对象之后，还包括：
27.获取所述报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出现的总次数和所述报错信息的处理状态；
28.根据所述报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出现的总次数和所述报错信息的处理状态，生成图形化数据；
29.根据终端设备发起的查询请求，将所述图形化数据展示于预设网络平台。
30.在第一方面的又一种可能设计中，所述根据所述文件路径，确定所述报错文件的文件信息，包括：
31.根据所述文件路径，从预设版本库中查询得到所述报错文件的提交作者、提交版本和提交时间，得到所述文件信息；
32.根据所述提交作者，确定所述目标对象。
33.在第一方面的又一种可能设计中，所述将所述报错信息、文件信息推送至目标群组和/或所述目标对象之前，还包括：
34.根据所述报错信息，建立缺陷跟踪单，所述缺陷跟踪单用于指示所述目标对象对所述报错信息进行处理的处理状态；
35.将所述跟踪单推送至所述目标群组和/或目标对象。
36.在第一方面的又一种可能设计中，所述获取存储在目标服务器中的目标游戏的报错信息，包括：
37.根据预设定时间隔，从所述目标服务器中定时拉取所述目标游戏的报错信息。
38.第二方面，本技术实施例提供一种报错信息的处理装置，包括：
39.信息获取模块，用于获取存储在目标服务器中的目标游戏的报错信息，从所述报错信息中提取得到报错文件和所述报错文件的文件路径；
40.文件确定模块，用于根据所述文件路径，确定所述报错文件的文件信息，所述文件信息中至少包括处理所述报错信息的目标对象；
41.信息推送模块，用于将所述报错信息、文件信息推送至目标群组和/或所述目标对
象，所述目标群组中至少包括有所述目标对象。
42.第三方面，本技术实施例提供一种服务器，包括存储器和至少一个处理器；
43.所述存储器存储计算机执行指令；
44.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上述的方法。
45.第四方面，本技术实施例提供一种可读存储介质，所述可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如上述的方法。
46.第五方面，本技术实施例提供一种程序产品，包括计算机指令，该计算机指令被处理器执行时实现上述的方法。
47.本技术实施例提供的报错信息的处理方法、装置、服务器和可读存储介质，通过获取服务器上存储的报错信息，确定报错信息中报错文件的文件信息，能够确定出负责处理该报错文件的目标对象，并及时的自动通知目标对象处理该报错信息，避免了需要目标对象人工介入，从服务器上主动认领其负责处理的报错信息，流程操作繁琐的问题，提高报错信息的修复效率。
附图说明
48.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理；
49.图1为本技术实施例提供的报错信息的处理方法的场景示意图；
50.图2为本技术实施例提供的报错信息的处理方法实施例一的流程示意图；
51.图3为本技术实施例提供的报错信息的处理方法实施例二的流程示意图；
52.图4为本技术实施例提供的报错信息的处理方法实施例三的流程示意图；
53.图5为本技术实施例提供的报错信息的处理装置的结构示意图；
54.图6为本技术实施例提供的报警信息的处理系统架构图；
55.图7为本技术实施例提供的服务器的结构示意图。
56.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
57.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
58.首先对本技术所涉及的名词进行解释：
59.脚本：
60.脚本是指使用一种解释性的编码语言，是依据一定的格式编写的可执行文件。在游戏制作过程中，游戏玩法逻辑很大一部分是由脚本代码来完成编译的，脚本不需要通过编译就可以直接运行。
61.图1为本技术实施例提供的报错信息的处理方法的场景示意图。如图1所示，本实施例的应用场景可以是第一服务器10，在第一服务器10上可以搭一个脚本服务，通过该脚本服务从第二服务器11上拉取报错信息，保存到数据库中，同时在保存之前，会将报错信息、报错文件的文件信息推送给终端设备12中的开发人员。第二服务器11可以是远程的运维服务器，第二服务器11上会有特定的工作人员来维护，将游戏中产生的报错信息存储到第二服务器11上。
62.其中，报错信息可以是玩家在游戏中一些特殊操作行为所产生的，例如玩家在从手机客户端切换到电脑端时，由于电脑和手机所搭载的操作系统不同，就有可能发生系统兼容性问题，导致出现报错。报错信息还可以是游戏在内测时，测试人员对脚本进行各种检查(例如静态代码检查)，出现的各种检查的报错信息。对这些报错信息进行及时的修复，能够减少游戏缺陷，提高游戏质量。
63.在实际生活应用中，游戏在发行时可以根据不同的国家，分为不同的版本，例如分为国内版和海外版。而国内版又可以根据客户端分支(例如电脑端、手机端)、服务端分支(例如体验服、审核服、正式服和开发服)进行分类，所以报错信息会来自很多分支，分支越多，每天所产生的报错信息就越多。现有技术在处理这些报错信息时，往往是将报错信息收集存储在web平台数据中，测试人员和开发人员登录web平台查看，然后根据自己的职责，认领其负责处理的报错信息，然后进行修复。现有技术的这种方式，一方面需要人员主动介入到该流程中，有时候开发人员受制于其他开发任务，不会时刻关注web平台上的报错信息，导致报错信息无法得到及时的修复。另一方面，不同职责的开发人员需要各自去认领所负责的报错信息，效率非常慢，并且认领之后由于报错信息较多，往往会显得杂乱无章，开发人员无法针对性的进行修复，导致一些重要的报错信息的修复被滞后。综上述，现有技术这种报错信息的处理方式会导致报错信息的修复效率非常慢。
64.针对上述问题，本技术实施例提供了一种报错信息的处理方法、装置、服务器和可读存储介质。通过定时从服务器拉取报错信息，能够实时的对游戏产生的报错信息进行收集，并提取出报错文件的文件信息，确定出修复该报错信息的负责人，自动推送至该负责人或其所处的群组。能够保证负责人及时的接收到报错信息，实现报错信息的及时修复。同时不需要负责人主动介入，根据其职责主动认领其负责的报错信息，减少工作量，提高修复效率。最后还可以统计每一个报错信息的优先级，使得负责人可以根据优先级来针对性的进行修复，避免重要的报错信息修复出现滞后。
65.下面，通过具体实施例对本技术的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
66.图2为本技术实施例提供的报错信息的处理方法实施例一的流程示意图，该方法可以应用于服务器或者计算机等设备。如图2所示，该方法具体可以包括如下步骤：
67.s201、获取存储在目标服务器中的目标游戏的报错信息，从报错信息中提取得到报错文件和报错文件的文件路径。
68.示例性的，目标游戏可以分为若干个分支，例如根据发行版本可以分为海外版和国内版。根据目标游戏的运行平台，又可以划分为电脑端、ios端和android端。根据目标游戏的游戏架构，其还可以划分为客户端或者网页服务端。根据目标游戏的服务端进程类别，
还可以划分为体验服、审核服、开发服和正式服等。
69.目标服务器可以是上述的第二服务器11，目标游戏中各个分支的玩家在游戏时出现的报错信息都会被上传到第二服务器11中，第一服务器10可以从第二服务器11中拉取得到报错信息。
70.示例性的，报错信息包括有报错文件、出现错误的是哪一行代码(即错误代码行数)、该错误代码对应输出的信息和绝对路径等。示例性的，报错文件可以是某一个脚本。
71.在本实施例中，文件路径用于获取报错文件的文件信息。
72.在一些实施方式中，可以预设定时间隔，根据预设定时间隔，从目标服务器中拉取目标游戏的报错信息。
73.示例性的，预设时间间隔可以是1分钟或者3分钟，具体可以根据第一服务器11的性能和报错信息的实时性进行设置。
74.s202、根据文件路径，确定报错文件的文件信息。
75.其中，文件信息中至少包括处理报错信息的目标对象，示例性的，文件信息还包括报错文件的提交作者、提交时间和提交版本等。
76.在本实施例中，目标对象是指负责处理该报错信息的人员，示例性的，目标对象可以是报错文件的提交作者。
77.示例性的，可以通过文件路径直接在预设版本库找到存储的文件信息，也可以将文件路径与预设版本库中的预设路径进行对比，找到与文件路径吻合的预设路径，然后通过该预设路径，查找得到文件信息。
78.s203、将报错信息、文件信息推送至目标群组和/或目标对象。
79.其中，目标群组中至少包括目标对象。示例性的，目标群组可以是聊天群组，聊天群组的群成员中至少包括有该目标对象。
80.示例性的，在将报错信息和文件信息推送至目标群组和/或目标对象进行提醒时，还可以设置确认操作，例如，当提醒了目标对象之后，若目标对象没有进行确认操作(即确认收到)时，可以在间隔一定的时间周期内再次进行推送，直到目标对象确认收到。
81.可选的，还可以将报错信息的处理状态推送给目标对象，处理状态可以包括有新建、已提单、已忽略和已修复等，当报错信息处于新建状态时，指示游戏产生了新的报错信息，当报错信息为已提单状态时，则表示报错信息和文件信息已经推送至目标群组和/或目标对象。当报错信息为已忽略时，则表示目标对象将该报错信息忽略。已修复则表示报错信息已经被目标对象修复。
82.可选的，为了避免报错信息和文件信息推送过于频繁，可以设置一个时间周期，例如以一天为一个时间周期，当天已经推送过了的报错信息和文件信息，在当天不再进行推送。
83.本技术实施例通过设置定时脚本定时获取报错信息，能够及时发现并捕获报错信息，提高报错信息修复的实时性，同时能够实现全自动化管理，不需要开发人员主动介入，认领其所负责的报错信息，显著提升工作效率。报错信息和文件信息可以自动的推送给开发人员，实现有效的实时提醒。
84.在一些实施例中，上述步骤s201中“从报错信息中提取得到报错文件和报错文件的文件路径”，具体可以通过如下步骤实现：
85.根据报错信息，获取报错文件和报错文件的绝对路径；
86.将绝对路径中的地址前缀滤除，得到报错文件的文件路径。
87.在本实施例中，报错信息中包括有报错文件以及报错文件的绝对路径，其中，绝对路径是指目录下的绝对位置，直接到达目标位置，通常是从盘符开始的路径。完整的描述文件位置的路径就是绝对路径。示例性的，绝对路径可以是e:/website/index.htm。
88.其中，来自不同的运行平台的报错信息，其中的报错文件的绝对路径是不相同的，其前缀地址不相同，而后缀地址是相同的，例如ios端的报错文件的绝对路径可以是e:/website/index.htm。而在android端的报错文件的绝对路径可以是d:/website/index.htm。两者的地址前缀不相同。
89.本技术实施例通过对绝对路径中的地址前缀进行滤除，能够对不同客户端的报错文件进行区分，找到来自不同客户端的报错文件的文件路径，方便后续查找得到该报错文件对应的文件信息。
90.进一步的，在上述实施例的基础上，在一些实施例中，上述步骤s202具体可以通过如下步骤实现：
91.根据文件路径，在预设版本库中查找得到报错文件的文件信息。
92.示例性的，预设版本库中包括有报错文件的提交作者、提交日期和提交版本等信息，报错文件的这些信息被整合存储在预设版本库中的同一个预设路径下。若文件路径与该预设路径吻合，则可以将该预设路径中存储的提交作者、提交日期和提交版本等信息提取出来，得到文件信息。
93.本技术实施例通过能够通过文件信息，确定出负责修复该报错信息的负责人，不需要开发人员来主动认领其所负责的报错信息，提高修复效率。
94.图3为本技术实施例提供的报错信息的处理方法实施例二的流程示意图，如图3所示，该方法包括如下步骤：
95.s301、获取存储在目标服务器中的目标游戏的报错信息，从报错信息中提取得到报错文件和报错文件的文件路径。
96.s302、根据文件路径，确定报错文件的文件信息。
97.其中，文件信息中至少包括处理报错信息的目标对象。
98.s303、获取报错信息的优先级。
99.s304、根据优先级，对报错信息进行排序，得到排序之后的报错信息。
100.s305、将文件信息和排序之后的报错信息推送至目标群组和/或目标对象。
101.其中，步骤s301和步骤s302与上述步骤s201、步骤s202相同，在此不再赘述。在本实施例中，由于目标游戏包括有很多分支，每一天每一个时刻可能都会有大量的报错信息从各个分支上传到第二服务器11中。示例性的，不同的报错信息对游戏的影响程度不相同。例如，有的报错信息如果不能够及时修复，游戏将无法启动运行，其对游戏的影响较大，而有的报错信息可能是游戏内玩家的一些特殊操作产生的，不影响游戏的正常运行，其对游戏的影响程度较小。
102.其中，优先级用于指示每一个报错信息对目标游戏的影响程度。优先级高的报错信息，应当优先进行修复，优先级低的报错信息，则延后修复。
103.本技术实施例通过确定每个报错信息的优先级，开发人员能够根据优先级来进行
修复，将重要的报错信息优先修复，提高报错信息的修复效果。
104.进一步的，在上述实施例的基础上，在一些实施例中，在确定每一个报错信息的优先级时，可以通过如下步骤实现：
105.对报错信息进行分类，得到分类后的报错信息；
106.对分类后的报错信息进行统计，确定分类后的报错信息出现的频率；
107.根据频率，确定报错信息的优先级。
108.其中，优先级为指示目标对象处理报错信息的优先级。
109.示例性的，报错信息可以根据目标游戏的发行版本进行分类，例如可以将海外版所产生的报错信息分为第一类别，游戏的国内版所产生的报错信息分为第二类别。第一类别和第二类别中的报错信息又可以分为若干类。例如第一类别中包括有第一报错信息、第二报错信息和第三报错信息，其中，第一报错信息出现的频率最高，第二报错信息出现的频率次之，第三报错信息出现的频率最低。则第一报错信息的优先级最高，第二报错信息的优先级次之，第三报错信息的优先级最低。
110.本技术实施例通过统计每个报错信息出现的频率，能够让开发人员将一些出现较为频繁的报错信息优先修复，提高游戏质量。
111.进一步的，在上述实施例的基础上，在一些实施例中，上述对报错信息进行分类可以通过如下步骤实现：
112.获取报错信息的分支来源、报错信息的平台来源、目标游戏的游戏架构、报错信息的处理状态和目标游戏的服务端进程类别中的至少一种；
113.根据报错信息的分支来源、报错信息的平台来源、目标游戏的游戏架构、报错信息的处理状态和目标游戏的服务端进程类别中的至少一种，对报错信息进行分类，得到分类后的报错信息。
114.在本实施例中，分支来源可以分为海外版和国内版。平台来源可以分为电脑端、ios端和android端。游戏架构可以分为客户端和网页服务端。处理状态包括上述的新建、已提单、已忽略和已修复。服务端进程类别包括体验服、审核服、开发服和正式服等。
115.示例性的，可以将分支来源作为大类，将平台来源作为大类下的小类，对报错信息进行多维度的分类。
116.本技术实施例通过多维度的分类，能够准确确定出报错信息的重要程度，方便开发人员优先处理重要程度高的报错。
117.在一些实施例中，上述的报错信息的处理方法还可以包括如下步骤：
118.获取报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出现的总次数和报错信息的处理状态；
119.根据报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出现的总次数和报错信息的处理状态，生成图形化数据；
120.根据终端设备发起的查询请求，将图形化数据展示于预设网络平台。
121.在本实施例中，不同的玩家在游戏中可能产生同一个报错信息，游戏在不同平台(即电脑端、ios端或android端)运行也可以会出现同一个报错信息。第一服务器10在从第二服务器11拉取到大量的报错信息之后，可以对报错信息进行分类统计，确定出每一个报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出
现的总次数和报错信息的处理状态。示例性的，预设时间周期可以是一周，即七天。
122.示例性的，可以根据预设时间周期内出现的总次数大小，对每一个报错信息进行排序，得到排名前5的报错信息，加入至图形化数据中。示例性的，图形化数据可以是图形化表格。
123.本技术实施例通过将报错信息转换为图形化数据，并在web系统上提供统计信息的查询、指派，以直观的图形化展示数据，利于帮助开发人员分析数据，把握趋势，辅助开发人员进行报错修复，提高修复效率。
124.在一些实施例中，上述的报错信息的处理方法还可以包括如下步骤：
125.根据报错信息，建立缺陷跟踪单；
126.将缺陷跟踪单推送至目标群组和/或目标对象。
127.其中，缺陷跟踪单用于指示目标对象对报错信息进行处理的处理状态。
128.示例性的，可以在第一服务器10上设置缺陷跟踪系统，当第一服务器10从第二服务器11拉取到报错信息时，缺陷跟踪系统自动建立缺陷跟踪单对该报错信息进行跟踪。
129.本技术实施例通过缺陷跟踪单来跟踪每一个报错信息的处理状态，让开发人员可以了解报错信息当前的处理状态，避免出现报错信息处理滞后的情况。
130.图4为本技术实施例提供的报错信息的处理方法实施例三的流程示意图，如图4所示，该方法包括如下步骤：
131.s401、定时脚本拉取远程运维服务器的报错信息并保存在项目本地数据库中。
132.具体的，定时脚本可以设置第一服务器中，以定时的方式运行，示例性的，可以每间隔一分钟运行一次，从第二服务器(即运维服务器)上拉取报错信息。
133.s402、对报错信息进行分析，获取报错文件的文件信息，并自动在缺陷管理系统中新建缺陷跟踪单。
134.具体的，在将报错信息保存在项目本地数据库之前，可以对依次拉取的多条报错信息进行文本分析，分割出多条报错信息，并在每条报错信息中提取出报错文件的文件路径，再利用代码控制管理工具，获取报错文件的文件信息。
135.示例性的，文件信息包括提交作者、提交时间和提交版本等内容，根据提交作者可以确定目标对象，即负责修复该报错信息的开发人员。
136.s403、把每条报错信息、报错文件的文件信息、缺陷跟踪单发送到聊天群组和/或目标对象进行提醒和确认。
137.示例性的，在一段时间(例如一天)内，若某条报错信息、该条报错信息的报错文件的文件信息、对应的缺陷跟踪单已经发送到聊天群组和/或目标对象进行提醒和确认，在该段时间内，后续又产生了该条报错信息，则不会再进行提醒和确认，而是直接保存到项目本地数据库中。避免重复的信息过多，造成混淆。
138.s404、设置定时分类脚本，对收集的报错信息进行分类统计，通过不同维度的统计分析，并进行定时播报。
139.具体的，可以依据如下五种分类方式，对报警信息进行分类：
140.(1)按报错信息的分支来源，划分为国服类，海外类；
141.(2)按平台来源划分为，pc端、ios端、android端；
142.(3)按游戏架构，划分为客户端、服务端；
143.(4)按报错信息的处理情况，划分为新建、已提单、已忽略、已修复；
144.(5)按照服务端进程类别，划分为体验服、审核服、开发服、正式外服等。
145.可以通过如下五种不通过的维度进行统计分析，确定出每条报警信息的优先级。
146.(6)统计一个时间段内报错信息出现的频率排名，表征报错修复的重要程度；
147.(7)统计不同平台的报错次数排名，分析脚本代码的系统兼容性问题；
148.(8)统计不同玩家的出现的报错次数，表征报错的偶发性还是必发性；
149.(9)统计不同分支的处理情况，每日特定时间播报当周各个分支修复率；
150.(10)统计每周次数最多的top5位报错，总结报错类型及避免方法。
151.s405、在web系统上提供统计信息的查询，以图形化展示分析数据。
152.具体的，当研发人员在进行报错信息的修复时，可以登录web系统，查看图形化数据，来辅助其修复工作。例如通过查看不同平台的报错次数排名，确定出脚本代码是否存在兼容性问题。
153.下述为本技术装置实施例，可以用于执行本技术方法实施例。对于本技术装置实施例中未披露的细节，请参照本技术方法实施例。
154.图5为本技术实施例提供的报错信息的处理装置的结构示意图，该处理装置可以集成在服务器上，也可以独立于服务器且与服务器协同完成本技术方案。如图5所示，该处理装置50包括信息获取模块51、文件确定模块52和信息推送模块53。
155.其中，信息获取模块51用于获取存储在目标服务器中的目标游戏的报错信息，从报错信息中提取得到报错文件和报错文件的文件路径。文件确定模块52用于根据文件路径，确定报错文件的文件信息。信息推送模块53用于将报错信息、文件信息推送至目标群组和/或目标对象。
156.其中，文件信息中至少包括处理报错信息的目标对象，目标群组中至少包括有目标对象。
157.在一些实施例中，上述信息获取模块51具体可以用于：
158.根据报错信息，获取报错文件和报错文件的绝对路径；
159.将绝对路径中的地址前缀滤除，得到报错文件的文件路径。
160.在一些实施例中，上述文件确定模块52具体可以用于：
161.根据文件路径，在预设版本库中查找得到报错文件的文件信息。
162.在一些实施例中，上述信息推送模块53具体可以用于：
163.获取报错信息的优先级；
164.根据优先级，对报错信息进行排序，得到排序之后的报错信息；
165.将文件信息和排序之后的报错信息推送至目标群组和/或目标对象。
166.可选的，在一些实施例中，上述信息推送模块53具体可以用于：
167.对报错信息进行分类，得到分类后的报错信息；
168.对分类后的报错信息进行统计，确定分类后的报错信息出现的频率；
169.根据频率，确定报错信息的优先级。
170.其中，优先级为指示目标对象处理报错信息的优先级。
171.可选的，在一些实施例中，上述信息推送模块53具体可以用于：
172.获取报错信息的分支来源、报错信息的平台来源、目标游戏的游戏架构、报错信息
的处理状态和目标游戏的服务端进程类别中的至少一种；
173.根据报错信息的分支来源、报错信息的平台来源、目标游戏的游戏架构、报错信息的处理状态和目标游戏的服务端进程类别中的至少一种，对报错信息进行分类，得到分类后的报错信息。
174.在一些实施例中，上述报错信息的处理装置50还可以包括数据生成模块，用于：
175.获取报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出现的总次数和报错信息的处理状态；
176.根据报错信息出现的频率、在不同平台出现的次数、在不同玩家出现的次数、在预设时间周期内出现的总次数和报错信息的处理状态，生成图形化数据；
177.根据终端设备发起的查询请求，将图形化数据展示于预设网络平台。
178.可选的，在一些实施例中，上述文件确定模块52具体可以用于：
179.根据文件路径，从预设版本库中查询得到报错文件的提交作者、提交版本和提交时间，得到文件信息；
180.根据提交作者，确定目标对象。
181.在一些实施例中，上述报错信息的处理装置50还包括跟踪模块，用于：
182.根据报错信息，建立缺陷跟踪单，缺陷跟踪单用于指示目标对象对报错信息进行处理的处理状态；
183.将缺陷跟踪单推送至目标群组和/或目标对象。
184.可选的，在一些实施例中，上述信息获取模块51具体可以用于：
185.根据预设定时间隔，从目标服务器中定时拉取目标游戏的报错信息。
186.本技术实施例提供的装置，可用于执行图2至图4所示实施例中的方法，其实现原理和技术效果类似，在此不再赘述。
187.需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，信息获取模块可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上信息获取模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。在实现过程中，上述方法的各步骤或以上各个模块可以通过软件形式的指令完成。
188.例如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(central processing unit，cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system
‑
on
‑
a
‑
chip，soc)的形式实现。
189.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本技术实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机
可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solid state disk(ssd))等。
190.图6为本技术实施例提供的报警信息的处理系统架构图，如图6所示，包括有运维服务器61和本地项目服务器62。其中，运维服务器61可以收集国服不同客户端的报错信息和海外服不同客户端的报错信息。由本地项目服务器62通过定时脚本定时拉取。本地项目服务器62通过数据处理器将报错信息进行特征去重、信息提取、自动建单和报错报警。然后通过分类统计脚本对不同分支来源的报错信息进行分类，形成图形化数据，并存放到web平台。开发人员可以登录web平台来查看图形化数据，以辅助修复工作。
191.图7为本技术实施例提供的服务器的结构示意图。如图7所示，该服务器70包括：至少一个处理器71、存储器72、总线73及通信接口74。
192.其中：处理器71、通信接口74以及存储器72通过总线73完成相互间的通信。
193.通信接口74，用于与其它设备进行通信。该通信接口74包括用于进行数据传输的通信接口。
194.处理器71，用于执行存储器72中存储的计算机执行指令，具体可以执行上述实施例中所描述的方法中的相关步骤。
195.具体地，程序可以包括程序代码，该程序代码包括计算机操作指令。
196.处理器可能是中央处理器，或者是特定集成电路(application specific integrated circuit，asic)，或者是被配置成实施本发明实施例的一个或多个集成电路。服务器包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。
197.存储器72，用于存放计算机执行指令。存储器可能包含高速ram存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。
198.本实施例还提供一种可读存储介质，可读存储介质中存储有计算机指令，当服务器的至少一个处理器执行该计算机指令时，服务器执行上述的各种实施方式提供的报警信息的处理方法。
199.本实施例还提供一种程序产品，该程序产品包括计算机指令，该计算机指令存储在可读存储介质中。服务器的至少一个处理器可以从可读存储介质读取该计算机指令，至少一个处理器执行该计算机指令使得服务器实施上述的各种实施方式提供的报警信息的处理方法。
200.本技术中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a
‑
b，a
‑
c，b
‑
c，或a
‑
b
‑
c，其中，a，b，c可以是单个，也可以是多个。
201.可以理解的是，在本技术实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本技术的实施例的范围。在本技术的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术的实施例的实施过程构成任何限定。
202.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。