Container-based test method and device and computer equipment

Abstract

The invention relates to the technical field of testing, in particular to a container-based testing method and device and computer equipment. The method comprises the steps of generating a container mirror image corresponding to target equipment according to an equipment code of the target equipment and an operation dependency item of the equipment code in the target equipment; running the container mirror image in different test environments to obtain running results of the container mirror image in different test environments; and obtaining a test result of the container mirror image based on the operation results of the container mirror image in different test environments.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a container-based testing method, device and computer equipment. Background Art

[0002] Software-Defined Wide Area Network (SD-WAN) is a software-defined wide area network technology that uses software-defined networking (SDN) principles to manage and optimize the performance of wide area networks (WANs).

[0003] Currently, SD-WAN testing usually uses an automated testing framework.

[0004] However, the automated testing framework has limitations such as insufficient flexibility and a single testing model, making it difficult to adapt to the complex testing environment of SD-WAN during actual use. Therefore, improvement is urgently needed. Summary of the invention

[0005] Based on this, it is necessary to provide a container-based testing method, device and computer equipment that can improve testing flexibility in response to the above technical problems.

[0006] In a first aspect, the present application provides a container-based testing method, the method comprising:

[0007] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0008] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0009] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0010] In one embodiment, running the container image in different test environments to obtain the running results of the container image in the different test environments includes:

[0011] Build container orchestration configuration files;

[0012] According to the test requirements, build different test environments in the container orchestration configuration file and create container instances corresponding to the container images;

[0013] In each test environment, the container instance is run through the startup instructions corresponding to the container orchestration configuration file to obtain the running results of the container image in different test environments.

[0014] In one embodiment, the device code is compiled by using a coverage test compilation method; the container instance is run to obtain the running results of the container image under different test environments, including:

[0015] Run the container instance to obtain the device performance results of the container image in different test environments and the code execution coverage of the container instance during operation;

[0016] Determine the running results of the container image in different test environments based on the device performance results and code execution coverage.

[0017] In one embodiment, different test environments are constructed in the container orchestration configuration file according to the test requirements, including:

[0018] Different test environments are constructed in the container orchestration configuration file according to the network setting dimension requirements, environment variable dimension requirements, data volume dimension requirements, port mapping dimension requirements, and test case dimension requirements in the test requirements.

[0019] In one of the embodiments, if the container orchestration configuration file includes different container images, the different container images are networked.

[0020] In one of the embodiments, the test case dimension requirement includes at least one unit test code.

[0021] In a second aspect, the present application also provides a container-based code testing device, comprising:

[0022] A container image generation module, used to generate a container image corresponding to a target device according to a device code of the target device and running dependencies of the device code in the target device;

[0023] The container image test module is used to run the container image in different test environments and obtain the running results of the container image in different test environments;

[0024] The test result generation module is used to obtain the test result of the container image based on the running results of the container image in different test environments.

[0025] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0026] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0027] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0028] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0029] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the following steps are implemented:

[0030] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0031] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0032] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0033] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0034] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0035] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0036] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0037] The above container-based testing method, device and computer equipment, this application generates a corresponding container image based on the target device code and its running dependencies in the target device, taking advantage of container technologies such as containers, and can package and distribute device codes and their dependent environments, ensuring the consistency of the target device in different test environments. Test cases for the container image are obtained, which can cover various functional scenarios of the target device. Based on the running results of the container image in different test environments, the performance and stability of the target device code in different scenarios can be comprehensively analyzed to adapt to complex test scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0039] Figure 1 is a flow chart of a container-based testing method in one embodiment;

[0040] Figure 2 A schematic diagram of a process for building any test environment of a container image in an embodiment;

[0041] Figure 3 A flowchart of steps for running a container instance and obtaining running results of a container image in different test environments in one embodiment;

[0042] Figure 4 A schematic diagram of an application environment of a container-based testing method in an embodiment;

[0043] Figure 5 is a flow chart of a container-based testing method in another embodiment;

[0044] Figure 6 is a structural block diagram of a container-based code testing device in one embodiment;

