Code testing method and device, electronic equipment and storage medium

Abstract

This application discloses a code testing method, apparatus, electronic device, and storage medium. The method includes: creating a first container and a second container corresponding to the code to be tested, allocating shared storage space for the first and second containers, obtaining the code to be tested through the first container, testing the code to be tested, obtaining test coverage data of the code to be tested generated by the first container and shared in the shared storage space, reading the test coverage data of the code to be tested from the shared storage space through the second container, and generating a test coverage file of the code to be tested based on the read test coverage data. The technical solution of this application embodiment can improve the accuracy of test coverage data.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a code testing method and apparatus, electronic equipment, storage medium, and program product. Background Technology

[0002] The entire software code development lifecycle involves multiple phases, including requirements gathering, system design, coding, unit testing, integration testing, system testing, acceptance testing, and subsequent maintenance and updates. The testing process plays a crucial role in ensuring the stability of software releases, and test coverage is an important indicator of the comprehensiveness and effectiveness of testing. Therefore, obtaining test coverage data is necessary during code testing.

[0003] In related technologies, test coverage data is easily lost and difficult to obtain, which reduces the accuracy of test coverage data, makes it impossible to accurately evaluate test results, and reduces software stability. Summary of the Invention

[0004] Embodiments of this application provide a code testing method and apparatus, electronic device, storage medium, and program product that can improve the accuracy of test coverage data.

[0005] In a first aspect, embodiments of this application provide a code testing method, the method comprising:

[0006] Create a first container and a second container corresponding to the code to be tested, and allocate shared storage space for the first container and the second container;

[0007] The code to be tested is obtained through the first container, and the code to be tested is tested to obtain test coverage data of the code to be tested generated by the first container and shared to the shared storage space;

[0008] The test coverage data of the code to be tested is read from the shared storage space through the second container;

[0009] Based on the read test coverage data, a test coverage file for the code to be tested is generated.

[0010] Secondly, embodiments of this application provide a code testing apparatus, the apparatus comprising:

[0011] Create a module, configure it to create a first container and a second container corresponding to the code to be tested, and allocate shared storage space for the first container and the second container;

[0012] The testing module is configured to obtain the code to be tested through the first container, test the code to be tested, and obtain test coverage data of the code to be tested generated by the first container and shared to the shared storage space.

[0013] The reading module is configured to read test coverage data of the code to be tested from the shared storage space through the second container;

[0014] The generation module is configured to generate a test coverage file for the code to be tested based on the read test coverage data.

[0015] Thirdly, embodiments of this application provide an electronic device, including:

[0016] At least one processor;

[0017] A storage device for storing at least one computer program, which, when executed by the at least one processor, causes the electronic device to implement the code testing method as described above.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor of an electronic device, causes the electronic device to implement the code testing method as described above.

[0019] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the code testing method as described above.

[0020] In the technical solution provided by the embodiments of this application, a first container and a second container corresponding to the code to be tested are created, and shared storage space is allocated to the first container and the second container. The code to be tested is obtained through the first container and tested to obtain test coverage data of the code to be tested generated by the first container and shared in the shared storage space. The test coverage data of the code to be tested is read from the shared storage space through the second container, and a test coverage file of the code to be tested is generated based on the read test coverage data. Compared with related technologies, on the one hand, a first container is created for testing the code to be tested and generating test coverage data, and the test coverage data is stored in a specific storage space through the first container, so that test coverage data can be obtained from the specific storage space, reducing the difficulty of obtaining test coverage data; on the other hand, a second container is created to store the test coverage data in the shared storage space of the first container and the second container, so that even if the first container is destroyed, the test coverage will not be lost, reducing the probability of test coverage data loss, improving the accuracy of the obtained test coverage data, and thus improving the accuracy of the generated test coverage file and the accuracy of the software to which the code to be tested belongs.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] Figure 1 This is a schematic diagram illustrating an implementation environment as shown in an exemplary embodiment of this application;

[0023] Figure 2 This is a flowchart illustrating a code testing method in an exemplary embodiment of this application;

[0024] Figure 3 This is a schematic diagram illustrating the relationship between the first container and the second container, as shown in an exemplary embodiment of this application;

[0025] Figure 4 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0026] Figure 5 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0027] Figure 6 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0028] Figure 7 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0029] Figure 8 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0030] Figure 9 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0031] Figure 10 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0032] Figure 11 This is a flowchart illustrating a code testing method as shown in another exemplary embodiment of this application;

[0033] Figure 12 This is a schematic diagram illustrating a code testing architecture as shown in an exemplary embodiment of this application;

[0034] Figure 13 This is a schematic diagram of the structure of a code testing device shown in an exemplary embodiment of this application;

[0035] Figure 14 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0036] Exemplary embodiments will now be described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be construed as limited to these examples; rather, these embodiments are provided so that this application will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art.

[0037] Furthermore, the features, structures, or characteristics described in this application can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to provide a full understanding of the embodiments of this application. However, those skilled in the art will recognize that when implementing the technical solutions of this application, not all the detailed features in the embodiments may be used, one or more specific details may be omitted, or other methods, elements, devices, steps, etc., may be employed.

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

[0039] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or at least two hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0040] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0041] It should also be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0042] The technical solutions of the embodiments of this application are described in detail below:

[0043] In related technologies, test coverage data is easily lost and difficult to obtain, thus reducing the accuracy of the test coverage data, making it impossible to accurately evaluate the test results, and reducing the stability of the software. Based on this, embodiments of this application provide a code testing method and apparatus, electronic device, storage medium, and program product that can improve the accuracy of test coverage data.

[0044] Please see Figure 1 , Figure 1 This is a schematic diagram of an implementation environment involved in this application, which includes a code testing device 101 and a container platform 102.

[0045] The code testing device 101 can be a physical device or a virtual device. A physical device can be a terminal device or a server. Terminal devices can include, but are not limited to, mobile phones, tablets, laptops, computers, voice interaction devices, home appliances, vehicle terminals, aircraft, remote driving terminals, etc. Servers can be independently deployed servers, distributed servers, or cloud servers utilizing 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 (Content Delivery Network), and big data and artificial intelligence platforms. Virtual devices include, but are not limited to, microservices and virtual machines. The code testing device 101 can be deployed in a container platform 102 or not.

[0046] Container Platform 102 is used to provide container services. Container services are cloud services based on container technology that provide highly scalable, high-performance container management services centered around containers. They allow users to directly deploy and run containerized applications without purchasing and managing underlying servers or virtual machines.

[0047] In an exemplary embodiment, the code testing method provided in the embodiments of this application can be executed by a code testing device 101. For example, the code testing device 101 can invoke the container service in the container platform 102 to create a first container and a second container corresponding to the code to be tested, and allocate shared storage space for the first container and the second container. This allows the device to obtain the code to be tested through the first container, perform testing on the code to be tested, and obtain test coverage data of the code to be tested generated by the first container and shared in the shared storage space. Then, the device reads the test coverage data of the code to be tested from the shared storage space through the second container, and generates a test coverage file corresponding to the code to be tested based on the read test coverage data. Compared to related technologies, on the one hand, a first container is created to test the code under test and generate test coverage data. The test coverage data is stored in a specific storage space through the first container, thus reducing the difficulty of obtaining test coverage data. On the other hand, a second container is created to store the test coverage data in a shared storage space between the first and second containers. This ensures that the test coverage data will not be lost even if the first container is destroyed, reducing the probability of test coverage data loss and improving the accuracy of the obtained test coverage data. This, in turn, improves the accuracy of the generated test coverage file and the accuracy of the software to which the code under test belongs.

