前端测试方法、装置及电子设备与流程

本申请涉及互联网应用技术领域，尤其是涉及一种前端测试方法、装置及电子设备。

背景技术：

现在开发项目中，为提高前后端开发效率，通常将前端和后端分离，后端负责业务/数据接口，前端负责展现/交互逻辑。对于前端开发而言，最终是展现的后端数据，而开发往往是同步进行的，在后端接口未完成的情况下，需要模拟后端接口定义的数据。

mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。

现有mock技术通用做法是根据特定的标识(一般为http(hypertexttransferprotocol)，超文本传输协议)请求定义一份虚假数据返回(此数据可能为随机数据)，前端开发时调用mock服务进行开发，后续待开发完成后再对接到完成的后端服务。

上述方式虽然解决了前端开发测试中前端依赖后端的问题，但是由于测试中接口测试请求过于单一，导致前端测试的真实性及灵活性较差，联调成本较高。

技术实现要素：

有鉴于此，本申请的目的在于提供一种前端测试方法、装置及电子设备，以实现不同参数条件模拟不同的应答信息，尽可能模拟真实环境，减少后续联调成本，并提高前端测试的真实性和灵活性。

第一方面，本申请实施例提供了一种前端测试方法，包括：

获取前端的待检测接口的访问请求，所述访问请求包括输入参数；

从预设规则库中选择与所述输入参数匹配的预设规则作为目标规则；

基于所述目标规则生成与所述目标规则对应的应答信息；

将所述应答信息反馈至所述前端。

结合第一方面，本申请实施例提供了第一方面的第一种可能的实施方式，其中，从预设规则库中选择与所述输入参数匹配的预设规则作为目标规则包括：

从预设规则库中读取预设规则；

将每一条预设规则分别与所述输入参数进行匹配；

从匹配成功的至少一条预设规则中选取一条作为目标规则。

结合第一方面，本申请实施例提供了第一方面的第二种可能的实施方式，其中，所述预设规则的类型为模拟规则或代理规则；

所述模拟规则包括输入参数的数据结构、应答信息数据结构、第一参数校验方法；

所述代理规则包括代理服务器地址及第二参数校验方法。

结合第一方面的第二种可能的实施方式，本申请实施例提供了第一方面的第三种可能的实施方式，其中，所述基于所述目标规则生成与所述目标规则对应的应答信息，包括：

对所述目标规则进行解析，得到所述目标规则的类型；

生成与所述目标规则的类型对应的应答信息。

结合第一方面的第三种可能的实施方式，本申请实施例提供了第一方面的第四种可能的实施方式，其中，如果所述目标规则的类型为模拟规则，则：

生成与所述模拟规则对应的模拟数据；

将所述模拟数据作为应答信息返回至所述前端。

结合第一方面的第四种可能的实施方式，本申请实施例提供了第一方面的第五种可能的实施方式，其中，所述生成与所述模拟规则对应的模拟数据包括：

利用mock.js模拟数据生成器或者faker.js模拟数据生成器生成与所述模拟规则对应的模拟数据。

结合第一方面的第三种可能的实施方式，本申请实施例提供了第一方面的第六种可能的实施方式，其中，如果所述目标规则的类型为代理规则，则：

从所述访问请求的输入参数中提取真实接口地址；

将所述访问请求发送到所述真实接口地址；

接收从所述真实接口地址返回的应答信息；

将所述应答信息返回至所述前端。

结合第一方面，本申请实施例提供了第一方面的第七种可能的实施方式，其中，所述获取前端的待检测接口的访问请求之前，还包括：将关联在同一场景下的待检测接口对应的预设规则进行关联，形成规则组。

结合第一方面的第七种可能的实施方式，本申请实施例提供了第一方面的第八种可能的实施方式，其中，所述输入参数中包括待检测接口所属的场景的标识；

所述从预设规则库中选择与所述输入参数匹配的规则作为目标规则包括：

根据所述场景的标识，确定对应的规则组；

基于确定的规则组，对所述输入参数进行校验，确定与所述输入参数对应的目标规则。

第二方面，本申请实施例还提供一种前端测试装置，包括：

请求接收模块，用于获取前端的待检测接口的访问请求，所述访问请求包括输入参数；

规则匹配模块，用于从预设规则库中选择与所述输入参数匹配的预设规则作为目标规则；

信息生成模块，用于基于所述目标规则生成与所述目标规则对应的应答信息；

应答返回模块，用于将所述应答信息反馈至所述前端。

结合第二方面，本申请实施例提供了第二方面的第一种可能的实施方式，其中，所述规则匹配模块包括：

