Software testing method and system based on data analysis platform

Abstract

The invention discloses a software testing method and system based on a data analysis platform, and particularly relates to the technical field of software testing, and the method comprises the following steps: tracking business semantic change by constructing a semantic evolution perception map, and establishing a semantic-driven data label linkage mechanism to maintain the consistency of training samples of a defect recognition model; semantic consistency drifting is monitored, model output is controlled, a map-enhanced test case generation mechanism is introduced to achieve semantic synchronous generation, meanwhile, a semantic regression verification process is set to ensure alignment of a test case and evolution semantics, and a closed-loop test process covering a full path is formed; according to the method, semantic-driven label linkage and model synchronous updating are realized by constructing the semantic evolution perception map, and a map-enhanced test case generation and regression verification process is introduced, so that the test process is ensured to be consistent with the service semantic dynamic state, the defect identification accuracy and the test coverage integrity are improved, and the test efficiency is improved. The method is suitable for software quality guarantee in a continuous delivery environment.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically, to a software testing method and system based on a data analysis platform. Background Technology

[0002] As software development models evolve into iterative systems centered on Continuous Integration (CI) and Continuous Delivery (CD), enterprises are placing higher demands on the automation, intelligence, and closed-loop response capabilities of their testing processes. Traditional testing methods mostly rely on static test case libraries and rule-driven models, which are ill-suited to the dynamic environment of rapidly evolving business semantics, coexistence of multiple version interfaces, and frequent semantic drift. This leads to blind spots in test coverage, semantic comprehension biases, and the failure of defect identification models.

[0003] Especially with the widespread application of big data analytics platforms and artificial intelligence technologies, more and more enterprises are introducing defect identification models and automated test case generation mechanisms based on large language models to achieve an automated closed loop from historical defect discovery to end-to-end testing and verification. However, existing solutions generally lack the ability to model and monitor "semantic consistency evolution." Defect identification models and test generation engines are often trained or constructed based on historical static semantics, making it difficult to perceive dynamic changes in semantic dimensions such as business terms, status fields, and user behavior. This easily leads to a "double failure path," namely, model misjudgment plus test omission, which seriously affects delivery quality and online stability.

[0004] Furthermore, current defect identification models behave in a relatively isolated manner within the continuous delivery process, and the semantic alignment between their training samples and actual business states cannot be guaranteed. Even after semantic shifts, they may still output "high-confidence false positives." Additionally, test generation methods based on preset prompts lack a deep coupling mechanism with the business graph, causing test content to lag behind the actual business semantic evolution rhythm. Therefore, this paper proposes a software testing method and system based on a data analysis platform to address the aforementioned problems. Summary of the Invention

[0005] To achieve the above objectives, the present invention provides the following technical solution: The software testing method based on a data analysis platform includes the following steps: Construct a semantic evolution perception graph. Based on business interface fields, state enumeration information and user behavior description information, generate a graph structure covering semantic entities and their evolutionary relationships. Continuously track the historical changes of semantic nodes for semantic consistency comparison and model calibration. Establish a semantic-driven data tag linkage mechanism to map semantic nodes to defect tags. Through automatic inheritance and synchronous updates of tag versions, maintain the consistency between the training samples of the built-in defect recognition model and business semantics. Establish a semantic consistency drift monitoring mechanism. Calculate the semantic consistency deviation index by comparing the current output of the defect identification model with the semantic labels in the graph. When the semantic consistency deviation index exceeds a preset threshold, trigger the model correction task and interrupt its quality judgment function in the continuous delivery process. A graph-enhanced test case generation mechanism is introduced. When constructing test input, active semantic nodes in the current graph are dynamically spliced ​​together, and the automatically generated test cases are synchronized with the current business semantic state, covering all path branches after semantic evolution. Establish a semantic regression verification process to perform semantic alignment verification between automatically generated test cases and semantic evolution graphs, set mandatory consistency judgment rules, and only allow test cases that pass the verification to enter the test execution; for test cases that fail the verification, mark them as pending review and return the correction feedback information to the test case generation mechanism.

[0006] In a preferred embodiment, during the construction of the semantic evolution perception graph, the user behavior description information is semantically decomposed based on natural language processing algorithms to identify key behavioral phrases and upstream and downstream action flow relationships; combined with business interface fields and state enumeration information, the decomposed behavioral fragments are semantically classified and embedded into the graph node structure to establish a behavior-state-interface ternary mapping model; a graph neural network is introduced to vectorize the evolutionary relationships between graph nodes and learn similarity, and is used to dynamically complete the potential relationships between semantic nodes.

[0007] It has a pre-set graph version control mechanism that creates a version snapshot for each graph node change in the semantic evolution perception graph and records the source of the change, the type of change, and the scope of association.

[0008] In a preferred embodiment, the specific steps for establishing a semantic-driven data tag linkage mechanism include: Perform field-level semantic reconstruction on defective data from historical versions, extract context descriptions and label definitions related to the current semantic node, and construct a label semantic vector representation; By comparing the semantic distance between semantic nodes in the current graph and the semantic vectors of historical tags, the system automatically determines whether tags need to be inherited, renamed, split, or discarded, and generates tag version mapping relationships accordingly. A label synchronization update process is constructed. When a semantic node in the graph changes, all related label versions are automatically retrieved and updated to maintain the consistency and timeliness of label semantics in the model training data, and finally realize the dynamic binding of label and semantic evolution.

[0009] When generating the tag version mapping relationship, a corresponding node semantic representation vector is generated for each semantic node in the current graph, and the similarity is calculated with the historical tag semantic vector to obtain the semantic distance matrix. Based on a semantic distance threshold strategy, the semantic association type between tags and nodes is automatically determined, including inheritance, renaming, splitting, or obsolescence, and a tag version mapping table is constructed accordingly.

[0010] In a preferred embodiment, when establishing a semantic consistency drift monitoring mechanism, the semantic labels, confidence scores and their corresponding timestamps involved in the prediction output of the defect identification model are first extracted. At the same time, the semantic node content of the current version, the time of the most recent change and the evolution path information are retrieved from the semantic evolution perception map to construct a label correspondence matrix. The textual semantic similarity between the model-predicted labels and the graph labels is calculated. The cosine similarity of word vectors is used as the basic index, and the label change time difference and model confidence offset value are integrated. A unified semantic consistency deviation score is generated through a pre-set linear weighted model. When the semantic consistency deviation score is higher than the preset threshold, a model calibration task is immediately generated and the output of the model in the current continuous delivery process is interrupted from participating in the quality judgment logic.

