一种应用故障信息的修复方法、系统及设备与流程

本申请涉及应用程序开发技术领域，特别是涉及一种应用故障信息的修复方法、系统及设备。

背景技术：

随着社会科技的发展，越来越多的人使用移动设备，这样移动设备中各种各样的故障问题也就越来越多。目前，针对移动设备的问题，都是用户发现问题进行反馈，通过文字和截图等撰写问题，然后通过邮件或者应用内置的反馈功能向开发者反馈问题。开发者收到问题后，通过后台日志和用户的反馈进行对比分析，来猜测所遇到的问题，修复完成后交给测试，测试拿一些通用设备，这些设备在软硬件系统上都和用户发现问题的手机不完全一致。验证完成后在若干天后向线上所有用户推送修复版本。

但是，目前的修复方法存在如下问题：1、用户的问题描述和图片信息往往片面，缺少每一步的操作流程，如果开发商通过邮件和电话与用户进行一对一沟通，效率很低。2、问题修复后，出现问题的移动设备已经在后台修复现场消失，难以复现，无法确定问题是否能够得到修复。

技术实现要素：

有鉴于此，本申请提供了一种应用故障信息的修复方法、系统及设备。主要目的在于解决目前进行应用故障修复过程中，用户的问题描述和图片信息往往片面，用户与开发商的沟通效率较低，以及启动修复版本后现场难以复现，无法确定问题是否能够得到修复的技术问题。

依据本申请的第一方面，提供了一种应用故障信息的修复方法，所述方法包括：

所述本地终端设备接收到所述本地显示屏发送的故障反馈启动命令后，利用应用内的客户机器人根据所述故障信息形成相应的交互问题，并将所述交互问题发送至所述本地显示屏进行显示，其中，所述故障反馈启动命令是由用户在所述本地显示屏上触发，与所述故障信息一一对应；

所述本地终端设备接收到所述本地显示屏发送的与所述交互问题对应的回答内容后，将所述回答内容与设定回答内容进行比对，若比对成功，则将所述交互问题对应的故障信息作为有效故障信息，若比对失败，则将所述交互问题对应的故障信息作废删除；

所述本地终端设备将所述有效故障信息，以及与所述有效故障信息对应的交互问题和回答内容组合在一起作为有效故障包，发送至开发者终端设备；

所述开发者终端设备将所述有效故障包对应的修复安装包发送至所述本地终端设备；

所述本地终端设备安装所述修复安装包，对所述应用的故障进行修复。

依据本申请的第二方面，提供了一种应用故障信息的修复系统，所述系统包括：

本地终端设备，用于当应用出现故障时，将故障信息发送至本地显示屏进行显示；

所述本地终端设备，还用于接收到所述本地显示屏发送的故障反馈启动命令后，利用应用内的客户机器人根据所述故障信息形成相应的交互问题，并将所述交互问题发送至所述本地显示屏进行显示，其中，所述故障反馈启动命令是由用户在所述本地显示屏上触发，与所述故障信息一一对应；

所述本地终端设备，还用于接收到所述本地显示屏发送的与所述交互问题对应的回答内容后，将所述回答内容与设定回答内容进行比对，若比对成功，则将所述交互问题对应的故障信息作为有效故障信息，若比对失败，则将所述交互问题对应的故障信息作废删除；

所述本地终端设备，还用于将所述有效故障信息，以及与所述有效故障信息对应的交互问题和回答内容组合在一起作为有效故障包，发送至开发者终端设备；

所述开发者终端设备，用于将所述有效故障包对应的修复安装包发送至所述本地终端设备；

所述本地终端设备，还用于安装所述修复安装包，对所述应用的故障进行修复。。

依据本申请的第三方面，提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现第一方面所述应用故障信息的修复方法的步骤。

依据本申请的第四方面，提供了一种计算机存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述应用故障信息的修复的步骤。

