Automatic test code generation method and device based on large language model

Abstract

The embodiment of the application provides a kind of based on the automatic test code generation method and device of large language model, by innovatively designing requirement processing system, by semantic analysis and scene construction, the effective generation of test case is realized.Code generation mechanism is constructed, in combination with quality evaluation and execution control, reliable test strategy is established.Result analysis is introduced, through experience accumulation and scheme optimization, ensure the continuous improvement of test.The method effectively solves the deficiency of traditional technology in requirement processing, code generation and result analysis etc., provides technical support for automated testing.

Description

Technical Field

[0001] This application relates to the field of large model technology, specifically to an automated test code generation method and apparatus based on a large language model. Background Technology

[0002] Existing test code generation methods have significant shortcomings. Traditional systems perform poorly in requirements analysis and scenario analysis, failing to effectively understand test requirements and thus impacting code quality.

[0003] Furthermore, existing technologies suffer from bottlenecks in code generation and execution control. Most systems lack robust code optimization mechanisms and scheduling strategies, resulting in inefficient testing.

[0004] The existing system has technical shortcomings in result analysis. It lacks in-depth analysis of testing experience, making it difficult to achieve efficient solution optimization through knowledge accumulation, thus affecting testing effectiveness. Solving these problems is crucial for improving automated testing capabilities. Summary of the Invention

[0005] To address the problems in existing technologies, this application provides an automated test code generation method and apparatus based on a large language model, which can effectively solve the shortcomings of traditional technologies in terms of requirement processing, code generation and result analysis, and provide technical support for automated testing.

[0006] To solve at least one of the above problems, this application provides the following technical solution:

[0007] Firstly, this application provides an automated test code generation method based on a large language model, including:

[0008] An input acquisition template is established based on the requirement description collection and configuration rule base. The test requirement information is structured according to a preset format to generate a requirement parsing rule set. Semantic analysis and entity recognition are performed based on the parsing rule set to construct a test requirement matrix. A scenario similarity calculation model is established based on the test requirement matrix. Historical test scenarios are analyzed according to the scenario similarity calculation model to generate a scenario knowledge graph. A test case set containing test conditions and expected results is generated based on the scenario knowledge graph.

[0009] Code generation rules are constructed based on a preset test framework template. The test case set is converted into code snippets according to the generation rules. The code is optimized according to the quality assessment criteria. A code adaptive adjustment mechanism is constructed. The test execution script is updated based on the adjustment mechanism. The test execution script is run through the execution control system and data collection and task scheduling are performed to generate a test result dataset containing execution status and performance indicators.

[0010] The test result dataset is analyzed based on the test result evaluation rules. An attribution analysis method is constructed to identify key failure factors. Test experience is extracted according to the knowledge base construction rules to generate a knowledge base containing test cases and best practices. The test plan is optimized according to the knowledge retrieval and recommendation mechanism to generate a test report containing analysis results and improvement suggestions. The test report and the knowledge base are fed back to the test case generation stage to complete the test plan update.

[0011] Furthermore, it also includes: establishing rules for identifying demand elements, constructing a demand description parser based on a preset collection template, segmenting and labeling the input text based on the parser, extracting key demand element information, constructing a demand description vector, and generating a demand feature matrix containing demand element identifiers and relationships.

[0012] Based on the aforementioned requirement feature matrix, a requirement information mapping rule is constructed. The requirement element information is then structurally transformed according to a standard format to establish a requirement semantic parsing model. Based on the parsing model, semantic analysis and entity extraction are performed on the requirement elements to generate a test requirement matrix containing test objectives and scenario constraints.

[0013] Furthermore, it also includes: decomposing the test requirement matrix according to preset feature extraction rules, constructing a scene feature vector space, establishing a scene semantic representation model, calculating the correlation strength between scene elements based on the representation model, and generating a scene feature relationship graph;

[0014] Based on the scene feature relationship graph, a similarity measurement standard is constructed. Clustering and association analysis are performed on historical test scene data to establish a scene knowledge relationship network. Test scene patterns are extracted based on the relationship network to generate a test case set containing test paths and verification rules.

[0015] Furthermore, it also includes: constructing a code mapping rule set based on the test framework template library, mapping the test conditions and expected results in the test case set to code structure templates, establishing a code syntax conversion model, and generating initial test code based on the conversion model;

[0016] Static analysis is performed on the initial test code, an optimization strategy library is built based on code quality evaluation indicators, the code structure is restructured and optimized according to the optimization strategies, a code adaptation mechanism is established, and test code snippets that conform to the framework specifications are generated.

[0017] Furthermore, it also includes: constructing a script update strategy based on the test environment configuration information, dynamically analyzing the test execution script, establishing a script execution dependency graph, generating a task scheduling sequence based on the dependency graph, and constructing a scheduling scheme that includes execution priority and resource allocation;

[0018] Run test script sets based on the aforementioned scheduling scheme, establish performance monitoring rules, sample and analyze the system status and resource usage during script execution, construct a test data acquisition model, and generate a result dataset containing execution trajectories and performance metrics.

[0019] Furthermore, it also includes: constructing a result analysis model based on preset evaluation dimensions, extracting multi-dimensional features from the test result dataset, establishing failure mode recognition rules, clustering test failure samples based on the recognition rules, and generating a failure cause attribution map;

[0020] Based on the failure cause attribution graph, knowledge extraction rules are constructed, and pattern mining and correlation analysis are performed on historical test experience data to establish a test knowledge representation model. Based on the representation model, a knowledge base containing test cases and solutions is generated.

[0021] Furthermore, it also includes: constructing a knowledge retrieval model based on test requirement characteristics, performing semantic retrieval and similarity matching on the knowledge base, establishing test plan recommendation rules, and generating a test optimization plan containing optimization suggestions and improvement measures based on the recommendation rules;

[0022] Based on the aforementioned test optimization scheme, a report generation template is constructed. The test execution results and improvement suggestions are structured and organized to establish a test feedback closed-loop mechanism. According to the closed-loop mechanism, the optimization results are updated to the test case generation stage to complete the test scheme iteration.

[0023] Secondly, this application provides an automated test code generation device based on a large language model, comprising:

[0024] The scenario graph construction module is used to establish input acquisition templates based on the requirement description collection configuration rule library, perform structured processing on test requirement information according to a preset format, generate a requirement parsing rule set, perform semantic analysis and entity recognition based on the parsing rule set, construct a test requirement matrix, establish a scenario similarity calculation model based on the test requirement matrix, analyze historical test scenarios according to the scenario similarity calculation model, generate a scenario knowledge graph, and generate a test case set containing test conditions and expected results based on the scenario knowledge graph.

[0025] The test script building module is used to build code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, build a code adaptive adjustment mechanism, update the test execution script based on the adjustment mechanism, run the test execution script through the execution control system, and perform data collection and task scheduling to generate a test result dataset containing execution status and performance indicators.

[0026] The automated testing module is used to analyze the test result dataset based on test result evaluation rules, construct attribution analysis methods to identify key failure factors, extract test experience according to knowledge base construction rules, generate a knowledge base containing test cases and best practices, optimize the test plan according to knowledge retrieval and recommendation mechanisms, generate a test report containing analysis results and improvement suggestions, and feed the test report and the knowledge base back to the test case generation stage to complete the test plan update.

[0027] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the automated test code generation method based on a large language model.

[0028] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the automated test code generation method based on a large language model.

[0029] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the automated test code generation method based on a large language model.

[0030] As described above, this application provides an automated test code generation method and apparatus based on a large language model. Through an innovative design of the requirement processing system, and by employing semantic analysis and scenario construction, it achieves effective test case generation. A code generation mechanism is constructed, combined with quality assessment and execution control, to establish a reliable testing strategy. Result analysis is introduced, and through experience accumulation and solution optimization, continuous improvement of testing is ensured. This method effectively addresses the shortcomings of traditional technologies in requirement processing, code generation, and result analysis, providing technical support for automated testing. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a flowchart illustrating the automated test code generation method based on a large language model in an embodiment of this application.

[0033] Figure 2This is a structural diagram of the automated test code generation device based on a large language model in the embodiments of this application;

[0034] Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.

[0035] Figure label:

