一种基于可编程式测试服务的创建方法及装置与流程

本发明涉及计算机技术领域，尤其涉及一种基于可编程式测试服务的创建方法及装置。

背景技术：

随着信息技术的发展，网络服务商后台的服务系统可以为用户提供各类丰富的业务服务。业务服务的顺利实现，通常依赖于服务系统内部的各功能单元之间的交互、以及服务系统与外部系统的交互。

目前，在对业务服务进行开发测试的过程中，为了保证业务服务在实际应用时能够正常运行，需要对业务服务进行运行模拟测试，也即，针对业务服务进行mock。其中，mock是指在针对某一待测对象A，构造虚拟的运行环境，模仿待测对象A在实际运行场景中的运行逻辑，包括：待测对象A在实际应用时与服务系统内部各功能单元之间的调用及交互、以及与外部系统之间的调用及交互等。

现有技术中，当开发者要对待测业务服务进行mock时，通常会将待测业务服务的业务代码部署至具有mock功能的服务器中，针对部署至服务器中的业务代码，开发者可以根据实际需要，进行不同运行场景下的mock，其具体方式为：开发者将所需的运行场景和运行参数，以mock代码的方式部署至服务器中，并与待测业务服务的业务代码进行耦合，从而，服务器则会将mock代码转换形成mock服务(该mock服务只针对该待测业务服务)，用以实现在相应运行场景下对该业务服务进行模拟测试。

但是，在实际应用中，很多特定的业务服务需要多种类型的测试结果，由于mock代码与待测业务服务的业务代码耦合在一起，只能进行固定类型的测 试，若开发者想要获得不同类型的测试结果，只能重新编写mock代码，并重复上述的耦合过程。另外，上述方式中mock服务只针对与其匹配的待测试业务服务，而很多业务服务之间相互关联，其运行场景相同，采用上述方式进行mock时，其他待测业务服务不能使用该mock服务。显然，在大量开发测试的情况下，上述mock方式将严重影响模拟测试的效率。

技术实现要素：

本发明实施例提供一种基于可编程式测试服务的创建方法及装置，用以解决传统的mock服务进行模拟测试时的效率较低的问题。

本发明实施例提供的一种基于可编程式测试服务的创建方法，包括：

测试平台接收测试环境信息对应的代码；

对所述代码进行编译；

根据编译后的代码，确定所述测试环境信息对应的服务类型；

根据预设的与所述服务类型对应的发布方式，发布所述编译后的代码，用以对不同类型的测试请求进行处理。

本发明实施例另提供的一种基于可编程式测试服务的创建方法，包括：

测试平台接收测试请求；

确定所述测试请求对应的测试环境信息；

根据所述测试环境信息，在已发布的所有代码中，查找与所述测试请求对应的所述测试环境信息相同的代码；

调用查找到的所述代码对所述测试请求进行处理。

本发明实施例另提供的一种基于可编程式测试服务的创建装置，包括：

接收模块，用于接收测试环境信息对应的代码；

编译模块，用于对所述代码进行编译；

确定模块，用于根据编译后的代码，确定所述测试环境信息对应的服务类型；

发布模块，用于根据预设的与所述服务类型对应的发布方式，发布所述编译后的代码，用以对不同类型的测试请求进行处理。

本发明实施例另提供的一种基于可编程式测试服务的创建装置，包括：

接收模块，用于接收测试请求；

确定模块，用于确定所述测试请求对应的测试环境信息；

查找模块，用于根据所述测试环境信息，在已发布的所有代码中，查找与所述测试请求对应的所述测试环境信息相同的代码；

处理模块，用于对所述测试请求进行处理。

本发明实施例提供一种基于可编程式测试服务的创建方法及装置，测试平台接收测试环境信息对应的代码，在对该代码进行编译后，确定出测试环境信息对应的服务类型，并按照不同的发布方法，将编译后的代码发布在测试平台中。这样的方式，不同于现有技术中测试代码与业务代码绑定耦合的方式，开发者通过测试平台，不仅可以查找已经发布且适用的代码进行模拟测试，而且可以根据已经发布的代码所对应的测试环境信息，对测试场景相同的其他业务服务进行测试，从而改变了现有技术中相同运行场景的不同业务服务，不能使用同一测试代码的缺陷，有效提升了大量开发测试情况下，模拟测试的效率。

附图说明

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

图1为本发明实施例提供的接收的基于可编程式测试服务的创建过程示意图；

