一种基于AOP的插桩测试方法、装置和电子设备

技术领域

本发明涉及软件测试领域，尤其涉及一种基于AOP的插桩测试方法、装置和电子设备。

背景技术

代码插桩技术是在保证被测程序原有逻辑完整性的基础上在程序中插入一些探针(又称为“探测仪”)，通过探针的执行获得程序的控制流和数据流信息，进而得到逻辑覆盖等动态信息，从而实现测试的目的。

目前广泛应用的是源代码插桩技术，它是基于对源文件进行词法分析和语法分析的基础上实现代码插桩的技术。但是，源代码插桩技术依赖于源代码，也就是说，在没有源代码的情况下，无法实现代码插桩。并且，源代码插桩需要修改源代码，若要实现源代码修改，不仅需要技术人员非常了解源代码的词法和语法，而且还需要对代码插桩技术非常的了解，这样使得代码插桩技术实现起来有一定的难度，进而也为通过代码插桩技术进行的软件测试的实现带来了一定的难度。

发明内容

有鉴于此，本发明实施例公开了一种基于AOP的插桩测试方法及装置，解决了由于源代码插桩导致的代码插桩和软件测试困难的问题，并且，实现了测试规则的复用，大大降低了技术人员的工作量，并且，提高了测试效率。

本发明实施例公开了一种基于AOP的插桩测试方法，包括：

获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则；

在探针探测到与测试规则对应的第一程序行为时，检测是否满足执行所述测试规则的条件；

若满足执行所述测试规则的执行条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据；

其中，捕获的第二程序行为和/或所述第二程序行为产生的数据用于进行测试分析。

可选的，所述检测是否满足执行所述测试规则的条件，包括：

调用启停配置文件；

读取启停配置文件中的数据,并查找到与所述测试规则对应的启停数据；

基于与所述测试规则相对应的启停数据，确定是否满足执行所述测试规则的条件。

可选的，所述基于与所述测试规则相对应的启停配置文件中的数据，确定是否满足执行所述测试规则的条件，包括：

在所述启停数据中包含启动条件的情况下，检测被测对象当前的运行环境是否满足启动条件；

若所述被测对象当前的运行环境满足所述启动条件，则满足执行所述测试规则的条件；

若所述被测对象当前的运行环境不满足所述启动条件，则不满足执行所述测试规则的条件。

可选的，还包括：

修改所述启停配置文件中的数据。

可选的，所述执行所述测试规则包括：

调用所述测试规则对应的参数配置文件；

读取所述参数配置文件中的参数信息；

基于所述参数信息执行所述测试规则。

可选的，还包括：

将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理，得到预处理数据；所述预处理数据用于测试人员进行测试分析。

可选的，所述将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理包括：

从捕获到的第二程序行为和/或所述第二程序行为产生的数据中，提取符合预设异常条件的第二程序行为和/或第二程序行为产生的数据。

本发明实施例还公开了一种基于AOP的插桩测试装置，包括：

获取单元，用于获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则，且每个测试规则对应一个探针，以用于对所述测试规则对应的程序行为进行探测；

检测单元，用于在探针探测到与测试规则对应的第一程序行为时，检测是否满足执行所述测试规则的条件；

执行单元，用于若满足执行所述测试规则的条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据；

其中，捕获的第二程序行为和/或所述第二程序行为产生的数据用于进行测试分析。

可选的，所述检测单元，包括：

第一调用单元，用于调用启停配置文件；

第一读取单元，用于读取启停配置文件中的数据,并查找到与所述测试规则对应的启停数据；

第一确定单元，用于基于与所述测试规则相对应的启停数据，确定是否满足执行所述测试规则的条件。

本发明实施例还公开了一种电子设备，包括：处理器和存储器；

其中，所述处理器用于执行所述存储器中存储的程序；

所述存储器用于存储程序，所述程序至少用于：

获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则；

