Test method, device, electronic equipment, computer readable storage medium and computer program product

Abstract

This application provides a testing method, apparatus, electronic device, computer-readable storage medium, and computer program product. The method includes: determining a first number of first resource containers in a first resource cluster, and determining a second number based on the first number and a preset resource allocation ratio; obtaining the second number of second resource containers, and constructing a second resource cluster based on the second number of second resource containers; obtaining multiple processing requests and target resource components received by the first resource cluster, wherein the target resource components are components whose versions have been updated; using the second resource cluster to respond to the multiple processing requests and obtain request response results; and determining the version test result of the target resource components based on the request response results. This application can improve the efficiency of resource component version testing and the quality of computing power services.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a testing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] Heterogeneous computing power is a key technology for improving computing efficiency. It integrates different types of computing resources to meet the demands of high-performance computing. In heterogeneous computing power component version testing, ensuring that each component can work effectively together is crucial for guaranteeing system stability and performance. With the rapid development of Artificial Intelligence (AI) technology, the scale of heterogeneous computing power services has increased significantly, and the business operations of these services are also becoming more diverse. Faced with the challenges of numerous and diverse business operations, how to reduce the impact of component version changes on the stability of computing power services and improve the quality of computing power services is an urgent problem to be solved.

[0003] In related technologies, manually building test case sets is costly in terms of human resources for test development, and manually built test case sets cannot cover all business scenarios. This results in components that have not been fully tested being released to online services with heterogeneous computing power, leading to low efficiency in resource component version testing and low quality of computing power services. Summary of the Invention

[0004] This application provides a testing method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the efficiency of resource component version testing and the quality of computing power services.

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

[0006] This application provides a testing method, the method comprising:

[0007] Determine the first number of first resource containers in the first resource cluster, and determine the second number based on the first number and a preset resource allocation ratio;

[0008] Obtain the second number of second resource containers, and construct a second resource cluster based on the second number of second resource containers;

[0009] Obtain multiple processing requests and target resource components received by the first resource cluster, wherein the target resource component is a component whose version has been updated;

[0010] Using the second resource cluster, multiple processing requests are responded to, and request response results are obtained;

[0011] The version test result of the target resource component is determined based on the request and response results.

[0012] This application provides a testing apparatus, including:

[0013] The first determining module is used to determine the first number of the first resource containers in the first resource cluster, and to determine the second number based on the first number and a preset resource allocation ratio;

[0014] The first acquisition module is used to acquire the second number of second resource containers and construct a second resource cluster based on the second number of second resource containers;

[0015] The second acquisition module is used to acquire multiple processing requests and target resource components received by the first resource cluster, wherein the target resource component is a component whose version has been updated.

[0016] The second determining module is used to utilize the second resource cluster to respond to multiple processing requests and obtain request response results.

[0017] The third determining module is used to determine the version test result of the target resource component based on the request response result.

[0018] This application provides an electronic device, the electronic device comprising:

[0019] Memory is used to store executable instructions or computer programs.

[0020] The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the testing method provided in the embodiments of this application.

[0021] This application provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, implement the testing method provided in this application.

[0022] This application provides a computer program product, including computer-executable instructions or a computer program, which, when executed by a processor, implements the testing method provided in this application.

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

[0024] By applying the embodiments of this application, a first number of first resource containers in a first resource cluster is determined, and a second number is determined based on the first number and a preset resource allocation ratio. Then, the second number of second resource containers is obtained, and a second resource cluster is constructed based on these second number of second resource containers. This allows for the construction of simulated resource containers in the corresponding simulated cluster based on the number of resource containers in the resource cluster and the preset resource allocation ratio. Furthermore, multiple processing requests and target resource components received by the first resource cluster are obtained. The target resource component is a component whose version has been updated. Using the second resource cluster, multiple processing requests are responded to, and request response results are obtained. This enables the construction of a test case set for the resource component version in the simulated cluster based on the processing requests received by the first resource cluster, avoiding manual construction of the test case set and thus improving the efficiency of resource component version testing. Finally, the version test result of the target resource component is determined based on the request response results. Therefore, by testing resource components whose versions have been updated in the simulated cluster, resource component version test anomalies will not affect online computing power services, thereby improving the quality of computing power services. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating the application mode of the testing method provided in the embodiments of this application;

[0026] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0027] Figure 3A This is a first flowchart illustrating the testing method provided in the embodiments of this application;

[0028] Figure 3B This is a second flowchart illustrating the testing method provided in the embodiments of this application;

[0029] Figure 3C This is a schematic diagram of the third process of the testing method provided in the embodiments of this application;

[0030] Figure 3D This is a schematic diagram of the fourth process of the testing method provided in the embodiments of this application;

[0031] Figure 4 This is a schematic diagram of the computing power structure supporting model training services provided in the embodiments of this application;

[0032] Figure 5 This is a schematic diagram of the component version testing structure provided in the embodiments of this application;

[0033] Figure 6 This is a flowchart illustrating the testing method provided in the embodiments of this application.

[0034] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

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

[0041] 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.

[0042] 1) Heterogeneous computing power: refers to a computing system that contains different types of computing units, such as central processing units and graphics processing units, each with different computing capabilities and efficiencies. These different types of computing units are combined to form a collaborative computing system to adapt to and meet diverse and complex computing needs.

[0043] 2) Computing Containers: These are virtualized containers used for deploying and managing computing resources, focusing on providing environments for high-performance computing and data processing. Users can package computing tasks and applications into a container, deploy it to a computing cluster or cloud environment, and utilize the computing resources in the cluster for efficient parallel computing.

[0044] 3) Simulation isolation domain: The simulation environment of the heterogeneous computing power cluster is physically isolated from the heterogeneous computing power cluster used for online services. Resource component version testing is carried out in the simulation isolation domain, which will not affect the heterogeneous computing power services running online.