图2为本发明实施例提供的测试平台的平台界面的示意图；

图3为本发明实施例提供的对mock请求处理的过程示意图；

图4为本发明实施例提供的基于可编程式测试服务的创建装置结构示意 图。

图5为本发明实施例提供的基于可编程式测试服务的创建装置结构示意图。

具体实施方式

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

图1为本发明实施例提供的基于可编程式测试服务的创建过程，该过程具体包括以下步骤：

S101，测试平台接收测试环境信息对应的代码。

在本申请实施例中，所述的测试平台可以由具有模拟测试功能的服务器或者服务器集群构成。需要说明的是，本申请中采用测试平台的方式，使得接收到的代码公开化，也即，对于任一开发者，均可以在该测试平台上调用其他开发者上传的代码。

在上述步骤S101中，所述的测试环境信息，就是待测业务服务进行模拟测试时所需的信息，该测试环境信息中定义了进行模拟测试时待测业务服务的运行场景、与服务系统内的各功能单元进行交互的接口、交互的数据值、返回值等信息。

本申请实施例中的所述的代码具体可以编写在mock脚本中，也即，对于上述步骤S101而言，接收测试环境信息对应的代码，具体为：接收mock脚本，其中，所述mock脚本中包含以代码方式编写的测试环境信息。

S102，对所述代码进行编译。

在本申请实施例中，服务器对测试环境信息对应的代码进行编译，就是服 务器读取该代码中包含的内容的过程。也即，通过对所述代码进行编译，使得服务器可以获知该测试环境信息的具体内容，以便后续进行模拟测试。

其中，所述编译的方式包括但不限于：静态编译或动态编译。其中，静态编译是指针对代码中涉及的类和方法，无论当时是否使用，均全部进行加载；动态编译是指针对代码中涉及的类和方法，只在需要使用时才进行加载。两种加载方式均可以用于本申请中对所述代码的编译过程，这里并不构成对本申请的限定。

S103，根据编译后的代码，确定所述测试环境信息对应的服务类型。

在实际应用中，不同的业务服务通常对应不同的服务类型，例如：网站提供网页显示的业务服务，那么，该业务服务对应的类型就是超文本传输协议(Hypertext transfer protocol，Http)服务。又例如：服务器系统向气象台获取天气信息的业务服务，其对应的类型是传输控制协议(Transmission Control Protocol，TCP)服务(即通过特定TCP接口，接收气象台传输的天气信息)。

可见，不同的业务服务对应不同的服务类型，那么，对于业务服务的开发测试而言，也将基于相同的服务类型。因此，对于任一待测业务服务来说，其对应的服务类型，就是其测试环境代码所对应的服务类型。故服务器可以根据编译后的代码，确定出不同的测试环境信息对应的服务类型。

这里需要说明的是，本申请实施例中，测试环境信息对应的服务类型，包括但不限于：Http服务、TCP服务、webservice服务、tair服务等。

S104，根据预设的与所述服务类型对应的发布方式，发布所述编译后的代码，用以对不同类型的测试请求进行处理。

不同的服务类型，所涉及到的交互方式、后台所需调用的功能均不相同，为了能够使得不同服务类型的代码顺利运行，所以在服务器针对代码进行编译后，便会根据测试环境信息对应的服务类型，按照不同的方式发布所述代码。

需要说明的是，在本申请实施例中，发布后的代码将作为所述测试平台的一项测试服务，并在全平台可见，也就是说，访问该平台的开发者，可以浏览、 查阅并使用已经发布的所述代码，这样的方式改变了传统进行mock时“私有化”的方式，也即，测试代码不再与待测业务服务的业务代码相耦合，而转变成一种全平台通用的测试服务。

通过上述方法，测试平台接收测试环境信息对应的代码，在对该代码进行编译后，确定出测试环境信息对应的服务类型，并按照不同的发布方法，将编译后的代码发布在测试平台中。这样的方式，不同于现有技术中测试代码与业务代码绑定耦合的方式，开发者通过测试平台，不仅可以查找已经发布且适用的代码进行模拟测试，而且可以根据已经发布的代码所对应的测试环境信息，对测试场景相同的其他业务服务进行测试，从而改变了现有技术中相同运行场景的不同业务服务，不能使用同一测试代码的缺陷，有效提升了大量开发测试情况下，模拟测试的效率。

