一种bug自动调试系统及方法

一种bug自动调试系统及方法
【专利摘要】本发明涉及电子通信技术领域，具体涉及一种bug自动调试系统及方法。一种减小线性稳压器串扰的系统，应用于同一电源芯片供电的系统，包括，一第一线性稳压器，于一第一控制信号的作用下为设定功能模块供电，并于设定条件下于一驱动信号的作用下调整工作状态；一第二线性稳压器，于一第二控制信号的作用下为设定功能模块供电，同时产生驱动信号；控制单元，用于产生第一控制信号和第二控制信号，第二控制信号相比第一控制信号有一设定时间的延迟。本发明通过第二线性稳压器产生驱动信号，使得第二线性稳压器开启的同时，第一线性稳压器于驱动信号的作用下整个电路的偏置电流加倍，从而增加运算放大单元的增益，改善电源抑制比，减小线性稳压器之间的串扰。
【专利说明】
一种bug自动调试系统及方法
技术领域
[0001]本发明涉及bug调试，具体涉及到一种bug自动调试系统及方法。
【背景技术】
[0002]随着信息技术的不断发展，基于智能操作系统的电子设备成了人们工作、生活所不可缺少的一个重要部分。但是在操作系统和基于操作系统开发出来的软件经常会出现各种bug，而在开发过程中一项很重要的工作就是找出bug并进行修复。由于软件需要调整适应的芯片设计，快速使软件系统达到稳定。如何高效的完成系统稳定性问题的分析和解决至关重要。
[0003]综上，如何加快bug的定位及修复速度一直为本领域技术人员所致力研究的方向。

【发明内容】