[0045] 4) System components: These are the essential components necessary for maintaining and running a container orchestration system, responsible for the management and resource scheduling of the computing cluster.

[0046] 5) Functional components: These are components in the system that are responsible for specific functions and are used to implement specific business logic or services.

[0047] 6) Resource node components: These are components that run on the resource nodes of the computing cluster and are responsible for starting, managing, and maintaining containers on the resource nodes.

[0048] This application provides a testing method, apparatus, electronic device, computer-readable storage medium, and computer program product, which can improve the efficiency of resource component version testing and the quality of computing power services.

[0049] The following describes exemplary applications of the electronic devices provided in the embodiments of this application. These electronic devices can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals, or as servers. The following will describe exemplary applications when the device is implemented as a server.

[0050] See Figure 1 , Figure 1 This is a schematic diagram illustrating the application mode of the testing method provided in the embodiments of this application, for example. Figure 1 The system involves server 200, network 300, and terminal 400. Terminal 400 is connected to server 200 through network 300, which can be a wide area network, a local area network, or a combination of both.

[0051] During the resource component version testing process, terminal 400 sends test setting information to server 200. Based on the test setting information, server 200 sets a preset resource allocation ratio, determines a first number of first resource containers in the first resource cluster, and determines a second number based on the first number and the preset resource allocation ratio; obtains the second number of second resource containers, and constructs a second resource cluster based on the second number of second resource containers; obtains multiple processing requests and target resource components received by the first resource cluster, where the target resource component is a component whose version has been updated; uses the second resource cluster to respond to multiple processing requests and obtain request response results; determines the version test result of the target resource component based on the request response results, and sends the version test result to terminal 400.

[0052] In some embodiments, the server (e.g., server 200) 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, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal 400 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, in-vehicle terminal, 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.

[0053] See Figure 2 , Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may be a terminal or a server. Figure 2 The illustrated electronic device 500 includes at least one processor 410, a memory 450, and at least one network interface 420. The various components in the electronic device 500 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 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 440.

[0054] The processor 410 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. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0055] The memory 450 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 450 may optionally include one or more storage devices physically located away from the processor 410.

[0056] The memory 450 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 450 described in this application embodiment is intended to include any suitable type of memory.

[0057] In some embodiments, memory 450 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.

[0058] Operating system 451 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.

[0059] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including Bluetooth, WiFi, and Universal Serial Bus (USB).

[0060] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A test device 455 stored in memory 450 is shown. It may be software in the form of programs and plug-ins, including the following software modules: a first determination module 4551, a first acquisition module 4552, a second acquisition module 4553, a second determination module 4554, and a third determination module 4555. These modules are logically related and can therefore be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0061] In some embodiments, the terminal or server can implement the testing method provided in this application by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run, such as cloud computing APPs or instant messaging APPs; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0062] The testing methods provided in this application will be described in conjunction with exemplary applications and implementations of the server devices provided in the embodiments of this application.

[0063] The following describes the testing method provided in the embodiments of this application. For example, in order to facilitate understanding of the testing method provided in the embodiments of this application, the description is based on the application in the resource component version testing scenario.

[0064] As mentioned above, the electronic device implementing the testing method of this application embodiment can be a terminal, a server, or a combination of both. The following explanation uses an electronic device as a server as an example to illustrate the testing method provided in this application embodiment. See also... Figure 3A , Figure 3A This is a first flowchart illustrating the testing method provided in the embodiments of this application, which will be combined with... Figure 3A The steps shown are explained.

[0065] In step 301, a first number of first resource containers in the first resource cluster is determined, and a second number is determined based on the first number and a preset resource allocation ratio.

[0066] Here, the first resource cluster is a heterogeneous computing power cluster, which is a resource cluster including different types of computing units. The first resource container is a computing power container in the first resource cluster, and a computing power container is a virtualized container used to deploy and manage computing resources. The first quantity is the number of first resource containers in the first resource cluster, and the preset resource allocation ratio is the allocation ratio of central processing unit (CPU) computing power resources used for simulation of the first resource containers. Multiplying the CPU computing power resources of the first resource container by the preset resource allocation ratio gives the CPU computing power resources of the simulation computing power container corresponding to the first resource container. For example, the preset resource allocation ratio can be 0.5. If the first resource container has a single-core CPU computing power resource, then the simulation computing power container corresponding to the first resource container has 0.5 cores of CPU computing power resources.

[0067] Divide the first quantity by the preset resource allocation ratio to obtain the result, which is the number of simulated computing power containers, also known as the second quantity. For example, the preset resource allocation ratio can be 0.5, the first quantity can be 10, and the first quantity is divided by the preset resource allocation ratio. The result is 20, so the number of simulated computing power containers is 20, which is the second quantity.

[0068] In step 302, a second number of second resource containers are obtained, and a second resource cluster is constructed based on the second number of second resource containers.

[0069] Here, the second resource container is the simulation computing power container corresponding to the first resource container, and the second quantity is the number of second resource containers. A second quantity of second resource containers is created, and a simulation cluster of the first resource cluster, i.e., the second resource cluster, is constructed based on this second quantity of second resource containers.

[0070] In step 303, multiple processing requests and target resource components received by the first resource cluster are obtained.

[0071] Here, the target resource component is the component whose version has been updated. The target resource component includes at least one of the following: system components, functional components, and resource node components. The processing request is the actual user processing request received by the online heterogeneous computing cluster. User processing requests can include, but are not limited to, AI training requests (text, voice, etc.), page browsing requests, data query requests, service subscription requests, etc.

[0072] In step 304, the second resource cluster is used to respond to multiple processing requests and obtain the request response results.

[0073] Here, the second resource container in the second resource cluster is used to respond to multiple processing requests and obtain the request response results.