在实际应用场景下，代码的实现基于类，其中，类是用于定义特定类型的对象而使用的方法和变量的模板。也就是说，代码中所使用的逻辑方法以及变量的赋值，是由类进行定义的，故测试平台要执行该代码时，就需要获知该代码的逻辑方法以及变量的赋值，也即，测试平台需要加载该代码中的类。而在本申请实施例中，代码携带在mock脚本中，因此，在本申请实施例中，对所述代码进行编译，具体为：加载所述mock脚本中代码所包含的类，以对所述代码进行编译。

在本申请实施例中，对mock脚本中代码的类进行加载，往往是通过类加载器实现的，例如：通过Java虚拟机(Java Virtual Machine，JVM)对类进行加载(也即，从相应的类库中加载代码中类所对应的类文件)。在某些情况下，用户所编写的代码中所使用的类均是默认类，其中，所述默认类是默认类库中默认存储的类文件所对应的类，也即，服务器可以直接使用默认类加载器对代码中的类进行加载(加载默认类库中的类文件)，而在实际应用中，用户所编写的代码中使用到的类并非是默认类(也即，代码中包含的类所对应的类文件并非是默认类库中的类文件，而是第三方的类文件)，这样一来，服务器便不 能使用默认类加载器来加载这些类。所以在本申请实施例中，加载所述mock脚本中包含的代码所对应的类，具体为：确定所述代码中包含的类所属的类型，若所述类属于默认类，则调用默认类加载器加载所述类，若所述类不属于默认类，则调用自定义类加载器加载所述类。

需要说明的是，在本申请实施例中，测试平台确定所述代码中包含的类所属的类型，其方式具体可以是通过确定代码中类的类名以及代码中所使用的逻辑方法的结合，来确定所述代码中的类所属的类型。这里并不构成对本申请的限定。

在本申请实施例中，使用默认类加载器和自定义类加载器对类进行加载的过程并不相同，下面对两类过程进行说明，具体而言：

在服务器调用默认类加载器的情况下，就表明mock脚本中代码包含的类是默认类，但是考虑到实际应用场景下，开发者用户在编写所述代码时，使用的类名可能会根据用户的喜好自行定义(类中定义的方法和变量仍与默认类相同，并未发生变化)，在这样的情况下，由于类名发生了变化的类，使得默认类加载器不能准确地从默认类库中加载该类对应的类文件，即类加载器并不能有效地对该代码中的类进行加载，因此在本申请实施例中，调用类加载器加载所述类，具体为：确定所述代码中包含的类对应的类名，判断所述类名是否为默认类的类名，若是，则调用所述默认类加载器直接加载所述类，否则，则将所述类名重命名为默认类名，再调用默认类加载器加载所述类。也即，默认类加载器会对代码中类的类名重命名为默认类名，从而，使得默认类加载器可以顺利对mock脚本中代码的类进行加载。

也就是说，若代码中默认类的类名没有发生变化，那么，测试平台可以直接针对该代码中包含的类，在默认类库中加载该类对应的类文件。而若代码中默认类的类名发生了变化，那么，测试平台会将该类的类名重命名为默认类的类名，从而便可以在默认类库中找到该类对应的类文件，并进行加载。

在服务器调用自定义类加载器的情况下，就表明代码中使用的类并非默认 类。这就需要服务器在加载这些非默认类时，通过相应的路径查找到非默认类对应的类文件(此时，服务器并不能在默认类库中查找到类文件)。

另外，考虑到在实际应用中，服务器可能接收到多个不同的mock脚本，这些mock脚本中的代码均可能使用了非默认类，这样一来，服务器就会针对每一mock脚本，分别调用各自的自定义类加载器，通过查找不同的路径来加载这些mock脚本中代码的非默认类，为了不发生调用混乱的现象，故服务器会采用标记的方式，也即，在本申请实施例中，调用自定义类加载器加载所述类，具体为：确定所述类文件的存储路径，调用自定义类加载器，并为该自定义类加载器设置身份标识，建立所述身份标识与所述存储路径的对应关系，通过所述自定义类加载器，加载与该自定义加载器的身份标识对应的存储路径所指向的类文件。

这里需要说明的是，存储路径所指向的可能是类文件，也可能是存储类文件的文件目录。若存储路径所指向的是类文件，则自定义类加载器从该类文件中查找非默认类。而若存储路径所指向的文件目录，则自定义类加载器在该文件目录中查找类文件，查找到了类文件之后，在该类文件中查找非默认类。成功查找到非默认类，那么，便可以对非默认类进行加载，但是如果未查找到非默认类，那么，服务器会返回异常提示信息，以告知开发者用户未能成功查找到非默认类，以使得开发者用户重新调整存储路径或重新上传正确的类文件。

