Code coverage collection method and apparatus, computing device, and storage medium

Abstract

The present specification provides a code coverage collection method and device, a computing device and a storage medium. The method establishes a test task and configures at least one measured service container corresponding to the test task, the test task has a task identifier, and each measured service container has dynamic address information. At least one measured service container is called to execute the test task, and coverage data representing the code coverage of each measured service container is obtained. The coverage data is pulled according to the dynamic address information of each measured service container, the name of the coverage data includes the identifier information of the measured service container and the data acquisition time. The coverage data corresponding to the test task is established according to each coverage data and stored. The embodiment of the present application can avoid the problem of data pulling failure caused by address invalidation through the dynamic address registration mode, improve the data pulling reliability. And the coverage data is stored in the task dimension, which ensures that different test batches can be traced back and compared.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, computing device, and storage medium for acquiring code coverage. Background Technology

[0002] Code coverage is a metric used to measure how well unit tests, integration tests, or other tests have tested the code. It reflects how much code has been adequately tested during actual test execution. Code coverage reveals which code has been covered by tests and which code may not have been executed or has testing blind spots. However, related technologies for testing code coverage suffer from issues such as unreliable coverage file acquisition and untraceable task batches. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this specification provides a method, apparatus, computing device, and storage medium for collecting code coverage.

[0004] According to a first aspect of the embodiments of this specification, a method for collecting code coverage is provided, the method comprising: A test task is created and configured to correspond to at least one service container under test. The test task has a corresponding task identifier and each service container under test has corresponding dynamic address information. The test task is executed by calling at least one of the tested service containers to obtain coverage data characterizing the code coverage of each tested service container; The corresponding coverage data is retrieved based on the dynamic address information of each of the tested service containers. The name of the coverage data includes the identification information of the corresponding tested service container and the data acquisition time. Based on the coverage data, a coverage document corresponding to the test task is created and stored.

[0005] According to a second aspect of the embodiments of this specification, a code coverage acquisition device is provided, the device comprising: The task configuration module is used to create test tasks and configure the test tasks to correspond to at least one service container under test. The test tasks have corresponding task identifiers and each service container under test has corresponding dynamic address information. The task execution module is used to call the at least one service container under test to execute the test task and obtain coverage data that characterizes the code coverage of each service container under test. The data retrieval module is used to retrieve the corresponding coverage data according to the dynamic address information of each of the tested service containers. The name of the coverage data includes the identification information of the corresponding tested service container and the data acquisition time. The data storage module is used to create and store the coverage document corresponding to the test task based on the coverage data.

[0006] According to a third aspect of the embodiments of this specification, a computing device is provided, the computing device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the operations performed by the code coverage acquisition method described in the first aspect above.

[0007] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a program is stored, the program being executed by a processor as performed by the code coverage acquisition method described in the first aspect.

[0008] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, the computer program product including a computer program, which, when executed by a processor, performs the operations performed by the code coverage acquisition method described in the first aspect above.

[0009] The technical solutions provided in the embodiments of this specification may include the following beneficial effects: Dynamic address registration avoids data retrieval failures due to invalid addresses, improving data retrieval reliability. Coverage documents are stored at the task level, ensuring backtracking and comparison across different test batches.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of a code coverage collection method according to an exemplary embodiment of this specification.

[0013] Figure 2 This is a flowchart illustrating a code coverage acquisition method according to an exemplary embodiment of this specification.

[0014] Figure 3This is a block diagram illustrating a code coverage acquisition device according to an exemplary embodiment of this specification.

[0015] Figure 4 This is a schematic diagram of the structure of a computing device according to an exemplary embodiment. Detailed Implementation

[0016] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed herein.

[0017] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “described,” and “the” as used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0018] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0019] In related technologies, code coverage detection suffers from the following defects and problems: Go version incompatibility: Specifically, the existing open-source tool goc-v1.4.5 fails to compile in Go 1.23+ environments because the go.mod file contains the format "go 1.23.0" and the "toolchain" directive, causing the compilation phase to fail. This defect prevents projects from being upgraded to higher versions of Go, or gets stuck in the compilation and build process.

