应用程序的测试方法、客户端、服务器及系统与流程

本发明涉及计算机系统的测试领域，尤其涉及一种应用程序的测试方法、客户端、服务器及系统。

背景技术：

模糊测试是一种通过向目标系统提供非预期的输入并监视异常结果的方法，常常用于检测软件安全漏洞。通常，模糊测试包括如下的过程：自动或半自动的生成随机数据输入到一个程序中，然后监视程序异常，得到测试结果并存储和显示。

在对开放式操作系统的某一应用程序进行测试时，例如安卓系统的应用程序，该应用程序在接收到输入参数时，若未对输入参数进行严格校验和异常处理，某些异常的输入参数可能会造成应用程序停止提供服务。在现有的针对应用程序的模糊测试中，由于在测试服务器直接发送给应用程序的测试消息中输入参数的数据类型较单一，导致模糊测试能够检测出的漏洞有限，测试效率较低。

技术实现要素：

有鉴于此，本发明提供了一种应用程序的测试方法、客户端、服务器及系统，能够提升测试效率和准确度。

本发明的技术方案是这样实现的：

本发明提供了一种应用程序的测试方法，该方法应用于安装有代理客户端和应用程序的开放式操作系统，每次进行测试时，代理客户端执行如下处理：接收测试服务器发送的测试消息；从测试消息中解析得到测试数据；根 据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态。

本发明还提供了一种代理客户端，包括：接收模块、解析模块、生成模块、发送模块；其中，代理客户端和应用程序被安装于开放式操作系统，每次进行测试时：接收模块，用于接收测试服务器发送的测试消息；解析模块，用于从接收模块接收的测试消息中解析得到测试数据；生成模块，用于根据解析模块解析得到的测试数据生成测试用例；及，发送模块，用于将生成模块生成的测试用例发送给应用程序，以测试得到应用程序的状态。

本发明又提供了一种测试服务器，包括：获取模块，用于获取应用程序的安装包；反编译模块，用于对获取模块获取的安装包进行反编译，得到测试数据；生成模块，用于每次进行测试时，生成携带反编译模块得到的测试数据的测试消息；及，发送模块，用于将生成模块生成的测试消息发送给代理客户端；其中，在安装有代理客户端和应用程序的开放式操作系统中，每次进行测试时，代理客户端接收测试服务器发送的测试消息；从测试消息中解析得到测试数据；根据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态。

本发明还提供了一种测试系统，包括：测试服务器和代理客户端；其中，代理客户端和应用程序被安装于开放式操作系统中，每次进行测试时，测试服务器，用于向代理客户端发送测试消息；代理客户端，用于接收测试服务器发送的测试消息；从测试消息中解析得到测试数据；根据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态。

与现有技术相比，本发明提供的测试方法，通过在开放式操作系统中安装代理客户端，根据来自测试服务器的测试消息，能够构建包含各种数据类型的测试用例对应用程序进行测试，从而提升测试效率和准确度。

附图说明

图1为本发明实施例所涉及的实施环境示意图；

图2为依据本发明一实施例的应用程序测试方法的流程示意图；

图3A为依据本发明一实施例的测试用例示意图；

图3B为依据本发明一实施例的另一测试用例示意图；

图4为依据本发明另一实施例的应用程序测试方法的流程示意图；

图5为依据本发明一实施例的代理客户端的装置结构示意图；

图6为依据本发明一实施例的代理客户端的设备结构示意图；

图7为依据本发明一实施例的测试服务器的装置结构示意图；

图8为依据本发明一实施例的测试服务器的设备结构示意图；

图9为依据本发明一实施例的测试系统的结构示意图。

具体实施方式

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

图1为本发明实施例所涉及的实施环境示意图。参见图1，该实施环境包括测试服务器110和开放式操作系统120，其中，开放式操作系统120中安装有代理客户端130以及应用程序140。测试服务器110与代理客户端130进行交互，使得代理客户端130从测试服务器110处获得测试消息，定制化地构建各种数据类型的模糊测试用例，并将构建的测试用例发送给应用程序140，以测试得到应用程序140的状态。

