Test data processing method and device for production problem feedback, equipment and storage medium

Abstract

This application discloses a test data processing method, apparatus, equipment, and storage medium for production problem feedback, relating to the field of software test data processing technology. The method includes: structuring historical production problem data to obtain structured production problem data; constructing a problem database based on the structured production problem data; determining root cause analysis data based on the problem database in response to newly added production problem data; updating test assets in the problem database based on the root cause analysis data when the root cause analysis data passes correctness verification, obtaining updated test assets; and generating test case data based on the updated test assets in response to system function change data. Through the structured governance and knowledge base construction of historical production problem data, the method achieves automatic determination of the root causes of newly added production problems and dynamic mapping and updating of test assets.

Description

Technical Field

[0001] This application relates to the field of software test data processing technology, and in particular to test data processing methods, apparatus, equipment and storage media for production problem feedback. Background Technology

[0002] As software systems continue to expand in scale and production environments become increasingly complex, the demand for in-depth mining and knowledge reuse of historical problem data in the software testing field is becoming more and more urgent. How to efficiently utilize production problem data to drive the dynamic updating of test assets has become a key link in ensuring software quality.

[0003] However, in existing technologies, testers still need to manually analyze the root causes and write analysis documents for abnormal information in production traffic monitoring, which is time-consuming and prone to repetitive work; the lessons learned from abnormal issues depend on manual processing, and it is difficult to verify whether they are actually applied after the update; in addition, there is no effective connection between test case design and the lessons learned from historical issues, which can easily lead to the omission of key test scenarios.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a method, apparatus, equipment, and storage medium for processing test data for production problem feedback, aiming to solve the technical problem of how to enhance the knowledge correlation of software system production problem data and realize the dynamic updating of test assets.

[0006] To achieve the above objectives, this application proposes a test data processing method for production problem feedback, which includes: Historical production problem data is processed in a structured manner to obtain structured production problem data; A problem database is constructed based on the structured production problem data; In response to newly added production problem data, root cause analysis data is determined based on the problem database; When the root cause analysis data passes the correctness verification, the test assets in the problem database are updated according to the root cause analysis data to obtain the updated test assets. In response to system function change data, test case data is generated based on the updated test assets.

[0007] In one embodiment, the step of structuring historical production problem data to obtain structured production problem data includes: Extract historical production problem data from the historical problem database; Irrelevant fields are removed from the historical production problem data to obtain filtered data; The filtered data is then subjected to field format standardization processing to obtain standard format data; The standard format data is deduplicated to obtain the deduplicated data; The associated system configuration information is used to supplement the missing field information in the deduplicated data to obtain structured production problem data.

[0008] In one embodiment, the step of constructing a problem database based on the structured production problem data includes: The structured production problem data is input into a pre-trained language model for vector representation extraction to obtain vector representation data; The vector representation data is normalized to obtain normalized vector data; The normalized vector data is stored in a distributed vector database to obtain vector storage data; Entity identification and relation extraction are performed on the structured production problem data to obtain entity relation data; A knowledge graph is constructed based on the entity relationship data to obtain graph data; The graph data and the vector storage data are associated and stored to obtain the problem database.

[0009] In one embodiment, the step of determining root cause analysis data based on the problem database in response to newly added production problem data includes: The newly added production problem data is input into the problem database for vector similarity calculation to obtain similar historical problem vectors; The similar historical question vectors are sorted according to the cosine similarity value to obtain a preset number of similar historical question data. The newly added production problem data is classified by a classification model to obtain problem type data, affected module data, and severity data. Based on the problem type data, the impact module data, and the similar historical problem data, and combined with the knowledge graph in the problem database, correlation reasoning is performed to obtain candidate root cause data; The candidate root cause data is corrected by associating system configuration data and environmental variable data to obtain root cause analysis data.

[0010] In one embodiment, the step of obtaining candidate root cause data by performing correlation reasoning based on the question type data, the impact module data, and the similar historical question data, combined with the knowledge graph in the question database, includes: Based on the problem type data and the impact module data, the problem-related entities are determined to obtain the problem entity data; Historical root cause entities associated with the problem entity data are extracted from the knowledge graph in the problem database to obtain historical root cause data. The historical root cause data is matched with the similar historical problem data to obtain candidate root cause paths; Candidate root cause data is obtained by cross-validating the candidate root cause paths with the system configuration data.

[0011] In one embodiment, the step of updating the test assets in the problem database based on the root cause analysis data when the root cause analysis data passes the correctness verification, to obtain the updated test assets, includes: The root cause analysis data is compared and verified with historical production problem data in the problem database to obtain verification result data; When the verification result data is passed, asset update content data is generated based on the root cause analysis data; The document editing interface is called to update the checklist data, test strategy data, and model-based test list data based on the asset update content data, and the updated data is obtained. Generate product design asset data to be updated based on the updated data; The format of the product design asset data to be updated is validated to obtain the validated asset data. The verified asset data is associated with the newly added production problem data and stored in the problem database to obtain the updated test assets.

[0012] In one embodiment, the step of generating test case data based on the updated test assets in response to system function change data includes: Standardize and transform the development-related documentation data to obtain standardized functional description data; Based on the standardized functional description data, the knowledge graph in the problem database is retrieved to obtain relevant and referential data. The data on the association and reference significance are mapped to the data on system function changes to obtain test scenario data; Initial test case data is generated based on the test scenario data; Perform coverage analysis on the initial test case data to obtain coverage analysis results; Based on the coverage analysis results, the execution order of the initial test case data is optimized and regression test cases are added to obtain test case data.

