Minimum test case generation and function coverage calculation method

Abstract

This application provides a method for generating minimum test cases and calculating functional coverage, comprising: Step 1, generating a feature map based on real online traffic packets recorded on the AREX platform; Step 2, generating a minimum feature test unit set based on the feature map; Step 3, generating a test unit-functional node binding matrix based on the pre-set list of functional nodes in the business system and the minimum feature test unit set; Step 4, generating functional coverage dimension values ​​based on the test unit-functional node binding matrix; Step 5, generating corresponding supplementary parameter combinations based on the functional coverage dimension values ​​by reverse parsing the logical dependencies between functional nodes, so as to synchronously update the minimum feature test unit set and the test unit-functional node binding matrix. This application has a higher degree of fit with the actual characteristics of online business scenarios, can more systematically reflect the coverage status of test units to functional nodes, and can dynamically supplement test elements that adapt to business logic during the testing process.

Description

Technical Field

[0001] This application relates to the field of data management technology, and more specifically, to a method for generating minimum test cases and calculating functional coverage. Background Technology

[0002] In enterprise-level business systems, business scenarios often involve complex logical relationships, such as the impact of local cache state changes on business processes, the linkage between time anchors and business rules, and the interaction dependencies between multiple modules. This places high demands on test cases to accurately reproduce real online scenarios and fully cover business functions. In particular, during system iteration, testing methods need to efficiently support functional consistency verification and rapid location and repair of online issues.

[0003] Among the existing test case generation and functional coverage calculation solutions, one approach is to extract typical business parameter combinations based on a pre-written business scenario description document to generate test cases; another approach is to collect parameter data from historical interface calls and directly reuse this parameter data to generate test cases for scenario replay; and yet another approach is to generate test cases that cover high-priority functional nodes in sequence according to the preset importance priority of functional nodes.

[0004] In the existing solutions mentioned above, the generated test cases are difficult to accurately adapt to the dynamically changing characteristics of online business scenarios (such as the real-time status of local cache, the impact of time factors on the triggering of business logic, and the logical dependencies when multiple modules interact). This results in limited coverage of complex business scenarios by the test cases, and the evaluation results of functional coverage cannot accurately match the functional coverage of the actual business. This is not conducive to the technical team optimizing test cases more accurately, and may affect the stability assurance after system iteration. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method for generating minimum test cases and calculating functional coverage, which can at least alleviate the aforementioned technical problems.

[0006] The technical solutions provided in this application are as follows:

[0007] A method for generating minimum test cases and calculating functional coverage includes:

[0008] Step 1: Generate a feature map based on the real online traffic packets recorded on the AREX platform;

[0009] Step 2: Generate the minimum feature test unit set based on the feature map;

[0010] Step 3: Generate a test unit-function node binding matrix based on the pre-set list of functional nodes and the minimum feature test unit set of the business system;

[0011] Step 4: Generate functional coverage dimension values ​​based on the test unit-functional node binding matrix;

[0012] Step 5: Based on the functional coverage dimension value, generate corresponding supplementary parameter combinations by reverse parsing the logical dependencies between functional nodes, so as to synchronously update the minimum feature test unit set and the test unit-functional node binding matrix.

[0013] The technical solution in this application has the following technical advantages:

[0014] By generating feature maps from real online traffic packets recorded on the AREX platform, the subsequently generated minimum feature test unit set has a higher degree of relevance to the actual characteristics of online business scenarios compared to generating test cases solely based on pre-written business scenario description documents. The function coverage dimension values ​​generated by the test unit-function node binding matrix, compared to generating test cases based on preset function node importance priorities, more systematically reflect the coverage status of test units to function nodes. Furthermore, by reverse-analyzing the logical dependencies between function nodes to generate supplementary parameter combinations and simultaneously updating the minimum feature test unit set and the test unit-function node binding matrix, test elements that adapt to business logic relationships can be dynamically supplemented during testing. Compared to directly reusing historical interface call parameters to generate test cases, this can improve the sufficiency of test case coverage for complex business scenarios to a certain extent. It also helps to improve the matching degree between the function coverage evaluation results and the actual function coverage of the business, providing a more reliable basis for the technical team to optimize test cases, and thus providing more effective support for the stability of the system after iteration. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a method for generating minimum test cases and calculating functional coverage according to an embodiment of this application.

[0016] Figure 2 This is a schematic diagram of the structure of a minimum test case generation and functional coverage computing device according to an embodiment of this application. Detailed Implementation

[0017] Figure 1 This is a flowchart illustrating a method for generating minimum test cases and calculating functional coverage according to an embodiment of this application. Figure 1 As shown, it includes:

[0018] Step 1: Generate a feature map based on the real online traffic packets recorded on the AREX platform;

[0019] Step 2: Generate the minimum feature test unit set based on the feature map;

[0020] Step 3: Generate a test unit-function node binding matrix based on the pre-set list of functional nodes and the minimum feature test unit set of the business system;

[0021] Step 4: Generate functional coverage dimension values ​​based on the test unit-functional node binding matrix;

[0022] Step 5: Based on the functional coverage dimension value, generate corresponding supplementary parameter combinations by reverse parsing the logical dependencies between functional nodes, so as to synchronously update the minimum feature test unit set and the test unit-functional node binding matrix.

[0023] Optionally, it includes: Step 1, generating a feature map based on the online real traffic packets recorded by the AREX platform, specifically including: performing feature deconstruction processing on the online real traffic packets recorded by the AREX platform to obtain interface call parameters, local cache snapshots, and time anchor information, and generating a feature map accordingly.

[0024] In summary, this solution proactively acquires "local cache snapshots" through feature deconstruction, incorporating the dynamic business element of caching into the feature graph. Compared to traditional methods, this approach better reflects the actual scenario in online business where "cache status affects API call results." For example, if the result of an API call depends on user permission data in the cache, traditional solutions may be unable to reproduce this scenario due to the lack of cache snapshots, while this solution can recreate the real call environment through cache snapshots. This deliberate collection of cache snapshots is not a natural extension of traditional parameter collection approaches; it requires understanding that "cache dynamism is the core bottleneck for test scenario distortion," rather than simply following the traditional method of "only collecting API parameters."

[0025] Furthermore, this solution proactively acquires "time anchor information" through feature deconstruction, incorporating the temporal dimension into the feature map construction process. Compared to traditional methods, it can more comprehensively reflect the impact of time factors on business logic in online operations. This extraction of time anchors is a result of breaking through the limitations of the traditional mindset of "only focusing on static parameters." It is necessary to recognize that "the time dimension is the key to covering time-related business scenarios," rather than simply following the traditional method of "parameter collection detached from time."

[0026] Furthermore, this solution deconstructs interface call parameters from "real online traffic packages" recorded on the AREX platform. These parameters originate from actual online business operations and, compared to traditional static document parameters or historical data, more closely reflect the real-time call situation of online business. This parameter acquisition method, which uses "real-time online traffic" as the data source, needs to break away from the traditional mindset of "relying on preset or historical data" and choose real-time traffic as the core data source to solve the bottleneck of "mismatch between online dynamic parameters and test data," rather than simply following the traditional "offline parameter collection" logic.

[0027] Optionally, step 1, generating a feature map based on the online real traffic packets recorded by the AREX platform, specifically includes: performing feature deconstruction processing on the online real traffic packets recorded by the AREX platform to obtain interface call parameters, local cache snapshots, and time anchor information, and generating a feature map accordingly, specifically including the following steps:

[0028] Step 11: Call the traffic feature layering parsing module to load the preset dynamic protocol matching library, and perform protocol type detection on the online real traffic packets recorded by the AREX platform to separate the metadata and payload of the real traffic packets.

[0029] Step 12: Perform multi-dimensional feature layering extraction based on the separated metadata and payload to obtain interface call parameters, local cache snapshots, and time anchor information;

[0030] Step 13: Calculate the co-occurrence dependency weights of interface parameters and cache states to establish a parameter-cache dependency chain; calculate the time interval distribution of time-series anchors and business operations to establish a time-series-operation association; and perform topology fusion of the parameter-cache dependency chain and the time-series-operation association with session ID as the hub node to generate an intrinsic traffic feature map.