[0074] In some embodiments, see Figure 3B , Figure 3B This is a schematic diagram of the second process of the testing method provided in the embodiments of this application. Figure 3A Step 304 shown can be achieved through Figure 3B Steps 3041 to 3042 are implemented, and will be explained in detail below.

[0075] In step 3041, the first kernel runtime of the first resource container is determined, and the first kernel runtime is divided based on the resource allocation ratio to obtain the second kernel runtime of the second resource container.

[0076] Here, the first kernel runtime is the CPU kernel runtime of the first resource container. The first kernel runtime is multiplied by the resource allocation ratio, and the first kernel runtime is divided based on the multiplication result to obtain the CPU kernel runtime of the second resource container, which is also the second kernel runtime.

[0077] For example, the first kernel has a runtime of 100 minutes and a resource allocation ratio of 0.1. Multiplying these results in 10, which gives the CPU kernel runtime of the second resource container to be 10 minutes. In other words, the second kernel has a runtime of 10 minutes.

[0078] In step 3042, based on the second kernel runtime, the second resource container is used to respond to multiple processing requests and obtain the request response results.

[0079] Here, each second resource container parses multiple processing requests within the second kernel's runtime, extracting information such as the request type, path, query parameters, and request body content. Based on this request information, the application within the second resource container executes corresponding business logic. This business logic may include performing computational tasks, accessing databases, and calling external services, thereby generating a request response result. The request response result can include request response data and request response status information.

[0080] In this embodiment, the first kernel runtime of the first resource container is divided based on the first kernel runtime of the first resource container and the preset resource allocation ratio to obtain the second kernel runtime of the second resource container. This realizes the determination of the kernel runtime of multiple simulated computing power containers corresponding to the first resource container, and responds to multiple processing requests within the kernel runtime of multiple simulated computing power containers, thereby improving the request response efficiency.

[0081] In some embodiments, the second resource cluster can be used to respond to multiple processing requests and obtain request response results. This can also be achieved by performing the following steps: storing multiple processing requests received by the first resource cluster in a first request queue, and replicating each processing request in the first request queue to obtain multiple replica processing requests; storing each replica processing request in a second request queue; retrieving each replica processing request from the second request queue; and using the second resource cluster to respond to each replica processing request and obtain request response results.

[0082] Here, a request queue is created in the first resource cluster, also known as the first request queue, to store multiple processing requests received by the first resource cluster. Each processing request in the first request queue is retrieved by accessing its storage interface, and each processing request is replicated to obtain multiple replica processing requests. A request queue is then created in the second resource cluster, also known as the second request queue, to store multiple replica processing requests. Enqueue and dequeue operations are performed on the replica processing requests in the second request queue. Each replica processing request is retrieved from the second request queue, and using the second resource container in the second resource cluster, request information parsing and request business logic processing are performed on each replica processing request to obtain the request response result for each replica processing request.

[0083] In this embodiment, multiple processing requests received by the first resource cluster are stored in a first request queue, and each processing request in the first request queue is copied to obtain multiple replica processing requests. Each replica processing request is stored in a second request queue, and then the second resource cluster is used to respond to each replica processing request to obtain the request response result. This realizes the construction of a test case set for the resource component version in the simulation cluster based on the processing requests received by the first resource cluster, avoiding the need for manual construction of the test case set, thereby improving the efficiency of resource component version testing.

[0084] In some embodiments, when the target resource component is a system component, version testing of the system component includes functional testing and performance testing, see [link to documentation]. Figure 3C , Figure 3C This is a schematic diagram of the third process of the testing method provided in the embodiments of this application. Figure 3A Step 304 shown can be achieved through Figure 3C Steps 3046 to 3049 are implemented, and will be explained in detail below.

[0085] In step 3046, functional test requests and performance test requests for system components are determined from multiple processing requests.

[0086] Here, system components are the fundamental components for system operation. Functional test requests typically contain input data for specific functions of the system component, used to verify whether the updated system component can perform specific functions as expected. Performance test requests may contain specific load patterns of the system component, used to test the stress performance of the updated system component. Request parameter analysis is performed on multiple processing requests; functional test requests may contain specific test case IDs, while performance test requests may contain parameters such as the number of simulated users or request frequency. Request path analysis can also be performed on multiple processing requests; functional test requests and performance test requests correspond to different test paths, thereby determining the functional test requests and performance test requests for the system component.

[0087] In step 3047, the second resource cluster is used to respond to the functional test request, perform functional tests on the system components, and obtain the first request response result.

[0088] Here, the first request response result is the response result of the system component's functional testing request. The second resource container in the second resource cluster contains the computing services required for functional testing. Based on the second kernel runtime of the second resource container, it responds to the functional test request, that is, it parses and executes the business logic corresponding to the functional test request, and obtains the first request response result. For example, taking the computing power scheduler as the system component, it uses the second resource container in the second resource cluster, and based on the second kernel runtime of the second resource container, responds to the functional test request, performs functional testing on the computing power scheduler, obtains the first request response result, and then determines whether the computing power scheduler meets the new functional requirements based on the first request response result.

[0089] In step 3048, the second resource cluster is used to respond to the performance test request, perform performance tests on the system components, and obtain the second request response result.

[0090] Here, the second request response result is the response result of the system component's performance testing request. The second resource container in the second resource cluster contains the computing services required for performance testing. Based on the second kernel runtime of the second resource container, it responds to the performance test request, that is, it parses and executes the business logic corresponding to the performance test request, and obtains the second request response result. For example, taking the computing power scheduler as the system component, it uses the second resource container in the second resource cluster, and based on the second kernel runtime of the second resource container, it responds to the performance test request to perform performance tests on the computing power scheduler, such as platform scheduling, business scheduling, and scheduling status, and obtains the second request response result. Based on the second request response result, it is determined whether the computing power scheduler affects the platform scheduling logic, business scheduling logic, and scheduling status synchronization function.

