CN110941554B - 一种复现故障的方法及装置 - Google Patents

Abstract

本申请的实施例提供了一种复现故障的方法及装置。该复现故障的方法包括：获取应用程序运行时的属性信息和操作指令序列，并对属性信息进行挖掘，得到应用程序发生故障时对应的关键属性，同时根据操作指令序列，得到应用程序发生故障时对应的关键操作指令序列，最后基于关键属性和关键操作指令序列复现应用程序发生故障时的状态。本申请实施例的技术方案通过对应用程序运行时的信息进行挖掘，得到应用程序发生故障时对应的关键属性以及关键操作指令序列，进而基于关键属性和关键操作指令序列复现应用程序发生故障时的状态，节省了信息整合的时间，提高了故障定位的效率和准确率。

Description

一种复现故障的方法及装置

技术领域

本申请涉及计算机及通信技术领域，具体而言，涉及一种复现故障的方法及装置。

背景技术

当应用程序在运行过程中发生故障时，例如出现崩溃的情况时，一般通过故障发生时候的报错信息来确定故障发生的原因。但是，应用程序一般是在底层的程序代码中，很难通过报错信息定位到问题，且当应用程序发生故障的情况很普遍、数据量很大的情况下，将会极大的降低故障复现的效率。

发明内容

本申请的实施例提供了一种复现故障的方法及装置，进而至少在一定程度上可以基于大量应用程序运行信息复现故障，提高故障复现的效率和准确率。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种复现故障的方法，包括：获取应用程序运行时的属性信息和操作指令序列；对所述属性信息进行挖掘，得到所述应用程序发生故障时对应的关键属性；根据所述操作指令序列，得到所述应用程序发生故障时对应的关键操作指令序列；基于所述关键属性和所述关键操作指令序列复现所述应用程序发生故障时的状态。

根据本申请实施例的一个方面，提供了一种复现故障的装置，包括：获取单元，用于获取应用程序运行时的属性信息和操作指令序列；属性单元，用于对所述属性信息进行挖掘，得到所述应用程序发生故障时对应的关键属性；序列单元，用于根据所述操作指令序列，得到所述应用程序发生故障时对应的关键操作指令序列；复现单元，用于基于所述关键属性和所述关键操作指令序列复现所述应用程序发生故障时的状态。

在本申请的一些实施例中，基于前述方案，所述属性单元包括：构建单元，用于基于预设的属性列表和所述属性信息，构建属性信息的频繁项集；第一挖掘单元，用于从所述频繁项集中挖掘得到所述关键属性。

在本申请的一些实施例中，基于前述方案，所述第一挖掘单元配置为：根据所述频繁项集中每个属性名称出现的概率，确定所述应用程序发生故障时对应的关键属性。

在本申请的一些实施例中，基于前述方案，所述序列单元包括：根据所述操作指令序列中各个操作指令之间的排序，从所述操作指令序列中挖掘出所述关键操作指令序列。

在本申请的一些实施例中，基于前述方案，所述复现单元包括：第一复现单元，用于基于所述故障对应的所述关键属性，生成复现的属性列表；第二复现单元，用于基于所述故障对应的关键操作指令序列，生成复现的操作指令列表；第三复现单元，用于根据所述属性列表和所述操作指令列表，复现所述应用程序发生故障时的状态。

在本申请的一些实施例中，基于前述方案，所述复现故障的装置还包括：第一存储单元，用于根据所述故障对应的所述属性列表和所述操作指令列表生成所述故障的档案信息，并将所述档案信息存储至预设的故障数据库。

在本申请的一些实施例中，基于前述方案，所述复现故障的装置还包括：第一获取单元，用于获取客户端发送的故障查询标识；查询单元，用于根据所述故障查询标识，在所述故障数据库中查找所述故障查询标识对应的属性列表和操作指令列表；返回单元，用于将所述故障查询标识对应的属性列表和操作指令列表返回至所述客户端。

在本申请的一些实施例中，基于前述方案，所述获取单元包括：检测单元，用于检测所述应用程序发生故障的时刻；第二获取单元，用于根据所述时刻，获取所述应用程序的操作指令序列、业务属性信息以及所述应用程序的载体的运行属性信息。