借由上述技术方案，本申请提供的一种应用故障信息的修复方法、系统和设备，能够在应用出现故障时，将故障信息在本地显示屏上显示提示用户，让用户触发故障反馈按钮，使得本地终端设备接收到本地显示屏发送的故障反馈启动命令，并启动应用内的客户机器人将相应的交互问题发送到本地显示屏上让用户回答，然后再把用户回答的回答内容与设定回答内容进行比对，将符合设定回答内容的故障信息作为有效故障信息，与对应的交互问题和用户回答的回答内容组合打包成有效故障包，发送给开发者终端设备，让开发者根据有效故障包研发出能够修复应用的修复安装包，并发送给本地终端设备进行安装，完成对应用的故障进行修复的过程。这样本地终端设备能够对故障信息进行筛选，将一些无效的故障信息过滤出去，保证发送至开发者终端设备的故障信息都是有效的故障信息，避免了一些用户利用无效的故障信息干扰开发者的情况，同时提高了开发者对应用进行修复的效率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本申请的应用故障信息的修复方法的一个实施例的流程图；

图2为本申请的应用故障信息的修复系统的一个实施例的结构框图；

图3为本申请的计算机设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本申请实施例提供了一种应用故障信息的修复方法，当本地终端设备的应用出现故障时，可以根据客户机器人与用户的交互问题的对答筛选出符合要求的故障信息，发送给开发者终端设备，以供开发者根据发来的故障信息进行研发，对应用的故障进行修复。这样能够保证发送至开发者终端设备的故障信息都是有效的故障信息，避免了一些用户利用无效的故障信息干扰开发者的情况，同时提高了开发者对应用进行修复的效率。

如图1所示，本申请实施例提供了一种应用故障信息的修复方法，包括如下步骤：

步骤101，本地终端设备当应用出现故障时，将故障信息发送至本地显示屏进行显示，其中，本地显示屏为设置在本地终端设备上的显示屏。

在该步骤中，当用户在本地终端设备(例如，手机、平板、笔记本、台式电脑等)上使用a应用时，或者本地终端设备的a应用在自主运行时，出现了故障，该故障可能是：应用某项功能无法完成、应用无法打开、应用出现闪退的情况等，将这些故障作为故障信息发送至本地终端设备的本地显示屏，来提示用户该应用出现了故障，需要进行处理。

另外，在将故障信息发送至本地显示屏的同时，还可以获取用户的联系方式(例如手机号、微信号、qq号、邮箱等)，通过这些联系方式告知用户本地终端设备的应用出现了故障，以防用户未在本地终端设备附近无法查看本地显示屏上显示的故障信息，造成故障延误的情况。

步骤102，本地终端设备接收到本地显示屏发送的故障反馈启动命令后，利用应用内的客户机器人根据故障信息形成相应的交互问题，并将交互问题发送至本地显示屏进行显示，其中，故障反馈启动命令是由用户在本地显示屏上触发，与故障信息一一对应。

在该步骤中，用户获知应用出现故障后，就会触发本地显示屏上的故障反馈按钮，本地显示屏就会形成故障反馈启动命令发送至本地终端设备的控制器，控制器触发应用内的客户机器人根据该故障信息形成相应的交互问题，发送至本地显示屏显示给用户。

其中，客户机器人中预先针对每种故障信息都有一一对应的交互问题，并保存在客户机器人内。例如，针对应用某项功能无法完成的故障信息，则客户机器人对应的交互问题就是：出现该故障的操作流程是怎么样？需要用户描述回答。

步骤103，本地终端设备接收到本地显示屏发送的与交互问题对应的回答内容后，将回答内容与设定回答内容进行比对，若比对成功，则将故障信息作为有效故障信息，若比对失败，则将故障信息作废删除。

在该步骤中，用户在本地显示屏上看到客户机器人发来的交互问题后，根据应用故障的实际情况进行回答，回答的内容可以是文字、图片、视频或者录音中的一种或者多种。本地显示屏将用户的回答内容发送至控制器，控制器调取保存在应用中与该故障信息对应的设定回答内容，与回答内容进行比对，若回答内容符合设定回答内容的要求，则比对成功，否则比对失败。

其中，在应用中会保存针对每个交互问题对应的设定回答内容，例如，针对“该故障是否能够复现？”这个问题的设定回答内容是“能够复现”，如果用户回答的是“能够复现”，则将该故障信息作为有效故障信息。如果用户回答的是“不复现”则该故障可能是由于手机系统卡顿或者过热死机出现的故障，只需重启手机即可，无需修复，直接将该故障信息作废删除即可。