[0091] In step 3049, the request response result is determined based on the first request response result and the second request response result.

[0092] In some embodiments, the request response result is determined based on the first request response result and the second request response result by performing the following steps: when both the first request response result and the second request response result are characterized as normal, the request response result is characterized as normal; when at least one of the first request response result and the second request response result is characterized as abnormal, the request response result is characterized as abnormal.

[0093] Here, the first request response result is characterized as a normal response, meaning the functional test response result of the updated system component meets the expected new functional requirements. The second request response result is characterized as a normal response, meaning the performance test response result of the updated system component meets the expected stress performance. When both the first and second request response results are characterized as normal, the system component's response results for multiple processing requests are characterized as normal. When at least one of the first and second request response results is characterized as an abnormal response, the system component's response results for multiple processing requests are characterized as abnormal.

[0094] In this embodiment, the request response result is determined based on the first request response result and the second request response result. This can combine the response results of the functional test request and the response results of the performance test request to determine the request response results of the system component in response to multiple processing requests, thereby improving the accuracy of determining the request response results of the system component.

[0095] In this embodiment of the application, when the target resource component is a system component, the version testing of the system component includes functional testing and performance testing. Using the second resource cluster, functional test requests and performance test requests are responded to respectively, and functional tests and performance tests are performed on the system component respectively, and the corresponding first request response results and second request response results are obtained. This realizes the testing of system components with updated versions in the simulation cluster. Abnormalities in the version testing of system components will not affect the online computing power service, thereby improving the quality of computing power service.

[0096] Continue to refer to Figure 3A In step 305, the version test result of the target resource component is determined based on the request response result.

[0097] Here, based on the request response results of the target resource component in response to multiple processing requests, the version test result of the target resource component is determined. The version test result is used to characterize whether the test result of the target resource component is normal, that is, whether the test result of the target resource component meets the expected result.

[0098] In some embodiments, when the target resource component is a system component, the version test result of the target resource component can be determined based on the request response result by performing the following steps: when the request response result indicates that the request response is normal, the version test result of the system component is determined to be normal; when the request response result indicates that the request response is abnormal, the version test result of the system component is determined to be abnormal.

[0099] Here, when a system component responds to multiple processing requests with a normal response, the system component's version test result is determined to be in line with expectations, i.e., the system component's version test result is considered normal. When a system component responds to multiple processing requests with an abnormal response, the system component's version test result is determined to be unsatisfactory, i.e., the system component's version test result is considered abnormal.

[0100] In this embodiment, when the request response result indicates that the request response is normal, the version test result of the system component is determined to be normal; when the request response result indicates that the request response is abnormal, the version test result of the system component is determined to be abnormal. This allows for accurate determination of the version test result of the system component based on the request response result.

[0101] In some embodiments, when the target resource component is a functional component, see [link to relevant documentation]. Figure 3D , Figure 3D This is a schematic diagram of the fourth process of the testing method provided in the embodiments of this application. Figure 3A Step 305 shown can be achieved through... Figure 3D Steps 3051 to 3053 are implemented, and will be explained in detail below.

[0102] In step 3051, the functional test results of the functional components are determined based on the request response results.

[0103] Here, the functional component includes multiple replicas. Each replica has the same application effect as the others. When a replica malfunctions, it can be replaced with another replica to restore its normal functionality. The request-response result of the functional component includes a response status code and response data. The response status code verifies whether the request was successfully responded to; for example, a successful response status code is 200, and a failed response status code is 404. The response data verifies whether the returned data meets expectations. The functional test result of the functional component is determined based on the response status code and response data.

[0104] In step 3052, the request response time and request response success rate are obtained.

[0105] During functional testing of functional components, the request response time, the number of request responses, and the number of successful request responses are measured. The ratio of the number of successful request responses to the total number of request responses is determined as the request response success rate.

[0106] In step 3053, when the functional test result is that the function is normal, the request response time is lower than the first preset threshold, and the request response success rate is higher than the second preset threshold, the version test result of the functional component is determined to be normal.

[0107] Here, the functional test result of a functional component is "functionally normal," meaning the functional test result meets the expected functional requirements. The first preset threshold is the request response time threshold, and the second preset threshold is the request response success rate threshold. When the functional test result is "functionally normal," the request response time is lower than the first preset threshold, and the request response success rate is higher than the second preset threshold, the version test result of the functional component is determined to meet the expected result, i.e., the version test result of the functional component is "test normal."

[0108] In this embodiment of the application, when the target resource component is a functional component, and the functional test result of the functional component is that the function is normal, the request response time is lower than the first preset threshold, and the request response success rate is higher than the second preset threshold, the version test result of the functional component is determined to be normal. This can combine the functional test result, the request response time, and the request response success rate to comprehensively determine the version test result of the functional component, thereby improving the accuracy of determining the version test result of the functional component.

[0109] In some embodiments, when the target resource component is a resource node component, the version test result of the target resource component can be determined based on the request response result by performing the following steps: when the request response result indicates that the resource node component can produce resource containers, the version test result of the resource node component is determined to be normal.

[0110] Here, the resource node component is a component used to produce resource containers. When it is determined that the resource node component can produce resource containers based on the request and response results of the resource node component, it is determined that the version test result of the resource node component meets the expected result, that is, the version test result of the resource node component is normal.

[0111] In this embodiment of the application, when the target resource component is a resource node component, and the request response result indicates that the resource node component can produce resource containers, the version test result of the resource node component is determined to be normal. Based on the request response result of the resource node component, the version test result of the resource node component can be accurately determined.

[0112] In some embodiments, after determining the version test result of the target resource component based on the request response result, the following steps may also be performed: when the version test result of the target resource component is a test exception, the target resource component is repaired to obtain a repaired target resource component; the version test result of the repaired target resource component is determined; when the version test result of the repaired target resource component is a test normal, the repaired target resource component is released.