[0036] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0039] To address the shortcomings of existing technologies, this application provides an automated test code generation method and apparatus based on a large language model. Through an innovative design of the requirement processing system, semantic analysis, and scenario construction, it achieves effective test case generation. A code generation mechanism is constructed, combined with quality assessment and execution control, to establish a reliable testing strategy. Result analysis is introduced, and continuous improvement of testing is ensured through experience accumulation and solution optimization. This method effectively solves the deficiencies of traditional technologies in requirement processing, code generation, and result analysis, providing technical support for automated testing.

[0040] To effectively address the shortcomings of traditional technologies in requirements processing, code generation, and result analysis, and to provide technical support for automated testing, this application provides an embodiment of an automated test code generation method based on a large language model. See [link to relevant documentation]. Figure 1 The automated test code generation method based on a large language model specifically includes the following:

[0041] Step S101: Based on the requirement description, establish an input acquisition template from the configuration rule base; perform structured processing on the test requirement information according to a preset format to generate a requirement parsing rule set; perform semantic analysis and entity recognition based on the parsing rule set to construct a test requirement matrix; establish a scenario similarity calculation model based on the test requirement matrix; analyze historical test scenarios according to the scenario similarity calculation model to generate a scenario knowledge graph; and generate a test case set containing test conditions and expected results based on the scenario knowledge graph.

[0042] First, this embodiment uses a requirement description collection and configuration rule base to access raw text from requirement documents and defect records. Paragraphs are broken down into five categories of slots based on the input template: test objectives, input conditions, trigger actions, expected results, and scenario constraints. This embodiment then segments and annotates sentences according to the mandatory relationships and terminology in the template, aligns unit and time expressions, and generates a list of requirement elements, which serves as direct input for subsequent structured processing.

[0043] Next, the list of requirement elements is read by the structured processor in this embodiment and mapped into standard records according to a preset format. The record key includes a scene identifier and an interface field. This embodiment generates a requirement parsing rule set by merging synonyms based on alias mappings and negation boundaries in the collection configuration rule base. The rule set carries part-of-speech constraints and dependency templates for direct use by semantic analysis and entity recognition.

[0044] Then, the set of requirements parsing rules is loaded by the semantic analysis and entity recognition module of this embodiment, performing dependency analysis and semantic role labeling on standard records to extract the operation object, input data, environment preconditions, and verification expressions. This embodiment encodes the extraction results into indexed key-value pairs and fills in cross-sentence references through referencing resolution to form a test requirement matrix. This matrix uses scenarios as rows and elements as columns, with column fields containing data types, boundary conditions, and constraint labels, serving as input for similarity modeling.

[0045] Based on the aforementioned test requirement matrix, this embodiment trains and solidifies a scene similarity calculation model, named the Scene Semantic Similarity Engine. This engine takes matrix row vectors as input and outputs scene similarity scores, employing a joint objective of weighted allocation and regularization constraints.

[0046] R=μ·∑k ak·bk-ν·∑h dh^2.

[0047] In the formula, R is the similarity target, ak is the weight of the k-th element, bk is the corresponding matching score, dh is the regularization coefficient, and μ and ν are tradeoff coefficients, whose values ​​are constrained by word frequency distribution and error upper bound. The terms are connected by "-", reflecting the design intent of the joint objective function. The left and right sides correspond to the two opposing objectives of "incentive" and "penalty" in similarity modeling, respectively, which together constitute the optimization criteria of the scene semantic similarity engine in this embodiment. This embodiment iteratively updates the weights and coefficients under the labeled clustering of historical similar scenes.

[0048] Based on the aforementioned similarity score, this embodiment clusters historical test scenarios and establishes connections to output a scenario knowledge graph. This graph uses scenarios as nodes and high similarity and shared constraints as edges. Edge attributes register the co-occurrence strength of triggering actions and verification modes. Nodes maintain a one-to-one mapping with scenario identifiers in the test requirement matrix, used for subsequent test case extraction.

[0049] Based on the aforementioned scenario knowledge graph, the test case generator in this embodiment filters a set of nodes similar to the current requirements, aligns and deduplicates the test conditions and expected results on the nodes, and obtains a draft test case. In this embodiment, conflicting entries are sorted by similarity score and constraint satisfaction, prioritizing conditions consistent with the current matrix column domain, and filling in necessary prerequisites at missing locations based on graph neighbor relationships.

[0050] For example, in this embodiment, for the requirement of "user balance insufficient to refuse deduction", the account status and deduction threshold constraint are marked in the matrix. The engine retrieves the neighboring nodes of the payment failure related clusters in the knowledge graph, extracts the expected results of the same verification expression, and generates two sets of use cases covering the failure path and the recovery path to illustrate the mapping method from elements to use cases.

[0051] Finally, the draft test cases are read by the consistency checker in this embodiment, and the semantics and expected expressions of the conditions are reviewed according to the requirement parsing rule set to form a test case set containing test conditions and expected results. This test case set, along with the similarity score and the graph node number, is registered as the input entry point for the code generation rules in subsequent steps, and is directly called by the code mapping and script generation stages.

[0052] Step S102: Construct code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, construct a code adaptive adjustment mechanism, update the test execution script based on the adjustment mechanism, run the test execution script through the execution control system and perform data collection and task scheduling, and generate a test result dataset containing execution status and performance indicators;

[0053] First, this embodiment receives the test case set and scenario knowledge graph index output in step S101. It selects a framework template matching the target system from the preset test framework template library and encodes the test conditions, trigger actions, and expected results in the test case items as framework placeholders using a mapping dictionary. Based on the three-part structure of the template declaration (preconditions, steps, assertions), it aligns the input data source and environment variables to obtain a list to be generated, which serves as the direct input for the code generation rules.

[0054] Next, the list to be generated is read by the rule compiler of this embodiment, and code generation rules are constructed based on a preset test framework template. The rules map statement patterns to step types and verification statements to assertion types, and inject a fixed assembly order during the data preparation phase. The compiler converts test cases into code snippets according to the rules. Each snippet contains three types of paragraphs: data construction, interface calls, and assertion blocks, and is bound to the source test case number for quality assessment and traceability.

[0055] The code snippet is then loaded by the static analyzer in this embodiment, and performs syntax validation, dependency resolution, and complexity metric optimization according to quality assessment standards. The analyzer rewrites non-compliant calls based on naming constraints and resource usage specifications, aggregates repeatedly constructed test data, splits long-chain assertions into atomic assertion sequences, and produces reconstructed candidate snippets. The reasons for rewriting the candidate snippets are recorded while maintaining the semantics of the use cases, for subsequent adjustment mechanisms to read.

[0056] Based on the candidate fragments, this embodiment constructs a code adaptive adjustment mechanism. The mechanism reads the runtime baseline and framework capability characteristics, selects appropriate decorators for asynchronous calls and retry strategies, and injects stub modules and timeout controls for steps that depend on external services. The mechanism also calculates fragment-level execution overhead estimates and provides scheduling labels for subsequent script merging and execution order arrangement.

[0057] Based on the aforementioned scheduling tags, this embodiment merges candidate fragments into a test execution script. The script generator performs differential comparison on historical scripts according to the script update strategy, replacing only the affected function blocks while maintaining the topological order of initialization and resource release. The script embeds execution hooks and metric sampling probes, which are mapped to a unified metric namespace to ensure the comparability of different scripts.

[0058] After the test execution script is generated, this embodiment executes the script and schedules tasks through the execution control system. The scheduler reads the dependency graph within the script, distributes tasks according to priority and resource quota, locks mutually exclusive resources, and renews sessions for steps requiring external credentials. During execution, the monitor collects execution status, response time, and error stack according to sampling rules, generating the original execution trajectory.

[0059] Finally, the original execution trajectory is parsed into a structured event stream by the data acquisition model of this embodiment. Performance metrics are calculated based on the indicator criteria and aligned with the execution status to form a test result dataset. This dataset includes script identifiers, test case numbers, assertion pass / fail status, and key latency items, and the generated version is registered, serving as the input entry point for test result evaluation rules and attribution analysis methods in subsequent steps.

[0060] Step S103: Analyze the test result dataset based on the test result evaluation rules, construct an attribution analysis method to identify key failure factors, extract test experience according to the knowledge base construction rules, generate a knowledge base containing test cases and best practices, optimize the test plan according to the knowledge retrieval and recommendation mechanism, generate a test report containing analysis results and improvement suggestions, and feed the test report and the knowledge base back to the test case generation stage to complete the test plan update.

