1. An end-to-end automated testing method, comprising:

receiving a call request of data required by a test, wherein the call request carries query condition information;

acquiring available data which accords with the query condition information from a preset data pool, wherein various service data which are obtained by calling an end-to-end execution case to establish at regular time are stored in the preset data pool;

and returning the acquired available data so as to execute the end-to-end automation test.

2. The method of claim 1, further comprising:

acquiring configuration information generated by data;

and calling an end-to-end execution case to create various service data in a timed and multi-thread manner according to the configuration information and storing the service data in the preset data pool.

3. The method of claim 2, wherein the configuration information comprises: factory configuration, label configuration and script configuration of data;

the regularly multi-threaded calling of the end-to-end execution case according to the configuration information to create various service data specifically comprises the following steps:

executing an end-to-end script in the script configuration, generating dynamic data of various services, and implanting context information of the dynamic data according to data factory information in the factory configuration and data label information in the label configuration.

4. The method of claim 3, wherein the data plant information comprises: an identification of a service line, and/or an identification of a data responsible party, the data tag information comprising: data type, and/or data as a whole.

5. The method according to claim 3, wherein the storing in the preset data pool specifically includes:

and according to the context information of the dynamic data which is successfully generated, storing the successfully generated dynamic data in a service data table of a corresponding factory, and connecting marked corresponding data factory information and data tag information.

6. An end-to-end automated testing method, comprising:

sending a call request of data required by testing, wherein the call request carries query condition information so as to acquire available data meeting the query condition information from a preset data pool, and various service data obtained by calling an end-to-end execution case to create regularly are stored in the preset data pool;

receiving the returned available data;

and executing end-to-end automation test according to the available data.

7. An end-to-end automated testing apparatus, comprising:

the receiving module is used for receiving a call request of data required by testing, and the call request carries query condition information;

the acquisition module is used for acquiring available data meeting the query condition information from a preset data pool, wherein various service data obtained by calling an end-to-end execution use case to establish at regular time are stored in the preset data pool;

and the sending module is used for returning the acquired available data so as to execute the end-to-end automation test.

8. An end-to-end automated testing apparatus, comprising:

the system comprises a sending module, a receiving module and a processing module, wherein the sending module is used for sending a call request of data required by testing, the call request carries query condition information so as to obtain available data meeting the query condition information from a preset data pool, and various service data obtained by calling an end-to-end execution case to create regularly are stored in the preset data pool;

the receiving module is used for receiving the returned available data;

and the test module is used for executing end-to-end automatic test according to the available data.

9. A storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method of any of claims 1 to 6.

10. An electronic device comprising a storage medium, a processor and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the method of any one of claims 1 to 6 when executing the computer program.

Background

Automated testing generally refers to the automation of software testing, and is a process for converting human-driven testing behavior into machine execution. In the daily test and end-to-end automatic regression process, the software system often has the requirement and dependence on basic data, for example, the flow of testing an order processing needs to depend on the preposed data of commodities, shops, activities and the like.

At present, the traditional way is to write down the basic data on which the automation test depends during the end-to-end automation preparation phase. For example, some commodity data depended on by order processing is constructed manually before execution, and the commodity data is written in a script.

However, the data that is written out is easily damaged by other human or natural reasons, and needs to be replaced repeatedly, and the stability is poor, for example, the commodity database is cleared, or the commodity state is modified manually. And the maintenance cost is high, the maintainability is poor, for example, 3 data need to be written to death by one script, and 30 data can be exactly by 10 scripts, and the later maintenance and replacement cost is extremely high.

Disclosure of Invention

In view of the above, the present application provides an end-to-end automatic testing method, an end-to-end automatic testing device, and an electronic apparatus, and mainly aims to solve the technical problems that the conventional method reduces the effectiveness, stability, and maintainability of the automatic testing and increases the maintenance cost.

According to one aspect of the application, an end-to-end automatic testing method is provided, which is applicable to a data provider, and comprises the following steps:

receiving a call request of data required by a test, wherein the call request carries query condition information;

acquiring available data which accords with the query condition information from a preset data pool, wherein various service data which are obtained by calling an end-to-end execution case to establish at regular time are stored in the preset data pool;

and returning the acquired available data so as to execute the end-to-end automation test.

