Intelligent configuration method and system for test environment

Abstract

The purpose of this invention is to provide an intelligent configuration method and system for a test environment. The method includes: collecting and parsing code change events; identifying the corresponding function nodes of the code change events in a pre-built code call graph to obtain a set of change nodes; the code call graph records all function nodes in the code repository and the call relationships between them; performing influence domain analysis on each change node based on the code call graph to obtain influence domain analysis results; extracting feature vectors based on the influence domain analysis results; inputting the feature vectors into a pre-trained test environment prediction model to obtain preliminary configuration results; performing conflict checks between the preliminary configuration results and the organization's configuration strategy; adaptively adjudicating conflicting configurations to obtain adjudication results; and generating a standardized environment description file as the final configuration result output based on the adjudication results. This embodiment's method enables intelligent and efficient configuration of the test environment.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an intelligent configuration method and system for a testing environment. Background Technology

[0002] In current software development and continuous integration practices, the configuration management of test environments faces increasingly complex challenges. With the popularization of microservice architecture, agile development, and DevOps practices, the frequency of code repository changes has increased significantly. Each code commit, branch merge, or patch update may require reconfiguration of the associated test environment to ensure the effectiveness and accuracy of the tests.

[0003] In existing technologies, test environment configuration typically relies on human experience, predefined static scripts, or rule-based expert systems. Manual configuration is inefficient and error-prone, especially in large code repositories where developers struggle to fully assess the impact of code changes on upstream and downstream modules and the overall test environment. Static scripts lack dynamic awareness of code changes, often requiring numerous pre-defined conditional branches, resulting in high maintenance costs and poor adaptability. While traditional rule-based configuration systems offer some automation, their rule base construction relies heavily on domain experts and struggles to handle complex transitive dependencies and indirect effects implicit in code call relationships. More critically, existing solutions generally lack the ability to model the intrinsic relationship between code change events and test environment configuration requirements, leading to configuration results that are either overly redundant or incomplete. Furthermore, different organizations or projects often have specific configuration strategies, such as security specifications and compliance requirements. Directly using existing technologies after generating configuration results can easily cause configuration conflicts or policy violations, leading to test execution failures or distorted results.

[0004] Therefore, there is an urgent need for an intelligent test environment configuration method to overcome the shortcomings of existing technologies, such as configuration lag, low accuracy, and frequent conflicts. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent configuration method and system for a test environment. The method in this embodiment can achieve accurate and conflict-free intelligent and efficient configuration of the test environment.

[0006] To address the above problems, embodiments of the present invention provide an intelligent configuration method for a test environment, the method comprising: Code change events are collected and parsed. The corresponding function nodes for each code change event are identified in a pre-built code call graph, resulting in a set of change nodes. The code call graph records all function nodes in the code repository and the call relationships between them. An impact domain analysis is performed on each change node based on the code call graph, yielding the analysis results. Feature vectors are extracted from the impact domain analysis results and input into a pre-trained test environment prediction model to obtain preliminary configuration results. The preliminary configuration results are then compared with the organization's configuration strategy to perform conflict checks. Adaptive adjudication is applied to conflicting configurations to obtain adjudication results. A standardized environment description file is generated based on the adjudication results as the final configuration output.

[0007] In addition, the steps for constructing the code call graph as described above include: performing a full parsing of the code repository, defining all functions as function nodes, defining the call relationships between functions as directed edges; and constructing the code call graph based on each function node and the directed edges between function nodes.

[0008] In addition, the influence domain analysis of each changed node based on the code call graph as described above, to obtain the influence domain analysis results, includes: performing forward propagation analysis on the changed node to determine the function node that calls the changed node as the influence node, and determining the influence weight of each influence node according to the preset propagation rules; and performing backward propagation analysis on the changed node to determine the function node that is called by the changed node as the influence node, and determining the influence weight of each influence node according to the preset propagation rules.

[0009] In addition, before collecting the code change event as described above, the method further includes: synchronizing microservice topology information from the service registry, constructing a service dependency graph, and obtaining historical running data from the historical test environment; the step of extracting feature vectors based on the influence domain analysis results includes: extracting static features based on the change event; extracting influence domain features based on the influence nodes and the influence weights corresponding to each influence node; extracting dependency features based on the service dependency graph; and extracting historical association features similar to the code change event based on the historical running data; and using the static features, the influence domain features, the dependency features, and the historical association features together as the feature vector.

[0010] Furthermore, as described above, inputting the feature vectors into a pre-trained test environment prediction model to obtain preliminary configuration results includes: dividing the feature vectors into numeric feature vectors, selection feature vectors, and dependency feature vectors; inputting the numeric feature vectors into a trained gradient boosting tree sub-model to obtain a first prediction result; inputting the selection feature vectors into a trained random forest sub-model to obtain a second prediction result; inputting the dependency feature vectors into a trained graph neural network sub-model to obtain a third prediction result; and fusing the first prediction result, the second prediction result, and the third prediction result to obtain the preliminary configuration result.