[0045] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0047] Software-Defined Wide Area Network (SD-WAN): Utilizes the principles of SDN (software defined networking) to optimize WAN performance.

[0048] DPDK (Data Plane Development Kit): An open source data plane development kit focused on fast packet processing.

[0049] VPP (Vector Packet Processing): An open source vector packet processing framework designed for high-performance networks.

[0050] Unit Testing: Testing that checks the correctness of the smallest unit of software design (usually a function or method). The purpose of unit testing is to find errors within the module and ensure that each unit works as expected.

[0051] Test coverage: an indicator to measure the testing of functional code. The adequacy of the test is quantified by counting the number of simulated scenarios such as lines, branches, and classes in the functional code in the unit test.

[0052] SD-WAN CPE (Customer Premises Equipment): Software-defined WAN customer edge equipment, deployed in enterprise branches or remote offices to connect the enterprise's internal network and external WAN.

[0053] With the continuous innovation and accelerated development of network communication technology, a series of high-performance, open source technology frameworks such as DPDK (Data Plane Development Kit) and VPP (Vector Packet Processing Framework) have emerged. DPDK and VPP not only optimize the network forwarding capabilities of SD-WAN devices, but also their accompanying automated testing frameworks, such as VPP's CSIT (Continuous System Integration and Test System) and DPDK's DTS (Test Suite), have been adopted by the SD-WAN development and testing team. These frameworks are used to perform detailed unit tests on related modules in SD-WAN devices.

[0054] In the R&D process of SD-WAN equipment, the development and testing team needs to conduct comprehensive testing of the equipment. Among them, improving the code coverage of the test is a key indicator to measure whether the testing work is in place. Therefore, in the actual project development process, test coverage acceptance criteria are usually established as clear requirements and constraints for developers' unit testing work, thereby ensuring that every line of code has been fully tested and verified. By drawing on the automated unit testing framework of DPDK / VPP, the development and testing team can, to a certain extent, ensure that the basic DPDK / VPP unit tests are effectively executed, thereby improving the test coverage of these key modules.

[0055] Although these automated testing frameworks have many advantages, they also have certain limitations. Due to the relatively limited flexibility of the framework and the diversity of test models, they cannot fully cover all complex scenarios in SD-WAN networks.

[0056] In an exemplary embodiment, Figure 1 As shown, a container-based testing method is provided, and the method is applied to a computer device as an example for explanation. The computer device may be a device for performing code testing, including:

[0057] S101, generating a container image corresponding to the target device according to a device code of the target device and running dependencies of the device code in the target device.

[0058] The target device is the SD-WAN device. The device code refers to the SD-WAN device code, which refers to the program code running on the SD-WAN (Software-Defined Wide Area Network) device. These codes are the core components of the SD-WAN device and are responsible for implementing various functions and features of the device, including but not limited to network connection, data transmission, routing selection, security encryption, etc.

[0059] Among them, the running dependencies in the target device refer to various resources and environment settings required for the device code to run on the target device; optionally, the running dependencies of the device code in the target device include at least library files, runtime environment and running configuration files. It can be understood that for SD-WAN devices, their device codes usually require the following dependencies at runtime: SD-WAN devices may rely on specific network libraries, encryption libraries, protocol libraries, etc. to implement their functions. For example, the DPDK (Data Plane Development Kit) library is used to improve the processing performance of the data plane, and the OpenSSL library is used to implement encryption functions. Further, the SD-WAN device may require a specific runtime environment to execute its code. For example, an SD-WAN device based on VPP (Vector Packet Processing) requires a VPP runtime environment to process network packets. Further, the configuration files of the SD-WAN device are used to define its network settings, security policies, routing information, etc. These running configuration files need to be included in the image when containerized and loaded correctly when the container is started.

[0060] Optionally, generate a container image corresponding to the target device, including the following two steps:

