CN117009238A

CN117009238A - Data testing method, device, electronic equipment, storage medium and program product

Info

Publication number: CN117009238A
Application number: CN202311009012.6A
Authority: CN
Inventors: 李强强
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2023-08-10
Filing date: 2023-08-10
Publication date: 2023-11-07

Abstract

The disclosure provides a data testing method, a device, electronic equipment, a storage medium and a product, relates to the technical field of computers, and particularly relates to the fields of cloud computing and big data. The specific implementation scheme is as follows: determining a plurality of service modules in a service object, wherein the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene; and scheduling the preset test resources in the test scene to a plurality of test environments in the test scene so as to test at least one service module corresponding to the test environments respectively to obtain a test result.

Description

Data testing method, device, electronic equipment, storage medium and program product

Technical Field

The disclosure relates to the field of computer technology, and in particular relates to a data testing method, a device, electronic equipment, a storage medium and a program product in the fields of cloud computing and big data.

Background

Currently, inspection and test are performed on the functions of products, and different business teams often have an offline testing environment, and often a research and development engineer (Research and Development engineer, abbreviated as RD) of the business deploys testing services through a physical machine.

However, different services have own testing environments, unified maintenance standards are not available, the services RD are deployed through physical machines, the environments lack certain stability, the RD of a certain service module is only responsible for knowing the state of the module where the RD is located, if a plurality of people deploy different modules, environmental conflict can be caused, and therefore the technical problem of low efficiency of data testing is caused.

Disclosure of Invention

The present disclosure provides a data testing method, apparatus, electronic device, storage medium and program product.

According to another aspect of the present disclosure, a data testing method is provided. The method may include: determining a plurality of service modules in a service object, wherein the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene; and scheduling the preset test resources in the test scene to a plurality of test environments in the test scene so as to test at least one service module corresponding to the test environments respectively to obtain a test result.

According to another aspect of the present disclosure, another data testing method is also provided. The method may include: responding to the distribution operation acted on the operation interface, and displaying at least one service module distributed to the test environment on the operation interface, wherein the at least one service module is from a plurality of service modules in the service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene; and responding to the test operation acted on the operation interface, and displaying a test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resources scheduled to the test environment.

According to another aspect of the present disclosure, there is also provided a data testing apparatus. The apparatus may include: the system comprises a determining unit, a judging unit and a judging unit, wherein the determining unit is used for determining a plurality of service modules in a service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene; the scheduling unit is used for scheduling the preset test resources in the test scene to a plurality of test environments in the test scene so as to test at least one service module corresponding to the test environments respectively to obtain a test result.

According to another aspect of the present disclosure, another data testing apparatus is also provided. The apparatus may include: the first display unit is used for responding to the distribution operation acted on the operation interface, displaying at least one service module distributed to the test environment on the operation interface, wherein the at least one service module is from a plurality of service modules in the service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene; the second display unit is used for responding to the test operation acted on the operation interface and displaying the test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resources scheduled to the test environment.

According to an aspect of the present disclosure, there is also provided an electronic apparatus. The electronic device may include: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the data testing method of the embodiments of the present disclosure.

According to another aspect of the present disclosure, there is also provided a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the data testing method of the embodiments of the present disclosure.

According to another aspect of the present disclosure, there is also provided a computer program product, which may comprise a computer program which, when executed by a processor, implements the data testing method of the embodiments of the present disclosure.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The drawings are for a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

FIG. 1 is a flow chart of a data testing method according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of another data testing method according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of building a development environment in accordance with an embodiment of the present disclosure;

FIG. 4 is a schematic illustration of a sand box joint debugging environmental maintenance according to an embodiment of the present disclosure;

FIG. 5 is a flow chart of a build environment container according to an embodiment of the present disclosure;

FIG. 6 is a flow chart of a user perspective build container according to an embodiment of the present disclosure;

FIG. 7 is a schematic diagram of an application container page according to an embodiment of the present disclosure;

FIG. 8 is a schematic diagram of a container page according to an embodiment of the present disclosure;

FIG. 9 is a schematic diagram of a sandbox scenerization test environment build according to an embodiment of the disclosure;

FIG. 10 is a flow diagram of a method of sandbox scenerization test environment construction, according to an embodiment of the disclosure;

FIG. 11 is a schematic diagram of a sandbox scenerization test, according to an embodiment of the present disclosure;

FIG. 12 is a schematic diagram of a task setting according to an embodiment of the present disclosure;

FIG. 13 is a schematic diagram of a data testing apparatus according to an embodiment of the present disclosure;

FIG. 14 is a schematic diagram of another data testing apparatus according to an embodiment of the present disclosure;

Fig. 15 is a block diagram of an electronic device of a data testing method according to an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present disclosure to facilitate understanding, and should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The present disclosure provides a data testing method, and fig. 1 is a flowchart of a data testing method according to an embodiment of the present disclosure, and as shown in fig. 1, an implementation of the data testing method may at least include the following implementation steps:

in step S102, a plurality of service modules are determined in the service object.

In the technical scheme provided in the step S102, a plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene.

In this embodiment, in the service object, a plurality of service modules may be determined. The service object may be a service deployed through a physical machine, or may be a computer program or an application program running on the physical machine for implementing a specific function or service, which is only illustrated herein, and the type of the service object is not specifically limited. The service module may be used to represent a degree code of a service function to be tested in a test scenario, may be a service module requiring joint debugging test, may be a module requiring iterative development, and is only illustrated herein without specific limitation on the type of the service module. The plurality of service modules may be obtained from a service module set and may be in the same test scenario. The test scenario may be a task scenario, an iteration scenario, etc., which are merely examples herein, and the type of the test scenario is not particularly limited. The service function to be tested can be a business iteration function, an increment function and the like. The program code of the service function to be tested is used for testing the service module, and branch codes can be tested for the module.

Alternatively, the same service module may be assigned to different person developments. At the same time, one person may also iterate multiple service modules at the same time. In this embodiment, a plurality of service modules in the service module set that needs joint debugging test at this time may be generalized to a test scenario through a platform.

For example, the platform automatically maintains the correspondence between all the service modules in the test scenario, including how many people are developing the same service module at the same time. A plurality of service modules corresponding to the service object may be determined in the service object.

Step S104, scheduling the preset test resources in the test scene to a plurality of test environments in the test scene to test at least one service module corresponding to the test environments respectively, so as to obtain a test result.

In the technical scheme provided in the step S104, the preset test resources in the test scene are determined, and the test resources can be scheduled to a plurality of test environments in the test scene, so that at least one service module corresponding to the plurality of test environments is tested based on the test resources, and a test result is obtained. The test resource may be a traffic resource (simply referred to as traffic). The test environment may also be referred to as a development environment, and may be a container environment of an application container engine (Docker), a general test environment, a sandbox test environment, a benchmark sandbox environment, a Base (Base) environment, etc., which are merely illustrative, and the type of the test environment is not particularly limited.

Optionally, for the same service module, the embodiment supports scheduling of freely switching test resources (may be simply referred to as traffic scheduling), and the test resources under the test scene may be set in the platform in advance. The platform can be used for scheduling the testing resources of the service modules to the testing environments in multiple iterations, for example, on a container corresponding to a certain RD, so as to test at least one service module corresponding to the multiple testing environments respectively, and a testing result is obtained.