规则读取单元，用于从预设规则库中读取预设规则；

规则匹配单元，用于将每一条预设规则分别与所述输入参数进行匹配；

规则选取单元，用于从匹配成功的至少一条预设规则中选取一条作为目标规则。

结合第二方面，本申请实施例提供了第二方面的第二种可能的实施方式，其中，所述预设规则的类型为模拟规则或代理规则；

所述模拟规则包括输入参数的数据结构、应答信息数据结构、第一参数校验方法；

所述代理规则包括代理服务器地址及第二参数校验方法。

结合第二方面的第二种可能的实施方式，本申请实施例提供了第二方面的第三种可能的实施方式，其中，所述信息生成模块还用于：

对所述目标规则进行解析，得到所述目标规则的类型；

生成与所述目标规则的类型对应的应答信息。

结合第二方面的第三种可能的实施方式，本申请实施例提供了第二方面的第四种可能的实施方式，其中，如果所述目标规则的类型为模拟规则，则所述信息生成模块包括：数据模拟单元，用于生成与所述模拟规则对应的模拟数据；

所述应答返回模块包括：第一返回单元，用于将所述模拟数据作为应答信息返回至所述前端。

结合第二方面的第四种可能的实施方式，本申请实施例提供了第二方面的第五种可能的实施方式，其中，所述数据模拟单元，还用于：

利用mock.js模拟数据生成器或者faker.js模拟数据生成器生成与所述模拟规则对应的模拟数据。

结合第二方面的第三种可能的实施方式，本申请实施例提供了第二方面的第六种可能的实施方式，其中，如果所述目标规则的类型为代理规则，则所述信息生成模块还包括：

请求发送单元，用于从所述访问请求的输入参数中提取真实接口地址；

请求发送单元，用于将所述访问请求发送到所述真实接口地址；

应答接收单元，用于接收从所述真实接口地址返回的应答信息；

所述应答返回模块还包括：第二返回单元，用于将所述应答信息返回至所述前端。

第三方面，本申请实施例还提供一种电子设备，包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面及其任一种可能的实施方式所述的方法。

第四方面，本申请实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行所述第一方面及其任一种可能的实施方式所述方法。

本申请实施例带来了以下有益效果：

在本申请实施例中，该前端测试方法包括获取前端的待检测接口的访问请求，该访问请求包括输入参数；然后根据从预设规则库中选择与该输入参数匹配的预设规则作为目标规则；基于上述目标规则生成与该目标规则对应的应答信息；将该应答信息反馈至所述前端。本申请提供的技术方案，将访问请求中根据实际接口需求定义的输入参数，与预设规则进行匹配，然后根据该输入参数匹配的预设规则返回对应的应答信息，从而实现了不同参数条件模拟不同的应答信息，以尽可能模拟真实环境，减少后续联调成本，并提高前端测试的真实性和灵活性。

本申请的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本申请实施例提供的一种前端测试方法的流程示意图；

图2为本申请实施例提供的另一种前端测试方法的流程示意图；

图3为本申请实施例提供的一种前端测试装置的结构示意图；

图4为本申请实施例提供的另一种前端测试装置的结构示意图；

图5为本申请实施例提供的另一种前端测试装置的结构示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

目前在前端开发过程中，前后端可以采用异步接口编程开发，该方式虽然解决了前端开发测试中前端依赖后端的问题，但是由于测试中接口测试请求过于单一，导致前端测试的真实性及灵活性较差，联调成本较高。

基于此，本申请实施例提供的一种前端测试方法、装置及电子设备，可以将访问请求中根据实际接口需求定义的输入参数，与预设规则进行匹配，然后根据该输入参数匹配的预设规则返回对应的应答信息，从而实现了不同参数条件模拟不同的应答信息，以尽可能模拟真实环境，减少后续联调成本，并提高前端测试的真实性和灵活性。

为便于对本实施例进行理解，首先对本申请实施例所公开的一种前端测试方法进行详细介绍。该方法可以应用于电子设备，如mock服务器或者mock平台，通过相关的硬件或者软件实现。

图1示出了本申请实施例提供的一种前端测试方法的流程示意图。如图1所示，该前端测试方法包括：

步骤s101，获取前端的待检测接口的访问请求，其中该访问请求包括输入参数。

其中上述输入参数的数据结构是根据前端与后端的接口需求定义的。上述访问请求的方式可以但不限于包括http请求中的“get”和“post”这两种方式中的任一种。

步骤s102，从预设规则库中选择与上述输入参数匹配的预设规则作为目标规则。