[0048] It should be noted that the embodiments of this application do not limit the specific forms of the code testing device 101 and the container platform 102. Figure 1 The number of code testing devices 101 and container platforms 102 is merely illustrative; any number of code testing devices 101 and container platforms 102 can be used as needed. The embodiments of this application involve user-related data such as the code to be tested. When the methods of this application are applied to specific products or technologies, user permission or consent is always obtained, and the extraction, use, and processing of related data comply with local security standards and local laws and regulations.

[0049] See Figure 2 , Figure 2 This is a flowchart illustrating a code testing method in an exemplary embodiment of this application. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0050] like Figure 2 As shown, in an exemplary embodiment, the code testing method may include S201-S204, which are described in detail below:

[0051] S201, create the first and second containers corresponding to the code to be tested, and allocate shared storage space for the first and second containers.

[0052] The code to be tested refers to any code that needs to be tested. Depending on the development lifecycle stage, the code to be tested can be code that needs to be tested in stages such as unit testing, integration testing, system testing, and acceptance testing. Depending on the subject, the code to be tested can be the code of an application, the code of any functional unit within an application, or the code of a microservice. That is, in the embodiments of this application, the entire application can be tested, or a specific functional unit within an application can be tested. For example, in an application developed based on microservice technology, at least two microservices are included. All code in the application can be tested, or the code of any microservice within the application can be tested. The types of applications include, but are not limited to, native applications, web applications, mini-programs, plugin applications, containerized applications, etc. Microservices can be containerized microservices or not. Depending on the programming language, the code to be tested can be code written in Java, code written in Golang, etc. Golang, also known as the Go language, is an open-source programming language characterized by its simplicity, efficiency, and reliability.

[0053] The first container corresponding to the code under test is used to run the code under test, to test the code under test, and to generate test coverage data for the code under test during the testing process. The first container contains all the dependencies for the code under test to run, to ensure that the code under test works correctly.

[0054] The second container corresponding to the code under test is used to share data with the first container to obtain test coverage data of the code under test generated by the first container. Both the first and second containers can be created based on Kubernetes. Under this condition, the type of the second container includes, but is not limited to, a sidecar container. Kubernetes (k8s) is an open-source container orchestration platform used for automating the deployment, scaling, and management of containerized applications. A sidecar container is a design pattern in Kubernetes (k8s) that refers to sharing the same container group (Pod) with the main application container. A Pod is the smallest resource management component and the smallest resource object for running a containerized application; it contains one or at least two containers. The first and second containers can belong to the same Pod or different Pods. Optionally, the first and second containers can also be created based on other container orchestration platforms. The embodiments of this application do not restrict the container orchestration platforms to which the first and second containers belong. It should be emphasized that the "first" and "second" in "first container" and "second container" are only used to distinguish the types of containers, and are not used to limit the number of containers or the order of containers. For example, the number of first containers corresponding to the code under test can be 1 or at least 2, and the number of second containers can also be 1 or at least 2.

[0055] Shared storage space refers to storage space that can be accessed by both the first container and the second container, thereby enabling data sharing between the first container and the second container.

[0056] In an optional implementation, the process of creating a first container and a second container corresponding to the code to be tested, and allocating shared storage space for the first container and the second container, includes:

[0057] Create the first and second containers corresponding to the code to be tested within the same container group Pod;

[0058] Within the storage volumes contained in the Pod, a shared storage volume is allocated for the first and second containers, and this shared storage volume is used as shared storage space.

[0059] Each Pod has its own network namespace, file system, and other resources. Containers within the same Pod can not only share data—a sharing method that ensures data consistency and relative security across containers—but also share network namespaces, inter-process communication (IPC) namespaces, etc., making communication and data exchange between containers more convenient. Therefore, to simplify the data sharing process between the first and second containers and improve data sharing security, the first and second containers are deployed in the same Pod. A storage volume is allocated from the storage volume contained in the deployed Pod for both the first and second containers. The first and second containers are mounted on the allocated storage volume, giving both containers access to the storage volume. This makes the storage volume a shared storage volume for the first and second containers, serving as a shared storage space.

[0060] In another alternative implementation, the first container and the second container may belong to different Pods. Under this condition, the process of allocating shared storage space for the first container and the second container may include: creating a shared storage region for the Pod to which the first container belongs and the Pod to which the second container belongs, and allocating shared storage space for the first container and the second container from the shared storage region.

[0061] Since the first and second containers belong to different Pods, and these Pods typically do not share storage volumes or namespaces, a shared storage region needs to be created first to enable data sharing between the Pods. Then, shared storage space is allocated to both containers from this shared storage region. During the creation of the shared storage region, both Pods can be mounted to the same storage region in the target storage system, allowing both Pods to access this region, thus achieving the shared storage region. The target storage system is a storage system that supports data sharing between Pods, including but not limited to HostPath, Network File System (NFS), Ceph, PersistentVolume (PV), and PersistentVolumeClaim (PVC). HostPath is a persistent storage method in Kubernetes that allows mounting directories or files from a file system on a worker node to a Pod. Ceph is an open-source, unified distributed storage system that provides object storage, block storage, and file system storage interfaces. A PV is a network storage resource in the cluster, while a PVC is a user's request declaration for storage resources. By creating a PV and binding it to a PVC, and then having different Pods mount this PVC, these Pods can access and share the data stored on the PV.

[0062] S202: Obtain the code to be tested through the first container, test the code to be tested, and obtain the test coverage data of the code to be tested generated by the first container and shared to the shared storage space.

[0063] Test coverage is an important metric for measuring test completeness, and its types include, but are not limited to, code coverage, functional coverage, and requirement coverage. Code coverage is calculated as the ratio between the number of code units executed during testing and the total number of code units contained in the code under test. It indicates whether the tests cover all code units in the code under test. A code unit can be a line of code or a block of code. A code block can be a function, conditional statement, or loop, etc. For example, if a line of code is considered a code unit, and the code under test contains 1000 lines of code, and 900 lines of code are executed during testing, then code coverage can be calculated based on the ratio between 900 and 1000. Functional coverage is calculated as the ratio between the number of functions tested and the total number of functions contained in the code under test. Requirement coverage is calculated as the ratio between the number of test requirements tested and the total number of test requirements. It indicates whether the tests cover all test requirements.

[0064] Test coverage data refers to data related to test coverage, including but not limited to execution information of code units.

[0065] The first container can obtain the code to be tested and test it. During the test, the first container can run the code to be tested based on the test cases and collect test coverage data during the execution of the code to be tested, and add the collected data to the shared storage space.