Optionally, the method further includes: acquiring configuration information generated by data; and calling an end-to-end execution case to create various service data in a timed and multi-thread manner according to the configuration information and storing the service data in the preset data pool.

Optionally, the configuration information includes: factory configuration, label configuration and script configuration of data;

the regularly multi-threaded calling of the end-to-end execution case according to the configuration information to create various service data specifically comprises the following steps: executing an end-to-end script in the script configuration, generating dynamic data of various services, and implanting context information of the dynamic data according to data factory information in the factory configuration and data label information in the label configuration.

Optionally, the data factory information includes: an identification of a service line, and/or an identification of a data responsible party, the data tag information comprising: data type, and/or data as a whole.

Optionally, the storing in the preset data pool specifically includes: and according to the context information of the dynamic data which is successfully generated, storing the successfully generated dynamic data in a service data table of a corresponding factory, and connecting marked corresponding data factory information and data tag information.

Optionally, the invoking an end-to-end execution case to create various service data according to the configuration information in a timed and multi-threaded manner and storing the service data in the preset data pool specifically includes: judging whether the data volume of the effective data of each service in the preset data pool meets preset shortage conditions or not; if the target type service with the data volume of the effective data meeting the preset insufficiency condition exists, calling an end-to-end execution case corresponding to the target type service, creating new data of the target type service and storing the new data in the preset data pool.

Optionally, the query condition information includes: target factory information and target label information of data to be called;

the acquiring available data meeting the query condition information from a preset data pool specifically includes: and acquiring available data corresponding to the target factory information and the target label information from a preset data pool by inquiring a service data table of a factory.

Optionally, static data and dynamic data of various services are stored in the preset data pool, where the static data may be used repeatedly, and the dynamic data has a limit on the number of times of use;

the acquiring, by querying a service data table of a factory, available data corresponding to the target factory information and the target tag information from a preset data pool specifically includes: if the available data is static data, directly acquiring the available data; if the available data is dynamic data, judging whether the use times of the available data exceed the corresponding use time limit according to the use state information of the available data, and if the use times do not exceed the corresponding use time limit, acquiring the available data.

Optionally, the number of times of use is limited to be used at most once, and the use state of the dynamic data in the preset data pool is changed into a used state after the dynamic data is acquired;

the determining, according to the use state information of the available data, whether the number of uses of the available data exceeds a corresponding number of uses limit, specifically including: and if the use state of the available data is the unused state, judging that the use times do not exceed the corresponding use time limit.

Optionally, the method further includes: and based on an optimistic locking mechanism, a plurality of data requesters are limited to simultaneously request to call the same service data by updating the use state information of the data in the preset data pool.

Optionally, the obtaining available data meeting the query condition information from a preset data pool specifically includes: performing effective data check on the service data in the preset data pool; and acquiring available data meeting the query condition information from the valid data of the preset data pool.

Optionally, the checking valid data of the data in the preset data pool specifically includes: and performing entry check and label validity check on the service data in the preset data pool.

According to another aspect of the present application, there is provided an end-to-end automated testing method, applicable to a data user, the method including:

sending a call request of data required by testing, wherein the call request carries query condition information so as to acquire available data meeting the query condition information from a preset data pool, and various service data obtained by calling an end-to-end execution case to create regularly are stored in the preset data pool;

receiving the returned available data;

and executing end-to-end automation test according to the available data.

According to another aspect of the present application, there is provided an end-to-end automatic testing apparatus, applicable to a data provider, the apparatus including:

the receiving module is used for receiving a call request of data required by testing, and the call request carries query condition information;

the acquisition module is used for acquiring available data meeting the query condition information from a preset data pool, wherein various service data obtained by calling an end-to-end execution use case to establish at regular time are stored in the preset data pool;

and the sending module is used for returning the acquired available data so as to execute the end-to-end automation test.

According to still another aspect of the present application, there is provided an end-to-end automatic test apparatus, which is applicable to a data user, the apparatus including:

the system comprises a sending module, a receiving module and a processing module, wherein the sending module is used for sending a call request of data required by testing, the call request carries query condition information so as to obtain available data meeting the query condition information from a preset data pool, and various service data obtained by calling an end-to-end execution case to create regularly are stored in the preset data pool;

the receiving module is used for receiving the returned available data;