[0061] (1) SD-WAN device image generation: Select the base image of the SD-WAN device, install all dependencies required by the SD-WAN device on the base image, including library files, runtime environment, etc., copy the device code and necessary configuration files of the SD-WAN device to the appropriate locations in the image, set the necessary environment variables so that the SD-WAN device can find its dependencies when the container is running, specify the command or script to be executed when the container is started to start the SD-WAN device, and thus obtain the SD-WAN image.

[0062] (2) Container image generation: Use the Docker build tool to build the container image corresponding to the SD-WAN image according to the Dockerfile. During the build process, Docker will execute the instructions in the Dockerfile in order and eventually generate a container image that contains the SD-WAN device code and all its dependencies.

[0063] Specifically, create a Dockerfile that contains instructions for installing dependencies, copying compiled binaries, setting environment variables, and defining entry points. Use the docker build command to build a container image and tag it as sdwan-image-gcov.

[0064] S102, running the container image in different test environments to obtain running results of the container image in different test environments.

[0065] Among them, different test environments are generated according to test requirements.

[0066] Specifically, in each test environment, pre-prepared test cases are executed, and then the entire test environment is started to execute the test cases to verify the functions and performance of the container image of the SD-WAN device in the test environment, that is, to obtain the running results of the container image in different test environments.

[0067] S103, obtaining a test result of the container image based on the running results of the container image in different test environments.

[0068] Optionally, real-time monitoring of log output, network traffic, resource usage and other indicators during the test process can be used to obtain the execution results of each test case, including success, failure, exception, etc. Statistics and analysis of the execution results of the test cases can be performed to obtain the test results of the container image, and the quality and stability of the container image can be evaluated based on the test results.

[0069] In the above container-based testing method, this application generates a corresponding container image based on the target device code and its running dependencies in the target device, taking advantage of container technologies such as containers, and can package and distribute device code and its dependent environment, ensuring the consistency of the target device in different test environments. Test cases for the container image are obtained, which can cover various functional scenarios of the target device. Based on the running results of the container image in different test environments, the performance and stability of the target device code in different scenarios can be comprehensively analyzed to adapt to complex test scenarios.

[0070] In an exemplary embodiment, Figure 2 As shown, any test environment of the container image is constructed in the following way:

[0071] S201, build a container orchestration configuration file.

[0072] The container orchestration configuration file may be a docker-compose.yml file.

[0073] As you can understand, define multiple SD-WAN appliance services in the docker-compose.yml file, each service using the sdwan-image-gcov image built previously. Define the docker-compose network so that all SD-WAN appliance containers can communicate in the same network.

[0074] Furthermore, based on the docker-compose.yml file, the docker-compose command can be used to easily manage and orchestrate multiple container services. Each container service corresponds to a container image, and management and orchestration actions include start, stop, and restart. Defining a network can ensure that communication between containers is isolated and secure.

[0075] S202: Build different test environments in the container orchestration configuration file according to the test requirements, and create a container instance corresponding to the container image.

[0076] The test requirements may include the test objectives, scope, conditions, etc. Determine which configuration parameters need to be adjusted to meet the test requirements. Configuration parameters may include network settings, environment variables, data volumes, port mappings, resource limits (such as CPU, memory), security settings, etc.

[0077] Furthermore, according to the test requirements, modify the docker-compose.yml file. In the docker-compose.yml file, specify different configuration parameters for different services (i.e. container images). You can use conditional statements or variable replacements to dynamically adjust the configuration according to the test requirements.

[0078] Use the modified container orchestration configuration file to create a container instance through docker-compose. When creating a container instance, you can specify additional command line parameters or environment variables as needed to further customize the test environment.

[0079] S203, in each test environment, run the container instance through the startup instruction corresponding to the container orchestration configuration file to obtain the running results of the container image in different test environments.

[0080] Optionally, after verifying that the test environment is correct, start the container instance through docker-compose and start the test. According to the test requirements, run the corresponding test script or command, and record the test results to obtain the running results of the container image in different test environments.

[0081] In one of the embodiments, different test environments are constructed in the container orchestration configuration file according to the test requirements, including: constructing different test environments in the container orchestration configuration file according to the network setting dimension requirements, environment variable dimension requirements, data volume dimension requirements, port mapping dimension requirements and test case dimension requirements in the test requirements.

