应用程序的测试方法及装置与流程

本发明涉及应用程序领域，具体而言，涉及一种应用程序的测试方法及装置。

背景技术：

将一段能够实现某个特定功能的代码注入到某个应用程序中之后，运行该应用程序得到的应用进程具有该功能，举例来说，假设目标代码的作用是拦截广告，那么将目标代码注入到应用程序a中之后，在运行应用程序a时，就能够实现对广告的拦截。但是将目标代码注入到应用程序a之后，有可能会影响应用程序a运行的稳定性。因此，需要对应用程序a进行测试，以判断目标代码的注入对应用程序a的运行产生的影响的强弱。

现有技术中主要根据信号处理器来监控注入的代码对应用进程的稳定性的影响。具体过程为：android中的应用程序可以处于两种运行状态：native和java虚拟机。native和普通的linux程序一样，而java虚拟机则是运行的java字节码。当native的代码运行发生错误时，内核会发送信号给进程，并调用进程的信号处理器来处理后默认的处理结果是进程异常退出。在java虚拟机也有类似的机制，当发生异常而应用代码没有捕获时，虚拟机会调用线程的异常处理器来处理，默认处理结果也是进程异常退出。两种状态下，应用都可以注册自己处理器来替换默认处理器接收这类异常消息，从而可以在进程退出前做一些善后的工作：例如记录日志等。利用这个技术特点可以监控应用进程自身的异常情况。

现有技术中方法主要的缺点是只能监控单个应用自身的异常退出，无法同时知道应用的正常退出和异常退出情况，因此测试应用程序的准确度低。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种应用程序的测试方法及装置，以至少解决现有技术中测试应用程序的准确度低的技术问题。

根据本发明实施例的一个方面，提供了一种应用程序的测试方法，包括：运行目标应用程序，其中，所述目标应用程序是待测试的应用程序，所述目标应用程序中注入有目标代码，在运行所述目标应用程序的过程中产生了目标应用进程；监控所述目标应用进程的运行数据，其中，所述运行数据包括所述目标应用进程的正常退出数据和异常退出数据；根据所述正常退出数据和所述异常退出数据确定所述目标应用进程的稳定性参数；判断所述稳定性参数是否满足预设条件；在判断出所述稳定性参数不满足所述预设条件的情况下，从所述目标应用程序中删除所述目标代码。

根据本发明实施例的另一方面，还提供了一种应用程序的测试装置，包括：运行单元，用于运行目标应用程序，其中，所述目标应用程序是待测试的应用程序，所述目标应用程序中注入有目标代码，在运行所述目标应用程序的过程中产生了目标应用进程；监控单元，用于监控所述目标应用进程的运行数据，其中，所述运行数据包括所述目标应用进程的正常退出数据和异常退出数据；确定单元，用于根据所述正常退出数据和所述异常退出数据确定所述目标应用进程的稳定性参数；判断单元，用于判断所述稳定性参数是否满足预设条件；删除单元，用于在判断出所述稳定性参数不满足所述预设条件的情况下，从所述目标应用程序中删除所述目标代码。

在本发明实施例中，在目标应用程序中注入有目标代码，运行目标应用程序产生目标应用进程，根据目标应用进程的正常退出数据和异常退出数据确定目标应用进程的稳定性参数，如果该稳定性参数满足预设条件，说明目标代码对目标应用进程的稳定性的影响较小；如果该稳定性参数不满足预设条件，说明目标代码对目标应用进程的稳定性的影响较大，在目标代码对目标应用进程的稳定性的影响较大的情况下，从目标应用程序中删除目标代码，由于能够同时获得应用进程的正常退出情况和异常退出情况，因此，这种测试应用程序的方式全面考虑到了注入的代码对应用程序运行的影响，达到了提高应用程序的测试的准确度的技术效果，进而解决了现有技术中测试应用程序的准确度低的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的硬件环境的示意图；

图2是根据本发明实施例的应用程序的测试方法的流程图；

图3是根据本发明实施例的应用异常退出的监控流程图；

图4是根据本发明实施例的劫持的dlopen函数执行流程图；

图5是根据本发明实施例的应用程序的测试装置的示意图；

图6是根据本发明实施例的服务器的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

技术术语解释：