and the test module is used for executing end-to-end automatic test according to the available data.

According to yet another aspect of the present application, there is provided a storage medium having stored thereon a computer program which, when executed by a processor, implements the above-described end-to-end automated testing method applicable to a data provider.

According to yet another aspect of the present application, there is provided an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, the processor implementing the above end-to-end automated testing method applicable to a data provider when executing the computer program.

According to yet another aspect of the present application, there is provided another storage medium having stored thereon a computer program which, when executed by a processor, implements the above-described end-to-end automated testing method applicable to a data consumer.

According to yet another aspect of the present application, there is provided an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, the processor implementing the above end-to-end automated testing method applicable to a data consumer when executing the computer program.

By means of the technical scheme, compared with the mode of basic data which is relied on by the existing program deadwriting automatic test, the end-to-end automatic test method, the end-to-end automatic test device and the electronic equipment provided by the application provide a faster and more effective scheme to replace the original deadwriting mode. The complex data preparation steps in the end-to-end automation are decoupled, the complexity is reduced, the mutual dependence is reduced, and the cost and the complexity of the construction of the dependent data are reduced. The data provider configures data basic information through the scheme of the application, further drives end-to-end case execution of various service data preparations, temporarily stores the basic data required to be called by the tests in a preset data pool, provides a universal data obtaining service, and enables data users of various services to quickly obtain available data meeting query condition information, thereby realizing end-to-end automatic tests. The method and the device can improve the effectiveness, stability and maintainability of the automatic test and reduce the subsequent maintenance cost.

The foregoing description is only an overview of the technical solutions of the present application, and the present application can be implemented according to the content of the description in order to make the technical means of the present application more clearly understood, and the following detailed description of the present application is given in order to make the above and other objects, features, and advantages of the present application more clearly understandable.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a schematic flow chart illustrating an end-to-end automated testing method provided by an embodiment of the present application;

FIG. 2 is a flow chart illustrating another end-to-end automated testing method provided by an embodiment of the present application;

FIG. 3 is a flow chart illustrating a further method for end-to-end automated testing provided by an embodiment of the present application;

FIG. 4 is a schematic diagram illustrating an application scenario service architecture provided by an embodiment of the present application;

FIG. 5 is a flowchart illustrating an application scenario provided by an embodiment of the present application;

FIG. 6 illustrates a timing diagram for offline data generation provided by embodiments of the present application;

FIG. 7 is a timing diagram illustrating offline data acquisition provided by embodiments of the present application;

FIG. 8 is a schematic structural diagram illustrating an end-to-end automated testing apparatus provided in an embodiment of the present application;

fig. 9 shows a schematic structural diagram of another end-to-end automatic testing apparatus provided in the embodiment of the present application.

Detailed Description

The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

The method aims to solve the technical problems that the traditional method reduces the effectiveness, stability and maintainability of the automatic test and increases the maintenance cost. The embodiment provides an end-to-end automated testing method, as shown in fig. 1, which is applicable to a data provider (which may refer to an actual producer of business data, a manufacturer of data), and the method includes:

step 101, receiving a call request of data required by a test.

The calling request carries query condition information. The invocation request may be sent by a data consumer (which may refer to an actual consumer of the business data, a relying party of the data) to a data provider. The query condition information may include requirement information of data on which the data user depends to perform the end-to-end automation test.

And 102, acquiring available data meeting the query condition information from a preset data pool.

The preset data pool stores various service data obtained by calling the end-to-end execution use case to establish at regular time. The preset data pool may be a Database (DB), and the generation of the service data in the preset data pool is equivalent to an asynchronous operation process of the end-to-end automation test, and does not affect the efficiency of the end-to-end automation test.

And step 103, returning the acquired available data so as to execute the end-to-end automation test.

After the available data is acquired, the data can be returned to a data user so as to execute end-to-end automation test according to the available data.

Compared with the conventional basic data mode on which the program crash automation test depends, the end-to-end automation test method provided by the embodiment provides a faster and more effective scheme to replace the conventional crash mode. The complex data preparation steps in the end-to-end automation are decoupled, the complexity is reduced, the mutual dependence is reduced, and the cost and the complexity of the construction of the dependent data are reduced. The data provider configures data basic information through the scheme of the application, further drives end-to-end case execution of various service data preparations, temporarily stores the basic data required to be called by the tests in a preset data pool, provides a universal data obtaining service, and enables data users of various services to quickly obtain available data meeting query condition information, thereby realizing end-to-end automatic tests. The embodiment can improve the effectiveness, stability and maintainability of the automatic test and reduce the subsequent maintenance cost.