在本申请的一些实施例中，基于前述方案，所述复现故障的装置还包括：记录单元，用于记录所述应用程序的载体运行所述应用程序时操作指令；第二存储单元，用于将所述操作指令存储至预设的经分日志中。

根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的复现故障的方法。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的复现故障的方法。

在本申请的一些实施例所提供的技术方案中，获取应用程序运行时的属性信息和操作指令序列，并对属性信息进行挖掘，得到应用程序发生故障时对应的关键属性，同时根据操作指令序列，得到应用程序发生故障时对应的关键操作指令序列，最后基于关键属性和关键操作指令序列复现应用程序发生故障时的状态。通过对应用程序运行时的信息进行挖掘，得到应用程序发生故障时对应的关键属性以及关键操作指令序列，进而基于关键属性和关键操作指令序列复现应用程序发生故障时的状态，节省了信息整合的时间，提高了故障定位的效率和准确率。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了可以应用本申请实施例的技术方案的示例性系统架构的示意图；

图2示意性示出了根据本申请的一个实施例的复现故障的方法的流程图；

图3示意性示出了根据本申请的一个实施例的获取属性信息和操作指令序列之前的方法的流程图；

图4示意性示出了根据本申请的一个实施例的获取应用程序运行时的属性信息和操作指令序列的流程图；

图5示意性示出了根据本申请的一个实施例的得到应用程序发生故障时对应的关键属性的流程图；

图6示意性示出了根据本申请的一个实施例的频繁项集可视化的示意图；

图7示意性示出了根据本申请的一个实施例的频繁项集可视化的示意图；

图8示意性示出了根据本申请的一个实施例的关键属性的示意图；

图9示意性示出了根据本申请的一个实施例的经分数据的列表的示意图；

图10示意性示出了根据本申请的一个实施例的挖掘组件的执行示例图；

图11示意性示出了根据本申请的一个实施例的关键操作指令序列的示意图

图12示意性示出了根据本申请的一个实施例的基于关键属性和关键操作指令序列复现应用程序发生故障时的状态的流程图；

图13示意性示出了根据本申请的一个实施例的故障查询的流程图；

图14示意性示出了根据本申请的一个实施例的故障复现和管理的示意图；

图15示意性示出了根据本申请的一个实施例的复现故障的装置的示意图；

图16示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1示出了可以应用本申请实施例的技术方案的示例性系统架构的示意图。

如图1所示，系统架构可以包括终端设备(如图1中所示智能手机101、平板电脑102和便携式计算机103中的一种或多种，当然也可以是台式计算机等等)、网络104和服务器105。网络104用以在终端设备和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线通信链路、无线通信链路等等。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。

用户可以使用终端设备通过网络104与服务器105交互，以接收或发送消息等。服务器105可以是提供各种服务的服务器。例如用户利用终端设备103(也可以是终端设备101或102)向服务器105上传了应用程序运行时的属性信息和操作指令序列；服务器105获取应用程序运行时的属性信息和操作指令序列，并对属性信息进行挖掘，得到应用程序发生故障时对应的关键属性，同时根据操作指令序列，得到应用程序发生故障时对应的关键操作指令序列，最后基于关键属性和关键操作指令序列复现应用程序发生故障时的状态。通过对应用程序运行时的信息进行挖掘，得到应用程序发生故障时对应的关键属性以及关键操作指令序列，进而基于关键属性和关键操作指令序列复现应用程序发生故障时的状态，节省了信息整合的时间，提高了故障定位的效率和准确率。

需要说明的是，本申请实施例所提供的复现故障的方法一般由服务器105执行，相应地，复现故障的装置一般设置于服务器105中。但是，在本申请的其它实施例中，终端设备也可以与服务器具有相似的功能，从而执行本申请实施例所提供的复现故障的方案。除此之外，本实施例中复现故障的方法也可以通过其它具有复现故障功能的客户端来执行，此处不做限定。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图2示出了根据本申请的一个实施例的复现故障的方法的流程图，该复现故障的方法可以由服务器来执行，该服务器可以是图1中所示的服务器。参照图2所示，该复现故障的方法至少包括步骤S210至步骤S240，详细介绍如下：

