A software quality evaluation method based on dependency chain quality conduction

Abstract

The application discloses a software quality evaluation method based on a 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; the application constructs a dependency chain graph covering the dependency relationship of a component, a version pedigree and a quality index, combines evidence reliability labels and license lists, accurately identifies target components and conduction paths that do not meet a quality evaluation threshold, and constructs semantic mapping of the target components and a business function domain; in a path conduction analysis stage, a constraint propagation and a causal checking mechanism are introduced, influences are transmitted layer by layer, real paths and interference paths are automatically identified, a comprehensive quality measurement item and a quality level label of the target components are generated, when the evaluation does not meet the requirement, an upgrade, replacement, isolation or rollback scheme is automatically constructed, compatibility, a time window and test influence are evaluated, a closed-loop repair path and disposal guidance are output, and the response efficiency and decision rationality of software quality problems are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software quality evaluation, more particularly, to a software quality evaluation method based on quality conduction of dependency chain. BACKGROUND

[0002] In the process of software development and delivery, projects usually rely on multiple third-party components or internal modules to form a complex dependency relationship network. Current software quality evaluation methods mostly focus on static indicator checking, compliance scanning or test coverage analysis as the core, trying to judge the overall quality from the characteristics of the components themselves. Such methods often ignore the potential conduction effect of quality defects in the dependency path, as well as the influence of semantic relationship and business coupling between components on quality results. Especially in software projects with multiple versions coexisting and multiple module reuse, a single defect may affect multiple business function domains downstream through the structural path, thereby causing systematic quality risks.

[0003] However, the existing technology still has obvious deficiencies in dependency chain quality analysis: on the one hand, there is a lack of quality conduction modeling mechanism for dependency paths, making it difficult to quantify how defect factors affect target modules through component calls, configurations and environments; on the other hand, the disposal strategy is mostly based on experience rules, which cannot realize closed-loop optimization combined with quality influence range, compatibility risk and verification cost, resulting in the outbreak of some deep-seated quality problems at the later stage of system operation, such as key function failure, rollback difficulty or integration failure, which cannot be discovered and intervened in time at the evaluation stage, thereby seriously restricting the controllability and engineering efficiency of large software system quality management. SUMMARY

[0004] In order to overcome the above-mentioned defects of the prior art, the following scheme is proposed to solve the problem of difficulty in quantifying quality conduction between software in the background art.

[0005] To achieve the above-mentioned purpose, the present application provides the following technical scheme:

[0006] A software quality evaluation method based on quality conduction of dependency chain, comprising the following steps:

[0007] S1, constructing a dependency chain map and path index of the project, obtaining quality indicators, evidence reliability labels, license lists and business scenario parameters of each component, and judging whether a preset quality evaluation threshold is met;

[0008] S2, when the judgment result is not met, determining the association relationship of the conduction path, target component and business function domain, and extracting trigger evidence and influence radius;

[0009] S3, based on the correlation relationship and the preset service priority, using constraint propagation and combining causal checking, performing sequential transmission, stage deduction and threshold triggering conduction calculation along the dependent path to obtain the self-quality measurement item, the upstream conduction quality measurement item and the comprehensive quality measurement item of the target component, and generating a quality level label and an evaluation confidence index;

[0010] S4, according to the mapping rule of the comprehensive quality measurement item and the evaluation threshold, forming a software quality evaluation conclusion and an evaluation explanation report;

[0011] S5, when the software quality evaluation conclusion is not satisfied, generating a candidate disposal sequence of upgrading, replacing, isolating or rolling back based on the evaluation explanation report, evaluating the compatibility damage possibility, the service downtime window satisfaction degree and the regression test coverage influence for each candidate sequence, selecting a target repair path with the minimum cost, and outputting an execution guide.

[0012] Further, the specific steps of S1 include:

[0013] Analyzing the dependency configuration, the build manifest and the package manager lock file to generate a directed acyclic graph among the project, the component and the version;

[0014] Recording the direct dependency depth, the indirect dependency depth, the dependency breadth and the version lineage information at each node;

[0015] Taking the target component as an index, listing its upstream path, assigning a unique identifier to each path and establishing a sequential relationship table according to the dependency order;

[0016] Performing signature integrity checking, source credibility verification and build reproducibility verification on the component to form an evidence reliability label and write it into the node metadata;

[0017] Collecting the license list and the business scenario parameters and storing them in the database;

[0018] Comparing the key quality indicators item by item according to the quality evaluation threshold, giving a satisfaction label, and generating a non-satisfaction reason label when not satisfied.

[0019] Further, the specific steps of S2 include:

[0020] Reading the non-satisfaction reason label, backtracking from the target component along the path index to the trigger node, locking the key edges and key nodes that cause the non-satisfaction;

[0021] Recording the category, occurrence time and source of the trigger evidence, and binding the record to the corresponding path;

[0022] According to the dependency depth, the dependency breadth and the cross-module boundary, listing the affected node list and giving the influence radius;

[0023] The call relationship, configuration association and data dependency between the target component and the business function domain are sorted into an association graph;

[0024] An output conduction path list, an influence radius list and an association mapping result of the target component and the business function domain are output.

[0025] Further, the specific steps of S3 include:

[0026] The association graph, the target priority, the compliance constraint and the non-satisfaction reason mark are taken as the input of constraint propagation, and the feasible range of the candidate path is reduced according to the constraint condition;

[0027] The influence is transmitted in the order of the path, and when each edge is reached, the transmission strength of the edge is determined according to the transmission rule table, the influence of the previous node is counted into the next node according to the transmission strength, and the reason and source of this transmission are recorded in the node;

[0028] When a version isolation point, an interface compatibility change point or a running environment difference point appears, a deduction amplitude is given according to the deduction rule table, and the corresponding amplitude is directly deducted from the last transmission result, and the deduction reason is recorded;

[0029] When the cumulative influence reaches the determination interval corresponding to the threshold condition, the path influence is merged into the target influence; when the cumulative influence does not reach the determination interval corresponding to the threshold condition, the target influence is not counted;

[0030] The results of at least two paths are merged, the stability label and the influence amplitude of each path are compared first, the path with the largest influence amplitude and the highest stability is selected as the dominant path and is preferentially merged, and the remaining paths are judged whether to be merged according to the preset merging order and merging conditions;