Further, as a refinement and an extension of the specific implementation of the above embodiment, in order to fully illustrate the implementation of this embodiment, this embodiment further provides another end-to-end automated testing method that can be used for a data provider, as shown in fig. 2, where the method includes:

step 201, obtaining configuration information generated by data.

Optionally, the configuration information includes: factory configuration of data, tag configuration, script configuration. In this embodiment, in order to accurately generate various types of service data in the preset data pool, script management and data management may be performed in advance. The script management can be specifically divided into three steps of factory configuration, label configuration and script configuration.

Factory configuration: new/modified/deleted are supported. For defining what the service line represented by the factory is and who the data owner is. The method is a concept of 'domain', which is convenient for a subsequent data user to quickly locate the origin of the required data.

And (3) tag configuration: tags support multiple selection based on the plant dimension, which defines what kinds of data are within the plant (business). Mainly divided into label key, label name and label enumeration, key-value structure [ label key (label name): tag enumeration).

And (4) label key: corresponding to the label names one by one, representing the general name or type of a label, English explanation.

Label name: corresponding to the labels keys one by one, representing the Chinese explanation of the type of labels (general name) or the type).

Tag enumeration: within each tag enumeration may be defined a number [ tag content ], representing a particular business meaning. Preferably, the service semantics among the labels are independent and have no intersection. Only one tag can be selected under each type of tag name. The labels can be combined, and different kinds of labels are combined to represent a specific [ business scene ].

Script configuration: based on the dimension of the factory, the label characteristics of the data generated by the end-to-end script for data creation of the factory (business) are defined, and the data and the label are 1: n, a piece of business data may have multiple tags at the same time.

For data management, a data provider can provide an end-to-end test platform (KBT) based on the method of the embodiment, and the synchronous/asynchronous interface call can be realized in a way that a user writes a script. The page operation of the end-to-end test platform supports new addition/modification/deletion and the like, mainly aims at service data processing, has authority control and can only support data owner operation.

Alternatively, the types of data managed may be classified as "dynamic" or "static". That is, the preset data pool stores static data and dynamic data of various services, where the static data can be used repeatedly, and the dynamic data can have a use time limit (specifically, a time threshold for the limit can be preset according to actual needs).

Specifically, the dynamic data: can be generated by the defined end-to-end script in the script configuration, for data preservation, it is preferable that each dynamic data can be used only once, and the availability of the data is ensured to the maximum extent. Such as order data, etc.

Static data: can be repeatedly used. Such as user ID, store, long-term marketing campaigns with large inventory, etc.

In this embodiment, a scheme of scheduling a timed task is adopted, and based on the plant dimension, various types of service data (offline data generation) are created through multi-thread processing and are landed on a plant database, that is, stored in a preset data pool. The process shown in steps 201 to 202 may be specifically executed, wherein the configuration information generated by acquiring data in step 201, i.e. the configuration defined in the script management, the plant information, the data generation script, the data tag, and the like.

Step 202, calling the end-to-end execution case to create various service data in a timed and multi-threaded manner according to the acquired configuration information, and storing the service data in a preset data pool.

Optionally, step 202 may specifically include: judging whether the data volume of the effective data of each type of service in the preset data pool meets the preset shortage condition or not; if the target type service with the data volume of the effective data meeting the preset shortage condition exists, calling an end-to-end execution case corresponding to the target type service, creating new data of the target type service and storing the new data in a preset data pool.

For this embodiment, it may be determined whether valid data in the preset data pool reaches a threshold, and all service data have a threshold set in the configuration of script management, for example, default is 50, and the data owner may also be self-defined, so as to avoid creating service data indefinitely, which results in waste. Only after use, when the available service data is less than the threshold, new data is created again.

Illustratively, in step 202, according to the configuration information, regularly invoking multiple threads to create various service data by using an end-to-end execution case, which may specifically include: executing an end-to-end script in script configuration, generating dynamic data of various services, and implanting context information of the dynamic data according to data factory information in factory configuration and data label information in label configuration.