[0082] Optionally, if the container orchestration configuration file includes different container images, the different container images are networked.

[0083] Optionally, the configuration of the network setting dimension refers to specifying the configuration of the memif interface in the docker-compose.yml file and in the configuration file of the SD-WAN device, including the interface name, IP address, subnet mask, etc. Ensure that all SD-WAN device container images are configured with the same or mutually reachable memif interface. The memif interface is an efficient way for container images to communicate with each other, suitable for scenarios that require high performance and low latency. SD-WAN device container images can communicate through the memif interface to achieve interconnection

[0084] Optionally, the configuration of the data volume dimension refers to mounting the host's directory or file to a specific directory inside the container, thereby achieving data sharing and synchronization between the host and the container. This configuration method is of great significance when testing SD-WAN devices because it allows testers to flexibly change and access data and configuration files inside the container without modifying the container image. For example, in the docker-compose.yml file, add volumes mounts for each SD-WAN device service, and mount the host's test configuration directory to a specific directory of the container image (such as / etc / vpp). The mounted directory makes it easy to change the configuration file without rebuilding the container image, making the test more flexible and customizable. The behavior of the SD-WAN device inside the container can be affected by changing the configuration file on the host without rebuilding or starting the container.

[0085] Optionally, the configuration of the port mapping dimension means adding ports mapping for each SD-WAN device service in the docker-compose.yml file, mapping the host's port to the container image's SSH port. The mapped port makes it easy to access the container image's SSH service from the host for testing or debugging. The SSH service of the SD-WAN device container image can be accessed directly through the host's port without entering the container image.

[0086] Optionally, the configuration of the test case dimension refers to writing test cases in the docker-compose.yml file.

[0087] Specifically, the test case dimension requirement includes at least one unit test code.

[0088] Optionally, you can use Python's unittest or pytest framework to write unit test code for SD-WAN devices. In these test codes, different configuration variables can be passed in a parameterized manner to execute the same test logic in different test scenarios.

[0089] Among them, the configuration variables may include the number of CPU cores, the number of network card queues, and the DPDK encryption and decryption backend.

[0090] Optionally, the number of CPU cores can be specified for the SD-WAN appliance container in the container orchestration configuration file (such as docker-compose.yml). This can be achieved by setting resource limits, such as using the --cpus option of Docker or CPU resource requests and limits of Kubernetes. The number of CPU cores determines the amount of CPU resources that the container can use, which in turn affects the processing power and throughput of the SD-WAN appliance.

[0091] The number of NIC queues can be named NIC_QUEUES or something similar. This configuration usually requires network configuration inside the container or on the host. For Docker, you may need to specify the number of NIC queues via the --network option or network plugin when starting the container. For Kubernetes, you can set it using network policy or the network configuration of the Pod. The number of NIC queues affects the processing capacity and concurrency of network traffic, which is very important for SD-WAN devices that require high throughput and low latency.

[0092] DPDK encryption and decryption backend: can be named DPDK_CRYPTO_BACKEND. This configuration usually needs to be done inside the SD-WAN device container. You may need to specify the encryption and decryption backend used by DPDK through environment variables, command line parameters, or configuration files when the container is started. The choice of DPDK encryption and decryption backend directly affects the performance and efficiency of data encryption and decryption, which is crucial for SD-WAN devices that need to handle large amounts of encrypted traffic.

[0093] Specifically, in the docker-compose.yml file, use the environment keyword to set environment variables. In the Docker command line, use the -e option to pass environment variables. In Kubernetes, you can set environment variables through the env field of the Pod, or pass configuration information through ConfigMap and Secret.

[0094] It is understandable that common configuration variables are abstracted and used in the test code by passing parameters. In this way, when the configuration needs to be changed, only the parameter value passed to the test function needs to be modified without modifying the internal logic of the test function. The above method improves the reusability and maintainability of the test code.

[0095] In an exemplary embodiment, the device code is compiled using a coverage test compilation method.