[0061] First, this embodiment receives the test result dataset and script identifier generated in step S102, and aligns and cleans the event stream according to the test case number, assertion item, and timestamp. Based on the caliber constraints in the test result evaluation rules, the processing actions filter out entries lacking essential context, unify the stack symbol and code version number of the error stack, and obtain comparable result slices. The result slices are aggregated into batch views according to scenario identifiers, serving as input for the attribution analysis method.

[0062] Next, the batch view is read by the attribution analysis method of this embodiment, establishing a correlation between assertion pass / fail status, key latency items, and resource usage indicators. The attribution method first performs pattern clustering on the failed samples, and then extracts common triggering paths and anomaly locations from each cluster.

[0063] To reduce the impact of incidental noise on the conclusions, this embodiment constructs a joint scoring function to measure the explanatory power and stability of the failure factor:

[0064] Y=α·∑u pu·ru-β·∑v gv^2.

[0065] In the formula, Y represents the failure factor score, pu represents the proportion of occurrence of the u-th triggering path, ru represents the correlation strength between this path and the failure event, gv represents the volatility penalty term associated with this factor, and α and β are trade-off parameters whose values ​​are constrained by sample size and variance. The two terms are connected by a "-", with the left side representing the "explanatory power incentive" and the right side representing the "instability penalty." The difference between the two constitutes the quantitative criterion for the overall quality of the failure factor. Factors with high scores are registered as key failure factors and mapped to their corresponding script segments.

[0066] Then, the key failure factors are read by the knowledge extraction engine, which extracts test experience from historical execution trajectories and use case contexts according to the knowledge base construction rules. The engine maps failure factors to three types of experience slots: "scenario preconditions, data construction, and assertion methods," and deduplicates reusable repair steps to form candidate test cases and operation steps. To ensure traceability, this embodiment backfills the source use case number and script version into the case metadata, enabling the specific implementation to be located during subsequent recommendations.

[0067] Based on the candidate test cases, this embodiment constructs a knowledge base, using scenario identifiers as indexes, and stores "test conditions, triggering actions, expected results, common failure factors, and verified repair steps" in a fixed structure. This knowledge base uses the same terminology as the test requirement matrix in step S101, with fields mapped one-to-one, so that semantic comparison can be directly completed in the subsequent retrieval stage. When generating knowledge base entries, the coverage and applicable boundaries are calculated simultaneously to avoid misapplying experience from specific environments to other environments.

[0068] Based on the aforementioned knowledge base, this embodiment employs a knowledge retrieval and recommendation mechanism to optimize test plans that are frequently added or fail. Upon receiving a target scenario description, the mechanism encodes it into a requirement vector, performs a similarity search with knowledge base entries, and returns a set of cases that highly overlap with the current failure factors. During the alignment phase, this embodiment compares the suggested repair steps with the existing scripts to identify execution conflicts, marks the assertion methods and data construction steps that need to be replaced, and generates a test optimization plan awaiting review.

[0069] Subsequently, the test optimization plan is read by the report generator and, combined with the scoring results of the attribution analysis method, a test report containing analysis results and improvement suggestions is generated. The report lists key failure factors, triggering path evidence, and suggested changes on a scenario-by-scenario basis, and provides applicable boundaries and regression verification suggestions. To reduce lengthy descriptions, this embodiment only retains the elements that can drive script changes in the report, and includes an executable change list for direct application by implementers.

[0070] After the test report is generated, this embodiment feeds the report and knowledge base back to the test case generation stage. The feedback interface, based on the test case generation logic in step S101, synchronously updates the data construction, pre-validation, and assertion expressions involved. It updates the action record change time and source score. When a similar scenario occurs again in subsequent batches, the test case generation logic prioritizes the verified repair steps, thus using the attribution conclusion in a closed loop.

[0071] Finally, the closed-loop results are registered by the version manager, including the knowledge base version number, test report number, and corresponding script snapshot. The version manager provides a stable reference point for the evaluation and training of subsequent steps, supporting batch playback and comparative analysis. These outputs are read as parameters in the next round of execution control to verify the effectiveness of the updated scheme in the new round of data collection and scheduling.

[0072] As described above, the automated test code generation method based on a large language model provided in this application can effectively generate test cases through innovative design of a requirement processing system, semantic analysis, and scenario construction. It establishes a reliable testing strategy by constructing a code generation mechanism, combining quality assessment and execution control, and introducing result analysis to ensure continuous improvement of testing through experience accumulation and solution optimization. This method effectively solves the shortcomings of traditional technologies in requirement processing, code generation, and result analysis, providing technical support for automated testing.

[0073] In one embodiment of the automated test code generation method based on a large language model in this application, it may further include the following:

[0074] Step S201: Establish requirement element identification rules, construct a requirement description parser according to the preset collection template, perform word segmentation and annotation on the input text based on the parser, extract key requirement element information, construct a requirement description vector, and generate a requirement feature matrix containing requirement element identifiers and association relationships.

[0075] Step S202: Construct requirement information mapping rules based on the requirement feature matrix, perform structured transformation of the requirement element information according to the standard format, establish a requirement semantic parsing model, perform semantic analysis and entity extraction on the requirement elements according to the parsing model, and generate a test requirement matrix containing test objectives and scenario constraints.

[0076] First, this embodiment establishes requirement element identification rules based on the slot definitions of "test target, input conditions, triggering action, expected result, and scenario constraints" in the preset data acquisition template, clarifying the determination methods for mandatory items, optional items, and negative boundaries. After receiving the input text, word segmentation and annotation are performed according to the domain lexicon and unit caliber to identify entity candidates and dimensional expressions. Numerical phrases such as time, amount, and threshold are standardized to obtain a cleaned syntactic annotation sequence, which serves as the input for subsequent vectorization.

[0077] Next, the syntactic annotation sequence is read by the requirement description parser of this embodiment. Based on the recognition rules, the predicate-argument positions within the sentence are aligned, and key requirement element information is extracted, including the operation object, data fields, preconditions, and validation expressions. The parser encodes the elements into sparse key-value pairs by slot and performs backfilling for cross-sentence references, outputting a requirement description vector. The vector dimension maps one-to-one with the slots for use in structured association.

[0078] Then, the requirement description vector is read by the feature association engine, which calculates the dependency edges between elements under the constraints of dependency relationships and temporal tags, distinguishing between three types of relationships: "precursor to trigger," "data to assertion," and "constraint to target." The association engine assembles nodes and edges into a requirement feature matrix, where the matrix rows correspond to scene fragments, the columns correspond to standard slots, and the edge weights record the dependency strength and negation modifiers to reduce ambiguity in subsequent semantic parsing.

[0079] Based on the aforementioned requirement feature matrix, this embodiment constructs requirement information mapping rules, establishes alias mapping and field caliber alignment relationships, and maps synonymous elements to a unified terminology. The mapper performs structured transformation on the elements according to the mapping rules, fills in missing default calibers, performs unit conversions for inconsistent units, and generates intermediate structured records. The record keys include scene identifiers and interface fields, maintaining consistency with the column fields of the aforementioned matrix.

[0080] Based on the aforementioned structured records, this embodiment trains and loads a demand semantic parsing model, named the semantic element extractor. This model takes records and matrix fragments as input, outputs element categories and boundary locations, and determines the relationship type.

[0081] For joint constraint classification and relation determination, this embodiment uses the following objective function:

[0082] Z = θ·∑p xp·yp-κ·∑q zq^2, where Z is the overall objective, xp is the class score, yp is the corresponding weight, zq is the relation consistency penalty, and θ and κ are tradeoff coefficients whose values ​​are constrained by the sample size and error upper limit. The two terms are connected by a "-", with the left side representing the "classification confidence incentive" and the right side representing the "relation consistency penalty." The difference between the two terms constitutes the quantification criterion for the joint optimization objective of the semantic element extractor. After the model converges on the validation set, it is solidified for inference services.

[0083] Subsequently, the semantic element extractor is invoked by the inference pipeline, outputting test targets and scene constraints for each scene fragment, and mapping the extraction boundaries back to the primary keys of the structured records. The inference results are compared for consistency with the requirement feature matrix, and conflicting items are backtracked to high-confidence elements according to weights and penalties to form a test requirement matrix. This matrix contains scene primary keys, target descriptions, constraint labels, and confidence markers, which can be directly read by the scene similarity calculation model in step S101.