Optionally, the data factory information may specifically include: the identifier of the service line and/or the identifier of the data responsible party, and the data tag information may specifically include: data type, and/or data as a whole.

For example, an end-to-end execution case is called, a script is generated by using data defined in the script management, a KBT platform (i.e., an end-to-end platform) is called to generate corresponding service data, a configuration corresponding to a factory (a primary key of the factory, a tag configuration, etc.) needs to be brought into context information in the calling process, which is asynchronous operation, and an execution result message of the KBT platform needs to be monitored subsequently.

Illustratively, the step 202 of storing in the preset data pool may specifically include: and storing the successfully generated dynamic data in a service data table of the corresponding plant according to the context information of the successfully generated dynamic data, and marking the corresponding data plant information and the data tag information.

For example, after the end-to-end execution use case is called, the execution result of the KBT platform is monitored. If the calling fails, ending the process and waiting for the scheduling of the timing task next time; if the calling is successful, obtaining the pre-implanted context information from the calling result, obtaining the configuration and label information of the factory and the like, and enabling the business data generated by the successful calling to fall into a business data table of the factory and be stored with the factory information and the label information so as to determine the business and the scene of the data.

For the present embodiment, by performing the processes shown in steps 201 to 202, the process of generating offline data can be implemented, and then the process of acquiring the generated offline data, that is, performing steps 203 to 205

Step 203, receiving a call request of data required by the test.

The calling request carries query condition information. In this embodiment, calls in different modes (HTTP request, API synchronous call) can be supported, and a piece of random service data is obtained by transmitting factory and tag information, so as to be used end-to-end by subsequent services.

And step 204, acquiring available data meeting the query condition information from a preset data pool.

Optionally, step 204 may specifically include: firstly, carrying out effective data check on service data in a preset data pool; and then, obtaining available data which accords with the query condition information from the valid data of the preset data pool.

For example, the valid data check on the data in the preset data pool may specifically include: and performing entry check and label validity check on the service data in the preset data pool.

For example, for ginseng inspection, a parameter-based inspection, non-null, non-numeric, etc. may be performed. The validity check of the tag can check whether undefined tag data exists by comparing with the basic data in the tag configuration. By the checking mode, invalid data can be prevented from being acquired, and the accuracy of subsequent end-to-end automatic testing is ensured.

After the entry check and the tag validity check, the present embodiment may open transactions, and obtain available data (switchable quantity) in batches according to the specified query condition, optionally, the query condition information may specifically include: target factory information and target tag information of the data to be called. Correspondingly, step 204 may specifically include: and acquiring available data corresponding to the target factory information and the target label information from a preset data pool by inquiring a service data table of the factory. The factory and label data transmitted through the interface queries the factory business data table to obtain the data of the state 'available', and the transaction needs to be started here to prevent the concurrence and the like.

Based on the above embodiment, the preset data pool stores static data and dynamic data of various services. Correspondingly, by querying a service data table of the factory, available data corresponding to the target factory information and the target tag information is obtained from a preset data pool, which may specifically include: if the available data is static data, directly acquiring the available data; if the available data is dynamic data, judging whether the use times of the available data exceeds the corresponding use time limit according to the use state information of the available data, and if the use times does not exceed the corresponding use time limit, acquiring the available data.

Preferably, for data preservation, the use frequency limit may be at most once, and the use state of the dynamic data in the preset data pool is changed into the used state after the dynamic data is acquired; correspondingly, according to the usage status information of the available data, determining whether the usage number of the available data exceeds the usage number limit corresponding to the available data, specifically, the determining may include: and if the use state of the available data is the unused state, judging that the use frequency does not exceed the corresponding use frequency limit.

Further optionally, based on an optimistic lock mechanism, the data request parties are restricted from simultaneously requesting to call the same service data by updating the use state information of the data in the preset data pool.

