响应噪音的识别方法、模型、电子设备及计算机存储介质

技术领域

本发明涉及信息处理技术领域，尤其涉及一种响应噪音的识别方法、电子设备以及计算机可读存储介质。

背景技术

在成熟的互联网应用中，保证系统的稳定运行的优先级往往比新功能的开发更高，为避免新功能开发对旧功能逻辑造成影响，软件测试人员需要频繁的对系统进行旧功能的回归测试，传统的手工测试会浪费大量的人力成本，所以各种自动化测试的方案应运而生。

在实际应用中，即使是相同版本的软件，多次相同的输入也可能会产生不同的输出，这主要是软件运行环境、软件内部随机算法的影响导致的，这种不可控的差异(噪音)会和因bug产生的差异混在一起，导致测试人员难以区分软件本身是否真的存在问题，从而对自动化测试的效率和精度产生影响。

对于响应噪音的识别，目前采用的方案如下：方案一：平台提供多次回放的响应对比结果展示，由测试人员人工标注噪音；方案二：运行三个软件的软件实例，分别为稳定版本、稳定版本的副本以及测试版本，同时运行一个代理程序将测试数据同时发送上述三个软件实例。通过分析稳定版本和稳定版本的副本的响应差别甄别出噪音，再将噪音识别结果运用与稳定版本和测试版本的差异上，最终找出去除噪音后的对比差异。

其中，方案一中当测试的软件存在大量接口都含有噪音时，例如：响应结果中带上随机字符串的调用链id、依赖时间加密的签名等，需要消耗大量人力去标注噪音，无论在人力成本还是准确度上都不理想。方案二难以应用于主流的大型互联网应用架构中，即方案二的应用场景通常局限在一些规模小、离线运行、无状态、无存储的工具类应用中。

发明内容

本申请主要解决的技术问题是提供一种响应噪音的识别方法、电子设备以及计算机存储介质，解决了现有方案无法应用在有状态、有存储的被测软件，同时无法部署在大型多服务网络架构、需要在线运行的被测软件上的问题。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种响应噪音的识别方法，该识别方法包括：获取到测试数据，并将所述测试数据输入到稳定版本应用中；抓取所述稳定版本应用处理所述测试数据产生的第一输入请求包、与所述第一输入请求包对应的第一输入响应包、第一发送请求包以及与所述第一发送请求包对应的第一发送响应包；将所述第一输入请求包和第一输入响应包存储至回放后台，将所述第一发送请求包和第一发送响应包存储至虚拟后台；将所述第一输入请求包输入给测试版本应用；采集所述测试版本应用处理所述第一输入请求包产生的第二发送请求包；从所述虚拟后台选择与所述第二发送请求包最接近的第一发送请求包，并获取到所述最接近的第一发送请求包对应的第一发送响应包；将所述最接近的第一发送请求包对应的第一发送响应包输入到所述测试版本应用；抓取所述测试版本应用对应所述第一输入请求包，以及所述最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包；基于所述第一输入响应包以及所述第二输入响应包确定所述测试版本应用的响应噪音。

为了解决上述问题，本申请第二方面提供了一种响应噪音识别模型，包括：稳定版本抓包模块，所述稳定版本抓包模块用于在获取到测试数据，并将所述测试数据输入到稳定版本应用中；所述稳定版本抓包模块还用于抓取所述稳定版本应用处理所述测试数据产生的第一输入请求包、与所述第一输入请求包对应的第一输入响应包、第一发送请求包以及与所述第一发送请求包对应的第一发送响应包；所述稳定版本抓包模块还用于将所述第一输入请求包和第一输入响应包存储至回放后台，将所述第一发送请求包和第一发送响应包存储至虚拟后台；模拟回放模块，所述模拟回放模块用于将所述第一输入请求包输入给测试版本应用；所述模拟回放模块还用于采集所述测试版本应用处理所述第一输入请求包产生的第二发送请求包；所述模拟回放模块还用于从所述虚拟后台选择与所述第二发送请求包最接近的第一发送请求包，并获取到所述最接近的第一发送请求包对应的第一发送响应包；所述模拟回放模块还用于将所述对应的第一发送响应包输入到所述测试版本应用；所述模拟回放模块还用于抓取所述测试版本应用对应所述第一输入请求包，以及所述对应的第一发送响应包产生的第二输入响应包；响应噪音识别模块，所述响应噪音识别模块用于基于所述第一输入响应包以及所述第二输入响应包确定所述测试版本应用的响应噪音。