[0084] Finally, the test requirement matrix, along with the version information of the identification and mapping rules, is registered as a traceable product. Subsequently, when the test case set is generated in step S101, the original slot and caliber label are directly traced back by the scenario primary key of the matrix to verify the consistency of extraction of similar scenarios and to serve as the basis for assertion caliber during the code generation stage.

[0085] In one embodiment of the automated test code generation method based on a large language model in this application, it may further include the following:

[0086] Step S301: Decompose the test requirement matrix according to the preset feature extraction rules, construct the scene feature vector space, establish the scene semantic representation model, calculate the correlation strength between scene elements based on the representation model, and generate a scene feature relationship graph.

[0087] Step S302: Construct a similarity metric based on the scene feature relationship graph, perform clustering and association analysis on historical test scene data, establish a scene knowledge relationship network, extract test scene patterns according to the relationship network, and generate a test case set containing test paths and verification rules.

[0088] First, this embodiment reads the test requirement matrix and its column labels output in step S202, decomposes the matrix according to preset feature extraction rules, and encodes "test target, input conditions, triggering actions, expected results, and scene constraints" into sub-vectors. The processing actions standardize the fields according to a glossary and dimensional definitions, and set explicit Boolean bits for negation markers and boundary conditions to obtain the initial embeddings of scene fragments. The initial embeddings are aggregated into sample batches under the scene primary key, serving as input for the construction of the feature vector space.

[0089] Next, the initial embedding is read by the feature space builder of this embodiment and encoded in parallel on two channels: sparse slots and dense semantics, to establish a scene feature vector space. The feature space maintains the interpretability of discrete elements in the sparse channels, aggregates phrase semantics through a context window in the dense channels, and establishes an alignment mapping between the two channels to form a traceable feature index. This index is used to constrain the downstream representation model to be able to refer back to the original slots and caliber labels when calculating associations.

[0090] Then, the feature vector space is read by the scene semantic representation model, which is named Scene Semantic Representer. The input is a multi-channel vector of a single scene, and the output is a scene representation with a unified dimension and the correlation strength between elements.

[0091] To jointly characterize key elements and suppress noise, this embodiment sets the objective function as follows:

[0092] H=α·∑r ur·vr-β·∑s ms^2,

[0093] Where H is the training objective, ur is the projected component of the r-th feature channel, vr is the corresponding attention weight, ms is the regularization coefficient, and α and β are trade-off parameters whose values ​​are constrained by the sample size and error upper limit. The two terms are connected by a "-", with the left side representing the "key feature representation incentive" and the right side representing the "parameter regularization penalty". The difference between the two constitutes the quantification criterion for the joint training objective of the scene semantic representation. After training, the model outputs the association strength of feature pairs for each scene, which serves as the edge weight for subsequent relation graph generation.

[0094] Based on the aforementioned association strength, this embodiment generates a scene feature relationship graph. The graph uses scenes as nodes and feature pairs within the same scene as edges. Edge weights are derived from the output of the scene semantic representation and include slot source and negation markers. To ensure traceability, the nodes retain the scene primary key, and the edges retain anchor points mapped back to the column domains of the test requirement matrix. This relationship graph serves as a direct input for cross-scene analysis, providing a unified structure for clustering and association mining.

[0095] Based on the aforementioned scene feature relationship diagram, this embodiment constructs a similarity measurement standard, defining two types of quantities: node-level similarity and subgraph-level similarity. Node-level similarity is calculated based on the weighted cosine of the element weights, while subgraph-level similarity is calculated based on the matching degree between the set of shared edges and the distribution of edge weights, with penalties applied when the negation labels are inconsistent. The measurement standard registers weight calibers under version control to ensure consistent interpretation across different batches of data.

[0096] Subsequently, the similarity metric is read by the clusterer and association analyzer to perform clustering and nearest neighbor retrieval on historical test scene data. The clusterer forms initial clusters based on node-level similarity and performs secondary merging based on subgraph-level similarity to obtain a stable set of scene clusters. The association analyzer counts co-occurring paths within clusters, extracts high-frequency triggering sequences and common assertion combinations to form a scene knowledge relationship network. This network uses clusters as supernodes and cross-cluster transferable paths as edges, with edge attributes recording applicable preconditions and boundary conditions.

[0097] Based on the aforementioned scene knowledge relationship network, this embodiment extracts test scene patterns. The pattern extractor traverses along the high-weighted edges of the network, collects reusable "pre-triggered-verified" links, and prunes conflicting edges according to subgraph-level similarity and boundary consistency. The extracted patterns are encoded into test paths, and the verification expressions on the paths are written back into verification rules through a terminology list, forming executable rule fragments.

[0098] For example, this embodiment identifies a chain of "account status check - balance calculation - deduction request - error code verification" within the payment-related cluster. This chain coexists in multiple scenarios and has consistent boundaries, thus it is extracted as a test path. The corresponding error codes and prompt text are mapped to verification rules through a glossary to ensure consistency in assertion expression and terminology. This example is only used to illustrate the conversion method from chain to rule.

[0099] Finally, the test paths and verification rules are assembled into a test case set, and a one-to-one mapping is established with the scenario primary key of the test requirement matrix in step S101. The test case set records the source cluster number and metric version during generation, which is used to read the code generation rules in subsequent steps. Later, when code mapping and script generation are executed in step S102, the path order and assertion criteria are directly read from this test case set, completing the connection from semantic representation to executable script.

[0100] In one embodiment of the automated test code generation method based on a large language model in this application, it may further include the following:

[0101] Step S401: Construct a code mapping rule set based on the test framework template library, map the test conditions and expected results in the test case set to code structure templates, establish a code syntax conversion model, and generate initial test code according to the conversion model;

[0102] Step S402: Perform static analysis on the initial test code, build an optimization strategy library based on code quality evaluation indicators, refactor and optimize the code structure according to the optimization strategies, establish a code adaptation mechanism, and generate test code snippets that conform to the framework specifications.

[0103] First, this embodiment reads the test case set and its path order generated in step S302, accesses the test framework template library, and performs field alignment and caliber verification on the test conditions and expected results of each test case. The alignment action, based on a unified glossary and dimensional rules, maps data construction, environment preconditions, and assertion expressions into placeholder structures of "precondition blocks, step blocks, and verification blocks," forming a list to be mapped, which serves as input to the code mapping rule set.

[0104] Next, the list of items to be mapped is read by the code mapping rule set generator in this embodiment. Based on the framework specifications and constraint declarations in the test framework template library, a one-to-one mapping from "use case slot → code structure template" is established. The mapping rules clarify the correspondence between parameter injection locations, data factory interfaces, and assertion syntax, and provide optional branches for asynchronous calls and resource initialization declarations. After processing by this rule set, a code structure template instance is output, retaining the use case number and scenario primary key for backtracking during the syntax conversion phase.

[0105] Then, the code structure template instance is loaded by the code syntax transformation model of this embodiment, which is named a syntax mapper. The syntax mapper reads the template placeholders and context type information, and decodes the high-level actions into function calls and decorator combinations of the target framework.

[0106] To ensure the stability and maintainability of the constraint transformation, this embodiment defines a joint objective function:

[0107] T=φ·∑a ra·sa-ψ·∑b kb^2.

[0108] In the formula, T represents the conversion quality target, ra represents the matching score of the a-th type of sentence fragment, sa represents the corresponding weight, kb represents the penalty for violations of frame constraints, and φ and ψ are trade-off coefficients whose values ​​are limited by the rule version and the upper bound of errors. The two terms are connected by a "-", with the left side representing the "sentence matching quality incentive" and the right side representing the "frame violation penalty". The subtraction of the two terms constitutes the joint optimization criterion for the conversion quality of the syntax mapper. Under this target, the syntax mapper generates initial test code and records the mapping relationship from each placeholder to a specific line of code.

[0109] Based on the initial test code, this embodiment initiates a static analysis process. The static analyzer scans for dependencies, complexity, and resource usage, identifies circular dependencies and redundant constructs, extracts a list of code smells, and locates issues to use case slots in the aforementioned mapping relationship. The analysis results are standardized into quality assessment metrics, covering naming conventions, branch depth, and assertion granularity, and used as search keys for the optimization strategy library.

[0110] Based on the aforementioned quality assessment metrics, this embodiment constructs an optimization strategy library, mapping strategies to specific refactoring actions according to problem type. For excessively long step blocks, extraction functions and parameterized test case strategies are applied; for long chains of assertions, they are broken down into atomic assertions and aggregated reports are introduced; for repetitive data construction, it is upgraded to a data factory and the construction results are cached; for external dependencies, stub modules and timeout protection are inserted. After each strategy is executed, the reason for the rewrite and the scope of impact are written back to ensure that subsequent adaptation mechanisms can read it.

