Test task processing method, device and electronic equipment

Abstract

The present application provides a test task processing method, device, electronic device and computer-readable storage medium; the method includes: determining multiple test tasks of the target business; performing operation splitting processing on each test task to obtain multiple call operations of each test task during execution; arranging and processing the call operations corresponding to the multiple test tasks according to the logical relationship between different call operations, and obtaining an arrangement result that conforms to the logical relationship; encapsulating the arrangement result into the business pipeline corresponding to the target business as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, multiple test tasks are executed according to the arrangement result. Through this application, the orderliness of the call operation can be enhanced, and the pipeline mechanism can be combined to ensure fast and accurate testing, thereby improving the overall test efficiency.

Description

Technical Field

[0001] The present application relates to software testing technology, and in particular to a test task processing method, device, electronic device and computer-readable storage medium. Background Art

[0002] Software testing refers to a process used to promote the identification of the correctness, integrity, security and quality of software. With the rapid development of software technology, software tends to be large-scale and highly complex, and software testing plays an increasingly important role in the software life cycle.

[0003] In the solutions provided by the related art, for a certain business to be tested, the testing work is usually distributed to multiple testers, and each tester writes the management and execution code for the test to test the part he is responsible for. However, during the entire testing process, multiple repeated operations or conflicting operations may occur, resulting in low overall testing efficiency. Summary of the invention

[0004] The embodiments of the present application provide a test task processing method, device, electronic device and computer-readable storage medium, which can avoid unnecessary operations during the test process and improve the test efficiency by combining the pipeline mechanism.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] The present application provides a test task processing method, including:

[0007] Identify multiple testing tasks for the target business;

[0008] Perform operation splitting on each test task to obtain multiple call operations of each test task during execution;

[0009] According to the logical relationship between different calling operations, the calling operations corresponding to the multiple test tasks are arranged and processed to obtain an arrangement result that conforms to the logical relationship;

[0010] The orchestration result is encapsulated into the business pipeline corresponding to the target business to serve as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, the multiple test tasks are executed according to the orchestration result.

[0011] The present application provides a test task processing device, including:

[0012] A task determination module is used to determine multiple test tasks for the target business;

[0013] The operation splitting module is used to perform operation splitting processing on each test task to obtain multiple call operations of each test task during the execution process;

[0014] An arrangement module, used for arranging the call operations corresponding to the plurality of test tasks respectively according to the logical relationship between different call operations, and obtaining an arrangement result that conforms to the logical relationship;

[0015] An encapsulation module is used to encapsulate the orchestration result into the business pipeline corresponding to the target business as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, the multiple test tasks are executed according to the orchestration result.

[0016] An embodiment of the present application provides an electronic device, including:

[0017] A memory for storing executable instructions;

[0018] The processor is used to implement the test task processing method provided in the embodiment of the present application when executing the executable instructions stored in the memory.

[0019] An embodiment of the present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute and implement the test task processing method provided in the embodiment of the present application.

[0020] An embodiment of the present application provides a computer program product, which includes executable instructions for causing a processor to execute and implement the test task processing method provided in the embodiment of the present application.

[0021] The embodiments of the present application have the following beneficial effects:

[0022] On the basis of determining the multiple test tasks required for the test target business, each test task is split and processed to obtain multiple call operations of each test task during the execution process. Then, the orchestration is performed according to the logical relationship between different call operations to obtain an orchestration result that conforms to the logical relationship. This can improve the orderliness between the call operations and avoid situations such as repeated execution or inability to execute call operations. For the obtained orchestration result, it is encapsulated into the business pipeline corresponding to the target business as a test pipeline in the business pipeline, that is, the test pipeline is used to be called as a step in the business pipeline, so as to ensure that the test work is carried out according to the orchestration results during the business production process. In summary, the embodiment of the present application can quickly and accurately complete the test in the business production process, improve the overall test efficiency, and facilitate the rapid release of the business. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 It is a schematic diagram of the architecture of the test task processing system provided in the embodiment of the present application;

[0025] Figure 2 It is a structural diagram of a server provided in an embodiment of the present application;

[0026] Figure 3A It is a flowchart of a test task processing method provided in an embodiment of the present application;

[0027] Figure 3B is another flowchart of the test task processing method provided in an embodiment of the present application;

[0028] Figure 3C is another flowchart of the test task processing method provided in an embodiment of the present application;

[0029] Figure 3D is another flowchart of the test task processing method provided in an embodiment of the present application;

[0030] Figure 4 is another flowchart of the test task processing method provided in an embodiment of the present application;

[0031] Figure 5 It is a schematic diagram of the continuous delivery pipeline provided by the embodiment of the present application;

[0032] Figure 6 It is a schematic diagram of the system architecture provided by the embodiment of the present application;

[0033] Figure 7 It is a flowchart of a special test process provided by an embodiment of the present application;

[0034] Figure 8 is a schematic diagram of the arrangement result provided by the embodiment of the present application;

[0035] Fig. 9 It is a schematic diagram of the special test steps provided in the embodiment of the present application;

[0036] Fig. 10A It is a schematic diagram of the pipeline platform interface provided by the embodiment of the present application;

[0037] Fig. 10BIt is another schematic diagram of the pipeline platform interface provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0039] In the following description, reference is made to "some embodiments", which describes a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. In the following description, reference is made to the term "multiple" to mean at least two.

[0040] In the following description, the terms "first\second" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0042] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0043] 1) Target business: refers to the business that needs to be tested. The embodiment of the present application does not limit the specific type of the target business. For example, the target business can be a business module in the software. The business module needs to be tested to ensure that the business module can operate normally when released.

[0044] 2) Test task: A collection of operations used to implement a specific type of test, where the specific type of test can be a test of functionality, performance, security, usability, etc.

[0045] 3) Call operation: used to call specific tools or code logic to perform testing. For example, if there is a special test tool, all operations on the test tool can be regarded as call operations, such as start operation, stop operation, query operation, etc. Call operation is a non-universal operation, that is, there are differences in call operations in different test tasks. The differences here essentially refer to the differences in tools or code logic called by different test tasks. For example, there are differences between the start operation of test tool A and the start operation of test tool B. Call operation is a component of the test task. In addition to call operation, the test task can also include non-call operation, which is a universal operation, such as the operation used to apply for the test environment.

[0046] 4) Pipeline: A set that defines how multiple serial and / or parallel steps are executed, and the output of the previous step is the input of the next step. In an embodiment of the present application, the pipeline includes two types: business pipeline and test pipeline. Among them, the business pipeline is used to define the production process of the target business. For example, in software development, the software production process includes continuous integration (CI), continuous delivery (CD) and continuous deployment (CD). The business pipeline can be a CI / CD pipeline, which defines how the CI / CD process is implemented through a series of steps. The test pipeline is used to define how to test in the production process of the target business.

[0047] 5) Encapsulation: In the embodiments of the present application, it refers to hiding the implementation details of the orchestration results and only exposing the interface to the outside. In this way, when the test pipeline obtained by encapsulating the orchestration results is triggered, there is no need to pay attention to the implementation details of the orchestration results, and multiple test tasks can be executed according to the orchestration results.

[0048] 6) In response to: used to indicate the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more operations executed may be in real time or have a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations executed are executed.

[0049] 7) Application Programming Interface (API): A predefined function or agreement that connects different components of a software system. Its purpose is to provide applications and developers with access to a set of routines based on certain software or hardware, without requiring developers to access the source code or understand the details of the internal working mechanism.

[0050] In the solutions provided by the related art, for the business to be tested, the testing work is usually distributed to multiple testers, and each tester writes the management and execution code for the test to test the part he is responsible for. After research, the inventor found that the solutions provided by the related art have at least the following problems: 1) When accessing new testing capabilities, it is necessary to consider which link to test and write the corresponding management and execution code, which is too costly and takes a lot of time; 2) There may be multiple repeated operations or conflicting operations, resulting in a waste of computing resources and low overall testing efficiency.

[0051] In view of this, the embodiments of the present application provide a test task processing method, apparatus, device and computer-readable storage medium, which can realize intelligent scheduling, improve overall test efficiency, and facilitate the rapid release of services. The following describes an exemplary application of the electronic device provided by the embodiments of the present application. The electronic device provided by the embodiments of the present application can be implemented as various types of terminal devices or as a server.

[0052] See also Figure 1 , Figure 1 1 is a schematic diagram of the architecture of the test task processing system 100 provided in an embodiment of the present application. The terminal device 400-1 is connected to the server 200-1 through the network 300-1, the terminal device 400-2 is connected to the server 200-2 through the network 300-2, and the server 200-1 is connected to the server 200-2 through the network 300-3. Figure 1 The network involved (referring to network 300 - 1 , network 300 - 2 or network 300 - 3 ) may be a wide area network or a local area network, or a combination of the two.

[0053] In some embodiments, taking the electronic device as a server as an example, the test task processing method provided in the embodiment of the present application can be implemented by the server. For example, server 200-1 is used to implement intelligent orchestration and pipeline management. Server 200-1 can determine multiple test tasks for the target business; perform operation splitting processing on each test task to obtain multiple call operations of each test task during execution; according to the logical relationship between different call operations, perform orchestration processing on the call operations corresponding to the multiple test tasks respectively to obtain an orchestration result that conforms to the logical relationship; encapsulate the orchestration result into the business pipeline corresponding to the target business as a test pipeline in the business pipeline. Among them, the business pipeline is generated by server 200-1 and also run by server 200-1. When server 200-1 executes the test pipeline in the business pipeline, multiple test tasks are executed according to the orchestration result.

[0054] For another example, server 200-1 is used to implement intelligent orchestration, such as through a dedicated test platform, and server 200-2 is used to implement pipeline management, such as through a dedicated pipeline platform. After obtaining the orchestration result, server 200-1 sends the orchestration result to server 200-2, so that server 200-2 encapsulates the received orchestration result into the business pipeline. Server 200-2 can execute the business pipeline, and when executing the test pipeline in the business pipeline, execute multiple test tasks according to the orchestration result.