For example, in the traffic forwarding, the corresponding test resources under the test scenario may be preset. Each service module has a snapshot of the test environment, which may be referred to as a reference sandbox environment. The service grid can dispatch the test resources to the reference sandbox environment of the service module, so that the test of the service module is completed, and a test result is obtained, thereby achieving the aim of cascade test. The test environment may be an online test environment.

Through the steps S102 to S104, determining a plurality of service modules in the service object, where the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene; and scheduling the preset test resources in the test scene to a plurality of test environments in the test scene so as to test at least one service module corresponding to the test environments respectively to obtain a test result. That is, the embodiment of the disclosure proposes a concept of scenery, binds the service modules and the test scenes, can iterate a plurality of service modules simultaneously through the scene ID, performs resource scheduling among the service modules by the scene ID, breaks the limitation of test joint debugging, thereby achieving the technical effect of improving the data test efficiency and solving the technical problem of low data test efficiency.

The above-described method of this embodiment is described in further detail below.

As an alternative embodiment, the method may further comprise: and generating a test scene, wherein the identification information is used for identifying the test scene and representing the association relation among the plurality of service modules.

In this embodiment, a test scenario may be generated. The test scenario may be identified by the identification information. Based on the identification information, an association relationship between the plurality of service modules can be determined. The identification information may be scene Identity information (ID for short), which may also be marked as scene_id, or may be referred to as Identity information of a link feature, feature identification ID, link feature ID, etc., which are only for illustration, and the identification information is not particularly limited.

Alternatively, the same service module may be assigned to different person developments. At the same time, one person may also iterate multiple service modules at the same time. In this embodiment, a plurality of service modules that need joint debugging test at this time may be generalized to a test scene through a platform, and the generated test scene is identified by the identification information, so that full-link dispatching is implemented by using the service grid through the identification information. The scene IDs of the service modules under the same test scene are the same.

For example, the service may directly enter the corresponding sandbox scene page, create a test scene, and identify the test scene through the identification information, and may allocate some service modules to the RD for iteration. The corresponding relation among all the service modules under the same identification information can be automatically maintained according to the identification information.

In the embodiment, on the construction of a sandbox scene test scene (also called a link), a scene idea is creatively provided, one test scene is virtual, an iteration plan (namely a service module) and the test scene are bound, each test scene is provided with a characteristic identification ID of displacement, and the same service module can be distributed to different RD development or one person to iterate a plurality of service modules simultaneously through identification information. That is, in this embodiment, the association relationship (may also be referred to as a scheduling organization) between the service modules is determined by the identification information, so as to solve the problem that the conventional parallel test joint debugging is limited.

As an alternative embodiment, the test resources are set to the test scenario based on the identification information.

In this embodiment, identification information of the test scenario is determined, and based on the identification information, test resources may be set to the test scenario.

Optionally, after the RD receives the allocation of the test resources, the RD claims its own test resources through the scenerization platform, and builds a test environment, for example, a container development environment, through the platform, so as to complete operations such as reference deployment, output package update, front-back task, and the like of the service module, and perform incremental function development.

For example, assume that the service module that needs to be iteratively developed at this time is service module a and service module C, and the test between service module a and service module C needs to be performed by the intermediate service module B and the final service module D to calculate a complete link. The 4 involved service modules can be integrated into one scene through a one-stop development platform, and then a scene ID (which can be recorded as scene_id) is generated. Based on the scene ID, a test resource can be set to the test scene, for example, a WEB version (WEB version) sets a schedule on a corresponding service module, and the platform can automatically seed cache information taking the scene ID as a characteristic value on the WEB page, and based on the identification information, the test resource is set to the test scene to complete the schedule setting.

In this embodiment, a plurality of service modules of a certain iteration may be unified and summarized into one iteration scene plan (also may be referred to as a test scene), where the test scene is globally unique and has unique identification information (such as ID identification). The service module can deploy the test environment by using the Docker container so as to quickly construct the research and development environment and ensure the consistency of all the test scenes. The same service module can be assigned to different people for development. At the same time, one person may also iterate multiple service modules at the same time. The service module requiring joint debugging test can be generalized to a test scene through the visual platform, and the whole link scheduling can be realized through the identification information and the service grid, so that the problem of joint debugging test limitation is broken, the technical effect of improving the efficiency of data test is achieved, and the technical problem of low efficiency of data test is solved.

As an alternative embodiment, setting the test resources to the test scenario based on the identification information includes: the identification information is determined as a characteristic value to request the test resource from the resource provider.

In this embodiment, the identification information may be determined as a characteristic value to request the test resource from the resource provider. Wherein the resource provider may also be referred to as a relying party. The characteristic values may include staining characteristic values.

Alternatively, the identification information may be determined as the characteristic value. The dyeing eigenvalue in the top (header) may be detected, and the test resources are scheduled from the resource provider into the corresponding test environment based on the eigenvalue. For example, traffic may be forwarded to multiple test environments in a given test scenario to enable concatenation of links.

For example, before the formal joint debugging test, the test can be performed by two ends, the WEB page version (WEB version) is only required to set scheduling information in the corresponding service module, and the platform can seed a cache (Cookie information) taking the scene ID as a characteristic value on the WEB page; the network access terminal (NA terminal) can complete the scheduling setting by adding the request header with the scene ID as the characteristic value in the top (header). The test resource may be requested from the resource provider based on the identification information.

According to the embodiment, the multi-path multi-person joint debugging test conflict is solved by means of iterative joint debugging of the scene organization service, the container dispatching is standardized, the final dispatching route is determined by means of scene identification information, and therefore multi-module multi-person parallel testing acceptance is achieved, and flexible switching is achieved. The platform integrates 80% of automation capability, thereby greatly reducing the manual intervention degree of the service and realizing the technical effect of improving the efficiency of data testing. The platform can be a visual platform and can be used for setting contents such as characteristic values, scheduling information and the like.

As an optional embodiment, step S104, scheduling the preset test resources in the test scenario to the multiple test environments in the test scenario includes: and scheduling the test resources to a plurality of test environments according to scheduling information, wherein the scheduling information is used for representing a rule for scheduling the test resources and is updated according to a time period.

In this embodiment, the test resources may be scheduled into a plurality of test environments according to the scheduling information, where the scheduling information may be used to characterize a rule for scheduling the test resources, may be a pre-set scheduling rule, for example, may be a real-time update scheduling rule, a timing update scheduling rule, etc., which is merely illustrative herein, and does not specifically limit the content of the scheduling information.

Alternatively, the scheduling information may be updated in time periods, and the test resources are scheduled into multiple test environments based on the scheduling information. The time period may be preset, for example, may be about 0.5 to 1 minute, and is only illustrated herein, and the size of the time period is not particularly limited.

For example, a user may set scheduling information, such as port information, update rules, etc., at the visualization platform. The visual platform (may be simply referred to as a platform) back-end service may be persistent, and the gateway may poll periodically to obtain the latest scheduling information, so that the platform updates the scheduling information according to a time period. According to the scheduling information, the test resources can be scheduled into a plurality of test environments.