[0111] Then, the refactored code is taken over by the code adaptation mechanism of this embodiment. The adaptation mechanism matches the version characteristics of the target framework with the runtime baseline, selects and injects an adaptation layer, including asynchronous execution decorators, retry wrappers, and resource cleanup hooks. The mechanism also estimates fragment-level execution overhead based on historical runtime baselines and labels each test function with three scheduling tags: "concurrency-friendly," "sequential execution," and "external dependency," which serve as the basis for script synthesis and task orchestration.

[0112] Under the constraints of the scheduling tags, this embodiment synthesizes the code into a set of executable test code snippets according to the use case path order. The synthesizer ensures that the topological order of initialization and destruction is not disrupted and extracts common pre-processors to the device-level fixture to reduce duplication overhead. Metric sampling probes are embedded within the snippets, covering start time, end time, assertion pass, and error stack summary. The probes are named in accordance with a unified metric namespace for subsequent data collection and reconciliation.

[0113] For example, when the use case description is "Insufficient balance, deduction refused," this embodiment maps account preparation to a pre-block, the deduction request to a step block, and the error code assertion and the prompt text assertion to two atomic verification blocks. If the initial code output by the syntax mapper contains an excessively long assertion chain, the static analyzer will trigger a splitting strategy and inject a stub module and timeout control into the external payment gateway in the adaptation mechanism to generate a fragment that conforms to the framework specification.

[0114] Finally, the test code snippet, along with the scheduling tag and mapping traceability information, is registered as a versioned artifact, serving as direct input to the script update and execution control system in step S102. Subsequent running phases use this data for task distribution and data collection, outputting result data including execution status and performance indicators, providing a stable source for the test result evaluation rules and attribution analysis methods in step S103.

[0115] In one embodiment of the automated test code generation method based on a large language model in this application, it may further include the following:

[0116] Step S501: Construct a script update strategy based on the test environment configuration information, dynamically analyze the test execution script, establish a script execution dependency graph, generate a task scheduling sequence based on the dependency graph, and construct a scheduling scheme that includes execution priority and resource allocation;

[0117] Step S502: Run the test script set based on the scheduling scheme, establish performance monitoring rules, sample and analyze the system status and resource usage during script execution, construct a test data acquisition model, and generate a result dataset containing execution trajectory and performance metrics.

[0118] First, this embodiment reads the test code snippet set and scheduling tags output in step S402, and obtains available nodes, concurrency quotas, and external dependency whitelists by combining them with test environment configuration information. Based on the above inputs, a differential comparison is performed between historical script snapshots and the current snippets to locate affected initialization and destruction segments, and credential placeholders and server endpoints are updated according to environment variable mapping. The update action generates a list of test execution scripts to be run, which will serve as the object of subsequent dynamic analysis.

[0119] Next, the test execution script list is loaded by the dynamic analyzer of this embodiment. In a sandbox environment, it parses import relationships and entry points in dry running mode, capturing declarations of external calls, file handles, and network ports. The dynamic analyzer identifies synchronous and asynchronous boundaries based on scheduling tags and frame decorators within the fragments, extracts dependency pairs, and establishes a script execution dependency graph. This dependency graph uses script functions as nodes and resource, sequence, and session constraints as edges. Edge attributes record lock domains and timeout limits, providing a structural basis for generating scheduling sequences.

[0120] Then, the script execution dependency graph is read by the sequence generator in this embodiment, which calculates the task topology sequence while maintaining dependency constraints. The sequence generator first shrinks the strongly connected components to obtain an acyclic skeleton, and then superimposes concurrent windows and mutex lock markers on the nodes to obtain a candidate task scheduling sequence. To distinguish between critical paths and deferred tasks, the generator introduces priority evaluation, which combines initialization coverage, external dependency density, and assertion density to output a sequence with priority labels.

[0121] Based on the candidate sequences, this embodiment constructs a scheduling scheme that clearly defines execution priorities and resource allocation. The scheme divides the sequences into batches according to the node capabilities and quota constraints of the test environment configuration information. It applies exclusive windows to tasks requiring dedicated resources and allocates thread pools and rate-limiting parameters to concurrent tasks. The scheme also includes a session reuse strategy, maximizing the reuse of sessions with the same external credentials to reduce connection establishment costs. The scheduling scheme serves as a direct input to the runtime controller.

[0122] According to the aforementioned scheduling scheme, this embodiment initiates the execution of the test script set by the startup controller. The controller submits tasks in batches, dispatching critical paths first based on priority, and coordinating cross-node dependencies through distributed locks. During operation, the controller applies exponential backoff and limited retries to failed tasks, and synchronizes the final state and error summary to the event bus to ensure that subsequent monitoring and data collection can be consumed in chronological order.

[0123] Subsequently, the execution process is loaded with the performance monitoring rules of this embodiment, which cover CPU usage, memory growth, handle count, network latency, and external service response. Monitoring probes are placed at function entry points and assertion completion points, generating metric samples according to a dual mechanism of fixed sampling period and event triggering. To avoid sampling from disturbing execution, this embodiment uses sliding window aggregation for high-frequency metrics and directly records the raw values ​​of low-frequency events with timestamps to form a monitoring event stream.

[0124] Based on the aforementioned monitoring event stream, this embodiment constructs a test data acquisition model, unifying the acquisition criteria and aligning multi-source time. The acquisition model aligns the task status output by the execution controller, the performance samples of the monitoring probes, and the exception entries of the error event bus according to the use case number and function name, fills in missing field null markers, and reconstructs cross-thread logs based on causal identifiers. To balance metric aggregation and detailed traceability, the acquisition model simultaneously generates two types of views: a fine-grained event view and an aggregated metric view.

[0125] For example, when a payment use case times out on a step with intensive external dependencies, the monitoring rules will generate peak points in network latency and session reuse metrics. The data collection model will then align these peak points with the corresponding assertion failures and record the number of retries and the backoff interval for subsequent attribution analysis to determine the failure factor.

[0126] Finally, the event view and the metric view are merged into a result dataset, with fields including script identifier, test case number, execution status, start and end times, number of retries, error stack summary, peak CPU and memory usage, network latency percentile, and external dependency response code. This result dataset registers the generated version and scheduling scheme summary, serving as the basis for backtracking the execution control system in step S102, and as the direct input for the test result evaluation rules and attribution analysis methods in step S103.

[0127] In one embodiment of the automated test code generation method based on a large language model in this application, it may further include the following:

[0128] Step S601: Construct a result analysis model based on preset evaluation dimensions, extract multi-dimensional features from the test result dataset, establish failure mode recognition rules, cluster test failure samples based on the recognition rules, and generate a failure cause attribution map.

[0129] Step S602: Construct knowledge extraction rules based on the failure cause attribution graph, perform pattern mining and association analysis on historical test experience data, establish a test knowledge representation model, and generate a knowledge base containing test cases and solutions based on the representation model.

[0130] First, this embodiment reads the result dataset produced in step S502 and aligns the execution status, error stack summary, and performance metrics according to the use case number and script identifier. Based on the three categories of time, resources, and assertions in the preset evaluation dimensions, the original fields are cleaned and standardized, and response latency, CPU peak, memory growth, retry count, and assertion failure codes are encoded as comparable features. After processing, a feature candidate set is output as input to the result parsing model.

[0131] Next, the feature candidate set is read by the result parsing model of this embodiment, named the multidimensional result parser, which uses joint encoding of time-series summaries and anomaly context. The multidimensional result parser calculates the trend slope and peak position within a fixed window and maps the call depth and anomaly type of the error stack to discrete vectors.

[0132] To jointly measure the consistency between anomalies in the metrics and assertion failures, this embodiment defines a scoring function:

[0133] U=ξ·∑i ai·bi-ζ·∑j cj^2,

[0134] Where U is the sample explanatory power score, ai is the normalized value of the i-th performance feature, bi is the weight associated with assertion failure, cj is the uncertainty penalty term for abnormal context, and ξ and ζ are tradeoff coefficients whose values ​​are constrained by sample size and variance. The two terms are connected by a "-", with the left side representing the "incentive for consistency between indicator anomalies and assertion failure" and the right side representing the "uncertainty penalty for abnormal context". The difference between the two constitutes the joint evaluation criterion for sample explanatory power. The score result serves as the triggering basis for failure mode recognition rules.

