CN113296653B - 一种仿真交互模型构建方法、交互方法及相关设备 - Google Patents

Abstract

本申请实施例提供一种仿真交互模型构建方法、交互方法及相关设备，其中仿真交互模型构建方法包括：预先获取使用者与应用程序的交互数据；至少基于所述交互数据构建仿真交互模型，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；生成所述仿真交互模型对应的用于用户交互的仿真交互页面。本申请实施例能够降低沉浸式交互体验的实现成本并且提升了通用性。

Description

一种仿真交互模型构建方法、交互方法及相关设备

技术领域

本申请实施例涉及用户交互技术领域，具体涉及一种仿真交互模型构建方法、交互方法及相关设备。

背景技术

互联网服务提供方在宣传、介绍新的互联网应用程序（简称应用程序）或者应用程序的新功能时，或者，用户在初次使用新的应用程序或者应用程序的新功能时，往往需要通过交互引导，以引导用户如何使用应用程序；特别是一些涉及复杂用户操作的应用程序，有效的交互引导能够使得用户更为快速的上手使用应用程序。交互引导可以通过可视化引导、视觉动效、声音引导等方式，来引导用户与应用程序的交互体验，从而在用户与应用程序的交互过程中，基于用户的感官和认知体验，营造沉浸式交互体验。

沉浸式交互体验无疑为用户上手使用一些涉及复杂用户操作的应用程序提供了途径。然而，每个应用程序在开发时都有其自身独特的技术栈和技术实现，如果通过改造应用程序的代码来实现沉浸式交互体验，无疑存在较大的改造成本；并且需要通过分别改造各个应用程序的代码来实现各个应用程序的沉浸式交互体验，难以实现通用化。因此，如何提供沉浸式交互体验方案，以降低沉浸式交互体验的实现成本并且提升通用性，成为了本领域技术人员亟需解决的问题。

发明内容

有鉴于此，本申请实施例提供一种仿真交互模型构建方法、交互方法及相关设备，以通过仿真技术来构建用户与应用程序进行交互的仿真交互模型，从而在仿真层面为用户与应用程序提供沉浸式交互体验，降低沉浸式交互体验的实现成本并且提升通用性。

为实现上述目的，本申请实施例提供如下技术方案。

第一方面，本申请实施例提供一种仿真交互模型构建方法，所述方法包括：

预先获取使用者与应用程序的交互数据；

至少基于所述交互数据构建仿真交互模型，其中，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；

生成所述仿真交互模型对应的用于用户交互的仿真交互页面。

第二方面，本申请实施例提供一种交互方法，所述方法包括：

展示仿真交互模型对应的仿真交互页面；

在所述仿真交互页面检测当前交互操作，所述当前交互操作由仿真交互模型提供；

调用与所述当前交互操作关联的交互数据，并在所述仿真交互页面展示相应的交互效果，所述交互数据为预先获取的使用者与应用程序的交互数据。

第三方面，本申请实施例提供一种仿真交互模型构建装置，包括：

数据获取模块，用于预先获取使用者与应用程序的交互数据；

模型构建模块，用于至少基于所述交互数据构建仿真交互模型，其中，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；

页面生成模块，用于生成所述仿真交互模型对应的用于用户交互的仿真交互页面。

第四方面，本申请实施例提供一种交互装置，包括：

页面展示模块，用于展示仿真交互模型对应的仿真交互页面；

操作检测模块，用于在所述仿真交互页面检测当前交互操作，所述当前交互操作由仿真交互模型提供；

数据调取及展示模块，用于调用与所述当前交互操作关联的交互数据，并在所述仿真交互页面展示相应的交互效果，所述交互数据为预先获取的使用者与应用程序的交互数据。

第五方面，本申请实施例提供一种模型构建设备，包括：至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第一方面所述的仿真交互模型构建方法。

第六方面，本申请实施例提供一种交互前端，包括：至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如上述第二方面所述的交互方法。

第七方面，本申请实施例提供一种存储介质，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时实现如上述第一方面所述的仿真交互模型构建方法，或者，如上述第二方面所述的交互方法。

第八方面，本申请实施例提供一种程序，所述程序被电子设备执行时实现如上述第一方面所述的仿真交互模型构建方法，或者，如上述第二方面所述的交互方法。

本申请实施例提供的仿真交互模型构建方法可在使用者与应用程序的真实交互过程中，预先获取使用者与应用程序的交互数据；至少基于所述交互数据构建仿真交互模型，其中，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；生成所述仿真交互模型对应的用于用户交互的仿真交互页面。可以看出，本申请实施例构建的仿真交互模型可在仿真环境下提供交互操作，并且该交互操作可直接调用预先获取的交互数据，而不需要通过真实的交互接口来获取交互数据；因此本申请实施例构建的仿真交互模型可使得用户交互过程能够在仿真环境下进行，而不需要调用真实的交互接口实现，减少了对应用程序的代码改造，并且能够在多个应用程序进行通用。本申请实施例通过仿真技术来构建用户与应用程序进行交互的仿真交互模型，从而在仿真层面为用户与应用程序提供沉浸式交互体验，降低了沉浸式交互体验的实现成本并且提升了通用性。

附图说明

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

图1为沉浸式交互体验的制约示意图。

图2为本申请实施例提供的构建仿真交互模型的系统架构示意图。

图3为本申请实施例提供的仿真交互模型构建方法的流程图。

图4为本申请实施例提供的构建仿真交互模型的阶段示意图。

图5a为本申请实施例提供的采集交互数据的流程图。

图5b为浏览器的原生API的转接示例图。

图5c为本申请实施例注入撷取器的实现流程图。

图5d为MarkUp的技术架构示意图。

图5e为导致采集的数据不具有唯一性的情况示意图。

图5f为交互数据的唯一标识的形成示意图。

图6a为仿真建模阶段的子阶段示意图。

图6b为仿真交互模型的组成示意图。

图6c为页面快照技术的实现示例图。

图6d为页面的元素捕捉与展示示意图。

图6e为构建页面的示意图。

图7a为本申请实施例提供的交互方法的流程图。

图7b为本申请实施例提供的交互实现示意图。

图8a为本申请实施例提供的仿真交互模型构建装置的框图。

图8b为本申请实施例提供的模型构建设备的框图。

图8c为本申请实施例提供的交互装置的框图。

具体实施方式

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

沉浸式体验：沉浸体验（Flow Experience），也叫沉浸理论（Flow Theory）。用户进入沉浸式体验时，具备高度的挑战与鼓舞(highlevels of challenge and arousal)、注意力专注(focused attention)以及交互与远距临场感的强化(enhanced by interactivityand telepresence)等条件。本申请实施例所指的沉浸式体验为沉浸式交互体验，特指互联网领域中，使用软件辅助来在用户与应用程序的交互体验过程中，达到挑战与鼓舞、注意力专注与交互等目的，从而使得用户沉浸其中。

本申请的发明人发现：应用程序要实现沉浸式交互体验往往会受到三项制约，并且存在难以通用化和实现成本较高的问题。图1示例性的示出了沉浸式交互体验的制约示意图。如图1所示，该三项制约包括：真实线上环境制约、业务稳定性制约、以及应用程序的差异性制约。真实线上环境制约是指应用程序上线后，出于应用程序的运行操作考虑而产生的来自线上环境的制约，包括：接口鉴权问题、资源占用问题、安全性问题、接口的延时问题等。业务稳定性制约主要是指应用程序进行迭代时，沉浸式交互体验也需要相应的调整，否则可能导致沉浸式交互体验的稳定性变差，例如沉浸式交互体验的体验内容出现错误。沉浸式交互体验的稳定性直接影响沉浸式交互体验的质量。应用程序的差异性制约来自于应用程序的差异性，不同的应用程序所使用的前端框架、接口格式定义、账号体系都不相同，这使得沉浸式交互体验的实现成本变高，难以复制和通用。基于上述这些制约，如果直接改造应用程序的代码来实现沉浸式交互体验，将带来较高的实现成本并且难以通用化的问题。

基于此，本申请实施例提供新型的沉浸式交互体验方案，该沉浸式交互体验方案可将用户与应用程序的交互过程设计成仿真过程，并基于仿真技术构建出用于交互的仿真交互模型；通过该仿真交互模型，用户不需要登录账号、不需要调用接口就能在应用程序的交互引导中实现沉浸式交互体验。

下面将分别对本申请实施例提供的仿真交互模型的构建方案，以及基于仿真交互模型的交互方案进行介绍。