logcat：android系统的日志系统，外部工具可以通过logcat来读取系统运行期间的日志信息。

墓碑文件：android系统发生异常时，系统会记录异常现场的一些信息到文件，通常会保存一份到/data/system/dropbox目录下。

debuggerd：debuggerd是android系统的自带进程，当有应用进程发生异常而死亡时，debuggerd进程会读取crash进程的堆栈信息并存储墓碑文件中，同时将crash日志输出到logcat。

binder服务对象：android系统中跨进程通信的服务端对象，对应的另一方是binder客户对象。当服务对象死亡时，会发送通知给注册了死亡监听消息的binder客户对象。

需要注意的是，本发明实施例中的应用进程退出包括应用进程异常退出和应用进程正常退出。

根据本发明实施例，提供了一种应用程序的测试方法的实施例。

可选地，在本实施例中，上述应用程序的测试方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。如图1所示，服务器102通过网络与终端104进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端104并不限定于pc、手机、平板电脑等。本发明实施例的应用程序的测试方法可以由终端104来执行，也可以由服务器102来执行。终端104执行本发明实施例的应用程序的测试方法可以是由安装在其上的客户端来执行。

在应用程序的测试方法由终端104来执行的情况下，该方法的过程如下：终端104的目标应用程序中注入有目标代码，运行目标应用程序产生目标应用进程，终端104监控目标应用进程的运行数据，运行数据包括目标应用进程正常退出数据和异常退出数据。终端104根据正常退出数据和异常退出数据确定目标应用进程的稳定性参数，判断稳定性参数是否满足预设条件。在终端104判断出稳定性参数不满足预设条件的情况下，说明在目标应用程序中注入目标代码对目标应用进程的稳定性的影响较大，此时需要从目标应用程序中删除目标代码。

在应用程序的测试方法由服务器102来执行的情况下，本发明实施例提供的网络构架图如图1所示。如图1所示，终端104的目标应用程序中注入有目标代码，运行目标应用程序产生目标应用进程，终端104监控目标应用进程的运行数据，运行数据包括目标应用进程正常退出数据和异常退出数据。终端104将正常退出数据和异常退出数据发送给服务器102。服务器102接收目标应用进程的正常退出数据和异常退出数据，并根据正常退出数据和异常退出数据确定目标应用进程的稳定性参数。服务器102判断稳定性参数是否满足预设条件。在服务器102判断出稳定性参数不满足预设条件的情况下，说明在目标应用程序中注入目标代码对目标应用进程的稳定性的影响较大，此时需要向终端104发送指令，该指令用于指示从目标应用程序中删除目标代码。

根据本发明实施例，提供了一种应用程序的测试方法，如图2所示，该方法包括以下步骤：

步骤s202，运行目标应用程序，其中，目标应用程序是待测试的应用程序，目标应用程序中注入有目标代码，在运行目标应用程序的过程中产生了目标应用进程。

步骤s204，监控目标应用进程的运行数据，其中，运行数据包括目标应用进程的正常退出数据和异常退出数据。

步骤s206，根据正常退出数据和异常退出数据确定目标应用进程的稳定性参数。

步骤s208，判断稳定性参数是否满足预设条件。

步骤s210，在判断出稳定性参数不满足预设条件的情况下，从目标应用程序中删除目标代码。

目标代码可以是能够实现某个功能的一段代码。举例来说，假设目标代码的作用是拦截广告，那么将目标代码注入到应用程序a中之后，在运行应用程序a时，就能够实现对广告的拦截。但是将目标代码注入到应用程序a之后，有可能会影响应用程序a运行的稳定性。因此，需要对应用程序a进行测试，以判断目标代码的注入对应用程序a的运行产生的影响强弱。

在本发明实施例中，能够表明应用程序运行的稳定性的参数都可以作为应用进程的稳定性参数，稳定性参数可以有多种表示形式，下面列出几种进行说明。

稳定性参数的第一种表示形式：

si＝ai/bi公式(1)

其中，si表示目标应用进程i的稳定性参数，ai表示目标应用进程i在一段时间之内的异常退出次数(根据异常退出数据获得)，bi表示目标应用进程i在该段时间之内的退出次数，其中，bi＝ai+ci，ci表示目标应用进程i在该段时间之内的正常退出次数(根据正常退出数据获得)。