[0135] Then, the scoring results and feature vectors are read by failure mode recognition rules, which include three parts: threshold determination, pattern profile, and consistency of adjacent windows. The recognition process first filters out suspected samples based on the joint interval of U and key features, and then performs density clustering in a two-dimensional space of call depth and resource peak to obtain several failure clusters. Each cluster is extracted to identify the trigger path, resource bottleneck type, and assertion location, and failure mode entries are output. A mapping is established between the entries and use case numbers to facilitate backtracking to specific script segments.

[0136] Based on the failure mode entries, this embodiment constructs a failure cause attribution graph. The graph uses failure clusters as nodes, connected by edges linked by common triggering paths or shared external dependencies. Edge attributes record co-occurrence frequency and temporal sequence. Key signal bits, such as "connection establishment timeout," "data factory mismatch," and "assertion inconsistency," are attached to the nodes, and a summary of the indicator distribution from the result dataset is retained. This attribution graph serves as direct input for subsequent knowledge extraction, ensuring the traceability of the mapping from patterns to experience.

[0137] Based on the aforementioned attribution graph, this embodiment initiates knowledge extraction rules to perform pattern mining and association analysis on historical test experience data. Knowledge extraction compares node signal bits with historical repair steps to identify reusable solutions, and then merges them according to three categories of slots: scenario preconditions, data construction, and assertion methods. For cases where multiple repair paths exist for the same failure mode, this embodiment prunes the steps according to applicable boundaries and side effect labels, retaining only the set of steps compatible with the current environment.

[0138] Subsequently, the pruned set of steps is read by the test knowledge representation model, named the Test Knowledge Representer, which adopts a four-tuple organization of "scenario primary key—problem type—solution steps—verification evidence". The Test Knowledge Representer explicitly annotates the dependency chains and rollback conditions of the steps and records the source of verification evidence, including the trajectory hash of the successful retry and the regression stability interval of key indicators. The represented entries form structured knowledge fragments, facilitating querying and combination.

[0139] Based on the structured knowledge fragments, this embodiment generates a knowledge base containing test cases and solutions. The knowledge base uses the scenario primary key as the index key and the problem type and external dependencies as secondary keys, storing verified case descriptions and executable step instructions. To facilitate interoperability with the test requirement matrix in step S101, the knowledge base uses the same terminology and maintains consistency in terminology labels, ensuring that the recommendation process can directly return alternative solutions for assertion expressions and data construction.

[0140] For example, when the attribution graph indicates a pattern of "session reuse leading to credential expiration" in a payment-related scenario, this embodiment registers a step guide in the knowledge base to "refresh credentials and shorten session keep-alive during the initialization phase," along with a performance regression range for verifying evidence. This registration is bound to the scenario primary key, enabling subsequent searches to quickly locate the appropriate repair path.

[0141] Finally, the knowledge base provides a retrieval interface and version tags for subsequent optimization of test plans and report generation. When step S103 requires generating analysis results and improvement suggestions, the knowledge base is queried directly using the node identifier of the failure mode. Matching test cases and solutions are returned and written into the report and test case update process, achieving a closed-loop connection from result parsing to knowledge accumulation.

[0142] In one embodiment of the automated test code generation method based on a large language model in this application, it may further include the following:

[0143] Step S701: Construct a knowledge retrieval model based on test requirement features, perform semantic retrieval and similarity matching on the knowledge base, establish test plan recommendation rules, and generate a test optimization plan containing optimization suggestions and improvement measures based on the recommendation rules;

[0144] Step S702: Based on the test optimization scheme, construct a report generation template, organize the test execution results and improvement suggestions in a structured manner, establish a test feedback closed-loop mechanism, update the optimization results to the test case generation stage according to the closed-loop mechanism, and complete the test scheme iteration.

[0145] First, this embodiment reads the knowledge base generated in step S602 and the test requirement matrix obtained in step S202, and aligns the fields of "test target, input conditions, triggering actions, expected results, and scenario constraints" according to the scenario primary key. During processing, the requirement fragments of the current batch are encoded into query vectors, with the vector dimensions mapped one-to-one with the aforementioned terminology table, and the negation flag and the Boolean bits of the boundary conditions are retained. This query vector serves as the direct input in the retrieval stage, ensuring consistency with the terminology of the knowledge base entries.

[0146] Next, the query vector is read by the knowledge retrieval model of this embodiment, which is named the semantic retrieval engine. While maintaining slot interpretability, the semantic retrieval engine integrates sparse features with dense semantic channels to calculate the similarity to knowledge base entries.

[0147] To balance constraint matching and noise suppression, this embodiment sets a search score:

[0148] V=α·∑m pm·qm-β·∑n rn^2.

[0149] In the formula, V represents the overall retrieval score, pm represents the weight of the query in slot m, qm represents the matching degree of the knowledge item to the corresponding slot, rn represents the constraint inconsistency penalty term, and α and β are trade-off coefficients whose values ​​are constrained by slot importance and upper bound of error. The two terms are connected by a "-", with the left side representing the "slot semantic matching incentive" and the right side representing the "constraint inconsistency penalty". The difference between the two constitutes a joint evaluation criterion for the retrieval quality of the semantic retrieval machine. After ranking the scoring results, candidate knowledge fragments are output, retaining the mapping between source items and scene primary keys.

[0150] Then, the candidate knowledge fragments are read by the test scheme recommendation rules, and conflict comparisons are performed under the premise of consistency with the column domains of the current requirement matrix. The recommendation rules first check the compatibility of assertion caliber and data construction, and then determine the compatibility of external dependencies and session strategies. For entries with conflicts, the rules are pruned according to V and boundary coverage, prioritizing the scheme with the fewest changes and coverage of failure modes, to obtain a draft test optimization scheme, and the replacement position and rollback conditions are marked in the entries.

[0151] Based on the draft test optimization plan, this embodiment assembles the plan and verifies its executability. The assembler maps the suggested "pre-triggered-verified" chain back to the code structure template placeholder in step S401, generating a change list for three types of change points: "data construction, session strategy, and assertion expression." Executability verification checks whether dependencies are resolvable and whether stub modules are usable in a dry-running environment, and records any new resource credentials and rate limiting configurations that need to be added. After verification, a test optimization plan is formed, serving as input for subsequent report generation.

[0152] Subsequently, the test optimization plan is read by the report generator, which structures the test execution results and improvement suggestions to build a report generation template. The template uses the scenario primary key as an index and presents sections for "current status indicators, key failure factors, recommended change points, applicable boundaries, and rollback conditions," with each change point accompanied by a summary of verification evidence from the knowledge base. To facilitate implementation, the report also provides revised assertion definitions and data construction examples, maintaining consistency with the glossary.

[0153] According to the aforementioned report, this embodiment establishes a test feedback closed-loop mechanism. The closed-loop mechanism sends the change list of the test optimization scheme to the test case generation process in step S101, synchronously updates the relevant slots, and registers the source knowledge entry and score V in the test case metadata. Simultaneously, the closed loop triggers the bounded rerun of the static analysis and adaptation process in step S402, performing differential verification only on the affected segments to reduce disturbance to irrelevant test cases.

[0154] After the closed-loop mechanism is completed, this embodiment writes the updated use case set and version tags back to the knowledge base index, forming a ternary mapping of "scenario primary key - solution version - evidence hash". This mapping is used for deduplication and priority selection in the subsequent retrieval stage, so that verified solutions are given priority recommendation in similar scenarios. The version tag records the effective time and applicable environment to avoid misuse across environments.

[0155] For example, when the knowledge entry "session keep-alive causes credential expiration" is retrieved in a payment scenario, the semantic search engine increases its V value based on constraint consistency. The recommendation rule selects the change point of "initializing and refreshing credentials and shortening keep-alive" without changing the interface protocol. The report generation template then displays the expected impact scope and rollback threshold. The closed-loop mechanism synchronizes this change to the use case generation and triggers differential verification for payment-related scripts.

[0156] Finally, the report and updated use case set are provided to the subsequent execution control system and attribution analysis method through an interface, serving as the starting point for the next batch of operation and evaluation. Thus, knowledge retrieval and recommendation, report generation and feedback updates form a stable iteration under versioning constraints, ensuring consistency and traceability of the test plan across consecutive batches.