[0004]本发明提供了一种bug自动处理系统，应用于终端设备的bug处理中，其中，包括:
[0005]测试装置，用于采集bug的日志文件，并上传到一共享装置中进行存储；
[0006]解析装置，分别与所述测试装置和所述共享装置连接，用于获取并解析所述日志文件，以生成报告文件并上传到一存储装置进行存储，该存储装置与所述测试装置连接；
[0007]分配装置，分别与所述测试装置和所述存储装置连接；
[0008]处理装置，分别与所述分配装置和所述共享装置连接；
[0009]其中，所述测试装置根据所述报告文件下发分配指令至所述分配装置，该分配装置根据接收到的所述分配指令调取所述报告文件并进行分析后，发送至所述处理装置，所述处理装置根据解析后的报告文件，从所述共享装置中获取相应的日志文件，并对bug进行修复。
[0010]上述的bug自动处理系统，其中，所述解析装置包括:
[0011]抓取模块，与所述共享装置连接，用于抓取所述日志文件；
[0012]判断模块，与所述抓取模块连接，用于根据所述日志文件来判断bug类型，所述bug类型包括未知原因错误类型和重启错误类型；
[0013]报告生成模块，连接所述判断模块，用于在未知原因错误类型、重启错误类型的情况下生成所述报告文件。
[0014]上述的bug自动处理系统，其中，所述解析装置还包括:
[0015]检查模块，连接所述判断模块，用于对终端设备重启后进行命令行检查；
[0016]异常判断模块，连接所述检查模块，用于在命令行检查的模式下进行异常判断；
[0017]比较模块，与所述异常判断模块连接，用于比较内核代码段的完整性；
[0018]截取模块，与所述比较模块和所述报告生成模块连接，用于截取终端设备的屏幕帧缓冲内容。
[0019]上述的bug自动处理系统，其中，所述异常判断模块包括:
[0020]内核异常判断单元、第一看门狗单元、第二看门狗单元和未知原因判断单元，均与所述检查模块相连；
[0021]其中，利用所述内核异常判断单元和/或所述第一看门狗单元进行判断过后，通过一拾取模块来拾取异常日志文件打印信息，并传输到所述比较模块；
[0022]利用第二看门狗单元和/或未知原因判断单元进行判断过后，通过一跟踪模块来检查系统转储是否完整:若完整，则继续通过一访问记录检查模块来检查最终寄存器的访问记录，之后利用所述比较模块来比较内核代码段的完整性；若不完整，则生成不完整日志文件。
[0023]上述的bug自动处理系统，其中，在经由所述检查模块对终端设备重启并进行命令行检查后，若没有检查到所需字段，则生成不完整日志文件。
[0024]上述的bug自动处理系统，其中，所述bug类型还包括程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型；
[0025]当藉由所述判断模块判断出bug类型为程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型中的任意一种或多种时，通过一问题检查模块进行问题检查。
[0026]上述的bug自动处理系统，其中，当藉由所述检查模块进行命令行检查后判断为系统严重异常时，通过所述问题检查模块进行问题检查。
[0027]上述的bug自动处理系统，其中，所述测试装置还用于采集bug的符号表文件，并通过所述共享装置进行存储。
[0028]在另一实施例中，本发明还提供了一种bug自动处理方法，应用于终端设备的bug处理中，其中，包括如下步骤:
[0029]步骤S1:采集bug的日志文件；
[0030]步骤S2:对所述日志文件进行解析，以生成报告文件；
[0031]步骤S3:根据所述报告文件来下发分配指令至一分配装置；
[0032]步骤S4:分配装置对所述报告文件进行分析后发送至一处理装置，所述处理装置根据所述分配装置发送的解析后的报告文件，获取相应的日志文件，并对bug进行修复。
[0033]上述的bug自动处理方法，其中，在所述步骤SI中，通过一测试装置来采集bug的日志文件，并上传到一共享装置中进行存储。
[0034]上述的bug自动处理方法，其中，在所述步骤S2中，通过一分别与所述测试装置和所述共享装置连接的解析装置来获取并解析所述日志文件，以生成所述报告文件；
[0035]其中，所述报告文件通过一存储装置进行存储，该存储装置与所述测试装置连接。
[0036]上述的bug自动处理方法，其中，通过所述解析装置对所述日志文件进行解析以生成所述报告文件的步骤包括:
[0037]步骤S21:通过一与所述共享装置连接的抓取模块抓取所述日志文件；
[0038]步骤S22:通过一与所述抓取模块连接的判断模块来根据所述日志文件判断bug类型，所述bug类型包括未知原因错误类型和重启错误类型；
[0039]利用一报告生成模块在未知原因错误类型、重启错误类型的情况下生成所述报告文件。
[0040]上述的bug自动处理方法，其中，在所述步骤S22中，在重启错误类型的情况下生成所述报告文件的步骤包括:
[0041]S221:利用一与所述判断模块连接的检查模块对终端设备重启后进行命令行检查；
[0042]S222:利用一与所述检查模块连接的异常判断模块进行异常判断；
[0043]S223:利用一比较模块来比较内核代码段的完整性；
[0044]S224:利用一与所述比较模块连接的截取模块来截取所述终端设备的屏幕帧缓冲内容；
[0045]S225:利用与所述截取模块连接的报告生成模块来根据所述屏幕帧缓冲内容来生成所述报告文件。
[0046]上述的bug自动处理方法，其中，在所述S222中，进行如下异常判断:
[0047]内核异常判断、看门狗快速中断程序判断、看门狗未知程序判断和未知原因判断；
[0048]其中，完成内核异常判断和/或看门狗快速中断程序判断之后，通过一拾取模块来拾取异常日志文件打印信息，并传输到所述比较模块；
[0049]完成看门狗未知程序判断和未知原因判断过后，通过一跟踪模块来检查系统转储是否完整:若完整，则继续通过一访问记录检查模块来检查最终寄存器的访问记录，之后利用所述比较模块来比较内核代码段的完整性；若不完整，则生成不完整日志文件。
[0050]上述的bug自动处理方法，其中，在所述步骤S221中，在经由所述检查模块对终端设备重启并进行命令行检查后，若没有检查到所需字段，则生成不完整日志文件。
[0051]上述的bug自动处理方法，其中，在所述步骤S22中，所述bug类型还包括程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型；
[0052]当藉由所述判断模块判断出bug类型为程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型中的任意一种或多种时，通过一问题检查模块进行问题检查。
[0053]上述的bug自动处理方法，其中，在所述步骤S221中，当藉由所述检查模块对终端设备重启后进行命令行检查后判断为系统严重异常时，通过所述问题检查模块进行问题检查。
[0054]上述的bug自动处理方法，其中，所述测试装置还用于采集包括bug数据的符号表文件，并通过所述共享装置进行存储。
[0055]基于上述技术方案，能够极大缩小系统开发速度，同时避免了资源浪费。
【附图说明】
[0056]通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明及其特征、夕卜形和优点将会变得更明显。在全部附图中相同的标记指示相同的部分。并未刻意按照比例绘制附图，重点在于示出本发明的主旨。
[0057]图1为现有技术中在开发过程中针对bug的解决模式；
[0058]图2为本发明提供的一种bug自动调试系统；
[0059]图3为本发明抓取log的示意图；
[0060]图4为本发明藉由解析装置生成报告文件的框图。
【具体实施方式】
[0061]在下文的描述中，给出了大量具体的细节以便提供对本发明更为彻底的理解。然而，对于本领域技术人员而言显而易见的是，本发明可以无需一个或多个这些细节而得以实施。在其他的例子中，为了避免与本发明发生混淆，对于本领域公知的一些技术特征未进行描述。
[0062]为了彻底理解本发明，将在下列的描述中提出详细的步骤以及详细的结构，以便阐释本发明的技术方案。本发明的较佳实施例详细描述如下，然而除了这些详细描述外，本发明还可以具有其他实施方式。
[0063]目前，主要采用了一贯使用的TDD (Test Driven Development，测试驱动开发)和BDD (Bug Driven Development，错误驱动开发)两种方式来对bug进行测试和修复。其中所占比重较大、耗时较长、投入资源较多，存在较多不可控因素的就是BDD阶段。
[0064]所谓的BDD是指Bug驱动开发，简单的说就是发现bug —解决bug —发现新的bug，这样一个不断循环的过程驱动着开发。某一产品的开发过程中通过Bug管理系统，管理所有的bug。一旦测试过程中发现问题后，测试系统会在Bug管理系统中相应的工程下提一个bug,然后分给一个研发系统，分配到bug的研发系统的任务是解决这个bug，然后测试系统回归测试，如果通过则关闭该bug，反之则重新进行BDD流程。通过这样的方式，质量保证系统(Quality Assurance，QA)和研发系统共同配合来完成一个项目的开发，而Bug管理系统使质量保证系统和研发系统都能很好的了解和追踪每个bug的状态。从发现bug到解决bug这一过程中，bug会在测试系统和研发系统之间以及各个研发系统之间多次流转，是整个BDD的一个非常重要的环节，这一环节是否高效直接影响了整个项目的开发周期。如果质量保证系统和研发系统不能很好的控制各种bug，那么各种bug将反过来控制整个项目的日程安排进程，这严重影响了开发效率。
[0065]因此，各个公司都在寻找一种能够更好的控制bug，以及如何更快的完成发现bug到解决bug的过程。但是据了解，目前市面上抓取log，以及监控手机进程状态的工具很多，比如ddms (调试监控服务工具，Dalvik Debug Monitor Service)，但是这样的工具并不能自动解析log文件以及定位问题。
[0066]目前，一个问题的调试(debug)从测试系统(tester)抓取一份log(日志文件)开始，如果测试时间很长，所获取的log文件就会非常的大，这就造成了测试装置共享log和处理装置获取log的耗时非常长。同时，对于本机崩溃(native crash)和信息转储(memorydump)的解析，除了 log文件以外，还需要符号表文件去配合解析，而符号表文件通常都是在几百兆以上(例如200M?300M)，且必须与软件版本相对应，这样就使得在处理问题时，必须为每个问题对应的版本找到对应的符号表并下载，耗时巨大，而这个工作没有可复用性，进而浪费了时间。
[0067]参照图1所示，示出了现有技术中针对bug定位及处理的流程图，首先通过一测试装置I来采集bug的日志文件和符号表文件，之后上传到共享装置2中进行存储。随后测试装置I在众多处理装置(处理装置3a、3b、3c......)中任意指派一个来进行bug的后续处理，例如图1中示出了测试装置I指派处理装置3a进行处理。但是处理装置3a在接收到指令后，从共享装置2中花了 30分钟找到并下载了 log文件和符号表，解析log分析后发现这个问题需要处理装置3b分析，而处理装置3b还需要再花30分钟去下载log和符号表；如此可能还要给到处理装置3c......—个CR (change request，变更请求)从提交到解决，下载
log和符号表这个操作平均要做2?3次，非常浪费时间和资源，这严重降低了开发效率。
[0068]对于测试而言，有些现场并不是很明确的指示出问题发生在哪个模块，比如发生信息转储、黑屏、定屏等问题。因此很难在问题发生的时候就能知道这个版本哪些模块存在问题，CR不能第一时间提给处理装置，进而增加了 CR流转的时间。同时，由于不能很好的掌握版本的状态，导致很容易重复的测试有问题的模块，这也浪费了时间和资源。
[0069]另一方面，对于研发而言，对于某一类问题的处理有一些特定的机械的处理动作，这部分工作实际上是可以将研发的经验抽象出来通过数据文件(例如脚本)的形式完成，这样也可以大大节省研发的时间。
[0070]概括来说，一个问题的调试，特别是像需要分析memory dump的问题，需要三个条件:1，log (memory dump file) ;2，symbol (符号表)文件；3，bug分析处理的经验。现在的缺点是:a、上述三点物理上分布在不同地方，集中到一处成本高；b、因为测试装置只有log文件，因此往往无法有效分配bug给对应的处理装置；C、处理装置即使只需要几分钟甚至更长时间去完成的一次流转，却要为拿到log文件和symbol文件花费几倍乃至于几十倍的时间。与此同时，b让这个情况变得更糟；d、很多问题的处理模式已经成熟，但处理装置还在做机械性的处理动作，浪费宝贵的时间。本发明的目的就是解决上述问题，将log文件、符号表文件和尽量多的处理经验集中到一处，将处理装置从大量低效的工作中解放出来，并更加充分了解更多问题内幕，从而可以更合理分配测试资源。
[0071]针对上述技术问题，本发明提供了一种bug自动处理系统，应用于终端设备的bug处理中，参照图2所示，包括:
[0072]测试装置11，用于采集包括bug数据的日志文件(log)，并上传到一共享装置12中进行存储；
[0073]解析装置13 (或可称为ATS，Automatic trouble-shooting，自动故障检测工具)，分别与测试装置11和共享装置12连接，用于获取并解析日志文件，以生成报告文件(report)并上传到一存储装置14进行存储，该存储装置14与测试装置11连接；
[0074]分配装置15，分别与测试装置11和存储装置14连接；
[0075]处理装置16，分别与分配装置15和共享装置12连接；
[0076]其中，测试装置11根据存储装置14中的报告文件来下发分配指令至分配装置15，该分配装置15根据接收到的分配指令调取存储装置14中的报告文件并进行解析后，发送至一处理装置16，处理装置16根据分配装置15发送的解析后的报告文件，从共享装置12中获取相应的日志文件(log)，并对bug进行修复。
[0077]在本发明一可选的实施例中，采用测试装置11获取日志文件的步骤可参照图3所示，具体如下:首先，提供一存在异常(例如存在黑屏(无背光)或定屏/单色屏/花屏等问题)的终端设备，可选的，该终端设备为基于安卓(Android)系统的电子设备。之后判断该终端设备能否在abd模式下与电脑连接，若能直接连接，则可直接抓取log ;若终端设备无法在adb模式下连接电脑，那么依次进行如下操作:确认按键反应、确认插拔USB反应、确认呼叫测试机反应、确认系统是否崩溃(crash key)、硬启动(powerkey 7S)。其中，在进行确认系统是否崩溃(crash key)和硬启动(powerkey 7S)之后，均进行判断是否能够激活系统转储模式(sysdump enabled)，如果不允许，则直接进行静谧重启的操作；如果允许，则先进行系统转储之后再进行静谧重启的操作，之后再抓取log文件。同时，本发明还可在其他情况实现下对log的抓取，请继续参阅图3，当终端设备出现应用退出、程序未响应(Applicat1n No Response，简称 ANR)、功能(funct1n)/UI (用户界面)的 bug 时，也同样可以抓取bug的日志文件。
[0078]下面请参照图4所示，对解析装置13以及如何生成报告文件进行进一步的阐述。
[0079]在本发明一可选的实施例中，解析装置13包括:
[0080]判断模块，与共享装置12连接，用于根据日志文件来判断bug类型(pick a bugtype)，bug类型包括未知原因错误类型(unknown)和重启错误类型(reboot)；
[0081]报告生成模块，连接判断模块，用于在未知原因错误类型、重启错误类型的情况下生成报告文件(generate report)。其中，当bug类型为未知原因错误类型时，贝Ij不作任何处理，直接生成报告文件。
[0082]在本发明一可选的实施例中，解析装置还包括:
[0083]检查模块，连接判断模块，用于对终端设备重启后进行命令行检查(checkcmdline Androidboot.mode)；
[0084]异常判断模块，连接检查模块，用于在命令行检查的模式下进行异常判断；
[0085]比较模块，与异常判断模块连接，用于比较内核代码段的完整性(compare, textsegment kernel)，进而判断内核代码段是否在使用过程中存在异常；
[0086]截取模块，与比较模块和报告生成模块连接，用于截取终端设备的屏幕帧缓冲内容(dump FB content)，也即截取手机最后的画面。
[0087]在本发明一可选的实施例中，异常判断模块包括:
[0088]内核异常判断单元(panic)、第一看门狗单元(wdtfiqreboot，看门狗快速中断程序)、第二看门狗单元(wdtreboot，看门狗程序)和未知原因判断单元(unknown)，均与检查模块相连，用于在检查模块在重启判断类型下进行命令行检查进行故障类型判断；
[0089]其中，利用内核异常判断单元和第一看门狗单元进行判断过后，通过一拾取模块来拾取异常日志文件打印(collect “0opS”log)，并传输到比较模块，之后利用比较模块来比较内核代码段的完整性；
[0090]而在利用第二看门狗单元和未知原因判断单元进行判断过后，通过一跟踪模块来检查系统转储是否完整:若完整，则继续通过一访问记录检查模块来检查最终寄存器的访问记录(check the lastregs—access)，之后利用比较模块来比较内核代码段的完整性；若不完整，则生成不完整日志文件(log incomplete) ο
[0091]在本发明一可选的实施例中，在经由检查模块对终端设备重启并进行命令行检查后，若没有检查到所需字段(即无此字段)，则同样生成不完整日志文件。
[0092]在本发明一可选的实施例中，bug类型还包括程序未响应错误类型(ANR)、程序异常退出类型(APP quit with except1n)、功能/用户界面错误类型(funct1n/UI bug)和唤醒异常类型(collectsleep/wakeup log)；
[0093]当藉由判断模块判断出bug类型为程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型中的任意一种或多种时，通过一问题检查模块进行问题检查。
[0094]在本发明一可选的实施例中，当藉由检查模块对终端设备重启后进行命令行检查后判断为安卓系统严重异常(Special)时，通过问题检查模块进行安卓问题检查。
[0095]在本发明一可选的实施例中，测试装置11还可以采集bug的符号表文件，并通过共享装置12进行存储。当需要对native crash和memory dump进行解析时，本发明所提供的测试装置11在采集bug的日志文件的过程中，还可采集符号表文件，将其存储到共享模块12中，当处理装置16在应对某些特殊解析时，可同时在共享模块12中获取日志文件(log)和符号表文件(symbols)。
[0096]在另一种实施例中，本发明还提供了一种bug自动处理方法，可结合图3所示，应用于终端设备的bug处理中，包括如下步骤:
[0097]步骤S1:采集bug的日志文件；
[0098]步骤S2:对日志文件进行解析，以生成报告文件；
[0099]步骤S3:根据报告文件来下发分配指令至一分配装置；
[0100]步骤S4:分配装置根据报告文件来分配到一处理装置，处理装置获取相应的日志文件，并对bug进行修复。
[0101]在本发明一可选的实施例中，在步骤SI中，通过一测试装置来采集包括bug数据的日志文件，并上传到一共享装置中进行存储。
[0102]在本发明一可选的实施例中，在上述步骤S2中，通过一分别与测试装置和共享装置连接的解析装置来获取并解析日志文件，以生成报告文件；
[0103]其中，报告文件通过一存储装置进行存储，该存储装置与测试装置连接。
[0104]在本发明一可选的实施例中，通过解析装置对日志文件进行解析以生成报告文件的步骤包括:
[0105]步骤S21:通过一与共享装置连接的抓取模块抓取日志文件；
[0106]步骤S22:通过一与抓取模块连接的判断模块来根据日志文件来判断bug类型，bug类型包括未知原因错误类型和重启错误类型；
[0107]利用一报告生成模块在未知原因错误类型、重启错误类型的情况下生成报告文件。其中，当bug类型为未知原因错误类型时，不作任何处理，直接生成报告文件。
[0108]在本发明一可选的实施例中，上述步骤S22中，在重启错误类型的情况下生成报告文件的步骤包括:
[0109]S221:利用一检查模块对终端设备重启后进行命令行检查；
[0110]S222:利用一异常判断单元在命令行检查的模式下进行异常判断；
[0111]S223:利用一比较模块来比较内核代码段的完整性；
[0112]S224:利用一截取模块来截取终端设备的屏幕帧缓冲内容；
[0113]S225:根据屏幕帧缓冲内容来生成报告文件。
[0114]在本发明一可选的实施例中，在上述S222中，进行如下异常原因的判断:
[0115]内核异常判断、看门狗快速中断程序判断、看门狗未知程序判断和未知原因判断；
[0116]其中，完成内核异常判断和/或看门狗快速中断程序判断之后，通过一拾取模块来拾取异常日志文件打印，并传输到比较模块；
[0117]完成看门狗未知程序判断和未知原因判断过后，通过一跟踪模块来检查系统转储是否完整:若完整，则继续通过一访问记录检查模块来检查最终寄存器的访问记录，之后利用比较模块来比较内核代码段的完整性；若不完整，则生成不完整日志文件。
[0118]在本发明一可选的实施例中，在步骤S231中，在经由检查模块对终端设备重启并进行命令行检查后，若没有检查到所需字段，则生成不完整日志文件。
[0119]在本发明一可选的实施例中，在上述步骤S22中，bug类型还包括程序未响应错误类型、程序异常退出类型、用户界面功能错误类型和唤醒异常类型；
[0120]当藉由判断模块判断出bug类型为未响应错误类型、程序异常退出类型、用户界面功能错误类型和唤醒异常类型中的任意一种或多种时，通过一问题检查模块进行安卓问题检查。
[0121]在本发明一可选的实施例中，在上述步骤S231中，当藉由检查模块对终端设备重启后进行命令行检查后判断为系统严重异常时，可同样通过上述问题检查模块进行安卓问题检查。
[0122]在本发明一可选的实施例中，测试装置还用于采集包括bug数据的符号表文件，并通过共享装置进行存储。
[0123]综上所述，由于本发明采用了上述技术方案，先通过一解析装置对log文件进行解析进而生成占用空间较小的报告文件，根据该报告文件来指派给能够解决相应bug的处理装置，进而极大的提高开发进程，本发明无需昂贵的专家系统软硬件投入；部署简单快速；能适应终端公司手工测试、自动化测试、场测等各种环境需求。
[0124]以上对本发明的较佳实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，其中未尽详细描述的设备和结构应该理解为用本领域中的普通方式予以实施；任何熟悉本领域的技术人员，在不脱离本发明技术方案范围情况下，都可利用上述揭示的方法和技术内容对本发明技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例，这并不影响本发明的实质内容。因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本发明技术方案保护的范围内。
【主权项】
1.一种bug自动处理系统，应用于终端设备的bug处理中，其特征在于，包括: 测试装置，用于采集bug的日志文件，并上传到一共享装置中进行存储； 解析装置，分别与所述测试装置和所述共享装置连接，用于获取并解析所述日志文件，以生成报告文件并上传到一存储装置进行存储，该存储装置与所述测试装置连接； 分配装置，分别与所述测试装置和所述存储装置连接； 处理装置，分别与所述分配装置和所述共享装置连接； 其中，所述测试装置根据所述报告文件下发分配指令至所述分配装置，该分配装置根据接收到的所述分配指令调取所述报告文件并进行分析后，发送至所述处理装置，所述处理装置根据解析后的报告文件，从所述共享装置中获取相应的日志文件，并对bug进行修复。2.如权利要求1所述的bug自动处理系统，其特征在于，所述解析装置包括: 抓取模块，与所述共享装置连接，用于抓取所述日志文件； 判断模块，与所述抓取模块连接，用于根据所述日志文件来判断bug类型，所述bug类型包括未知原因错误类型和重启错误类型； 报告生成模块，连接所述判断模块，用于在未知原因错误类型、重启错误类型的情况下生成所述报告文件。3.如权利要求2所述的bug自动处理系统，其特征在于，所述解析装置还包括: 检查模块，连接所述判断模块，用于对终端设备重启后进行命令行检查； 异常判断模块，连接所述检查模块，用于在命令行检查的模式下进行异常判断； 比较模块，与所述异常判断模块连接，用于比较内核代码段的完整性； 截取模块，与所述比较模块和所述报告生成模块连接，用于截取终端设备的屏幕帧缓冲内容。4.如权利要求3所述的bug自动处理系统，其特征在于，所述异常判断模块包括: 内核异常判断单元、第一看门狗单元、第二看门狗单元和未知原因判断单元，均与所述检查模块相连； 其中，利用所述内核异常判断单元和/或所述第一看门狗单元进行判断过后，通过一拾取模块来拾取异常日志文件打印信息，并传输到所述比较模块； 利用第二看门狗单元和/或未知原因判断单元进行判断过后，通过一跟踪模块来检查系统转储是否完整:若完整，则继续通过一访问记录检查模块来检查最终寄存器的访问记录，之后利用所述比较模块来比较内核代码段的完整性；若不完整，则生成不完整日志文件。5.如权利要求3所述的bug自动处理系统，其特征在于，在经由所述检查模块对终端设备重启并进行命令行检查后，若没有检查到所需字段，则生成不完整日志文件。6.如权利要求2所述的bug自动处理系统，其特征在于，所述bug类型还包括程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型； 当藉由所述判断模块判断出bug类型为程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型中的任意一种或多种时，通过一问题检查模块进行问题检查。7.如权利要求3或6所述的bug自动处理系统，其特征在于，当藉由所述检查模块进行命令行检查后判断为系统严重异常时，通过所述问题检查模块进行问题检查。8.如权利要求1所述的bug自动处理系统，其特征在于，所述测试装置还用于采集bug的符号表文件，并通过所述共享装置进行存储。9.一种bug自动处理方法，应用于终端设备的bug处理中，其特征在于，包括如下步骤: 步骤S1:采集bug的日志文件； 步骤S2:对所述日志文件进行解析，以生成报告文件； 步骤S3:根据所述报告文件来下发分配指令至一分配装置； 步骤S4:分配装置对所述报告文件进行分析后发送至一处理装置，所述处理装置根据所述分配装置发送的解析后的报告文件，获取相应的日志文件，并对bug进行修复。10.如权利要求9所述的bug自动处理方法，其特征在于，在所述步骤SI中，通过一测试装置来采集bug的日志文件，并上传到一共享装置中进行存储。11.如权利要求10所述的bug自动处理方法，其特征在于，在所述步骤S2中，通过一分别与所述测试装置和所述共享装置连接的解析装置来获取并解析所述日志文件，以生成所述报告文件； 其中，所述报告文件通过一存储装置进行存储，该存储装置与所述测试装置连接。12.如权利要求11所述的bug自动处理方法，其特征在于，通过所述解析装置对所述日志文件进行解析以生成所述报告文件的步骤包括: 步骤S21:通过一与所述共享装置连接的抓取模块抓取所述日志文件； 步骤S22:通过一与所述抓取模块连接的判断模块来根据所述日志文件判断bug类型，所述bug类型包括未知原因错误类型和重启错误类型； 利用一报告生成模块在未知原因错误类型、重启错误类型的情况下生成所述报告文件。13.如权利要求12所述的bug自动处理方法，其特征在于，在所述步骤S22中，在重启错误类型的情况下生成所述报告文件的步骤包括: 5221:利用一与所述判断模块连接的检查模块对终端设备重启后进行命令行检查； 5222:利用一与所述检查模块连接的异常判断模块进行异常判断； 5223:利用一比较模块来比较内核代码段的完整性； S224:利用一与所述比较模块连接的截取模块来截取所述终端设备的屏幕帧缓冲内容； S225:利用与所述截取模块连接的报告生成模块来根据所述屏幕帧缓冲内容来生成所述报告文件。14.如权利要求13所述的bug自动处理方法，其特征在于，在所述S222中，进行如下异常判断: 内核异常判断、看门狗快速中断程序判断、看门狗未知程序判断和未知原因判断；其中，完成内核异常判断和/或看门狗快速中断程序判断之后，通过一拾取模块来拾取异常日志文件打印信息，并传输到所述比较模块； 完成看门狗未知程序判断和未知原因判断过后，通过一跟踪模块来检查系统转储是否完整:若完整，则继续通过一访问记录检查模块来检查最终寄存器的访问记录，之后利用所述比较模块来比较内核代码段的完整性；若不完整，则生成不完整日志文件。15.如权利要求13所述的bug自动处理方法，其特征在于，在所述步骤S221中，在经由所述检查模块对终端设备重启并进行命令行检查后，若没有检查到所需字段，则生成不完整日志文件。16.如权利要求12所述的bug自动处理方法，其特征在于，在所述步骤S22中，所述bug类型还包括程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型； 当藉由所述判断模块判断出bug类型为程序未响应错误类型、程序异常退出类型、功能/用户界面错误类型和唤醒异常类型中的任意一种或多种时，通过一问题检查模块进行问题检查。17.如权利要求13或16所述的bug自动处理方法，其特征在于，在所述步骤S221中，当藉由所述检查模块对终端设备重启后进行命令行检查后判断为系统严重异常时，通过所述问题检查模块进行问题检查。18.如权利要求10所述的bug自动处理方法，其特征在于，所述测试装置还用于采集包括bug数据的符号表文件，并通过所述共享装置进行存储。
【文档编号】G06F9/44GK105988818SQ201510100424
【公开日】2016年10月5日
【申请日】2015年3月6日
【发明人】任赓, 康纪滨, 楚恩来, 龚春林, 何春思
【申请人】展讯通信(天津)有限公司