[0013] Furthermore, to achieve the above objectives, this application also proposes a test data processing device for production problem feedback, the device comprising: The data cleaning module is used to perform structured processing on historical production problem data to obtain structured production problem data; The knowledge base construction module is used to construct a problem database based on the structured production problem data; The root cause determination module is used to determine root cause analysis data based on the problem database in response to newly added production problem data. The asset update module is used to update the test assets in the problem database according to the root cause analysis data when the root cause analysis data passes the correctness verification, so as to obtain the updated test assets. The test case generation module is used to generate test case data based on the updated test assets in response to system function change data.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the test data processing method for production problem feedback as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the test data processing method for production problem feedback as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By structuring and building a knowledge base for historical production problem data, the system automatically identifies the root causes of new production problems and dynamically maps and updates test assets. This reduces manual analysis intervention, shortens the root cause analysis cycle for production problems, ensures the timeliness and accuracy of test asset updates, and improves test coverage and anomaly detection rate based on the correlation mapping between historical production problems and system function changes. This forms a continuous improvement closed loop for production problem data from root cause analysis to test asset updates and test case generation. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the test data processing method for production problem feedback in this application. Figure 2 This is a system function overview diagram provided for Embodiment 1 of the test data processing method for production problem feedback in this application; Figure 3 This is a flowchart illustrating Embodiment 2 of the test data processing method for production problem feedback in this application. Figure 4 This is a schematic diagram of the module structure of a test data processing device for production problem feedback according to an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the test data processing method for production problem feedback in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions, or a test data processing device for production problem feedback, etc. The following description uses a test data processing device for production problem feedback as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, embodiments of this application provide a test data processing method for production problem feedback, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the test data processing device method for production problem feedback in this application.

[0025] In this embodiment, the test data processing device method for production problem feedback includes steps S10~S50: Step S10: Perform structured processing on the historical production problem data to obtain structured production problem data; It should be noted that historical production problem data refers to anomaly records generated during software operation in the production environment, including multi-source data such as problem descriptions, error logs, and system logs. Additionally, structured production problem data refers to standardized data that has been formatted in a unified way; that is, data with clearly defined fields and complete information that can be directly used for subsequent analysis and processing.

[0026] It is understandable that historical production problem data is processed in a structured manner, that is, the original abnormal records from multiple sources and heterogeneous structures are formatted and information is supplemented to obtain structured production problem data that can be directly called by subsequent steps.

[0027] This step involves structuring and managing scattered historical production problem data, eliminating redundancy and format differences in the original data, and providing a high-quality data foundation for subsequent knowledge base construction.

[0028] like Figure 2 As shown, the overall architecture comprises three main functional modules: knowledge base construction, new issue analysis, and test design. Each module interacts with the central issue database to form a complete test data processing system. In the knowledge base construction module, historical issues are first input, followed by data cleaning and structuring. The processed data is then vectorized and a knowledge graph is constructed before being stored in the issue database. In the new issue analysis module, a new issue is first input, followed by a search of the vector database for historical similar data. Root cause analysis is generated based on the search results, with the issue database providing data input concurrently. A correctness check is then performed; if the check is negative, the root cause analysis is regenerated; if the check is positive, test assets are automatically updated. The updated assets are output to the checklist, test strategy, and MBT list, and then fed back into the issue database via new issue input, achieving a data loop. In the test design module, development-related documents are first input, then converted into standardized functional descriptions. The knowledge graph is searched based on these descriptions to obtain relevant insights. This search process is supported by graph data provided by the issue database, ultimately generating test cases. As a result, the problem database simultaneously contributes to the retrieval vector database in the newly added problem analysis module, generates root cause analysis, and the retrieval knowledge graph in the test design module.

[0029] In one feasible implementation, step S10 may include steps A11 to A15: Step A11: Extract historical production problem data from the historical problem database; It should be noted that the historical problem database refers to a centralized data set that stores historical production problem data, that is, a persistent storage area that accumulates and manages past anomaly records.

[0030] Understandably, historical production problem data is extracted from the historical problem database, which means reading the accumulated past anomaly records to obtain the original production problem data.

[0031] This step achieves unified collection of production problem data through a centralized historical problem database, ensuring that subsequent processing has a complete data source.

[0032] Step A12: Remove irrelevant fields from historical production problem data to obtain filtered data; It should be noted that irrelevant fields refer to data items that are not directly related to the root cause analysis of the problem, i.e., non-core content that does not affect the judgment result. In this embodiment, irrelevant fields include timestamps and operator information. Furthermore, filtered data refers to the data retained after removing irrelevant fields, i.e., a simplified dataset containing only the core elements of the problem.

[0033] It is understandable that irrelevant fields are removed from historical production problem data, that is, unnecessary content such as timestamps and operator information is removed to obtain filtered data.

[0034] This step reduces data noise by removing irrelevant fields, allowing subsequent processing to focus on the core elements of the problem and improving data processing efficiency.

[0035] Step A13: Standardize the field format of the filtered data to obtain standard format data; It should be noted that field format refers to the representation standard of data items, that is, the unified writing form of information. In this embodiment, field format includes the representation form of error codes and module names. Additionally, standard format data refers to unified data after field format standardization processing, that is, a data set with a consistent representation standard.

[0036] It is understandable that the filtered data undergoes field format standardization, that is, the representation of information such as error codes and module names is standardized to obtain standard format data.

[0037] This step eliminates differences in data representation by standardizing field formats, making data from different sources comparable and searchable.

[0038] Step A14: Perform deduplication on the standard format data to obtain the deduplicated data; It should be noted that deduplication refers to the operation of identifying and removing duplicate data records, that is, the process of determining whether a record is duplicated based on specific rules and retaining the unique record. In this embodiment, deduplication is based on the problem description and error code to identify duplicate problems. Furthermore, the deduplicated data refers to the non-redundant data after duplicate removal, that is, the data set that retains only unique records.

[0039] Understandably, deduplication of standard format data involves identifying duplicate records based on problem descriptions and error codes, removing redundancy, and obtaining deduplicated data.

[0040] This step eliminates the interference of duplicate question records on subsequent analysis by deduplication, reduces data storage redundancy, and improves the efficiency of knowledge base construction.

[0041] Step A15: Use the associated system configuration information to supplement the missing field information in the deduplicated data to obtain structured production problem data.

[0042] It should be noted that configuration information refers to the set of parameters of the software's operating environment, that is, the settings related to the running state when the problem occurred. In this embodiment, associated configuration information includes associated logs and configuration information to supplement the state when the problem occurred. Additionally, field information refers to the specific attribute items in the data record, such as descriptive content like problem type and affected modules.

[0043] Understandably, the associated configuration information supplements the missing field information in the deduplicated data, that is, it retrieves the runtime environment parameters at the time the problem occurred to fill the data gaps and obtain structured production problem data.

[0044] This step completes missing fields by associating with runtime environment configuration information, giving production problem data complete contextual information and improving the accuracy of subsequent root cause analysis.