[0113] Here, when the version test results of the target resource component do not meet expectations, i.e., the version test results of the target resource component are abnormal, the log file of the target resource component is checked to determine the abnormal information of the target resource component. When the abnormal information indicates that the configuration file of the target resource component is abnormal, the software packages and library files that the target resource component depends on are reconfigured; when the abnormal information indicates that the target resource component is corrupted, the corrupted target resource component is replaced with a backup target resource component; when the abnormal information indicates that the function of the target resource component is malfunctioning, the target resource component is restarted to repair it, resulting in a repaired target resource component.

[0114] Using the second resource cluster and the repaired target resource component, respond to multiple processing requests and obtain the request response results of the repaired target resource component.

[0115] When the request response result of the repaired target resource component is normal, the version test result of the repaired target resource component is determined to be normal. When the request response result of the repaired target resource component is abnormal, the version test result of the repaired target resource component is determined to be abnormal. When the version test result of the repaired target resource component is normal, the repaired target resource component is deployed online.

[0116] In this embodiment, when the version test result of the target resource component is abnormal, the target resource component is repaired, and when the version test result of the repaired target resource component is normal, the repaired target resource component is released. This realizes the testing and repair of resource components with updated versions in the simulation cluster. The abnormality of the resource component version test will not affect the online computing power service, thereby improving the quality of computing power service.

[0117] In some embodiments, the testing method provided in this application can be applied to the field of cloud technology. A first number of first resource containers in a first resource cluster is determined on a cloud platform, and a second number is determined based on the first number and a preset resource allocation ratio. Then, the second number of second resource containers is obtained, and a second resource cluster is constructed based on these second number of containers. This allows for the construction of simulated resource containers in a simulated cluster corresponding to the resource cluster, based on the number of resource containers in the resource cluster and the preset resource allocation ratio. Multiple processing requests and target resource components received by the first resource cluster are then obtained. The target resource component is a component whose version has been updated. Using the second resource cluster, multiple processing requests are responded to, and request response results are obtained. This achieves the construction of a test case set for the resource component version in the simulated cluster based on the processing requests received by the first resource cluster, avoiding manual construction of test case sets and thus improving the efficiency of resource component version testing. Finally, the version test result of the target resource component is determined based on the request response results. Therefore, by testing resource components whose versions have been updated in the simulated cluster, abnormal resource component version testing will not affect online computing power services, thereby improving the quality of computing power services.

[0118] The following will describe an exemplary application of the testing method provided in the embodiments of this application in a version testing scenario of heterogeneous computing power components.

[0119] With the research and development of large AI models, the scale of heterogeneous computing power services has increased significantly, and the business of heterogeneous computing power services is also diverse. Faced with the challenges of a large number and variety of businesses, how to reduce the impact of component version changes on the stability of computing power services and improve the quality of computing power services during the process of implementing heterogeneous computing power component changes is an urgent problem to be solved.

[0120] In related technologies, component release testing involves manually constructing a set of test cases based on the modifications made to the component. The test aims to verify the modified logic and achieve the desired component version testing. However, in services with diverse business scenarios, manually constructed test cases cannot cover all scenarios and require significant manpower. Furthermore, manually constructed test scenarios are limited and cannot simulate concurrent multi-user requests or high-load scenarios, especially for system component stress testing, which often fails to meet expectations. Inadequately tested components, when deployed to heterogeneous computing power online services, can trigger potential anomalies, thereby reducing the service quality of heterogeneous computing power.

[0121] This application proposes a testing method to address the problems existing in related technologies, which includes the following improvements compared to related technologies:

[0122] 1) Based on the requests from the live network (multiple processing requests received by the first resource cluster in the above embodiment), a set of test cases for the component version is constructed. This not only maintains the diversity of test cases, but also ensures that the request load pressure of the test environment is consistent with that of the live network. This avoids the need to manually construct test case sets, reduces the cost of test development manpower, and also improves the usability of component version testing.

[0123] 2) A simulation environment for heterogeneous computing power is built based on low-cost central processing unit (CPU) computing resources. This creates an isolated domain for component version testing. Tests of live network requests are executed in the isolated domain, physically isolating the live network environment. Anomalies in component version testing will not affect the live network. This can both verify the new features of the component version and isolate the impact of test anomalies, alleviating the operational pressure of heterogeneous computing power, improving the iteration efficiency of heterogeneous computing power component versions, and ensuring that the high frequency of component version iterations will not affect the stability of live network computing power services. This has a positive effect on the R&D efficiency of heterogeneous computing power.

[0124] Faced with the pressure of rapidly increasing heterogeneous computing power and diverse business needs, it is necessary to reduce the impact of component version changes on the stability of computing power services. The testing method proposed in this application optimizes the test case set for component version testing, transforming the traditional method of manually building test case sets into reusing live network requests as test case sets. Tests are conducted using live network requests in a constructed heterogeneous computing power simulation environment to observe the availability of updated components. Due to the high cost of heterogeneous computing power equipment, the simulation environment uses low-cost CPU computing resources, and each heterogeneous computing power container in the simulation uses virtualized 0.x cores to minimize the equipment cost of deploying the simulation environment. Since the live network requests belong to the user test request set, they inherit the diversity of test cases by default. For example, the user test request set includes AI training requests; during AI training, multiple AI training requests, such as text and voice, are integrated into a test case set. Furthermore, this reduces the manpower cost of manually building test cases when addressing diverse business testing needs. A heterogeneous computing environment was simulated using low-cost CPU devices, and this simulation environment was physically isolated from the heterogeneous computing environment of the online service. This created a heterogeneous computing simulation isolation domain for component version testing. This allows for the construction of a physically isolated test domain using the simulation environment, and testing is performed using live network requests for the component versions. Even if a system component experiences testing risks, it will not affect the heterogeneous computing service running live. Tests of live network requests are executed within the simulation isolation domain. Example test coverage of component version change scenarios is shown in Table 1.