[0031] According to the three types of trigger evidence, common source evidence, simultaneous change evidence and mirror fingerprint evidence, the real conduction and synchronous interference are distinguished; the paths judged as synchronous interference are removed from the candidate set;

[0032] The self quality measurement item, the upstream conduction quality measurement item and the comprehensive quality measurement item of the target component are output, and the quality level label and the evaluation confidence index are generated.

[0033] Further, the self quality measurement item, the upstream conduction quality measurement item and the comprehensive quality measurement item of the target component are output, and the quality level label and the evaluation confidence index are generated.

[0034] The self quality measurement item of the target component is calculated according to the key quality index of the target component and the threshold segmentation rule, and the index mapping is completed according to the preset caliber to form a single determined value;

[0035] The upstream conduction quality measurement item of the target component is calculated by taking the determined value of the target influence obtained after merging as the upstream conduction quality measurement item;

[0036] The comprehensive quality metric item of the target component is the upstream conduction quality metric item when the upstream conduction quality metric item reaches the risk threshold; the self quality metric item when the upstream conduction quality metric item does not reach the risk threshold; and the one with higher risk level when both reach the risk threshold.

[0037] Further, the specific steps of S4 include:

[0038] The correspondence between the comprehensive quality metric item and the grade interval is established, and the conclusion judgment condition is set in combination with the evaluation confidence;

[0039] The software quality evaluation conclusion is given as meeting or not meeting according to the judgment condition, and the key factors leading to the conclusion are recorded;

[0040] An evaluation explanation report is formed, and the report content includes the dominant conduction path, the key node, the trigger evidence summary, the influence radius, the compliance state, and the recommended monitoring index;

[0041] The comprehensive quality metric item, the quality grade label, and the evaluation confidence index are archived as a comparison baseline, and a reevaluation time window is set for incremental review.

[0042] Further, when the software quality evaluation conclusion is not meeting, a candidate disposal sequence of upgrading, replacing, isolating, or rolling back is generated based on the evaluation explanation report, and the specific steps include:

[0043] The dominant conduction path, the key node, the compliance state, the influence radius, and the conclusion judgment basis are read;

[0044] Four types of actions, i.e., upgrading disposal, replacement disposal, isolation disposal, and rollback disposal, are respectively constructed around each key node, and preconditions and post-check items are given for each type of action;

[0045] The actions are arranged from near to far according to the dependency order and the influence radius, and an ordered sequence is established according to the actions that exist in the order of execution and the actions that exist in the order of execution;

[0046] The license clauses and enterprise strategies are verified for each ordered sequence, and a judgment of allowed or not allowed is given;

[0047] The preparation time length, the calculation execution time length, and the calculation verification time length are calculated for each ordered sequence, and the number of construction steps, deployment steps, and configuration steps involved is listed;

[0048] The candidate disposal sequence set and its constraint description are output.

[0049] Further, the compatibility damage possibility, business downtime window satisfaction and regression test coverage influence are evaluated for each candidate sequence, the target repair path with the minimum cost is selected, and execution guidance is output, and the specific steps include:

[0050] The compatibility damage possibility is calculated, the interface signature change list, the configuration item change list and the downward compatibility declaration are compared, the damage level of the incompatible items is given according to the number of occurrences and the location, and the level generation reason is recorded;

[0051] The business downtime window satisfaction is calculated, the preparation time, the execution time and the verification time in the ordered sequence are sequentially accumulated to obtain the required time window, and the business available time window is compared item by item, the conclusion of satisfaction or dissatisfaction is given, and the insufficient time period is recorded;

[0052] The regression test coverage influence is calculated, the affected module set is listed, the number of modules covered by the existing regression use case is counted, the uncovered proportion is given, and the names of the uncovered modules are listed;

[0053] Under the premise of meeting the compliance constraints and the business downtime window, the ordered sequence with the lowest compatibility damage level and the smallest uncovered proportion is preferentially selected as the target repair path; when there are parallel sequences, the ordered sequence with the minimum number of steps is selected as the target repair path;

[0054] The selected target repair path is submitted to the verification environment for generating disposal guidance.

[0055] Further, the specific steps of submitting the selected target repair path to the verification environment for generating disposal guidance include:

[0056] The target repair path is decomposed into a step list, a time label, a precondition, an expected result and a rollback trigger condition are set for each step;

[0057] The function use case set, the performance baseline use case set and the interface stability use case set are executed in the verification environment, the number of passes and the number of failures are recorded respectively, and the failure reason is recorded;

[0058] When the three conditions of all function use cases passing, the performance decline amplitude not exceeding the preset threshold and the interface remaining stable are met at the same time, the passing conclusion is given, and when any condition is not met, the failure conclusion is given and the candidate disposal sequence is returned for reselection;

[0059] The disposal guidance document is formed, and the disposal guidance document includes the step order, the time label, the observation index and the rollback trigger condition.

[0060] The technical effects and advantages of the software quality evaluation method based on the quality conduction of the dependency chain are as follows:

[0061] The application systematically depicts the quality state and structural association of each component in the software project by constructing a dependency chain graph covering the component dependency relationship, version pedigree and quality index, and combining the evidence reliability label and license list, and can accurately identify the target component and its transmission path that do not meet the quality evaluation threshold, further combining the calling relationship, configuration reference and data dependency, constructing the semantic mapping of the target component and the business function domain, so that the quality failure can be accurately traced to the structural trigger point, the dependency path and the business impact boundary, and a verifiable, locatable and explainable quality management foundation is established from the source.

[0062] In the conduction analysis stage, the constraint propagation algorithm and the cause-effect checking mechanism based on the path structure are introduced, the layer-by-layer transmission, deduction and integration of the influence factors on the dependency path are realized, and the combination judgment logic of the stability label, the influence weight and the interference identification is established, so that the comprehensive quality measurement item and the quality level label of the target component are generated, when the evaluation result does not meet, the candidate disposal sequence such as upgrading, replacing, isolating and rolling back around the key node is automatically constructed, and the multi-dimensional cost evaluation is carried out in combination with the compatibility damage possibility, the business downtime window satisfaction degree and the regression test coverage influence, and finally the closed-loop repair path and the structured disposal guide which can be executed in the verification environment are formed, which significantly improves the response efficiency and decision rationality of the enterprise when facing the quality problem of multi-module and multi-version software. BRIEF DESCRIPTION OF DRAWINGS

