Software quality assessment method based on dependency chain quality conduction

Abstract

The invention discloses a software quality evaluation method based on dependency chain quality conduction, relates to the technical field of software quality evaluation, and is used for solving the problem that quality conduction between software is difficult to quantify. According to the method, the dependency chain graph covering the component dependency relationship, the version pedigree and the quality index is constructed, the evidence reliability label and the license list are combined, the target component and the conduction path which do not meet the quality evaluation threshold value are accurately recognized, the semantic mapping of the target component and the business function domain is constructed, and in the path conduction analysis stage, the quality of the target component is analyzed. A constraint propagation and causal checking mechanism is introduced, influence is transmitted layer by layer, a real path and an interference path are automatically identified, a comprehensive quality measurement item and a quality grade label of a target component are generated, when evaluation is not met, an upgrading, replacing, isolating or rollback scheme is automatically constructed, compatibility, time window and test influence of the scheme are evaluated, and a test result is obtained. And a closed-loop repair path and a treatment guide are output, so that the response efficiency and decision-making reasonability of the software quality problem are improved.

Description

Technical Field

[0001] This invention relates to the field of software quality assessment technology, and more specifically, to a software quality assessment method based on dependency chain quality transmission. Background Technology

[0002] In the software development and delivery process, projects typically rely on multiple third-party components or internal modules to form a complex dependency network. Current software quality assessment methods mostly focus on static indicator checks, compliance scans, or test coverage analysis, attempting to judge overall quality based on the characteristics of the components themselves. These methods often overlook the potential transmission effect of quality defects in the dependency path, as well as the impact of semantic relationships and business coupling between components on the quality results. Especially in software projects with multiple versions and multiple modules, a single point of failure can affect multiple downstream business functional domains through structural paths, thereby triggering systemic quality risks.

[0003] However, existing technologies still have significant shortcomings in dependency chain quality analysis: on the one hand, there is a lack of quality transmission modeling mechanisms oriented towards dependency paths, making it difficult to quantify how defect factors affect target modules through inter-component calls, configurations, and environmental transmission; on the other hand, handling strategies are mostly based on empirical rules, failing to achieve closed-loop optimization by combining the scope of quality impact, compatibility risks, and verification costs. This leads to some deep-seated quality problems erupting in the later stages of system operation, such as critical function failures, rollback difficulties, or integration failures, which cannot be detected and intervened in a timely manner during the evaluation phase, thus severely restricting the controllability and engineering efficiency of quality management in large software systems. Summary of the Invention

[0004] To overcome the aforementioned shortcomings of the prior art, the following solution is proposed to address the difficulty in quantifying the quality transfer between software in the aforementioned background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A software quality assessment method based on dependency chain quality propagation includes the following steps: S1. Construct the project's dependency chain graph and path index, obtain the quality indicators, evidence reliability labels, license list and business scenario parameters of each component, and determine whether the preset quality assessment threshold is met. S2. When the judgment result is not satisfied, determine the relationship between the transmission path and the target component and business functional domain, and extract the triggering evidence and the radius of influence. S3. Based on the relationship and preset business priority, the constraint propagation is adopted and combined with causal verification. The propagation calculation of sequential transmission, stage deduction and threshold triggering is performed along the dependency path to obtain the target component's own quality metric, upstream propagation quality metric and comprehensive quality metric, and generate quality level label and evaluation credibility index. S4. Based on the mapping rules between comprehensive quality metrics and evaluation thresholds, generate software quality evaluation conclusions and evaluation interpretation reports; S5. When the software quality assessment conclusion is unsatisfactory, generate a candidate sequence of actions for upgrading, replacement, isolation, or rollback based on the assessment interpretation report. For each candidate sequence, assess the possibility of compatibility breach, the satisfaction of the business downtime window, and the impact of regression test coverage, and select the target repair path with the lowest cost, and output execution guidelines.

[0006] Furthermore, the specific steps of S1 include: Parse dependency configurations, build manifests, and package manager lock files to generate a directed acyclic graph (DAG) between projects, components, and versions; Record the direct dependency depth, indirect dependency depth, breadth of dependencies, and version hierarchy information at each node; Using the target component as an index, list its upstream paths, assign a unique identifier to each path, and build a sequential relationship table according to the dependency order; Perform signature integrity verification, source credibility verification, and construction reproducibility verification on the components to generate evidence reliability labels and write them into the node metadata; Collect the license list and business scenario parameters and import them into the database; The key quality indicators are compared one by one according to the quality assessment threshold, and a satisfaction label is given. If the quality is not satisfied, a reason for non-satisfaction is generated.

[0007] Furthermore, the specific steps of S2 include: Read the flag indicating the reason for non-compliance, trace back layer by layer from the target component along the path index to the triggering node, and lock the key edge and key node that caused the non-compliance; Record the type, time, and source of the triggering evidence, and bind the record to the corresponding path; List the affected nodes and give the radius of influence based on dependency depth, breadth of dependencies, and cross-module boundaries; Organize the calling relationships, configuration associations, and data dependencies between target components and business functional domains into a relationship diagram; Output a list of transmission paths, a list of influence radii, and the association mapping results between target components and business functional domains.

[0008] Furthermore, the specific steps of S3 include: Using the relationship graph, target priority, compliance constraints, and non-compliance reason markers as inputs for constraint propagation, the feasible range of candidate paths is narrowed down based on the constraints. The influence is propagated in the order of the path. When each edge is reached, the propagation strength of the edge is determined according to the propagation rule table. The influence of the previous node is included in the next node according to the propagation strength, and the reason and source of this propagation are recorded in the node. When version isolation points, interface compatibility change points, or differences in operating environments occur, the deduction amount is given according to the deduction rule table, the corresponding amount is directly deducted from the previous transmission result, and the reason for the deduction is recorded. When the cumulative impact reaches the judgment interval corresponding to the threshold condition, the path impact is included in the target impact; when the cumulative impact does not reach the judgment interval corresponding to the threshold condition, it is not included in the target impact. The results of at least two paths are merged. First, the stability label and impact of each path are compared. The path with the largest impact and the highest stability is selected as the dominant path and merged first. The remaining paths are judged item by item according to the preset merging order and merging conditions. Based on three types of triggering evidence—common source evidence, simultaneous alteration evidence, and mirror fingerprint evidence—we distinguish between genuine transmission and synchronous interference; paths identified as synchronous interference are removed from the candidate set. Output the target component's own quality metrics, upstream transmission quality metrics, and overall quality metrics, and generate quality level labels and evaluation credibility indicators.

