Software Testing Method and Apparatus Based on Dynamic Coverage Data and Feedback Learning

Abstract

This invention provides a software testing method and apparatus based on dynamic coverage data and feedback learning, relating to the field of software testing technology. The method includes: determining test cases to be executed on the software system under test within the current test cycle according to the test case priorities corresponding to the test case set; acquiring dynamic coverage data of the software system under test in the previous test cycle, and updating the dynamic coverage data using test execution feedback information corresponding to the test cases; adjusting the test case priorities based on the dynamic coverage data corresponding to the current test cycle, and proceeding to the next test cycle until a preset test termination condition is met, thereby obtaining the test results for the software system under test. This invention enables a self-optimizing and adaptive dynamic test case priority ranking mechanism based on real-time test execution feedback, significantly improving the defect discovery efficiency and test resource utilization in regression testing.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a software testing method and apparatus based on dynamic coverage data and feedback learning. Background Technology

[0002] Existing test case priority sorting (TCP) technologies are mainly divided into several categories, and their core process can be abstracted as: test case set generation, static priority sorting, sequential execution of test cases, and test completion.

[0003] The above static solution has the following fundamental technical defects: First, the sequencing decision is lagging and cannot respond to dynamic changes in the software state. The sequencing process is only executed once before the test starts, and the data relied upon are all historical snapshots or static analysis results. During the test execution, when new logical units are covered, new defects are located, or the defect density of a module changes significantly, the actual quality status of the software under test has changed. However, the established execution order cannot be adjusted according to this real-time evolving state information, resulting in test resources being continuously allocated to areas that are already fully covered or have low defect risk, while high-risk areas that are not fully covered, have been recently modified, or have a sudden increase in defect density fail to be verified in a timely manner.

[0004] Second, the feedback information generated during the defect discovery process is not fully utilized. Existing methods (such as greedy algorithms based on branch coverage) focus solely on rapidly increasing coverage as the ranking objective. However, there is no necessary correlation between high coverage and high defect detection rate. Existing static ranking schemes that rely on coverage cannot immediately increase the priority of other test cases for that module after the first defect is discovered.

[0005] Third, the ranking strategy lacks adaptive optimization capabilities. Whether it is a greedy strategy based on coverage or a model that uses fixed weights to combine multi-dimensional indicators, the strategy parameters and calculation logic remain constant throughout the entire testing cycle, and cannot dynamically adjust the focus of the ranking objective according to the progress of the test.

[0006] Fourth, the generation (or selection) and execution of test cases are disconnected. The existing process treats test case sequencing as an independent pre-stage, and the key feedback information generated during execution is not fully explored, resulting in a systematic waste of test knowledge. Summary of the Invention

[0007] In view of this, the purpose of the present invention is to provide a software testing method and apparatus based on dynamic coverage data and feedback learning, which can perform self-optimization and adaptive dynamic test case priority ranking mechanism according to real-time feedback of test execution, so as to significantly improve the defect discovery efficiency and test resource utilization of regression testing.

[0008] In a first aspect, the present invention provides a software testing method based on dynamic coverage data and feedback learning, comprising: Based on the test case priority corresponding to the test case set, determine the test cases to be executed against the software system under test in the current test cycle; The dynamic coverage data of the software system under test in the previous test cycle is obtained. The dynamic coverage data is updated using the test execution feedback information corresponding to the test cases to obtain the dynamic coverage data in the current test cycle. The dynamic coverage data is used to characterize the coverage and defect status of multiple logical units contained in the software system under test in at least one test cycle. The test case priorities are adjusted based on the dynamic coverage data corresponding to the current test cycle, and the test cycle continues until the preset test termination conditions are met, at which point the test results for the software system under test are obtained.

[0009] In one implementation, the software system under test is divided into multiple logical units; Test execution feedback information includes at least the execution result, coverage increment, and defect association information; wherein, the execution result is: execution success, execution failure, or execution error; the coverage increment is used to characterize: at least one logical unit and its branches covered by the test cases executed against the software system under test within the current test cycle; the defect association information is used to characterize: at least one logical unit that caused the execution result to be execution failure or execution error; Dynamic coverage data includes at least test sufficiency and defect density; wherein, test sufficiency is used to characterize: the coverage status of the logical unit in at least one test cycle, including at least the covered identifier, branch coverage rate and coverage count; defect density is used to characterize: the probability that the logical unit will fail or err due to defects in at least one historical test cycle.

[0010] In one implementation, the dynamic coverage data is updated using test execution feedback information corresponding to the test cases to obtain the dynamic coverage data corresponding to the current test cycle, including: Based on the coverage increment, determine the first target logical unit and its target branch that are covered in the current test cycle from the software system under test, and perform the following operations on the first target logical unit: Set the covered flag corresponding to the first target logical unit to true, update the branch coverage rate corresponding to the first target logical unit according to the covered target branch, and increment the coverage count corresponding to the first target logical unit by one.

[0011] In one implementation, the dynamic coverage data is updated using test execution feedback information corresponding to the test cases to obtain the dynamic coverage data corresponding to the current test cycle, and the method further includes: In the event of execution failure or error, based on defect association information, a second target logical unit that caused the execution failure or error is identified from the software system under test, and the defect density corresponding to the second target logical unit is increased. If the execution is successful, the defect density corresponding to the first target logic unit is attenuated.

[0012] In one implementation, adjusting test case priorities based on dynamic coverage data corresponding to the current test cycle includes: Based on the dynamic coverage data corresponding to the current test cycle, determine the test sufficiency normalized value and defect density normalized value for each logical unit in the software system under test. Based on the pre-constructed use case-unit association matrix, the normalized test sufficiency value and the normalized defect density value corresponding to each logical unit, the potential evaluation value corresponding to each logical unit is determined. The priority of unexecuted test cases in the test case set is adjusted according to the potential assessment value from high to low.