[0020] Unstable instance addresses: Specifically, existing technologies use static configuration to record the collection address of the service under test. However, in containerized deployment scenarios using open-source container orchestration engines (such as Kubernetes), the smallest deployable unit's address frequently changes due to scaling, version upgrades, or abnormal restarts. This defect causes the pre-configured static collection address to become invalid, resulting in the coverage collection client being unable to find the service under test and data collection being interrupted.

[0021] Lack of runtime coverage reset capability: Specifically, existing technology does not integrate with the testing platform to enable an optional reset process before testing. Before executing a new test task, it is impossible to reset the coverage counter without service downtime. This deficiency causes historical coverage data to remain in the counter, mixing it with the data from the current run, thus polluting the statistical results and making incremental data inaccurate.

[0022] Coverage file retrieval failure: Specifically, when developers build images, deploy containers, and define service names, the names often differ. This defect causes the coverage management platform to fail to retrieve coverage files due to name mismatch, directly resulting in the inability to obtain coverage data for that specific time.

[0023] Untraceable task batches: Specifically, coverage files are typically overwritten without associating data with the "task batch." This defect makes it impossible to trace the coverage of a specific test task in history, or to make horizontal comparisons between different test batches (such as versions V1.0 and V2.0), lacking a foundation for analyzing long-term quality evolution.

[0024] The aforementioned defects cover the entire lifecycle of software test coverage collection, namely, defects exist in the compilation and building stage, runtime addressing stage, data reset stage, data retrieval stage and storage traceability stage.

[0025] In view of this, this specification provides a code coverage collection method to provide a closed-loop coverage collection solution when code coverage testing is required. This method enables the entire system to have high compatibility, high stability, high purity, high success rate, and high traceability in a cloud-native dynamic environment.

[0026] Optionally, the code coverage collection method provided in this specification can be applied to the testing process of the learning machine to achieve code coverage testing of the software and applications deployed on the learning machine.

[0027] See Figure 1 , Figure 1 This is a schematic diagram illustrating an application scenario of a code coverage acquisition method according to an exemplary embodiment, as shown in this specification. Figure 1As shown, this application scenario can consist of a terminal device 101 and a computing device 102. The terminal device 101 can be a learning machine, desktop computer, portable computer, laptop computer, tablet computer, smartphone, smartwatch, etc., on which dedicated online learning software can be installed and run, allowing users to conduct online learning through the terminal device 101. The computing device 102 can be a server, multiple servers, a server cluster, a cloud computing platform, etc., which can provide backend support for the online learning software installed on the terminal device 101.

[0028] Taking terminal device 101 as a learning machine as an example, in some embodiments, the user can send a code coverage test command to computing device 102 through terminal device 101. This code coverage test command instructs computing device 102 to perform a code coverage test. Simultaneously, the code coverage test command may also include information data required for test task creation and configuration of the service under test, so that computing device 102 can create and execute a test task based on the received code coverage test command, using the code coverage acquisition method provided in this specification to obtain and store the coverage document.

[0029] The above is merely an illustrative description of the application scenarios of this manual and does not constitute a limitation on the application scenarios of this manual. In many other possible implementations, this manual can be applied to various other processes involving the recognition of mathematical formulas and text conversion.

[0030] After introducing the application scenarios of the code coverage collection method provided in this manual, the following section will provide a detailed explanation of the code coverage collection method provided in this manual, in conjunction with the embodiments in this manual.

[0031] See Figure 2 , Figure 2 This is a flowchart illustrating a code coverage acquisition method according to an exemplary embodiment, as shown in this specification. Figure 2 As shown, the method includes the following steps: For ease of description, the code coverage acquisition method of this application embodiment is described using a computing device as the execution subject. It should be understood that the execution subject of this application embodiment can also be a processor or chip in a computing device, and this application embodiment does not impose any limitations.

[0032] Step S10: Create a test task and configure the test task to correspond to at least one container of the service under test.

