CN111767164B - 一种组装产品中定位崩溃堆栈所属组件的方法及其*** - Google Patents
一种组装产品中定位崩溃堆栈所属组件的方法及其*** Download PDFInfo
- Publication number
- CN111767164B CN111767164B CN202010420117.0A CN202010420117A CN111767164B CN 111767164 B CN111767164 B CN 111767164B CN 202010420117 A CN202010420117 A CN 202010420117A CN 111767164 B CN111767164 B CN 111767164B
- Authority
- CN
- China
- Prior art keywords
- information
- component
- application
- class
- name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/30—Computing systems specially adapted for manufacturing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
Abstract
本发明提供了一种组装产品定位崩溃堆栈所属组件的方法,所述方法为:步骤S1、获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;步骤S2、保存组件信息的同时,根据组件信息和组件库管理方式拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;步骤S3、在java服务端开发一个根据类名查询组件信息的接口;步骤S4、当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过所述接口在数据库中进行查询获得对应的组件信息;提高了测试效率。
Description
技术领域
本发明涉及计算机通讯技术领域,特别是一种组装产品中定位崩溃堆栈所属组件的方法及其***。
背景技术
近几年,为了程序之间各个模块之间的解耦以及高效的开发应用,各大公司推出相应的应用工厂的框架,原各个模块定义为独立的工作的组件,生产一个应用时,选择对应的组件,根据应用工厂的框架,即可生产出一个完整的应用,像生产汽车似的。这样在自动化测试***中收集了很多Crash Bug(崩溃bug),一堆一堆的代码,如何快速定位到所属的组件以及对应版本呢?如何加快bug的解决呢?
现在各大公司都有自己的自动化云测试***,包括UI自动化、性能自动化、兼容性测试、稳定性测试等等,各种测试都会收集大量的Crash日志。这种方式缺点是:大量的Crash日志发给开发员,一个个开发人员排查过去是不是自己的组件、效率低下。
发明内容
为克服上述问题,本发明的目的是提供一种组装产品中定位崩溃堆栈所属组件的方法,精准定位到所属的组件名称和版本,大大提高了测试效率。
本发明采用以下方案实现:一种组装产品中定位崩溃堆栈所属组件的方法,所述方法包括如下步骤:
步骤S1、获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;
步骤S2、保存组件信息的同时,根据组件信息和组件库管理方式拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;
步骤S3、在java服务端开发一个根据类名查询组件信息的接口;
步骤S4、当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过所述的接口在数据库中进行查询获得对应的组件信息。
进一步的,所述步骤S1进一步具体为:对项目中应用所需组件的依赖信息进行配置管理,将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中,解析tree.txt文件获取组件信息,所述组件信息包括项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix;通过Android***API获取应用信息,所述应用信息包括应用的包名和版本信息;将组件信息和应用信息存储到服务端的数据库中。
进一步的,所述S2进一步具体为:设置一组件库,通过Java服务器应用程序Sonatype Nexus Repository Manager对组件库进行管理,通过Nexus域名和所述组件信息得到下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该下载地址下载组件库保存到服务端;解析组件库通过命令jar-tf组件库的路径,即可获取该组件库的所有组件类名,将组件类名保存到服务端的数据库中。
进一步的,所述步骤S4进一步具体为:当一个应用程序发生崩溃时,循环崩溃堆栈,匹配每一行堆栈信息是否包含预先设定的应用的包名关键字,匹配成功后,对这一条堆栈信息进行处理,取出类名,该类即为引起崩溃的类名,并通过所述的接口在数据库中进行查询获得对应的组件信息。
本发明还提供了一种组装产品中定位崩溃堆栈所属组件的***,所述***包括获取信息模块、组件类名获取模块、接口开发模块、以及查询模块;
所述获取信息模块,获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;
所述组件类名获取模块,用于在保存组件信息的同时,根据组件信息和组件库管理方式拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;
所述接口开发模块,用于在java服务端开发一个根据类名查询组件信息的接口;
所述查询模块,用于当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过所述的接口在数据库中进行查询获得对应的组件信息。
进一步的,所述获取信息模块进一步具体为:对项目中应用所需组件的依赖信息进行配置管理,将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中,解析tree.txt文件获取组件信息,所述组件信息包括项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix;通过Android***序API获取应用信息,所述应用信息包括应用的包名和版本信息;将组件信息和应用信息存储到服务端的数据库中。
进一步的,所述组件类名获取模块进一步具体为:设置一组件库,通过Java服务器应用程序Sonatype Nexus Repository Manager对组件库进行管理,通过Nexus域名和所述组件信息得到下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该下载地址下载组件库保存到服务端;解析组件库通过命令jar-tf组件库的路径,即可获取该组件库的所有组件类名,将组件类名保存到服务端的数据库中。
进一步的,所述查询模块进一步具体为:当一个应用程序发生崩溃时,循环崩溃堆栈,匹配每一行堆栈信息是否包含预先设定的应用的包名关键字,匹配成功后,对这一条堆栈信息进行处理,取出类名,该类即为引起崩溃的类名,并通过所述的接口在数据库中进行查询获得对应的组件信息。
本发明的有益效果在于:现有的方法人工分析费时,效率低下,不利于bug的快速解决;而本发明的程序全自动化分析,无需人工介入,精准定位到所属的组件名称和版本,大大提高了测试效率,大大提高了bug的解决速度。
附图说明
图1是本发明的方法流程示意图。
图2是本发明的***框图。
具体实施方式
下面结合附图对本发明做进一步说明。
请参阅图1所示,本发明的一种组装产品中定位崩溃堆栈所属组件的方法,所述方法包括如下步骤:
步骤S1、获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;
步骤S2、保存组件信息的同时,根据组件信息和组件库管理方式拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;
步骤S3、在java服务端开发一个根据类名查询组件信息的接口;
步骤S4、当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过步骤S3的接口在数据库中进行查询获得对应的组件信息。
所述步骤S1进一步具体为:对项目中应用所需组件的依赖信息进行配置管理,将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中,解析tree.txt文件获取组件信息,所述组件信息包括项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix;通过Android***API获取应用信息,所述应用信息包括应用的包名和版本信息;将组件信息和应用信息存储到服务端的数据库中。
所述S2进一步具体为:设置一组件库,通过Java服务器应用程序Sonatype NexusRepository Manager对组件库进行管理,通过Nexus域名和所述组件信息得到下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该下载地址下载组件库保存到服务端;解析组件库通过命令jar-tf组件库的路径,即可获取该组件库的所有组件类名,将组件类名保存到服务端的数据库中。
所述步骤S4进一步具体为:当一个应用程序发生崩溃时,循环崩溃堆栈,匹配每一行堆栈信息是否包含预先设定的(即公司自研产品)的应用的包名的关键字,匹配成功后,对这一条堆栈信息进行处理,取出类名,该类即为引起崩溃的类名,并通过步骤S3的接口在数据库中进行查询获得对应的组件信息。
下面结合一具体实施例对本发明作进一步说明:
S1:获取应用和所需依赖组件的信息服务:
监控程序打包服务,根据程序包获取应用的包名、版本等信息,查询服务端是否存在该应用信息,否,则解析apk应用,对项目中应用所需组件的依赖信息进行配置管理,配置管理:在公司应用工厂的框架中,对应用所需组件进行了依赖信息的配置管理,保存在assets目录下的tree.txt文件下,组件的配置格式为:
‘com.nd.android.audiosdk:audio-trans-sdk-impl:0.1.69.release@aar',按“:”和“@”分割依次是groupId、artifactId、version、suffix;
解析步骤:修改APK包的后缀名为zip,解压zip,获取assets目录下的tree.txt文件,解析tree.txt文件获取项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix。(即组件信息)
应用信息:可通过***Android***API获取应用的包名和版本信息。
综上所述将获取的groupId、artifactId、version、suffix、应用的包名和版本信息上传并保存到服务端数据库待用。
S2:解析组件类服务
下载组件库:行业里一般用Marven私服(一种库包的管理服务)管理自己开发的库,公司的应用工厂使用了这个服务,即通过Sonatype Nexus Repository Manager(一个Java服务器应用程序)对组件的库进行管理,可通过Nexus域名以及S1中得到的组件信息拼出下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该地址下载组件库保存到服务端。
解析组件库的组件类名:通过命令jar-tf组件库的路径,即可获取该组件库的所有类名,将类名保存到服务端数据库。
S3:获取崩溃堆栈发生类的定位算法
当一个APP发生Crash时,Crash的堆栈是各种各样的,甚至有上百行,如何定位到代码的出错的类呢?错误日志的输出首先是报错原因,其次是代码堆栈,这个代码堆栈的输出顺序跟调用顺序是相反的,为什么呢?因为java的方法在执行的时候是在虚拟机栈中执行的,每执行一个方法就会新建一个栈帧然后压入到虚拟机栈中。这是一个后进先出的结构,所以报错的时候也是从被调用者最开始报错,然后调用者依次报错,所以打印错误时的顺序也是报错的位置在最上面,调用者依次向后排。大部分情况下,最上方的报错信息就是代码出错的位置。但是有时候最上方的日志并不是自己的代码,那是因为代码调用了一些第三方jar包的代码。但是这并不影响去定位问题,还是根据上面报错,下面跟随来定位问题,那么真正报错的位置还是在上面。那么只需要从上往下依次找自己的代码即可;第一个找到的的代码类就是代码中引发报错的类。
所以根据上面Java程序崩溃日志的原理,错误日志从上到下依次是崩溃原因、第三方代码或自己代码调用,依次去循环判断每行堆栈信息是否包含公司自研应用的包名的关键字,这个包命名关键字一般公司都有特殊的命名规则,所以第一次匹配到包名的关键字的就是崩溃位置的类。
比如:公司的包命名规则是“com.xx”,在下面的堆栈中,排除掉第一行的崩溃原因,逐条判断是否包含有“com.xx”关键字,由下面案例可知第三行包含,即是错误代码的位置行,因为最后面f2是方法,所以截取掉方法后,com.xx.Test即是引发报错的类。
Exception in thread“main”java.lang.NullPointerException
com.android.Test.f1(TestException.java:22)
com.xx.Test.f2(TestException.java:17);
S4:通过崩溃类名查询组件接口服务
在上面S1和S2中已经获取了应用、组件以及组件类名等信息,通过崩溃类名在组件类名、应用信息数据库中即可查询出该崩溃类类所属的组件,所以现在实现一个崩溃类名查询组件接口服务供第三方使用。注意,在收到请求的堆栈后,经过S3的处理获取崩溃类后再进行查询获取组件信息。这样能精准定位到所属的组件名称和版本,大大提高了测试效率。
请参阅图2所示,本发明的一种组装产品中定位崩溃堆栈所属组件的***,所述***包括获取信息模块、组件类名获取模块、接口开发模块、以及查询模块;
所述获取信息模块,获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;
所述组件类名获取模块,用于在保存组件信息的同时,根据组件信息和组件库管理方式拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;
所述接口开发模块,用于在java服务端开发一个根据类名查询组件信息的接口;
所述查询模块,用于当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过所述接口在数据库中进行查询获得对应的组件信息。
所述获取信息模块进一步具体为:对项目中应用所需组件的依赖信息进行配置管理,将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中,解析tree.txt文件获取组件信息,所述组件信息包括项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix;通过Android***API获取应用信息,所述应用信息包括应用的包名和版本信息;将组件信息和应用信息存储到服务端的数据库中。
所述组件类名获取模块进一步具体为:设置一组件库,通过Java服务器应用程序Sonatype Nexus Repository Manager对组件库进行管理,通过Nexus域名和所述组件信息得到下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该下载地址下载组件库保存到服务端;解析组件库通过命令jar-tf组件库的路径,即可获取该组件库的所有组件类名,将组件类名保存到服务端的数据库中。
进一步的,所述查询模块进一步具体为:当一个应用程序发生崩溃时,循环崩溃堆栈,匹配每一行堆栈信息是否包含预先设定的应用的包名的关键字,匹配成功后,对这一条堆栈信息进行处理,取出类名,该类即为引起崩溃的类名,并通过所述的接口在数据库中进行查询获得对应的组件信息。
以上所述仅为本发明的较佳实施例,凡依本发明申请专利范围所做的均等变化与修饰,皆应属本发明的涵盖范围。
Claims (6)
1.一种组装产品中定位崩溃堆栈所属组件的方法,其特征在于:所述方法包括如下步骤:
步骤S1、获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;所述步骤S1进一步具体为:对项目中应用所需组件的依赖信息进行配置管理,将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中,解析tree.txt文件获取组件信息,所述组件信息包括项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix;通过Android***API获取应用信息,所述应用信息包括应用的包名和版本信息;将组件信息和应用信息存储到服务端的数据库中;
步骤S2、保存组件信息的同时,根据组件信息和组件库管理规则拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;
步骤S3、在java服务端开发一个根据类名查询组件信息的接口;
步骤S4、当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过S3的接口在数据库中进行查询获得对应的组件信息。
2.根据权利要求1所述的一种组装产品中定位崩溃堆栈所属组件的方法,其特征在于:所述S2进一步具体为:设置一组件库,通过Java服务器应用程序Sonatype NexusRepository Manager对组件库进行管理,通过Nexus域名和所述组件信息得到下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该下载地址下载组件库保存到服务端;解析组件库通过命令jar -tf 组件库的路径,即可获取该组件库的所有组件类名,将组件类名保存到服务端的数据库中。
3.根据权利要求1所述的一种组装产品中定位崩溃堆栈所属组件的方法,其特征在于:所述步骤S4进一步具体为:当一个应用程序发生崩溃时,循环崩溃堆栈,匹配每一行堆栈信息是否包含公司自研产品的应用包名关键字,匹配成功后,对这一条堆栈信息进行处理,取出类名,该类即为引起崩溃的类名,并通过S3的接口在数据库中进行查询获得对应的组件信息。
4.一种组装产品中定位崩溃堆栈所属组件的***,其特征在于:所述***包括获取信息模块、组件类名获取模块、接口开发模块、以及查询模块;
所述获取信息模块,获取项目中应用和应用所需依赖组件的信息,所述信息包括组件信息和应用信息,并上传保存到服务端的数据库;所述获取信息模块进一步具体为:对项目中应用所需组件的依赖信息进行配置管理,将组件所依赖的依赖信息保存在assets目录下的tree.txt文件中,解析tree.txt文件获取组件信息,所述组件信息包括项目组织唯一的标识符groupId、项目的唯一的标识符artifactId、版本号version、以及后缀名suffix;通过Android***API获取应用信息,所述应用信息包括应用的包名和版本信息;将组件信息和应用信息存储到服务端的数据库中;
所述组件类名获取模块,用于在保存组件信息的同时,根据组件信息和组件库管理规则拼出组件库的下载地址,再通过Java服务对组件库进行下载和解析,解析获取组件库所有的类名,将类名保存到服务端的数据库;
所述接口开发模块,用于在java服务端开发一个根据类名查询组件信息的接口;
所述查询模块,用于当一个应用程序发生崩溃时,通过获取崩溃堆栈发生类的定位算法,获取引起崩溃的类名,并通过S3的接口在数据库中进行查询获得对应的组件信息。
5.根据权利要求4所述的一种组装产品中定位崩溃 堆栈所属组件的***,其特征在于:所述组件类获取模块进一步具体为:设置一组件库,通过Java服务器应用程序SonatypeNexus Repository Manager对组件库进行管理,通过Nexus域名和所述组件信息得到下载地址:Nexus域名/groupId/artifactId/version/artifactId-version.suffix,然后通过该下载地址下载组件库保存到服务端;解析组件库通过命令jar -tf 组件库的路径,即可获取该组件库的所有组件类名,将组件类名保存到服务端的数据库中。
6.根据权利要求4所述的一种组装产品中定位崩溃堆栈所属组件的***,其特征在于:所述查询模块进一步具体为:当一个应用程序发生崩溃时,循环崩溃堆栈,匹配每一行堆栈信息是否包含公司自研产品的应用包名关键字,匹配成功后,对这一条堆栈信息进行处理,取出类名,该类即为引起崩溃的类名,并通过S3的接口在数据库中进行查询获得对应的组件信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010420117.0A CN111767164B (zh) | 2020-05-18 | 2020-05-18 | 一种组装产品中定位崩溃堆栈所属组件的方法及其*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010420117.0A CN111767164B (zh) | 2020-05-18 | 2020-05-18 | 一种组装产品中定位崩溃堆栈所属组件的方法及其*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111767164A CN111767164A (zh) | 2020-10-13 |
CN111767164B true CN111767164B (zh) | 2022-08-09 |
Family
ID=72719403
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010420117.0A Active CN111767164B (zh) | 2020-05-18 | 2020-05-18 | 一种组装产品中定位崩溃堆栈所属组件的方法及其*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111767164B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112346900B (zh) * | 2020-11-10 | 2023-09-01 | 广州虎牙科技有限公司 | 符号表的下载控制、堆栈解析方法、装置、设备及介质 |
CN113591980A (zh) * | 2021-07-30 | 2021-11-02 | 上海识装信息科技有限公司 | 一种应用程序崩溃堆栈指派方法、装置及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104572327A (zh) * | 2014-12-24 | 2015-04-29 | 北京奇虎科技有限公司 | 一种浏览器崩溃的处理方法、装置和*** |
CN107704356A (zh) * | 2017-06-12 | 2018-02-16 | 平安科技(深圳)有限公司 | 异常堆栈信息获取方法、装置及计算机可读存储介质 |
CN110727581A (zh) * | 2019-09-06 | 2020-01-24 | 网宿科技股份有限公司 | 崩溃定位方法与电子设备 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6785848B1 (en) * | 2000-05-15 | 2004-08-31 | Microsoft Corporation | Method and system for categorizing failures of a program module |
-
2020
- 2020-05-18 CN CN202010420117.0A patent/CN111767164B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104572327A (zh) * | 2014-12-24 | 2015-04-29 | 北京奇虎科技有限公司 | 一种浏览器崩溃的处理方法、装置和*** |
CN107704356A (zh) * | 2017-06-12 | 2018-02-16 | 平安科技(深圳)有限公司 | 异常堆栈信息获取方法、装置及计算机可读存储介质 |
CN110727581A (zh) * | 2019-09-06 | 2020-01-24 | 网宿科技股份有限公司 | 崩溃定位方法与电子设备 |
Also Published As
Publication number | Publication date |
---|---|
CN111767164A (zh) | 2020-10-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11366747B2 (en) | Unified test automation system | |
US7191364B2 (en) | Automatic root cause analysis and diagnostics engine | |
US9703677B2 (en) | Code coverage plugin | |
US8037195B2 (en) | Method and apparatus for managing components in an IT system | |
US20120159443A1 (en) | System and method for reducing test effort by object risk analysis | |
US20100146325A1 (en) | Systems and methods for correcting software errors | |
CN111158741B (zh) | 监控业务模块对第三方类库依赖关系变化的方法及装置 | |
CN111767164B (zh) | 一种组装产品中定位崩溃堆栈所属组件的方法及其*** | |
US8949812B2 (en) | System and method for updating hard-coded dependencies | |
CN110716873B (zh) | 一种硬件兼容性知识库构建方法 | |
CN111090452A (zh) | 服务环境的切换方法及计算机可读存储介质 | |
US11573780B2 (en) | Automated generation of status chains for software updates | |
CN112099880B (zh) | 场景驱动的应用程序约减方法和*** | |
CN111611207A (zh) | 状态数据处理方法、装置及计算机设备 | |
CN111966390A (zh) | 项目构建方法、***、终端设备及存储介质 | |
CN112965913A (zh) | 一种Java软件依赖冲突问题自动化修复的方法 | |
CN116414774A (zh) | 文件迁移方法、装置、设备及存储介质 | |
CN114816816A (zh) | 崩溃堆栈信息处理方法、装置、设备及存储介质 | |
US20160147547A1 (en) | Metadata-based class loading using a content repository | |
CN107341110B (zh) | 一种软件测试定位补丁修改及影响范围的工具及实现方法 | |
Lee et al. | Unified debugging of distributed systems with recon | |
US20220334955A1 (en) | Automated unit testing in a mainframe cics environment | |
CN110674024A (zh) | 电子设备集成测试***及其方法 | |
CN111367796B (zh) | 应用程序调试方法及装置 | |
CN115168175A (zh) | 程序错误解决方法、装置、电子设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |