A testing method and apparatus for container services

Abstract

This application provides a testing method, apparatus, electronic device, and computer-readable storage medium for container services; it relates to cloud computing technology; the method includes: running a container service; wherein the container service includes multiple service units; the container service corresponds one-to-one with a development object; obtaining multiple test cases, each test case including tags of service units related to the test case; searching among the multiple test cases for a test case including a tag of a target test unit, the target test unit being the updated service unit among the multiple service units of the container service; and executing the found test case through the container service to obtain corresponding test results. This application can improve testing efficiency.

Description

Technical Field

[0001] This application relates to computer software testing technology and cloud technology, and more particularly to a testing method, apparatus, electronic device and computer-readable storage medium for container services. Background Technology

[0002] Cloud computing refers to the delivery and usage model of IT infrastructure, which means obtaining the required resources in an on-demand and easily scalable manner through the network. In a broader sense, cloud computing also refers to the delivery and usage model of services, which means obtaining the required services in an on-demand and easily scalable manner through the network. These services can be IT and software related, internet-related, or other services.

[0003] With the rapid development and application of the internet industry, client-side applications require corresponding server-side components and code to provide services. Testing these services is crucial for ensuring service quality. During service testing, scripting languages ​​are typically used to write test cases, which are then run on the server.

[0004] In related technologies, the mapping relationship between service units and test cases is usually recorded manually. This method has high maintenance costs and low search efficiency. Furthermore, when service units are updated or modified, the efficiency of re-executing test cases is also very low. Summary of the Invention

[0005] This application provides a testing method, apparatus, electronic device, and computer-readable storage medium for container services, which can improve the processing efficiency of testing.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a method for testing container services, including:

[0008] Run container services;

[0009] The container service includes multiple service units; each container service corresponds one-to-one with a development object.

[0010] Obtain multiple test cases, each test case including tags for service units related to the test case;

[0011] Search among the multiple test cases for test cases that include the tag of the target test unit, wherein the target test unit is the updated service unit among the multiple service units of the container service;

[0012] The found test cases are executed through the container service to obtain the corresponding test results.

[0013] This application provides a testing apparatus for container services, including:

[0014] The runtime module is used to run container services;

[0015] The container service includes multiple service units; each container service corresponds one-to-one with a development object.

[0016] The acquisition module is used to acquire multiple test cases, wherein the test cases include tags of service units related to the test cases;

[0017] The search module is used to search for test cases that include a tag for a target test unit among the plurality of test cases, wherein the target test unit is the updated service unit among the plurality of service units of the container service;

[0018] The testing module is used to execute the found test cases through the container service to obtain the corresponding test results.

[0019] In the above scheme, the container service runs in a container, and a relay service also runs in the container; the acquisition module is further configured to perform the following processing for multiple test cases to be executed: execute the test cases through the container service, and take over the call requests of multiple service units in the container service during the execution of the test cases through the relay service, so as to determine the service units related to the test cases among the multiple service units; and write the tags of the service units related to the test cases into the test cases.

[0020] In the above scheme, the acquisition module is further configured to execute the test case through the first service unit in the container service; when the target function to be called by the test case is not located in the first service unit, send a call request to the relay service; parse the call request through the relay service to determine the second service unit in the container service that includes the target function, and send the call request to the second service unit; receive the response result of the second service unit in response to the call request through the relay service, and send it to the first service unit.

[0021] In the above scheme, the acquisition module is further configured to register each service unit to the relay service, so that the relay service records the address and port of each service unit and responds to the call request based on the address and port of the service unit.

[0022] In the above scheme, the multiple service units are obtained by performing at least one of the following operations: splitting the container service into multiple service units according to the degree of business association, wherein the business of each service unit is interconnected; splitting the container service into multiple service units according to the degree of resource association, wherein the resources of each service unit are interdependent.

[0023] In the above scheme, the testing module is further configured to search for the historical test results of the target test unit before it was updated in the historical test results of all service units of the container service; and replace the historical test results of the target test unit before it was updated with the test results of the target test unit after it was updated.

[0024] In the above scheme, when there are multiple target test units, the test module is further configured to sort the multiple target test units in descending order according to their calling frequency; and use the descending order as the order in which the multiple target test units are tested.

[0025] In the above scheme, the container service is deployed in a container cluster; the running module is also used to run the container service in each container by installing a container service image in each container of the container cluster; wherein, each container provides a service testing interface to receive test cases to be executed.

[0026] In the above scheme, the found test cases include input data, running conditions, and script files; the test module is further configured to execute the script file based on the input data under the running conditions through the container service to obtain the actual execution result; the combination of the actual execution result and the test cases is used as the corresponding test result.

[0027] This application provides a testing apparatus for container services, including:

[0028] Memory, used to store executable instructions;

[0029] The processor, when executing executable instructions stored in the memory, implements the test method for the container service provided in the embodiments of this application.

[0030] This application provides a computer-readable storage medium storing executable instructions for implementing a test method for container services provided in this application when executed by a processor.

[0031] The embodiments of this application have the following beneficial effects:

[0032] Tagging service units related to test cases with labels in the test cases enables automated mapping of test cases and service units, saving maintenance costs and improving search efficiency. By searching for test cases with labels of the updated service units among multiple test cases, and executing the found test cases through the container service, only the test cases related to the updated service units need to be executed, thereby improving testing efficiency. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the architecture of the container service testing system 100 provided in this application embodiment;

[0034] Figure 2 This is a schematic diagram of the structure of server 200-1 provided in an embodiment of this application;

[0035] Figure 3A This is a flowchart illustrating a testing method for container services provided in an embodiment of this application.

[0036] Figure 3B This is a flowchart illustrating a testing method for container services provided in an embodiment of this application;

[0037] Figure 3C This is a flowchart illustrating a testing method for container services provided in an embodiment of this application;

[0038] Figure 4 This is a flowchart illustrating the execution of test cases provided in an embodiment of this application;

[0039] Figure 5 This is a flowchart illustrating the testing method for container services provided in this application embodiment. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0041] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, 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.

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

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0044] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0045] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0046] 1) Docker: An open-source application container engine that allows developers to package their applications and dependencies into a container and then deploy it to any popular Linux machine.

[0047] 2) SOA: Service-Oriented Architecture, which connects different functional units of an application (called services) through well-defined interfaces between these services.

[0048] 3) Mock: In the testing process, for certain objects that are not easy to construct or obtain, a virtual object is created to facilitate testing (i.e., to simulate the external environment and objects during testing). Generally, the mock function (equivalent to a proxy function) needs to provide simulated data return to ensure that the function under test (which includes the original function (i.e., the proxied function) can accurately obtain the dependent data.

[0049] 4) Relay machine: Records the IP address / port and interface of each service in the SOA service-oriented architecture.

[0050] 5) Integration testing: Testing of services or interfaces in an SOA architecture.

[0051] 6) Test Cases: The material for integration testing, which is an executable code file that records the specific input parameters and expected output results for a particular test.

[0052] 7) Tags: These record which services / interfaces a particular test case is related to. Tags can indicate which services / interfaces an integration test case covers.

[0053] 8) Kubernetes, or K8s for short, is an open-source application used to manage containerized applications across multiple hosts in a cloud platform. It uses the number 8 to represent the eight characters of "ubernete".

[0054] In related technologies, all developers typically share a single testing environment. An unstable testing environment will hinder the progress of all developers and result in extremely low testing efficiency. Furthermore, conflicts will arise when different developers set different mock data for the same interface. Manually recording the mapping relationship between interfaces and test cases is costly to maintain and inefficient to find. Additionally, the process of re-executing test cases when any interface undergoes a contract update is inefficient.

[0055] To address the aforementioned issues, embodiments of this application provide a testing method, apparatus, electronic device, and computer-readable storage medium for container services, which can improve testing efficiency. The following describes an exemplary application of the testing method for container services provided in this application. The testing method for container services provided in this application can be implemented by a server, for example, by a single server or by multiple servers (i.e., a server cluster) working together.

[0056] The following describes an embodiment of this application using an example of implementation by multiple servers working together. See also... Figure 1 , Figure 1 This is a schematic diagram of the architecture of the container service testing system 100 provided in this application embodiment. The container service testing system 100 includes: a server cluster 200, a network 300, a container cluster 500 (containers 500-1, 500-2, and 500-3 are shown as examples), and a terminal 400, which will be described separately.

[0057] The containers in container cluster 500 (exemplarily shown as containers 500-1, 500-2, and 500-3) are installed on the corresponding servers in the server cluster. Each container is used to perform regression testing on test cases that include the tags of the updated service unit after any service unit is updated; after the testing is completed, the container service deployed in the container (e.g., a payment deduction service in an instant messaging client) is used to implement the corresponding functional requirements in client 410.

[0058] Server cluster 200 is used to receive service requests from terminal 400, distribute the service requests to the corresponding containers in container cluster 500, and return the response results sent by the received containers to terminal 400.

[0059] Terminal 400 is used to run client 410 to receive business requests (such as electronic payment requests) initiated by users. Client 410 is used to output the corresponding human-computer interaction interface to users according to the corresponding container services provided by container cluster 500.