图2示例性的示出了本申请实施例提供的构建仿真交互模型的系统架构示意图。如图2所示，构建仿真交互模型的系统架构可以包括：仿真前端210、应用程序服务器220、仿真服务器230。仿真前端210是构建仿真交互模型所使用的客户端，仿真前端210可以部署于手机、PC（个人计算机）等电子设备上。在一些实施例中，仿真前端210可以提供浏览器（例如基于H5的浏览器）。应用程序服务器220是提供应用程序的服务支持的服务器设备，在使用者与应用程序的真实交互过程中，仿真前端210可与应用程序服务器220进行交互，并产生交互数据。在一些实施例中，应用程序服务器220可以支持基于H5（HTML5，超文本5）的服务。仿真服务器（Mock Server）230可以是部署于网络侧的构建仿真交互模型所使用的服务设备。本申请实施例构建的仿真交互模型可存储于仿真服务器。

在一些实施例中，仿真前端210的使用者可以是互联网服务提供方的技术人员（例如运营人员）。也就是说，仿真前端210可以是本申请实施例构建仿真交互模型所使用的客户端，其使用者可以是互联网服务提供方的技术人员。例如，互联网服务提供方的技术人员可基于应用程序的交互引导需求，使用仿真前端210构建仿真交互模型。而在进行具体的交互引导时，交互引导的对象可以是使用应用程序的用户，此时，用户可使用交互前端基于仿真交互模型进行具体的交互引导。在一种可选实现中，本申请实施例构建仿真交互模型的阶段所使用的前端为仿真前端，其使用者可以是互联网服务提供方的技术人员；而在交互引导的阶段所使用的前端为交互前端，其使用者可以是使用应用程序的用户。

作为一种可选实现中，图3示出了本申请实施例提供的仿真交互模型构建方法的可选流程图。如图3所示，该流程可以包括如下步骤。

在步骤S310中，预先获取使用者与应用程序的交互数据。

仿真前端可提供使用者与应用程序进行真实交互的能力，例如，仿真前端可提供浏览器，从而使用者可通过浏览器与应用程序进行真实交互。在使用者与应用程序的真实交互过程中，本申请实施例可预先获取使用者与应用程序的交互数据。在一些实施例中，此处的使用者可以是互联网服务提供方的技术人员（例如运营人员）；在另一些实施例中，此处的使用者也可以是使用应用程序的用户，即本申请实施例也可支持基于用户与应用程序的真实交互过程，构建仿真交互模型。

在一些实施例中，仿真前端可通过用于交互请求的原生接口，与应用程序服务器进行交互，以实现使用者与应用程序的真实交互。该原生接口可基于使用者的交互操作向应用程序服务器发送交互请求，以及获得应用程序服务器反馈的交互响应数据。作为一种可选实现，本申请实施例可通过劫持该原生接口，以在使用者与应用程序的真实交互过程中，劫持使用者与应用程序的交互数据，从而预先获取到使用者与应用程序的交互数据。

在一些实施例中，步骤S310可由仿真前端执行实现，例如仿真前端通过劫持原生接口，以预先获取使用者与应用程序的交互数据。在另一些实施例中，步骤S310可由仿真服务器执行实现，例如仿真服务器可预先获取仿真前端劫持的交互数据。

在步骤S311中，至少基于所述交互数据构建仿真交互模型，其中，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据。

在预先获取使用者与应用程序的交互数据后，本申请实施例可至少基于所述交互数据构建仿真交互模型。需要说明的是，仿真交互模型可在仿真层面为用户提供交互操作，并在提供的交互操作被执行后呈现对应的交互效果。为避免基于仿真交互模型实现的用户交互需要调用真实的交互接口，本申请实施例可将仿真交互模型提供的交互操作与步骤S310中预先获取的交互数据进行关联，从而通过仿真交互模型提供的交互操作可直接调用步骤S310中预先获取的交互数据。

在一些实施例中，仿真交互模型可提供使用者与应用程序的多个交互场景，并且在各个交互场景下提供交互操作的集合。该交互操作的集合中的各个交互操作可与步骤S310中对应预先获取的交互数据进行关联，从而在进行交互引导时，用户基于仿真交互模型执行了某一交互操作，本申请实施例可直接调用步骤S310预先获取的对应的交互数据，而不需要再通过真实的交互接口来获取对应的交互数据。因此本申请实施例构建的仿真交互模型可使得用户交互过程能够在仿真环境下进行，而不需要调用真实的交互接口实现，减少了对应用程序的代码改造，并且能够在多个应用程序进行通用。

在一些实施例中，步骤S310可以基于使用者的交互操作向应用程序服务器发送交互请求，以实现预先获取使用者与应用程序的交互数据，本申请实施例可确定出预取获取的交互数据所对应的交互操作，也就是说，确定触发获取交互数据的交互操作；进而，本申请实施例可由仿真交互模型提供触发获取交互数据的交互操作，并与预先获取的交互数据进行关联。

在一些实施例中，步骤S311可由仿真前端执行实现。可选的，仿真前端在构建仿真交互模型后，可将仿真交互模型上传到仿真服务器，以便后续在实现用户交互时，能够从仿真服务器获取到仿真交互模型。在另一些实施例中，步骤S311可由仿真服务器实现，例如，仿真服务器可基于仿真前端劫持的交互数据，构建出仿真交互模型。

在步骤S312中，生成所述仿真交互模型对应的用于用户交互的仿真交互页面。

本申请实施例在实现用户交互时，可提供用于用户交互的仿真交互页面，以便用户在该仿真交互页面下基于仿真环境实现用户交互（例如交互引导）。因此本申请实施例在构建仿真交互模型后，可生成仿真交互模型对应的仿真交互页面，以便后续的用户交互过程使用。

在一些实施例中，步骤S312可由仿真前端执行实现。在另一些实施例中，步骤S312也可由仿真服务器执行实现。

本申请实施例提供的仿真交互模型构建方法可在使用者与应用程序的真实交互过程中，预先获取使用者与应用程序的交互数据；至少基于所述交互数据构建仿真交互模型，其中，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；生成所述仿真交互模型对应的用于用户交互的仿真交互页面。可以看出，本申请实施例构建的仿真交互模型可在仿真环境下提供交互操作，并且该交互操作可直接调用预先获取的交互数据，而不需要通过真实的交互接口来获取交互数据；因此本申请实施例构建的仿真交互模型可使得用户交互过程能够在仿真环境下进行，而不需要调用真实的交互接口实现，减少了对应用程序的代码改造，并且能够在多个应用程序进行通用。本申请实施例通过仿真技术来构建用户与应用程序进行交互的仿真交互模型，从而在仿真层面为用户与应用程序提供沉浸式交互体验，降低了沉浸式交互体验的实现成本并且提升了通用性。

作为一种可选实现，图4示例性的示出了本申请实施例提供的构建仿真交互模型的阶段示意图。如图4所示，构建仿真交互模型的阶段可以包括：脚本信息录入阶段410、数据采集阶段420、仿真建模阶段430、以及版本建立阶段440。在一些实施例中，上述示出的阶段可由仿真前端执行实现，并由仿真前端将上述阶段的输出结果上传到仿真服务器；例如，仿真前端可在数据采集阶段420采集使用者与应用程序的交互数据，在仿真建模阶段430构建仿真交互模型，在版本建立阶段440建立仿真交互模型的版本。仿真前端在实现仿真交互模型的构建与版本确定后，仿真前端可将采集的交互数据以及构建的仿真交互模型上传到仿真服务器，以便后续仿真环境下的用户交互过程使用。当然，由仿真前端实现上述阶段仅是一种示例，本申请实施例并不排除由仿真服务器实现上述部分阶段的情况，具体可视技术实现配置而定。下面以仿真前端主要实现上述阶段为例，对上述各阶段的实现内容进行说明。

在脚本信息录入阶段410，使用者（例如互联网服务提供方的技术人员）可填写仿真交互模型的脚本基本信息，例如：仿真交互模型的名称、交互使用的应用程序、使用者与应用程序的交互场景（也称为交互案例）等。在一些实施例中，本申请实施例可提供仿真交互模型的构建页面，该构建页面可在仿真前端进行展示，使用者可在构建页面输入所述脚本基本信息。需要说明的是，本申请实施例提供的用于用户交互的仿真交互模型也可称为剧本，上述仿真交互模型的名称也可视为是剧本名称。

在数据采集阶段420，仿真前端可采集使用者与应用程序的交互数据。在一些实施例中，仿真前端可在录制环境下，采集使用者与应用程序在交互场景下的交互数据，然后将交互数据录制到仿真服务器，以实现预先获取交互数据。可选的，仿真前端采集交互数据之后，可先将交互数据存储在本地数据库中，然后在实现仿真交互模型的构建与版本确定之后，再将本地数据库中存储的交互数据上传到仿真服务器。