在一实施例中，开放式操作系统120可以为安卓系统。安卓系统的应用程序120通常具备四大组件：活动(Activity)、服务(Service)、广播消息接收器(BroadcastReceiver)以及内容提供者(Content Provider)。具体而言， 活动是应用程序中负责与用户交互的组件，为应用程序提供可视化用户界面。服务通常用于为其他组件提供后台服务或监控其他组件的运行状态，一般不需要与用户交互，因此服务没有图形用户界面。广播消息接收器用于监听，其监听的事件源是应用程序中的其他组件。内容提供者作为应用程序之间唯一的共享数据的途径，其主要的功能是存储并检索数据以及向其他应用程序提供访问数据的接口。

当需要连接不同的组件时，通常需要借助于一种统一的方式启动组件及传递数据。在安卓系统中，通常是由Intent来实现，它是应用程序内不同组件之间通信的载体。具体而言，Intent封装了应用程序需要启动某个组件的“意图”，一个Intent对象包含接收“意图”的组件所关心的信息，例如Intent的动作(Action)属性和数据(Data)属性，以及安卓系统关心的信息，例如Intent的组件类型(Category)属性等。也就是说，发送“意图”的组件通过Intent对象所包含的内容(即组件(Component)属性)来启动指定的一个或多个组件，或者通过动作属性和类型属性联合筛选确定的一个或多个组件，然后实施相应的动作并传递相应的数据以便完成相应的动作。通常，Intent可以启动应用程序中另一个活动、服务或向广播消息接收器发送广播消息。

图2为依据本发明一实施例的应用程序测试方法的流程示意图。参见图2，该方法应用于安装有代理客户端和应用程序的开放式操作系统，每次进行测试时，代理客户端执行如下处理：

步骤201、接收测试服务器发送的测试消息。

测试消息可以包括如下信息中的一个或多个：测试类型、组件类型、安装包名称、组件名称、动作、输入参数的名称及数据类型。其中，测试类型可以为空Intent、无动作、畸形参数、自定义序列化参数等。组件类型可以为活动、服务、广播消息接收器；组件名称用来指定将被启动的目标组件，动作用来指定目标组件要完成的动作，例如，活动拨打电话 (ACTION_CALL)、活动显示用户将要编辑的数据(ACTION_EDIT)、广播消息接收器进行低电池容量警示(ACTION_BATTERY_LOW)、广播消息接收器完成耳机已插入或拔出(ACTION_HEADSET_PLUG)、广播消息接收器完成屏幕已开启(ACTION_SCREEN_ON)等等。输入参数的数据类型包括基本的数据类型，例如整数型(int)、字符串类型(string)、布尔型(boolean)等，例如在基本数据类型参数中添加畸形数据，还包括自定义的数据类型，例如序列化的自定义的类的对象等。

需要指出，以上测试消息中参数的各种取值仅限于举例，本发明不做具体限定。

在具体实现时，可以采用安卓系统中安卓调试桥(ADB)命令的格式来发送Intent测试消息。例如，按照如下的格式将上述测试数据携带在测试消息中：adb start am-n com.example.kkadapter/.CmdReceiverActivity--es type<测试类型>--es cmpoption<组件类型>--es pkgname<安装包名称>--es component<组件名称>--es action<指定的动作>--es str<输入参数的名称和数据类型>。其中，上述测试消息中的“com.example.kkadapter”指定了代理客户端。

其中，该测试消息携带了指示输入参数的名称及数据类型的字段，通过写入字符串的方式来指示测试时输入参数的名称以及输入参数的数据类型。并且，输入参数的数据类型与其对应的模糊测试类型相关联。例如，若输入参数的数据类型为“ByteArray”，基于这种ByteArray数据类型得到的参数的数值为畸形数据，其对应了上述“畸形参数”的测试类型。

步骤202、从测试消息中解析得到测试数据。