[0060] Network 300 is used as a medium for communication between server cluster 200 and terminal 400, and can be a wide area network, a local area network, or a combination of both.

[0061] In some embodiments, the server deployed in the container can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0062] Next, the structure of the electronic device for implementing the testing method of container services provided in the embodiments of this application will be described. As mentioned above, the electronic device provided in the embodiments of this application can be... Figure 1 Server 200-1. See also... Figure 2 , Figure 2 This is a schematic diagram of the structure of server 200-1 provided in an embodiment of this application. Figure 2 The server 200-1 shown includes at least one processor 210, memory 230, and at least one network interface 220. The various components in server 200-1 are coupled together via a bus system 240. It is understood that the bus system 240 is used to implement communication between these components. In addition to a data bus, the bus system 240 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 240.

[0063] 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. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0064] The memory 230 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 230 may optionally include one or more storage devices physically located away from the processor 210.

[0065] The memory 230 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 230 described in this application embodiment is intended to include any suitable type of memory.

[0066] In some embodiments, memory 230 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0067] The operating system 231 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, for implementing various basic business functions and handling hardware-based tasks.

[0068] The network communication module 232 is used to reach other computing devices via one or more (wired or wireless) network interfaces 220, such as Bluetooth, WiFi, and Universal Serial Bus (USB).

[0069] In some embodiments, the testing apparatus for container services provided in this application can be implemented in software. Figure 2 A test apparatus 233 for a container service stored in memory 230 is shown. This apparatus can be software in the form of programs and plug-ins, and includes the following software modules: a running module 2331, an acquisition module 2332, a search module 2333, and a test module 2334. These modules are logically linked and can therefore be arbitrarily combined or further separated according to the functions they implement. The functions of each module will be described below.

[0070] It is understood that the container service testing method provided in this application embodiment can be implemented by a single server or by multiple servers (i.e., a server cluster) working together. The following will illustrate the container service testing method provided in this application embodiment using an example of implementation by a single server.

[0071] See Figure 3A , Figure 3A This is a flowchart illustrating a testing method for container services provided in an embodiment of this application, which will be combined with... Figure 3A The steps shown are explained.

[0072] In step 101, the container service is run. The container service comprises multiple service units; each container service corresponds one-to-one with a development object.

[0073] In some embodiments, a container service is run in each container by installing a container service image in each container of the container cluster; wherein each container provides a service testing interface to receive test cases to be executed. It should be noted that, since there is a one-to-one correspondence between container services and development objects, different virtual container services can be deployed in each container of the container cluster for different developers, supporting developers to perform development / testing in their respective containers.

[0074] For example, installing a container service image in each container of a container cluster can be achieved by packaging each container service as a Docker container image and deploying each container service instance as a container. Docker is a way to package and deploy services. For example, a Docker cluster framework could be Kubernetes. Each container encapsulates the details of the technology used to build the container service. For instance, installing the same container service image in each container of a container cluster allows all container services to start and stop in exactly the same way; since each service instance is an isolated container, installing different container service images in each container of a container cluster allows different developers to set up different virtual containers to support development / testing in their respective containers.

[0075] This application's embodiments enable the direct scaling up and down of container services by changing the number of container service instances. By installing different container service images in each container of the container cluster, different virtual containers are set up for different developers, eliminating the dependence on a unified testing environment and improving development efficiency. Furthermore, it allows developers to freely configure mock data in their respective containers, avoiding data conflicts.

[0076] In some embodiments, multiple service units can be obtained by splitting the service according to multiple dimensions, such as at least one of the following: splitting the container service into multiple service units according to the degree of business correlation, wherein the business of each service unit is interconnected; or splitting the container service into multiple service units according to the degree of resource correlation, wherein the resources of each service unit are interdependent.

[0077] It's important to note that each service unit communicates via data serialization, application layer protocols, and Transmission Control Protocol / Internet Protocol (TCP / IP) to invoke services. The application layer protocol of the container service is responsible for defining which code data is used for service calls, distinguishing which interface is being called, and how various serialized data structures are grouped together to form a unified communication data block. Then, the data serialization mechanism associates the returned response data with the call request. TCP / IP communication is responsible for transmitting the call request to the service unit providing the corresponding service and returning the response data to the service unit that initiated the call. Here, TCP / IP is just a common choice; UDP or other communication protocols can also be used if call efficiency and latency are considered, or in broadcast scenarios.

[0078] In this embodiment, complex and bloated monolithic services are decomposed into fine-grained service-oriented components, with each decomposed container service packaged and deployed independently, thereby greatly improving the efficiency of service delivery.

