MOCK测试方法、装置及设备与流程

本申请涉及测试技术领域，尤其是涉及到一种mock测试方法、装置及设备。

背景技术：

平台应用需要和外部应用合作，当用户在平台应用获取外部应用特定服务的电子凭证时，平台应用需要通过网关请求到外部应用进而请求发券，成功后用户的平台应用会接收到外部应用发放的券码。这样用户就可通过该券码兑换该外部应用相应的服务。

由于平台应用和外部应用的系统之间交互会存在许多不确定性，因此平台应用系统需要针对这些不确定性制定不同的策略，例如，外部应用发券延迟时平台应用需要提示用户券码发放中、网络交互发生超时需要通过调度再次请求外部应用的系统发券等。开发人员基于这些策略除了进行相关编码工作以外，还需要对这些策略进行测试。

然而，由于外部应用的系统对平台应用系统来说是一个相对黑盒的场景，并且外部应用系统的开发进度和平台应用系统并不一致，目前，只能通过口头沟通和单元测试的方式进行模拟测试，无法进行端到端的测试验收(就是在测试系统链路的过程中，完全模拟用户一个场景的真实使用过程通过完整的链路进行测试)，对上述这些策略的验证带来了极大的困难，成为了平台应用整个项目的主要风险和瓶颈，进而会影响平台应用项目的完成进度。

技术实现要素：

有鉴于此，本申请提供了一种mock测试方法、装置及设备，主要目的在于解决目前平台应用测试外部应用的应用场景时，通过现有测试方式只能通过口头沟通和单元测试的方式进行模拟测试，无法进行端到端的测试验收，进而会影响平台应用项目的完成进度的问题。

根据本申请的一个方面，提供了一种mock测试方法，该方法包括：

发送对被测应用的测试请求，所述测试请求中携带有目标登录用户的请求属性信息，其中，不同登录用户各自对应测试所述被测应用的其中之一应用场景；

接收根据所述请求属性信息匹配到的mock对象；

根据所述mock对象，实现与所述目标登录用户对应测试的目标应用场景的链路mock测试。

可选的，所述根据所述mock对象，实现与所述目标登录用户对应测试的目标应用场景的链路mock测试，具体包括：

将所述mock对象确定为所述目标应用场景中对应的模拟请求结果，并执行所述链路mock测试，以便验证针对所述模拟请求结果制定的应对策略信息是否存在异常。

可选的，若根据所述请求属性信息未匹配到相应的mock对象，则所述方法还包括：

接收所述测试请求的请求响应信息，所述请求响应信息是与所述被测应用对应的服务端经过线上真实链路返回的；

根据所述请求响应信息确定所述被测应用对应的业务测试结果。

可选的，在所述发送对被测应用的测试请求之前，所述方法还包括：

对所述被测应用预先挂载插件；

获取mock规则与mock对象之间的映射关系并推送给所述插件，其中不同的mock规则都有各自对应的mock对象。

可选的，所述发送对被测应用的测试请求，具体包括：

向所述插件发送所述测试请求，以使得所述插件对所述请求属性信息进行解析得到符合目标mock规则的属性特征，以便通过查询所述映射关系将所述目标mock规则对应的mock对象，作为根据所述请求属性信息匹配到的mock对象。

可选的，所述属性特征包括与所述目标登录用户相关的特定字段、和/或与所述目标登录用户对应的ip地址。

可选的，接收到的所述mock对象是所述插件执行根据所述映射关系配置项转换的groovy脚本，利用java探针的技术动态更改所述被测应用代码查询得到的。

可选的，所述获取mock规则与mock对象之间的映射关系，具体包括：

向测试平台获取所述映射关系，所述测试平台用于编辑与更新所述映射关系。

可选的，若需要对其他被测应用进行测试，则所述方法还包括：

将所述插件进行镜像处理，得到镜像插件；

对所述其他被测应用预先挂载所述镜像插件；

获取测试所述其他被测应用所配置的mock规则与mock对象之间的映射关系并推送给所述镜像插件。

可选的，所述方法还包括：

输出所述链路mock测试的测试结果。

根据本申请的另一方面，提供了一种mock测试装置，该装置包括：

发送模块，用于发送对被测应用的测试请求，所述测试请求中携带有目标登录用户的请求属性信息，其中，不同登录用户各自对应测试所述被测应用的其中之一应用场景；