[0157] To effectively address the shortcomings of traditional technologies in areas such as requirement processing, code generation, and result analysis, and to provide technical support for automated testing, this application provides an embodiment of an automated test code generation device based on a large language model for implementing all or part of the aforementioned automated test code generation method based on a large language model. See [link to embodiment]. Figure 2 The automated test code generation device based on a large language model specifically includes the following components:

[0158] The scenario graph construction module 10 is used to establish an input acquisition template based on the requirement description collection configuration rule library, perform structured processing on the test requirement information according to a preset format, generate a requirement parsing rule set, perform semantic analysis and entity recognition based on the parsing rule set, construct a test requirement matrix, establish a scenario similarity calculation model based on the test requirement matrix, analyze historical test scenarios according to the scenario similarity calculation model, generate a scenario knowledge graph, and generate a test case set containing test conditions and expected results based on the scenario knowledge graph.

[0159] The test script construction module 20 is used to build code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, build a code adaptive adjustment mechanism, update the test execution script based on the adjustment mechanism, run the test execution script through the execution control system and perform data collection and task scheduling, and generate a test result dataset containing execution status and performance indicators.

[0160] The automatic testing module 30 is used to analyze the test result dataset based on the test result evaluation rules, construct an attribution analysis method to identify key failure factors, extract test experience according to the knowledge base construction rules, generate a knowledge base containing test cases and best practices, optimize the test plan according to the knowledge retrieval and recommendation mechanism, generate a test report containing analysis results and improvement suggestions, and feed the test report and the knowledge base back to the test case generation stage to complete the test plan update.

[0161] As described above, the automated test code generation device based on a large language model provided in this application can effectively generate test cases through innovative design of a requirement processing system, semantic analysis, and scenario construction. It establishes a reliable testing strategy by constructing a code generation mechanism, combining quality assessment and execution control, and introducing result analysis to ensure continuous improvement of testing through experience accumulation and solution optimization. This method effectively solves the shortcomings of traditional technologies in requirement processing, code generation, and result analysis, providing technical support for automated testing.

[0162] From a hardware perspective, in order to effectively address the shortcomings of traditional technologies in areas such as requirement processing, code generation, and result analysis, and to provide technical support for automated testing, this application provides an embodiment of an electronic device for implementing all or part of the aforementioned automated test code generation method based on a large language model. The electronic device specifically includes the following components:

[0163] The system comprises a processor, memory, a communication interface, and a bus; wherein the processor, memory, and communication interface communicate with each other via the bus; the communication interface is used to realize information transmission between the automated test code generation device based on a large language model and core business systems, user terminals, and related databases and other related devices; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the automated test code generation method based on a large language model and the embodiments of the automated test code generation device based on a large language model, the content of which is incorporated herein, and repeated details will not be described again.

[0164] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.

[0165] In practical applications, parts of the automated test code generation method based on a large language model can be executed on the electronic device side as described above, or all operations can be completed on the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed on the client device, the client device may further include a processor.

[0166] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0167] Figure 3 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 3 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 3 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0168] In one embodiment, the automated test code generation method based on a large language model can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following controls:

[0169] Step S101: Based on the requirement description, establish an input acquisition template from the configuration rule base; perform structured processing on the test requirement information according to a preset format to generate a requirement parsing rule set; perform semantic analysis and entity recognition based on the parsing rule set to construct a test requirement matrix; establish a scenario similarity calculation model based on the test requirement matrix; analyze historical test scenarios according to the scenario similarity calculation model to generate a scenario knowledge graph; and generate a test case set containing test conditions and expected results based on the scenario knowledge graph.

[0170] Step S102: Construct code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, construct a code adaptive adjustment mechanism, update the test execution script based on the adjustment mechanism, run the test execution script through the execution control system and perform data collection and task scheduling, and generate a test result dataset containing execution status and performance indicators;

[0171] Step S103: Analyze the test result dataset based on the test result evaluation rules, construct an attribution analysis method to identify key failure factors, extract test experience according to the knowledge base construction rules, generate a knowledge base containing test cases and best practices, optimize the test plan according to the knowledge retrieval and recommendation mechanism, generate a test report containing analysis results and improvement suggestions, and feed the test report and the knowledge base back to the test case generation stage to complete the test plan update.

[0172] As described above, the electronic device provided in this application, through an innovatively designed requirements processing system, achieves effective test case generation via semantic analysis and scenario construction. It establishes a reliable testing strategy by constructing a code generation mechanism, combining quality assessment and execution control. Furthermore, it introduces result analysis, ensuring continuous improvement of testing through experience accumulation and solution optimization. This method effectively addresses the shortcomings of traditional technologies in requirements processing, code generation, and result analysis, providing technical support for automated testing.

[0173] In another embodiment, the automated test code generation device based on a large language model can be configured separately from the central processing unit 9100. For example, the automated test code generation device based on a large language model can be configured as a chip connected to the central processing unit 9100, and the automated test code generation method function based on a large language model can be implemented through the control of the central processing unit.

[0174] like Figure 3 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 3 All components shown; in addition, the electronic device 9600 may also include Figure 3 For components not shown, please refer to existing technologies.

[0175] like Figure 3 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.

[0176] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.

[0177] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0178] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.

[0179] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0180] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0181] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.

[0182] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the automated test code generation method based on a large language model, where the execution subject is a server or client, as described in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the automated test code generation method based on a large language model, where the execution subject is a server or client, as described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps:

[0183] Step S101: Based on the requirement description, establish an input acquisition template from the configuration rule base; perform structured processing on the test requirement information according to a preset format to generate a requirement parsing rule set; perform semantic analysis and entity recognition based on the parsing rule set to construct a test requirement matrix; establish a scenario similarity calculation model based on the test requirement matrix; analyze historical test scenarios according to the scenario similarity calculation model to generate a scenario knowledge graph; and generate a test case set containing test conditions and expected results based on the scenario knowledge graph.

[0184] Step S102: Construct code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, construct a code adaptive adjustment mechanism, update the test execution script based on the adjustment mechanism, run the test execution script through the execution control system and perform data collection and task scheduling, and generate a test result dataset containing execution status and performance indicators;

[0185] Step S103: Analyze the test result dataset based on the test result evaluation rules, construct an attribution analysis method to identify key failure factors, extract test experience according to the knowledge base construction rules, generate a knowledge base containing test cases and best practices, optimize the test plan according to the knowledge retrieval and recommendation mechanism, generate a test report containing analysis results and improvement suggestions, and feed the test report and the knowledge base back to the test case generation stage to complete the test plan update.

[0186] As described above, the computer-readable storage medium provided in this application, through an innovative design of a requirements processing system, achieves effective generation of test cases through semantic analysis and scenario construction. It establishes a reliable testing strategy by constructing a code generation mechanism, combining quality assessment and execution control. Furthermore, it introduces result analysis, ensuring continuous improvement of testing through experience accumulation and solution optimization. This method effectively addresses the shortcomings of traditional technologies in requirements processing, code generation, and result analysis, providing technical support for automated testing.

[0187] Embodiments of this application also provide a computer program product capable of implementing all steps in the automated test code generation method based on a large language model, where the execution subject is a server or client, as described in the above embodiments. When executed by a processor, this computer program / instruction implements the steps of the automated test code generation method based on a large language model. For example, the computer program / instruction implements the following steps:

[0188] Step S101: Based on the requirement description, establish an input acquisition template from the configuration rule base; perform structured processing on the test requirement information according to a preset format to generate a requirement parsing rule set; perform semantic analysis and entity recognition based on the parsing rule set to construct a test requirement matrix; establish a scenario similarity calculation model based on the test requirement matrix; analyze historical test scenarios according to the scenario similarity calculation model to generate a scenario knowledge graph; and generate a test case set containing test conditions and expected results based on the scenario knowledge graph.

[0189] Step S102: Construct code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, construct a code adaptive adjustment mechanism, update the test execution script based on the adjustment mechanism, run the test execution script through the execution control system and perform data collection and task scheduling, and generate a test result dataset containing execution status and performance indicators;

[0190] Step S103: Analyze the test result dataset based on the test result evaluation rules, construct an attribution analysis method to identify key failure factors, extract test experience according to the knowledge base construction rules, generate a knowledge base containing test cases and best practices, optimize the test plan according to the knowledge retrieval and recommendation mechanism, generate a test report containing analysis results and improvement suggestions, and feed the test report and the knowledge base back to the test case generation stage to complete the test plan update.