在实际应用中，当开发者用户在其编写的代码中使用了非默认类时，通常开发者用户会将该非默认类所需的类文件上传至所述测试平台中，以便测试平台在对该mock脚本中的代码进行编译时使用。其中，开发者用户所上传的类文件的文件格式可以为jar、zip等，这里并不作出具体限定。当然，在实际应用中，自定义类加载器，也可以由开发者上传至测试平台中，从而，当测试平台对该开发者的代码中的非默认类进行加载时，就会调用该开发者上传的自定义类加载器，用以加载该开发者上传的非默认类文件。上述方式只是对本申请实施例中的示例，在实际应用中并不局限在上述方式中，例如：在实际应用中， 自定义类加载器可以由测试平台提供，测试平台提供的自定义类加载器可适用于加载各种类型的类文件。这里并不构成对本申请的限定。

测试平台通过上述方式实现对类的加载，这样便可以顺利地完成对mock脚本中代码的编译。当测试平台成功编译了代码后，就会将编译后的代码发布在整个测试平台中，这样一来，该代码就会对所有访问该测试平台的不同开发者可见，开发者可根据使用需要，调用该代码进行相应的模拟测试。

这里需要说明的是，在实际应用中，不同的测试环境信息定义了不同的服务类型，测试平台根据编译后的代码，就可以确定出该代码对应的测试环境信息所属的服务类型。在本申请实施例中，测试环境信息对应的服务类型如上所述，也即，至少包括：Http服务、TCP服务、webservice服务、tair服务。而对于不同的服务类型来说，在测试过程中，所要调用的服务、测试环境的运行逻辑等均不相同，所以，为了保证不同服务类型的代码在模拟测试时可以正常有效地运行，测试平台就需要针对不同服务类型的代码，以不同的方式进行发布。

具体而言，在本申请实施例中，根据预设的与所述服务类型对应的发布方式，发布所述代码，具体为：当所述服务类型为Http服务时，将所述mock脚本中的对象保存在所述服务器的内存中发布所述mock脚本，当所述服务类型为TCP服务时，通过mina服务框架发布所述mock脚本，当所述服务类型为webservice服务和tair服务时，通过xfire发布所述mock脚本。

需要说明的是，当所述测试环境信息对应的服务类型为Http服务时，就表明模拟测试时的运行环境是基本的网络服务，那么，测试平台会将代码的类所包含的对象(如：各类网络参数)存放在服务器的内存中，以实现对代码的发布。在进行Http服务的模拟测试时，测试平台就可从内存中调用存储的测试所需的网络参数，完成测试。

当所述测试环境信息对应的服务类型为TCP服务时，就表明模拟测试时的运行环境需要模拟与外部系统通过TCP连接进行交互的过程，此时，服务 器会使用mina框架(mina框架一种网络通信应用框架，主要针对TCP/IP、UDP/IP协议栈的通信框架)发布所述mock脚本，以实现基于TCP连接进行通信交互场景的模拟。通过mina框架，测试平台可在TCP服务的模拟测试时，实现对连接建立的监听、监测传输通道上是否有数据的读写、发送数据时的编码过程、接收数据时的解码过程、对指定数据的拦截(如：黑名单拦截)等运行场景。可见，本申请实施例中使用mina框架对TCP服务进行模拟测试，可以模拟丰富的运行场景，不仅为不同的开发者提供了多种运行场景的选择，而且通过多种运行场景的组合，其模拟测试更接近实际应用。

当所述测试环境信息对应的服务类型为webservice或tair服务时，就表明mock服务是一种网站服务或者是一种数据存储服务，这两类服务均模拟的是服务端，此时，服务器会使用web服务(如：Xfire，web服务引擎)发布所述mock脚本，以实现对服务端的模拟。

通过上述内容可以看出，本申请实施例中构建了一种可编程式的测试平台(也即，mock平台)，这样的测试平台与现有技术不同的是，开发者可以自己编写所需的各种测试环境信息(以模拟不同运行场景)，形成mock脚本发送至该测试平台上，该测试平台会根据不同服务类型的mock脚本，采用不同的方式进行发布，使得mock脚本对全平台可见，发布后的mock脚本不仅能够对当前的待测业务服务进行模拟测试，其他开发者还可在该测试平台上调用该mock脚本，以对其他待测业务进行模拟测试。