[0045] Step S20: Construct a problem database based on structured production problem data; It should be noted that the question database refers to a collection of related data that integrates vector storage and knowledge graph, that is, a composite data structure used to support similarity retrieval and relational reasoning.

[0046] Understandably, a problem database is constructed based on structured production problem data, that is, by integrating vector storage and knowledge graphs to form a composite data structure, thus obtaining the problem database.

[0047] This step integrates vector storage and knowledge graphs to construct a problem database that simultaneously possesses semantic similarity retrieval and association reasoning capabilities, providing unified data support for production problem analysis.

[0048] In one feasible implementation, step S20 may include steps A21 to A26: Step A21: Input the structured production problem data into the pre-trained language model to extract vector representations, and obtain vector representation data; It should be noted that a pre-trained language model refers to a text representation model pre-trained on a large-scale corpus, i.e., a neural network model capable of extracting semantic features from text. In this embodiment, the pre-trained language model employs a Bidirectional Encoder Representations from Transformers (BERT) model, fine-tuned for software testing corpora. Furthermore, vector representation data refers to the numerical representation of text after model transformation, i.e., high-dimensional numerical vectors used to measure the similarity between texts.

[0049] Understandably, structured production problem data is input into a pre-trained language model for vector representation extraction, that is, the text is converted into a high-dimensional numerical vector through a neural network model to obtain vector representation data.

[0050] This step uses a pre-trained language model to achieve semantic numerical representation of production problem data, providing a computable data foundation for subsequent similarity retrieval.

[0051] Step A22: Normalize the vector representation data to obtain normalized vector data; It should be noted that normalization refers to the operation of converting data to a uniform scale, that is, the standardization process that eliminates numerical differences and makes vectors comparable. Furthermore, normalized vector data refers to numerical vectors that have undergone scale unification, i.e., standard vectors with consistent length that can be directly used for similarity calculations.

[0052] Understandably, normalizing vector data involves standardizing the numerical scale and length of each vector to obtain normalized vector data.

[0053] This step eliminates the numerical scale differences between vectors through normalization, ensuring the accuracy and stability of subsequent similarity calculation results.

[0054] Step A23: Store the normalized vector data in a distributed vector database to obtain the vector storage data; It should be noted that a distributed vector database refers to a distributed storage engine that supports high-dimensional vector storage and retrieval, i.e., a dedicated database for similarity retrieval of massive vector data. In this embodiment, the distributed vector database includes the Facebook AI Similarity Search (FAISS) library or Milvus. Additionally, vector storage data refers to a persistently stored collection of vectors, i.e., numerical vector data that can be quickly retrieved and accessed.

[0055] Understandably, storing normalized vector data in a distributed vector database involves writing standard vectors into a distributed storage engine to obtain vector storage data.

[0056] This step utilizes a distributed vector database to achieve efficient storage and rapid retrieval of massive vectors, supporting the recall of similar historical issues for subsequent new production problems.

[0057] Step A24: Perform entity identification and relation extraction on the structured production problem data to obtain entity relation data; It should be noted that entity recognition refers to the process of extracting objects with specific semantic categories from text, i.e., the operation of identifying objects such as modules, functions, and error types. Additionally, relation extraction refers to the technical means of identifying semantic relationships between entities in text, i.e., the process of determining the relationships between entities. In this embodiment, relation extraction is implemented using natural language processing technology. Furthermore, entity relation data refers to a data set containing entities and their associated information, i.e., relational data describing the relationships between objects.

[0058] Understandably, entity recognition and relation extraction are performed on structured production problem data, that is, identifying modules, functions and error types from the production problem text and determining the relationships between them to obtain entity relation data.

[0059] This step transforms unstructured text into a structured entity relationship network through entity recognition and relationship extraction, providing directly usable relational data for knowledge graph construction.

[0060] Step A25: Construct a knowledge graph based on entity relationship data to obtain graph data; It should be noted that a knowledge graph refers to a database that organizes entities and their relationships in a graph structure, i.e., a semantic network used to describe complex relationships between objects. Additionally, graph data refers to a collection of data organized in a graph structure, i.e., structured graph data containing nodes and edges.

[0061] Understandably, knowledge graphs are constructed based on entity relationship data, which means organizing entities and their relationships into a semantic network in the form of a graph structure to obtain graph data.

[0062] This step uses knowledge graph construction to organize discrete entity relationship data into a reasonable semantic network, enhancing the relevance and interpretability of production problem data.

[0063] Step A26: Associate the map data with the vector storage data to obtain the problem database.

[0064] It is understandable that the graph data and vector storage data are linked and stored together, that is, the graph structure data and numerical vector data are indexed and linked and saved in a unified manner to obtain the problem database.

[0065] This step integrates graph structure semantics and vector numerical representation through associative storage, enabling the problem database to simultaneously possess semantic reasoning and similarity retrieval capabilities.

[0066] Step S30: In response to newly added production problem data, determine root cause analysis data based on the problem database; It should be noted that newly added production problem data refers to newly monitored abnormal records of the production environment, i.e., the original abnormal information to be analyzed for root causes. Additionally, root cause analysis data refers to the description of the root cause of the problem determined through reasoning, i.e., the structured analysis results including the problem type, influencing modules, and possible causes. In this embodiment, the root cause analysis data is obtained by combining knowledge graph reasoning with consideration of configuration information and environmental variables.

[0067] Understandably, in response to new production problem data, root cause analysis data is determined based on the problem database. That is, new abnormal records are received and the problem database is called for retrieval and reasoning to obtain root cause analysis data.

[0068] This step utilizes the similarity retrieval and graph reasoning capabilities of the problem database to achieve rapid and automatic identification of the root causes of newly added production problems, reducing manual analysis and intervention.

[0069] Step S40: When the root cause analysis data passes the correctness check, update the test assets in the problem database according to the root cause analysis data to obtain the updated test assets. It should be noted that correctness verification refers to the automated process of checking the consistency of root cause analysis results, that is, verifying whether the analyzed data matches and conforms to historical records to determine validity. Additionally, test assets refer to a collection of documents and checklists used to guide testing activities, including checklists, test strategies, and model-based test checklists. In this embodiment, test assets also include product testing guidelines and product design assets. Furthermore, updated test assets refer to the latest test assets updated based on root cause analysis data, that is, test guidance documents containing newly added issues and modified solutions.