步骤104，本地终端设备将有效故障信息，以及与有效故障信息对应的交互问题和回答内容组合在一起作为有效故障包，发送至开发者终端设备。

在该步骤中，为了让开发者能够更加全面的了解应用出现的故障，将有效故障信息、交互问题和该交互问题的回答内容，进行打包组合成有效故障包，并在发送给开发者终端设备的同时，在本地终端设备上也进行备份，当开发者终端设备接收到该有效故障包后，会给本地终端设备一个反馈信息，如果本地终端设备在规定时间(例如，5分钟)内没有收到该反馈信息，就会将备份的有效故障包再次发送给开发者终端设备，直至能够接收到反馈信息为止。

步骤105，开发者终端设备将有效故障包对应的修复安装包发送至本地终端设备。

在该步骤中，开发者中设备接收到有效故障包后，就会发出警示信息，该警示信息可以是灯光闪动提示、声音提示、震动提示、本地显示屏图像显示提示中的一种或多种。开发者看到提示后，就会打开该有效故障包，根据有效故障包中的内容为应用研发对应的修复程序，并对修复程序进行测试、漏洞修复等。将测试通过没有漏洞的修复程序进行打包，形成能够该应用的故障进行修复的的修复安装包。并将该修复安装包发送到出现应用故障的本地终端设备上。

步骤106，本地终端设备安装修复安装包，对应用的故障进行修复。

本地终端设备接收到修复安装包后，可以自动安装该修复安装包对应用进行故障修复，也可以是接收到修复安装包后在本地显示屏显示“是否安装修复安装包”的提示，用户可以根据提示进行选择，当用户确认后再安装该修复安装包。

通过上述技术方案，能够在应用出现故障时，将故障信息在本地显示屏上显示提示用户，让用户触发故障反馈按钮，使得本地终端设备接收到本地显示屏发送的故障反馈启动命令，并启动应用内的客户机器人将相应的交互问题发送到本地显示屏上让用户回答，然后再把用户回答的回答内容与设定回答内容进行比对，将符合设定回答内容的故障信息作为有效故障信息，与对应的交互问题和用户回答的回答内容组合打包成有效故障包，发送给开发者终端设备，让开发者根据有效故障包研发出能够修复应用的修复安装包，并发送给本地终端设备进行安装，完成对应用的故障进行修复的过程。这样本地终端设备能够对故障信息进行筛选，将一些无效的故障信息过滤出去，保证发送至开发者终端设备的故障信息都是有效的故障信息，避免了一些用户利用无效的故障信息干扰开发者的情况，同时提高了开发者对应用进行修复的效率。

在具体实施例中，当开发者终端设备接收到多个有效故障包时，步骤105具体包括：

步骤1051，开发者终端设备将多个有效故障包依次发送至开发者显示屏上进行显示，其中，开发者显示屏为设置在开发者终端设备上的显示屏。

在该步骤中，开发者终端设备有时会在一定时间(例如，1小时)内接收到由多个本地终端设备发来的多个有效故障包，这些有效故障包有的是针对同一个故障发送的，因此开发者终端设备，会将属于同一个故障的有效故障包进行汇总，并按照有效故障包的发送时间对各个不同故障的有效故障包进行排序。按照这个顺序依次发送至开发者显示屏，以供开发者查看。

步骤1052，开发者终端设备判断是否接收到开发者显示屏发来的将有效故障包作为待修复故障包的命令，是则，将有效故障包确定为待修复故障包，否则，将有效故障包作废删除。

在该步骤中，开发者看完一个有效故障包后，根据该有效故障包中的内容，判断该有效故障包是否是需要进行修复的待修复故障包，如果是，则触发开发者显示屏上的“添加至待修复故障包库”的按钮，开发者显示屏就会形成将有效故障包作为待修复故障包的命令，并将该命令发送至开发者终端设备的控制器，控制器就会将该有效故障包作为待修复故障包，并保存至待修复故障包库中。如果不是，则直接将该有效故障包舍弃。

然后，开发者触发开发者显示屏上查看下一个的按钮，将下一个有效故障包的内容显示给开发者，以供开发者按照上述方案进行筛选。