在步骤S210中，获取应用程序运行时的属性信息和操作指令序列。

在本申请的一个实施例中，应用程序可以为在客户端运行，也可以在服务器端运行，此处不做限定。

在本申请的一个实施例中，应用程序运行过程中，通过接收用户的操作指令，运行实现相应的功能，并生成一系列的运行信息。基于实际的应用场景，本实施例中，通过获取应用程序运行时的属性信息和操作指令序列，来进行之后的操作。

在本申请的一个实施例中，属性信息可以包括应用程序运行过程中的状态信息、应用程序的载体在运行应用程序时候的硬件属性信息等，此处不做限定。操作指令序列用于表示应用程序在运行过程中，用户通过应用程序的载体发出的指令及其发出指令的时序组成的操作指令序列，其中包括至少一个或者两个以上的操作指令，且可以通过操作指令序列来确定用户在使用应用程序的过程中的操作序列或行为序列。

在本申请的一个实施例中，在获取应用程序的属性信息和操作指令序列时，可以是实时获取，也可以是应用程序运行完毕之后的某一时刻获取，此处不做限定。

在本申请的一个实施例中，在获取应用程序的属性信息和操作指令序列时，可以是直接通过应用程序的载体获取，也可以是通过应用程序上传数据至服务器，从服务器中获取等方式，此处不做限定。

在本申请的一个实施例中，如图3所示，步骤S210中获取应用程序运行时的属性信息和操作指令序列的过程之前，包括如下步骤S310至步骤S320，详细介绍如下：

在步骤S310中，记录应用程序的载体运行应用程序时的操作指令。

在本申请的一个实施例中，在应用程序运行的载体运行该应用程序时，可对其运行过程中生成的数据进行记录，确定应用程序在运行过程中对应的每个操作指令都可以在之后被查询或者获取到。

在步骤S320中，将操作指令存储至预设的经分日志中。

在本申请的一个实施例中，预先设置有经分日志，用于基于运行时间，记录应用程序的载体在运行应用程序过程中的操作指令或者属性等信息流信息。

示例性的，经分日志是记录玩家某些信息流根据时间变化的一种日志，每一条日志记录某个玩家在某个时刻的一个操作或者属性，比如，代表“ABCD”这个玩家在2019年05月03日16点56分23秒进行了穿装备操作。其中，“ABCD”用于表示用户属性信息，“2019年05月03日16点56分23秒”表示时间流信息，“穿装备操作”用于表示操作属性信息。

在本申请的一个实施例中，如图4所示，步骤S230中获取应用程序运行时的属性信息和操作指令序列的过程，包括如下步骤S410至步骤S420，详细介绍如下：

在步骤S410中，检测应用程序发生故障的时刻。

在本申请的一个实施例中，通过检测应用程序发生故障的时刻，以针对性的获取发生故障时候的属性信息和操作指令序列，提高数据的利用率。

应用程序所发生的故障可以包括崩溃、闪退、卡顿等，此处不做限定。在应用程序的载体中运行应用程序时，若应用程序发生故障，应用程序的载体可以记录故障信息，并将故障信息上报至服务器等，以通过报错时间来确定应用程序发生故障的时刻。

在步骤S420中，根据时刻，获取应用程序的操作指令序列、业务属性信息以及应用程序的载体的运行属性信息。

在本申请的一个实施例中，在确定了应用程序发生故障的时候，根据该时刻，在应用数据中查找该时刻对应的应用程序的操作指令序列、业务属性信息以及应用程序的运行属性信息。其中，业务属性信息可以包括应用场景、运行属性等，运行属性信息可以包括应用程序的载体的型号、CPU或者应用系统等，此处不做限定。

示例性的，在游戏应用程序中，业务属性信息可以包括游戏复本、游戏场景以及游戏加载进程等信息，应用程序的载体的运行属性信息可以包括客户端的硬件信息，例如手机型号、应用系统等。请参考下表所示：

根据上表示例，在以游戏为应用程序的场景的，本实施例中通过记录游戏运行过程中的各种信息，并着重将游戏发生崩溃时候的操作指令序列、业务属性信息以及应用程序的载体的运行属性信息等存储在故障平台中，以在之后进行查询或调用。

