【iOS测试】如何高效的分析崩溃日志

对于iOS崩溃日志，开发同学可以使用Mac连接iPhone设备后，在XCode的Device里面查看崩溃日志。如果本机正好有对应的符号表文件的话，会自动解析崩溃日志。而当XCode不自动解析崩溃日志时，也可以用过symbolicateCrash、atos等命令行工具解析崩溃日志。但是当缺少Mac机器的情况下，比如测试人员发现了崩溃并获取到了崩溃日志，他们该如何解析呢？

之前的做法

1.测试同学将崩溃日志从设备中取出后，发送给开发同学（一个统一的接口人）处理。

2.开发同学解析崩溃日志，将解析后的崩溃日志再发送给测试同学。

3.测试同学根据现象及解析后的崩溃日志提交bug到bug管理系统。

4.模块负责同学根据bug现象和崩溃日志进行处理。

在这个过程中，崩溃日志在测试和开发同学中倒来倒去，这样处理会造成对开发和测试双方的打断，浪费时间，效率极低。如果另一个测试同学也出现崩溃，提交bug同时附上了崩溃日志，开发根据崩溃日志，发现导致这两个bug的原因是一样的，那么开发还需要对这两个bug进行合并。是不是有些没有必要的工作在里面？为了减少打断的次数，认真的进行了分析，挖掘可优化的环节，最终这个过程变成了下面的样子。

现在的做法

1.测试同学将崩溃日志从设备中取出后，提交到崩溃日志分析系统里。

2.提交后，崩溃系统会返回解析后的崩溃日志的下载链接，并且判断当前数据库中有无同样类型的崩溃日志。

3.如果存在相同的崩溃日志，那么显示出bug编号。

4.如果没有相同的崩溃日志，测试同学提交bug后，在崩溃日志分析系统里输入bug编号，将崩溃日志和bug编号保存到崩溃日志数据库中。

改进之后，在提交bug之前都不需要开发同学的参与，并且由于崩溃日志的数据库的存在，降低了提交重复的bug，开发同学也就减少了合并bug的操作。简化了流程，在一定程度上提高了工作效率。

崩溃日志分析系统的实现原理

崩溃日志分析系统通过B/S架构实现。主要使用的apache+mysql+php环境，毕竟在mac上只需要安装mysql即可，apache和php都是源生的。整个系统大概需要以下几部分：

1. 提供上传崩溃日志、安装包版本信息等的界面。

2. 展示数据库中崩溃日志的界面

3. symbolicateCrash工具

4. 崩溃日志对比的命令行工具

5. 一个目录来保存各个版本符号表文件

这样从上传界面上传崩溃日志后，根据版本号等信息匹配到对应的符号表文件后，调用symbolicateCrash命令对崩溃日志进行解析。得到解析后的崩溃日志，再利用崩溃日志对比工具跟数据库中的其他崩溃日志逐一对比。对比完成后，根据需求再处理刚刚解析后的崩溃日志，或插入数据库，或提示相同类型的崩溃日志已存在，bug编号是XXX。

tips：

1. 在调用symbolicateCrash时，作为php菜鸟的我，不知道如何设置环境变量DEVELOPER_DIR，所以就编写了一个命令行工具，通过NSTask设置环境变量并调用symbolicateCrash命令。

2. 崩溃日志对比工具——不是简单地对比文件大小，可以将有效地崩溃栈信息提取出来，只针对这些内容进行比较。

3. 如果还需要更多功能的话，可以根据需求设计数据库，比如统计每一个崩溃日志的崩溃次数，来查看这个版本那种类型的崩溃较多。也可以统计每个版本总体的崩溃情况，还可以查看某一天的崩溃情况等等，这些锦上添花的功能，就要根据具体的需求来实现就好啦。

对于iOS崩溃日志，开发同学可以使用Mac连接iPhone设备后，在XCode的Device里面查看崩溃日志。如果本机正好有对应的符号表文件的话，会自动解析崩溃日志。而当XCode不自动解析崩溃日志时，也可以用过symbolicateCrash、atos等命令行工具解析崩溃日志。但是当缺少Mac机器的情况下，比如测试人员发现了崩溃并获取到了崩溃日志，他们该如何解析呢？

之前的做法

1.测试同学将崩溃日志从设备中取出后，发送给开发同学（一个统一的接口人）处理。

2.开发同学解析崩溃日志，将解析后的崩溃日志再发送给测试同学。

3.测试同学根据现象及解析后的崩溃日志提交bug到bug管理系统。

4.模块负责同学根据bug现象和崩溃日志进行处理。

在这个过程中，崩溃日志在测试和开发同学中倒来倒去，这样处理会造成对开发和测试双方的打断，浪费时间，效率极低。如果另一个测试同学也出现崩溃，提交bug同时附上了崩溃日志，开发根据崩溃日志，发现导致这两个bug的原因是一样的，那么开发还需要对这两个bug进行合并。是不是有些没有必要的工作在里面？为了减少打断的次数，认真的进行了分析，挖掘可优化的环节，最终这个过程变成了下面的样子。

现在的做法

1.测试同学将崩溃日志从设备中取出后，提交到崩溃日志分析系统里。

2.提交后，崩溃系统会返回解析后的崩溃日志的下载链接，并且判断当前数据库中有无同样类型的崩溃日志。

3.如果存在相同的崩溃日志，那么显示出bug编号。

4.如果没有相同的崩溃日志，测试同学提交bug后，在崩溃日志分析系统里输入bug编号，将崩溃日志和bug编号保存到崩溃日志数据库中。