[0009] Furthermore, the target component's own quality metrics, upstream transmission quality metrics, and overall quality metrics are output. Specific steps include: The calculation of the target component's own quality metric is based on the target component's key quality indicators and threshold segmentation rules, and the indicators are mapped according to a preset standard to form a single definite value. The upstream transmission quality metric for the target component is calculated using the determined value of the target impact obtained after incorporation as the upstream transmission quality metric. The comprehensive quality metric for the target component is calculated as follows: when the upstream transmission quality metric reaches the risk threshold, the upstream transmission quality metric is used as the comprehensive quality metric; when the upstream transmission quality metric does not reach the risk threshold, its own quality metric is used as the comprehensive quality metric; when both reach the risk threshold, the one with the higher risk level is used as the comprehensive quality metric.

[0010] Furthermore, the specific steps of S4 include: Establish the correspondence between comprehensive quality metrics and grade intervals, and set conclusion judgment conditions in conjunction with the assessment credibility; The software quality assessment conclusion is given as either "satisfied" or "unsatisfied" according to the judgment criteria, and the key factors leading to the conclusion are recorded. A comprehensive assessment and interpretation report will be prepared, which will include the main transmission path, key nodes, summary of triggering evidence, radius of influence, compliance status, and recommended monitoring indicators. The comprehensive quality metrics, quality grade labels, and assessment credibility indicators are archived as a baseline for comparison, and a re-evaluation time window is set for incremental review.

[0011] Furthermore, when the software quality assessment conclusion is unsatisfactory, a candidate sequence of actions—upgrade, replacement, isolation, or rollback—is generated based on the assessment interpretation report. Specific steps include: Read the dominant transmission path, key nodes, compliance status, radius of influence, and the basis for conclusion judgment; For each key node, four types of actions are constructed: upgrade handling, alternative handling, isolation handling and rollback handling, and preconditions and post-verification items are given for each type of action. Arrange actions from near to far according to their dependency order and radius of influence, and establish an ordered sequence of actions that have a sequential dependency relationship according to the order of execution. For each ordered sequence, verify the license terms and corporate strategy, and give a decision on whether it is permitted or not. For each ordered sequence, calculate the preparation time, calculation execution time, and calculation verification time, and list the number of construction steps, deployment steps, and configuration steps involved. Output the set of candidate disposal sequences and their constraints.

[0012] Furthermore, for each candidate sequence, the likelihood of compatibility breach, the satisfaction of the business downtime window, and the impact of regression test coverage are evaluated. The target remediation path with the lowest cost is then selected, and execution guidelines are output. Specific steps include: Calculate the probability of compatibility breaches, compare the interface signature change list, configuration item change list, and backward compatibility declaration, assign a breach level to the incompatible items based on the frequency and location of occurrence, and record the reasons for the level. Calculate the service downtime window satisfaction rate by sequentially accumulating the preparation time, execution time, and verification time in the ordered sequence to obtain the required time window, comparing it item by item with the available service time window, giving a conclusion of whether it is satisfied or not, and recording the insufficient time period. Calculate the impact of regression test coverage, list the set of affected modules, count the number of modules covered by existing regression test cases, give the uncovered percentage, and list the names of the uncovered modules; Provided that compliance constraints and business downtime windows are met, the ordered sequence with the lowest compatibility violation level and the smallest uncovered proportion should be selected as the target repair path; when there are ties, the ordered sequence with the fewest total steps should be selected as the target repair path. Submit the selected target remediation path to the verification environment to generate remediation guidelines.

[0013] Furthermore, the specific steps for submitting the selected target remediation path to the verification environment to generate remediation guidelines include: The target repair path is broken down into a list of steps, and time tags, prerequisites, expected results and rollback trigger conditions are set for each step. In the verification environment, execute the functional test case set, performance baseline test case set, and interface stability test case set, respectively record the number of passes and the number of failures, and record the reasons for failures; When all three conditions are met simultaneously—all functional test cases pass, the performance degradation does not exceed the preset threshold, and the interface remains stable—a pass conclusion is given. When any one condition is not met, a fail conclusion is given, and the candidate disposal sequence is returned for reselection. A handling guide document is created, which includes the sequence of steps, time tags, observation indicators, and rollback trigger conditions.

[0014] The technical effects and advantages of the software quality assessment method based on dependency chain quality transmission in this invention are as follows: This invention constructs a dependency chain graph covering component dependencies, version lineage, and quality indicators. Combined with evidence reliability tags and license lists, it systematically characterizes the quality status and structural relationships of each component in a software project. Relying on sequential path indexing and metadata verification mechanisms, it can accurately identify target components and their propagation paths that do not meet the quality assessment threshold. Furthermore, by combining call relationships, configuration references, and data dependencies, it constructs a semantic mapping between target components and business functional domains, enabling quality failures to be accurately traced to structural trigger points, dependency paths, and business impact boundaries. This establishes a verifiable, locatable, and explainable quality management foundation from the source. In the transmission analysis phase, by introducing a constraint propagation algorithm based on path structure and a causal verification mechanism, the layer-by-layer transmission, deduction, and incorporation of influencing factors on the dependent path are realized. At the same time, a combined judgment logic of stability label, influence weight, and interference identification is established to generate comprehensive quality metrics and quality level labels for the target component. When the evaluation results are not met, it supports the automatic construction of candidate disposal sequences such as upgrade, replacement, isolation, and rollback around key nodes. It also combines the possibility of compatibility breach, the satisfaction of business downtime window, and the impact of regression test coverage to conduct multi-dimensional cost evaluation. Finally, a closed-loop repair path and structured disposal guidelines that can be executed in the verification environment are formed, which significantly improves the response efficiency and decision-making rationality of enterprises when facing quality issues of multi-module and multi-version software. Attached Figure Description

[0015] Figure 1This is a flowchart illustrating a software quality assessment method based on dependency chain quality transmission according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and 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.

