Probe-based cloud native container module test method and related equipment

Abstract

The invention discloses a probe-based cloud native container module test method and related equipment. The method comprises the following steps: acquiring a target test unit and a preset verification rule; obtaining metadata according to the target test unit, analyzing the metadata, and determining target data information; performing data acquisition according to the target data information, a preset probe and kernel resources to obtain an original data set; performing rule conversion based on a preset verification rule and a preset pointer to obtain a target filtering condition; extracting key feature information according to the original data set, and performing multi-layer verification on the key feature information through a target filtering condition; obtaining a first test result, performing fault injection according to a preset fault type to test modules in the test unit to perform fault processing test, and determining a second test result; and determining a final test result according to the obtained first test result and the second test result. The embodiment of the invention can increase the test coverage range and reduce the resource consumption. The method can be widely applied to the technical field of testing.

Description

Technical Field

[0001] This application relates to the field of testing technology, and in particular to a probe-based cloud-native container module testing method and related equipment. Background Technology

[0002] With the popularization of cloud-native technologies, containerized applications are widely used in various fields. In order to ensure the stable operation of related processes, containerized applications need to be tested. Existing testing technologies usually adopt unit testing, which calls external component cluster resources to build corresponding test environments and tests the functional modules of containerized applications separately. This results in small test coverage and high resource consumption. Summary of the Invention

[0003] The main objective of this application is to propose a probe-based cloud-native container module testing method and related equipment, which can increase the testing coverage and reduce resource consumption.

[0004] To achieve the above objectives, one aspect of this application proposes a probe-based cloud-native container module testing method, the method comprising: Obtain the target test unit and preset verification rules, determine the metadata based on the target test unit, and parse the metadata to determine the target data information; The original dataset is determined by processing the target data information, preset probes, and kernel resources. The preset verification rules are transformed based on the preset probe to determine the target filtering conditions; Feature extraction is performed on the original dataset to determine key feature information, and multi-level verification is performed based on the target filtering conditions and the key feature information to determine the first test result; Injection tests are performed based on preset fault types to determine the second test result, and the final test result is determined based on the first test result and the second test result.

[0005] In some embodiments, parsing the metadata to determine the target data information specifically includes: The metadata is parsed to determine the target path information, and the target test units are filtered based on the target path information to determine the target process set; The target process set is analyzed to determine module characteristic information, and the target data information is determined based on the module characteristic information.

[0006] In some embodiments, the step of processing the target data information, preset probes, and kernel resources to determine the original dataset specifically includes: The target data information is parsed to determine the target module, and data is collected based on the preset probe and the target module to determine the target module data; The system is called according to the preset probe to determine system parameter information and return value data; The kernel resources are monitored using the preset probe to determine resource usage data. The target module data, system parameter information, return value data, and resource usage data are compressed to obtain the original dataset.

[0007] In some embodiments, the step of performing multi-layer verification based on the target filtering conditions and the key feature information to determine the first test result specifically includes: The target filtering conditions are parsed to determine multi-layer verification conditions and preset test cases; wherein, the multi-layer verification conditions include network layer verification conditions, application layer verification conditions, kernel layer verification conditions and performance layer verification conditions; The key feature information is tested according to the preset test cases to determine the third test result; the third test result is verified according to the multi-layer verification conditions to determine the first test result.

[0008] In some embodiments, the step of performing injection testing according to a preset fault type and determining the second test result specifically includes: A fault simulation event is generated based on the preset fault type, and the system is simulated for faults based on the fault simulation event to determine the current operating data of the system. The current system operation data is analyzed to determine fault handling information. The fault handling information is compared with the preset handling information to determine the second test result.

[0009] In some embodiments, the method further includes: The system's current operating data is analyzed based on the simulated fault events to determine fault handling link information; wherein, the fault handling link information includes processing node information; The current time information and the fault handling link information are processed to determine the node timestamp information, and the node timestamp information is matched with the fault handling link information according to the preset mapping relationship to determine the processing event ID information. Log records are determined by associating the fault handling link information, the node timestamp information, and the handling event ID information.