为了解决上述问题，本申请第三方面提供了一种电子设备，包括相互耦接的存储器和处理器，所述处理器用于执行所述存储器中存储的程序指令，以实现上述第一方面的识别方法。

为了解决上述问题，本申请第四方面提供了一种计算机可读存储介质，其上存储有程序指令，所述程序指令被处理器执行时实现上述第一方面的识别方法。

本申请的有益效果是：区别于现有技术的情况，本申请在获取到测试数据，并将测试数据输入到稳定版本应用中；抓取稳定版本应用处理测试数据产生的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包；将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台；将第一输入请求包输入给测试版本应用；采集测试版本应用处理第一输入请求包产生的第二发送请求包；从虚拟后台选择与第二发送请求包最接近的第一发送请求包，并获取到最接近的第一发送请求包对应的第一发送响应包；将最接近的第一发送请求包对应的第一发送响应包包输入到测试版本应用；抓取测试版本应用对应第一输入请求包，以及最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包；基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音。本申请的识别方法可以应用在有状态、有存储的测试版本应用上，还可以应用于主流的互联网公司的大型多服务网络架构以及离线场景中，大大减少自动化测试中噪音带来的干扰，提高自动化测试的效率和准确率，同时还可以为无脚本回归测试、全链路压测等高级研测方案提供数据支持。

附图说明

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

图1本申请响应噪音的识别方法的第一实施例的流程示意图；

图2是步骤S102的具体步骤的流程示意图；

图3是图1的响应噪音的识别方法中的数据流向示意图；

图4是本申请响应噪音的识别方法的第二实施例的流程示意图；

图5是本申请响应噪音识别模型的一实施例的框架示意图；

图6是本申请电子装置的一实施例的结构示意图；

图7是本申请计算机可读存储介质的一实施例的结构示意图。

具体实施方式

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

参阅图1，图1是本申请提供的响应噪音的识别方法的第一实施例的流程示意图。具体而言，可以包括如下步骤：

步骤S101:获取到测试数据，并将测试数据输入到稳定版本应用中。

在软件的自动化测过程中，需要测试人员给特定的测试数据作为软件的输入，将测试数据的执行结果作为输出，比较被测软件不同版本下的输出结果的差异，从而分析是否存在BUG。对于一个封闭的软件工程系统，理论上同样的输入就会对应同样的输出，即同样的请求包会对应同样的响应包，但实际情况中，由于受到软件运行环境以及软件内部随机算法的影响，即使是相同的内容，多次相同请求的响应中也会带有不可复现的内容，例如：时间相关字段、随机验证码等，这些不可复现的响应内容称为响应噪音。这些不可控的响应噪音会和因BUG产生的差异混合在一起，导致测试人员难以区分软件本身是否真的存在问题，从而对自动化测试的效率和精度产生影响。

在本实施例中，启动稳定版本的软件后，稳定版本获取到测试数据后，稳定版本应用处理测试数据时，会产生第一输入请求包与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包。其中，测试数据包括输入数据或/和线上流量数据，输入数据为测试人员将特定的测试数据作为输入形成的，线上流量数据为测试人员通过抓包程序获取的真实的线上流量数据，线上流量数据相比输入数据更加真实且准确。

步骤S102：抓取稳定版本应用处理测试数据产生的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包。

在本实施例中，在启动稳定版本应用前，先启动抓包程序，然后输入测试数据。稳定版本应用获取到测试数据后，处理该测试数据会产生第一输入请求包与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包。抓包程序会抓取稳定版本应用处理测试数据产生所有的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包。

请进一步参阅图2，图2是步骤S102的具体步骤的流程示意图。

步骤S201：获取到第一发送请求包，将第一发送请求包发送到客户端。

在本实施例中，稳定版本应用处理测试数据产生的第一输入请求包时，同时对第一输入请求包进行处理获取到第一发送请求包，并将该第一发送请求包发送到客户端。客户端在接收到第一发送请求包后，进行对应处理会产生第一发送响应包。