[0013] In one implementation, the use case-unit association matrix is ​​used to characterize the static association strength value between logical units and test cases; the method further includes: Based on historical execution coverage data, the co-occurrence frequency of coverage between logical units and test cases is statistically analyzed. After applying time decay processing to the co-occurrence frequency of coverage, it is normalized to obtain the first association strength value. Based on the code file of the logical unit, the calling relationship between the logical unit and the test case is parsed, and the second association strength value is determined according to the calling relationship; The first association strength value and the second association strength value are merged to generate a static association strength value between the logical unit and the test case.

[0014] In one implementation, before adjusting test case priorities based on dynamic coverage data corresponding to the current test cycle, the method further includes: Determine whether the preset priority adjustment conditions are met; wherein the priority adjustment conditions include at least one of the following: the number of continuously executed test cases reaches a preset number threshold, the change in defect density of any logical unit exceeds a preset change threshold, and the time between the current time and the time of the previous test case priority adjustment reaches a preset time threshold. If the judgment result is yes, the priority of the test cases will be adjusted according to the dynamic coverage data corresponding to the current test cycle.

[0015] Secondly, the present invention also provides a software testing apparatus based on dynamic coverage data and feedback learning, comprising: The test case determination module is used to determine the test cases to be executed on the software system under test within the current test cycle according to the test case priority corresponding to the test case set. The coverage data update module is used to obtain the dynamic coverage data of the software system under test in the previous test cycle, and update the dynamic coverage data using the test execution feedback information corresponding to the test cases to obtain the dynamic coverage data in the current test cycle. The dynamic coverage data is used to characterize the coverage and defect status of multiple logical units contained in the software system under test in at least one test cycle. The priority adjustment module is used to adjust the priority of test cases based on the dynamic coverage data corresponding to the current test cycle, and then proceed to the next test cycle until the preset test termination conditions are met, at which point the test results of the software system under test are obtained.

[0016] Thirdly, the present invention also provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement any of the methods provided in the first aspect.

[0017] Fourthly, the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement any of the methods provided in the first aspect.

[0018] This invention provides a software testing method and apparatus based on dynamic coverage data and feedback learning. In each test cycle, dynamic coverage data is updated in real time according to the latest execution feedback, and the priority of unexecuted test cases is adjusted accordingly. This ensures that scheduling decisions always focus on key logic units with insufficient coverage, high defect risk, or recent modifications. This mechanism avoids the problem of wasting resources on verified areas in static sorting, significantly improves the number of defects detected per unit test time and the speed of first discovery, while reducing the number of test execution rounds and total time required to achieve the same defect detection rate. Thus, it improves the overall utilization efficiency of test resources while ensuring quality.

[0019] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating a software testing method based on dynamic coverage data and feedback learning, provided for an embodiment of the present invention; Figure 2 A diagram illustrating the overall technical framework of a software testing method based on dynamic coverage data and feedback learning, provided in an embodiment of the present invention. Figure 3 A schematic diagram of a software testing device based on dynamic coverage data and feedback learning provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Currently, existing static sorting schemes suffer from the following problems: sorting decisions are lagging and unable to respond to dynamic changes in software state; they do not adequately utilize feedback information generated during defect discovery; the sorting strategy lacks adaptive optimization capabilities; and the generation (or selection) and execution of test cases are disconnected. Based on this, this invention provides a software testing method and apparatus based on dynamic coverage data and feedback learning. This method features a self-optimizing and adaptive dynamic test case priority sorting mechanism that utilizes real-time feedback from test execution to significantly improve defect discovery efficiency and test resource utilization in regression testing.

[0025] To facilitate understanding of this embodiment, a software testing method based on dynamic coverage data and feedback learning, as disclosed in this embodiment of the invention, will first be described in detail. (See [link to relevant documentation]). Figure 1 The diagram shows a software testing method based on dynamic coverage data and feedback learning. This method mainly includes the following steps S102 to S106: Step S102: Determine the test cases to be executed on the software system under test within the current test cycle according to the test case priority corresponding to the test case set.

[0026] A test case set is a collection of multiple test cases. A test case is the smallest logical unit that can be independently compiled, loaded, and executed. Test case priority refers to a numerical value (i.e., a potential assessment value) assigned to each test case. This value is calculated using dynamic coverage data and the test case-unit association matrix, and is used to characterize the relative importance of the test case being scheduled for execution at the current moment. The software system under test refers to the target software currently in the testing phase, whose code has been deployed in the testing environment and is able to respond to calls initiated by test cases and return execution results.

[0027] In one implementation, firstly, a scheduling list is formed by acquiring all unexecuted test cases from the test case set; then, the current test case priority of each test case is read; next, the test cases are sorted from high to low priority; finally, the test case at the top of the sorted list is determined as the test case to be executed in the current test cycle. Based on this, for the test case executed on the software system under test, corresponding test execution feedback information is obtained. The test execution feedback information includes the execution result (i.e., the deterministic result identifier of this execution), the coverage increment (i.e., the set of newly covered logical units in this execution), and defect association information (i.e., the set of defect-associated logical units located when the execution result is failure or error).

[0028] Step S104: Obtain the dynamic coverage data of the software system under test in the previous test cycle, and update the dynamic coverage data using the test execution feedback information corresponding to the test cases to obtain the dynamic coverage data in the current test cycle.

[0029] Among them, dynamic coverage data is used to characterize the coverage and defect status of multiple logical units contained in the software system under test within at least one test cycle. Specifically, it is a data structure used to record the continuously evolving coverage status and defect risk status of each logical unit in the software system under test during the test process. Each logical unit corresponds to a data item, which includes at least two fields: test adequacy and defect density.

[0030] In one implementation, the dynamic coverage data saved at the end of the previous test cycle is first loaded; then, the test execution feedback information corresponding to the test cases to be executed in this test cycle is obtained; then, based on the test execution feedback information, the test sufficiency and defect density fields of the corresponding logical units in the dynamic coverage data are updated; finally, the updated dynamic coverage data is saved and used as the dynamic coverage data corresponding to the current test cycle.