[0063] Figure 1 The figure is a flowchart of the software quality evaluation method based on the quality conduction of the dependency chain. DETAILED DESCRIPTION

[0064] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, not all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0065] In order to achieve the above purpose, Figure 1 The structure diagram of the software quality evaluation method based on the quality conduction of the dependency chain is given, which specifically includes the following steps.

[0066] S1, construct the dependency chain graph and path index of the project, obtain the quality index, evidence reliability label, license list and business scenario parameters of each component, and judge whether the preset quality evaluation threshold is met;

[0067] S2, when the judgment result is not satisfied, determine the association relationship of the conduction path and the target component and the business function domain, extract the trigger evidence and the influence radius;

[0068] S3, based on the association relationship and the preset business priority, adopt constraint propagation and combine causal review, perform sequential transmission, stage deduction and threshold trigger conduction calculation along the dependent path to obtain the self-quality measurement item of the target component, the upstream conduction quality measurement item and the comprehensive quality measurement item, and generate quality level labels and evaluation confidence indicators;

[0069] S4, according to the mapping rule of the comprehensive quality measurement item and the evaluation threshold, form a software quality evaluation conclusion and an evaluation explanation report;

[0070] S5, when the software quality evaluation conclusion is not satisfied, generate the candidate disposal sequence of upgrading, replacing, isolating or rolling back based on the evaluation explanation report, evaluate the compatibility damage possibility, the business downtime window satisfaction degree and the regression test coverage influence for each candidate sequence, select the target repair path with the minimum cost, and output the execution guide.

[0071] S1, construct the dependency chain graph and path index of the project, obtain the quality indicators, evidence reliability labels, license lists and business scenario parameters of each component, and judge whether the preset quality evaluation threshold is satisfied, which is specifically implemented as:

[0072] This embodiment runs on a software engineering server for construction and analysis. First, read the dependency configuration, construction list and package manager lock file, generate a directed acyclic graph according to the dependency relationship between the projects, components and versions recorded in the file, and mark it as the dependency chain graph;

[0073] Take the project itself as the root node, establish a unique node identifier for each component, and record the direct dependency depth, indirect dependency depth, dependency breadth and version pedigree information on the node. The recording method of the direct dependency depth is as follows: when there is a dependency edge between the project node and the component node with a length of one, mark it as one, otherwise mark it as zero;

[0074] The recording method of the indirect dependency depth is as follows:

[0075] When the shortest dependency path length from the project node to the component node is greater than one, mark it as the shortest dependency path length, otherwise mark it as zero;

[0076] The recording method of the dependency breadth is as follows: count the number of outgoing edges with the component as the upstream endpoint, and record the number in the component node; the recording method of the version pedigree information is as follows: write the major version number, minor version number, revision number and release time of the component into the version pedigree field of the component node in turn;

[0077] Subsequently, the upstream path of the target component is indexed, and the path enumeration follows the simple path rule of non-repeating nodes; a unique identifier is assigned to each path, and the generation method of the unique identifier is: connecting the project node identifier, the order number of each node in the path, and the target component identifier in a fixed order to form a character sequence, and registering the character sequence and the node order relationship table in the path index. After the path index is established, the signature integrity check, source credibility verification, and reproducibility verification are performed for each component: the execution method of the signature integrity check is to verify the digital signature of the component release package and record the verification conclusion, the execution method of the source credibility verification is to check the binding relationship between the publisher's identity and the registered public key and record the verification conclusion, and the execution method of the reproducibility verification 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 values and record the verification conclusion.

[0078] According to the three verification conclusions, the evidence reliability label is generated, and the determination method of the label is:

[0079] When all three verification conclusions are passed, the evidence reliability label is marked as high, when the signature integrity check and the source credibility verification are passed and the reproducibility verification is not passed, the evidence reliability label is marked as medium, and when there is a signature integrity check or a source credibility verification that is not passed, the evidence reliability label is marked as low. At the same time, the license list is collected and bound to the component node, and the business scenario parameters are collected and stored, including deployment scale, business criticality level, and allowed downtime window. The three parameters are recorded as scale value, level value, and time length.

[0080] After the above data preparation is completed, the key quality indicators of each component are obtained, and the quality evaluation threshold is compared item by item to form a satisfaction label or a reason mark for not meeting the requirements. The key quality indicators include defect event frequency, maintenance response time, test coverage, and compatibility damage record. The acquisition method of the defect event frequency is: counting the number of confirmed defect events within a preset observation window, and comparing the number with the upper limit of the defect event frequency threshold; when the number of entries is not greater than the upper limit of the threshold, the defect event frequency is determined to be satisfied, otherwise it is determined to be not satisfied.

[0081] The acquisition method of the maintenance response time is: for each problem ticket created within a preset observation window, take the natural day difference between the first response time and the creation time, sort all problem tickets by natural day difference according to a fixed rule, and take the median value, and compare the median value with the upper limit of the maintenance response time threshold; when the median value is not greater than the upper limit of the threshold, the maintenance response time is determined to be satisfied, otherwise it is determined to be not satisfied.

[0082] The acquisition method of test coverage is: reading the line coverage value in the construction report, and comparing the value with the lower threshold value of test coverage, when the line coverage value is not less than the lower threshold value, the test coverage is determined to be satisfied, otherwise it is determined to be not satisfied;

[0083] The acquisition method of compatibility breaking record is: counting the number of breaking changes in the preset observation window, and comparing the number with the upper threshold value of compatibility breaking record, when the number of entries is not greater than the upper threshold value, the compatibility breaking record is determined to be satisfied, otherwise it is determined to be not satisfied, and the comparison of the four key quality indicators is completed for each component in the above order, when the four key quality indicators are all determined to be satisfied, the evidence reliability label is high, and the license list does not appear the item conflicting with the business policy, the satisfaction label is generated as satisfied; When any one of the key quality indicators is determined to be not satisfied, or the evidence reliability label is medium or low, or the license list appears the item conflicting with the business policy, the satisfaction label is generated as not satisfied, and the not satisfied reason mark is generated.

[0084] The not satisfied reason mark contains the name of the triggered key quality indicator, the triggered comparison direction, the actual value participating in the comparison, the corresponding threshold value, the evidence reliability label value, the conflict item identification in the license list, the unique identification of the impact path, and the record time, after the above processing, the dependency chain graph, the path index, the evidence reliability label, the license list, the business scene parameter, the satisfaction label and the not satisfied reason mark are output, which are used to determine the transmission path and perform transmission calculation and software quality evaluation conclusion generation.

