CN109408393A - 应用测试方法、装置及设备和计算机可读存储介质 - Google Patents

Abstract

本发明公开了一种应用测试方法、装置及设备和计算机可读存储介质，属于计算机技术领域，用于解决现有技术中存在的测试效率较低的技术问题。该方法包括：在应用进程启动后，通过应用进程中的加载接口函数，将用于对应用进程进行测试的动态链接库DLL文件加载至应用进程中，其中，DLL文件中包括调用不同测试用例进行测试的测试逻辑脚本，测试逻辑脚本中指示了测试用例间的执行逻辑关系；将测试逻辑脚本挂载到应用进程中执行测试用例的对象上，使得该对象基于测试逻辑脚本的指示在应用进程中执行相应测试用例，并在执行过程中收集与测试用例相对应的测试数据；针对每一个测试用例的测试数据进行分析，得到测试结果。

Description

应用测试方法、装置及设备和计算机可读存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种应用测试方法、装置及设备和计算机可读存储介质。

背景技术

随着终端性能的不断提升，给各种各样的应用提供了良好的运行环境。例如，随着手机性能的不断提升，随之在手机上能够运行更多的大型游戏。对于游戏平台的后台人员而言，为了保障用户的使用体验，需要定时对游戏进行测试，以对游戏中的漏洞(Bug)及时进行修复。

目前，对于游戏测试通常是基于Lua脚本的方式进行的，基于Lua脚本的测试方式需要将测试代码嵌入到游戏代码中，由于测试代码自身可能存在Bug，可能会对游戏代码造成污染。并且，若将测试代码嵌入到游戏代码中，那么在生成游戏包时，就需要进行编译。由于Lua脚本依赖于调用通过C#层编写的用于测试的相关接口函数，例如装备购买接口函数以及技能释放接口函数等，一旦C#层的接口函数不满足要求，那么在修改接口函数之后，就需要对整个游戏包重新进行编译，编译所消耗的时间一般都较长，例如对于大型的手游，编译一次消耗的时间至少需要2小时，因此，一旦需要重新编译，测试效率就会极低。针对其他应用程序的测试，同样存在上述的问题。

发明内容

本发明实施例提供一种应用测试方法、装置及设备和计算机可读存储介质，用于解决现有技术中存在的测试效率较低的技术问题。

一方面，提供一种应用测试方法，该方法包括：

在应用进程启动后，通过所述应用进程中的加载接口函数，将用于对所述应用进程进行测试的动态链接库DLL文件加载至所述应用进程中，其中，所述DLL文件中包括调用不同测试用例进行测试的测试逻辑脚本，所述测试逻辑脚本中指示了测试用例间的执行逻辑关系，一个测试用例用于执行所述应用进程中一个测试功能；

将所述测试逻辑脚本挂载到所述应用进程中执行测试用例的对象上，使得所述对象基于所述测试逻辑脚本的指示在应用进程中执行相应测试用例，并在执行过程中收集与测试用例相对应的测试数据；

针对每一个测试用例的测试数据进行分析，得到测试结果。

一方面，提供一种应用测试装置，该装置包括：

加载模块，用于在应用进程启动后，通过所述应用进程中的加载接口函数，将用于对所述应用进程进行测试的动态链接库DLL文件加载至所述应用进程中，其中，所述DLL文件中包括调用不同测试用例进行测试的测试逻辑脚本，所述测试逻辑脚本中指示了测试用例间的执行逻辑关系，一个测试用例用于执行所述应用进程中一个测试功能；

挂载模块，用于将所述测试逻辑脚本挂载到所述应用进程中执行测试用例的对象上，使得所述对象基于所述测试逻辑脚本的指示在应用进程中执行相应测试用例，并在执行过程中收集与测试用例相对应的测试数据；

数据分析模块，用于针对每一个测试用例的测试数据进行分析，得到测试结果。

一方面，提供一种应用测试设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述所述应用测试方法。

一方面，提供一种计算机存储介质；

所述计算机存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行上述所述的应用测试方法。