[0055] In some embodiments, the test task processing method provided in the embodiments of the present application can be implemented by a server and a terminal device. For example, server 200-1 is used to implement intelligent orchestration and pipeline management. Terminal device 400-1 can register candidate test tasks to server 200-1, so that server 200-1 determines the test tasks of the target business among the registered multiple candidate test tasks, and performs relevant processing to obtain the orchestration results; server 200-1 can send the obtained orchestration results to terminal device 400-1, terminal device 400-1 displays the orchestration results, and sends the user's update operation for the displayed orchestration results to server 200-1, so that server 200-1 updates the orchestration results; server 200-1 can also send the execution progress and test results of the test pipeline to terminal device 400-1, so that terminal device 400-1 displays them.

[0056] For another example, server 200-1 is used to implement intelligent orchestration, and server 200-2 is used to implement pipeline management. Then terminal device 400-1 can register candidate test tasks to server 200-1, so that server 200-1 can determine the test tasks of the target business from the registered multiple candidate test tasks, and perform relevant processing to obtain the orchestration result; server 200-1 can send the obtained orchestration result to terminal device 400-1, terminal device 400-1 displays the orchestration result, and sends the user's update operation on the displayed orchestration result to server 200-1, so that server 200-1 updates the orchestration result; server 200-2 can send the execution progress and test results of the test pipeline to terminal device 400-2, so that terminal device 400-2 can display it.

[0057] The interaction between the terminal device 400-1 and the server 200-1 can be implemented through the client 410-1, such as the client of the test platform; the interaction between the terminal device 400-2 and the server 200-2 can be implemented through the client 410-2, such as the client of the pipeline platform.

[0058] In some embodiments, the terminal device or server can implement the test task processing method provided in the embodiments of the present application by running a computer program. For example, the computer program can be a native program or software module in the operating system; it can be a native application (APP, Application), that is, a program that needs to be installed in the operating system to run, such as an application of the test platform or an application of the pipeline platform (such as Figure 1 The computer program may be a client 410-1 or client 410-2); it may also be a small program, that is, a program that can be run by downloading it to a browser environment; it may also be a small program that can be embedded in any APP, wherein the small program can be controlled to run or closed by the user. In short, the computer program may be any form of application, module or plug-in.

[0059] In some embodiments, the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms, among which cloud services can be test task processing services for terminal devices to call. The terminal device can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart TV, a smart watch, etc., but is not limited to this. The terminal device and the server can be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiments of the present application.

[0060] See also Figure 2 , Figure 2 is a schematic diagram of the structure of a server (taking server 200-1 as an example) provided in an embodiment of the present application. Figure 2 The server 200-1 shown includes: at least one processor 210, a memory 250 and at least one network interface 220. The various components in the server 200 are coupled together via a bus system 240. It is understood that the bus system 240 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 240 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 240 is not described in detail. Figure 2 Various buses are labeled as bus system 240 .

[0061] The processor 210 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0062] The memory 250 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 250 may optionally include one or more storage devices that are physically remote from the processor 210.

[0063] The memory 250 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 250 described in the embodiments of the present application is intended to include any suitable type of memory.

[0064] In some embodiments, memory 250 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0065] Operating system 251, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0066] A network communication module 252, used to reach other computing devices via one or more (wired or wireless) network interfaces 220, exemplary network interfaces 220 include: Bluetooth, Wireless Compatibility Certification (WiFi), and Universal Serial Bus (USB);

[0067] In some embodiments, the test task processing device provided in the embodiments of the present application can be implemented in a software manner. Figure 2 The test task processing device 255 stored in the memory 250 is shown, which can be software in the form of a program and a plug-in, etc., including the following software modules: a task determination module 2551, an operation splitting module 2552, an arrangement module 2553 and an encapsulation module 2554. These modules are logical, so they can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be explained below.

[0068] The test task processing method provided by the embodiment of the present application will be described in combination with the exemplary application and implementation of the electronic device provided by the embodiment of the present application. For example, the test task processing method provided by the embodiment of the present application can be Figure 1 The server 200-1 is shown as an implementation.

[0069] See also Figure 3A , Figure 3A This is a flow chart of a test task processing method provided by an embodiment of the present application, which will be combined with Figure 3A The steps shown are explained.

[0070] In step 101, multiple test tasks of a target business are determined.

[0071] Here, the target business refers to the business that needs to be tested. The embodiment of the present application does not limit the specific type of the target business. For example, the target business may be a business module of a certain software, and the business module needs to be tested to ensure that the business module can operate normally after release.

[0072] During the test process, the multiple required test tasks are first determined. A test task refers to a collection of a series of operations used to implement a specific type of test. In some embodiments, a registration request for registering a candidate test task can be received, and the candidate test task can be registered. In this way, when it is necessary to test the target business, the test task of the target business is determined from the multiple registered candidate test tasks. For example, some candidate test tasks are screened out as test tasks for the target business, or all candidate test tasks are used as test tasks for the target business. Among them, the candidate test tasks can be reused for different businesses, or they can be set specifically for the target business.

[0073] In some embodiments, the above-mentioned determination of multiple test tasks for the target business can be implemented in the following manner: determining multiple candidate test tasks; screening and processing the multiple candidate test tasks according to task screening conditions to obtain test tasks for the target business; wherein the task screening conditions include at least one of the following: the execution status of the candidate test task is executable; the candidate test task is specified by a test request for testing the target business; the candidate test task corresponds to a business type of the target business; wherein each candidate test task corresponds to at least one business type.

[0074] Here, the test task of the target business may be determined from a plurality of registered candidate test tasks, and the screening condition may include at least one of the following:

[0075] 1) The execution status of the candidate test task is executable. Each candidate test task has an execution status, which includes executable and non-executable. Therefore, the candidate test task with an executable execution status can be used as the test task of the target business. Among them, the execution status of the candidate test task can be determined according to the online status of the tool or code logic called by the candidate test task. For example, if the tool called by a candidate test task is not online (i.e., it cannot be called), the execution status of the candidate test task is determined to be non-executable; if the tool called by a candidate test task is online (i.e., it can be called), the execution status of the candidate test task is determined to be executable. The execution status of the candidate test task can also be determined according to the execution effect index of the candidate test task in history (one or more historical executions). The larger the value of the execution effect index, the better the execution effect. For example, when the execution effect index of a candidate test task is less than the index threshold, the execution status of the candidate test task is determined to be non-executable; when the execution effect index of a candidate test task is greater than or equal to the index threshold, the execution status of the candidate test task is determined to be executable. The above methods for determining the execution status are only examples. In actual application scenarios, the execution status may be determined by other methods, such as manual setting. Through the above screening condition 1), the execution effect of the test task of the target business can be guaranteed as much as possible, and the test success rate can be improved.

[0076] 2) The candidate test task is specified by the test request for testing the target business. The situation referred to here is that when a test request for testing the target business is received, the candidate test task specified in the test request is used as the test business of the target business. For example, the test request may include a task identifier, and the candidate test task corresponding to the task identifier is the candidate test task specified by the test request. Through the above-mentioned screening condition 2), the test task can be specified according to the needs in the actual application scenario, thereby enhancing the targeted nature of the test.

[0077] 3) The candidate test tasks correspond to the business types of the target business; wherein each candidate test task corresponds to at least one business type. Here, a correspondence between the candidate test tasks and the business types can be established in advance, wherein each candidate test task corresponds to at least one business type. Then, the candidate test tasks corresponding to the business type of the target business are screened out from all the candidate test tasks to serve as the test tasks for the target business. Through the above-mentioned screening condition 3), it can be ensured that the screened test tasks meet the actual business conditions of the target business, improve the effectiveness of the test, and avoid problems such as excessive testing time and waste of computing resources due to invalid testing.

[0078] It is worth noting that, according to the needs of the actual application scenarios, the above-mentioned filtering conditions 1), 2), and 3) can be used any one or in combination. For example, when the filtering conditions 1), 2), and 3) are used in combination, the filtered test tasks refer to candidate test tasks whose execution status is executable, specified by the test request, and corresponding to the business type of the target business.

[0079] In step 102, operation splitting processing is performed on each test task to obtain multiple calling operations of each test task during execution.

[0080] Since a test task refers to a collection of operations used to implement a specific type of test, the operations are split here to obtain multiple calling operations for each test task during its execution. For example, the operations in the test task used to call specific test tools or code logic (which can be embodied in code or other forms) can be used as calling operations.

[0081] In some embodiments, the above-mentioned operation splitting processing for each test task can be implemented in such a way as to obtain multiple calling operations for each test task during the execution process: For any test task, perform the following processing: When any test task belongs to a non-continuous task, split any test task into a start operation and a query operation; when any test task belongs to a continuous task, split any test task into a start operation, a stop operation and a query operation; wherein, the start operation, the stop operation and the query operation are all calling operations.

[0082] Here, the test tasks can be divided into non-continuous tasks and continuous tasks. Non-continuous tasks refer to tasks that are executed once and automatically stopped (actively stopped), such as business execution type tasks or result inspection type tasks; continuous tasks refer to tasks that are continuously executed until passively stopped, such as detection type tasks that require continuous detection. For non-continuous tasks, since they do not include stop operations, they are split into start operations (or execution operations) and query operations, where the start operation is used to start a specific test tool or code logic, and the query operation is used to query the return results of a specific test tool or code logic; for continuous tasks, they are split into start operations, stop operations and query operations, where the stop operation is used to stop the execution of a specific test tool or code logic. In the above manner, the splitting strategy of different types of test tasks is clarified, which is convenient for subsequent accurate arrangement.

[0083] In some embodiments, between any steps, the method also includes: receiving an operation registration request; wherein the operation registration request includes a candidate call operation configured for the target test task; and in response to the operation registration request, registering the candidate call operation configured for the target test task as the call operation of the target test task.

[0084] Here, in addition to the mobilization operation included in the test task itself, the registration of additional call operations can also be supported. For example, an operation registration request is received, and the operation registration request includes a candidate call operation configured for a target test task, the target test task represents any one of multiple test tasks, and the candidate call operation can be a user-defined operation. In response to the operation registration request, the candidate call operation included in the operation registration request is registered as the call operation of the target test task. In this way, the addition of the call operation included in the test task can be realized.