上述预设规则的类型为模拟规则或代理规则，存储于预设规则库中。其中模拟规则包括输入参数的数据结构、应答信息数据结构、第一参数校验方法；输入参数的数据结构中可以包括http头(httpheader)、查询参数类(query)、主体(body)等。在可能的实施例中，该模拟规则还可以包括调用的接口路径、请求方式；输入参数的数据结构中还包括路径参数。

代理规则包括代理服务器地址及第二参数校验方法，如当一些接口已完成开发，则可以直接设置该接口对应的代理规则，从而直接通过真实后端环境进行测试，提前介入联调缓解，减少后续联调成本。

上述步骤s102中，可以通过根据预设规则，对上述输入参数进行校验的方式，确定与输入参数对应的目标规则。

步骤s103，基于上述目标规则生成与该目标规则对应的应答信息。

步骤s104，将上述应答信息反馈至上述前端。

根据上述目标规则，生成相应的模拟数据作为应答信息，或者是至直接从后端获取应答信息，将该应答信息返回至前端，从而完成当前待检测接口的测试。

本申请提供的技术方案，将访问请求中根据实际接口需求定义的输入参数，与预设规则进行匹配，然后根据该输入参数匹配的预设规则返回对应的应答信息，从而实现了不同参数条件模拟不同的应答信息，以尽可能模拟真实环境，减少后续联调成本，并提高前端测试的真实性和灵活性。

在图1所示实施例的基础上，本申请实施例提供了另一种前端测试方法。如图2所示，该前端测试方法包括：

步骤s201，获取前端的待检测接口的访问请求，其中访问请求包括输入参数。

其中上述前端可以为客户端，该客户端将访问请求以http报文的形式发送至mock服务器或者mock平台。

输入参数的数据结构是根据前端与后端的接口需求定义的。上述访问请求的方式可以但不限于包括http请求方式中的“get”和“post”这两种方式中的任一种。

步骤s202，从预设规则库中读取预设规则。

其中，该预设规则库可以存储在本地或者是云端服务器中。在接收到访问请求后，即可从本地或者云端服务器获取该预设规则库。

上述预设规则的类型为模拟规则或代理规则。其中模拟规则包括输入参数的数据结构、应答信息数据结构、第一参数校验方法；输入参数的数据结构中可以包括http头(httpheader)、查询参数类(query)、主体(body)等。在可能的实施例中，该模拟规则还可以包括调用的接口路径、请求方式；输入参数的数据结构中还包括路径参数。

代理规则包括代理服务器地址及第二参数校验方法，如当一些接口已完成开发，则可以直接设置该接口对应的代理规则，从而直接通过真实后端环境进行测试，在后续联调环节，无需对该地址进行更改，直接使用该地址即可，降低了后续联调成本。

步骤s203，将每一条预设规则分别与上述输入参数进行匹配。

每一条预设规则均对应有相应的参数校验方法，在实现过程中，该参数校验方法可以通过代码编程封装为参数校验模块。在进行校验时，可以将上述输入参数，输入至相应的参数校验模块，从而对输入参数进行校验，比如校验上述输入参数的数据结构与预设规则的数据结构是否匹配，如果是，则确定匹配成功。如校验预设规则中定义的输入参数的数据结构与访问请求中的输入参数的数据结构是否匹配，或者预设规则中定义的真实接口地址与访问请求中输入参数中的代理服务器地址是否匹配。

当然上述参数校验模块的校验方法是可以由相关人员进行具体设定，如可以设定通过上述校验数据格式的方式校验，也可以设定通过校验路径的方式校验。如校验预设规则中的代理服务器地址或者是调用的接口路径，与访问请求中的输入参数的路径参数是否匹配。

需要说明的是，该真实接口地址为后端接口的真实地址，根据该真实接口地址，可以连接至后端的接口。当在前端测试时，对应的后端的接口已经完成时，则可以在输入参数中加入该后端的接口的真实地址，以方便后续使用真实后端服务。

在可能的实施例中，将访问请求中的输入参数依次与读取到的预设规则进行匹配，若输入参数与预设规则相匹配，则对应的参数校验模块返回值为真，否则返回值为假。

步骤s204，从上述匹配成功的至少一条规则中选取一条作为目标规则。

在可能的实施例中，根据所有返回值为真的预设规则，生成与上述访问请求对应的匹配规则数组，即将匹配规则作为该匹配规则数组的元素。如果该匹配规则数组为空，则可以返回错误代码404至前端，以表示未找到相关文件。