[0011] In a preferred embodiment, the preset linear weighted model refers to: The following three metrics are extracted from the prediction results of the defect identification model: Semantic similarity S represents the cosine similarity between the text vectors of the model output label and the semantic nodes in the graph; Label change time difference T represents the difference between the current time and the last change time of the label; Model confidence score difference C represents the absolute difference between the confidence score of the current predicted label and the historical mean of the label. The formula for calculating the semantic consistency deviation score D is as follows: D = α × (1 - S) + β × normalize(T) + γ × C; where α, β, and γ are all preset non-zero weight parameters that satisfy α + β + γ = 1, and normalize(T) is a preset time difference normalization function that maps the time difference to the interval [0, 1].

[0012] In a preferred embodiment, the introduction of a graph-enhanced test case generation mechanism refers to: Based on the semantic evolution graph, extract the set of semantic nodes that are active in the current version, identify their corresponding input parameter fields, state transition conditions and upstream and downstream dependencies, and construct a semantic-driven input structure template. The input structure template is embedded in the test case generation process, and the input variants under different semantic paths are combined and expanded to generate test input descriptions that cover different state branches. The generated test input descriptions and semantic nodes are validated by path mapping. Each test case corresponds to a valid semantic path branch, ultimately forming a set of test cases that are synchronized with the current business semantic state.

[0013] In a preferred embodiment, during semantic regression verification, semantic extraction is performed on each automatically generated test case to extract the operation actions, input field names and expected responses contained therein, generate semantic content description units, and match them with the context semantic labels of each node in the semantic evolution graph. Based on the consistency verification results of semantic description, the connectivity verification results of graph path, and the validity verification results of the current version of node status, the mandatory consistency judgment rule is executed to determine whether the test cases are consistent with the current business semantics. Test cases that fail the verification will be blocked from entering the test execution process. Misaligned semantic content units are identified, and the deviation relationship between them and the target node is converted into feedback information and transmitted to the test case generation mechanism.

[0014] In a preferred embodiment, the software testing system based on the data analysis platform specifically includes: The graph construction module is used to generate a graph structure covering semantic entities and their evolutionary relationships based on business interface fields, state enumeration information and user behavior description information, and continuously track the historical changes of semantic nodes to support semantic consistency comparison and model calibration operations. The data tag linkage module is used to establish a mapping relationship between semantic nodes and defect tags, and maintain the consistency between the training samples of the built-in defect recognition model and the current business semantics through the automatic inheritance and synchronous update mechanism of tag versions. The drift monitoring module is used to compare the matching degree between the current output of the defect identification model and the semantic labels of the graph, and calculate the semantic consistency deviation index. When the deviation index exceeds the preset threshold, the model correction task is automatically triggered and the quality judgment function of the model in the continuous delivery process is interrupted. The test case generation module is used to dynamically stitch together active semantic nodes in the current graph when constructing test input content, so that the automatically generated test cases are synchronized and aligned with the current business semantic state, covering the complete path branches after semantic evolution; The semantic regression verification module is used to perform semantic alignment verification between automatically generated test cases and semantic evolution graphs, and sets mandatory consistency judgment rules to allow only verified test cases to enter the test execution process; for test cases that fail verification, they are marked as pending review and the correction feedback information is returned to the test case generation module.

[0015] The technical effects and advantages of this invention are as follows: This invention constructs a semantic evolution awareness graph. Based on the structured extraction and semantic modeling of business interface fields, state enumeration information, and user behavior description information, it generates a graph structure covering semantic entities and their evolutionary relationships. This enables continuous tracking and structured representation of every change in business semantics during version evolution. This graph not only records the evolutionary path of semantic nodes but can also be used for subsequent semantic consistency comparisons and input calibration of defect identification models. It avoids model input misleading or semantic understanding deviations caused by minor changes in state naming, field definitions, or behavior descriptions, thereby achieving semantically transparent control and evolution tracking in a continuous delivery environment and enhancing the dynamic adaptability of the testing system to business updates.

[0016] This invention establishes a semantically driven data tag linkage mechanism. By establishing a one-to-one mapping relationship between semantic nodes and defect tags, and combining this with automatic inheritance and synchronous update logic of tag versions, it achieves a high degree of consistency maintenance between the training samples of the defect identification model and the current business semantics. In actual continuous delivery scenarios, defect tags often lag behind semantic evolution, causing the training model to use historical samples with outdated semantics, which can easily lead to prediction drift. This invention, through its mechanism, automatically links the tag data with the synchronous change logic of the semantic graph, effectively solving the semantic gap problem between training data and the actual business state, and improving the stability and accuracy of the defect identification model in dynamic business contexts.

[0017] This invention introduces a graph-enhanced test case generation mechanism and a semantic regression verification process, forming a complete semantic alignment closed loop from test case construction to pre-execution verification. This ensures that each automatically generated test case remains synchronized with the current semantic state. By dynamically concatenating active semantic nodes during test input construction, a set of test cases covering all paths after semantic evolution is generated. Combined with subsequent semantic alignment verification and mandatory consistency rules, test cases with semantic inconsistencies or broken paths are eliminated, and the correction feedback information is returned to the test case generation mechanism for secondary optimization. This process effectively avoids test omissions, redundancy, and misjudgments, and is particularly suitable for large-scale continuous delivery systems with high-frequency deployment and rapid changes, significantly improving testing efficiency and semantic coverage accuracy. Attached Figure Description

[0018] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings; Figure 1 This is a schematic diagram of the software testing method based on a data analysis platform in this invention.

[0019] Figure 2 This is a schematic diagram of the software testing system based on a data analysis platform in this invention. Detailed Implementation

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

[0021] Reference Figure 1 - Figure 2 The following examples were obtained: Example 1: A software testing method based on a data analysis platform, comprising the following steps: A semantic evolution awareness graph is constructed. Based on business interface fields, state enumeration information, and user behavior description information, a graph structure covering semantic entities and their evolutionary relationships is generated. Historical changes of semantic nodes are continuously tracked for semantic consistency comparison and model calibration. This step provides semantic infrastructure for the entire testing process, solving the problem that traditional testing cannot perceive interface and behavior changes. By introducing semantic entities and evolutionary relationships, a knowledge graph with temporal awareness and contextual structure is formed, providing a unified semantic alignment reference for subsequent model judgment, data annotation, and test case generation. Continuous tracking of semantic node changes supports dynamic updates to test targets, enabling adaptation to version changes and laying a structural foundation for model drift monitoring and semantic consistency verification.

[0022] A semantically driven data label linkage mechanism is established, mapping semantic nodes to defect labels. Through automatic inheritance and synchronous updates of label versions, the consistency between the training samples of the built-in defect recognition model and business semantics is maintained. This linkage between labels and semantics addresses the disconnect between business semantic changes and model training samples. By establishing a mapping relationship, the consistency between historical labels and the current semantic scenario is ensured, avoiding mislabeling or misjudgment caused by semantic drift. The version inheritance mechanism enables structural tracking and evolutionary mapping of labels, allowing the model to continue training and predicting based on semantically consistent samples even when facing semantic updates, thereby improving model robustness and the intelligence of testing.