[0033] In one possible implementation, when a computing device determines that a test task requires code coverage testing, it can create the current test task and at least one service container under test corresponding to the test task. Specifically, the computing device can determine the need for code coverage testing upon receiving a test task instruction from a terminal device, or upon the triggering of preset testing conditions.

[0034] Optionally, the test tasks established in this embodiment have corresponding task identifiers, and each service container under test has corresponding dynamic address information. When a test task requiring code coverage detection is needed, the computing device can establish a test task and determine the corresponding task identifier based on pre-stored task-related information or user-uploaded task-related information. Then, it configures at least one service container under test corresponding to the test task according to a preset code repository for the service under test. Furthermore, each service container under test is published, and the corresponding dynamic address information is registered for each published service container.

[0035] For example, in this embodiment, a test plan can be created based on task-related information using the ApiRun testing platform. After the test plan is created, the corresponding test task is automatically generated on the coverage management platform. Then, the test task configures the container for the service under test. Since the existing open-source Go tool goc-v1.4.5 for code coverage testing fails during the compilation stage of high-version Go (1.23+) tests due to the inability to parse the "go 1.23.0" format and "toolchain" instructions in the preset code repository go.mod for the service under test, in order to improve the robustness and reliability of the test task execution process, this embodiment can use the secondary development version goc-v1.4.5-tal-patch1 to build the container for the service under test. The main improvement of this secondary development version is that the preset code repository for the service under test is a code repository obtained by modifying at least one line of code in go.mod. Furthermore, during the configuration of the container for the service under test based on the code repository, incompatible instructions and formats related to the toolchain are ignored. Furthermore, in this embodiment of the application, a callback interface is configured in the callback address of each service container under test to collect information such as the image name and code submission of the service container under test.

[0036] It should be noted that after the test task and at least one service under test container corresponding to the test task are configured, this embodiment of the application can build and publish the service under test container. After each service under test container is successfully published, the computing device dynamically registers its address with the coverage registry center to obtain the dynamic address information of the service under test container. The registration process of this dynamic address information may include automatic address registration, registration of service name (name), and dynamic address (address), etc. The registration of dynamic address information can avoid the defect of current technology where the configured static collection address is easily invalidated due to the scaling up and down of Pods (the smallest deployable unit that encapsulates one or more containers) and container restarts.

[0037] Step S20: Invoke the at least one service container under test to execute the test task and obtain coverage data characterizing the code coverage of each service container under test.

[0038] In one possible implementation, the computing device can execute pre-configured test tasks according to test instructions or test task arrangements. Each service container under test has a corresponding execution order, and the computing device can invoke at least one service container under test to execute test tasks sequentially, obtaining coverage data characterizing the code coverage of each service container under test.

[0039] In some embodiments, to avoid historical data contaminating the current statistics, this application embodiment may also determine whether to clear the historical coverage data of the tested service container corresponding to the test task before executing the test task by means of human-computer interaction with the user. That is, the computing device may first send the historical data page to the terminal device for display, or display the historical data page through a set display device. The historical data page may include the historical coverage data storage information of at least one tested service container corresponding to the current test task. The historical coverage data storage information may include whether the tested service container has historical coverage data, and the name and value of the existing historical coverage data.

[0040] If the user does not upload data clearing information based on the historical data page, each container under test can determine its coverage data based on both historical and current coverage data during test task execution. If the user uploads data clearing information based on the historical data page, the historical coverage data of at least one container under test is cleared according to the data clearing information, and then the test task is executed on at least one container under test. Specifically: If the container under test does not have historical coverage data, the coverage data is determined based on the code coverage obtained in this test. If the container under test has historical coverage data, the coverage data is determined based on the sum of the code coverage obtained in this test and the historical coverage data.

[0041] It should be noted that even when determining the coverage data based on the sum of the code coverage data obtained from this test and the historical coverage data, the computing device can store the code coverage data obtained from this test and the historical coverage data separately at different data addresses, allowing for individual data retrieval. Furthermore, if the data clearing information includes identification information for at least one container under test, the computing device will clear the historical coverage data for the container under test corresponding to that identification information. If the data clearing information does not include identification information for the container under test, the computing device will clear the historical coverage data for all containers under test corresponding to the test task.