[0096] Among them, add gcov compilation options such as -fprofile-arcs and -ftest-coverage in the compilation script or Makefile of the SD-WAN project. This will cause the compiler to generate files for coverage analysis.

[0097] Correspondingly, such as Figure 3 As shown in the figure, based on the running test cases, the running results of the container image in the test environment include:

[0098] S301, running the container instance to obtain the device performance results of the container image under different test environments and the code execution coverage of the container instance during operation.

[0099] Specifically, in the started container service, run the test cases for the SD-WAN container image. The test cases should include verification of various functions of the container image, such as connectivity, message processing, encryption and decryption performance, etc.

[0100] During the test case execution, the performance indicators of the container are recorded in real time through the monitoring tools provided by the container or third-party performance monitoring software. Performance indicators include but are not limited to CPU usage, memory usage, network throughput, latency, etc. After the test case is completed, the performance indicator data is collected and analyzed. Compare the expected performance standards with the actual test results to evaluate the performance of the container image in the test environment.

[0101] Furthermore, when compiling the SD-WAN code, use the coverage test compilation method (such as using the gcov tool) to insert coverage test-related code segments into the source code. After compilation, the generated container image will contain the information required for coverage testing. When running test cases in the container service, enable the coverage test function at the same time. The coverage test will record the execution of each code segment of the container image during operation. After the test case runs, collect the generated coverage data files (such as .gcda and .gcno files). These files contain specific data on code execution coverage.

[0102] Use a coverage analysis tool such as gcovr to convert the collected coverage data files into an easy-to-understand coverage report. The coverage report will show which code segments are executed, which are not executed, and the overall coverage percentage.

[0103] S302: Determine the running results of the container image under different test environments according to the device performance results and the code execution coverage.

[0104] Specifically, the running results of the container image in the test environment are comprehensively evaluated based on the device performance results and code execution coverage. The evaluation content includes whether the performance meets the standards, whether there are performance bottlenecks, and whether the code coverage meets the requirements.

[0105] In an exemplary embodiment, Figure 4 As shown in the figure, an application environment of a container-based testing method is provided, including SD-WAN devices, headquarters campus, and branch campus; the headquarters campus communicates with the branch campus through the SD-WAN device. The simulation of the headquarters-branch direct connection scenario requires two CPE devices: one simulates the branch device (low-end device) and is configured with fewer resources; the other simulates the headquarters device (mid-to-high-end device), allocates more memory and CPU resources, and uses IPsecMB for encryption and decryption processing to improve performance. In order to achieve the flexibility and convenience of unit testing, variables such as memory, CPU, encryption and decryption backend are defined in the test case, which will assist in generating the configuration file of the SD-WAN CPE device.

[0106] Based on the above application environment, an optional implementation of the container-based testing method is provided, such as Figure 5 As shown, the following process is included:

[0107] S501, compile and generate gcov dependency information to create a container image for the SD-WAN device:

[0108] During the image compilation process of SD-WAN CPE, the gcov method was used, that is, the -fprofile-arcs and -ftest-coverage parameters were added during source code compilation. This will generate a .gcno file during compilation, which contains the basic code blocks, line numbers and other information of the source code, which facilitates the subsequent statistical code test coverage. After the compilation is completed, the image is deployed into the container using Dockerfile to generate the container image of SD-WAN CPE for rapid deployment in the subsequent test environment.

[0109] S502, arrange docker-compose.yml according to test requirements;

[0110] Specifically, in the docker-compose.yml file, define the headquarters CPE as a high-end device, and the encryption backend device as ipsecmb; define the branch CPE as a low-end device, and the encryption backend device uses openssl. In this way, you can flexibly cover various test scenarios by reading the environment variables in the orchestration file or overwriting their initial values, and generate corresponding configuration files. Then execute the docker-compose up command to start the entire test environment and achieve one-click deployment and launch.