步骤S202：接收客户端对应第一发送请求包产生的第一发送响应包。

在本实施例中，客户端产生第一发送请求包后，会将该第一发送请求包返回给稳定版本应用，稳定版本应用会接收该第一发送响应。

步骤S203：将第一发送响应包输入到稳定版本应用中。

在本实施例中，稳定版本应用接收到第一发送响应包后，将该第一发送响应包输入到稳定版本应用中，即此时，稳定版本应用的输入有第一输入请求包和第一发送响应包。

步骤S204：抓取稳定版本应用对应第一输入请求包以及第一发送响应包产生的第一输入响应包。

在本实施例中，将第一发送响应包输入到稳定版本应用中后，稳定版本应该对应第一输入请求包和第一发送请求包会产生第一输入响应包，抓包程序抓取该第一输入响应包。

步骤S103：将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台。

在本实施例中，抓包程序在将所有的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包都抓取完毕后，进一步将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台。通过抓包程序抓取的第一输入请求包和第一发送响应包可以在测试版本应用运行过程中进行模拟和伪造，从而更好的重现软件状态，减少软件状态本身对自动化测试带来的干扰。

步骤S104：将第一输入请求包输入给测试版本应用。

在本实施例中，将存储在回放后台的第一输入请求包作为输入发送给测试版本应用，此时，发送给测试版本应用的第一输入请求包与稳定版本输入的第一输入请求包相同，从而避免测试版本应用的由于输入的不同而产生的响应噪音。

步骤S105：采集测试版本应用处理第一输入请求包产生的第二发送请求包。

在本实施例中，测试版本应用获取到第一输入请求包后，会根据第一输入请求包进行对应处理得到第二发送请求包，同时会将该第二发送请求包发送至虚拟后台进行存储。其中，为了避免线上环境带来的干扰，将测试版本应用在独立网段的服务器内，在部署测试版本应用前还需部署虚拟代理，通过虚拟代理采集测试版本应用处理第一输入请求包产生的所有第二发送请求包，并将其转发至虚拟后台进行存储。

其中，在测试版本应用将第二发送请求包发送给虚拟后台的过程中，在测试版本应用与虚拟后台之间部署虚拟代理，通过该虚拟代理截获所有测试版本应用发送给虚拟后台的第二发送请求包。该第二发送请求包是由测试版本应用发起的，第二发送请求包内的访问地址和端口等信息在测试版本应用内已经确定，一个测试版本应用的所有第二发送请求包可能会发向多个地址，为避免需要搭建多个虚拟后台的资源开销，因此，将所有的第二发送请求包均转发至虚拟后台处理。

为了实现统一转发的流程，在测试版本应用启动时修改其默认运行的网络相关动态库，即基于C语音网络库实现第二发送请求包的截获的网络相关动态库。为了减少对测试版本应用本身性能的影响，网络相关动态库只是简单的将第二发送请求包转至虚拟代理，虚拟代理通过修改第二发送请求包的网络层层中的地址信息，并将修改后的第二发送请求包统一转发至虚拟后台，由虚拟后台来统一对第二发送请求包传输层和应用层报文进行解析和匹配。

步骤S106：从虚拟后台选择与第二发送请求包最接近的第一发送请求包，并获取到最接近的第一发送请求包对应的第一发送响应包。

在本实施例中，虚拟后台接收到第二发送请求包后，将该第二发送请求包存储在虚拟后台。此时，虚拟后台内存储有第一发送请求包、第一发送响应包以及第二发送请求包，虚拟后台根据第一发送请求包以及第二发送请求包得到第二客户端响应包。

具体地，虚拟后台接收到第二发送请求包后，将第二发送请求包与第一发送请求包进行包对比，从第一发送请求包中选择与第二发送请求包最接近的第一发送请求包，并获取到该最接近的第一发送请求包对应的第一发送响应包。

步骤S107：将最接近的第一发送请求包对应的第一发送响应包输入到测试版本应用。