[0042] Based on this technical feature, embodiments of this application can select to clear historical coverage data before executing the test. This process can be achieved by directly calling the clear coverage interface. Without interrupting the testing service container, the computing device can call `clearValuesGoc()` to reset the counter and thus reset the coverage data of the testing service container. This avoids interference from historical data and accurately collects the execution data of the current test task.

[0043] Step S30: Retrieve the corresponding coverage data based on the dynamic address information of each of the tested service containers.

[0044] In one possible implementation, after the computing device completes the test task, it can retrieve the corresponding coverage data based on the dynamic address information of each tested service container during the test. The name of this coverage data can include the identification information of the corresponding tested service container and the data acquisition time. Furthermore, after retrieving the coverage data for the corresponding tested service container, the computing device can also upload the retrieved coverage data to OSS (Object Storage Service) for storage, using a name that includes the identification information and the data acquisition time.

[0045] In some embodiments, the computing device may retrieve coverage data corresponding to a service container under test (DUT) by determining, for each DUT, whether the name of the coverage data stored in the dynamic address information matches the identification information of the DUT. If the name of the coverage data matches the identification information of the DUT, the coverage data is retrieved. The computing device can determine whether the coverage data matches the DUT by using the identification information included in the name of the coverage data. In other words, a match between the name of the coverage data and the DUT is defined as the identification information in the name of the coverage data being identical to the identification information of the DUT.

[0046] Furthermore, if the name of the coverage data does not match the identifier information of the service container under test, at least one candidate identifier for the service container under test is determined. If the name of the coverage data matches at least one candidate identifier, the coverage data is retrieved. The candidate identifier is an identifier with the same meaning and similar content as the identifier information of the service container under test. For example, if the identifier information of the service container under test is "-test", the candidate identifier could be "_test". Each service container under test can have three or fewer candidate identifiers.

[0047] Matching this candidate identifier can prevent inconsistencies in naming images / container names / service names, thus avoiding the problem of coverage file retrieval failure due to inconsistent names.

[0048] Step S40: Create and store the coverage document corresponding to the test task based on the coverage data.

[0049] In one possible implementation, after the computing device retrieves the coverage data for each service container under test corresponding to the test task, it can create and store a coverage document for each test task based on the coverage data. This data storage method can store data according to the task dimension and supports data comparison between different tasks. Optionally, in the embodiments of this application, the file naming format of the coverage document can be accurate to the second dimension during data storage, such as Service under test_year-month-day-hour-minute-second.cov, and the coverage file can be persistently stored in OSS for historical data tracing.

[0050] Based on the aforementioned technical features, this solution provides a systematic solution to address the end-to-end pain points of code coverage collection in containerized (Kubernetes) deployment scenarios. During the build phase, the `goc` tool is developed and `go.mod` is preprocessed to resolve incompatibility issues with high-version Go compilation. During the runtime phase, the automatic registration mechanism after container startup replaces static configuration, completely avoiding the risk of address invalidation caused by dynamic Pod migration. During the execution phase, the ability to reset data without restarting before testing is introduced, ensuring the purity and accuracy of statistical data for each task. During the data retrieval phase, a multi-candidate name fault-tolerant matching mechanism is adopted, effectively overcoming file retrieval failures caused by non-standard naming. During the storage phase, data is organized by task dimension and persisted to OSS after naming files with timestamps accurate to the second, achieving long-term traceability of coverage data and horizontal comparison between different versions. In summary, this solution comprehensively improves the compatibility, stability, accuracy, and maintainability of coverage collection, significantly reduces testing and maintenance costs, and provides a reliable technical foundation for software quality measurement in cloud-native environments.

[0051] Corresponding to the embodiments of the methods described above, this specification also provides embodiments of the apparatus and the computing devices on which it is applied.