公式(1)所示出的稳定性参数si是目标应用进程i的异常率，通常一个应用在没有重大bug的情况下，异常率应该是非常低甚至接近于0，如果异常率高于1％，一般可认为应用有严重的质量问题。

稳定性参数的第二种表示形式：

si＝ai/ci公式(2)

其中，si表示目标应用进程i的稳定性参数，ai表示目标应用进程i在一段时间之内的异常退出次数(根据异常退出数据获得)，ci表示目标应用进程i在该段时间之内的正常退出次数(根据正常退出数据获得)。

当目标应用程序有多个(大于等于2)时，运行每一个目标应用程序都会产生目标应用进程，因此，一共会产生多个目标应用进程，在这种情况下，上述稳定性参数可以认为是综合n个目标应用进程的稳定性状况得到的，稳定性参数可以是这多个目标应用进程各自的稳定性参数的加权平均。即，稳定性参数的第三种表示形式：

n表示一共有n个目标应用程序，运行每个目标应用程序都得到一个目标应用进程，即，一共有n个目标应用进程。s表示综合n个目标应用进程的稳定性状况得到的稳定性参数。

其中，si表示目标应用进程i的稳定性参数，si可以由上述公式(1)或者公式(2)计算出来。

wi表示目标应用进程i的权重。可以根据不同目标应用程序的重要程度，将不同的目标应用程序对应的目标应用进程赋予不同的权重值。这种计算稳定性参数的方法的好处是：多个应用程序中均注入了目标代码，目标代码对应用程序对应的应用进程的稳定性的影响可能是不相同的，对一些应用进程的稳定性的影响较大，对另外一些应用进程的稳定性的影响较小。对于比较重要的应用程序，将其对应的应用进程的权重赋予较大的数值，对于比较不重要的应用程序，将其对应的应用进程的权重赋予较小的数值，这样，能够突显出目标代码对重要的应用进程的稳定性的影响。

当目标应用程序有多个(大于等于2)时，稳定性参数还可以有第四种表示形式：

s＝a/b公式(4)

s表示综合n个目标应用进程的稳定性状况得到的稳定性参数。

a表示n个目标应用进程的异常退出次数的总和，ai表示目标应用进程i在一段时间之内的异常退出次数(根据异常退出数据获得)。

b表示n个目标应用进程的退出次数的总和，bi表示目标应用进程i在该段时间之内的退出次数。

通过考虑多个应用进程的稳定性状况，得到一个稳定性参数，根据该稳定性参数判断注入目标代码对系统应用进程的影响强弱，达到了提高判断的准确度的效果。

在得到稳定性参数之后，判断稳定性参数是否满足预设条件。预设条件可以是一个数值范围，例如，预设条件是稳定性参数小于0.01％。

当稳定性参数满足预设条件时，认为注入的代码对应用进程的稳定性影响较小。当稳定性参数不满足预设条件时，认为注入的目标代码对应用进程的稳定性影响较大，需要从应用程序中删除注入的目标代码。

在本发明实施例中，在目标应用程序中注入有目标代码，运行目标应用程序产生目标应用进程，根据目标应用进程的正常退出数据和异常退出数据确定目标应用进程的稳定性参数，如果该稳定性参数满足预设条件，说明目标代码对目标应用进程的稳定性的影响较小；如果该稳定性参数不满足预设条件，说明目标代码对目标应用进程的稳定性的影响较大，在目标代码对目标应用进程的稳定性的影响较大的情况下，从目标应用程序中删除目标代码，由于能够同时获得应用进程的正常退出情况和异常退出情况，因此，这种测试应用程序的方式全面考虑到了注入的代码对应用程序运行的影响，解决了现有技术中测试应用程序的准确度低的技术问题，达到了提高应用程序的测试的准确度的技术效果。

监控目标应用进程的运行数据的过程可以是这样的：在目标应用进程中创建第一对象，其中，第一对象随目标应用进程的退出而被销毁；监控第一对象是否被销毁；在监控到第一对象被销毁时确定目标应用进程退出，其中，目标应用进程退出包括异常退出和正常退出；将目标应用进程退出时产生的数据作为第一退出数据。在目标应用进程异常退出的情况下，会产生异常退出数据；在目标应用进程正常退出和异常退出两种情况下，都会产生第一退出数据。