As an alternative embodiment, scheduling the test resources to the plurality of test environments according to the scheduling information includes: and scheduling the test resource from a first test environment to a second test environment according to the scheduling information.

In this embodiment, the test resources may be scheduled by a first one of the plurality of test environments to a second one of the plurality of test environments according to the scheduling information.

Optionally, the same service module in this embodiment supports scheduling of freely switched test resources, so that the test resources may be scheduled by a first test environment of the multiple test environments to a second test environment of the multiple test environments according to the scheduling information.

In the joint debugging test process, most of business teams (which can be called business for short) have no unified sand box joint debugging environment maintenance standard, and a part of fixed machine pools are generally adopted as a platform for deployment of a test module. When a service iteration needs to test, the service RD deploys a corresponding module test branch code to a certain machine, and exposes an address to a relying party for test. In the parallel test iteration process, the situation that a plurality of branches of the same service module are deployed at the same time is often involved, and continuous confirmation and relying party confirmation are needed during joint debugging test, and the joint debugging test is switched to the corresponding code branch. Particularly, when cascade test is performed, if one ring in a certain link is an on-line environment and the other ring is an off-line environment, a module of the on-line environment cannot be enabled to request test resources to the off-line environment, and finally the whole link is interrupted, so that the problem that data test cannot be performed exists. In this embodiment, a visual platform is provided for operation, and a user can apply as required, i.e. a complete set of container development environments can be re-carved in a minute level, and on the construction of a test link, the same service module can schedule a test environment from a first test environment in a plurality of test environments to a second test environment in the plurality of test environments according to scheduling information set by the platform, so as to realize scheduling of freely switching test resources.

As an alternative embodiment, at least one service module corresponding to the first test environment is identical to at least one service module corresponding to the second test environment.

In this embodiment, at least one service module corresponding to the first test environment is the same as at least one service module corresponding to the second test environment.

Optionally, the platform may automatically maintain correspondence between all service modules under the identification information, including: how many service modules and how many people are developing the same service module at the same time. For the same module, free handoff traffic scheduling is supported. The same service module can be distributed to different test environments for development testing.

As an alternative embodiment, scheduling the test resources to the plurality of test environments according to the scheduling information includes: and scheduling a plurality of sub-test resources in the test resources to a plurality of test environments according to the scheduling information, wherein the plurality of sub-test resources are in one-to-one correspondence with the plurality of test environments.

In this embodiment, a plurality of sub-test resources among the test resources may be scheduled into a plurality of test environments according to the scheduling information. The plurality of sub-test resources are in one-to-one correspondence with the plurality of test environments.

Optionally, the service may forward the subtest resources of the service module to the test environment where a specific RD in the multiple iterations is located through the platform settings.

Alternatively, the service modules A1, C1 requiring iteration may be assigned to the corresponding RDs through the platform designation.

As an optional embodiment, step S104, scheduling the preset test resources in the test scenario to the multiple test environments in the test scenario includes: the service grid is invoked to schedule the test resources to a plurality of test environments.

In this embodiment, a service grid may be invoked to schedule test resources into multiple test environments. The service grid may be a basic component service grid, such as a GateWay (GateWay), a cloud computing service grid (UFC), etc., which is only illustrated herein, and the type of the service grid is not particularly limited.

Alternatively, all requests may go through the service grid on forwarding of the test resources, so the service grid may be invoked to schedule the test resources into multiple test environments.

As an alternative embodiment, the method may further comprise: and constructing at least one target container to the service module, wherein the target container is used for representing the testing environment corresponding to the service module.

In this embodiment, at least one target container may be built into the service module. The target container may be used to characterize a test environment corresponding to the service module, and may be a joint debugging container, a Docker container, etc., which are only illustrated herein, and the type of the target container is not specifically limited.

Optionally, at least one target container may be constructed for the service module, and the service user (also referred to as a user) may apply for the target container according to the requirement, so as to complete the test on the service module.

In the embodiment, on the construction of a research and development environment, a general research and development environment is constructed into a container mirror image in advance through an e-containerization application program (Dockerfile), and container arrangement is realized by using an open source platform (Kubernetes, abbreviated as K8 s) technology for container arrangement and management so as to construct at least one target container for a service module. The service is completely shielded from the bottom implementation details, all the capabilities provide the operation of a visual platform, and a service user can re-etch a complete container development environment at the minute level only by applying for a target container according to the need. The container environment has strong isolation and has the capability of dynamic expansion and contraction capacity and mirror image in-situ updating, thereby achieving the technical effect of improving the efficiency of data testing. The Dockerfile may be a text file, which is used to define the building process and configuration information of the Docker mirror image, and is used to automatically build and create the portable containerized application program.

As an alternative embodiment, constructing at least one target container to the service module includes: the target container is constructed based on the mirrored information of the test environment.

In this embodiment, the target container may be constructed based on the mirrored information of the test environment. The image information may be a service environment image, a container image of multiple environments, etc., and is only illustrated herein without specific limitation to the type of the image information.

Optionally, the Dockerfile mirror is pre-arranged with the base dependency component, completely without relying on other traffic lines. The independent container environments are isolated, and the platform directly constructs a target container based on the mirror image information of the test environment so as to host all environments required by the container and mirror image preassembled joint debugging test and support functions of expansion and contraction, sharing, release and the like, thereby achieving the aim of improving the data test efficiency.

For example, authority checking can be performed on the service user, whether the user is qualified for application of the target container is judged, if the user is qualified for application, the container application information is initialized and the application page is skipped. The background can pull the appointed Docker environment mirror image to construct a target container according to the application information of the user, and after the construction is successful, the test of the service module is executed. The application information may be information such as a specified container mirror kernel version, which is not limited herein. Meanwhile, after the target container is successfully constructed, the keep-alive process of the container agent program (agent) is automatically started, the state information of the target container is reported in real time, the service can automatically jump to an integrated development environment (Visual Studio Code, VSCODE for short) to develop the coding page, all development environments depend on the fact that the information is tiled through mirror image, and a user does not need to construct for the second time.

Optionally, a target container (also referred to as a container image) constructed based on image information of the test environment supports functions of in-situ updating, data backup, new image pulling, data restoration and the like, and service is not felt in the process of completing image iterative upgrade.

Optionally, the embodiment can utilize the K8s technology to dynamically expand and contract the capacity according to the persistent storage volume statement (Persistent Volume Claim, abbreviated as PVC) so as to realize dynamic adjustment of resources and meet special service requirements, thereby expanding the application range of the application.

In the embodiment, the target container is constructed based on the Docker containerization technology so as to achieve the aim of quickly constructing an isolated, stable and unified development environment, and in the embodiment, the service construction target environment period is shortened to a minute level based on mirror image information, repeated construction is not needed, and the development efficiency is greatly improved.

As an alternative embodiment, constructing the target container based on the mirrored information of the test environment includes: the target container is built in the application container engine using the mirrored information of the test environment.

In this embodiment, the target container may be built in the application engine using the mirrored information of the test environment, using the portable features of the application container engine. The application container engine may be a Docker container, among others.

