具体实施方式

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

为了改善目前传统方式会降低自动化测试的有效性、稳定性、可维护性，以及会增加维护成本的技术问题。本实施例提供了一种端到端自动化测试方法，如图1所示，可应用于数据提供方(可指业务数据的实际生产方，数据的制造者)，该方法包括：

步骤101、接收测试所需数据的调用请求。

其中，调用请求中携带有查询条件信息。该调用请求可由数据使用方(可指业务数据的实际消费方，数据的依赖方)发送给数据提供方。查询条件信息中可包含该数据使用方执行端到端自动化测试所依赖数据的需求信息。

步骤102、从预设数据池中获取符合查询条件信息的可用数据。

其中，预设数据池中保存有定时通过调用端到端执行用例创建得到的各类业务数据。预设数据池具体可为数据库(Database，DB)，该预设数据池中的业务数据生成相当于端到端自动化测试的异步操作过程，不会影响端到端自动化测试的效率。

步骤103、返回获取到的可用数据，以便执行端到端自动化测试。

在获取到可用数据后，可返回给数据使用方，以便根据该可用数据执行端到端自动化测试。

本实施例提供的端到端自动化测试方法，与目前程序写死自动化测试所依赖的基础数据的方式相比，本实施例提供了一种更为快捷有效的方案，代替原来的写死方式。将端到端自动化中这些繁琐的数据准备步骤做解耦，化繁为简，减少相互依赖，降低依赖数据构建的成本和复杂度。数据提供方通过本申请方案配置数据基础信息，进而驱动各类业务数据准备的端到端用例执行，将这些测试所需调用的基础数据在预设数据池中暂存下来，并提供通用的获取数据服务，供各业务的数据使用方快速获取符合查询条件信息的可用数据，从而实现端到端自动化测试。本实施例可提高自动化测试的有效性、稳定性和可维护性，以及会降低后续的维护成本。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的实施方式，本实施例还提供了另一种可用于数据提供方的端到端自动化测试方法，如图2所示，该方法包括：

步骤201、获取数据生成的配置信息。

可选的，配置信息包括：数据的工厂配置、标签配置、脚本配置。在本实施例中，为了实现在预设数据池中准确生成各类业务数据，可预先执行脚本管理和数据管理。其中，脚本管理具体可分为工厂配置、标签配置、脚本配置三步骤。

工厂配置：支持新增/修改/删除。用于定义该工厂所代表的业务线是什么、数据owner是谁。便于后续数据使用方可以快速定位所需数据的出处，是一种“域”的概念。

标签配置：基于工厂维度，用于定义该工厂(业务)内有哪些种类的数据，标签支持多选。主要分为标签key、标签名称和标签枚举，键值对(key-value)结构【标签key(标签名称)：标签枚举】。

标签key：与标签名称一一对应，代表一类标签的【统称】或【类型】，英文解释。

标签名称：与标签key一一对应，代表一类标签的【统称】或【类型】，中文解释。

标签枚举：每个标签枚举内可以定义多个【标签内容】，代表某种具体业务含义。标签间最好业务语义独立，没有交集。每种类型的标签名称下只能选择一个标签。标签可以组合，不同种类的标签组合起来，代表某种具体的【业务场景】。

脚本配置：基于工厂维度，用于定义该工厂(业务)的数据创建端到端脚本生成出的数据有哪些标签特性，数据与标签是1：N的关系，一条业务数据可以有同时多个标签。

对于数据管理，在数据提供方，基于本实施例方法，可提供一种端到端测试平台(KBT)，可通过用户编写脚本的方式实现同/异步接口调用。端到端测试平台的页面操作，支持新增/修改/删除等，主要针对业务数据处理，有权限管控，可仅支持数据owner操作。

可选的，管理的数据类型可分为“动态”、“静态”。即预设数据池中保存有各类业务的静态数据和动态数据，其中，静态数据可反复使用，动态数据可具有使用次数限制(具体可根据实际需求进行预先设置限制的次数阈值)。