[0011] In addition, as described above, the preliminary configuration result is checked for conflict with the organizational configuration strategy, and the conflicting configurations are adaptively adjudicated to obtain the adjudication result. This includes: obtaining the organizational configuration strategy, which includes: a global hard constraint strategy, a project requirement strategy, an implementation strategy based on resource pool information, and a security compliance strategy; comparing the preliminary configuration result with the organizational configuration strategy to identify the conflict type; and constructing a large model of prompt words that conforms to a preset template based on the conflict type and the scenario context, so that the large model can adaptively adjudicate to obtain the adjudication result.

[0012] In addition, the method described above also includes: after completing the test based on the final configuration result, collecting actual operating data throughout the entire lifecycle of the test process; cross-comparing the preliminary configuration result, the final configuration result, and the actual operating data to obtain error attribution results; and constructing error attribution samples based on the error attribution results to fine-tune the test environment prediction model.

[0013] This invention also proposes an intelligent configuration system for a testing environment, characterized by comprising: The data acquisition module collects and parses code change events, identifies the corresponding function nodes of the code change events in a pre-built code call graph, and obtains a set of change nodes. The code call graph records all function nodes in the code repository and the call relationships between them. The influence domain analysis module performs influence domain analysis on each change node based on the code call graph, and obtains the influence domain analysis results. Based on the influence domain analysis results, feature vectors are extracted and input into a pre-trained test environment prediction model to obtain preliminary configuration results. The configuration output module checks for conflicts between the preliminary configuration results and the organization's configuration strategy, adaptively adjudicates conflicting configurations, and obtains adjudication results. Based on the adjudication results, a standardized environment description file is generated as the final configuration result output.

[0014] This invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described above.

[0015] This invention also proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described above.

[0016] This invention, through collecting and parsing code change events and combining them with a pre-built code call graph for impact domain analysis, can determine the range of function nodes affected by changes. This avoids the omissions or over-configurations common in traditional manual methods or static scripts, significantly improving the targeting and accuracy of configuration. Secondly, by introducing a machine learning prediction model based on feature vector extraction, the test environment configuration can automatically learn the complex mapping relationship between changes and configuration requirements from historical experience, thereby reducing reliance on manually built rule bases by domain experts. Thirdly, by performing conflict checks and adaptive adjudication between the initial configuration results and organizational configuration strategies, the contradiction between intelligent prediction and organizational compliance is effectively resolved. This maintains the flexibility of automated configuration while ensuring compliance with mandatory constraints such as resource usage and security standards, reducing the risk of test failures due to configuration conflicts. Overall, this improves the efficiency and accuracy of the software testing process and reduces operational costs. Attached Figure Description

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 This is a flowchart illustrating the intelligent configuration method for the testing environment according to the first embodiment of the present invention. Figure 2 This is a specific flowchart of step 102 in the second embodiment of the present invention; Figure 3 This is a specific flowchart of step 103 in the third embodiment of the present invention; Figure 4 This is a flowchart illustrating the intelligent configuration method for the testing environment according to the fourth embodiment of the present invention. Figure 5 This is a schematic diagram of the intelligent configuration system for the test environment according to the fifth embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of the electronic device according to the sixth embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this disclosure, and to fully understand and implement the process of how this disclosure applies technical means to solve technical problems and achieve corresponding technical effects, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. The embodiments of this disclosure and the various features within them can be combined with each other without conflict, and the resulting technical solutions are all within the protection scope of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort should fall within the protection scope of this disclosure.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] The first embodiment of this invention relates to an intelligent configuration method for a test environment, applied to an intelligent configuration system for a test environment, such as... Figure 1 As shown, the method in this embodiment specifically includes the following steps 101-103: Step 101: Collect and parse code change events, identify the corresponding function nodes of the code change events in the pre-built code call graph, and obtain a set of change nodes; the code call graph is used to record all function nodes in the code repository and the call relationships between each function node.

[0022] In software development scenarios, code change events can originate from version control systems, such as Git commit hooks, continuous integration server trigger notifications, or code hosting platform webhook callbacks. These events typically include the changed file path, change type (e.g., add, modify, delete), committer information, commit hash, and the specific lines of code involved in the change. In this embodiment, the code change events are specifically Git events (e.g., push, merge, tag).

[0023] After detecting code change events, the code is structured and parsed to extract key information such as the changed function name, its class, or module. A pre-built code call graph is then used to identify the function nodes corresponding to these changes. In this embodiment, the code call graph is a directed graph data structure used to record all function nodes in the code repository and the call relationships between them; each node represents a function, and each directed edge represents a control dependency relationship from the calling function to the called function. The code call graph can be pre-built on the baseline version of the code repository using static analysis tools and incrementally updated as the code evolves. It should be noted that in this embodiment, the function node refers to both independent functions and methods attached to objects / classes. However, since a "method" is essentially a function bound to an object or class, it still conforms to the fundamental definition of a function as an "executable code block, capable of receiving parameters, and capable of returning a value." Therefore, in this embodiment, both are collectively referred to as "function nodes." The function nodes corresponding to the parsed code change events are used as query indexes. Node matching is performed in the code call graph to find all function nodes corresponding to the change events, forming a set of change nodes.