[0085] S2, when the judgment result is not satisfied, the association relationship between the transmission path and the target component and the business function domain is determined, and the trigger evidence and the impact radius are extracted, which is specifically implemented as:

[0086] After obtaining the not satisfied reason mark of the satisfaction label as not satisfied, the target component identification and the triggered key quality indicator name in the not satisfied reason mark are read, and the upstream nodes and dependent edges in the path are accessed in turn according to the order relationship table from the target component. When the first node or dependent edge that causes the not satisfied reason mark to be established is encountered, the node is recorded as the trigger node, and the dependent edge is recorded as the key edge, when there are multiple paths, the backtracking is completed respectively and the trigger node and the key edge are recorded for each path.

[0087] Subsequently, trigger evidence is established, and the categories of trigger evidence are common source evidence, simultaneous change evidence, mirror fingerprint evidence, vulnerability notification evidence, and license conflict evidence. The recording method of common source evidence is to check the same commit record in version control, which simultaneously affects the upstream node and the target component, and record the commit identification. The recording method of simultaneous change evidence is to check the same build batch in the build pipeline log, which updates the version of the upstream node and the target component, and record the batch number. The recording method of mirror fingerprint evidence is to compare the base mirror fingerprints used by the upstream node and the target component in the artifact library record, and record the fingerprint value. The recording method of vulnerability notification evidence is to search for the announcement number hit by the upstream node in the vulnerability announcement library, and record the number. The recording method of license conflict evidence is to search for the item in conflict with the enterprise policy in the license list verification result, and record the item identification. Each of the above evidences records three fields of category, occurrence time, and source. The occurrence time is recorded in server time, the source is recorded in the corresponding unique identification, and the evidence record is bound to the unique identification of the corresponding path.

[0088] After confirming the trigger node and the critical edge, the affected node list and the influence radius are counted according to the dependency chain graph. The listing process of the affected node list is as follows:

[0089] For each determined path, all nodes from the trigger node to the target component are selected and added to the affected node list in turn. When there are multiple paths, the nodes obtained from each path are merged item by item, and the duplicate nodes are removed.

[0090] The method of giving the influence radius is to record three determined quantities at the same time: one is the level span, the determination method of the level span is to count the number of dependency edges from the trigger node to the target component and record the number; the second is the number of affected nodes, the determination method of the number of affected nodes is to count the number of node entries in the affected node list and record the number; the third is the number of cross-module boundary, the determination method of the number of cross-module boundary is to count the number of dependency edges that cross the module attribution change from the trigger node to the target component according to the module attribution field in the component metadata, and record the number.

[0091] After the above statistics are completed, the conduction path list is formed, and each entry contains path unique identification, trigger node, critical edge, affected node list, and influence radius.

[0092] The association relationship between the target component and the business function domain is established, and the association relationship graph is constructed according to three kinds of relationships of calling relationship, configuration association and data dependency. The acquisition method of the calling relationship is to perform static calling scanning on the source code and check the calling direction of the service and the interface in combination with the service registration information. The calling initiated by the target component to the outside and the calling received from the outside are recorded as directed edges respectively. The acquisition method of the configuration association is to parse the reference relationship of the target component and other components to the same configuration item in the configuration center record. The relationship between the components sharing the configuration item is recorded as an undirected edge. The acquisition method of the data dependency is to count the access and subscription of the target component to tables, views, topics and queues in the database access list and the message queue subscription list. The relationship between the components that read and write or subscribe and publish through the same data object is recorded as a directed edge.

[0093] The three kinds of relationships are combined into an association relationship graph, and the component identifier and the business function domain identifier are marked on the nodes of the graph. The business function domain identifier is derived from the business criticality level and the function domain division table in the business scenario parameter. Finally, the conduction path list, the influence radius list and the association mapping result of the target component and the business function domain are output.

[0094] For example, in the development process of an enterprise-level data analysis platform, the research and development team discovers from the dependency graph that after the dependent component com.example.json-serializer of the statistical analysis module in a certain version is updated, the report module in the business function domain appears abnormal. User feedback that the exported report field is missing. By determining that the comprehensive quality metric of the report module is lower than the preset threshold;

[0095] In step S2, according to the dissatisfaction reason mark of the report module, the dependency path is traced back, it is identified that the version upgrade of com.example.json-serializer is 3.1.4, and the version is marked as a key node. The key edge identified is the direct dependency relationship of the report module to it, the trigger evidence is the inconsistency of the build fingerprint in the change record, the configuration signature verification fails, the time record is the submission date June 3, 2024, and the source is the build pipeline version control;

[0096] According to the dependency depth of the component, which is 2, i.e. direct dependency once, and the intermediate node depends on once again, the dependency breadth is 4, i.e. a total of 4 business modules depend on the component, the cross-module boundary is 1, involving the report module and the export module, the influence radius is calculated as medium level, and then the calling relationship, the dependency configuration and the data input and output path information between the report module and the statistical module are established into an association relationship graph.

[0097] S3, based on the association relationship and the preset business priority, adopting constraint propagation and combining causal checking, performing sequential transmission, stage deduction and threshold triggering conduction calculation along the dependent path to obtain the self-quality measurement item, the upstream conduction quality measurement item and the comprehensive quality measurement item of the target component, and generating quality level labels and evaluation confidence indicators, and the specific implementation is:

[0098] After obtaining the conduction path list, the influence radius list and the association mapping result of the target component and the business function domain, the association relationship diagram, the target priority, the compliance constraint and the non-compliance reason mark are taken as the input of the constraint propagation. First, the conduction path list is filtered according to the compliance constraint and the target priority. Paths with license conflicts that cannot be solved by replacing the license are removed, and the remaining paths are recorded as a candidate path set. For each path in the candidate path set, an accumulated influence record is established and initialized to zero. Then, each dependent edge is processed in turn from the upstream to the target component according to the order relationship table: when the current dependent edge is reached, the transmission strength of the dependent edge is calculated according to the transmission rule table.