[0010] To achieve the above objectives, another aspect of this application proposes a probe-based cloud-native container module testing system, the system comprising: The acquisition module is used to acquire the target test unit and the preset verification rules, determine the metadata based on the target test unit, and parse the metadata to determine the target data information; The acquisition module is used to process the target data information, preset probes, and kernel resources to determine the original dataset; The conversion module is used to convert the preset verification rules according to the preset probe and determine the target filtering conditions; The first testing module is used to extract features from the original dataset, determine key feature information, and perform multi-level verification based on the key feature information to determine the first test result. The second testing module is used to perform injection tests according to preset fault types, determine the second test results, and determine the final test results based on the first test results and the second test results.

[0011] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0012] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0013] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0014] The embodiments of this application include at least the following beneficial effects: This application provides a probe-based cloud-native container module testing method, system, electronic device, storage medium, and program product. This solution obtains a target test unit and preset verification rules; parses the metadata obtained from the target test unit to determine target data information; collects data based on the parsed target data information, preset probes, and kernel resources to obtain a raw dataset; performs rule transformation based on preset verification rules and preset pointers to obtain target filtering conditions; extracts key feature information from the raw dataset and performs multi-layer verification on the key feature information through the target filtering conditions; obtains a first test result; then injects faults according to preset fault types to perform fault handling tests on the modules within the test unit, determining a second test result; and determines the final test result based on the first and second test results. The target data information is determined based on the metadata corresponding to the target test unit, and data is collected based on preset probes, target data information, and kernel resources, followed by subsequent multi-layer verification tests. This includes the entire chain data of business processing in each module of the target test unit within the test scope, improving test coverage. Simultaneously, data collection and verification testing via probes reduce the need to call external component clusters to build test environments, reducing resource consumption. Attached Figure Description

[0015] Figure 1 This is a flowchart of a probe-based cloud-native container module testing method provided in an embodiment of this application; Figure 2 yes Figure 1 The flowchart of step S101 in the text; Figure 3 yes Figure 1 The flowchart of step S102 in the document; Figure 4 yes Figure 1 The flowchart of step S104 in the process; Figure 5 yes Figure 1 The flowchart of step S105 in the process; Figure 6 yes Figure 1 Another flowchart of step S105 in the process; Figure 7 This is a schematic diagram of the structure of a test system in a specific embodiment provided in this application; Figure 8 This is a schematic diagram of the structure of a probe-based cloud-native container module testing system provided in an embodiment of this application; Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0017] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0018] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

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

[0020] This application provides a probe-based cloud-native container module testing method, relating to the field of information technology. This probe-based cloud-native container module testing method can be applied to terminals, servers, or software running on either a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent 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 server can also be a node server in a blockchain network. The software can be an application implementing a probe-based module testing method, but is not limited to the above forms.

[0021] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0022] Figure 1 This is an optional flowchart of a probe-based cloud-native container module testing method provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0023] Step S101: Obtain the target test unit and preset verification rules, determine the metadata based on the target test unit, and parse the metadata to determine the target data information; Step S102: Process the target data information, preset probes, and kernel resources to determine the original dataset; Step S103: Convert the preset verification rules according to the preset probe to determine the target filtering conditions; Step S104: Extract features from the original dataset, determine key feature information, and perform multi-level verification based on the target filtering conditions and key feature information to determine the first test result; Step S105: Perform injection testing according to the preset fault type, determine the second test result, and determine the final test result based on the first test result and the second test result.

[0024] Steps S101 to S105 as illustrated in this embodiment involve obtaining the target test unit to be tested and the user-configured verification test rules. Based on the interface of the containerized application of the target test unit, metadata corresponding to the target test unit is obtained. The obtained metadata is dynamically compiled, and identification information related to the target test unit is extracted as target data information, such as Cgroup path information and PID range. Then, a preset probe is loaded into the kernel of the containerized application. Based on the loaded probe, data from each functional module within the target test unit, as well as system call information and resource information in the kernel, are collected according to the obtained target data information. The data collected by the probe is organized to obtain the raw dataset. The user-set verification rules are transformed to obtain the filtering conditions that the probe can execute. The probe then processes the collected data... The original dataset is parsed and standardized to convert the data into a structured format, and key feature information, such as request frequency and error code distribution, is extracted. The probe then performs multi-layered verification on the structured data and key feature information obtained after processing the original dataset according to the converted filtering conditions. Based on the structured data and key feature information, corresponding verification tests are conducted at different stages of the business process to obtain the first test result. Next, fault simulation is performed on the target test unit according to pre-set fault types to determine the target test unit's fault handling and verify the operation of the fault response mechanism set by the target test unit, serving as the second test result. Finally, the first and second test results are combined to obtain the final test result of the target test unit.