[0023] A semantic consistency drift monitoring mechanism is established. This mechanism calculates a semantic consistency deviation index by comparing the current output of the defect identification model with the semantic labels in the graph. When the semantic consistency deviation index exceeds a preset threshold, a model correction task is triggered, and its quality assessment function in the continuous delivery process is interrupted. Dynamically comparing the model output with the semantic baseline allows for real-time detection of whether the model has failed due to semantic evolution, serving as a key safeguard mechanism in intelligent testing. The semantic consistency deviation index, as the core metric for quantifying drift, can promptly reflect the risk of a decline in the model's semantic perception capability. The threshold triggering mechanism not only enables automatic correction task scheduling but also prevents potentially erroneous results from entering the release process, effectively reducing the deployment risk caused by quality assessment errors.

[0024] A graph-enhanced test case generation mechanism is introduced. When constructing test input, active semantic nodes in the current graph are dynamically pieced together, synchronizing the automatically generated test cases with the current business semantic state and covering all path branches after semantic evolution. By deeply integrating the semantic graph with test case generation, the generation logic is synchronized with business semantics. Traditional test case generation is often based on static rules or templates, which cannot adapt to changes in semantic structure, resulting in coverage blind spots. This mechanism identifies active semantic nodes, constructs input structure templates, and expands the path based on the evolution path, ensuring that the generated test cases are complete, dynamically adaptable, and structurally reasonable. It is particularly suitable for the automated testing needs of complex, multi-state business processes.

[0025] A semantic regression verification process is established to perform semantic alignment verification between automatically generated test cases and the semantic evolution graph. Mandatory consistency rules are set to allow only valid test cases to enter test execution. Test cases that fail verification are marked as pending review, and correction feedback information is returned to the test case generation mechanism. A closed-loop control mechanism for test semantics is constructed to ensure that all executed test cases are highly consistent with the current business semantics. Semantic alignment verification not only detects whether test cases cover the correct path but also filters out erroneous test cases caused by semantic offsets. Mandatory consistency rules prevent test cases that do not conform to the current version's semantics from mistakenly entering the execution process, ensuring test accuracy. The feedback mechanism supports the self-optimization of the generation logic, forming a closed-loop learning system from generation to verification, improving the intelligence level and coverage quality of the test case generation engine.

[0026] In constructing the semantic evolution perception graph, natural language processing algorithms are used to semantically decompose user behavior descriptions and identify key behavioral phrases and their upstream and downstream action flow relationships. Specifically, behavioral descriptions from product prototypes, interaction documents, test case annotations, and user feedback logs are input into a contextual semantic model trained using Bidirectional Encoder Representation (BERT). Each behavioral description undergoes word segmentation, part-of-speech tagging, and dependency analysis to identify key behavioral phrases with operational intent. For example, in the sentence "After the user clicks the submit button, they are redirected to the confirmation page," two key action nodes, "click the submit button" and "redirect to the confirmation page," are extracted. Combined with syntactic dependencies, a sequential relationship between these two nodes can be determined, forming a pair of upstream and downstream action flows. Through semantic analysis of a large number of behavioral sentences, a set of user behavior action pairs is generated, laying the foundation for subsequent structural mapping.

[0027] By combining business interface fields and status enumeration information, the decomposed behavior fragments are semantically categorized and embedded into the graph node structure to establish a behavior-state-interface ternary mapping model. Specifically, for each behavior action, relevant fields are searched in the interface definition using a field matching method (e.g., the interface corresponding to a button click is POST / submitForm), and the enumerated states before and after the behavior are identified in the system status table (e.g., "Form filling in" before clicking, "Form submission in" after clicking). This forms a structured triple: Click the submit button (POST / submitForm). The form is being submitted. All triples, serving as core information components of the graph nodes, are uniformly encoded into the graph structure to support subsequent semantic path generation and state transition analysis. If multiple actions map to the same interface field or state transition path, they will be clustered and categorized based on semantic weights to avoid redundancy in the graph structure.

[0028] A graph neural network is introduced to vectorize and model the evolutionary relationships between graph nodes and learn similarity, which is then used to dynamically complete the potential relationships between semantic nodes. The specific operations include: first, constructing an adjacency matrix and a node feature vector table, where the feature vectors are derived from the semantic encoding of the aforementioned behavioral phrases, interface parameter summaries, and embedded representations of state identifiers. The graph structure is then input into a graph attention network (GAT), utilizing a multi-head attention mechanism to learn the association strength between nodes. During training, interface change paths in actual business versions are used as labels to achieve supervised learning. The trained graph neural network model can predict the evolutionary probability between nodes that are not explicitly connected, thus completing the potential connections between semantic nodes. For example, if there is no direct connection between "jump to payment page" and "confirm order status" in the graph, but the model predicts their association exceeds 0.85, the edge can be automatically completed to enhance semantic connectivity.

[0029] In constructing a semantic evolution-aware graph, to achieve automatic identification and dynamic completion of latent semantic relationships in the graph structure, graph neural networks can be introduced to vectorize and model the evolutionary relationships between graph nodes and learn similarity. This method, based on the graph structure data modeling capabilities and the representation learning advantages of deep learning, can effectively capture the implicit associations and contextual semantic evolution trends between semantic nodes. This allows for the discovery of node pairs in the graph that are not explicitly edged but semantically coupled, enabling edge completion operations and improving the graph's expressive completeness and structural accuracy.

[0030] The fundamental principle of graph neural networks lies in the iterative propagation mechanism that aggregates and computes the structural and semantic features of each graph node with information from its neighboring nodes to generate a node embedding representation with contextual awareness. In this method, each semantic node in the graph is considered a graph node in the graph neural network, and its initial feature representation consists of three dimensions: first, the semantic vector of the behavioral phrase represented by the node, obtained through natural language processing methods (such as the BERT encoder); second, the structural feature vector obtained by hash embedding of the business interface field corresponding to the node; and third, the state position information vector mapped by the node's state enumeration identifier. These three types of vectors are combined through concatenation or weighted summation to form the input feature vector of each semantic node.