下面以一应用实例对所述测试平台进行说明：

如图2所示，是本申请实施例中测试平台提供的平台界面，对于任一访问该测试平台的开发者，均可以使用该平台界面。图2中的所述平台界面，显示了每一个在该测试平台上发布的代码，使得不同的开发者可以通过该平台界面，直观地浏览到该开发者自己所发布的，以及其他开发者所发布的代码，并且对于每一开发者，均可以通过该平台界面，使用任一已发布的代码。

其中，在图2中的区域A1中显示的是在该测试平台上已经发布的不同的 代码的标识，具体包括：代码的编号和名称。

区域A2中显示的是每一代码所属的服务类型，所述平台界面中包括4种服务类型，分别为：http(也即Http服务)、tcp(也即TCP服务)、ws(也即webservice服务)以及tr(也即tair服务)。

区域A3中显示的是每一代码对应的地址，具体而言，对于http而言，其代码的地址为统一资源定位符(Uniform Resource Locator，URL)。对于ws和tr，其代码的地址都是服务器域名。对于tcp而言，其代码的地址为端口号。

并且在图2中的平台界面中，还提供了操作选项(图2中右侧名为“操作”的列)，开发者可以通过操作选项对自己所发布的代码进行编辑，且其他开发者可以通过该操作选项，使用相应的代码进行模拟测试。当然，实际应用中可能出现不同开发者对代码编辑的混乱现象，故在本申请实施例中，可以采用校验开发者身份的方式，防止上述现象的发生，也即，各开发者均使用身份信息登录至该平台中，并且，每一开发者只能编辑自己所发布的代码，而不能编辑其他开发者发布的代码。这里并不构成对本申请的限定。

从上例可见，与现有技术不同的是，现有技术中的mock平台所提供的mock服务深度嵌入在待测业务服务的业务代码中，开发者只能使用该mock服务对该待测业务服务进行测试，而在本申请实施例中，正是通过本申请实施例中测试平台的方式，使得用户可以随意地构建自身所需的各类mock服务，并且mock服务并非与待测业务服务深度耦合，其他开发者也可以使用该开发者的代码，对其他的业务服务进行模拟测试，有效提升了该测试平台中mock服务的可用性，并且，用户还可以选择从测试平台中，将所属该用户且已发布的代码撤销，即可拔插的方式，使得该测试平台的灵活性极大增强。

以上为本申请实施例中，建立可编程式测试平台的过程。在可编程式测试平台建立之后，便可以对不同的测试请求进行处理，具体地，基于可编程式测试平台的数据处理过程如图3所示，该过程具体如下：

S301，测试平台接收测试请求。

在本申请实施例中，在所述测试平台由服务器集群构成的情况下，可由该服务器集群中的任一台服务器接收测试请求。当然，本申请实施例中，服务器集群中可根据各台服务器的负载状态，来指定相应的服务器来接收该测试请求，进行模拟测试。这里并不构成对本申请的限定。

这里需要说明的是，本申请实施例中所述的测试请求，就是待测对象的测试请求。在本申请实施例中，所述的待测对象就是待测业务服务。

S302，确定所述测试请求对应的测试环境信息。

不同的待测业务服务，在进行模拟测试时，需要确定该待测业务服务的测试环境信息。在本申请中，待测业务服务所需的测试环境信息，是携带在测试请求中的，从而，测试平台接收到测试请求之后，就可以确定出该测试请求对应的测试环境信息。

S303，根据所述测试环境信息，在已发布的所有代码中，查找与所述测试请求对应的所述测试环境信息相同的代码。

在如图1所述的可编程式测试服务的创建方法中，不同开发者将其编写的测试环境信息对应的代码发布在所述测试平台中，从而，当测试平台接收到所述测试请求后，就会在已经发布的各代码中，确定出与当前待测业务服务的测试请求相匹配的代码，用来对该待测业务服务进行测试。

S304，调用查找到的所述代码对所述测试请求进行处理。

在查找到相应的代码后，测试平台就会调用该代码，对测试请求进行处理。

通过上述步骤，在本申请实施例中的测试平台上，当接收到的测试请求后，测试平台会根据该测试请求对应的测试环境信息，在该测试平台已经发布的所有代码中，查找出与该测试环境信息相匹配的代码，用来对所述测试对象进行模拟测试，正是由于测试平台的共用性，使得不同的测试对象均可以通过调用测试平台中已有的代码进行模拟测试，有效地提升了对待测对象进行模拟测试时的效率，同样，对于特定待测对象，想要进行多种类型的模拟测试，也可以从所述测试平台中查找适用的代码进行不同类型的模拟测试，不仅提升了开发 测试的效率，也提升了测试过程中的便捷性。

