Test case data processing method and device, equipment, storage medium and program product

Abstract

The invention discloses a test case data processing method and device, equipment, a storage medium and a program product, and the method comprises the steps: obtaining a full-quantity test case set, and generating an ordered test case list based on the full-quantity test case set; traversing the ordered test case list according to a forward sequence, and determining the traversed test case as a target test case in the traversing process; executing the target test case, and judging whether the target test case is an effective test case or a redundant test case based on an execution result, the method can reduce the number of the test case sets corresponding to the code file, avoids unnecessary test execution, reduces the test operation scale, and improves the test efficiency. Time overhead and computing resource consumption caused by redundant test operation are reduced, and finally the continuous integration and delivery efficiency in the software development process is improved.

Description

Technical Field

[0001] This application belongs to the field of integrated circuit design technology, and in particular relates to a test case data processing method, apparatus, device, storage medium and program product. Background Technology

[0002] In software development, code files are files written in a specific programming language that store the source code of a program and are the basic units for implementing system functions. To ensure the quality and functional correctness of these code files, systematic software testing is required. Among these, test cases are the core element of the testing process. They consist of a set of clearly defined input data, execution steps, and expected results, and are used to verify whether the software behaves as expected under specific conditions, thereby improving test coverage and verification effectiveness.

[0003] To improve test execution efficiency during code merging, related technologies, such as Chinese Patent Application No. 202311267241.8, disclose a code testing method, apparatus, electronic device, and storage medium. This method constructs a mapping relationship between code files and test cases by analyzing changes in code file coverage after running test cases. This allows for the selection of code-associated test cases from all test cases that have a mapping relationship with the target code file. In this scheme, if the coverage of a code file changes relative to the reference baseline coverage after a test case is run, it is considered that a mapping relationship exists between that test case and that code file. Based on this mapping relationship, when a specific code file is modified, only its corresponding test cases need to be run, thus avoiding the need to perform full tests for every code change and reducing the runtime of the code branch merging process.

[0004] However, in actual operation, it was found that existing test case set construction methods have a large number of redundant test cases. The mapping relationship between code files and test cases in existing technologies is usually established based on the static analysis results of code coverage. In this case, the same code file may be covered by multiple test cases, and these test cases often repeatedly go through the same function call paths during actual execution. Moreover, such repeated tests do not contribute to the coverage, thus generating a large number of redundant test cases, which leads to a decrease in overall test execution efficiency.

[0005] Especially for low-level code files, the high versatility and reusability of their functions often lead to significant overlap in function paths, resulting in a particularly prominent issue of redundant test cases in testing scenarios. Specifically, when a low-level code file is modified, many of its highly reusable, generic functions, which may be called by top-level functions, are frequently invoked across multiple test paths. Although these test cases may originate from different high-level modules or functions, their call chains all include access to the same low-level generic function, leading to a high degree of overlap in test case coverage and verification paths. This results in a large number of redundant test cases lacking any new coverage or verification value. When a low-level generic code file is modified, the mapping relationship between code files and test cases alone may trigger a large number of test cases related to that file's coverage. This redundancy not only wastes resources in test scheduling but also significantly reduces the overall execution efficiency of the testing system. Summary of the Invention

[0006] This application provides a test case data processing method, apparatus, device, and computer-readable storage medium, aiming to provide a test case data processing scheme that can identify and eliminate redundant test cases.

[0007] On one hand, embodiments of this application provide a data processing method, the method comprising:

[0008] Obtain the full set of test cases, and generate an ordered list of test cases based on the full set of test cases;

[0009] The ordered test case list is traversed in forward order, and the test cases encountered during the traversal are identified as target test cases.

[0010] Execute the target test case and determine whether the target test case is a valid test case or a redundant test case based on the execution result;

[0011] The next test case in the ordered test case list is determined as the target test case, and the execution of the target test case is returned. Based on the execution result, the target test case is determined to be a valid test case or a redundant test case. This process continues until the traversal of the ordered test case list is completed.

[0012] On the other hand, this application provides a test case data processing apparatus, which may include:

[0013] The acquisition module is used to acquire the full set of test cases and generate an ordered list of test cases based on the full set of test cases.

[0014] The traversal module is used to traverse the ordered list of test cases in a forward order, and to determine the traversed test cases as target test cases during the traversal process.

[0015] The judgment module is used to execute the target test case and determine whether the target test case is a valid test case or a redundant test case based on the execution result.

[0016] The target update module is used to determine the next test case in the ordered test case list as the target test case, return to the steps of executing the target test case, and judging whether the target test case is a valid test case or a redundant test case based on the execution result, until the traversal of the ordered test case list is completed.

[0017] In another aspect, this application provides a test case data processing device, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the steps of the above-described test case data processing method.

[0018] Processor and memory storing computer program instructions;

[0019] The steps by which a processor implements the data processing methods described above when executing computer program instructions.

[0020] In another aspect, this application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the test case data processing method described above.

[0021] In another aspect, this application provides a computer program product, which includes a computer program that, when executed by a processor, implements the test case data processing steps described above.

[0022] This invention reduces the number of test cases for code files by obtaining a full set of test cases, generating an ordered list of test cases based on the full set of test cases, traversing the ordered list in forward order, and identifying the encountered test cases as target test cases during the traversal, executing the target test cases, and determining whether the target test cases are valid or redundant based on the execution results, and then identifying the next test case in the ordered list as the target test case and returning to the previous steps of executing the target test case and determining whether the target test case is valid or redundant based on the execution results, until the traversal of the ordered list of test cases is completed. This reduces the number of test cases for code files, avoids unnecessary test execution, thereby reducing the scale of test runs, reducing the time overhead and computing resource consumption caused by redundant test runs, and ultimately improving the efficiency of continuous integration and delivery in the software development process. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic flowchart of a data processing method provided in one embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the structure of a data processing apparatus provided in another embodiment of this application;

[0026] Figure 3 This is a schematic diagram of the structure of a data processing device provided in another embodiment of this application. Detailed Implementation