第一对象是在目标应用进程空间内创造的一个具有生命周期的对象，第一对象和其所在的进程同生死，当其所在的进程退出时，第一对象会被销毁。因此，通过监控第一对象是否被销毁，能够得知其所在的进程是否退出。

第一对象可以是binder对象、socket对象等。

在第一对象是binder对象的情况下，监控第一对象是否被销毁的过程如下：注册binder服务对象的第一通知，其中，第一通知用于指示binder所在的进程已退出；判断是否检测到第一通知；在检测到第一通知的情况下，确定binder对象被销毁。

binder是android系统的跨进程通信的一种机制，并且会在binder对象死亡时(即binder所在的进程退出)向其客户端发送死亡通知(即第一通知)。监控客户端首先注入目标进程，创建binder服务对象。然后注册该binder服务对象的死亡通知，就可以获得目标应用进程的退出次数(第一退出数据)。

在第一对象是socket对象的情况下，监控第一对象是否被销毁的过程如下：调用目标函数，其中，目标函数用于接收目标应用进程发送的信息，并且在目标应用进程退出的情况下，目标函数退出；判断是否检测到目标函数退出；在检测到目标函数退出的情况下，确定socket对象被销毁。

目标函数是用于接收目标应用进程发送的信息的一个函数，当目标应用进程退出时，目标函数会随之退出，因此，通过检测目标函数是否退出，能够得知socket对象是否被销毁，从而得知进程是否退出。

可选地，监控目标应用进程的运行数据包括：获取目标应用进程的异常退出数据，其中，在目标应用进程异常退出的情况下，会产生异常退出数据；获取目标应用进程的第一退出数据，其中，在目标应用进程正常退出和异常退出两种情况下，都会产生第一退出数据；根据异常退出数据和第一退出数据获取正常退出数据。

目标应用进程的运行数据包括第一退出数据。第一退出数据的获取过程上文已经进行了详细说明。

获取应用的异常退出数据可以采用以下两种方法中的任意一种：

获取应用的异常退出数据的第一种方法：

利用墓碑文件获取应用的异常退出数据。根据读取到的墓碑文件目录判断墓碑文件目录是否发生了改变；如果墓碑文件目录发生了改变，则确定目标应用进程发生了异常退出；将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

由于android系统的特点，在应用进程正常退出时，不会产生墓碑文件；在应用发生异常退出时，会记录一个墓碑文件到特定的目录，因此通过监控该目录的写文件等事件，就可以获知有进程发生异常，通过解析墓碑文件的具体内容，可以获知发生异常的具体应用信息。如果墓碑文件目录发生了改变，则说明目标应用进程发生了异常退出。

根据读取到的墓碑文件目录判断墓碑文件目录是否发生了改变，这个过程可以使用下述方法(a)或者方法(b)实现。

方法(a)：创建目录修改事件监听器，其中，在创建目录修改事件监听器之后，如果有应用进程发生异常退出，系统会生成墓碑文件；判断系统是否生成了墓碑文件；在系统生成了墓碑文件的情况下，确定墓碑文件目录发生了改变。将目标应用进程发生异常退出时产生的运行数据作为异常退出数据包括：解析墓碑文件，得到异常退出数据。

利用墓碑文件可以获知全部应用的异常退出，可以采用inotify机制监控墓碑文件目录的修改事件，该方法实时性强。具体过程是：首先创建一个目录修改事件监听器(通过inotify)，在应用发生异常退出时，系统会生成一个异常信息文件(墓碑文件)，该文件头部会包含是哪个应用哪个进程发生异常。通过对异常信息文件的简单解析，就可以定位出应用的异常退出。

方法(b)：采用定时扫描墓碑文件目录的方式来发现新的修改。每隔一定的时间，扫描一次墓碑文件目录，如果发现墓碑文件目录改变了，则说明目标应用进程发生了异常退出。

图3是根据本发明实施例的应用异常退出的监控流程图。

如图3所示，监控应用启动对进程的监控。守护进程监控墓碑目录。当第三方应用进程发生异常退出的情况下，android系统发出修改墓碑文件的指令，守护进程根据该指令修改墓碑文件，当监控应用监控到墓碑文件被修改之后，确定第三方应用发生了异常退出。