[0025] Please see Figure 2 In some embodiments, step S101 may include, but is not limited to, steps S201 to S202: Step S201: Parse the metadata to determine the target path information, filter the target test units based on the target path information, and determine the target process set; Step S202: Analyze the target process set, determine the module feature information, locate the target data information based on the module feature information.

[0026] In step S201 of some embodiments, the target test unit's metadata is parsed to determine the Cgroup path of the target test unit in the containerized application. The process corresponding to the target test unit is filtered according to the path to avoid interference from other irrelevant data, thereby improving the accuracy and precision of the test results.

[0027] In step S202 of some embodiments, the relevant information of the functional module in the target detection unit is located by using module feature information in the metadata, such as process name, listening port, environment variables, etc., so as to conduct subsequent testing on the functional module and improve the accuracy of the test results.

[0028] Please see Figure 3 In some embodiments, step S102 may include, but is not limited to, steps S301 to S303: Step S301: Analyze the target data information, determine the target module, and collect data according to the preset probe and the target module to determine the target module data; Step S302: Make a system call according to the preset probe to determine the system parameter information and return value data; Step S303: Monitor kernel resources for events according to preset probes, determine resource usage data, and compress the target module data, system parameter information, return value data, and resource usage to obtain the original dataset.

[0029] In step S301 of some embodiments, the probe is loaded into the kernel of the containerized application. The probe parses the target data information obtained earlier to determine the information of the target functional module that needs to be verified and tested, and collects data based on the target functional module information to obtain the target module data. In this embodiment, a network data probe is set up to capture TCP / UDP packets that need to be verified and tested based on SOCKOPS and TC hooks. The packets include source and destination IPs, ports, protocol types, payloads, and other data information. Through the probe and the collected metadata, accurate data filtering is achieved to reduce interference from irrelevant module data, thereby improving the accuracy and reliability of the verification and test results.

[0030] In step S302 of some embodiments, in practical applications, containerized applications often encounter failures when interacting with different external components, such as cross-boundary interaction operations like network request sending and kernel system calls. By setting a probe to collect system call data associated with the target module in the kernel, the target module can be verified and tested during cross-boundary interaction with external components, thereby determining whether there are faults in the interaction logic of the target module and improving the accuracy of the verification test results. In this embodiment, system call probes are set to extract system call data from the kernel, and based on Kprobe hooking system calls such as connect / sendto / recvfrom, the corresponding system parameters and return values ​​are extracted.

[0031] In step S303 of some embodiments, when a kernel layer failure occurs during actual application of a containerized application, the containerized application will fail. Traditional testing schemes only focus on whether the return results of the functional modules in the containerized application are correct to determine whether the functional modules have failed, without considering the interaction between the functional modules and the kernel, or the risk of failure of the kernel itself. By setting probes to collect kernel resource status information, and combining it with the relevant system call data and running data of the functional modules for comprehensive verification and analysis, the failure of the functional modules can be accurately located, improving the accuracy and reliability of the verification test results. Then, the probes compress and filter the collected functional module data information, system call data, and kernel resource status information, retaining test-related fields, reducing the resource overhead of data transmission between the target test unit and the cloud application, thereby reducing costs.

[0032] Please see Figure 4 In some embodiments, step S104 may include, but is not limited to, steps S401 to S402: Step S401: Analyze the target filtering conditions to determine multi-layer verification conditions and preset test cases; wherein, the multi-layer verification conditions include network layer verification conditions, application layer verification conditions, kernel layer verification conditions and performance layer verification conditions. Step S402: Test the key feature information according to the preset test cases to determine the third test result; verify the third test result according to the multi-layer verification conditions to determine the first test result.

[0033] In step S401 of some embodiments, the user can pre-set test cases for testing, which serve as verification rules for verifying functional modules. The probe transforms the user-pre-set verification rules into executable filtering conditions, including filtering conditions at the network layer, application layer, kernel layer, and performance layer. The probe tests the data collected by the probe based on the transformed filtering conditions to determine whether the test results are normal, thereby determining whether the functional module has malfunctioned. In this embodiment, a test case management component is set up to manage the user-set verification rules. This component includes a rule conversion engine that converts the user-set verification rules into executable filtering conditions, enabling dynamic rule updates. The probe does not need to be restarted to load the updated verification rules, thereby improving the efficiency of verification testing.