[0031] In summary, step 11 of this solution calls the "dynamic protocol matching library" to perform protocol type detection on traffic packets. Compared with traditional fixed protocol parsing, this approach can more flexibly adapt to diverse online protocol environments and reduce feature loss due to protocol mismatch. This design of "dynamic protocol matching" is not a natural extension of the traditional "fixed rule parsing" approach, but rather introduces a dynamic adaptation mechanism to address the specific bottleneck of "protocol diversity under multi-module interaction dependencies," thereby covering a wider range of traffic scenarios. Furthermore, step 12 of this solution performs "multi-dimensional feature layered extraction" based on metadata and payload, proactively acquiring three types of information: interface parameters, local cache snapshots, and time anchors. Compared with traditional single-dimensional extraction, this approach can more comprehensively cover dynamic elements that influence the logical flow of online business. This deliberate extraction of "cache snapshots and time anchors" is a result of breaking through the limitations of the traditional "focusing only on interface parameters" mindset. It is necessary to recognize the crucial role of these implicit elements in restoring business scenarios, rather than simply following the traditional "explicit parameter extraction" logic. Finally, step 13 of this solution establishes a "parameter-cached dependency chain" by calculating co-occurrence dependency weights, establishes a "time-series-operation association" by analyzing time interval distributions, and performs "topology fusion" using session IDs as the hub to integrate fragmented features into a holistic graph reflecting business logic relationships. Compared to traditional fragmented processing, this approach more systematically reconstructs the scenario logic of multi-element linkages in online business. This "topology fusion" design is not an optimization of the traditional "element stacking" approach, but rather introduces a correlation modeling and fusion mechanism to address the "feature correlation under multi-module interaction dependencies," thereby reflecting the integrity of the business scenario.

[0032] Optionally, step 2, generating a minimum feature test unit set based on the feature map, specifically includes: performing feature hashing on the feature map to generate a unique hash value for the parameter combination; eliminating duplicate parameter combinations by comparing hash values ​​to obtain a collapsed feature subset; then performing scene primitive extraction on the collapsed feature subset to obtain scene primitives; and finally, filtering out scene primitives that support the core business process through business logic dependency analysis to generate a minimum feature test unit set including several test units.

[0033] In summary, this solution generates a unique hash value for each parameter combination through "feature hashing," and then accurately eliminates duplicates through hash comparison to obtain a collapsed feature subset. This processing is not the traditional "simple parameter filtering," but rather addresses the bottleneck of "difficulty in efficiently determining duplicate parameters" by introducing a hash value as a unique identifier for parameter combinations—traditional methods struggle to quickly determine whether parameter combinations are completely identical, while hashing transforms complex parameter combinations into a single hash value, significantly reducing the difficulty of comparison. Furthermore, this solution uses "scenario primitive extraction" to decompose the parameter combinations in the collapsed feature subset into "parameter combination units reflecting a single business behavior," ensuring that each primitive corresponds to an independent behavior in actual business. This "decomposition" is not the traditional "parameter splitting," but rather addresses the "unclear binding between parameter combinations and business scenarios" by proposing the concept of "scenario primitives"—focusing on "a single business behavior as the smallest effective granularity of the test unit," rather than following the traditional "parameter combination integrity-oriented" approach, thus achieving a more accurate association between parameters and business scenarios. Finally, this solution uses "business logic dependency analysis" to calculate the "dependency contribution value" and "execution frequency ratio" of each scenario primitive in the core business process, and selects the primitive generation test units that truly support the core process. This selection is not a traditional "sorting," but rather addresses the bottleneck of "disconnect between traditional priorities and actual business logic" by combining "business logic dependency" with "coreness," rather than simply relying on preset priorities, and is based on the actual business logic.

[0034] Optionally, step 2 involves performing feature hashing on the feature map to generate unique hash values ​​for parameter combinations. Duplicate parameter combinations are then eliminated through hash value comparison to obtain a collapsed feature subset. This subset is then processed to extract scene primitives, and scene primitives supporting core business processes are selected through business logic dependency analysis to generate a minimal feature test unit set including several test units. Specifically, this includes the following steps:

[0035] Step 21: Perform feature dimension weighted encoding on the parameter combinations in the feature map to calculate the unique hash value corresponding to the parameter combination. Then, remove parameter combinations with duplicate hash values ​​by using the unique hash value to generate a collapsed feature subset.

[0036] Step 22: Call the preset business scenario label mapping rule library, perform business scenario label mapping processing on each parameter combination in the collapsed feature subset, and generate a set of scenario primitives;

[0037] Step 23: Call the core weight calculation model to calculate the dependency contribution value and execution frequency ratio of each scenario primitive in the scenario primitive set in the core business process to generate the minimum feature test unit set.

[0038] In summary, step 21 of this solution first calculates the weight coefficients of each feature dimension using "feature dimension weighted encoding," and then performs a hash operation based on the weights to generate a unique hash value. Compared to traditional methods, weighted encoding makes the hash value more reflective of the "essential business characteristics" of the parameter combination: for example, core parameters (such as order amount) have a higher weight than secondary parameters (such as log number). Even if the secondary parameters are different, combinations with repeated core parameters will still generate the same hash value and be accurately removed; while combinations with different core parameters but the same secondary parameters will be identified as valid difference combinations and retained. This processing method is not a simple extension of traditional hash deduplication. It addresses the issue of "different contribution levels of different feature dimensions to the business scenario," breaking through the inherent thinking of "treating all fields equally." By assigning weights, it makes deduplication more closely aligned with actual business needs, significantly reducing redundancy while retaining valid scenarios. Furthermore, step 22 of this solution first calls the business scenario tag mapping rule library to associate parameter combinations with actual business scenarios (e.g., mapping the parameter combination "product ID + purchase quantity + shipping address" to the "create order" scenario tag). Then, it performs "minimum granularity decomposition" on the parameter combinations of each scenario to obtain scenario primitives reflecting a single business behavior. Compared to traditional methods, this processing transforms the test unit from a "parameter set" into a "business behavior unit": for example, the traditional solution might treat the mixed parameters of "create order + payment" as a test unit, while this solution can decompose them into two scenario primitives, "create order" and "payment," each corresponding to a single business behavior. This design requires proposing the concept of "scenario primitives," breaking through the traditional approach of "focusing on parameter integrity," establishing the association between parameters and scenarios through tag mapping, and then restoring the essence of business behavior through minimum granularity decomposition, making the test unit more closely aligned with actual online business logic. Finally, step 23 of this solution calls the core weight calculation model to calculate the core weight by combining "dependency contribution value" (the irreplaceability of the scenario primitive in the core process) and "execution frequency ratio" (actual online call frequency), thus filtering out core scenario primitives with weights higher than the threshold. Compared to traditional methods, this filtering logic shifts from "preset static priority" to "business dynamic logic driven": for example, the "order payment" primitive, due to its high dependency contribution value and high execution frequency ratio in the core process, will be given a high weight and prioritized for retention; while the "log query" primitive, due to its low weight, will be reasonably filtered. This design requires combining "business logic dependency" with "online execution data" to construct a core weight model, breaking through the limitations of "subjective judgment," ensuring that the test unit focuses on the core business process, and improving the stability of core functions after system iteration.

[0039] Optionally, step 21 specifically involves: performing feature dimension weighted encoding on the parameter combinations in the feature map to calculate the weight coefficients of each dimension of the features in the parameter combination; then performing a hash operation on the parameter combination based on the weight coefficients to generate a unique hash value corresponding to each parameter combination and obtain a parameter combination-hash value mapping table; and then traversing and comparing the hash values ​​in the parameter combination-hash value mapping table one by one to remove parameter combinations that correspond to duplicate hash values ​​in order to generate a collapsed feature subset.

[0040] In summary, step 21 of this solution first performs "feature dimension weighted encoding" on the parameter combinations in the feature map, calculating the weight coefficient of each dimension feature—core dimensions (such as business identifiers and operation types) have higher weight coefficients, while secondary dimensions (such as temporary identifiers and log information) have lower weight coefficients. Compared to traditional methods, this processing amplifies the "essential business features" of the parameter combinations and weakens secondary differences: for example, "Product ID=1001+User Level=VIP+Request Sequence Number=A" and "Product ID=1001+User Level=VIP+Request Sequence Number=B" will show high similarity after weighted encoding due to the high weight of the core dimension, laying the foundation for more accurate deduplication in the subsequent process; while "Product ID=1001+User Level=VIP" and "Product ID=1001+User Level=Ordinary" will show significant differentiation after weighted encoding due to the difference in the core dimension "User Level". This design addresses the issue of varying contributions of different feature dimensions to business scenarios, moving beyond simply comparing all fields equally. By assigning weighted values, it makes parameter processing more aligned with business logic. This is not merely a simple coding optimization, but a deep integration of "business feature priority." Furthermore, step 21 of this solution performs a hash operation based on weighted encoding. The resulting unique hash value better reflects the "business essence consistency" of parameter combinations: for parameter combinations with the same core dimension, even if secondary dimensions differ, the weighted hash value will still tend to be consistent, allowing for more accurate identification and elimination of duplicates; for parameter combinations with different core dimensions, even if secondary dimensions are highly similar, the weighted hash value will remain different, preserving effective scenarios. For example, a large number of "repeated purchase requests for the same product" in online traffic differ only in temporary parameters. Traditional hashing would generate multiple different hash values, leading to redundancy. However, the weighted hashing in step 21 can identify these as duplicate combinations and eliminate them, significantly reducing redundancy. Simultaneously, "regular purchases and discounted purchases of the same product" will generate different hash values ​​due to differences in core dimensions, ensuring sufficient scenario coverage. This process is not a simple replacement of the hash algorithm, but rather a reconstruction of the hash value generation logic through "weighted pre-processing", which upgrades the deduplication logic from "data-level consistency" to "business-level consistency".