步骤1053，开发者终端设备将待修复故障包对应的修复安装包发送至本地终端设备，其中，修复安装包是开发者根据待修复故障包研发出来对应用的故障进行修复的安装包。

在该步骤中，开发者将筛选出来的保存在待修复故障包库中的待修复故障包进行一一对应的研发，研发出各个待修复故障包对应的修复安装包，然后将修复安装包发送至对应的一个或多个本地终端设备上，以供本地终端设备进行安装和应用修复。

通过开发者对接收到的有效故障包的进一步筛选，避免了一些无需修复程序即可对应用进行修复的有效故障包的干扰，还能提高开发者研发修复安装包的效率，保证修复安装包的修复质量。

在具体实施例中，本地终端设备将有效故障包发送至开发者终端设备的同时，将应用当前的所有数据信息，以及应用出现故障时的操作进行备份，其中，数据信息：为应用出现故障时，用户向应用输入的数据，应用出现故障时的操作：为应用出现故障时，用户在使用应用时的操作流程。

这样，在后续步骤中应用被修复之后，可以利用数据信息和应用出现故障时的操作，对应用的修复情况进行判断。

例如，用户利用视频播放软件(即，应用)搜索a电视剧时出现故障，此时就会将用户在搜索窗口输入的a电视剧的名称(即，数据信息)进行备份，还会将视频播放软件出现故障时的操作，即“用户打开电视剧页面→触发搜索窗口→输入电视剧名称→触发搜索命令”，进行备份。以供在视频播放软件被修复之后使用这些数据信息和操作重复当初出现故障的过程，对视频播放软件的修复情况进行判断。

则步骤106具体包括：

步骤1061，本地终端设备安装修复安装包，并启动备份中应用的所有数据信息，重复应用出现故障时的操作。

步骤1062，本地终端设备判断应用的故障是否修复成功，若修复成功，则本地终端设备将修复成功信息发送至开发者终端设备，若修复未成功，则本地终端设备将修复之后的故障信息、修复之后的应用的现场信息以及本地终端设备用户的联系方式，发送至开发者终端设备。

在上述方案中，本地终端设备接收到修复安装包后，会在本地显示屏提示用户是否安装该修复安装包，如果用户选择不安装，则自动将修复安装包删除或者放置在垃圾文件夹中。如果用户选择安装，就会在本地显示屏上出现一个窗口，询问用户是否将出现故障时的数据启动。当用户选择是时，则安装修复安装包将启动备份中应用的所有数据信息，并将保存的应用出现故障时的操作进行自动重复，判断该应用是否修复成功。当用户选择否时，则直接将修复安装包进行安装，用户可以自己手动启动应用，并对应用进行操作，判断修复是否成功。

为了让开发者获知应用的修复情况，当修复成功后，将修复成功信息发送至开发者终端设备，告知开发者。若修复没有成功，则将修复之后的故障信息、修复之后的应用的现场信息以及本地终端设备用户的联系方式，发送至开发者终端设备，以供开发者根据这些数据重新研发新的修复安装包。或者直接利用联系方式与用户进行直接沟通，沟通完后再重新研发新的修复安装包。以保证应用故障能够得到有效的修复。

在具体实施例中，步骤1061具体包括：

步骤10611，本地终端设备安装修复安装包，并启动备份中应用的所有数据信息。

步骤10612，本地终端设备将应用出现故障时的操作重复n次，得到对应的n个数据结果，n≥1。

步骤10613，本地终端设备将n个数据结果分别与故障修复成功后的数据进行比对，筛选出m个与故障修复成功后的数据相匹配的数据结果，其中m≤n。

则步骤1062具体包括：

本地终端设备判断m是否大于等于设定阈值，若大于等于设定阈值，则修复成功，本地终端设备将修复成功信息发送至开发者终端设备，若小于设定阈值修复未成功，则本地终端设备将修复之后的故障信息、修复之后的应用的现场信息以及本地终端设备用户的联系方式，发送至开发者终端设备。