具体的，动态数据：可由脚本配置中所定义的【端到端脚本】所生成，为了数据保鲜，优选的，每个动态数据可仅能使用一次，最大程度保证数据本身的可用性。比如，订单数据等。

静态数据：可以反复多次使用。比如，用户ID、门店、大库存长时间营销活动等。

在本实施例中，采用定时任务调度的方案，基于工厂维度，多线程处理创建各类业务数据(离线数据生成)并落地工厂数据库，即保存在预设数据池中。具体可执行步骤201至202所示的过程，其中，步骤201的获取数据生成的配置信息，即脚本管理中所定义的配置，工厂信息、数据生成脚本、数据标签等。

步骤202、根据获取到的配置信息，定时多线程调用端到端执行用例创建各类业务数据并保存在预设数据池中。

可选的，步骤202具体可包括：判断预设数据池中各类业务的有效数据的数据量是否符合预设不足条件；若存在有效数据的数据量符合预设不足条件的目标类型业务，则调用目标类型业务相应的端到端执行用例，创建目标类型业务的新数据并保存在预设数据池中。

对于本实施例，可先判断预设数据池中的有效数据是否达到阈值，所有的业务数据在脚本管理的配置中都有一个阈值设置，如默认为50，数据owner也可以自定义，避免无限的创建业务数据，造成浪费。只有使用后，可用业务数据不足阈值后，才会重新创建新数据。

示例性的，步骤202中根据配置信息，定时多线程调用端到端执行用例创建各类业务数据，具体可包括：执行脚本配置中的端到端脚本，生成各类业务的动态数据，并根据工厂配置中的数据工厂信息和标签配置中的数据标签信息，植入动态数据的上下文信息。

可选的，数据工厂信息具体可包括：业务线的标识、和/或数据负责方的标识，数据标签信息具体可包括：数据类型、和/或数据统称。

例如，调用端到端执行用例，使用脚本管理中所定义的数据生成脚本，调用KBT平台(即端到端平台)生成对应的业务数据，调用过程中需要在上下文信息中带入工厂对应的配置(工厂的主键，标签配置等)，此处为异步操作，后续需要监听KBT平台的执行结果消息。

示例性的，步骤202中保存在预设数据池中，具体可包括：根据成功生成的动态数据的上下文信息，将成功生成的动态数据保存在对应工厂的业务数据表中，并连带标记相对应的数据工厂信息和数据标签信息。

例如，在调用端到端执行用例之后，监听KBT平台的执行结果。如果调用失败，结束流程，等待下次定时任务的调度；如果调用成功，从调用结果中获取预植入的上下文信息，获得工厂的配置及标签信息等，将调用成功生成的业务数据落入工厂的业务数据表，并连带存入工厂信息及标签信息，以此明确这条数据属于什么业务，以及什么场景。

对于本实施例，通过执行步骤201至202所示的过程，可实现离线数据生成的过程，后续执行对生成的离线数据获取的过程，即执行步骤203至205

步骤203、接收测试所需数据的调用请求。

调用请求中携带有查询条件信息。在本实施例中可支持不同方式的调用(HTTP请求、API同步调用)，通过传入工厂及标签信息，来获取一条随机的业务数据，供后续业务端到端使用。

步骤204、从预设数据池中获取符合查询条件信息的可用数据。

可选的，步骤204具体可包括：首先对预设数据池中的业务数据进行有效数据检查；然后从预设数据池的有效数据中获取符合查询条件信息的可用数据。

示例性的，对预设数据池中的数据进行有效数据检查，具体可包括：对预设数据池中的业务数据进行入参检查和标签合法性检查。

例如，对于人参检查，可执行参数基础检查、非空、非数字等。对于标签合法性检查可通过与标签配置中的基础数据进行比对检查，是否有未定义的标签数据。通过这种检查方式，可避免获取无效数据，保证后续端到端自动化测试的准确性。