进一步的，本实施例中可以将应用程序的报错信息通过预先设定的报错系统上报各类应用信息，然后从报错系统提取某个问题所有用户的对应的应用程序的操作指令序列、业务属性信息以及应用程序的载体的运行属性信息。其中，报错系统可用于提供专业的崩溃、应用无响应、卡顿的监控和解决方案。

在步骤S220中，对属性信息进行挖掘，得到应用程序发生故障时对应的关键属性。

在获取到属性信息之后，属性信息中包括了与应用程序相关的所有信息，其中信息种类和内容可能过于庞杂，无法从中得到清楚明确的故障信息。因此，本实施例通过对属性信息进行挖掘，得到应用程序发生故障时对应的关键属性。

其中，本实施例中的关键属性用于表示应用程序在发生故障时，具有代表性的、可用于体现故障原因的属性。以通过关键属性，复现应用程序的故障。

在本申请的一个实施例中，如图2所示，步骤S220中对属性信息进行挖掘，得到应用程序发生故障时对应的关键属性的过程，包括如下步骤S510至步骤S520，详细介绍如下：

在步骤S510中，基于预设的属性列表和属性信息，构建属性信息的频繁项集。

现有的复现方案依赖的故障管理系统上搜集的信息零散而不聚焦，并且缺少很多与业务相关的信息，比如问题出现时，玩家所处的场景以及玩家身上的任务等等；同时对于日志的分析，传统日志没有更多的有效信息，并且查看耗时，一次只能查看一个玩家数据，无法在全局的角度更好的将信息整合起来。针对上述问题，本实施例的技术方案整合了机型库数据，并上报更多的业务属性，通过频繁项集聚焦关键属性，对经分日志进行序列模式挖掘出操作序列，大大提高了崩溃问题的复现效率。

在本申请的一个实施例中，预先针对各种类型的属性及其属性信息构建了属性列表，用于通过属性列表确定当前获取到的属性信息对应的频繁项集。本实施例中的频繁项集用于表示最基本的属性。

在本申请的一个实施例中，在生成频繁项集的过程中，先确定属性信息中频繁出现的项集，在计算每个项集对应的支持度，当支持度大于等于最小支持度的时，根据该属性及其对应的属性值构成频繁项集中的一个属性集合。其中，支持度是指某个集合在所有事务中出现的频率。

在本申请的一个实施例中，在生成了频繁项集之后，可以通过可视化的方式，将频繁项集中的各属性情况显示出来。示例性的，获取问题玩家的属性信息之后，对特征进行了可视化，并通过频繁项集挖掘来获取关键属性，针对需要复现的崩溃问题。

请一并参考图6和图7所示，图6和图7皆为本申请实施例提供的频繁项集可视化的示意图。在图6中，610～680分别表示任务标识或者代码等，各个百分比用于表示崩溃时的主线任务占比，例如，73％的崩溃发生时的主线任务为任务610，7％的崩溃发生时的主线任务为620等，通过分析崩溃发生时的主线任务占比，可以确定发生崩溃的主要任务是哪些。

如图7所示，图7用于表示崩溃发生时应用程序的运行时长。其中，710～790分别表示应用程序运行了40-50min、30-40min、60-70min、>＝100min、10-20min、50-60min、0-10min、70-100min以及20-30min的时长之后，发生了崩溃的比例，通过该饼状图，可以直观的得出崩溃和运行时长的关系。

在步骤S520中，从频繁项集中挖掘得到关键属性。

在本申请的一个实施例中，在得到频繁项集之后，根据属性信息的频繁项集，从中挖掘得到关键属性。具体的，本实施例中通过根据频繁项集中每个属性名称出现的概率，确定应用程序发生故障时对应的关键属性。

在本申请的一个实施例中，这里对于频繁项集的挖掘可以是利用了频繁模式增长算法，此算法首先确定最小支持度，然后主要包含三个步骤：第一遍遍历数据集，得到只包含一个项的支持度，删除小于最小支持度的项，再将原始数据集中每一条内的各项按照降序排序；第二遍扫描数据集，创建项头表从上往下降序，以及频繁模式树；对于每个项目找到其条件模式基，可以按照从下往上的顺序递归调用树结构，删除小于最小支持度的项。如果最终呈现单一路径的树结构，则直接列举所有组合；非单一路径的则继续调用树结构，直到形成单一路径即可，由此便可以得到关键属性。