[0027] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0028] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0029] In large-scale software projects such as Electronic Design Automation (EDA), testing processes (such as CI / CD pipelines) can be extremely time-consuming, especially during each code merge or commit, requiring the execution of numerous test cases to verify the system's stability and functional correctness. For example, in practical applications, continuous integration and delivery are typically achieved using automated servers like Jenkins. Jenkins is an open-source build and testing platform that automatically executes build, test, and deployment processes after code commits, providing a unified interface for managing and monitoring the testing process. In automated environments like Jenkins, the presence of numerous redundant test cases further lengthens pipeline execution time and reduces software development efficiency. Therefore, reducing redundant test cases while ensuring test coverage and verification effectiveness has become a key issue in improving overall development and delivery efficiency.

[0030] To improve test execution efficiency during code merging, a code testing method is disclosed in Chinese Patent Application No. 202311267241.8. This method first records the code file information covered by each test case during test execution to obtain coverage data. For example, after executing test case A, if the covered code files include file1.cpp and file2.cpp, the system records the corresponding coverage relationship. Then, the current test coverage is compared with a pre-saved baseline coverage (e.g., coverage before testing or after the last full test). If a test case causes a change in the current test coverage of a code file relative to the baseline coverage during execution—for example, by adding new lines of executed code—the system determines that a valid coverage relationship exists between the test case and the code file, and establishes a corresponding entry in the mapping table to create and maintain the mapping relationship between code files and test cases, thus reflecting the specific coverage of each test case on the code file. Subsequently, when a code file is modified, the corresponding test case can be selected for verification based on this mapping relationship, thereby avoiding the execution of irrelevant tests, reducing unnecessary test runs, and saving time and computing resources.

[0031] However, in actual operation, it was found that existing test case set construction methods have a large number of redundant test cases. The mapping relationship between code files and test cases in existing technologies is usually established based on the static analysis results of code coverage. In this case, the same code file may be covered by multiple test cases, and these test cases often repeatedly go through the same function call paths during actual execution. Moreover, such repeated tests do not contribute to the coverage, thus generating a large number of redundant test cases, which leads to a decrease in overall test execution efficiency.

[0032] Especially for low-level code files, due to the high versatility and reusability of their functions, there is often a large number of overlapping function paths, which makes the problem of redundant test cases in testing scenarios particularly prominent.

[0033] Specifically, when the underlying code file is modified, many of the common functions it contains, which are likely to be called by top-level functions, are highly reusable and frequently invoked across multiple test paths. Although these test cases may originate from different high-level modules or functions, their call chains all include access to the same underlying common function. This results in a high degree of overlap between the test case coverage and verification paths, creating a large number of redundant test cases that lack new coverage or verification value. When a particular underlying common code file is modified, the mapping relationship between the code file and test cases alone may trigger a large number of test cases related to that file's coverage. This redundancy not only wastes resources in test scheduling but also significantly reduces the overall execution efficiency of the test system.

[0034] For example, in a test case set, suppose there are test cases TestA() and TestB(). TestA()'s call path during execution is: TopFunc1() → MidFuncX() → BaseFuncY(), while TestB()'s call path is: TopFunc2() → MidFuncZ() → BaseFuncY(). It can be seen that although TestA() and TestB() come from different top-level test modules, their function call paths both enter the same underlying function, BaseFuncY(). Since BaseFuncY() is completely covered in both test cases, repeated execution does not bring new coverage or verification capabilities; it only causes test execution redundancy, ultimately resulting in a test set containing a large number of redundant test cases, reducing execution efficiency.

[0035] In summary, the test case set processing solutions in related technologies have problems such as generating a large number of redundant test cases and low overall test execution efficiency.

[0036] To address at least one of the aforementioned technical problems, embodiments of this application provide a test case data processing method, apparatus, device, and storage medium. The test case data processing method of this application embodiment will be described below with reference to the accompanying drawings.

[0037] See Figure 1 , Figure 1 A flowchart illustrating a test case data processing method provided in one embodiment of this application is shown. Figure 1 As shown, this method is applied to the testing process of electronic design automation software, and the method may include the following steps:

[0038] S100: Obtain the full set of test cases and generate an ordered list of test cases based on the full set of test cases;

[0039] S200: Traverse the ordered test case list in forward order and determine the traversed test cases as target test cases during the traversal process.

[0040] S300 executes the target test case and determines whether the target test case is a valid test case or a redundant test case based on the execution result;

[0041] S400: Determine the next test case in the ordered test case list as the target test case, return to execute the target test case, and determine whether the target test case is a valid test case or a redundant test case based on the execution result, until the traversal of the ordered test case list is completed.

[0042] In this embodiment, a full set of test cases is first obtained, and an ordered test case list is generated based on the full set of test cases. Then, the ordered test case list is traversed in forward order. During the traversal, the currently traversed test case is identified as the target test case and executed. During execution, the execution result of the target test case is used to determine whether it is a valid or redundant test case. After the determination, the next test case in the ordered test case list is identified as the new target test case, and the execution and determination steps are returned until the ordered test case list has been traversed completely.

[0043] This application streamlines the existing full test case set by performing ordered processing on the full test case set, then iterating through the full test cases in an ordered manner, and executing and judging the validity of the target test cases one by one during the traversal. This allows for the discovery of redundant test cases with overlapping coverage paths or the retention of only valid test cases that produce differentiated coverage with the target code file. This reduces the number of test cases that need to be run during code modification or merging, thereby significantly shortening test execution time, reducing computational resource consumption, and improving the overall efficiency of the code merging and verification process.

[0044] In S100, obtain the full set of test cases and generate an ordered list of test cases based on the full set of test cases.

[0045] The full test case set refers to the collection of all test cases prepared to achieve the test objective. All test cases in the full test case set can cover the preset test objective. The steps to obtain the full test case set include: obtaining all test cases from the full test case database; wherein, the full test case database stores all test cases prepared in advance for the test objective, wherein the preset test objective includes, but is not limited to, verifying the functional correctness of the verification object, boundary condition coverage checking, abnormal path handling, and performance and stability verification. The verification object can be the target EDA software system or its sub-modules. Each test case in the full test case set can be run by an executable file to generate the first code coverage data corresponding to each test case for subsequent screening and analysis.

[0046] In some alternative implementations, the full set of test cases can also be a set of code-associated test cases that are mapped to the target code file. That is, the full set of test cases can also be a set of code-associated test cases that are mapped to the target code file selected from all test cases. Accordingly, the step of obtaining the full set of test cases may include: obtaining all test cases associated with the target code file from the code-associated test case database; wherein, the code-associated test case database stores all test cases corresponding to the specified target code file.