在一实施例中，代理客户端接收到上述Intent测试消息后，启动代理客户端中的Activity，从而代理客户端得知要进行后续操作，即生成测试用例并发送给待测应用程序以进行测试。根据上述ADB命令的格式，代理客户端对该测试消息进行解析，从测试消息的各个字段中读取出测试数据，包括 上述测试消息所包含的信息中的任一项或任意几项，如测试类型、组件类型、安装包名称、组件名称、动作、输入参数的名称及数据类型。

步骤203、根据解析得到的测试数据生成测试用例。

在具体实现时，可以根据解析得到的测试数据生成Intent测试用例。图3A为依据本发明一实施例的测试用例示意图。在该测试用例中相应的测试数据包括：测试类型为“畸形参数”，输入参数的名称为“key”、数据类型为“ByteArray”。通过执行该测试用例所包括的程序代码，新建一个Intent，根据测试数据中的安装包名称“pkg_name”和组件名称“component_name”设置Intent Component属性，根据测试数据中的数据类型“ByteArray”设置Intent附加信息(Extra)属性为畸形数组，最后启动被测应用程序的Activity。

图3B为依据本发明一实施例的另一测试用例示意图。在该测试用例中，测试类型为“自定义序列化参数”，输入参数的名称为“key”，数据类型为序列化的自定义的类的对象。通过执行该测试用例所包括的程序代码，新建一个Intent，根据测试数据中的安装包名称“pkg_name”和组件名称“component_name”设置Intent Component属性，根据自定义数据类型设置Intent Extra属性为自定义类NewSerializable，最后启动被测应用程序的Activity。

步骤204、将测试用例发送给应用程序，以测试得到应用程序的状态。

应用程序接收到该测试用例后执行测试，若该应用程序仍能正常工作，则判断该应用程序的状态为正常；否则，若该应用程序停止提供服务，如崩溃，则判断该应用程序的状态为异常。

然后，开放式操作系统将得到的崩溃情况等测试结果写入系统日志，测试人员通过查看系统日志来确定应用程序是否崩溃。

每次进行测试时，代理客户端重新执行步骤201至204，根据测试服务器重新发送的测试信息，生成测试用例，并将该测试用例发送给应用程序，对应用程序执行下一次测试，从而可以获得多次测试结果。

在本实施例中，通过在开放式操作系统中安装代理客户端，在对基于开放式操作系统的应用程序进行测试时，代理客户端接收测试服务器发送的测试消息；从测试消息中解析得到测试数据；根据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态，能够避免现有技术中由测试服务器直接发送给应用程序的测试消息中输入参数的数据类型仅包括整数型(int)、字符串类型(string)和布尔型(boolean)的情况，而代理客户端根据来自测试服务器的测试消息，能够构建包含各种数据类型的测试用例，从而有效提高模糊测试的效率和准确度。

图4为依据本发明另一实施例的应用程序测试方法的流程示意图。参见图4，该方法包括：

步骤401、测试服务器获取应用程序的安装包。

此处的“获取”可以指测试服务器从开放式操作系统处获得安装包，例如通过从安装有开放式操作系统的电子设备上复制该安装包来获取，或者也可以指测试服务器从提供该应用程序的第三方服务器处获得安装包，例如软件提供商服务器。

步骤402、测试服务器对安装包进行反编译，得到测试数据。

在一实施例中，测试服务器对所获取安装包进行反编译，获得安装包的源代码，通过静态扫描暴露组件所允许接收的Intent的各种参数，从中提取出如步骤202所述的测试数据。这里，暴露组件是指可以被外部应用调用的组件，包括活动、服务及广播消息接收器。这种暴露组件存在明显的安全隐患，容易被恶意程序利用。

此外，测试服务器对安装包进行反编译得到的测试数据和步骤202中代理客户端解析得到的测试数据的数据格式可以不同，测试服务器和代理客户端可以按照自身规定的格式对测试数据进行处理。

步骤403、每次进行测试时，测试服务器生成携带测试数据的测试消息。