The embodiment constructs the general research and development environment dependence into a Dockerf ile container mirror image, and the service user is completely transparent. Meanwhile, the K8s container arrangement technology mainstream in the industry is adopted to realize strategies such as container suspension, recovery, sharing and release, so that dynamic scheduling of resources is met, and the resource utilization rate is effectively improved. All the capabilities provide the operation of a visual platform, a user can etch a set of complete container development environment at the minute level again only by applying as required, meanwhile, the one-stop development platform uniformly hosts service environment images (namely image information), the maintenance and protection service Docker images are updated in time according to service use characteristics, and the latest capability of a target container developed by service application is ensured, so that the technical effect of improving the efficiency of data testing is achieved.

In the embodiment of the present disclosure, a plurality of service modules of a certain iteration may be unified and summarized into one iteration scene plan (may also be referred to as a test scene), where the test scene is globally unique and has unique identification information (such as an ID identifier). The service module can deploy the test environment by using the Docker container so as to quickly construct the research and development environment and ensure the consistency of all the test scenes. The same service module can be assigned to different people for development. At the same time, one person may also iterate multiple service modules at the same time. The service module requiring joint debugging test can be generalized to a test scene through the visual platform, and the whole link scheduling can be realized through the identification information and the service grid, so that the problem of joint debugging test limitation is broken, the technical effect of improving the data test efficiency is achieved, and the technical problem of low data test efficiency is solved.

The disclosed embodiments also provide another data testing method from the service development side, and fig. 2 is a flowchart of another data testing method according to the disclosed embodiments, and as shown in fig. 2, an implementation of the data testing method may at least include the following implementation steps:

step S202, at least one service module allocated to the test environment is displayed on the operation interface in response to the allocation operation on the operation interface.

In the technical scheme provided in the step S202, at least one service module is from a plurality of service modules in a service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene.

In this embodiment, at least one service module allocated to the test environment may be displayed on the operation interface in response to an allocation operation on the operation interface. Wherein the allocation operation may be used to allocate service modules. At least one service module is from a plurality of service modules in the service object. The plurality of service modules are in the same test scene and can be used for representing program codes of service functions to be tested in the test scene. The operation interface may be an operation interface of a visual platform or a mobile terminal, and may be used for selecting or inputting an allocation operation, which is only illustrated herein, and the type of the operation interface is not particularly limited.

Step S204, responding to the test operation on the operation interface, and displaying the test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resources scheduled to the test environment.

In the technical solution provided in step S204 of the present disclosure, the test result of the service module may be displayed on the operation interface in response to the additional test operation on the operation interface.

In the technical scheme provided in the step S204, the test result may be a result obtained after the test resource is tested, and may be obtained by testing the service module based on the test resource scheduled to the test environment.

Optionally, the embodiment can build a visual platform, and through inputting form input items on an operation interface of the visual platform, the container mirror images of various environments are provided for service selection, for example, domestic, foreign, mixed cloud and the like, and the service can select a target container according to own needs. The visual panel is used for operation, so that management capabilities of release, capacity expansion, mirror image updating, sharing and the like are realized, and the complex operation can be completed only by clicking a mouse, so that the convenience in the data testing process is improved.

As an alternative embodiment, the method may further comprise: and displaying the identification information of the test scene on the operation interface, wherein the identification information is used for identifying the test scene and representing the association relation among the plurality of service modules.

In this embodiment, the identification information of the test scene may be displayed on the operation interface, and the identification information may be modified or adjusted. The identification information may be used to identify a test scenario, and may be used to characterize an association relationship between a plurality of service modules, where the association relationship may be that the plurality of service modules belong to the same test scenario.

As an alternative embodiment, the method may further comprise: and responding to the calling operation acted on the operation interface, and displaying at least one target container on the operation interface, wherein the target container is used for representing the test environment corresponding to the service module.

In this embodiment, a call operation input on the operation interface may be acquired, and at least one target container may be displayed on the operation interface in response to the call operation acting on the operation interface. The target container may be used to characterize a test environment corresponding to the service module.

In this embodiment, in response to an allocation operation acting on an operation interface, displaying, on the operation interface, at least one service module allocated to a test environment, where the at least one service module is from a plurality of service modules in a service object, the plurality of service modules being in a same test scenario, the service modules being configured to represent program code for a service function to be tested in the test scenario; responding to the test operation acted on the operation interface, and displaying the test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resources scheduled to the test environment, thereby achieving the technical effect of improving the data test efficiency and solving the technical problem of low data test efficiency.

The foregoing technical solutions of the embodiments of the present disclosure are further described by way of example with reference to the preferred embodiments.

At present, with the development of new technologies in the industry, in order to adapt to the social development and keep the technological advancement, a technical stack (which may be a technical tool, a technical platform, etc.) used by a company in the process of development and operation and maintenance also changes to some extent, for example, a cloud native technical tool and an open-source programming language (abbreviated as a GO language) derived from the cloud native technical tool. In order to accelerate development efficiency, many companies actively hug cloud primordia, and reconstruct an old service module by adopting a new technical stack. In the reconstruction stage, the phenomenon that multiple languages exist simultaneously often exists, and at the moment, a consistent research and development environment is required to be quickly constructed stably and reliably to meet daily development requirements, meanwhile, the service switching cost can be reduced, and all research and development requirements in the transition stage are met.

The stable research and development environment can ensure the rapid iteration of the service, improve the productivity, ensure the environment consistency, simplify the service deployment flow, accelerate the continuous integration and shorten the product delivery period. With a stable development environment, a significant portion of the integrated testing needs to be done to verify that the function is expected before the product is formally delivered. Different business teams often have their own set of off-line test environments, typically services that business RD deploys through physical machines. This environment lacks certain stability, and only the RD responsible for a module knows the state of the module where it is located, and multiple people deploying different modules often causes environmental conflicts (e.g., ports). Alternatively, this mode does not allow free implementation of end-to-end joint debugging, requiring all configuration of the participants when involved in multi-party dependencies (in practice sometimes one of the dependencies has no new functional iterations, but a set of sandboxed test environments needs to be deployed for coordination testing). Based on this, a complete, stable, reliable, flexible sandbox testing environment is needed to support business side joint debugging tests. The sandbox environment has important significance in software development and testing, as the functions of the service module are more and more complex, the upstream and downstream call links are longer and the dependence items are more and more huge, and an isolated and safe environment is needed for experiment, test and verification, so that the sandbox environment is used as the last safety guarantee before business online, avoids online risks and improves service reliability.

As an alternative embodiment, the development environment is usually built, the company provides basic machine resources, the department infrastructure group is responsible for maintaining some basic environment dependent components, providing minimum units of service dependent environments, and the business team maintains a set of own development and joint debugging environments according to own needs. FIG. 3 is a flow chart of building a development environment, as shown in FIG. 3, according to an embodiment of the disclosure, the method may include the steps of:

step S301, claim the computer and configure the basic environment.

In this embodiment, the business team claims the computer and configures the underlying environment (e.g., git, GO, etc. environments).

Step S302, it is determined whether the configuration of the base environment is successful.