本发明实施例提供的应用程序的测试方法能够获得应用的全部退出情况下产生的退出数据(即上述第一退出数据)，并计算出应用的稳定性指标(上述稳定性参数)，而现有技术的方案仅仅获得应用异常退出的次数，因此，本发明实施例提供的应用程序的测试方法得到的测试结果更加准确，同时也能监控整个系统中的全部应用，对于会对整个系统有潜在影响的手机管理类工具而言，有非常大的价值。

获取应用的异常退出数据的第二种方法：

运行调试程序，其中，运行调试程序的过程中产生了第一进程；检测第一进程是否创建了墓碑文件；在检测到第一进程创建了墓碑文件的情况下，确定目标应用进程发生了异常退出；将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。其中，第一进程可以是debuggerd进程。debuggerd进程是上述第一种方法提到的异常信息文件(墓碑文件)的创建者，因此通过注入该进程拦截它创建文件的动作(创建文件的动作是通过dlopen函数执行的)，达到了拦截应用异常崩溃的消息的效果，能够得到应用异常退出的次数。图4是根据本发明实施例的劫持的dlopen函数执行流程图。

如图4所示，监控应用注入第三方进程，第三方应用进程创建binder服务，当第三方应用进程异常退出时，第三方应用进程向监控应用发送binder死亡通知(即上述第一通知)。

本发明实施例提供的应用程序的测试方法不仅可以监控应用的正常退出和异常退出，而且可以覆盖整个系统的全部应用进程，对于想评估自身对系统中其他应用稳定性的影响的应用，本测试方法得出的结果具有非常重要的参考意义。

本发明实施例提供的应用程序的测试方法，可以应用于android系统安全类和测试工具类应用上。例如，应用a是android系统的一个测试工具类应用。将本发明实施例提供的应用程序的测试方法应用于应用a上，能够获知全局广告拦截功能(即目标代码的作用是实现广告拦截)是否会造成应用b频繁发生异常退出，从而可以在超出某一个预警比例的时候，关闭对应用b的广告拦截。

例如，终端上一共有10个应用程序，分别为应用程序b1、应用程序b2、……、应用程序b10。将目标代码(目标代码的作用是实现广告拦截)注入这10个应用程序中。使用应用a监控应用程序b1、应用程序b2、……、应用程序b10对应的应用进程的所有退出情况(包括正常退出情况和异常退出情况)，并根据第一退出数据和异常退出数据分别计算应用程序b1、应用程序b2、……、应用程序b10对应的应用进程的异常率。应用进程的异常率(稳定性参数)可以使用前文所述的公式(1)计算。

假设得到10个应用进程的异常率如表1所示。

表1

注入同一段目标代码之后，应用程序b1、应用程序b2、……、应用程序b10的应用进程的异常率是不一样的，由于异常率是应用进程的异常退出次数除以应用进程的所有退出次数得到的，因此，异常率越高，说明应用进程异常退出越频繁，应用进程的运行稳定性越差。

在应用程序没有重大bug的情况下，异常率应该是一个很小的数，接近于0。如果一个应用程序对应的应用进程的异常率大于1％，那么可以认为该应用有严重的质量问题。

从表1中可以看出，应用程序b1和应用程序b2对应的应用进程的异常率较大，均大于1％，这说明目标代码的注入严重影响了应用程序b1和应用程序b2对应的应用进程的运行的稳定性。在此种情况下，需要将注入到应用程序b1和应用程序b2中的目标代码进行删除，以保证应用程序b1和应用程序b2对应的应用进程的运行的稳定性。将注入到应用程序b1和应用程序b2中的目标代码进行删除之后，在应用程序b1和应用程序b2对应的应用进程运行时，不会拦截广告。

应用程序b3至应用程序b10对应的应用进程的异常率较小，均远远小于1％，这说明目标代码的注入对应用程序b3至应用程序b10对应的应用进程的运行的稳定性的影响很小，可以忽略不计。在应用程序b3至应用程序b10对应的应用进程运行时，会拦截广告。

在本发明实施例中，具有root权限，并对android系统或是普通应用进行代码注入的应用，可以使用该方法来判断自己的注入行为是否会影响第三方进程的稳定性，从而预先进行避让或做出技术上的适配。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