[0070] Understandably, when the root cause analysis data passes the correctness check, the test assets in the problem database are updated based on the root cause analysis data. That is, after verifying the validity of the analysis results, the editing interface is called to modify the test guidance document, and the updated test assets are obtained.

[0071] This step ensures the reliability of the root cause analysis results through correctness verification and automatically updates the test assets based on the verified analysis results, thus realizing a closed-loop mapping from production problem analysis results to test guidance documents.

[0072] In one feasible implementation, step S40 may include steps A31 to A36: Step A31: Compare and verify the root cause analysis data with historical production problem data in the problem database to obtain verification result data; It should be noted that the verification result data refers to the judgment information generated after comparison and verification, that is, the identifying data indicating whether the root cause analysis data has passed the verification.

[0073] Understandably, the root cause analysis data is compared and verified with historical production problem data in the problem database. That is, the new analysis results are matched with historical anomaly records to obtain the verification result data.

[0074] This step, by comparing and verifying with historical production problem data, ensures the consistency between the root cause analysis results and existing knowledge, preventing erroneous analysis results from flowing into the test asset update process.

[0075] Step A32: If the verification result data is passed, generate asset update content data based on the root cause analysis data; It should be noted that asset update content data refers to the specific item information used to modify test assets, that is, the set of content to be updated, including new problem descriptions and solution changes.

[0076] Understandably, when the verification result data is passed, asset update content data is generated based on the root cause analysis data. That is, after the verification is passed, the valid information in the root cause analysis results is extracted to form update entries, and thus the asset update content data is obtained.

[0077] This step automatically generates asset update content after verification, ensuring that only verified and reliable analysis results enter the test asset update process, thus improving the accuracy of the update content.

[0078] Step A33: Call the document editing interface to update the checklist data, test strategy data, and model-based test list data based on the asset update content data to obtain the updated data; It should be noted that the document editing interface refers to the program call interface used for automatically modifying document content, i.e., a standardized calling method that supports remote or local editing of test asset documents. Additionally, checklist data refers to list data used to verify test points item by item, i.e., tabular data recording test verification items and their completion status. Furthermore, test strategy data refers to planning data describing the selection of test methods and scope, i.e., decision-making documents specifying test types, priorities, and resource allocation. Further, model-based test checklist data refers to the set of test items generated according to model-driven methods, i.e., a model-based testing (MBT) checklist. Finally, update data refers to the set of modified assets generated after the interface call, i.e., a comprehensive data package containing the latest checklist, test strategy, and checklist data.

[0079] Understandably, calling the document editing interface updates the checklist data, test strategy data, and model-based test list data based on the asset update content data. In other words, it automatically modifies the checklist, test plan, and model-driven list through a standardized interface to obtain updated data.

[0080] This step uses a document editing interface to automate the batch updates of test assets, avoiding the tedious manual modification of each item and ensuring the timeliness and consistency of test asset updates.

[0081] Step A34: Generate product design asset data to be updated based on the updated data; It should be noted that product design asset data refers to documented information describing the product's functional design scheme, i.e., planning materials containing functional definitions, interaction logic, and implementation details. In this embodiment, the product design asset data to be updated is generated from the updated data and pushed to the responsible person for review.

[0082] Understandably, the product design asset data to be updated is generated based on the updated data. That is, based on the updated test asset information, the content that needs to be changed synchronously on the design side is extracted to obtain the product design asset data to be updated.

[0083] This step establishes a data channel between test analysis results and product design documents by deriving design-side change requirements from test asset update content, thus enabling cross-role asset synchronization.

[0084] Step A35: Perform format validation on the product design asset data to be updated to obtain the validated asset data; It should be noted that format verification refers to the operation of checking the document format and content specifications, that is, verifying whether the data to be updated conforms to the preset template and field specifications. Additionally, verified asset data refers to compliant data that has passed the format verification, i.e., valid asset data with a standard format that can be directly entered into the database.

[0085] It is understandable that format validation is performed on the product design asset data to be updated, that is, to check whether the updated content on the design side conforms to the preset document template and field filling specifications, so as to obtain the validated asset data.

[0086] This step ensures the standardization and readability of the updated asset content on the design side through format validation, avoiding subsequent call failures or misunderstandings caused by format errors.

[0087] Step A36: Associate the verified asset data with the newly added production problem data and store it in the problem database to obtain the updated test assets.

[0088] Understandably, the verified asset data is associated with the newly added production problem data and stored in the problem database. That is, the verified design-side assets are indexed and associated with the corresponding abnormal records and saved in a unified manner to obtain the updated test assets.

[0089] This step binds the updated test assets with the production issue data that triggered the update through associated storage, forming a traceable update chain that facilitates quick location of the issue source during subsequent retrieval and retrieval.

[0090] Step S50: In response to system function change data, generate test case data based on the updated test assets.

[0091] It should be noted that functional change data refers to recorded information describing modifications to software functions, i.e., a development-side description of changes including new functions, modified logic, and the scope of impact. In this embodiment, functional change data corresponds to software modification records. Additionally, test case data refers to a set of execution scripts used to verify the correctness of software functions, i.e., verification data including input conditions, execution steps, and expected results.

[0092] Understandably, in response to feature change data, test case data is generated based on the updated test assets. That is, the feature change notification is received, and the verification script is generated by referencing historical issues to obtain test case data.

[0093] This step generates test cases that are targeted at historical issues by associating the analysis results of historical production problems with current functional changes, thereby improving test coverage and anomaly detection rate.

[0094] In one feasible implementation, step S50 may include steps A41 to A46: Step A41: Standardize and transform the development-related document data to obtain standardized functional description data; It should be noted that development-related documentation data refers to technical documents describing the details of software function implementation, i.e., explanatory materials including detailed design documents, code flowcharts, or source code. In this embodiment, development-related documentation data includes detailed design documents, code flowcharts, or directly accessible code provided by the developer. Additionally, standardized functional description data refers to functional descriptions converted to a unified format, i.e., functional description information with a standard structure that can be directly used for retrieval and analysis.

[0095] It is understandable that development-related documentation data needs to be standardized and converted, that is, detailed design documents or code materials are converted into functional specifications in a unified format to obtain standardized functional description data.