在探针探测到与测试规则对应的第一程序行为时，检测是否满足执行所述测试规则的条件；

若满足执行所述测试规则的执行条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据；

其中，捕获的第二程序行为和/或所述第二程序行为产生的数据用于进行测试分析。

本发明实施例公开了一种基于AOP的插桩测试方法，该方法包括：获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则；在探针探测到与测试规则相对应的第一程序行为时，检测是否满足执行测试规则的条件，若满足执行测试规则的条件，执行该测试规则，以依据测试规则捕获与测试规则对应的第二程序行为和/或第二程序行为产生的数据；其中，捕获的第二程序行为和/或第二程序行为产生的数据用于进行测试分析。由此可知，通过AOP技术将测试规则集插桩到被测对象中，无需修改源代码，解决了由于源代码插桩导致的代码插桩和软件测试困难的问题。并且，将通用的测试规则集成到一起，并将集成有至少一个测试规则的测试规则集插桩到被测对象中，实现了测试规则的复用，大大降低了技术人员的工作量，提高了测试效率。

除此之外，将集成有至少一个测试规则的插桩规则集插桩到测试对象中，如何使测试规则运行也具有一定的困难，技术人员通过对每个测试规则设置开启条件，控制测试规则是否开启，这样实现了对插桩规则集中的每个插桩规则的灵活控制。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1示出了本发明实施例公开的一种基于AOP的插桩测试方法的流程示意图；

图2示出了本发明实施例提供的一种基于AOP的插桩测试方法的又一流程示意图；

图3示出了一种软件开发包的结构示意图；

图4示出了本发明实施例公开的一种基于AOP的插桩测试方法的另一流程示意图；

图5示出了本发明实施例公开的一种基于AOP的插桩测试装置的结构示意图；

图6示出了本发明实施例提供的一种电子设备的结构示意图；

图7示出了本发明实施例提供的一种测试分析示意图；

图8示出了本发明实施例提供的有一种测试分析示意图；

图9示出了本发明实施例提供的另一种测试分析示意图。

具体实施方式

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

申请人发现，AOP(英文名称：Aspect-Oriented programming，中文名称：面向切面编程)，是可以通过编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。由此申请人发现，可以应用该技术实现在不修改源代码的基础上，给程序动态添加用于测试的功能，这样实现了在不修改源代码的基础上进行软件测试的目的。

然而，AOP的技术复杂性较高，需要开发人员对被测对象的相关技术平台有比较深入的了解，才能编写出相应的插桩规则，而且，针对不同的被测对象，开发人员每次都需要重新编写插桩规则，不仅耗时，而且耗费人力物力。

申请人在对不同的测试对象进行测试时发现，一些被测对象的测试项目具有通用性，例如一些异常场景的构造、程序行为的监控或者性能数据的收集等。

由此，申请人发现，为了提高测试效率，并降低测试所需的人力物力，可以将通用的规则集成起来，应用于软件测试中。

有鉴于此，本发明实施例公开了一种基于AOP的插桩测试方法，该方法包括：通过AOP技术将插桩规则集插桩到被测对象中，插桩规则集中包括至少一个针对预设程序行为的测试规则；每个插桩规则对应的探针对测试规则相对应的第一程序行为进行探测，在探针探测到与测试规则相对应的第一程序行为时，检测是否满足执行测试规则的条件，若满足执行测试规则的条件，执行该测试规则，以依据测试规则捕获与测试规则对应的第二程序行为和/或第二程序行为产生的数据；其中，捕获的第二程序行为和/或第二程序行为产生的数据用于进行测试分析。

由此可知，通过AOP技术将测试规则集插桩到被测对象中，无需修改源代码，解决了由于源代码插桩导致的代码插桩和软件测试困难的问题。

并且，将通用的测试规则集成到一起，并将集成有至少一个测试规则的测试规则集插桩到被测对象中，实现了测试规则的复用，大大降低了技术人员的工作量，提高了测试效率。

