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

Abstract

The application discloses a test case data processing method, device, equipment, storage medium and program product. The method comprises the following steps: acquiring a full-amount test case set, generating an ordered test case list based on the full-amount test case set; traversing the ordered test case list in a forward order, and determining a test case traversed in the traversal process as a target test case; executing the target test case, and judging the target test case as a valid test case or a redundant test case based on an execution result. The method can reduce the number of test case sets corresponding to code files, avoid unnecessary test execution, reduce the test running scale, reduce the time cost and the calculation resource consumption caused by redundant test running, and finally improve the continuous integration and delivery efficiency in the software development process.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of integrated circuit design, and particularly relates to a test case data processing method and device, equipment, a storage medium and a program product. BACKGROUND

[0002] In the software development process, code files are files written in a specific programming language and save program source codes, and are basic units for realizing system functions. In order to ensure the quality and functional correctness of these code files, systematic software testing is needed. Among them, the test case is the core element of the testing process, which is composed of a set of explicit input data, execution steps and expected results, and is used to verify whether the behavior of the software under specific conditions meets the expectations, so as to improve the test coverage and verification effect.

[0003] In order to improve the test execution efficiency in the code merging process, the related technology such as the Chinese patent with the application number 202311267241.8 discloses a code testing method, device, electronic equipment and storage medium. The method constructs the mapping relationship between the code files and the test cases through the code file coverage change after running the test cases, so as to realize the code associated test cases filtered from all test cases which have mapping relationship with the target code file. In this scheme, as long as the coverage of a code file changes relative to the reference benchmark coverage after the test case is run, it is considered that the test case has a mapping relationship with the code file. Based on the mapping relationship, when a specific code file is changed, only the corresponding test case needs to be run, so as to avoid executing full test due to each code change and reduce the running time of the code branch merging process.

[0004] However, it is found in actual operation that the existing test case set construction method has the problem of too many redundant test cases. The mapping relationship between the code files and the test cases in the prior art is usually established based on the static analysis result of the code coverage. Among them, the same code file may be covered by multiple test cases, and these test cases often repeatedly pass through the same function call path in actual execution, and such repeated test has no new contribution to the coverage, thus a large number of redundant test cases are generated, resulting in the decline of the overall test execution efficiency.

[0005] Especially for the bottom layer code file, due to the high generality and high reusability of the functions therein, there are often a large number of function path overlaps, so the redundant test case problem in the test scene is particularly prominent. Specifically, when the bottom layer code file is modified, a large number of general functions contained therein have high reusability and are frequently called in multiple test paths. Although these test cases may come from different high-level modules or functions, their call chains all contain access to the same bottom layer general function, resulting in a high overlap of the coverage and verification paths of the test cases, forming a large number of redundant test cases that lack new coverage or verification value. When a bottom layer general code file is changed, a large number of test cases related to the coverage of the file may be triggered according to the mapping relationship between the code file and the test case, and such redundancy not only causes waste of resources in test scheduling, but also significantly reduces the execution efficiency of the overall test system. SUMMARY

[0006] Embodiments of the present application provide a test case data processing method, device and equipment and a computer readable storage medium, aiming to provide a test case data processing scheme capable of identifying and eliminating redundant test cases.

[0007] In one aspect, the embodiments of the present application provide a data processing method, which comprises:

[0008] Obtaining a full-amount test case set, and generating an ordered test case list based on the full-amount test case set;

[0009] Traversing the ordered test case list in a forward order, and determining the test case traversed in the traversal process as a target test case;

[0010] 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;

[0011] Determining the next test case in the ordered test case list as the target test case, and returning to the step 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;

[0012] In another aspect, the present application provides a test case data processing device, which can comprise:

[0013] An obtaining module, configured to obtain a full-amount test case set, and generate an ordered test case list based on the full-amount test case set;

[0014] The traversal module is configured to traverse the ordered test case list in a forward direction and determine a test case as a target test case during the traversal;

[0015] The judgment module is configured 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 an execution result;

[0016] The target updating module is configured to determine a next test case in the ordered test case list as the target test case and return 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 an execution result until the traversal of the ordered test case list is completed.

[0017] In another aspect, the present application provides a test case data processing device, which comprises a processor and a memory storing computer program instructions; the processor implements the steps of the test case data processing method when executing the computer program instructions.

[0018] a processor and a memory storing computer program instructions;

[0019] the processor implements the steps of the data processing method of the above aspect when executing the computer program instructions.

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

[0021] In another aspect, the present application provides a computer program product, which comprises a computer program; the computer program implements the steps of the test case data processing of the above aspect when executed by a processor.