在经过入参检查和标签合法性检查之后，本实施例可开启事务，根据指定查询条件，获得批量可用数据(可开关控制数量)，可选的，查询条件信息具体可包括：所需调用数据的目标工厂信息和目标标签信息。相应的，步骤204具体可包括：通过查询工厂的业务数据表，从预设数据池中获取与目标工厂信息和目标标签信息对应的可用数据。通过接口传入的工厂及标签数据，查询工厂业务数据表，获得状态“可用”的数据，此处需要开始事务，以防止并发等情况。

基于上述实施例内容，预设数据池中保存有各类业务的静态数据和动态数据。相应的，通过查询工厂的业务数据表，从预设数据池中获取与目标工厂信息和目标标签信息对应的可用数据，具体可包括：若该可用数据为静态数据，则直接获取该可用数据；若可用数据为动态数据，则根据可用数据的使用状态信息，判断可用数据的使用次数是否超出其对应的使用次数限制，如果使用次数未超出其对应的使用次数限制，则获取该可用数据。

优选的，为了数据保鲜，使用次数限制可为最多使用一次，预设数据池中的动态数据被获取后其使用状态变更为已使用状态；相应的，根据可用数据的使用状态信息，判断可用数据的使用次数是否超出其对应的使用次数限制，具体可包括：若可用数据的使用状态为未使用状态，则判定使用次数未超出其对应的使用次数限制。

进一步可选的，可基于乐观锁机制，通过预设数据池中数据的使用状态信息更新，限制多个数据请求方同时请求调用同一条业务数据。

例如，判断符合查询条件信息的可用数据的类型，是否为“静态”数据。其中，静态数据，代表可以反复使用，直接返回对应的业务数据即可。而符合查询条件信息的可用数据为动态数据时，可逐笔操作，尝试更新为“已使用”。采用乐观锁机制，避免并发调用，获取了同一条业务数据。乐观锁的条件是状态“未使用”，如果数据池DB更新操作的结果：条数为1，则表示更新成功，将对应业务数据返回，结束流程。条数为0，则表示更新失败，出现了并发情况，继续循环下一笔业务数据，直到全部从数据库中查询出的业务数据全部使用完成，如果还未获取数据，则返回失败。

步骤205、返回获取到的可用数据，以便执行端到端自动化测试。

目前除了程序写死自动化测试所依赖的基础数据的方式以外，在实际被测业务脚本执行前，先执行依赖数据的创建脚本，动态创建完数据后将对应的值传给被测脚本，动态替换后开始实际业务测试。这种方式缺点包括：a、脚本数量增多，整体自动化测试的稳定性和成功率低。一般一个依赖数据的脚本需要两个(执行脚本+验证脚本)，如3个依赖数据就是6个脚本，不同的脚本依赖不同的系统，不同的调用链路，增加脚本意味着增加失败的风险。b、脚本依赖方变多，可维护性差。依赖数据的生成脚本，通常都不是本业务负责的同学维护，通常都是不同“数据提供方”编写的脚本，随“数据提供方”的业务变更或系统变更可能发生脚本的变化。由于使用了这些依赖数据的脚本，导致本业务的测试人员也需要感知依赖数据业务或系统的变更，而操作相应脚本的更新动作。

本实施例方案提出了一种更为快捷有效的方法，利用类似“数据池DB”的概念。致力于将端到端自动化中这些繁琐的数据准备步骤做解耦，化繁为简，减少相互依赖，降低依赖数据构建的成本和复杂度。“数据提供方”通过本平台配置数据基础信息，由平台驱动各数据准备的端到端用例执行，将这些基础数据暂存下来，并由平台提供通用的获取数据服务，供各业务的“数据使用方”快速获取。以此解决“链路长”，“环境不稳定”，“脚本相互依赖”等带来的困扰。

上述实施例内容为在数据提供方的端侧描述的端到端自动化测试过程，进一步的，为了完整说明本实施例的实施方式，本实施例还提供了又一种端到端自动化测试方法，可应用于数据使用方，如图3所示，该方法包括：

步骤301、发送测试所需数据的调用请求，调用请求中携带有查询条件信息。