除此之外，将集成有至少一个测试规则的插桩规则集插桩到测试对象中，如何使测试规则运行也具有一定的困难，技术人员通过对每个测试规则设置开启条件，控制测试规则是否开启，这样实现了对插桩规则集中的每个插桩规则的灵活控制。

接下来对本申请的技术方案进行详细的介绍：

参考图1，示出了本发明实施例公开的一种基于AOP的插桩测试方法的流程示意图，在本实施例中，该方法包括：

S101：获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则；

本实施例中，被测对象表示需要进行测试的软件，其中被测对象可以为基于不同技术平台开发的，例如基于Android平台开发的软件或者基于iOS平台开发的软件。

本实施例中，插桩规则集中预先集成了至少一个插桩规则，插桩规则是预先生成的，插桩规则可以理解为针对一种程序行为的测试方法，或者可以理解为针对软件中某种功能的测试方法。

而且，需要说明的是，插桩规则集中的插桩规则是具有通用性的，可以应用于不同的被测对象。

举例说明：以被测对象为Android平台开发的软件为例，插桩规则集中包含的具有通用性的插桩规则可以包括：

1)控件性能测试规则ActivityTimePerf：记录核心activity控件的各个生命期函数的执行时间，以使测试人员可以通过记录的控件的各个生命期函数的执行时间发现潜在的性能问题。

2)网络异常检测规则DumpHttpHeaders：记录http request/response headers的异常数据包(如返回码>＝300)，发现网络异常数据。

3)通用异常检测规则ExceptionCatcher：捕获并记录代码中所有的异常，例如已经在代码中被try...catch...模块捕获住的异常以及所有函数throw的异常以通过捕获的代码中的异常发现潜藏在UI层面背后的潜在问题。

4)函数追踪规则FuncTracing：记录和统计每个函数的执行次数，以使测试人员根据记录的数据发现潜在问题。

5)网络测试规则NetworkTypeCheater：通过hook特定的API函数，模拟各类网络场景进行测试，其中API函数可以包括：

call(int android.net.NetworkInfo.getType())，

call(int android.net.NetworkInfo.getSubtype())，

call(Stringandroid.net.NetworkInfo.getExtraInfo())。

6)严格模式模拟规则StrictModeEnabler：自动开启android系统的strictmode模式，自动记录ANR和资源泄露问题。

7)线程模拟测试规则ThreadMonkeyRunner

8)UI控件测试规则UIActionTracing：记录UI操作事件流，帮助定位非必现问题，例如采用统一的方式来直接钩取各类控件的响应函数，通过读取控件元素属性获取信息。

其中，基于AOP的插桩技术，将插桩规则插桩到被测对象中，无需源代码，可以对被测对象的源代码编译后的class文件进行插桩，即通过对编译后的java class文件进行编译插桩，将插桩规则集导入到编译系统中，通过AOP技术对java class文件和插桩规则集进行编译，生成一个全新的目标代码，该目标代码中除了包含源代码的功能外，还增加了插桩规则集中各个规则对应的测试功能。

S102：在探针探测到与测试规则对应的第一程序行为时，检测是否满足执行所述测试规则的条件；

本实施例中，在通过AOP技术将插桩规则集插桩到被测对象的过程中，生成了多个探针，每个探针对应一个插桩规则集中的一个规则，该探针用于对被测对象进行测试时，探测是否发生了与测试规则对应的第一程序行为。

本实施例中，由于插桩到被测对象的插桩规则集中包含至少一个测试规则，但是测试时并不是所有的项目都需要被测试，测试人员需要根据需求选择测试项目，即用户可以选择在被测对象进行测试后，哪个测试规则可以被执行。

为了实现测试规则的灵活控制，即有选择性的执行测试规则，为每个测试规则设置了启动条件，在满足执行该测试规则的条件时，启动该测试规则。

其中，启动条件的设置规则可以包括多种，本实施例中不进行限定，如下会对一些可以实现的方式进行介绍，在这里就不再赘述。