[0066] Optionally, testing can be performed on the code to be tested after receiving a test request for the code to be tested. The test request may contain test cases for the code to be tested, allowing testing to be performed based on these test cases. Alternatively, upon receiving the test request, a first and second container corresponding to the code to be tested can be created directly; or, upon receiving the test request, a check can be performed to determine if a first and second container already exist. If not, then the first and second containers can be created, allowing different testing processes to share the first and second containers corresponding to the code to be tested. Test requests can be initiated by users (e.g., testers).

[0067] The specific method by which the first container obtains the code to be tested can be flexibly configured according to actual needs. In an optional example, a copy instruction, such as `COPY . / app`, can be added to the Dockerfile of the first container. After the first container's build process, the code to be tested will be copied to the first container's working directory based on the copy instruction, allowing the first container to obtain the code to be tested and perform testing on it. The Dockerfile is a text file used to define the Docker image build process.

[0068] Optionally, the first container can add code for collecting test coverage data to the code under test, so that test coverage data is collected during the execution of the code under test. The specific method of adding the collection code can be flexibly configured according to actual needs, for example:

[0069] In an optional implementation, if the test language of the code to be tested is Java, i.e., the code to be tested is a Java program, the first container can add collection code to collect test coverage data through the JaCoCo agent. JaCoCo agent is a tool for collecting code coverage data during the runtime of a Java program. Specifically, the `-javaagent` parameter can be written to the first container to specify the path to the JaCoCo agent's JAR file, for example: `java-javaagent:jacocoagent.jar MyApp`. When the first container starts the JVM to run the Java program, it loads the JaCoCo agent based on the `-javaagent` parameter, thereby adding collection code to the Java program through the JaCoCo agent to collect code coverage data during the Java program's execution. Optionally, after the JaCoCo agent is loaded, the `premain` method is executed to create an `Instrumentation` instance and register a `ClassFileTransformer`. This allows the JaCoCo agent to call the `transform` method in `ClassFileTransformer` whenever the JVM loads a class in the Java program. The `transform` method receives the raw class bytecode, and the JaCoCo agent modifies the bytecode within it, adding counters for each method and branch to record the execution count. When the Java program runs, the JaCoCo agent collects this counter information to obtain data related to code coverage. Here, JVM refers to the Java Virtual Machine, used to run Java programs. The `premain` method is a special entry point method provided by Java; it is part of the Java Agent mechanism and is used to perform preprocessing operations before the Java application starts.

[0070] In another optional implementation, if the test language of the code under test is Golang, the `-cover` parameter can be written to the first container, for example, using the `go build-cover` command. The first container can then add sampling code based on the `-cover` parameter to collect test coverage data. Optionally, during the process of running the code under test, the first container first compiles the code under test into a binary file, inserts sampling code into the binary file based on the `-cover` parameter, and then runs the binary file to test the code under test. During execution, the sampling code records the execution information of each code unit in the code under test, thereby obtaining test coverage data.

[0071] S203 reads test coverage data of the code to be tested from the shared storage space through a second container.

[0072] The second container reads test coverage data for the code under test from the shared storage space.

[0073] Optionally, test coverage data can be read from shared storage space via a second container after the code under test has completed testing. During the testing process, a process corresponding to the code under test is created, and the code under test is run based on this process. The completion of testing for the code under test can be determined when the process corresponding to the code under test exits.

[0074] S204 generates a test coverage file for the code to be tested based on the read test coverage data.

[0075] Test coverage files for the code under test are used to indicate the completeness of the tests performed during the testing process. To facilitate testers' viewing of test coverage, test coverage files can be generated based on the test coverage data. These files can be easy-to-read documents, such as those in HyperText Markup Language (HTML) format, which can be displayed through browser components. Alternatively, the test coverage file can be in a visual file format.

[0076] The specific method for generating the test coverage file for the code under test can be flexibly set according to actual needs. In one optional implementation, the test coverage data of the code under test can be added to a file to obtain the test coverage file for the code under test. Alternatively, the test coverage data of the code under test can be analyzed and processed to generate a test coverage report for the code under test based on the analysis results. The test coverage report for the code under test may include at least one of the following test coverage information for the code under test: test coverage of the code under test in the current testing process, coverage alert information, coverage trend data, and execution status information of each code unit in the code under test. The execution status information of the code unit is used to indicate whether the code unit has been executed and the number of times it has been executed. The coverage alarm information is used to indicate that the test coverage of the code under test is lower than the set threshold in the current test process. The coverage trend data is used to indicate the change in the test coverage of the code under test, so that testers can optimize test cases based on the change in the test coverage of the code under test. The coverage trend data includes the test coverage of the code under test in the current test process and the test coverage of the code under test in the historical test process. The coverage trend data can be presented in the form of charts, that is, the coverage trend data can be a test coverage trend graph.

[0077] In an optional implementation, a test interface for initiating tests and a viewing interface for viewing test coverage files can be provided, allowing testers to initiate test requests against the code under test through the test interface and view the test coverage files through the viewing interface; the test interface can be an Application Programming Interface (API), for example, see [link to example]. Figure 3 As shown, testers can initiate tests via API calls. After the first container completes the test, the test coverage data is shared to the second container via shared storage. A test coverage file is generated using the shared test coverage data, which testers can then view.

[0078] In an optional implementation, a test service can be deployed to control the first and second containers. The first container acquires the code to be tested and performs tests on it, obtaining test coverage data for the code to be tested, which is generated by the first container and shared in a shared storage space. The second container reads the test coverage data from the shared storage space. Optionally, the test service can also be used to generate a test coverage file corresponding to the code to be tested. Optionally, the test service can also be used to provide at least one of the following functions: storing test coverage files, displaying test coverage files, and interacting with users to receive user requests. Correspondingly, for ease of expansion and maintenance, the test service can be designed with a modular architecture.

[0079] exist Figure 2 In the illustrated embodiment, on one hand, a first container is created for testing the code to be tested and generating test coverage data. The test coverage data is stored in a specific storage space through the first container, thereby allowing the test coverage data to be obtained from the specific storage space, reducing the difficulty of obtaining the test coverage data. On the other hand, a second container is created to store the test coverage data in a shared storage space between the first and second containers. This ensures that even if the first container is destroyed, the test coverage data will not be lost, reducing the probability of test coverage data loss and improving the accuracy of the obtained test coverage data. This, in turn, improves the accuracy of the generated test coverage file and the accuracy of the software to which the code to be tested belongs.

[0080] In one exemplary embodiment, see Figure 4 , Figure 4 Is Figure 2 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0081] like Figure 4 As shown, S201 may include S401-S402, which are described in detail below:

[0082] S401, if the application to be tested contains at least two microservice codes, then each microservice code is used as the code to be tested, and a first container and a second container corresponding to each microservice code are created; wherein, the microservices to which the at least two microservice codes belong are different.

[0083] Microservice code refers to the code of a microservice; different microservice codes belong to different microservices. If testing an application is required, and the application is developed based on a microservice architecture, containing at least two microservices, and the application code contains at least two microservice codes, then, considering that each microservice can be deployed, scaled, and maintained independently, each microservice code is treated as a test case. A first container and a second container are created for each microservice. Different microservices have different first containers, and different microservices have different second containers. The first container for each microservice is used to run the microservice code and test it; it contains all the dependencies required for the microservice code to run.