[0085] It is worth noting that the candidate call operation can be shared, that is, the candidate call operation can be registered as the call operation of any one or more test tasks.

[0086] In addition, the call operation in the test task can also be modified or deleted. For example, an operation modification request is received, and the operation modification request includes a second call operation configured for the first call operation in the target test task; in response to the operation modification request, the first call operation in the target test task is updated to the second call operation, wherein the first call operation represents the original call operation in the target test task, and the second call operation represents the new call operation. For another example, an operation deletion request is received, and the operation deletion request specifies the call operation to be deleted in the target test task; in response to the operation deletion request, the call operation specified by the operation deletion request in the target test task is deleted.

[0087] It is worth noting that the above-mentioned operation registration, operation modification and operation deletion can also be applied to non-call operations.

[0088] In step 103, according to the logical relationship between different calling operations, the calling operations corresponding to the multiple test tasks are arranged and processed to obtain an arrangement result that complies with the logical relationship.

[0089] For multiple call operations obtained through operation splitting, the logical relationships between different call operations are determined, such as sharing relationships, conflict relationships, association relationships, etc. The multiple call operations are orchestrated according to the determined logical relationships to obtain orchestration results that conform to the logical relationships, wherein the orchestration results define how the multiple call operations should be executed. In this way, the orderliness of the call operations during execution is enhanced through intelligent orchestration.

[0090] It is worth noting that the logical relationship between various calling operations can be pre-set according to various possible task types. In this way, in step 103, the corresponding logical relationship can be determined and arranged according to the task type to which the test task belongs. Among them, the task type to which the test task belongs can be manually selected (for example, manually configured by the user), or it can be obtained by identifying the test task, for example, matching the name of the test task with the names of multiple task types for similarity, and taking the task type with the highest similarity as the task type to which the test task belongs. In the case where the calling operation is used to call a test tool, the task type to which the test task belongs can also be the tool type of the test tool called by the test task.

[0091] In some embodiments, non-call operations of each test task during execution are obtained through operation splitting processing; the orchestration result also includes at least one shared test step; during the orchestration processing, the method also includes: according to the non-call operation type to which the non-call operation belongs, the non-call operation is orchestrated into the shared test step corresponding to the non-call operation type; wherein each shared test step corresponds to a non-call operation type.

[0092] For test tasks, in addition to call operations, non-call operations are also included. Non-call operation types may include application environment (referring to application test environment), execution use cases, result summary, and release environment, etc. Since the operation methods of the same type of non-call operations in different test tasks are the same or similar, at least one shared test step can be created in the orchestration template, and each shared test step corresponds to a non-call operation type, wherein the orchestration template is used to accommodate call operations and non-call operations, and the orchestration template after the completion of the orchestration is the orchestration result. For each non-call operation obtained by splitting, the non-call operation is orchestrated into the shared test step corresponding to the non-call operation type according to the non-call operation type to which the non-call operation belongs. In this way, in the obtained orchestration result, executing the shared test step is equivalent to executing all non-call operations of the corresponding type of the shared test step, which can achieve unified processing and effectively improve the execution efficiency of the non-call operation.

[0093] In some embodiments, after step 103, the method further includes: displaying the arrangement result, and updating the arrangement result in response to an update operation on the arrangement result.

[0094] After obtaining the arrangement result, the arrangement result can also be displayed, for example, on the client of the terminal device. Then, an update operation for the displayed arrangement result is received, such as deleting certain operations or adjusting the order of certain operations. In response to the update operation, the arrangement result is updated accordingly. In the above manner, the user can be supported to freely modify the arrangement result, thereby improving the flexibility of the test.

[0095] In step 104, the orchestration result is encapsulated into the business pipeline corresponding to the target business to serve as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, multiple test tasks are executed according to the orchestration result.

[0096] The target business corresponds to a business pipeline, which is used to define the production process of the target business. In an embodiment of the present application, the orchestration result is encapsulated into the business pipeline corresponding to the target business as a test pipeline in the business pipeline, that is, a test pipeline is created in the business pipeline according to the orchestration result, and the test pipeline is used as a step in the business pipeline. In this way, when the test pipeline is executed, that is, when the test pipeline is triggered, there is no need to pay attention to the implementation details of the test pipeline, and multiple test tasks can be executed according to the orchestration results.

[0097] It is worth noting that for various operations involved in the embodiments of the present application, the execution can be indicated by corresponding operation parameters. The operation parameters may include the identifier of the called object and the operation type. Taking the called object as a test tool as an example, the operation parameters may be {tool ID: xxxx, tool call type: start}, and when the server reads the operation parameters, it executes the operation of starting the test tool. On this basis, the test task may include operation parameters corresponding to multiple operations respectively; the orchestration process may refer to the orchestration process of the operation parameters, and the orchestration result obtained by the orchestration process includes the orderly arranged operation parameters; when executing the test pipeline, the operation parameters in the orchestration result may be read in sequence, and the corresponding operation is performed according to the read operation parameters.

[0098] It is worth noting that the embodiment of the present application does not limit the position of the test pipeline in the business pipeline, and can be set according to the needs of the actual production process. For example, the test pipeline can be located between the compilation and construction step and the branch merging step of the business pipeline.

[0099] In some embodiments, the calling operation is used to call the test tool; after step 104, it also includes: obtaining business parameters of the target business; sending the business parameters to the corresponding test tool, so that the test tool performs test processing according to the business parameters when called by the calling operation.

[0100] Here, the call operation is used to call the test tool. During the execution of the test pipeline, the business parameters of the target business (such as the name of the target business) can be obtained, and the business parameters can be sent to the test tool involved in the test pipeline. In this way, the test tool can perform test processing according to the business parameters, such as detecting the operation of the target business. The embodiment of the present application does not limit how the test tool uses the business parameters to perform test processing, which can be determined according to the type of test tool. In this way, the test tool can be helped to lock the target to be tested, thereby improving the test success rate.

[0101] In some embodiments, during the process of executing multiple test tasks according to the arrangement results, at least one of the execution progress and the execution result is displayed. Here, during the test process, at least one of the execution progress and the execution result can be displayed, the execution progress is such as which test task is currently executed, and the execution result is the execution result of the test task, such as the data detected by the test task used for detection. In this way, it is convenient for users to intuitively understand the actual situation of the test.

[0102] like Figure 3A As shown, the embodiment of the present application splits each test task required for testing the target business into multiple call operations, intelligently arranges all the call operations obtained, obtains the arrangement results that conform to the logical relationship, and tests according to the arrangement results. In this way, the orderliness of the call operation during execution can be enhanced, the waste of computing resources (such as the waste of computing resources caused by repeated execution of the call operation or long waiting) can be reduced, and the situation of repeated execution or inability to execute the call operation due to logical problems can be effectively avoided. On this basis, the arrangement results are encapsulated as a test pipeline, and the test pipeline is called as a step in the business pipeline, so as to ensure that the test is carried out according to the arrangement results in the business production process (such as the release and launch process of the target business), that is, the test work is completed automatically and accurately, the overall test efficiency is improved, and it is conducive to the rapid release of the business.

[0103] In some embodiments, see Figure 3B , Figure 3B is a flow chart of a test task processing method provided in an embodiment of the present application. Figure 3A The illustrated step 103 can be implemented through steps 201 to 203 , which will be described in conjunction with each step.

[0104] In step 201, an orchestration template is created; wherein the orchestration template includes multiple stages.

[0105] In the orchestration process, firstly, an orchestration template is created, which includes multiple pre-set stages, such as a preparation stage, an execution stage, and an end stage. The created orchestration template is used to accommodate the call operation, that is, according to the logical relationship between the call operations, the call operation is placed in a certain position in a certain stage.

[0106] In the case where non-call operations are obtained through operation splitting processing, the orchestration template also includes several shared test steps, and the shared test steps are used to accommodate non-call operations. The relationship between the shared test steps and the stages can be set according to the actual application scenario. For example, the shared test steps for applying for the environment can be set to be in the preparation stage, the shared test steps for executing the use case can be set to be in the execution stage, and the shared test steps for result summary and release of the environment can be set to be in the end stage. On this basis, the position of each shared test step in the corresponding stage and the logical relationship between it and the call operation of the corresponding stage can also be set. For example, the shared test step for applying for the environment is the first step in the preparation stage, and the logical relationship between it and the call operation of the preparation stage is an association relationship; the logical relationship between the shared test step for executing the use case and the call operation of the execution stage is a sharing relationship, that is, all steps in the execution stage are performed in parallel; the shared test step for result summary and release of the environment is the last step in the end stage, and the logical relationship between it and the call operation of the end stage is an association relationship.

[0107] In step 202, according to the internal logical relationship between the multiple call operations belonging to the same test task, stage orchestration processing is performed on the multiple call operations belonging to the same test task in the orchestration template.

[0108] The logical relationship in the embodiment of the present application may include two types: internal logical relationship between multiple call operations belonging to the same test task, and external logical relationship between multiple call operations belonging to different test tasks.

[0109] First, implement stage arrangement processing according to the internal logical relationship. For example, for any test task, according to the internal logical relationship between the multiple call operations belonging to the test task, perform stage arrangement processing on the multiple call operations belonging to the test task in the arrangement template, that is, arrange the call operations into corresponding stages in sequence according to the internal logical relationship, so as to ensure the orderly execution of the call operations within a single test task. The stage to be arranged can be fixed or determined according to the task type of the test task.