进一步的，以使得数据提供方从预设数据池中获取符合查询条件信息的可用数据。其中，预设数据池中保存有定时通过调用端到端执行用例创建得到的各类业务数据。

数据提供方的数据处理过程可参照如图1和图2所示方法的对应描述，在此不再赘述。

步骤302、接收返回的可用数据。

数据提供方将预设数据池中符合查询条件信息的可用数据返回给数据使用方。

步骤303、根据返回的可用数据，执行端到端自动化测试。

数据使用方通过预先设置的自动化测试脚本，利用得到的可用数据执行端到端自动化测试。

为了方便理解上述各实施例方法的具体实现过程，给出如下应用场景示例，但不限于此：

如图4所示，为一种示例的业务架构。商品数据、店铺数据、订单数据等为端到端测试所依赖的基础数据。比如测试一笔订单处理的流程，需要依赖商品、店铺、活动等等前置数据。利用本实施例提供的方案可实现配置管理、数据生成、数据获取、数据列表、数据订正、数据清洗、水位监测(数据量监测)等。具体的流程示意图如图5所示，图5中的离线数据生成(数据池中的数据生成)以及离线数据获取(数据池中的数据获取)可为本实施例方案的主要创新内容。其中，离线数据生成的时序图可如图6所示，离线数据获取的时序图可如图7所示。

本实施例方案提出了一种快捷有效的方法，利用类似“业务数据池DB”的概念。致力于将端到端自动化中这些繁琐的数据准备步骤做解耦，化繁为简，减少相互依赖，降低依赖数据构建的成本和复杂度。“数据提供方”通过本平台配置数据基础信息，由平台驱动各数据准备的端到端用例执行，将这些基础数据暂存下来，并由平台提供通用的获取数据服务，供各业务的“数据使用方”的业务端到端脚本快速获取所依赖的业务数据。此方案将业务数据构建的流程做了解耦，既通过平台提供的基础能力，数据使用方可以根据一定条件(工厂信息及标签信息)动态获取所依赖的业务数据，避免了“写死”业务数据带来的维护性差的问题，又通过该能力，解耦了数据供需两方间的依赖问题，“数据使用方”无需再感知“数据提供方”的各种业务数据创建脚本，不用再担心因为“数据提供方”的业务变化带来的脚本维护成本，也不用担心因为业务数据创建脚本的链路问题造成自身业务自动化的成功率下降，解决了“链路长”，“环境不稳定”，“脚本相互依赖”的问题。

进一步的，作为图1和图2所示方法的具体实现，本实施例提供了一种可应用于数据提供方的端到端自动化测试装置，如图8所示，该装置包括：接收模块41、获取模块42、发送模块43。

接收模块41，用于接收测试所需数据的调用请求，所述调用请求中携带有查询条件信息；

获取模块42，用于从预设数据池中获取符合所述查询条件信息的可用数据，其中，所述预设数据池中保存有定时通过调用端到端执行用例创建得到的各类业务数据；

发送模块43，用于返回获取到的所述可用数据，以便执行端到端自动化测试。

在具体的应用场景中，本装置还包括：创建模块；

获取模块42，还用于获取数据生成的配置信息；

创建模块，用于根据所述配置信息，定时多线程调用端到端执行用例创建各类业务数据并保存在所述预设数据池中。

在具体的应用场景中，可选的，所述配置信息包括：数据的工厂配置、标签配置、脚本配置；创建模块，具体用于执行所述脚本配置中的端到端脚本，生成各类业务的动态数据，并根据所述工厂配置中的数据工厂信息和所述标签配置中的数据标签信息，植入所述动态数据的上下文信息。

在具体的应用场景中，可选的，所述数据工厂信息包括：业务线的标识、和/或数据负责方的标识，所述数据标签信息包括：数据类型、和/或数据统称。

在具体的应用场景中，创建模块，具体还用于根据成功生成的所述动态数据的上下文信息，将成功生成的所述动态数据保存在对应工厂的业务数据表中，并连带标记相对应的数据工厂信息和数据标签信息。