本实施例中，被测对象的第一程序行为可以理解为被测对象的某些功能的执行，或者可以理解为可以触发测试规则开始执行测试的程序行为，例如某些控件的运行、具有某些功能的函数的运行、或者网络的开启等。

S103：若满足执行所述测试规则的条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据。

本实施例中，第二程序行为可以理解为测试规则需要捕获的程序行为，例如网络运行时异常的网络数据、运行异常的函数、或者网络场景测试的过程。

其中，第二程序行为产生的数据可以理解为测试规则中监测的一些程序行为产生的数据，例如控件运行时的生命周期的执行时间，模拟网络场景产生的数据等。

并且，由于测试的软件的功能不同，针对不同软件的功能，用于进行测试分析的数据也不同，或者针对不同的测试规则捕获的数据也不同，其中捕获的数据例如可以包括如下的几种情况：

情况一、捕获与测试规则对应的程序行为：

有一些功能仅通过记录的程序行为就可以对性能进行分析，在这种情况下，依据测试规则捕获的数据为程序行为，例如函数追踪规则，记录的是函数执行的行为，并记录函数备调用的次数和调用关系。

情况二、捕获测试规则对应的程序行为产生的数据：

有一些功能需要对程序行为产生的数据进行分析，在该种情况下无需捕获程序行为，捕获程序行为产生的数据，例如控件性能测试规则，记录控件的各个生命周期的执行时间。

情况三、捕获测试规则对应的程序行为和程序行为产生的数据：

有一些功能需要同时对程序行为和程序行为产生的数据进行测试分析，在该种情况下捕获的是测试规则对应的程序行为和程序行为产生的数据，例如线程模拟测试规则，记录模拟线程的执行，并记录线程的执行序列等。

本实施例中，在测试规则执行的过程中，需要一些参数进行控制，例如在一些场景模拟测试中，需要一些调取一些参数进行场景模拟，或者在测试规则执行的过程中需要进行一些逻辑判断，在该种情况下，需要调用预设的参数辅助测试规则的执行，优选的，S103中执行测试规则包括：

调用测试规则对应的参数配置文件；

读取参数配置文件中的参数信息；

基于所述参数信息执行所述测试规则。

举例说明：网络测试规则NetworkTypeCheater对应的参数配置文件中的参数信息包括：

android.net.NetworkInfo.getType()、android.net.NetworkInfo.getSubType()和android.net.NetworkInfo.getExtraInfo()；

并且，辅助判断逻辑为：

extraInfo＝””//为空，表示不篡改getExtraInfo()的返回值，返回该API的真实返回值；

networkType＝-1//-1，表示不篡改getType()的返回值，返回该API的真实返回值；

networkSubtype＝-1//-1，表示不篡改getSubType()的返回值，返回该API的真实返回值；

其中，各个字段的取值由Android API决定。

本实施例中，捕获的第二程序行为和/或第二程序行为产生的数据用于进行测试分析。

其中，对第二程序行为和/或第二程序行为产生的数据进行测试分析，可以通过程序执行自动的进行测试分析，或者测试人员根据测试结果人为的进行测试分析，本实施例中，对于如何进行测试分析不进行限定。

本实施例中，通过AOP技术将测试规则集插桩到被测对象中，无需修改源代码，解决了由于源代码插桩导致的代码插桩和软件测试困难的问题。并且，将通用的测试规则集成到一起，并将集成有至少一个测试规则的测试规则集插桩到被测对象中，实现了测试规则的复用，大大降低了技术人员的工作量，提高了测试效率。

参考图2，示出了本发明实施例提供的一种基于AOP的插桩测试方法的又一流程示意图，在本实施例中，该方法包括：

S201:获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则；

本实施例中，S201与上述介绍的S101一致，本实施例中不再赘述。

S202：在探针探测到与测试规则对应的第一程序行为时，调用启停配置文件；