[0110] The internal logical relationship is defined in the test task, and may include at least one of the sharing relationship, association relationship, and conflict relationship. Taking any two operations as an example, the sharing relationship means that both operations depend on the output of the previous step, and the order corresponding to the sharing relationship in the sequence arrangement is a parallel order; the association relationship means that the latter operation depends on the output of the previous operation, and the order corresponding to the association relationship in the sequence arrangement is a serial order; the conflict relationship means that the two operations cannot be executed at the same time due to data conflicts or environmental conflicts, and the order corresponding to the conflict relationship in the sequence arrangement is a serial order. For example, a test task includes a start operation, a stop operation, and a query operation. The stop operation depends on the start operation (it can only be stopped after starting), and the query operation depends on the stop operation (it can only be queried after stopping by default). Then the start operation and the stop operation, as well as the stop operation and the query operation are all association relationships, and the start operation, stop operation, and query operation need to be executed in sequence in a serial order.

[0111] In some embodiments, the above-mentioned stage orchestration processing of multiple call operations belonging to the same test task in the orchestration template according to the internal logical relationship between the multiple call operations belonging to the same test task can be achieved in the following way: according to the task type of the same test task, determining the associated stage associated with the task type from multiple stages; according to the internal logical relationship between the multiple call operations belonging to the same test task, arranging the multiple call operations belonging to the same test task in sequence into the associated stages.

[0112] Here, according to the task type to which the test task belongs, the associated stage associated with the task type can be determined in multiple stages, wherein the association relationship between the stage and the task type can be set according to the actual application scenario. For example, the task type can include a business execution type, a detection type, and a result inspection type. For the business execution type, since it does not require preparation and the execution result needs to be queried after the execution is completed, the associated stage includes the execution stage and the end stage; for the detection type, since it does not execute itself but detects the execution process, the associated stage includes the preparation stage and the end stage; for the result inspection type, no preparation is required and there is no need to pay attention to the execution, so the associated stage only includes the end stage.

[0113] On the basis of the determined associated phases of the test task, the multiple call operations are arranged in sequence into the associated phases according to the internal logical relationship between the multiple call operations belonging to the test task. If there is only one associated phase, the multiple call operations are placed in the associated phase and arranged in sequence according to the internal logical relationship; if there are multiple associated phases, it is also necessary to determine the one-to-one correspondence between the call operations and the associated phases, and place each call operation in the corresponding phase according to the correspondence, and then arrange the call operations in different associated phases in sequence according to the internal logical relationship (for example, arrange two call operations in different associated phases into a serial order, or arrange two call operations in a certain associated phase into a parallel order). The correspondence between the calling operation and the associated phase can be specifically set according to the task type of the test task. For example, if the task type of the test task is a business execution type, and the calling operation includes a start operation and a query operation, then the start operation can be set to correspond to the execution phase, and the query operation can be set to correspond to the end phase; for another example, if the task type of the test task is a detection type, and the calling operation includes a start operation, a stop operation, and a query operation, then the start operation can be set to correspond to the preparation phase, and the stop operation and the query operation can both correspond to the end phase; for another example, if the task type of the test task is a result inspection type, and the calling operation includes a start operation and a query operation, then the start operation and the query operation can both correspond to the end phase. In the above manner, setting the associated phase based on the characteristics of the task type to which the test task belongs can improve the rationality of phase arrangement.

[0114] In step 203, according to the external logical relationship between multiple call operations respectively belonging to different test tasks, the call operations that have been arranged into the arrangement template are sequentially arranged to obtain an arrangement result.

[0115] After performing stage orchestration processing for each test task, it is also necessary to consider the external logical relationship between multiple call operations belonging to different test tasks, that is, to perform sequential orchestration processing on the call operations that have been orchestrated into the orchestration template according to the external logical relationship to obtain the orchestration result, so as to avoid mutual interference between the call operations belonging to different test tasks. Among them, the external logical relationship can be set according to the task type to which the test task belongs and the type of call operation included. The external logical relationship can include at least one of a sharing relationship, an association relationship and a conflict relationship. For example, the stop operation in the test task of the detection type and the start operation in the test task of the result check type can be set as a sharing relationship, that is, the result obtained by sharing the business execution; the start operation in the test task of the result check type and the start operation in the test task of the business execution type can be set as an association relationship, that is, the start of the result check depends on the start of the business execution.

[0116] In some embodiments, the above-mentioned sequential orchestration processing of the call operations that have been orchestrated into the orchestration template according to the external logical relationship between multiple call operations that belong to different test tasks can be achieved in the following way: for any two call operations that belong to different test tasks, the following processing is performed: when the external logical relationship between any two call operations is a sharing relationship, the any two call operations are orchestrated in parallel; when the external logical relationship between any two call operations is an association relationship or a conflict relationship, the any two call operations are orchestrated in series.

[0117] Here, any two calling operations, namely, calling operation A and calling operation B, are taken as an example for explanation, wherein calling operation A and calling operation B belong to different test tasks respectively.

[0118] When the external logical relationship between calling operation A and calling operation B is a sharing relationship, since the output of the previous step can be shared, calling operation A and calling operation B are arranged in parallel, that is, the order between calling operation A and calling operation B is a parallel order, thereby improving execution efficiency; when the external logical relationship between calling operation A and calling operation B is an association relationship or a conflict relationship, since calling operation A and calling operation B cannot be executed at the same time, calling operation A and calling operation B are arranged in series, so that calling operation A and calling operation B are executed in sequence, avoiding problems such as execution failure or excessive execution time caused by mutual interference of operations.

[0119] like Figure 3B As shown, the embodiment of the present application implements intelligent orchestration based on an orchestration template including multiple stages. For each test task, according to the internal logical relationship between the multiple call operations belonging to the test task, the multiple call operations are respectively orchestrated into the associated associated stages in the orchestration template. In this way, from the perspective of a single test task, the operational orderliness of the single test task can be guaranteed; further, according to the external logical relationship between the multiple call operations respectively belonging to different test tasks, the call operations that have been orchestrated into the orchestration template are sequentially orchestrated. In this way, from the perspective of a single test task to the perspective of all test tasks, different test tasks can be taken into account, the orchestration effect can be improved, and conflicts between different test tasks during execution can be effectively avoided.

[0120] In some embodiments, see Figure 3C , Figure 3C This is a flow chart of a test task processing method provided in an embodiment of the present application, based on Figure 3A After step 103, in step 301, the arrangement result can be matched with the historical arrangement result; wherein the historical arrangement result has been packaged to obtain the historical test pipeline.

[0121] After the orchestration result is obtained through the orchestration process, the orchestration result can be matched with the historical orchestration result to obtain a matching result, wherein the historical orchestration result refers to the orchestration result obtained in the past and the historical test pipeline has been encapsulated.

[0122] Here, the conditions for successful or failed matching can be set according to the actual application scenario. For example, when the arrangement result is completely consistent with the historical arrangement result, the matching result is determined to be a successful matching; when the arrangement result is different from the historical arrangement result, the matching result is determined to be a failed matching.

[0123] In step 302, when the orchestration result successfully matches the historical orchestration result, the historical test pipeline corresponding to the historical orchestration result is reused in the business pipeline; wherein, when the historical test pipeline in the business pipeline is triggered, multiple test tasks are executed according to the historical orchestration result.

[0124] When the orchestration result matches the historical orchestration result successfully, the historical test pipeline corresponding to the historical orchestration result is reused in the business pipeline without creating a test pipeline based on the orchestration result. This can reduce resource waste without adversely affecting test efficiency.

[0125] In this way, the obtained business pipeline includes a historical test pipeline. When the historical test pipeline is triggered, that is, when the historical test pipeline is executed, multiple test tasks are executed according to the historical arrangement results.

[0126] In some embodiments, the above-mentioned matching of the orchestration result with the historical orchestration result can be achieved in the following manner: obtaining the correspondence between the hash value of the historical orchestration result and the pipeline identifier of the historical test pipeline; performing hash processing on the orchestration result to obtain the hash value of the orchestration result; matching the hash value of the orchestration result with the hash value of the historical orchestration result; the above-mentioned multiplexing of the historical test pipeline corresponding to the historical orchestration result into the business pipeline can be achieved in the following manner: performing query processing in the correspondence according to the successfully matched hash value, and multiplexing the historical test pipeline corresponding to the queried pipeline identifier into the business pipeline.

[0127] Here, the correspondence between the hash value of the historical arrangement result and the pipeline identifier of the historical test pipeline can be obtained first, wherein the hash value of the historical arrangement result is obtained by hashing the historical arrangement result through a hash algorithm, and can uniquely identify the historical arrangement result. For ease of explanation, an example is given in which the correspondence includes "hash value 1-pipeline identifier 1" and "hash value 2-pipeline identifier 2".

[0128] For the arrangement result obtained by the current arrangement processing, the arrangement result is also hashed by the hash algorithm to obtain the hash value of the arrangement result. The hash algorithm used here is the same as the hash algorithm used for the historical arrangement result. Then, the hash value of the arrangement result is matched with the hash values ​​of all the historical arrangement results (such as the hash value 1 and the hash value 2 above). When the hash value of the arrangement result is the same as the hash value of any historical arrangement result, the matching result is determined to be a successful match; when the hash value of the arrangement result is different from the hash value of all the historical arrangement results, the matching result is determined to be a failed match. The matching result here is the matching result between the hash values, and it is also the matching result between the arrangement result and the historical arrangement result.

[0129] When the hash value of the orchestration result is the same as the hash value of any historical orchestration result, that is, the match is successful, a query is performed in the corresponding relationship based on the successfully matched hash value, and the historical test pipeline corresponding to the queried pipeline identifier is reused in the business pipeline. For example, if the hash value of the orchestration result is the same as the above-mentioned hash value 1, a query is performed in the corresponding relationship based on hash value 1 to obtain pipeline identifier 1, and then the historical test pipeline corresponding to pipeline identifier 1 is reused in the business pipeline. Since the hash algorithm is a compression mapping algorithm, the hash value matching speed is fast, and the accuracy of the matching result can also be guaranteed.

[0130] exist Figure 3C middle, Figure 3A Step 104 shown can be updated to step 303. In step 303, when the orchestration result fails to match the historical orchestration result, the orchestration result is encapsulated into the business pipeline as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, multiple test tasks are executed according to the orchestration result.

[0131] When the orchestration result fails to match the historical orchestration result, it proves that the test purpose cannot be achieved based on the historical orchestration result. Therefore, the orchestration result is encapsulated into the business pipeline as a test pipeline in the business pipeline.