在上述步骤中，安装完修复安装包后，为了确定应用的故障是否完全得到修复，需要在应用出现故障的数据信息下，重复n次出现故障时的操作，如果这n次操作中有m次修复成功，并且该m大于等于设定阈值，则证明修复成功，否则修复失败，需要将最后一次重复操作得到修复之后的故障信息、修复之后的应用的现场信息以及本地终端设备用户的联系方式，发送至开发者终端设备。

例如，设定阈值为n，则需要得到的m＝n次修复成功的记录，即重复的这n次操作要全部没有故障出现，才算修复成功。

通过上述方案，重复多次应用出现故障时的操作，能够保证故障修复的准确性，避免了应用无法通过多次重复操作的情况。

在具体实施例中，步骤101具体包括：本地终端设备当应用出现故障时，将故障信息发送至本地显示屏进行显示，同时，利用守护进程将应用的现场信息进行保存，其中，守护进程在应用安装时自动生成，能够对应用进行实时监控，现场信息：本地终端设备的型号、应用的版本号、执行操作时调用的数据和执行操作后得到的数据结果。

则步骤104具体包括：本地终端设备将有效故障信息，以及与有效故障信息对应的现场信息、交互问题和回答内容组合在一起作为有效故障包，发送至开发者终端设备。

在上述技术方案中，应用的安装包中携带一个守护进程的安装包，如果该应用安装包启动安装，就会触发守护进程的安装包启动，该守护进程起到守护应用的作用，能够实时对应用的操作进行监控，守护进程一旦发现应用的某个数据或者功能出现故障就会将应用的现场信息进行保存。其中，现场信息包含本地移动设备信息、故障的关键操作步骤、后台交互数据等。

这样当将故障信息作为有效故障信息发送至开发者终端时，可以将保存的现场信息一并发出去，以供开发者根据现场信息快速准确的确定出故障发生的原因，进而加快研发修复安装包的进度，避免应用故障时间太长，给用户带来损失。

在具体实施例中，在步骤106之后，还包括：

步骤107，本地终端设备利用守护进程实时监控修复之后的应用，并实时保存修复之后的应用运行的数据。

步骤108，本地终端设备每间隔预定时间将修复之后的应用运行的数据发送至开发者终端设备，以供开发者根据修复之后的应用运行的数据确定应用的修复情况。

步骤109，本地终端设备累计修复之后的应用运行的数据的发送次数，当发送次数达到预定发送次数之后，终止修复之后的应用运行的数据的发送。

在上述技术方案中，为了确保应用故障得到完全的修复，还会利用守护每间隔预定时间(例如，一天)，就将应用运行的数据发送到开发者终端设备上，以供开发者根据这些运行数据判断该应用的故障修复情况。守护进程发送预定发送次数之后，如果开发者没有发现应用运行异常，则终止运行的数据的发送。如果开发者发现应用运行异常，则根据应用运行的数据，再次研发对应的修复安装包，并发送给本地终端设备进行安装。然后再利用上述过程对修复后的应用进行监控，直至确认应用的故障得到完全修复。

其中，运行数据包括：应用的每个操作步骤、每个操作步骤调用的数据、每个操作步骤完成后的数据等。

在具体实施例中，步骤102具体包括：

步骤1021，本地终端设备接收到本地显示屏发送的故障反馈启动命令后，利用应用内的客户机器人根据故障信息形成相应的多个交互问题。

步骤1022，本地终端设备将第一个交互问题发送至本地显示屏，当接收到本地显示屏发来的第一个交互问题的第一个回答内容后，再将第二个交互问题发送至本地显示屏，直至多个交互问题全部接收到与每个交互问题一一对应的回答内容。

则步骤103具体包括：

步骤1031，本地终端设备将接收到的本地显示屏发送的与多个交互问题对应的多个回答内容进行汇总。

步骤1032，将多个回答内容中的每个回答内容与对应的设定回答内容进行一一比对，若比对成功的数量大于等于设定回答阈值，则将多个交互问题对应的故障信息作为有效故障信息，若比对成功的数量小于设定回答阈值，则将多个交互问题对应的故障信息作废删除。