[0031] Step S106: Adjust the test case priority according to the dynamic coverage data corresponding to the current test cycle, and enter the next test cycle until the preset test termination condition is met, and obtain the test result corresponding to the software system under test.

[0032] The preset test termination conditions refer to the technical indicators set before the start of the test to determine whether the current round of regression testing has ended. These include, but are not limited to, the number of executed test cases reaching the upper limit, the cumulative execution time exceeding a threshold, the number of consecutive rounds without new defects being found reaching a set value, or the priority of all unexecuted test cases being lower than the minimum threshold. The test results refer to the comprehensive quality assessment conclusion output by the system when the preset test termination conditions are met. These conclusions include at least the pass rate of executed test cases, the number and distribution of newly discovered defects, statistics on the coverage adequacy of key logic units, and a list of modules with high defect density.

[0033] In one implementation, the dynamic coverage data corresponding to the current test cycle is first read; then, based on the dynamic coverage data and the test case-logic element association matrix, the priority of each test case that has not yet been executed is recalculated; then, the latest test case priority is applied to subsequent scheduling; then, the next test cycle is entered; the aforementioned steps are repeated until the preset test termination condition is met; when the condition is met, all execution records and dynamic coverage data are summarized to generate the test results corresponding to the software system under test.

[0034] The software testing method based on dynamic coverage data and feedback learning provided by this invention updates the dynamic coverage data in real time according to the latest execution feedback in each test cycle, and adjusts the priority of unexecuted test cases accordingly. This ensures that scheduling decisions always focus on key logical units with insufficient coverage, high defect risk, or recent modifications. This mechanism avoids the problem of wasting resources on verified areas in static sorting, significantly improves the number of defects detected per unit of test time and the speed of first discovery, while reducing the number of test execution rounds and total time required to achieve the same defect detection rate. Thus, it improves the overall utilization efficiency of test resources while ensuring quality.

[0035] The embodiments of the present invention first explain the relevant concepts.

[0036] The software system under test is divided into multiple logical units; Test execution feedback information includes at least the execution result, coverage increment, and defect association information; wherein, the execution result is: execution success, execution failure, or execution error; the coverage increment is used to characterize: at least one logical unit and its branches covered by the test cases executed against the software system under test within the current test cycle; the defect association information is used to characterize: at least one logical unit that caused the execution result to be execution failure or execution error; Dynamic coverage data includes at least test sufficiency and defect density; test sufficiency is used to characterize the coverage of a logical unit in at least one test cycle, including at least coverage indicators, branch coverage, coverage count, condition coverage, path coverage, modification coverage and other metrics or combinations thereof; defect density is used to characterize the probability that a logical unit will fail or err due to defects in at least one historical test cycle.

[0037] Among them, the following are key metrics: **Coverage Flag:** A Boolean field indicating whether a logical unit has been covered at least once in historical test executions. A true value indicates the logical unit has been covered, and a false value indicates it has not been covered. **Branch Coverage:** A numerical indicator reflecting the proportion of all decision branches executed within a logical unit, obtained by comparing the number of executed branches to the total number of decision branches. **Coverage Count:** An integer field recording the cumulative number of times a logical unit has been covered in historical test executions. **Condition Coverage:** A metric reflecting whether each atomic condition within a logical unit is covered by test executions within its possible value range, requiring each atomic condition to take at least one true and one false value. **Path Coverage:** A metric reflecting whether all feasible control flow paths within a logical unit are covered by test executions, where feasible paths refer to execution paths actually reachable under program semantic constraints. **Modification Coverage:** A metric reflecting whether code elements added, modified, or deleted in the current software version iteration have been covered by the current test execution, calculated based on change difference information provided by the version control system.

[0038] Based on this, embodiments of the present invention provide a specific implementation of a software testing method based on dynamic coverage data and feedback learning, see [link to relevant documentation]. Figure 2 The diagram shown illustrates the overall technical framework of a software testing method based on dynamic coverage data and feedback learning, including: Step S202: Initialize the test case set and construct dynamic coverage data.