[0034] In step S402 of some embodiments, the probe performs a structured format conversion on the acquired raw dataset to obtain data that the probe can process; the probe extracts features from the structured converted data to determine key feature information of the functional module, such as request frequency, data integrity, error code distribution, etc.; the probe performs hierarchical verification of the extracted key feature information according to the loaded filtering conditions; for example, for network layer data, the probe verifies the connection target, protocol type, handshake success rate, and other feature information of the test functional module to determine whether a network layer fault has occurred; for application layer data, the probe verifies the consistency between the test request / response data and the expected pattern to determine whether application layer data has occurred; the verification results are statistically summarized to obtain a first test result.

[0035] Please see Figure 5 In some embodiments, step S105 may include, but is not limited to, steps S501 to S502: Step S501: Generate a fault simulation event according to a preset fault type, and perform fault simulation on the system according to the fault simulation event to determine the current operating data of the system; Step S502: Analyze the current system operation data to determine fault handling information, compare the fault handling information with the preset handling information, and determine the second test result.

[0036] In step S501 of some embodiments, in practical applications, cloud-native services face abnormal scenarios such as network fluctuations, which may cause functional modules to malfunction. A fault injection mechanism is set up to simulate faults in the functional modules, and the fault handling mechanism initiated by the functional modules in response to the injected faults is tested to verify the fault tolerance capability of the functional modules. In this embodiment, possible fault types in business processing are pre-set, and probes are set to inject faults into the functional modules according to the set fault types to simulate corresponding abnormal scenarios; for example, 10s network latency, data packet loss, resource limitations, etc. Then, the probes collect system operation data in real time from the functional modules and target test units handling the abnormal scenarios, so as to analyze the fault tolerance capability of the functional modules and improve the stability of the functional modules in processing business.

[0037] In step S502 of some embodiments, the probe analyzes the collected system operation data to determine the data information called by the functional module to handle the injected fault, the called component information, the fault response mechanism activated, and other fault handling information; then the analyzed fault handling information is compared with the ideal fault handling information of the fault to determine the processing result of the functional module in the abnormal scenario simulated by the fault injection, test the fault tolerance capability of the functional module, and obtain the second test result.

[0038] Please see Figure 6 In some embodiments, step 105 may also include, but is not limited to, steps S601 to S603: Step S601: Analyze the current operating data of the system based on the fault simulation event to determine the fault handling link information; wherein, the fault handling link information includes processing node information; Step S602: Process the current time information and fault handling link information to determine the node timestamp information, and match it with the fault handling link information according to the preset mapping relationship to determine the processing event ID information; Step S603: Based on the fault handling link information, node timestamp information and handling event ID information, determine the log record.

[0039] In step S601 of some embodiments, the probe analyzes the collected system operation data according to the type of injected fault, tracks the processing link information of the injected fault according to the functional module of the verification test, determines the status information of the functional module in detecting the injected fault, and information on the external components called for the detected fault, etc., as well as information on the fault processing link. In this embodiment, the probe analyzes the recorded system operation data to record the complete data link of "module user mode - system call - kernel protocol stack - network transmission".

[0040] In step S602 of some embodiments, after the probe analyzes the system running data and determines that the injected fault is handled by the complete data link, the probe determines the event ID of the fault handling by the probe in each processing node according to the current time information. This is so that the handling of the fault scenario by the functional module can be retrospectively analyzed and the functional module can be adjusted accordingly to improve the stability of business processing.

[0041] In step S603 of some embodiments, after obtaining the event ID, event stamp information and complete data link, the probe associates the determined event ID and event stamp information with the previously determined complete data link and records it in the system log so that users can perform retrospective analysis of the fault scenario.

[0042] In some embodiments, the probe analyzes the collected system operation data and automatically marks abnormal nodes. For example, it detects "recvfrom returns EAGAIN error" and generates a fault causal chain diagram based on the analysis results, which shows that the functional module fails due to the injected fault. For example, "buffer full - sendto fails - request timeout", that is, because the buffer is full, the request sent by the functional module by calling sendto overflows, causing the functional module to experience a request timeout fault.