[0047] The aforementioned full test case database and code-associated test case database can be implemented using a Structured Query Language (SQL) database within an Electronic Design Automation (EDA) software environment, such as MySQL or PostgreSQL. In one example implementation, each test case is stored as a corresponding test case record in the SQL database. This record includes at least one or more of the following fields: test case number (for unique identification); test case name (for describing the test objective or function); creation time (for recording the generation or registration time of the test case); and the name of the target code file corresponding to the test case (for establishing the mapping relationship between the test case and the target code file). This structured storage of the above fields enables efficient retrieval and filtering of test cases based on SQL queries, thereby achieving the function of obtaining the full set of test cases or the set of code-associated test cases.

[0048] In this embodiment, generating an ordered test case list refers to generating an ordered list containing several test cases in a determined order by sorting the entire set of test cases according to a preset sorting rule. The generated ordered test case list is used to provide a definite and consistent execution order for the subsequent test case processing.

[0049] In the above embodiments, the preset sorting rule can be a single sorting rule based on test case attributes. As an optional implementation, the preset sorting rule is a natural order based on the test case identifier number. In other implementations, the preset sorting rule can be any sorting method based on the test case attributes, including but not limited to number order, name dictionary order, execution time, creation time, or other rules that can uniquely determine the order. This application does not impose any special restrictions on this.

[0050] This embodiment can generate a unique sorting result under the same input conditions through the above-mentioned preset sorting rules, so as to ensure the consistency of the execution process and support repeatable filtering and verification operations.

[0051] As an optional implementation, the specific steps for generating an ordered test case list include: assigning a sequence index to each test case in the full test case set, corresponding to its position; constraining the sequential relationship between test cases in the full test case set; setting a start identifier at the beginning of the full test case set and an end identifier at the end of the full test case set. After obtaining the full test case set, the step of generating an ordered test case list based on the full test case set enables the test cases to be numbered and ordered in sequence. Compared to a conventional unordered test case set, an ordered test case list has a fixed sequential structure, can maintain consistent results under the same input and rule conditions, and can support retrieval and traversal operations based on sequence indexes, thereby facilitating repeated execution and verification of subsequent filtering processes.

[0052] In S200, the ordered test case list is traversed in forward order, and the test cases encountered during the traversal are identified as target test cases.

[0053] Specifically, the ordered test case list is first traversed in forward order, and the test cases encountered during the traversal are identified as target test cases. The forward traversal includes starting from the first test case in the ordered test case list and traversing sequentially until the last test case at the end of the ordered test case list is reached. During the traversal, the test cases encountered are identified as target test cases. The target test cases refer to the test cases that are currently traversed and selected for execution and judgment during the forward traversal of the ordered test case list. This achieves a complete scan of the ordered test case list and a step-by-step inspection of the target test cases.

[0054] It should be noted that when the traversal begins, it starts from the first test case in the ordered test case list and is determined as the first target test case. During the traversal, after the execution and judgment of the previous target test case are completed, the next test case is selected from the ordered test case list and updated as the new target test case.

[0055] In S300, the target test case is executed, and the result is used to determine whether the target test case is a valid test case or a redundant test case.

[0056] In this step, the target test case is first executed, and the execution results generated during the execution process are collected. Then, based on the execution results of the target test case, such as the first code coverage data, the target test case is analyzed and judged to determine whether it is a valid test case or a redundant test case.

[0057] By judging target test cases based on execution results, redundant test cases that do not contribute to coverage can be identified and eliminated, thereby reducing the execution of invalid test cases, reducing computational resource consumption, and improving testing efficiency and the accuracy of results.

[0058] In S400, the next test case in the ordered test case list is determined as the target test case, and the execution and judgment steps are returned, namely: the target test case is executed, and the target test case is judged as a valid test case or a redundant test case based on the execution result; until the traversal of the ordered test case list is completed, the traversal ends when there is no next test case in the ordered test case list.

[0059] Specifically, after determining the validity of the current target test case, the next test case is selected from the ordered test case list as the new target test case, and the above steps of executing the target test case are repeated, and the target test case is determined as a valid test case or a redundant test case based on the execution result. For example, suppose the entire set of test cases is sorted by number to generate an ordered list of test cases from TC1 to TC5. We can traverse the list sequentially, starting with TC1. During this traversal, the first test case in the ordered list, TC1, is identified as the target test case and executed. The execution result of TC1 determines whether the target test case is valid or redundant. For example, after executing TC1, it is determined to be a valid test case. Then, we continue traversing to the next test case, TC2, and identify it as the new target test case, executing it. The execution result of TC2 is then used to determine whether it is a valid or redundant test case. For example, TC2 is determined to be redundant. This process continues with TC3, TC4, and TC5, until the last test case in the ordered list is reached. This achieves a complete scan and individual validity check of the entire ordered test case list.

[0060] Throughout the traversal and execution process, the target test cases are executed and evaluated one by one. Finally, by sequentially traversing the list, the check and evaluation of each test case in the ordered test case list are achieved.

[0061] As some optional implementations, the steps of executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result also include creating an initial list of valid test cases and storing the valid test cases in the initial list of valid test cases.

[0062] Specifically, firstly, before executing the target test case, an initial list of valid test cases is created in advance. For example, this initial list of valid test cases can be a list structure generated by the EDA software in memory or a database to record valid test cases. After determining whether the target test case is a valid or redundant test case based on the execution results, if the target test case is determined to be a valid test case, the identification information corresponding to the determined valid test case is written into the initial list of valid test cases.

[0063] Specifically, the aforementioned identification information may include, but is not limited to: test case number, test case name, execution time, and coverage path data added compared to the existing coverage. By writing the identification information corresponding to the determined valid test cases into the initial valid test case list, the system retains only valid test cases that are truly relevant to the target code file and can produce differentiated coverage.

[0064] It should be noted that the initial list of valid test cases serves as a unified storage container to store valid test cases that have been determined to be completed, in order to support subsequent processing steps. Specifically, the initial list of valid test cases can be implemented in various ways, such as storing it in memory as an array or linked list, or storing it as a database table record.

[0065] As some optional implementations, after completing the traversal, execution, and judgment of the ordered test case list, this embodiment further includes the step of outputting an initial list of valid test cases to the user.