[0132] like Figure 3C As shown, the embodiment of the present application supports the reuse of historical test pipelines, that is, when the orchestration result successfully matches the historical orchestration result, the historical test pipeline corresponding to the historical orchestration result is reused into the business pipeline, thereby ensuring the test efficiency and success rate without creating duplicate test pipelines, which can effectively reduce resource waste.

[0133] In some embodiments, see Figure 3D , Figure 3D This is a flow chart of a test task processing method provided in an embodiment of the present application, based on Figure 3AAfter step 104, in step 401, execution effect indicators corresponding to multiple test tasks may be obtained.

[0134] Here, after the test pipeline is executed once or multiple times, the execution effect indicators corresponding to the multiple test tasks can be obtained. The execution effect indicators are used to evaluate the execution effect of the test tasks. The larger the execution effect indicator, the better the execution effect. The execution effect indicator can be determined based on at least one of the factors such as the execution success rate and the execution time. For example, the execution success rate can be used as the execution effect indicator, and the inverse of the execution time can also be used as the execution effect indicator.

[0135] In some embodiments, the execution effect index of the call operation in the test task is obtained as the execution effect index corresponding to the test task. Since the differences between different test tasks are mainly reflected in the differences in the call operations, the execution effect index of the call operation in the test task can be obtained as the execution effect index corresponding to the test task, so that the execution effect of the test task can be measured more accurately.

[0136] In step 402, the scheduling result is updated according to the test tasks whose execution effect index is less than the index threshold.

[0137] Test tasks whose execution effect indicators are less than the indicator threshold are screened out from multiple test tasks. The fact that the execution effect indicators are less than the indicator threshold proves that the execution effect does not meet expectations. Therefore, the orchestration results are updated according to the screened test tasks, that is, operations related to the screened test tasks are adjusted in the orchestration results.

[0138] In some embodiments, the above-mentioned updating of the orchestration result according to the test task whose execution effect index is less than the index threshold can be achieved in the following manner: performing any one of the following processing: deleting the target call operation in the orchestration result; configuring constraint conditions for the target call operation in the orchestration result, so that when the target call operation is executed, the execution process of the target call operation is constrained according to the constraint conditions; wherein the target call operation represents the call operation corresponding to the test task whose execution effect index is less than the index threshold.

[0139] For the sake of convenience, the call operation corresponding to the test task whose execution effect index is less than the index threshold is named as the target call operation. Then updating the orchestration result according to the test task whose execution effect index is less than the index threshold can refer to any of the following situations:

[0140] 1) Delete the target call operation in the orchestration result. Here, during the test process, you can directly not execute the test task whose execution effect index is less than the index threshold, that is, delete the target call operation in the orchestration result. If the orchestration result also includes the target non-call operation, then the target non-call operation can be deleted without affecting other test tasks. The target non-call operation refers to the non-call operation corresponding to the test task whose execution effect index is less than the index threshold. This method can greatly improve the execution effect of the new test pipeline by abandoning the test tasks with poor execution effect.

[0141] For test tasks whose execution effect index is less than the index threshold, the related operations can be optimized, and after the optimization is completed, they can be re-involved in the orchestration process to obtain new orchestration results.

[0142] 2) In the orchestration result, constraints are configured for the target call operation, so that when the target call operation is executed, the execution process of the target call operation is constrained according to the constraints. Here, the execution process of the target call operation can be constrained by constraints. The purpose of constraint processing is to prevent the execution process of the target call operation from causing adverse effects on the execution process of the entire test pipeline. For example, constraints can be used to constrain the execution time of the target call operation. Once the execution time of the target call operation reaches a threshold, the execution of the target call operation is directly stopped. This method balances the test purpose and the execution effect, and to a certain extent retains the test tasks with poor execution effect, thereby avoiding the loss of test capabilities.

[0143] In step 403, the updated orchestration result is encapsulated into the business pipeline to replace the original test pipeline in the business pipeline.

[0144] The updated orchestration result is repackaged into the business pipeline to replace the original test pipeline in the business pipeline (ie, the test pipeline packaged according to the orchestration result before the update).

[0145] like Figure 3D As shown, the embodiment of the present application evaluates the execution effect of each test task, that is, measures the execution effect of the test task through a quantitative execution effect indicator, and updates the orchestration results according to the test tasks with poor execution effects, thereby improving the execution effect of subsequent test processes based on historical experience and reducing the adverse effects of individual test tasks with poor execution effects on the entire test process.

[0146] The test task processing method provided by the embodiment of the present application will be described in combination with the exemplary application and implementation of the electronic device provided by the embodiment of the present application. For example, the test task processing method provided by the embodiment of the present application can be Figure 1 The server 200 - 1 and the server 200 - 2 shown are implemented together.

[0147] See also Figure 4 , Figure 4 This is a flow chart of a test task processing method provided by an embodiment of the present application, which will be combined with Figure 4 The steps shown are explained.

[0148] In step 501, the test platform determines a plurality of test tasks for a target service.

[0149] Figure 1 The server 200-1 in the example can serve as both a test platform and a pipeline platform; or the server 200-1 can run the test platform, and the server 200-2 can run the pipeline platform, and the test task processing is performed through the interaction between the server 200-1 and the server 200-2. In the latter case, the test platform run by the server 200-1 first determines multiple test tasks of the target business. For example, the test platform selects the test tasks of the target business from multiple registered candidate test tasks.

[0150] In some embodiments, the step of the test platform determining multiple test tasks for the target service may be triggered by the pipeline platform. For example, when the pipeline platform receives a test request for testing the target service, it notifies the test platform to determine multiple test tasks for the target service.

[0151] In step 502, the test platform performs operation splitting processing on each test task to obtain multiple call operations of each test task during execution.

[0152] In step 503, the test platform arranges the call operations corresponding to the multiple test tasks according to the logical relationship between different call operations, and obtains an arrangement result that conforms to the logical relationship.

[0153] In step 504, the test platform sends the orchestration result to the pipeline platform.

[0154] Here, the pipeline platform is used to manage the pipeline, so the test platform sends the orchestration results to the pipeline platform.

[0155] In some embodiments, after step 503, it also includes: the test platform matches the orchestration result with the historical orchestration result; wherein the historical orchestration result has been encapsulated to obtain a historical test pipeline; when the orchestration result successfully matches the historical orchestration result, the test platform notifies the pipeline platform to reuse the historical test pipeline corresponding to the historical orchestration result in the business pipeline; the above-mentioned test platform sending the orchestration result to the pipeline platform can be implemented in the following way: when the orchestration result fails to match the historical orchestration result, the test platform sends the orchestration result to the pipeline platform.

[0156] Here, the test platform stores historical orchestration results. After the orchestration results are obtained through orchestration processing, the orchestration results are matched with the historical orchestration results. When the orchestration results match the historical orchestration results successfully, the test platform notifies the pipeline platform to reuse the historical test pipeline corresponding to the historical orchestration results in the business pipeline, without the need to recreate the test pipeline in the pipeline platform, which can effectively save resources; when the orchestration results fail to match the historical orchestration results, the test platform sends the orchestration results to the pipeline platform, and the pipeline platform creates a test pipeline based on the orchestration results.

[0157] In some embodiments, the above-mentioned test platform can be implemented by matching the orchestration result with the historical orchestration result in the following manner: the test platform obtains the correspondence between the hash value of the historical orchestration result and the pipeline identifier of the historical test pipeline; the test platform hashes the orchestration result to obtain the hash value of the orchestration result; the test platform matches the hash value of the orchestration result with the hash value of the historical orchestration result; the above-mentioned test platform can be implemented by notifying the pipeline platform that the historical test pipeline corresponding to the historical orchestration result is reused in the business pipeline in the following manner: query processing is performed in the corresponding relationship according to the successfully matched hash value, and the queried pipeline identifier is sent to the pipeline platform, so that the pipeline platform reuses the historical test pipeline corresponding to the pipeline identifier into the business pipeline.

[0158] Here, the test platform stores the correspondence between the hash value of the historical orchestration result and the pipeline identifier of the historical test pipeline, wherein the pipeline identifier is sent to the test platform by the pipeline platform after creating the historical test pipeline. The test platform performs hash processing on the orchestration result to obtain the hash value of the orchestration result, and then matches the hash value of the orchestration result with the hash value of the historical orchestration result. If the match is successful, the test platform performs query processing in the above-mentioned correspondence according to the hash value of the successful match, and sends the queried pipeline identifier to the pipeline platform. When the pipeline platform receives the pipeline identifier, it can determine the historical test pipeline corresponding to the pipeline identifier and reuse it in the business pipeline. In this way, the reuse of the test pipeline is achieved through the interaction between the test platform and the pipeline platform, which can effectively save resources.

[0159] In some embodiments, after step 504, the process further includes: the pipeline platform displays the orchestration result, and sends an update operation for the orchestration result to the test platform; and the test platform updates the orchestration result according to the received update operation.

[0160] Here, the pipeline platform can display the received orchestration results, for example, Figure 1In the example, the pipeline platform can send the orchestration result to the client 410-2 of the terminal device 400-2 for display, and the terminal device 400-2 can send the received update operation for the orchestration result to the pipeline platform, which is forwarded to the test platform via the pipeline platform. The test platform updates the orchestration result according to the update operation and sends the updated orchestration result to the pipeline platform again. In the above manner, it is convenient for users of the pipeline platform to freely modify the orchestration result, thereby improving the test flexibility.

[0161] In step 505, the pipeline platform encapsulates the orchestration result into the business pipeline corresponding to the target business as a test pipeline in the business pipeline.

[0162] The pipeline platform encapsulates the received orchestration results into the business pipeline corresponding to the target business as a test pipeline in the business pipeline. The business pipeline is generated and managed by the pipeline platform.

[0163] That is, "packaging the orchestration result into the business pipeline corresponding to the target business" referred to in step 104 may refer to the process in which the test platform sends the orchestration result to the pipeline platform so that the pipeline platform performs packaging.