请参阅图8所示，图8为本申请实施例提供的关键属性的示意图。其中，800用于表示在某次挖掘得到的某个故障的关键属性，其中810表示终端的应用系统，即发生故障的大部分系统为该应用系统，820表示应用程序的载体的型号，即某品牌的手机容易发生该类型的故障，830表示应用程序在开启0-10分钟之内容易发生该故障，840用于表示发生该故障时，用户还没有登录该应用程序。

在步骤S230中，根据操作指令序列，得到应用程序发生故障时对应的关键操作指令序列。

在本申请的一个实施例中，除了属性特征，故障还可能跟用户对应用程序的操作行为、应用程序的任务执行流程有关，需要特定的操作路径才能触发故障，此方案通过提取故障问题的所有用户的经分日志，提取出操作流，即操作指令序列。

请参阅图9所示，图9为本申请实施例提供的经分数据的列表。其中，910用于表示该故障对应的所有经分日志，在其中一个日志920中，包括了应用程序在运行过程中的每一时刻对应的操作指令序列。

通过基于上述经分日志中的操作指令序列，根据操作指令序列中各个操作指令之间的排序，从操作指令序列中挖掘出关键操作指令序列。

在本申请的一个实施例中，根据操作指令序列中各个操作指令之间的排序，进行序列模式挖掘获取复现的操作序列。这里对序列模式的挖掘主要利用了序列模式挖掘算法，该算法首先确定最小支持度，主要包含三个步骤：扫描数据库，找出所有长度为1的前缀和对应的投影数据库；对长度为1的前缀进行计数，将支持度低于最小支持度的前缀对应的项从数据集S删除，同时得到所有的频繁1项序列，i＝1；第三步对于每个长度为i并且满足支持度要求的前缀进行递归挖掘。其中，在第三步中，先找出前缀所对应的投影数据库。如果投影数据库为空，则递归返回；统计对应投影数据库中各项的支持度计数。如果所有项的支持度计数都低于阈值，则递归返回；将满足支持度计数的各个单项和当前的前缀进行合并，得到若干新的前缀；令i＝i+1，前缀为合并单项后的各个前缀，分别递归执行第3步。

为了解决序列模式挖掘算法在单条记录的长度比较长的时候执行效率是很低的情况，本实施中通过构建平台，此平台上集成了各种机器学习框架和工具,方便的使用各种算法。我们使用了平台上的挖掘组件pyspark来进行序列模式的挖掘，大大的提高了算法的执行效率。

如图10所示，图10是本申请实施例提供的挖掘组件的执行示例图。首先在挖掘组件1000中，先在工作列表1010中创建一个工作流；在组件区域1020中添加挖掘组件pyspark；在组件参数配置栏1030中，编写并上传脚本和数据集，其中组件参数中可以包括执行脚本的信息、资源参数以及配置参数等；在资源参数配置区域1040中，进行资源参数调优，最后通过运行组件1050运行，查看输出结果。

如图11所示，图11为本申请实施例提供的关键操作指令序列的示意图。本实施例中通过根据操作指令序列中各个操作指令之间的排序，从操作指令序列中挖掘出关键操作指令序列。示例性的，在应用程序为游戏的应用场景中，玩家对战玩家(Player VersusPlayer，PVP)为游戏的一种对战模式，图11中的两类日志是在终端玩家完成PVP玩法时进行的数据出入写入，该序列表示在崩溃前参与了三场PVP玩法。

在步骤S240中，基于关键属性和关键操作指令序列复现应用程序发生故障时的状态。

在本申请的一个实施例中，在确定了关键属性和关键操作指令序列之后，基于关键属性和关键操作指令序列复现应用程序发生故障时的状态，完全复原应用程序发生故障时候的情景。

在本申请的一个实施例中，如图12所示，步骤S240中基于关键属性和关键操作指令序列复现应用程序发生故障时的状态的过程，包括如下步骤S1210至步骤S1230，详细介绍如下：