[0052] See Figure 3 , Figure 3 This is a block diagram illustrating a code coverage acquisition device according to an exemplary embodiment of this specification, such as... Figure 3 As shown, the device includes: The task configuration module 30 is used to create a test task and configure the test task to correspond to at least one service container under test. The test task has a corresponding task identifier and each service container under test has corresponding dynamic address information. The task execution module 31 is used to call the at least one service container under test to execute the test task and obtain coverage data that characterizes the code coverage of each service container under test. The data retrieval module 32 is used to retrieve the corresponding coverage data according to the dynamic address information of each of the tested service containers. The name of the coverage data includes the identification information of the corresponding tested service container and the data acquisition time. The data storage module 33 is used to create and store the coverage document corresponding to the test task based on the coverage data.

[0053] In one possible implementation, the task configuration module 30 is further configured to: Create a test task and determine the task identifier corresponding to the test task; Configure at least one container of the service under test corresponding to the test task according to the preset code repository of the service under test; Publish each of the service containers under test, and register the corresponding dynamic address information for each published service container under test.

[0054] In one possible implementation, the preset code repository for the service under test is a code repository obtained by modifying at least one line of code in go.mod. During the process of configuring the container of the service under test based on the code repository of the service under test, incompatible instructions and incompatible formats related to the toolchain are ignored.

[0055] In one possible implementation, the task execution module 31 is further configured to: Display historical data page; In response to a user uploading data clearing information based on the historical data page, at least one historical coverage data of the tested service container is cleared according to the data clearing information. Invoke the at least one container of the service under test to execute the test task; If no historical coverage data exists for the service container under test, the coverage data is determined based on the code coverage obtained in this test. If historical coverage data exists for the service container under test, the coverage data is determined based on the code coverage obtained in this test and the sum of the historical coverage data.

[0056] In one possible implementation, the task execution module 31 is further configured to: If the data clearing information includes at least one identification information corresponding to the tested service container, the historical coverage data of the tested service container corresponding to the identification information is cleared. If the identification information corresponding to the service container under test is not included in the data clearing information, the historical coverage data of all service containers under test corresponding to the test task will be cleared.

[0057] In one possible implementation, the data fetching module 32 is further configured to: For each of the tested service containers, determine whether the name of the coverage data stored in the dynamic address information matches the identification information of the tested service container; If the name of the coverage data matches the identification information of the service container under test, the coverage data is retrieved.

[0058] In one possible implementation, the data fetching module 32 is further configured to: If the name of the coverage data does not match the identification information of the service container under test, at least one candidate identifier of the service container under test shall be determined. If the name of the coverage data matches at least one of the candidate identifiers, the coverage data is retrieved.

[0059] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0060] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0061] This specification also provides a computing device, see [link to documentation] Figure 4 , Figure 4 This is a schematic diagram illustrating the structure of a computing device according to an exemplary embodiment. Figure 4 As shown, the computing device includes a processor 410, a memory 420, and a network interface 430. The memory 420 stores computer instructions that can run on the processor 410. The processor 410 is used to implement the code coverage acquisition method provided in any embodiment of this specification when executing the computer instructions. The network interface 430 is used to implement input / output functions. In many other possible implementations, the computing device may also include other hardware, which is not limited in this specification.

[0062] This specification also provides a computer-readable storage medium, which can take many forms, such as RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (e.g., hard disk drives), solid-state drives, any type of storage disk (e.g., optical discs, DVDs), or similar storage media, or combinations thereof. Specifically, the computer-readable medium can also be paper or other suitable media capable of printing programs. A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the code coverage acquisition method provided in any embodiment of this specification.

[0063] This specification also provides a computer program product, including a computer program that, when executed by a processor, implements the code coverage acquisition method provided in any embodiment of this specification.

[0064] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, apparatus, computing device, computer-readable storage medium, or computer program product. Therefore, one or more embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-readable program code.

[0065] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments corresponding to computing devices are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0066] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of this specification. In some cases, the actions or steps described in this specification may be performed in a different order than those shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0067] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, the program instructions can be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by a code coverage acquisition device. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0068] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by dedicated logic circuitry—such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the device can also be implemented as dedicated logic circuitry.