[0041] Optionally, step 22 specifically involves: based on the collapsed feature subset, calling a preset business scenario label mapping rule library to perform business scenario label mapping processing on each parameter combination in the collapsed feature subset, so as to associate the parameter combination with the actual business scenario and obtain a parameter combination-business scenario mapping table; performing minimum granular decomposition processing on the parameter combination corresponding to each business scenario in the parameter combination-business scenario mapping table to obtain parameter combination units reflecting a single business behavior, so as to generate a scenario primitive set.

[0042] In summary, step 22 of this solution calls the "Business Scenario Tag Mapping Rule Library" to bind parameter combinations with actual business scenarios (e.g., mapping the above parameter combination to the "New User Exclusive Purchase" tag using "User Registration Time + Product Discount Identifier"). Compared to traditional methods, this processing transforms parameter combinations from "isolated data" into "scenario-based data": for example, after associating with the "Promotional Discount Scenario" tag, the test unit can naturally adapt to dynamic features such as "Discount Rule Cache Verification" and "Time-Limited Trigger Logic" under this scenario without additional configuration. This design is not simply parameter labeling; it addresses the fact that "the business scenario attributes of parameters are the core of reproducing online dynamic features," breaking through the "emphasis on data integrity and neglect of scenario relevance" approach. By establishing a strong association between data and scenarios through tags, it significantly improves the fit of test cases to online scenarios. In addition, step 22 of this solution performs "minimum granularity decomposition" of parameter combinations for each scenario, breaking down mixed parameters into parameter units that reflect single business behaviors (e.g., decomposing the mixed parameters of "Browse + Add to Cart + Place Order" into "Product Browsing Parameter Unit," "Add to Cart Inventory Verification Parameter Unit," and "Order Submission Parameter Unit"). Compared to traditional methods, this approach allows test units to more accurately correspond to single business behaviors, enabling the independent verification of the logic of each functional node. For example, for the "add to cart inventory verification" unit, its interaction logic with the local cache can be specifically tested, unaffected by other parameters such as "browse" and "place order." This design introduces the concept of "scenario primitives," matching "a single business behavior is the basic unit covering complex scenarios," overcoming the limitations of the traditional approach of "using the complete business process as the testing granularity." By decomposing and restoring the atomicity of business behaviors, test cases become more targeted in covering complex scenarios.

[0043] Optionally, step 23 specifically involves: calling the core degree weight calculation model to calculate the dependency contribution value and execution frequency ratio of each scenario primitive in the scenario primitive set in the core business process, and obtaining the core degree weight of each scenario primitive; selecting scenario primitives with core degree weights greater than a preset threshold from the scenario primitive set based on the core degree weights to form a core scenario primitive subset; and performing test unit attribute encapsulation processing on each scenario primitive in the core scenario primitive subset to generate a minimum feature test unit set.

[0044] In summary, step 23 of this solution invokes the coreity weight calculation model to quantify the coreity of scenario primitives from two dimensions: "dependency contribution value" and "execution frequency ratio." The dependency contribution value reflects the irreplaceability of the scenario in the core business process (e.g., "payment verification" is a direct dependency of "order completion," resulting in a high contribution value); the execution frequency ratio reflects the actual online activity level of the scenario (e.g., the frequency of "product search" is much higher than that of "exporting historical orders"). Compared to traditional methods, this quantification method shifts the determination of core scenarios from "subjective experience" to "objective data-driven": for example, although "new user real-name authentication" has a low execution frequency, it is a necessary prerequisite for the payment process, resulting in a high dependency contribution value, and will still be judged as a core scenario; while "modifying personal signature," although a high-frequency operation, has no direct dependency on the core business process, resulting in a low contribution value, and will be judged as a non-core scenario. This design addresses the fact that "scenario coreity is a comprehensive result of 'irreplaceability of dependency' and 'actual activity,'" breaking through the "single-dimensional subjective judgment." In addition, step 23 of this solution first selects scenario primitives with a core weight greater than a preset threshold to form a core subset, and then encapsulates the test unit attributes. Compared with traditional methods, this approach achieves a balance between "efficiency" and "core coverage": selecting the core subset can significantly eliminate non-core scenarios, reduce test unit redundancy, and significantly improve test execution efficiency; at the same time, because the selection is based on objective core metrics, key scenarios of core business processes are less likely to be missed, ensuring more comprehensive coverage. Test unit attribute encapsulation gives each core scenario primitive standardized test attributes (such as unique identifiers and business scenario tags), laying the foundation for "more accurate binding of test units and functional nodes" in the subsequent step 3—for example, the encapsulated "payment verification" test unit can be directly associated with the functional nodes of the payment module through business tags, avoiding mapping deviations caused by missing attributes in traditional test units. This design requires linking "selection" and "encapsulation" to achieve "selection for focusing on the core, and encapsulation for subsequent association and adaptation," breaking through the traditional limitation of "selection and subsequent processing being disconnected," and balancing efficiency and coverage quality through a closed-loop design of "selection-encapsulation."

[0045] Optionally, step 3, generating a test unit-function node binding matrix based on the pre-set list of function nodes in the business system and the minimum feature test unit set, specifically includes: based on the pre-set list of function nodes in the business system, tracing the function nodes covered by each test unit in the minimum feature test unit set by parsing the call path, so as to establish the mapping relationship between test units and function nodes, and generating a test unit-function node binding matrix accordingly.

[0046] In summary, step 3 of this solution achieves "dynamic and objective matching" of relationships by "analyzing the test unit call path to trace the coverage nodes." Regardless of whether the test unit is generated based on real online traffic or a subsequently added parameter combination, all functional nodes are traced back by parsing its actual execution call path (such as service call sequences and interface interaction logs). Compared to traditional methods, this approach makes the mapping relationship more closely match the actual execution logic of the test unit. For example, if the "product ordering" test unit triggers a discount due to parameters, the call path will include a "discount calculation" node, which can be automatically associated during tracing. If "inventory deduction" is not triggered due to insufficient inventory, no association is established because the call path does not contain this node. This design takes into account that "the actual coverage nodes of the test unit are determined by the execution path, not by a pre-defined document," breaking through "static subjective annotation" and shifting the association logic from "human judgment" to "data-driven" through call path parsing. Furthermore, step 3 of this solution solidifies the mapping relationship into a "test unit-functional node binding matrix," presenting the association status in a two-dimensional matrix (row dimensions represent test units, column dimensions represent functional nodes, and cell values ​​indicate whether an association exists). Compared to traditional methods, this presentation method makes the coverage status more systematic and traceable: First, the overall coverage status is intuitively visible. The "0-value distribution" of the matrix columns allows for quick identification of uncovered nodes, while the "1-value distribution" of the rows allows for determination of the coverage range of individual test units. Second, it provides a standardized data carrier for subsequent coverage calculations. When calculating the functional coverage dimension values ​​in step 4, column-level statistics (such as the number of columns with 1 values) can be directly performed based on the matrix, eliminating the need for secondary processing and reducing statistical errors. Third, it supports dynamic updates of relationships. When adding test units or adjusting functional nodes, only adding or deleting matrix rows / columns or modifying cell values ​​is required. This design transforms "discrete relational records" into a "structured matrix," realizing that "the core of coverage assessment is the system's presentation of relational status, not just simple recording." It breaks through the traditional limitations of "list-style registration," achieving "visualization, computability, and updability" of relational relationships through matrix design, providing fundamental support for subsequent coverage calculations and test optimization.

[0047] Optionally, step 3, based on the pre-set list of functional nodes in the business system, traces the functional nodes covered by each test unit in the minimum feature test unit set by parsing the call path, in order to establish a mapping relationship between test units and functional nodes, and generates a test unit-functional node binding matrix accordingly, including the following steps:

[0048] Step 31: Perform structured annotation of the functional node attributes on the pre-set list of functional nodes in the business system to determine the call path fingerprint of each test unit and trace the functional nodes covered by each test unit accordingly.

[0049] Step 32: Check whether the functional nodes associated with each test unit exist in the pre-set list of functional nodes in the business system, remove test unit records with invalid associated functional nodes, establish the mapping relationship between test units and functional nodes, and generate a test unit-functional node binding matrix accordingly.