[0031] In terms of graph structure, the semantic evolution-aware graph is converted into a weighted directed graph structure. The direction of the edges represents the sequence of semantic evolution, and the edge weights can represent auxiliary features such as the strength of semantic relationships or call frequency between nodes. After construction, this graph structure and node features are input into a graph neural network, using a graph attention network (GAT) as the backbone. GAT uses a multi-head attention mechanism to calculate the attention weights between each node and its neighboring nodes. In each round of propagation, the information of neighboring nodes is weighted and aggregated to achieve deep fusion of semantic context. During the network training phase, confirmed semantic connections in historical business versions are used as positive samples, and unconnected but logically unrelated node pairs are used as negative samples to construct a connection prediction task. The cross-entropy loss function is used to optimize the connection prediction score, enabling the model to learn the connection probability between node pairs.

[0032] After training, the model will output the connection similarity score between each pair of nodes. For example, for semantic node A ("fill in address") and node B ("submit order"), if there is no connection between them in the graph, but the model calculates a connection similarity of 0.92 (far higher than the set threshold of 0.7), then this edge can be considered a potential connection and dynamically added to the graph. The completion operation is not limited to single-edge connections, but can also be extended to path prediction to discover missing intermediate nodes or abnormal broken chains. By introducing graph neural networks to model the relationships between nodes, not only is the graph's ability to express complex semantic paths improved, but it can also achieve automatic adaptation and predictive completion of semantic structures in new business scenarios, providing a more stable and reliable structural foundation for subsequent test case generation, path coverage calculation, and semantic consistency analysis.

[0033] A pre-defined graph version control mechanism is in place to create a version snapshot for every change in a graph node within the semantic evolution awareness graph, recording the source of the change, the type of change, and the associated scope. Specifically, whenever the graph structure is updated (e.g., a node is added, deleted, or an edge relationship is changed), a version snapshot is recorded, along with the source of the change event (e.g., interface documentation update, state definition change, new connection added in model prediction), the type of change (addition, modification, deletion), and the range of affected semantic nodes. The version snapshot data structure uses an incremental storage design, supporting difference tracking and time-series backtracking, enabling the system to quickly switch and compare between different versions. For example, if an abnormal test result can be traced back to a structural break in graph version V15, it can be rolled back to version V14 to recalibrate the test path. This version control mechanism effectively addresses the semantic change risks brought about by rapid business iterations, ensuring the timeliness and consistency of the test structure.

[0034] The specific steps for establishing a semantically driven data tag linkage mechanism include: Field-level semantic reconstruction is performed on defect data from historical versions to extract contextual descriptions and label definitions related to the current semantic node, and a label semantic vector representation is constructed. Data samples of defects labeled from multiple past versions are selected, and the label name, exception description, associated interface fields, triggering behavior, and system response content are extracted from each defect record. Natural language processing models (such as BERT or RoBERTa) are used to encode the above text, generating a contextual semantic vector for each label. For example, if a historical record is described as "Order payment failed, interface returned 403 error," its label is "Payment failed." The system encodes its associated fields, such as / order / pay, and status, such as "Payment in progress," into a semantic vector representation of the label. Simultaneously, each semantic node in the current semantic evolution perception graph is encoded in the same way to form a node semantic representation vector, providing a basic semantic space for subsequent comparisons.

[0035] By comparing the semantic distance between semantic nodes in the current graph and the semantic vectors of historical labels, the system automatically determines whether labels need to be inherited, renamed, split, or discarded, and generates label version mapping relationships accordingly. A label synchronization update process is constructed: when a semantic node in the graph changes, all associated label versions are automatically retrieved and updated. The update process includes three parts: first, version mapping backtracking, tracing all historical semantic nodes corresponding to the current label; second, a change detection mechanism, detecting whether graph node attributes have changed in name, semantic content, or positional structure; and third, automatic label update operation, automatically revising the label's version number, name, classification path, and its binding record in the training data. The updated label is written into a new training sample set and marked with the source version number for subsequent model training or incremental updates. For example, if the original node "Order Submission" in the graph is updated to "Order Confirmation," the system automatically updates the label to "Confirmation Anomaly" based on its mapping relationship with the original label "Submission Anomaly," while retaining the label mapping record and establishing a pointing relationship from the old label to the new label.

[0036] By maintaining the consistency and timeliness of the semantic meaning of labels in the model training data, the system ultimately achieves a dynamic binding between labels and semantic evolution. After completing the label synchronization update, the system reconstructs the label index of the training samples and verifies whether each piece of training data references the current version of the label. If a label lag, missing mapping, or semantic shift is found, the sample is automatically removed or relabeled to avoid erroneous training interfering with the model's prediction accuracy. Through the linkage mechanism of the above steps, not only is the dynamic binding between labels and semantic nodes achieved, but a traceable, iterative, and clearly structured label evolution system is also established, significantly improving the adaptability and robustness of the defect identification model in complex semantic environments.

[0037] When generating tag version mapping relationships, a corresponding node semantic representation vector is generated for each semantic node in the current graph, and similarity is calculated with historical tag semantic vectors to obtain a semantic distance matrix. Based on a semantic distance threshold strategy, the semantic association type between tags and nodes is automatically determined, including inheritance, renaming, splitting, or abandonment, and a tag version mapping table is constructed accordingly. A corresponding node semantic representation vector is generated for each semantic node in the current graph as the basic representation for tag matching. Specific operations include: extracting the semantic element set of all semantic nodes in the graph structure, including the node's name, descriptive fields, the name of the interface to which it belongs, triggering conditions, and business context state information. The above content is uniformly encoded into structured semantic fragments, and each fragment is context-vectorized and encoded using a natural language pre-trained model (such as BERT or RoBERTa). The encoded results will use a weighted aggregation strategy, setting the semantic name weight to 0.4, the interface field weight to 0.3, the state information weight to 0.2, and the behavior description weight to 0.1, to calculate a comprehensive semantic vector. For example, for the node "Initiate a refund request", its interface is POST / refund / apply, its status is "Transaction closed", and its behavior is "User-initiated operation", then the generated vector combination is the semantic representation of this node.

[0038] The semantic representation vectors of nodes are paired with the semantic vectors of historical labels to calculate semantic similarity and generate a semantic distance matrix. Cosine similarity is used as the metric, and each element in the matrix represents the semantic fit between the current graph node and a historical label. For example, if the node "refund application" has a similarity of 0.84 with the label "return failed" and a similarity of 0.93 with the label "refund failed," these are recorded as the corresponding values ​​in the matrix. During the comparison process, the similarity sets between the label and multiple nodes are also recorded to facilitate subsequent handling of label splitting or merging scenarios. This matrix ultimately serves as the matching baseline between labels and semantic nodes, used to classify label states.