在一些实施例中，上述构建页面可提供开始录制按钮，当使用者点击该开始录制按钮，仿真前端可进入录制环境。在录制环境下，仿真前端可通过劫持用于交互请求的原生接口，以劫持使用者与应用程序在交互场景下的交互数据。

在仿真建模阶段430，仿真前端可基于采集的交互数据，构建仿真交互模型。可选的，仿真前端构建的仿真交互模型可先存储在本地数据库中，然后在实现仿真交互模型的版本确定之后，再将本地数据库中存储的仿真交互模型上传到仿真服务器。

在一些实施例中，仿真交互模型可以视为是剧本，剧本可以包括一个或多个步骤。步骤可以是指仿真交互模型下的交互场景（例如交互案例），步骤包括一个或多个子步骤。子步骤是指仿真交互模型下的一个交互场景中的分段描述符，子步骤可以包括运行操作和/或回滚操作。运行操作是指运行一个子步骤下的交互操作的集合，以介绍或者引导使用应用程序的功能。回滚操作可回溯发生交互错误的交互操作或者上一交互操作。交互操作是仿真交互模型中的最小粒度，可以视为是执行的动作（Action），如点击、聚焦、输入数据等。

基于此，在仿真交互模型视为剧本的情况下，本申请实施例在仿真建模阶段，构建仿真交互模型的过程可以至少包括：创建剧本下的步骤、创建步骤下的子步骤、创建子步骤下的运行操作和/或回滚操作，创建运行操作和/或回滚操作下的多个交互操作。例如，本申请实施例可基于脚本信息录入阶段所录入的使用者与应用程序的交互场景创建剧本下的步骤、创建所述交互场景下的子步骤、以及创建子步骤下的运行操作和/或回滚操作中包含的各个交互操作，从而使得所述仿真交互模型可提供交互操作，子步骤下的运行操作和/或回滚操作中的交互操作可直接调用数据采集阶段所采集的交互数据。

在版本建立阶段440，本申请实施例可实现仿真交互模型的版本管理。

在一些实施例中，为便于用户在仿真环境下执行交互操作，本申请实施例可提供仿真交互模型对应的仿真页面，从而用户可在仿真交互模型对应的仿真页面下，执行交互操作。

本申请实施例通过构建用于交互的仿真交互模型，可将用户与应用程序的交互过程设计成仿真过程；用户在执行仿真交互模型提供的交互操作后，可实现直接调用预先获取的交互数据，而不需要通过真实的交互接口来获取交互数据，从而可在仿真环境下实现用户与应用程序的沉浸式交互体验。例如应用程序的互动引导可在仿真环境下实现，并提供沉浸式交互体验。

下面对本申请实施例在数据采集阶段420、仿真建模阶段430以及版本建立阶段440的可选实现过程进行分别说明。

在数据采集阶段420，仿真前端可刷新使用者与应用程序进行交互的页面，并在页面重新加载前，通过劫持仿真前端用于发送交互请求的原生接口，来劫持交互数据。上述过程可在录制环境下进行。作为一种可选实现，图5a示例性的示出了本申请实施例提供的采集交互数据的可选流程图。在一些实施例中，该流程可由仿真前端执行。如图5a所示，该流程可以包括如下步骤。

在步骤S510中，进入录制环境，触发刷新使用者与应用程序进行交互的页面。

在一些实施例中，当使用者点击构建页面的开始录制按钮后，仿真前端可进入录制环境并且触发页面重新加载（即触发刷新使用者与应用程序进行交互的页面）。

在步骤S511中，在页面重新加载前，劫持仿真前端用于交互请求的原生接口。

在使用者与应用程序的真实交互过程中，仿真前端可以通过用于交互请求的原生API（Application Programming Interface，应用程序接口），向应用程序服务器发送交互请求以及获取应用程序服务器反馈的对应的交互响应数据，以完成使用者与应用程序的真实交互。例如，仿真前端可加载使用者与应用程序进行交互的页面，使用者可在该页面上执行交互操作，从而仿真前端可通过原生API向应用程序服务器发送交互请求，进而获取应用程序服务器反馈的交互响应数据。

本申请实施例可将仿真前端用于交互请求的原生API进行劫持，以劫持到交互请求对应的交互响应数据，从而实现采集交互数据。在一些实施例中，本申请实施例可通过注入撷取器，来实现劫持仿真前端用于交互请求的原生API。撷取器可用于撷取接口信息。例如，本申请实施例可通过注入撷取器，将仿真前端用于交互请求的原生API转接为代理API，以实现劫持原生API。

在步骤S512中，基于劫持的原生接口发送交互请求，并捕获与所述交互请求对应的交互响应数据。

基于劫持的原生接口，本申请实施例可通过原生接口向应用程序服务器发送交互请求，并且捕获到应用程序服务器反馈的与所述交互请求对应的交互响应数据。在一些实施例中，若通过将原生API转接为代理API，以实现劫持原生API，则本申请实施例可基于原生API发起交互请求，通过代理API捕获到对应的交互响应数据。

仿真前端在通过劫持原生接口，采集到交互请求与对应的交互响应数据后，可将交互请求与对应的交互响应数据（交互请求与对应的交互响应数据可形成交互数据）存储到本地数据库，然后再在构建仿真交互模型和确定模型版本之后，将本地数据库中的交互数据上传到仿真服务器。

在一些实施例中，交互请求可以包括请求参数、请求包头等信息，本申请实施例可通过代理API捕获请求参数、请求包头以及仿真前端的cookies（例如浏览器的cookies）并进行封装，然后连同捕获的对应的真实交互响应（response）数据录制到仿真服务器。在可选实现中，仿真前端可先将数据存储到本地数据库，之后再将本地数据库存储的数据录制到仿真服务器中。

由于本申请实施例并不在真实交互环境下实现沉浸式交互体验，而是基于构建的仿真交互模型在仿真环境下实现沉浸式交互体验，因此为保障仿真交互模型在实现仿真交互时的准确性和真实性，本申请实施例构建仿真交互模型所使用的数据可以来源于使用者与应用程序在真实交互过程中的交互数据，包括使用者与应用程序在真实交互过程中的交互请求、以及相对应的交互响应数据。基于此，本申请实施例通过采集使用者与应用程序在真实交互过程中的交互数据，以预先获取交互数据，并将预先获取的交互数据与后续构建的仿真交互模型提供的交互操作进行关联，可使得基于仿真交互模型实现的用户交互能够通过交互操作直接调用预先获取的真实的交互数据，而不需要通过真实的交互接口来获取真实的交互数据。

在一个示例中，以仿真前端提供浏览器为例，本申请实施例可通过将浏览器用于交互请求的本机浏览器API（Native Browser API），转接为本机浏览器代理API（ProxyNative Browser API），以实现劫持仿真前端用于交互请求的原生接口。

图5b示例性的示出了浏览器的原生API的转接示例图。如图5b所示，浏览器可通过XMLHttpRequest或fetch等本机浏览器API（Native Browser API）进行交互请求，本机浏览器API可以视为是浏览器用于交互请求的原生API。例如，通过XMLHttpRequest或fetch等本机浏览器API，浏览器可基于用户的交互操作，向应用程序服务器发送交互请求，并获取对应的交互响应数据。其中，XMLHttpRequest是客户端的一个API，为浏览器与服务器通信提供了一个便捷通道；Fetch提供了一个JavaScript接口，用于访问和操纵HTTP（HyperTextTransfer Protocol，超文本传输协议）管道的一些具体部分，例如请求和响应。本申请实施例可将XMLHttpRequest或fetch等本机浏览器API进行转接，得到本机浏览器代理API（Proxy Native Browser API）。本机浏览器代理API可以具有如下功能：捕获交互请求的请求参数、请求包头以及浏览器的cookies等信息、并且捕获交互响应数据。进一步的，该本机浏览器代理API还可在将交互请求和对应的交互响应数据录制到仿真服务器之后，将交互响应数据返回给本机浏览器API，以实现在录制环境下的数据录制能够正常继续运行。

在一些实施例中，在将XMLHttpRequest或fetch等本机浏览器API进行转接，得到本机浏览器代理API之后，本申请实施例可基于劫持配置信息，实现劫持交互请求对应的交互响应数据。该劫持配置信息可以至少指示：以原生的XMLHttpRequest或Fetch API发起交互请求，以本机浏览器代理API捕获对应的交互响应数据；然后，以本机浏览器代理API将交互请求的请求参数、请求包头以及cookies进行封装，连同交互响应数据送到仿真服务器中进行存储；最后，将交互响应数据返回给原生的XMLHttpRequest或Fetch API，使得录制环境能够正常继续运行。