接收模块，用于接收根据所述请求属性信息匹配到的mock对象；

处理模块，用于根据所述mock对象，实现与所述目标登录用户对应测试的目标应用场景的链路mock测试。

可选的，所述处理模块，具体用于将所述mock对象确定为所述目标应用场景中对应的模拟请求结果，并执行所述链路mock测试，以便验证针对所述模拟请求结果制定的应对策略信息是否存在异常。

可选的，所述装置还包括：确定模块；

所述接收模块，还用于若根据所述请求属性信息未匹配到相应的mock对象，则接收所述测试请求的请求响应信息，所述请求响应信息是与所述被测应用对应的服务端经过线上真实链路返回的；

所述确定模块，用于根据所述请求响应信息确定所述被测应用对应的业务测试结果。

可选的，所述装置还包括：挂载模块；

所述挂载模块，用于对所述被测应用预先挂载插件；

所述接收模块，还用于获取mock规则与mock对象之间的映射关系；

所述发送模块，还用于将所述映射关系推送给所述插件，其中不同的mock规则都有各自对应的mock对象。

可选的，所述发送模块，具体用于向所述插件发送所述测试请求，以使得所述插件对所述请求属性信息进行解析得到符合目标mock规则的属性特征，以便通过查询所述映射关系将所述目标mock规则对应的mock对象，作为根据所述请求属性信息匹配到的mock对象。

可选的，所述属性特征包括与所述目标登录用户相关的特定字段、和/或与所述目标登录用户对应的ip地址。

可选的，接收到的所述mock对象是所述插件执行根据所述映射关系配置项转换的groovy脚本，利用java探针的技术动态更改所述被测应用代码查询得到的。

可选的，所述接收模块，具体用于向测试平台获取所述映射关系，所述测试平台用于编辑与更新所述映射关系。

可选的，所述装置还包括：镜像模块和挂载模块；

所述镜像模块，用于若需要对其他被测应用进行测试，则将所述插件进行镜像处理，得到镜像插件；

所述挂载模块，用于对所述其他被测应用预先挂载所述镜像插件；

所述接收模块，还用于获取测试所述其他被测应用所配置的mock规则与mock对象之间的映射关系；

所述发送模块，还用于将所述映射关系推送给所述镜像插件。

可选的，处理模块，还用于输出所述链路mock测试的测试结果。

依据本申请又一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述mock测试方法。

依据本申请再一个方面，提供了一种mock测试的实体设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述mock测试方法。

借由上述技术方案，本申请提供的一种mock测试方法、装置及设备，与目前现有方式相比，本申请在需要对被测应用进行测试时，可发送携带有目标登录用户的请求属性信息的测试请求，以便根据请求属性信息匹配到对应的mock对象，其中，不同登录用户各自对应测试被测应用的其中之一应用场景，通过这种方式可匹配到该目标登录用户对应场景测试需要的模拟请求结果，这样虽然被测应用系统是个相对黑盒的场景，但也能够根据该mock对象，实现与目标登录用户对应测试的目标应用场景的链路mock测试，进而使得在平台应用测试外部应用的应用场景时，也能进行端到端的测试验收，保证平台应用项目的测试效率，从而保证平台应用项目的完成进度。除此之外，还可实现不同测试人员在相同的端到端链路上相互不干扰，进一步提高测试效率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

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

图1示出了本申请实施例提供的一种mock测试方法的流程示意图；

图2示出了本申请实施例提供的另一种mock测试方法的流程示意图；

图3示出了本申请实施例提供的扳机应用方案的实例示意图；

图4示出了本申请实施例提供的挡板应用方案的实例示意图；

图5示出了本申请实施例提供的mock测试架构方案示意图；

图6示出了本申请实施例提供的mock测试架构集中化管理示意图；

图7示出了本申请实施例提供的mock测试实例场景示意图；

图8示出了本申请实施例提供的一种mock测试装置的结构示意图；

图9示出了本申请实施例提供的另一种mock测试装置的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

目前通过现有测试手段，如果被测应用相对来说是一个黑盒场景，会难以获得被测应用对应端的场景请求结果，进而无法进行端到端的测试验收的问题。为了解决该问题，本实施例提供了一种mock测试方法，如图1所示，该方法包括：

101、发送对被测应用的测试请求。