在一实施例中，测试服务器可以将测试数据的全部信息以调试命令的形 式携带在测试消息中。在具体实现时，该调试命令可以为ADB命令。

或者，测试服务器可以将测试数据的全部信息以文本文件的形式携带在测试消息中。

或者，测试服务器还可以将测试数据的一部分信息以文本文件的形式携带在测试消息中，而将测试数据的另一部分信息以调试命令的形式携带在测试消息中。例如，若测试数据中输入参数的名称和数据类型的符号长度过长，例如超过1024字节，那么可以将输入参数的名称和数据类型的信息写到文本文件中，然后将测试数据的其他信息以ADB命令的形式携带在测试消息中。

步骤404、测试服务器将测试消息发送给代理客户端。

根据步骤403中在测试消息中携带测试数据的不同形式，测试服务器可以将测试消息以文本文件的形式发送给代理客户端，或者以文本文件和ADB命令联合的形式发送给代理客户端。

在一实施例中，还可以通过第三方服务器来完成代理客户端与测试服务器之间的交互，即代理客户端向第三方服务器发送测试请求以请求获得测试消息，第三方服务器将该测试请求转发给测试服务器，然后测试服务器完成步骤401、步骤402和步骤403后，将测试消息发送给第三方服务器，由其转发给代理客户端。

在另一实施例中，测试服务器响应于外部输入操作，执行上述步骤401至步骤404。例如，测试人员输入启动测试指令，测试服务器开始执行相应操作。

步骤405、代理客户端接收测试服务器发送的测试消息。

步骤406、代理客户端从测试消息中解析得到测试数据，根据解析得到的测试数据生成测试用例。

步骤407、代理客户端将测试用例发送给应用程序。

步骤408、对应用程序进行测试，以获得应用程序的状态。

对应用程序进行多次测试，在每次测试时，可以重新执行步骤403至步 骤408，即测试服务器向代理客户端发送一次测试消息，代理客户端向应用程序发送一次测试用例。

完成测试后，测试服务器可以从开放式操作系统中获取系统日志，来观察应用程序是否停止服务，以判断是否执行后续处理。

在本实施例中，通过将测试数据的信息以文本文件的形式携带在测试消息中发送给代理客户端，能够克服现有技术中仅使用ADB命令传输测试消息时字符长度受限的缺陷，增强了测试消息的信息容量，有效提高了测试的效率和准确度。

图5为依据本发明一实施例的代理客户端500的装置结构示意图，包括接收模块510、解析模块520、生成模块530、发送模块540；其中，代理客户端和应用程序被安装于开放式操作系统，每次进行测试时：

接收模块510，用于接收测试服务器发送的测试消息；

解析模块520，用于从接收模块510接收的测试消息中解析得到测试数据；

生成模块530，用于根据解析模块520解析得到的测试数据生成测试用例；及，

发送模块540，用于将生成模块530生成的测试用例发送给应用程序，以测试得到应用程序的状态。

在一实施例中，测试消息中携带了指示输入参数的名称及数据类型的字段；解析得到的测试数据包括输入参数的名称及数据类型。

图6为依据本发明一实施例的代理客户端600的硬件结构示意图。该代理客户端包括：处理器610、存储器620、端口630以及总线640。处理器610和存储器620通过总线640互联。处理器610可通过端口630接收和发送数据。其中，

处理器610用于执行存储器620存储的机器可读指令模块。

存储器620存储有处理器610可执行的机器可读指令模块。处理器610 可执行的指令模块包括：接收模块621、解析模块622、生成模块623和发送模块624。其中，代理客户端600和应用程序被安装于开放式操作系统，每次进行测试时，确定模块621被处理器610执行时可以为：接收测试服务器发送的测试消息；

解析模块622被处理器610执行时可以为：从接收模块621接收的测试消息中解析得到测试数据；

生成模块623被处理器610执行时可以为：根据解析模块622解析得到的测试数据生成测试用例；及，

发送模块624被处理器610执行时可以为：将生成模块623生成的测试用例发送给应用程序，以测试得到应用程序的状态。