需要说明的是，主流浏览器对于交互请求所曝露的原生API一般遵循W3C（WorldWide Web Consortium，万维网联盟）协议，包含使用XHR（XML Http Request，XML Http请求）协议为主的XMLHttpRequest原生API以及新一代的fetch API。而一些主流的请求库皆是以XMLHttpRequest或fetch为基础进行封装的第三方库。因此，本申请实施例通过劫持仿真前端用于交互请求的原生API来实现数据采集，能够解决在不同系统中可能依赖不同请求库的问题，降低了数据采集的适配成本。

在一些实施例中，本申请实施例可在使用者与应用程序进行交互的页面重新加载前，通过注入器注入撷取器，来实现劫持仿真前端用于交互请求的原生接口。为避免原生API的接口信息漏捕捉的情况发生，本申请实施例需对撷取器注入原生接口的时机进行精准定义，以确保原生接口劫持的时机必然发生在原生接口发送交互请求之前。作为一种可选实现，图5c示出了本申请实施例注入撷取器的可选实现流程图。在一些实施例中，该流程可由仿真前端执行实现。如图5c所示，该流程可以包括如下步骤。

在步骤S520中，在页面重新加载之前，在仿真前端的localStorage（本地存储）中写入标签，以通知仿真前端需要启用注入器来在原生接口注入撷取器。

在触发刷新使用者与应用程序进行交互的页面之后，且该页面重新加载之前，本申请实施例可在仿真前端的localStorage中写入标签，以指示页面重新加载时需要启用注入器，来在原生接口注入撷取器。

在步骤S521中，在页面重新加载时，加载注入器；所述注入器基于在localStorage中检测到的所述标签启动撷取器，以将撷取器注入原生接口。

在一些实施例中，本申请实施例可触发仿真前端通过window.reload（窗口重新加载）方法来重新刷新页面，以调用真实交互环境下页面加载阶段所使用的接口。随后，仿真前端（例如浏览器）将经历onunload状态（onunload 状态在页面退出时发生）并进入重新加载页面资源的过程。在这个过程中，由于浏览器扩展程序的生命周期机制，浏览器会在页面的document readystate（文档读取状态）为loading（加载）阶段时，加载用于开始文档的内容脚本并运行内容脚本的代码，此时，本申请实施例可实现加载注入器。在注入器侦测到localStorage中的标签时启动撷取器，从而将撷取器注入原生接口，以启动请求劫持原生接口的能力。

由于上述整个过程都是同步进行的，因此本申请实施例可以保证撷取器的注入时机必然快于原生API的第一个交互请求的发生时间点。从而，在撷取器完成注入后，并且仿真前端完成启动环境准备后，本申请实施例可进入到document readystate为interactive（交互）的阶段，此时，页面相关的资源将开始被加载并运行操作，原生API的第一个交互请求便发生在这个交互阶段。

在一个示例中，注入器可以作为网络内容脚本（network content script）存在；以浏览器使用Chrome为例，本申请实施例实现加载用于开始文档的内容脚本的一种实现可以包括：由于Chrome扩展程序（Chrome Extension）的生命周期机制，Chrome扩展程序会在页面进入document readystate为loading阶段时，加载run_at状态为document_start的所有content script（内容脚本）并运行代码，此时，本申请实施例可在加载content script的过程中加载注入器。进而在注入器侦测到localStorage中的标签时启动撷取器，以启动请求劫持原生API的能力。其中，run_at为Chrome 扩展程序中manifest（清单）文件的一个描述属性，用于描述content script的运行时机。

在一个示例中，本申请实施例可使用录制工具（例如MarkUp），来实现录制交互数据，并将录制的交互数据存储到Chrome background的indexedDB里。Chrome background为Chrome 扩展程序中一个中心化的程序，该程序与其他Chrome线程以及其他background程序相隔离，生命周期与浏览器相同。Chrome Background中的操作元可以达到浏览器层级，即拥有较高权限，可调用浏览器级别API。IndexedDB是浏览器提供的本地数据库，它可以被网页脚本创建和操作。

以提供MarkUp录制工具为例，MarkUp是以Chrome Extension作为载体进行录制的工具，在架构上需遵循Chrome Extension的设计思路。图5d示例性的示出了MarkUp的技术架构示意图，可进行参照。结合图5d所示，当使用者点击启用插件后，Chrome background（浏览器后端）会收到仿真前端的请求并藉由content script loader来加载名为Apprenderer（应用程序渲染）的content script。App renderer会将MarkUp的交互组件加载到仿真前端的页面中。此外，Request（请求）与Error Handler（错误处理）这两个contentscript被设定为run_at状态是document_start，因此当页面加载时，仿真前端就会自动加载这两个content script。Request content script是进行数据劫持的主要插件，当启用数据劫持的功能时，该插件会将当前录制的接口进行劫持并将数据传递到backgroundscript的store listener（存储侦听器）中，以实现将数据存储到background workspace中的indexedDB当中。这样的设计方式避免了Chrome Extension在不同域名的页面中数据不共享的问题，使MarkUp实现了在多个应用程序中进行建模的能力。而Error handler插件则用来处理例外情况，如在多个页面中同时启用MarkUp插件或账号检查不通过等问题，若判定不通过，Error handler将在客户端页面中写入Error DOM（Document Object Model，文档对象模型），以告知错误信息。

需要进一步说明的是，在数据采集的过程中，可能会遇到采集数据的接口重复的问题，因此若没有一个完善的机制对采集的数据进行唯一标识，就有可能在后续基于仿真的交互过程出现请求到错误数据的情况。基于此，在进一步的一些实施例中，本申请实施例可对数据采集阶段所采集的交互数据提供唯一标识。

作为一种示例，图5e示例性的示出了导致采集的数据不具有唯一性的情况示意图，下面将分别对不同的情况进行说明。

跨应用程序的交互请求使用同一接口而返回不同数据，这种情况发生在跨应用程序的场景中。例如，数个应用程序可能调用相同的接口，但不同应用程序基于相同的接口可能返回不同的数据，若不对这种情况下取得的数据加以标识，可能会导致后续基于仿真的交互过程请求到错误数据的情况。

同一应用程序的交互请求使用同一接口而返回不同数据，这种情况发生在针对同一应用程序的交互请求，使用同一接口的场景中。这种情况的实例例如交互请求使用的接口为带状态的接口，比如在第一次请求数据时，数据处于loading（加载）状态，而再次基于同一接口请求数据时，数据变为了加载成功（success）的状态。

同一接口同时支持不同的交互请求方法。这种情况例如发生在同一接口拥有多重方法定义的RestFul（RESTFUL是一种网络应用程序的设计风格和开发方式） API上，因此即使接口的URL（Uniform Resource Locator，统一资源定位符）相同，但请求方法不同就会导致返回的数据结果不同。

应用程序存在轮询接口。这种情况发生在应用程序的轮询接口的场景下，这种情况的实例例如应用程序服务器需要处理时间来返回数据，因此应用程序服务器返回ticket让仿真前端每隔一段时间进行询问。ticket机制是指一些不经常改变的信息打包发送给仿真前端，然后仿真前端每次请求的时候都把这个信息带过来，这样应用程序服务器就可以减少查库或者远程调用的次数。

接口中query（查询）参数或body（本体）参数不同。这种情况下，同一接口中的query参数或body的参数不同，将导致交互请求（例如查询请求）中的query参数或body的参数不同，从而导致接口返回的数据结果不同。

cookie不同而导致数据不同。这种情况下，由于交互请求（例如身份校验的请求）中带入的cookie不同而导致返回的数据结果不同。

当然，上述列举的导致采集的数据不具有唯一性的情况仅是示例性的，本申请实施例并不排除其他可能导致采集的数据不具有唯一性的情况。

在一些实施例中，为使得本申请实施例采集的数据具有唯一性，本申请实施例可将交互请求拆解为多个请求参数，包括如下任意多项：请求的url、请求的query（查询）、请求的方法（Method）、请求的body（本体）、请求的源头（origin）、cookies、请求的数据类型（Content-Type）与请求包头（head）中的用户自定义key（User defined key）。基于将交互请求拆解的多个请求参数，本申请实施例可基于该多个请求参数、仿真互动模型的标识（用以标记仿真互动模型，例如剧本标识）、交互操作的ID（Action ID，用以标记特定用户操作），以及轮询计数器（Poll Request Counter）来形成交互数据的唯一标识。图5f示例性的示出了交互数据的唯一标识的形成示意图，可进行参照。