[0096] This step eliminates format differences between different development documents through standardized conversion, providing a unified search entry point for function descriptions and facilitating subsequent association and matching with historical issue data.

[0097] Step A42: Retrieve the knowledge graph from the problem database based on the standardized functional description data to obtain relevant and referential data; It should be noted that the relevant reference data refers to historical problem experience data related to the current function, that is, empirical information including the causes of past anomalies, the scope of impact, and the solutions. In this embodiment, the relevant reference data is extracted from the knowledge base.

[0098] Understandably, by retrieving the knowledge graph from the problem database based on the standardized functional description data, relevant and referential data can be obtained. In other words, by searching for relevant historical experience in the graph structure database based on the unified functional description, relevant and referential data can be obtained.

[0099] This step uses knowledge graph retrieval to establish a semantic association between current functions and historical problem experiences, enabling test design to fully utilize the analysis results of past production problems.

[0100] Step A43: Map the relevant reference data with the system function change data to obtain test scenario data; It should be noted that scenario mapping refers to the operation of associating historical experience with current changes, that is, matching referential data with functional change data to specific test scenarios. Additionally, test scenario data refers to a set of data describing the verification scenario and triggering conditions, that is, contextualized information including functional points, abnormal conditions, and verification targets.

[0101] Understandably, mapping relevant reference data with functional change data to specific scenarios involves mapping historical experience and current changes to specific verification contexts to obtain test scenario data.

[0102] This step transforms abstract historical experience into concrete test scenario descriptions through scenario mapping, giving test case generation a clear functional coverage objective.

[0103] Step A44: Generate initial test case data based on the test scenario data; It should be noted that the initial test case data refers to the original verification scripts that have not been optimized, that is, the preliminary set of test cases that contain basic verification steps but have not yet been adjusted for coverage and order.

[0104] Understandably, initial test case data is generated based on test scenario data, that is, basic verification scripts are compiled based on specific verification scenarios to obtain initial test case data.

[0105] This step generates initial test cases based on the test scenario, ensuring that the test design is directly linked to functional changes and historical problem experience, thus avoiding omissions of key test points.

[0106] Step A45: Perform coverage analysis on the initial test case data to obtain the coverage analysis results; It should be noted that coverage analysis refers to the statistical operation of evaluating the degree to which test cases cover functional points; that is, the quantitative evaluation process of calculating the coverage ratio of existing test cases to requirements and code. Furthermore, the coverage analysis result refers to the coverage data obtained after statistical evaluation, which is a numerical or hierarchical description of the completeness of test case coverage.

[0107] Understandably, coverage analysis is performed on the initial test case data, which involves statistically analyzing the coverage ratio of the basic verification scripts to the functional points and code paths to obtain the coverage analysis results.

[0108] This step quantifies the coverage completeness of the initial test cases through coverage analysis, providing clear data basis for subsequent optimization and supplementation.

[0109] Step A46: Optimize the execution order and supplement regression test cases based on the coverage analysis results to obtain test case data.

[0110] It should be noted that execution order optimization refers to the operation of adjusting the execution order of test cases, that is, the process of rearranging the execution sequence of test cases based on dependencies and risk priorities. Additionally, regression test cases are verification scripts added to validate the effectiveness of historical problem fixes; they are dedicated sets of test cases used to repeatedly verify fixed defects to prevent recurrence. In this embodiment, regression test cases are used to ensure the effectiveness of problem fixes.

[0111] Understandably, the execution order of the initial test case data is optimized and regression test cases are supplemented based on the coverage analysis results. That is, the execution order of the test cases is adjusted according to the coverage statistics and historical defect verification scripts are added to obtain the test case data.

[0112] This step improves test execution efficiency by optimizing the execution order and ensures the effectiveness of fixing historical production issues by supplementing with regression test cases, thus forming a complete test verification closed loop.

[0113] This embodiment provides a test data processing method for production problem feedback. By structuring historical production problem data, a complete data set with unified field formats is obtained, eliminating redundancy and noise in the original data and providing a high-quality data foundation for subsequent analysis. The structured production problem data is input into a pre-trained language model for vector representation extraction and stored in a distributed vector database. Simultaneously, a knowledge graph is constructed, forming a problem database that integrates vector retrieval and graph reasoning, enhancing the knowledge correlation between production problem data. In response to new production problem data, vector similarity calculation and knowledge graph association reasoning are performed based on the problem database to automatically determine root cause analysis data, reducing manual analysis intervention and shortening the root cause analysis cycle. When the root cause analysis data passes the correctness verification, the checklist, test strategy, model-based test list, and product design assets are automatically updated, ensuring the timeliness and accuracy of test asset updates and reducing human error. In response to functional change data, test cases targeting historical problems are generated based on the updated test assets and knowledge graph, significantly improving test coverage and problem detection rate.

[0114] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S30 includes steps S301 to S305: Step S301: Input the newly added production problem data into the problem database to calculate the vector similarity and obtain similar historical problem vectors; It should be noted that newly added production problem data refers to newly detected abnormal records of the production environment, i.e., the original abnormal information to be analyzed for root causes. Additionally, the problem database refers to a collection of associated data integrating vector storage and knowledge graphs, i.e., a composite data structure used to support similarity retrieval and relational reasoning. Furthermore, vector similarity calculation refers to the operation of measuring the geometric distance between vectors to determine the degree of text similarity, i.e., the calculation process of comparing the semantic similarity between new problems and historical problems in a numerical way. Further, similar historical problem vectors refer to the numerical representations of historical problems recalled after similarity calculation, i.e., high-dimensional vector forms of past abnormal records that are semantically similar to the new problems.

[0115] Understandably, new production problem data is input into the problem database for vector similarity calculation, which means comparing the geometric distance between the new abnormal records and the historical vectors in the problem database to obtain similar historical problem vectors.

[0116] This step achieves rapid semantic matching between new production problems and historical problems through vector similarity calculation, providing a basis of similar cases for subsequent root cause analysis.

[0117] Step S302: Sort the similar historical question vectors according to the cosine similarity value to obtain a preset number of similar historical question data. It should be noted that the cosine similarity value is a metric that measures the magnitude of the cosine of the angle between two vectors; that is, a standardized value used to characterize the directional consistency between vectors. Additionally, the preset quantity refers to a pre-defined number of returned results, which is a limit controlling the scale of similar historical issues recalled. Furthermore, similar historical issue data refers to specific historical anomaly records after sorting and filtering, that is, past case information including problem descriptions, error codes, and solutions.