[0050] In summary, step 31 of this solution constructs a standardized tracing system through "structured annotation of functional node attributes + determination of call path fingerprints": First, the unique ID, input / output parameters, and dependency conditions of each functional node are annotated to form a structured attribute table, clarifying the "triggerable features" of the nodes; then, a call chain graph is constructed based on node dependencies, service sequences are extracted by parsing test unit call logs and path fingerprints are generated, and finally, the fingerprints are matched to trace the covered nodes. Compared to traditional methods, this approach shifts tracing from "subjective and vague judgment" to "objective standard matching": for example, the "payment verification" node is annotated with the dependency condition "user real-name authentication status = authenticated". If the test unit call path fingerprint does not contain a "real-name authentication" service sequence, it can be clearly determined that the node is not covered; while traditional methods may misjudge coverage simply because it "includes a payment interface". This design addresses the core of "accurate tracing lies in 'standardized node features' and 'quantifiable paths'", breaking through the reliance on "experience and scattered information". By combining structured annotation and path fingerprints, it provides a foundation for more accurate association and constructs a standardized system for comprehensive tracing. Furthermore, step 32 of this solution ensures the validity of associations through "association verification + invalid record removal": first, it checks whether the nodes associated with each test unit are within the system's preset valid list, removing test units associated with obsolete or erroneous nodes; then, it generates a binding matrix based on valid association records. Compared to traditional methods, this approach significantly reduces the interference of invalid associations on the evaluation: for example, after the system iteration deletes the "old version inventory deduction" node, step 32 will identify and remove the test units associated with this node to prevent them from being included in coverage statistics; while the traditional method would retain these invalid records, leading to misjudgments that "the inventory deduction node has been covered" during evaluation. This design addresses the fact that "the 'validity' of associations is more important than 'quantity'," breaking through the traditional limitation of "only building associations without verification," and ensuring the "business validity" of association records through verification and removal. Especially in the context of frequent system iterations, this approach ensures that the binding matrix always matches the current business nodes, providing reliable data for subsequent coverage calculations, which is a key guarantee for the "authenticity of coverage evaluation."

[0051] Optionally, step 31 specifically includes the following steps:

[0052] Step 311: Perform structured annotation of the functional node attributes on the pre-set list of functional nodes in the business system, annotating the unique identifier ID, business module to which each functional node belongs, input parameter definition, output parameter definition, and node execution dependency conditions to generate a functional node attribute table;

[0053] Step 312: Based on the functional node attribute table, determine the sequential calling relationship between functional nodes according to the node execution dependency conditions, and construct a functional node call chain graph by using directed edges to represent dependencies and nodes to represent functional nodes.

[0054] Step 313: Based on the functional node call link graph, perform call path log parsing processing on each test unit in the minimum feature test unit set, extract the service call sequence, interface call parameters and return results during the execution of the test unit, and generate a test unit call sequence table;

[0055] Step 314: Perform a hash operation on the string form of each service call sequence in the test unit call sequence table to generate a call path fingerprint corresponding to each service call sequence;

[0056] Step 315: Based on the call path fingerprint, match the corresponding functional node sequence in the functional node call chain graph to trace the functional nodes covered by each test unit, so as to generate a test unit-covered functional node correspondence table.

[0057] In this application, a structured attribute table is generated by labeling each functional node with its unique identifier ID, module, input / output parameters, and execution dependencies. Compared to traditional methods, this process makes the "traceability characteristics" of functional nodes comprehensive and standardized: the triggering conditions, data requirements, and module to which each node belongs are clearly defined, avoiding ambiguity in traceability caused by missing information. For example, the attribute table of the "inventory deduction" node can clearly present "input product ID + inventory value, dependent on order creation node, belonging to inventory module," providing a unified reference for subsequent judgment on whether the test unit has truly triggered the node. This design standardizes node information from the "source," solving the fundamental problem of "no standard to follow" in traditional traceability. In this application, based on the execution dependencies in the attribute table, directed edges represent dependencies, and nodes represent functional nodes, constructing a call chain graph. Compared to traditional methods, this process transforms scattered functional nodes into a "linked model" that fits the business logic: the order of nodes and direct / indirect dependencies are explicitly presented through the graph, intuitively reflecting "which node is a prerequisite and which node is a subsequent step." For example, the chain of "payment verification → inventory deduction → order confirmation" is clearly visible in the graph. If a test unit calls "inventory deduction" without executing "payment verification," the graph can quickly identify the incomplete chain it doesn't cover. This design makes the implicit logic between nodes explicit, solving the key problem of "no logical basis" in traditional tracing. This application extracts service call sequences, interface parameters, and return results by parsing the call path logs of the test unit, generating a call sequence table. Compared to traditional methods, this processing replaces "review" with "log parsing," objectively and completely restoring the actual execution path of the test unit: both cross-module service calls and dynamic parameter changes can be recorded relatively accurately. For example, when the "order payment" test unit is executed, the sequence table can completely record the service sequence of "user verification - payment verification - inventory deduction - order confirmation" and the parameters of each stage, avoiding omissions or deviations in the review. This design shifts the acquisition of the execution path from "subjective memory" to "objective data," improving the completeness of the path information. This application performs hash operations on the service call sequence to generate a unique call path fingerprint. Compared to traditional methods, this processing transforms "textualized call sequences" into "quantified fingerprint identifiers": different call sequences (even with similar interface names) generate different fingerprints, while the same sequence generates a consistent fingerprint. For example, the sequences "payment verification (success)" and "payment verification (failure retry)" are different, and their fingerprints are also different, allowing for a more accurate match between the corresponding functional node links. This design provides a "unique quantitative basis" for matching execution paths with functional nodes, reducing ambiguity in matching similar paths. This application uses path fingerprints to match corresponding node sequences in the functional node call link graph, generating a test unit-coverage functional node correspondence table.Compared to traditional methods, this processing achieves a more accurate "path-to-link" association, rather than "single interface-to-single node": the complete execution path (fingerprint) of the test unit can be matched with the corresponding complete node link in the graph, ensuring that each covered node is accurately identified. For example, the fingerprint of "payment verification - inventory deduction" can be matched with two corresponding node sequences in the graph, and the generated correspondence table will completely record these two covered nodes. This design extends the coverage relationship from "single node" to "node link," improving the completeness of coverage tracing.

[0058] Optionally, step 32 checks whether all functional nodes associated with each test unit exist in the pre-set list of functional nodes in the business system, removes test unit records associated with invalid functional nodes, and establishes a mapping relationship between test units and functional nodes to generate a test unit-functional node binding matrix. This specifically includes the following steps:

[0059] Step 321: Perform mapping relationship verification on the test unit-covered function node correspondence table, check whether the function nodes associated with each test unit exist in the preset function node list of the business system, remove test unit records associated with invalid function nodes, and generate a valid test unit-function node mapping relationship table.

[0060] Step 322: Based on the effective test unit-functional node mapping relationship table, construct a two-dimensional matrix. The row dimension of the matrix is ​​the test units in the minimum feature test unit set, and the column dimension is the functional nodes preset by the business system. Fill the matrix cells with binary values ​​to generate the test unit-functional node binding matrix.

[0061] This application verifies the mapping of a "test unit-coverage function node correspondence table" by checking whether each associated node is in a preset valid list, removing test unit records associated with invalid nodes, and generating a valid mapping table. Compared to traditional methods, this process purifies the relationships from the "source": only test units associated with valid nodes are retained, avoiding interference from obsolete or erroneous nodes on coverage evaluation. For example, the aforementioned "offline payment reconciliation" old node will be identified as invalid, and the test unit record associated with this node will be removed, ensuring that every association in the mapping table corresponds to a valid function of the current system. This design shifts the relationship establishment from "extensive" to "more accurate purification," providing more reliable basic data for subsequent coverage evaluation. This application constructs a two-dimensional matrix based on the valid mapping table, with rows corresponding to test units and columns corresponding to function nodes, and fills the cells with binary values ​​(e.g., "1" indicates association, "0" indicates no association). Compared to traditional methods, this processing transforms coverage status from "scattered records" to "systematic visualization": First, the overall coverage situation is immediately apparent; uncovered nodes can be quickly identified through the "0-value distribution" in the column dimension, and the coverage range of individual test units can be clearly seen through the "1-value distribution" in the row dimension. Second, cross-relationships are intuitively verifiable; for example, a cell with a value of "1" directly reflects that "the corresponding test unit covers the corresponding node," eliminating the need for retrieval. Third, it provides a standardized data carrier for the subsequent step 4, coverage dimension calculation, allowing direct statistical analysis based on matrix column dimensions without secondary processing, resulting in higher efficiency. This design transforms discrete relationships into a structured matrix model, solving the problems of traditional coverage status being "difficult to statistically analyze and not intuitive."

[0062] Optionally, step 4, generating functional coverage dimension values ​​based on the test unit-functional node binding matrix, specifically includes: performing coverage dimension calculation processing on the test unit-functional node binding matrix to count the number of functional nodes with established mapping relationships in the test unit-functional node binding matrix, calculating the proportion of the number of functional nodes to the total number of functional nodes in the system, and generating functional coverage dimension values ​​accordingly.