[0191] As described above, the computer program product provided in this application, through an innovatively designed requirements processing system, achieves effective test case generation through semantic analysis and scenario construction. It establishes a reliable testing strategy by constructing a code generation mechanism, combining quality assessment and execution control. Furthermore, it introduces result analysis, ensuring continuous improvement of testing through experience accumulation and solution optimization. This method effectively addresses the shortcomings of traditional technologies in requirements processing, code generation, and result analysis, providing technical support for automated testing.

[0192] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0193] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0194] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0195] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0196] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for generating automated test code based on a large language model, characterized in that, The method includes: An input acquisition template is established based on the requirement description collection and configuration rule base. The test requirement information is structured according to a preset format to generate a requirement parsing rule set. Semantic analysis and entity recognition are performed based on the parsing rule set to construct a test requirement matrix. A scenario similarity calculation model is established based on the test requirement matrix. Historical test scenarios are analyzed according to the scenario similarity calculation model to generate a scenario knowledge graph. A test case set containing test conditions and expected results is generated based on the scenario knowledge graph. Based on a preset test framework template, code generation rules are constructed, and the test case set is converted into code snippets according to the generation rules. Optimization is performed according to quality assessment standards, and a code adaptive adjustment mechanism is constructed. This includes: constructing a code mapping rule set based on a test framework template library; mapping the test conditions and expected results in the test case set to code structure templates; establishing a code syntax conversion model; generating initial test code based on the conversion model; performing static analysis on the initial test code; constructing an optimization strategy library based on code quality assessment indicators; refactoring and optimizing the code structure according to the optimization strategies; establishing a code adaptation mechanism; and generating test code snippets that conform to the framework specifications. The test execution script is updated based on the aforementioned adjustment mechanism. The test execution script is then run through an execution control system, and data collection and task scheduling are performed to generate a test result dataset containing execution status and performance metrics. This includes: constructing a script update strategy based on test environment configuration information; dynamically analyzing the test execution script; establishing a script execution dependency graph; generating a task scheduling sequence based on the dependency graph; constructing a scheduling scheme containing execution priority and resource allocation; running a set of test scripts based on the scheduling scheme; establishing performance monitoring rules; sampling and analyzing system status and resource usage during script execution; constructing a test data collection model; and generating a result dataset containing execution trajectories and performance metrics. The test result dataset is analyzed based on test result evaluation rules. An attribution analysis method is constructed to identify key failure factors. Test experience is extracted according to knowledge base construction rules, generating a knowledge base containing test cases and best practices. This includes: constructing a result parsing model based on preset evaluation dimensions; extracting multi-dimensional features from the test result dataset; establishing failure pattern recognition rules; clustering test failure samples based on the recognition rules to generate a failure cause attribution map; constructing knowledge extraction rules based on the failure cause attribution map; performing pattern mining and association analysis on historical test experience data; establishing a test knowledge representation model; and generating a knowledge base containing test cases and solutions based on the representation model. The test plan is optimized based on the knowledge retrieval and recommendation mechanism, and a test report containing analysis results and improvement suggestions is generated. The test report and the knowledge base are then fed back to the test case generation stage to complete the test plan update.

2. The automated test code generation method based on a large language model according to claim 1, characterized in that, The process involves establishing an input acquisition template based on a requirement description collection and configuration rule base, structuring the test requirement information according to a preset format to generate a requirement parsing rule set, performing semantic analysis and entity recognition based on the parsing rule set, and constructing a test requirement matrix, including: Establish rules for identifying demand elements, construct a demand description parser based on a preset collection template, segment and label the input text based on the parser, extract key demand element information, construct a demand description vector, and generate a demand feature matrix containing demand element identifiers and relationships. Based on the aforementioned requirement feature matrix, a requirement information mapping rule is constructed. The requirement element information is then structurally transformed according to a standard format to establish a requirement semantic parsing model. Based on the parsing model, semantic analysis and entity extraction are performed on the requirement elements to generate a test requirement matrix containing test objectives and scenario constraints.

3. The automated test code generation method based on a large language model according to claim 1, characterized in that, The process involves establishing a scenario similarity calculation model based on the test requirement matrix, analyzing historical test scenarios according to the scenario similarity calculation model, generating a scenario knowledge graph, and generating a test case set containing test conditions and expected results based on the scenario knowledge graph, including: The test requirement matrix is ​​decomposed according to the preset feature extraction rules to construct a scene feature vector space, establish a scene semantic representation model, calculate the correlation strength between scene elements based on the representation model, and generate a scene feature relationship graph. Based on the scene feature relationship graph, a similarity measurement standard is constructed. Clustering and association analysis are performed on historical test scene data to establish a scene knowledge relationship network. Test scene patterns are extracted based on the relationship network to generate a test case set containing test paths and verification rules.

4. The automated test code generation method based on a large language model according to claim 1, characterized in that, The step of optimizing the test plan based on the knowledge retrieval and recommendation mechanism, generating a test report containing analysis results and improvement suggestions, and feeding the test report and the knowledge base back to the test case generation stage to complete the test plan update includes: A knowledge retrieval model is constructed based on the characteristics of test requirements. Semantic retrieval and similarity matching are performed on the knowledge base. Test plan recommendation rules are established, and test optimization plans containing optimization suggestions and improvement measures are generated based on the recommendation rules. Based on the aforementioned test optimization scheme, a report generation template is constructed. The test execution results and improvement suggestions are structured and organized to establish a test feedback closed-loop mechanism. According to the closed-loop mechanism, the optimization results are updated to the test case generation stage to complete the test scheme iteration.

5. An automated test code generation device based on a large language model, characterized in that, The device includes: The scenario graph construction module is used to establish input acquisition templates based on the requirement description collection configuration rule library, perform structured processing on test requirement information according to a preset format, generate a requirement parsing rule set, perform semantic analysis and entity recognition based on the parsing rule set, construct a test requirement matrix, establish a scenario similarity calculation model based on the test requirement matrix, analyze historical test scenarios according to the scenario similarity calculation model, generate a scenario knowledge graph, and generate a test case set containing test conditions and expected results based on the scenario knowledge graph. The test script construction module is used to build code generation rules based on a preset test framework template, convert the test case set into code snippets according to the generation rules, optimize them according to quality assessment standards, and build a code adaptive adjustment mechanism. This includes: building a code mapping rule set based on a test framework template library; mapping the test conditions and expected results in the test case set to code structure templates; establishing a code syntax conversion model; generating initial test code based on the conversion model; performing static analysis on the initial test code; building an optimization strategy library based on code quality assessment indicators; refactoring and optimizing the code structure according to the optimization strategies; establishing a code adaptation mechanism; and generating test code snippets that conform to the framework specifications. The test execution script is updated based on the adjustment mechanism. The test execution script is then run through the execution control system, and data collection and task scheduling are performed to generate a test result dataset containing execution status and performance metrics. This includes: constructing a script update strategy based on test environment configuration information; dynamically analyzing the test execution script; establishing a script execution dependency graph; generating a task scheduling sequence based on the dependency graph; constructing a scheduling scheme containing execution priority and resource allocation; running the test script set based on the scheduling scheme; establishing performance monitoring rules; sampling and analyzing the system status and resource usage during script execution; constructing a test data collection model; and generating a result dataset containing execution trajectory and performance metrics. An automated testing module is used to analyze the test result dataset based on test result evaluation rules, construct an attribution analysis method to identify key failure factors, extract test experience according to knowledge base construction rules, and generate a knowledge base containing test cases and best practices. This includes: constructing a result parsing model based on preset evaluation dimensions; extracting multi-dimensional features from the test result dataset; establishing failure mode recognition rules; clustering test failure samples based on the recognition rules to generate a failure cause attribution map; constructing knowledge extraction rules based on the failure cause attribution map; performing pattern mining and association analysis on historical test experience data to establish a test knowledge representation model; generating a knowledge base containing test cases and solutions based on the representation model; optimizing the test plan according to a knowledge retrieval and recommendation mechanism; generating a test report containing analysis results and improvement suggestions; and feeding the test report and the knowledge base back to the test case generation stage to complete the test plan update.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the automated test code generation method based on a large language model as described in any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the automated test code generation method based on a large language model as described in any one of claims 1 to 4.

Images