[0111] During this process, we used the unittest and pytest modules provided by Python to build a highly scalable test framework. The framework provides a wealth of test tools and methods, including test code, test suites, assertions, etc., and provides general class interfaces such as setUp() / teardown(). Developers can focus on the implementation of business logic and quickly implement or reuse related test cases. In the setUp() interface, set more CPU cores according to the properties of the headquarters device, specify the DPDK encryption and decryption backend device as IPsecMB, and set whether to enable functions such as message reassembly as needed, and then generate the corresponding VPP configuration file startup.conf.

[0112] S503, executing unit test;

[0113] Specifically, specific test steps are set, such as setting up the respective memif interfaces for connectivity testing, setting up encryption and decryption ike profiles and triggering negotiation, packet capture inspection and other general test steps. These test steps will verify the basic connectivity function of the CPE, the IKE message handoff function, the IPsec MB encryption and decryption function and other related codes.

[0114] S504, using gcovr to generate a coverage report.

[0115] Optionally, since the image uses the gcov compilation method, a code test coverage statistics .gcda file will be automatically generated during runtime. After the entire unit test is completed, use the gcovr command to generate a detailed test coverage report. This helps to find code problems that do not meet expectations and check which scenarios are not covered, thereby ensuring the quality of software development.

[0116] Exemplarily, based on the above application environment, this embodiment provides a specific docker-compose.yml file, which includes the following contents:

[0117] yaml

[0118] version: "3.2" #Specify the Docker Compose file version. Version 3.2 supports multiple services, environment variables, volume mounting, etc.

[0119] services: #Define the services (containers) to run

[0120] cpe1: # The name of the first service, representing the CPE device at the headquarters

[0121] image: sdwan-cpe:latest # Use the Docker image named sdwan-cpe with the tag latest

[0122] environment: #Set environment variables

[0123] LEVEL: high # Set the device level to high

[0124] CRYPTO: ipsecmb # Set the encryption and decryption backend to ipsecmb

[0125] ports: #Port mapping

[0126] - "127.0.0.1:2022:22" # Map the host's port 2022 to the container's port 22 for SSH access

[0127] volumes: # Volume mount

[0128] - "$PWD / memif_dir: / var / run / memif" #Mount the memif_dir in the current directory of the host to the container's / var / run / memif

[0129] - "$PWD / $role: / etc / vpp" #Mount the directory specified by the $role variable in the current directory of the host to the / etc / vpp of the container ($role needs to be defined externally)

[0130] - " / etc / machine-id: / etc / machine-id" #Mount the host's / etc / machine-id file to the same location as the container to maintain consistency of the machine ID

[0131] cpe2: # The name of the second service, representing the branch CPE device

[0132] image: sdwan-cpe:latest # Also use the Docker image named sdwan-cpe, tagged as latest

[0133] environment: #Set environment variables

[0134] LEVEL: lower # Set the device level to low end

[0135] CRYPTO: openssl # Set the encryption and decryption backend to openssl

[0136] ports: #Port mapping

[0137] -"127.0.0.1:2023:22" # Map the host's port 2023 to the container's port 22 for SSH access

[0138] volumes: # Volume mount

[0139] - "$PWD / memif_dir: / var / run / memif" #Mount the memif_dir in the current directory of the host to the container's / var / run / memif

[0140] - "$PWD / $role: / etc / vpp" #Mount the directory specified by the $role variable in the current directory of the host to the / etc / vpp of the container ($role also needs to be defined externally)

[0141] - " / etc / machine-id: / etc / machine-id" #Mount the host's / etc / machine-id file to the same location in the container

[0142] # Note: $PWD represents the current working directory, and $role is a variable that needs to be defined before running the docker-compose command.

[0143] # For example, you can set role=some_role on the command line and then run docker-compose up.

[0144] # In this way, $PWD / some_role will be mounted to the / etc / vpp directory of the container.

[0145] This docker-compose.yml file defines two services (cpe1 and cpe2), representing the SD-WAN CPE devices at the headquarters and branches respectively. They use the same image but configure different environment variables and port mappings to simulate different device levels and encryption and decryption backends. By mounting volumes, you can map the host's directories and files to the container, which facilitates persistent storage of configuration and data.