[0063] In this application, by performing coverage dimension calculation on the test unit-functional node binding matrix, the number of functional nodes with established mapping relationships in the matrix is ​​counted, realizing a systematic statistical analysis of the coverage of functional nodes. Compared with the traditional method of only targeting preset high-priority nodes or randomly and sporadically counting coverage nodes by module, it has the technical advantage of being able to more comprehensively grasp the coverage of the test unit to the overall functional nodes. It is especially suitable for enterprise-level business systems with many functional nodes and multi-module interactions, avoiding the bias in coverage judgment caused by the omission of low-priority but key related nodes in traditional sporadic statistics.

[0064] In this application, the functional coverage dimension value is generated by calculating the ratio of the number of functional nodes with established mapping relationships to the total number of functional nodes in the system. This achieves a quantitative presentation of the functional coverage status. Compared with the traditional method of only qualitatively describing or listing covered nodes as "covered / uncovered", this method has the technical advantage of allowing the technical team to more intuitively perceive the overall coverage adequacy. It solves the problem that the coverage degree cannot be quantitatively measured in traditional qualitative assessments, and provides a quantitative basis for subsequent judgment on whether additional test elements are needed. This method is suitable for the high accuracy requirements of coverage assessment in system iteration.

[0065] In this application, by relying on the test unit-functional node binding matrix to carry out coverage dimension calculation, the linkage between coverage statistics and node association relationship is realized. Compared with the traditional technology where coverage statistics and test unit-node association records are processed independently, it has the technical advantage of reducing the risk of coverage statistics being out of touch with the actual association status. It avoids the problem of coverage statistics distortion caused by untimely updates of association records in traditional technology. It is especially suitable for scenarios where system functional nodes are dynamically iterated, making the matching degree between coverage dimension values ​​and actual business coverage higher.

[0066] Optionally, step 4 involves calculating the coverage dimension of the test unit-functional node binding matrix to count the number of functional nodes with established mapping relationships in the matrix, calculating the ratio of this number to the total number of functional nodes in the system, and generating the functional coverage dimension value accordingly. This process includes the following steps:

[0067] Step 41: Perform column-dimensional validity verification on the test unit-functional node binding matrix to count the number of functional nodes with established mapping relationships in the test unit-functional node binding matrix and generate a statistical value of the total number of valid functional nodes in the system.

[0068] Step 42: Call the preset functional node business module mapping rule library to construct a module-test unit sub-matrix for each business module to perform coverage dimension calculation and obtain a module-level coverage statistics table;

[0069] Step 43: Call the module core weight calculation model to assign core weights to each business module in the module-level coverage statistics table to generate weighted statistics of covered nodes;

[0070] Step 44: Based on the weighted statistics of covered nodes and the statistics of the total number of effective functional nodes in the system, calculate the ratio of the number of functional nodes to the total number of functional nodes in the system, and generate the functional coverage dimension value accordingly.

[0071] In this application, by validating the column dimensions of the test unit-functional node binding matrix, eliminating functional nodes without complete attribute information, and counting the total number of valid nodes, the calibration of the basic data for coverage calculation is achieved. Compared with the traditional method of directly counting the total number of nodes without validating the validity of functional nodes, this method has the technical advantage of making the calculation basis of functional coverage dimension values ​​more reliable. It is suitable for statistical interference scenarios caused by some functional nodes being abandoned due to iteration or missing information in enterprise-level business systems, and avoids the misleading effect of invalid nodes on coverage evaluation results.

[0072] In this application, a modular and refined statistical analysis of coverage status is achieved by constructing a sub-matrix for each module and generating a module-level coverage statistics table by calling the functional node business module mapping rule library. Compared with the traditional method of only performing a general statistical analysis of the overall system functional coverage, this method has the technical advantage of being able to more accurately locate the coverage shortcomings of specific business modules. It solves the problem that traditional overall statistics cannot distinguish the coverage differences of each module in multi-module interaction scenarios, and provides a clearer direction for subsequent targeted supplementation of test elements.

[0073] In this application, the contribution and frequency of modules in the core business process are analyzed by calling the module core weight calculation model. Weights are assigned to each module and weighted statistical values ​​of covered nodes are generated. This achieves the adaptation of coverage statistics to business priorities. Compared with the traditional method of assigning equal weights to all business modules to statistical coverage, it has the technical advantage of making the functional coverage dimension values ​​more in line with the core business needs. In particular, it is suitable for scenarios in enterprise-level systems where the impact of core modules and non-core modules on system stability is very different, avoiding the misjudgment that non-core modules are fully covered but core modules are insufficiently covered.

[0074] In this application, the proportion is calculated based on the weighted statistical value of covered nodes and the total number of effective nodes in the system, and the results are corrected by range verification. This achieves the generation of coverage dimension values ​​that are closer to the actual business priorities. Compared with the traditional method of directly calculating the unweighted coverage proportion without range calibration, this method has the technical advantage of making the functional coverage dimension values ​​more reasonable and better reflecting the coverage quality of core businesses. It avoids the problem of coverage evaluation distortion caused by not considering module priorities or range out of control in traditional calculations, and provides a basis for test optimization that is more in line with business priorities.

[0075] Optionally, step 41: Perform column-dimensional validity validation on the test unit-functional node binding matrix to count the number of functional nodes with established mapping relationships in the test unit-functional node binding matrix and generate a statistical value of the total number of valid functional nodes in the system, specifically including:

[0076] Step 411: Traverse the functional nodes corresponding to the test unit-functional node binding matrix, check whether each column dimension functional node has complete attribute information, remove column dimensions without complete attribute information and corresponding functional nodes, retain valid column dimensions and corresponding functional nodes to generate the calibrated test unit-functional node binding matrix.

[0077] Step 412: Perform column dimension mapping statistics on the calibrated test unit-functional node binding matrix, count the number of functional nodes with at least one cell value of 1 in the column dimension, and generate a statistical value of the number of functional nodes with established mapping relationships; at the same time, perform a full count on the pre-set functional node list of the business system, record the total number of functional nodes with complete attribute information, and combine it with the statistical value of the number of functional nodes with established mapping relationships to generate a statistical value of the total number of effective functional nodes in the system.

[0078] In this application, by traversing the column dimension functional nodes of the test unit-functional node binding matrix, checking and removing nodes and corresponding column dimensions without complete attribute information, a calibrated matrix is ​​generated, which realizes the purification of the basic data for coverage calculation. Compared with the traditional method of directly using the original matrix without validating the validity of nodes for statistics, it has the technical advantage of reducing the interference of invalid nodes on coverage statistics. It is suitable for the statistical deviation scenario caused by some functional nodes being abandoned or missing information in the iteration of enterprise-level business systems, making the basis for subsequent coverage dimension value calculation more reliable.

[0079] In this application, by performing column dimension mapping statistics on the calibrated matrix, the number of functional nodes with at least one cell value of 1 is obtained. At the same time, the total number of nodes with complete attribute information in the preset functional node list is fully counted to generate a statistical value of the total number of effective functional nodes in the system. This achieves a more accurate matching and statistical analysis of the number of covered nodes and the total number of effective nodes. Compared with the traditional technology that only counts the number of covered nodes and uses all nodes in the system (including invalid nodes) as the total number to calculate the proportion, this method has the technical advantage of making the denominator of the functional coverage dimension value more in line with the actual effective functional range. It avoids misjudgment of the degree of coverage caused by the inclusion of invalid nodes in the denominator and adapts to scenarios where there is a difference between the number of effective functional nodes and the total number of nodes in the system.

[0080] Optionally, step 42: Call the preset functional node business module mapping rule library to construct a module-test unit sub-matrix exclusive to each business module for coverage dimension calculation to obtain a module-level coverage statistics table, specifically including the following steps:

[0081] Step 421: Call the preset functional node business module mapping rule library, classify the effective column dimension functional nodes of the calibrated test unit-functional node binding matrix according to their respective business modules, and form a module-functional node grouping table;

[0082] Step 422: For each business module in the module-functional node grouping table, extract the column dimension of the corresponding module in the calibrated test unit-functional node binding matrix, and construct a module-test unit sub-matrix for each business module. The row dimension of the module-test unit sub-matrix is ​​the test unit, and the column dimension is the functional node under the test unit.

[0083] Step 423: Perform coverage dimension calculation processing on each module-test unit submatrix, count the number of column dimensions with a cell value of 1 in the submatrix, and generate a module-level coverage statistics table, which includes the business module name, the total number of functional nodes in the module, and the number of covered functional nodes in the module.

[0084] In this application, by calling a preset functional node business module mapping rule library, the effective functional nodes of the calibrated matrix are classified according to their respective business modules to form a module-functional node grouping table. This achieves modular organization of functional nodes. Compared with the traditional technology that does not classify functional nodes according to business modules and directly performs coverage statistics on the whole system, this method has the technical advantage of clearly defining the scope of functional nodes corresponding to each business module. It is suitable for enterprise-level business systems with multiple modules working together and functional nodes of each module intertwined, laying the foundation for more accurate analysis of module coverage in the future.