[0079] In step 102, multiple test cases are obtained, and the test cases include tags for service units related to the test cases.

[0080] In some embodiments, the container service runs in a container, and a relay service also runs in the container; obtaining multiple test cases including tags of service units related to the test cases can be achieved by performing the following processes for multiple test cases to be executed: executing the test cases through the container service, and taking over the call requests of multiple service units in the container service during the execution of the test cases through the relay service to determine the service units related to the test cases among the multiple service units; and writing the tags of the service units related to the test cases into the test cases.

[0081] In some examples, the relay service can take over the call requests of multiple service units in the container service during the execution of test cases. This can be achieved in the following way: the test case is executed by the first service unit in the container service. When the target function that the test case needs to call is not located in the first service unit, a call request is sent to the relay service. The relay service parses the call request to determine the second service unit in the container service that includes the target function, and sends a call request to the second service unit. The relay service receives the response result of the second service unit to the call request and sends it to the first service unit.

[0082] For example, since container services are broken down into multiple service units, these service units provide complete business service functions (i.e., target functions) through mutual calls. However, manually recording the mapping relationship between service units and test cases during test case execution leads to low testing efficiency. In this embodiment, during test case execution, the call requests between service units are handled by a relay service. That is, when service unit A needs to call service unit B and initiates a call request, the relay service parses the call request, which includes call information and the call object. Based on the call request, the relay service sends the call information to service unit B, receives the response result from service unit B, and sends it back to service unit A. It also records the call details between service units A and B, including the service units covered by the test cases. It should be noted that the relay service is used to handle call requests during testing. In scenarios providing business services, the relay service can be omitted, and service unit A can directly call service unit B.

[0083] Due to the rapid pace of internet updates and the need for real-time updates to business service functions, this application embodiment records the mapping relationship between service units and test cases during the testing process through a relay service. This enables the accurate identification of test cases that need to be regressed, thereby improving the coverage accuracy of regression testing.

[0084] As an example, to determine the second service unit in the container service that includes the target function by parsing the call request through a relay service, this can be achieved by registering each service unit with the relay service so that the relay service records the address and port of each service unit and responds to the call request based on the address and port of the service unit.

[0085] For example, each service unit is pre-registered with a relay service. The relay service can be established in the following ways: creating a new connection to the relay service, i.e., specifying that the relay service will handle the call requests; authorizing the relay service, i.e., authorizing the relay service by verifying the relay service's account and password; and adding a relay channel for the relay service. It should be noted that authorization can also be enhanced by verifying the password in the private key file.

[0086] In step 103, a test case containing the tag of the target test unit is searched among multiple test cases. The target test unit is the updated service unit among multiple service units of the container service.

[0087] In some embodiments, test cases including tags for service units related to the test cases can be stored in a database. The database is used to receive, store, and manage test cases with service unit tags generated in the transit service, so that testers can query test cases including tags for target test units through the database. That is, when any one of the multiple service units of the container service is updated, the container service searches for the corresponding test case in the database based on the tags of the updated service unit.

[0088] In some examples, finding test cases tagged with the target test unit among multiple test cases can be achieved through a test case management platform. This platform provides a user-friendly interface for testers via a client-side page or web page, allowing them to connect via mobile devices or computers. The platform manages test cases stored in a database and also allows testers to query them. Specifically, the platform displays a test case search interface with a search box for testers to input the target test unit. The platform reads the target test unit entered in the search box, searches for test cases tagged with that unit, and then performs regression testing on the found test cases.

[0089] In this embodiment of the application, since the database stores the correspondence between service units and test cases, when any service unit is updated, the test cases that cover the service unit can be accurately found. Thus, in the subsequent regression processing, the test cases that include the tags of the updated service units can be accurately executed, thereby improving the accuracy of the test cases' coverage of the service units.

[0090] In step 104, the found test cases are executed through the container service to obtain the corresponding test results.

[0091] In some embodiments, the found test cases include input data, runtime conditions, and script files. See also Figure 3B , Figure 3B This is a flowchart illustrating a testing method for container services provided in an embodiment of this application. Figure 3A Step 104 can be achieved through steps 1041 and 1042, which will be explained in conjunction with each step.

[0092] In step 1041, the container service executes the script file based on the input data under the running conditions to obtain the actual execution result.

[0093] In step 1042, the combination of the actual execution result and the test case is taken as the corresponding test result.

[0094] In some embodiments, the found test cases include: the expected execution result. When the actual execution result matches the expected execution result, the result of passing the test is also written into the test result; when the execution result does not match the expected execution result, the result of failing the test is also written into the test result.