[0084] The number of first containers and second containers corresponding to each microservice code can be flexibly set according to actual needs. In an optional example, one first container and one second container can be configured for each microservice code.

[0085] If the application under test contains only one microservice code, or if the application under test is not developed based on microservices and the functional units in the application cannot be deployed independently, then the application code can be used as a test code.

[0086] S402, allocate shared storage space to the first and second containers corresponding to each microservice code, thus obtaining the shared storage space corresponding to each microservice code.

[0087] For each microservice, a shared storage space is configured, where both the first container and the second container corresponding to the microservice have permission to access the shared storage space.

[0088] Under these conditions, the process of obtaining the code to be tested through the first container, testing the code to be tested, and obtaining the test coverage data of the code to be tested generated by the first container and shared to the shared storage space may include: testing each microservice code through the first container corresponding to each microservice code, obtaining the test coverage data of each microservice code, and sharing the test coverage data of each microservice code to the shared storage space corresponding to each microservice code.

[0089] The process of reading test coverage data of the code to be tested from the shared storage space through the second container includes: reading the test coverage data of each microservice code from the shared storage space corresponding to each microservice code through the second container corresponding to each microservice code.

[0090] For example, if the application to be tested contains microservice code 1 and microservice code 2, containers 11 and 12 are created as the first and second containers of microservice code 1, respectively, and shared storage space 13 is allocated to containers 11 and 12. Correspondingly, containers 21 and 22 are created as the first and second containers of microservice code 2, respectively, and shared storage space 23 is allocated to containers 21 and 22. During the test, container 11 obtains microservice code 1 and tests it, sharing the test coverage data collected during the test to shared storage space 13; container 21 obtains microservice code 2 and tests it, sharing the test coverage data collected during the test to shared storage space 23; container 12 reads the test coverage data of microservice code 1 from shared storage space 13, and container 22 reads the test coverage data of microservice code 2 from shared storage space 23.

[0091] In an optional implementation, the process of generating a test coverage file for the code to be tested based on the read test coverage data may include:

[0092] Using the second container corresponding to each microservice code, a test coverage report is generated for each microservice code based on the test coverage data of each microservice code;

[0093] The test coverage reports corresponding to at least two microservices are merged to obtain the application's test coverage report. Based on the application's test coverage report, the application's test coverage file is generated.

[0094] In other words, the second container corresponding to each microservice code can process the read test coverage data of that microservice code to generate a test coverage report for that microservice code. Based on the test coverage reports of each microservice code in the application, a test coverage report for the entire application is generated. Using this application's test coverage report as the application's test coverage file improves the efficiency of test coverage report generation. The application's test coverage report can include at least one of the following: test coverage of the application in the current testing process, application coverage alerts, application coverage trend data, and execution status information of each code unit in the application.

[0095] Optionally, if a testing service is deployed, after generating the test coverage report for the microservice code, the second container can transmit the test coverage report to the testing service. The testing service then generates the application's test coverage report based on the received test coverage report for the microservice code. In this approach, by having the second container handle part of the application's test coverage data processing, the processing load on the testing service can be reduced, and the efficiency of generating the application's test coverage report can be improved.

[0096] In another optional implementation, the process of generating a test coverage file for the code to be tested based on the read test coverage data may include: a second container transmitting the test coverage data of the microservice code to a test service, and the test service analyzing and processing the test coverage data corresponding to at least two microservice codes to generate a test coverage report for the application.

[0097] It should be noted that, Figure 4 The specific implementation details of S202-S204 shown can be found in [reference]. Figure 2 S202-S204, as shown, will not be described again here.

[0098] exist Figure 4 In the illustrated embodiment, for an application containing at least two microservice codes, a first container and a second container are created for each microservice code. Shared storage space is configured for each microservice code's first and second containers, resulting in shared storage space for each microservice code. This allows for testing and collection of test coverage data for each microservice code through the first and second containers, improving testing efficiency and enhancing the independence of testing between microservices. Furthermore, even if the first and second containers for a certain microservice code crash, it will not affect the testing and collection of test coverage data for other microservice codes, further reducing the probability of test coverage data loss.

[0099] In one exemplary embodiment, see Figure 5 , Figure 5 Is Figure 4 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0100] like Figure 5 As shown, S202 may include S501-S502, which are described in detail below:

[0101] S501 receives test requests from applications through the test service.

[0102] The testing service may include an interface for receiving test requests, which may be in the form of an API. The application's test request is used to request testing of the application, and the test request may be initiated by the tester.

[0103] S502, in response to a test request, controls the first container corresponding to each microservice code, performs tests on each microservice code, obtains test coverage data for each microservice code, and shares the test coverage data of each microservice code to the shared storage space corresponding to each microservice code.

[0104] The test service interacts with the first container corresponding to each microservice code to control the first container corresponding to each microservice code. After receiving a test request, the test service controls the first container corresponding to each microservice code in the application to start the test. The first container corresponding to each microservice code tests the microservice code and collects test coverage data during the test. The collected test coverage data is then shared to the second container corresponding to the first container.

[0105] It should be noted that, Figure 5 The specific implementation details of S203-S204 shown can be found in [reference]. Figure 2 S203-S204 are shown. Figure 5 For specific implementation details of S401-S402 shown, please refer to Figure 4 S401-S402 shown here will not be described in detail here.

[0106] exist Figure 5 In the illustrated embodiment, a testing service is deployed that can receive test requests from the application and, based on the test requests, control the first container corresponding to each microservice code to test each microservice code, obtain test coverage data for each microservice code, and share the test coverage data of each microservice code to the shared storage space corresponding to each microservice code. This allows testers to initiate test requests only for the application, without needing to initiate test requests for each microservice code, reducing the operational complexity for testers during the testing process and improving the user experience. Furthermore, managing the first container through the testing service can improve test accuracy.

[0107] In one exemplary embodiment, see Figure 6 , Figure 6 Is Figure 5 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0108] like Figure 6 As shown, S203 may include S601, which is described in detail below:

[0109] S601 If it is detected that at least two microservice codes have completed testing, the test service controls the second container corresponding to each microservice code to read the test coverage data of each microservice code from the shared storage space corresponding to each microservice code.

[0110] The test service interacts with the second container corresponding to each microservice code to control the second container to read test coverage data. To improve the accuracy of the test coverage data, the second container for each microservice code can only be controlled to read the test coverage data after at least two microservice codes within the application have been tested.

[0111] Optionally, the test service can also be used to display test coverage files. Correspondingly, after generating the test coverage file for the code to be tested based on the read test coverage data, the code testing method also includes: displaying the test coverage file through the test service.

[0112] The testing service may include a user interface unit for displaying the test coverage file. This user interface unit can be a Web Server unit. A Web Server, also known as a web server, primarily provides website access services to web clients such as browsers, enabling the world to browse website content.