[0017] In order to achieve the above objectives, Figure 1 A schematic diagram of the structure of a software quality assessment method based on dependency chain quality transmission according to the present invention is given, which specifically includes the following steps; S1. Construct the project's dependency chain graph and path index, obtain the quality indicators, evidence reliability labels, license list and business scenario parameters of each component, and determine whether the preset quality assessment threshold is met. S2. When the judgment result is not satisfied, determine the relationship between the transmission path and the target component and business functional domain, and extract the triggering evidence and the radius of influence. S3. Based on the relationship and preset business priority, the constraint propagation is adopted and combined with causal verification. The propagation calculation of sequential transmission, stage deduction and threshold triggering is performed along the dependency path to obtain the target component's own quality metric, upstream propagation quality metric and comprehensive quality metric, and generate quality level label and evaluation credibility index. S4. Based on the mapping rules between comprehensive quality metrics and evaluation thresholds, generate software quality evaluation conclusions and evaluation interpretation reports; S5. When the software quality assessment conclusion is unsatisfactory, generate a candidate sequence of actions for upgrading, replacement, isolation, or rollback based on the assessment interpretation report. For each candidate sequence, assess the possibility of compatibility breach, the satisfaction of the business downtime window, and the impact of regression test coverage, and select the target repair path with the lowest cost, and output execution guidelines.

[0018] S1. Construct the project's dependency chain graph and path index, obtain the quality indicators, evidence reliability labels, license list, and business scenario parameters for each component, and determine whether they meet the preset quality assessment threshold. The specific implementation is as follows: This embodiment runs on a software engineering server used for building and analysis. First, it reads the dependency configuration, build manifest and package manager lock file, and generates a directed acyclic graph based on the dependency relationships between projects, components and versions recorded in the file, which is denoted as the dependency chain graph. The project itself is used as the root node. A unique node identifier is created for each component, and the direct dependency depth, indirect dependency depth, breadth of dependencies, and version lineage information are recorded on the node. The direct dependency depth is recorded as follows: if there is a dependency edge of length one between the project node and the component node, it is recorded as one; otherwise, it is recorded as zero. The recording method that indirectly depends on depth is: When the shortest dependency path length from the project node to the component node is greater than one, it is recorded as the shortest dependency path length; otherwise, it is recorded as zero. The method for recording the breadth of dependencies is as follows: count the number of outgoing edges with this component as the upstream endpoint and record the number in the component node; the method for recording version lineage information is as follows: write the major version number, minor version number, revision number and release time of this component into the version lineage field of this component node in sequence; Subsequently, the upstream paths of the target component are listed using the target component as an index. The path enumeration follows a simple path rule of non-repeating nodes. A unique identifier is assigned to each path. The method for generating the unique identifier is to connect the project node identifier, the sequence number of each node in the path, and the target component identifier in a fixed order to form a character sequence. The relationship table between this character sequence and the node order is registered in the path index. After the path index is established, signature integrity verification, source credibility verification, and build reproducibility verification are performed on each component. The signature integrity verification method is to verify the digital signature of the component release package and record the verification result. The source credibility verification method is to verify the binding relationship between the publisher's identity and the registered public key and record the verification result. The build reproducibility verification method is to rebuild the product in an independent build environment using the same source code and build script and compare the consistency of the product hash value and record the verification result.

[0019] Evidence reliability labels are generated based on the three verification conclusions. The method for determining the labels is as follows: When all three verification conclusions are passed, the evidence reliability label is recorded as high. When the signature integrity verification and source credibility verification are passed but the construction reproducibility verification is failed, the evidence reliability label is recorded as medium. When either the signature integrity verification or the source credibility verification fails, the evidence reliability label is recorded as low. At the same time, a license list is collected and bound to the component node, and business scenario parameters are collected and stored in the database. The business scenario parameters include deployment scale, business criticality level, and allowed downtime window. The three parameters are recorded as scale value, level value, and time length, respectively.

[0020] After the above data preparation is completed, the key quality indicators of each component are obtained, and each component is compared with the quality assessment threshold to form a satisfaction label or a non-satisfaction reason mark. The key quality indicators include defect event frequency, maintenance response latency, test coverage and compatibility violation records. The defect event frequency is obtained by counting the number of confirmed defect events in a preset observation window and comparing the number with the upper limit of the defect event frequency threshold. When the number of items is not greater than the upper limit of the threshold, the defect event frequency is judged to be satisfactory; otherwise, it is judged to be unsatisfactory.

[0021] The method for obtaining maintenance response latency is as follows: For each issue created within the preset observation window, the natural daily difference between the first response time and the creation time is taken. All the natural daily differences of all issue issues are sorted according to a fixed rule, and the median is taken. This median is then compared with the upper limit of the maintenance response latency threshold. If the median is not greater than the upper limit of the threshold, the maintenance response latency is determined to be satisfied; otherwise, it is determined to be unsatisfactory.

[0022] The test coverage is obtained by reading the row coverage value in the build report and comparing it with the lower limit of the test coverage threshold. If the row coverage value is not less than the lower limit of the threshold, the test coverage is considered to be satisfied; otherwise, it is considered not satisfied. The method for obtaining compatibility violation records is as follows: Count the number of destructive change entries within a preset observation window and compare this number with the upper limit of the compatibility violation record threshold. If the number of entries is not greater than the upper limit, the compatibility violation record is considered satisfactory; otherwise, it is considered unsatisfactory. For each component, the four key quality indicators are compared in the above order. When all four key quality indicators are satisfied, the evidence reliability label is high, and the license list does not contain any entries that conflict with the business strategy, a satisfaction label is generated as satisfied. When any key quality indicator is unsatisfactory, or the evidence reliability label is medium or low, or the license list contains any entries that conflict with the business strategy, a satisfaction label is generated as unsatisfactory, and a reason for unsatisfactory is generated.

[0023] The non-compliance reason marker includes the name of the triggering key quality indicator, the direction of the triggering comparison, the actual value of the comparison, the corresponding threshold, the value of the evidence reliability label, the identifier of the conflict item in the license list, the unique identifier of the impact path, and the recording time. After completing the above processing, the dependency chain graph, path index, evidence reliability label, license list, business scenario parameters, satisfaction label and non-compliance reason marker are output to determine the propagation path and perform propagation calculation and software quality assessment conclusion generation.