For example, it is determined whether the type of available data that meets the query condition information is "static" data. Wherein, the static data can be repeatedly used, and the corresponding service data is directly returned. And when the available data meeting the query condition information is dynamic data, the data can be operated one by one, and the data is tried to be updated to be used. And an optimistic locking mechanism is adopted, so that concurrent calling is avoided, and the same service data is obtained. The condition of the optimistic lock is that the state is "unused", if the result of the data pool DB update operation: if the number of the data is 1, the updating is successful, the corresponding service data is returned, and the process is ended. If the number of the data is 0, the updating is failed, the concurrence condition is generated, the next service data is continuously circulated until all the service data inquired from the database are completely used, and if the data is not acquired, the failure is returned.

And step 205, returning the acquired available data so as to execute the end-to-end automation test.

At present, except for a mode of automatically testing basic data depended on by program dead writing, before an actual tested service script is executed, a data-dependent creating script is executed, a corresponding value is transmitted to the tested script after data is dynamically created, and the actual service test is started after dynamic replacement. Disadvantages of this approach include: a. the number of scripts is increased, and the stability and the success rate of the whole automatic test are low. Generally, two scripts (execution script + verification script) are needed for one data-dependent script, for example, 6 scripts are needed for 3 data-dependent scripts, different scripts depend on different systems, different call links, and adding scripts means increasing the risk of failure. b. The script has more dependent parties and poor maintainability. The generation scripts depending on the data are not generally the classmate maintenance which is responsible for the business, but are generally scripts written by different data providers, and the scripts can change along with the business change or system change of the data providers. Due to the use of the data-dependent scripts, the tester of the service also needs to sense the change of the data-dependent service or the system and operate the update action of the corresponding script.

The scheme of the embodiment provides a faster and more effective method, and utilizes the concept similar to 'data pool DB'. The method aims to decouple the fussy data preparation steps in end-to-end automation, reduces interdependency and reduces the cost and complexity of dependent data construction. The data provider configures basic data information through the platform, the platform drives end-to-end use cases prepared by each data to execute, the basic data are temporarily stored, and the platform provides a general data acquisition service for the data user of each service to quickly acquire. Therefore, the problems caused by long link, unstable environment, mutual dependence of scripts and the like are solved.

The above embodiment content is an end-to-end automation test process described at an end side of a data provider, and further, to fully illustrate an implementation of the embodiment, the embodiment further provides another end-to-end automation test method, which is applicable to a data consumer, as shown in fig. 3, and the method includes:

step 301, sending a call request of data required by the test, wherein the call request carries query condition information.

And further, enabling the data provider to acquire available data which accords with the query condition information from the preset data pool. The preset data pool stores various service data obtained by calling the end-to-end execution use case to establish at regular time.

The data processing procedure of the data provider can refer to the corresponding description of the methods shown in fig. 1 and fig. 2, and is not described herein again.

Step 302, receiving the returned available data.

And the data provider returns the available data meeting the query condition information in the preset data pool to the data user.

And step 303, executing an end-to-end automation test according to the returned available data.

And the data user executes the end-to-end automatic test by using the obtained available data through a preset automatic test script.

For convenience of understanding of the specific implementation process of the method in each embodiment, the following application scenario examples are given, but not limited to:

as shown in fig. 4, an exemplary business architecture. Commodity data, store data, order data, and the like are basic data on which end-to-end testing depends. For example, testing the flow of an order processing process, requires pre-positioning data of commodities, shops, activities and the like. The scheme provided by the embodiment can realize configuration management, data generation, data acquisition, data list, data correction, data cleaning, water level monitoring (data quantity monitoring) and the like. Fig. 5 shows a specific flowchart, and the offline data generation (data generation in the data pool) and the offline data acquisition (data acquisition in the data pool) in fig. 5 may be main innovative contents of the solution of the present embodiment. A timing chart of the offline data generation may be as shown in fig. 6, and a timing chart of the offline data acquisition may be as shown in fig. 7.

The scheme of the embodiment provides a quick and effective method, and utilizes the concept similar to a business data pool DB. The method aims to decouple the fussy data preparation steps in end-to-end automation, reduces interdependency and reduces the cost and complexity of dependent data construction. The data provider configures data basic information through the platform, the platform drives end-to-end use cases prepared by each data to execute, the basic data are temporarily stored, the platform provides general data acquisition service, and service end-to-end scripts of data users of each service can quickly acquire the dependent service data. The scheme decouples the process of business data construction, not only can the data user dynamically obtain the dependent business data according to certain conditions (factory information and label information) through the basic capability provided by the platform, and avoid the problem of poor maintainability caused by writing dead business data, but also decouples the dependence problem between the data supply and demand parties through the capability, and the data user does not need to sense various business data creation scripts of a data provider, and does not need to worry about the script maintenance cost caused by the business change of the data provider, and the success rate of business automation is reduced caused by the link problem of the business data creation scripts, so that the problems of long link, unstable environment and mutual dependence of the scripts are solved.