[0024] Step 102: Perform influence domain analysis on each change node based on the code call graph to obtain the influence domain analysis results; extract feature vectors based on the influence domain analysis results, input the feature vectors into the pre-trained test environment prediction model to obtain the preliminary configuration prediction results.

[0025] Specifically, since functions in code do not exist in isolation, the propagation effect of calls can cause a local change to have a cascading effect on the entire chain of dependencies. The code call graph provides a graph structure model to describe this structural dependency relationship. Through the code call graph, the potential impact boundaries of changes can be quantified and predicted, thus providing a reasonable range for test environment configuration. Specifically, after obtaining the set of changed nodes, an impact domain analysis is performed on each changed node in the set to obtain the impact domain analysis results. In this embodiment, the impact domain analysis aims to determine the set of function nodes that one or more changed nodes can affect through call relationships; that is, to assess which other functions might be affected if a certain function is changed. Specifically, each node in the changed node set can be used as a starting point, and multiple rounds of reachability traversal can be performed on the code call graph according to preset impact domain analysis rules. This embodiment does not limit the specific impact domain analysis rules, as long as they are used to analyze the relationship between changed nodes and their affected function nodes.

[0026] After obtaining the influence domain analysis results, feature vectors are extracted based on these results, and these feature vectors are input into a pre-trained test environment prediction model to obtain a preliminary configuration prediction result. In this embodiment, the feature vectors are a set of structured numerical or categorical features extracted from the influence domain analysis results, used to describe the characteristics of code changes and their influence domains. These features may include, but are not limited to: the number of changed nodes, the influence weight of the changed nodes, the total number of nodes in the influence domain, the maximum depth of the influence domain, the average fan-in and fan-out degrees of the call relationships, the hierarchical position of the module where the changed node is located, the change type, and keywords contained in the influence domain, etc. This embodiment does not impose specific limitations on these. The test environment prediction model can employ methods such as decision trees, random forests, gradient boosting machines, or lightweight neural networks. Its training data comes from historical code change events and their corresponding, manually verified, correct test environment configuration samples. During the training phase, the system extracts the aforementioned feature vectors for each historical change event, using the then-effective test environment configuration as a label, and learns the mapping relationship between features and configuration parameters by minimizing the prediction error. After training is complete, when the feature vector of the current change event is input, the model will output a structured or semi-structured preliminary configuration result.

[0027] Step 103: Perform conflict checks between the preliminary configuration results and the organization's configuration strategy, adaptively adjudicate conflicting configurations, and obtain the adjudication results; generate a standardized environment description file based on the adjudication results as the final configuration result output.

[0028] Specifically, after obtaining the initial configuration results, the system performs a conflict check against the organization's configuration policies and adaptively adjudicates conflicting configurations to obtain the adjudication result. The organization's configuration policies are a set of predefined configuration constraints with priorities or mandatory requirements, used to ensure that the test environment conforms to the organization's security, compliance, resource usage, and operational standards. For example, an organization's policy might stipulate that "the maximum memory request limit cannot exceed 8GB." The conflict check process compares each configuration parameter in the initial configuration results with the rules in the organization's policy library one by one to determine if there are any conflicts. If a configuration parameter fully complies with all applicable policies, there is no conflict; if a parameter exceeds the threshold set by the policy or violates a prohibitive clause, it is marked as a conflict. For conflicting configurations, this solution adaptively adjudicates them. In this implementation, adaptive adjudication does not simply reject conflicting configurations, but rather uses configurable adjudication logic to dynamically generate a compromise but still usable configuration scheme for adjudication. In practice, this can be achieved through priority processing based on a rules engine. For example, if the initial configuration requires 16GB of memory while the organization's policy limit is 8GB, the adjudication mechanism will automatically reduce the memory request to 8GB. When policy conflicts involve security prohibitions that cannot be automatically corrected, the adjudication mechanism can trigger an alert and request manual intervention, or call an internal knowledge base to find recommended alternatives. Finally, a standardized environment description file is generated based on the adjudication results. This file explicitly defines all resources, service topology, network rules, and environment variables required for the test environment. This standardized file can be directly parsed and executed by Infrastructure as Code (IaaS) tools, enabling rapid and accurate deployment of the test environment.

[0029] Compared to related technologies, this embodiment, by collecting and parsing code change events and combining them with a pre-built code call graph for impact domain analysis, can determine the range of function nodes affected by changes. This avoids the omissions or over-configurations common in traditional manual methods or static scripts, significantly improving the targeting and accuracy of configuration. Secondly, by introducing a machine learning prediction model based on feature vector extraction, the test environment configuration can automatically learn the complex mapping relationship between changes and configuration requirements from historical experience, thereby reducing reliance on manually built rule bases by domain experts. Thirdly, by performing conflict checks and adaptive adjudication between the initial configuration results and the organization's configuration strategy, the contradiction between intelligent prediction and organizational compliance is effectively resolved. This maintains the flexibility of automated configuration while ensuring compliance with mandatory constraints such as resource usage and security standards, reducing the risk of test failures caused by configuration conflicts. Overall, this improves the efficiency of the software testing process and reduces operational costs.