[0039] Based on a semantic distance threshold strategy, the semantic association type between tags and nodes is automatically determined. Semantic similarity is divided into intervals according to a set threshold, for example, a high threshold of 0.90 and a low threshold of 0.70. If the similarity between a tag and a node is higher than 0.90, it is considered "semantically consistent," and the tag can be directly inherited by that node. If the similarity is between 0.70 and 0.90, and the node has undergone renaming, interface changes, or state expansion, the tag is marked as "needs renaming." If multiple nodes have similarities with the same tag in the middle range (e.g., 0.75, 0.78, 0.79), the system determines that the tag's semantics may be shared by multiple nodes and performs a "splitting" operation, splitting the original tag into multiple sub-tags, which are then bound to the corresponding nodes. If a tag has no match in any node (e.g., similarity below 0.70), it is marked as "discarded." Taking the tag "Order Abnormality" as an example, if its matching degree with the nodes "Order Unconfirmed", "Insufficient Inventory", and "Missing Delivery Address" is 0.76, 0.73, and 0.74 respectively, then the system will split the tag into "Order Confirmation Abnormality", "Inventory Abnormality", and "Address Abnormality".

[0040] Based on the judgment results, a tag version mapping table is constructed, and the tag change history is recorded. The tag version mapping table includes the original tag name, change type (inheritance, renaming, splitting, obsolescence), new tag name (if applicable), target semantic node ID, mapping effective version number, and creation timestamp. Simultaneously, a unique version number is assigned to each tag, such as in the format "TAG2025-09-V3.1," which includes the year, month, and semantic graph version number index, ensuring the traceability of tags across multiple graph versions. This mapping table is not only used for the synchronous update of tags in model training data but also serves as a basis for tag evolution auditing, facilitating developers, testers, and model maintainers to track the tag lifecycle. For example, the tag "Payment Failure" is renamed to "Transaction Interruption" in graph V3.0 and simultaneously split into "Payment Interface Anomaly" and "Transaction Verification Failure," forming multiple records in the mapping table, ensuring that subsequent training tasks can switch to the correct tag according to the graph version.

[0041] When establishing a semantic consistency drift monitoring mechanism, semantic labels, confidence scores, and corresponding timestamps are extracted from the prediction output of the defect identification model and associated with the current node in the semantic evolution awareness graph. Specifically, the defect identification model is built using a multi-layer bidirectional Transformer architecture. The input is structured text from automated test logs, including interface names, response times, and exception messages. The model output is the semantic label with the highest confidence probability and its probability value (i.e., confidence score). Simultaneously, a timestamp is generated for each prediction result record for comparison with graph change records. The semantic evolution awareness graph stores semantic node information for all current business versions, including node descriptions, interface bindings, status information, the most recent change time, and evolution path context. Using business interface IDs and label name indexing, a preliminary mapping is established between the labels in the prediction results and the nodes in the graph, and a label-to-relationship matrix is ​​constructed.

[0042] The textual semantic similarity between the model's predicted labels and the graph labels is calculated. A pre-trained language model encoding method (such as BERT or SimCSE) is used to vectorize the semantic content of both the predicted labels and the graph nodes, obtaining the cosine similarity between each vector pair, defined as semantic similarity S. Taking "transaction interrupted" and "payment failed" as an example, a textual semantic similarity of 0.68 indicates a certain deviation. Furthermore, the label change time difference T is calculated, i.e., the time difference (in days) between the current time and the most recent change time of the graph node, to measure the activity level of semantic evolution. Simultaneously, the historical confidence score of the predicted label (e.g., the average of the last 100 predictions is 0.91) is calculated and subtracted from the current prediction confidence score (e.g., 0.76), yielding the model confidence shift value C = |0.76 - 0.91| = 0.15. These three indicators together serve as the basic quantitative elements for judging semantic consistency drift.

[0043] A unified semantic consistency deviation score D is generated based on a pre-defined linear weighted model to comprehensively judge the degree of deviation of the model output. The scoring formula is: D=α×(1-S)+β×normalize(T)+γ×C; where α, β, and γ are respectively set weighting coefficients, satisfying α+β+γ=1, for example, set to α=0.4, β=0.3, γ=0.3; normalize(T) is the time difference normalization function, which scales the change time difference to the [0,1] interval. For example, if T is 50 days and the maximum time window is 100 days, then normalize(T)=0.5. Assuming that the S of the predicted label "payment failure" and the current map label "transaction interruption" is 0.68, T is 50 days, and C is 0.15, then the final deviation score is: D = 0.4 × (1 - 0.68) + 0.3 × 0.5 + 0.3 × 0.15 = 0.323. If the deviation score D exceeds the threshold set by the system (e.g., 0.30), it indicates that the label has deviated from the current business status in terms of semantics, time, or confidence, and has obvious signs of drift.

[0044] When the semantic consistency deviation score D exceeds a preset threshold, a model calibration task is immediately triggered, and the output of the defect identification model in the continuous delivery process is interrupted from participating in the quality judgment logic. This includes two actions: first, the system generates a model correction task request and pushes it to the model retraining queue, requiring the training data to be resampled using the current semantic nodes in the graph as new labels; second, the model's quality gate judgment function in the current CI / CD process is terminated to prevent it from continuing to mislead downstream test reports and release decisions. For example, in a release process, if the model repeatedly predicts labels with D>0.30, such as "payment failure" being mistakenly considered a non-defect, the model is removed from the quality verification stage until it completes calibration and re-registers. This achieves proactive monitoring and responsive control of the defect identification model in semantic evolution scenarios. This semantic consistency drift monitoring mechanism can not only identify subtle drift trends at the label level but also comprehensively consider time lag and prediction confidence fluctuations, ensuring test stability and the credibility of intelligent test quality decisions in a continuous delivery environment.

[0045] The graph-enhanced test case generation mechanism refers to extracting a set of active semantic nodes in the current version based on the semantic evolution graph, identifying their corresponding input parameter fields, state transition conditions, and upstream and downstream dependencies, and constructing a semantic-driven input structure template. Active semantic nodes refer to semantic nodes in the current version that have behavioral triggering significance in the business process and have not yet been abandoned or merged. Their identification conditions include: the node status is marked as "valid," the change record has been updated in the most recent version, and there is a binding relationship with at least one test interface. For example, the node "Order Payment Confirmation" has a new status "Payment Processing" in graph version V4.2 and is bound to the interface POST / order / pay / confirm; this node is considered active. After structured parsing of this node, input parameter fields (such as user_id, pay_token, amount), state transition conditions (such as amount>0 and pay_token verification successful), and subsequent state dependencies (such as needing to jump to "Transaction Completed") can be extracted. The above structure is transformed into a unified input structure template, organized in the form of JSONSchema or key-value table, to provide an input skeleton for subsequent use case construction.