[0024] S2. When the judgment result is not satisfied, determine the correlation between the transmission path and the target component and business function domain, extract the triggering evidence and the radius of influence, and implement it as follows: After obtaining the non-satisfaction reason markers (where satisfaction is not met), the target component identifier and the triggering key quality indicator name are read from the non-satisfaction reason markers. Based on the path index, backtracking is performed layer by layer upwards from the target component. During backtracking, upstream nodes and dependent edges in the path are visited sequentially according to the order relationship table. When a node or dependent edge that first causes the non-satisfaction reason marker to be valid is encountered, that node is recorded as the triggering node, and that dependent edge is recorded as the key edge. When multiple paths exist, backtracking is completed separately for each path, and the triggering node and key edge are recorded for each path.

[0025] Subsequently, triggering evidence was established, categorized into five types: common source evidence, simultaneous change evidence, mirror fingerprint evidence, vulnerability notification evidence, and license conflict evidence. Common source evidence was recorded by verifying in version control that the same commit record simultaneously affected both upstream nodes and target components, and recording the commit identifier. Simultaneous change evidence was recorded by verifying in the build pipeline log that the same build batch caused version updates to upstream nodes and target components, and recording the batch number. Mirror fingerprint evidence was recorded by comparing the base mirror fingerprint used by upstream nodes and target components in the artifact repository and recording the fingerprint value. Vulnerability notification evidence was recorded by retrieving the notification number matched by the upstream node in the vulnerability notification database and recording the number. License conflict evidence was recorded by retrieving entries that conflicted with enterprise policies from the license list verification results and recording the entry identifier. Each piece of evidence recorded three fields: category, occurrence time, and source. The occurrence time was recorded using server time, and the source was recorded using a corresponding unique identifier. The evidence record was then bound to the unique identifier of the corresponding path.

[0026] After identifying the triggering node and key edge, the list of affected nodes and the radius of influence are compiled based on the dependency chain graph. The process of listing the affected nodes is as follows: For each determined path, select all nodes from the trigger node to the target component and add them to the list of affected nodes in sequence. When there are multiple paths, merge the nodes obtained from each path one by one and remove duplicate nodes.

[0027] The method for determining the radius of influence involves simultaneously recording three defined quantities: first, the hierarchical span, which is determined by counting and recording the number of dependency edges from the triggering node to the target component; second, the number of affected nodes, which is determined by counting and recording the number of node entries in the list of affected nodes; and third, the number of cross-module boundaries, which is determined by counting and recording the number of dependency edges that cross module ownership changes on the path from the triggering node to the target component based on the module ownership field in the component metadata.

[0028] After completing the above statistics, a list of transmission paths is generated. Each entry includes three items: a unique path identifier, a triggering node, a critical edge, a list of affected nodes, and an influence radius.

[0029] Establish the association between target components and business functional domains, and construct an association graph according to three types of relationships: call relationship, configuration association, and data dependency. The call relationship is obtained by performing static call scanning on the source code and verifying the call points of services and interfaces in conjunction with service registration information. Calls initiated by the target component to external entities and calls received from external entities are recorded as directed edges. The configuration association is obtained by parsing the reference relationship between the target component and other components for the same configuration item in the configuration center record. The relationship between components sharing configuration items is recorded as undirected edges. The data dependency is obtained by counting the target component's access to and subscription to tables, views, topics, and queues in the database access list and message queue subscription list. The relationship between components that have read / write or subscription / publish relationships through the same data object is recorded as directed edges.

[0030] The three relationships are merged into a single relationship graph, and component identifiers and business function domain identifiers are labeled on the nodes of the graph. The business function domain identifiers are derived from the business criticality level and function domain division table in the business scenario parameters. The final output includes a list of transmission paths, a list of influence radii, and the association mapping results between target components and business function domains.

[0031] For example, during the development of an enterprise-level data analysis platform, the R&D team discovered from the dependency graph that after the dependency component com.example.json-serializer of the statistical analysis module in a certain version was updated, the report module in the business function domain became abnormal, and users reported that the exported report fields were missing. It was determined that the overall quality metric of the report module was lower than the preset threshold. Proceeding to step S2, based on the non-compliance reason flag of the report module, backtrack along the dependency path to identify that the version of com.example.json-serializer has been upgraded to 3.1.4, and mark this version as a critical node. The identified critical edge is the direct dependency relationship between the report module and it. The triggering evidence is the inconsistent build fingerprint and configuration signature verification failure in the change record. The time record is the submission date of June 3, 2024, and the source is the build pipeline version control. Based on the component's dependency depth of 2 (meaning it depends on the component directly once and then on the intermediate nodes), its dependency breadth of 4 (meaning it is depended on by 4 business modules), its module boundary crossing of 1 (involving the reporting module and the export module), and its influence radius of medium level, a relationship graph was then established between the reporting module and the statistics module, including their call relationships, dependency configurations, and data input / output path information.

[0032] S3. Based on the relationships and preset business priorities, constraint propagation is adopted, combined with causal verification, to perform sequential propagation, stage deduction, and threshold triggering propagation calculations along the dependency path. This yields the target component's own quality metrics, upstream propagation quality metrics, and comprehensive quality metrics, and generates quality level labels and evaluation credibility indicators. The specific implementation is as follows: After obtaining the list of transmission paths, the list of influence radii, and the association mapping results between target components and business functional domains, the association graph, target priority, compliance constraints, and non-compliance reason markers are used as inputs for constraint propagation. First, the list of transmission paths is filtered according to compliance constraints and target priority, eliminating paths with license conflicts that cannot be resolved by alternative licenses, and the remaining paths are recorded as a candidate path set. A cumulative impact record is established for each path in the candidate path set and initialized to zero. Then, each dependency edge is processed sequentially from upstream to the target component according to the order relationship table: when the current dependency edge is reached, the transmission strength of the dependency edge is calculated according to the transmission rule table.