[0066] Specifically, the initial list of valid test cases can be displayed to the user through the interface of the electronic design automation (EDA) software, such as directly through the graphical user interface (GUI). Users can view fields such as the number, name, and execution time of the valid test cases in the interface window. Alternatively, it can be saved as a file to a preset directory, such as a CSV, JSON, or XML file, for subsequent script or automation tool access. Or, it can be stored in a database for user retrieval. After storage in an SQL database, users can retrieve and query the data using SQL queries or through the software's retrieval interface. Through these output methods, the initial list of valid test cases can be directly provided to the user. This list includes all valid test cases determined after execution and evaluation, allowing users to promptly view the selection results and use them as a basis for subsequent test execution and analysis, thereby improving the convenience and continuity of test management.

[0067] As some optional implementations, the steps of executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result further include creating a list of redundant test cases and storing the target test cases determined to be redundant test cases in the list of redundant test cases.

[0068] Specifically, before executing the target test cases, the Electronic Design Automation (EDA) software can pre-initialize and generate a list of redundant test cases. As an example, this list of redundant test cases can be created in memory, storing redundant test cases as arrays or linked lists, or it can be created in a database, storing redundant test cases as table records. The list of redundant test cases serves as a unified storage container, centrally storing redundant test cases that have been evaluated, to support subsequent processing steps and analysis operations.

[0069] Subsequently, after executing the target test cases and determining their validity based on the execution results, if a target test case is determined to be a redundant test case, the identification information corresponding to the redundant test case is written into the redundant test case list. The identification information for the redundant test cases may include, but is not limited to: test case number, test case name, execution time, coverage information, and the name of the associated target code file. By writing the identification information of the determined redundant test cases into the redundant test case list, redundant test cases that do not contribute to coverage can be centrally stored to support subsequent statistical and analytical processing. Furthermore, based on the data in this redundant test case list, statistical analysis can be performed, such as calculating the number, distribution, or type ratio of redundant test cases under a specific module, thereby providing data support for optimizing test case design and simplifying the test suite.

[0070] For example, in a certain EDA software testing scenario, after the system executes test case TC101 and completes coverage analysis, it determines that the test case does not contribute any new coverage to the target code file ModuleX.v. The system then inserts this test case as a redundant test case into the database table, recording the data behavior as: [TC101,"CheckModuleX","2025-09-09 10:30",0%,"ModuleX.v"]. Subsequently, testers can analyze the entire test set based on this list of redundant test cases. If they find that the proportion of redundant test cases in a certain module exceeds 40%, they can further prune the test set, reduce the number of redundant test executions, and thus improve the overall efficiency of the CI / CD pipeline.

[0071] By creating and storing a list of redundant test cases, redundant test cases can be centrally managed, which not only avoids them being repeatedly scheduled in subsequent testing processes, but also provides a basis for streamlining the test set and provides valuable data support for subsequent test optimization and maintenance.

[0072] As some optional implementations, executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result further includes: after executing the target test case, obtaining the first code coverage data of the target test case, and comparing the first code coverage data with the first code coverage data of the previous test case; if the first code coverage data of the target test case is the same as the first code coverage data of the previous test case, then the target test case is determined to be a redundant test case; if the first code coverage data of the target test case is different from the first code coverage data of the previous test case, then the target test case is determined to be a valid test case.

[0073] In its implementation, after executing the target test cases, the system calls a code coverage analysis tool (such as gcov, JaCoCo, or the coverage module built into the EDA testing framework) to generate a coverage result file. This file records the coverage of the target source code, including function calls, basic block triggers, and branch coverage. The first code coverage data for the target test cases can be obtained from this file. This first code coverage data is the coverage data obtained from executing a single test case. The statistical unit for the first code coverage data is the test case level, not the overall coverage of a test case group or the entire set. This first code coverage data is usually expressed as a percentage. For example, the first code coverage data for target test case A is 75%, and the first code coverage data for the preceding test case B is also 75%.

[0074] If the first code coverage data of the target test case is the same as that of the previous test case, the target test case is identified as a redundant test case. Specifically, during the comparison, if the results are consistent, it means that the execution of test case A did not add any new code coverage paths, and its coverage scope has been completely included by the previous test case. In this case, the execution of the target test case did not add any new code coverage paths, and its coverage scope is completely included in the coverage results of the previous test case. Therefore, it is automatically identified as a redundant test case by the system and stored in the redundant test case list.

[0075] Conversely, if the first code coverage data of the target test case differs from that of the previous test case, the target test case is determined to be a valid test case. In this case, the execution of the target test case adds a new code coverage path, expanding the overall coverage range, and is therefore considered a valid test case. For example, if test case C has a coverage rate of 80%, while the previous test case B has a coverage rate of 75%, then test case C has expanded a new coverage path, is considered a valid test case, and is stored in the list of valid test cases.

[0076] As some optional implementation methods, the target test case is executed, and the target test case is determined to be a valid test case or a redundant test case based on the execution result. This includes: creating a coverage record variable and setting the initial value of the coverage record variable to 0. After the target test case is executed, the coverage record variable is updated based on the first code coverage data.

[0077] Before executing the target test case, the system can define a coverage record variable in the test execution module to store the coverage data of a single test case. The initial value of the coverage record variable is set to 0, indicating that no code is covered before the test case is executed. For example, an integer or floating-point variable `coverage=0` can be defined in the runtime memory as the initial state of the coverage record variable.

[0078] After the target test case is executed, the system can call a coverage analysis tool (such as gcov, JaCoCo, or the coverage module included in the EDA testing framework) to obtain the first code coverage data for that test case. This first code coverage data can be expressed as a percentage (e.g., 75%). After obtaining new first code coverage data, this data is written to a coverage record variable, enabling dynamic updates to the variable. For example, if the initial value is coverage=0, and the first code coverage obtained after the test case execution is 75%, the system will update the coverage record variable to coverage=75.

[0079] This embodiment supports the test case determination process by establishing and maintaining coverage record variables. After each target test case is executed, the coverage record variable will reflect the coverage result of the current test case in real time, providing basic data support for subsequent comparison and determination, and ensuring that there is a unified coverage value as the basis for determination.

[0080] As some alternative implementations, when the target test case is the first test case in the test case list, the first code coverage data of the target test case is compared with the initial value of the coverage record variable.

[0081] In the specific implementation, at the beginning of traversing the ordered test case list, the system first determines whether the current target test case is the first test case. If it is determined to be the first test case, there is no need to compare the first code coverage data with the previous test case. Instead, the initial value of the coverage record variable (usually 0) is directly used as the comparison benchmark.