[0039] The input is the software system under test, S, and the initial test case set, T. First, static analysis is performed on system S (e.g., scanning the source code using code analysis tools), dividing it into m logical units (such as functions, code blocks, and modules), denoted as U={ , , ..., Then, we construct a core data structure: Dynamic Covering Array (DCA). DCA is an array of length m, where the i-th element... Corresponding logic unit Its data structure must contain at least: unit_id: Unit identifier.

[0040] `coverage_sufficiency`: This is a vector or composite value used to record whether a cell is covered. For example, it can contain a boolean field `is_covered` (whether it has been covered), a numeric field `branch_coverage_ratio` (branch coverage rate, between 0 and 1), and an integer field `hit_count` (number of times a cell has been covered). All fields are initialized to 0 or an uncovered state.

[0041] `defect_density`: Defect density is a scalar value representing the risk of this unit causing defects. The initial value can be calculated by analyzing version history (such as Git logs), for example: (number of historical modifications related to fixing defects / total number of modifications to this unit). If no historical data is available, it can be initialized to a base value (e.g., 0.1). Optionally, the initial value of defect density can be calculated without relying on version history, using other prior knowledge such as code complexity or developer experience. The update formula is not limited to weighted averages; other incremental update algorithms can be used, such as probabilistic models based on Bayesian updates.

[0042] It should be noted that a Dynamic Coverage Array (DCA) does not necessarily have to be a strict "array" data structure. Essentially, it is a data container that allows for quick lookup and updating of values ​​(coverage sufficiency, defect density) by key (logical unit identifier). Therefore, hash tables, dictionaries, or key-value tables in databases can all be used as alternative implementations, as long as they can efficiently store and retrieve the state information of each logical unit.

[0043] Simultaneously, the system creates or loads a test case-unit association matrix A (n rows and m columns, where n is the number of test cases). Matrix elements Represents test cases AND logic unit The static association strength can be obtained through historical execution coverage data or static call relationship analysis of code. This invention provides a specific implementation method for establishing a use case-unit association matrix A, including: (1) Based on historical execution coverage data, the frequency of co-occurrence of coverage between logical units and test cases is statistically analyzed. The frequency of co-occurrence of coverage is normalized after time decay processing is applied to obtain the first correlation strength value.

[0044] Historical execution coverage data refers to the set of coverage reports generated by the software under test in previous test rounds, containing the identifiers of the logical units covered in each test execution and their corresponding coverage status. Coverage co-occurrence frequency refers to the cumulative number of times a test case and a logical unit appear simultaneously in the same round of test coverage reports during historical executions. Time decay processing refers to the operation of applying weighted attenuation to the coverage co-occurrence frequency based on its proximity to the current time, giving higher weight to more recent co-occurrence records than earlier records. The first association strength value refers to a numerical value representing the empirical association degree between test cases and logical units, obtained based on historical execution coverage data after time decay and normalization.

[0045] In one implementation, the system reads historical execution coverage data and extracts coverage records for all test cases and logic units. It counts the number of times each pair of test cases and logic units co-occurs in history to form coverage co-occurrence frequency. Based on the occurrence time of each record, it assigns a weight to its frequency using an exponential decay function, with higher weights for more recent records. The weighted sum of frequencies is then normalized to obtain the first association strength value corresponding to the test case and the logic unit.

[0046] This invention also provides another implementation for establishing a use case-unit association matrix A, comprising: outputting from a pre-trained machine learning model, the model being based on two inputs: (1) A snapshot of the current state of the Dynamic Coverage Array (DCA), including the values ​​of the is_covered, branch_coverage_ratio, hit_count, and defect_density fields for each logical unit; (2) Test cases The structured characteristics include the name of the test class to which it belongs, the name of the target class under test, the method signature, the length of the call chain, the set of parameter types, the number of assertions, and the expected type of exception.

[0047] After receiving the above input, the model directly outputs a scalar value as a test case. With the specified logic unit The static correlation strength between the components; this value, ranging from 0 to 1, reflects the prior fit of the test case to verify the logical unit under the dual constraints of the current software state and the test case context; the model is trained and deployed before test execution, and its output remains unchanged in a single test session, functionally equivalent to a traditional correlation matrix. The corresponding element in.

[0048] (2) Based on the code file of the logical unit, parse the calling relationship between the logical unit and the test case, and determine the second association strength value according to the calling relationship; The code file refers to a text file containing the source code of the logical units in the software under test. Its format includes source code files from mainstream programming languages ​​such as Java, Python, and C++. The call relationship refers to the program control flow dependency formed by the direct or indirect calls of logical units by the test case during execution. The second association strength value refers to a numerical value determined based on the call relationship obtained from static code analysis, characterizing the degree of structural association between the test case and the logical unit.

[0049] In one implementation, the system reads the code file of the software under test and uses a static analysis tool to parse the call path between the test case class and the logical unit; it identifies whether the test case directly calls the logical unit or indirectly calls it through no more than two layers of intermediate logical units; if there is a direct call, a higher second association strength value is assigned; if it is an indirect call, the second association strength value is decreased according to the call depth.

[0050] (3) The first association strength value and the second association strength value are merged to generate a static association strength value between the logical unit and the test case.

[0051] In one implementation, a first association strength value and a second association strength value corresponding to the same test case and the same logical unit are obtained; the two values ​​are weighted and averaged according to a preset weight; the weighted average result is used as the element value of the test case and the logical unit in the association matrix, that is, the static association strength value.

[0052] Step S204: Execute test cases according to the current test case priority and collect feedback.

[0053] The system enters the loop execution phase. Initially, all test cases can be arranged in any initial order (such as random order). The system retrieves one (or a batch) of test cases from the head of the current priority queue. Execution. Upon completion, immediately collect real-time feedback information from three aspects using monitoring tools: (a) Coverage increment: obtained through instrumentation tools (such as JaCoCo). The set of logical units newly covered in this execution is denoted as C_new(k). For each unit in C_new(k), the coverage details (such as whether a new branch was covered) are recorded.

[0054] (ii) Execution result: Record Execution result Examples include PASS, FAIL, and ERROR.

[0055] (iii) Defect-related information: If If the result is FAIL or ERROR, preliminary defect localization is performed. By analyzing stack traces, logs, or combining lightweight fault localization techniques, the one or more logical units most likely to have failed are identified, denoted as the defect association information F(k). This feedback is encapsulated as a triple: .

[0056] Optionally, the location of defect association information F(k), in addition to analyzing stack traces, can be combined with more advanced runtime diagnostic tools, program spectrum analysis (such as Ochiai coefficients), or integration with a defect management system to more accurately locate suspicious logical units.

[0057] Furthermore, embodiments of the present invention provide a process for locating defect association information F(k), specifically including: Step 1: When test cases When execution fails, the system captures its complete stack trace string, parses it to extract the complete call chain from the test entry logic unit to the deepest exception throwing point, denoted as... ,in To test the entry logic unit, The call chain, which corresponds to the logical unit where the exception is actually thrown, constitutes a candidate defect propagation path. Step 2: Obtain the instrument using a tool such as JaCoCo. The code covered by this failed execution is retrieved, and the coverage increment of all recently executed test cases in the historical test library is retrieved. Test cases that pass and fail are marked. The preset program spectrum analysis module is called, and based on the coverage increment of the code covered by this failed execution and the historical executed test cases, the following data is collected: (1) In the historical test set, the execution failed and covered the logical unit. (1) The number of test cases; (2) The execution passed and covered the logical units. The number of test cases; (3) Execution failure but not covered logical units. The number of test cases; (4) Execution passed but not covered logical units. The number of test cases. For each logical unit. Substitute the above data into the standard formula for calculating the Ochiai coefficient to obtain the logical unit in the call chain. The Ochiai coefficient is used to select the first set of logical units S_spect whose coefficients are higher than a preset threshold (e.g., 0.65). This set is used to verify which nodes in the call chain have statistically significant defect correlations.

[0058] Step 3: Call the standard API interface of the defect management system, using the three characteristics of this failure as the joint query conditions: full name of the error type (referring to the test case). When execution fails, the fully qualified name of the exception class caught by the test execution environment; the identifier of the service module under test (which is the same as the test case). The microservice or subsystem-level logical boundary identifier corresponding to the verified business function is used to define the test case. All logical units covered by and that have failed are uniformly managed under the same business domain, i.e., one service module identifier corresponds to a group of logical units with a clear affiliation; stack prefix matching (referring to the ordered tuple consisting of the fully qualified names of three consecutive logical units located at the beginning of the call sequence extracted from the call chain generated by this failure); return all historical defect reports that satisfy the complete matching of the three criteria; extract the root cause logical unit (i.e., the logical unit that directly caused the defect) confirmed by the developers from each report, and form the second logical unit set S_bugs after deduplication; if no historical report is matched, S_bugs is an empty set.

[0059] Step 4: With Each logical unit in For each node, initialize its role label to "unlabeled"; iterate through the nodes in sequence. Each node: If If a logical unit exists simultaneously in both the first logical unit set S_spect and the second logical unit set S_bugs, then its role label is set as a strong root cause candidate; if the logical unit If a node belongs to the first logical unit set S_spect but not to the second logical unit set S_bugs, then check its preceding node. (i.e., call) If the logical unit belongs to the second logical unit set S_bugs, then... The role label is set as the defect propagation intermediate, and the role label is set as the defect propagation intermediate. The label is updated synchronously to the upstream strong root cause; if If a component does not belong to the first logical unit set S_spect but belongs to the second logical unit set S_bugs, then its role label is set as the historical recurrence root cause.

[0060] After the traversal is complete, for all nodes marked as intermediate points in defect propagation, their direct upstream nodes are identified. Include it in the expanded attention set (without changing its original label); the final output is one or more path segments consisting of consecutive labeled nodes, for example: "[ [The root causes of historical recurrence], [ [Defect propagation intermediates], [ [:Strong root cause candidate].

[0061] Step 5: Based on the path fragment generated in Step 4, perform the following operations: All logical units labeled as strong root cause candidates or historically recurring root causes are included in the main set of F(k) as core localization units; all logical units labeled as direct upstream nodes in the defect propagation process (i.e., As an extended positioning unit, it is included in the auxiliary set of F(k); For each logical unit in the main set (denoted as ) Assign confidence scores: 1.0 for a strong root cause candidate, and 0.9 for a historically recurring root cause; for each logical unit in the auxiliary set (denoted as...). (), and assign a score of 0.7; Define F(k) as a list of key-value pairs: This list is directly passed to the dynamic overlay data update module, which is used to adjust the defect density field of the corresponding logical unit according to the score ratio.

[0062] This process ensures that F(k) is no longer an isolated list of units, but a structured diagnostic result that carries the defect occurrence mechanism, propagation path, and historical recurrence evidence. This enables subsequent scheduling decisions to not only focus on high-risk units, but also to conduct in-depth testing along the propagation path, thereby significantly improving the detection efficiency of associated defects.

[0063] Step S206: Update the dynamic coverage data based on feedback and assess the potential of unexecuted test cases.

[0064] The embodiments of the present invention provide specific processes for updating the test adequacy and defect density in dynamic coverage data: The specific process for updating the test sufficiency is as follows: Based on the coverage increment, the first target logical unit and its target branch that are covered in the current test cycle are determined from the software system under test, and the following operations are performed on the first target logical unit: the covered flag corresponding to the first target logical unit is set to true, the branch coverage corresponding to the first target logical unit is updated according to the covered target branch, and the coverage count corresponding to the first target logical unit is incremented by one.

[0065] In practical implementation, within the current test cycle, the system identifies the code region to be newly covered in this test based on the coverage increment data collected by the instrumentation tool, and determines the first target logical unit from it: this unit is any one of the C_new(k) sets that is being tested by this test case. The system first covers or adds a new covered logical unit; further, the system locates the target branch within the unit that was triggered by this execution and was not previously covered. Subsequently, the system performs the following three update operations on the first target logical unit: (1) sets the corresponding "is_covered" field in its dynamic coverage array (DCA) to true to indicate that the logical unit has been covered by at least one execution; (2) updates its "branch_coverage_ratio" field according to the target branch that is newly covered this time: the current value of the field is cumulatively corrected according to the ratio of the actual number of newly added branches to the total number of predefined branches of the logical unit; (3) increments the value of its "hit_count" field by one to record the cumulative number of times the logical unit has been covered.

[0066] The specific process for updating the defect density is as follows: In the event of execution failure or error, based on defect association information, a second target logical unit that caused the execution failure or error is identified from the software system under test, and the defect density corresponding to the second target logical unit is increased; in the event of successful execution, the defect density corresponding to the first target logical unit is decreased.

[0067] In practical implementation, when test cases Execution result When the result is FAIL or ERROR, the system determines one or more second target logical units based on the defect association information F(k). These are the logical units listed in F(k) that are strongly correlated with the failure, as confirmed by stack analysis and spectral analysis. Each such unit is a second target logical unit. The system performs defect density enhancement processing on each second target logical unit: it updates the "defect_density" field corresponding to it in the Dynamic Coverage Array (DCA) with a preset learning rate, making the updated value higher than the original value, thereby increasing the risk weight of the unit in subsequent priority evaluation.

[0068] In practical implementation, when test cases Execution result When the result is PASS, the system performs defect density attenuation processing on any newly covered logical unit among the first target logical units identified in the previous steps: its "defect_density" field is multiplied by an attenuation factor less than 1 to moderately reduce its risk score, reflecting the observation that the unit has not exposed defects in the current execution. This attenuation operation only applies to the newly covered units, and its magnitude is controllable to avoid excessively weakening historically accumulated risk indications.

[0069] The process for assessing the potential of unexecuted use cases is as follows: Based on the dynamic coverage data corresponding to the current testing cycle, determine the test sufficiency normalized value and defect density normalized value for each logical unit in the software system under test; based on the pre-constructed test case-unit association matrix and the test sufficiency normalized value and defect density normalized value for each logical unit, determine the potential evaluation value for each logical unit; adjust the priority of test cases corresponding to unexecuted test cases in the test case set according to the potential evaluation values ​​from high to low.

[0070] The process for determining the normalized values ​​for test adequacy and defect density is as follows: The normalized value of the test adequacy for each logic unit of the system. The determination is made as follows: Based on the `branch_coverage_ratio` and `hit_count` fields already recorded in the Dynamic Coverage Array (DCA) for this unit, a dimensionless value between 0 and 1 is calculated. Here, `branch_coverage_ratio` reflects the degree of completion of branch-level coverage for this unit (0 indicates no branches are covered, 1 indicates all predefined branches are covered), and `hit_count` reflects the frequency with which this unit is triggered for execution. These two values ​​are then weighted and combined to make... The lower the overall value, the more insufficient the current coverage and the more it needs to be supplemented with testing, exhibiting a monotonically decreasing characteristic.

[0071] The system's defect density normalization value for each logic unit The determination process involves using the `defect_density` field stored in the DCA for this unit as a basis, and mapping it to a value between 0 and 1 through linear scaling or piecewise mapping. The mapping rule ensures that the higher the original `defect_density` value, the better the resulting value. The larger the value, the more likely it is to maintain the order relation, i.e., if the unit... The defect_density is greater than the unit The defect_density, then its This normalization process is only used to standardize the units of measurement, facilitating its use in subsequent priority score calculations. Collaborate in weighted calculations.

[0072] In one example, the potential assessment value for each unexecuted test case can be determined using the following formula: ; in, This is a potential assessment value. Test cases in the use case-cell association matrix AND logic unit static correlation strength, To test the sufficiency normalized value, This is the normalized value of the defect density. , These are adjustable weighting coefficients, which can be adaptively adjusted based on factors such as the proportion of executed test cases, the current overall coverage level, or defect discovery trends. They are used to balance the two objectives of "improving coverage" and "finding defects." They can be set at the beginning of testing. It is relatively large, and can be increased later. The formula means that a test case's score depends on its comparison with those currently under-covered ( Low) and high defect risk ( The strength of the association between logical units (high). The stronger the association, the higher the score.

[0073] In another example, the score can be calculated using other functional forms, such as a product, instead of a linear weighted sum: This is to place greater emphasis on targeting units that simultaneously possess both "low coverage" and "high risk" characteristics.

[0074] Step S208: Dynamically sort and select the next test case to be executed.

[0075] All unexecuted use cases calculated based on S206 They are then reordered according to their scores from highest to lowest to form a new priority queue. Then, the highest-scoring test cases are selected (or a batch, for example, the number K determined based on available parallel resources) from the head of the new queue as the execution targets for the next loop (S204).

[0076] Furthermore, it is determined whether the preset priority adjustment conditions are met; wherein the priority adjustment conditions include at least one of the following: the number of continuously executed test cases reaches a preset number threshold, the change in defect density of any logical unit exceeds a preset change threshold, and the time between the current moment and the moment of the previous test case priority adjustment reaches a preset time threshold; if the determination result is yes, the test case priority is adjusted according to the corresponding dynamic coverage data in the current test cycle.

[0077] In specific implementation, the system continuously monitors the preset priority adjustment conditions during test execution. These conditions include at least one of the following: (1) the number of test cases that have been executed continuously since the last test case priority adjustment has reached a preset number threshold; (2) the defect density recorded in the dynamic coverage array (DCA) of any logical unit has changed more than a preset change threshold compared to its last updated value; (3) the time interval between the current moment and the last time the test case priority was adjusted has reached a preset duration threshold. After each test case is executed and feedback processing (i.e., updating the DCA) is completed, the system makes a judgment on the above conditions. If any condition is met, it is determined that the "priority adjustment conditions are met" and the priority reordering process is immediately triggered. At this time, the system recalculates the potential score of all unexecuted test cases based on the latest updated dynamic coverage data in the current test cycle and generates a new priority queue accordingly.

[0078] Step S210: Determine whether test resources are exhausted or all test cases have been executed. If yes, end; otherwise, return to step S204.

[0079] Determine the loop termination condition: whether all test cases have been executed, or whether the preset test time / resources have been exhausted. If not, return to step S204 to continue the closed-loop process of execution, feedback, update, and reordering.

[0080] In summary, the embodiments of the present invention have at least the following characteristics: (i) Enhancing Early Defect Detection Capabilities: The dynamic coverage array continuously tracks the defect density changes of each logical unit and updates the density value in real time based on test execution feedback. When the defect density of a logical unit increases due to test failure, the system immediately increases the scheduling priority of all unexecuted test cases that have strong data or control dependencies on that unit based on preset strong correlations. This allows subsequent testing resources to quickly focus on code areas where risks have become apparent, thus identifying other potential defects within the same risk area at an earlier stage. In contrast, static sorting methods rely on fixed historical statistics or offline analysis results and cannot adjust priorities in real time based on a single test failure event, making it difficult to achieve rapid response and continuous capture of related defects.

[0081] (II) Achieving Dynamic Optimization of Test Resources: This embodiment of the invention establishes a real-time decision-making mechanism oriented towards the current state of the software through a feedback learning closed loop consisting of S204 to S208. The test execution results serve as input to drive the system's cognitive update of the software quality status, thereby triggering iterative adjustments to the test resource allocation strategy. This mechanism ensures that limited resources such as test execution time are always directed to logical units with insufficient coverage or high defect risk, rather than remaining in areas with sufficient coverage and low risk. This improves the effectiveness and relevance of the overall testing process under given test resource constraints.

[0082] (III) Enhanced Adaptability to Software Evolution: The dynamic coverage array supports incremental initialization and online updates, enabling it to naturally respond to various change scenarios throughout the software lifecycle. For example, after new code is committed, the coverage sufficiency of related logical units is initially zero, and the system automatically assigns higher priority to their associated test cases accordingly. For modules that are frequently modified and have a history of frequent defects, their defect density will remain relatively high under continuous test feedback, thus continuously receiving higher test attention. This feature stems from the continuous absorption and modeling of runtime information by the feedback loop, unlike static methods that only rely on a historical snapshot at a certain moment, thus possessing stronger temporal adaptability and version robustness.

[0083] (iv) Providing traceable and interpretable quality situation awareness: The dynamic coverage array records the defect density and coverage status of each logical unit in a structured form at different testing stages, constituting a software quality status sequence that evolves with the testing process. This sequence can be mapped to an intuitive quality heatmap, enabling test managers to clearly identify high-risk areas, weak coverage links, and their dynamic evolution trends. This provides empirical process evidence for test strategy formulation, schedule assessment, and development quality evaluation, overcoming the contextual lack problem caused by traditional methods that rely solely on final coverage summaries and discrete defect lists.

[0084] (v) Reduced reliance on external prior knowledge: The core scheduling logic of this invention is driven by real-time feedback during test execution. Key parameters such as defect density can evolve autonomously through an online learning mechanism, without relying on a complete historical defect database or manually labeled impact range analysis. Even in new projects or new module scenarios lacking historical data, the system can gradually establish a dynamic sorting model that conforms to the current software state after the initial test execution, thereby ensuring the applicability and feasibility of the method in diverse engineering environments.

[0085] Based on the foregoing embodiments, this invention provides a software testing device based on dynamic coverage data and feedback learning. (See also...) Figure 3The diagram shows a software testing device based on dynamic coverage data and feedback learning. The device mainly includes the following parts: The test case determination module 302 is used to determine the test cases to be executed on the software system under test in the current test cycle according to the test case priority corresponding to the test case set. The coverage data update module 304 is used to obtain the dynamic coverage data of the software system under test in the previous test cycle, and update the dynamic coverage data using the test execution feedback information corresponding to the test cases to obtain the dynamic coverage data in the current test cycle. The dynamic coverage data is used to characterize the coverage and defect status of multiple logical units contained in the software system under test in at least one test cycle. The priority adjustment module 306 is used to adjust the priority of test cases according to the dynamic coverage data corresponding to the current test cycle, and enter the next test cycle until the preset test termination conditions are met, so as to obtain the test results of the software system under test.

[0086] The software testing device based on dynamic coverage data and feedback learning provided by this invention updates the dynamic coverage data in real time according to the latest execution feedback in each test cycle, and adjusts the priority of unexecuted test cases accordingly. This ensures that scheduling decisions always focus on key logic units with insufficient coverage, high defect risk, or recent modifications. This mechanism avoids the problem of wasting resources on verified areas in static sorting, significantly improves the number of defects detected per unit of test time and the speed of first discovery, while reducing the number of test execution rounds and total time required to achieve the same defect detection rate. Thus, it improves the overall utilization efficiency of test resources while ensuring quality.

[0087] In one implementation, the software system under test is divided into multiple logical units; Test execution feedback information includes at least the execution result, coverage increment, and defect association information; wherein, the execution result is: execution success, execution failure, or execution error; the coverage increment is used to characterize: at least one logical unit and its branches covered by the test cases executed against the software system under test within the current test cycle; the defect association information is used to characterize: at least one logical unit that caused the execution result to be execution failure or execution error; Dynamic coverage data includes at least test sufficiency and defect density; wherein, test sufficiency is used to characterize: the coverage status of the logical unit in at least one test cycle, including at least the covered identifier, branch coverage rate and coverage count; defect density is used to characterize: the probability that the logical unit will fail or err due to defects in at least one historical test cycle.

[0088] In one implementation, the overlay data update module 304 is specifically used for: Based on the coverage increment, determine the first target logical unit and its target branch that are covered in the current test cycle from the software system under test, and perform the following operations on the first target logical unit: Set the covered flag corresponding to the first target logical unit to true, update the branch coverage rate corresponding to the first target logical unit according to the covered target branch, and increment the coverage count corresponding to the first target logical unit by one.

[0089] In one implementation, the overlay data update module 304 is specifically used for: In the event of execution failure or error, based on defect association information, a second target logical unit that caused the execution failure or error is identified from the software system under test, and the defect density corresponding to the second target logical unit is increased. If the execution is successful, the defect density corresponding to the first target logic unit is attenuated.

[0090] In one implementation, the priority adjustment module 306 is specifically used for: Based on the dynamic coverage data corresponding to the current test cycle, determine the test sufficiency normalized value and defect density normalized value for each logical unit in the software system under test. Based on the pre-constructed use case-unit association matrix, the normalized test sufficiency value and the normalized defect density value corresponding to each logical unit, the potential evaluation value corresponding to each logical unit is determined. The priority of unexecuted test cases in the test case set is adjusted according to the potential assessment value from high to low.

[0091] In one implementation, the use case-unit association matrix is ​​used to characterize the static association strength value between logical units and test cases; the association generation module is used to: Based on historical execution coverage data, the co-occurrence frequency of coverage between logical units and test cases is statistically analyzed. After applying time decay processing to the co-occurrence frequency of coverage, it is normalized to obtain the first association strength value. Based on the code file of the logical unit, the calling relationship between the logical unit and the test case is parsed, and the second association strength value is determined according to the calling relationship; The first association strength value and the second association strength value are merged to generate a static association strength value between the logical unit and the test case.

[0092] In one implementation, the priority adjustment module 306 is further configured to: Determine whether the preset priority adjustment conditions are met; wherein the priority adjustment conditions include at least one of the following: the number of continuously executed test cases reaches a preset number threshold, the change in defect density of any logical unit exceeds a preset change threshold, and the time between the current time and the time of the previous test case priority adjustment reaches a preset time threshold. If the judgment result is yes, the priority of the test cases will be adjusted according to the dynamic coverage data corresponding to the current test cycle.

[0093] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0094] This invention provides an electronic device, specifically, the electronic device includes a processor and a memory; the memory stores a computer program, which, when run by the processor, executes the method described in any of the above embodiments.

[0095] Figure 4 The present invention provides a schematic diagram of the structure of an electronic device 100, which includes a processor 40, a memory 41, a bus 42 and a communication interface 43. The processor 40, the communication interface 43 and the memory 41 are connected through the bus 42. The processor 40 is used to execute executable modules, such as computer programs, stored in the memory 41.

[0096] The memory 41 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 43 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0097] Bus 42 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0098] The memory 41 is used to store programs. After receiving an execution instruction, the processor 40 executes the program. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 40 or implemented by the processor 40.