[0113] It should be noted that, Figure 6 For specific implementation details of S204 shown, please refer to Figure 2 S204 as shown, Figure 6 For specific implementation details of S401-S402 shown, please refer to Figure 4 S401-S402 shown, Figure 6 For specific implementation details of S501-S502 shown, please refer to Figure 5 The S501-S502 shown here will not be described in detail here.

[0114] exist Figure 6In the illustrated embodiment, the test service controls the second containers corresponding to the at least two microservice codes contained in the application, so that each second container reads test coverage data from the corresponding shared storage space. This reduces the cumbersome operation for testers during the testing process. Furthermore, the control of the corresponding second container to read test coverage data is only performed after the at least two microservice codes contained in the application have been tested, which can improve the accuracy of test coverage data, thereby improving test accuracy and application stability.

[0115] In one exemplary embodiment, see Figure 7 , Figure 7 Is Figure 2 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0116] like Figure 7 As shown, S202 may include S701-S702, which are described in detail below:

[0117] S701, send a test notification to the first container so that the first container can obtain the code to be tested and the test cases corresponding to the code to be tested according to the test notification, and perform tests on the code to be tested according to the test cases.

[0118] Test notifications instruct the first container to test the code to be tested. During the testing process, the code to be tested and test cases are first retrieved, and then the test cases are executed to test the code to be tested. Optionally, the test notification may include test cases.

[0119] Optionally, after receiving a test request for the code to be tested, a test notification can be generated based on the test request, and the code to be tested can be tested.

[0120] When testing an application containing at least two microservice codes is required, a test notification for each microservice code can be sent to the first container corresponding to that microservice code. The test notification contains the test cases for that microservice code. It should be noted that different microservices have different functions and therefore different test cases. The test cases for each microservice code can be determined based on the actions of the testers, and a test notification for each microservice code can be generated based on the test cases for each microservice code.

[0121] Optionally, if a test service is deployed, the test service can provide a user interaction interface to receive operations from testers, determine test cases based on the testers' operations, generate test notifications, and send them to the corresponding first container.

[0122] S702 collects test coverage data of the code under test during the testing process through the first container and stores the collected test coverage data in the shared storage space.

[0123] During the testing process of the code under test, the first container collects test coverage data and stores the collected test coverage data in the shared storage space.

[0124] Optionally, the first container can store the collected test coverage data in the shared storage space after the code to be tested has been tested; or, the second container can store the collected test coverage data in the shared storage space in real time.

[0125] It should be noted that, Figure 7 The specific implementation details of S201, S203-S204 shown can be found in [reference]. Figure 2 S201, S203-S204 shown will not be described again here.

[0126] exist Figure 7 In the illustrated embodiment, a test notification is sent directly to the first container so that the first container can obtain the code to be tested and the corresponding test cases based on the test notification, and execute the test cases to test the code to be tested. By collecting test coverage data of the code to be tested during the testing process through the first container and storing the collected test coverage data in the shared storage space, testing efficiency can be improved.

[0127] In one exemplary embodiment, see Figure 8 , Figure 8 Is Figure 7 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0128] like Figure 8 As shown, S203 may include S801-S802, which are described in detail below:

[0129] S801 If the code to be tested is detected to have completed testing, a stop notification is sent to the second container so that the second container controls the first container to stop running based on the stop notification.

[0130] A stop notification is used to instruct the first container to stop running. The second container, based on the stop notification, controls the first container to stop running. Specifically, the second container can send a stop command to the first container based on the stop notification, causing the first container to execute the stop command and cease operation. Optionally, if both the first and second containers are created using Kubernetes, the second container can control the first container to stop running via the Kubernetes API.

[0131] Specifically, the code under test can be determined to be tested successfully after all test cases corresponding to the code under test have been executed; alternatively, the code under test can be determined to be tested successfully after the process used for the code under test has ended; or alternatively, the code under test can be determined to be tested successfully after receiving a stop test request from the code under test. The stop test request can be triggered by the tester.

[0132] Optionally, if it is necessary to test an application containing at least two microservice codes, the test service can detect whether each microservice code of the application has been tested. If each microservice code has been tested, a stop notification is sent to the second container corresponding to each microservice code, so that the second container controls the corresponding first container to stop running according to the stop notification.

[0133] Optionally, if a test service is deployed, the test service can be used to detect whether the code to be tested has been tested and send a stop notification to the second container based on the detection result.

[0134] S802, if the first container is detected to have stopped running, a read notification is sent to the second container so that the second container can read the test coverage data from the shared storage space according to the read notification.

[0135] The read notification is used to instruct the reading of test coverage data.

[0136] With the test service deployed, the test service can detect whether the first container has stopped running, and then send a read notification to the second container based on the detection result.

[0137] Optionally, if testing of an application containing at least two microservice codes is required, a read notification may be sent to the second container of each microservice code after the first container corresponding to each microservice code has stopped running.

[0138] It should be noted that, Figure 8 For the specific implementation details of S201 and S204 shown, please refer to Figure 2 S201 and S204 are shown. Figure 8 For specific implementation details of S701-S702 shown, please refer to Figure 2The S701-S702 shown will not be described again here.

[0139] exist Figure 8 In the illustrated embodiment, after the code to be tested has been tested, the first container is first stopped, and then the second container is notified to read the test coverage data from the shared storage space, which can improve the accuracy of the test coverage data. Furthermore, during the process of stopping the first container, a stop notification is first sent to the second container, so that the second container controls the first container to stop. Since the stopping of the container is implemented through the container's underlying interface, the first container does not need to expose its underlying interface to services or components outside the second container by controlling the first container to stop. This can improve the security of the first container, save resources, and improve the accuracy of the test.

[0140] In one exemplary embodiment, see Figure 9 , Figure 9 Is Figure 2 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0141] like Figure 9 As shown, S204 may include S901-S903, which are described in detail below:

[0142] S901, shares the code to be tested obtained by the first container to the shared storage space.

[0143] To reduce the difficulty for the second container to obtain the code to be tested and to ensure the consistency of the code to be tested obtained by the first and second containers, the first container can share the code to be tested to the shared storage space after obtaining it.

[0144] In an alternative implementation, to facilitate reading different types of data, different storage spaces can be used to share the code under test and the test coverage data. Under this condition, the process of allocating shared storage space for the first container and the second container includes:

[0145] Allocate a first shared storage space to the first container and the second container; wherein the first shared storage space is used to share test coverage data;

[0146] Allocate a second shared storage space for the first container and the second container; wherein the second shared storage space is used to share the code to be tested, and the first shared storage space and the second shared storage space are different.

[0147] In other words, two shared storage spaces are configured between the first container and the second container. The first container shares test coverage data to the first shared storage space, and the second container reads test coverage data from the first shared storage space. The first container shares the code to be tested to the second storage space, and the second container reads the code to be tested from the second storage space.

[0148] The sizes of the first and second storage spaces can be flexibly set according to actual needs. In an optional implementation, the ratio between the storage capacity occupied by the code under test and the storage capacity occupied by the test coverage data of the code under test during historical testing can be statistically analyzed to obtain a reference ratio. Then, in the process of allocating the first and second shared storage spaces to the first and second containers, the size of the first shared storage space can be determined based on the storage capacity of the code under test, and the size of the second shared storage space can be determined based on the storage capacity of the code under test and the reference ratio.