[0099] The determination method of the transmission rule table is to disclose the corresponding relationship between the edge type and the influence transmission in the specification in advance and give the source of the deterministic value. The edge type includes three types of version inheritance edge, function call edge and running environment dependent edge. The transmission strength of the version inheritance edge is determined by the indirect dependence depth and the dependence breadth. The greater the indirect dependence depth, the lower the transmission strength by a fixed decreasing amplitude. The greater the dependence breadth, the higher the transmission strength by a fixed increasing amplitude. The transmission strength of the function call edge is determined by the call direction and the call stability. The call direction is counted as positive influence when it is from upstream to downstream. The call stability is converted to a stable level from the occurrence frequency of the call change record and then corresponds to a fixed value. The transmission strength of the running environment dependent edge is determined by the running environment difference identifier. The same running environment is counted as a baseline value, and the different running environment is counted as a deducted value. The influence of the previous node is converted into the influence contribution of the dependent edge according to the transmission strength of the dependent edge, and is written into the accumulated influence record of the path. The reason and source of this transmission are recorded in the node metadata.

[0100] If a version isolation point, an interface compatibility change point or a running environment difference point is detected at the current node, the deduction amplitude is calculated according to the deduction rule table, and the corresponding amplitude is directly deducted from the accumulated influence record of the path. At the same time, the deduction reason is recorded. After completing the sequential transmission of all dependent edges on the path, the accumulated influence record of the path is compared with the judgment interval corresponding to the threshold condition. When the accumulated influence record enters the judgment interval, the path is marked as valid and is integrated. When the accumulated influence record does not enter the judgment interval, the path is marked as invalid and is not integrated into the target influence.

[0101] When there are at least two paths marked as valid merging in the candidate path set, multi-path merging is performed, and first, a stability label is generated for each valid merging path. The stability label is determined by consistency verification of common source evidence, simultaneous change evidence, and mirror fingerprint evidence. If a path meets three types of evidence, it is marked as high; if it meets two types of evidence, it is marked as medium; and if it meets one type of evidence, it is marked as low.

[0102] When there is vulnerability notification evidence and it matches the path trigger node, the stability label is increased by one level; when there is license conflict evidence and the conflict entry has not been replaced by a license, the stability label is decreased by one level. Then, the cumulative impact record and the 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 according to the preset merging order and merging conditions. The preset merging condition is that the path and the dominant path do not have mutually negative version isolation points in the node sequence, and the stability label of the path is not lower than medium. When the merging condition is met, the cumulative impact record of the path is written into the remaining part of the target impact according to the merging rule, and the rule of not covering the written part of the dominant path is followed. When the merging condition is not met, the target impact is not written and the reason is noted in the record.

[0103] To distinguish between real transmission and synchronous interference, the cause and effect of all paths marked as valid merging are checked. When at least two types of common source evidence, simultaneous change evidence, and mirror fingerprint evidence can form a matching closed loop with the trigger node and the target component, the path is determined to be real transmission. When a matching closed loop cannot be formed, the path is determined to be synchronous interference and is removed from the candidate set. The final target impact is the deterministic impact value of the remaining path after merging, which is used for subsequent calculation of the upstream transmission quality metric item of the target component.

[0104] After obtaining the target impact, the self-quality metric item of the target component, the upstream transmission quality metric item of the target component, and the comprehensive quality metric item of the target component are calculated in turn. The steps for calculating the self-quality metric item of the target component are as follows: read the defect event frequency, maintenance response time delay, test coverage, and compatibility damage record collected in step S1, map the four key quality indicators to a single determined value according to the threshold segmentation rule and the preset standard. During mapping, indicators that do not exceed the threshold are marked as qualified contributions, and indicators that exceed the threshold are marked as risk contributions. The mapping source is recorded in the mapping table. After the contributions are summarized in a fixed order, the single determined value of the self-quality metric item is confirmed.

[0105] The process of calculating the upstream transmission quality metric item of the target component is to use the deterministic impact value of the target impact obtained after merging as the upstream transmission quality metric item.

[0106] The process of calculating the comprehensive quality metric item of the target component is that when the upstream conduction quality metric item reaches the risk threshold, the upstream conduction quality metric item is taken as the comprehensive quality metric item; when the upstream conduction quality metric item does not reach the risk threshold, the self quality metric item is taken as the comprehensive quality metric item; when the upstream conduction quality metric item and the self quality metric item both reach the respective risk thresholds, the one with the higher risk level is taken as the comprehensive quality metric item.

[0107] According to the correspondence between the comprehensive quality metric item and the grade interval, a quality level label is generated, which contains six items of grade code, grade interval, dominant conduction path identification, key node list, compliance status and reevaluation time window; and an evaluation confidence index is generated, which contains five items of index coverage, evidence reliability strength, conduction explanation completeness, result stability and cause-effect checking pass rate, wherein the index coverage is recorded by the ratio of the number of collected key quality indicator items to the number of items that should be collected, the evidence reliability strength is recorded by the ratio of the number of passed three items of evidence verification to the total number of three items, the conduction explanation completeness is recorded by the number of three contained items of triggered evidence, node sequence and influence radius, the result stability is recorded by the ratio of the number of consistent evaluation conclusions within the reevaluation time window to the number of reevaluations, and the cause-effect checking pass rate is recorded by the ratio of the number of checked passed evidence items to the number of involved checked evidence items.

[0108] After the above calculation is completed, the self quality metric item of the target component, the upstream conduction quality metric item of the target component, the comprehensive quality metric item of the target component, the quality level label and the evaluation confidence index are output.

[0109] S4, according to the mapping rule of the comprehensive quality metric item and the evaluation threshold, a software quality evaluation conclusion and an evaluation explanation report are formed, which is specifically implemented as:

[0110] When forming the conclusion determination condition, the grade interval in which the comprehensive quality metric item is located and the five indicators in the evaluation confidence index are jointly determined, and the determination process is:

[0111] After obtaining the self quality metric item of the target component, the upstream conduction quality metric item of the target component and the comprehensive quality metric item of the target component, the quality level label and the evaluation confidence index, first, the correspondence between the comprehensive quality metric item and the grade interval is established and solidified as a grade interval table. The grade interval table is determined offline before deployment and written into a configuration item, which is set as four disjoint closed intervals: low risk interval, medium risk interval, high risk interval and extremely high risk interval, and each interval is represented by a lower limit value and an upper limit value and given a determined numerical value in the configuration.