由此可以看出，当存储在存储器620中的指令模块被处理器610执行时，可实现前述各个实施例中接收模块、解析模块、生成模块和发送模块的各种功能。

图7为依据本发明一实施例的测试服务器700的装置结构示意图，包括获取模块710、反编译模块720、生成模块730和发送模块740。其中，

获取模块710，用于获取应用程序的安装包；

反编译模块720，用于对获取模块710获取的安装包进行反编译，得到测试数据；

生成模块730，用于每次进行测试时，生成携带反编译模块720得到的测试数据的测试消息；及，

发送模块740，用于将生成模块730生成的测试消息发送给代理客户端；

其中，在安装有代理客户端和应用程序的开放式操作系统中，每次进行测试时，代理客户端接收测试服务器700发送的测试消息；从测试消息中解析得到测试数据；根据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态。

在一实施例中，测试数据的一部分信息以文本文件的形式携带在测试消 息中，测试数据的另一部分信息以调试命令的形式携带在测试消息中；或者，测试数据的全部信息以文本文件的形式携带在测试消息中。

图8为依据本发明一实施例的代理客户端800的硬件结构示意图。该代理客户端包括：处理器810、存储器820、端口830以及总线840。处理器810和存储器820通过总线840互联。处理器810可通过端口830接收和发送数据。其中，

处理器810用于执行存储器820存储的机器可读指令模块。

存储器820存储有处理器810可执行的机器可读指令模块。处理器810可执行的指令模块包括：获取模块821、反编译模块822、生成模块823和发送模块824。其中，

获取模块821被处理器810执行时可以为：获取应用程序的安装包；

反编译模块822被处理器810执行时可以为：对获取模块821获取的安装包进行反编译，得到测试数据；

生成模块823被处理器810执行时可以为：每次进行测试时，生成携带反编译模块822得到的测试数据的测试消息；及，

发送模块824被处理器810执行时可以为：将生成模块823生成的测试消息发送给代理客户端；

其中，在安装有代理客户端和应用程序的开放式操作系统中，每次进行测试时，代理客户端接收测试服务器800发送的测试消息；从测试消息中解析得到测试数据；根据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态。

由此可以看出，当存储在存储器820中的指令模块被处理器810执行时，可实现前述各个实施例中获取模块、反编译模块、生成模块和发送模块的各种功能。

图9为依据本发明一实施例的测试系统900的结构示意图。测试系统900包括：测试服务器910和代理客户端920。其中，代理客户端920和应用程 序930被安装于开放式操作系统中，每次进行测试时，

测试服务器910，用于向代理客户端920发送测试消息；

代理客户端920，用于接收测试服务器910发送的测试消息；从测试消息中解析得到测试数据；根据解析得到的测试数据生成测试用例；及，将测试用例发送给应用程序，以测试得到应用程序的状态。

其中，测试服务器910可以包括图7所示的各个模块，代理客户端920可以包括图5所示的各个模块。在对应用程序930进行测试时，测试服务器910中的发送模块740将测试消息发送给代理客户端920中的接收模块510,代理客户端920中的发送模块540将测试用例发送给应用程序930以执行测试，获得应用程序930的测试状态。

上述系统实施例中，各个模块及单元实现自身功能的具体方法在方法实施例中均有描述，这里不再赘述。

另外，本发明的每一个实施例可以通过由数据处理设备如计算机执行的数据处理程序来实现。显然，数据处理程序构成了本发明。此外，通常存储在一个存储介质中的数据处理程序通过直接将程序读取出存储介质或者通过将程序安装或复制到数据处理设备的存储设备(如硬盘和或内存)中执行。因此，这样的存储介质也构成了本发明。存储介质可以使用任何类型的记录方式，例如纸张存储介质(如纸带等)、磁存储介质(如软盘、硬盘、闪存等)、光存储介质(如CD-ROM等)、磁光存储介质(如MO等)等。

因此，本发明还公开了一种存储介质，其中存储有数据处理程序，该数据处理程序用于执行本发明上述方法的任何一种实施例。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。