[0085] In this application, by extracting the column dimensions of the corresponding modules based on the module-functional node grouping table, a dedicated module-test unit sub-matrix is ​​constructed for each business module, achieving module-level focus of coverage statistics. Compared with the traditional method of using only the system-level overall matrix for coverage calculation and being unable to split each module for independent analysis, it has the technical advantages of isolating the coverage data of each business module and avoiding data interference between modules. It solves the problem of mutual confusion of the coverage of multiple modules in traditional overall matrix analysis and is suitable for enterprise-level system scenarios where multiple modules interact frequently but the responsibility boundaries of each module are clear.

[0086] In this application, by performing coverage calculations on each module-test unit submatrix, counting the number of column dimensions with a cell value of 1, and generating a module-level coverage statistics table containing the module name, total number of nodes, and number of covered nodes, a module-level quantitative presentation of coverage status is achieved. Compared with the traditional technology that only outputs the total number of covered nodes in the system and lacks detailed module-level statistics, it has the technical advantage of being able to intuitively grasp the sufficiency of coverage within each business module. It avoids the problem in traditional overall statistics that some modules may not be covered while the overall coverage data may seem reasonable, thus providing a clear basis for targeted optimization of test cases for each module.

[0087] Optionally, step 43: Invoke the module core weight calculation model to assign core weights to each business module in the module-level coverage statistics table to generate weighted statistics of covered nodes. This includes the following steps:

[0088] Step 431: Call the module core weight calculation model to analyze the execution frequency of business modules in the core business process and their correlation with core business indicators, output the module core weight coefficient of each business module, and form a module core weight coefficient table.

[0089] Step 432: Based on the module-level coverage statistics table and the module core weight coefficient table, multiply the number of covered functional nodes in each business module by the corresponding module core weight coefficient to obtain the weighted number of covered nodes for each module; sum the weighted number of covered nodes for all business modules to generate a weighted number of covered node statistics.

[0090] In this application, by calling the module core weight calculation model, the execution frequency of each business module in the core business process and its correlation with the core business indicators are analyzed, and the module core weight coefficients are output and a coefficient table is formed. This realizes the differentiated adaptation of module weights. Compared with the traditional technology of using a uniform weight or no weight for all business modules, this method has the technical advantage of making the weight allocation more in line with the priority of the business process. It adapts to scenarios in enterprise-level business systems where different modules have significantly different support roles for the core business, and solves the problem of treating the coverage of core modules and non-core modules equally in traditional statistics.

[0091] In this application, by multiplying the number of covered functional nodes of each module by the corresponding weight coefficient, and then summing the weighted results of all modules to generate a weighted statistical value of covered nodes, a weighted integration of coverage data is achieved. Compared with the traditional method of simply adding up the number of covered nodes of each module as the total coverage statistical value, this method has the technical advantage of making the coverage statistical results more reflective of the coverage quality of core business. It avoids the misjudgment scenario in the traditional simple summation where the total coverage data seems good when non-core modules are fully covered but core modules are not. This provides a reliable basis for more accurate assessment of the coverage of core business.

[0092] Optionally, step 44: Based on the weighted statistics of covered nodes and the statistics of the total number of effective functional nodes in the system, calculate the ratio of the number of functional nodes to the total number of functional nodes in the system, and generate the functional coverage dimension value accordingly. This includes the following steps:

[0093] Step 441: Based on the weighted covered node statistics and the total number of effective functional nodes in the system, calculate the ratio of the weighted covered node statistics to the total number of effective functional nodes in the system to obtain the initial functional coverage dimension value;

[0094] Step 442: Perform range validation on the initial functional coverage dimension value. If the initial functional coverage dimension value is greater than 1, correct it to 1. If the initial functional coverage dimension value is less than 0, correct it to 0 to generate the final functional coverage dimension value.

[0095] In this application, the initial functional coverage dimension value is obtained by calculating the ratio of the weighted covered node statistics and the total number of effective functional nodes in the system. This achieves a dual binding between the coverage dimension value and the quality of core business coverage and the scope of effective functions. Compared with the traditional method of directly calculating the ratio by the unweighted number of covered nodes and the total number of functional nodes in the system, this method has the technical advantage of making the initial coverage dimension value more consistent with the actual coverage of core business and the boundaries of effective functions. It is suitable for scenarios in enterprise-level systems where core modules need to be given priority consideration and some functional nodes are invalid due to missing information. This method solves the problem in traditional statistics where the coverage of core modules is insufficient but the ratio seems reasonable due to the large base number of total nodes.

[0096] In this application, by performing range verification on the initial functional coverage dimension values, values ​​greater than 1 or less than 0 are corrected to 1 or 0 respectively to generate the final values, the reasonableness calibration of the coverage dimension values ​​is achieved. Compared with the traditional method of directly using the calculated original proportion as the final result without processing out-of-range values, this method has the technical advantage of making the final functional coverage dimension values ​​more consistent with the actual coverage logic. It avoids the situation where the coverage dimension values ​​exceed the reasonable range of 0-1 due to weighted calculation errors or statistical boundary issues, and ensures that the evaluation results are a reference for the technical team to optimize test cases.

[0097] Optionally, step 5, based on the functional coverage dimension value, generates corresponding supplementary parameter combinations by reverse parsing the logical dependencies between functional nodes to synchronously update the minimum feature test unit set and the test unit-functional node binding matrix, specifically includes: based on the functional coverage dimension value, for functional nodes without established mapping relationships, generating corresponding supplementary parameter combinations by reverse parsing their logical dependencies to update the minimum feature test unit set and synchronously update the test unit-functional node binding matrix.

[0098] In this application, for functional nodes without established mapping relationships, supplementary parameter combinations are generated by reverse parsing their logical dependencies, achieving deep coupling between supplementary parameters and business logic. For enterprise-level business systems with complex logic such as local caching and parameter dependencies, and multi-module interaction relationships, traditional technical solutions often supplement test elements by randomly generating parameter combinations or reusing historical unrelated interface parameters when facing insufficient coverage. These parameters often deviate from the actual logical dependencies of the nodes to be supplemented, making it difficult to adapt to complex business scenarios. This step, however, generates parameters by reverse tracing the logical dependency chain of unmapped nodes, ensuring that the supplementary parameter combinations align with the calling rules and data transfer logic between nodes. This improves the adaptability of supplementary test elements to complex business scenarios to a certain extent, alleviating the bottleneck of test parameters being disconnected from business logic in traditional solutions.

[0099] In this application, after generating supplementary parameter combinations, the minimum feature test unit set and the test unit-functional node binding matrix are updated synchronously, realizing the linkage and collaboration between the test execution carrier and the coverage evaluation carrier. Traditional technical solutions often only update the test case set after supplementing test elements, without synchronously updating the core carrier used for coverage evaluation (such as the binding matrix). This results in the functional coverage evaluation results always lagging behind the actual test status and failing to accurately reflect the true coverage of business functions. The dual-carrier synchronous update design in this step allows the coverage of test units to match the mapping relationship of the matrix in real time, making the functional coverage evaluation results more in line with the actual test progress. This approach adapts to the requirement in the background technology that "system iteration needs to efficiently support functional consistency verification" and alleviates the technical bottleneck of the disconnect between coverage evaluation and actual testing in traditional solutions.

[0100] Optionally, step 5, based on the functional coverage dimension value, generates corresponding supplementary parameter combinations for functional nodes without established mapping relationships by reverse parsing their logical dependencies, in order to update the minimum feature test unit set and synchronously update the test unit-functional node binding matrix, specifically including the following steps:

[0101] Step 51: Filter target function nodes based on function coverage dimension values ​​and construct an inverse dependency graph of unmapped nodes;

[0102] Step 52: Based on the reverse dependency graph of unmapped nodes, reversely resolve logical dependencies and generate a supplementary parameter combination set;

[0103] Step 53: Based on the supplementary parameter combination set, synchronously update the minimum feature test unit set and the test unit-function node binding matrix.

[0104] Step 51 filters target nodes based on functional coverage dimension values ​​and constructs a reverse dependency graph for unmapped nodes, achieving integrated positioning of uncovered nodes and their logical relationships. Background technology clearly indicates that enterprise-level systems have complex relationships such as multi-module interaction dependencies and node execution dependencies. Traditional technical solutions, when discovering insufficient coverage, often only filter uncovered nodes by node name or number, without sorting out the logical dependencies between nodes, resulting in a lack of clear logical anchors when supplementing test elements. This step, however, first accurately identifies the nodes to be supplemented based on coverage dimension values, and then presents the relationship between nodes and their predecessor dependencies through a reverse dependency graph, transforming "isolated nodes" into "related node chains." This approach aligns with the logical characteristics of complex business systems and alleviates the bottleneck of disconnect between uncovered node positioning and logical sorting in traditional solutions.