[0112] When forming the conclusion determination condition, the grade interval in which the comprehensive quality metric item is located is combined with the five indicators in the evaluation credibility index to make a joint determination. The determination process is as follows:

[0113] When the comprehensive quality metric item falls into the low-risk interval, and the index coverage is not less than 90%, the evidence reliability strength is equal to 1, the conduction explanation completeness contains the trigger evidence, the node sequence, and the impact radius 3, the result stability is not less than 80%, and the causal review pass rate is not less than 2 / 3, the software quality evaluation conclusion is given as satisfactory; when the comprehensive quality metric item falls into the medium-risk interval, and the index coverage is not less than 95%, the evidence reliability strength is equal to 1, the conduction explanation completeness contains 3, the result stability is not less than 85%, and the causal review pass rate is not less than 3 / 4, the software quality evaluation conclusion is given as satisfactory;

[0114] When the comprehensive quality metric item falls into the high-risk interval or the extremely high-risk interval, the software quality evaluation conclusion is given as unsatisfactory; when the comprehensive quality metric item falls into the low-risk interval or the medium-risk interval and any evaluation credibility index does not reach the corresponding threshold, the software quality evaluation conclusion is given as unsatisfactory.

[0115] After generating the software quality evaluation conclusion, the key factors leading to the conclusion are recorded, including the grade interval in which the comprehensive quality metric item is located, the evaluation credibility index name that does not reach the threshold and the actual value of the evaluation credibility index, the dominant conduction path identifier, and the key node list. The above records are written into the evaluation result storage in a structured field.

[0116] When forming the evaluation explanation report, the report template is filled in with the dominant conduction path, the key node, the trigger evidence summary, the impact radius, the compliance status, and the recommended monitoring indicator.

[0117] The dominant conduction path is filled in with the determined dominant conduction path identifier and the sequence number list of the nodes in the path;

[0118] The key node is filled in with the name and sequence number of each node in the key node list;

[0119] The trigger evidence summary is filled in with the ordered list of the three fields of evidence category, occurrence time, and source;

[0120] The impact radius is filled in with the three determined quantities of hierarchical span, number of affected nodes, and number of cross-module boundaries;

[0121] The compliance status is filled in with the compliance or non-compliance in the license list verification conclusion;

[0122] The recommended monitoring indicators are the key quality indicators and evidence items that need to be continuously monitored, including defect event frequency, maintenance response time delay, test coverage, compatibility damage record, evidence reliability label change, and license list conflict identification. The sources of each item and the review period are given in the report.

[0123] Subsequently, the comprehensive quality metric items, quality level labels, and evaluation credibility indicators are archived for comparison with the baseline. The baseline record includes the generation time, applicable target component identification, and version lineage information. The reevaluation time window is set based on the quality level label and evaluation credibility indicator: when the quality level label is low risk and the result stability is not less than 90%, the reevaluation time window is set to 30 days; when the quality level label is medium risk or the result stability is between 80% and 90%, the reevaluation time window is set to 10 days; when the quality level label is high risk or extremely high risk, the reevaluation time window is set to 3 days. When the reevaluation time window expires, incremental review is triggered. The incremental review refers to the comparison of the baseline, and each item is checked for changes in the comprehensive quality metric items, quality level labels, and evaluation credibility indicators. The reasons for the changes are written into a new evaluation explanation report.

[0124] S5, when the software quality evaluation conclusion is not satisfied, generate candidate disposal sequences of upgrading, replacing, isolating, or rolling back based on the evaluation explanation report. For each candidate sequence, evaluate the compatibility damage possibility, business downtime window satisfaction, and regression test coverage impact, and select the target repair path with the minimum cost. Output the execution guide, which is implemented as follows:

[0125] When the software quality evaluation conclusion is not satisfied, read the dominant transmission path, key node, compliance status, influence radius, and conclusion determination basis from the evaluation explanation report. Around each key node, construct four types of actions: upgrading, replacing, isolating, and rolling back. Set the preconditions and post-check items for each type of action. The precondition for upgrading is that there is a released repair version in the upstream version and the license terms and enterprise strategy are consistent. The post-check item is the signature integrity and source credibility verification of the build product after upgrading. The precondition for replacing is that there is a replacement component that meets the functional contract and license terms. The post-check item is the interface signature and configuration item consistency after replacement. The precondition for isolation is that there is a verifiable runtime isolation strategy and deployment boundary. The post-check item is that the call path does not cross the isolation boundary after isolation. The precondition for rollback is that there is an archived previous stable version. The post-check item is that the version lineage information after rollback is consistent with the archive record.

[0126] Arrange the four types of actions under the same key node according to the principle of first resolving the near-end influence and then resolving the far-end influence, that is, establish an ordered sequence from near to far based on the dependency order and influence radius. When there is a prior and posterior dependency relationship at the same key node, execute the pre-action first and then execute the post-action.

[0127] For each ordered sequence, check the license terms and enterprise policies, give a decision of allow or not allow, for the ordered sequence decided as allow, calculate the preparation duration, execution duration and verification duration one by one, the source of the three durations are the statistics of build pipeline time, deployment pipeline time and regression case execution time respectively, at the same time, list the number of build steps, deployment steps and configuration steps involved in the ordered sequence, form the candidate treatment sequence set and its constraint description.

[0128] For the candidate treatment sequence set, carry out three evaluations one by one, the first one is compatibility damage possibility evaluation: read the interface signature change list, configuration item change list and downward compatibility declaration, compare the interface signature and configuration item after the ordered sequence execution with the calling contract of the target component one by one, for the inconsistent items, give a damage level according to the number of occurrences and the location, the judgment of the location is based on whether the inconsistent item is located in the external public interface or the internal calling interface, the inconsistent item of the external public interface is higher than that of the internal calling interface in damage level; record the reason for each damage level and summarize the compatibility damage possibility conclusion of the ordered sequence;

[0129] The second one is business downtime window satisfaction degree evaluation: add the preparation duration, execution duration and verification duration of the ordered sequence in order to get the required time window, then compare it with the business available time window in the business scenario parameter one by one, when the required time window is not greater than the business available time window, give the satisfaction conclusion, when the required time window is greater than the business available time window, give the dissatisfaction conclusion and record the start and end time of the insufficient period;