需要说明的是，在本申请实施例中，所述测试请求中携带有待测对象的默认的服务类型和/或运行环境。例如：假设某一天气业务服务是待测对象，其自身默认的服务类型为http服务，运行环境默认为成功接收到气象台的天气信息。而在实际应用中，为了测试该天气业务服务在实际运行过程中，遇到服务错误时的处理方案，所以，开发者可能会指定运行环境为接收天气信息失败。这样一来，用户所指定的运行环境就与该天气业务服务自身的运行环境发生了变化。

那么，上述步骤S302中，确定所述测试请求对应的测试环境信息，具体为：当所述测试请求中包含用户指定的服务类型和/或运行场景时，将用户指定的所述服务类型和/或运行场景，确定为所述测试请求对应的测试环境信息；当所述测试请求中不包含用户指定的服务类型和/或运行场景时，将所述待测对象对应的默认的服务类型和/或运行环境，确定为所述测试请求对应的测试环境信息。

以上为本发明实施例提供的基于可编程式测试服务的创建方法，基于同样的思路，本发明实施例还提供一种基于可编程式测试服务的创建装置。

如图4所示，基于可编程式测试服务的创建装置包括：接收模块401、编译模块402、确定模块403以及发布模块404，其中，

所述接收模块401，用于接收测试环境信息对应的代码。

所述编译模块402，用于对所述代码进行编译。

所述确定模块403，用于根据编译后的代码，确定所述测试环境信息对应的服务类型。

所述发布模块404，用于根据预设的与所述服务类型对应的发布方式，发布所述编译后的代码，用以对不同类型的测试请求进行处理。

在本申请实施例中，所述服务类型包括但不限于：超文本传输协议Http服务、传输控制协议TCP服务、webservice服务、tair服务等。

所述编译模块402，具体用于接收mock脚本。其中，所述mock脚本中包含以代码方式编写的测试环境信息。

所述发布模块404，具体用于当所述服务类型为Http服务时，将所述mock脚本中代码包含的对象保存在所述服务器的内存中发布所述mock脚本；当所述服务类型为TCP服务时，通过mina框架发布所述mock脚本；当所述服务类型为webservice服务或tair服务时，通过web服务发布所述mock脚本。

所述编译模块402，具体用于确定所述mock脚本中包含的类所属的类型，若所述类属于默认类，则调用默认类加载器加载所述类，若所述类不属于默认类，则调用自定义类加载器加载所述类。

更为具体地，所述编译模块402，具体用于确定所述mock脚本中包含的类对应的类名，判断所述类名是否为默认类的类名，若是，则调用所述默认类加载器直接加载所述类，否则，则将所述类名重命名为默认类名，再调用默认类加载器加载所述类。

以及，所述编译模块402，具体用于确定所述类文件的存储路径，调用自定义类加载器，并为该自定义类加载器设置身份标识，建立所述身份标识与所述存储路径的对应关系，通过所述自定义类加载器，加载与该自定义加载器的身份标识对应的存储路径所指向的类文件。

通过上述如图4所示的装置，可以构建相应的测试平台，从而，不同的开发者用户可以通过所述测试平台，对不同的待测对象(待测业务服务)进行模拟测试。相应地，在本申请实施例中，还提供一种基于可编程式测试服务的创建装置，如图5所示。所述装置包括：

接收模块501，用于接收测试请求。

确定模块502，用于确定所述测试请求对应的测试环境信息。

查找模块503，用于根据所述测试环境信息，在已发布的所有代码中，查找与所述测试请求对应的所述测试环境信息相同的代码。

处理模块504，用于对所述测试请求进行处理。

其中，所述测试请求中携带有待测对象的默认的服务类型和/或运行环境。

所述确定模块502，具体用于当所述测试请求中包含用户指定的服务类型和/或运行场景时，将用户指定的所述服务类型和/或运行场景，确定为所述测试请求对应的测试环境信息；当所述测试请求中不包含用户指定的服务类型和/或运行场景时，将所述待测对象对应的服务类型和/或运行环境，确定为所述测试请求对应的测试环境信息。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设 备中还存在另外的相同要素。

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

以上所述仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。