S203：读取启停配置文件中的数据，并查找到与所述测试规则对应的启停数据；

S204：基于与所述测试规则相对应的启停数据，确定是否满足执行所述测试规则的条件；

本实施例中，启停配置文件中包含所有控制测试规则是否开启的数据，在探针探测到与测试规则对应的程序行为时，调用启停配置文件，通过配置文件中的数据确定是否执行该测试规则。

由于启停配置文件中包含所有插桩规则集中所有规则的启停控制数据，那么需要先找到待执行的测试规则对应的启停数据，并基于该启停数据，确定是否满足执行该测试规则的条件。

本实施例中，通过启停数据控制测试规则执行的方式可以包括多种，在本实施例中不进行限定，例如可以包括如下两种方式：

方式一、在程序执行之前测试人员设置启停标识；

在读取启停配置文件中的数据，查找到与测试规则相对应的启停数据；

若所述启停数据为启动标识，则满足执行测试规则的条件；

若所述启停数据为停止标识，则不满足执行测试规则的条件。

举例说明：假设将启动标识设置为1，将停止标识设置为0，测试人员可以预先设置测试规则的启停数据。当在配置文件中读取到测试规则对应的启停数据为1时，表示满足执行测试规则的条件，并执行该测试规则；当在配置文件中读取到的测试规则对应的启停数据为0时，表示不满足执行测试规则的条件，不执行该测试规则。

方式二、

测试人员还可以为启停数据中设置启动条件，只有在满足启动条件的情况下，才执行测试规则；具体的，S204包括：

在所述启停数据中包含启动条件的情况下，检测被测对象当前的运行环境是否满足启动条件；

若所述被测对象当前的运行环境满足所述启动条件，则满足执行所述测试规则的条件；

若所述被测对象当前的运行环境不满足所述启动条件，则不满足执行所述测试规则的条件。

本实施例中，启动条件可以是测试人员设置的，并且可以根据需求进行修改的。

举例说明：被测对象在进行测试时，若当前环境下，CPU占用的内存太多，可能会出现被测对象出现卡顿的情况，不利于被测对象进行测试，在该种情况下，可以停止启动一些测试功能，缓解运行压力，例如启动条件可以是操作系统的CPU的占用率是否小于预设的阈值，若小于预设的阈值，则表示满足执行测试规则的条件，若不小于预设的阈值，则表示不满足执行测试规则的条件。

S205：若满足执行所述测试规则的执行条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据。

本实施例中，S205与上述S103一致，在本实施例中不进行限定。

本实施例中，通过对每个测试规则设置开启条件，控制测试规则是否开启，这样使得插桩规则集中的每个插桩规则可以有序的执行，并且实现了对各个测试规则的灵活控制。

基于上述实施例一(S101-S103)和实施例二(S201-S205)，进一步的，本实施例还包括如下的步骤：

为了便于用户对捕获到的程序行为和/或程序行为产生的数据进行测试分析，可以预先对捕获到的数据进行处理，优选的，还包括：

将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理，得到预处理数据；所述预处理数据用于测试人员进行测试分析。

本实施例中，对于由不同测试规则捕获的程序行为和/或程序行为产生的数据，用于进行不同的测试分析，在测试分析之前，可以对不同的数据进行相应预处理操作，因此预先对不同的测试规则得到的数据设置了不同的预处理方法。

举例说明：1)对于获取到的控件的性能数据，例如控件的生命期函数的执行时间，分析规则可以为对控件的生命期函数的执行时间进行统计分析，并生成表格。2)对于函数追踪规则得到的数据，分析规则可以为统计函数执行次数和调用关系，并依据顺序输出结果；3)将捕获到的数据进行重分类统计，其中，可以指定一个日志文件进行重分类统计，也可以指定多个日志文件进行重分类统计。

本实施例中，进行预处理的一种实现方式还可以为，从捕获到的第二程序行为和/或所述第二程序行为产生的数据中，提取符合预设异常条件的程序行为或程序行为产生的数据。