[0099] Processor 40 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 40 or by instructions in software form. Processor 40 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 41. The processor 40 reads the information in memory 41 and, in conjunction with its hardware, completes the steps of the above method.

[0100] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0101] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A software testing method based on dynamic coverage data and feedback learning, characterized in that, include: Based on the test case priority corresponding to the test case set, determine the test cases to be executed against the software system under test in the current test cycle; The dynamic coverage data of the software system under test in the previous test cycle is obtained, and the dynamic coverage data is updated using the test execution feedback information corresponding to the test case to obtain the dynamic coverage data in the current test cycle. The dynamic coverage data is used to characterize the coverage and defect status of multiple logical units contained in the software system under test in at least one test cycle. The priority of the test cases is adjusted based on the dynamic coverage data corresponding to the current test cycle, and the test cycle continues until the preset test termination condition is met, at which point the test result corresponding to the software system under test is obtained.

2. The software testing method based on dynamic coverage data and feedback learning of claim 1, wherein, The software system under test is divided into multiple logical units; The test execution feedback information includes at least the execution result, coverage increment, and defect association information; wherein, the execution result is: execution success, execution failure, or execution error; the coverage increment is used to characterize: at least one logical unit and its branch covered by the test cases executed against the software system under test within the current test cycle; the defect association information is used to characterize: at least one logical unit that causes the execution result to be the execution failure or the execution error; The dynamic coverage data includes at least test sufficiency and defect density; wherein, the test sufficiency is used to characterize the coverage status of the logic unit in at least one test cycle, including at least the covered identifier, branch coverage rate, and coverage count; the defect density is used to characterize the probability that the logic unit will result in execution failure or execution error due to defects in at least one historical test cycle.