[0043] The solutions of the embodiments of the present invention will be described in detail and explained below with reference to specific application examples: In a specific embodiment, a probe-based cloud-native container module testing method provided in this application is applied to an eBPF-based Pod module testing system. This system achieves accurate testing of individual modules within a Pod through kernel-level data capture, layered verification, and lightweight environment construction. Please refer to [link to relevant documentation]. Figure 7The system architecture comprises an eBPF probe management component, a test case management component, a data verification and analysis component, and a fault injection and logging component, forming a closed loop of "data acquisition - test case management - verification and analysis - fault injection". The testing system acquires the target Pod's metadata through the eBPF probe management component, dynamically compiles the metadata, and loads the eBPF probe into the kernel. Then, the probe analyzes the acquired metadata to determine the target Pod's Cgroup path. Based on the determined path information, all processes of the Pod are filtered to reduce irrelevant data interference with subsequent tests, thereby improving test accuracy. Simultaneously, it uses module characteristics from the metadata, such as process name, listening port, and environment variables, to locate the target module's PID, and performs module localization based on the determined PID. The eBPF probe includes network data probes, system call probes, and kernel resource probes. By calling different probes, the system collects TCP / UDP packets, system call parameters, and returns from the target module. The system incorporates data on values ​​and kernel resources, bringing the entire link from module to kernel to external components into the testing scope, improving test coverage and thus increasing the accuracy and reliability of test results. The eBPF probe compresses and filters the collected data, retaining only test-related fields, and uses eBPFMap to achieve data transfer from kernel to user space. Then, a test case management component provides a visual interface and structured test case definition format, allowing users to configure multi-level verification rules and intuitively obtain test results for the target module. The system uses a rule transformation engine configured in the test case management component to convert user-defined verification rules into executable filtering conditions for the eBPF probe, such as BPF bytecode. The eBPF probe dynamically updates rules by loading the transformed filtering conditions. Based on the loaded filtering conditions, the eBPF probe performs verification tests on the previously collected data, achieving testing of the target module without needing to call an external component cluster to build a test environment, simplifying the testing process and improving testing efficiency.The system receives raw data collected by the eBPF probe through a data verification and analysis component, including data packets, system call parameters, and kernel resource data of the target module. It then converts the received raw data into a structured format and extracts key features to obtain the target module's key characteristic information. Next, it applies the converted filtering conditions for layered verification, obtaining verification results for the network layer, application layer, kernel layer, and performance layer. Based on the verification results, a test report is generated, and a visual comparison interface is provided to compare ideal values ​​with measured values. The system also simulates abnormal scenarios for the target module through a fault injection and logging component, performing fault injection and fault tolerance verification. This proactively verifies the target module's fault response mechanism and determines its fault tolerance capability. The system injects faults into the target module through this component, which is configured with different types of faults, including network faults and kernel faults. This includes data faults such as delayed packet loss, system call return errors, kernel resource overruns, and request tampering. After a fault is injected, the target module invokes its configured fault handling mechanisms, such as retry mechanisms and degradation measurements. The system analyzes data collected by eBPF probes to determine whether the configured fault handling mechanisms are functioning correctly and records the complete data processing chain of the injected fault by the target module. It also associates the timestamp information and event IDs of each link in the chain and saves them in the system log for backtracking analysis of the fault scenario. When analyzing the data collected by the eBPF probes, the system automatically marks the identified abnormal nodes and generates a fault causal chain diagram based on the marked node information and the corresponding event ID, so that users can formulate corresponding handling solutions based on the causal chain diagram. The fault tolerance capability of the target module is verified in advance through fault injection simulation and fault tolerance verification to improve the stability of business processing.

[0044] The embodiments of this application include at least the following beneficial effects: This application provides a probe-based cloud-native container module testing method, system, electronic device, storage medium, and program product. This solution obtains a target test unit and preset verification rules; parses the metadata obtained from the target test unit to determine target data information; collects data based on the parsed target data information, preset probes, and kernel resources to obtain a raw dataset; performs rule transformation based on preset verification rules and preset pointers to obtain target filtering conditions; extracts key feature information from the raw dataset and performs multi-layer verification on the key feature information through the target filtering conditions; obtains a first test result; then injects faults according to preset fault types to perform fault handling tests on the modules within the test unit, determining a second test result; and determines the final test result based on the first and second test results. The target data information is determined based on the metadata corresponding to the target test unit, and data is collected based on preset probes, target data information, and kernel resources, followed by subsequent multi-layer verification tests. This includes the entire chain data of business processing in each module of the target test unit within the test scope, improving test coverage. Simultaneously, data collection and verification testing via probes reduce the need to call external component clusters to build test environments, reducing resource consumption.