改进之后，在提交bug之前都不需要开发同学的参与，并且由于崩溃日志的数据库的存在，降低了提交重复的bug，开发同学也就减少了合并bug的操作。简化了流程，在一定程度上提高了工作效率。

崩溃日志分析系统的实现原理

崩溃日志分析系统通过B/S架构实现。主要使用的apache+mysql+php环境，毕竟在mac上只需要安装mysql即可，apache和php都是源生的。整个系统大概需要以下几部分：

1. 提供上传崩溃日志、安装包版本信息等的界面。

2. 展示数据库中崩溃日志的界面

3. symbolicateCrash工具

4. 崩溃日志对比的命令行工具

5. 一个目录来保存各个版本符号表文件

这样从上传界面上传崩溃日志后，根据版本号等信息匹配到对应的符号表文件后，调用symbolicateCrash命令对崩溃日志进行解析。得到解析后的崩溃日志，再利用崩溃日志对比工具跟数据库中的其他崩溃日志逐一对比。对比完成后，根据需求再处理刚刚解析后的崩溃日志，或插入数据库，或提示相同类型的崩溃日志已存在，bug编号是XXX。

tips：

1. 在调用symbolicateCrash时，作为php菜鸟的我，不知道如何设置环境变量DEVELOPER_DIR，所以就编写了一个命令行工具，通过NSTask设置环境变量并调用symbolicateCrash命令。

2. 崩溃日志对比工具——不是简单地对比文件大小，可以将有效地崩溃栈信息提取出来，只针对这些内容进行比较。

3. 如果还需要更多功能的话，可以根据需求设计数据库，比如统计每一个崩溃日志的崩溃次数，来查看这个版本那种类型的崩溃较多。也可以统计每个版本总体的崩溃情况，还可以查看某一天的崩溃情况等等，这些锦上添花的功能，就要根据具体的需求来实现就好啦。

对于iOS崩溃日志，开发同学可以使用Mac连接iPhone设备后，在XCode的Device里面查看崩溃日志。如果本机正好有对应的符号表文件的话，会自动解析崩溃日志。而当XCode不自动解析崩溃日志时，也可以用过symbolicateCrash、atos等命令行工具解析崩溃日志。但是当缺少Mac机器的情况下，比如测试人员发现了崩溃并获取到了崩溃日志，他们该如何解析呢？

之前的做法

1.测试同学将崩溃日志从设备中取出后，发送给开发同学（一个统一的接口人）处理。

2.开发同学解析崩溃日志，将解析后的崩溃日志再发送给测试同学。

3.测试同学根据现象及解析后的崩溃日志提交bug到bug管理系统。

4.模块负责同学根据bug现象和崩溃日志进行处理。

在这个过程中，崩溃日志在测试和开发同学中倒来倒去，这样处理会造成对开发和测试双方的打断，浪费时间，效率极低。如果另一个测试同学也出现崩溃，提交bug同时附上了崩溃日志，开发根据崩溃日志，发现导致这两个bug的原因是一样的，那么开发还需要对这两个bug进行合并。是不是有些没有必要的工作在里面？为了减少打断的次数，认真的进行了分析，挖掘可优化的环节，最终这个过程变成了下面的样子。

现在的做法

1.测试同学将崩溃日志从设备中取出后，提交到崩溃日志分析系统里。

2.提交后，崩溃系统会返回解析后的崩溃日志的下载链接，并且判断当前数据库中有无同样类型的崩溃日志。

3.如果存在相同的崩溃日志，那么显示出bug编号。

4.如果没有相同的崩溃日志，测试同学提交bug后，在崩溃日志分析系统里输入bug编号，将崩溃日志和bug编号保存到崩溃日志数据库中。

改进之后，在提交bug之前都不需要开发同学的参与，并且由于崩溃日志的数据库的存在，降低了提交重复的bug，开发同学也就减少了合并bug的操作。简化了流程，在一定程度上提高了工作效率。

崩溃日志分析系统的实现原理

崩溃日志分析系统通过B/S架构实现。主要使用的apache+mysql+php环境，毕竟在mac上只需要安装mysql即可，apache和php都是源生的。整个系统大概需要以下几部分：

1. 提供上传崩溃日志、安装包版本信息等的界面。

2. 展示数据库中崩溃日志的界面

3. symbolicateCrash工具

4. 崩溃日志对比的命令行工具

5. 一个目录来保存各个版本符号表文件

这样从上传界面上传崩溃日志后，根据版本号等信息匹配到对应的符号表文件后，调用symbolicateCrash命令对崩溃日志进行解析。得到解析后的崩溃日志，再利用崩溃日志对比工具跟数据库中的其他崩溃日志逐一对比。对比完成后，根据需求再处理刚刚解析后的崩溃日志，或插入数据库，或提示相同类型的崩溃日志已存在，bug编号是XXX。

tips：

1. 在调用symbolicateCrash时，作为php菜鸟的我，不知道如何设置环境变量DEVELOPER_DIR，所以就编写了一个命令行工具，通过NSTask设置环境变量并调用symbolicateCrash命令。

2. 崩溃日志对比工具——不是简单地对比文件大小，可以将有效地崩溃栈信息提取出来，只针对这些内容进行比较。

3. 如果还需要更多功能的话，可以根据需求设计数据库，比如统计每一个崩溃日志的崩溃次数，来查看这个版本那种类型的崩溃较多。也可以统计每个版本总体的崩溃情况，还可以查看某一天的崩溃情况等等，这些锦上添花的功能，就要根据具体的需求来实现就好啦。

    转载请注明：http://blog.csdn.net/sogouauto