在具体的应用场景中，创建模块，具体还用于判断所述预设数据池中各类业务的有效数据的数据量是否符合预设不足条件；若存在有效数据的数据量符合所述预设不足条件的目标类型业务，则调用所述目标类型业务相应的端到端执行用例，创建所述目标类型业务的新数据并保存在所述预设数据池中。

在具体的应用场景中，可选的，所述查询条件信息包括：所需调用数据的目标工厂信息和目标标签信息；

获取模块42，具体用于通过查询工厂的业务数据表，从预设数据池中获取与所述目标工厂信息和目标标签信息对应的可用数据。

在具体的应用场景中，可选的，所述预设数据池中保存有各类业务的静态数据和动态数据，其中，所述静态数据可反复使用，所述动态数据具有使用次数限制；

获取模块42，具体还用于若所述可用数据为静态数据，则直接获取所述可用数据；若所述可用数据为动态数据，则根据所述可用数据的使用状态信息，判断所述可用数据的使用次数是否超出其对应的使用次数限制，如果所述使用次数未超出其对应的使用次数限制，则获取所述可用数据。

在具体的应用场景中，可选的，所述使用次数限制为最多使用一次，所述预设数据池中的动态数据被获取后其使用状态变更为已使用状态；

获取模块42，具体还用于若所述可用数据的使用状态为未使用状态，则判定所述使用次数未超出其对应的使用次数限制。

在具体的应用场景中，本装置还包括：限制模块；

限制模块，用于基于乐观锁机制，通过所述预设数据池中数据的使用状态信息更新，限制多个数据请求方同时请求调用同一条业务数据。

在具体的应用场景中，获取模块42，具体还用于对所述预设数据池中的业务数据进行有效数据检查；从所述预设数据池的有效数据中获取符合所述查询条件信息的可用数据。

在具体的应用场景中，获取模块42，具体还用于对所述预设数据池中的业务数据进行入参检查和标签合法性检查。

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

进一步的，作为图3所示方法的具体实现，本申请实施例提供了一种可应用于数据使用方的端到端自动化测试装置，如图9所示，该装置包括：发送模块51、接收模块52、测试模块53。

发送模块51，用于发送测试所需数据的调用请求，所述调用请求中携带有查询条件信息，以使得从预设数据池中获取符合所述查询条件信息的可用数据，其中，所述预设数据池中保存有定时通过调用端到端执行用例创建得到的各类业务数据；

接收模块52，用于接收返回的所述可用数据；

测试模块53，用于根据所述可用数据，执行端到端自动化测试。

需要说明的是，本实施例提供的一种可应用于数据使用方的端到端自动化测试装置所涉及各功能单元的其它相应描述，可以参考图3中方法的对应描述，在此不再赘述。

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

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

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

基于上述如图3所示的方法，以及图9所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了另一种电子设备，具体可以为个人计算机、服务器、智能终端、或其他网络设备等，该电子设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图3所示的方法。

可选的，上述两种实体设备都还可以包括用户接口、网络接口、摄像头、射频(Radio Frequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

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

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

基于上述内容，进一步的，本申请实施例还提供了一种端到端自动化测试系统，该系统包括数据提供方设备、数据使用方设备。

其中，数据提供方设备可用于执行如图1和图2所示的方法，数据使用方设备可用于执行如图3所示的方法。

具体的，数据使用方设备，可用于向数据提供方设备发送测试所需数据的调用请求，所述调用请求中携带有查询条件信息。

数据提供方设备，可用于接收数据使用方设备发送的接收测试所需数据的调用请求；从预设数据池中获取符合所述查询条件信息的可用数据，其中，所述预设数据池中保存有定时通过调用端到端执行用例创建得到的各类业务数据；返回获取到的所述可用数据。

数据使用方设备，还可用于接收数据提供方设备返回的所述可用数据；根据所述可用数据，执行端到端自动化测试。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本实施例的技术方案，可提高自动化测试的有效性、稳定性和可维护性，以及会降低后续的维护成本。

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

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