[0095] In some embodiments, when executing multiple found test cases via a container service, test components are generated based on the input data, script files, and remote conditions in the test cases. While generating multiple test components, the execution order between these components can be configured by the developer. For the container service, upon receiving an indication that the test component configuration is complete, the execution order between the multiple test components is determined, and the multiple test components are assembled into test cases according to the execution order.

[0096] In some embodiments, see Figure 3C , Figure 3C This is a flowchart illustrating a testing method for container services provided in an embodiment of this application, based on... Figure 3A After step 104, steps 105 and 106 can also be performed, which will be explained in conjunction with each step.

[0097] In step 105, the historical test results of the target test unit before it was updated are found in the historical test results of all service units of the container service.

[0098] In step 106, the historical test results of the target test unit before the target test unit was updated are replaced with the updated test results of the target test unit.

[0099] For example, historical test results include test results a, b, c, d, and e. When a service unit is updated, the test cases covered by that service unit are included in test results b and c. This means that we can find the historical test results b and c of the target test unit before the update in the historical test results a, b, c, d, and e of all service units of the container service. Then, we replace the historical test results b and c of the target test unit before the update with the updated test results b' and c'.

[0100] The embodiments of this application can accurately update historical test results to quickly obtain updated historical test results.

[0101] In some embodiments, when there are multiple target test units, the following steps may also be performed: sorting the multiple target test units in descending order according to their call frequency; and using the descending order as the order in which the multiple target test units are tested.

[0102] In some examples, the process involves: identifying at least one target test unit to be tested; determining the execution cycle of the test cases corresponding to the target test unit; determining the executable time period of the test cases within the execution cycle; obtaining the historical call frequency of at least one target test unit within each historical execution cycle; determining the standard execution time of the test cases within the executable time period of each historical execution cycle; training the neural network model using the historical call frequency and the standard execution time to generate the trained neural network model; obtaining the current call frequency of at least one target test unit within the target time period of the current execution cycle; inputting the current call frequency into the trained neural network model; and obtaining the execution time of the test cases in the current execution cycle output by the trained neural network model.

[0103] In this embodiment, the order of testing the target test unit is determined based on the calling frequency of the target test unit, so as to prioritize testing service units with high calling frequency, making the testing order more reasonable. The calling frequency usually reflects the demand of the service unit, so it can be closer to the user's needs. This embodiment can dynamically predict and determine the execution time of the test cases in the current execution cycle based on the running status of the service unit in the current execution cycle, determine the appropriate execution time of the test cases, and reduce the workload of developers.

[0104] In some embodiments, during test case execution, the relay service records the process ID of the called service unit and the call stack of the thread containing that service unit, storing them together in the database. After the test is completed, the relay service categorizes and summarizes each record in the database according to the class name and process ID of the service unit call, sorts them according to the timestamp of the record, and finally forms a service unit call sequence for each process during the test case execution. The service unit call status during test case execution is checked, specifically whether the process ID of the called service unit is equal to the process ID of the corresponding container service. If they are equal, the call is recorded in the database; otherwise, it is considered a malicious call and is not recorded.

[0105] In this embodiment of the application, recording of malicious calls is excluded, saving the container service additional recording operations and improving the efficiency of testing.

[0106] The following describes an exemplary application of the embodiments of this application in a real-world application scenario. Taking the application of the container service testing method provided in the embodiments of this application to the integration testing of payment deduction in an instant messaging client as an example, the specific implementation scheme of the embodiments of this application is as follows: Based on Docker technology, different container service images are installed in each container of the container cluster to set up different virtual containers for different developers, supporting developers to develop / test in their own containers, eliminating the dependence on a unified testing environment and improving development efficiency. It also allows developers to freely set Mock data in their own containers, avoiding data conflicts. Based on SOA technology, after a test case is executed, the call stack of the test case and the service / interface (i.e., service unit) name on the call stack can be obtained. The service unit name is marked on the test case, thus achieving the mapping of test cases and service units in an automated way. When any interface undergoes a contract change, it is only necessary to search for which test cases cover the service unit by marking, and then re-execute these test cases to quickly test the service unit, improving testing efficiency and the accuracy of test case coverage of interfaces. Taking the execution of test case 1 in container 3 as an example, the specific process is as follows:

[0107] First, the relay takeover service unit makes invocation requests during the execution of test cases.