其中，异常条件可以是用户根据需求设置的，提取到的符合预设条件的程序行为或程序行为产生的数据，可以用来为用户进行测试分析提供依据。

为了便于利用对捕获到的程序行为和/或程序行为产生的数据，可以将捕获到的程序行为和/或程序行为产生的数据存储到预设的位置上，优选的可以以日志的形式存储到预设的位置上。

当需要通过捕获到的数据进行测试分析时，可以调取存储的日志信息，并对日志信息进行分析，提取出程序行为和/或程序行为产生的数据，并从解析出的程序行为和/或所述程序行为产生的数据中，提取符合预设异常条件的程序。

在一种实施方式中，集成了至少一个测试规则的插桩规则集可以存储在软件开发包中，或者表示为一个jar包，以该种软件开发包的形式存在，可以轻松的插入到被测对象中。

在该中实施方式中，参考图3，软件开发包，包括：插桩规则模块301，所述插桩规则模块中部署了预先生成的插桩规则集，所述插桩规则集中包括至少一个针对预设程序行为的测试规则；

所述插桩规则模块，用于在将所述插桩规则模块插桩到被测对象后，在对被测对象进行测试时，通过执行测试规则，捕获程序行为和/或程序行为产生的数据；

其中，捕获的所述程序行为和/或所述程序行为产生的数据用于进行测试分析。

可选的，还包括：

配置文件模块302，所述配置文件包括启停配置文件和参数配置文件；

所述启停配置文件包括，用于控制插装规则模块启动和停止的数据；

所述参数配置文件包括，用于控制所述插桩规则模块中的测试规则执行的参数信息。

其中，启停配置文件中控制测试规则启动和停止的数据的形式可以包括多种，本实施例中不进行限定，优选的，包括如下的两种形式：

1、设置启动标识和停止标识，其中启动标识用于控制测试规则启动，停止标识表示不执行测试规则；

2、设置测试规则的启停条件，例如设置启动测试规则的被测设备当前的运行环境。

其中，参数配置文件中的参数信息是用于控制测试规则执行的：

举例说明：1)用于控制网络测试规则的具体参数，例如设置了如下三个系统函数：

call(int android.net.NetworkInfo.getType())，

call(int android.net.NetworkInfo.getSubtype())，

call(Stringandroid.net.NetworkInfo.getExtraInfo())。

2)threadMonkeyRunner.config：

TheadMonkeyRunner表示在线程执行前，随机sleep一段时间，参数配置文件中可以设置sleep的时间，例如，如果没有该配置文件或配置项，则取默认上限值10秒。如果将sleepRandom设为0，则不进行sleep，但会打印thread启动信息，可以用来监控thread的执行情况。

3)exceptionCatcher.config：配置有哪些stacktrace里的函数是无需记录函数入参的，例如以android./java.等开头的包名函数无需记录。

可选的，所述软件开发包还包括：

测试分析模块303，用于存储进行测试分析的程序，该程序的执行用于从捕获到的程序行为和/或所述程序行为产生的数据中，提取符合预设的异常条件的程序行为和/或数据。

其中，针对于测试的项目不同，或者说捕获的程序行为或者数据不同，那么分析的策略也不同，本实施例中可以针对不用的测试规则设置相应的分析策略。

举例说明:1)对于控件性能的分析，提取出监控的控件Activity各个生命期函数的执行时间，并进行统计，生成图表供用户分析。

如下图7所示，是对onResume函数的执行时间的统计情况，其中Time表示函数开始执行的时间，Cost表示函数执行的时长，并且还统计了onResume函数执行的总次数(COUNT＝4)，时长的最大值(MAX＝51)，时长的最小值(MIN＝2)，时长的平均值(AVG＝25)。

2)测试分析模块，还用于统计函数执行次数和调用关系，并将结果排序输出，帮助测试人员发现潜在的冗余函数调用。