本发明实施例中，通过将测试代码封装成DLL文件，在进行测试时，通过应用进程中的加载接口函数，将DLL文件加载到应用进程中，并挂载到应用进程上的对象上来执行，从而进行测试。这样，由于本发明实施例中的测试代码和应用程序的代码是完全分离的，在想要对测试代码进行修改时，只需要将修改后的测试代码在此封装成DLL文件即可，相较将测试代码嵌入到应用程序的代码中的方案，省去了再次进行编译的时间，进而提升了测试效率。此外，由于测试代码无需嵌入到应用程序的代码中，则不会对应用程序的代码造成污染，减少应用程序的代码潜在的代码风险。

附图说明

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

图1为现有技术中的测试框架示意图；

图2为本发明实施例提供的应用场景示意图；

图3为本发明实施例提供的测试框架示意图；

图4为本发明实施例提供的应用测试方法的流程示意图；

图5为本发明实施例提供的游戏包解压后的文件目录示意图；

图6为本发明实施例提供的应用测试装置的一种结构示意图；

图7为本发明实施例提供的应用测试设备的一种结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为便于理解本发明实施例提供的技术方案，这里先对本发明实施例使用的一些关键名词进行解释：

动态链接库(Dynamic Link Library，DLL)文件：是一个独立文件，可以被程序或者其它DLL通过一定的加载方式加载到程序中或者其他DLL中，进行调用DLL文件中的接口函数来完成一定的操作。DLL文件包括托管DLL文件和非托管DLL文件，其中，托管DLL文件是基于.NET平台开发的DLL，属于托管代码，托管代码实际上即为中间语言(IntermediateLanguage，IL)代码，代码在编写完毕后则会被编译器编译成中间语言代码，而并非能够直接能够运行的机器码，托管DLL能够支持被动态加载到程序或者其他DLL中；而非托管DLL一般即为通过C++语言等开发得到的DLL，是直接被编译成能够直接运行的机器码，非托管DLL一般不支持动态加载。

Unity：目前较为主流的游戏开发平台，可以运行在多种系统环境种，例如可以运行在窗口(windows)操作系统、苹果(ios)操作系统以及安卓(Android)操作系统等系统环境中。Unity平台提供了动态加载和反射调用的功能，因而可以通过Unity平台开发得到支持动态加载和反射调用的游戏应用。

IL2CPP：使用基于IL2CPP开发的Unity3D游戏时，在得到中间语言后，使用IL2CPP将他们重新变回C++代码，然后再由各个平台的C++编译器直接编译成能执行的原生汇编代码。

动态加载：或称动态注入，在应用程序运行时，可以通过动态加载的方式将DLL文件或者其他可被动态加载的文件加载到应用程序中，使得应用程序可以调用DLL文件中包含的接口函数等。

测试用例(Test Case)：用于执行一个测试功能，例如对于游戏而言，购买指定的装备，或者释放指定的技能，即可以作为一个测试用例。

测试脚本(Testing script)：通过测试脚本可以自动执行全部测试过程或者部分测试过程，例如可以在测试脚本中编写好测试的逻辑顺序关系，在自动执行时，则会按照编写好的顺序来执行。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。

目前，对于游戏测试通常是基于Lua脚本的方式进行的，基于Lua脚本的测试方式需要将测试代码嵌入到游戏代码中，由于测试代码自身可能存在Bug，可能会对游戏代码造成污染，给游戏代码带来一定的代码风险。并且，若将测试代码嵌入到游戏代码中，那么在生成游戏包时，就需要进行编译。具体而言，请参见图1，基于Lua脚本的测试框架一般包括C#层和Lua层，其中，在C#层可以编写并封装好用于测试的相关接口函数，例如图1中所示的装备相关接口函数、召唤师相关接口函数、符文相关接口函数以及游戏人物相关接口函数等接口函数，分别用于执行游戏中的相关功能，例如装备相关接口函数用于购买装备或者出售装备等。编写好相关接口函数之后，再将相关接口函数注册到Lua虚拟机，进而在Lua层通过逻辑测试模块调用注册到Lua虚拟机的接口函数编写测试流程的测试逻辑。在进行游戏测试时，通过C#层的Update驱动Lua层中LuaTick，进而通过LuaTick进行测试环境的初始化，并调用测试逻辑模块按照编写好的测试逻辑进行测试。