[0033] The method for determining the propagation rule table is to publicly disclose the correspondence between edge types and impact propagation in the specification and provide a deterministic source of values. Edge types include three types: version inheritance edges, function call edges, and runtime environment dependency edges. The propagation strength of version inheritance edges is jointly determined by the indirect dependency depth and the breadth of the dependent edge. The greater the indirect dependency depth, the lower the propagation strength by a fixed decreasing margin; the greater the breadth of the dependent edge, the higher the propagation strength by a fixed increasing margin. The propagation strength of function call edges is jointly determined by the call direction and call stability. When the call direction is from upstream to downstream, a positive impact is included. Call stability is converted from the frequency of call change records to a stability level and then mapped to a fixed value. The propagation strength of runtime environment dependency edges is determined by the runtime environment difference identifier. The same runtime environment is included in the baseline value, and different runtime environments are included in the deducted value. The impact of the previous node is converted into the impact contribution of the dependency edge according to the propagation strength of the dependency edge, written into the cumulative impact record of the path, and the reason and source of this propagation are recorded in the node metadata. If a version isolation point, interface compatibility change point, or runtime environment difference point is detected at the current node, the deduction amount is calculated according to the deduction rule table, and the corresponding amount is directly deducted from the cumulative impact record of the path. At the same time, the reason for the deduction is recorded. After the sequential transmission of all dependent edges on the path is completed, the cumulative impact record of the path is compared with the judgment interval corresponding to the threshold condition. When the cumulative impact record enters the judgment interval, the path is marked as valid and merged. When the cumulative impact record does not enter the judgment interval, the path is marked as invalid and merged, and is not included in the target impact.

[0034] When there are at least two paths marked as valid to be merged in the candidate path set, multi-path merging is performed. First, a stability label is generated for each valid merged path. The stability label is determined by verifying the consistency of common source evidence, simultaneous change evidence and mirror fingerprint evidence. Paths that satisfy all three types of evidence are labeled as high, paths that satisfy two types of evidence are labeled as medium, and paths that satisfy one type of evidence are labeled as low. When there is evidence of a vulnerability notification and it matches the trigger node of the path, the stability label is increased by one level. When there is evidence of a license conflict and the conflicting entry has not yet obtained an alternative license, the stability label is decreased by one level. Then, the cumulative impact record and stability label of each path are compared. The path with the largest cumulative impact record and the highest stability label is selected as the dominant path, and the cumulative impact record of the dominant path is written into the initial value of the target impact. The remaining paths are judged one by one according to the preset merging order and merging conditions. The preset merging conditions are that there are no mutually exclusive version isolation points between the path and the dominant path in the node sequence, and the stability label of the path is not lower than medium. When the merging conditions are met, the cumulative impact record of the path is written into the remaining part of the target impact according to the merging rules, following the rule of not overwriting the part already written in the dominant path. When the merging conditions are not met, the target impact is not written, and the reason is noted in the record.

[0035] To distinguish between true conduction and synchronous interference, causal verification is performed on all paths marked as valid incorporation: when at least two types of evidence—common source evidence, simultaneous alteration evidence, and mirror fingerprint evidence—can form a matching closed loop with the triggering node and the target component, the path is identified as true conduction; when a matching closed loop cannot be formed, the path is identified as synchronous interference and is removed from the candidate set. The final target impact is the deterministic impact value of the retained path after incorporation. This deterministic impact value is used to subsequently calculate the upstream conduction quality metric of the target component.

[0036] After obtaining the target impact, the self-quality metrics of the target component, the upstream transmission quality metrics of the target component, and the comprehensive quality metrics of the target component are calculated sequentially. The steps for calculating the self-quality metrics of the target component are as follows: read the four key quality indicators collected in step S1, namely, defect event frequency, maintenance response latency, test coverage, and compatibility violation records. According to the threshold segmentation rules and preset caliber, the four key quality indicators are mapped to a single definite value. During mapping, indicators not exceeding the threshold are considered as qualified contributions, and indicators exceeding the threshold are considered as risky contributions. The mapping source is recorded in the mapping table. After summarizing the various contributions in a fixed order, the single definite value of the self-quality metric is confirmed. The process of calculating the upstream transmission quality metric of the target component uses the deterministic impact value of the target impact obtained after incorporation as the upstream transmission quality metric. The process of calculating the comprehensive quality metric of the target component is as follows: when the upstream transmission quality metric reaches the risk threshold, the upstream transmission quality metric is used as the comprehensive quality metric; when the upstream transmission quality metric does not reach the risk threshold, its own quality metric is used as the comprehensive quality metric; when the upstream transmission quality metric and its own quality metric both reach their respective risk thresholds, the one with the higher risk level is used as the comprehensive quality metric.

[0037] Quality level labels are generated based on the correspondence between comprehensive quality metrics and level intervals. Each quality level label includes six components: level code, level interval, dominant transmission path identifier, key node list, compliance status, and reassessment time window. Simultaneously, assessment credibility indicators are generated, comprising five components: indicator coverage, evidence reliability strength, transmission interpretation completeness, result stability, and causal verification pass rate. Indicator coverage is recorded as the ratio of the number of collected key quality indicators to the number of indicators that should have been collected; evidence reliability strength is recorded as the ratio of the number of verified items from the three evidence categories to the total number of the three categories; transmission interpretation completeness is recorded as the number of items included in the triggering evidence, node sequence, and influence radius; result stability is recorded as the ratio of the number of times the assessment conclusions are consistent within the reassessment time window to the number of reassessments; and causal verification pass rate is recorded as the ratio of the number of verified evidence items to the number of evidence items participating in the verification.

[0038] After the above calculations are completed, the following are output: the target component's own quality metric, the target component's upstream transmission quality metric, the target component's comprehensive quality metric, quality grade label, and evaluation credibility index.

[0039] S4. Based on the mapping rules between comprehensive quality metrics and evaluation thresholds, generate software quality evaluation conclusions and an evaluation interpretation report. The specific implementation is as follows: When forming the criteria for conclusions, the grade range of the comprehensive quality metric is jointly determined with the five indicators in the assessment credibility index. The determination process is as follows: After obtaining the target component's own quality metrics, upstream transmission quality metrics, comprehensive quality metrics, quality level labels, and assessment credibility indicators, the first step is to establish the correspondence between the comprehensive quality metrics and level intervals and solidify it into a level interval table. Before deployment, the level interval table is determined offline and written into the configuration items, set as four non-overlapping closed intervals: low-risk interval, medium-risk interval, high-risk interval, and extremely high-risk interval. Each interval is represented by a lower and upper bound value, and the defined values ​​are given in the configuration.