[0046] The input structure template is embedded into the test case generation process to combine and expand input variants under different semantic paths, generating test input descriptions covering different state branches. In this step, the input space is expanded at the path coverage level by combining the value constraints, boundary conditions, and state transition conditions of the input fields. For example, variants such as 0, negative numbers, and exceeding the limit are generated for the `amount` field; combinations such as valid, expired, and forged are generated for the `pay_token` field. Input description groups are generated through permutations and combinations. For example, an input group might be: `{user_id:"U123",amount:100,pay_token:"VALID123"}`, with a corresponding jump path of "Payment processing → Transaction completed". Each generated input description is bound to the target semantic path and tagged with a generation label to identify the source node and input triggering logic.

[0047] The generated test input descriptions and semantic nodes undergo path mapping verification to ensure that each test case corresponds to a valid semantic path branch in the graph. This path mapping verification is implemented using a combination of graph traversal and semantic vector calibration. First, in the semantic evolution graph, starting from the initial node, all reachable paths are extracted using depth-first search (DFS), and the node sequence of each path is encoded into a path semantic vector. Second, the field combinations in the test input description are semantically encoded and matched with the graph path vectors using cosine similarity. If the matching degree is higher than a set threshold (e.g., 0.92), the input description is determined to be mappable to the corresponding path. For example, if the input combination contains amount>0 and pay_token is valid, its path intent is "initiate payment → payment processing → waiting for confirmation," and this path is considered valid if it exists in the graph. If path mapping cannot be completed, the test input is marked as "path broken" and not executed.

[0048] Test input descriptions validated through path mapping are uniformly used to generate a set of test cases, serving as an execution plan synchronized with the current business semantic state, and submitted to the automated testing engine for execution. Each test case includes its corresponding semantic node ID, input field structure, expected state transition path, and version tag information for test regression management and semantic tracing. Test case execution results are also fed back to the graph-enhanced test case generation mechanism for continuous optimization of test cases in subsequent semantic evolution. For example, if a path branch is marked as obsolete in a future version, its related test cases will be automatically archived and removed from the main execution set, ensuring the test semantic set remains consistent with the current business state.

[0049] During semantic regression verification, semantic extraction is performed on each automatically generated test case, extracting core semantic elements such as the operation actions, input field names, and expected responses to generate semantic content description units. These semantic content description units express the semantic intent of the test case in a structured form. For example, for a test case verifying a user payment process, the operation action is "submit payment request," the input field names are {user_id, order_id, pay_token}, and the expected response is "return payment confirmation." Simultaneously, state breakpoints within the test path (such as "paying in progress" and "payment successful") are extracted as intermediate expected states, forming a complete set of semantic units. This process can be combined with natural language processing methods to automatically annotate field labels, action verbs, and response templates in the test cases.

[0050] The semantic content description units are matched one-to-one with the contextual semantic labels of each node in the semantic evolution graph, and the semantic consistency verification result is calculated. Each semantic node in the graph carries contextual description, field constraints, state transition logic, and version timestamp information. A bidirectional semantic vector alignment mechanism is adopted to convert the field-action-expectation triple extracted from the test cases into vector representations, and perform cosine similarity matching with the semantic vectors of candidate nodes in the graph. For example, if the expected state of the test case is "payment successful", but the current graph has been replaced with "transaction completed", the similarity result may drop to 0.72, triggering a semantic consistency alarm.

[0051] To improve the matching accuracy between test cases and semantic evolution graphs and avoid matching deviations caused by relying solely on semantic similarity calculations, the matching process can further introduce field logic verification and state transition path verification as two auxiliary verification dimensions when calculating the matching degree between the semantic content description unit of the test case and the graph node. These dimensions are then combined with the semantic vector matching results for a weighted score to enhance the reliability and anti-offset capability of the overall semantic consistency judgment.

[0052] Field logic verification refers to the requirement that the input field names extracted from the semantic content description unit of the test case must exist in the field definition set of the target semantic node in the current version of the semantic evolution graph, and be consistent with the field data type and usage context. For example, if a test case contains the field "pay_token", but the target node "initiate payment" in the graph only has this field in historical versions and has been replaced by "token_hash" in the current version, then the field logic verification will fail. Furthermore, field logic verification not only requires exact matching of field names, but also structural consistency judgment on the usage location of the field. For example, the field "user_id" must appear in the interface parameter definition or form field list, not in the response template. Field logic verification can be comprehensively implemented through field thesaurus comparison, interface definition parsing, field scope judgment, etc., and finally form a binary verification result F (1 for successful field matching, 0 for failure), or a field coverage score F∈[0,1) can be generated by using soft matching.

[0053] State transition path verification refers to whether the connections between nodes in the semantic evolution graph contain the state transition path expected by the test case. That is, whether the preceding, intermediate, and target states covered by the test actually exist in the graph structure, and whether the connection order conforms to the actual business logic. For example, if a test case expects the path to be "pending payment → payment processing → payment successful," it must be verified that these three are indeed a directed path in the graph. If "payment processing" has been reconstructed into an independent sub-process "asynchronous settlement" in the graph, the original path will be judged as unconnectable. State transition path verification is completed through path reachability analysis and topology consistency verification. Common methods include depth-first search (DFS) or Dijkstra's shortest path algorithm. The verification result generates a path connectivity score P∈[0,1], where 1 represents complete connectivity and 0 represents a broken path. By combining the semantic vector similarity score S, the field logic verification score F, and the state transition path verification score P, a joint scoring function can be constructed to determine the semantic matching degree of the test case. For example, the semantic matching degree of the test case can be obtained by multiplying each parameter by its corresponding preset coefficient and summing the results. The preset coefficients can be set according to the degree of influence of each parameter on the semantic matching degree of the test case, or they can be set by expert assignment method, or they can be set according to existing standard setting rules.

[0054] Based on the consistency verification results of semantic descriptions, the connectivity verification results of graph paths, and the validity verification results of the current version of node states, a mandatory consistency judgment rule is executed to determine whether each test case is allowed to execute. The specific rules can be set as follows: if the semantic consistency score is below 0.85, or the matching path lacks connectivity, or the target semantic node has been marked as obsolete in the current version, the test case is judged as "inconsistent"; otherwise, it is considered "passed." For "inconsistent" test cases, their entry into the test execution process is immediately blocked to avoid misjudgments. For example, a test case used to verify "order suspended" is marked as invalid if the "suspended" state path cannot be found in the graph or the state has been merged into "pending payment."