由于上述基于Lua脚本的方式需要将在C#层封装的接口函数嵌入到游戏代码中，并编译到游戏包中，并且通过上述描述可知，Lua脚本需要依赖于调用通过C#层编写的用于测试的相关接口函数，例如装备购买接口函数以及技能释放接口函数等，一旦C#层的接口函数不满足要求，那么在修改接口函数之后，就需要对整个游戏包重新进行编译，编译所消耗的时间一般都较长，例如对于大型的手游，编译一次消耗的时间至少需要2小时，因此，一旦需要重新编译，测试效率就会极低。

本发明人对现有技术分析后发现，现有技术中正是因为需要将测试代码嵌入到游戏代码中，且因为在生成游戏包时需要编译才需要消耗过多的时间，产生测试效率低以及污染游戏代码的问题，对于其他应用程序的测试，同样如此。鉴于此，本发明人考虑到，若是在能够完成测试的前提下，能够将测试代码不嵌入到应用程序的代码中，那么就不会产生上述的问题，因而解决上述问题的关键在于将测试代码与应用程序的代码进行分离。

鉴于上述的分析和考虑，本发明实施例提供了一种应用测试方法，在该方法中，通过将测试代码封装成DLL文件，在进行测试时，通过应用进程中的加载接口函数，将DLL文件加载到应用进程中，并挂载到应用进程上的对象上来执行，从而进行测试。这样，由于可以通过动态加载的方式，将测试代码加载到应用进程中，即测试代码和应用程序的代码是完全分离的，在想要对测试代码进行修改时，只需要将修改后的测试代码在此封装成DLL文件即可，相较将测试代码嵌入到应用程序的代码中的方案，省去了再次进行编译的时间，进而提升了测试效率。此外，由于测试代码无需嵌入到应用程序的代码中，则不会对应用程序的代码造成污染，减少应用程序的代码潜在的代码风险。特别针对于大型游戏而言，大型游戏的安装包通常较大，若是在修改测试代码后能够避免再次进行编译，则能够大大的节省测试耗时，进一步提升游戏的测试效率。

在介绍完本发明实施例的设计思想之后，下面对本发明实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本发明实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本发明实施例提供的技术方案。

请参见图2所示，为本发明实施例中的技术方案能够适用的一种应用场景，在该场景中，可以包括用户设备(User Equipment，UE)201以及服务器202。

用户设备201可以是平板电脑(PAD)、手机、笔记本电脑或者个人计算机(PersonalComputer，PC)等设备，其中，用户设备101中可以安装多种应用，例如可以是游戏类型的应用程序，或者还可以是社交类型的应用程序，例如微博、QQ或者微信等。

服务器202可以用于存储在测试过程中产生的测试数据，并对测试数据进行分析。其中，服务器202可以是被测试的应用的后台服务器，也可以是任意与用户还是被201连接的服务器。

其中，用户设备201和服务器202通过网络进行相连，该网络可以是有线网络，也可以是无线网络，例如无线网络可以是移动蜂窝网络，或者可以是无线保真(WIreless-Fidelity，WIFI)网络，当然还可以是其他可能的网络，本发明实施例对此不做限制。

当然，本发明实施例提供的方法并不限用于图2所示的应用场景中，还可以用于其他可能的应用场景，例如对于测试数据的存储实质上可以直接放置在用户设备201上，本发明实施例并不进行限制。对于图2所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

为进一步说明本发明实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本发明实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本发明实施例提供的执行顺序。所述方法在实际的处理过程中或者装置执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。

请参见图3，为本发明实施例提供的测试框架示意图，其中，该测试框架是基于游戏测试为例的测试框架，对于其他类型的应用，本领域技术人员可以结合应用的实际情况结合图3所示的测试框架以及后续的描述进行合理的设置，因此对此不过多赘述。在该测试框架中，包括测试代码库以及游戏代码库。

测试代码库包括接口函数模块和测试逻辑脚本模块，其中，接口函数模块中封装了多个游戏测试相关的接口函数，例如图3中所示的装备相关接口函数、召唤师相关接口函数、符文相关接口函数以及游戏人物相关接口函数等接口函数，分别用于执行游戏中的相关功能，例如装备相关接口函数用于购买装备或者出售装备等。测试逻辑脚本模块调用接口函数模块中的接口函数来执行测试过程。