[0030] The second embodiment of the present invention relates to an intelligent configuration method for a test environment. This embodiment is a supplement to the foregoing embodiments and specifically includes the following contents.

[0031] In one example, the steps to construct the code call graph include: The code repository is fully parsed, all functions are defined as function nodes, and the call relationships between functions are defined as directed edges. The code call graph is constructed based on each function node and the directed edges between each function node.

[0032] Specifically, full parsing refers to performing syntactic and semantic analysis on all source code files in the code repository. This can be implemented using an abstract syntax tree (AST), employing a corresponding parser to convert the code into a structured AST. Then, each function definition node in the tree is traversed, generating a unique identifier for each function, thus forming a set of function nodes. Simultaneously, the statement sequence within each function body is analyzed. When a direct function call expression is encountered, the identifier information of the called function is extracted, and its specific definition is parsed in the symbol table of the current code repository. A directed edge is then established from the calling function node to the called function node. For indirect calls, all potential call relationships are identified through type hierarchy analysis. Finally, based on all function nodes and all directed edges, a complete code call graph is constructed. This graph can be stored in the form of an adjacency list or adjacency matrix, and the corresponding node attribute mapping table is recorded for subsequent lookups. Furthermore, the code call graph in this embodiment should be able to be incrementally updated with code changes. When a new code submission is detected, the changed file is re-parsed, the added or deleted function nodes and edges are calculated, and the original graph is locally incrementally updated using a graph difference algorithm.

[0033] In another example, step 102 performs an impact domain analysis on each change node based on the code call graph, obtaining the impact domain analysis results, including: A forward propagation analysis is performed on the changed nodes to identify the function nodes that call the changed nodes as affected nodes, and the influence weight of each affected node is determined according to a preset propagation rule; and, Perform backpropagation analysis on the changed nodes to identify the function nodes called by the changed nodes as the affected nodes, and determine the influence weight of each affected node according to the preset propagation rules.

[0034] Specifically, forward propagation analysis refers to traversing the code call graph backwards from the changed node, in the opposite direction of the call direction (i.e., along the edges pointing from the called node to the calling node), to identify which functions call the changed node, thus determining the set of function nodes that call the changed node. These functions that call the changed node constitute part of the affected nodes because if the underlying called function changes, the behavior of all its upper-level calling functions may be affected, such as changes in return value semantics, exception types, or differences in execution side effects. Conversely, backward propagation analysis refers to traversing the code call graph from the calling node to the called node, starting from the changed node, to determine the set of function nodes directly or indirectly called by the changed node. These lower-level functions are also marked as affected nodes. If the implementation of an upper-level function changes, its usage of lower-level functions may change, leading to a change in the actual execution context of the lower-level function, thus requiring synchronous configuration adjustments in the test environment associated with the lower-level function. Through bidirectional forward and backward analysis, the system can fully capture the upstream and downstream effects of changes, avoiding omissions that may occur with single-direction analysis. Based on this, the influence weight of each affected node is determined according to preset propagation rules. Influence weight is a quantitative indicator used to represent the degree of potential impact of a change event on that node. Preset propagation rules may include distance decay rules, that is, in the call graph, the farther the number of edges traversed from the changed node, the lower the influence weight. For example, if the influence weight of the changed node itself is set to 1, the influence weight coefficient decays by 50% for each layer of propagation from the changed node. In addition, preset propagation rules may also include call frequency rules. If the number of calls on the edges is recorded in the code call graph, then the weight is positively correlated with the call frequency. This embodiment does not impose specific restrictions on the specific preset propagation rules.

[0035] Based on this, the method of this embodiment further includes: before collecting code change events, the method of this embodiment further includes: synchronizing microservice topology information from the service registry, constructing a service dependency graph, and obtaining historical running data of the historical test environment; At this point, feature vectors are extracted based on the influence domain analysis results, including: Static features are extracted based on change events; influence domain features are extracted based on the affected nodes and their corresponding influence weights; dependency features are extracted based on the service dependency graph; and historical association features similar to code change events are extracted based on historical running data. Static features, influence domain features, dependency features, and historical association features are used together as feature vectors.

[0036] Specifically, the service registry is a common component in microservice architecture, recording all registered service instances and their metadata in the current runtime environment. The system periodically calls the registry's interface to retrieve a complete service registry and analyzes the call dependencies between services. By treating these services as nodes and the call relationships between services as directed edges, a service dependency graph can be constructed. This graph operates at a different level of abstraction than the aforementioned code call graph. The code call graph describes static dependencies at the function level, while the service dependency graph describes the network topology at the runtime service level; the two complement each other. Simultaneously, the system also retrieves historical runtime data from the test environment's historical database or log storage system, including environment configuration parameters for each test execution, such as the number of CPU cores, memory size, database connection pool limit, caching strategy, message queue topics, test results, and code change event identifiers associated with the current test.