[0118] Understandably, similar historical problem vectors are sorted according to cosine similarity values, that is, historical problem vectors are arranged from high to low according to the directional consistency metric, to obtain a preset number of similar historical problem data.

[0119] This step uses cosine similarity ranking to select a predetermined number of historical cases that are most similar to the new problem, thus narrowing the reference range for subsequent root cause analysis and improving the focus of the analysis.

[0120] Step S303: Classify the newly added production problem data by type using a classification model to obtain problem type data, affected module data, and severity data; It should be noted that a classification model refers to a machine learning model trained to determine the category of data; that is, an algorithmic component capable of automatically classifying the type of a problem based on input features. In this embodiment, the classification model includes random forests or neural networks. Furthermore, type classification refers to the discriminative operation of assigning a problem to a preset category; that is, the process of determining the type and scope of impact of a problem based on the model output. Further, problem type data refers to identifying information indicating the category to which a problem belongs; that is, classification results used to distinguish between defects, anomalies, or malfunctions. Further, affected module data refers to information describing the scope of the problem's impact; that is, the determination results indicating the software modules involved in the anomaly. Further, severity data refers to information quantifying the severity level of the problem; that is, the level determination results used to identify the urgency of the problem.

[0121] Understandably, classification models are used to categorize newly added production problem data, that is, machine learning models are used to determine the type of new anomalies, the affected modules, and the severity level, so as to obtain problem type data, affected module data, and severity data.

[0122] This step uses a classification model to automatically determine the category of newly added production problems, providing structured problem attribute inputs for subsequent association reasoning using knowledge graphs.

[0123] Step S304: Based on the problem type data, the impact module data, and similar historical problem data, and combined with the knowledge graph in the problem database, perform correlation reasoning to obtain candidate root cause data; It should be noted that a knowledge graph is a database that organizes entities and their relationships in a graph structure; that is, a semantic network used to describe complex relationships between objects. Furthermore, relational reasoning refers to the process of logical deduction based on the entity relationships in a knowledge graph, that is, analyzing the possible causes of a problem using the relational paths between nodes in the graph structure. Further, candidate root cause data refers to a preliminary set of root causes obtained through reasoning, that is, a description of potential factors that may lead to the occurrence of anomalies.

[0124] Understandably, based on the problem type data, the impact module data, and similar historical problem data, and combined with the knowledge graph in the problem database, correlation reasoning is performed. That is, potential causes are derived from the problem attributes and similar cases in the graph structure database to obtain candidate root cause data.

[0125] This step combines classification attributes, similar cases, and knowledge graphs for association reasoning, enabling automatic deduction from multidimensional data to potential root causes and improving the comprehensiveness of root cause analysis.

[0126] In one feasible implementation, step S304 may include steps A51 to A54: Step A51: Determine the associated entities of the problem based on the problem type data and the impact module data to obtain the problem entity data; It should be noted that the associated entity of a problem refers to the graph node object corresponding to the current problem attribute, that is, the graph node in the knowledge graph that represents the problem type and the module affecting it. Additionally, the problem entity data refers to the graph node information determined after location, that is, the set of entity identifiers used for subsequent relationship deduction.

[0127] Understandably, the problem-related entities are determined based on the problem type data and the impact module data. That is, the corresponding type nodes and module nodes are located in the knowledge graph based on the classification results to obtain the problem entity data.

[0128] This step establishes a bridge between numerical classification and graph structure semantics by mapping the classification results to entity nodes in the knowledge graph, providing an accurate starting point for subsequent relation extraction.

[0129] Step A52: Extract historical root cause entities associated with the problem entity data from the knowledge graph in the problem database to obtain historical root cause data; It should be noted that historical root cause entities refer to node objects in the knowledge graph that represent the root causes of past problems, i.e., root cause description nodes that are related to the problem entity. Additionally, historical root cause data refers to past cause information extracted from historical root cause entities, i.e., descriptive content containing the root causes of historical anomalies.

[0130] Understandably, historical root cause entities associated with the problem entity data are extracted from the knowledge graph of the problem database. That is, the historical root cause nodes associated with the current problem node are searched in the graph structure to obtain the historical root cause data.

[0131] This step extracts historical root causes associated with the current problem entity, utilizing past experience accumulated in the knowledge graph to provide historical basis for determining candidate root causes.

[0132] Step A53: Perform path matching between historical root cause data and similar historical problem data to obtain candidate root cause paths; It should be noted that path matching refers to the operation of comparing the relationship between the paths of association between entities in a knowledge graph and the correspondence with similar cases, that is, the process of verifying the consistency of the connection paths between historical root causes and similar historical problems. Additionally, candidate root cause paths refer to the potential cause transmission links identified after matching, that is, graph structure information describing the relationship between the problem phenomenon and possible root causes.

[0133] Understandably, path matching is performed between historical root cause data and similar historical problem data, that is, comparing whether the connection paths of historical root causes and similar cases in the knowledge graph match to obtain candidate root cause paths.

[0134] This step verifies the consistency of the association between historical root causes and similar cases through path matching, and filters out credible transmission links with case support.

[0135] Step A54: Perform cross-validation between the candidate root cause paths and system configuration data to obtain candidate root cause data.

[0136] It should be noted that cross-validation refers to the process of verifying the consistency of inference results using multi-source data, that is, the verification operation to confirm the rationality of the root cause by comparing the candidate root cause path with the operating environment parameters.

[0137] Understandably, cross-validation is performed based on candidate root cause paths and system configuration data, that is, the consistency of potential cause propagation links is checked using runtime environment parameters to obtain candidate root cause data.

[0138] This step cross-validates candidate root cause paths using system configuration data, eliminating false associations that are inconsistent with the operating environment and improving the reliability of candidate root cause data.

[0139] Step S305: Correct the candidate root cause data by associating the system configuration data and environmental variable data to obtain root cause analysis data.