[0105] Step 52 generates supplementary parameter combinations based on reverse dependency graph reverse parsing, achieving adaptation between supplementary parameters and business logic transmission rules. Traditional technical solutions often use fixed templates or directly reuse historical parameters from unrelated scenarios when generating supplementary parameters. These parameters do not consider the parameter transmission rules between the node to be supplemented and its predecessor nodes, making it difficult to adapt to dynamic features in scenarios such as "local caching and parameter linkage" and "multi-module parameter flow." This step, however, derives parameter combinations adapted to the node to be supplemented from the valid parameters of already mapped nodes by tracing the parameter transmission rules along the dependency path. This ensures that the supplementary parameters align with the logical relationships between nodes, improving the matching degree between supplementary parameters and complex business scenarios to a certain extent and solving the problem of disconnect between traditional parameter generation and business logic.

[0106] Step 53 synchronously updates the minimum feature test unit set and the test unit-functional node binding matrix, achieving coordinated consistency between the test execution vehicle and the coverage evaluation vehicle. Traditional technical solutions, after supplementing test elements, often only update the test case set without synchronously updating the core matrix used for coverage calculation. This results in the calculation of functional coverage dimension values ​​still being based on old mapping relationships, and the evaluation results failing to reflect the latest test status. This step, however, encapsulates the supplementary parameters into test units and synchronously updates the mapping relationships in the matrix, ensuring that the coverage of the test units aligns in real time with the statistical logic of the evaluation vehicle. This approach addresses the background technology's requirement for "efficiently supporting functional consistency verification during system iteration," alleviating the technical bottleneck of the disconnect between coverage evaluation and actual test progress in traditional solutions.

[0107] Optionally, step 51: Filter target function nodes based on function coverage dimension values, and construct an unmapped node reverse dependency graph, specifically including:

[0108] Step 511: Perform threshold judgment processing on the functional coverage dimension value. If the functional coverage dimension value is less than the preset coverage threshold, start the unmapped node filtering process to perform column dimension traversal detection processing on the test unit-functional node binding matrix. Traverse all functional nodes corresponding to the column dimensions of the matrix, filter out the functional nodes corresponding to the column dimensions where all row dimension cell values ​​are 0, and extract the unique identifier ID, input parameter definition, output parameter definition and business module to which these functional nodes belong to generate a list of functional nodes to be supplemented.

[0109] Step 512: Based on the list of functional nodes to be supplemented, call the functional node dependency parsing module to parse the node execution dependency rules preset by the business system, determine the direct and indirect predecessor dependency nodes (predecessors of direct predecessor dependency nodes) of each functional node to be supplemented, and mark the dependency type. With the functional node to be supplemented as the target node, the predecessor dependency node as the associated node, and the directed edge with the dependency type identifier as the dependency relationship, construct the unmapped node reverse dependency graph.

[0110] Step 511 triggers the filtering of unmapped nodes based on a threshold value for the functional coverage dimension. This, combined with column-dimensional traversal of the test unit-functional node binding matrix, allows for more targeted filtering of uncovered nodes. In the background, enterprise-level systems require efficient support for iterative verification. Traditional solutions often use a full traversal of the functional node list to filter uncovered nodes, failing to dynamically adjust the filtering timing based on actual coverage levels. This can lead to ineffective filtering even when coverage is sufficient, resulting in resource waste. This step, however, first determines whether coverage is insufficient based on a threshold value for the coverage dimension, initiating filtering only when coverage is insufficient. Furthermore, the standard of "all row cells having a value of 0" in the matrix column dimension accurately locates nodes without mapping. Simultaneously, it extracts core attributes such as node ID and parameter definitions to generate a list, providing complete attribute support for subsequent processing. Compared to the traditional method of full traversal and only recording node names, this approach better meets the system iteration's need for efficient and accurate filtering.

[0111] Step 512 parses direct and indirect prerequisite dependencies based on the list of nodes to be supplemented and constructs a reverse dependency graph, achieving a full-link presentation of the logical relationships of uncovered nodes. For complex scenarios where enterprise-level systems clearly have multi-module interaction dependencies and multi-level dependencies between nodes, traditional technical solutions, when analyzing the dependencies of uncovered nodes, often only extract direct prerequisite dependencies, without tracing indirect dependencies or labeling dependency types, resulting in a lack of complete logical relationship basis when supplementing test elements. This step, however, through the functional node dependency parsing module, fully identifies the direct and indirect prerequisite dependencies of each node to be supplemented, labels the dependency types, and visualizes the "target node - associated node - dependency relationship" in the form of a reverse graph, making the logical relationship link of uncovered nodes clearer. This approach aligns with the multi-level dependency characteristics of complex business systems, alleviating the bottleneck of incomplete dependency analysis in traditional solutions that leads to subsequent parameter generation deviating from business logic.

[0112] Optionally, step 52: Based on the reverse dependency graph of unmapped nodes, reverse resolve logical dependencies to generate a supplementary parameter combination set, specifically including:

[0113] Step 521: Perform reverse path tracing processing on the reverse dependency graph of unmapped nodes. Starting from each functional node to be supplemented, traverse backwards along the directed edges to the functional nodes that have been mapped. Record the predecessor dependent nodes, dependency types and parameter passing rules on each reverse path to generate a reverse dependency path parameter rule table.

[0114] Step 522: Based on the reverse dependency path parameter rule table, extract the test units associated with the established mapping function nodes from the test unit-function node binding matrix, obtain the parameter combinations of these test units, and generate the parameter set associated with the mapped nodes.

[0115] Step 523: Based on the reverse dependency path parameter rule table and the parameter set associated with mapped nodes, perform constraint adaptation processing on the parameters in the parameter set associated with mapped nodes to adjust the parameter values ​​according to the parameter passing rules, supplement the input parameters specific to the functional nodes to be supplemented, and verify whether the parameters conform to the input parameter definition of the functional nodes to be supplemented, so as to generate a set of supplementary parameter combinations.

[0116] Step 521 performs reverse path tracing on the reverse dependency graph of unmapped nodes, recording the preceding dependent nodes, dependency types, and parameter passing rules to generate a rule table, thus realizing the construction of the "logical anchor point" for supplementary parameter generation. Background technology clearly states that enterprise-level business systems have characteristics such as multi-module interaction dependencies and complex parameter passing links. Traditional technical solutions often ignore the parameter passing rules between nodes when generating supplementary parameters, constructing parameters out of thin air based solely on the input parameter definitions of the node to be supplemented, resulting in a disconnect between parameters and business logic requirements. This step, however, traverses backward from the node to be supplemented to the mapped nodes, fully capturing the dependency relationships and parameter flow rules along the path, transforming abstract logical dependencies into executable parameter generation criteria. This approach accurately meets the core requirement in the background technology that "parameters under complex logical relationships must conform to the passing rules," alleviating the bottleneck of traditional solutions lacking logical support for parameter generation.

[0117] Step 522 extracts the test unit parameters associated with mapped nodes from the binding matrix based on the rule table, forming a set of parameters associated with mapped nodes, ensuring the "scenario relevance" of the supplementary parameters. Traditional technical solutions often reuse global historical parameters or apply generic parameter templates when generating supplementary parameters. These parameters are not bound to the associated scenarios of the nodes to be supplemented, easily leading to mismatches between parameters and the current business context. This step, however, uses a rule table obtained through reverse path tracing to more accurately locate the associated nodes with established mappings. It then extracts the valid test unit parameters associated with these nodes from the test unit-functional node binding matrix, ensuring that the parameter source and the business scenario of the node to be supplemented belong to the same logical link. Compared to the generic parameter acquisition method of traditional solutions, this approach better aligns with the scenario characteristics of "local caching and parameter linkage, multi-module interaction dependency" in the background technology.

[0118] Step 523 performs constraint adaptation and verification based on the rule table and parameter set, improving the "validity and adaptability" of the supplementary parameters. In traditional solutions, after generating parameters, there is often a lack of adaptation and adjustment of parameter transmission rules and verification of input definitions, resulting in generated parameters that do not meet node execution requirements and cannot effectively cover unmapped nodes. This step, however, first adjusts the parameter values ​​of mapped nodes according to the parameter transmission rules in the rule table, then supplements the specific input parameters for the node to be supplemented, and finally verifies whether the parameters conform to the input definitions, forming a closed loop of "adjustment-supplementation-verification." This process ensures that the supplementary parameters not only meet the logical transmission requirements but also satisfy the node's own parameter specifications, significantly reducing the probability of invalid parameters compared to the traditional approach of "no targeted verification after generation."

[0119] Optionally, step 53: Based on the supplementary parameter combination set, synchronously update the minimum feature test unit set and the test unit-function node binding matrix, specifically including:

[0120] Step 531: Perform test unit encapsulation processing on each supplementary parameter combination in the supplementary parameter combination set, assign a unique test unit ID to each supplementary parameter combination, associate it with the business scenario tag of the corresponding functional node to be supplemented, and add the encapsulated test unit to the original minimum feature test unit set to generate the updated minimum feature test unit set.

