本发明涉及计算机领域，尤其涉及一种iOS(iphone Operation System)崩溃数据分类与统计的方法和装置。
背景技术：
目前运行在iOS系统上的app，在崩溃发生后(俗称“应用闪退”)通常会将崩溃发生时的堆栈信息、设备信息等上报到服务器，有些是通过apple的官方崩溃收集来完成，而更多的app是选择使用友盟、腾讯Bugly等第三方崩溃收集分析商来收集数据。
但是，当收到海量的崩溃数据后(假定一条崩溃数据单独的放置在一个文本文件中)，如何对这些崩溃文件进行分类，如何有效地界定哪些崩溃文件是属于同一个bug(在系统或程序中，隐藏着的一些未被发现的缺陷或问题，是引发崩溃的原因)导致的，如何对这些崩溃文件进行统计分析，以此来更好地提升app的稳定性，这些一直是业界的难题，这也是本发明需要解决的主要问题。
在上传的崩溃信息中，第三方崩溃SDK、大公司自己开发的崩溃收集SDK以及苹果自带的崩溃收集采集的内容差异很大，但都具备以下数据：崩溃发生时间、app版本和build号、系统版本、设备类型、启动时间、错误类型、崩溃线程调用栈信息等。本发明为了追求通用性，也仅将原始数据限定为以上几项内容。
目前大多现有技术只是简单的根据崩溃线程调用栈顶层的语句匹配或者是崩溃栈完全匹配作为崩溃分类的依据。并没有一套系统化的完整方案来实现精确分类。具体地：
首先，获取大量崩溃日志，每次的崩溃日志都是一个文件。
然后，使用Symbolicatecrash对所有的崩溃日志进行调用栈符号化。
接下来，对这些崩溃文件进行分类操作。
最后，直接提取调用栈栈顶的调用语句做比较，如果栈顶函数调用语句一致的，那么就归类为同类崩溃。
由于栈顶调用语句，是程序最后执行的地方，也是崩溃发生的语句，所以，直接根据栈顶语句对崩溃进行了粗浅的分类。
在实现本发明过程中，发明人发现现有技术中至少存在如下问题：
由于现有技术方案直接依据栈顶调用语句对崩溃做分类，这会导致有些情况下崩溃原因定位不准，因为崩溃不一定是由于调用栈顶层代码引起的，而是有由中间的某一句调用触发的，我们真正需要定位的是那一句引发崩溃的调用。比如说，程序中有一个abort()语句，表示在开发者要主动抛出异常，终止应用，这种语句在系统库中比较常用，在调用系统函数时，发现调用有误或者参数不对，那么系统就有可能会调用该语句，终止应用，此时，调用栈栈顶语句就是abort()。但是，这种崩溃，究其原因，是错误的调用了系统函数导致的，比如参数错误、环境配置有误等，那么应该把崩溃原因定位到调用系统函数的那一条语句上，而不是abort()这条语句，这样做的原因是，第一，系统函数是不可控的，如果发生异常，则只能通过修改自己的调用方式或者替换掉调用语句来修复崩溃；第二，很多系统函数最后都会调用abort()来终止应用，而触发它们的原因是由于调用方式有误/参数配置有误导致的，应该要找的是触发abort()的真实原因，而不是abort()这一条触发崩溃的语句。
现有方案的分类，会导致同一个崩溃下，隐藏有多个真实的崩溃原因，分类不够彻底。就如刚才所说，一个abort()终止语句，有很多种原因可以导致应用最后调用abort()，应该对导致调用abort()的原因进行分类，而不是针对这一条语句。
技术实现要素：
有鉴于此，本发明实施例提供一种用于iOS崩溃数据分类与统计的方法、装置、电子设备和可读存储介质。能够对崩溃原因的定位更加准确，直接定位到程序引发崩溃的本质原因，而不是触发崩溃的语句而已。能够对崩溃的分类尽可能做到彻底，分类更加清晰，确保一类崩溃分类下面不会隐藏有多个崩溃原因；并且能够输出一份整洁易读的报告，方便发现问题，以及可以结合上一版的报告，给出同一种崩溃的变化趋势，验证修复成果。
为实现上述目的，根据本发明实施例的一个方面，提供了一种用于iOS崩溃数据分类与统计的方法，该方法包括：对崩溃数据进行自动化分类，采用对调用栈逆向查找方式，提取整个调用栈中的属于应用程序的调用语句，输出初步分类报表；通过编写的配置文件，不断地对未被分类的崩溃数据进行迭代分类，并在每一次迭代后输出递归分类报表；以及将初步分类报表和递归分类报表进行整合，并且结合上一次崩溃分析的最终报告来输出本次崩溃分析的最终报告。
优选地，该方法还包括：提取所述调用语句的类名、函数名、以及文件函数作为崩溃原因的描述，制作崩溃原因与存放文件夹的映射表，并将同一崩溃原因的崩溃数据放到同一个文件夹。
优选地，该方法还包括：读入所述编写的配置文件之后，将所述编写的配置文件转化为对象，将每一个匹配规则都转化为匹配对象，并组成匹配对象列表，由匹配管理器管理所述匹配对象列表。
优选地，匹配对象的基本功能是根据配置的特定字段进行正则匹配，并支持多个字段“和”匹配和多个“或”匹配。
优选地，初步分类报表的每一项内容包括：已分类的崩溃原因、占比统计以及崩溃类型存放的文件夹位置。
优选地，最终报表内容包括：结果概览和崩溃统计列表，其中，结果概览包含本次合法崩溃总数及占比，初步分类阶段被分类的崩溃数量及占比，递归分类阶段被分类的崩溃数量及占比，未分类崩的数量及占比，崩溃统计列表的每一项内容包括崩溃原因、崩溃原因导致的崩溃数量、占比以及崩溃类型存放的文件夹位置，并且崩溃统计类别按照占比从高到低排序。
为实现上述目的，根据本发明实施例的一个方面，提供一种用于iOS崩溃数据分类与统计的装置，该装置包括：初步分类模块，所述初步分类模块对崩溃数据进行自动化分类，采用对调用栈逆向查找方式，提取整个调用栈中的属于应用程序的调用语句，并输出初步分类报表；递归分类模块，所述递归分类模块通过编写的配置文件，不断地对未被分类的崩溃数据进行迭代分类，并在每一次迭代后输出递归分类报表；以及报告生成模块，所述报告生成模块将所述初步分类报表和所述递归分类报表进行整合，并结合上一次崩溃分析的最终报告来输出本次崩溃分析的最终报告。
可选地，初步分类模块提取所述调用语句的类名、函数名、以及文件函数作为崩溃原因的描述，制作崩溃原因与存放文件夹的映射表，并将同一崩溃原因的崩溃数据放到同一个文件夹。
可选地，在递归分类模块读入所述编写的配置文件之后，将编写的配置文件转化为对象，将每一个匹配规则都转化为匹配对象，并组成匹配对象列表，由匹配管理器管理所述匹配对象列表。
可选地，匹配对象的基本功能是根据配置的特定字段进行正则匹配，并支持多个字段“和”匹配和多个“或”匹配。
可选地，初步分类报表的每一项内容包括：已分类的崩溃原因、占比统计以及崩溃类型存放的文件夹位置。
优选地，最终报表内容包括：结果概览和崩溃统计列表，其中，结果概览包含本次合法崩溃总数及占比，初步分类阶段被分类的崩溃数量及占比，递归分类阶段被分类的崩溃数量及占比，未分类崩的数量及占比，崩溃统计列表的每一项内容包括崩溃原因、崩溃原因导致的崩溃数量、占比以及崩溃类型存放的文件夹位置，并且崩溃统计列表按照占比从高到低排序。
本发明实施例的一种电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，以使一个或多个处理器能够执行本发明实施例的用于iOS崩溃数据分类与统计的方法。
为实现上述目的，根据本发明实施例的又一方面，提供了一种计算机可读存储介质。
本发明实施例的一种计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行本发明实施例的用于iOS崩溃数据分类与统计的方法。
上述发明中的一个实施例具有如下优点或有益效果：对崩溃的分类更加精确，对能自动归类的崩溃，确保能归类到具体的原因中去。对疑难崩溃，提供人工参与的阶段，通过编写配置表，迭代性地对这些崩溃进行分类。在多次崩溃分析中，可以给出崩溃分类的趋势变化，从而为任务分配以及修复结果校验提供参考依据。
上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1是根据本发明实施例的实现崩溃数据分类与统计的系统的模块的示意图。
图2是根据本发明实施例的初步分类模块的详细流程图。
图3是根据本发明实施例的递归分类模块的流程图。
图4是适于用来实现本申请实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
图1是根据本发明实施例的实现崩溃数据分类与统计的系统的模块的示意图。
参见图1，该系统包括初步分类模块、递归分类模块和报告生成模块。以下将对各个模块进行详细描述。
初步分类模块：负责将可以完全自动化分类的崩溃在此处分类统计，主要是调用栈中明确存在代码调用语句的崩溃(main语句除外)，在此处进行分类，并输出初步分类报表。
递归分类模块：通过编写的配置文件，不断迭代分类未被分类的崩溃数据，不断降低未分类的崩溃比例，并在每一次迭代后输出递归分类报表。
报告生成模块：将初步分类报表和递归分类报表进行整合输出，并结合上一次崩溃分析的最终报告，输出本次崩溃分析的最终报告。
实现本发明所需的前置操作：
使用atos、Symbolicatecrash等崩溃符号翻译工具需要先将调用堆栈的二进制地址翻译为可视化的调用语句。
图2是根据本发明实施例的初步分类模块的详细流程图。
参考图2，初步分类模块的详细流程如下。
首先，输入数据，所输入的数据是原始的崩溃数据文件集合。
其次，对无效数据进行过滤：首先对无效的崩溃数据进行过滤，通过将每一个崩溃文件格式化为一个对象，能够有效地检查哪些崩溃数据是不符合分析要求的。例如，文件信息不完整、非本次分析所针对的app版本崩溃等。此外，在此处也可以进行其他特定字段的过滤校验。例如用户希望只对特定iOS系统版本的崩溃做分析，那么可以在此处扩展程序，将非指定版本的崩溃过滤掉。
第三，对App崩溃语句进行分类：在该步骤中，首先读取崩溃调用栈，对崩溃发生线程的调用栈进行回溯，从最顶层开始向下查找，查看有无属于自已app的调用语句，并使用正则表达式校验是否符合规范。如果存在，则将这一条语句提取出来，作为崩溃发生原因，并提取该语句的类名+函数名+文件函数作为崩溃原因的描述，制作崩溃原因与存放文件夹的映射表，并将同一崩溃原因的崩溃数据放在同一个文件夹下面。
下面给出崩溃日志调用栈示例。
在调用栈语句中-[JDInvoiceInfoViewController fillVatInvoiceView:]表示崩溃调用函数名(in Jdipad)；表示该调用函数属于哪个库；(JDInvoiceInfoViewController.m:2106)表示该调用函数属于哪个文件。因此，从库名就可以知道是属于app自己的调用语句，而不是系统库调用。
"__exceptionPreprocess(in CoreFoundation_7.1.1)+132",
"objc_exception_throw(in libobjc.A.dylib_7.1.1)+60",
"-[__NSPlaceholderArray initWithObjects:count:](in CoreFoundation_7.1.1)+376",
"+[NSArray arrayWithObjects:count:](in CoreFoundation_7.1.1)+60",
"-[JDInvoiceInfoViewController fillVatInvoiceView:](in Jdipad_3.9.1_8088_AppStore)(JDInvoiceInfoViewController.m:2106)",
"-[JDInvoiceInfoViewController fillContentView](in Jdipad_3.9.1_8088_AppStore)(JDInvoiceInfoViewController.m:0)",
"__46-[JDInvoiceInfoViewController fetchRemoteData]_block_invoke(in Jdipad_3.9.1_8088_AppStore)(JDInvoiceInfoViewController.m:1417)",
"__86-[JDiPadNetworkingInterface
startNetworkingRequest:progress:success:failure:canceled:]_block_invoke_2(in Jdipad_3.9.1_8088_AppStore)(JDiPadNetworkingInterface.m:204)",
"_dispatch_call_block_and_release(in libdispatch.dylib_7.1.1)+24",
"_dispatch_client_callout(in libdispatch.dylib_7.1.1)+16",
"_dispatch_main_queue_callback_4CF(in libdispatch.dylib_7.1.1)+336",
"__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(in CoreFoundation_7.1.1)+12",
"__CFRunLoopRun(in CoreFoundation_7.1.1)+1452",
"CFRunLoopRunSpecific(in CoreFoundation_7.1.1)+452",
"GSEventRunModal(in GraphicsServices_7.1.1)+168",
"UIApplicationMain(in UIKit_7.1.1)+1156",
"main(in Jdipad_3.9.1_8088_AppStore)(main.m:41)",
"start(in libdyld.dylib_7.1.1)+4"
第四，输出结果：在完成前面的步骤之后，将输出初步分类报表，报表本身是一个列表，每一项的内容包含已分类的崩溃原因、占比统计和崩溃类型存放的文件夹位置，并按照占比高低进行排序输出。
在上述步骤完成之后，没有被过滤或者分类的数据放在未分类文件夹中，并指明未分类的崩溃的占比，等待进入递归匹配状态。
图3是根据本发明实施例的递归分类模块的详细流程图。
参考图3，对递归分类模块的详细流程进行如下描述。
递归分类模块详细流程如下：
1.输入数据：初步分类完成后，未被分类的崩溃文件集合。
2.生成匹配规则对象列表：读入配置文件(使用json编写)，将配置文件转化为对象，将每一个匹配规则都转化为匹配对象，并组成匹配对象列表，交由匹配管理器管理。每一个匹配对象的基本功能是根据配置的特定字段进行正则匹配，在此基础上，进一步支持多个字段“和”匹配和多个“或”匹配。
3.循环读入崩溃数据，不断读入还未被处理的崩溃数据，并交由匹配管理器匹配，如果能匹配到具体的某一个匹配规则，那么就将其分类到该匹配规则所映射的崩溃文件夹中。如果均不匹配，那么放入未分类文件夹。
4.输出结果：处理完所有输入数据后，输出本次匹配的结果报表，将输出递归分类的报表，报表本身是一个列表，每一项的内容包含已分类的崩溃原因、占比统计和该崩溃类型存放的文件夹位置，并按照占比高低进行排序输出。而没有被过滤或者分类的数据放在未分类文件夹中，并指明未分类的崩溃的占比。
关于配置文件的编写方式进行如下详细描述：
1.首先，需要分析未分类文件夹下的崩溃，在读取一个崩溃文件后，将可以归类出这个崩溃的原因和它的崩溃报告中表明自己原因的一些标识字段。
2.配置文件本身是一个json格式的文本文件，最外层是一个列表。列表内的每一项内容包括崩溃原因描述，崩溃原因匹配规则字段(支持正则匹配、以及支持同个规则共同生效才算匹配，以及多个规则任一匹配就算匹配)。将上面归纳出的崩溃信息转化为配置文件中的一项崩溃匹配原则。
3.现在对匹配规则进行具体描述：在json文件的每一个崩溃匹配项都是一个字典，每个字典中都有一个keywords键值、keywordList键值，分别对应一个数组，数组内的每一项都是一个正则表达式字符串，。在keywords数组中的表达式必须全部满足，在keywordList数组中的表达式必须至少满足其一。在崩溃日志的调用栈中，以每一行调用语句为单位，分别与上面说的正则表达式进行检索，如果在调用栈总有任一调用语句可以检索到该正则表达式的内容，那么这一项正则表达式就是满足的。另外，还有一些常用字段，比如iOSVersionMin和iOSVersionMax，用来表示需要匹配的系统版本范围；比如ExceptionType，用来表示具体是哪一类Exception(系统提供的值，比如NSGenericException、NSRangeException、NSInvalidArgumentException、….)；比如signalType，用来表示触发了哪一类signal(系统提供的值，比如SEGV、SIGBUS、SIGABRT、…..)；对于这些常用字段匹配项，不想要参与匹配的，直接写入“NULL”即可。
4.将详细描述这个匹配表为什么可以有助于对崩溃进行归类。因为同一类原因导致的崩溃，那么在调用栈中一定是有所体现的。比如，一个系统原因导致的崩溃，它的崩溃发生系统版本会非常集中，然后，虽然整个调用栈可能各不相同，但是，里面总有一些调用语句是有重合的，这些语句就是我们认为的触发这个崩溃的原因，也是他们共有的特性。因此，当一个经验丰富的开发人员看过未能被自动归类的崩溃日志后，可以从中提取出一些共有的特性，然后根据所提供的这些配置项，依次配置，即可对未分类的崩溃日志，做进一步的分类。
由于一个崩溃原因一般都会对应多份崩溃文件，不断的读取未分类崩溃，然后更新配置文件，再去执行递归分类模块，就可以使未分类的崩溃文件一次次的减少。当迭代执行到认为未分类崩溃数据占比已经处于一个合理位置的时候，就可以整合输出最终报表了。
以下将对报告生成模块进行详细描述：
1.结合之前的初步分类报表，和递归分类报表，输出合并报表。报表内容分为两大部分：
a)结果概览：包含本次合法崩溃总数及占比，初步分类阶段被分类的崩溃数量及占比，递归分类阶段被分类的崩溃数量及占比，未分类崩的数量及占比。
b)崩溃统计列表：每一项内容包括崩溃原因、该崩溃原因导致的崩溃数量、占比以及该崩溃类型存放的文件夹位置。并且整个列表按照占比从高到低排序。
2.可选地，如果能读取到上一次崩溃的分析报告，将会对本次崩溃合并报表和上次崩溃分析报告进行比对。对两份报告的崩溃统计列表中，相同原因的崩溃占比做一个趋势说明，直接在崩溃统计列表的该崩溃原因的内容项中添加一个字段表明趋势：“新增”代表该崩溃原因是本次崩溃分析后新产生的一项分类、“+xx.xx％”表示该崩溃的占比相比对上一次分析增加，需要开发进一步关注、“-xx.xx％”表示该崩溃的占比相比于上一次分析下降。
在完成前面两步后，输出的报告即为最终的崩溃分析报告。
以下，将对完整的分类流程进行描述：
1.首先将崩溃文件都放在一个具体的文件夹中，然后执行初步分类脚本。此时的崩溃文件，必须是已经经历过符号化操作的文件，其所有调用栈都必须是可视化的代码调用语句，而不是二进制地址。
2.初步分类阶段：首先对所有崩溃日志做校验，不符合要求的崩溃日志(格式要求等，用户可自定义扩展)直接删除。接着，将对每个文件的调用栈从栈顶开始，向栈底查找，将找到栈中第一条非系统库调用、非main函数的调用语句，并将其作为这个崩溃的分类依据。提取到相同调用语句的崩溃需要归为一类，并存放到同一文件夹中。最后将未能按照上述方式分类的崩溃放到未分类文件夹中，并输出此次分类的类目，以及各个类目占比(未分类也算一个类目)。
3.查看未分类文件夹下的崩溃，按照【配置文件的编写方式】所述去编写配置文件。
4.执行递归分类脚本，从上一步初步分类后的未分类文件夹中获取初始数据，通过编写的配置文件，将每个崩溃文件，依次与每个匹配表配置进行匹配，如果匹配成功，则将该崩溃日志分类为该配置项对应的崩溃分类，并将该崩溃日志从未分类文件夹移动到具体的分类文件夹中(如果之前不存在此分类文件夹，则新建并移入)。最后输出递归分类后的类目，以及各个类目占比(未分类也算一个类目)。
5.不断执行【3】和【4】，当迭代执行到未分类文件夹下的崩溃数据占比已经处于一个合理位置的时候，就可以整合输出最终报表了。
6.将上一次分析报告结果放在当前文件夹下，执行报告生成脚本，就可以得到最终的崩溃分析报告了。
下面参考图4，其示出了适于用来实现本申请实施例的终端设备的计算机系统400的结构示意图。图4示出的终端设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图4所示，计算机系统400包括中央处理单元(CPU)401，其可以根据存储在只读存储器(ROM)402中的程序或者从存储部分408加载到随机访问存储器(RAM)403中的程序而执行各种适当的动作和处理。在RAM 403中，还存储有系统400操作所需的各种程序和数据。CPU 401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。
以下部件连接至I/O接口405：包括键盘、鼠标等的输入部分406；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分407；包括硬盘等的存储部分408；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也根据需要连接至I/O接口405。可拆卸介质411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器410上，以便于从其上读出的计算机程序根据需要被安装入存储部分408。
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(CPU)401执行时，执行本申请的系统中限定的上述功能。
需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的“模块”可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的“模块”也可以设置在处理器中，例如，可以描述为：一种处理器包括初步分类模块、递归分类模块和报告生成模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，递归分类模块还可以被描述为“通过编写的配置文件，不断地对未被分类的崩溃数据进行迭代分类，并在每一次迭代后输出递归分类报表的模块”。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备对崩溃数据进行自动化分类，采用对调用栈逆向查找方式，提取整个调用栈中的属于应用程序的调用语句，输出初步分类报表；通过编写的配置文件，不断地对未被分类的崩溃数据进行迭代分类，并在每一次迭代后输出递归分类报表；以及将所述初步分类报表和所述递归分类报表进行整合，并且结合上一次崩溃分析的最终报告来输出本次崩溃分析的最终报告。
根据本发明实施例的技术方案，对崩溃的分类更加精确，对能自动归类的崩溃，确保能归类到具体的原因中去。对疑难崩溃，提供人工参与的阶段，通过编写配置表，迭代性地对这些崩溃进行分类。在多次崩溃分析中，可以给出崩溃分类的趋势变化，从而为任务分配以及修复结果校验提供参考依据。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。