[0037] Building upon this foundation, after impact domain analysis, feature vector extraction is performed. This extraction is no longer limited to the impact domain itself but involves multi-source fusion. Specifically: First, static features are extracted based on the change event itself. Static features refer to attributes obtained directly from the code change event without relying on the call graph structure, such as the number of changed files, the number of changed lines of code, the change type, the number of new API endpoints, and the average cyclomatic complexity of the changed nodes. Simultaneously, impact domain features are extracted based on each affected node and its corresponding impact weight obtained from the impact domain analysis. These features characterize the propagation scope and intensity of the change, such as the total number of nodes in the impact domain, the weighted number of affected nodes, the maximum impact depth, the average fan-in and fan-out degrees, and whether it affects core business paths. Furthermore, dependency features are extracted based on the service dependency graph. This involves projecting the affected nodes in the impact domain onto the service dependency graph using the module-to-service mapping relationship recorded in the static code analysis, thereby obtaining the set of services related to the code change and the call topology features between services, such as the number of affected services, the service layer depth, the degree of coupling between services, and whether there are circular dependencies or critical path nodes. Finally, based on historical runtime data, historical correlation features similar to code change events are extracted. Similarity retrieval is then used to identify historical events similar to the current code change event in terms of static features, impact domain features, or service dependency features. The test environment configurations and execution performance characteristics corresponding to these similar historical events are then statistically analyzed. By organically integrating these four types of features, the feature vector can comprehensively describe the configuration requirements of change events from four dimensions: static code attributes, dependency propagation, runtime service architecture, and historical patterns.

[0038] Based on this, such as Figure 2As shown, in step 102, the feature vector is input into the pre-trained test environment prediction model to obtain the preliminary configuration result of the prediction, including the following steps: Step 201: Divide the feature vectors into numeric feature vectors, selection feature vectors, and dependency feature vectors.

[0039] Specifically, after extracting the complete feature vector containing static features, influence domain features, dependency features, and historical association features, the feature vector is first semantically categorized into numerical feature vectors, selection feature vectors, and dependency feature vectors. Numerical feature vectors refer to features with continuous or ordered discrete values, such as the number of lines of code changed, the total number of nodes in the influence domain, the average influence weight, and the predicted value of memory allocation. These features have inherent numerical comparison and computational significance. Selection feature vectors refer to features whose values ​​come from a finite discrete set and typically represent categories or options, such as the change type, the name of the affected service, the database type, and whether network operations are involved. These features are essentially categorical variables. Dependency feature vectors describe the topological relationships and structural dependencies between nodes, such as node degree, clustering coefficient, shortest path length extracted from the service dependency graph, and the vectorized representation of the subgraph adjacency matrix of the affected nodes in the code call graph. After the categorization, the system feeds these three types of features into three pre-trained sub-models.

[0040] Step 202: Input the number class feature vector into the trained gradient boosting tree sub-model to obtain the first prediction result; input the selection class feature vector into the trained random forest sub-model to obtain the second prediction result; input the dependency class feature vector into the trained graph neural network sub-model to obtain the third prediction result.

[0041] Specifically, the numeric feature vector is input into the trained gradient boosting tree sub-model. Gradient boosting trees are an ensemble learning method based on decision trees, which iteratively constructs new decision trees to fit the residuals predicted by the previous tree. XGBoost, LightGBM, or CatBoost can be used, but this embodiment does not impose specific limitations. During training, the gradient boosting tree sub-model uses numeric features from historical samples as input, with corresponding configuration parameters, such as specific numerical configuration items (e.g., number of CPU cores, memory size, timeout seconds), as the regression or classification objective to obtain a first prediction result. The selected class feature vector is input into the trained random forest sub-model. Random forest constructs multiple independent decision trees and outputs results using voting or averaging methods. A random forest classifier or regressor can be used, with the training objective being to predict based on categorical configuration items, outputting a second prediction result. Graph Neural Networks (GNNs) are deep learning models specifically designed for processing graph-structured data. Since dependency features originate from code call graphs and service dependency graphs, GNNs directly take influence domain subgraphs or service dependency subgraphs as input. After several layers of graph convolution, the graph-level representation vector is obtained through a readout function, and then the third prediction result is output through a fully connected layer.

[0042] Step 203: Based on the fusion of the first prediction result, the second prediction result and the third prediction result, a preliminary configuration result is obtained.

[0043] Specifically, the fusion strategy can adopt a weighted average method, which assigns weights based on the performance of each sub-model on the validation set, such as a gradient boosting tree weight of 0.4, a random forest weight of 0.3, and a graph neural network weight of 0.3. The weighted fusion yields the preliminary configuration result.