[0149] Optionally, if testing of an application containing at least two microservice codes is required, a first shared storage space and a second shared storage space can be allocated to the first container and the second container corresponding to each microservice code.

[0150] In another alternative implementation, the first shared storage space and the second shared storage space can be used interchangeably to share test coverage data and code under test through the same shared storage space.

[0151] S902 reads the code to be tested from the shared storage space through the second container, and determines the execution status information of each code unit in the read code to be tested based on the read test coverage data.

[0152] The execution status information of a code unit is used to indicate the execution status of the code unit, including but not limited to whether the code unit has been executed and the number of times it has been executed.

[0153] S903 generates a test coverage file based on each code unit and its execution status information.

[0154] Based on the code units and their execution status information, a test coverage file is generated, enabling testers to understand the code units under test and their corresponding execution status when viewing the test coverage file.

[0155] In an optional implementation, the process of generating a test coverage file based on each code unit and its execution status information may include: annotating each code unit according to its execution status information, and adding the annotated code units to the test coverage file.

[0156] Optionally, the annotation method includes adjusting the display style of the code unit. The display style includes, but is not limited to, character color, character size, background color, highlighting, etc. Different execution status information of the code unit corresponds to different display styles, thereby distinguishing the display of code units with different execution status information. This allows testers to determine the execution status of the code unit based on the display method. For example, the character color of the code unit that was executed during the test can be adjusted to black, and the character color of the code unit that was not executed can be adjusted to red, so that testers can more intuitively determine whether each code unit was executed during the test based on the character color of the code unit.

[0157] Optionally, annotation methods include annotating each code unit based on its execution status information to obtain annotated code units. The annotation information includes the execution status information of the code unit, and annotation methods include, but are not limited to, inserting comments or adding comments within the code.

[0158] It should be noted that, Figure 9 The specific implementation details of S201-S203 shown can be found in [reference]. Figure 2 S201-S203 shown here will not be described again.

[0159] exist Figure 9 In the illustrated embodiment, the first container shares the code to be tested to a shared storage space, and the second container reads the code to be tested from the shared storage space. Then, a test coverage file is generated based on the code to be tested, ensuring consistency between the code being tested and the code used to generate the test coverage file, thus improving the accuracy of the test coverage file. Furthermore, by reading the code to be tested from the shared storage space through the second container and determining the execution status information of each code unit in the read test coverage data, and then generating the test coverage file based on each code unit and its execution status information, testers can obtain the execution status information of each code unit from the test coverage file, thereby optimizing test cases and improving the efficiency of test case optimization.

[0160] In one exemplary embodiment, see Figure 10 , Figure 10 Is Figure 2 The flowchart illustrates a code testing method proposed based on the given example. This method can be applied to... Figure 1 The implementation environment shown can be composed of Figure 1 The code testing device 101 in the implementation environment shown is executed.

[0161] like Figure 10As shown, S204 may include S1001-S1003, which are described in detail below:

[0162] S1001 parses the read test coverage data to obtain the test coverage of the code under test in the current test process.

[0163] Specifically, the test coverage of the code under test in the current test process is calculated based on the test coverage data of the code under test in the current test process.

[0164] S1002, obtain the test coverage of the code to be tested in the historical test process, and generate a test coverage trend chart of the code to be tested based on the test coverage of the code to be tested in the current test process and the historical test process respectively.

[0165] For the code to be tested, multiple rounds of testing may be conducted to continuously optimize test cases and improve test completeness. In order to enable testers to more intuitively analyze and compare the test coverage of the current test process and the historical test process, a test coverage trend chart can be generated. The trend chart includes the test coverage of the code to be tested in the current test process and the historical test process.

[0166] In an optional implementation, the horizontal axis can represent the test process and the vertical axis can represent the test coverage. A coordinate axis can be established, and the test coverage of the code to be tested in the current test process and the test coverage of the historical test processes can be added to the coordinate axis to obtain a test coverage trend chart. The trend chart can be a bar chart, a line chart, etc.

[0167] S1003, Generate a test coverage file based on the test coverage trend chart.

[0168] The test coverage trend chart of the code to be tested contains the test coverage trend chart of the code to be tested.

[0169] In other embodiments, when testing an application containing at least two microservice codes is required, the test coverage of the application in the current testing process can be calculated based on the test coverage data corresponding to each of these at least two microservice codes. Then, based on the application's test coverage in the current and historical testing processes, a test coverage trend chart is generated and added to the application's test coverage file. Optionally, the application's test coverage trend chart may also include the test coverage trend for each microservice code, allowing testers to identify microservice codes requiring test case optimization based on the trend chart and optimize application test cases accordingly.

[0170] Optionally, if testing of the application is required, a test coverage trend chart of the application can be generated. This can be achieved by merging the test coverage trend charts of the various microservice codes included in the application to obtain the test coverage trend chart of the application.

[0171] It should be noted that, Figure 10 The specific implementation details of S201-S203 shown can be found in [reference]. Figure 2 S201-S203 shown here will not be described again.

[0172] exist Figure 10 In the illustrated embodiment, a test coverage trend chart is generated, which includes the test coverage of the code under test in the current test process and in historical test processes. This allows testers to more intuitively understand the test coverage of the code under test in different test processes based on the test coverage trend chart, thereby optimizing the test cases of the code under test, improving the speed of test case optimization, and improving testing efficiency.

[0173] See Figure 11 , Figure 11 This is a flowchart illustrating a code testing method as shown in an exemplary embodiment of this application. Figure 11 As shown, in an exemplary embodiment, the code testing method may include S1101-S1105, which are described in detail below:

[0174] S1101, create a first container and a second container corresponding to each microservice code in the application to be tested, and allocate shared storage space to the first container and the second container corresponding to each microservice.

[0175] For applications containing at least two microservices, where the application code includes code for at least two microservices, deploy a first container and a second container corresponding to each microservice code in a Kubernetes (k8s) cluster. Place the first and second containers in the same Pod. Configure a first shared storage space and a second shared storage space for the first and second containers. The first shared storage space is used to share test coverage data and the code to be tested, i.e., the source code of the microservice. Copy the microservice code of each microservice to the working directory of the corresponding first container. See the example below. Figure 12 As shown, for business 1 in the application, its corresponding first container and second container, as well as shared storage space, are deployed in the same Pod. For business 2 in the application, its corresponding first container and second container, as well as shared storage space, are deployed in the same Pod.

[0176] Microservices can be containerized services.

[0177] S1102 receives test requests for the application through the test service and notifies the first container corresponding to each microservice code to perform the test according to the test request.

[0178] Testers can trigger the test service through APIs or other means provided by the test service. The test service then sends test notifications to the first container of each microservice code. The first container of each microservice code performs tests on the microservice code based on the test cases and adds the collected test coverage data to the second container corresponding to that microservice code.

[0179] S1103, through the test service, controls the first container of each microservice code to stop running.

[0180] Once all test cases are completed, testers can notify the test service of the test completion via API or other means. The test service then sends a stop notification to the second container of each microservice code. There is a Kubernetes API between the second container and the first container for each microservice code. The second container for each microservice code controls the first container to stop running through the Kubernetes API based on Kubernetes operations.