Further, as a specific implementation of the method shown in fig. 1 and fig. 2, the embodiment provides an end-to-end automatic testing apparatus applicable to a data provider, as shown in fig. 8, the apparatus includes: a receiving module 41, an obtaining module 42, and a sending module 43.

A receiving module 41, configured to receive a call request of data required for testing, where the call request carries query condition information;

an obtaining module 42, configured to obtain available data meeting the query condition information from a preset data pool, where various service data obtained by calling an end-to-end execution case to create at regular time are stored in the preset data pool;

and a sending module 43, configured to return the obtained available data, so as to perform an end-to-end automation test.

In a specific application scenario, the apparatus further comprises: a creation module;

the obtaining module 42 is further configured to obtain configuration information of data generation;

and the creating module is used for calling an end-to-end execution case to create various service data in a timed and multi-thread manner according to the configuration information and storing the service data in the preset data pool.

In a specific application scenario, optionally, the configuration information includes: factory configuration, label configuration and script configuration of data; and the creating module is specifically used for executing the end-to-end script in the script configuration, generating dynamic data of various services, and implanting context information of the dynamic data according to data factory information in the factory configuration and data label information in the label configuration.

In a specific application scenario, optionally, the data factory information includes: an identification of a service line, and/or an identification of a data responsible party, the data tag information comprising: data type, and/or data as a whole.

In a specific application scenario, the creating module is further specifically configured to store the successfully generated dynamic data in a service data table of a corresponding plant according to context information of the successfully generated dynamic data, and to connect data plant information and data tag information corresponding to tags.

In a specific application scenario, the creating module is specifically further configured to determine whether the data volume of the valid data of each service in the preset data pool meets a preset shortage condition; if the target type service with the data volume of the effective data meeting the preset insufficiency condition exists, calling an end-to-end execution case corresponding to the target type service, creating new data of the target type service and storing the new data in the preset data pool.

In a specific application scenario, optionally, the query condition information includes: target factory information and target label information of data to be called;

the obtaining module 42 is specifically configured to obtain available data corresponding to the target plant information and the target tag information from a preset data pool by querying a service data table of the plant.

In a specific application scenario, optionally, static data and dynamic data of various services are stored in the preset data pool, wherein the static data can be used repeatedly, and the dynamic data has a limitation on the number of times of use;

the obtaining module 42 is specifically configured to, if the available data is static data, directly obtain the available data; if the available data is dynamic data, judging whether the use times of the available data exceed the corresponding use time limit according to the use state information of the available data, and if the use times do not exceed the corresponding use time limit, acquiring the available data.

In a specific application scenario, optionally, the number of times of use is limited to be used at most once, and the use state of the dynamic data in the preset data pool is changed into a used state after the dynamic data is acquired;

the obtaining module 42 is further specifically configured to determine that the number of times of use does not exceed the corresponding limit of the number of times of use if the use state of the available data is an unused state.

In a specific application scenario, the apparatus further comprises: a restriction module;

and the limiting module is used for limiting a plurality of data requesters to simultaneously request to call the same service data through updating the use state information of the data in the preset data pool based on an optimistic lock mechanism.

In a specific application scenario, the obtaining module 42 is further configured to perform valid data check on the service data in the preset data pool; and acquiring available data meeting the query condition information from the valid data of the preset data pool.

In a specific application scenario, the obtaining module 42 is further specifically configured to perform entry check and tag validity check on the service data in the preset data pool.

It should be noted that other corresponding descriptions of the functional units involved in the end-to-end automatic testing apparatus applicable to the data provider provided in this embodiment may refer to the corresponding descriptions of the methods in fig. 1 and fig. 2, and are not described herein again.

Further, as a specific implementation of the method shown in fig. 3, an embodiment of the present application provides an end-to-end automation testing apparatus applicable to a data consumer, as shown in fig. 9, the apparatus includes: a sending module 51, a receiving module 52 and a testing module 53.