[0164] In step 506, the pipeline platform executes the business pipeline, wherein when the test pipeline in the business pipeline is triggered, multiple test tasks are executed according to the orchestration result.

[0165] The pipeline platform executes the business pipeline, and when executing the test pipeline in the business pipeline, it executes multiple test tasks according to the orchestration results. In the case where the call operation is used to call the test tool, the pipeline platform can obtain the business parameters of the target business and send the business parameters to the corresponding test tool, so that the test tool performs test processing according to the business parameters when it is called by the call operation.

[0166] In some embodiments, after step 506, it also includes: the pipeline platform obtains execution effect indicators corresponding to multiple test tasks respectively, and sends them to the test platform; the test platform updates the orchestration results according to the test tasks whose execution effect indicators are less than the indicator threshold, and sends the updated orchestration results to the pipeline platform; the pipeline platform encapsulates the updated orchestration results into the business pipeline to replace the original test pipeline in the business pipeline.

[0167] Here, the pipeline platform counts the execution effect indicators of each test task and sends the execution effect indicators to the test platform. The test platform updates the orchestration results according to the received execution effect indicators and sends the updated orchestration results to the pipeline platform so that the pipeline platform encapsulates the updated orchestration results into the business pipeline. In this way, the execution effect of the overall test process can be improved.

[0168] In some embodiments, in the process of executing multiple test tasks according to the arrangement results, it also includes: the pipeline platform displays at least one of the execution progress and the execution result. Here, the test platform can obtain at least one of the execution progress and the execution result through a callback method and send it to the pipeline platform; or the pipeline platform can directly obtain at least one of the execution progress and the execution result through a callback method, depending on the specific call and callback situation. In this way, it is convenient for users of the pipeline platform to intuitively understand the actual situation of the test.

[0169] like Figure 4 As shown, the embodiment of the present application implements intelligent orchestration through a test platform, and manages business pipelines and test pipelines through a pipeline platform, so that each performs its own duties and further improves the test efficiency by leveraging the computing power of their respective servers.

[0170] Below, an exemplary application of an embodiment of the present application in an actual application scenario, namely a special testing scenario, will be described, wherein special testing refers to testing of specific functions, performance, security, usability, etc. of the software. Different from general functional testing, special testing uses special testing tools to assist testing, such as stress testing tools, exception construction tools, memory detection tools, etc.

[0171] The embodiment of the present application disassembles and encapsulates multiple special test tasks (special test tasks can be regarded as test tasks in the above text) into a sub-pipeline, which is called as a step of the continuous delivery pipeline (corresponding to the business pipeline in the above text). Based on the characteristics of the special test tool and combined with low-code configuration, automatic arrangement is performed to solve the problems of logical sharing, conflict, association, etc. between special test tasks, reduce access costs, and improve test efficiency.

[0172] The present application embodiment provides Figure 5 The continuous delivery pipeline shown in the figure includes steps such as static scanning, compilation and construction, branch merging and publishing. Of course, Figure 5This is only an example and does not constitute a limitation on the continuous delivery pipeline. In the continuous delivery pipeline, a special test step can be added between the compilation and the branch merge. If the continuous delivery pipeline includes a build verification test (BVT), the special test step can be located between the build verification test and the branch merge to avoid unnecessary resource waste caused by performing special tests before the basic test (build verification test) passes.

[0173] Among them, the special test steps are connected to the special test platform (for example, it can be Figure 4 Corresponding to the test platform in the embodiment, when a special test tool is connected, it is connected to the special test platform, and is uniformly managed and executed by the special test platform; the special test platform generates an orchestration result for each continuous delivery pipeline to orchestrate the execution of the special test tool; the special test step calls the special test platform, special test pipeline and related test tools, which is not reflected in the continuous delivery pipeline orchestration. The special test step is equivalent to a black box, but the overall execution progress can be observed.

[0174] The present application embodiment provides Figure 6 The schematic diagram of the system architecture shown in FIG. Figure 7 The flow chart of the special test process shown in FIG. 1 shows, the system architecture mainly includes a special test platform and an assembly line platform (for example, Figure 4 The corresponding assembly line platform in the embodiment) etc. will be introduced in detail below.

[0175] 1) Special testing platform.

[0176] The special test platform is used to achieve the following functions: connect the continuous delivery pipeline and the special test pipeline; manage special test tools; generate orchestration results (the orchestration results are used to create special test pipelines). When the special test tool is connected, it is configured on the special test platform, such as the configuration tool name, type, person in charge, call and callback interfaces, dependent environment type, dependent use case type, stability monitoring, and operation control parameters.

[0177] When the special test platform receives the special test request from the pipeline platform, it performs intelligent orchestration to obtain the orchestration result. During the orchestration process, the special test platform first creates a basic orchestration template, and then adds specific steps to the orchestration template according to the situation of calling the special test tool for the special test task and the relevant configuration of the special test tool to obtain the orchestration result. The special test platform enters the orchestration result into the pipeline platform to encapsulate the orchestration result as a sub-pipeline of the continuous delivery pipeline. When the continuous delivery pipeline executes the special test step, the pipeline engine of the pipeline platform will call the special test tool according to the special test pipeline to complete all the testing work. Among them, the pipeline engine is the core component of the pipeline platform and is used to support the operation of the pipeline platform. During the test process, the progress and results of the entire process will be fed back to the special test step of the continuous delivery pipeline for the convenience of relevant users to view.

[0178] 2) Assembly line platform.

[0179] The pipeline platform is used to manage two types of pipelines and step logic: continuous delivery and special testing. The pipeline defines a series of execution orders of pipeline steps (including serial or parallel order), and supports user custom editing, where each step has input and output, and the output of the previous step can be obtained by the subsequent step as input; each step is a code logic block, such as reading configuration, calling external interfaces, etc., and supports customization. When the pipeline is executed, the pipeline platform will input its internal arrangement into the pipeline engine, and the pipeline engine will execute each step in sequence. When the step is completed and the pipeline is completed, the pipeline initiator can be called back to return the result. It should be noted that the embodiment of the present application does not limit the type of pipeline platform. For example, the embodiment of the present application can be implemented based on various open source pipeline platforms.

[0180] 3) Special testing tools.

[0181] A special testing tool refers to a non-general testing tool used in a special testing task. For example, in an exception testing task, the application environment and execution use cases are universal, but the construction of exceptions (such as tampering with requests) and analysis of results (it is normal for a request to fail due to tampering with requests, that is, if the request fails, the test result should be judged as passed; if the request succeeds, the test result should be judged as failed) are not universal. The construction of exceptions and analysis of results are unique tools or code logic, namely, the special testing tool in the embodiment of the present application.

[0182] The present application embodiment provides Figure 8 The schematic diagram of the arrangement result shown will be combined with Figure 8The process of orchestration processing by the special test platform is described. First, the special test platform creates a general orchestration template based on the commonality of the special test process. The orchestration template can include three stages: preparation, execution, and end. Then, according to the configuration parameters of the special test tool used for the special test task of this special test, specific steps are added to the orchestration template.

[0183] In the embodiment of the present application, the special test task can be divided into multiple calls to the special test tool (corresponding to the call operation above) and general operations of non-tool calls (corresponding to the non-call operation above). For example, for the call of the special test tool, three operations are defined: start (or execute), query, and stop; for the general operations of non-tool calls, four operations are defined: apply for environment, execute use case, summarize results, and release environment.

[0184] Based on the characteristics of the pipeline mechanism, the output of a certain step can be passed to the subsequent step as input, thereby realizing information sharing. Therefore, in an embodiment of the present application, the stage to which the call operation belongs can be determined in the arrangement template based on the logical relationship between the call operations, and multiple call operations can be arranged in series or in parallel to realize information sharing or information mutual exclusion. Prior to this, the types of special test tools (corresponding to the task types above) can be divided according to the actual application scenarios, and the internal logical relationships between the multiple call operations for calling the same special test tool and the external logical relationships between the multiple call operations for calling different special test tools can be pre-set. An example of type division is given below:

[0185] 1) Execution test type (corresponding to the business execution type mentioned above): Similar to the execution automation use case in functional testing, it refers to calling the tested business (target business) on the tested environment and executing the business process. For example, special test tools belonging to the execution test type may include stress testing tools, fuzz testing tools, security testing tools, etc. For tools belonging to the execution test type, there are two types of call operations: start and query. The start operation is used to orchestrate to the execution stage, and the query operation is used to orchestrate to the end stage.

[0186] 2) Detection construction class (corresponding to the detection type above): refers to the need to start before calling the tested business and stop after calling the tested business. For example, special test tools belonging to the detection construction class may include resource detection tools (such as for detecting memory leaks), exception construction tools, etc. For special test tools belonging to the detection construction class, there are three calling operations: start, stop, and query. The start operation is used to arrange to the preparation stage, and the stop operation and query operation are used to arrange to the end stage.

[0187] 3) Result check category (corresponding to the result check type above): refers to checking the results and logs of calling the tested business. For example, special test tools belonging to the result check category may include call chain check tools based on log analysis, Structured Query Language (SQL) check tools, etc. For special test tools belonging to the result check category, there are two types of call operations: start and query, both of which are arranged to the end stage.

[0188] The type of special test tool is included in the configuration parameters of the special test tool. Based on the type of special test tool, the logical relationship between the call operations can be clarified, and then the call operations can be arranged and processed. The arrangement result is as follows: Figure 8 As shown in the figure, by dividing the three stages into preparation, execution, and end, multiple special test tools can be aligned with the process when used, which can meet the needs of background traffic and detection.

[0189] In addition to the type, the configuration parameters of the special test tool can also include parameters related to general operations, such as dependent environment types and dependent use case types, etc. These parameters can be configured in the corresponding general steps (corresponding to the shared test steps above), for example, the dependent environment type is configured in the application environment step to apply for various environment types required in the application environment step; for example, the dependent use case type is configured in the execution use case step to execute various execution use cases required in the execution use case step. In this way, it is equivalent to executing the corresponding general operations in each special test task in the general step, which can realize information sharing and avoid repeated operations.