参考图8，可以看出QQAudioManager.getInstance()总共被调用了2831次，其中被QQPlayerService的658行代码调用了761次等，因此可以根据统计的数据进一步对调用的合理性进行分析。

3)测试分析模块，还用于将捕获到的异常程序行为进行去重分类统计，其中，若将捕获到的程序行为和/或程序行为产生的数据以日志的行为进行存储，那么在测试时可以得到多个日志文件，进行去重分类统计时，可以对单个的日志文件进行统计，也可以对多个日志文件进行统计，并且将屏幕的输出结果重定向到文本文件中。

从图9可以看出，定位出了一个异常情况，该情况发生了2次(如图中的2times)，因此可以表示为总共出现了2个异常(如图中展示的TOTAL Exceptions:2)。

4)StackTraceFuncNamesxxx.log中，记录有当前app中出现过被catch住的stacktrace中在白名单之外的函数列表，用于当再次出现异常时，定位问题。

可选的，还包括：

通用工具模块304，存储有实现预设的基本功能的程序，该程序的执行用于为所述软件开发包中的其它模块的执行提供预设的基本功能。

其中，预设的基本功能例如可以包括：文件操作功能，例如文件的读写功能，手机相关操作功能，例如查看手机系统信息、唯一标识等；记录插桩脚本生成的日志等。

基于上述软件开发包，参考图4，插桩测试方法的实现流程可以包括：

S401：基于AOP技术将软件开发包插桩到被测对象中；

其中，本实施例中，可以基于AOP技术对被测对象的源代码编译后得到的javaclass文件进行编译插桩，这样无需源代码即可实现代码插桩。在代码插桩的过程中，会生成多个探针，每个探针对应于一个测试规则，每个探针用于对相应的测试规则所对应的程序行为进行探测。

S402：在探针探测到与测试规则对应的第一程序行为时，调用启停配置文件；

S403：读取启停配置文件中的数据，并查找与测试规则对应的启停数据；

S404：基于与测试规则相对应的启停数据，确定是否满足执行所述测试规则的条件；

S405：若满足执行所述测试规则的执行条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据；

本实施例中，在测试规则执行的过程中，可以读取测试规则对应的参数配置文件中的参数信息，并依据参数信息执行测试规则。

S406：启动测试分析模块将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理，得到预处理数据；所述预处理数据用于测试人员进行测试分析；

S407：用户通过调取测试过程中捕获的第二程序行为和/或第二程序行为产生的数据，或者测试分析模块得到的预处理数据，进行测试分析。

由此可知，通过AOP技术将测试规则集插桩到被测对象中，无需修改源代码，解决了由于源代码插桩导致的代码插桩和软件测试困难的问题。

并且，将通用的测试规则集成到一起，并将集成有至少一个测试规则的测试规则集插桩到被测对象中，实现了测试规则的复用，大大降低了技术人员的工作量，并且，提高了测试效率。

除此之外，技术人员通过对每个测试规则设置开启条件，控制测试规则是否开启，这样实现了对插桩规则集中的每个插桩规则的灵活控制。

参考图5，本发明实施例公开了一种基于AOP的插桩测试装置的结构示意图，在本实施例中，该装置包括：

获取单元501，用于获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则，且每个测试规则对应一个探针，以用于对所述测试规则对应的第一程序行为进行探测；

检测单元502，用于在探针探测到与测试规则对应的第一程序行为时，检测是否满足执行所述测试规则的条件；

执行单元503，用于若满足执行所述测试规则的条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据；

其中，捕获的第二程序行为和/或所述第二程序行为产生的数据用于进行测试分析。

可选的，所述检测单元，包括：

第一调用单元，用于调用启停配置文件；

第一读取单元，用于读取启停配置文件中的数据,并查找到与所述测试规则对应的启停数据；

第一确定单元，用于基于与所述测试规则相对应的启停数据，确定是否满足执行所述测试规则的条件。