游戏代码库中包括游戏代码程序集和加载与反射调用模块，其中，在编写接口函数时，可以调用程序代码程序集中的内容，例如操作指令或者装备名称等；加载与反射调用模块用于将测试代码库，即后续所述的DLL文件，加载到游戏进程中，并调用测试代码库中的初始化接口函数进行初始化参数配置，以及将测试逻辑脚本挂在到游戏人物上，以按照测试逻辑脚本的控制逐帧进行测试。

请参见图4，为本发明实施例提供的应用测试方法的流程示意图，该方法可以通过任何可以运行应用程序的设备来执行，例如设备可以包括安装Windows操作系统的PC、安装有Android操作系统、IOS操作系统或者塞班操作系统等智能操作系统的手机等，其中，本发明实施例的方法可以应用于所有应用的测试，后续的描述中，将主要以游戏程序的测试为例进行描述，但实质上对于其他类型的应用的测试思想是一致的，其他类型的应用可参考后续的描述。本发明实施例提供的应用测试方法的流程描述如下。

步骤401：生成用于对所述应用进程进行测试的DLL文件。

本发明实施例中，在进行对应用的测试之前，都需要针对想要测试的内容编写好测试代码，并将测试代码封装成DLL文件。

下面以针对多人在线战术竞技(Multiplayer Online Battle Arena，MOBA)类游戏测试为例，为保证游戏的正常进行，游戏的运营商需要定时的对游戏进行测试，一旦发现Bug，尽早对Bug进行修复，以免影响到用户的使用体验。其中，该类游戏中通常包括多位游戏人物，每一个游戏人物拥有着不同的技能，技能释放后效果也不尽相同，同时，用户在玩耍时，还可以使用一些游戏道具，例如铭文或者装备来加强自己的游戏人物的技能效果，游戏中对于游戏人物的每一项操作都是通过相应的接口函数来控制，例如对于技能的释放需要调用释放相应技能的接口函数来完成，购买装备也需要调用购买相应装备的接口函数来完成。

例如针对游戏内的数值测试而言，即测试游戏内的实际数值与游戏介绍中的数值是否相符，例如装备介绍上的属性值与穿戴这件装备后给游戏人物实际增加的属性值是否相符，或者游戏人物的技能介绍上的伤害值与释放该技能后实际对敌方造成的伤害值是否相符等等。在进行游戏测试之前，需要预先编写好测试过程中的所有测试用例，一个测试用例用于执行应用进程中的一个测试功能，例如购买指定的装备，释放指定的技能等等，换句话说，一个测试用例实质上就是测试过程中所需要调用的一个接口函数。测试用例编写完成之后，再针对整个测试过程编写好测试逻辑脚本，其中，测试逻辑脚本是整个测试过程的测试逻辑，测试逻辑脚本中指示了测试用例间的执行逻辑关系，即测试过程中首先执行哪个测试用例，后续再执行哪个测试用例，都被编写到了测试逻辑脚本中，一旦测试逻辑脚本开始运行，就可以按照编写好的顺序执行各个测试用例，从而完成测试。

具体的，一般通过Mono版，即非IL2CPP版本的Unity平台开发的基于在Android操作系统的游戏，游戏包(Android Package，APK)被解压后，在特定的文件下可以找到该游戏的游戏代码程序集，在编写测试代码时，可以引用游戏代码中的内容，例如引用其中包括的购买装备的接口函数，或者引用其中包括的装备属性获取以及技能释放接口函数等等。如图5所示，为某游戏的APK被解压后Managed文件夹的示意图，其中Managed文件夹中包含了一文件名为Assembly-CSharp.dll的DLL文件，该DLL文件即为该游戏的游戏代码程序集，在编写自己的测试代码程序集时，就可以引用Assembly-CSharp.dll中的内容。

本发明实施例中，在根据测试需求编写完成测试所需的测试接口函数以及调用测试接口函数的测试逻辑脚本后，封装生成DLL文件，DLL文件即为封装好的测试程序集。对于游戏测试，DLL文件命名例如可以为gametestlib.dll。