[0108] In some embodiments, Figure 4The diagram illustrates three service units (i.e., services / interfaces): service unit a, service unit b, and service unit c, which have a calling relationship. A relay server (i.e., a server providing relay services) handles call request 1 initiated by service unit a (call request 1 attempts to call service unit b). Specifically, service unit a initiates call request 1.1 to the relay server. The relay server obtains the IP address and port of service unit b and initiates call request 1.2 to call service unit b. It's important to note that service units a, b, and c pre-register with the relay server so that the relay server can record their addresses and ports, allowing it to respond to call requests based on these addresses and ports. Thus, through calls 1.1 and 1.2, service unit a calls service unit b. Similarly, when service unit b attempts to call service unit c by initiating call request 2, the actual call occurs through call requests 2.1 and 2.2 from the relay server.

[0109] It should be noted that the multiple service units are derived from the decomposition of a monolithic service based on SOA technology. There are two ways to decompose services: one is vertical decomposition, which is based on the business dimension, that is, dividing closely related business functions into service units; the other is horizontal decomposition, which is based on the dimension of common and independent functions, that is, dividing interdependent business functions into service units based on the degree of resource correlation.

[0110] Secondly, after the test cases are executed, the relay machine marks the service unit's tag in the test cases and stores it in the database.

[0111] It should be noted that since service units a, b, and c pre-register and log in to the relay machine, during the execution of test case 1, the relay machine responds to the call requests initiated by service units a, b, and c based on the recorded addresses and ports of service units a, b, and c. Service units a, b, and c are then labeled as three tags on test case 1.

[0112] Furthermore, when service unit a is modified, the service test interface in the container searches for the corresponding test case in the database based on the tag of service unit a, and sends the found test case to the service in the container; the service in the container executes the found test case to obtain the corresponding test result.

[0113] In some embodiments, when service unit a (or b / c) is modified by developer 4, the service test interface in the container only needs to filter test cases based on the tag of service unit a to accurately obtain test cases involving service unit a (e.g., test case 1). The service test interface in the container sends the found test cases to the service in the container. The service in the container only needs to re-execute test case 1 once to perform coverage regression testing on service unit a. In this way, the accuracy of test case coverage of service unit is improved.

[0114] The following is a flowchart illustrating the testing method for container services provided in this application. The testing method for container services provided in this application can be implemented by a single server; see [link to documentation]. Figure 5 , Figure 5 This is a flowchart illustrating the testing method for container services provided in this application embodiment. The testing method for container services provided in this application embodiment includes the following steps, which will be described below.

[0115] Step 501: The relay service receives the registration of the service unit and records the address and port of each service unit.

[0116] Step 502: The service test interface in the container receives test cases and sends them to the container service in the container.

[0117] It should be noted that by installing container service images in each container of the container cluster, the services in each container run within that container. The services in the containers (i.e., container services) are broken down into multiple service units based on their degree of business relevance or resource relevance.

[0118] Step 503: Execute test cases for the services in the container.

[0119] Step 504: The relay service in the container takes over the call requests of multiple service units in the container service during the execution of test cases, in order to identify the service units related to the test cases among the multiple service units, and write the tags of the service units related to the test cases into the test cases.

[0120] Taking multiple service units as an example, with the first service unit and the second service unit as the second, the first service unit in the container executes test case 1. When the electronic payment function that test case 1 needs to call is not located in the first service unit, the first service unit sends a call request to the relay service. The relay service parses the call request to determine that the container service includes the electronic payment function as the second service unit, and sends a call request to the second service unit. The second service unit responds to the call request and returns a response result to the relay service. The relay service receives the response result of the second service unit and sends it to the first service unit. Then, the relay service writes the tags of the first service unit and the second service unit into test case 1.

[0121] It should be noted that steps 501-504 are the processing plan for the first execution of the test case, while steps 505-509 are the processing plan for when the service unit is updated.

[0122] Step 505: The container service test interface receives multiple test cases related to the container service, and the test cases include tags for the service units related to the test cases.

[0123] Step 506: The container's service test interface searches for test cases tagged with the target test unit among multiple test cases. The target test unit is the updated service unit among the multiple service units of the container service.

[0124] Step 507: The container's service test interface sorts multiple target test units in descending order according to their call frequency, and sends them to the container service in the container in descending order.

[0125] Step 508: The container service executes the found test cases in descending order to obtain the corresponding test results and sends them to the service test interface.

[0126] Step 509: The container's service test interface searches for the historical test results of the target test unit before it was updated in the historical test results of all service units; and replaces the historical test results of the target test unit before it was updated with the test results of the target test unit after it was updated.

[0127] In the embodiments described above, the service unit tags related to the test cases are marked in the test cases through a relay service, thereby realizing the automated mapping of test cases and service units, saving maintenance costs and improving search efficiency. By searching for test cases with updated service unit tags among multiple test cases and executing the found test cases through the container service, test cases with updated service unit tags can be executed accurately, improving the accuracy of test case coverage of service units.