3. The software testing method based on dynamic coverage data and feedback learning of claim 2, wherein, The dynamic coverage data is updated using the test execution feedback information corresponding to the test cases to obtain the dynamic coverage data corresponding to the current test cycle, including: Based on the coverage increment, determine the first target logical unit and its target branch that are covered in the current test cycle from the software system under test, and perform the following operations on the first target logical unit: The covered flag corresponding to the first target logic unit is set to true, the branch coverage rate corresponding to the first target logic unit is updated according to the covered target branch, and the coverage count corresponding to the first target logic unit is incremented by one.

4. The software testing method based on dynamic coverage data and feedback learning of claim 3, wherein, The dynamic coverage data is updated using the test execution feedback information corresponding to the test cases to obtain the dynamic coverage data corresponding to the current test cycle, and the method further includes: In the event of execution failure or execution error, based on the defect association information, a second target logic unit that caused the execution failure or execution error is determined from the software system under test, and the defect density corresponding to the second target logic unit is increased. If the execution is successful, the defect density corresponding to the first target logic unit is attenuated.

5. The software testing method based on dynamic coverage data and feedback learning of claim 2, wherein, Adjusting the priority of the test cases based on the dynamic coverage data corresponding to the current test cycle includes: Based on the dynamic coverage data corresponding to the current test cycle, determine the test sufficiency normalized value and defect density normalized value corresponding to each logical unit in the software system under test; Based on the pre-constructed use case-unit association matrix, the test sufficiency normalized value and defect density normalized value corresponding to each logical unit, the potential evaluation value corresponding to each logical unit is determined; The priority of the test cases corresponding to the unexecuted test cases in the test case set is adjusted according to the potential assessment values ​​from high to low.