在本实施例中，将最接近的第一发送请求包对应的第一发送响应包输入到测试版本应用，测试版本应用接收最接近的第一发送请求包对应的第一发送响应包，即此时测试版本应用的输入包括第一输入请求包和最接近的第一发送请求包对应的第一发送响应包，测试版本应用根据第一输入请求包和最接近的第一发送请求包对应的第一发送响应包处理得到第二输入响应包，此时，输入至测试版本应用的第一输入请求包与第一发送响应包与稳定版本应用的第一输入请求包与最接近的第一发送请求包对应的第一发送响应包一一对应且相同，从而避免了由于测试版本应用与稳定版本应用由于输入不同导致的输出不同。

步骤S108：抓取测试版本应用对应第一输入请求包，以及最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包。

在本实施例中，测试版本应用对应第一输入请求包，以及最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包后，抓取该第二输入响应包传输至回放后台并进行存储。此时，测试版本应用的响应噪音是由于服务器系统调用本身的不可控产生的响应噪应，避免了由于测试版本应用和稳定版本应用输入不同而产生的不同的影响，得到响应噪音更加准确。

步骤S109：基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音。

在本实施例中，第一输入响应包与第二输入响应包均存储在回放后台中，将存储在回放后台内的第一输入响应包与第二输入响应包进行差异对比，分析得到响应噪音。具体地，基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音，此时，测试版本应用的响应噪音是由于服务器系统调用本身的不可控产生的响应噪应，避免了由于测试版本应用和稳定版本应用输入不同而产生的不同的影响，得到响应噪音更加准确。同时，模拟的第一输入请求包，以及伪造的最接近的第一发送请求包对应的第一发送响应包作为输入，即通过模拟软件的输入内容及其顺序，以重现软件状态，减少了软件状态本身对自动化测试带来的干扰，提高自动化测试的效率和准确率。

其中，第一输入响应包与第二输入响应包的报文格式有一种或多种，例如json、html、xml等报文格式，根据报文格式的不同，对比算法和噪音的标注方式可进行对应的调整，具体调整方式在此不做限定。

请进一步参阅图3，图3是图1的响应噪音的识别方法中的数据流向示意图。

在本实施例中，首先启动抓包程序，在启动稳定版本应用301，由测试人员输入测试数据，稳定版本应用301在测试用例输入后会接收到第一输入请求包，并对该第一输入请求包进行处理得到第一发送请求包，在该过程中，抓包程序抓取输入到稳定版本应用的第一输入请求包以及稳定版本应用301发送给客户端的第一发送请求包，抓包程序将第一输入请求包存储至回放后台302，将第一发送请求包存储至虚拟后台303；同时，客户端接收到第一发送请求包后对该第一发送请求包进行处理得到第一发送响应包，并将该第一发送响应包发送给稳定版本应用301，抓包程序在稳定版本应用301接收该第一发送响应包时，抓取第一发送响应包存储至虚拟后台303中；稳定版本应用301接收到第一发送响应包后，对第一输入请求包和第一发送响应包进行处理并得到第一输入响应包，抓包程序抓取该第一输入响应包并存储至回放后台302。

启动测试版本应用304，将存储在回放后台301的第一输入请求包输入至测试版本应用304，测试版本应用304接收到第一输入请求包处理得到第二发送请求包，并将该第二发送请求包发送至虚拟后台303进行存储；在虚拟后台303中，对存储在虚拟后台303的第二发送请求包进行处理，具体地，将第二发送请求包与第一发送请求包进行包对比，从而在选出与第二发送请求包最接近的第一发送请求包，将最接近的第一发送请求包对应的第一发送响应包作为输入从虚拟后台303中提取出来，并发送给测试版本应用304，测试版本应用304接收到最接收的第一发送请求包对应的第一发送响应包，根据第一输入请求包以及最接收的第一发送请求包对应的第一发送响应包进行处理得到第二输入响应包，并将该第二发送响应包发送至回放后台302进行存储。