In this embodiment, it is determined whether the configuration of the base environment is successful, and if the configuration is successful, step S304 is implemented; if the configuration fails, step S303 is implemented.

Step S303, the configuration is returned.

In this embodiment, in response to the failure of the configuration of the base environment, the configuration is returned, and the configuration of the base environment can be completed by checking the cause and asking other people.

Step S304, the development and pulling of codes are entered.

In this embodiment, in response to a failure of the base environment configuration, the development environment may be entered and the corresponding code pulled.

Step S305 determines whether the code was successfully pulled.

In this embodiment, determining whether the code was successfully pulled, in response to which step S306 is implemented; in response to the pull-replacement code failure, step S309 is implemented.

And step S306, expanding and shrinking the container environment.

In this embodiment, the container environment is scaled in response to successfully pulling the code.

Step S307, approves the expansion and contraction rights of the business team.

In this embodiment, the business team's scaling rights may be approved by a manager, an operations and maintenance engineer (Operations Engineer, abbreviated OP) in response to allowing scaling of the container environment.

Step S308, upgrading the container environment.

In this embodiment, the container environment may be upgraded in response to the business team having the capacity expansion right.

In this embodiment, it is described that an RD builds a complete development environment from 0 to 1, including the whole processes of subsequent maintenance and expansion, which all need to participate in multiple ways, but different business teams often have their own set of offline test environments, usually services deployed by a physical machine by the business RD, and this container environment lacks a certain stability, only the RD responsible for a module knows the state of the module where it is located, and multiple people deploy different modules often cause environmental conflicts (such as ports).

Step S309, the base environment is reconfigured.

In this embodiment, the base environment is reconfigured in response to a failure to pull the substitution code.

As another alternative embodiment, a method for maintaining a sandbox joint debugging environment is provided, fig. 4 is a schematic diagram of a sandbox joint debugging environment maintenance according to an embodiment of the present disclosure, as shown in fig. 4, a service unit may be simultaneously developed by multiple people in a service team, for example, an a module has 10 application programming interfaces (Application Programming Interface, abbreviated as APIs) to be developed, and is distributed to three RDs in the service team, each RD develops 3 to 4 APIs therein, and A1-0 and A1-1 may be used to represent different development states of the same development unit, and service units such as B1-0 and B1-1 are the same.

In this method, most business teams do not have a unified sandbox joint debugging environmental maintenance standard, and a fixed part of machine pool (pool) is generally adopted as a platform for deployment of test modules. When service iteration needs to be tested, the service RD deploys the corresponding module test branch code to a certain machine, and exposes an address to a relying party for test. In the parallel iteration process, the situation that a plurality of branches of the same module are deployed at the same time is often involved, and continuous switching to the corresponding code branch is required to be confirmed by a relying party during joint debugging. Particularly when cascade test is performed, if one ring in a certain link is an on-line environment and the other ring is an off-line environment, a module in the on-line environment cannot request traffic to the off-line environment, so that the problem that a subsequent module cannot be tested due to different links is caused.

In the two embodiments, each business team needs to maintain a set of development and joint debugging environments, part of environments belong to the category of universality, the phenomenon of repeatedly manufacturing wheels is serious, and the basic components are excessively dependent on the basic architecture group classmates and cannot be reused quickly. In the construction process, the development environment of the self needs to be constructed from 0 to 1, and the cost is high; meanwhile, as the business team maintains own sand box joint debugging environment, the upstream and downstream tests are seriously dependent on the progress of the other party, and the parallel and flexible switching cannot be realized. The sandbox environment is usually mixed on a physical machine, and only the classmates responsible for corresponding modules are clear, so that the black box problem is serious, and the technical problem of low data testing efficiency still exists.

In order to solve the problems, the disclosure provides a research and development environment and sandbox scene test link construction method based on a Docker container. The general research and development environment is constructed into a container mirror image in advance through a Docker text file (Dockerfile), and the container arrangement is realized by using a K8s technology. The service is completely shielded from the bottom layer implementation details, all the capacities provide the operation of a visual platform, and a service user can re-etch a complete container development environment at the minute level only by applying according to the requirement. The container environment has strong isolation and the capability of dynamic expansion and contraction capacity and mirror image in-situ update.

Meanwhile, on the construction of the sandbox scene test environment, business iteration is organized by taking scenes as dimensions. And unifying a plurality of modules of a certain iteration into an iteration scene plan, wherein the scene plan is globally unique and has a unique ID. The service module deployment environment can quickly construct a research and development environment and ensure the consistency of all Base environments by using the Docker container. The same service module can be assigned to different people for development. At the same time, one person may also iterate multiple modules at the same time. The service module which needs joint debugging test is concentrated under one scene through the platform, and the whole-link dispatching can be realized by means of the service grid through the link characteristic ID, so that the technical problem of low data testing efficiency is solved, and the technical effect of improving the data testing efficiency is realized.

FIG. 5 is a flow chart of building an environmental container, as shown in FIG. 5, according to an embodiment of the present disclosure, the method may include the following steps.

Step S501, apply for a container.

In this embodiment, the service RD applies for the container through the platform portal. Among other things, a platform (Easy platform) may include front-end pages and back-end services. The platform entry station may be a front page from a traffic perspective.

Step S502, it is determined whether a container has been applied.

In this embodiment, if the application has been previously applied, step S502 may be executed to directly enter the development stage; if not, step S505 may be performed.

Step S503, it is determined whether to construct an item using a container.

In this embodiment, if it has been previously applied, it may be further determined whether to build the project using the container.

In step S504, the container agent executes the task and reports.

In this embodiment, it is determined whether the container has been previously applied, and in response to the user having previously applied for the container, it may be further confirmed whether the container has built the project. In response to the container having built the project, the container agent may perform the task and report into the platform.

Step S505, the user is authenticated to apply for qualification.

In this embodiment, if the user has not previously applied for the container, it may be further determined whether the user qualifies for application for verification of the rights. If the user qualifies for an application, step S506 is performed.

For example, it may be determined whether this user is company A, has access to the platform (for which access to the platform domain name is required).

Optionally, this embodiment further limits the number of containers one can create, which cannot be created without limitation.

Step S506, initializing container application information and jumping to an application page.

In this embodiment, if it is determined that the user qualifies for the application, the container application information is initialized and jumps to an application page, where the application page may be a third party page (e.g., loading page). If the user does not qualify the application, the container application information is not initialized, and the user is directly reminded of no authority or the applied quantity reaches the limit.

Optionally, a jump to a third party page may be waiting for a container to be created, and the third party page may be used to show the progress of the user creation process, for example, for a control center (e.g., EE control center), the jump to the third party page may take the user's login state information and call their interface to trigger an action to create a container.

And S507, pulling mirror image information according to the application information of the user by the background to construct the container.

In this embodiment, the mirror image warehouse in the background may pull the specified dock environment mirror image according to the user application information to construct a container, and execute the post task after the construction is successful. The application information may be a user name, a selection of a specified container image kernel version, etc., which is only illustrated herein, and the type of the application information is not particularly limited. The post tasks may be specified for all platform contexts. The Docker environment image may be specified by the platform service provider and may be pre-built.