[0181] S1104 uses a test service to control a second container for each microservice code to generate test coverage reports.

[0182] The testing service includes an interaction unit for communicating with the second container, including sending stop notifications and reading notifications. After the testing service detects that the first container of each microservice has stopped running, it sends a read notification to the second container of each microservice code through the interaction unit. The second container of each microservice code reads the test coverage data of that microservice code from the corresponding shared storage space, and converts the test coverage data into HTML format using the `go tool cover` command to obtain the test coverage report of that microservice code.

[0183] S1105, through the test service, integrates the test coverage reports corresponding to at least two microservice codes contained in the application to obtain the application's test coverage report.

[0184] The application's test coverage report contains test coverage information for each microservice, as well as the application's overall test coverage information. The application's test coverage report is in HTML format. The testing service includes an analysis unit for parsing coverage data and generating test coverage reports, including integrating the test coverage reports corresponding to at least two microservices within the application to obtain the application's test coverage report.

[0185] Optionally, the testing service includes a web server unit that allows you to publish application test coverage reports. Developers or testers can view the test coverage files through this web server unit. For example, see [link to web server unit]. Figure 12 As shown, testers can view test coverage reports through the test service. Optionally, the test service can also send the application's test coverage report to testers or upload it to a specific storage area (e.g., a remote storage service) for viewing by the application's team members. The web server unit provides the user interface, which displays the test coverage report and other functions.

[0186] Optionally, the testing service includes a storage unit for storing test coverage reports obtained from the second container and test coverage reports of the generated application, etc.

[0187] exist Figure 11 In the illustrated embodiment, the probability of test coverage data loss can be reduced by using the second container and the test service, simplifying the collection and processing of test coverage data. Furthermore, by coordinating and controlling the collection of test coverage data for each microservice code through the test service, generating detailed coverage reports, and providing a web server unit for the development team to view and analyze the test coverage reports, the efficiency of the development team can be improved, ensuring code quality and the completeness of test cases, and enhancing the reliability and stability of the application. In addition, the test service is deployed in a modular manner, which facilitates the maintenance and expansion of the test service.

[0188] See Figure 13 , Figure 13 This is a block diagram of a code testing apparatus illustrating an exemplary embodiment of this application, as shown below. Figure 13 As shown, the device includes:

[0189] Create module 1301, configure it to create a first container and a second container corresponding to the code to be tested, and allocate shared storage space for the first container and the second container;

[0190] Test module 1302 is configured to obtain the code to be tested through the first container, test the code to be tested, and obtain the test coverage data of the code to be tested generated by the first container and shared to the shared storage space;

[0191] The reading module 1303 is configured to read test coverage data of the code to be tested from the shared storage space through a second container;

[0192] Module 1304 is configured to generate a test coverage file for the code to be tested based on the read test coverage data.

[0193] In an exemplary embodiment, based on the foregoing scheme, the creation module 1301 is specifically configured as follows:

[0194] Create the first and second containers corresponding to the code to be tested within the same container group Pod;

[0195] Within the storage volumes contained in the Pod, a shared storage volume is allocated for the first and second containers, and this shared storage volume is used as shared storage space.

[0196] In an exemplary embodiment, based on the foregoing scheme, the creation module 1301 is specifically configured as follows:

[0197] If the application to be tested contains at least two microservice codes, then each microservice code is used as the code to be tested, and a first container and a second container are created for each microservice code; wherein, the microservices to which the at least two microservice codes belong are different;

[0198] Allocate shared storage space to the first and second containers corresponding to each microservice code, thus obtaining the shared storage space corresponding to each microservice code.

[0199] In an exemplary embodiment, based on the foregoing scheme, the generation module 1304 is specifically configured as follows:

[0200] Using the second container corresponding to each microservice code, a test coverage report is generated for each microservice code based on the test coverage data of each microservice code;

[0201] The test coverage reports corresponding to at least two microservices are merged to obtain the application's test coverage report. Based on the application's test coverage report, the application's test coverage file is generated.

[0202] In an exemplary embodiment, based on the foregoing scheme, the test module 1302 is specifically configured as follows:

[0203] The test service receives test requests from the application.

[0204] In response to a test request, control the first container corresponding to each microservice code, perform tests on each microservice code, obtain test coverage data for each microservice code, and share the test coverage data of each microservice code to the shared storage space corresponding to each microservice code.

[0205] In an exemplary embodiment, based on the foregoing scheme, the reading module 1303 is specifically configured as follows:

[0206] If at least two microservice codes are detected to have completed testing, the test service controls the second container corresponding to each microservice code to read the test coverage data of each microservice code from the shared storage space corresponding to each microservice code.

[0207] In an exemplary embodiment, based on the foregoing scheme, the test module 1302 is specifically configured as follows:

[0208] Send a test notification to the first container so that the first container can obtain the code to be tested and the corresponding test cases according to the test notification, and perform tests on the code to be tested according to the test cases;

[0209] The test coverage data of the code under test is collected through the first container during the testing process, and the collected test coverage data is stored in the shared storage space.

[0210] In an exemplary embodiment, based on the foregoing scheme, the reading module 1303 is specifically configured as follows:

[0211] If the code under test is detected to have completed testing, a stop notification is sent to the second container so that the second container can control the first container to stop running based on the stop notification;

[0212] If the first container is detected to have stopped running, a read notification is sent to the second container so that the second container can read the test coverage data from the shared storage space according to the read notification.

[0213] In an exemplary embodiment, based on the foregoing scheme, the generation module 1304 is specifically configured as follows:

[0214] Share the code to be tested obtained by the first container to the shared storage space;

[0215] The code to be tested is read from the shared storage space through the second container, and the execution status information of each code unit in the code to be tested is determined based on the read test coverage data.

[0216] A test coverage file is generated based on each code unit and its execution status information.

[0217] In an exemplary embodiment, based on the foregoing scheme, the allocation module is specifically configured as follows:

[0218] Allocate a first shared storage space to the first container and the second container; wherein the first shared storage space is used to share test coverage data;

[0219] Allocate a second shared storage space for the first container and the second container; wherein the second shared storage space is used to share the code to be tested, and the first shared storage space and the second shared storage space are different.

[0220] In an exemplary embodiment, based on the foregoing scheme, the generation module 1304 is specifically configured as follows:

[0221] The read test coverage data is parsed to obtain the test coverage of the code under test in the current test process;

[0222] Obtain the test coverage of the code to be tested in the historical test process, and generate a test coverage trend chart of the code to be tested based on the test coverage of the code to be tested in the current test process and the historical test process respectively;

[0223] Generate a test coverage file based on the test coverage trend chart.

[0224] It should be noted that, Figure 13 The provided code testing device and the code testing method provided in the above embodiments belong to the same concept. The specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0225] Embodiments of this application also provide an electronic device, including: at least one processor; and a storage device for storing at least one computer program, which, when executed by at least one processor, causes the electronic device to implement the code testing methods provided in the above embodiments.