[0146] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0147] Based on the same inventive concept, the embodiment of the present application also provides a container-based code testing device for implementing the container-based testing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more container-based code testing device embodiments provided below can refer to the limitations of the container-based testing method above, and will not be repeated here.

[0148] In an exemplary embodiment, Figure 6 As shown, a container-based code testing device is provided, including: a container image generation module 11, a container image testing module 12 and a test result generation module 13, wherein:

[0149] The container image generation module 11 is used to generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0150] The container image testing module 12 is used to run the container image in different test environments to obtain the running results of the container image in different test environments;

[0151] The test result generating module 13 is used to obtain the test result of the container image based on the running results of the container image in different test environments.

[0152] In one of the embodiments, the container image testing module 12 is further used to: construct a container orchestration configuration file;

[0153] According to the test requirements, build different test environments in the container orchestration configuration file and create container instances corresponding to the container images;

[0154] In each test environment, the container instance is run through the startup instructions corresponding to the container orchestration configuration file to obtain the running results of the container image in different test environments.

[0155] In one of the embodiments, the test result generating module 13 is further used to: run the container instance to obtain the device performance results of the container image under different test environments and the code execution coverage of the container instance during operation;

[0156] Determine the running results of the container image in different test environments based on the device performance results and code execution coverage.

[0157] In one of the embodiments, the container image testing module 12 is further used to build different test environments in the container orchestration configuration file according to the network setting dimension requirements, environment variable dimension requirements, data volume dimension requirements, port mapping dimension requirements and test case dimension requirements in the test requirements.

[0158] In one of the embodiments, if the container orchestration configuration file includes different container images, the different container images are networked.

[0159] In one of the embodiments, the test case dimension requirement includes at least one unit test code.

[0160] Each module in the container-based code testing device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0161] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 7As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data of a container-based test method. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a container-based test method is implemented.

[0162] Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0163] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0164] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0165] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0166] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0167] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0168] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0169] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0170] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0171] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0172] Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device;

[0173] Run the container image in different test environments to obtain the running results of the container image in different test environments;

[0174] Based on the running results of the container image in different test environments, the test results of the container image are obtained.

[0175] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0176] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0177] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A container-based testing method, characterized in that: The method comprises: Generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device; Run the container image in different test environments to obtain the running results of the container image in different test environments; Based on the running results of the container image in different test environments, the test results of the container image are obtained.

2. The method according to claim 1, characterized in that: The step of running the container image in different test environments to obtain the running results of the container image in different test environments includes: Build container orchestration configuration files; According to the test requirements, build different test environments in the container orchestration configuration file, and create a container instance corresponding to the container image; In each test environment, the container instance is run through the startup instruction corresponding to the container orchestration configuration file to obtain the running results of the container image in different test environments.

3. The method according to claim 2, characterized in that The device code is compiled by using a coverage test compilation method; and the running of the container instance to obtain the running results of the container image under different test environments includes: Running the container instance to obtain device performance results of the container image under different test environments and code execution coverage of the container instance during operation; The running results of the container image under different test environments are determined according to the device performance results and the code execution coverage.

4. The method according to claim 2, characterized in that: According to the test requirements, different test environments are constructed in the container orchestration configuration file, including: According to the network setting dimension requirements, environment variable dimension requirements, data volume dimension requirements, port mapping dimension requirements and test case dimension requirements in the test requirements, different test environments are constructed in the container orchestration configuration file.

5. The method according to claim 2, characterized in that: If the container orchestration configuration file includes different container images, the different container images are networked.

6. The method according to claim 2, characterized in that The test case dimension requirement includes at least one unit test code.

7. A container-based code testing device, characterized in that: The device comprises: A container image generation module, used to generate a container image corresponding to the target device according to the device code of the target device and the running dependencies of the device code in the target device; A container image testing module, used to run the container image in different test environments to obtain the running results of the container image in different test environments; The test result generating module is used to obtain the test result of the container image based on the running results of the container image in different test environments.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

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

Images