And step S508, after the container is successfully constructed, automatically starting the agent program keep-alive process, and reporting the container state information in real time.

In this embodiment, after the container is successfully constructed, the agent keep-alive process is automatically started, the container state information is reported in real time, the service automatic jump integrated development environment (Visual Studio Code, abbreviated as vscod IDE) performs the page coding development, all development environments depend on that the image is tiled, and the user does not need to construct for the second time.

The container executes some custom commands (command) when initializing the construction, and reports the construction state to the platform after the container is constructed successfully and the custom commands are finished, wherein the construction state can be basic information such as success or not, IP of the container and the like.

In step S509, the maintenance of the container image updates and dynamic scaling.

In this embodiment, the container image supports in-situ updating, data backup, new image pulling, data restoration, etc. to complete image iteration upgrade, and has unique advantages compared with the conventional container construction method.

In the embodiment, the storage volume mount can be dynamically created according to PVC by using the K8s technology, so that the dynamic adjustment and management of resources are realized, and the special service requirements are met.

FIG. 6 is a flow chart of a user perspective build container according to an embodiment of the present disclosure, as shown in FIG. 6, where the build container may include the following steps.

Step S601, apply for computer and container.

In this embodiment, when the user wants to expand the capacity, he can claim the computer first and claim the container.

Step S602, a development stage is entered.

In this embodiment, the process of expanding and contracting, sharing and releasing containers is fully flattened in the development stage.

For example, a smaller functional example may be selected for illustration. For developing an environment application, a service only needs to arrive at a designated page and apply for a container according to the environment, fig. 7 is a schematic diagram of an application container page according to an embodiment of the disclosure, as shown in fig. 7, a container that has been created by me may be displayed in the application container page, and a container to be processed may be selected in the my container list. The container which is applied successfully can be automatically displayed on the page and has certain management capability.

Alternatively, as shown in fig. 7, the operations on the container may be selected at the visual interface, and may be operations of entering the container, releasing the container, sharing the container, etc., which are only illustrative and not limiting in particular on the type of operations. As shown in fig. 7, the development container platform of the application integrates rich management capabilities, such as release, capacity expansion and contraction, mirror image update, sharing and the like, and is operated through a visual panel, and the service can complete complex operations only by clicking a mouse.

Fig. 8 is a schematic diagram of a container page according to an embodiment of the disclosure, as shown in fig. 8, after a container is applied successfully, a code space may be initialized by initializing container application information, and the code space may be started to jump to the application page again. The client may select a mode of launching the code space, and may be opened by a client or a web page, etc.

Alternatively, when the option is to open in the web page, the code space is loaded and opened in the web page. As shown in fig. 8, the loading time may be displayed in the web page, for example, immediately after 4s of display, at the web page. It should be noted that the loading manner and the display content of the web page are only illustrative, and are not particularly limited.

Optionally, fig. 9 is a schematic diagram of a sandbox scenerization test environment construction, as shown in fig. 9, where the construction of the sandbox scenerization test environment may include: benchmark environments, development containers, and base environments. The reference environment may include a module a, a module B, a module C, and a module D, among others. The development container may include an application container module, a clone code module, a scene management module, an index collection module, a concurrent dispatching module, a service automatic deployment module, a dispatch setting module, a task allocation module, a configuration deriving module, and a port setting module. The base environment may include image management, container initialization, binding code (icode), running program maintenance (also referred to as runtime maintenance), developing software tools (icoding ide).

Alternatively, the scheduling of the full link may be implemented by a scheduler, where the scheduler may be a gateway application programming interface (gateway Api) scheduler, a cloud computing service grid scheduler, etc., and it should be noted that the foregoing is merely illustrative, and the type of the scheduler is not specifically limited.

FIG. 10 is a flow diagram of a method of sandbox-scene-testing-environment construction, as shown in FIG. 10, that may include an iteration principal, a planning and distribution module, iterations RD1, and iterations RD2, according to an embodiment of the disclosure.

As shown in fig. 10, a sandbox scenerisation test environment construction may comprise the following steps.

Step S1001, planning and determining a scheduling period.

As an alternative embodiment, the iterative principal module may specify a plan, determining a schedule.

In this embodiment, it may be assumed that the modules that need to be iteratively developed at this time are a and C, and the test between a and C needs to be performed by the intermediate module B and the final module D to calculate a complete link. In order to enable the A1-B-C1-D links to run through, the 4 modules involved can be integrated into one scene through a one-stop development platform, and then a scene ID is generated. Meanwhile, modules A1 and C1 needing iteration can be assigned to corresponding RD through platform assignment.

Step S1002, selecting a product line and a service module.

As an alternative embodiment, the planning and distribution module selects the product line and service module in response to the planning specified by the iterative responsible person.

Step S1003, assigning a task to the specified RD.

In this embodiment, the planning and distribution module selects product lines and service modules, and distributes tasks to the specified iterations RD.

Step S1004, performing iterative task management.

In this embodiment, the planning and distribution module manages the iterative tasks based on the joint debugging test conditions determined by the iterative responsible. The management of the iterative tasks may include, among other things, adding plans, deleting plans, and setting up the master container.

Alternatively, the planning and distribution module may upload the management of the iterative tasks into a platform (Easy platform) that is utilized for metadata interactions with the gateway.

In step S1005, it is determined whether to assign a task to RD1.

As an alternative embodiment, after the iteration RD1 receives the task allocation, it may be determined by the scenerization platform whether the task is allocated.

Step S1006, claim the own module task.

In this embodiment, if iteration RD1 determines that the task is assigned, then its own service module task may be and claimed.

Step S1007, performing iterative task management.

In this embodiment, the iteration RD1 may claim its own service module task, and may build a container development environment through a platform to perform iteration task management, so as to complete operations such as reference deployment, output packet update, front-back task, code pulling, port setting, and the like of the service module, and perform incremental function development. Wherein the same service modules in different RDs may be developed in parallel.

Optionally, before formal joint debugging, testing can be performed by two ends, the WEB version is scheduled on the corresponding module, and the platform can automatically seed Cookie information taking the scene ID as a characteristic value on a webpage; and the NA end can finish the scheduling setting by adding a request head with the scene ID as a characteristic value into the header.

Step S1008, determining whether to assign a task to RD2.

In this embodiment, after the iteration RD2 receives the task allocation, it may be determined by the scenerisation platform whether the task is allocated.

Step S1009, claim the own module task.

In this embodiment, if iteration RD2 determines that the task is assigned, then its own service module task may be and claimed. The modules in the module task of the iteration RD2 may be developed in parallel with the unified modules in the module task of the RD1, or may be different modules from the module task of the RD 1.

Step S1010, performing iterative task management.

In this embodiment, the iteration RD2 may claim its own service module task, and may build a container development environment through a platform to perform iteration task management, so as to complete operations such as reference deployment, output packet update, front-back task, code pulling, port setting, and the like of the service module, and perform incremental function development.

Step S1011, checking and accepting the result of the iterative task management.

In this embodiment, the iteration responsible person checks the result of the iteration task management, and in response to the completion of the check, the iteration ends.