当然，针对于其他类型的应用测试时，也可以针对该应用的测试需求合理的编写测试接口函数以及调用这些测试接口函数进行测试的测试逻辑脚本，并封装成DLL文件，具体可参考上述游戏的描述，在此不过多赘述。

步骤402：在应用进程启动后，通过应用进程中的加载接口函数，将DLL文件加载至应用进程中。

本发明实施例中，应用进程中设置了加载模块，该加载模块中包括至少一个加载接口函数，用于在应用进程中加载可被动态加载到应用进程中的程序集，例如上述封装好的DLL文件。

正常而言，用户在使用应用进程时，是用户自身在对应用进程进行控制，那么对于测试而言，实质上也是对应用进程的一种使用，只不过通常是通过测试脚本替代了人力，来自动运行应用进程，以发现应用进程在运行过程中是否会出现异常。例如对于游戏而言，在玩游戏时，用户都是自己来操作游戏人物，比如让游戏人物移动、释放技能或者购买装备等操作，都是用户通过对屏幕上显示的功能按钮进行操作来实现的，而在进行游戏测试时，若是单单靠人力的对游戏进行试玩是很消耗人力资源的，因此一般都是通过测试脚本，来控制游戏自动运行，游戏中的操作都是依靠测试脚本调用接口函数来实现的。

因此，在开始对应用进行测试，也是与正常使用应用相同的启动应用进程，再通过应用进程中的加载模块，可以将封装好的DLL文件加载到应用进程中，这样，对于DLL文件中用于测试的所有接口函数都可以在被调用时，在应用进程中被执行来实现相应的功能。

具体的，为了能够正常的加载DLL文件，DLL文件通常需要被放置到指定的文件目录下，这样，在加载DLL文件时，才能够找到该DLL文件。例如，沿用上述游戏测试的例子，在生成上述的gametestlib.dll之后，可以将gametestlib.dll放置到指定的文件目录下，例如游戏文件夹下的/data/local/tmp/中。

具体的，在C#中包括Assembly类，Assembly类表示一个程序集，通过Assembly类可以将基于.NET平台开发的程序集加载到发生加载操作的应用程序域中，以及浏览程序集的元数据和构成部分、发现程序集中包含的类型以及创建这些类型的实例等等。其中，Assembly类中包括多种加载程序集的方法，那么就可以通过Assembly类中的加载方法将上述DLL文件加载至应用进程中。Assembly类中较为常用的是如下几种加载方法，即：

(1)Load方法，即System.Reflection.Assembly.Load()，Load方法可以将一个String或AssemblyName类型作为参数，这个参数实质上即为需要加载的程序集的强名称，例如名称、版本、语言或者公钥标记。

(2)LoadFrom方法，即System.Reflection.Assembly.LoadFrom()，LoadFrom方法可以从指定文件中加载程序集，在加载程序集时，首先会打开程序集文件，通过GetAssemblyName方法得到程序集名称，然后关闭文件，最后将得到的AssemblyName对象传入Load()方法中，在通过Load()方法会再次打开这个文件进行加载。所以，LoadFrom方法加载一个程序集时，会多次打开文件，与Load方法相比，效率相对比较低。

(3)LoadFile方法，即System.Reflection.Assembly.LoadFile()，LoadFile方法也可以从一个指定文件中加载程序集，但是与LoadFrom方法不同，LoadFile方法不会加载目标程序集所引用和依赖的其他程序集。

当然，除了上述的加载方法，还可以通过其他可能的加载方法将DLL文件加载到应用进程中，本发明实施例对此不进行限制。

步骤403：将DLL文件中的测试逻辑脚本挂载到应用进程中执行测试用例的对象上，使得该对象基于测试逻辑脚本的指示在应用进程中执行相应测试用例。

本发明实施例中，将DLL文件加载到应用进程中之后，则可以通过DLL文件来进行应用的测试。

本发明实施例中，DLL文件中包括初始化接口函数，初始化接口函数用于在应用进程中进行必要的初始化配置，为后续的测试提供必要的运行环境。为了调用DLL文件中所包括的初始化接口函数，可以利用C#中的反射调用机制，其中，在C#中，System.Type类是一种可以得到程序集中的类型信息的类，因此，可以通过System.Type类获取到DLL文件中的内部信息，从而才能对DLL文件中的初始化接口函数进行反射调用。