可选的，第一确定单元，包括：

条件检测子单元，用于在所述启停数据中包含启动条件的情况下，检测被测对象当前的运行环境是否满足启动条件；

第一确定子单元，用于若所述被测对象当前的运行环境满足所述启动条件，则满足执行所述测试规则的条件；

第二确定子单元，用于若所述被测对象当前的运行环境不满足所述启动条件，则不满足执行所述测试规则的条件。

可选的，还包括：

修改单元，用于修改所述启停配置文件中的数据。

可选的，执行单元，包括：

第二调用子单元，用于调用所述测试规则对应的参数配置文件；

第二读取子单元，用于读取所述参数配置文件中的参数信息；

执行子单元，用于基于所述参数信息执行所述测试规则。

可选的，还包括：

预处理单元，用于将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理，得到预处理数据；所述预处理数据用于测试人员进行测试分析。

可选的，所述预处理单元，还用于：

从捕获到的第二程序行为和/或所述第二程序行为产生的数据中，提取符合预设异常条件的第二程序行为和/或第二程序行为产生的数据。

本实施例公开的装置，通过AOP技术将测试规则集插桩到被测对象中，无需修改源代码，解决了由于源代码插桩导致的代码插桩和软件测试困难的问题。并且，将通用的测试规则集成到一起，并将集成有至少一个测试规则的测试规则集插桩到被测对象中，实现了测试规则的复用，大大降低了技术人员的工作量，并且，提高了测试效率。

除此之外，将集成有至少一个测试规则的插桩规则集插桩到测试对象中，如何使测试规则运行也具有一定的困难，技术人员通过对每个测试规则设置开启条件，控制测试规则是否开启，这样可以灵活控制插桩规则集中的每个插桩规则的执行。

参考图6，本发明实施例公开了一种电子设备的结构示意图，在本实施例中，该电子设备包括：

处理器601和存储器602；

其中，所述处理器601用于执行所述存储器中存储的程序；

所述存储器602用于存储程序，所述程序至少用于：

获取被测对象；所述被测对象中通过AOP技术插桩有预先生成的插桩规则集，所述插桩规则集中包括至少一个测试规则；

在探针探测到与测试规则对应的第一程序行为时，检测是否满足执行所述测试规则的条件；

若满足执行所述测试规则的执行条件，执行所述测试规则，以依据所述测试规则捕获所述测试规则对应的第二程序行为和/或所述第二程序行为产生的数据；

其中，捕获的第二程序行为和/或所述第二程序行为产生的数据用于进行测试分析。

可选的，所述检测是否满足执行所述测试规则的条件，包括：

调用启停配置文件；

读取启停配置文件中的数据,并查找到与所述测试规则对应的启停数据；

基于与所述测试规则相对应的启停数据，确定是否满足执行所述测试规则的条件。

可选的，所述基于与所述测试规则相对应的启停配置文件中的数据，确定是否满足执行所述测试规则的条件，包括：

在所述启停数据中包含启动条件的情况下，检测被测对象当前的运行环境是否满足启动条件；

若所述被测对象当前的运行环境满足所述启动条件，则满足执行所述测试规则的条件；

若所述被测对象当前的运行环境不满足所述启动条件，则不满足执行所述测试规则的条件。

可选的，还包括：

修改所述启停配置文件中的数据。

可选的，所述执行所述测试规则包括：

调用所述测试规则对应的参数配置文件；

读取所述参数配置文件中的参数信息；

基于所述参数信息执行所述测试规则。

可选的，还包括：

将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理，得到预处理数据；所述预处理数据用于测试人员进行测试分析。

可选的，所述将捕获的第二程序行为和/或第二程序行为产生的数据基于预设的分析规则进行预处理包括：

从捕获到的第二程序行为和/或所述第二程序行为产生的数据中，提取符合预设异常条件的第二程序行为和/或第二程序行为产生的数据。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。