[0128] The following description continues to illustrate the exemplary structure of the container service testing device 233 provided in this application embodiment as a software module. In some embodiments, such as... Figure 2 As shown, the software modules in the test device 233 for container services stored in memory 230 may include:

[0129] The execution module 2331 is used to run the container service; wherein the container service includes multiple service units; the container service corresponds one-to-one with the development object; the acquisition module 2332 is used to acquire multiple test cases, wherein the test cases include tags of service units related to the test cases; the search module 2333 is used to search for test cases including tags of target test units among the multiple test cases, wherein the target test unit is the updated service unit among the multiple service units of the container service; the test module 2334 is used to execute the found test cases through the container service to obtain the corresponding test results.

[0130] In some embodiments, the container service runs in a container, and a relay service also runs in the container; the acquisition module 2332 is further configured to perform the following processing for multiple test cases to be executed: execute the test cases through the container service, and take over the call requests of multiple service units in the container service during the execution of the test cases through the relay service, so as to determine the service unit related to the test cases among the multiple service units; and write the tag of the service unit related to the test cases into the test cases.

[0131] In some embodiments, the acquisition module 2332 is further configured to execute the test case through a first service unit in the container service; when the target function to be called by the test case is not located in the first service unit, send a call request to the relay service; parse the call request through the relay service to determine a second service unit in the container service that includes the target function, and send the call request to the second service unit; receive the response result of the second service unit responding to the call request through the relay service, and send it to the first service unit.

[0132] In some embodiments, the acquisition module 2332 is further configured to register each service unit to the relay service, so that the relay service records the address and port of each service unit and responds to the call request based on the address and port of the service unit.

[0133] In some embodiments, the plurality of service units are obtained by performing at least one of the following operations: splitting the container service into the plurality of service units according to the degree of business association, wherein the business of each service unit is interconnected; splitting the container service into the plurality of service units according to the degree of resource association, wherein the resources of each service unit are interdependent.

[0134] In some embodiments, the testing module 2334 is further configured to search for the historical test results of the target test unit before it was updated in the historical test results of all service units of the container service; and replace the historical test results of the target test unit before it was updated with the test results of the target test unit after it was updated.

[0135] In some embodiments, when there are multiple target test units, the test module 2334 is further configured to sort the multiple target test units in descending order according to their calling frequency; and use the descending order as the order in which the multiple target test units are tested.

[0136] In some embodiments, the container service is deployed in a container cluster; the running module 2331 is further configured to run the container service in each container by installing a container service image in each container of the container cluster; wherein each container provides a service testing interface to receive test cases to be executed.

[0137] In some embodiments, the found test cases include input data, running conditions, and script files; the test module 2334 is further configured to execute the script file based on the input data under the running conditions through the container service to obtain actual execution results; and to use the combination of the actual execution results and the test cases as the corresponding test results.

[0138] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the container service testing method described above in this application.

[0139] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute a test method for a container service provided in this application. For example, ... Figure 3A , 3B The test method for container services shown in 3C.

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

[0141] In some embodiments, executable instructions may take 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 standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0142] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0143] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0144] In summary, this application's embodiments, by tagging service units related to test cases within test cases to achieve automated mapping between test cases and service units, can save maintenance costs and improve search efficiency. By searching for test cases with tags for the updated service units among multiple test cases and executing these found test cases through container services, it can accurately execute test cases with updated service unit tags, improving the accuracy of test case coverage of service units. Furthermore, by determining the testing order of the target test unit based on its call frequency, prioritizing services with high call frequencies, the testing order becomes more rational. Call frequency typically reflects the demand level of a service unit, thus better aligning with user needs. Finally, this application's embodiments can dynamically predict and determine the execution time of test cases within the current execution cycle based on the service unit's operational status, thus reducing the workload of developers.

[0145] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A test method of a container service, characterized by, The method includes: Run container services; The container service includes multiple service units; each container service corresponds one-to-one with a development object; the container service runs in a container, and a relay service also runs in the container. For multiple test cases to be executed, the following processes are performed respectively: the test cases are executed through the container service, and the relay service takes over the call requests of multiple service units in the container service during the execution of the test cases to identify the service units related to the test cases; tags of the service units related to the test cases are written into the test cases; when the relay service records the service units related to the test cases, it records the process ID of the service unit and the call stack of the thread in which the service unit is located and stores them in the database. Search among multiple test cases for test cases that include the tag of the target test unit, where the target test unit is the updated service unit among the multiple service units of the container service; The found test cases are executed through the container service to obtain the corresponding test results.