[0226] Figure 14 A schematic diagram of a computer system suitable for implementing an electronic device according to embodiments of this application is shown. The electronic device may be... Figure 1 The code testing equipment shown.

[0227] It should be noted that, Figure 14 The computer system 1400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0228] like Figure 14As shown, the computer system 1400 includes a Central Processing Unit (CPU) 1401, which can perform various appropriate actions and processes based on a computer program stored in Read-Only Memory (ROM) 1402 or a computer program loaded from storage portion 1408 into Random Access Memory (RAM) 1403, such as executing the code testing method described in the above embodiment. Various computer programs and data required for system operation are also stored in RAM 1403. The CPU 1401, ROM 1402, and RAM 1403 are interconnected via bus 1404. An input / output (I / O) interface 1405 is also connected to bus 1404.

[0229] In some embodiments, the following components are connected to the I / O interface 1405: an input section 1406 including a keyboard, mouse, etc.; an output section 1407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to the I / O interface 1405 as needed. A removable medium 1411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1410 as needed so that computer programs read from it can be installed into the storage section 1408 as needed.

[0230] In particular, according to embodiments of this application, a computer program implementing the code testing method can be carried on a computer-readable medium, which can be downloaded and installed from a network via the communication section 1409, and / or installed from a removable medium 1411.

[0231] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. For example, a computer-readable storage medium can be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or at least two wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a computer program that can be used by or in conjunction with an instruction execution system, apparatus, or device. Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer program contained in the computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0232] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or at least two executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.

[0233] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0234] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor of an electronic device, causes the electronic device to implement the code testing method described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0235] Another aspect of this application provides a computer program product, which includes a computer program that, when executed by a processor, implements the code testing methods provided in the various embodiments described above. The computer program can be stored in a computer-readable storage medium. The computer program product can be a computer program as a product, such as an APP (Application), webpage, mini-program, etc.; or, the computer program product can also be a storage medium, device, terminal, virtual machine, etc., containing the computer program.

[0236] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A method of code testing, characterized by, The method includes: Create a first container and a second container corresponding to the code to be tested, and allocate shared storage space for the first container and the second container; The code to be tested is obtained through the first container, and the code to be tested is tested to obtain test coverage data of the code to be tested generated by the first container and shared to the shared storage space; The test coverage data of the code to be tested is read from the shared storage space through the second container; Based on the read test coverage data, a test coverage file for the code to be tested is generated.

2. The method of claim 1, wherein, The step of creating a first container and a second container corresponding to the code to be tested, and allocating shared storage space for the first container and the second container, includes: Create the first and second containers corresponding to the code to be tested in the same container group Pod; In the storage volumes contained in the Pod, a shared storage volume is allocated for the first container and the second container, and the shared storage volume is used as the shared storage space.

3. The method of claim 1, wherein, The step of creating a first container and a second container corresponding to the code to be tested, and allocating shared storage space for the first container and the second container, includes: If the application to be tested contains at least two microservice codes, then each microservice code is used as the code to be tested, and a first container and a second container corresponding to each microservice code are created; wherein the microservices to which the at least two microservice codes belong are different; Shared storage space is allocated to the first container and the second container corresponding to each microservice code, thereby obtaining the shared storage space corresponding to each microservice code.

4. The method of claim 3, wherein, The step of generating a test coverage file for the code to be tested based on the read test coverage data includes: Using the second container corresponding to each microservice code, a test coverage report is generated for each microservice code based on the test coverage data of each microservice code; The test coverage reports corresponding to the at least two microservice codes are merged to obtain the test coverage report of the application. Based on the test coverage report of the application, the test coverage file of the application is generated.

5. The method of claim 3, wherein, The step of obtaining the code to be tested through the first container, testing the code to be tested, and obtaining test coverage data of the code to be tested generated by the first container and shared to the shared storage space includes: The testing service receives test requests from the application. In response to the test request, the first container corresponding to each microservice code is controlled to test each microservice code, obtain test coverage data for each microservice code, and share the test coverage data for each microservice code to the shared storage space corresponding to each microservice code.

6. The method of claim 5, wherein, The step of reading the test coverage data of the code to be tested from the shared storage space through the second container includes: If it is detected that the tests of at least two microservice codes have been completed, the test service controls the second container corresponding to each microservice code to read the test coverage data of each microservice code from the shared storage space corresponding to each microservice code.

7. The method of claim 1, wherein, The step of obtaining the code to be tested through the first container, testing the code to be tested, and obtaining test coverage data of the code to be tested generated by the first container and shared to the shared storage space includes: A test notification is sent to the first container so that the first container can obtain the code to be tested and the test cases corresponding to the code to be tested according to the test notification, and test the code to be tested according to the test cases; The test coverage data of the code under test is collected through the first container during the testing process, and the collected test coverage data is stored in the shared storage space.

8. The method of claim 7, wherein, The step of reading the test coverage data of the code to be tested from the shared storage space through the second container includes: If the test code is detected to have completed testing, a stop notification is sent to the second container so that the second container controls the first container to stop running according to the stop notification; If the first container is detected to have stopped running, a read notification is sent to the second container so that the second container reads the test coverage data from the shared storage space according to the read notification.

9. The method of claim 1, wherein, The second container includes a sidecar container; The step of generating a test coverage file for the code to be tested based on the read test coverage data includes: The code to be tested obtained by the first container is shared to the shared storage space; The code to be tested is read from the shared storage space through the second container, and the execution status information of each code unit in the code to be tested is determined based on the read test coverage data. The test coverage file is generated based on each code unit and its execution status information.

10. The method of claim 9, wherein, The allocation of shared storage space for the first container and the second container includes: Allocate a first shared storage space for the first container and the second container; wherein the first shared storage space is used to share the test coverage data; Allocate a second shared storage space for the first container and the second container; wherein the second shared storage space is used to share the code to be tested, and the first shared storage space and the second shared storage space are different.

11. The method of any one of claims 1-10, wherein, The step of generating a test coverage file for the code to be tested based on the read test coverage data includes: The read test coverage data is parsed to obtain the test coverage of the code under test in the current test process; Obtain the test coverage of the code to be tested in the historical test process, and generate a test coverage trend chart of the code to be tested based on the test coverage of the code to be tested in the current test process and the historical test process respectively; The test coverage file is generated based on the test coverage trend chart.

12. A code testing apparatus, characterized by comprising: The device includes: Create a module, configure it to create a first container and a second container corresponding to the code to be tested, and allocate shared storage space for the first container and the second container; The testing module is configured to obtain the code to be tested through the first container, and test the code to be tested to obtain test coverage data of the code to be tested generated by the first container and shared to the shared storage space; The reading module is configured to read test coverage data of the code to be tested from the shared storage space through the second container; The generation module is configured to generate a test coverage file for the code to be tested based on the read test coverage data.

13. An electronic device, comprising: include: At least one processor; A storage device for storing at least one computer program, which, when executed by the at least one processor, causes the electronic device to implement the code testing method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the processor of the electronic device, causes the electronic device to implement the code testing method according to any one of claims 1-11.

15. A computer program product, characterised in that, Includes a computer program that, when executed by a processor, implements the code testing method according to any one of claims 1-11.

Images