[0140] It should be noted that system configuration data refers to the set of parameters of the software's operating environment, that is, the settings related to the running state when the problem occurs. In this embodiment, system configuration data includes system logs and configuration information. Additionally, environment variable data refers to the state parameters of the external environment in which the software runs, that is, the runtime environment settings that affect program behavior. Furthermore, root cause analysis data refers to the final root cause description after environmental parameter correction, that is, a complete analysis result including the problem type, affected modules, severity, and the determined cause.

[0141] Understandably, the candidate root cause data is corrected by associating system configuration data and environmental variable data, that is, by combining the operating environment parameters to calibrate and adjust the candidate root causes to obtain root cause analysis data.

[0142] This step modifies candidate root causes by associating them with runtime environment parameters, making the root cause analysis results more consistent with the actual runtime environment and improving the accuracy of root cause determination.

[0143] This embodiment provides a test data processing method for production problem feedback. By structuring historical production problem data, data redundancy and noise are eliminated, providing a high-quality data foundation for subsequent analysis. A problem database is formed through vector representation extraction and knowledge graph construction, enhancing the knowledge relevance of production problem data. The root causes of new production problems are automatically determined based on the problem database, reducing manual intervention. Test assets are automatically updated after correctness verification, ensuring timely and accurate updates. Targeted test cases are generated by combining the lessons learned from historical problems with functional changes, improving test coverage and problem detection rate, forming a data loop for continuous improvement.

[0144] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the test data processing method for production problem feedback in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0145] This application also provides a test data processing device for production problem feedback. Referring to Figure 4, the test data processing device for production problem feedback includes: The data cleaning module 10 is used to perform structured processing on historical production problem data to obtain structured production problem data. Knowledge base construction module 20 is used to build a problem database based on structured production problem data; The root cause determination module 30 is used to determine root cause analysis data based on the problem database in response to new production problem data. The asset update module 40 is used to update the test assets in the problem database based on the root cause analysis data when the root cause analysis data passes the correctness check, so as to obtain the updated test assets. The test case generation module 50 is used to generate test case data based on the updated test assets in response to system function change data.

[0146] The test data processing apparatus for production problem feedback provided in this application, employing the test data processing method for production problem feedback in the above embodiments, can solve the technical problem of how to enhance the knowledge correlation of software system production problem data and realize the dynamic updating of test assets. Compared with the prior art, the beneficial effects of the test data processing apparatus for production problem feedback provided in this application are the same as the beneficial effects of the test data processing method for production problem feedback provided in the above embodiments, and other technical features in the test data processing apparatus for production problem feedback are the same as the features disclosed in the methods of the above embodiments, and will not be repeated here.

[0147] In one embodiment, the data cleaning module 10 is further configured to extract historical production problem data from the historical problem database; Irrelevant fields are removed from historical production problem data to obtain filtered data; The filtered data is then processed to standardize the field formats to obtain standard format data; The standard format data is deduplicated to obtain the deduplicated data; The associated system configuration information is used to supplement the missing field information in the deduplicated data, resulting in structured production problem data.

[0148] In one embodiment, the knowledge base construction module 20 is further configured to input structured production problem data into a pre-trained language model for vector representation extraction to obtain vector representation data; Normalize the vector representation data to obtain normalized vector data; The normalized vector data is stored in a distributed vector database to obtain the vector storage data; Entity identification and relation extraction are performed on structured production problem data to obtain entity relation data; A knowledge graph is constructed based on entity relationship data to obtain graph data; By associating and storing the graph data with the vector storage data, a problem database is obtained.

[0149] In one embodiment, the root cause determination module 30 is further configured to input newly added production problem data into the problem database for vector similarity calculation to obtain similar historical problem vectors; The similar historical question vectors are sorted according to the cosine similarity value to obtain a preset number of similar historical question data. The newly added production problem data is classified by a classification model to obtain problem type data, affected module data, and severity data. Based on the problem type data, the impact module data, and similar historical problem data, and combined with the knowledge graph in the problem database, correlation reasoning is performed to obtain candidate root cause data; The candidate root cause data is corrected by relating system configuration data and environmental variable data to obtain root cause analysis data.

[0150] In one embodiment, the root cause determination module 30 is further configured to determine the problem-related entities based on the problem type data and the impact module data, thereby obtaining problem entity data; Historical root cause entities associated with problem entity data are extracted from the knowledge graph in the problem database to obtain historical root cause data. Path matching is performed between historical root cause data and similar historical problem data to obtain candidate root cause paths; Candidate root cause data is obtained by cross-validating candidate root cause paths with system configuration data.

[0151] In one embodiment, the asset update module 40 is further configured to compare and verify the root cause analysis data with historical production problem data in the problem database to obtain verification result data; If the verification result is passed, generate asset update content data based on the root cause analysis data; The document editing interface is called to update the checklist data, test strategy data, and model-based test list data based on the asset update content data, and the updated data is obtained. Generate product design asset data to be updated based on the updated data; Perform format validation on the product design asset data to be updated to obtain the validated asset data. The verified asset data is associated with the newly added production problem data and stored in the problem database to obtain the updated test assets.

[0152] In one embodiment, the use case generation module 50 is further used to standardize and transform development-related document data to obtain standardized functional description data; Based on the standardized functional description data, the knowledge graph in the problem database is retrieved to obtain relevant and referential data. By mapping the relevant reference data with the system function change data to the scenarios, test scenario data is obtained. Generate initial test case data based on test scenario data; Perform coverage analysis on the initial test case data to obtain the coverage analysis results; Based on the coverage analysis results, the execution order of the initial test case data is optimized and regression test cases are added to obtain the test case data.

[0153] This application provides a test data processing device for production problem feedback. The test data processing device for production problem feedback includes: 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, and the instructions are executed by the at least one processor to enable the at least one processor to execute the test data processing method for production problem feedback in the above embodiment 1.

[0154] The following is for reference. Figure 5 This document illustrates a schematic diagram of a test data processing device suitable for implementing production problem feedback in the embodiments of this application. The test data processing device for production problem feedback in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The test data processing device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this application.

[0155] like Figure 5As shown, the test data processing device for production problem feedback may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the test data processing device for production problem feedback. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the test data processing equipment for production problem feedback to exchange data wirelessly or via wired communication with other devices. Although the figure shows a test data processing equipment for production problem feedback with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0156] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0157] The test data processing device for production problem feedback provided in this application, employing the test data processing method for production problem feedback in the above embodiments, can solve the technical problem of how to enhance the knowledge correlation of software system production problem data and realize the dynamic updating of test assets. Compared with the prior art, the beneficial effects of the test data processing device for production problem feedback provided in this application are the same as the beneficial effects of the test data processing device method for production problem feedback provided in the above embodiments, and other technical features in this test data processing device for production problem feedback are the same as the features disclosed in the method of the previous embodiment, and will not be repeated here.