根据本发明实施例，还提供了一种用于实施上述应用程序的测试方法的应用程序的测试装置，如图5所示，该装置包括：运行单元10、监控单元20、确定单元30、判断单元40、删除单元50。

运行单元10，用于运行目标应用程序，其中，目标应用程序是待测试的应用程序，目标应用程序中注入有目标代码，在运行目标应用程序的过程中产生了目标应用进程。

监控单元20，用于监控目标应用进程的运行数据，其中，运行数据包括目标应用进程的正常退出数据和异常退出数据。

确定单元30，用于根据正常退出数据和异常退出数据确定目标应用进程的稳定性参数。

判断单元40，用于判断稳定性参数是否满足预设条件。

删除单元50，用于在判断出稳定性参数不满足预设条件的情况下，从目标应用程序中删除目标代码。

可选地，监控单元20包括：创建子单元、监控子单元、第一确定子单元、第二确定子单元。创建子单元，用于在目标应用进程中创建第一对象，其中，第一对象随目标应用进程的退出而被销毁。监控子单元，用于监控第一对象是否被销毁。第一确定子单元，用于在监控到第一对象被销毁时确定目标应用进程退出，其中，目标应用进程退出包括异常退出和正常退出。第二确定子单元，用于将目标应用进程退出时产生的数据作为第一退出数据。

可选地，监控子单元包括：注册模块、第一判断模块、第一确定模块。注册模块，用于注册第一对象的第一通知，其中，第一通知用于指示第一对象所在的进程已退出。第一判断模块，用于判断是否检测到第一通知。第一确定模块，用于在检测到第一通知的情况下，确定第一对象被销毁。

可选地，监控单元20包括：第一获取子单元、第二获取子单元、第三获取子单元。第一获取子单元，用于获取目标应用进程的异常退出数据，其中，在目标应用进程异常退出的情况下，会产生异常退出数据。第二获取子单元，用于获取目标应用进程的第一退出数据，其中，在目标应用进程正常退出和异常退出两种情况下，都会产生第一退出数据。第三获取子单元，用于根据异常退出数据和第一退出数据获取正常退出数据。

可选地，监控单元20包括：判断子单元、第三确定子单元、第四确定子单元。判断子单元，用于根据读取到的墓碑文件目录判断墓碑文件目录是否发生了改变。第三确定子单元，用于如果墓碑文件目录发生了改变，则确定目标应用进程发生了异常退出。第四确定子单元，用于将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

可选地，判断子单元包括：创建模块、第二判断模块、第二确定模块。创建模块，用于创建目录修改事件监听器，其中，在创建目录修改事件监听器之后，如果有应用进程发生异常退出，系统会生成墓碑文件。第二判断模块，用于判断系统是否生成了墓碑文件。第二确定模块，用于在系统生成了墓碑文件的情况下，确定墓碑文件目录发生了改变。第四确定子单元包括：解析模块。解析模块，用于解析墓碑文件，得到异常退出数据。

可选地，监控单元20包括：运行子单元、检测子单元、第五确定子单元、第六确定子单元。运行子单元，用于运行调试程序，其中，运行调试程序的过程中产生了第一进程。检测子单元，用于检测第一进程是否创建了墓碑文件。第五确定子单元，用于在检测子单元检测到第一进程创建了墓碑文件的情况下，确定目标应用进程发生了异常退出。第六确定子单元，用于将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

根据本发明实施例，还提供了一种用于实施上述应用程序的测试方法的服务器，如图6所示，该服务器主要包括处理器601、显示器603、数据接口604、存储器605和网络接口606，其中：

数据接口604则主要通过数据传输的方式将目标应用进程的运行数据传输给处理器901。

存储器605主要用于存储目标应用进程的运行数据、稳定性参数。

网络接口606主要用于与终端和其他服务器进行网络通信。

显示器603主要用于显示目标应用进程的运行数据。

处理器601主要用于执行如下操作：

运行目标应用程序，其中，目标应用程序是待测试的应用程序，目标应用程序中注入有目标代码，在运行目标应用程序的过程中产生了目标应用进程；监控目标应用进程的运行数据，其中，运行数据包括目标应用进程的正常退出数据和异常退出数据；根据正常退出数据和异常退出数据确定目标应用进程的稳定性参数；判断稳定性参数是否满足预设条件；在判断出稳定性参数不满足预设条件的情况下，从目标应用程序中删除目标代码。