[0045] Please see Figure 8 This application also provides a probe-based cloud-native container module testing system that can implement the above-described method. The system includes: The acquisition module is used to acquire the target test unit and the preset verification rules, determine the metadata based on the target test unit, and parse the metadata to determine the target data information; The acquisition module is used to process the target data information, preset probes, and kernel resources to determine the original dataset; The conversion module is used to convert the preset verification rules according to the preset probe and determine the target filtering conditions; The first testing module is used to extract features from the original dataset, determine key feature information, and perform multi-level verification based on the key feature information to determine the first test result. The second testing module is used to perform injection tests according to preset fault types, determine the second test results, and determine the final test results based on the first test results and the second test results.

[0046] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0047] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0048] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0049] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 using the methods described in the embodiments of this application. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0050] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0051] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0052] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0053] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0054] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0055] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0056] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0057] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0058] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0059] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0060] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0061] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0062] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0064] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0065] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A probe-based cloud-native container module testing method, characterized in that, The method includes: Obtain the target test unit and preset verification rules, determine the metadata based on the target test unit, and parse the metadata to determine the target data information; The original dataset is determined by processing the target data information, preset probes, and kernel resources. The preset verification rules are transformed based on the preset probe to determine the target filtering conditions; Feature extraction is performed on the original dataset to determine key feature information, and multi-level verification is performed based on the target filtering conditions and the key feature information to determine the first test result; Injection tests are performed based on preset fault types to determine the second test result, and the final test result is determined based on the first test result and the second test result.

2. The method according to claim 1, characterized in that, The step of parsing the metadata to determine the target data information specifically includes: The metadata is parsed to determine the target path information, and the target test units are filtered based on the target path information to determine the target process set; The target process set is analyzed to determine module characteristic information, and the target data information is determined based on the module characteristic information.

3. The method according to claim 1, characterized in that, The step of processing the target data information, preset probes, and kernel resources to determine the original dataset specifically includes: The target data information is parsed to determine the target module, and data is collected based on the preset probe and the target module to determine the target module data; The system is called according to the preset probe to determine system parameter information and return value data; The kernel resources are monitored using the preset probe to determine resource usage data. The target module data, system parameter information, return value data, and resource usage data are compressed to obtain the original dataset.

4. The method according to claim 1, characterized in that, The step of performing multi-layer verification based on the target filtering conditions and the key feature information to determine the first test result specifically includes: The target filtering conditions are parsed to determine multi-layer verification conditions and preset test cases; wherein, the multi-layer verification conditions include network layer verification conditions, application layer verification conditions, kernel layer verification conditions and performance layer verification conditions; The key feature information is tested according to the preset test cases to determine the third test result; the third test result is verified according to the multi-layer verification conditions to determine the first test result.

5. The method according to claim 1, characterized in that, The step of performing injection testing based on preset fault types and determining the second test result specifically includes: A fault simulation event is generated based on the preset fault type, and the system is simulated for faults based on the fault simulation event to determine the current operating data of the system. The current system operation data is analyzed to determine fault handling information. The fault handling information is compared with the preset handling information to determine the second test result.

6. The method according to claim 5, characterized in that, The method further includes: The system's current operating data is analyzed based on the simulated fault events to determine fault handling link information; wherein, the fault handling link information includes processing node information; The current time information and the fault handling link information are processed to determine the node timestamp information, and the node timestamp information is matched with the fault handling link information according to the preset mapping relationship to determine the processing event ID information. Log records are determined by associating the fault handling link information, the node timestamp information, and the handling event ID information.

7. A probe-based cloud-native container module testing system, characterized in that, The system includes: The acquisition module is used to acquire the target test unit and the preset verification rules, determine the metadata based on the target test unit, and parse the metadata to determine the target data information; The acquisition module is used to process the target data information, preset probes, and kernel resources to determine the original dataset; The conversion module is used to convert the preset verification rules according to the preset probe and determine the target filtering conditions; The first testing module is used to extract features from the original dataset, determine key feature information, and perform multi-level verification based on the key feature information to determine the first test result. The second testing module is used to perform injection tests according to preset fault types, determine the second test results, and determine the final test results based on the first test results and the second test results.

8. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images