在上述过程中，输入至稳定版本应用304的第一输入请求包以及第一发送响应包，与输入至测试版本应用304的第一输入请求包以及最接收的第一发送请求包对应的第一发送响应包实际上是相同的，即输入到稳定版本应用301和测试版本应用304的请求是相同的，而由相同的输入返回的第一输入响应包和第二输入响应包理论上是相同的，但实际请求下由于稳定版本应用301和测试版本应用304的运行环境以及软件内部算法的影响，相同的输入返回的返回的第一输入响应包和第二输入响应包实际带有不可复现的内容，即响应噪音，通过对第一输入响应包和第二输入响应包即可识别分析出响应噪音。识别出的响应噪音可以在自动化测试过程中，测试人员可以通过该识别方法识别的响应噪音快速、精准将响应噪音和因BUG产生的差异区分开来，从而找到因BUG产生的差异，进一步提高自动化测试的效率和精度。

区别于现有技术，本申请提供了一种响应噪音的识别方法，本申请的识别方法可以应用在有状态、有存储的测试版本应用上，还可以应用于主流的互联网公司的大型多服务网络架构以及离线场景中，大大减少自动化测试中噪音带来的干扰，提高自动化测试的效率和准确率，同时还可以为无脚本回归测试、全链路压测等高级研测方案提供数据支持。

请参阅图4，图4是本申请提供的响应噪音的识别方法的第二实施例的流程示意图，本实施方式的识别方法包括：

步骤S401：启动稳定版本应用。

在本实施例中，启动稳定版本应用，稳定版本应用在启动期间自身会向外发送的第一发送请求包，此时的第一发送请求包一般多是各种拉取配置的请求。

步骤S402：抓取启动稳定版本应用产生的第一发送请求包以及与第一发送请求包对应的第一发送响应包。

在本实施例中，在启动稳定版本应用之前，先启动抓包程序，通过该抓包程序可以抓取启动稳定版本应用产生的第一发送请求包以及与第一发送请求包对应的第一发送响应包。

步骤S403：将启动稳定版本应用产生的第一发送请求包和第一发送响应包存储到虚拟后台。

在本实施例中，抓包程序抓取到稳定版本应用启动期间第一发送请求包和第一发送响应包后，将启动稳定版本应用产生的第一发送请求包和第一发送响应包存储到虚拟后台，从而避免了部分数据的丢失，提供了测试的准确率。

步骤S404：获取到测试数据，并将测试数据输入到稳定版本应用中。

步骤S404与上述步骤S101相同，在此不再赘述。

步骤S405：抓取稳定版本应用处理测试数据产生的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包。

步骤S405与上述步骤S102相同，在此不再赘述。

步骤S406：将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台。

步骤S406与上述步骤S103相同，在此不再赘述。

步骤S407：将第一输入请求包输入给测试版本应用。

在本实施例中，将存储在回放后台的第一输入请求包作为输入发送给测试版本应用，此时，发送给测试版本应用的第一输入请求包与稳定版本输入的第一输入请求包相同，从而避免测试版本应用的由于输入的不同而产生的响应噪音。

其中，在将第一输入请求包输入给测试版本应用的步骤还包括：响应于测试版本应用已正常启动，将第一输入请求包输入给测试版本应用。

具体地，自动化测试时，模拟回放录制耗时多长，回放耗时也需要对应的时长，但当测试数据来自实际生产环境时，录制会持续很长时间以提高测试数据的功能覆盖率，此时，若每次回放都要消耗相同时长，整个自动化测试的效率就会降低。因此，为了提高自动化测试效率，在模拟回放过程中，需要监听测试版本应用的启动状态。

在模拟回放过程中，需要等待测试版本应用正常启动，而测试版本应用启动时间无法调节，因此，通过监听所有的第一发送请求包是否全部存储至虚拟后台的方式，进一步判断是否可以向测试版本应用发送存储在回放后台的第一输入请求包。具体地，在稳定版本获取到测试数据时，监听第一个第一输入请求包发送至测试版本应用前，所有的第一发送请求包是否全部存储至虚拟后台，当第一个第一输入请求包发送至测试版本应用前，所有的第一发送请求包均全部存储至虚拟后台，则启动测试版本应用。

在第一输入请求包输入到测试版本应用前，响应于稳定版本应用产生的第二发送请求包全部发送完毕，启动测试版本应用，将第一输入请求包从回放后台输入个测试版本应用。