[0082] Subsequently, the system compares the first code coverage data obtained after executing the first test case with the initial value mentioned above: if the first code coverage data is greater than the initial value, it means that the test case has generated new coverage paths for the target code, and therefore it is classified as a valid test case; if the first code coverage data is equal to the initial value, it means that the test case has not triggered any code paths, and it can be identified as a redundant test case.

[0083] In this embodiment, when processing the first target test case, the initial value of the coverage recording variable is used as a benchmark for comparison. Even in the first stage of traversal, the integrity of the judgment logic can be guaranteed, and a unified benchmark reference is established for the coverage comparison of subsequent test cases.

[0084] As some optional implementations, before obtaining the full set of test cases and generating an ordered list of test cases based on the full set of test cases, the method further includes: obtaining the target source code file from the code repository, using a compiler to preprocess, compile and link the target source code file to generate an executable file, which is used to run the test cases and obtain the first code coverage data corresponding to the test cases.

[0085] In this embodiment, before generating the ordered test case list, preparatory steps are included, such as acquiring and compiling source code files to form executable files, for running test cases and collecting coverage data. First, the target source code file is acquired from a code repository; this repository can be a version control system such as Git or SVN, or a source code management platform built internally by the EDA software development company. After acquiring the source code file, the compiler is invoked to perform preprocessing, compilation, and linking steps sequentially, ultimately generating an executable file. Preprocessing includes expanding macro definitions, replacing header files, and deleting comments; compilation converts the source code into intermediate object files; and linking includes linking the object files with relevant library files. This executable file serves as the carrier for subsequent test case execution and can be called and executed in the required test environment. During test case execution, a coverage acquisition module (such as gcov, llvm-cov, JaCoCo, or EDA's built-in coverage tool) can be invoked to collect the execution path, branch triggering, and basic block coverage of the executable file in real time, generating corresponding coverage data files (such as .gcda or .exec). This coverage data will serve as the basis for subsequently determining whether test cases are valid or redundant.

[0086] For example, in a specific EDA testing scenario, the system first pulls the source code file ModuleX.c of the target module ModuleX from the Git code repository. Then, it calls the GCC compiler to preprocess and compile it, adding the `--coverage` option during compilation to enable coverage information collection. After the linking phase, the system generates the executable file ModuleX.exe. When test case TC301 is executed, the system runs ModuleX.exe and calls the gcov tool to collect coverage information, thereby generating the corresponding .gcda file. This coverage file records in detail the execution count of basic blocks and the triggering of branch statements. Based on this, the system calculates the first code coverage data for test case TC301 and stores this coverage data to support subsequent validity determination and processing.

[0087] By retrieving target source code files from a code repository and using a compiler for preprocessing, compilation, and linking to generate executable files, it is possible to ensure that test cases run on the latest source code version, thereby improving the accuracy and timeliness of initial code coverage data. Specifically, this method avoids the risks of errors from manual compilation, promotes the automation of the testing process, improves overall testing efficiency, and provides reliable basic data support for the subsequent generation of an ordered list of test cases.

[0088] In a preferred implementation, after determining the next test case in the ordered test case list as the target test case, returning to execute the target test case, and judging whether the target test case is a valid test case or a redundant test case based on the execution result, the method further includes: traversing the initial valid test case list in reverse order, and determining the traversed test cases as target test cases during the traversal process; executing the target test cases in the initial valid test case list, and judging whether the target test cases are valid test cases or redundant test cases based on the execution result; updating the target test case with the previous test case in the initial valid test case list, and returning to the execution step: executing the target test case in the initial valid test case list, and judging whether the target test case is a valid test case or a redundant test case based on the execution result; and ending the traversal of the initial valid test case list and outputting the updated initial valid test case list to the user when there is no previous test case in the initial valid test case list.

[0089] It should be noted that although traversing the ordered test case list in forward order to form an initial list of valid test cases can identify redundant test cases or remove some redundant test cases from the list of valid test cases, there may still be residual redundant test cases. This is because when the previous test case in the initial list of valid test cases is a subset of the subsequent target test cases, the set of covered code elements of the previous test case in the initial list of valid test cases is completely contained by the set of covered code elements of the subsequent target test cases. In this case, the previous test case is essentially a redundant test case.

[0090] Specifically, the above implementation method determines valid or redundant test cases through forward traversal. The essence of its determination logic relies on comparing the covered code set of the current target test case with that of the previous test case. When the covered code element set of the previous test case is completely contained within the covered code set of the target test case, although the previous test case should be a redundant test case from the perspective of set relationship, the forward traversal only judges whether the target test case brings an increase in code coverage, that is, it focuses on whether the current test case covers code that was not covered before. If it covers, it is retained as a valid test case; if it does not cover, it is discarded as a redundant test case.

[0091] However, the initial list of valid test cases retained through the above forward traversal method will still contain some redundant test cases. This is because when the content covered by the previous test case is a subset of the content covered by the next test case, the previous test case should be considered redundant. However, this redundancy cannot be identified during the forward traversal process, which ultimately results in the retained valid test cases still containing some redundant test cases.

[0092] For example, after forward traversal of an ordered list of test cases, if the initial list of valid test cases is TC1, TC3, and TC5, where TC1 covers A, B, and C, TC3 covers A, B, C, and D, and TC5 covers A, B, C, and E; during forward traversal, TC3 is considered a valid test case because it introduces a new code block D, resulting in a different first code coverage rate than TC1; similarly, TC5 is also considered a valid test case because it introduces code block E, resulting in a different first code coverage rate than TC3. However, since TC1's coverage is completely encompassed by TC3, this means that TC1 fails to provide any coverage that TC3 does not possess; when the coverage of a test case is a subset of that of another test case, that test case is a redundant test case. Therefore, TC1 should actually be considered a redundant test case.

[0093] To address this, this embodiment traverses the initial list of valid test cases in reverse order, checking each case sequentially from the end of the list backwards. During this process, the system uses the target test case as a baseline and compares its coverage data with the preceding test case in the initial list of valid test cases. If the coverage data of the preceding test case is determined to be completely contained within the target test case, the preceding test case is marked as redundant and removed. Thus, by traversing backwards, the initial list of valid test cases is further streamlined, effectively avoiding redundant test cases, improving the compactness and accuracy of the initial list, and ultimately outputting an updated list of initial valid test cases to the user.

[0094] Specifically, after traversing the ordered test case list in forward order, the initial valid test case list is traversed in reverse order, and the traversed test cases are identified as target test cases during the traversal process.

[0095] The reverse order traversal involves starting from the last test case at the end of the initial list of valid test cases and proceeding backwards until the first test case in the list is reached, identifying each traversed test case as the target test case in the process.

[0096] The target test case refers to the test case currently selected for execution and evaluation during the process of traversing the initial list of valid test cases in a preset reverse order. This reverse traversal process ensures a complete scan of the initial list of valid test cases from end to beginning, guaranteeing that all test cases in the list are checked and evaluated one by one, thus avoiding omissions.

[0097] Subsequently, the target test cases in the initial list of valid test cases are executed, and the execution results are used to determine whether the target test cases are valid or redundant. In this step, the target test cases are executed, and relevant execution result information, such as initial code coverage data, is collected. Then, the collected execution result information is analyzed and evaluated to determine whether the target test cases contribute to the overall code coverage. If the analysis results indicate that the target test case can trigger new code paths or increase coverage, it is determined to be a valid test case; conversely, if the execution result of the target test case is consistent with the existing coverage data and does not generate new coverage, it is determined to be a redundant test case.

[0098] After the target test case is executed, the target test case is updated with the previous test case in the initial valid test case list, and the execution steps are returned: execute the target test case in the initial valid test case list, and determine whether the target test case is a valid test case or a redundant test case based on the execution result; until the reverse traversal of the initial valid test case list is completed, the traversal ends when the previous test case does not exist in the initial valid test case list, and the updated initial valid test case list is output to the user.

[0099] Specifically, after determining the validity of the current target test case, the system selects the previous test case from the initial list of valid test cases as the new target test case and repeats the above execution and determination process. By traversing in reverse, all test cases in the initial list of valid test cases are executed again from the end to the beginning, and are determined to be valid or redundant test cases.

[0100] For example, suppose the initial list of valid test cases, after filtering, generates a list containing TC1, TC3, and TC5. During the reverse traversal, the system first identifies the last test case, TC5, as the target test case and executes it, determining its validity based on the execution result. Then, it selects the previous test case, TC3, as the new target test case and executes it. If it determines that TC3 does not contribute to increased coverage, it is marked as a redundant test case. This process continues sequentially with TC1 until the first test case is encountered.

[0101] Throughout the reverse traversal and execution process, the target test cases are updated, executed, and evaluated one by one. This reverse scanning method ensures that all test cases in the initial list of valid test cases are executed and checked. Finally, after traversing all test cases in the initial list of valid test cases, the updated list of initial valid test cases is output to the user for the user to obtain and analyze the final set of valid test cases.

[0102] In this embodiment, after forward traversal, the aforementioned reverse traversal operation can further identify redundant test cases that were initially deemed valid in the list of valid test cases. For example, by comparing the first code coverage of TC1 and TC3 in reverse traversal, the coverage range of TC3 is A, B, C, and D, while the coverage range of TC1 is A, B, and C. Through the comparison in reverse traversal, it is found that the coverage range of TC1 (A, B, C) is completely contained within the coverage range of TC3 (A, B, C, D). That is, TC1 is a subset of the previous target test case TC3. Therefore, TC1 does not provide any coverage contribution that TC3 does not possess. Thus, through the aforementioned reverse traversal, redundant test cases in the list of valid test cases can be further identified and removed, such as test case TC1 in the example.

[0103] In a preferred embodiment, after executing the target test cases in the initial list of valid test cases and determining whether the target test cases are valid or redundant test cases based on the execution results, the method may further include a step of removing the redundant test cases from the initial list of valid test cases.

[0104] Specifically, after a target test case in the initial valid test case list is executed, and the target test case is determined to be a redundant test case based on the execution result, the method further includes a step of removing the redundant test case from the initial valid test case list. This step of removing the redundant test case from the initial valid test case list can be executed after a target test case is determined to be a redundant test case, or it can be executed uniformly after all test cases in the initial valid test case list have been determined. In this embodiment, by removing the redundant test cases from the initial valid test case list, redundant test cases in the initial valid test case list are further removed, thus maintaining the validity of the test cases in the initial valid test case list.

[0105] In this embodiment, after executing the target test cases, the generated test information files include a control flow information file stored in .gcno format and a runtime execution information file stored in .gcda format. The .gcda file is generated during program execution and records dynamic execution information generated by the target source code during test execution, including the execution count of each basic block, the triggering of branch statements, and the number of function calls. Correspondingly, the .gcno file is generated during compilation and records the static control flow information of the target source code, including the structural relationships of functions, basic blocks, and branches. The .gcno file reflects the code hierarchy structure of the target program before execution and is used to map it to the dynamic execution information in the .gcda file, thus achieving a correspondence between static structure and runtime execution, supporting coverage calculation and statistics.

[0106] In this embodiment, after generating the Gcda file, the specific process of parsing the test information file and generating the first code coverage data is as follows: First, the code coverage analysis tool performs joint parsing of the Gcno and Gcda files, matching the dynamic execution counts recorded in the Gcda file with the control flow information in the Gcno file. This determines the coverage of each function, code block, and branch in the target source code and generates coverage statistics, providing data support for the subsequent output of the first code coverage data and the generation of a coverage report. Specifically, when compiling the target source code, a GCC compiler with coverage instrumentation parameters (e.g., -fprofile-arcs, -ftest-coverage) is used to generate the corresponding executable program and Gcno file. Subsequently, the target test cases are executed using the code coverage analysis tool, for example, using the Gcov tool in the GNU toolchain. After the test execution is completed, the corresponding Gcda file is generated. Next, the Gcov tool is used to parse the Gcno and Gcda files, mapping the dynamic execution counts recorded in the Gcda file to the control flow information in the Gcno file. This determines the coverage of each function, basic block, and branch, and generates coverage statistics. Finally, the first code coverage data can be output based on the parsing results.

[0107] Through the above steps, this embodiment can accurately obtain the first code coverage data after executing the target test case, thereby supporting the subsequent redundancy judgment and screening of test cases.

[0108] As an optional implementation, after finishing traversing the initial valid test case list and outputting the updated initial valid test case list to the user, the method further includes: in response to receiving a new test case input by the user, executing all test cases in the initial valid test case list to obtain the baseline coverage of the initial valid test case list; adding the new test case to the initial valid test case list and executing all test cases in the initial valid test case list again to obtain the updated coverage of the initial valid test case list; if the baseline coverage and the updated coverage are different, determining the new test case as a valid test case and retaining the new test case in the initial valid test case list; if the baseline coverage and the updated coverage are the same, determining the new test case as a redundant test case.

[0109] In the specific implementation process, all test cases in the initial valid test case list are first executed to generate a baseline coverage, which serves as a reference value for subsequently determining the validity of newly added test cases. When the user inputs a new test case, the system adds the new test case to the initial valid test case list and executes all test cases in the initial valid test case list again to obtain an updated coverage. By comparing the baseline coverage and the updated coverage, it can be determined whether the newly added test case makes a new contribution to the overall coverage. As an optional approach, the baseline coverage and updated coverage in this embodiment are calculated based on the statement coverage of the function. In other embodiments, the baseline coverage and updated coverage can also be calculated based on branch coverage or path coverage.

[0110] The above method enables the dynamic generation and comparison of baseline coverage and updated coverage when new test cases are received. This allows for the automatic determination of whether new test cases are valid or redundant, ensuring the real-time updating and simplification of the initial list of valid test cases, avoiding the accumulation of redundant test cases, improving test execution efficiency, reducing computational resource consumption, and ensuring that the determination process of baseline coverage and updated coverage is consistent, objective, and standardized.

[0111] For example, in an EDA software testing scenario, after traversing the initial list of valid test cases, the baseline coverage is 82%. When a user adds a test case TC401 and adds it to the initial list of valid test cases, all test cases in the initial list are executed again to obtain an updated coverage. If the updated coverage increases to 85%, the newly added test case is determined to be a valid test case and retained in the initial list of valid test cases. If the updated coverage is still 82%, the newly added test case is determined to be a redundant test case, and the user is notified that the test case has not contributed to the new coverage.

[0112] Figure 2 A schematic diagram of the hardware structure of the test case data processing device provided in an embodiment of this application is shown. Figure 2 In this context, the test case data processing device may include:

[0113] The acquisition module 201 is used to acquire the full set of test cases and generate an ordered list of test cases based on the full set of test cases.

[0114] The traversal module 202 is used to traverse the ordered test case list in forward order and determine the traversed test cases as target test cases during the traversal process.

[0115] The judgment module 203 is used to execute the target test case and determine whether the target test case is a valid test case or a redundant test case based on the execution result.

[0116] The target update module 204 is used to determine the next test case in the ordered test case list as the target test case, return to execute the target test case, and determine whether the target test case is a valid test case or a redundant test case based on the execution result, until the traversal of the ordered test case list is completed.

[0117] In some embodiments, the determination module 203 may include:

[0118] The initial valid test case list module is used to create an initial valid test case list and store valid test cases in the initial valid test case list.

[0119] In some embodiments, the target update module 204 described above may include:

[0120] The output module is used to output the initial list of valid test cases to the user.

[0121] In some embodiments, the determination module 203 may include:

[0122] The redundant test case list module is used to create a list of redundant test cases and store the redundant test cases in the redundant test case list.

[0123] In some embodiments, the determination module 203 may include:

[0124] The first code coverage data comparison module is used to obtain the first code coverage data of the target test case after executing the target test case, and compare the first code coverage data with the first code coverage data of the previous test case; if the first code coverage data of the target test case is the same as the first code coverage data of the previous test case, the target test case is determined as a redundant test case; if the first code coverage data of the target test case is different from the first code coverage data of the previous test case, the target test case is determined as a valid test case.

[0125] In some embodiments, the determination module 203 may include:

[0126] The coverage recording variable module is used to create coverage recording variables and set the initial value of the coverage recording variables to 0; after the target test case is executed, the coverage recording variables are updated based on the first code coverage data.

[0127] In some embodiments, the determination module 203 may include:

[0128] The first test case comparison module is used to compare the first code coverage data of the target test case with the initial value of the coverage record variable when the target test case is the first test case in the test case list.

[0129] In some embodiments, the acquisition module 201 described above may include:

[0130] The preprocessing module is used to obtain the target source code file from the code repository, and use a compiler to preprocess, compile and link the target source code file to generate an executable file. The executable file is used to run test cases and obtain the first code coverage data corresponding to the test cases.

[0131] In some embodiments, the target update module 204 described above may include:

[0132] The reverse traversal module is used to traverse the initial list of valid test cases in reverse order, and identify the traversed test cases as target test cases during the traversal process; execute the target test cases in the initial list of valid test cases, and determine whether the target test cases are valid or redundant test cases based on the execution results; update the target test cases with the previous test cases in the initial list of valid test cases, and return to the execution steps: execute the target test cases in the initial list of valid test cases, and determine whether the target test cases are valid or redundant test cases based on the execution results; when there is no previous test case in the initial list of valid test cases, end the traversal of the initial list of valid test cases, and output the updated initial list of valid test cases to the user.

[0133] In some embodiments, the determination module 203 may include:

[0134] The redundant test case removal module is used to remove redundant test cases from the initial list of valid test cases.

[0135] In some embodiments, the determination module 203 may include:

[0136] The test information file generation module is used to execute the target test cases using a code coverage analysis tool and generate a test information file corresponding to the target test cases, and calculate the first code coverage data based on the test information file; wherein, the test information file includes a Gcda file and a Gcno file.

[0137] In some embodiments, the target update module 204 described above may include:

[0138] A new test case determination module is used to respond to a user input request for a new test case by executing all test cases in the initial valid test case list to obtain the baseline coverage of the initial valid test case list; adding the new test case to the initial valid test case list and executing all test cases in the initial valid test case list again to obtain the updated coverage of the initial valid test case list; if the baseline coverage and the updated coverage are different, the new test case is determined to be a valid test case and is retained in the initial valid test case list; if the baseline coverage and the updated coverage are the same, the new test case is determined to be a redundant test case.

[0139] Figure 3 A schematic diagram of the hardware structure of a test case data processing device provided in an embodiment of this application is shown. The test case data processing device includes a processor 301 and a memory 302 storing computer program instructions.

[0140] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0141] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 302 may include removable or non-removable (or fixed) media. Where appropriate, memory 302 may be internal or external to a test case data processing device. In a particular embodiment, memory 302 is a non-volatile solid-state memory.