[0040] When formulating conclusion criteria, the grade range of the comprehensive quality metric item is jointly determined with the five indicators in the assessment credibility index. The determination process is as follows: When the comprehensive quality metric falls into the low-risk range, and the indicator coverage is not less than 90%, the evidence reliability strength is equal to 1, the transmission explanation completeness includes three items: triggering evidence, node sequence, and radius of influence, the result stability is not less than 80%, and the causal verification pass rate is not less than 2 / 3, the software quality assessment conclusion is given as satisfactory; when the comprehensive quality metric falls into the medium-risk range, and the indicator coverage is not less than 95%, the evidence reliability strength is equal to 1, the transmission explanation completeness includes three items, the result stability is not less than 85%, and the causal verification pass rate is not less than 3 / 4, the software quality assessment conclusion is given as satisfactory. When the comprehensive quality metric falls into the high-risk or very high-risk range, the software quality assessment conclusion is "not satisfied"; when the comprehensive quality metric falls into the low-risk or medium-risk range and any assessment credibility index fails to reach the corresponding threshold, the software quality assessment conclusion is "not satisfied".

[0041] After generating the software quality assessment conclusion, record the key factors leading to the conclusion. These key factors include the grade range of the comprehensive quality metric, the name of the assessment credibility indicator that did not reach the threshold and its actual value, the identifier of the dominant transmission path, and a list of key nodes. These records are written into the assessment results storage using structured fields.

[0042] When generating the assessment and interpretation report, fill in the main transmission path, key nodes, triggering evidence summary, radius of influence, compliance status, and recommended monitoring indicators item by item using the report template.

[0043] The dominant transmission path should be filled in with a definite dominant transmission path identifier and a list of the sequence numbers of the nodes in the path; The key nodes should be filled in with the names and sequence numbers of each node in the key node list; The trigger evidence summary should be filled in as an ordered list of the three fields: evidence category, time of occurrence, and source. The radius of influence should be filled in with three determined quantities: hierarchical span, number of affected nodes, and number of cross-module boundaries. The compliance status should be entered as "compliant" or "non-compliant" in the license list verification conclusion. It is recommended that the monitoring indicators be filled in as key quality indicators and evidence items that require continuous monitoring, including six items: frequency of defect events, maintenance response time, test coverage, compatibility violation records, changes in evidence reliability labels and conflict items in the license list. The report should also provide the data collection source and review cycle for each item.

[0044] Subsequently, the comprehensive quality metrics, quality grade labels, and assessment credibility indicators are archived as a baseline. The baseline record includes the generation time, applicable target component identifiers, and version lineage information. The review time window is set based on the quality grade labels and assessment credibility indicators: when the quality grade label is low risk and the result stability is not less than 90%, the review time window is set to 30 days; when the quality grade label is medium risk or the result stability is between 80% and 90%, the review time window is set to 10 days; when the quality grade label is high risk or very high risk, the review time window is set to 3 days. When the review time window expires, an incremental review is triggered. The incremental review uses the baseline as a reference to check the changes in the comprehensive quality metrics, quality grade labels, and assessment credibility indicators item by item, and the reasons for the changes are written into a new assessment explanation report.

[0045] S5. When the software quality assessment conclusion is unsatisfactory, a candidate sequence of actions—upgrade, replacement, isolation, or rollback—is generated based on the assessment interpretation report. For each candidate sequence, the likelihood of compatibility breach, the satisfaction of the business downtime window, and the impact of regression test coverage are assessed. The target remediation path with the lowest cost is selected, and execution guidelines are output. Specifically, the implementation is as follows: When the software quality assessment conclusion is "not met," the dominant transmission path, key nodes, compliance status, impact radius, and conclusion judgment basis in the assessment interpretation report are read. Four types of actions are constructed around each key node: upgrade handling, replacement handling, isolation handling, and rollback handling. Preconditions and post-verification items are set for each type of action. The precondition for upgrade handling is the existence of a released patch version upstream with license terms consistent with the enterprise policy. The post-verification item is the consistency between the signature integrity and source credibility verification of the upgraded build artifact. The precondition for replacement handling is the existence of a replacement component that meets the functional contract and license terms. The post-verification item is the consistency between the interface signature and configuration items after replacement. The precondition for isolation handling is the existence of a verifiable runtime isolation strategy and deployment boundary. The post-verification item is that the call path does not cross the isolation boundary after isolation. The precondition for rollback handling is the existence of an archived previous stable version. The post-verification item is that the version lineage information after rollback is consistent with the archived records.

[0046] The four types of actions under the same key node are arranged according to the principle of eliminating the influence of the near end first and then the influence of the far end. That is, an ordered sequence is established from near to far according to the dependency order and the influence radius. When there is a sequential dependency relationship between the same key node, the preceding action is executed first and then the following action is executed.

[0047] For each ordered sequence, verify the license terms and corporate policies, and give a judgment of whether it is allowed or not. For ordered sequences that are judged to be allowed, calculate the preparation time, execution time, and verification time for each one. The sources of the three times are the construction pipeline time statistics, deployment pipeline time statistics, and regression test case execution time statistics, respectively. At the same time, list the number of construction steps, deployment steps, and configuration steps involved in the ordered sequence to form a set of candidate disposal sequences and their constraint descriptions.

[0048] Three assessments are conducted on each candidate disposal sequence. The first assessment is the compatibility violation probability assessment: the interface signature change list, configuration item change list, and backward compatibility declaration are read, and the interface signature and configuration item after the ordered sequence is executed are compared to see if they are consistent with the calling contract of the target component. For any inconsistencies, the violation level is given according to the frequency of occurrence and the location. The location is determined by whether the inconsistency is located in an external public interface or an internal calling interface. Inconsistencies in external public interfaces have a higher violation level than those in internal calling interfaces. The cause of each violation level is recorded and summarized into the compatibility violation probability conclusion of the ordered sequence. The second item is the evaluation of the satisfaction of the business downtime window: the preparation time, execution time and verification time of the ordered sequence are added in order to obtain the required time window, and then compared with the business available time window in the business scenario parameters item by item. When the required time window is not greater than the business available time window, a satisfaction conclusion is given; when the required time window is greater than the business available time window, a dissatisfaction conclusion is given and the start and end times of the insufficient period are recorded. The third item is the regression test coverage impact assessment: Based on the association mapping results and influence radius between the target component and the business functional domain, list the set of affected modules, count the number of affected modules covered by the existing regression test cases and the total number of affected modules, give the non-coverage ratio by dividing the number of non-covered affected modules by the total number of affected modules, and list the names of the non-covered modules.