[0125] Table 1. Version Change Components Covered by the Test

[0126]

[0127] The system components include the central control and production components of the computing cluster, such as components running on the master node in the container orchestration system and storage components. Each functional component in the multi-replica functional components has multiple instances, which are idempotent and can mutually support each other in disaster recovery. Implementing canary releases is a gradual deployment strategy for component versions during the deployment process. It involves gradually introducing new features or modifying components while ensuring user experience and system stability.

[0128] The testing method provided in this application supports mixed-model training, game AI model training, and conventional AI model training services. For example, see [link to example]. Figure 4 , Figure 4 This is a schematic diagram of the computing power structure supporting model training services provided in this application embodiment. In the heterogeneous computing power layer 401, computing power containers (first resource containers in the above embodiment) in the heterogeneous computing power cluster (first resource cluster in the above embodiment) are simulated through CPU computing power resources. In the simulation cluster in the simulation isolation domain (second resource cluster in the above embodiment), each simulation computing power container (second resource container in the above embodiment) is a 0.x container. A 0x container is a computing power container with 0.x cores, used to characterize the proportion of CPU resources allocated to a simulation computing power container, with the aim of controlling the expenditure cost of the simulation cluster. The heterogeneous computing power cluster receives user requests and mirrors them. Mirroring means forwarding the user request to the simulation cluster in the simulation isolation domain while keeping it unchanged. When a component version change is executed, in the component development layer 402, new version components such as system components, multi-replica functional components, and resource node components are preferentially changed in the simulation isolation domain used for simulation processing. Then, component testing is performed in the simulation isolation domain based on user requests to test the functionality and operational stability of the new version components. Product layer 403 includes mixed models, visual models, speech models, game models, medical models, and natural language processing models.

[0129] The testing method provided in this application constructs a heterogeneous computing power simulation isolation domain based on low-cost CPU computing resources, and verifies the version functionality and stability of component changes based on mirrored live network requests within the simulation isolation domain. For example, refer to... Figure 5 , Figure 5 This is a schematic diagram of the component version testing structure provided in an embodiment of this application. The following is in conjunction with... Figure 5 The component version testing structure provided in the embodiments of this application will be explained.

[0130] In the heterogeneous computing power cluster 503, one-to-one virtualization simulation of resource nodes is performed to reduce the cost of the simulation cluster. Taking a single-core computing power container in the heterogeneous computing power cluster 503 as an example, if the simulation of the computing power container is performed according to the simulation specification of 0.1 cores, 10 0.1-core containers can be produced in the simulation cluster 504. In this embodiment, the virtualization simulation adopts a time-division multiplexing fair mode virtualization method, that is, the running time of a single core is divided into N equal parts, and each simulated computing power container corresponds to one part of the running time. When the CPU core running time is allocated, the running time of each simulated computing power container is obtained by proportional division, that is, the ratio of the running time of each simulated computing power container to the running time of a single core is the same. There is no real heterogeneous computing power card in the simulated computing power container. The physical device with heterogeneous card will virtualize the device descriptor of the heterogeneous device at the kernel layer. The device descriptor is used to identify the heterogeneous computing power card, and the simulated computing power container simulates the heterogeneous computing power card through the device descriptor.

[0131] Due to the diversity of heterogeneous computing power services, manually constructed test case sets cannot cover all test scenarios. In this embodiment, the test case set originates from mirrored user requests, rather than manually constructed test cases. User test requests are stored in request queue 501. Requests in request queue 501 are distributed to the heterogeneous computing power cluster 503 and copied. User requests in request queue 501 are retrieved by accessing the request queue storage interface. These user requests are then copied and imported into the mirrored request queue 502. User requests in the mirrored request queue 502 are then enqueued and dequeued, i.e., a test request is retrieved from the mirrored request queue 502. The simulation isolation domain then performs functional and stress tests on the components based on this test request, thus reflecting the queue requests in the simulation isolation domain.

[0132] After the simulation cluster 504 and the image request queue 502 are built, a full component deployment is performed. This involves deploying the components driving simulation cluster 504 within the simulation isolation domain to power its heterogeneous computing power. During non-version change periods, the components in the simulation isolation domain must maintain version consistency with the live network components. If a new version of a component is deployed, it will be prioritized for deployment to the simulation cluster. New version components include system components, multi-replica functional components, and resource node components. Once the new version of the component has been successfully verified in the simulation cluster, it will be released to the online service's heterogeneous computing power cluster to drive it.

[0133] System components are fundamental to system operation, but scenarios exist where multiple replicas cannot operate in parallel. That is, if an anomaly occurs during a system component version change, it will affect the entire system. When testing system component versions using a simulation cluster, a striped testing strategy is employed. This involves dividing the interconnected functions of system components into several test flows, focusing on whether each test flow meets the component's functional and stability requirements. Taking the computing power scheduler as an example, the striped testing verification of the computing power scheduler is shown in Table 2:

[0134] Table 2. Stripe Test Verification Items for Computational Scheduler

[0135]

[0136] If all four stripe tests are normal, it can be inferred that there are no abnormalities in the development of the computing power scheduler.

[0137] The multi-replica functional component can monitor whether the new function has been fully implemented and whether requests are processed normally after a canary rollout is performed in the simulation cluster. In other words, it monitors whether the new function service is functioning normally and whether the processing time and success rate of requests are within acceptable limits. The resource node component can determine whether it is functioning correctly in the simulation cluster by checking whether the production of the computing power container can be executed normally. Both the multi-replica functional component and the resource node component require extended observation periods during the canary rollout process.