同时为了让系统更准确的判断测试版本应用是否启动，通过预设方式确定测试版本应用是否已正常启动，其中，该预设方式包括通过心跳监听或其他由定时任务触发的第二发送请求包的方式判断测试版本应用是否正常启动。进一步地，第二发送请求包在模拟时不一定会全部复现，还可根据测试版本应用启动时间、第二发送请求包捕获百分比等参数等方式进行监听，以调节不同的测试版本应用的启动监听效果。可选的，还可以增加自定义启动判断插件，通过自定义启动判断插件，设置不同的监听参数，从而让系统更准确的判断测试版本应用是否启动。

在确定测试版本应用启动后，可以使用tcpdump等常用回放工具的方法，实现倍数回放、顺序回放、逐步回放等多种回放方式，测试人员在不同场景下可以选择合适的回放方式，从而提高效率和准确率。

步骤S408：采集测试版本应用处理第一输入请求包产生的第二发送请求包。

步骤S408与上述步骤S105相同，在此不再赘述。

步骤S409：从虚拟后台选择与第二发送请求包最接近的第一发送请求包，并获取到最接近的第一发送请求包对应的第一发送响应包。

步骤S409与上述步骤S106相同，在此不再赘述。

步骤S410：将最接近的第一发送请求包对应的第一发送响应包输入到测试版本应用。

步骤S410与上述步骤S107相同，在此不再赘述。

步骤S411：抓取测试版本应用对应第一输入请求包，以及最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包。

步骤S411与上述步骤S108相同，在此不再赘述。

步骤S412：基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音。

步骤S412与上述步骤S109相同，在此不再赘述。

区别于现有技术，本申请提供了一种响应噪音的识别方法，本申请的识别方法可以应用在有状态、有存储的测试版本应用上，还可以应用于主流的互联网公司的大型多服务网络架构以及离线场景中，大大减少自动化测试中噪音带来的干扰，提高自动化测试的效率和准确率，同时还可以为无脚本回归测试、全链路压测等高级研测方案提供数据支持。

请参阅图5，图5是本申请响应噪音识别模型一实施例的框架示意图。响应噪音识别模型50包括：稳定版本抓包模块501，稳定版本抓包模块501用于在获取到测试数据，并将测试数据输入到稳定版本应用中；稳定版本抓包模块501还用于抓取稳定版本应用处理测试数据产生的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包；稳定版本抓包模块501还用于将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台；模拟回放模块502，模拟回放模块502用于将第一输入请求包输入给测试版本应用；模拟回放模块502还用于采集测试版本应用处理第一输入请求包产生的第二发送请求包；模拟回放模块502还用于从虚拟后台选择与第二发送请求包最接近的第一发送请求包，并获取到最接近的第一发送请求包对应的第一发送响应包；模拟回放模块502还用于将对应的第一发送响应包输入到测试版本应用；模拟回放模块502还用于抓取测试版本应用对应第一输入请求包，以及对应的第一发送响应包产生的第二输入响应包；响应噪音识别模块503，响应噪音识别模块503用于基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音。

稳定抓包模块501具体用于抓包程序启动后，抓取稳定版本应用处理测试数据产生的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包。在将第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包抓取完毕后，将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台。从而可以将稳定抓包模块501抓取的第一输入请求包和第一发送响应包可以在测试版本应用运行过程中进行模拟和伪造，从而更好的重现软件状态，减少软件状态本身对自动化测试带来的干扰。

模拟回放模块502具体用于将稳定抓包模块501存储在回放后台的第一输入请求包作为输入发送给测试版本应用，测试版本应用获取到第一输入请求包后，会根据第一输入请求包进行对应处理得到第二发送请求包，同时会将该第二发送请求包发送至虚拟后台进行存储。在测试版本应用发送第二发送请求包至虚拟后台时，通过虚拟代理采集测试版本应用处理第一输入请求包产生的第二发送请求包。

虚拟后台在接收到第二发送请求包并进行存储后，虚拟后台内存储有第一发送请求包、第一发送响应包以及第二发送请求包，虚拟后台根据第一发送请求包以及第二发送请求包得到第二客户端响应包。模拟回放模块502将第二发送请求包与第一发送请求包进行包对比，从第一发送请求包中选择与第二发送请求包最接近的第一发送请求包，并获取到该最接近的第一发送请求包对应的第一发送响应包。