[0049] After completing the three assessments, and provided that compliance constraints and business downtime windows are met, the ordered sequence with the lowest compatibility violation level and the smallest non-coverage ratio is selected as the target repair path. When there are ties, the ordered sequence with the fewest total steps is selected as the target repair path. The reasons for abandoning the ordered sequence that is not selected are recorded. The reasons for abandonment include at least one of the following three categories: highest violation level, largest non-coverage ratio, or most steps.

[0050] The selected target remediation path is submitted to a verification environment that does not affect the live network and verification is carried out. Before verification, the target remediation path is broken down into a step list, and time tags, preconditions, expected results, and rollback trigger conditions are set for each step. The execution order is from earliest to latest time tag. For each step, the functional test case set, performance baseline test case set, and interface stability test case set are run in the verification environment. The number of passes and failures are recorded respectively, and the reason for each failure is recorded. The pass criterion for the functional test case set is that all functional test cases pass; the pass criterion for the performance baseline test case set is that the decline in key performance indicators does not exceed the preset threshold; the pass criterion for the interface stability test case set is that the results of external public interface calls are consistent with the expected results, and the results of internal interface calls are consistent with the expected results. When all three criteria are met, a pass conclusion is given. When any criterion is not met, a fail conclusion is given, and the candidate disposal sequence set is returned to select a new target remediation path. At the same time, the reason for this failure is written into the abandonment reason record.

[0051] Upon successful verification, a handling guide document is generated. This document uses a structured template and includes four parts: step sequence, time stamps, observation metrics, and rollback trigger conditions. The step sequence lists the specific operations in the execution order of the target remediation path. The time stamps indicate the start time and maximum allowed duration of each step. Observation metrics include the results of the build artifact signature integrity verification, source credibility verification, build artifact hash consistency, service availability metrics, interface success rate metrics, and key performance metrics. Rollback trigger conditions include any of the following: the first failure of a functional use case, a drop in key performance metrics exceeding a preset threshold, an interface success rate falling below a preset threshold, and any non-compliant item appearing in the license verification results.

[0052] Once the handling guidelines document is generated, it will be archived together with the selected target remediation path. The archived content includes version lineage information, dominant transmission path identifiers, a list of key nodes, and the verification evidence for this purpose, so as to facilitate audit tracing and review.

[0053] For example, during continuous integration on the same platform, the development team's evaluation of the com.example.parser-core component found that its comprehensive quality metric had reached a high-risk level. Based on the dominant transmission path, key nodes, and radius of influence provided in the evaluation interpretation report, the team constructed three candidate disposal paths: upgrading parser-core to 5.2.0, replacing it with the open-source component fast-parser, and rolling back to the original version 4.8.7. The platform calculates the results for each of the three processing paths: Possible compatibility breaches: In the upgrade path, the parser-core 5.2.0 configuration items have been changed to 7 items, and the interface signature has been adjusted to 3 items, which is considered a medium level of breach; in the replacement path, there are 9 interface differences, which is considered a high level of breach; in the rollback path, there are no breaches, which is considered a low level of breach.

[0054] Service downtime window satisfaction: The preparation time, execution time, and verification time for the three paths are as follows: upgrade path 6 hours, execution time 2 hours, and verification time 2 hours, totaling 10 hours; replacement path totaling 18 hours; rollback path totaling 6 hours. The current service availability window is 12 hours, therefore all three are satisfied.

[0055] Regression test coverage impact: The replacement path affects 7 modules, with existing test cases covering 5 modules, resulting in an uncovered rate of 28.6%; the upgrade path has an uncovered rate of 14.3%; and the rollback path has an uncovered rate of 0%.

[0056] Based on the compatibility violation level, the percentage of regressions not covered, and the total number of steps, the rollback path is selected as the target repair path and submitted to the verification environment to trigger the handling verification process.

[0057] It should be noted that the threshold information in this embodiment was set in advance by professionals and will not be explained in detail here. Some parameters in the embodiment may have the same English letters, but they are explained with different meanings when used, and will not be explained one by one here.

[0058] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0059] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0060] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0061] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A software quality assessment method based on dependency chain quality propagation, characterized in that: The specific steps include: S1. Construct the project's dependency chain graph and path index, obtain the quality indicators, evidence reliability labels, license list and business scenario parameters of each component, and determine whether the preset quality assessment threshold is met. S2. When the judgment result is not satisfied, determine the relationship between the transmission path and the target component and business functional domain, and extract the triggering evidence and the radius of influence. S3. Based on the relationship and preset business priority, the constraint propagation is adopted and combined with causal verification. The propagation calculation of sequential transmission, stage deduction and threshold triggering is performed along the dependency path to obtain the target component's own quality metric, upstream propagation quality metric and comprehensive quality metric, and generate quality level label and evaluation credibility index. S4. Based on the mapping rules between comprehensive quality metrics and evaluation thresholds, generate software quality evaluation conclusions and evaluation interpretation reports; S5. When the software quality assessment conclusion is unsatisfactory, generate a candidate sequence of actions for upgrading, replacement, isolation, or rollback based on the assessment interpretation report. For each candidate sequence, assess the possibility of compatibility breach, the satisfaction of the business downtime window, and the impact of regression test coverage, and select the target repair path with the lowest cost, and output execution guidelines.

2. The software quality assessment method based on dependency chain quality propagation according to claim 1, characterized in that: The specific steps of S1 include: Parse dependency configurations, build manifests, and package manager lock files to generate a directed acyclic graph (DAG) between projects, components, and versions; Record the direct dependency depth, indirect dependency depth, breadth of dependencies, and version hierarchy information at each node; Using the target component as an index, list its upstream paths, assign a unique identifier to each path, and build a sequential relationship table according to the dependency order; Perform signature integrity verification, source credibility verification, and construction reproducibility verification on the components to generate evidence reliability labels and write them into the node metadata; Collect the license list and business scenario parameters and import them into the database; The key quality indicators are compared one by one according to the quality assessment threshold, and a satisfaction label is given. If the quality is not satisfied, a reason for non-satisfaction is generated.