[0130] The third one is regression test coverage impact evaluation: according to the association mapping result and influence radius of the target component and business function domain, list the affected module set, count the number of affected modules covered by existing regression cases and the total number of affected modules, give the uncovered proportion in the way of the number of uncovered affected modules divided by the total number of affected modules, and list the name list of uncovered modules.

[0131] After completing the three evaluations, under the premise of meeting the compliance constraints and business downtime time window, prefer to choose the ordered sequence with the lowest compatibility damage level and the smallest uncovered proportion as the target repair path, when there are ties, choose the ordered sequence with the least total number of steps as the target repair path, for the ordered sequences not selected, record the abandonment reason, which includes at least one of the three situations of the highest damage level, the largest uncovered proportion or the most total number of steps.

[0132] The selected target repair path is submitted to a verification environment that does not affect the live network and is expanded for verification. Before verification, the target repair path is decomposed into a step list, and a time tag, a precondition, an expected result, and a rollback trigger condition are set for each step. The execution order is from early to late time tags. For each step, a set of functional use cases, a set of performance baseline use cases, and a set of interface stability use cases are run in the verification environment. The number of passes and the number of failures are recorded, and the reason for each failure is recorded. The pass criteria for the set of functional use cases are that all functional use cases pass; the pass criteria for the set of performance baseline use cases are that the decline in key performance indicators does not exceed the pre-set threshold; and the pass criteria for the set of interface stability use cases are that the results of external 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, and when any criterion is not met, a fail conclusion is given and the candidate treatment sequence set is returned to select the target repair path again, and the reason for this failure is written into the abandonment reason record.

[0133] In the case of verification pass, a treatment guide document is formed, which is output using a structured template and contains four parts of step order, time tag, observation index, and rollback trigger condition. The step order lists the specific operations in the execution order of the target repair path, the time tag indicates the start time and the maximum allowed duration of each step, the observation index includes the construction product signature integrity check result, the source credibility verification result, the construction product hash consistency result, the service availability index, the interface success rate index, and the key performance index, and the rollback trigger condition includes any of the following situations: the first failure of a functional use case, the decline in key performance indicators exceeding the pre-set threshold, the interface success rate falling below the pre-set threshold, and the license verification result showing any irregular items.

[0134] After the treatment guide document is generated, it is archived together with the selected target repair path, and the archived content includes version lineage information, leading conduction path identification, key node list, and this verification evidence, so as to audit traceability and re-evaluation reference.

[0135] For example, in the continuous integration process of the same platform, the development team found that the comprehensive quality metric item of the com.example.parser-core component had reached a high risk level. According to the leading conduction path, key node, and influence radius provided in the evaluation explanation report, the team constructed three candidate treatment 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.

[0136] The platform calculates each of the three treatment paths:

[0137] Compatibility breaking possibility: 7 configuration items of parser-core5.2.0 are changed in the upgrade path, 3 interface signatures are adjusted, and the breaking level is determined to be medium; the interface difference reaches 9 in the replacement path, and the breaking level is high; there is no breaking item in the rollback path, and the breaking level is low.

[0138] Service downtime window satisfaction: the preparation time, execution time, and verification time of the three paths are as follows: 6 hours, 2 hours, and 2 hours for the upgrade path, a total of 10 hours; 18 hours for the replacement path; and 6 hours for the rollback path. The current service available window is 12 hours, so all of them meet the requirements.

[0139] Regression test coverage impact: the replacement path affects 7 modules, 5 modules are covered by existing use cases, and the uncovered proportion is 28.6%; the uncovered proportion of the upgrade path is 14.3%; and the uncovered proportion of the rollback path is 0%.

[0140] According to the compatibility breaking level, the regression uncovered proportion, and the total number of steps, the rollback path is selected as the target repair path, and it is submitted to the verification environment to trigger the handling verification process.

[0141] It should be noted that the threshold information related in the embodiments is set by professionals in advance, and will not be explained too much here. In the embodiments, some parameters have the same letters, but different meanings are explained in use, and they will not be explained one by one here.

[0142] Those skilled in the art can realize that the modules and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0143] In addition, each functional module in each embodiment of the present application can be integrated in one processing module, or each module can exist physically alone, or two or more modules can be integrated in one module.

[0144] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any skilled person in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0145] Finally: the above only for the preferred embodiments of the present application, and not for limiting the present application, any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application, should be included in the scope of protection of the present application.

Claims

1. A software quality evaluation method based on dependency chain quality conduction, characterized in that: The specific steps include: S1, constructing a dependency chain map and path index of the project, obtaining quality indicators, evidence reliability labels, license lists and business scenario parameters of each component, and judging whether a preset quality evaluation threshold is met; S2, when the judgment result is not met, determining the association relationship between the conduction path, the target component and the business function domain, and extracting the trigger evidence and the influence radius; S3, based on the association relationship and the preset business priority, using constraint propagation and combining causal checking, performing sequential transmission, stage deduction and threshold triggering conduction calculation along the dependency path, obtaining the self-quality measurement item, the upstream conduction quality measurement item and the comprehensive quality measurement item of the target component, and generating quality level labels and evaluation reliability indicators; S4, according to the mapping rule of the comprehensive quality measurement item and the evaluation threshold, forming a software quality evaluation conclusion and an evaluation explanation report; S5, when the software quality evaluation conclusion is not met, generating a candidate disposal sequence of upgrading, replacing, isolating or rolling back based on the evaluation explanation report, evaluating the compatibility damage possibility, the business downtime window satisfaction degree and the regression test coverage influence of each candidate sequence, selecting the target repair path with the minimum cost, and outputting the execution guide.

2. The software quality evaluation method based on the dependency chain quality conduction according to claim 1, characterized in that: The specific steps of S1 include: Analyzing the dependency configuration, constructing the list and package manager lock file, and generating a directed acyclic graph between the project, component and version; Record the direct dependency depth, indirect dependency depth, dependency breadth and version pedigree information at each node; List the upstream paths of the target component, assign a unique identifier to each path, and establish a sequential relationship table according to the dependency order; Perform signature integrity verification, source credibility verification and reproducibility verification on the component, form the evidence reliability label and write it into the node metadata; Collect license lists and business scenario parameters and store them in the database; Compare key quality indicators one by one according to the quality evaluation threshold, give a satisfaction label, and generate a non-satisfaction reason mark when not met.