[0044] Compared with related technologies, this embodiment can significantly improve the accuracy and robustness of configuration prediction while maintaining computational efficiency by selectively allocating and fusing sub-models that each model has its own strengths.

[0045] The third embodiment of the present invention relates to an intelligent configuration method for a test environment. This embodiment is a supplement to the foregoing embodiments, and the supplement is that the steps of step 103 are refined, specifically including the following contents.

[0046] like Figure 3 As shown, step 103 involves: performing a conflict check between the preliminary configuration result and the organizational configuration policy, adaptively resolving conflicting configurations, and obtaining a resolution result. This includes the following steps: Step 301: Obtain the organization configuration policy, which includes: global hard constraint policy, project requirement policy, implementation policy based on resource pool information, and security compliance policy.

[0047] Specifically, organizational configuration strategies consist of various hard constraints determined before configuring the current test environment. Global hard constraints are inviolable bottom-line rules at the organizational level, typically derived from infrastructure operation and maintenance specifications or cost requirements, such as "all test environments are prohibited from accessing the production database" or "maximum memory must not exceed 16GB." These can be stored as Boolean expressions or threshold conditions. This embodiment does not impose specific restrictions on these constraint strategies. Project requirement strategies are differentiated configuration requirements for specific projects, product lines, or business domains. For example, a payment project may require the test environment to enable encryption modules. Specific configurations can be tailored to the needs of different business scenarios, and this embodiment does not impose specific restrictions on this. Implementation strategies based on resource pool information are dynamic strategies, not fixed rules, but constraints or suggestions derived from the current available resource pool status. These strategies are obtained through real-time queries of the resource scheduling system, aiming to make feasible configuration decisions under limited resources. Security compliance strategies include requirements related to data security level protection and privacy compliance.

[0048] Step 302: Compare the preliminary configuration results with the organization's configuration strategy to identify conflict types.

[0049] Specifically, after obtaining the above four types of strategies, the system compares each configuration parameter in the preliminary configuration result with the strategies at each level to identify the conflict type. Conflict types can be classified from multiple dimensions. For example, according to severity, they can be divided into hard conflicts (must be resolved) and soft conflicts (adjustment is allowed); according to the source of the conflict, they can be divided into resource overrun, missing mandatory option, type mismatch, and topology violation, etc. This embodiment does not impose specific limitations on these.

[0050] Step 303: Construct a large model of prompt words that conforms to a preset template based on the conflict type and scene context, so as to make adaptive decisions and obtain the decision results.

[0051] Specifically, after identifying the specific conflict type and its associated organizational policy clauses, an adaptive adjudication is required. This invention introduces a large-scale model for adaptive adjudication. Based on the conflict type and scenario context, prompt words conforming to a preset template are constructed. These prompt words are input into the large-scale model, which then outputs an adjudication result based on its understanding of organizational policy semantics, preset conflict retention priorities, and general reasoning capabilities. The prompt words conforming to the preset template guide the large-scale model to output clear and executable configuration adjustment instructions. For more complex conflict scenarios, such as initial configurations simultaneously violating project requirements and security compliance policies, the large-scale model can comprehensively judge and output a combined adjudication.

[0052] Compared with related technologies, the embodiments of the present invention determine the output results through the above-mentioned conflict checking and large model adaptive adjudication mechanism. The output adjudication results not only respect various mandatory policies, but also make full use of the dynamic information of the current resource pool, which significantly reduces the frequency of manual intervention caused by configuration conflicts, improves the accuracy of test environment configuration, and reduces the risk of conflict.

[0053] The fourth embodiment of the present invention relates to an intelligent configuration method for a test environment. This embodiment is a supplement to the foregoing embodiments, such as... Figure 4 As shown, this embodiment specifically includes the following contents.

[0054] Step 401: After completing the test based on the final configuration result, collect the actual running data of the entire lifecycle of the test process.

[0055] Specifically, after deploying the test environment and executing the corresponding test tasks based on the final configuration results, the configuration process does not end there. Instead, it further collects actual runtime data throughout the entire lifecycle of the test process. This actual runtime data can include information from multiple dimensions, including: resource usage (such as actual CPU utilization, peak memory usage, disk I / O latency, and network bandwidth consumption); test execution (such as the total number of test cases, pass rate, failure rate, exception type distribution, and execution time); environment stability (such as service restart count, connection timeout frequency, and resource leakage alarm records); and configuration compliance (such as whether there are runtime configuration violation alarms and whether there are issues discovered by security scans). This data can be obtained through monitoring agents and log collection systems deployed in the test environment. This embodiment does not limit the specific content or acquisition method.

[0056] Step 402: Cross-compare the preliminary configuration results, the final configuration results, and the actual operating data to obtain the error attribution results.

[0057] Specifically, after the data collection is completed, the system cross-compares the preliminary configuration results, the final configuration results, and the actual operating data to obtain the error attribution results.