6. The software testing method based on dynamic coverage data and feedback learning of claim 5, wherein, The use case-unit association matrix is ​​used to characterize the static association strength value between the logical unit and the test case; the method further includes: Based on historical execution coverage data, the frequency of co-occurrence of coverage between the logical unit and the test case is counted. After applying time decay processing to the frequency of co-occurrence of coverage, it is normalized to obtain the first association strength value. Based on the code file of the logical unit, the calling relationship between the logical unit and the test case is parsed, and a second association strength value is determined according to the calling relationship; The first association strength value and the second association strength value are fused together to generate a static association strength value between the logic unit and the test case.

7. The software testing method based on dynamic coverage data and feedback learning according to claim 2, characterized in that, Before adjusting the test case priority based on the dynamic coverage data corresponding to the current test cycle, the method further includes: Determine whether the preset priority adjustment conditions are met; wherein the priority adjustment conditions include at least one of the following: the number of continuously executed test cases reaches a preset number threshold, the change in the defect density of any logic unit exceeds a preset change threshold, and the duration between the current time and the previous time of adjusting the test case priority reaches a preset duration threshold. If the determination result is yes, then the priority of the test case is adjusted according to the dynamic coverage data corresponding to the current test cycle.

8. A software testing device based on dynamic coverage data and feedback learning, characterized in that, include: The test case determination module is used to determine the test cases to be executed on the software system under test within the current test cycle according to the test case priority corresponding to the test case set. The coverage data update module is used to obtain the dynamic coverage data of the software system under test in the previous test cycle, and update the dynamic coverage data using the test execution feedback information corresponding to the test case to obtain the dynamic coverage data in the current test cycle. The dynamic coverage data is used to characterize the coverage and defect status of multiple logical units contained in the software system under test in at least one test cycle. The priority adjustment module is used to adjust the priority of the test cases according to the dynamic coverage data corresponding to the current test cycle, and enter the next test cycle until the preset test termination condition is met, so as to obtain the test result corresponding to the software system under test.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images