在一些实施例中，本申请实施例可由仿真服务器基于上述数据的唯一标识规则，执行生成交互数据的唯一标识。在本申请实施例的数据采集阶段，仿真前端劫持交互响应数据之后，可将交互请求与对应的交互响应数据发给仿真服务器。仿真服务器获取到交互请求与对应的交互响应数据后，可进行路由解析（例如通过spring wrapper方法进行路由解析）。在进行路由解析的可选实现中，本申请实施例可使用泛化规则解析，仅匹配规则而非实体路径；通过这样的路由解析方式，本申请实施例就能允许仿真过程中仅改变报文的源（origin），而其他内容保持不变来实现访问仿真服务器。spring wrapper解析过程会根据model（模型）类型来进行模型分发，将model送到模型管理器中取得对应的场景/主体模型，并将其加载到服务模型当中。根据加载的模型，本申请实施例可以对交互请求进行特定解析，取得交互请求的header、cookies等相关内容，这整个过程可称为泛化拆解技术。通过泛化拆解技术，本申请实施例可以更加灵活地扩展接口并支持多样化的互动请求的拆解能力。

当互动请求被拆解完毕后，仿真服务器可基于拆解的多个请求参数、仿真互动模型的、交互操作的ID，以及轮询计数器（Poll Request Counter）来形成交互数据的唯一标识。

在一些实施例中，基于本申请实施例提供的交互操作的ID，以及交互数据的唯一标识；本申请实施例在预先获取使用者与应用程序的交互数据之后，可基于触发获取交互数据的交互操作的ID，以及交互数据的唯一标识，设置交互操作的ID与交互数据的唯一标识之间的对应关系，以实现交互操作与预先获取的交互数据之间的关联。例如，用户执行了仿真交互模型提供的某一交互操作，则基于该交互操作的ID，本申请实施例可通过交互操作的ID与交互数据的唯一标识之间的对应关系，调用到该交互操作所关联的交互数据。在进一步的一些实施例中，预先获取的交互数据、交互操作的ID与交互数据的唯一标识之间的对应关系可存储在仿真服务器中，用户在使用交互前端进行仿真交互时，若在交互前端执行了仿真交互模型提供的某一交互操作，则交互前端可向仿真服务器指示交互操作的ID，从而仿真服务器可向交互前端反馈对应的交互数据的唯一标识所相应的交互数据，以实现调用仿真交互模型提供的交互操作所关联的交互数据。

本申请实施例在数据采集阶段之前，先进入脚本信息录入阶段，在脚本信息录入阶段，本申请实施例可让使用者填写与仿真交互模型（例如剧本）相关的基本信息，例如剧本名称、使用到的应用程序、使用者与应用程序的交互场景等基本信息。填写上述基本信息之后，本申请实施例进入数据采集阶段。在数据采集阶段中，当使用者点击开始录制按钮后，仿真前端会触发页面刷新并注入撷取器来劫持原生接口，以在录制环境下劫持到使用者与应用程序的交互数据，并将交互数据录制到仿真服务器中。从而，后续在仿真建模阶段，本申请实施例可基于脚本信息录入阶段录入的基本信息，以及数据采集阶段录制的交互数据，构建用于用户交互的仿真交互模型。

在仿真建模阶段430，本申请实施例可构建用于用户交互的仿真交互模型。图6a示例性的示出了仿真建模阶段430的子阶段示意图。如图6a所示，实现仿真建模阶段可以包括如下子阶段：创建步骤子阶段431、创建子步骤子阶段432、创建操作子阶段433、接口录制子阶段434、模型试运行子阶段435、模型存储子阶段436。

在创建步骤子阶段431，基于仿真交互模型（例如剧本）包括一个或多个步骤，本申请实施例可创建剧本下的步骤。在一些实施例中，步骤可以是仿真交互模型下的交互场景，本申请实施例可基于脚本信息录入阶段录入的使用者与应用程序的交互场景，创建剧本下的步骤。

在创建子步骤子阶段432，基于步骤包括一个或多个子步骤，本申请实施例可创建步骤下的子步骤。在一些实施例中，子步骤是指仿真交互模型下的一个交互场景中的分段描述符，可包括运行操作和/或回滚操作。

在创建操作子阶段433，本申请实施例可创建子步骤下的运行操作和/或回滚操作包含的各个交互操作，使得所述仿真交互模型提供交互操作。在一些实施例中，本申请实施例可基于数据采集阶段录制的交互数据对应的交互操作，录制交互操作。

由于使用者与应用程序的交互过程中还涉及原生接口的调用，在接口录制子阶段434，本申请实施例可对交互操作调用的原生接口进行录制。需要说明的是，在接口录制子阶段，原生接口是通过录制获得，并不涉及到后续真实的原生接口的调用。

上述创建步骤子阶段、创建子步骤子阶段、创建操作子阶段以及接口录制子阶段，可从仿真交互模型的粗粒度（步骤）至最小粒度（交互操作），逐层的构建出仿真交互模型，并且通过最小粒度的交互操作可实现数据采集阶段所采集的交互数据的直接调用。图6b示例性的示出了仿真交互模型的组成示意图，可进行参照。如图6b所示，仿真交互模型（即剧本）下可包括多个步骤，一个步骤可对应使用者与应用程序的一个交互场景，一个步骤可表示应用程序的一个功能点的交互，例如介绍表单使用方式的交互、讲解如何进行开通应用程序功能的交互等；一个步骤下可包括多个子步骤，一个子步骤例如介绍一个表单的交互、描述开通功能的定义的交互等，一个子步骤下可以包括有序的交互操作的集合，且有序的交互操作的集合可形成运行操作与回滚操作；运行操作指的是完成一个子步骤所需的交互操作的集合，例如在介绍表单的交互时，涉及选中表单、展开表单、高亮表单、输入范例值等交互操作；回滚操作则表示回溯交互操作以用于支持发生交互错误的情况或上一步的交互操作；可以看出，子步骤下可以包括多个交互操作，各个交互操作可关联数据采集阶段所采集的交互数据。

需要说明的是，上述仿真交互模型的组成仅是一种示例，仿真交互模型除了剧本、步骤、子步骤、交互操作等粒度的拆解外，还可能根据实际的交互需求发生变化，例如剧本与剧本的串接形成剧场、交互操作再细分为操作源等。

在构建出仿真交互模型后，在模型试运行子阶段435，本申请实施例可试运行仿真交互模型，以查看构建的仿真交互模型是否符合预期，若不符合预期，则可对仿真交互模型继续进行修改编辑（例如重新创建仿真交互模型提供的交互操作）。当仿真交互模型符合预期之后，在模型存储子阶段436，本申请实施例可将仿真交互模型存储到本地数据库中。例如，将仿真交互模型存储到chrome background中的indexedDB。

在版本建立阶段440，为了避免因线上环境频繁地迭代，导致构建的仿真交互模型也跟著快速迭代的窘境，本申请实施例提出了模型版本管理技术来解决业务稳定性的制约。

在一些实施例中，在提供仿真交互模型对应的仿真交互页面来实现用户的仿真交互的情况下，本申请实施例可通过页面快照技术来建立仿真交互模型的版本。作为一种可选实现，图6c示例性的示出了页面快照技术的实现示例图。结合图6c所示，页面快照技术可分为工具端部分和后端部分。在工具端部分，本申请实施例可以通过Fetch方法请求当前域名，来取得原始的HTML文本。这里的原始HTML文本指的是页面未经过document.write、以JS方式加载Script与link等资源前的页面内容。在一些实施例中，本申请实施例在仿真过程中可以将整个仿真页面（Web page）当做一个黑盒，因此获取原始的HTML文本是必要的。通过document.scripts对象，本申请实施例可以取得所有已加载的scripts，这些scripts中可能会包含部分非文件类型加载的脚本，因此需要通过过滤器（Filter Remote TypeScripts）进行过滤以取得真正的JS文件路径。另外，透过 document.links对象，可以取得所有已加载的links标签，其中包含链接与CSS（Cascading Style Sheets，叠层样式表）资源。通过过滤器（Filter CSS links），本申请实施例可以将真正的CSS资源路径给过滤出来。最后，通过video、img、audio等标签，可以获取到图片、声音与视频的资源路径。

取得所有需要的路径与内容后，仿真前端可将路径与内容送往仿真服务器。仿真服务器可以根据文件路径去请求文件（Fetch Files）。由于JS与CSS中可能会包含路径信息，因此需要将内容进行扫描并替换路径信息为仿真服务器路径。最后，本申请实施例可以将所有文件存储到OSS（Object Storage Service，对象存储）中等待交互过程调用。

在完成版本建立后，本申请实施例可将indexedDB中存储的交互数据，仿真交互模型上传到仿真服务器。

在仿真建模的过程中，还有一个比较棘手的问题是如何捕捉应用程序的页面中的元素。因为真实环境中的元素往往是层层嵌套的，在不感知整个底层实践的情况下，要精准的确定触发互动请求的元素是相当困难的事情。基于此，本申请实施例提供了一套元素捕捉与展示的设计方案。图6d示出了页面的元素捕捉与展示示意图。该元素捕捉与展示可由仿真前端执行实现。