[0069] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0070] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0071] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0072] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0073] Therefore, specific embodiments of the subject matter have been described. Other embodiments are within the scope of this specification. In some cases, the actions described herein may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the accompanying drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0074] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. That is, this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

[0075] The above description is merely an optional embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification shall be included within the scope of protection of this specification.

Claims

1. A method for collecting code coverage, characterized in that, The method includes: A test task is created and configured to correspond to at least one service container under test. The test task has a corresponding task identifier and each service container under test has corresponding dynamic address information. The test task is executed by calling at least one of the tested service containers to obtain coverage data characterizing the code coverage of each tested service container; The corresponding coverage data is retrieved based on the dynamic address information of each of the tested service containers. The name of the coverage data includes the identification information of the corresponding tested service container and the data acquisition time. Based on the coverage data, a coverage document corresponding to the test task is created and stored.

2. The method according to claim 1, characterized in that, The process of establishing a test task and configuring the test task to correspond to at least one container of the service under test includes: Create a test task and determine the task identifier corresponding to the test task; Configure at least one container of the service under test corresponding to the test task according to the preset code repository of the service under test; Publish each of the service containers under test, and register the corresponding dynamic address information for each published service container under test.

3. The method according to claim 2, characterized in that, The preset code repository for the service under test is a code repository obtained by modifying at least one line of code in go.mod. During the process of configuring the container of the service under test based on the code repository of the service under test, incompatible instructions and incompatible formats related to the toolchain are ignored.

4. The method according to claim 1, characterized in that, The step of invoking the at least one service container under test to execute the test task, and obtaining coverage data characterizing the code coverage of each service container under test, includes: Display historical data page; In response to a user uploading data clearing information based on the historical data page, at least one historical coverage data of the tested service container is cleared according to the data clearing information. Invoke the at least one container of the service under test to execute the test task; If no historical coverage data exists for the service container under test, the coverage data is determined based on the code coverage obtained in this test. If historical coverage data exists for the service container under test, the coverage data is determined based on the code coverage obtained in this test and the sum of the historical coverage data.

5. The method according to claim 4, characterized in that, The step of clearing historical coverage data of at least one of the tested service containers according to the data clearing information includes: If the data clearing information includes at least one identification information corresponding to the tested service container, the historical coverage data of the tested service container corresponding to the identification information is cleared. If the identification information corresponding to the service container under test is not included in the data clearing information, the historical coverage data of all service containers under test corresponding to the test task will be cleared.

6. The method according to claim 1, characterized in that, The step of retrieving the corresponding coverage data based on the dynamic address information of each of the tested service containers includes: For each of the tested service containers, determine whether the name of the coverage data stored in the dynamic address information matches the identification information of the tested service container; If the name of the coverage data matches the identification information of the service container under test, the coverage data is retrieved.

7. The method according to claim 6, characterized in that, The step of retrieving the corresponding coverage data based on the dynamic address information of each of the tested service containers also includes: If the name of the coverage data does not match the identification information of the service container under test, at least one candidate identifier of the service container under test shall be determined. If the name of the coverage data matches at least one of the candidate identifiers, the coverage data is retrieved.

8. A code coverage acquisition device, characterized in that, The device includes: The task configuration module is used to create test tasks and configure the test tasks to correspond to at least one service container under test. The test tasks have corresponding task identifiers and each service container under test has corresponding dynamic address information. The task execution module is used to call the at least one service container under test to execute the test task and obtain coverage data that characterizes the code coverage of each service container under test. The data retrieval module is used to retrieve the corresponding coverage data according to the dynamic address information of each of the tested service containers. The name of the coverage data includes the identification information of the corresponding tested service container and the data acquisition time. The data storage module is used to create and store the coverage document corresponding to the test task based on the coverage data.

9. A computing device, characterized in that, The computing device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the operations performed by the code coverage acquisition method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that is executed by a processor as described in any one of claims 1 to 7, using the code coverage acquisition method.

Images