In this embodiment, the platform automatically maintains the correspondence between all iterative tasks under the scene ID, including how many service modules are available, and how many people are developing the same module at the same time. For the same module, free switching flow scheduling is supported, the service can forward the flow of the module to a container where a specific RD in the multi-person iteration is located through platform setting, and the platform updates the scheduling rule in real time.

In the flow forwarding, all requests pass through a basic component service grid, wherein dyeing characteristic values in a header are detected (a WEB version acquires dyeing characteristic values in a Cookie) and the corresponding flow is forwarded to a designated environment to realize the serial connection of links. Wherein each service has a snapshot of the online environment, called the benchmark sandbox. The service may choose to close the schedule (which may be set on the platform, e.g., B-module), then the service grid may schedule traffic to the reference sandbox environment of B-module, thus implementing the cascade test.

Fig. 11 is a schematic diagram of a sandbox scenerization test according to an embodiment of the disclosure, where, as shown in fig. 11, in a sandbox environment use situation, a service may directly enter a corresponding sandbox scenerization page, create a scene, and allocate some modules to an RD for iteration. As shown in fig. 11, 2 modules are assigned to an iteration plan with a scenario name of service test F (lqqServiceTest) to one RD development. RD may set the assigned service module.

Optionally, service modules (abbreviated as modules) may be allocated according to the service iteration requirement, for example, which modules need to be developed in this development iteration, each module is responsible for which RDs, and which modules are allocated to corresponding RDs may be determined by the iteration manager operation.

Fig. 12 is a schematic diagram of a task setting according to an embodiment of the present disclosure, as shown in fig. 12, after the RD receives an iteration task, the RD may automatically see an allocated task card in a sandbox scene-RD panel, and may quickly complete operations such as reference deployment, development container application, service port, schedule setting, and the like, develop at any time, and perform upstream and downstream serial testing.

Alternatively, as shown in fig. 12, a visual platform may be built, and through an automatic form input item, the platform provides container images of various environments for service selection (domestic, foreign, hybrid cloud, etc.), and the service may be selected according to its own needs.

In the embodiment, the one-stop development platform uniformly hosts the service environment mirror image, and timely updates the maintenance and maintenance service provider dock mirror image according to service use characteristics, so that the service application development container is ensured to have the latest capability. The research and development container platform integrates rich management capabilities, such as release, expansion and contraction, mirror image updating, sharing and the like, is operated through a visual panel, and can finish complex operations by only clicking a mouse by a service. The project responsible person (also called as service Owner) of the sandbox scene test link only needs to distribute task scenes, the research and development environment is based on the container constructed by the Docker, and the flow scheduling can be completed through the visualization operation.

In the embodiment, the isolated, stable and unified development environment is quickly built based on the Docker containerization technology, the service building environment period is shortened to the minute level, and repeated building is not needed. Meanwhile, the Dockerfile mirror image is pre-arranged with basic dependency components, and does not need to depend on other business line classmates at all. The independent container is isolated from environment, the platform directly hosts the container and the mirror image, and preassembles all environments required by the joint debugging, and the functions of expanding and shrinking, sharing, releasing and the like are supported. The multi-path multi-person joint debugging method has the advantages that the multi-path multi-person joint debugging conflict is solved through scene organization service iteration joint debugging, the final dispatching route is determined through scene identification, multi-module and multi-person simultaneous parallel test acceptance can be achieved, flexible switching is achieved, the technical effect of improving the efficiency of data testing is achieved, and the technical problem of low efficiency of data testing is solved.

The embodiment of the disclosure also provides a data testing device for executing the data testing method of the embodiment shown in fig. 1.

Fig. 13 is a schematic diagram of a data testing apparatus according to an embodiment of the present disclosure. As shown in fig. 13, the data testing apparatus 1300 may include: a determining unit 1302 and a scheduling unit 1304.

The determining unit 1302 is configured to determine a plurality of service modules in the service object, where the plurality of service modules are in the same test scenario, and the service modules are used to represent program codes of service functions to be tested in the test scenario.

And the scheduling unit 1304 is configured to schedule the preset test resources in the test scenario to a plurality of test environments in the test scenario, so as to test at least one service module corresponding to the plurality of test environments respectively, and obtain a test result.

Optionally, the apparatus further comprises: the generating unit is used for generating identification information of the test scene, wherein the identification information is used for identifying the test scene and representing the association relation among the plurality of service modules.

Optionally, the generating unit includes: the setting module is used for setting the test resources to the test scene based on the identification information.

Optionally, the setting module includes: and the processing sub-module is used for determining the identification information as a characteristic value to request the test resource from the resource providing end.

Optionally, the scheduling unit 1304 includes: the scheduling module is used for scheduling the test resources to a plurality of test environments according to scheduling information, wherein the scheduling information is used for representing rules for scheduling the test resources and is updated according to a time period.

Optionally, the scheduling module includes: and the first scheduling sub-module is used for scheduling the test resources from a first test environment to a second test environment in the plurality of test environments according to the scheduling information.

Optionally, the scheduling module further includes: and the second scheduling sub-module is used for scheduling a plurality of sub-test resources in the test resources to a plurality of test environments according to the scheduling information, wherein the plurality of sub-test resources are in one-to-one correspondence with the plurality of test environments.

Optionally, the scheduling unit 1304 further includes: and the calling module is used for calling the service grid to schedule the test resources to a plurality of test environments.

Optionally, the apparatus further comprises: the construction unit is used for constructing at least one target container for the service module, wherein the target container is used for representing the testing environment corresponding to the service module.

Optionally, the building unit comprises: and the construction module is used for constructing the target container based on the mirror image information of the test environment.

Optionally, the building module includes a building sub-module for building the target container in the application container engine using the mirrored information of the test environment.

The embodiment of the disclosure also provides another data testing device for executing the data testing method of the embodiment shown in fig. 2.

Fig. 14 is a schematic diagram of another data testing apparatus according to an embodiment of the present disclosure. As shown in fig. 14, the data testing apparatus 1400 may include: a first display unit 1402 and a second display unit 1404.

The first display unit 1402 is configured to display, on the operation interface, at least one service module allocated to the testing environment in response to an allocation operation acting on the operation interface, where the at least one service module is from a plurality of service modules in the service object, the plurality of service modules are in a same testing scenario, and the service modules are configured to represent program codes of service functions to be tested in the testing scenario.

The second display unit 1404 is configured to respond to a test operation on the operation interface, and display a test result of the service module on the operation interface, where the test result is obtained by testing the service module based on the test resource scheduled to the test environment.

In the data testing device of the embodiment of the disclosure, a concept of scenery is provided, the service modules and the testing scenes are bound, a plurality of service modules can be iterated simultaneously through scene IDs, resource scheduling among the service modules is performed by the scene IDs, and the limitation of testing joint debugging is broken, so that the technical effect of improving the data testing efficiency is achieved, and the technical problem of low data testing efficiency is solved.

In the technical scheme of the disclosure, the acquisition, storage, application and the like of the related user personal information all conform to the regulations of related laws and regulations, and the public sequence is not violated.

According to embodiments of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium and a computer program product and an autonomous vehicle.

Embodiments of the present disclosure provide an electronic device that may include: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the data testing method of the embodiments of the present disclosure.