其中，测试请求中携带有目标登录用户的请求属性信息。不同登录用户各自对应测试被测应用的其中之一应用场景。即每个登录用户都有各自对应的测试任务，每个测试任务对应测试被测应用的其中之一应用场景。不同的测试任务所分别对应的应用场景可不同或者有个别相同等，具体可根据实际需求进行预先配置。

在本实施例中，请求属性信息用于确定登录用户，不同登录用户的请求属性信息是不同的。例如，请求属性信息可包括登录用户的ip地址、设备mac地址等。另外，应用场景可为针对与被测应用交互存在的不确定性所制定策略的场景测试，即验证执行该策略所关联的各功能模块是否存在异常，应用场景的具体内容可根据实际测试需求确定，例如，应对支付成功的策略场景、应对支付失败的策略场景、应对某请求失败的策略场景和应对某请求超时的策略场景等。

例如，在具体的应用场景中，不同的测试人员有相应的分工，进而验证不同场景下的应对策略是否存在异常，这些分工可不同或者相同。不同的场景对于不同的测试人员来说是固定的。测试请求中携带用户的请求属性信息可以便于根据请求属性信息锁定相应的测试人员，进而锁定相应的测试场景。

对于本实施例的执行主体可为用于辅助mock测试的客户端装置或设备，具体可配置在平台应用侧，进而验证其与外部应用之间的交互应对策略等。需要说明的是，除此之外，本实施例方法还可应用到其他应用之间的交互应对策略测试当中(如其中存在黑盒环境的应用等)。

102、接收根据请求属性信息匹配到的mock对象。

其中，mock对象，即虚拟的对象，是真实对象在调试期间的替代品，在本实施例中相当于是对被测应用进行测试过程中不容易构造或者不容易获取的对象。

在具体的应用场景中，端与端之间，不同的研发团队之间难以实例化的对象，测试需要生成mock对象来代替真实对象。不同的测试用户有不同的测试场景，根据测试用户的请求属性信息匹配相应的mock方法，实例化mock方法生成mock对象。通过上述方法匹配的mock对象，用于替换代码中真实对象进行测试，在端对端测试中方便快捷，降低了团队之间的沟通成本和研发耦合性，不需要其他团队的技术支持就可以完成独立研发，提升测试效率，节约时间成本。

103、根据接收到的mock对象，实现与目标登录用户对应测试的应用场景的链路mock测试。

其中，mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。链路mock测试包括根据获得的mock对象进行端对端测试，进而验证该应用场景下的应对策略是否存在异常。

例如，被测应用属于平台应用中的应用，可通过平台应用支付被测应用中对应的服务，在平台应用与被测应用之间交互测试过程中，用户b为了验证支付失败时的应对策略，用户b登录平台应用后可通过平台应用对被测应用发送测试请求，由于被测应用属于黑盒环境，所以不容易获取到支付失败的结果，所以可返回该用户b请求属性对应的支付失败结果，进而基于该支付失败结果验证相应的应对策略是否存在异常。

本实施例提供的方法可以在端对端测试中为测试用户提供相应的mock对象进行mock测试，相比于传统测试方法，通过提供与用户请求属性信息匹配的mock对象进行应用场景的链路mock测试。这样虽然被测应用系统是个相对黑盒的场景，但也能够根据该mock对象，实现与目标登录用户对应测试的目标应用场景的链路mock测试，进而使得在平台应用测试外部应用的应用场景时，也能进行端到端的测试验收，保证平台应用项目的测试效率，从而保证平台应用项目的完成进度。除此之外，还可实现不同测试人员在相同的端到端链路上相互不干扰，进一步提高测试效率。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，本实施例提供了另一种mock测试方法，如图2所示，该方法包括：

201、对被测应用预先挂载插件。

对于本实施例，预先挂载插件，以便于后续步骤通过插件来实现对代码的修改完成mock测试，插件可以根据配置进行调整。

202、获取mock规则与mock对象之间的映射关系并推送给插件。

其中，不同的mock规则都有各自对应的mock对象。mock规则包括依据测试用户的参数匹配条件决定是否返回mock对象。