2. The method according to claim 1, characterized in that, The process of taking over the invocation requests of multiple service units in the container service during the execution of the test cases through the relay service includes: The test case is executed through the first service unit in the container service. When the target function to be called by the test case is not located in the first service unit, a call request is sent to the relay service. The relay service parses the call request to determine the second service unit in the container service that includes the target function, and sends the call request to the second service unit. The relay service receives the response result of the second service unit in response to the call request and sends it to the first service unit.

3. The method according to claim 2, characterized in that, The step of parsing the call request through the relay service to determine the second service unit in the container service that includes the target function includes: Register each of the service units to the relay service, so that... The relay service records the address and port of each service unit, and The service unit responds to the call request based on its address and port.

4. The method according to claim 1, characterized in that, The plurality of service units are obtained by performing at least one of the following operations: The container service is divided into multiple service units according to the degree of business relevance, wherein the business of each service unit is interconnected. The container service is divided into multiple service units according to the degree of resource association, wherein the resources of each service unit are interdependent.

5. The method according to claim 1, characterized in that, The method further includes: In the historical test results of all service units of the container service, find the historical test results of the target test unit before it was updated. The updated test results of the target test unit replace the historical test results of the target test unit before the update.

6. The method according to claim 1, characterized in that, When the number of target test units is multiple, the method further includes: The target test units are sorted in descending order according to their call frequency. The descending order is used as the order in which the multiple target test units are tested.

7. The method according to claim 1, characterized in that, The container service is deployed in a container cluster; running the container service includes: The container service is run in each container by installing the container service image in each container of the container cluster; Each of the containers provides a service testing interface to receive test cases to be executed.

8. The method according to claim 1, characterized in that, The found test cases include input data, runtime conditions, and script files; The step of executing the found test cases through the container service to obtain the corresponding test results includes: The container service executes the script file based on the input data under the operating conditions to obtain the actual execution result. The combination of the actual execution result and the test case is taken as the corresponding test result.

9. A testing apparatus for container services, characterized in that, include: The runtime module is used to run container services; The container service includes multiple service units; each container service corresponds one-to-one with a development object; the container service runs in a container, and a relay service also runs in the container. The acquisition module is used to perform the following processes for multiple test cases to be executed: execute the test cases through the container service, and take over the call requests of multiple service units in the container service during the execution of the test cases through the transit service to identify the service units related to the test cases; write the tags of the service units related to the test cases into the test cases; when recording the service units related to the test cases, the transit service records the process ID of the service unit and the call stack of the thread in which the service unit is located, and stores them in the database. The search module is used to search for test cases that include a tag for a target test unit among multiple test cases, wherein the target test unit is the updated service unit among multiple service units of the container service; The testing module is used to execute the found test cases through the container service to obtain the corresponding test results.

10. The apparatus according to claim 9, characterized in that, The acquisition module is also used to execute the test case through the first service unit in the container service. When the target function to be called by the test case is not located in the first service unit, a call request is sent to the relay service. The relay service parses the call request to determine the second service unit in the container service that includes the target function, and sends the call request to the second service unit. The relay service receives the response result of the second service unit in response to the call request and sends it to the first service unit.

11. The apparatus according to claim 10, characterized in that, The acquisition module is further configured to register each service unit to the relay service, so that... The relay service records the address and port of each service unit, and The service unit responds to the call request based on its address and port.

12. The apparatus according to claim 9, characterized in that, The testing module is also used to find the historical test results of the target test unit before it was updated in the historical test results of all service units of the container service; The updated test results of the target test unit replace the historical test results of the target test unit before the update.

13. The apparatus according to claim 9, characterized in that, When the number of target test units is multiple The testing module is also used to sort the multiple target test units in descending order according to their calling frequency; The descending order is used as the order in which the multiple target test units are tested.

14. The apparatus according to claim 9, characterized in that, The container service is deployed in a container cluster; The running module is also used to run the container service in each container by installing the container service image in each container of the container cluster; Each of the containers provides a service testing interface to receive test cases to be executed.

15. The apparatus according to claim 9, characterized in that, The found test cases include input data, runtime conditions, and script files; The testing module is also used to execute the script file based on the input data under the running conditions through the container service to obtain the actual execution result; The combination of the actual execution result and the test case is taken as the corresponding test result.

16. An electronic device, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the test method for the container service according to any one of claims 1 to 8.

17. A computer-readable storage medium storing executable instructions, characterized in that, When the executable instructions are executed by the processor, they implement the testing method for the container service as described in any one of claims 1 to 8.

18. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the testing method for the container service according to any one of claims 1 to 8.

Images