具体的，通过Assembly类中的加载方法加载DLL文件之后，则可以通过应用进程中的GetType方法获取DLL文件中指定命名空间下的程序集信息，并通过应用进程中的GetMethod方法从程序集信息中获取初始化接口函数。

沿用上述游戏测试的例子，该游戏测试的初始化接口函数为初始化(init)方法，该init方法位于测试(Test)类信息中，Test类信息位于命名空间GameTest中，那么加载和调用init方法的方式就可以如下：

Assembly assembly＝Assembly.Load("gametestlib.dll")；

Type type＝assembly.GetType("GameTest.Test")；

MethodInfo method＝type.GetMethod(“init”)；

其中，上述的示例中，通过Assembly类中的Load方法加载测试程序集gametestlib.dll，再通过GetType方法获取gametestlib.dll中命名空间GameTest中的Test类信息，再通过GetMethod方法从Test类信息获取到init方法。

当然，在调用初始化接口函数时，也可以采用其他可能的调用方式，本发明实施例对此不做限制。

本发明实施例中，除了可以通过初始化接口函数在应用进程中进行必要的初始化参数配置之外，还可以将DLL文件中的测试逻辑脚本挂载到应用进程中的对象上，这样，该对象就可以在测试逻辑脚本的指示下执行相应的测试用例。

同样沿用上述游戏测试的例子，这里所述的对象即是指游戏对象(GameObject)，游戏对象可以是游戏中的游戏人物，那么在挂载时，则可以将测试逻辑脚本挂载到其中一个游戏人物的组件(Component)上，这样游戏人物就可以在测试逻辑脚本的控制下每一帧的去执行相应的操作，来完成一局或者多局游戏。例如测试逻辑脚本中包括三个测试用例，顺序为购买A装备、释放B技能以及出售A装备，那么游戏人物则会按照测试逻辑脚本中的顺序依次执行购买A装备、释放B技能以及出售A装备这些操作，当然，这仅仅是举例说明，在实际应用中，测试用例的数量可以是很多的。

步骤404：在各个测试用例的执行过程中，收集与测试用例相对应的测试数据。

本发明实施例中，为了能够最终得到应用测试的测试结果，那么在每个测试用例的执行过程中，则需要收集相应的测试数据，以供后续对测试数据进行分析，得到测试结果。其中，收集的测试数据可以直接存储在执行测试过程的设备上，或者，为了测试数据存储的可靠性，还可以将测试数据存储在服务器上，例如可以存储在指定的数据库服务器(DataBase Server，DB Server)上。

具体的，以游戏数值测试为例，测试数据例如可以是在购买装备并且穿戴后游戏人物的属性变化值，还可以是释放技能后游戏人物的属性变化值，或者释放技能后对敌方造成的伤害值等，当然，还可以是其他可能的数据，针对不同类型的测试所需要采集的测试数据有所不同，具体可以根据测试需求进行设置。

步骤405：针对每一个测试用例的测试数据进行分析，得到测试结果。

本发明实施例中，在得到某一测试用例的测试数据之后，则可以将测试用例的测试数据的数值与该测试用例对应的预设数值进行比较，在测试数据的数值与预设数值相等时，得到指示测试用例数值未出现异常的测试结果；或者，在测试数据的数值与预设数值不相等时，得到指示测试用例数值异常的测试结果。

沿用上述的游戏数值测试的例子，在针对游戏中装备的数值测试时，可以针对游戏中的每一件装备，记录游戏人物在穿戴装备之前和穿戴装备之后的游戏人物的属性值，这样，就可以得到该装备可以为该游戏人物提供的属性值。例如，对于A装备而言，该装备的装备介绍中在穿戴该装备后为游戏人物增加50点生命值，10点物理攻击，如表1所示，为购买A装备的测试用例的测试数据。

属性	穿戴A装备前	穿戴A装备后
			生命值	100	150
物理攻击	50	60
			法术攻击	70	70
速度	20	20

根据表1的测试数据，该游戏人物在穿戴A装备后，生命值增加了50点，物理攻击增加了10点，而法术攻击和速度未发生变化，也就是说测试数据是与A装备的介绍的数值相同的，那么就可以确定A装备的数值是正常的。