[0190] The orchestration results obtained after the orchestration process often involve multiple special test tools. If some special test tools are unstable or the execution time is too long, the overall test effect will be poor. Therefore, the execution effect index of each special test tool can be counted, and the execution effect index can be determined based on at least one of the factors such as success rate and execution time. For special test tools whose execution effect index is less than the index threshold, offline processing is performed, and at the same time, the orchestration results are updated, for example, all call operations related to the special test tool are deleted in the orchestration results. For special test tools that are offline (not online), they can be optimized, and after the optimization is completed, they can be put back online (online again), and re-participate in the orchestration process to obtain new orchestration results.

[0191] The present application embodiment provides Fig. 9The schematic diagram of the special test step shown in the figure, considering the reusability of the pipeline, the special test step adopts an assembly architecture, and the special test step determines which object to load and what logic to execute according to the parameters dispatched by the pipeline engine (corresponding to the operation parameters above), and the input parameters of the special test step include but are not limited to the pipeline ID (corresponding to the pipeline identifier above), plug-in operation parameters (such as plug-in ID and plug-in type) and tool operation parameters (such as tool ID and tool call type), and the output parameters include but are not limited to the environment parameters of the applied environment (such as environment ID and environment type), tool call status (such as call return code, return body), use case execution status (such as use case type, number of successes, number of failures), and results (such as a list of problems found). For example, if a step in the special test pipeline is to start the memory detection tool, the corresponding tool operation parameters are {tool ID: memory detection tool ID, tool call type: start}.

[0192] For special test tools, several calling operations of the corresponding type may not be available when connected. For example, in the analysis of the results of the memory detection tool, it is necessary to determine whether the memory occupancy curve falls back to the level before the call after the call to the tested business ends. The memory detection tool itself only has the ability to record the memory occupancy at each time point during the call process, and has no statistical judgment capability, resulting in the inability to support statistical judgment needs. In response to this, you can write judgment logic to connect to the plug-in library as a custom code plug-in, and register the start operation of the plug-in as the start operation of the memory detection tool in the special test platform, register the stop operation of the plug-in as the stop operation of the memory detection tool, and register the query operation of the plug-in as the query operation of the memory detection tool.

[0193] Next, we will use a practical example to illustrate the interaction process between the special test platform and the pipeline platform. Assuming that a business module of the software (corresponding to the target business mentioned above) needs to be specially tested, we first create a continuous delivery pipeline on the pipeline platform. The continuous delivery pipeline calls the special test platform. The special test platform performs orchestration processing to obtain the orchestration result. The orchestration result is used to encapsulate it into a special test pipeline, and the special test pipeline is used to be executed to implement the special test. Among them, the continuous delivery pipeline and the special test pipeline both rely on the pipeline platform. The pipeline platform is equivalent to a task management system, which stores the relationship between the pipeline ID and the orchestration result. It can find the corresponding orchestration result according to the pipeline ID, and then execute the orchestration result. Below, we will explain the process of creating a special test pipeline and executing a special test pipeline.

[0194] 1) Create a dedicated test pipeline.

[0195] like Fig. 10AThe pipeline platform interface 101 shown, when a special test is needed for a certain business module, the user can initiate a special test request in the pipeline platform. The special test request can include the business parameters of the business module (the business parameters are used when executing the special test pipeline, not when creating the special test pipeline), the selected special test tools and the selected test environment, etc.

[0196] The pipeline platform sends the special test request to the special test platform. The special test platform selects the special test tools that are currently online (i.e., can support calls), selected by the special test request, and corresponding to the business type of the business module from all the connected special test tools, and performs orchestration processing according to the selected special test tools (essentially, the call operation of the selected special test tools is orchestrated) to obtain the orchestration results. Among them, the format of the orchestration results is not limited, for example, it can be in json format. It is worth noting that the orchestration results contain the operating parameters required to call the special detection tool, but do not contain business parameters, so that similar business modules (such as different business modules with the same special test tasks) can reuse the same orchestration results.

[0197] The special test platform goes to the pipeline platform to create a special test pipeline according to the orchestration result. The pipeline platform returns the pipeline ID of the created special test pipeline to the special test platform. The special test platform stores the correspondence between the hash value of the orchestration result and the received pipeline ID. In this way, when the special test platform subsequently orchestrates a new orchestration result, it matches the hash value of the new orchestration result with the previously stored hash value. If the match is successful, the pipeline ID corresponding to the successfully matched hash value is queried, and the pipeline platform is notified to reuse the special test pipeline corresponding to the pipeline ID without repeated creation, thereby reducing resource waste.

[0198] 2) Execute special test pipeline.

[0199] Based on the created special test pipeline, the pipeline engine of the pipeline platform calls the special test tool according to the special test pipeline to implement the special test. Among them, the business parameters of the business module (such as the name of the business module) need to be transparently transmitted to the special test tool so that the special test tool can perform actual test operations, such as detecting the memory of the business module.

[0200] For a special test pipeline, the pipeline platform can be displayed. For example, the embodiment of the present application provides Fig. 10BThe pipeline platform interface 102 shown in the figure shows, on the left side of the pipeline platform interface 102, a visual structure of the orchestration result used by the special test pipeline with pipeline ID "special test pipeline 1", wherein tool 1, tool 2, tool 3 and tool 4 are all special test tools; the user can click on a step in the orchestration result to view the relevant information of the step, for example, on the right side of the pipeline platform interface 102, the relevant information of the step "start tool 2" is shown.

[0201] The embodiment of the present application is based on the characteristics of special testing tools and combines low-code configuration for automatic orchestration, which can solve problems such as logical sharing, conflict, and association between special testing tasks, improve the orderliness of operations, and improve the efficiency of special testing. It is suitable for various special testing scenarios.

[0202] The following is a description of an exemplary structure of the test task processing device 255 provided in the embodiment of the present application implemented as a software module. In some embodiments, Figure 2 As shown, the software modules stored in the test task processing device 255 of the memory 250 may include: a task determination module 2551, used to determine multiple test tasks of the target business; an operation splitting module 2552, used to perform operation splitting processing on each test task to obtain multiple call operations of each test task during the execution process; an orchestration module 2553, used to perform orchestration processing on the call operations corresponding to multiple test tasks according to the logical relationship between different call operations, and obtain an orchestration result that conforms to the logical relationship; an encapsulation module 2554, used to encapsulate the orchestration result into the business pipeline corresponding to the target business as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, multiple test tasks are executed according to the orchestration result.

[0203] In some embodiments, the logical relationship between different call operations includes the internal logical relationship between multiple call operations belonging to the same test task, and the external logical relationship between multiple call operations belonging to different test tasks; the orchestration module 2553 is also used to: create an orchestration template; wherein the orchestration template includes multiple stages; according to the internal logical relationship between the multiple call operations belonging to the same test task, the multiple call operations belonging to the same test task are orchestrated in stages in the orchestration template; according to the external logical relationship between the multiple call operations belonging to different test tasks, the call operations that have been orchestrated into the orchestration template are sequentially orchestrated to obtain an orchestration result.

[0204] In some embodiments, the orchestration module 2553 is also used to perform the following processing for any two call operations that belong to different test tasks: when the external logical relationship between any two call operations is a sharing relationship, the any two call operations are orchestrated in parallel; when the external logical relationship between any two call operations is an association relationship or a conflict relationship, the any two call operations are orchestrated in serial.

[0205] In some embodiments, the orchestration module 2553 is further used to: determine, according to the task type of the same test task, an associated stage associated with the task type in multiple stages; and orchestrate, according to the internal logical relationship between multiple call operations belonging to the same test task, multiple call operations belonging to the same test task into associated stages in sequence.

[0206] In some embodiments, the orchestration template includes a preparation phase, an execution phase, and an end phase; the orchestration module 2553 is further used to: when the task type of the same test task is a business execution type, determine both the execution phase and the end phase as associated phases; when the task type of the same test task is a detection type, determine both the preparation phase and the end phase as associated phases; when the task type of the same test task is a result inspection type, determine the end phase as an associated phase.

[0207] In some embodiments, the test task processing device 255 also includes a matching module for matching the orchestration result with the historical orchestration result; wherein the historical orchestration result has been encapsulated to obtain a historical test pipeline; the test task processing device 255 also includes a multiplexing module for multiplexing the historical test pipeline corresponding to the historical orchestration result into the business pipeline when the orchestration result successfully matches the historical orchestration result; the encapsulation module 2554 is also used to encapsulate the orchestration result into the business pipeline when the orchestration result fails to match the historical orchestration result.

[0208] In some embodiments, the matching module is also used to: obtain the correspondence between the hash value of the historical orchestration result and the pipeline identifier of the historical test pipeline; perform hash processing on the orchestration result to obtain the hash value of the orchestration result; match the hash value of the orchestration result with the hash value of the historical orchestration result; the multiplexing module is also used to perform query processing in the correspondence according to the successfully matched hash value, and reuse the historical test pipeline corresponding to the queried pipeline identifier into the business pipeline.

[0209] In some embodiments, the test task processing device 255 also includes an update module, which is used to: obtain execution effect indicators corresponding to multiple test tasks; update the orchestration results according to the test tasks whose execution effect indicators are less than the indicator threshold; and encapsulate the updated orchestration results into the business pipeline to replace the original test pipeline in the business pipeline.

[0210] In some embodiments, the update module is further used to perform any one of the following processing: deleting the target call operation in the orchestration result; configuring constraints for the target call operation in the orchestration result, so that when the target call operation is executed, the execution process of the target call operation is constrained according to the constraints; wherein the target call operation represents a call operation corresponding to a test task whose execution effect index is less than an index threshold.

[0211] In some embodiments, the operation splitting module 2552 is also used to perform the following processing for any test task: when any test task is a non-continuous task, any test task is split into a start operation and a query operation; when any test task is a continuous task, any test task is split into a start operation, a stop operation and a query operation; wherein the start operation, the stop operation and the query operation are all call operations.