[0058] Specifically, cross-comparison refers to comparing the three sets of data pairwise to attribute errors. The goal of error attribution is to determine whether unsatisfactory test results are due to biases in the prediction model itself, excessive or inappropriate modifications to the configuration during the conflict resolution process, unreasonable organizational strategies, or external interference from non-configuration factors in the operating environment. Error attribution can be achieved by constructing a difference analysis engine. This engine first performs field-by-field difference analysis between the initial and final configuration results to obtain a "resolution modification list," recording each configuration parameter adjusted by the strategy and its values ​​before and after the modification. Then, it compares the configuration-related performance indicators in the actual operating data with the expected indicators in the final configuration results to identify significantly deviated indicators. Finally, it uses rules or lightweight statistical models to trace the sources of deviations. If a deviation indicator can form a reasonable causal relationship with a modified field in the resolution modification list, it is considered a deviation. For example, if the memory limit is reduced from the predicted 12GB to 8GB, but the actual peak memory usage reaches 7.9GB with frequent page swapping, this can be attributed to an overcorrection. Conversely, if memory usage is still less than 3GB even with the 8GB limit, it indicates that the prediction model overestimated the demand, which is attributed to model error. If the correction does not involve the relevant fields but the actual performance is abnormal, further analysis is needed to determine whether the code change itself is flawed or the strategy itself is too stringent.

[0059] Step 403: Construct error attribution samples based on the error attribution results to fine-tune the test environment prediction model.

[0060] Specifically, after obtaining the error attribution results, error attribution samples are constructed based on these results to fine-tune the prediction model for the test environment. The specific fine-tuning method depends on the type of sub-model used in the prediction model: for gradient boosting tree sub-models, new decision trees can be added incrementally to fit the error residuals, or a warm-start approach can be used to continue training on the existing model; for random forest sub-models, a weighted training set can be constructed using error attribution samples, and the model can be selectively partially retrained, or periodically retrained fully; for graph neural network sub-models, some lower-level network layers can be frozen based on the pre-trained model, and only the top fully connected layers can be adjusted using error samples, or a small number of gradient descent iterations can be performed. Furthermore, the timing for fine-tuning can be either a small update using error samples immediately after each test, or a unified model update after collecting a certain number of error attribution samples. Regardless of the method used, the goal of fine-tuning is to narrow the gap between the initial configuration predicted by the model and the ideal configuration derived from the actual operating data. The ideal configuration can be obtained by back-calculating the optimal resource allocation from the actual operating data.

[0061] Compared with related technologies, this embodiment uses real running data generated by each test execution as a supervision signal. By cross-comparison to locate the source of error, the prediction model is incrementally fine-tuned, enabling the model to continuously adapt to the latest code change patterns and resource usage rules. The prediction accuracy gradually improves with the number of uses, while reducing the waste of test resources and false positives and false negatives caused by improper environment configuration, thus ensuring the overall adaptive capability of the configuration system.

[0062] The fifth embodiment of the present invention relates to a distributed storage system, such as... Figure 5 As shown, this system includes: The data acquisition module 501 is used to collect and parse code change events, identify the corresponding function nodes of the code change events in the pre-built code call graph, and obtain a set of change nodes; the code call graph is used to record all function nodes in the code repository and the call relationships between each function node; The influence domain analysis module 502 is used to perform influence domain analysis on each change node based on the code call graph to obtain the influence domain analysis results; based on the influence domain analysis results, feature vectors are extracted and input into a pre-trained test environment prediction model to obtain the preliminary configuration prediction results; The configuration output module 503 is used to perform conflict checks between the preliminary configuration results and the organization's configuration strategy, adaptively adjudicate conflicting configurations, and obtain the adjudication result; based on the adjudication result, a standardized environment description file is generated as the final configuration result output.

[0063] In this embodiment, the data acquisition module 501 is also used to collect code change events. The method further includes: synchronizing microservice topology information from the service registry, constructing a service dependency graph, and obtaining historical running data from the historical test environment.

[0064] In some examples, the intelligent configuration system for the test environment in this embodiment also includes: The system update module is used to collect actual operating data throughout the entire lifecycle of the test process after the test is completed based on the final configuration results; cross-compare the preliminary configuration results, final configuration results and actual operating data to obtain error attribution results; and construct error attribution samples based on the error attribution results to fine-tune the test environment prediction model.

[0065] In summary, it is not difficult to see that this embodiment is a system embodiment corresponding to the aforementioned method embodiments. The implementation details described in the above method embodiments are still applicable and effective in this embodiment, and will not be repeated here.

[0066] The sixth embodiment of the present invention relates to an electronic device, such as... Figure 6As shown, it includes at least one processor 602; and a memory 601 communicatively connected to at least one processor 602; wherein the memory 601 stores instructions executable by at least one processor 602, the instructions being executed by at least one processor 602 to enable at least one processor 602 to perform any of the above method embodiments.

[0067] The memory 601 and processor 602 are connected via a bus, which may include any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors 602 and memory 601 together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 602 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 602.

[0068] Processor 602 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 601 can be used to store data used by processor 602 during operation.