本发明实施例中，在对应用进行测试时，一般都会测试较多个测试用例，针对每一个测试用例，都可以通过上述的过程判断是否存在异常，在遍历所有的测试用例后，即可得到指示应用进程是否异常的测试结果，即任意一个测试用例出现异常，测试结果均会指示异常，若是未发现任何测试用例出现异常，则可得到指示应用进程无异常的测试结果。

综上所述，本发明实施例中，通过将测试代码封装成DLL文件，在进行测试时，通过应用进程中的加载接口函数，将DLL文件加载到应用进程中，并挂载到应用进程上的对象上来执行，从而进行测试。这样，由于本发明实施例中的测试代码和应用程序的代码是完全分离的，在想要对测试代码进行修改时，只需要将修改后的测试代码在此封装成DLL文件即可，相较将测试代码嵌入到应用程序的代码中的方案，省去了再次进行编译的时间，进而相应地提升了测试效率。此外，由于测试代码无需嵌入到应用程序的代码中，则不会对应用程序的代码造成污染，减少应用程序的代码潜在的代码风险。

请参见图6，基于同一发明构思，本发明实施例还提供了一种应用测试装置，包括：

加载模块601，用于在应用进程启动后，通过应用进程中的加载接口函数，将用于对应用进程进行测试的动态链接库DLL文件加载至应用进程中，其中，DLL文件中包括调用不同测试用例进行测试的测试逻辑脚本，测试逻辑脚本中指示了测试用例间的执行逻辑关系，一个测试用例用于执行应用进程中一个测试功能；

挂载模块602，用于将测试逻辑脚本挂载到应用进程中执行测试用例的对象上，使得对象基于测试逻辑脚本的指示在应用进程中执行相应测试用例，并在执行过程中收集与测试用例相对应的测试数据；

数据分析模块603，用于针对每一个测试用例的测试数据进行分析，得到测试结果。

可选的，加载模块601，具体用于：

通过应用进程包括的Assembly类中的加载方法，将DLL文件加载至应用进程中。

可选的，加载模块601，具体用于：

通过Assembly类中的Load方法将DLL文件加载至应用进程中；或者，

通过Assembly类中的LoadFrom方法将DLL文件加载至应用进程中；或者，

通过Assembly类中的LoadFile方法将DLL文件加载至应用进程中。

可选的，挂载模块602，具体用于：

反射调用DLL文件中的初始化接口函数；

通过初始化接口函数进行初始化参数配置，并将测试逻辑脚本挂载到应用进程中的对象上，使得对象基于测试逻辑脚本的指示在应用进程中执行相应测试用例。

可选的，挂载模块602，具体用于：

通过应用进程中的GetType方法获取DLL文件中指定命名空间下的程序集信息；

通过应用进程中的GetMethod方法从程序集信息中获取初始化接口函数。

可选的，数据分析模块603，具体用于：

针对每一个测试用例，执行如下步骤：

将测试用例的测试数据的数值与该测试用例对应的预设数值进行比较；

在测试数据的数值与预设数值相等时，得到指示测试用例数值未出现异常的测试结果；或者，

在测试数据的数值与预设数值不相等时，得到指示测试用例数值异常的测试结果。

该装置可以用于执行图4和5所示的实施例中应用测试装置所能执行的方法，因此，对于应用测试装置的各功能模块所能够实现的功能等可参考图4和5所示的实施例的描述，不多赘述。

请参见图7，基于同一技术构思，本发明实施例还提供了一种应用测试设备，可以包括存储器701和处理器702。

所述存储器701，用于存储处理器702执行的计算机程序。存储器701可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据应用测试设备的使用所创建的数据等。处理器702，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等等。本发明实施例中不限定上述存储器701和处理器702之间的具体连接介质。本发明实施例在图7中以存储器701和处理器702之间通过总线703连接，总线703在图7中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线703可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器701可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器701也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器701是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器701可以是上述存储器的组合。

处理器702，用于调用所述存储器701中存储的计算机程序时执行如图4和5中所示的实施例中设备所执行的方法，例如应用测试设备可以为安装有应用进程的用户设备。