Optionally, the electronic device may further include a transmission device and an input/output device, where the transmission device is connected to the processor, and the input/output device is connected to the processor.

According to an embodiment of the present disclosure, an automatic driving vehicle is further provided, wherein the automatic driving vehicle may include the above-described electronic device.

According to an embodiment of the present disclosure, the present disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the data testing method of the embodiments of the present disclosure.

Alternatively, in the present embodiment, the above-described nonvolatile storage medium may be configured to store a computer program for performing the steps of:

s1, determining a plurality of service modules in a service object, wherein the service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene;

s2, scheduling preset test resources in the test scene to a plurality of test environments in the test scene to test at least one service module corresponding to the test environments respectively, so as to obtain a test result.

Alternatively, in the present embodiment, the above-described nonvolatile storage medium may be further configured to store a computer program for performing the steps of:

s1, responding to allocation operation acted on an operation interface, and displaying at least one service module allocated to a test environment on the operation interface, wherein the at least one service module is from a plurality of service modules in a service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene;

S2, responding to the test operation acted on the operation interface, and displaying a test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resources scheduled to the test environment.

Alternatively, in the present embodiment, the non-transitory computer readable storage medium described above may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

According to an embodiment of the present disclosure, the present disclosure also provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of:

Optionally, in this embodiment, the above computer program may further implement the following steps when executed by a processor:

Fig. 15 is a block diagram of an electronic device of a data testing method according to an embodiment of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 15, the apparatus 1500 includes a computing unit 1501, which can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 1502 or a computer program loaded from a storage unit 1508 into a Random Access Memory (RAM) 1503. In the RAM1503, various programs and data required for the operation of the device 1500 may also be stored. The computing unit 1501, the ROM1502, and the RAM1503 are connected to each other through a bus 1504. An input/output (I/O) interface 1505 is also connected to bus 1504.

Various components in device 1500 are connected to I/O interface 1505, including: an input unit 1506 such as a keyboard, mouse, etc.; an output unit 1504 such as various types of displays, speakers, and the like; a storage unit 1508 such as a magnetic disk, an optical disk, or the like; and a communication unit 1509 such as a network card, modem, wireless communication transceiver, etc. The communication unit 1509 allows the device 1500 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunications networks.

The computing unit 1501 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of computing unit 1501 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital Signal Processors (DSPs), and any suitable processor, controller, microcontroller, etc. The calculation unit 1501 executes the respective methods and processes described above, for example, a travel track method of an autonomous vehicle. For example, in some embodiments, the data testing method may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as the storage unit 1508. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 1500 via the ROM1502 and/or the communication unit 1509. When a computer program is loaded into the RAM1503 and executed by the computing unit 1501, one or more steps of the data processing method described above may be performed. Alternatively, in other embodiments, the computing unit 1501 may be configured to perform the data testing method by any other suitable means (e.g., by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), complex Programmable Logic Devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: other types of devices may also be used to provide interaction with a user, for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user may be received in any form (including acoustic input, speech input, or tactile input).

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.

The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps recited in the present disclosure may be performed in parallel or sequentially or in a different order, provided that the desired results of the technical solutions of the present disclosure are achieved, and are not limited herein.

The above detailed description should not be taken as limiting the scope of the present disclosure. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present disclosure are intended to be included within the scope of the present disclosure.

Claims

1. A data testing method, comprising:

determining a plurality of service modules in a service object, wherein the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene;

and scheduling the preset test resources in the test scene to a plurality of test environments in the test scene so as to test at least one service module corresponding to the test environments respectively to obtain a test result.

2. The method of claim 1, further comprising:

generating identification information of the test scene, wherein the identification information is used for identifying the test scene and representing association relations among the plurality of service modules.

3. The method of claim 2, further comprising:

and setting the test resources to the test scene based on the identification information.

4. The method of claim 3, wherein setting the test resource to the test scenario based on the identification information comprises:

and determining the identification information as a characteristic value to request the test resource from a resource provider.

5. The method of claim 1, wherein scheduling the preset test resources in the test scenario to the plurality of test environments in the test scenario comprises:

and dispatching the test resources to the plurality of test environments according to dispatching information, wherein the dispatching information is used for representing a rule for dispatching the test resources and is updated according to a time period.

6. The method of claim 5, wherein scheduling the test resources to the plurality of test environments according to scheduling information comprises:

And dispatching the test resource from a first test environment to a second test environment according to the dispatching information.

7. The method of claim 6, wherein at least one of the service modules corresponding to the first test environment is the same as at least one of the service modules corresponding to the second test environment.

8. The method of claim 5, wherein scheduling the test resources to the plurality of test environments according to scheduling information comprises:

and scheduling a plurality of sub-test resources in the test resources to the plurality of test environments according to the scheduling information, wherein the plurality of sub-test resources are in one-to-one correspondence with the plurality of test environments.

9. The method of claim 1, wherein scheduling the preset test resources in the test scenario to the plurality of test environments in the test scenario comprises:

and calling a service grid to schedule the test resources to the plurality of test environments.

10. The method of claim 1, further comprising:

and constructing at least one target container to the service module, wherein the target container is used for representing the test environment corresponding to the service module.

11. The method of claim 10, wherein building at least one target container to the service module comprises:

and constructing the target container based on the mirror image information of the test environment.

12. The method of claim 11, wherein constructing the target container based on the mirrored information of the test environment comprises:

the target container is constructed in an application container engine using the mirrored information of the test environment.

13. A data testing method, comprising:

responding to allocation operation acted on an operation interface, and displaying at least one service module allocated to a test environment on the operation interface, wherein the at least one service module is from a plurality of service modules in a service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene;

and responding to the test operation acted on the operation interface, and displaying a test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resources scheduled to the test environment.

14. The method of claim 13, further comprising:

and displaying the identification information of the test scene on the operation interface, wherein the identification information is used for identifying the test scene and representing the association relation among the plurality of service modules.

15. The method of claim 13, further comprising:

and responding to a calling operation acted on the operation interface, and displaying at least one target container on the operation interface, wherein the target container is used for representing the test environment corresponding to the service module.

16. A data testing apparatus, comprising:

the system comprises a determining unit, a judging unit and a judging unit, wherein the determining unit is used for determining a plurality of service modules in a service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene;

the scheduling unit is used for scheduling the preset test resources in the test scene to a plurality of test environments in the test scene so as to respectively test at least one service module corresponding to the plurality of test environments to obtain a test result.

17. A data testing apparatus, comprising:

The system comprises a first display unit, a second display unit and a control unit, wherein the first display unit is used for responding to allocation operation acted on an operation interface, and displaying at least one service module allocated to a test environment on the operation interface, wherein the at least one service module is from a plurality of service modules in a service object, the plurality of service modules are in the same test scene, and the service modules are used for representing program codes of service functions to be tested in the test scene;

and the second display unit is used for responding to the test operation acted on the operation interface and displaying the test result of the service module on the operation interface, wherein the test result is obtained by testing the service module based on the test resource scheduled to the test environment.

18. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-15.

19. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-15.

20. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any of claims 1-15.