[0158] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0160] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the test data processing method for production problem feedback in the above embodiments.

[0161] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0162] The aforementioned computer-readable storage medium may be included in a test data processing device for production problem feedback; or it may exist independently and not assembled into a test data processing device for production problem feedback.

[0163] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a test data processing device for production problem feedback, cause the following to occur: historical production problem data is processed in a structured manner to obtain structured production problem data; a problem database is constructed based on the structured production problem data; in response to newly added production problem data, root cause analysis data is determined based on the problem database; when the root cause analysis data passes the correctness verification, test assets in the problem database are updated based on the root cause analysis data to obtain updated test assets; and in response to system function change data, test case data is generated based on the updated test assets.

[0164] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0165] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0166] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0167] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described test data processing method for production problem feedback. This solves the technical problem of how to enhance the knowledge correlation of software system production problem data and achieve dynamic updates of test assets. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the test data processing method for production problem feedback provided in the above embodiments, and will not be repeated here.

[0168] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the test data processing method for production problem feedback as described above.

[0169] The computer program product provided in this application can solve the technical problem of how to enhance the knowledge correlation of production problem data in software systems and realize the dynamic updating of test assets. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the test data processing method for production problem feedback provided in the above embodiments, and will not be repeated here.

[0170] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A test data processing method for production problem feedback, characterized in that, The test data processing method for production problem feedback includes: Historical production problem data is processed in a structured manner to obtain structured production problem data; A problem database is constructed based on the structured production problem data; In response to newly added production problem data, root cause analysis data is determined based on the problem database; When the root cause analysis data passes the correctness verification, the test assets in the problem database are updated according to the root cause analysis data to obtain the updated test assets. In response to system function change data, test case data is generated based on the updated test assets.

2. The method as described in claim 1, characterized in that, The step of structuring historical production problem data to obtain structured production problem data includes: Extract historical production problem data from the historical problem database; Irrelevant fields are removed from the historical production problem data to obtain filtered data; The filtered data is then subjected to field format standardization processing to obtain standard format data; The standard format data is deduplicated to obtain the deduplicated data; The associated system configuration information is used to supplement the missing field information in the deduplicated data to obtain structured production problem data.

3. The method as described in claim 1, characterized in that, The step of constructing a problem database based on the structured production problem data includes: The structured production problem data is input into a pre-trained language model for vector representation extraction to obtain vector representation data; The vector representation data is normalized to obtain normalized vector data; The normalized vector data is stored in a distributed vector database to obtain vector storage data; Entity identification and relation extraction are performed on the structured production problem data to obtain entity relation data; A knowledge graph is constructed based on the entity relationship data to obtain graph data; The graph data and the vector storage data are associated and stored to obtain the problem database.

4. The method as described in claim 1, characterized in that, The step of determining root cause analysis data based on the problem database in response to newly added production problem data includes: The newly added production problem data is input into the problem database for vector similarity calculation to obtain similar historical problem vectors; The similar historical question vectors are sorted according to the cosine similarity value to obtain a preset number of similar historical question data. The newly added production problem data is classified by a classification model to obtain problem type data, affected module data, and severity data. Based on the problem type data, the impact module data, and the similar historical problem data, and combined with the knowledge graph in the problem database, correlation reasoning is performed to obtain candidate root cause data; The candidate root cause data is corrected by associating system configuration data and environmental variable data to obtain root cause analysis data.

5. The method as described in claim 4, characterized in that, The step of obtaining candidate root cause data by performing correlation reasoning based on the question type data, the impact module data, and the similar historical question data, combined with the knowledge graph in the question database, includes: Based on the problem type data and the impact module data, the problem-related entities are determined to obtain the problem entity data; Historical root cause entities associated with the problem entity data are extracted from the knowledge graph in the problem database to obtain historical root cause data. The historical root cause data is matched with the similar historical problem data to obtain candidate root cause paths; Candidate root cause data is obtained by cross-validating the candidate root cause paths with the system configuration data.

6. The method as described in claim 1, characterized in that, The step of updating the test assets in the problem database based on the root cause analysis data when the root cause analysis data passes the correctness verification, to obtain the updated test assets, includes: The root cause analysis data is compared and verified with historical production problem data in the problem database to obtain verification result data; When the verification result data is passed, asset update content data is generated based on the root cause analysis data; The document editing interface is called to update the checklist data, test strategy data, and model-based test list data based on the asset update content data, and the updated data is obtained. Generate product design asset data to be updated based on the updated data; The format of the product design asset data to be updated is validated to obtain the validated asset data. The verified asset data is associated with the newly added production problem data and stored in the problem database to obtain the updated test assets.

7. The method as described in claim 1, characterized in that, The step of generating test case data based on the updated test assets in response to system function change data includes: Standardize and transform the development-related documentation data to obtain standardized functional description data; Based on the standardized functional description data, the knowledge graph in the problem database is retrieved to obtain relevant and referential data. The data on the association and reference significance are mapped to the data on system function changes to obtain test scenario data; Initial test case data is generated based on the test scenario data; Perform coverage analysis on the initial test case data to obtain coverage analysis results; Based on the coverage analysis results, the execution order of the initial test case data is optimized and regression test cases are added to obtain test case data.

8. A test data processing device for production problem feedback, characterized in that, The device includes: The data cleaning module is used to perform structured processing on historical production problem data to obtain structured production problem data; The knowledge base construction module is used to construct a problem database based on the structured production problem data; The root cause determination module is used to determine root cause analysis data based on the problem database in response to newly added production problem data. The asset update module is used to update the test assets in the problem database according to the root cause analysis data when the root cause analysis data passes the correctness verification, so as to obtain the updated test assets. The test case generation module is used to generate test case data based on the updated test assets in response to system function change data.

9. A test data processing device for production problem feedback, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the test data processing method for production problem feedback as claimed in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the test data processing method for production problem feedback as described in any one of claims 1 to 7.

Images