在步骤S1210中，基于故障对应的关键属性，生成复现的属性列表。

在本申请的一个实施例中，在得到关键属性之后，便可以确定是由哪种因素导致了应用程序发生问题，因此，本实施例中基于故障对应的关键属性生成复现的属性列表，其中可以包括各种可能导致应用程序故障的原因。例如，手机型号、应用系统等，此处不做限定。

在步骤S1220中，基于故障对应的关键操作指令序列，生成复现的操作指令列表。

在本申请的一个实施例中，在得到关键操作指令序列之后，基于故障对应的关键操作指令序列，便可以确定出用户在应用程序的载体上操作该应用程序的过程中，进行了哪些一系列的操作使得应用程序发生故障。因此，可以通过关键操作指令序列生成复现的操作指令列表。

在步骤S1230中，根据属性列表和操作指令列表，复现应用程序发生故障时的状态。

在本申请的一个实施例中，在得到属性列表和操作指令列表之后，基于属性列表和操作指令列表，复现应用程序发生故障时的状态。

需要说明的是，本实施例中在对应用程序发生故障时的状态进行复现时，可以是只根据属性列表或者操作指令列表中的一个实现复现，也可以是综合属性列表和操作指令列表实现复现。在综合属性列表和操作指令列表实现复现的过程中，可以是先根据属性列表确定发生故障的关键属性，这些属性都是单一的没有关联的元素，在确定了关键属性之后，基于关键属性和操作指令列表中的操作序列实现复现。通过这种方式可以更加多元、全面的复现应用程序发生故障时候的状态，提高复现的准确性。

在本申请的一个实施例中，在步骤S1230之后，还可以包括步骤1231：根据故障对应的属性列表和操作指令列表生成故障的档案信息，并将档案信息存储至预设的故障数据库。

如下表所示，下表是本申请实施例提供的一种故障管理系统的示意表。基于表格中的信息，在本申请的一个实施例中，故障管理系统中可以包括各种故障发生时候的关键属性和操作指令序列，其中，环境表示应用程序的运行环境，即应用程序的载体的应用系统，故障标识用于区别各个故障，关键堆栈用于表示发生故障时对应的程序代码，通过故障管理系统链接可以跳转至故障对应的页面，描述中包括了故障的基本表现、特征以及场景等，此处不做限定，通过解决方案可以编辑或者查看该故障信息。

可选的，本实施例中的故障管理系统可以为故障系统Bugly，面向移动开发者提供专业的故障监控、崩溃分析等质量跟踪服务。Bugly能帮助移动互联网开发者更及时地发现掌控异常，更全面的了解定位异常，更高效的修复解决异常。

在上述步骤S1231中将档案信息存储至预设的故障数据库的过程执行完成之后，还可以包括如下步骤S1310至步骤S1320，详细介绍如下：

在步骤S1310中，获取客户端发送的故障查询标识。

在步骤S1320中，根据故障查询标识，在故障数据库中查找故障查询标识对应的属性列表和操作指令列表。

在步骤S1330中，将故障查询标识对应的属性列表和操作指令列表返回至客户端。

在整个崩溃问题复现的过程中，复现人员不需要再人工的去查找故障管理系统上的信息，以及单独的去分析玩家的日志，目前只需要输入故障管理系统上的故障查询标识，就能得到复现的属性列表以及操作列表，大大提高了复现的效率和概率，同时，可参考案例库问题对项目内问题进行排查，提早的发现和解决问题。

请参考图14所示，图14为本申请实施例提供的故障复现和管理的示意图。本实施例中的上述方案可以通过三大部分来执行，分别为Web前端1410、服务器后台1420以及数据处理端1430，且其所有的数据来源都来源与应用程序的载体1440。其中，应用程序的载体1440可以为终端、服务器等客户端，此处不做限定。在具体的应用过程中，先通过应用程序的载体1440将业务自定义数据Bugly数据上报至大数据故障处理平台TDW1411，将数据取回本地并进行数据拓展1480得到基准benchmark数据1412和开放式分类目录搜索系统(OpenDirectory Project，ODP)数据1413，再将数据返回进行数据处理1490，其中包括数据特征可视化、频繁项集挖掘以及序列模式的处理，将数据处理得到的结果返回至Web前台，进行图表渲染及数据展示1460。在故障处理系统中，当用户通过Web前台用户接口1450提出分析某个故障问题的需求时，通过后台的数据获取模块1470从大数据故障处理平台TDW1411中，进行数据库SQL拉取故障问题数据，从而得到故障问题相关的数据。