[0055] The system identifies misaligned semantic content description units, converts their deviation from the target node into semantic correction feedback information, and sends it to the graph-enhanced test case generation mechanism. The feedback information includes: misaligned fields and suggested replacement fields (e.g., "payment failed" should be replaced with "transaction interrupted"), recommended node paths (the nearest semantic branch calculated based on the graph path topology), and semantic offset descriptions from the original input structure template. This feedback is used to semantically adjust the Prompt construction logic, driving the subsequent test case generation process to automatically correct semantic deviations. For example, if three consecutive test cases are judged as semantically broken under the "refund status," the feedback mechanism will suggest to the test case generation logic: "The refund status in the current graph has been split into 'pending review' and 'refunded.' Please reconstruct the input structure template to cover the new path."

[0056] A Prompt template is a predefined semantic structure template used to construct the input statements of a large language model when automatically generating test cases. It guides the language model to generate output content that conforms to expected logic according to specific intent and context by setting a fixed language framework and inserting dynamic business parameters and semantic node information into it. The Prompt template is a "fill-in-the-blank" input framework used to control the direction and scope of the content generated by the language model. Its core function is to transform structured business semantic information into natural language form for the language model to understand and use for reasoning or generating test logic. For example, a Prompt template example: "Please simulate a user in the [action] scenario, inputting [list of field names], and expecting to receive a [system status feedback] response." When the business semantic node is "Initiate payment" and the status is "Transaction processing," and the input fields include "user_id," "order_id," and "amount," then the actual Prompt generated after filling in the template is: "Please simulate a user in the 'Initiate payment' scenario, inputting user_id, order_id, and amount, and expecting to receive a response indicating the 'Transaction processing' status." This approach ensures that the logic of the generated test cases remains consistent with the semantic structure in the graph. When the graph is updated (e.g., the status changes from "Transaction in Progress" to "Processing Aborted"), the Prompt template can automatically populate new semantic nodes based on the update, thereby driving the language model to synchronously adjust the generated content.

[0057] Example 2: A software testing system based on a data analysis platform, specifically including: The graph construction module is used to generate a graph structure covering semantic entities and their evolutionary relationships based on business interface fields, state enumeration information and user behavior description information, and continuously track the historical changes of semantic nodes to support semantic consistency comparison and model calibration operations. The data tag linkage module is used to establish a mapping relationship between semantic nodes and defect tags, and maintain the consistency between the training samples of the built-in defect recognition model and the current business semantics through the automatic inheritance and synchronous update mechanism of tag versions. The drift monitoring module is used to compare the matching degree between the current output of the defect identification model and the semantic labels of the graph, and calculate the semantic consistency deviation index. When the deviation index exceeds the preset threshold, the model correction task is automatically triggered and the quality judgment function of the model in the continuous delivery process is interrupted. The test case generation module is used to dynamically stitch together active semantic nodes in the current graph when constructing test input content, so that the automatically generated test cases are synchronized and aligned with the current business semantic state, covering the complete path branches after semantic evolution; The semantic regression verification module is used to perform semantic alignment verification between automatically generated test cases and semantic evolution graphs, and sets mandatory consistency judgment rules to allow only verified test cases to enter the test execution process; for test cases that fail verification, they are marked as pending review and the correction feedback information is returned to the test case generation module.

[0058] It should be noted that in the semantic regression verification process, for test cases that fail the semantic consistency check, data such as misaligned field information, state expression deviations, or broken path connectivity in their semantic content description units are compiled into corrective feedback information and returned to the test case generation mechanism. This corrective feedback information is not only used for Prompt adjustments and test case reconstruction, but also forms a closed-loop linkage with the defect identification model, further improving the robustness and semantic accuracy of test coverage.

[0059] The application of corrective feedback information in the test case generation mechanism includes three aspects: Prompt Dynamic Refactoring: Based on semantic discrepancies pointed out in the feedback information (e.g., "payment failed" should be replaced with "transaction interrupted"), the action phrases, input variables, and expected state words in the Prompt template are dynamically updated. For example, the original Prompt "simulates user payment failure process" is automatically adjusted to "simulates user transaction interruption process", and the original generated input fields {order_id, pay_token} are replaced with {order_id, transaction_hash} to match the latest semantic path definition in the graph.

[0060] Semantic template correction: Feedback information will mark and correct the input structure templates used in the test generation mechanism. For example, it will mark that the current template uses deprecated state nodes, prompt that they should be replaced with new version semantic nodes, and automatically trigger the template update task to prevent the template from being repeatedly called by subsequent generation logic.

[0061] Branch path completion: If the feedback information indicates that a certain semantic path is not covered (such as the newly added state "processing stopped" in the graph not being covered), a new round of test case generation is triggered to actively construct test input descriptions and assertion logic that cover the semantic path and make up for the missing path.

[0062] The correction feedback information also forms a semantic linkage mechanism with the defect identification model: Semantic Label Linkage Adjustment: When a test case is marked as "misaligned" due to semantic offset, it indicates that the semantic labels in the current training samples of the model no longer fully reflect the current business semantics. At this time, the feedback information will be used as input to the label synchronization update mechanism to retrieve whether there are corresponding old labels (such as "payment failed") in the training set of the defect identification model, and mark them as semantically outdated.

[0063] Dynamic reconstruction of training samples: Feedback information can trigger a version repair process for the training data of the defect identification model, that is, automatically generate labeled samples containing new semantic nodes (such as "transaction interruption"), and use these samples to fine-tune the model to adapt to the new semantic logic structure.

[0064] Deviation verification-assisted correction: In the semantic consistency drift monitoring mechanism, if a label drifts but the drift value does not exceed the preset threshold, the correction feedback information can serve as auxiliary evidence to drive the early correction of the model, avoiding passive backtracking after the actual quality judgment fails.

[0065] For example, if three consecutive test cases generate feedback information because "refund has been revoked" is not covered, the system will automatically add this status to the Prompt template, graph path, and training data. Simultaneously, it will update the node semantic vectors in the semantic consistency calculation, improving the model's ability to perceive and respond to the "refund has been revoked" status. This corrective feedback information forms a two-way semantic linkage closed loop in the test generation and defect detection chains. It not only dynamically corrects test semantic deviations but also serves as a signal source for the evolution of training sample structures, guiding the defect identification model to maintain semantic synchronization with the graph, thereby achieving overall semantic consistency control from test generation to quality assessment.

[0066] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0067] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

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

[0069] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

Claims