处理器601还用于执行：在目标应用进程中创建第一对象，其中，第一对象随目标应用进程的退出而被销毁；监控第一对象是否被销毁；在监控到第一对象被销毁时确定目标应用进程退出，其中，目标应用进程退出包括异常退出和正常退出；将目标应用进程退出时产生的数据作为第一退出数据。

处理器601还用于执行：注册第一对象的第一通知，其中，第一通知用于指示第一对象所在的进程已退出；判断是否检测到第一通知；在检测到第一通知的情况下，确定第一对象被销毁。

处理器601还用于执行：获取目标应用进程的异常退出数据，其中，在目标应用进程异常退出的情况下，会产生异常退出数据；获取目标应用进程的第一退出数据，其中，在目标应用进程正常退出和异常退出两种情况下，都会产生第一退出数据；根据异常退出数据和第一退出数据获取正常退出数据。

处理器601还用于执行：根据读取到的墓碑文件目录判断墓碑文件目录是否发生了改变；如果墓碑文件目录发生了改变，则确定目标应用进程发生了异常退出；将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

处理器601还用于执行：创建目录修改事件监听器，其中，在创建目录修改事件监听器之后，如果有应用进程发生异常退出，系统会生成墓碑文件；判断系统是否生成了墓碑文件；在系统生成了墓碑文件的情况下，确定墓碑文件目录发生了改变，将目标应用进程发生异常退出时产生的运行数据作为异常退出数据包括：解析墓碑文件，得到异常退出数据。

处理器601还用于执行：运行调试程序，其中，运行调试程序的过程中产生了第一进程；检测第一进程是否创建了墓碑文件；在检测到第一进程创建了墓碑文件的情况下，确定目标应用进程发生了异常退出；将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于存储本发明实施例的方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于移动通信网络、广域网、城域网或局域网的网络中的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

s1，运行目标应用程序，其中，目标应用程序是待测试的应用程序，目标应用程序中注入有目标代码，在运行目标应用程序的过程中产生了目标应用进程；

s2，监控目标应用进程的运行数据，其中，运行数据包括目标应用进程的正常退出数据和异常退出数据；

s3，根据正常退出数据和异常退出数据确定目标应用进程的稳定性参数；

s4，判断稳定性参数是否满足预设条件；

s5，在判断出稳定性参数不满足预设条件的情况下，从目标应用程序中删除目标代码。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：在目标应用进程中创建第一对象，其中，第一对象随目标应用进程的退出而被销毁；监控第一对象是否被销毁；在监控到第一对象被销毁时确定目标应用进程退出，其中，目标应用进程退出包括异常退出和正常退出；将目标应用进程退出时产生的数据作为第一退出数据。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：注册第一对象的第一通知，其中，第一通知用于指示第一对象所在的进程已退出；判断是否检测到第一通知；在检测到第一通知的情况下，确定第一对象被销毁。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：获取目标应用进程的异常退出数据，其中，在目标应用进程异常退出的情况下，会产生异常退出数据；获取目标应用进程的第一退出数据，其中，在目标应用进程正常退出和异常退出两种情况下，都会产生第一退出数据；根据异常退出数据和第一退出数据获取正常退出数据。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：根据读取到的墓碑文件目录判断墓碑文件目录是否发生了改变；如果墓碑文件目录发生了改变，则确定目标应用进程发生了异常退出；将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：创建目录修改事件监听器，其中，在创建目录修改事件监听器之后，如果有应用进程发生异常退出，系统会生成墓碑文件；判断系统是否生成了墓碑文件；在系统生成了墓碑文件的情况下，确定墓碑文件目录发生了改变，将目标应用进程发生异常退出时产生的运行数据作为异常退出数据包括：解析墓碑文件，得到异常退出数据。

可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：运行调试程序，其中，运行调试程序的过程中产生了第一进程；检测第一进程是否创建了墓碑文件；在检测到第一进程创建了墓碑文件的情况下，确定目标应用进程发生了异常退出；将目标应用进程发生异常退出时产生的运行数据作为异常退出数据。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。