通过mock规则与mock对象之间的映射关系完成对测试用户的指向服务，根据不同的测试用户的需求，配置不同的mock规则和mock对象，一方面可以通过配置完成功能复用和修改，另一方面降低了维护成本。可选的，可通过测试平台集中化管理mock规则与mock对象之间的映射关系，mock规则和mock对象之间的映射关系通过测试平台进行修改、增加和删除等维护。相应的，步骤202中获取mock规则与mock对象之间的映射关系，具体可包括：向测试平台获取该映射关系，其中，测试平台用于编辑与更新该映射关系。测试平台的目的是为了通过一个平台对所有测试应用的规则和mock对象进行高内聚低耦合的集中化管理，这个平台主要负责维护mock规则和mock对象的映射关系。mock规则意义是之后告知插件当请求的参数匹配什么条件时要返回哪个mock对象，从而实现不同测试人员在同样的端到端链路上相互不干扰，针对自己测试场景返回定制的mock对象。在本可选方式中，通过测试平台可实现针对配置项进行集中化、持久化的管理。

当用户在测试平台编写完mock规则、mock对象后，将这些配置项选出来，按照指定类名+指定方法名+指定配置项的方式推送到被测应用挂载的插件上，以便激活插件。

203、向插件发送携带有目标登录用户请求属性信息的测试请求。

进一步的，以使得插件对请求属性信息进行解析得到符合目标mock规则的属性特征，以便通过查询映射关系将目标mock规则对应的mock对象，作为根据请求属性信息匹配到的mock对象。

可选的，属性特征可包括与目标登录用户相关的特定字段、和/或与目标登录用户对应的ip地址。例如，请求中某个字段为x时，其对应测试用户c，返回相应的mock对象。通过这种属性特征匹配方式可准确识别出测试用户身份，以便准确返回相应的mock对象。一方面相同的ip地址可能供不同的测试用户使用，另一方面同一测试用户可能使用不同的ip地址，可以根据测试用户的需要选择性地适用。在人员流动和设备更替的情况下，不影响测试效率，保障测试正常运行。

例如，预先配置mock规则与mock对象之间映射关系的样式如下：

配置1，mock规则：来自用户alice的ip地址的请求，mock对象：返回请求成功；

配置2，mock规则：在请求的属性中添加用户bob字段时，mock对象：返回请求失败；

配置3，mock规则：在请求的属性中添加用户cate字段时，mock对象：返回请求超时；

…

配置x，mock规则：符合用户jimmy规则的请求，mock对象：返回指定mock对象；

通过上述映射关系，如果测试请求中携带的目标登录用户的ip地址对应用户alice，则将“返回请求成功”的mock对象作为匹配到的mock对象。

204、接收根据请求属性信息匹配到的mock对象。

可选的，接收到的mock对象是插件执行根据映射关系配置项转换的groovy脚本，利用java探针的技术动态更改被测应用代码查询得到的。其中，java探针：基于java代理和java字节码注入的技术原理，本方案主要利用到的技术是将在类被加载到java虚拟机(javavirtualmachine，jvm)之前，将字节码转换掉，从而达到动态注入代码的目的。使用groovy脚本易于使用维护，稳定，能承受大负荷，可以更快地获得mock对象。在测试工程冗长，需要进行大规模测试的情况下，使用groovy脚本可以承受压力，突发情况下方便工程师对脚本进行修改。

使用java探针技术对被测应用的代码进行更改，即通过java反射的方式获取到请求对象的全部属性，然后根据属性中的特征是否匹配来决定要返回哪个mock对象，将需要进行实例化的mock对象所对应的类转化成groovy脚本形式利用java探针的技术动态修改被测应用的代码。通过java探针，让被测应用更加安全，测试用户在没有接触外界的情况下进行测试，提高被测应用在测试过程中的安全性。

需要说明的是，对于本实施例，除了使用java探针技术以外，也可以用侵入业务代码配置spring拦截器，利用动态代理的技术进行代码篡改，但是对业务代码入侵强，spring拦截器只能拦截有bean声明的实例，且需要重启应用才能生效。

可选的，集中管理的mock规则中还可包括针对某一次测试是否需要返回mock对象还是走真实链路。进一步的，若根据请求属性信息未匹配到相应的mock对象，则接收测试请求的请求响应信息，该请求响应信息是与被测应用对应的服务端经过线上真实链路返回的；最后根据请求响应信息确定被测应用对应的业务测试结果。

在本可选方式中，根据不同规则返回不同期望的mock对象，而不匹配mock规则的登录用户直接走真实链路，不返回任何mock对象结果。即假如没有规则被满足，执行原来真实代码即可。进而本方案在满足不同用户的mock测试需求的同时，还能满足非mock测试走线上真实链路的需求。