[0142] Memory 302 may include read-only memory (ROM), flash memory device, random access memory (RAM), disk storage medium device, optical storage medium device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory 302 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software that may include computer-executable instructions and, when executed (e.g., by one or more processors), is operable to perform the operations described with reference to the methods of the foregoing aspects of this disclosure.

[0143] The processor 301 reads and executes computer program instructions stored in the memory 302 to implement any of the test case data processing methods in the above embodiments.

[0144] In one example, the test case data processing device may further include a communication interface 303 and a bus 310. For example, Figure 3 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0145] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0146] Bus 310 includes hardware, software, or both, that couples components of a test case data processing device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0147] This test case data processing device can achieve a combination based on test case data processing methods. Figure 1 and Figure 2 The described test case data processing methods and apparatus.

[0148] Furthermore, in conjunction with the test case data processing methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the test case data processing methods in the above embodiments.

[0149] In addition, this application also provides a computer program product, including a computer program, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0150] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0151] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0152] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A test case data processing method, characterized in that, include: Obtain the full set of test cases, and generate an ordered list of test cases based on the full set of test cases; The ordered test case list is traversed in forward order, and the test cases encountered during the traversal are identified as target test cases. Execute the target test case and determine whether the target test case is a valid test case or a redundant test case based on the execution result; The next test case in the ordered test case list is identified as the target test case. The process of executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result is repeated until the traversal of the ordered test case list is completed.