A sending module 51, configured to send a call request for data required by a test, where the call request carries query condition information, so as to obtain available data meeting the query condition information from a preset data pool, where various service data obtained by calling an end-to-end execution case to create regularly are stored in the preset data pool;

a receiving module 52, configured to receive the returned available data;

and the testing module 53 is configured to execute an end-to-end automation test according to the available data.

It should be noted that other corresponding descriptions of the functional units involved in the end-to-end automatic testing apparatus applicable to a data consumer provided in this embodiment may refer to the corresponding descriptions of the method in fig. 3, and are not described herein again.

Based on the methods shown in fig. 1 and fig. 2, correspondingly, the embodiment of the present application further provides a storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the methods shown in fig. 1 and fig. 2. Based on the method shown in fig. 3, the present application further provides another storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the method shown in fig. 3.

Based on such understanding, the technical solution of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.), and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method of the embodiments of the present application.

Based on the method shown in fig. 1 and fig. 2 and the virtual device embodiment shown in fig. 8, in order to achieve the above object, an embodiment of the present application further provides an electronic device, which may be a personal computer, a server, an intelligent terminal, or other network devices, and the electronic device includes a storage medium and a processor; a storage medium for storing a computer program; a processor for executing a computer program for implementing the above-described method as shown in fig. 1 and 2.

Based on the method shown in fig. 3 and the virtual device embodiment shown in fig. 9, in order to achieve the above object, the present application provides another electronic device, which may specifically be a personal computer, a server, an intelligent terminal, or other network devices, and the electronic device includes a storage medium and a processor; a storage medium for storing a computer program; a processor for executing a computer program for implementing the above-described method as shown in fig. 3.

Optionally, both the two entity devices may further include a user interface, a network interface, a camera, a Radio Frequency (RF) circuit, a sensor, an audio circuit, a WI-FI module, and the like. The user interface may include a Display screen (Display), an input unit such as a keypad (Keyboard), etc., and the optional user interface may also include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), etc.

It will be understood by those skilled in the art that the two physical device configurations provided in the present embodiment are not intended to limit the two physical devices, and may include more or fewer components, or some components in combination, or different arrangements of components.

The storage medium may further include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the two physical devices described above, supporting the operation of the information processing program as well as other software and/or programs. The network communication module is used for realizing communication among components in the storage medium and communication with other hardware and software in the information processing entity device.

Based on the above, further, an end-to-end automation testing system is provided in the embodiments of the present application, and the system includes a data provider device and a data consumer device.

Wherein the data provider device is operable to perform the method as shown in fig. 1 and 2 and the data consumer device is operable to perform the method as shown in fig. 3.

Specifically, the data consumer device may be configured to send a call request for testing data required by the test to the data provider device, where the call request carries the query condition information.

The data provider equipment is used for receiving a call request for receiving the data required by the test, which is sent by the data user equipment; acquiring available data which accords with the query condition information from a preset data pool, wherein various service data which are obtained by calling an end-to-end execution case to establish at regular time are stored in the preset data pool; and returning the acquired available data.

The data user device can also be used for receiving the available data returned by the data provider device; and executing end-to-end automation test according to the available data.

Through the above description of the embodiments, those skilled in the art will clearly understand that the present application can be implemented by software plus a necessary general hardware platform, and can also be implemented by hardware. By applying the technical scheme of the embodiment, the effectiveness, the stability and the maintainability of the automatic test can be improved, and the subsequent maintenance cost can be reduced.

Those skilled in the art will appreciate that the figures are merely schematic representations of one preferred implementation scenario and that the blocks or flow diagrams in the figures are not necessarily required to practice the present application. Those skilled in the art will appreciate that the modules in the devices in the implementation scenario may be distributed in the devices in the implementation scenario according to the description of the implementation scenario, or may be located in one or more devices different from the present implementation scenario with corresponding changes. The modules of the implementation scenario may be combined into one module, or may be further split into a plurality of sub-modules.

The above application serial numbers are for description purposes only and do not represent the superiority or inferiority of the implementation scenarios. The above disclosure is only a few specific implementation scenarios of the present application, but the present application is not limited thereto, and any variations that can be made by those skilled in the art are intended to fall within the scope of the present application.