通过输入崩溃问题的标识，就能清楚的了解复现故障的特征以及复现推荐的操作序列，并且得到相关信息的可视化展示，节省了大量的信息整合的时间，同时这些信息也能够帮助开发同学来共同的定位问题。目前此崩溃问题的复现方案可以应用在多个游戏项目中，其中可以包括手游、网游或者虚拟交互游戏中，并且也成功的复现过一些复杂的崩溃问题。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的复现故障的方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的复现故障的方法的实施例。

图15示出了根据本申请的一个实施例的复现故障的装置的框图。

参照图15所示，根据本申请的一个实施例的复现故障的装置1500，包括：

获取单元1510，用于获取应用程序运行时的属性信息和操作指令序列；属性单元1520，用于对所述属性信息进行挖掘，得到所述应用程序发生故障时对应的关键属性；序列单元1530，用于根据所述操作指令序列，得到所述应用程序发生故障时对应的关键操作指令序列；复现单元1540，用于基于所述关键属性和所述关键操作指令序列复现所述应用程序发生故障时的状态。

在本申请的一些实施例中，基于前述方案，所述属性单元1520包括：构建单元，用于基于预设的属性列表和所述属性信息，构建属性信息的频繁项集；第一挖掘单元，用于从所述频繁项集中挖掘得到所述关键属性。

在本申请的一些实施例中，基于前述方案，所述第一挖掘单元配置为：根据所述频繁项集中每个属性名称出现的概率，确定所述应用程序发生故障时对应的关键属性。

在本申请的一些实施例中，基于前述方案，所述序列单元1530包括：根据所述操作指令序列中各个操作指令之间的排序，从所述操作指令序列中挖掘出所述关键操作指令序列。

在本申请的一些实施例中，基于前述方案，所述复现单元1540包括：第一复现单元，用于基于所述故障对应的所述关键属性，生成复现的属性列表；第二复现单元，用于基于所述故障对应的关键操作指令序列，生成复现的操作指令列表；第三复现单元，用于根据所述属性列表和所述操作指令列表，复现所述应用程序发生故障时的状态。

在本申请的一些实施例中，基于前述方案，所述复现故障的装置1500还包括：第一存储单元，用于根据所述故障对应的所述属性列表和所述操作指令列表生成所述故障的档案信息，并将所述档案信息存储至预设的故障数据库。

在本申请的一些实施例中，基于前述方案，所述复现故障的装置1500还包括：第一获取单元，用于获取客户端发送的故障查询标识；查询单元，用于根据所述故障查询标识，在所述故障数据库中查找所述故障查询标识对应的属性列表和操作指令列表；返回单元，用于将所述故障查询标识对应的属性列表和操作指令列表返回至所述客户端。

在本申请的一些实施例中，基于前述方案，所述获取单元1510包括：检测单元，用于检测所述应用程序发生故障的时刻；第二获取单元，用于根据所述时刻，获取所述应用程序的操作指令序列、业务属性信息以及所述应用程序的载体的运行属性信息。

在本申请的一些实施例中，基于前述方案，所述复现故障的装置1500还包括：记录单元，用于记录所述应用程序的载体运行所述应用程序时的操作指令；第二存储单元，用于将所述操作指令存储至预设的经分日志中。

图16示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图16示出的电子设备的计算机系统1600仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图16所示，计算机系统1600包括中央处理单元(Central Processing Unit，CPU)1601，其可以根据存储在只读存储器(Read-Only Memory，ROM)1602中的程序或者从存储部分1608加载到随机访问存储器(Random Access Memory，RAM)1603中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1603中，还存储有系统操作所需的各种程序和数据。CPU 1601、ROM 1602以及RAM 1603通过总线1604彼此相连。输入/输出(Input/Output，I/O)接口1605也连接至总线1604。