如果该匹配规则数数组非空，从该匹配规则数组中选取一条目标规则，如可以选取该匹配规则数组中的第一个元素，作为目标规则；当然也可以按照其他方式进行选取，如选取该匹配规则数组中的第三个元素作为目标规则，具体的选取方式可以根据实际需求设定，在此不作限定。

步骤s205，对上述目标规则进行解析，判断该目标规则的类型。

可以通过目标规则的类型生成对应的应答信息。

当上述目标规则中不包含真实接口地址，则确定该目标规则为模拟规则，执行步骤s206；如果上述目标规则中包含真实接口地址，则确定该目标规则为代理规则，执行步骤s207。

步骤s206，生成与模拟规则对应的模拟数据，将该模拟数据作为应答信息返回至前端。

在可能的实施例中，当检测到目标规则为模拟规则时，利用mock.js模拟数据生成器或者faker.js模拟数据生成器生成与上述模拟规则对应的模拟数据，并将该模拟数据作为应答信息，以报文的形式返回至前端。

步骤s207，从上述访问请求的输入参数中提取真实接口地址，将上述访问请求发送到该真实接口地址。

当目标规则为代理规则时，输入参数中必然包括后端接口的真实接口地址。在可能的实施例中，可以通过http代理服务器，将上述访问请求代理转发至后端。

具体地，代理规则中包括代理服务器地址，根据该代理服务器地址，将访问请求发送至该代理服务器，由该代理服务器对该访问请求进行封装，并将封装后的访问请求转发至上述真实接口地址对应的后端，以使用真实后端环境对该当前待检测接口进行检测。

步骤s208，接收从上述真实接口地址返回的应答信息，并将该应答信息返回至前端。

后端对接收到的访问请求进行分析处理，得到对应的应答信息。将该应答信息发送至代理服务器，以使该代理服务器将应答信息转发至前端。通过该方式，将前后端联调与mock模拟测试相结合，使得已完成的后端接口可以直接使用，无需进行数据模拟。

本申请提供的技术方案，将访问请求中根据实际接口需求定义的输入参数，与预设规则进行匹配，然后根据该输入参数匹配的预设规则返回对应的应答信息，从而实现了不同参数条件模拟不同的应答信息，以尽可能模拟真实环境，减少后续联调成本，并提高前端测试的真实性和灵活性。另外，针对已完成的后端接口，在输入参数中包含后端的真实接口地址并添加相应的代理规则，从而使用真实的后端环境进行测试，且在后续联调时无需进行更改直接测试即可，以进一步节省后续联调的改动成本和时间。

为了实现对实际应该中各种情况的模拟，在可能的实施例中，上述模拟规则包括运行异常规则、网络异常规则。在检测过程中，在访问请求中添加运行异常或者网络异常对应的输入参数，在后续测试过程中，匹配到运行异常规则或者是网络异常规则后，返回与该运行异常规则或者是网络异常规则对应的模拟数据即可。

考虑到在一些应用场景下，如登录场景、退出场景或者报错场景，一些接口属于关联操作，在可能的实施例中，可以对各个场景预先定义不同的标识，根据该场景的标识，建立该场景下的各个接口之间的关联。

如登录场景下a(标识)下对应4个接口，分别为接口1(标识)、接口2、接口3及接口4，该四个接口通过标识a进行关联，且该4个接口之间的测试顺序预先设定，如接口1的下一接口为接口2，接口2的下一接口为接口3，接口3的下一接口为接口4。在可能的实施例中，可以按序排列的方式定义接口之间的测试顺序。

在场景测试时，前端可以根据当前待检测接口所属的场景的标识确定待检测的下一接口。仍以上述登录场景a为例，如果当前待测试接口为接口1，则根据场景的标识a，确定待检测的下一接口为接口2。

基于场景测试的情境，上述步骤s201之前还包括：将关联在同一场景下的待检测接口对应的预设规则进行关联，形成规则组。且在场景测试情景下，请求接口的输入参数中包括场景的标识。

具体地，可以将同一场景下的各个接口通过场景的标识进行关联，在后续该场景下的接口进行检测的过程中，可以通过输入参数中的场景的标识，确定对应的规则组，基于确定的规则组，对输入参数进行校验，确定与输入参数对应的目标规则，并返回该目标规则对应的应答信息至前端。基于此，在步骤s202中，可以仅读取该规则组中的预设规则，后续在规则组中进行规则匹配。通过该方式，可以显著提高场景测试的效率。