[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 is to be noted that the relative terms such as first and second and the like are used herein to distinguish one entity or operation from another, but do not necessarily require or imply such actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, the elements defined by the statement "comprise" do not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the elements.

[0029] In large software projects such as Electronic Design Automation (EDA), the test flow (e.g., CI / CD Pipeline) can be very time-consuming, especially when a large number of test cases need to be run to verify the stability and correctness of the system every time the code is merged or committed. For example, in practical applications, continuous integration and delivery are usually implemented with the help of automation servers such as Jenkins, where Jenkins is an open-source build and test platform that can automatically execute build, test, and deployment processes after code submission and provide a unified interface to manage and monitor the testing process. In the automation environment of Jenkins, the existence of a large number of redundant test cases will further lengthen the execution time of the pipeline and reduce the software development efficiency. Therefore, how to reduce redundant test cases while ensuring test coverage and verification effect has become a key problem to improve the overall development and delivery efficiency.

[0030] To improve the test execution efficiency in the code merging process, the related technology such as the Chinese patent with application number 202311267241.8 discloses a code test method. First, the code file information covered by each test case is recorded through test execution, so as to obtain coverage data. For example, after executing test case A, if the code files covered by it include file1.cpp and file2.cpp, the system records the corresponding coverage relationship. Then, the current test coverage is compared with the pre-saved benchmark coverage (for example, the coverage before the test or after the last full test). If a test case causes the current test coverage of a certain code file to change relative to the benchmark coverage during execution, for example, a new executed code line is added, the system determines that there is an effective coverage relationship 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 the code file and the test case, so as to reflect the specific coverage of each test case on the code file. When a certain code file is changed later, the corresponding test case can be selected based on the mapping relationship for verification, thereby avoiding irrelevant tests, reducing unnecessary test runs, and saving time and computing resources.

[0031] However, in actual operation, it is found that the existing test case set construction method has the problem of too many redundant test cases. The mapping relationship between the code file and the test case in the prior art is usually established based on the static analysis result of the code coverage. Among them, the same code file may be covered by multiple test cases, and these test cases often repeatedly pass through the same function call path in actual execution, and such repeated tests have no new contribution to the coverage, thus generating a large number of redundant test cases, resulting in a decrease in overall test execution efficiency.

[0032] Especially for underlying code files, since the functions therein have high universality and high reusability, there are often a large number of function path overlaps, so the problem of redundant test cases in the test scenario is particularly prominent.

[0033] Specifically, when the underlying code file is modified, a large number of general functions contained therein have high reusability and are frequently called in multiple test paths. Although these test cases may come from different high-level modules or functions, their call chains all contain access to the same underlying general function, resulting in a high overlap of the coverage range and verification path of the test cases, forming a large number of redundant test cases that lack new coverage or verification value. When a certain underlying general code file is changed, only according to the mapping relationship between the code file and the test case, a large number of test cases related to the coverage of the file may be triggered, and such redundancy not only causes waste of resources in test scheduling, but also significantly reduces the execution efficiency of the overall test system.

[0034] For example, in a test case set, assume that there exist test cases TestA() and TestB() at the same time. Among them, the function call path of TestA() in the execution process is: TopFunc1()→MidFuncX()→BaseFuncY(), and the function call path of TestB() in the execution process is: TopFunc2()→MidFuncZ()→BaseFuncY(). It can be seen that although TestA() and TestB() come from different top-level test modules, the function call paths of TestA() and TestB() will both enter the same bottom-level function BaseFuncY(). Since BaseFuncY() is covered completely in the same way in the two test cases, repeated running will not bring new coverage or verification ability, but only cause test execution redundancy, ultimately leading to a test set containing a large number of redundant test cases and reducing the execution efficiency.

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

[0036] To solve at least one of the above technical problems, the embodiments of the present application provide a test case data processing method, device, equipment and storage medium. The following refers to the drawings to introduce the test case data processing method of the embodiments of the present application.

[0037] Referring to Figure 1 , Figure 1 A flowchart of a test case data processing method provided by an embodiment of the present application is shown. As Figure 1 shown, the method is applied to the test process of electronic design automation software. The method can include the following steps:

[0038] S100, obtaining a full test case set, and generating an ordered test case list based on the full test case set;

[0039] S200, traversing the ordered test case list in a forward order, and determining a test case traversed in the traversal process as a target test case;

[0040] S300, 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;

[0041] S400, determining the next test case in the ordered test case list as the target test case, returning to the step 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.

[0042] In the embodiments of the present application, firstly, a full test case set is acquired, and an ordered test case list is generated based on the full test case set; subsequently, the ordered test case list is traversed in a forward order, a test case currently traversed is determined as a target test case in the traversal process, and the target test case is executed. In the execution process, whether the target test case is an effective test case or a redundant test case is judged based on an execution result of the target test case; after the judgment is completed, a next test case in the ordered test case list is determined as a new target test case, and the steps of execution and judgment are returned until the ordered test case list is traversed completely.

[0043] By sequentially traversing the full test case set after the ordered processing of the full test case set, and executing and judging the validity of the target test case one by one in the traversal, the present application can find redundant test cases with repeated coverage paths or only keep effective test cases that can produce differential coverage with the target code file, realize the simplification of the existing full test case set, reduce the number of test cases that need to be run in the code modification or merging process, thereby significantly shorten the test execution time, reduce the consumption of computing resources, and improve the overall efficiency of the code merging and verification process.

[0044] In S100, a full test case set is acquired, and an ordered test case list is generated based on the full test case set.

[0045] The full test case set refers to a set of all test cases prepared for achieving a test target, and all test cases in the full test case set can cover a preset test target. The step of acquiring the full test case set includes: acquiring all test cases from a full test case database; the full test case database stores all test cases prepared in advance for the test target. The preset test target includes but is not limited to functional correctness verification of a verification object, boundary condition coverage check, abnormal path processing, and performance and stability verification. The verification object can be a target EDA software system or a sub-module thereof. Each test case in the full test case set can be run by an executable file to generate first code coverage data corresponding to each test case, which is used for subsequent screening and analysis.

[0046] In some alternative embodiments, the full-quantity test case set can also be a set of code-associated test cases that have a mapping relationship with the target code file, i.e., the full-quantity test case set can also be a set of code-associated test cases that have a mapping relationship with the target code file and are selected from all test cases. Accordingly, the step of obtaining the full-quantity test case set can include: obtaining all test cases associated with the target code file from a code-associated test case database. The code-associated test case database stores all test cases corresponding to the specified target code file.

[0047] The full-quantity test case database and the code-associated test case database described above can be implemented using a structured query language (SQL) database in an electronic design automation (EDA) software environment, such as a MySQL, PostgreSQL, or other database management system. In an example embodiment, each test case is stored as a test case record in the SQL database, which includes one or more of the following fields: a test case number for uniquely identifying the test case; a test case name for describing the test target or function; a creation time for recording the generation or registration time of the test case; and a target code file name corresponding to the test case for establishing a mapping relationship between the test case and the target code file. Through the structured storage of the above fields, efficient retrieval and screening of test cases based on SQL query statements can be supported, thereby realizing the functions of obtaining a full-quantity test case set or a code-associated test case set.

[0048] In this embodiment, generating an ordered test case list means generating an ordered list containing a plurality of test cases in a sequence determined by sorting the full-quantity test case set according to a preset sorting rule. The generated ordered test case list is used to provide a determined and consistent execution order for the subsequent test case processing process.

[0049] In the above embodiment, the preset sorting rule can be a single sorting rule based on test case attributes. As an alternative embodiment, the preset sorting rule is a natural order sorting based on test case identification numbers. In other embodiments, the preset sorting rule can be any sorting manner based on 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, which are not particularly limited in this application.

[0050] The above preset sorting rule can generate a uniquely determined sorting result under the same input conditions in this embodiment, to ensure the consistency of the execution process, thereby supporting repeatable screening and verification operations.

[0051] As an optional implementation, the specific steps of generating the ordered test case list include: assigning a serial number index corresponding to the arrangement position of each test case in the full test case set; restricting the front and rear position relationship between the test cases in the full test case set; setting a start mark at the head of the full test case set and setting an end mark at the tail of the full test case set. After obtaining the full test case set, the steps of generating the ordered test case list based on the full test case set can number and sequence constrain the test cases in sequence. Compared with the conventional unordered test case set, the ordered test case list has a fixed sequence structure, can keep the results consistent under the same input and rule conditions, and can support serial number index-based retrieval and traversal operations, thereby facilitating repeated execution and verification of the subsequent screening process.

[0052] In S200, the ordered test case list is traversed in a forward order, and the test case traversed in the traversal process is determined as a target test case.

[0053] Specifically, first, the ordered test case list is traversed in a forward order, and the test case traversed in the traversal process is determined as a target test case. The forward order traversal includes starting from the first test case of the ordered test case list, traversing backward one by one until the last test case at the tail of the ordered test case list is traversed, and determining the test case traversed in the traversal process as a target test case. The above target test case refers to the test case currently traversed and selected for execution and judgment in the process of traversing the ordered test case list in a forward order, thereby realizing complete scanning of the ordered test case list and one-by-one checking of the target test case.

[0054] It should be noted that when starting to traverse, the first test case of the ordered test case list is started and determined as the first target test case. In the traversal process, after completing the execution and judgment of the previous target test case, the next test case is selected from the ordered test case list and updated as a new target test case.

[0055] In S300, the target test case is executed, and based on the execution result, the target test case is determined as a valid test case or a redundant test case.

[0056] In this step, first, the target test case is executed, and the execution result generated in the execution process is collected. Then, based on the execution result 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 determining the target test case based on the execution result, redundant test cases without new contribution to coverage can be identified and removed, thereby reducing the execution of invalid test cases, reducing the consumption of computing resources, and improving the efficiency of testing and the accuracy of the 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 determination steps are returned, i.e., 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; until the traversal of the ordered test case list is completed, when there is no next test case in the ordered test case list, the traversal is ended.

[0059] Specifically, after the validity of the current target test case is determined, the next test case in the ordered test case list is selected as a new target test case, and the above steps of executing the target test case and determining the target test case to be a valid test case or a redundant test case based on the execution result are repeated. For example, assuming that the full test case set is sorted in a numbering order to generate an ordered test case list containing TC1 to TC5, the traversal can be performed in a forward order from TC1 to TC5, the first test case TC1 in the ordered test case list is determined as the target test case and executed, and then the target test case is determined to be a valid test case or a redundant test case based on the execution result of TC1. For example, TC1 is determined to be a valid test case after being executed, and then the next test case TC2 is traversed, TC2 is determined as a new target test case and executed, and then TC2 is determined to be a valid test case or a redundant test case based on the execution result of TC2. For example, TC2 is determined to be a redundant test case, and then TC3, TC4, and TC5 are processed in turn, until the last test case in the ordered test case list is traversed, thereby achieving complete scanning and validity checking of each test case in the ordered test case list.

[0060] During the entire traversal and execution process, the target test case is executed and determined one by one, and finally the checking and determination of each test case in the ordered test case list are achieved by sequentially traversing the list.

[0061] As some optional embodiments, in the step of executing the target test case and determining the target test case to be a valid test case or a redundant test case based on the execution result, an initial valid test case list is created, and the valid test case is stored in the initial valid test case list.

[0062] Specifically, first, an initial valid test case list is created in advance before the target test case is executed. As an example, the initial valid test case list can be a list structure for recording valid test cases generated by the EDA software in memory or a database. After determining that the target test case is a valid test case or a redundant test case based on the execution result, 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 valid test case list.

[0063] Specifically, the identification information can include, but is not limited to, test case number, test case name, execution time, and newly added coverage path data compared with existing coverage. Through the operation of writing the identification information corresponding to the determined valid test case into the initial valid test case list, the initial valid test case list is used to retain only the valid test cases that are truly related to the target code file and can produce differentiated coverage.

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

[0065] As some optional embodiments, after the traversal, execution, and determination of the ordered test case list are completed, the embodiment further includes a step of outputting the initial valid test case list to the user.

[0066] Specifically, the initial valid test case list can be displayed to the user through the interface of the electronic design automation software, such as being directly displayed through the graphical user interface (GUI) of the electronic design automation (EDA) software, so that the user can view the number, name, execution time, and other fields of the valid test cases in the interface window. Alternatively, the initial valid test case list can be saved in a file in a preset directory, such as being saved as a CSV file, a JSON file, or an XML file in a user-predefined directory for subsequent script or automation tool calling. Alternatively, the initial valid test case list can be stored in a database for user retrieval and query, such as being stored in a SQL database for user retrieval and query through SQL query statements or through a retrieval interface provided by the software. Through the above output methods, the initial valid test case list obtained through screening can be directly provided to the user. The initial valid test case list includes all the valid test cases determined after execution and determination, which facilitates the user to view the screening results in a timely manner and serves as a basis for subsequent test execution and analysis processing, thereby improving the convenience and continuity of test management.

[0067] As some optional implementations, in the step of executing the target test case and judging the target test case as a valid test case or a redundant test case based on the execution result, the step further includes the step of creating a redundant test case list and storing the target test case determined as a redundant test case in the redundant test case list.

[0068] Specifically, before executing the target test case, the electronic design automation (EDA) software can initialize a redundant test case list in advance. As an example, the redundant test case list can be established in the memory in the form of an array or a linked list to store redundant test cases, or can be established in the database in the form of a table record to store redundant test cases. The redundant test case list serves as a unified storage container to centrally save redundant test cases that have completed determination, thereby supporting subsequent processing steps and analysis operations.

[0069] Subsequently, after executing the target test case and completing the validity determination based on the execution result, if the target test case is determined as a redundant test case, the identification information corresponding to the determined redundant test case is written into the redundant test case list. The identification information corresponding to the redundant test case can include but is not limited to a test case number, a test case name, an execution time, coverage information, and an associated target code file name. Through the above operation of writing the identification information corresponding to the determined redundant test case into the redundant test case list, the redundant test case list can centrally save redundant test cases that have no new contribution to coverage, thereby supporting subsequent statistical and analysis processing. At the same time, based on the data in the redundant test case list, statistics and analysis can be performed, such as the number, distribution, or type ratio of redundant test cases in a certain module, thereby providing data support for optimization of test case design and refinement of the test set.

[0070] For example, in a certain EDA software test scenario, after the system executes the test case TC101 and completes coverage analysis, it is determined that the test case has no new coverage contribution to the target code file ModuleX.v. Then, the system inserts the test case as a redundant test case into the database table and records the data behavior: [TC101, "CheckModuleX", "2025-09-09 10:30", 0%, "ModuleX.v"]. Subsequently, the test personnel can analyze the entire test set based on the redundant test case list and find that the proportion of redundant test cases in a certain module exceeds 40%. Accordingly, the test set can be further trimmed to reduce the number of redundant test execution times, thereby improving the overall efficiency of the CI / CD pipeline.

[0071] Through the creation and storage of the redundant test case list, the redundant test cases can be centrally managed, which not only avoids the repeated scheduling of the redundant test cases in the subsequent test process, but also provides a basis for the simplification of the test set and valuable data support for the subsequent test optimization and maintenance.

[0072] As some optional implementations, the step of executing the target test case and judging the target test case as the effective test case or the redundant test case based on the execution result further includes: after executing the target test case, obtaining first code coverage data of the target test case, and comparing the first code coverage data with 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, determining the target test case as the 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, determining the target test case as the effective test case.

[0073] In a specific implementation, the system calls a code coverage analysis tool (for example, gcov, JaCoCo, or a coverage module built in an EDA test framework) after executing the target test case to generate a coverage result file. The coverage result file generated after executing the target test case records the coverage of the target source code, including function call, basic block triggering, or branch coverage. The first code coverage data of the target test case can be obtained through the coverage result file. The first code coverage data is the coverage data obtained by executing a single test case. The statistical unit of the first code coverage data is the test case level, rather than the overall coverage of the test case group or the full set. The first code coverage data is usually expressed in percentage. For example, the first code coverage data of the target test case A is 75%, and the first code coverage data of the previous test case B is also 75%.

[0074] 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 the redundant test case. Specifically, if the comparison result is consistent, it indicates that the execution of the test case A does not increase a new code coverage path, and the coverage range is completely contained in the previous test case. In this case, the execution of the target test case does not increase a new code coverage path, and the coverage range is completely contained in the coverage result of the previous test case. Therefore, the target test case is automatically determined as the 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 is different from the first code coverage data of the previous test case, the target test case is determined as an effective test case. In this case, the target test case increases a new code coverage path after execution, and can expand the overall coverage range, and thus is identified as an effective test case. For example, the coverage of the test case C is 80%, and the coverage of the previous test case B is 75%, which indicates that the test case C expands a new coverage path and is identified as an effective test case, and is stored in the effective test case list.

[0076] As some optional implementation, the execution of the target test case and the judgment of the target test case as an effective test case or a redundant test case based on the execution result include: creating a coverage record variable, and setting the initial value of the coverage record variable as 0, and updating the coverage record variable based on the first code coverage data after the execution of the target test case is completed.

[0077] Before the execution of the target test case, the system can define a coverage record variable in the test execution module, which is used to store the coverage data of a single test case. The initial value of the above coverage record variable is set as 0, which indicates that no code is covered when the test case has not been executed. For example, an integer or floating-point variable coverage = 0 can be defined in the running memory as the initial state of the coverage record variable.

[0078] After the execution of the target test case is completed, the system can call a coverage analysis tool (such as gcov, JaCoCo or the coverage module of the EDA test framework) to obtain the first code coverage data of the test case. The first code coverage data can be in the form of a percentage (such as 75%). After the new first code coverage data is obtained, the data is written into the coverage record variable, and the dynamic update of the coverage record variable is realized. For example, when the initial value coverage = 0, the first code coverage obtained after the execution of the test case is 75%, and the system updates the coverage record variable to coverage = 75.

[0079] The embodiment supports the process of test case determination by establishing and maintaining the coverage record variable. After the execution of each target test case, the coverage record variable instantaneously reflects the coverage result of the current test case, provides basic data support for subsequent comparison and determination, and ensures that there is a unified coverage value as a basis for determination.

[0080] As some optional implementation, 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 a 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, it is not necessary to compare the first code coverage data with the previous test case, but the initial value (usually 0) of the coverage record variable is directly used as the comparison reference.

[0082] Subsequently, the system compares the first code coverage data obtained after execution of the first test case with the initial value: if the first code coverage data is greater than the initial value, it indicates that the test case has generated a new coverage path for the target code, and therefore it is classified as an effective test case; if the first code coverage data is equal to the initial value, it indicates that the test case has not triggered any code path and 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 record variable is used as the reference for comparison, which ensures the integrity of the determination logic and establishes a unified reference for the coverage comparison of subsequent test cases, even at the beginning of traversal.

[0084] As some optional implementations, before obtaining the full set of test cases, generating the ordered test case list based on the full set of test cases, it 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, which is used to run the test case and obtain the first code coverage data corresponding to the test case.

[0085] In this embodiment, before generating the ordered test case list, it further includes the preparation steps of obtaining and compiling the source code file to form an executable file, which is used to run the test case and collect coverage data. First, the target source code file is obtained from the code repository; the code repository can be a version control system such as Git or SVN, or a source code management platform built internally by an EDA software development company. After obtaining the source code file, a compiler is called to perform the steps of preprocessing, compiling and linking in sequence, and finally an executable file is generated. The preprocessing includes expanding macro definitions, replacing header files and deleting comments, the compiling converts the source code into an intermediate target file, and the linking includes linking the target file with related library files; the executable file serves as a carrier for running the subsequent test cases and can be called and executed in the required running environment. During the execution of the test case, a coverage collection module (such as gcov, llvm-cov, JaCoCo or an EDA built-in coverage tool) can be called to collect the execution path, branch triggering condition and basic block coverage of the executable file in real time, and generate the corresponding coverage data file (such as.gcda,.exec). These coverage data will serve as the basis for determining effective test cases or redundant test cases.

[0086] For example, in a specific EDA test scenario, the system first pulls the source code file ModuleX.c of the target module ModuleX from the Git code repository, then calls the GCC compiler to preprocess and compile it, and adds the --coverage option during the compilation process to enable the collection of coverage information. After the linking stage is completed, the system generates the executable file ModuleX.exe. When executing the test case TC301, the system runs ModuleX.exe and calls the gcov tool to collect coverage information, thereby generating the corresponding.cda file. This coverage file records the execution times of basic blocks and the triggering conditions of branch statements in detail, and the system calculates the first code coverage data of the test case TC301 and stores it to support subsequent effectiveness determination and processing

[0087] By obtaining the target source code file from the code repository and using the compiler to preprocess, compile, and link to generate an executable file, it can ensure that the test case runs on the latest source code version, thereby improving the accuracy and timeliness of the first code coverage data. Specifically, this method avoids the risk of manual compilation errors, promotes automation of the testing process, improves overall testing efficiency, and provides reliable basic data support for subsequent generation of ordered test case lists.

[0088] As a preferred embodiment, after the next test case in the ordered test case list is determined as the target test case, and the step of executing the target test case and judging whether the target test case is an effective test case or a redundant test case based on the execution result is returned until the traversal of the ordered test case list is completed, it further includes: traversing the initial effective test case list in reverse order, and determining the traversed test case as the target test case during the traversal; executing the target test case in the initial effective test case list, and judging whether the target test case is an effective test case or a redundant test case based on the execution result; updating the target test case using the previous test case in the initial effective test case list, and returning to the execution step: executing the target test case in the initial effective test case list, and judging whether the target test case is an effective test case or a redundant test case based on the execution result; when there is no previous test case in the initial effective test case list, ending the traversal of the initial effective test case list, and outputting the updated initial effective test case list to the user.

[0089] It should be noted that although the redundant test cases can be identified or removed from the valid test case list by traversing the ordered test case list in the forward direction and forming the initial valid test case list, there can still be residual redundant test cases, because when the previous test case in the initial valid test case list is a subset of the subsequent target test case, the covered code element set of the previous test case is completely contained in the covered code element set of the subsequent target test case, and the previous test case is essentially a redundant test case.

[0090] Specifically, the above embodiment determines the valid test case or the redundant test case by forward traversal, and the determination logic essentially depends on the comparison of the covered code set of the current target test case and the previous test case; when the covered code element set of the previous test case is completely contained in the covered code element set of the target test case, although the previous test case should be a redundant test case from the set relationship, the forward traversal only determines whether the target test case brings an increase in code coverage, that is, whether the current test case covers the code that has not been covered before, if yes, the current test case is retained as a valid test case, if not, the current test case is discarded as a redundant test case.

[0091] However, the initial valid test case list retained by the above forward traversal still contains some redundant test cases, because when the covered content of the previous test case is a subset of the subsequent test case, the previous test case should be regarded as redundant, but such redundancy cannot be identified in the forward traversal process, and finally the retained valid test case list can still contain some redundant test cases.

[0092] For example, after the ordered test case list is traversed in the forward direction, the initial valid test case list is TC1, TC3, TC5, wherein TC1 covers A, B, C, TC3 covers A, B, C, D, and TC5 covers A, B, C, E; in the forward traversal, because TC3 introduces a new code block D, the first code coverage is different from that of TC1, and therefore TC3 is determined as a valid test case; similarly, TC5 introduces a code block E, and the first code coverage is different from that of TC3, and therefore TC5 is determined as a valid test case. However, because the coverage range of TC1 is completely contained in that of TC3, it means that TC1 fails to provide any coverage that TC3 does not have; when the covered content of a test case is a subset of another test case, the test case is a redundant test case, and therefore, in fact, TC1 should be determined as a redundant test case.

[0093] To this end, the embodiment traverses the initial valid test case list in reverse order, and checks the test cases from the tail of the initial valid test case list to the head. In this process, the system can compare the target test case with the previous test case in the initial valid test case list as a benchmark. If the coverage data of the previous test case is completely contained in the target test case, the previous test case can be marked as redundant and removed. Thus, the initial valid test case list is refined again by reverse traversal, effectively avoiding the residual of redundant test cases, improving the compactness and accuracy of the initial valid test case list, and finally outputting the updated initial valid test case list to the user.

[0094] Specifically, after the traversal of the ordered test case list in the forward order is completed, the initial valid test case list is traversed in reverse order, and the traversed test case is determined as the target test case in the traversal process.

[0095] The reverse order traversal includes starting from the last test case at the tail of the initial valid test case list, and then traversing forward until the first test case at the head of the list, and in the process, the traversed test case is determined as the target test case.

[0096] The target test case refers to the test case currently selected for execution and determination in the process of traversing the initial valid test case list in the preset reverse order. Through the above reverse order traversal process, complete scanning of the initial valid test case list from the tail to the head can be achieved, ensuring that all test cases in the list are checked and determined one by one, thereby avoiding omission.

[0097] Subsequently, the target test case in the initial valid test case list is executed, and based on the execution result, the target test case is determined as a valid test case or a redundant test case. In this step, the target test case is executed and relevant execution result information, such as the first code coverage data, is collected during the execution of the test case. Then, based on the collected execution result information, the target test case is analyzed and determined to determine whether it produces new contributions to the overall code coverage. If the analysis result shows that the target test case can trigger a new code path or increase coverage, it is determined as a valid test case; on the contrary, if the execution result of the target test case is consistent with the existing coverage data and does not produce new coverage, it is determined as a redundant test case.

[0098] After the execution of the target test case is completed, the target test case is updated using the previous test case in the initial valid test case list, and the execution step is returned: the target test case in the initial valid test case list is executed, and based on the execution result, the target test case is determined to be a valid test case or a redundant test case; until the reverse traversal of the initial valid test case list is completed, when there is no previous test case in the initial valid test case list, the traversal is ended, and the updated initial valid test case list is output to the user.

[0099] Specifically, after the validity of the current target test case is determined, the system continues to select the previous test case in the initial valid test case list as a new target test case, and repeats the above execution and determination process. Through reverse traversal, all test cases in the initial valid test case list are executed and determined to be valid test cases or redundant test cases from the tail to the head.

[0100] For example, it is assumed that the initial valid test case list generates a list containing TC1, TC3, and TC5 after screening. In the reverse traversal process, the system first determines the test case TC5 at the tail as the target test case and executes it, and determines it to be a valid test case according to the execution result. Then, the previous test case TC3 is selected as the new target test case and executed, and if it is determined that there is no new contribution to the coverage, TC3 is marked as a redundant test case. Then TC1 is processed in turn until the first test case is traversed.

[0101] In the entire reverse traversal and execution process, the target test case is updated, executed and determined one by one, and finally through the reverse scanning method, it is ensured that each test case in the initial valid test case list is executed and checked, and finally after the traversal of all test cases in the initial valid test case list is completed, the updated initial valid test case list is output to the user for the user to obtain and analyze the final valid test case set.

[0102] After the forward traversal, the above-mentioned reverse traversal operation can be performed to further determine the redundant test cases in the initial valid test case list that are determined to be valid test cases. For example, the first code coverage of TC1 and TC3 is compared in the reverse traversal. The coverage range of TC3 is A, B, C, and D, and the coverage range of TC1 is A, B, and C. Through the comparison in the reverse traversal, it is found that the coverage range A, B, and C of TC1 is completely contained in the coverage range A, B, C, and D of TC3, that is, TC1 is a subset of the previous target test case TC3, and therefore, TC1 does not provide any coverage contribution that TC3 does not have. Therefore, through the above-mentioned reverse traversal, the redundant test cases in the initial valid test case list can be further determined and removed, such as the test case TC1 in the example.

[0103] As a preferred embodiment, after the target test case in the initial valid test case list is executed and it is determined that the target test case is a valid test case or a redundant test case based on the execution result, a step of removing the redundant test case from the initial valid test case list can be further included.

[0104] Specifically, after the target test case in the initial valid test case list is executed and it is determined that the target test case is a redundant test case based on the execution result, a step of removing the redundant test case from the initial valid test case list is further included. The step of removing the redundant test case from the initial valid test case list can be performed after a certain target test case is determined to be a redundant test case, or all the test cases in the initial valid test case list can be executed after the determination of all the test cases in the initial valid test case list is completed. In this embodiment, the redundant test cases in the initial valid test case list are further removed through the operation of removing the redundant test cases in the initial valid test case list, so as to maintain the validity of the test cases in the initial valid test case list.

[0105] In this embodiment, after the target test case is executed, the generated test information file includes a control flow information file stored in a.gcno format and a runtime execution information file stored in a.gcda format. The Gcda file is generated during the program running stage and is used to record the dynamic execution information of the target source code generated during the test execution process, including the execution times of each basic block, the triggering condition of the branch statement, and the call times of the function. Correspondingly, the Gcno file is generated during the compilation stage and is used to record the static control flow information of the target source code, including the structural relationship of the function, the basic block, and the branch. The code level structure of the target program before running can be reflected through the Gcno file, which is used to map the dynamic execution information in the Gcda file to realize the correspondence between the static structure and the runtime execution condition, thereby supporting the calculation and statistics of the coverage.

[0106] After generating the Gcda file, the specific process of parsing and generating the first code coverage data based on the test information file is as follows. First, the code coverage analysis tool jointly parses the Gcno file and the Gcda file, corresponds the dynamic execution times recorded in the Gcda file with the control flow information in the Gcno file, determines the coverage of each function, each code block and each branch in the target source code, and forms the coverage statistical result, thereby providing data support for subsequent output of the first code coverage data and formation of the coverage report. Specifically, when compiling the target source code, the GCC compiler with the coverage insertion parameter (for example, -fprofile-arcs, -ftest-coverage) is used to generate the corresponding executable program and the Gcno file. Subsequently, the code coverage analysis tool is used to execute the target test case, for example, the Gcov tool in the GNU tool chain is used to execute the target test case, and the corresponding Gcda file is generated after the test is completed. Then, the Gcov tool is used to parse the Gcno file and the Gcda file, map the dynamic execution times recorded in the Gcda file with the control flow information in the Gcno file, thereby determine the coverage of each function, basic block and branch and generate the coverage statistical result. Finally, the first code coverage data can be output based on the parsing result.

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

[0108] As an optional implementation, after ending 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 the newly added test case input by the user, executing all test cases in the initial valid test case list to obtain a benchmark coverage rate of the initial valid test case list; adding the newly added test case to the initial valid test case list and executing all test cases in the initial valid test case list again to obtain an updated coverage rate of the initial valid test case list; in the case where the benchmark coverage rate is different from the updated coverage rate, determining that the newly added test case is a valid test case and retaining the newly added test case in the initial valid test case list; and in the case where the benchmark coverage rate is the same as the updated coverage rate, determining that the newly added test case is a redundant test case.

[0109] In the implementation process, firstly, all test cases in the initial valid test case list are executed to generate a benchmark coverage, which is used as a reference value for determining the validity of newly added test cases; when a user inputs a newly added test case, the system adds the newly added 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 benchmark coverage with the updated coverage, it can be determined whether the newly added test case produces new contribution to the overall coverage; as an optional mode, the benchmark coverage and the updated coverage in the embodiment are calculated based on function statement coverage, and in other implementation modes, the benchmark coverage and the updated coverage can also be calculated based on branch coverage or path coverage.

[0110] Through the above method, the benchmark coverage and the updated coverage can be dynamically generated and compared when a newly added test case is received, so as to realize the automatic judgment of whether the newly added test case is a valid test case or a redundant test case, ensure the real-time updating and simplification of the initial valid test case list, avoid the accumulation of redundant test cases, improve the test execution efficiency, reduce the consumption of computing resources, and ensure that the determination process of the benchmark coverage and the updated coverage is consistent, objective and standardized.

[0111] For example, in the EDA software test scene, the benchmark coverage is 82% after the traversal of the initial valid test case list is completed; when a user adds a test case TC401 to the initial valid test case list, all test cases in the initial valid test case list are executed again to obtain an updated coverage; if the updated coverage is increased to 85%, it is determined that the newly added test case is a valid test case and is retained in the initial valid test case list; if the updated coverage is still 82%, it is determined that the newly added test case is a redundant test case, and the user is prompted that the test case does not produce new coverage contribution.

[0112] Figure 2 A hardware structure schematic diagram of a test case data processing apparatus provided by an embodiment of the application is shown. In the Figure 2 embodiment, the test case data processing apparatus can include:

[0113] The acquisition module 201 is configured to acquire a full-amount test case set, and generate an ordered test case list based on the full-amount test case set.

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

[0115] The determination module 203 is configured to execute the target test case, and determine the target test case as a valid test case or a redundant test case based on an execution result.

[0116] The target updating module 204 is configured to determine the next test case in the ordered test case list as a target test case, return to execute the target test case, and judge 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 judging module 203 can include:

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

[0119] In some embodiments, the target updating module 204 can include:

[0120] The output module is configured to output the initial valid test case list to a user.

[0121] In some embodiments, the judging module 203 can include:

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

[0123] In some embodiments, the judging module 203 can include:

[0124] The first code coverage data comparison module is configured to obtain first code coverage data of the target test case after the execution of the target test case, compare the first code coverage data of the target test case with first code coverage data of a previous test case, determine the target test case as a redundant 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, and determine the target test case as a valid 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.

[0125] In some embodiments, the judging module 203 can include:

[0126] The coverage record variable module is configured to create a coverage record variable and set an initial value of the coverage record variable as 0, and update the coverage record variable based on the first code coverage data after the execution of the target test case is completed.

[0127] In some embodiments, the judging module 203 can include:

[0128] A first test case comparison module is configured to compare the first code coverage data of the target test case with an 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 obtaining module 201 can include:

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

[0131] In some embodiments, the target updating module 204 can include:

[0132] A reverse traversal module is configured to traverse the initial valid test case list in a reverse order, determine a traversed test case as a target test case during the traversal, execute the target test case in the initial valid test case list and judge whether the target test case is a valid test case or a redundant test case based on an execution result, update the target test case using a previous test case in the initial valid test case list, and return to the execution step of 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 an execution result, and when there is no previous test case in the initial valid test case list, end the traversal of the initial valid test case list and output the updated initial valid test case list to a user.

[0133] In some embodiments, the judging module 203 can include:

[0134] A redundant test case removal module is configured to remove a redundant test case from the initial valid test case list.

[0135] In some embodiments, the judging module 203 can include:

[0136] A test information file generation module is configured to execute the target test case using a code coverage analysis tool and generate a test information file corresponding to the target test case, and calculate 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 updating module 204 can include:

[0138] The test case adding judgment module is configured to, in response to receiving a user input of an added test case, execute all test cases in the initial valid test case list to obtain a benchmark coverage rate of the initial valid test case list, add the added test case to the initial valid test case list, and execute all test cases in the initial valid test case list again to obtain an updated coverage rate of the initial valid test case list, determine that the added test case is a valid test case and retain the added test case in the initial valid test case list when the benchmark coverage rate is different from the updated coverage rate, and determine that the added test case is a redundant test case when the benchmark coverage rate is the same as the updated coverage rate.

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

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

[0141] The memory 302 can comprise a mass storage for data or instructions. By way of example and not limitation, the memory 302 can include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. Where appropriate, the memory 302 can include removable or non-removable (or fixed) media. Where appropriate, the memory 302 can be internal or external to the test case data processing device. In certain embodiments, the memory 302 is a non-volatile solid-state memory.

[0142] The memory 302 can include read-only memory (ROM), a flash memory device, a random access memory (RAM), a magnetic disk storage device, an optical disk storage device, an electrical, optical, or other physical / tangible memory storage device. Thus, in general, the memory 302 includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software that can include computer executable instructions and when the software is executed (e.g., by one or more processors) it is operable to perform operations described with reference to the methods according to the above aspects of the present disclosure.

[0143] The processor 301 implements the test case data processing method in any of the above embodiments by reading and executing computer program instructions stored in the memory 302.

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

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

[0146] The bus 310 includes hardware, software or both to couple the components of the test case data processing device to each other. By way of example, and without limitation, the bus can include an accelerated graphics port (AGP) or other graphics bus, an enhanced industry standard architecture (EISA) bus, a front-side bus (FSB), a hypertransport (HT) interconnect, an industry standard architecture (ISA) bus, an infiniband 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 another suitable bus or combination of two or more of these. Where appropriate, the bus 310 can include one or more buses. Although the present embodiments describe and show a particular bus, the present application contemplates any suitable bus or interconnect.

[0147] The test case data processing device can be based on the test case data processing method, thereby realizing the test case data processing method and device described in combination with Figure 1 and Figure 2 The test case data processing method and device.

[0148] In addition, in combination with the test case data processing method in the above embodiments, the embodiments of the present application can provide a computer storage medium to realize. The computer storage medium has computer program instructions stored thereon; the computer program instructions are executed by the processor to realize any of the test case data processing methods in the above embodiments.

[0149] In addition, the embodiments of the present application also provide a computer program product, including a computer program, the computer program is executed by the processor to realize the steps and corresponding contents of the above method embodiment.

[0150] ​In addition, the term "and / or" herein merely describes an associated relationship with the associated objects, which means that there can be three relationships, for example, A and / or B can represent three cases: A exists alone, A and B exist together, and B exists alone. In addition, the character " / " herein generally represents an "or" relationship between the front and rear associated objects.

[0151] It should be understood that in the embodiments of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should also be understood that the determination of B according to A does not mean that B is determined only according to A, but B can also be determined according to A and / or other information.

[0152] The above is only a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present application, and these modifications or replacements should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A test case data processing method, characterized by, The method comprises the following steps: acquiring a full set of test cases, and generating an ordered test case list based on the full set of test cases; traversing the ordered test case list in a forward order, and determining a test case as a target test case during the traversal; executing the target test case, and judging whether the target test case is a valid test case or a redundant test case based on an execution result, including: creating an initial valid test case list, and storing a valid test case in the initial valid test case list; if the target test case can trigger a new code path or increase coverage, the target test case is determined as a valid test case, otherwise, the target test case is determined as a redundant test case; determining a next test case in the ordered test case list as the target test case, and returning to the step 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 an execution result, until the traversal of the ordered test case list is completed; traversing the initial valid test case list in a reverse order, and determining a test case as a target test case during the traversal; 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 an execution result; updating the target test case using a previous test case in the initial valid test case list, and returning to the step of 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 an execution result; when there is no previous test case in the initial valid test case list, ending the traversal of the initial valid test case list, and outputting the updated initial valid test case list to a user.

2. The test case data processing method of claim 1, wherein, After the step of determining a next test case in the ordered test case list as the target test case, and returning to the step 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 an execution result, until the traversal of the ordered test case list is completed, the method further comprises: outputting the initial valid test case list to a user.

3. The test case data processing method of claim 1, wherein, The step 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 an execution result comprises: creating a redundant test case list, and storing a redundant test case in the redundant test case list.

4. The test case data processing method of claim 3, wherein, The step 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 an execution result comprises: creating a coverage record variable, and setting an initial value of the coverage record variable as 0; after the execution of the target test case is completed, updating the coverage record variable based on first code coverage data.

5. The test case data processing method of claim 4, wherein, When the target test case is a first test case in the test case list, comparing first code coverage data of the target test case with the initial value of the coverage record variable.

6. The test case data processing method of claim 1, wherein, Before the acquiring the full test case set, and generating the ordered test case list based on the full test case set, the method further comprises: acquiring a target source code file from a code repository, and preprocessing, compiling and linking the target source code file using a compiler to generate an executable file, wherein the executable file is used to run a test case and acquire first code coverage data corresponding to the test case.

7. The test case data processing method of claim 1, wherein, The executing the target test case in the initial valid test case list, and determining whether the target test case is a valid test case or a redundant test case based on the execution result, further comprises: removing the redundant test case from the initial valid test case list.

8. The test case data processing method of claim 1, wherein, The 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, comprises: The target test case is executed by using a code coverage analysis tool to generate a test information file corresponding to the target test case, and first code coverage data is calculated based on the test information file; wherein the test information file comprises a Gcda file and a Gcno file.

9. The test case data processing method of claim 1, wherein, After the ending of the traversal of the initial valid test case list, and the outputting of the updated initial valid test case list to a user, the method further comprises: in response to receiving a newly added test case input by the user, executing all test cases in the initial valid test case list to obtain a baseline coverage rate of the initial valid test case list; The newly added test case is added to the initial valid test case list, and all test cases in the initial valid test case list are executed again to obtain an updated coverage rate of the initial valid test case list; In a case where the baseline coverage rate is different from the updated coverage rate, the newly added test case is determined to be a valid test case, and the newly added test case is retained in the initial valid test case list; in a case where the baseline coverage rate is the same as the updated coverage rate, the newly added test case is determined to be a redundant test case.

10. A test case data processing apparatus, characterized by, The method comprises: An acquiring module is configured to acquire a full test case set, and generate an ordered test case list based on the full test case set; A traversal module is configured to traverse the ordered test case list in a forward order, and determine a test case traversed in the process as a target test case; A determining module is configured 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 an execution result, wherein if the target test case can trigger a new code path or increase coverage rate, the target test case is determined to be a valid test case, otherwise, the target test case is determined to be a redundant test case, and the determining module comprises an initial valid test case list module configured to create an initial valid test case list, and store valid test cases in the initial valid test case list; a target updating module, configured to determine a next test case in the ordered test case list as the target test case, return the step of executing the target test case, and judging the target test case 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; a reverse traversal module, configured to traverse the initial valid test case list in a reverse order, and determine a traversed test case as a target test case in the traversal process; execute the target test case in the initial valid test case list, and judge the target test case as a valid test case or a redundant test case based on the execution result; update the target test case using a previous test case in the initial valid test case list, and return the step of executing the target test case in the initial valid test case list, and judging the target test case as a valid test case or a redundant test case based on the execution result; when there is no previous test case in the initial valid test case list, end the traversal of the initial valid test case list, and output the updated initial valid test case list to a user.

11. An electronic device, comprising: comprise: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the steps of the test case data processing method in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, the computer program instructions stored on the computer readable storage medium are executed by the processor to implement the steps of the test case data processing method in any one of claims 1-9.

13. A computer program product, characterised in that, the instructions in the computer program product are executed by the processor to implement the steps of the test case data processing method in any one of claims 1-9.

Images