[0121] Step 532: Based on the updated minimum feature test unit set and the list of functional nodes to be supplemented, add a row dimension to the test unit-functional node binding matrix, set the value of the cross cell of the column dimension corresponding to the functional node to be supplemented and the row dimension corresponding to the new test unit to 1, retain the original mapping relationship between test units and functional nodes, so as to generate the updated test unit-functional node binding matrix.

[0122] Step 531 encapsulates the supplementary parameter combinations into test units and associates them with business scenario tags, ensuring that the supplementary test elements have clear business affiliation and traceability. Background technology clearly states that enterprise-level business systems are characterized by intertwined business scenarios and frequent module interactions. Traditional technical solutions often simply add parameter combinations directly to the test case set when supplementing test elements, without encapsulating test unit attributes or associating them with business scenario information. This makes it difficult to locate the specific business scenario corresponding to the supplementary test unit during subsequent test execution, and also results in low reusability. This step, however, assigns a unique test unit ID to each supplementary parameter combination, encapsulates it as a standard test unit, and associates it with the business scenario tag of the functional node to be supplemented. This ensures that the supplementary test unit conforms to the overall test unit specifications and is strongly bound to the specific business scenario. This approach better aligns with the background technology's requirement that "test units in complex business scenarios need to be accurately associated with business logic," alleviating the bottleneck of the traditional solution's disconnect between supplementary test elements and business scenarios.

[0123] Step 532 synchronously updates the test unit set and binding matrix, ensuring consistency between the test execution vehicle and the coverage evaluation vehicle. In the background technology, system iteration requires efficient support for functional consistency verification. Traditional solutions often fail to synchronously update the core matrix used for coverage calculation after updating test cases, resulting in functional coverage dimension values ​​still being calculated based on old mapping relationships, leading to significant deviations between the evaluation results and the actual test coverage. This step, however, immediately adds a corresponding row dimension to the binding matrix after adding a test unit, sets the intersection cell between the functional node to be added and the new test unit to 1, and retains the original mapping relationship, enabling the matrix to reflect the latest association status between test units and functional nodes in real time. This synchronous update logic, compared to the traditional "asynchronous update of test cases and coverage matrix" model, better aligns with the core requirements of "rapidly locating online issues and ensuring iteration stability" in the background technology.

[0124] Figure 2This is a schematic diagram of the structure of a minimum test case generation and functional coverage computing device according to an embodiment of this application. Figure 2 As shown, it includes:

[0125] Feature graph construction module: Generates feature graphs based on real online traffic packets recorded on the AREX platform;

[0126] Unit generation module: Generates a set of minimum feature test units based on the feature map;

[0127] Matrix construction module: Generates a test unit-function node binding matrix based on the pre-set list of functional nodes and the minimum feature test unit set of the business system;

[0128] Coverage calculation module: Generates functional coverage dimension values ​​based on the test unit-functional node binding matrix;

[0129] Parameter update module: Based on the function coverage dimension value, it generates corresponding supplementary parameter combinations by reverse parsing the logical dependencies between function nodes, so as to synchronously update the minimum feature test unit set and the test unit-function node binding matrix.

[0130] Figure 2 For an exemplary explanation of each module, please refer to the above. Figure 1 The details of that record will not be repeated here.

[0131] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for generating minimum test cases and calculating functional coverage, characterized in that, include: Step 1: Generate a feature map based on the real online traffic packets recorded on the AREX platform; Step 2: Perform feature hashing on the feature map to generate a unique hash value for the parameter combination. Eliminate duplicate parameter combinations by comparing hash values ​​to obtain a collapsed feature subset. Then, perform scene primitive extraction on the collapsed feature subset to obtain scene primitives. Finally, filter out the scene primitives that support the core business process through business logic dependency analysis to generate a minimum feature test unit set including several test units. Step 3: Generate a test unit-function node binding matrix based on the pre-set list of functional nodes and the minimum feature test unit set of the business system; Step 4: Generate functional coverage dimension values ​​based on the test unit-functional node binding matrix; Step 5: Based on the functional coverage dimension value, generate corresponding supplementary parameter combinations by reverse parsing the logical dependencies between functional nodes, so as to synchronously update the minimum feature test unit set and the test unit-functional node binding matrix. Step 1, generating a feature map based on real online traffic packets recorded on the AREX platform, specifically includes: Step 11: Call the traffic feature layering parsing module to load the preset dynamic protocol matching library, and perform protocol type detection on the online real traffic packets recorded by the AREX platform to separate the metadata and payload of the real traffic packets. Step 12: Perform multi-dimensional feature layering extraction based on the separated metadata and payload to obtain interface call parameters, local cache snapshots, and time anchor information; Step 13: Calculate the co-occurrence dependency weights of interface parameters and cache states to establish a parameter-cache dependency chain; calculate the time interval distribution of time-series anchors and business operations to establish a time-series-operation association; and perform topology fusion of the parameter-cache dependency chain and the time-series-operation association with session ID as the hub node to generate an intrinsic traffic feature map.

2. The method according to claim 1, characterized in that, The feature map is subjected to feature hashing to generate unique hash values ​​for parameter combinations. Duplicate parameter combinations are eliminated by hash value comparison to obtain a collapsed feature subset. Then, the collapsed feature subset is subjected to scene primitive extraction to obtain scene primitives. Finally, scene primitives supporting the core business process are selected from these primitives through business logic dependency analysis to generate a minimal feature test unit set including several test units. The specific steps are as follows: Step 21: Perform feature dimension weighted encoding on the parameter combinations in the feature map to calculate the unique hash value corresponding to the parameter combination. Then, remove parameter combinations with duplicate hash values ​​by using the unique hash value to generate a collapsed feature subset. Step 22: Call the preset business scenario label mapping rule library, perform business scenario label mapping processing on each parameter combination in the collapsed feature subset, and generate a set of scenario primitives; Step 23: Call the core weight calculation model to calculate the dependency contribution value and execution frequency ratio of each scenario primitive in the scenario primitive set in the core business process, and obtain the core weight of each scenario primitive; based on the core weight, select scenario primitives with core weight greater than the preset threshold from the scenario primitive set to form a subset of core scenario primitives; Each scene primitive in the core scene primitive subset is encapsulated with test unit attributes to generate a minimal feature test unit set.

3. The method according to claim 2, characterized in that, Step 21 specifically involves: performing feature dimension weighted encoding on the parameter combinations in the feature map to calculate the weight coefficients of each dimension of the features in the parameter combination; then performing a hash operation on the parameter combination based on the weight coefficients to generate a unique hash value corresponding to each parameter combination and obtain a parameter combination-hash value mapping table. The hash values ​​in the parameter combination-hash value mapping table are traversed and compared one by one, and parameter combinations corresponding to duplicate hash values ​​are removed to generate a collapsed feature subset.

4. The method according to claim 2, characterized in that, Step 22 specifically involves: based on the collapsed feature subset, calling the preset business scenario label mapping rule library, performing business scenario label mapping processing on each parameter combination in the collapsed feature subset to associate the parameter combination with the actual business scenario, thereby obtaining a parameter combination-business scenario mapping table; performing minimum granular decomposition processing on the parameter combination corresponding to each business scenario in the parameter combination-business scenario mapping table to obtain parameter combination units reflecting a single business behavior, thereby generating a scenario primitive set.

5. The method according to claim 2, characterized in that, Step 23 specifically involves: calling the core weight calculation model to calculate the dependency contribution value and execution frequency ratio of each scenario primitive in the scenario primitive set in the core business process, and obtaining the core weight of each scenario primitive; and selecting scenario primitives with core weights greater than a preset threshold from the scenario primitive set based on the core weights to form a subset of core scenario primitives. Each scene primitive in the core scene primitive subset is encapsulated with test unit attributes to generate a minimal feature test unit set.

6. The method according to claim 1, characterized in that, Step 4: Generate functional coverage dimension values ​​based on the test unit-functional node binding matrix. Specifically, this includes: performing coverage dimension calculation on the test unit-functional node binding matrix to count the number of functional nodes with established mapping relationships in the test unit-functional node binding matrix, calculating the ratio of the number of functional nodes to the total number of functional nodes in the system, and generating functional coverage dimension values ​​accordingly.

7. The method according to claim 1, characterized in that, Step 5: Based on the functional coverage dimension value, generate corresponding supplementary parameter combinations by reverse parsing the logical dependencies between functional nodes to synchronously update the minimum feature test unit set and the test unit-functional node binding matrix. Specifically, based on the functional coverage dimension value, for functional nodes that have not established a mapping relationship, generate corresponding supplementary parameter combinations by reverse parsing their logical dependencies to update the minimum feature test unit set and synchronously update the test unit-functional node binding matrix.

Images