在一些实施例中，当仿真前端加载录制工具后，本申请实施例可在录制工具中选取元素。在可选实现中，仿真前端可通过监听光标（例如鼠标）事件，获取到光标的当前坐标。基于获取的当前坐标以及浏览器原生接口中的元素对应的坐标范围（elementFromPoint），本申请实施例可以确定出当前坐标对应的元素。

在确定当前坐标对应的元素后，本申请实施例可生成元素对应的路径(path）并进行存储。在一些实施例中，为了避免某些特殊情况中元素的ID 由随机数生成，本申请实施例可将基于元素的ID生成路径的功能关闭，而是基于元素的class（类型）、元素名来生成路径。此外，在threshold方面，由于官方建议的threshold为1000，目的是为了避免过多的nth-child导致路径变长，因此本申请实施例可将threshold改为1，主要原因在于使用nth-child来避免误判，例如在table list、ul等元素中，使用nth-child会比使用元素名或class更加保险。因此，在可选实现中，本申请实施例可基于元素的class以及元素名，或者基于元素的nth-child，来生成元素对应的路径。nth-child为元素选择器，用于匹配父元素中的子元素。

在确定元素的路径后，本申请实施例可将元素的路径上传到仿真服务器，以便后续调用。在调用元素的一些实施例中，前端可根据基于仿真服务器反馈的元素的路径反推元素，并取得元素实例。在取得元素实例后，前端并不能直接使用元素实例来操作交互事件，这是因为没办法保证所选取的元素必然是要触发交互操作的元素，例如，实际触发交互操作的元素是button（按钮）元素，但在选取元素时，可能选到的是跟button有着相同宽高、位置的父容器div。这个问题的解决方式有很多，例如可以透过下钻找到真正的button再记录下来，又或者可以直接下钻到底层再由浏览器的冒泡机制来触发到button，但这些方法都有风险，真正没有风险的作法是仿造用户行为来触发点击事件。因此本申请实施例将元素获取到后，通过getBoundingClientRect API来取得元素的边界，并藉由边界来获取到元素的中心点位，最后，在该中心点位上模拟鼠标点击事件来达成一个模拟点击的动作。其中，getBoundingClientRect可用于获取某个元素相对于视窗的位置集合。

在一些实施例中，本申请实施例可基于开源库来生成元素的路径。开源库例如finder，finder是一个专门用于将元素转换为路径的库。

在可选的应用示例中，本申请实施例构建的仿真交互模型可用于云计算平台，以通过云计算平台的能力来使得用户在仿真环境下实现沉浸式交互体验。

在一个可选示例中，当互联网服务提供方需要宣传、介绍新的应用程序，或者应用程序的新功能时，互联网提供方的运营人员可使用仿真前端打开用于构建仿真交互模型的构建页面。运营人员可基于新的应用程序的功能或者应用程序的新功能，在该构建页面输入仿真交互模型的脚本基本信息，然后点击录制按钮，以在运营人员使用新的应用程序或者应用程序的新功能时，仿真前端可录制下运营人员的真实交互数据。在一个示例中，图6e示例性的示出了介绍应用程序的收费功能如何开通的构建页面的示意图；例如，当应用程序新开通了收费功能，互联网服务提供方需向用户宣传、介绍该收费功能如何开通时，互联网服务提供方的运营人员可使用仿真前端打开相应的构建页面，然后点击录制按钮，从而仿真前端可在运营人员操作如何开通收费功能的过程中，通过劫持原生API来录制运营人员在开通收费功能的交互过程中的真实交互数据。进而，运营人员可在构建页面的下一步操作中，创建仿真交互模型的步骤、子步骤、运行操作和/或回滚操作、运行操作和/或回滚操作下的交互操作，并将仿真交互模型中的交互操作与录制的交互数据相关联，来实现构建仿真交互模型。进而，当互联网服务提供方邀请用户使用新的应用程序，或者应用程序的新功能时，用户可使用交互前端获取到仿真交互模型对应的仿真交互页面，在该仿真交互页面下基于引导执行交互操作，并实现不需调用接口的获取到交互数据，实现对用户使用新的应用程序，或者应用程序的新功能时的交互引导。

在一些实施例中，上述所指的互联网服务提供方可以是大数据服务提供方、云计算服务提供方。大数据服务提供方可通过大数据平台向用户提供多个应用程序的服务，即多个应用程序的服务提供可基于大数据平台实现，本申请实施例构建的仿真交互模型可在大数据平台的多个应用程序的交互引导中进行通用。例如，仿真交互模型可由多个剧本构成，一个剧本视为是一个应用程序。在另一些实施例中，上述所指的互联网提供方也可以是单一应用程序的服务提供方。在一个应用示例中，本申请实施例所指的应用程序可以是针对B端（企业端）的应用程序，例如大数据平台可以是针对B端提供服务的大数据平台，即大数据平台可以提供多个针对B端提供服务的应用程序产品。

在一些实施例中，本申请实施例可支持针对新用户体验应用程序提供交互引导，也可支持针对老用户体验应用程序的新功能提供交互引导。在可选实现上，由于仿真交互模型是互联网服务提供方的技术人员基于与应用程序的交互过程进行构建，因此针对新用户与老用户进行交互引导使用的交互数据来源可以相同，例如均是基于互联网服务提供方的技术人员的数据录制。

本申请实施例提供的仿真交互模型的构建方案以数据采集、仿真建模与建立版本为关键阶段；其中数据采集阶段通过对真实交互环境的交互数据进行采集并存储到仿真服务器中，解决了沉浸式交互体验过程中可能调用真实接口导致的接口安全、接口鉴权等问题，也因此不会产生边际效应。进一步的，本申请实施例可在仿真建模过程采用可视化方式进行，通过Chrome Content Script在页面中加载建模工具并进行录制，大幅降低了建模成本。进一步，本申请实施例可以Chrome扩展程序为基础进行仿真建模，从而使得仿真建模能够支持浏览器端实现，并且建模方式的设计考虑了互动过程，将模型拆解为剧本、步骤、子步骤以及交互操作，辅以元素捕捉方案达到仿真环境下可互动的能力。进一步，本申请实施例提出了仿真交互模型的版本管理方案，解决了在沉浸式交互体验中因应用程序的快速迭代而导致仿真交互模型必须一起迭代的问题。

下面对本申请实施例提供的交互方法进行介绍。下文描述的交互方法可基于上文构建的仿真交互模型实现。作为一种可选实现，图7a示出了本申请实施例提供的交互方法的可选流程。该交互方法可由交互前端执行实现。交互前端可以认为是用于进行用户交互的客户端。如图7a所示，该流程可以包括如下步骤。

在步骤S710中，展示仿真交互模型对应的仿真交互页面。

在步骤S711中，在所述仿真交互页面检测当前交互操作，所述当前交互操作由仿真交互模型提供。

在步骤S712中，调用与所述当前交互操作关联的交互数据，并在所述仿真交互页面展示相应的交互效果，所述交互数据为预先获取的使用者与应用程序的交互数据。

基于本申请实施例提供的交互方法，交互前端可在用户使用应用程序时进行交互引导。首先，交互前端可从仿真服务器获取仿真交互模型对应的仿真交互页面。在一些实施例中，该仿真交互页面可以展示供执行交互操作的对象（例如元素），且仿真交互页面中可进行的交互操作由仿真交互模型提供，并与仿真服务器中存储的预先获取的交互数据相关联；从而当交互前端检测到仿真交互页面执行的当前交互操作时，交互前端可从仿真服务器调取该当前交互操作对应的预先获取的交互数据（例如，调取当前交互操作对应的预先获取的交互请求及相应的交互响应数据），并在所述仿真交互页面展示相应的交互效果，以实现对仿真交互页面执行的当前交互操作进行响应和效果展示。

在一些实施例中，如果仿真交互模型（例如剧本）下包括多个步骤，且每个步骤下包括多个子步骤，每个子步骤下又可包括运行操作和回滚操作，且所述运行操作和回滚操作分别包括多个交互操作；则在进行交互引导时，所述运行操作可通过多个交互操作介绍或者引导使用应用程序的功能，例如，交互前端在引导用户使用应用程序的表单时，可通过介绍表单的运行操作包含的多个交互操作，引导用户进行选中表单、展开表单、高亮表单、输入范例值等交互操作。而所述回滚操作可以发生在用户的交互操作出现错误等情况下，所述回滚操作可通过多个交互操作回溯发生交互错误的交互操作或者上一交互操作。在一些实施例中，回滚操作有别于运行操作，回滚操作包含的交互操作可单独定义；因为仿真互动不像播放影片，仿真互动不具有可逆性，无法使用运行操作来进行回溯。举例来说，当执行了一个查询表单的交互操作后，它的回溯就可能是清空表单、清空查询条件，而这是从查询表单的交互操作中无法获得的信息。

在一些实施例中，交互前端可提示用户需要执行的当前交互操作或者自动执行当前交互操作。结合图7b所示的交互实现示意图，在交互前端提示用户需要执行当前交互操作或者自动执行当前交互操作时，当前交互操作可被交互前端加载；之后交互前端可进入初始化状态，以将执行当前交互操作的执行环境准备好，例如修改当前交互操作的ID到url列上、清空上一个交互操作的缓存、等待下一个交互操作的对象出现等。然后，交互前端可在仿真交互页面，突出展示当前交互操作对应的对象（例如高亮展示当前交互操作涉及的元素），并绑定相应的响应监听器，以监听响应事件完成的状态。在当前交互操作自动执行或者用户手动执行后，响应事件被触发，当前交互操作就算执行完成，交互前端可调取到相应的交互数据并进行效果展示。然后，交互前端可解绑对应的监听响应事件完成检测监听。进一步，交互前端还可绑定一个计时器来计时当前交互操作的完成时间，以支持定时完成交互操作的功能。在上述过程中，若有任一个执行失败，则交互前端可进入到回滚操作环节以进行操作回溯。

需要说明的是，本申请实施例可基于配置来决定当前交互操作是由交互前端主动触发还是等待用户手动触发。

在一些实施例中，本申请实施例也可支持对用户使用交互引导进行收费，例如B端的企业在使用某一应用程序或者大数据平台提供的应用程序时，本申请实施例可提供应用程序的交互引导，并在进行交互引导的仿真交互页面提供交互引导需要的收费信息。

在一些实施例中，本申请实施例可基于不同的业务类型，设置不同的数据库或者数据模块，一个业务类型下预先获取的交互数据可以存储在该业务类型相应的数据库中；例如，在预先获取使用者与应用程序的交互数据之后，可将预先获取的交互数据存储在与应用程序的业务类型相应的数据库中。从而在构建某一业务类型对应的仿真交互模型之后，针对该业务类型下的用户交互引导，本申请实施例可通过该业务类型对应的仿真交互模型提供该业务类型下的交互操作，并将该业务类型下的交互操作与该业务类型相应的数据库中存储的交互数据进行关联。进而，用户在基于该业务类型对应的仿真交互模型执行了某一交互操作之后，本申请实施例可从该业务类型对应的数据库中调用到交互操作相关联的交互数据，以实现在该业务类型下的用户交互引导。例如，仿真交互模型提供的交互操作用于：从应用程序的业务类型相应的数据库中，调用预先获取的交互数据。通过这样的设置，本申请实施例可针对不同的业务类型，设置不同的数据库以存储不同业务类型下预先获取的交互数据，从而用户在执行某一业务类型的交互操作时，本申请实施例可从相应的数据库中调用到关联的预先获取的交互数据，以支持不同业务类型的用户的交互引导。

本申请实施例在仿真交互页面执行交互操作后，交互操作对应的交互数据并不是通过真实的交互接口获取，而是从仿真服务器调取。因此本申请实施例在基于仿真交互模型实现用户交互的过程中，能够降低沉浸式交互体验的实现成本，并且可在多个应用程序间通用。

上文描述了本申请实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本申请实施例披露、公开的实施例方案。

下面对本申请实施例提供的仿真交互模型构建装置进行介绍，下文描述的装置内容可以认为是模型构建设备（模型构建设备可以是仿真前端也可以是仿真服务器），为实现本申请实施例提供的仿真交互模型构建方法，所需设置的功能模块。下文描述的装置内容可与上文描述内容相互对应参照。

作为一种可选实现，图8a示出了本申请实施例提供的仿真交互模型构建装置的可选框图。该仿真交互模型构建装置可应用于模型构建设备。所述模型构建设备可以是仿真前端，也可能是仿真服务器，具体可视技术配置而定。如图8a所示，该装置可以包括：

数据获取模块810，用于预先获取使用者与应用程序的交互数据；

模型构建模块811，用于至少基于所述交互数据构建仿真交互模型，其中，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；

页面生成模块812，用于生成所述仿真交互模型对应的用于用户交互的仿真交互页面。

在一些实施例中，所述仿真交互模型为剧本，所述剧本包括步骤，所述步骤包括子步骤，所述子步骤包括运行操作和/或回滚操作，所述运行操作和/或回滚操作包括多个交互操作；所述运行操作通过多个交互操作介绍或者引导使用应用程序的功能，所述回滚操作通过多个交互操作回溯发生交互错误的交互操作或者上一交互操作。

在一些实施例中，模型构建模块811，用于至少基于所述交互数据构建仿真交互模型包括：

基于使用者与应用程序的交互场景创建剧本下的步骤；

创建步骤下的子步骤，所述子步骤包括运行操作和/或回滚操作；

创建运行操作和/或回滚操作下的多个交互操作，以使得所述仿真交互模型提供交互操作。

在一些实施例中，所述交互数据包括交互请求以及对应的交互响应数据；所述仿真交互模型提供的交互操作用于调用预先获取的交互数据包括：

所述仿真交互模型提供的交互操作用于，调用预先获取的所述交互请求以及对应的交互响应数据。

在进一步的一些实施例中，该装置还可通过设置功能模块，进一步用于：

获取仿真交互模型的脚本基本信息，所述脚本基本信息包括：仿真交互模型的名称、交互使用的应用程序、应用程序的交互场景。

在一些实施例中，模型构建模块811，用于基于用户与应用程序的交互场景创建剧本下的步骤包括：

基于所述脚本基本信息中的交互场景，创建剧本下的步骤。

在一些实施例中，数据获取模块810，用于预先获取使用者与应用程序的交互数据包括：

进入录制环境，触发刷新使用者与应用程序进行交互的页面；

在页面重新加载前，劫持用于交互请求的原生接口；

基于劫持的原生接口发送交互请求，并捕获与所述交互请求对应的交互响应数据。

在一些实施例中，数据获取模块810，用于在页面重新加载前，劫持用于交互请求的原生接口包括：

在页面重新加载之前，在仿真前端的本地存储中写入标签，以通知仿真前端需要启用注入器来在原生接口注入撷取器；

在页面重新加载时，加载注入器；所述注入器基于在本地存储中检测到的所述标签启动撷取器，以将撷取器注入原生接口。

在一些实施例中，该装置还可通过设置一个或多个功能模块，进一步用于：

将交互数据中的交互请求拆解为多个请求参数；基于所述多个请求参数、仿真互动模型的标识、所述交互请求对应的交互操作的ID，生成所述交互数据的唯一标识；

和/或，通过监听光标事件，获取光标的当前坐标；基于当前坐标以及元素对应的坐标范围，确定当前坐标对应的元素；基于元素的类型以及元素名，或者基于元素的元素选择器，生成元素对应的路径；

和/或，将交互数据存储到本地数据库；

和/或，试运行仿真交互模型，在仿真交互模型试运行成功后，将仿真交互模型存储到本地数据库；

和/或，将本地数据库中的交互数据，以及仿真交互模型上传到仿真服务器；

和/或，基于页面快照技术建立仿真交互模型的版本。

上述示出的功能可部署在一个功能模块或者分别部署在多个功能模块，该多个功能模块的功能可以交叉。

在一些实施例中，所述应用程序由大数据平台提供，且所述大数据平台提供多个应用程序；所述仿真交互模型支持对多个应用程序进行交互引导，一个应用程序对应仿真交互模型的一个剧本，且所述仿真交互模型包括多个剧本，一个剧本下包括一个或多个步骤。

本申请实施例还提供一种模型构建设备，该模型构建设备可以是仿真前端，也可以是仿真服务器。该模型构建设备可以装载上述所述的仿真交互模型构装置，以实现本申请实施例提供的仿真交互模型构建方法。在一些实施例中，图8b示出了本申请实施例提供的模型构建设备的可选框图。如图8b，所述该模型构建设备可以包括：至少一个处理器1，至少一个通信接口2，至少一个存储器3和至少一个通信总线4。

在本申请实施例中，处理器1、通信接口2、存储器3、通信总线4的数量为至少一个，且处理器1、通信接口2、存储器3通过通信总线4完成相互间的通信。

可选的，通信接口2可以为用于进行网络通信的通信模块的接口。

可选的，处理器1可能是CPU（中央处理器），GPU（Graphics Processing Unit，图形处理器），NPU（嵌入式神经网络处理器），FPGA（Field Programmable Gate Array，现场可编程逻辑门阵列），TPU（张量处理单元），AI芯片，特定集成电路ASIC（Application SpecificIntegrated Circuit），或者是被配置成实施本申请实施例的一个或多个集成电路等。

存储器3可能包含高速RAM存储器，也可能还包括非易失性存储器（non-volatilememory），例如至少一个磁盘存储器。

其中，存储器3存储一条或多条计算机可执行指令，处理器1调用所述一条或多条计算机可执行指令，以执行本申请实施例提供的仿真交互模型构建方法。

本申请实施例还提供一种存储介质，该存储介质可以存储一条或多条计算机可执行指令，该一条或多条计算机可执行指令被执行时可实现本申请实施例提供的仿真交互模型构建方法。

下面对本申请实施例提供的交互装置进行介绍，下文描述的装置内容可以认为是交互前端为实现本申请实施例提供的交互方法，所需设置的功能模块。下文描述的装置内容可与上文描述内容相互对应参照。

作为一种可选实现，图8c示出了本申请实施例提供的交互装置的可选框图。如图8c所示，该装置可以包括：

页面展示模块820，用于展示仿真交互模型对应的仿真交互页面；

操作检测模块821，用于在所述仿真交互页面检测当前交互操作，所述当前交互操作由仿真交互模型提供；

数据调取及展示模块822，用于调用与所述当前交互操作关联的交互数据，并在所述仿真交互页面展示相应的交互效果，所述交互数据为预先获取的使用者与应用程序的交互数据。

在一些实施例中，所述仿真交互模型为剧本，所述剧本包括步骤，所述步骤包括子步骤，所述子步骤包括运行操作和/或回滚操作，所述运行操作和/或回滚操作包括多个交互操作；所述运行操作通过多个交互操作介绍或者引导使用应用程序的功能，所述回滚操作通过多个交互操作回溯发生交互错误的交互操作或者上一交互操作；所述在仿真交互页面检测到的当前交互操作为运行操作或者回滚操作下的交互操作；

操作检测模块在所述仿真交互页面检测当前交互操作之前，该装置还可进一步设置功能模块，以进一步用于：

加载当前交互操作并进入初始化状态，以准备执行当前交互操作的执行环境；

在仿真交互页面，突出展示当前交互操作对应的对象，并绑定相应的响应监听器，以监听响应事件完成的状态；

其中，所述当前交互操作可自动执行或者由用户手动执行。

本申请实施例还提供一种交互前端，该交互前端可通过装载上述描述的交互装置，以实现本申请实施例提供的交互方法。该交互前端的可选结构可结合图8b所示，包括：至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行本申请实施例提供的交互方法。

本申请实施例还提供一种存储介质，该存储介质可以存储一条或多条计算机可执行指令，该一条或多条计算机可执行指令被执行时实现本申请实施例提供的交互方法。

本申请实施例还提供一种程序，该程序被电子设备（例如模型构建设备或者交互前端）执行时，实现如本申请实施例提供的仿真交互模型构建方法，或者，如本申请实施例提供的的交互方法。

虽然本申请实施例披露如上，但本申请并非限定于此。任何本领域技术人员，在不脱离本申请的精神和范围内，均可作各种更动与修改，因此本申请的保护范围应当以权利要求所限定的范围为准。

Claims (11)

1.一种仿真交互模型构建方法，其中，所述方法包括：

预先获取使用者与应用程序的交互数据；

至少基于所述交互数据构建仿真交互模型，所述仿真交互模型提供交互操作，所述交互操作与预先获取的交互数据相关联，以使得所述仿真交互模型提供的交互操作用于调用预先获取的交互数据；

生成所述仿真交互模型对应的用于用户交互的仿真交互页面；

所述预先获取使用者与应用程序的交互数据包括：进入录制环境，触发刷新使用者与应用程序进行交互的页面；在页面重新加载前，劫持用于交互请求的原生接口；基于劫持的原生接口发送交互请求，并捕获与所述交互请求对应的交互响应数据。

2.根据权利要求1所述的方法，其中，所述仿真交互模型包括步骤，所述步骤包括子步骤，所述子步骤包括运行操作和/或回滚操作，所述运行操作和/或回滚操作包括多个交互操作；所述运行操作通过多个交互操作介绍或者引导使用应用程序的功能，所述回滚操作通过多个交互操作回溯发生交互错误的交互操作或者上一交互操作；

所述至少基于所述交互数据构建仿真交互模型包括：

基于使用者与应用程序的交互场景创建剧本下的步骤；

创建步骤下的子步骤，所述子步骤包括运行操作和/或回滚操作；

创建运行操作和/或回滚操作下的多个交互操作，以使得所述仿真交互模型提供交互操作。

3.根据权利要求1所述的方法，其中，所述交互数据包括交互请求以及对应的交互响应数据；所述仿真交互模型提供的交互操作用于调用预先获取的交互数据包括：

所述仿真交互模型提供的交互操作用于，调用预先获取的所述交互请求以及对应的交互响应数据；

所述方法还包括：

获取仿真交互模型的脚本基本信息，所述脚本基本信息包括：仿真交互模型的名称、交互使用的应用程序、应用程序的交互场景；

所述基于使用者与应用程序的交互场景创建剧本下的步骤包括：

基于所述脚本基本信息中的交互场景，创建剧本下的步骤。

4.根据权利要求1所述的方法，其中，所述在页面重新加载前，劫持用于交互请求的原生接口包括：

在页面重新加载之前，在仿真前端的本地存储中写入标签，以通知仿真前端需要启用注入器来在原生接口注入撷取器；

在页面重新加载时，加载注入器；所述注入器基于在本地存储中检测到的所述标签启动撷取器，以将撷取器注入原生接口。

5.根据权利要求1所述的方法，其中，所述方法还包括：

将交互数据中的交互请求拆解为多个请求参数；基于所述多个请求参数、仿真互动模型的标识、所述交互请求对应的交互操作的ID，生成所述交互数据的唯一标识；

和/或，通过监听光标事件，获取光标的当前坐标；基于当前坐标以及元素对应的坐标范围，确定当前坐标对应的元素；基于元素的类型以及元素名，或者基于元素的元素选择器，生成元素对应的路径；

和/或，将交互数据存储到本地数据库；

和/或，试运行仿真交互模型，在仿真交互模型试运行成功后，将仿真交互模型存储到本地数据库；

和/或，将本地数据库中的交互数据，以及仿真交互模型上传到仿真服务器；

和/或，基于页面快照技术建立仿真交互模型的版本。

6.根据权利要求2所述的方法，其中，所述应用程序由大数据平台提供，且所述大数据平台提供多个应用程序；所述仿真交互模型支持对多个应用程序进行交互引导，一个应用程序对应仿真交互模型的一个剧本，且所述仿真交互模型包括多个剧本，一个剧本下包括一个或多个步骤。

7.一种交互方法，其中，所述方法包括：

展示仿真交互模型对应的仿真交互页面；

在所述仿真交互页面检测当前交互操作，所述当前交互操作由仿真交互模型提供；

调用与所述当前交互操作关联的交互数据，并在所述仿真交互页面展示相应的交互效果，所述交互数据为预先获取的使用者与应用程序的交互数据；

所述交互数据的预先获取过程包括：进入录制环境，触发刷新使用者与应用程序进行交互的页面；在页面重新加载前，劫持用于交互请求的原生接口；基于劫持的原生接口发送交互请求，并捕获与所述交互请求对应的交互响应数据。

8.根据权利要求7所述的方法，其中，所述仿真交互模型包括步骤，所述步骤包括子步骤，所述子步骤包括运行操作和/或回滚操作，所述运行操作和/或回滚操作包括多个交互操作；所述运行操作通过多个交互操作介绍或者引导使用应用程序的功能，所述回滚操作通过多个交互操作回溯发生交互错误的交互操作或者上一交互操作；所述在所述仿真交互页面检测到的当前交互操作为运行操作或者回滚操作下的交互操作；

所述在所述仿真交互页面检测当前交互操作之前，所述方法还包括：

加载当前交互操作并进入初始化状态，以准备执行当前交互操作的执行环境；

在仿真交互页面突出展示当前交互操作对应的对象，并绑定相应的响应监听器，以监听响应事件完成的状态；

其中，所述当前交互操作可自动执行或者由用户手动执行。

9.一种模型构建设备，其中，包括：至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如权利要求1-6任一项所述的仿真交互模型构建方法。

10.一种交互前端，其中，包括：至少一个存储器和至少一个处理器，所述存储器存储一条或多条计算机可执行指令，所述处理器调用所述一条或多条计算机可执行指令，以执行如权利要求7-8任一项所述的交互方法。

11.一种存储介质，其中，所述存储介质存储一条或多条计算机可执行指令，所述一条或多条计算机可执行指令被执行时实现如权利要求1-6任一项所述的仿真交互模型构建方法，或者，如权利要求7-8任一项所述的交互方法。

Images