2. The test case data processing method according to claim 1, characterized in that, The step of executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result includes: creating an initial list of valid test cases and storing the valid test cases in the initial list of valid test cases.

3. The test case data processing method according to claim 2, characterized in that, The steps of determining the next test case in the ordered test case list as the target test case, returning to execute the target test case, and judging whether the target test case is a valid test case or a redundant test case based on the execution result, after completing the traversal of the ordered test case list, further include: outputting the initial valid test case list to the user.

4. The test case data processing method according to claim 1, characterized in that, The step of executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result includes: creating a list of redundant test cases and storing the redundant test cases in the list of redundant test cases.

5. The test case data processing method according to claim 1, characterized in that, The execution of the target test case, and the determination of whether the target test case is a valid test case or a redundant test case based on the execution result, includes: After executing the target test case, the first code coverage data of the target test case is obtained, and the first code coverage data is compared with the first code coverage data of the previous test case. If the first code coverage data of the target test case is the same as the first code coverage data of the previous test case, then the target test case is identified as a redundant test case. If the first code coverage data of the target test case is different from the first code coverage data of the previous test case, then the target test case is determined to be a valid test case.

6. The test case data processing method according to claim 1, characterized in that, The step of executing the target test case and determining whether the target test case is a valid test case or a redundant test case based on the execution result includes: creating a coverage record variable and setting the initial value of the coverage record variable to 0; after the target test case is executed, updating the coverage record variable based on the first code coverage data.