另外，在某些请求无法匹配到对应的mock规则或对象的情况下，但是该请求容易通过真实链路获取到对应的请求结果，进而不需要对应的mock对象，例如创建其相应mock对象的时间复杂度没有明显低于从真实链路中直接获取真实对象的时间复杂度。对于时间复杂度没有显著降低而言，执行真实链路更能有效地对系统进行全方位的测试。

205、根据mock对象，实现与目标登录用户对应测试的应用场景的链路mock测试。

例如，基于步骤203中的实例配置，假设插件执行了配置1，配置2，配置3转义后的groovy脚本，篡改了被测应用的代码，当用户alice发起请求时，代码匹配规则后发现ip请求来自用户alice，通过java反射的方式将mock对象实例化后返回给用户alice发起请求的端；用户bob和cate也是同理。而当用户dirk发送请求时，因为不匹配任何规则，所以执行被测应用原来的代码，真实发送请求到外部网关，返回相应的真实结果到用户dirk这里。

作为一种可选方式，步骤205具体可包括：将mock对象确定为目标应用场景中对应的模拟请求结果，并执行该链路mock测试，以便验证针对模拟请求结果制定的应对策略信息是否存在异常。进而在被测应用为相对黑盒的场景下，也能实现准确的端到端的链路mock测试。

进一步的，为了使得测试用户及时了解到测试结果，可选的，在测试结果出来后，还可包括：输出链路mock测试的测试结果。

进一步的，若需要对其他被测应用进行测试，则将插件进行镜像处理，得到镜像插件；对其他被测应用预先挂载所述镜像插件；获取测试其他被测应用所配置的mock规则与mock对象之间的映射关系并推送给镜像插件。

假设应用x还是用户alice/bob/cate/dirk需要测试的应用，他们还是通过测试平台按照之前的步骤推送规则针对应用x进行mock测试。此时jimmy需要针对另一个不同的应用y进行mock测试，他只需要和之前应用x的技术人员一样推送配置到应用y即可。而应用y只需要像应用x一样挂载一个镜像的插件即可。本方案针对所有基于java技术部署的应用都可以用一个统一的“插件”进行管理，而所有的用户只需要通过一个“测试平台”专门地维护自己的mock规则/对象的配置即可，符合高可用高聚合低耦合的特征。

下面结合目前现有技术手段的缺点分析，说明上述实施例所示方法的有益效果：

针对端到端的mock方案，不管底层技术如何，实现方式上都是以下两种技术方案为核心思路：一种是在端到端链路上添加一个扳机应用，如图3所示；另一种是直接修改被测应用的代码，实现一个类似“挡板”的功能，如图4所示。

其中，板机应用方案缺点：1)每次需求发生变化，想要返回新的mock对象时，需要重新对板机进行编码部署工作，部署期间整个端到端链路不可用。2)被测应用存在切换路由的成本，需要验证返回mock对象的场景时，需要将被测应用原本下游的路由切断，连接到板机应用上。测试完需要将路由切回，大部分的应用切换路由都需要重新部署应用，部署期间整个端到端链路不可用。3)采用板机的方案时，总有一方的需求不能满足。例如，当切换路由到板机上的时候，用户alice/bob/cate想要返回mock对象的需求可以被满足，但是用户dirk想要测试真实链路的需求无法被满足，反之亦然。

“挡板”应用方案的缺点：1)被测应用直接侵入了业务代码，真实代码发布上线时需要移除所有“挡板”相关的代码、或者针对“挡板”部分的代码进行很精确的控制，不能真实在线上环境测试造成一定影响。2)每次需求发生变化，想要返回新的mock对象时，需要重新对被测应用“挡板”相关的代码进行编码部署工作，部署期间整个端到端链路不可用。3)当多个不同的被测应用(被测应用x、y等等)都要进行mock测试时，需要分别针对不同的被测应用开发不同的“挡板”代码，不能集中化管理。

针对这两种方案思想，为了解决这两种方案存在的缺点，本方案是可事先通过测试平台集中化管理所有的mock规则和mock对象，并将mock规则和mock对象的配置脚本推送到被测应用挂载的插件上，在插件上采用java探针的技术动态篡改java代码，实现无需重新部署、对被测应用几乎无侵入、又能同时满足所有人需求来进行端到端的mock测试，如图5所示。需要说明的是，本方案适用面较广，对于java部署的应用进行端到端测试都可以采用本方案进行实践。测试平台、插件和被测应用之间的关系如图5所示。测试平台将规则推送给插件，插件通过java探针字节码注入被测应用，插件修改代码获得mock对象，插件根据测试平台推送的规则进行操作。一方面降低测试人员接触代码的程度，提高测试方法的安全性，另一方面，java探针字节对基于java的被测应用具有良好的适应性和可拓展性。