在上述技术方案中，当故障信息对应的交互问题有多个时，需要用户与客户机器人针对每个交互问题进行交流，并且每组交互问题都有对应的顺序，用户只有回答完当前的交互问题后才会出现下一个交互问题，这样避免用户对这多个交互问题混淆，出现胡乱回答的情况。另外，也可以将这多个交互问题同时显示在本地显示屏上以供用户作答。

然后本地终端将这多个交互问题以及对应用户回答的回答内容汇总到一起，并按照回答的顺序将用户回答的回答内容依次与设定回答内容进行比对，并统计比对成功的数量，当统计的数量大于等于设定回答阈值(例如，3个)，则确定该故障信息为有效故障信息，否则将该故障信息舍弃。其中设定回答阈值小于等于交互问题的总数。

通过上述实施例的应用故障信息的修复方法，能够在应用出现故障时，将故障信息在本地显示屏上显示提示用户，让用户触发故障反馈按钮，使得本地终端设备接收到本地显示屏发送的故障反馈启动命令，并启动应用内的客户机器人将相应的交互问题发送到本地显示屏上让用户回答，然后再把用户回答的回答内容与设定回答内容进行比对，将符合设定回答内容的故障信息作为有效故障信息，与对应的交互问题和用户回答的回答内容组合打包成有效故障包，发送给开发者终端设备，让开发者根据有效故障包研发出能够修复应用的修复安装包，并发送给本地终端设备进行安装，完成对应用的故障进行修复的过程。这样本地终端设备能够对故障信息进行筛选，将一些无效的故障信息过滤出去，保证发送至开发者终端设备的故障信息都是有效的故障信息，避免了一些用户利用无效的故障信息干扰开发者的情况，同时提高了开发者对应用进行修复的效率。

在本申请的另一个实施例的应用故障信息的修复方法中，包括如下步骤：

一、利用守护进程实时监控应用的故障信息

用户在移动设备上下载安装android应用，该应用安装包中包含相应守护进程的安装程序，当用户启动该应用后，会触发守护进程的安装程序，在对应应用的后台生成一个守护进程(service)，该守护进程能够实时监控该应用的用户操作或网络数据的交互。

如果应用发生异常问题或者崩溃(crash)，守护进程会自动保存应用对应故障的现场信息，包含移动设备信息、故障的关键操作步骤、后台数据交互等。

并将该应用的故障反馈给用户。

二、用户接收到故障反馈后，手动上传应用的故障信息。移动设备还会对所有上传的故障信息进行筛选，确认出需要开发者进行修复的待修复故障信息。

确认过程如下：

1、当用户接收到守护进程发来的故障反馈之后，点击页面中故障反馈的入口(通常发生在用户操作流程无法进行，或者用户发现错误的数据处理结果的时候)，在反馈的入口输入相应故障信息。

2、触发应用内的客户机器人功能，客户机器人通过语音或者文字针对用户输入的故障通过语音、图片或者视频的形式与用户进行简单的问题交互。若用户不与客户机器人进行交互，说明用户手动反馈的故障不成立。

例如：机器人问：该故障是否能够复现？用户对应进行回答。

机器人问：该故障的复现操作流程是怎么样？需要用户描述回答。

机器人问：该故障是否影响了用户的正常操作导致流程无法正常进行？用户对应进行回答。

机器人问：是否导致各项信息数据(包括用户个人信息，借还款等资金信息等)错误？用户对应进行回答。

3、弹出问题是否提交的界面，用户可以根据自己的情况选择是否提交该交互问题。

4、将所有提交的交互问题的内容汇总，并根据用户的回答对这些交互问题的内容进行筛选，将用户回答符合要求的故障信息作为有效故障信息。

例如，根据上述用户回答的内容，将能够稳定复现至少一次(尤其是重启app或者更换手机后依然无法解决)，或者影响了用户的正常操作导致流程无法正常进行，或者导致各项信息数据错误，将该交互问题的内容对应故障信息作为有效故障信息。

5、将有效故障信息、交互问题以及守护进行保存的现场信息，都返回到开发者进行进一步的筛选确认。将开发者确认后的故障信息作为待修复故障信息。

三、对待修复故障信息进行修复