[0212] In some embodiments, non-call operations of each test task during execution are obtained through operation splitting processing; the orchestration result also includes at least one shared test step; the orchestration module 2553 is also used to: according to the non-call operation type to which the non-call operation belongs, orchestrate the non-call operation to the shared test step corresponding to the non-call operation type; wherein each shared test step corresponds to a non-call operation type.

[0213] In some embodiments, the test task processing device 255 also includes a registration module, which is used to: receive an operation registration request; wherein the operation registration request includes a candidate call operation configured for the target test task; in response to the operation registration request, register the candidate call operation configured for the target test task as the call operation of the target test task.

[0214] In some embodiments, the task determination module 2551 is also used to: determine multiple candidate test tasks; filter and process the multiple candidate test tasks according to the task screening conditions to obtain the test tasks of the target business; wherein the task screening conditions include at least one of the following: the execution status of the candidate test task is executable; the candidate test task is specified by the test request used to test the target business; the candidate test task corresponds to the business type of the target business; wherein each candidate test task corresponds to at least one business type.

[0215] In some embodiments, the calling operation is used to call the test tool; the test task processing device 255 also includes a parameter sending module, which is used to: obtain the business parameters of the target business; send the business parameters to the corresponding test tool, so that the test tool performs test processing according to the business parameters when called by the calling operation.

[0216] The embodiment of the present application provides a computer program product or a computer program, which includes executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the executable instructions from the computer-readable storage medium, and the processor executes the executable instructions, so that the electronic device executes the test task processing method described in the embodiment of the present application.

[0217] An embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the test task processing method provided in the embodiment of the present application.

[0218] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0219] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0220] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0221] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0222] In summary, the embodiments of the present application can at least achieve the following technical effects:

[0223] 1) Intelligent arrangement is performed according to the logical relationship between the call operations, which can enhance the orderliness of the call operations during execution; the arrangement results are encapsulated as a test pipeline, which is called as a step in the business pipeline, so as to ensure that the test work is carried out according to the arrangement results during the business production process. Therefore, the embodiment of the present application can improve the overall test efficiency, reduce the waste of computing resources, facilitate the rapid release of the business, and is applicable to the production process of various businesses.

[0224] 2) Based on the internal logical relationship between multiple call operations belonging to the same test task, and the external logical relationship between multiple call operations belonging to different test tasks, the orchestration processing can take into account both individual and overall situations, improve the overall orchestration results, and improve the effective utilization of computing resources when executing the test pipeline.

[0225] 3) Supports the reuse of historical orchestration results (reuse of historical test pipelines), eliminating the need to create duplicate test pipelines, thereby effectively reducing resource waste while ensuring test results.

[0226] 4) Update the orchestration results according to the actual execution status of the test pipeline, so as to reduce the adverse effects of individual test tasks with poor execution on the entire test process; after the optimization is completed, the test tasks can be put back online and participate in the orchestration, which can supplement the test capacity while ensuring the overall test effect.

[0227] 5) The embodiments of the present application can be implemented collaboratively by a test platform and a pipeline platform, and the test efficiency and production efficiency can be improved through the interaction between the two platforms. It can be applicable to scenarios with a large test workload.

[0228] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A test task processing method, characterized in that: include: Identify multiple testing tasks for the target business; Perform operation splitting on each test task to obtain multiple call operations of each test task during execution; According to the logical relationship between different calling operations, the calling operations corresponding to the multiple test tasks are arranged and processed to obtain an arrangement result that conforms to the logical relationship; The orchestration result is encapsulated into the business pipeline corresponding to the target business to serve as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, the multiple test tasks are executed according to the orchestration result.

2. The method according to claim 1, characterized in that The logical relationship between the different call operations includes an internal logical relationship between multiple call operations belonging to the same test task, and an external logical relationship between multiple call operations belonging to different test tasks respectively; The process of arranging the call operations respectively corresponding to the plurality of test tasks according to the logical relationship between the different call operations to obtain an arrangement result that conforms to the logical relationship includes: Creating an orchestration template; wherein the orchestration template includes multiple stages; According to the internal logical relationship between the multiple call operations belonging to the same test task, the multiple call operations belonging to the same test task are subjected to stage orchestration processing in the orchestration template; According to the external logical relationship between a plurality of call operations respectively belonging to different test tasks, the call operations that have been arranged into the arrangement template are sequentially arranged to obtain an arrangement result.

3. The method according to claim 2, characterized in that The sequential arrangement of the call operations arranged in the arrangement template according to the external logical relationship between the multiple call operations respectively belonging to different test tasks includes: For any two call operations that belong to different test tasks, the following processing is performed: When the external logical relationship between the two arbitrary calling operations is a sharing relationship, the two arbitrary calling operations are arranged and processed in parallel; When the external logical relationship between any two calling operations is an association relationship or a conflict relationship, the any two calling operations are serially arranged and processed.

4. The method according to claim 2, characterized in that: The step of performing stage arrangement processing on the multiple call operations belonging to the same test task in the arrangement template according to the internal logical relationship between the multiple call operations belonging to the same test task includes: According to the task type of the same test task, determining an associated stage associated with the task type from among the multiple stages; According to the internal logical relationship between the multiple call operations belonging to the same test task, the multiple call operations belonging to the same test task are arranged in sequence into the association stage.

5. The method according to claim 4, characterized in that The arrangement template includes a preparation stage, an execution stage and an end stage; and the step of determining, according to the task type of the same test task, an associated stage associated with the task type from the multiple stages includes: When the task type of the same test task is a business execution type, both the execution phase and the end phase are determined as associated phases; When the task type of the same test task is a detection type, both the preparation phase and the end phase are determined as associated phases; When the task type of the same test task is a result check type, the end stage is determined as a correlation stage.

6. The method according to claim 1, characterized in that After arranging the call operations corresponding to the plurality of test tasks according to the logical relationship between the different call operations and obtaining an arrangement result that conforms to the logical relationship, the method further includes: Matching the arrangement result with the historical arrangement result; wherein the historical arrangement result has been packaged to obtain a historical test pipeline; When the orchestration result successfully matches the historical orchestration result, the historical test pipeline corresponding to the historical orchestration result is reused into the business pipeline; The step of encapsulating the orchestration result into a service pipeline corresponding to the target service includes: When the orchestration result fails to match the historical orchestration result, the orchestration result is encapsulated into the service pipeline.

7. The method according to claim 6, characterized in that The matching process of the arrangement result with the historical arrangement result includes: Obtaining a correspondence between a hash value of the historical arrangement result and a pipeline identifier of the historical test pipeline; Performing hash processing on the arrangement result to obtain a hash value of the arrangement result; Matching the hash value of the arrangement result with the hash value of the historical arrangement result; The reusing the historical test pipeline corresponding to the historical arrangement result into the business pipeline includes: A query process is performed in the corresponding relationship according to the successfully matched hash value, and the historical test pipeline corresponding to the queried pipeline identifier is reused in the business pipeline.

8. The method according to claim 1, characterized in that: After encapsulating the orchestration result into the service pipeline corresponding to the target service as a test pipeline in the service pipeline, the method further includes: Obtaining execution effect indicators corresponding to the multiple test tasks respectively; Update the arrangement result according to the test task whose execution effect index is less than the index threshold; The updated orchestration result is encapsulated into the business pipeline to replace the original test pipeline in the business pipeline.

9. The method according to claim 8, characterized in that The updating of the arrangement result according to the test task whose execution effect index is less than the index threshold includes: Perform any of the following: Deleting the target call operation in the arrangement result; configuring a constraint condition for the target call operation in the orchestration result, so that when the target call operation is executed, a constraint processing is performed on the execution process of the target call operation according to the constraint condition; The target call operation indicates a call operation corresponding to a test task whose execution effect index is less than the index threshold.

10. The method according to claim 1, characterized in that The operation splitting process is performed on each test task to obtain multiple call operations of each test task during the execution process, including: For any test task, perform the following processing: When any one of the test tasks is a non-persistent task, splitting the any one of the test tasks into a start operation and a query operation; When any one of the test tasks is a continuous task, the any one of the test tasks is divided into a start operation, a stop operation and a query operation; Among them, the start operation, the stop operation and the query operation are all call operations.

11. The method according to any one of claims 1 to 10, characterized in that: The non-calling operation of each test task during the execution process is also obtained through the operation splitting process; the arrangement result also includes at least one shared test step; The method further comprises: According to the non-call operation type to which the non-call operation belongs, arranging the non-call operation into a shared test step corresponding to the non-call operation type; Each shared test step corresponds to a non-call operation type.

12. The method according to any one of claims 1 to 10, characterized in that: The multiple test tasks for determining the target business include: Identify multiple candidate test tasks; Screening the multiple candidate test tasks according to the task screening condition to obtain the test task of the target business; The task screening condition includes at least one of the following: the execution status of the candidate test task is executable; the candidate test task is specified by the test request for testing the target business; the candidate test task corresponds to the business type of the target business; Each candidate test task corresponds to at least one business type.

13. A test task processing device, characterized in that: include: A task determination module is used to determine multiple test tasks for the target business; The operation splitting module is used to perform operation splitting processing on each test task to obtain multiple call operations of each test task during the execution process; An arrangement module, used for arranging the call operations corresponding to the plurality of test tasks respectively according to the logical relationship between different call operations, and obtaining an arrangement result that conforms to the logical relationship; An encapsulation module is used to encapsulate the orchestration result into the business pipeline corresponding to the target business as a test pipeline in the business pipeline; wherein, when the test pipeline in the business pipeline is triggered, the multiple test tasks are executed according to the orchestration result.

14. An electronic device, characterized in that: include: A memory for storing executable instructions; The processor is used to implement the test task processing method described in any one of claims 1 to 12 when executing the executable instructions stored in the memory.

15. A computer-readable storage medium, characterized in that: Executable instructions are stored, and when executed by a processor, the test task processing method described in any one of claims 1 to 12 is implemented.

16. A computer program product, characterized in that It includes executable instructions for implementing the test task processing method described in any one of claims 1 to 12 when executed by a processor.

Images