在具体的应用场景中，测试平台可以通过可视化的可扩展标记语言(extensiblemarkuplanguage，xml)进行管理，在更换测试用户或者调整测试用户的测试场景时，直接修改xml的bean，方便快捷，降低各个组成部分的耦合性。

通过测试平台统一管理mock规则与mock对象之间的映射关系的配置如图6所示。多个测试用户关联同一个测试平台，测试平台预置多种mock规则与mock对象之间的映射关系。进一步的，测试平台可以维护多个被测应用与测试用户的映射关系。例如，测试用户a对应用x进行测试，测试用户b对应用y进行测试，测试平台中预置着用户a对应用x的mock规则和mock对象映射关系以及用户b对应用y的mock规则和mock对象映射关系。然后分别对应推送给被测应用x的插件和被测应用y的插件，上述方法提高了系统的复用率，对于所有基于java的应用而言都可以通过测试平台确定映射关系，提高了代码利用率，降低了系统能耗。

基于上述方案内容，给出如下应用场景，但不限于此：

由于平台应用和外部码商的系统交互存在许多不确定性，而平台应用作为用户心智的主要入口需要基于这些不确定性制定不同的策略。例如外部码商发券延迟需要告知用户券码发放中、外部码商无法发码时需要文案提示并自动帮用户取消该次购买交易、网络交互发生超时需要通过调度再次请求外部码商的系统发券等等。开发测试员基于这些策略除了进行相关的编码工作，更需要在系统正式发布上线前验证这些策略的执行是否正确满足预期，同时还需要保证之前已经接入的外部码商的相关业务不能出问题。

由于外部码商的系统对于平台应用来说是一个相对黑盒的场景，且外部码商的开发进度和平台应用并不一致，因此需要有专门针对端到端场景的mock测试方法解决该问题以及今后所有的类似问题，并且需要保证同一时间验证不同策略和场景的测试人员在同样的链路中相互不受干扰。

例如，用户通过手机端平台应用购买了一张外部码商的电子凭证，平台应用券码系统请求外部码商进行发码，之后将该凭证码返回到用户的手机端，用户手机端展示该券码，对此场景，假设以下每个个体都从端到端链路进行验证不同的场景。

用户alice想要验证外部码商发码成功的策略应对场景，对其请求都模拟返回发码成功；

用户bob想要验证外部码商发码失败的策略应对场景，对其请求都模拟返回发码失败；

用户cate想要验证外部码商网络超时的策略应对场景，对其请求都模拟返回网络超时；

用户dirk想要回归测试原有的外部码商业务，因此不需要做任何模拟，真实调用到网关。

为此，本方案利用测试平台进行mock规则和mock对象的集中化管理、通过推送配置到被测应用的插件上利用java探针技术实现无需部署即可进行mock测试，同时通过规则匹配实现智能路由。具体的，如图7所示，对于用户alice的测试请求，请求中携带有用户alice的ip地址，在插件中匹配该ip地址匹配的mock对象，即发码成功，进而返回外部码商发码成功的请求结果，从而验证外部码商发码成功的策略应对场景。同理，对于用户bob的测试请求，返回外部码商发码失败的请求结果，从而验证外部商户发码失败的策略应对场景；对于用户cate的测试请求，返回外部码商网络超时的请求结果，从而验证外部商户网络超时的策略应对场景。而对于用户dirk的测试请求，由于规则不符合任何配置，可真实请求到外部网关，然后将真实返回的请求进行返回，进而实现回归测试原有的外部码商业务。

在上述方案中，对被测应用的代几乎没有入侵，发布上线时隔离插件或者不隔离插件都可以。如果不隔离，线上只要没有入口激活插件即可。是否要路由到真实网关由推送到插件的规则控制，各个测试用户需求能够同时被满足，相互不影响。并且不再需要重新部署任何一台端到端上的应用，部署成本几乎为0。一个测试平台管理多个被测应用的镜像插件，高可用高聚合低耦合。可扩展性极强，因为插件利用的是java探针技术，所以只要是基于java技术开发的应用，底层无论是开发的通讯协议、ws服务、http服务、甚至是类的方法，都可以通用地采用本方案进行端到端的mock测试。