1. A software testing method based on a data analysis platform, characterized in that, The method comprises the following steps: A semantic evolution awareness graph is constructed, based on business interface fields, state enumeration information and user behavior description information, to generate a graph structure covering semantic entities and their evolution relationships, continuously track historical changes of semantic nodes, and compare semantic consistency and calibrate models; A semantic-driven data label linkage mechanism is established to map semantic nodes to defect labels, automatically inherit and synchronously update label versions, maintain consistency between built-in defect recognition models and business semantics, and keep the training samples of the models consistent with the semantics; A semantic consistency drift monitoring mechanism is established to compare the matching degree between the current output of the defect recognition model and the graph semantic label, calculate the semantic consistency deviation index, and trigger model correction tasks and interrupt the quality judgment function in the continuous delivery process when the semantic consistency deviation index exceeds the preset threshold; A graph-enhanced test case generation mechanism is introduced to dynamically splice active semantic nodes in the current graph when constructing test input content, synchronize the automatically generated test cases with the current business semantic state, and cover all path branches after semantic evolution; A semantic regression verification process is established to perform semantic alignment and verification on the automatically generated test cases and the semantic evolution graph, set forced consistency judgment rules, and only allow test cases that pass the verification to enter the test execution; For test cases that do not pass the verification, mark them as pending and return correction feedback information to the test case generation mechanism.

2. The software testing method based on data analysis platform of claim 1, wherein, In the process of constructing the semantic evolution awareness graph, the user behavior description information is semantically disassembled based on natural language processing algorithms to identify key behavior phrases and upstream and downstream action flow relationships; the disassembled behavior segments are semantically classified and embedded in the graph node structure in combination with business interface fields and state enumeration information to establish a behavior-state-interface ternary mapping model; graph neural networks are introduced to vectorize the evolution relationships between graph nodes and learn their similarities, and are used for dynamically completing the potential relationships between semantic nodes.

3. The software testing method based on data analysis platform of claim 2, wherein, A graph version control mechanism is preset to establish version snapshots for each change in the semantic evolution awareness graph, and record the change source, change type and associated range.

4. The software testing method based on data analysis platform of claim 3, wherein, The specific steps of establishing the semantic-driven data label linkage mechanism include: Reconstruct the semantic of defect data in the historical version at the field level, extract the context description and label definition related to the current semantic node, and construct a label semantic vector representation; By comparing the semantic distance between the semantic nodes in the current graph and the historical label semantic vectors, automatically determine whether the label needs to be inherited, renamed, split or abandoned, and generate a label version mapping relationship accordingly; Construct a label synchronization update process, when a semantic node in the graph changes, automatically retrieve and update all label versions associated with it, maintain the consistency and timeliness of label semantics in model training data, and finally realize the dynamic binding of label and semantic evolution linkage.

5. The software testing method based on data analysis platform of claim 4, wherein, When generating the label version mapping relationship, generate a corresponding node semantic representation vector for each semantic node in the current graph, and calculate the similarity with the historical label semantic vector to obtain a semantic distance matrix; Based on the semantic distance threshold strategy, the semantic association type between the label and the node is automatically determined, including inheritance, renaming, splitting or abandonment, and a label version mapping table is constructed accordingly.

6. The software testing method based on data analysis platform according to claim 5, wherein, When establishing the semantic consistency drift monitoring mechanism, the semantic labels involved in the prediction output of the defect identification model, the confidence score and the corresponding timestamp are extracted, and the semantic node content, the latest change time and the evolution path information of the current version are retrieved from the semantic evolution perception graph to construct a label correspondence matrix; The text semantic similarity between the model prediction label and the graph label is calculated, the word vector cosine similarity is used as the basic index, and the label change time difference and the model confidence offset value are fused to generate a unified semantic consistency deviation score through a preset linear weighting model. When the semantic consistency deviation score is higher than the preset threshold, the model calibration task is generated immediately and the output results of the model in the current continuous delivery process are interrupted to participate in the quality judgment logic.

7. The software testing method based on data analysis platform of claim 6, wherein, The preset linear weighting model refers to: The following three indicators are extracted from the prediction results of the defect identification model: Semantic similarity S, representing the text vector cosine similarity between the model output label and the graph semantic node; Label change time difference T, representing the difference between the current time and the last change time of the label; Model confidence score difference C, representing the absolute difference between the confidence score of the current prediction label and the historical average value of the label; The formula for calculating the semantic consistency deviation score D is as follows: D = alpha * (1-S) + beta * normalize(T) + gamma * C; Where: alpha, beta, gamma are preset non-zero weight parameters, satisfying alpha + beta + gamma = 1, normalize(T) is a preset time difference normalization function, mapping the time difference to the interval [0, 1].

8. The software testing method based on data analysis platform of claim 5, wherein, The introduction of the graph-enhanced test case generation mechanism refers to: Based on the semantic evolution graph, the set of active semantic nodes in the current version is extracted, and the corresponding input parameter fields, state transition conditions and upstream and downstream dependencies are identified to construct a semantic-driven input structure template; Embed the input structure template into the test case generation process, combine and expand the input variants under different semantic paths to generate test input descriptions covering different state branches; Map and verify the generated test input descriptions and semantic nodes, each test case corresponds to an effective semantic path branch, and finally form a test case set that keeps pace with the current business semantic state.

9. The software testing method based on data analysis platform of claim 8, wherein, During semantic regression verification, extract the operation actions, input field names and expected responses contained in each automatically generated test case to generate semantic content description units, and match them with the context semantic labels of each node in the semantic evolution graph. According to the semantic description consistency verification result, the atlas path connectivity verification result and the current version validity verification result of the node state, a forced consistency judgment rule is executed to judge whether the test case is consistent with the current business semantics. The test case that fails to pass the verification will be blocked from entering the test execution process. The unaligned semantic content unit is identified. The deviation relationship between the unit and the target node is converted into feedback information and transmitted to the test case generation mechanism.

10. Software testing system based on a data analytics platform, based on the software testing method based on a data analytics platform according to any one of claims 1 to 9, characterized in that, Specifically, it comprises: An atlas construction module is configured to generate an atlas structure covering semantic entities and their evolution relationships based on business interface fields, state enumeration information and user behavior description information, and continuously track historical changes of semantic nodes to support semantic consistency comparison and model calibration operations. A data label linkage module is configured to establish a mapping relationship between semantic nodes and defect labels, and maintain consistency between the training samples of the built-in defect recognition model and the current business semantics through an automatic inheritance and synchronous update mechanism of label versions. A drift monitoring module is configured to compare the matching degree between the current output of the defect recognition model and the atlas semantic label, calculate a semantic consistency deviation index, and automatically trigger a model correction task and interrupt the quality judgment function of the model in the continuous delivery process when the deviation index exceeds a preset threshold. A test case generation module is configured to dynamically splice active semantic nodes in the current atlas when constructing test input content, so that the automatically generated test case is synchronized with the current business semantic state and covers the complete path branches after semantic evolution. A semantic regression verification module is configured to perform semantic alignment verification on the automatically generated test case and the semantic evolution atlas, and set a forced consistency judgment rule to allow only the test case that passes the verification to enter the test execution process. For the test case that fails to pass the verification, it is marked as a pending state, and correction feedback information is returned to the test case generation module.

Images