模拟回放模块502将该最接近的第一发送请求包对应的第一发送响应包输入到测试版本应用，此时测试版本应用的输入包括第一输入请求包和最接近的第一发送请求包对应的第一发送响应包，测试版本应用根据第一输入请求包和最接近的第一发送请求包对应的第一发送响应包处理得到第二输入响应包，此时，输入至测试版本应用的第一输入请求包与第一发送响应包与稳定版本应用的第一输入请求包与最接近的第一发送请求包对应的第一发送响应包一一对应且相同，从而避免了由于测试版本应用与稳定版本应用由于输入不同导致的输出不同。

模拟回放模块502抓取测试版本应用对应第一输入请求包，以及最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包，并将该第二输入响应包发送至回放后台进行存储。

模拟回放模块502还用于响应于测试版本应用已正常启动，将第一输入请求包输入给测试版本应用。具体地，模拟回放模块502第一输入请求包输入到测试版本应用前，响应于稳定版本应用产生的第二发送请求包全部发送完毕，启动测试版本应用，将第一输入请求包从回放后台输入个测试版本应用。

模拟回放模块502还用于通过预设方式确定测试版本应用是否已正常启动。其中，预设方式包括通过心跳监听或其他由定时任务触发的第二发送请求包的方式判断测试版本应用是否正常启动。可选的，模拟回放模块502还可根据测试版本应用启动时间、第二发送请求包捕获百分比等参数等方式进行监听，以调节不同的测试版本应用的启动监听效果。模拟回放模块502还可以增加自定义启动判断插件，通过自定义启动判断插件，设置不同的监听参数，从而让系统更准确的判断测试版本应用是否启动。

响应噪音识别模块503具体用于基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音，测试版本应用的响应噪音是由于服务器系统调用本身的不可控产生的响应噪应，避免了由于测试版本应用和稳定版本应用输入不同而产生的不同的影响，得到响应噪音更加准确。同时，模拟的第一输入请求包，以及伪造的最接近的第一发送请求包对应的第一发送响应包作为输入，即通过模拟软件的输入内容及其顺序，以重现软件状态，减少了软件状态本身对自动化测试带来的干扰，提高自动化测试的效率和准确率。

请参阅图6，图6是本申请电子设备一实施例的框架示意图。电子设备60包括相互耦接的存储器601和处理器602，处理器602用于执行存储器601中存储的程序指令，以实现上述任一识别方法实施例的步骤。在一个具体的实施场景中，电子设备60可以包括但不限于：微型计算机、服务器。

具体而言，处理器602用于控制其自身以及存储器601以实现上述任一识别方法实施例的步骤。处理器602还可以称为CPU(Central Processing Unit，中央处理单元)。处理器602可能是一种集成电路芯片，具有信号的处理能力。处理器602还可以是通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application SpecificIntegrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器602可以由集成电路芯片共同实现。

上述方案，处理器602在获取到测试数据，并将测试数据输入到稳定版本应用中；抓取稳定版本应用处理测试数据产生的第一输入请求包、与第一输入请求包对应的第一输入响应包、第一发送请求包以及与第一发送请求包对应的第一发送响应包；将第一输入请求包和第一输入响应包存储至回放后台，将第一发送请求包和第一发送响应包存储至虚拟后台；将第一输入请求包输入给测试版本应用；采集测试版本应用处理第一输入请求包产生的第二发送请求包；从虚拟后台选择与第二发送请求包最接近的第一发送请求包，并获取到最接近的第一发送请求包对应的第一发送响应包；将最接近的第一发送请求包对应的第一发送响应包包输入到测试版本应用；抓取测试版本应用对应第一输入请求包，以及最接近的第一发送请求包对应的第一发送响应包产生的第二输入响应包；基于第一输入响应包以及第二输入响应包确定测试版本应用的响应噪音。

请参阅图7，图7是本申请计算机可读存储介质一实施例的框架示意图。计算机可读存储介质70存储有能够被处理器运行的程序指令700，程序指令700用于实现上述任一识别方法实施例的步骤。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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