3. The software quality assessment method based on dependency chain quality propagation according to claim 1, characterized in that: The specific steps of S2 include: Read the flag indicating the reason for non-compliance, trace back layer by layer from the target component along the path index to the triggering node, and lock the key edge and key node that caused the non-compliance; Record the type, time, and source of the triggering evidence, and bind the record to the corresponding path; List the affected nodes and give the radius of influence based on dependency depth, breadth of dependencies, and cross-module boundaries; Organize the calling relationships, configuration associations, and data dependencies between target components and business functional domains into a relationship diagram; Output a list of transmission paths, a list of influence radii, and the association mapping results between target components and business functional domains.

4. The software quality assessment method based on dependency chain quality propagation according to claim 1, characterized in that: The specific steps of S3 include: Using the relationship graph, target priority, compliance constraints, and non-compliance reason markers as inputs for constraint propagation, the feasible range of candidate paths is narrowed down based on the constraints. The influence is propagated in the order of the path. When each edge is reached, the propagation strength of the edge is determined according to the propagation rule table. The influence of the previous node is included in the next node according to the propagation strength. The reason and source of this propagation are recorded in the node. When version isolation points, interface compatibility change points, or differences in operating environments occur, the deduction amount is given according to the deduction rule table, the corresponding amount is directly deducted from the previous transmission result, and the reason for the deduction is recorded. When the cumulative impact reaches the judgment interval corresponding to the threshold condition, the path impact is included in the target impact; when the cumulative impact does not reach the judgment interval corresponding to the threshold condition, it is not included in the target impact. The results of at least two paths are merged. First, the stability label and impact of each path are compared. The path with the largest impact and the highest stability is selected as the dominant path and merged first. The remaining paths are judged item by item according to the preset merging order and merging conditions. Based on three types of triggering evidence—common source evidence, simultaneous alteration evidence, and mirror fingerprint evidence—we distinguish between genuine transmission and synchronous interference; paths identified as synchronous interference are removed from the candidate set. Output the target component's own quality metrics, upstream transmission quality metrics, and overall quality metrics, and generate quality level labels and evaluation credibility indicators.

5. The software quality assessment method based on dependency chain quality propagation according to claim 4, characterized in that: The output includes the target component's own quality metrics, upstream transmission quality metrics, and overall quality metrics. Specific steps include: The calculation of the target component's own quality metric is based on the target component's key quality indicators and threshold segmentation rules, and the indicators are mapped according to a preset standard to form a single definite value. The upstream transmission quality metric for the target component is calculated using the determined value of the target impact obtained after incorporation as the upstream transmission quality metric. The comprehensive quality metric for the target component is calculated as follows: when the upstream transmission quality metric reaches the risk threshold, the upstream transmission quality metric is used as the comprehensive quality metric; when the upstream transmission quality metric does not reach the risk threshold, its own quality metric is used as the comprehensive quality metric; when both reach the risk threshold, the one with the higher risk level is used as the comprehensive quality metric.

6. The software quality assessment method based on dependency chain quality propagation according to claim 1, characterized in that: The specific steps of S4 include: Establish the correspondence between comprehensive quality metrics and grade intervals, and set conclusion judgment conditions in conjunction with the assessment credibility; The software quality assessment conclusion is given as either "satisfied" or "unsatisfied" according to the judgment criteria, and the key factors leading to the conclusion are recorded. A comprehensive assessment and interpretation report will be prepared, which will include the main transmission path, key nodes, summary of triggering evidence, radius of influence, compliance status, and recommended monitoring indicators. The comprehensive quality metrics, quality grade labels, and assessment credibility indicators are archived as a baseline for comparison, and a re-evaluation time window is set for incremental review.

7. The software quality assessment method based on dependency chain quality propagation according to claim 1, characterized in that: When the software quality assessment conclusion is unsatisfactory, a candidate sequence of actions—upgrade, replacement, isolation, or rollback—is generated based on the assessment interpretation report. Specific steps include: Read the dominant transmission path, key nodes, compliance status, radius of influence, and the basis for conclusion judgment; For each key node, four types of actions are constructed: upgrade handling, alternative handling, isolation handling and rollback handling, and preconditions and post-verification items are given for each type of action. Arrange actions from near to far according to their dependency order and radius of influence, and establish an ordered sequence of actions that have a sequential dependency relationship according to the order of execution. For each ordered sequence, verify the license terms and corporate strategy, and give a decision on whether it is permitted or not. For each ordered sequence, calculate the preparation time, calculation execution time, and calculation verification time, and list the number of construction steps, deployment steps, and configuration steps involved. Output the set of candidate disposal sequences and their constraints.

8. The software quality assessment method based on dependency chain quality propagation according to claim 1, characterized in that: For each candidate sequence, assess the likelihood of compatibility breach, the satisfaction of the business downtime window, and the impact of regression test coverage, and select the target remediation path with the lowest cost, outputting execution guidelines. Specific steps include: Calculate the probability of compatibility breaches, compare the interface signature change list, configuration item change list, and backward compatibility declaration, assign a breach level to the incompatible items based on the frequency and location of occurrence, and record the reasons for the level. Calculate the service downtime window satisfaction rate by sequentially accumulating the preparation time, execution time, and verification time in the ordered sequence to obtain the required time window, comparing it item by item with the available service time window, giving a conclusion of whether it is satisfied or not, and recording the insufficient time period; Calculate the impact of regression test coverage, list the set of affected modules, count the number of modules covered by existing regression test cases, give the uncovered percentage, and list the names of the uncovered modules; Provided that compliance constraints and business downtime windows are met, the ordered sequence with the lowest compatibility violation level and the smallest uncovered proportion should be selected as the target repair path; when there are ties, the ordered sequence with the fewest total steps should be selected as the target repair path. Submit the selected target remediation path to the verification environment to generate remediation guidelines.

9. A software quality assessment method based on dependency chain quality transmission according to claim 8, characterized in that: The specific steps for submitting the selected target remediation path to the verification environment to generate disposition guidelines include: The target repair path is broken down into a list of steps, and time tags, prerequisites, expected results and rollback trigger conditions are set for each step. In the verification environment, execute the functional test case set, performance baseline test case set, and interface stability test case set, respectively record the number of passes and the number of failures, and record the reasons for failures; When all three conditions are met simultaneously—all functional test cases pass, the performance degradation does not exceed the preset threshold, and the interface remains stable—a pass conclusion is given. When any one condition is not met, a fail conclusion is given, and the candidate disposal sequence is returned for reselection. A handling guide document is created, which includes the sequence of steps, time tags, observation indicators, and rollback trigger conditions.

Images