以下部件连接至I/O接口1605：包括键盘、鼠标等的输入部分1606；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1607；包括硬盘等的存储部分1608；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至I/O接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入存储部分1608。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被中央处理单元(CPU)1601执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

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

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (9)

1.一种复现故障的方法，其特征在于，包括：

获取应用程序运行时的属性信息和操作指令序列；

基于预设的属性列表和所述属性信息，构建属性信息的频繁项集，并根据所述频繁项集中每个属性名称出现的概率，确定所述应用程序发生故障时对应的关键属性；

根据所述操作指令序列中各个操作指令之间的排序，利用序列模式挖掘算法从所述操作指令序列中挖掘得到所述应用程序发生故障时对应的关键操作指令序列；

基于所述关键属性和所述关键操作指令序列复现所述应用程序发生故障时的状态；

其中，所述利用序列模式挖掘算法从所述操作指令序列中挖掘得到所述应用程序发生故障时对应的关键操作指令序列，包括：

扫描数据库，找出所有长度为1的前缀和对应的投影数据库；

对长度为1的前缀进行计数，将支持度低于最小支持度的前缀对应的项从数据集删除，同时得到所有的频繁1项序列；

对于每个长度为i并且满足支持度要求的前缀进行递归挖掘，以得到所述关键操作指令序列，其中，i为大于或等于1的整数。

2.根据权利要求1所述的方法，其特征在于，基于所述关键属性和所述关键操作指令序列复现所述应用程序发生故障时的状态，包括：

基于所述故障对应的所述关键属性，生成复现的属性列表；

基于所述故障对应的关键操作指令序列，生成复现的操作指令列表；

根据所述属性列表和所述操作指令列表，复现所述应用程序发生故障时的状态。

3.根据权利要求2所述的方法，其特征在于，基于所述故障对应的关键操作指令序列，生成复现的操作指令列表之后，还包括：

根据所述故障对应的所述属性列表和所述操作指令列表生成所述故障的档案信息，并将所述档案信息存储至预设的故障数据库。

4.根据权利要求3所述的方法，其特征在于，所述档案信息包括所述故障的故障标识，根据所述故障对应的所述属性列表和所述操作指令列表生成所述故障的档案信息之后，还包括：

获取客户端发送的故障查询标识；

根据所述故障查询标识，在所述故障数据库中查找所述故障查询标识对应的属性列表和操作指令列表；

将所述故障查询标识对应的属性列表和操作指令列表返回至所述客户端。

5.根据权利要求1所述的方法，其特征在于，获取应用程序运行时的属性信息和操作指令序列，包括：

检测所述应用程序发生故障的时刻；

根据所述时刻，获取所述应用程序的操作指令序列、业务属性信息以及所述应用程序的载体的运行属性信息。

6.根据权利要求1所述的方法，其特征在于，获取应用程序运行时的属性信息和操作指令序列之前，包括：

记录所述应用程序的载体运行所述应用程序时的操作指令；

将所述操作指令存储至预设的经分日志中。

7.一种复现故障的装置，其特征在于，包括：

获取单元，用于获取应用程序运行时的属性信息和操作指令序列；

属性单元，用于基于预设的属性列表和所述属性信息，构建属性信息的频繁项集，并根据所述频繁项集中每个属性名称出现的概率，确定所述应用程序发生故障时对应的关键属性；

序列单元，用于根据所述操作指令序列中各个操作指令之间的排序，利用序列模式挖掘算法从所述操作指令序列中挖掘得到所述应用程序发生故障时对应的关键操作指令序列；

复现单元，用于基于所述关键属性和所述关键操作指令序列复现所述应用程序发生故障时的状态；

其中，所述序列单元还用于执行如下步骤：

扫描数据库，找出所有长度为1的前缀和对应的投影数据库；

对长度为1的前缀进行计数，将支持度低于最小支持度的前缀对应的项从数据集删除，同时得到所有的频繁1项序列；

对于每个长度为i并且满足支持度要求的前缀进行递归挖掘，以得到所述关键操作指令序列，其中，i为大于或等于1的整数。

8.一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1-6中任一项所述的复现故障的方法。

9.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-6中任一项所述的复现故障的方法。