前端在接收到应答信息后，根据该应答信息确定该场景下，下一接口对应的输入参数。其中应答信息与输入参数之间的对应关系是预先设定的，如当接口1对应的应答信息为a时，对应的下一接口2对应的输入参数为b，也就是上一接口对应的应答信息影响下一接口对应的输入参数。

前端根据下一接口的输入参数生成该下一接口对应的访问请求。mock服务器或者mock平台根据该下一接口对应的访问请求确定场景的标识，基于该场景的标识对应的规则组对下一接口进行测试。

需要说明的是，上述实施例的实现过程可以但不限于使用node.js实现。

针对于上述实施例中的前端测试方法，参见图3，本申请实施例提供了一种前端测试装置，该装置包括：

请求接收模块11，用于获取前端的待检测接口的访问请求，该访问请求包括输入参数，其中该输入参数的数据结构是根据前端与后端的接口需求定义的；

规则匹配模块12，用于从预设规则库中选择与所述输入参数匹配的预设规则作为目标规则；

信息生成模块13，用于基于目标规则生成与该目标规则对应的应答信息；

应答返回模块14，用于将上述应答信息反馈至上述前端。

进一步地，参见图4，上述规则匹配模块12包括：

规则读取单元121，用于从预设规则库中读取预设规则；

规则匹配单元122，用于将每一条预设规则分别与上述输入参数进行匹配；

规则选取单元123，用于从匹配成功的至少一条预设规则中选取一条作为目标规则。

进一步地，预设规则的类型为模拟规则或代理规则；

上述模拟规则包括输入参数的数据结构、应答信息数据结构、第一参数校验方法；

上述代理规则包括代理服务器地址及第二参数校验方法。

进一步地，上述信息生成模块还用于：对目标规则进行解析，得到该目标规则的类型；生成与该目标规则的类型对应的应答信息。

进一步地，如果上述目标规则的类型为模拟规则，则上述信息生成模块13包括：

数据模拟单元131，用于生成与模拟规则对应的模拟数据；

上述应答返回模块14包括：

第一返回单元141，用于将该模拟数据作为应答信息返回至上述前端。

进一步地，上述数据模拟单元131还用于：

利用mock.js模拟数据生成器或者faker.js模拟数据生成器生成与模拟规则对应的模拟数据。

进一步地，如果上述目标规则的类型为代理规则，则

上述信息生成模块13还包括：

地址提取单元132，用于从访问请求的输入参数中提取真实接口地址；

请求发送单元133，用于将该访问请求发送到所述真实接口地址；

应答接收单元134，用于接收从上述真实接口地址返回的应答信息；

上述应答返回模块14还包括：

第二返回单元142，用于将该应答信息返回至上述前端。

进一步地，参见图5，上述装置还包括规则关联模块15，该规则关联模块15用于：

将关联在同一场景下的待检测接口对应的预设规则进行关联，形成规则组。

进一步地，上述输入参数中包括当前待检测接口所属的场景的标识；上述规则匹配模块12还用于：

根据上述场景的标识，确定对应的规则组；

基于确定的规则组，对上述输入参数进行校验，确定与该输入参数对应的目标规则。

本申请提供的技术方案，将访问请求中根据实际接口需求定义的输入参数，与预设规则进行匹配，然后根据该输入参数匹配的预设规则返回对应的应答信息，从而实现了不同参数条件模拟不同的应答信息，以尽可能模拟真实环境，减少后续联调成本，并提高前端测试的真实性和灵活性。另外，针对已完成的后端接口，在输入参数中包含后端的真实接口地址并添加相应的代理规则，从而使用真实的后端环境进行测试，且在后续联调时无需进行更改直接测试即可，以进一步节省后续联调的改动成本和时间。

参见图6，本申请实施例还提供一种电子设备100，包括：处理器40，存储器41，总线42和通信接口43，所述处理器40、通信接口43和存储器41通过总线42连接；处理器40用于执行存储器41中存储的可执行模块，例如计算机程序。

其中，存储器41可能包含高速随机存取存储器(ram，randomaccessmemory)，也可能还包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口43(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

总线42可以是isa总线、pci总线或eisa总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器41用于存储程序，所述处理器40在接收到执行指令后，执行所述程序，前述本申请实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器40中，或者由处理器40实现。

处理器40可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器40中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器40可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现成可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器41，处理器40读取存储器41中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的前端测试装置及电子设备，与上述实施例提供的前端测试方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。

本申请实施例所提供的进行前端测试方法的计算机程序产品，包括存储了处理器可执行的非易失的程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置及电子设备的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

附图中的流程图和框图显示了根据本申请的多个实施例方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对步骤、数字表达式和数值并不限制本申请的范围。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。