本发明实施例还提供了一种计算机存储介质，存储为执行上述处理器所需执行的计算机可执行指令，其包含用于执行上述处理器所需执行的程序。

在一些可能的实施方式中，本发明提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本发明各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图4和5中所示的实施例中设备所执行的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本发明的实施方式的方法的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种应用测试方法，其特征在于，所述方法包括：

在应用进程启动后，通过所述应用进程中的加载接口函数，将用于对所述应用进程进行测试的动态链接库DLL文件加载至所述应用进程中，其中，所述DLL文件中包括调用不同测试用例进行测试的测试逻辑脚本，所述测试逻辑脚本中指示了测试用例间的执行逻辑关系，一个测试用例用于执行所述应用进程中一个测试功能；

将所述测试逻辑脚本挂载到所述应用进程中执行测试用例的对象上，使得所述对象基于所述测试逻辑脚本的指示在应用进程中执行相应测试用例，并在执行过程中收集与测试用例相对应的测试数据；

针对每一个测试用例的测试数据进行分析，得到测试结果。

2.如权利要求1所述的方法，其特征在于，所述通过所述应用进程中的加载接口函数，将用于对所述应用进程进行测试的DLL文件加载至所述应用进程中，包括：

通过所述应用进程包括的Assembly类中的加载方法，将所述DLL文件加载至所述应用进程中。

3.如权利要求2所述的方法，其特征在于，所述通过所述应用进程包括的Assembly类中的加载方法加载所述DLL文件，包括：

通过所述Assembly类中的Load方法将所述DLL文件加载至所述应用进程中；或者，

通过所述Assembly类中的LoadFrom方法将所述DLL文件加载至所述应用进程中；或者，

通过所述Assembly类中的LoadFile方法将所述DLL文件加载至所述应用进程中。

4.如权利要求1所述的方法，其特征在于，所述将所述测试逻辑脚本挂载到所述应用进程中的对象上，使得所述对象基于所述测试逻辑脚本的指示在应用进程中执行相应测试用例，包括：

反射调用所述DLL文件中的初始化接口函数；

通过所述初始化接口函数进行初始化参数配置，并将所述测试逻辑脚本挂载到所述应用进程中的对象上，使得所述对象基于所述测试逻辑脚本的指示在应用进程中执行相应测试用例。

5.如权利要求4所述的方法，其特征在于，所述反射调用所述DLL文件中的初始化接口函数，包括：

通过所述应用进程中的GetType方法获取所述DLL文件中指定命名空间下的程序集信息；

通过所述应用进程中的GetMethod方法从所述程序集信息中获取所述初始化接口函数。

6.如权利要求1～5任一所述的方法，其特征在于，所述针对每一个测试用例的测试数据进行分析，得到测试结果，包括：

针对每一个测试用例，执行如下步骤：

将测试用例的测试数据的数值与该测试用例对应的预设数值进行比较；

在测试数据的数值与预设数值相等时，得到指示测试用例数值未出现异常的测试结果；或者，

在测试数据的数值与预设数值不相等时，得到指示测试用例数值异常的测试结果。

7.一种应用测试装置，其特征在于，包括：

加载模块，用于在应用进程启动后，通过所述应用进程中的加载接口函数，将用于对所述应用进程进行测试的动态链接库DLL文件加载至所述应用进程中，其中，所述DLL文件中包括调用不同测试用例进行测试的测试逻辑脚本，所述测试逻辑脚本中指示了测试用例间的执行逻辑关系，一个测试用例用于执行所述应用进程中一个测试功能；

挂载模块，用于将所述测试逻辑脚本挂载到所述应用进程中执行测试用例的对象上，使得所述对象基于所述测试逻辑脚本的指示在应用进程中执行相应测试用例，并在执行过程中收集与测试用例相对应的测试数据；

数据分析模块，用于针对每一个测试用例的测试数据进行分析，得到测试结果。

8.如权利要求7所述的装置，其特征在于，所述加载模块，具体用于：

通过所述应用进程包括的Assembly类中的加载方法，将所述DLL文件加载至所述应用进程中。

9.一种应用测试设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-6中任一权利要求所述的方法。

10.一种计算机可读存储介质，其特征在于：

所述计算机存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如权利要求1-6中任一项所述的方法。