进一步的，作为图1和图2方法的具体实现，本申请实施例提供了一种mock测试装置，如图8所示，该装置包括：发送模块31、接收模块32、处理模块33。

发送模块31，用于发送对被测应用的测试请求，测试请求中携带有目标登录用户的请求属性信息，其中，不同登录用户各自对应测试被测应用的其中之一应用场景；

接收模块32，用于接收根据请求属性信息匹配到的mock对象；

处理模块33，用于根据mock对象，实现与目标登录用户对应测试的目标应用场景的链路mock测试。

在具体的应用场景中，处理模块33，具体用于将mock对象确定为目标应用场景中对应的模拟请求结果，并执行链路mock测试，以便验证针对模拟请求结果制定的应对策略信息是否存在异常。

在具体的应用场景中，如图9所示，本装置还包括：确定模块34。

接收模块32，还用于若根据请求属性信息未匹配到相应的mock对象，则接收测试请求的请求响应信息，请求响应信息是与被测应用对应的服务端经过线上真实链路返回的；

确定模块34，用于根据请求响应信息确定被测应用对应的业务测试结果。

在具体的应用场景中，如图9所示，本装置还包括：挂载模块35；

挂载模块35，用于对被测应用预先挂载插件；

接收模块32，还用于获取mock规则与mock对象之间的映射关系；

发送模块31，还用于将映射关系推送给插件，其中不同的mock规则都有各自对应的mock对象。

在具体的应用场景中，发送模块31，具体用于向插件发送测试请求。

进一步的，以使得插件对请求属性信息进行解析得到符合目标mock规则的属性特征，以便通过查询映射关系将目标mock规则对应的mock对象，作为根据请求属性信息匹配到的mock对象。

在具体的应用场景中，可选的，属性特征包括与目标登录用户相关的特定字段、和/或与目标登录用户对应的ip地址。

在具体的应用场景中，可选的，接收到的mock对象是插件执行根据映射关系配置项转换的groovy脚本，利用java探针的技术动态更改被测应用代码查询得到的。

在具体的应用场景中，接收模块32，具体用于向测试平台获取映射关系，测试平台用于编辑与更新映射关系。

在具体的应用场景中，如图9所示，本装置还包括：镜像模块36；

镜像模块36，用于若需要对其他被测应用进行测试，则将插件进行镜像处理，得到镜像插件；

挂载模块35，用于对其他被测应用预先挂载镜像插件；

接收模块32，还用于获取测试其他被测应用所配置的mock规则与mock对象之间的映射关系；

发送模块31，还用于将映射关系推送给镜像插件。

在具体的应用场景中，处理模块33，还用于输出链路mock测试的测试结果。

需要说明的是，本实施例提供的一种mock测试装置所涉及各功能单元的其它相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

基于上述如图1和图2所示方法，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的mock测试方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述如图1和图2所示的方法，以及图8、图9所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种mock测试的实体设备，具体可以为计算机，智能手机，平板电脑，智能手表，服务器，或者网络设备等，该实体设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图2所示的mock测试方法。

可选的，该实体设备还可以包括用户接口、网络接口、摄像头、射频(radiofrequency，rf)电路，传感器、音频电路、wi-fi模块等等。用户接口可以包括显示屏(display)、输入单元比如键盘(keyboard)等，可选用户接口还可以包括usb接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如wi-fi接口)等。

本领域技术人员可以理解，本实施例提供的一种mock测试的实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述mock测试的实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本申请的技术方案，与目前现有方式相比，对被测应用的代几乎没有入侵，发布上线时隔离插件或者不隔离插件都可以。如果不隔离，线上只要没有入口激活插件即可。是否要路由到真实网关由推送到插件的规则控制，各个测试用户需求能够同时被满足，相互不影响。并且不再需要重新部署任何一台端到端上的应用，部署成本几乎为0。一个测试平台管理多个被测应用的镜像插件，高可用高聚合低耦合。可扩展性极强，因为插件利用的是java探针技术，所以只要是基于java技术开发的应用，底层无论是开发的通讯协议、ws服务、http服务、甚至是类的方法，都可以通用地采用本方案进行端到端的mock测试。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。