开发者针对需要修复的故障信息进行研发得出相应的修复版本，并将修复版本通过服务器推送至出现该故障的一台或多台移动设备的应用上，对应用进行修复，并提示用户使用发现故障时一模一样的操作流程和操作条件(如网络，系统，用户订单等数据)，对修复后的应用进行操作，利用守护进程对用户的操作进行监控，并让用户重复多次。

将用户多次操作的监控结果和之前的监控结果对比(若对比结果相同或者还是不符合用户的要求，证明故障复现)，如果多次操作后故障复现的比例大于等于预定比例，那问题就是需要进一步修复，服务器就会将开发者的电话或者邮箱地址推送给用户。用户可以选择重复上述流程，并提供与该待修复故障更多相关的信息再次反馈给开发者，让开发者进行再次研发修复，或者也可以选择直接和开发者进行交互详细反馈应用的故障，让开发者针对与用户交互后的详细故障信息进行进一步的研发修复。

如果多次操作后故障复现的比例小于预定比例，证明故障已经修复成功，并将修复成功的信息反馈给开发者。

综上所述，本方案无需用户与开发者直接进行交互，移动终端能够对故障信息进行筛选，将一些无效的故障信息过滤出去，保证发送给开发者的故障信息都是有效的故障信息，避免了一些用户利用无效的故障信息干扰开发者的情况，同时提高了开发者对应用进行修复的效率。并且本方案还会对修复版本后的现场进行复现，保证应用修复的质量。

进一步的，作为图1方法的具体实现，本申请实施例提供了一种应用故障信息的修复系统，如图2所示，系统包括：本地终端设备21和开发者终端设备22。

本地终端设备21，用于当应用出现故障时，将故障信息发送至本地显示屏进行显示；

本地终端设备21，还用于接收到本地显示屏发送的故障反馈启动命令后，利用应用内的客户机器人根据故障信息形成相应的交互问题，并将交互问题发送至本地显示屏进行显示，其中，故障反馈启动命令是由用户在本地显示屏上触发，与故障信息一一对应；

本地终端设备21，还用于接收到本地显示屏发送的与交互问题对应的回答内容后，将回答内容与设定回答内容进行比对，若比对成功，则将故障信息作为有效故障信息，若比对失败，则将故障信息作废删除；

本地终端设备21，还用于将有效故障信息，以及与有效故障信息对应的交互问题和回答内容组合在一起作为有效故障包，发送至开发者终端设备22；

开发者终端设备22，用于将有效故障包对应的修复安装包发送至本地终端设备21；

本地终端设备21，还用于安装修复安装包，对应用的故障进行修复。

在具体实施例中，当开发者终端设备22接收到多个有效故障包时，开发者终端设备22将有效故障包对应的修复安装包发送至本地终端设备21，具体包括：

开发者终端设备22将多个有效故障包依次发送至开发者显示屏上进行显示；

开发者终端设备22判断是否接收到开发者显示屏发来的将有效故障包作为待修复故障包的命令，是则，将有效故障包确定为待修复故障包，否则，将有效故障包作废删除；

开发者终端设备22将待修复故障包对应的修复安装包发送至本地终端设备21，其中，修复安装包是开发者根据待修复故障包研发出来对应用的故障进行修复的安装包。

在具体实施例中，本地终端设备21，还用于将有效故障包发送至开发者终端设备22的同时，将应用当前的所有数据信息，以及应用出现故障时的操作进行备份，其中，所述数据信息：为所述应用出现故障时，用户向所述应用输入的数据，所述应用出现故障时的操作：为所述应用出现故障时，用户在使用所述应用时的操作流程；

则本地终端设备21安装修复安装包，对应用的故障进行修复，具体包括：

本地终端设备21安装修复安装包，并启动备份中应用的所有数据信息，重复应用出现故障时的操作；

本地终端设备21判断应用的故障是否修复成功，若修复成功，则本地终端设备21将修复成功信息发送至开发者终端设备22，若修复未成功，则本地终端设备21将修复之后的故障信息、修复之后的应用的现场信息以及本地终端设备21用户的联系方式，发送至开发者终端设备22。

在具体实施例中，本地终端设备21，还用于安装修复安装包，并启动备份中应用的所有数据信息；

本地终端设备21，还用于将应用出现故障时的操作重复n次，得到对应的n个数据结果，n≥1；