[0138] Example, reference Figure 6 , Figure 6 This is a flowchart illustrating the testing method provided in an embodiment of this application. The electronic device implementing the testing method of this application embodiment can be a server, combined with... Figure 6 The steps shown illustrate the component version testing process provided in the embodiments of this application.

[0139] In step 601, the node resource quantity of the heterogeneous computing power cluster is determined.

[0140] By analyzing the node resources of the heterogeneous computing power cluster, the number of virtualized CPU computing power resources used to build the simulation isolation domain can be obtained. For example, if the simulation requirement is 10,000 heterogeneous computing power cards, and each heterogeneous computing power card corresponds to 0.5 cores of CPU computing power resources, then the number of CPU computing power cores in the heterogeneous computing power cluster is 5,000. That is, one simulation computing power container corresponds to one 0.5-core heterogeneous computing power card. Producing 10,000 simulation computing power containers corresponds to 5,000 computing power containers in the heterogeneous computing power cluster.

[0141] In step 602, CPU computing resources are requested and a simulation cluster is deployed.

[0142] A simulation cluster is deployed based on virtualized CPU computing resources. For example, one simulation computing container is created based on 0.5 CPU computing resources in a heterogeneous computing cluster. If there are M CPU computing resources in the heterogeneous computing cluster, then 2M simulation computing containers are created in the simulation cluster.

[0143] In step 603, the production of the 0.x kernel container is completed in the simulation isolation domain.

[0144] One-to-one virtualization simulation of computing containers in heterogeneous computing power clusters can be performed. Taking a single-core computing container in a heterogeneous computing power cluster as an example, if the simulation of the computing container is performed according to the simulation specification of 0.1 core, 10 0.1 core containers can be produced in the simulation cluster.

[0145] In step 604, the construction of the simulation isolation domain is completed.

[0146] A simulation isolation domain is constructed based on the 0.x kernel container in the simulation cluster.

[0147] In step 605, user requests from the heterogeneous computing power cluster are read.

[0148] Receive and read user requests in a heterogeneous computing power cluster.

[0149] In step 606, the request is copied to the new request queue.

[0150] When a newer version of the component is available, the user request is copied from the request queue and mirrored into a new request queue.

[0151] In step 607, it is determined whether an updated component version exists.

[0152] If a newer component version exists, proceed to step 608 and send the requests in the new request queue to the simulation isolation domain; if no newer component version exists, end the component version testing process.

[0153] In step 609, it is determined whether the component whose version has been updated is a system component.

[0154] If the updated component is a system component, proceed to step 612 to determine the striped verification list. In step 613, determine whether the striped verification list is functioning correctly, and use the striped verification list to determine whether the system component is functioning correctly. If the striped verification list is malfunctioning, proceed to step 614 to report the anomaly to the component's development team for repair. If the striped verification list is functioning correctly, proceed to step 615. If the component version verification is successful, the component can be released to the production network.

[0155] If the updated component is not a system component, proceed to step 610, focusing on the new features and request processing success rate. In step 611, determine if the new features and request processing are functioning correctly, i.e., check if the new feature service is working properly and if the request processing time and success rate are normal. If the new features and request processing are abnormal, proceed to step 614, reporting the anomaly to the component's development team for fixing. If the new features and request processing are normal, proceed to step 615, verifying the component version. Once the component version verification is successful, it can be released to the production environment.

[0156] In the application scenarios of version testing for the aforementioned heterogeneous computing power components, the diversity of test cases is inherited by transforming the traditional manual construction of test cases into the construction of test cases using reusable live network requests. By building a simulation isolation domain based on low-cost CPU devices and performing replay tests of live network requests within the simulation isolation domain, component version anomalies will not affect the live network, improving the stability of computing power services, alleviating the operational pressure of heterogeneous computing power, reducing the R&D manpower cost of manually building test cases, and improving the iteration efficiency of heterogeneous computing power component versions, thus positively promoting the R&D efficiency of heterogeneous computing power.

[0157] The following description continues to illustrate the exemplary structure of the test apparatus 455 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the test device 455 in the memory 450 may include: a first determining module 4551, used to determine a first number of first resource containers in the first resource cluster, and determine a second number based on the first number and a preset resource allocation ratio; a first acquiring module 4552, used to acquire the second number of second resource containers, and construct a second resource cluster based on the second number of second resource containers; a second acquiring module 4553, used to acquire multiple processing requests and target resource components received by the first resource cluster, wherein the target resource component is a component whose version has been updated; a second determining module 4554, used to respond to multiple processing requests using the second resource cluster and obtain request response results; and a third determining module 4555, used to determine the version test result of the target resource component based on the request response results.

[0158] In some embodiments, the second determining module 4554 is further configured to determine the first kernel runtime of the first resource container, and divide the first kernel runtime based on the resource allocation ratio to obtain the second kernel runtime of the second resource container; based on the second kernel runtime, the second resource container is used to respond to multiple processing requests to obtain request response results.

[0159] In some embodiments, the second determining module 4554 is further configured to store multiple processing requests received by the first resource cluster into a first request queue, and replicate each processing request in the first request queue to obtain multiple replica processing requests; store each replica processing request into a second request queue; obtain each replica processing request from the second request queue; and respond to each replica processing request using the second resource cluster to obtain a request response result.

[0160] In some embodiments, when the target resource component is a system component, the version testing of the system component includes functional testing and performance testing. The second determining module 4554 is further configured to determine functional test requests and performance test requests for the system component from multiple processing requests; utilize the second resource cluster to respond to the functional test requests and perform functional testing on the system component to obtain a first request response result; utilize the second resource cluster to respond to the performance test requests and perform performance testing on the system component to obtain a second request response result; and determine a request response result based on the first request response result and the second request response result.