[0069] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements any of the above-described method embodiments.

[0070] Another embodiment of the present invention relates to a computer program product, including computer instructions that, when executed by a processor, implement any of the above-described method embodiments.

[0071] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0072] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0073] While the embodiments disclosed herein are as described above, the foregoing content is merely for the purpose of facilitating understanding of this disclosure and is not intended to limit this disclosure. Any person skilled in the art to which this disclosure pertains may make any modifications and changes in form and detail of the implementation without departing from the spirit and scope of this disclosure; however, the scope of patent protection of this disclosure shall still be determined by the scope defined in the appended claims.

Claims

1. A method for intelligent configuration of a test environment, characterized in that, include: Collect and parse code change events, identify the corresponding function nodes of the code change events in the pre-built code call graph, and obtain a set of change nodes; The code call graph is used to record all function nodes in the code repository and the call relationships between each function node; The influence domain analysis of each change node is performed based on the code call graph to obtain the influence domain analysis results. Based on the influence domain analysis results, feature vectors are extracted and input into a pre-trained test environment prediction model to obtain preliminary configuration results. The initial configuration results are compared with the organizational configuration strategy for conflict checks. The conflicting configurations are then adaptively adjudicated to obtain the adjudication result. Based on the ruling, a standardized environment description file is generated as the final configuration result output.

2. The method according to claim 1, characterized in that, The steps for constructing the code call graph include: The code repository is fully parsed, all functions are defined as function nodes, and the call relationships between functions are defined as directed edges. The code call graph is constructed based on each function node and the directed edges between each function node.

3. The method according to claim 1, characterized in that, The influence domain analysis of each change node based on the code call graph yields the following results: A forward propagation analysis is performed on the changed nodes to identify the function nodes that call the changed nodes as influencing nodes, and the influence weight of each influencing node is determined according to a preset propagation rule; and, A backpropagation analysis is performed on the changed node to determine the function node called by the changed node as the affected node, and the influence weight of each affected node is determined according to the preset propagation rule.

4. The method according to claim 3, characterized in that, Before collecting the code change event, the method further includes: synchronizing microservice topology information from the service registry, constructing a service dependency graph, and obtaining historical runtime data from the historical test environment; The extraction of feature vectors based on the influence domain analysis results includes: Static features are extracted based on the change events; and, Influence domain features are extracted based on the influencing nodes and the influence weights corresponding to each influencing node; and... Dependency features are extracted based on the service dependency graph; and... Based on the historical operational data, extract historical correlation features that are similar to the code change event; The static features, the influence domain features, the dependency features, and the historical association features are collectively used as the feature vector.

5. The method according to claim 4, characterized in that, The step of inputting the feature vector into a pre-trained test environment prediction model to obtain the preliminary configuration result includes: The feature vectors are divided into numeric feature vectors, selection feature vectors, and dependency feature vectors. The number class feature vector is input into the trained gradient boosting tree sub-model to obtain the first prediction result; the selection class feature vector is input into the trained random forest sub-model to obtain the second prediction result; and the dependency class feature vector is input into the trained graph neural network sub-model to obtain the third prediction result. The preliminary configuration result is obtained by fusing the first prediction result, the second prediction result, and the third prediction result.

6. The method according to claim 1, characterized in that, The step of performing a conflict check between the preliminary configuration result and the organizational configuration policy, and adaptively adjudicating the conflicting configurations to obtain the adjudication result includes: Obtain the organization configuration policy, which includes: a global hard constraint policy, a project requirement policy, an implementation policy based on resource pool information, and a security compliance policy; The preliminary configuration results are compared with the organizational configuration strategy to identify conflict types; Based on the conflict type and scenario context, a large input model of prompt words conforming to a preset template is constructed, so that the large model can make adaptive decisions and obtain the decision result.

7. The method according to claim 1, characterized in that, The method further includes: After completing the test based on the final configuration result, collect the actual running data of the entire lifecycle of the test process; The preliminary configuration results, the final configuration results, and the actual operating data are cross-compared to obtain the error attribution results. Error attribution samples are constructed based on the error attribution results to fine-tune the test environment prediction model.

8. An intelligent configuration system for a testing environment, characterized in that, include: The data acquisition module is used to collect and parse code change events, identify the corresponding function nodes of the code change events in a pre-built code call graph, and obtain a set of change nodes; the code call graph is used to record all function nodes in the code repository and the call relationships between each function node; The impact domain analysis module is used to perform impact domain analysis on each change node based on the code call graph and obtain the impact domain analysis results. Based on the influence domain analysis results, feature vectors are extracted and input into a pre-trained test environment prediction model to obtain preliminary configuration results. The configuration output module is used to perform conflict checks between the preliminary configuration results and the organization's configuration strategy, adaptively adjudicate conflicting configurations, and obtain the adjudication result. Based on the ruling, a standardized environment description file is generated as the final configuration result output.

9. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements, as in a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method as described in any one of claims 1-7.

Images