3. The software quality evaluation method based on dependency chain quality propagation according to claim 1, characterized in that: The specific steps of S2 include: Read the non-satisfaction reason mark, backtrack from the target component to the trigger node along the path index layer by layer, lock the key edges and key nodes that cause the non-satisfaction; Record the category, occurrence time and source of the trigger evidence, and bind the record to the corresponding path; List the affected node list and give the influence radius according to the dependency depth, dependency breadth and cross-module boundary; Organize the call relationship, configuration association and data dependency between the target component and the business function domain into an association relationship diagram; Output the conduction path list, influence radius list and association mapping result between the target component and the business function domain.

4. The software quality evaluation method based on dependency chain quality conduction according to claim 1, characterized in that: The specific steps of S3 include: Using the association relationship diagram, target priority, compliance constraints and non-satisfaction reason mark as the input of constraint propagation, and reducing the feasible range of candidate paths according to the constraint conditions; Perform influence transmission according to the path order, at each edge, determine the transmission strength of the edge according to the transmission rule table, count the influence of the previous node into the next node according to the transmission strength, and record the reason and source of this transmission at the node; When a version isolation point, interface compatibility change point, or running environment difference point appears, the deduction amplitude is given according to the deduction rule table, the corresponding amplitude is directly deducted from the last transmission result, and the deduction reason is recorded; When the cumulative influence reaches the judgment interval corresponding to the threshold condition, the path influence is merged into the target influence; when the cumulative influence does not reach the judgment interval corresponding to the threshold condition, it is not counted into the target influence; The results of at least two paths are merged, the stability label and the influence amplitude of each path are compared first, the path with the largest influence amplitude and the highest stability is selected as the dominant path, and the rest of the paths are judged whether to be merged according to the preset merging order and merging conditions; According to the three types of trigger evidence of common source evidence, simultaneous change evidence and mirror fingerprint evidence, distinguish between real transmission and synchronous interference; for the paths judged as synchronous interference, eliminate them from the candidate set; Output the self quality metric item, upstream transmission quality metric item and comprehensive quality metric item of the target component, and generate quality level label and evaluation confidence index.

5. The software quality evaluation method based on dependency chain quality conduction according to claim 4, characterized in that: The specific steps of outputting the self quality metric item, upstream transmission quality metric item and comprehensive quality metric item of the target component include: The calculation of the self quality metric item of the target component is based on the key quality indicators of the target component and the threshold segmentation rule, and the index mapping is completed according to the preset caliber to form a single determined value; The calculation of the upstream transmission quality metric item of the target component is to take the determined value of the target influence obtained after merging as the upstream transmission quality metric item; The calculation of the comprehensive quality metric item of the target component is that when the upstream transmission quality metric item reaches the risk threshold, the upstream transmission quality metric item is taken as the comprehensive quality metric item; when the upstream transmission quality metric item does not reach the risk threshold, the self quality metric item is taken as the comprehensive quality metric item; when both reach the risk threshold, the one with higher risk level is taken as the comprehensive quality metric item.

6. The software quality evaluation method based on dependency chain quality conduction according to claim 1, characterized in that: The specific steps of S4 include: Establish the corresponding relationship between the comprehensive quality metric item and the grade interval, and set the conclusion judgment condition combined with the evaluation confidence; According to the judgment condition, give the software quality evaluation conclusion as satisfied or not satisfied, and record the key factors leading to the conclusion; Form an evaluation explanation report, which includes the dominant transmission path, key node, trigger evidence summary, influence radius, compliance status and recommended monitoring index; Archive the comprehensive quality metric item, quality level label and evaluation confidence index as a comparison baseline, and set a reevaluation time window for incremental review.

7. The software quality evaluation method based on dependency chain quality propagation according to claim 1, wherein: When the software quality evaluation conclusion is not satisfied, generate the candidate disposal sequence of upgrading, replacing, isolating or rolling back based on the evaluation explanation report, and the specific steps include: Read the dominant transmission path, key node, compliance status, influence radius and conclusion judgment basis; Around each key node, construct four types of actions of upgrading disposal, replacement disposal, isolation disposal and rollback disposal, and give the preconditions and post-check items for each type of action; Arrange the actions from near to far according to the dependence order and influence radius to establish an ordered sequence according to the execution first and execution later of the actions that exist in the sequence; Verify the permit clause and enterprise strategy for each ordered sequence, and give the judgment of allowed or not allowed; Calculate the preparation duration, execution duration and verification duration for each ordered sequence, and list the number of involved build steps, deployment steps and configuration steps; Output the candidate treatment sequence set and its constraint description.

8. The software quality evaluation method based on dependency chain quality propagation according to claim 1, wherein: For each candidate sequence, evaluate the compatibility disruption possibility, business downtime window satisfaction and regression test coverage impact, and select the target repair path with the minimum cost, output the execution guide, the specific steps include: Calculate the compatibility disruption possibility, compare the interface signature change list, configuration item change list and downward compatibility declaration, give the disruption level to the incompatible items according to the number of occurrences and the location, and record the reason for the level; Calculate the business downtime window satisfaction, add the preparation duration, execution duration and verification duration in the ordered sequence to get the required time window, compare it with the business available time window item by item, give the conclusion of satisfaction or dissatisfaction, and record the insufficient period; Calculate the regression test coverage impact, list the affected module set, count the number of modules covered by existing regression test cases, give the uncovered proportion, and list the names of uncovered modules; Under the premise of meeting compliance constraints and business downtime window, prefer to select the ordered sequence with the lowest compatibility disruption level and the smallest uncovered proportion as the target repair path; When there are parallel, select the ordered sequence with the least total number of steps as the target repair path; Submit the selected target repair path to the verification environment to generate the treatment guide.

9. The software quality evaluation method based on dependency chain quality conduction according to claim 8, characterized in that: The specific steps of submitting the selected target repair path to the verification environment to generate the treatment guide include: Decompose the target repair path into a step list, set the time label, preconditions, expected results and rollback trigger conditions for each step; Execute the functional test case set, performance baseline test case set and interface stability test case set in the verification environment, record the number of passed and failed respectively, and record the failure reason; When the three conditions of all functional test cases passing, performance degradation not exceeding the preset threshold, and interface remaining stable are met at the same time, give the pass conclusion, when any condition is not met, give the fail conclusion and return to the candidate treatment sequence selection; Form the treatment guide document, which includes step order, time label, observation index and rollback trigger condition.

Images