[0161] In some embodiments, the second determining module 4554 is further configured to characterize the request response result as normal when both the first request response result and the second request response result are characterized as normal; and to characterize the request response result as abnormal when at least one of the first request response result and the second request response result is characterized as abnormal.

[0162] In some embodiments, the second determining module 4554 is further configured to determine the version test result of the system component as normal when the request response result is characterized as a normal request response; and to determine the version test result of the system component as abnormal when the request response result is characterized as an abnormal request response.

[0163] In some embodiments, when the target resource component is a functional component, the third determining module 4555 is further configured to determine the functional test result of the functional component based on the request response result; obtain the request response time and request response success rate; and determine the version test result of the functional component as normal when the functional test result is normal, the request response time is lower than the first preset threshold, and the request response success rate is higher than the second preset threshold.

[0164] In some embodiments, when the target resource component is a resource node component, the third determining module 4555 is further configured to determine that the version test result of the resource node component is normal when the request response result indicates that the resource node component can produce resource containers.

[0165] In some embodiments, the third determining module 4555 is further configured to repair the target resource component when the version test result of the target resource component is abnormal, and obtain a repaired target resource component; determine the version test result of the repaired target resource component; and release the repaired target resource component when the version test result of the repaired target resource component is normal.

[0166] This application provides a computer program product, which includes computer-executable instructions or a computer program stored in a computer-readable storage medium. An electronic device's processor reads the computer-executable instructions or computer program from the computer-readable storage medium and executes the computer-executable instructions or computer program, causing the electronic device to perform the testing method described in this application.

[0167] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the test method provided in this application, for example... Figure 3A The test method is shown.

[0168] 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.

[0169] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, 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 stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0170] As an example, computer-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 co-located files (e.g., files that store one or more modules, subroutines, or code sections).

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

[0172] 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 testing method, characterized in that, The method includes: Determine the first number of first resource containers in the first resource cluster, and determine the second number based on the first number and a preset resource allocation ratio; Obtain the second number of second resource containers, and construct a second resource cluster based on the second number of second resource containers; Obtain multiple processing requests and target resource components received by the first resource cluster, wherein the target resource component is a component whose version has been updated; Using the second resource cluster, multiple processing requests are responded to, and request response results are obtained; The version test result of the target resource component is determined based on the request and response results.

2. The method according to claim 1, characterized in that, The process of utilizing the second resource cluster to respond to multiple processing requests and obtain request response results includes: Determine the first kernel runtime of the first resource container, and divide the first kernel runtime based on the resource allocation ratio to obtain the second kernel runtime of the second resource container; Based on the second kernel runtime, the second resource container is used to respond to multiple processing requests and obtain request response results.

3. The method according to claim 1, characterized in that, The method further includes: The first resource cluster receives multiple processing requests and stores them in a first request queue. Each processing request in the first request queue is then copied to obtain multiple replica processing requests. Each of the aforementioned copy processing requests is stored in the second request queue; Using the second resource cluster, multiple processing requests are responded to, and request response results are obtained, including: Retrieve each of the replica processing requests from the second request queue; Using the second resource cluster, respond to each of the replica processing requests to obtain the request response result.

4. The method according to claim 1, characterized in that, When the target resource component is a system component, the version testing of the system component includes functional testing and performance testing. The step of utilizing the second resource cluster to respond to multiple processing requests and obtain request response results includes: From the plurality of processing requests, determine the functional test requests and performance test requests for the system components; Using the second resource cluster, respond to the functional test request, perform functional tests on the system components, and obtain the first request response result; Using the second resource cluster, respond to the performance test request, perform performance tests on the system components, and obtain the second request response result; Based on the first request response result and the second request response result, the request response result is determined.

5. The method according to claim 4, characterized in that, The step of determining the request response result based on the first request response result and the second request response result includes: When both the first request response result and the second request response result indicate that the request response is normal, the request response result is indicated as normal. When at least one of the first request response result and the second request response result is characterized as a request response exception, the request response result is characterized as a request response exception.

6. The method according to claim 5, characterized in that, Determining the version test result of the target resource component based on the request-response result includes: When the request response result indicates that the request response is normal, the version test result of the system component is determined to be normal. When the request response result is characterized as a request response exception, the version test result of the system component is determined to be a test exception.

7. The method according to claim 1, characterized in that, When the target resource component is a functional component, determining the version test result of the target resource component based on the request response result includes: Based on the request and response results, determine the functional test results of the functional component; Get the request response time and request response success rate; When the functional test result is normal, the request response time is lower than the first preset threshold, and the request response success rate is higher than the second preset threshold, the version test result of the functional component is determined to be normal.

8. The method according to claim 1, characterized in that, When the target resource component is a resource node component, determining the version test result of the target resource component based on the request response result includes: When the request response indicates that the resource node component is capable of producing resource containers, the version test result of the resource node component is determined to be normal.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: When the version test result of the target resource component is abnormal, the target resource component is repaired to obtain the repaired target resource component; Determine the version test results of the repaired target resource component; When the test result of the repaired target resource component is normal, the repaired target resource component is released.

10. A testing apparatus, characterized in that, The device includes: The first determining module is used to determine the first number of the first resource containers in the first resource cluster, and to determine the second number based on the first number and a preset resource allocation ratio; The first acquisition module is used to acquire the second number of second resource containers and construct a second resource cluster based on the second number of second resource containers; The second acquisition module is used to acquire multiple processing requests and target resource components received by the first resource cluster, wherein the target resource component is a component whose version has been updated. The second determining module is used to utilize the second resource cluster to respond to multiple processing requests and obtain request response results. The third determining module is used to determine the version test result of the target resource component based on the request response result.

11. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, configured to execute computer-executable instructions or computer programs stored in the memory, implements the test method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the test method according to any one of claims 1 to 9 is implemented.

13. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the test method according to any one of claims 1 to 9 is implemented.

Images