7. The test case data processing method according to claim 6, characterized in that, When the target test case is the first test case in the test case list, the first code coverage data of the target test case is compared with the initial value of the coverage record variable.

8. The test case data processing method according to claim 1, characterized in that, Before obtaining the full set of test cases and generating an ordered list of test cases based on the full set of test cases, the method further includes: obtaining the target source code file from the code repository, and using a compiler to preprocess, compile, and link the target source code file to generate an executable file. The executable file is used to run the test cases and obtain the first code coverage data corresponding to the test cases.

9. The test case data processing method according to claim 2, characterized in that, The steps of determining the next test case in the ordered test case list as the target test case, returning to execute the target test case, and determining whether the target test case is a valid test case or a redundant test case based on the execution result, after completing the traversal of the ordered test case list, further include: The initial list of valid test cases is traversed in reverse order, and the test cases traversed are identified as target test cases during the traversal process. Execute the target test cases in the initial list of valid test cases, and determine whether the target test cases are valid test cases or redundant test cases based on the execution results; Update the target test case using the previous test case in the initial list of valid test cases, and return to the execution steps: execute the target test case in the initial list of valid test cases, and determine whether the target test case is a valid test case or a redundant test case based on the execution result; When the previous test case is not found in the initial list of valid test cases, the traversal of the initial list of valid test cases ends, and the updated list of initial valid test cases is output to the user.

10. The test case data processing method according to claim 9, characterized in that, The step of executing the target test case in the initial list of valid test cases and determining whether the target test case is a valid test case or a redundant test case based on the execution result further includes: removing the redundant test case from the initial list of valid test cases.

11. The test case data processing method according to claim 1 or 9, characterized in that, The execution of the target test case, and the determination of whether the target test case is a valid test case or a redundant test case based on the execution result, includes: The target test cases are executed using a code coverage analysis tool, and a test information file corresponding to the target test cases is generated. The first code coverage data is calculated based on the test information file. The test information file includes a Gcda file and a Gcno file.

12. The test case data processing method according to claim 9, characterized in that, After completing the traversal of the initial valid test case list and outputting the updated initial valid test case list to the user, the method further includes: in response to receiving a new test case input by the user, executing all test cases in the initial valid test case list to obtain the baseline coverage of the initial valid test case list; The newly added test cases are added to the initial valid test case list, and all test cases in the initial valid test case list are executed again to obtain the updated coverage of the initial valid test case list; If the baseline coverage is different from the updated coverage, the newly added test case is determined to be a valid test case and is retained in the initial valid test case list; if the baseline coverage is the same as the updated coverage, the newly added test case is determined to be a redundant test case.

13. A test case data processing device, characterized in that, include: The acquisition module is used to acquire the full set of test cases and generate an ordered list of test cases based on the full set of test cases. The traversal module is used to traverse the ordered list of test cases in a forward order, and to determine the traversed test cases as target test cases during the traversal process. The judgment module is used to execute the target test case and determine whether the target test case is a valid test case or a redundant test case based on the execution result. The target update module is used to determine the next test case in the ordered test case list as the target test case, return to the steps of executing the target test case, and judging whether the target test case is a valid test case or a redundant test case based on the execution result, until the traversal of the ordered test case list is completed.

14. An electronic device, characterized in that, include: Processor and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the steps of the test case data processing method as described in any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the steps of the test case data processing method as described in any one of claims 1-12.

16. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor, they implement the steps of the test case data processing method as described in any one of claims 1-12.

Images