本地终端设备21，还用于将n个数据结果分别与故障修复成功后的数据进行比对，筛选出m个与故障修复成功后的数据相匹配的数据结果，其中m≤n；

则本地终端设备21，还用于判断m是否大于等于设定阈值，若大于等于设定阈值，则修复成功，本地终端设备21将修复成功信息发送至开发者终端设备22，若小于设定阈值修复未成功，则本地终端设备21将修复之后的故障信息、修复之后的应用的现场信息以及本地终端设备21用户的联系方式，发送至开发者终端设备22。

在具体实施例中，本地终端设备21，还用于当应用出现故障时，将故障信息发送至本地显示屏进行显示，同时，利用守护进程将应用的现场信息进行保存，其中，守护进程在应用安装时自动生成，能够对应用进行实时监控，现场信息包括：本地终端设备的型号、应用的版本号、执行操作时调用的数据和执行操作后得到的数据结果；

本地终端设备21，还用于将有效故障信息，以及与有效故障信息对应的现场信息、交互问题和回答内容组合在一起作为有效故障包，发送至开发者终端设备22。

在具体实施例中，本地终端设备21，还用于利用守护进程实时监控修复之后的应用，并实时保存修复之后的应用运行的数据；

本地终端设备21，还用于每间隔预定时间将修复之后的应用运行的数据发送至开发者终端设备22，以供开发者根据修复之后的应用运行的数据确定应用的修复情况；

本地终端设备21，还用于累计修复之后的应用运行的数据的发送次数，当发送次数达到预定发送次数之后，终止修复之后的应用运行的数据的发送。

在具体实施例中，本地终端设备21，还用于接收到本地显示屏发送的故障反馈启动命令后，利用应用内的客户机器人根据故障信息形成相应的多个交互问题；

本地终端设备21，还用于将第一个交互问题发送至本地显示屏，当接收到本地显示屏发来的第一个交互问题的第一个回答内容后，再将第二个交互问题发送至本地显示屏，直至多个交互问题全部接收到与每个交互问题一一对应的回答内容；

本地终端设备21，还用于将接收到的本地显示屏发送的与多个交互问题对应的多个回答内容进行汇总；将多个回答内容中的每个回答内容与对应的设定回答内容进行一一比对，若比对成功的数量大于等于设定回答阈值，则将多个交互问题对应的故障信息作为有效故障信息，若比对成功的数量小于设定回答阈值，则将多个交互问题对应的故障信息作废删除。

基于上述图1所示方法和图2所示系统的实施例，为了实现上述目的，本申请实施例还提供了一种计算机设备，如图3所示，包括存储器32和处理器31，其中存储器32和处理器31均设置在总线33上存储器32存储有计算机程序，处理器31执行计算机程序时实现图1所示的应用故障信息的修复方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储器(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

可选地，该设备还可以连接用户接口、网络接口、摄像头、射频(radiofrequency，rf)电路，传感器、音频电路、wi-fi模块等等。用户接口可以包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如蓝牙接口、wi-fi接口)等。

本领域技术人员可以理解，本实施例提供的一种计算机设备的结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

基于上述如图1所示方法和图2所示系统的实施例，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1所示的应用故障信息的修复方法。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理计算机设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与计算机设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。

通过应用本申请的技术方案，能够在应用出现故障时，将故障信息在本地显示屏上显示提示用户，让用户触发故障反馈按钮，使得本地终端设备接收到本地显示屏发送的故障反馈启动命令，并启动应用内的客户机器人将相应的交互问题发送到本地显示屏上让用户回答，然后再把用户回答的回答内容与设定回答内容进行比对，将符合设定回答内容的故障信息作为有效故障信息，与对应的交互问题和用户回答的回答内容组合打包成有效故障包，发送给开发者终端设备，让开发者根据有效故障包研发出能够修复应用的修复安装包，并发送给本地终端设备进行安装，完成对应用的故障进行修复的过程。这样本地终端设备能够对故障信息进行筛选，将一些无效的故障信息过滤出去，保证发送至开发者终端设备的故障信息都是有效的故障信息，避免了一些用户利用无效的故障信息干扰开发者的情况，同时提高了开发者对应用进行修复的效率。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。