Interface repairing method and device, storage medium and program product

Abstract

The embodiment of the invention provides an interface repairing method and device, a storage medium and a program product. According to the method, interface error information can be input into an error analysis model, and the error analysis model is connected with a multi-dimensional knowledge base; performing semantic alignment on the interface error reporting information and the relationship between the entities of the first knowledge base in an error reporting analysis model to obtain interface problem information; performing semantic alignment on the interface problem information and respective entities and relationships between the entities of the first knowledge base and the second knowledge base to obtain a first repair strategy of a service level and a second repair strategy of a code level, and outputting a plurality of candidate repair schemes according to the first repair strategy and the second repair strategy; and performing interface repair by using a target repair scheme in the plurality of candidate repair schemes. In this way, based on the error analysis model and the multi-dimensional knowledge base, the repair scheme can be efficiently and accurately generated according to the interface error condition, and interface repair is carried out.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an interface repair method, device, storage medium, and program product. Background Technology

[0002] With the development of microservice architecture and API (Application Programming Interface) technology, modern applications typically consist of dozens or even hundreds of service components that interact through interfaces. When an interface experiences runtime failure, quickly locating the root cause and developing a remediation strategy becomes extremely challenging. Traditional interface failure remediation usually relies on manual work, which is inefficient and has low accuracy. Summary of the Invention

[0003] This application provides an interface repair method, device, storage medium, and program product to generate repair solutions for interface error situations in a more efficient and accurate manner.

[0004] This application provides an interface repair method, comprising: acquiring interface error information of a target application during runtime; inputting the interface error information into an AI-based error analysis model, the error analysis model being connected to a multi-dimensional knowledge base; the multi-dimensional knowledge base including at least: a first knowledge base for problem dimensions, a second knowledge base for service dimensions, and a third knowledge base for code dimensions; semantically aligning the interface error information with entities and entity relationships in the first knowledge base in the error analysis model to obtain interface problem information matching the interface error information; semantically aligning the interface problem information with entities and entity relationships in the first and second knowledge bases respectively to obtain a first repair strategy at the service level and a second repair strategy at the code level; outputting multiple candidate repair schemes for the interface error situation based on the first and second repair strategies; and repairing the interface of the target application using a target repair scheme from the multiple candidate repair schemes.

[0005] Optionally, in the error analysis model, semantically aligning the interface error information with the entities and entity relationships in the first knowledge base to obtain interface problem information matching the interface error information includes: converting the interface error information into a first semantic vector sequence containing contextual semantics; generating a second semantic vector sequence based on the entities and entity relationships in the first knowledge base; calculating a first similarity between the first semantic vector sequence and the second semantic vector sequence, and determining a first entity and a first entity relationship matching the interface error information from the first knowledge base based on the first similarity and a preset first threshold; and generating interface problem information matching the interface error information based on the first entity and the first entity relationship.

[0006] Optionally, converting the interface error information into a first semantic vector sequence containing contextual semantics includes: preprocessing the interface error information as follows: Preprocessing step S1: Identifying the error statement sentence patterns and logical connectors in the interface error information, and labeling the interface error information with error types based on preset error type classification rules, wherein the error types include syntax errors, logical errors, parameter errors, and permission errors; Preprocessing step S2: Extracting the core entities in the interface error information, wherein the core entities include module information, function information, call stack information, and / or parameter information where the error occurred, and identifying the semantic function of the core entities in the current error scenario; converting the preprocessed interface error information into a candidate semantic vector sequence containing contextual semantics; and performing weighted enhancement processing on the positions of the core entities in the candidate semantic vector sequence based on the semantic function of the core entities in the current error scenario to obtain the first semantic vector sequence.

[0007] Optionally, generating a second semantic vector sequence based on the entities and relationships between entities in the first knowledge base includes: performing a structured representation of the entities and relationships between entities in the first knowledge base to obtain multiple triples; each triple includes any entity in the first knowledge base, the relationship between the entity and other entities, and the attributes of the entity; using a knowledge graph embedding algorithm, converting the multiple triples into multiple low-dimensional dense vectors to form a second semantic vector set, and constructing a hierarchical index structure for the second semantic vector set, wherein the hierarchical index structure uses entity type as the first-level index and the relationship type between entities as the second-level index.

[0008] Optionally, calculating a first similarity between the first semantic vector sequence and the second semantic vector sequence, and determining a first entity and a first entity relationship matching the interface error information from the first knowledge base based on the first similarity and a preset first threshold, includes: performing preliminary matching between the first semantic vector sequence and the second semantic vector sequence based on the hierarchical index structure to obtain a set of candidate entities related to the error type in the second semantic vector sequence; calculating a multi-dimensional similarity between the first semantic vector sequence and the second semantic vector corresponding to each candidate entity for the candidate entity set, wherein the multi-dimensional similarity includes semantic similarity, structural similarity, and contextual similarity; and filtering out the first entity and the first entity relationship matching the interface error information from the candidate entity set based on the multi-dimensional similarity.

[0009] Optionally, the target application is repaired using the target repair scheme from the plurality of candidate repair schemes, including: displaying the plurality of candidate repair schemes to the target user for the target user to select a scheme, determining the target repair scheme in response to the selection operation, and repairing the target application using the target repair scheme; or, sequentially deploying the plurality of candidate repair schemes to a test environment, calling a preset test case set to test the plurality of candidate repair schemes to obtain test result data, and determining the target repair scheme from the plurality of candidate repair schemes based on the test result data.

[0010] Optionally, the method further includes: generating training samples based on the target repair scheme, the interface error information, and the repair effect data, wherein the repair effect data includes: changes in the response status codes of the interface before and after repair, error reproduction rate, and anomaly elimination rate of related service links; performing structured annotation on the training samples, wherein the structured annotation includes: mapping relationship labels between the interface error information and the target repair scheme, and validity labels of key repair steps in the target repair scheme; and inputting the structured-annotated training samples into the error analysis model to perform incremental training on the error analysis model.

[0011] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to: store one or more computer instructions; and the processor is used to execute the one or more computer instructions to: perform the steps in the interface repair method.

[0012] This application also provides a computer-readable storage medium that, when executed by a processor, enables the processor to implement the steps in the interface repair method.

[0013] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, enables the processor to implement the steps in the interface repair method.

[0014] In this embodiment, interface error information during the runtime of the target application can be obtained. This error information is input into an error analysis model, which is connected to a multi-dimensional knowledge base, including a first knowledge base at the problem dimension, a second knowledge base at the service dimension, and a third knowledge base at the code dimension. The error analysis model semantically aligns the interface error information with the entities and relationships between entities in the first knowledge base to obtain interface problem information. It then semantically aligns the interface problem information with the entities and relationships between entities in both the first and second knowledge bases to obtain a first repair strategy at the service level and a second repair strategy at the code level. Based on the first and second repair strategies, multiple candidate repair schemes are output for the interface error situation. Finally, the target repair scheme from among the multiple candidate repair schemes is used to repair the interface of the target application. In this way, the error analysis model can generate repair schemes for interface error situations efficiently and accurately based on a multi-dimensional knowledge base. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0016] Figure 1 A flowchart illustrating an exemplary embodiment of this application for an interface repair method;

[0017] Figure 2 Another flowchart illustrating the interface repair method provided in an exemplary embodiment of this application;

[0018] Figure 3 A schematic diagram of an interface repair method in a real-world scenario provided as an exemplary embodiment of this application;

[0019] Figure 4 A schematic diagram of an electronic device provided for an exemplary embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of such data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0022] With the development of microservice architecture and API (Application Programming Interface) technology, modern applications typically consist of dozens or even hundreds of service components that interact through interfaces. When an interface experiences runtime failure, quickly locating the root cause and developing a remediation strategy becomes extremely challenging. Traditional interface failure remediation usually relies on manual work, which is inefficient and has low accuracy.

[0023] To address the aforementioned technical issues, this application provides a technical solution that can acquire interface error information during the runtime of a target application, input it into an AI error analysis model that connects to a multi-dimensional knowledge base (including problem, service, and code dimensions), align the error information with the semantics of a first knowledge base to obtain matching interface problem information, then align it with the first and second knowledge bases to generate service-level and code-level repair strategies, and output multiple candidate repair schemes based on the multi-level repair strategies. Finally, the target repair scheme among the multiple candidate repair schemes is used to repair the interface of the target application.

[0024] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings. Figure 1 and Figure 2 These are schematic flowcharts of interface repair methods provided by exemplary embodiments of this application. The method is applicable to electronic devices, which can be any device such as mobile phones, tablets, servers, and computers. This embodiment does not limit this.

[0025] like Figure 1 and 2 As shown, the method may include the following steps:

[0026] Step 11: Obtain the interface error information of the target application at runtime.

[0027] Step 12: Input the interface error information into the AI-based error analysis model. The error analysis model is connected to a multi-dimensional knowledge base. The multi-dimensional knowledge base includes at least: a first knowledge base for the problem dimension, a second knowledge base for the service dimension, and a third knowledge base for the code dimension.

[0028] Step 13: In the error analysis model, semantically align the interface error information with the entities and relationships between entities in the first knowledge base to obtain interface problem information that matches the interface error information; semantically align the interface problem information with the entities and relationships between entities in the first and second knowledge bases respectively to obtain the first repair strategy at the service level and the second repair strategy at the code level; output multiple candidate repair schemes for the interface error situation based on the first and second repair strategies.

[0029] Step 14: Use the target repair scheme from multiple candidate repair schemes to repair the interface of the target application.

[0030] In this embodiment, the interface error information of the target application during runtime is used to describe the error details when an error occurs in the target application's interface, and may include, but is not limited to, at least one of the following: error code, error description, interface call parameters, and log information. The interface error information may be error information during testing of the target application, or error information during actual application. In other words, this embodiment can be applied to both program testing scenarios and program application scenarios, and this embodiment does not impose any limitations on this.

[0031] This embodiment does not limit the specific method of obtaining interface error information. In one exemplary embodiment, the target application itself can report interface error information; therefore, interface error information can be directly obtained from the target application. In another exemplary embodiment, the scenario automation platform can monitor the operation of the target application. When an interface error occurs in the target application, the scenario automation platform can detect the interface error and thus obtain the interface error information from the scenario automation platform. The scenario automation platform is a system that can simulate specific service scenarios or user operation processes, automatically execute preset tasks, and monitor the running status. It is commonly used in software testing, process monitoring, and other scenarios, such as automatically simulating a series of operations like user login and data submission, while recording various anomalies that occur during the process.

[0032] In this embodiment, interface error information can be input into an AI-based error analysis model, which can be connected to a multi-dimensional knowledge base. The AI-based error analysis model can be any AI-based model, such as a traditional model or a generative model; preferably, it can be a large model. The multi-dimensional knowledge base includes at least: a first knowledge base for the problem dimension, a second knowledge base for the service dimension, and a third knowledge base for the code dimension.

[0033] The first knowledge base for the problem dimension: Centered on the interface error itself, it stores standardized definitions of various errors (such as official explanations of error codes and exception types), typical manifestation characteristics (such as common error text patterns for "connection timeout"), triggering conditions (such as "NullPointerException is triggered when parameters are empty"), and historical related cases (including handling records of similar errors), forming a basic feature library of error problems. This is used to enable error analysis models to efficiently and accurately determine the interface problem information corresponding to the interface error information.

[0034] The second knowledge base for the service dimension focuses on the service architecture context in which the interface resides, covering service topology relationships (such as "user service depends on order service"), interface call protocols (such as HTTP / HTTPS, RPC), service deployment information (such as node distribution, resource configuration), and inter-service interaction rules (such as parameter passing format, timeout threshold), which are used to analyze error propagation paths from the perspective of service dependencies and interaction logic.

[0035] The third knowledge base in the code dimension: It delves into the code layer of interface implementation, including function / method definitions (such as input / output parameters, return value types), code logic structure (such as conditional branches, loop logic), scope of variables / constants, and code defect patterns (such as "crash caused by unchecked null pointers"), while also associating repair examples (such as "code snippets with added parameter non-null checks"), providing a basis for generating code-level repair strategies.

[0036] In this embodiment, the multi-dimensional knowledge base forms a cross-dimensional knowledge network through entity association (such as "error code 500" being associated with "query function of service A"), enabling the error analysis model to not only locate the error manifestation but also trace the root cause of service interaction, ultimately generating a complete repair solution covering business scenarios, service configurations, and code implementations.

[0037] In the error analysis model, interface error information can be semantically aligned with entities and their relationships in the first knowledge base to obtain interface problem information that matches the error information. This interface problem information describes the cause of the interface error. Any entity can be an error type entity (e.g., "parameter error," "permission error"), a module entity (e.g., "user service module," "order processing module"), a function entity (e.g., "verifyUser() function," "submitOrder() function"), or a parameter entity (e.g., "userId parameter," "timestamp parameter"), etc. The relationship between any two entities can be a trigger relationship (e.g., parameter error, trigger, verifyUser() function fails), a containment relationship (e.g., verifyUser() function, contained in, user service module), a dependency relationship (e.g., submitOrder() function, dependent on, userId parameter), or an attribute relationship (e.g., parameter error, attribute, error code: 400), etc.

[0038] It should be noted that the semantic alignment mentioned in this application refers to the precise matching of unstructured interface error information with a structured knowledge base, enabling the error analysis model to understand the semantic meaning of data from different sources and establish associations. This process is similar to human experts analyzing the correspondence between "symptoms" (interface error information) and "knowledge systems" (such as service architecture and code logic stored in the knowledge base) when diagnosing problems. Specifically, semantic alignment involves semantically mapping the entities (such as service names, parameter names, and exception types) and relationships between entities (such as call chains and dependencies) in the interface error information to the concepts and experiences in the knowledge base, thereby locating the root cause of the problem (determining the interface problem information) and generating a repair strategy. For example, locating the root cause: mapping the NullPointerException in the error stack to the specific line of code in the code base that did not perform null value checking; generating a repair strategy: matching the "service overload" alarm at the service dimension to the historical solution of "adjusting the rate limiting threshold" in the knowledge base.

[0039] After identifying the interface problem information that matches the interface error message, the interface problem information can be semantically aligned with the entities and inter-entity relationships in the first and second knowledge bases, respectively, to obtain a first repair strategy at the service level and a second repair strategy at the code level. Specifically, the interface problem information can be semantically aligned with the entities and inter-entity relationships in the first knowledge base to obtain the first repair strategy at the service level, and the interface problem information can be semantically aligned with the entities and inter-entity relationships in the second knowledge base to obtain the second repair strategy at the code level.

[0040] Through the bidirectional semantic alignment of the service level and code level, the remediation strategy can simultaneously cover the configuration adjustment of the service runtime environment and the logical optimization of the code implementation, forming a complete remediation solution that takes into account both the solution of surface problems and the elimination of deep-seated root causes.

[0041] Based on the above steps, multiple candidate repair schemes for interface error situations can be output according to the first repair strategy and the second repair strategy. This application embodiment does not limit the specific method of generating the candidate repair schemes. Optionally, the first repair strategy and the second repair strategy can be fused to obtain a fusion strategy, and multiple candidate repair schemes can be generated according to the fusion strategy; alternatively, at least one candidate repair scheme corresponding to the first repair strategy can be generated according to the first repair strategy, and at least one candidate repair scheme corresponding to the second repair strategy can be generated according to the second repair strategy, and then the at least one candidate repair scheme corresponding to each of the first and second repair strategies can be used as multiple candidate repair schemes.

[0042] Based on the above steps, the target repair scheme from multiple candidate repair schemes can be used to repair the interface of the target application. This application embodiment does not limit the method for determining the target repair scheme; it can be manually selected by the user or automatically selected based on the test effect information of different schemes in the test environment. The following will illustrate "using the target repair scheme to repair the interface of the target application" with an example. Assume that the order interface of the target application has an error, with the error message being "When calling the createOrder function, the passed goodsId parameter is null, resulting in a null pointer exception (response status code 500), the error reproduction rate is 100%, and the order service and inventory service in the related service chain both have abnormal logs." The target repair scheme determined through analysis is "Add a non-null check for the goodsId parameter at the entry point of the createOrder function; when the parameter is null, return error code 400 and the prompt message 'goodsId cannot be null'." The specific repair operation is as follows: ① Code layer modification: Insert validation logic in the first execution step of the createOrder function. ② Service layer configuration synchronization: Parameter validation rules for the createOrder interface were added to the API gateway, forming a double guarantee with code-level validation to prevent invalid requests from entering business logic. ③ The modified code was released to the test environment, and a preset test case set (including 100 requests with null goodsId and 50 requests with normal parameters) was used for verification. The results showed that the response status code changed from 500 to 400 (as expected), the error reproduction rate dropped to 0%, and the anomaly elimination rate of related service links reached 100% (no more anomaly logs appeared in nodes such as the inventory service). Through the above operations, the order interface error of the target application was successfully fixed, and the repair effect was verified by quantitative indicators, ensuring that the interface does not recur in the same scenario.

[0043] In this embodiment, an AI (Artificial Intelligence) model (i.e., an error analysis model) combined with a multi-dimensional knowledge base is used to achieve accurate semantic alignment of interface error information, enabling rapid location of interface problems. The generated service and code-level dual-dimensional repair strategies cover both surface mitigation and deep-root cause repair, improving the comprehensiveness of the repair. Multiple candidate solutions are adapted to different scenarios, enhancing the flexibility of the repair. The overall process is highly automated, effectively improving the efficiency and accuracy of interface repair and reducing the cost of manual intervention.

[0044] In some optional embodiments, step 13 in the aforementioned embodiments, "in the error analysis model, semantically aligning the interface error information with the entities and relationships between entities in the first knowledge base to obtain interface problem information that matches the interface error information," can be implemented based on the following steps:

[0045] Step K1: Convert the interface error message into a first semantic vector sequence containing contextual semantics. The first semantic vector sequence includes feature vectors of multiple entities in the interface error message, as well as contextual semantic information.

[0046] The following will describe this step in detail: First, the following preprocessing steps S1-S2 can be performed on the interface error information:

[0047] Preprocessing step S1: Identify the error statement patterns and logical connectors in the interface error messages, and label the interface error messages with error types based on preset error type classification rules. Error types include syntax errors, logic errors, parameter errors, and permission errors. For example, a syntax error may be: the interface request body JSON format is missing closing brackets, causing parsing failure; a logic error may be: the interface callback function does not handle asynchronous request timeout scenarios, causing repeated execution of logic; a parameter error may be: when calling the payment interface, a negative amount is passed, which does not meet the "amount ≥ 0" constraint; a permission error may be: calling the user information interface without carrying a valid token, triggering "403 Forbidden".

[0048] Preprocessing step S2: Extract core entities from the interface error information. Core entities include at least one of the following: module information where the error occurred, function information, call stack information, and parameter information. Identify the semantic function of each core entity in the current error scenario. Examples of the semantic functions of core entities are provided below: For example, the core entity "Order Service Module" indicates the system component scope where the error occurred; the core entity "createOrder()" identifies the specific function unit where the error occurred; the core entity "createOrder→checkInventory→dbQuery" reflects the code execution path of the error propagation; and the core entity "goodsId=null" reveals the reason for the key input anomaly that triggered the error and the failure of the associated validation logic.

[0049] After preprocessing, the preprocessed interface error information can be converted into a candidate semantic vector sequence containing contextual semantics. Specifically, the preprocessed interface error information can be segmented into words, and error type labels, core entities and their semantic function annotations can be embedded into the text sequence. The embedded text sequence can then be encoded to obtain a candidate semantic vector sequence containing word vectors, entity vectors and contextual features.

[0050] Based on the semantic function of the core entity in the current error reporting scenario, a weighted enhancement process is applied to the positions of the core entities in the candidate semantic vector sequence to obtain the first semantic vector sequence. Specifically, the weighted enhancement process can be applied to the positions of the core entities in the candidate semantic vector sequence according to different preset weights corresponding to different semantic functions. This weighted enhancement process adds weight to the positions of the core entities in the candidate semantic vector sequence to strengthen their semantic influence and highlight key information.

[0051] The above methods can accurately label error types, extract core entities, and identify their semantic functions, providing high-quality input for vector conversion. The preprocessed information is converted into a candidate vector sequence containing context, and weighted enhancement is performed by combining the semantic functions of core entities to highlight the weight of key information, improve the semantic expression accuracy and relevance of the first semantic vector sequence, lay the foundation for efficient semantic alignment with the knowledge base and the generation of accurate repair strategies, reduce interference from invalid information, and improve the efficiency of interface repair.

[0052] Step K2: Generate a second semantic vector sequence based on the entities and relationships between entities in the first knowledge base.

[0053] Specifically, the entities and relationships between entities in the first knowledge base can be structurally represented to obtain multiple triples; any triple includes any entity in the first knowledge base, the relationship between the entity and other entities, and the entity's attributes.

[0054] Next, a knowledge graph embedding algorithm is used to transform multiple triples into multiple low-dimensional dense vectors, forming a second semantic vector set. A hierarchical index structure is then constructed for this second semantic vector set. The knowledge graph embedding algorithm is a class of algorithms that map entities and relationships in a knowledge graph to a low-dimensional dense vector space. By preserving the semantic information of entities, the logical connections between entities, and attribute features, it transforms discrete triple data into continuous vector representations. Low-dimensional dense vectors refer to vectors with low dimensionality (e.g., tens to hundreds of dimensions) where each dimension has a specific numerical value.

[0055] The hierarchical index structure uses entity type as the first-level index, such as "error type entity," "module entity," or "function entity"; and the hierarchical index structure uses the relationship type between entities as the second-level index, such as "trigger relationship," "inclusion relationship," or "attribute association." In this way, the semantic integrity of the knowledge graph is preserved, and vectorization and index optimization provide a foundation for subsequent knowledge matching.

[0056] Step K3: Calculate the first similarity between the first semantic vector sequence and the second semantic vector sequence, and determine the first entity and the relationship between the first entities that match the interface error information from the first knowledge base based on the first similarity and the preset first threshold.

[0057] Specifically, based on the hierarchical index structure, the first semantic vector sequence and the second semantic vector sequence can be initially matched to obtain a set of candidate entities related to the error type in the second semantic vector sequence. Error type features (such as "parameter error") can be extracted from the first semantic vector sequence and matched to the "error type entity" category in the first-level index. Then, the relationship type related to error propagation (such as "trigger relationship" or "attribute association") is determined in the second-level index, and the entity vectors under this category are added to the candidate entity set. For example, if the interface error message is "userId parameter format error triggers 400 exception," the index can be used to quickly filter out the "parameter error" entity, the "400 error code" entity, and the "userId parameter" entity, forming a candidate entity set and initially narrowing the matching range.

[0058] Subsequently, for the candidate entity set, multi-dimensional similarity can be calculated between the first semantic vector sequence and the second semantic vectors corresponding to each candidate entity. This multi-dimensional similarity can include semantic similarity, structural similarity, and contextual similarity. Specifically, the vector space distance between any vector in the first semantic vector sequence and the second semantic vectors corresponding to each candidate entity can be calculated using the cosine similarity formula, and the semantic similarity is determined based on this vector space distance. Furthermore, the relationship path matching degree of entities in the knowledge graph can be analyzed, and the structural similarity is determined based on the relationship path matching degree. For example, if an interface error involves a relationship chain of "parameter error → function execution failure," the structural similarity between the relationship chain of "parameter error → verify() function exception" among candidate entities is 0.9. Finally, the association strength between the entity and the error scenario can be calculated by combining the context of the interface error (such as the involved modules and functions), and the contextual similarity is determined based on the association strength.

[0059] After obtaining multi-dimensional similarity scores, the first entity and its relationships that match the API error messages can be selected from the candidate entity set based on these scores. Specifically, the similarity scores across multiple dimensions can be weighted and fused (weights can be dynamically adjusted, such as 40% for semantics, 30% for structure, and 30% for context) to calculate the comprehensive score of the candidate entities. A preset threshold (e.g., comprehensive score ≥ 0.7) is set to select the first entity and its relationships as the matching results. For example, the triple with the highest comprehensive score (parameter error, trigger, verifyUser() function failed) is identified as the first entity and its relationships, completing the accurate mapping between the API error messages and the knowledge base. In this way, hierarchical indexing reduces unnecessary computation, and multi-dimensional similarity ensures comprehensive matching, significantly improving the efficiency and accuracy of entity and relationship matching.

[0060] Step K4: Generate interface problem information that matches the interface error information based on the first entity and the relationship between the first entities.

[0061] In this embodiment, the first entity and the relationship between the first entities can be directly used as the interface problem information to match the interface error information, or the interface problem information can be generated according to the first entity and the relationship between the first entities according to the preset structured template. This embodiment does not limit the specific implementation of step K4.

[0062] Based on steps K1-K4 above, the interface error information can be semantically aligned with the entities and relationships between entities in the first knowledge base in a relatively efficient and accurate manner, resulting in interface problem information that matches the interface error information. The accuracy of the interface problem information is relatively high.

[0063] It should be noted that after obtaining the interface problem information that matches the interface error information, the interface problem information is semantically aligned with the entities and entity relationships of the first and second knowledge bases, respectively. This is the same as the aforementioned step of "semantically aligning the interface error information with the entities and entity relationships of the first knowledge base in the error analysis model to obtain the interface problem information that matches the interface error information". In other words, the principle of semantic alignment for any two different targets in this application embodiment is the same. The content about semantic alignment mentioned in the aforementioned embodiment can still be used in the following text, which will be explained in detail below.

[0064] In some optional embodiments, step 13 in the foregoing embodiments, "semantically aligning the interface problem information with the entities and relationships between entities in the first knowledge base to obtain the first repair strategy at the service level," can be implemented based on the following steps M1-M4:

[0065] Step M1: Convert the interface problem information into a third semantic vector sequence containing contextual semantics. This third semantic vector sequence includes feature vectors of multiple entities within the interface problem information, as well as contextual semantic information.

[0066] The following will describe this step in detail: First, the interface problem information can be preprocessed using the following steps T1-T2:

[0067] Preprocessing step T1 involves identifying the problem statement structure and logical connectors in the interface problem information, and labeling the interface problem information with repair types based on preset service repair type classification rules. Repair types include configuration adjustment, dependency optimization, resource expansion, and permission configuration. For example, configuration adjustment could be: the interface timeout threshold is set too short and needs to be extended to a reasonable range; dependency optimization could be: the service call does not have a retry mechanism and a failure retry strategy needs to be added; resource expansion could be: the order service node is overloaded and the number of instances needs to be temporarily increased; and permission configuration could be: the interface access permissions are not associated with user roles and the role-permission mapping relationship needs to be added.

[0068] Preprocessing step T2 involves extracting service-related entities from the interface problem information. These entities include at least one of the following: service topology information, interface protocol information, deployment node information, and interaction rule information. The semantic function of each service-related entity in the current problem scenario is then identified. Examples of the semantic functions of service-related entities are provided below: For instance, a service-related entity might be the service topology information "User Service → Order Service," with the semantic function of indicating the dependency path between services; an interface protocol information "HTTP / 1.1," with the semantic function of identifying the communication standard for service interaction; a deployment node information "Order Service Node A / Node B," with the semantic function of locating the service instance involved in the problem; and an interaction rule information "Parameter passing format is JSON," with the semantic function of clarifying the constraints of data interaction between services.

[0069] After preprocessing, the preprocessed interface problem information can be converted into a candidate semantic vector sequence containing contextual semantics. Specifically, the preprocessed interface problem information can be segmented into words, and the repair type label, service-related entities, and their semantic function annotations can be embedded into the text sequence. The embedded text sequence can then be encoded to obtain a candidate semantic vector sequence containing word vectors, entity vectors, and contextual features.

[0070] Based on the semantic functions of service-related entities in the current problem scenario, a weighted enhancement process is applied to the positions of service-related entities in the candidate semantic vector sequence to obtain a third semantic vector sequence. Specifically, the weighted enhancement process can be applied to the positions of service-related entities in the candidate semantic vector sequence according to different preset weights corresponding to different semantic functions. This weighted enhancement process adds weight to the positions of service-related entities in the candidate semantic vector sequence to strengthen their semantic influence and highlight key information.

[0071] The above methods can accurately label repair types, extract service-related entities, and identify their semantic functions, providing high-quality input for vector transformation. The preprocessed information is converted into a candidate vector sequence containing context, and weighted enhancement is performed by combining the semantic functions of service-related entities to highlight the weight of key information, improve the semantic expression accuracy and relevance of the third semantic vector sequence, lay the foundation for efficient semantic alignment with the first knowledge base and the generation of accurate service-level repair strategies, reduce interference from invalid information, and improve the efficiency of repair strategy generation.

[0072] Step M2: Generate the fourth semantic vector sequence based on the entities and relationships between entities in the service dimension of the first knowledge base.

[0073] Specifically, the entities and relationships between entities in the service dimension of the first knowledge base can be structurally represented to obtain multiple triples; any triple includes any entity in the service dimension of the first knowledge base, the relationship between the entity and other entities, and the entity's attributes.

[0074] Then, using a knowledge graph embedding algorithm, multiple triples are converted into multiple low-dimensional dense vectors to form a fourth semantic vector set, and a hierarchical index structure is built for the fourth semantic vector set.

[0075] The hierarchical index structure uses service entity types as the first-level index, such as "configuration entity," "dependency entity," or "node entity." The hierarchical index structure also uses the relationship types between service entities as the second-level index, such as "call relationship," "dependency relationship," or "configuration association." This approach preserves the semantic integrity of the service-dimensional knowledge graph while providing a foundation for subsequent knowledge matching through vectorization and index optimization.

[0076] Step M3: Calculate the second similarity between the third semantic vector sequence and the fourth semantic vector sequence, and determine the second entity and the relationship between the second entity that match the interface question information from the first knowledge base based on the second similarity and the preset second threshold.

[0077] Specifically, based on the hierarchical index structure, the third semantic vector sequence and the fourth semantic vector sequence can be initially matched to obtain a set of candidate service entities related to the repair type in the fourth semantic vector sequence. Repair type features (such as "configuration adjustment") can be extracted from the third semantic vector sequence and matched to the "configuration entity" category in the first-level index. Subsequently, the relationship type related to service repair (such as "configuration association" or "dependency relationship") is determined in the second-level index, and the entity vectors under this category are added to the candidate service entity set. For example, if the interface problem information is "order service call timeout requires timeout configuration adjustment," the "timeout threshold configuration" entity, the "order service node" entity, and the "call protocol" entity can be quickly filtered out through the index to form a set of candidate service entities, initially narrowing the matching scope.

[0078] Subsequently, for the set of candidate service entities, multi-dimensional similarity can be calculated between the third semantic vector sequence and the fourth semantic vector corresponding to each candidate service entity. This multi-dimensional similarity can include semantic similarity, structural similarity, and service context similarity. Specifically, the vector space distance between any vector in the third semantic vector sequence and the fourth semantic vector corresponding to each candidate service entity can be calculated using the cosine similarity formula, and the semantic similarity is determined based on this vector space distance. Furthermore, the relationship path matching degree of service entities in the knowledge graph can be analyzed, and the structural similarity is determined based on the relationship path matching degree. For example, if the interface problem involves a relationship chain of "timeout configuration → successful service call," the structural similarity between the relationship chain of "timeout threshold adjustment → normal order service response" in the candidate entities is 0.9. Finally, the association strength between the service entity and the problem scenario can be calculated by combining the service scenario context of the interface problem (such as the service topology and deployment environment involved), and the service context similarity is determined based on the association strength.

[0079] After obtaining multi-dimensional similarity scores, second entities and relationships between them that match the interface problem information can be selected from the candidate service entity set based on these scores. Specifically, the similarity scores across multiple dimensions can be weighted and fused (weights can be dynamically adjusted, such as 40% for semantic level, 30% for structural level, and 30% for service context) to calculate the comprehensive score of the candidate service entities. A preset threshold (e.g., comprehensive score ≥ 0.7) is set to select second entities and their relationships as matching results. For example, the triple with the highest comprehensive score (timeout threshold configuration, association, successful order service call) is identified as the second entity and its relationship, completing the accurate mapping between the interface problem information and the service dimension knowledge of the first knowledge base. In this way, by reducing unnecessary calculations based on hierarchical indexing and ensuring the comprehensiveness of matching through multi-dimensional similarity, the efficiency and accuracy of matching service-related entities and relationships are significantly improved.

[0080] Step M4: Generate the first repair strategy for the service level based on the relationship between the second entity and the second entity.

[0081] In this embodiment, the first repair strategy can be directly used as the relationship between the second entity and the second entity, or the first repair strategy can be generated according to the relationship between the second entity and the second entity based on the preset service repair template. This embodiment does not limit the specific implementation of step M4.

[0082] Based on the above steps M1-M4, the interface problem information can be semantically aligned with the entities and relationships between entities in the first knowledge base in a relatively efficient and accurate manner, resulting in the first repair strategy at the service level. The first repair strategy has high pertinence and feasibility.

[0083] In some optional embodiments, step 13 in the foregoing embodiments, "semantically aligning the interface problem information with the entities and relationships between entities in the second knowledge base to obtain a second repair strategy at the code level," can be implemented based on the following steps N1-N4:

[0084] Step N1: Convert the interface question information into a fifth semantic vector sequence containing contextual semantics. The fifth semantic vector sequence includes feature vectors of multiple entities in the interface question information, as well as contextual semantic information.

[0085] The following will describe this step in detail: First, the following preprocessing steps U1-U2 can be performed on the interface problem information:

[0086] Preprocessing step U1: Identify the problem statement structure and logical connectors in the interface problem information, and label the interface problem information with repair types based on preset code repair type classification rules. Repair types include parameter validation supplementation, exception handling improvement, logic branch optimization, and code defect repair. For example, parameter validation supplementation could be: the function did not validate that the input parameter is not empty, so a non-empty check logic needs to be added; exception handling improvement could be: the try block did not catch a specific exception, so a catch branch needs to be added; logic branch optimization could be: condition judgments missed boundary scenarios, so branch conditions need to be improved; code defect repair could be: the loop variable is not incremented correctly, so the iteration logic needs to be corrected.

[0087] Preprocessing step U2: Extract code-related entities from the interface problem information. Code-related entities include at least one of function definition information, parameter constraint information, code structure information, and defect pattern information, and identify the semantic function of the code-related entities in the current problem scenario. The semantic functions of code-related entities are illustrated below: The code-related entity is the function definition information "createOrder(intgoodsId)", whose semantic function is: identifying the code unit that needs repair; the code-related entity is the parameter constraint information "goodsId>0", whose semantic function is: clarifying the legal range of the parameter; the code-related entity is the code structure information "if(goodsId==null){...}", whose semantic function is: indicating the conditional branch that needs optimization; the code-related entity is the defect pattern information "unprotected null pointer", whose semantic function is: revealing typical error types in the code.

[0088] After preprocessing, the preprocessed interface problem information can be converted into a candidate semantic vector sequence containing contextual semantics. Specifically, the preprocessed interface problem information can be segmented into words, and the repair type label, code-related entities, and their semantic function annotations can be embedded into the text sequence. The embedded text sequence can then be encoded to obtain a candidate semantic vector sequence containing word vectors, entity vectors, and contextual features.

[0089] Based on the semantic functions of code-related entities in the current problem scenario, a weighted enhancement process is applied to the positions of code-related entities in the candidate semantic vector sequence to obtain the fifth semantic vector sequence. Specifically, the weighted enhancement process can be applied to the positions of code-related entities in the candidate semantic vector sequence according to different preset weights corresponding to different semantic functions. This weighted enhancement process adds weight to the positions of code-related entities in the candidate semantic vector sequence to strengthen their semantic influence and highlight key information.

[0090] The above methods can accurately label repair types, extract code-related entities, and identify their semantic functions, providing high-quality input for vector conversion. The preprocessed information is converted into a candidate vector sequence containing context, and weighted enhancement is performed by combining the semantic functions of code-related entities to highlight the weight of key information, improve the semantic expression accuracy and relevance of the fifth semantic vector sequence, lay the foundation for efficient semantic alignment with the second knowledge base and accurate code-level repair strategy generation, reduce interference from invalid information, and improve the efficiency of repair strategy generation.

[0091] Step N2: Generate the sixth semantic vector sequence based on the entities and relationships between entities in the code dimension of the second knowledge base.

[0092] Specifically, the entities and relationships between entities in the code dimension of the second knowledge base can be structurally represented to obtain multiple triples; any triple includes any entity in the code dimension of the second knowledge base, the relationship between the entity and other entities, and the entity's attributes.

[0093] Next, a knowledge graph embedding algorithm is used to transform multiple triples into multiple low-dimensional dense vectors to form a sixth semantic vector set, and a hierarchical index structure is constructed for this set. The hierarchical index structure uses code entity types as the first-level index, such as "function entity," "parameter entity," or "defect entity"; and the hierarchical index structure uses the relationship types between code entities as the second-level index, such as "call relationship," "constraint relationship," or "repair association." In this way, the semantic integrity of the code-dimensional knowledge graph is preserved, and vectorization and index optimization provide a foundation for subsequent knowledge matching.

[0094] Step N3: Calculate the third similarity between the fifth semantic vector sequence and the sixth semantic vector sequence, and determine the third entity and the relationship between the third entities that match the interface question information from the second knowledge base based on the third similarity and the preset third threshold.

[0095] Specifically, based on the hierarchical index structure, the fifth semantic vector sequence and the sixth semantic vector sequence can be initially matched to obtain a set of candidate code entities related to the repair type in the sixth semantic vector sequence. Repair type features (such as "parameter validation supplement") can be extracted from the fifth semantic vector sequence and matched to the "parameter entity" category in the first-level index. Subsequently, the relationship type related to code repair (such as "constraint relationship" or "repair association") is determined in the second-level index, and the entity vectors under this category are added to the candidate code entity set. For example, if the interface problem information is "the createOrder function did not validate that goodsId is not empty and needs supplementary validation," then the "goodsId parameter" entity, the "not empty validation logic" entity, and the "createOrder function" entity can be quickly filtered out through the index to form a set of candidate code entities, initially narrowing the matching range.

[0096] Subsequently, for the candidate code entity set, multi-dimensional similarity can be calculated between the fifth semantic vector sequence and the sixth semantic vector corresponding to each candidate code entity. This multi-dimensional similarity can include semantic similarity, structural similarity, and code context similarity. Specifically, the vector space distance between any vector in the fifth semantic vector sequence and the sixth semantic vector corresponding to each candidate code entity can be calculated using the cosine similarity formula, and the semantic similarity is determined based on this vector space distance. Furthermore, the relationship path matching degree of code entities in the knowledge graph can be analyzed, and the structural similarity is determined based on the relationship path matching degree. For example, if the interface problem involves a relationship chain of "parameter unvalidation → null pointer exception," the structural similarity between the relationship chain of "supplementing non-null validation → exception elimination" in the candidate entities is 0.9. Finally, the association strength between the code entity and the problem scenario can be calculated by combining the code scenario context of the interface problem (such as the involved functions and code blocks), and the code context similarity is determined based on the association strength.

[0097] After obtaining multi-dimensional similarity scores, third entities and relationships between them that match the interface issue information can be selected from the candidate code entity set based on these scores. Specifically, the similarity scores across multiple dimensions can be weighted and fused (weights can be dynamically adjusted, such as 40% for semantic level, 30% for structural level, and 30% for code context) to calculate the comprehensive score of the candidate code entities. A preset threshold is set (e.g., comprehensive score ≥ 0.7) to select third entities and relationships between them as matching results. For example, the triple with the highest comprehensive score (goodsId parameter, which needs to be supplemented, non-empty validation logic) is determined as the third entity and its relationship, completing the accurate mapping between the interface issue information and the code dimension knowledge of the second knowledge base. In this way, by reducing invalid calculations based on hierarchical indexing and ensuring the comprehensiveness of matching through multi-dimensional similarity, the efficiency and accuracy of matching code-related entities and relationships are significantly improved.

[0098] Step N4: Generate a second repair strategy at the code level based on the third entity and the relationships between the third entities.

[0099] In this embodiment, the third entity and the relationship between the third entities can be directly used as the second repair strategy at the code level, or the second repair strategy can be generated according to the third entity and the relationship between the third entities based on the preset code repair template. This embodiment does not limit the specific implementation of step N4.

[0100] Based on steps N1-N4 above, the interface problem information can be semantically aligned with the entities and relationships between entities in the second knowledge base in a relatively efficient and accurate manner, resulting in a second repair strategy at the code level. The second repair strategy has high pertinence and feasibility.

[0101] Based on the foregoing embodiments, when repairing the interface of a target application using the target repair scheme among multiple candidate repair schemes, multiple candidate repair schemes can be displayed to the target user for the target user to select a scheme, the target repair scheme is determined in response to the selection operation, and the target repair scheme is used to repair the interface of the target application.

[0102] When repairing the interface of a target application using the target repair scheme from multiple candidate repair schemes, multiple candidate repair schemes can also be deployed to the test environment in sequence, and the preset test case set can be called to test the multiple candidate repair schemes to obtain test result data. The target repair scheme can then be determined from the multiple candidate repair schemes based on the test result data.

[0103] Specifically, an interface test scenario can be built in a test environment configured identically to the target application's production environment. This interface test scenario includes business processes related to interface errors, combinations of input parameters, and dependencies on third-party services. Then, multiple candidate fixes are deployed to the test environment sequentially. The test case set may include at least one of functional verification test cases, stress test cases, and compatibility test cases; this embodiment does not impose any limitations.

[0104] This approach offers two advantages: firstly, it showcases solutions for users to choose from, incorporating human experience; secondly, it automatically deploys relevant tests to select the appropriate solution based on test results, demonstrating intelligence and efficiency. The combination of these two methods ensures both flexibility and reliability in the repair process, while also improving the adaptability and accuracy of interface repair, enabling rapid and effective interface remediation.

[0105] Based on the aforementioned embodiments, training samples can also be generated according to the target repair scheme, interface error information, and repair effect data. The repair effect data includes: changes in the response status code of the interface before and after repair (e.g., from error code 500 to 200), error recurrence rate (e.g., the proportion of error recurrence in the same scenario after repair to the total number of tests, decreasing from 100% to 0%), and anomaly elimination rate of related service links (e.g., the proportion of the number of abnormal logs in each node of the call link reduced after repair, decreasing from 80% to 5%).

[0106] Afterwards, the training samples can be structurally labeled. The structured labeling includes: mapping relationship labels between interface error information and target repair solutions, and validity labels for key repair steps in the target repair solution. The mapping relationship labels can be used to represent the matching strength between the two using Boolean values ​​or weight values. For example, the mapping label for "parameter unvalidation error" and "supplementary non-empty validation solution" is 1.0 (strong match), while the mapping label for "anomaly handling improvement solution" is 0.3 (weak match). The validity labels for key repair steps in the target repair solution can be used to label the validity of core operations in the solution (such as "call location of non-empty validation logic" and "setting of anomaly capture range") based on the repair effect data (such as "effective," "partially effective," or "ineffective"). For example, the validity label for the step "adding non-empty validation at the function entry point" is "effective" because it directly reduces the error reproduction rate to 0%. The labeling process can combine manual review and automated rules; this embodiment does not impose restrictions. For example, when the error reproduction rate is ≤5%, the mapping relationship is automatically labeled as a strong match to ensure label accuracy.

[0107] Subsequently, the structured labeled training samples can be input into the error analysis model for incremental training. Specifically, during incremental training, the error analysis model can use the semantic vector of the error information as input and the mapping relationship label as the supervision signal to optimize the vector matching weights (e.g., enhancing the semantic association between "parameter error" and "validation of supplementary solutions"). Simultaneously, based on the validity labels of key steps, the logic for generating repair strategies is adjusted (e.g., prioritizing the recommendation of step combinations labeled "valid"). The model parameters are updated using mini-batch gradient descent, and model performance (e.g., the accuracy of repair solution recommendations) is monitored in real time using a validation set. Training stops once the metrics stabilize, and the optimized model parameters are retained.

[0108] Through the incremental training described above, the error analysis model can continuously learn new repair experience, gradually improve its adaptability to complex interface error scenarios, and enhance the accuracy and effectiveness of repair strategy generation.

[0109] The following will combine Figure 3 The specific implementation of the interface repair method provided in the embodiments of this application in a real-world application scenario is described.

[0110] like Figure 3 As shown, in software testing and maintenance scenarios, the following will use the automated testing and fault repair of an e-commerce platform interface as an example to illustrate the specific implementation process of this system:

[0111] I. Scene Background

[0112] An e-commerce platform's automated testing platform (such as automated testing scenarios for order creation and product queries) encountered errors during API testing due to abnormal API call parameters and code logic defects. This system is needed to quickly locate and fix the problem to ensure stable operation of the business process. The complete handling process is as follows:

[0113] II. System-level Layered Collaborative Process

[0114] (I) Presentation Layer and Access Layer: Error Triggering and Access Request

[0115] When the scenario automation platform was testing the order creation interface, an error occurred due to parameter validation failure. The error message was transmitted to the access layer via the platform. The API gateway received the POST / GET request (including the error context), and the load balancing module distributed the error handling request to the backend logic processing layer appropriately according to the system load. At the same time, the access control module verified the validity of the request, and the logging module started recording process logs simultaneously.

[0116] (II) Logic Processing Layer: Multi-module Collaborative Analysis and Repair

[0117] Error information collection module: Captures error information from the scene automation platform in real time, including error codes (such as "400 - Invalid parameter"), error descriptions ("Order amount field format error"), interface call parameters (including abnormal amount values) and call logs (recording call time and involved service nodes), and formats the information to prepare for subsequent analysis.

[0118] The AI ​​large-scale model analysis module utilizes natural language processing and reasoning capabilities, combined with the knowledge base module content, to deeply analyze the causes of errors. It calls upon the "Common Error Types and Solutions for E-commerce Order Interfaces" section in the knowledge base, determines the error type to be "parameter validation error," and, based on model training data (including historical cases of fixing similar parameter errors), attempts to generate a repair strategy (such as "validating the regular expression of the order amount field and correcting the parameter generation logic").

[0119] The knowledge base module stores common errors in e-commerce business scenarios (such as order parameters, inventory deduction issues) and solutions (including historical repair cases: an error caused by an excessively long order address field was fixed by truncation and format conversion), and a 58 business knowledge base (aligned with e-commerce business process specifications and interface design standards). The system continuously supplements and updates the knowledge base from data sources such as business documents (order interface development documents) and historical test records (past parameter validation error handling records) to ensure the accuracy of the knowledge.

[0120] The repair strategy generation and verification module: Based on the AI ​​large-scale model analysis results, it retrieves similar parameter error repair solutions from the knowledge base (such as "adjusting parameter validation rule code segments"), or generates specific strategies based on model suggestions (such as modifying parameter validation functions in the order service). Then, it simulates execution in the test environment: adjusting the interface call parameters to a compliant format, re-triggers the order creation interface test, and verifies the repair effect. If verification fails (e.g., causing inventory deduction logic conflicts after repair), the failure information (including new error points and conflict manifestations) is sent back to the AI ​​large-scale model analysis module for re-analysis and reasoning.

[0121] Repair Execution Module: After the repair strategy is successfully verified (e.g., the order creation interface call is normal in the test environment and returns "200 - Order creation successful"), the actual repair operation is performed: modify the interface call parameter generation logic (adjust the amount field formatting code), update the configuration file (supplement parameter validation rules) or fix code errors (correct the parameter validation function), and feed the repair results back to the scenario automation platform to support the continued execution of subsequent test processes.

[0122] (III) Data Layer and Storage Layer: Knowledge Support and Data Persistence

[0123] In the data layer, the interface call log repository records the complete call trajectory of this error; the exception code repository stores the error code and related logic fragments; relevant project information (such as the project and version to which the order service belongs), a historical error knowledge base (accumulating similar parameter error handling solutions), a business knowledge base (e-commerce order business rules), and model training data storage (including data from the error repair process) provide data support for analysis and repair. This data is stored in MSSQL structured format (e.g., error codes and repair solutions are stored together) and frequently accessed knowledge (such as recent similar error solutions) is cached in Redis, ensuring efficient data read and write operations and supporting rapid calls from the logic processing layer.

[0124] (iv) Operating Environment: Cloud Platform Cluster Assurance

[0125] The entire process relies on a cloud platform cluster to provide computing and storage resources, enabling distributed collaboration among modules, handling high-concurrency error processing needs, and ensuring efficient and stable system operation.

[0126] III. Implementation Results and Value

[0127] Through the layered collaborative processing of this system, the average time for repairing API errors on a certain e-commerce platform has been reduced from 2-4 hours of manual troubleshooting to 15-30 minutes of automated processing. By combining a knowledge base with a large AI model, repair solutions are accurately matched, reducing the cost of manual trial and error. The closed-loop process of repair verification and execution ensures the effectiveness of the repair, helping enterprises improve the efficiency of automated API testing and fault handling, strengthen business continuity and stability, and provide reliable technical support for high-frequency business scenarios such as e-commerce promotions.

[0128] (Note: This example uses an e-commerce interface testing scenario, but can be adapted to the automated error reporting and repair needs of system interfaces in multiple fields such as finance and social networking. By adjusting the business knowledge in the knowledge base and the model training data, it can be flexibly adapted to different business scenarios.)

[0129] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 11 to 14 can be device A; or the execution subject of steps 11 to 12 can be device A, and the execution subject of steps 13 to 14 can be device B; and so on.

[0130] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 11, 12, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0131] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0132] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. This electronic device is applicable to the interface repair method provided in the foregoing embodiments, such as... Figure 4 As shown, the electronic device may include: a memory 401, a processor 402, and a communication component 403.

[0133] Memory 401 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0134] Processor 402, coupled to memory 401, is used to execute computer programs in memory 401 for: acquiring interface error information of a target application during runtime; inputting the interface error information into an AI-based error analysis model, the error analysis model being connected to a multi-dimensional knowledge base; the multi-dimensional knowledge base includes at least: a first knowledge base for problem dimensions, a second knowledge base for service dimensions, and a third knowledge base for code dimensions; semantically aligning the interface error information with entities and entity relationships in the first knowledge base within the error analysis model to obtain interface problem information matching the interface error information; semantically aligning the interface problem information with entities and entity relationships in both the first and second knowledge bases to obtain a first repair strategy at the service level and a second repair strategy at the code level; outputting multiple candidate repair schemes for the interface error situation based on the first and second repair strategies; and using a target repair scheme from the multiple candidate repair schemes to repair the interface of the target application.

[0135] Optionally, when the processor 402 semantically aligns the interface error information with the entities and entity relationships in the first knowledge base to obtain interface problem information matching the interface error information in the error analysis model, it specifically performs the following steps: converting the interface error information into a first semantic vector sequence containing contextual semantics; generating a second semantic vector sequence based on the entities and entity relationships in the first knowledge base; calculating a first similarity between the first semantic vector sequence and the second semantic vector sequence, and determining a first entity and a first entity relationship matching the interface error information from the first knowledge base based on the first similarity and a preset first threshold; and generating interface problem information matching the interface error information based on the first entity and the first entity relationship.

[0136] Optionally, when the processor 402 converts the interface error information into a first semantic vector sequence containing contextual semantics, it specifically performs the following preprocessing on the interface error information: Preprocessing step S1: Identify the error statement sentence patterns and logical connectors in the interface error information, and label the interface error information with error types based on preset error type classification rules, wherein the error types include syntax errors, logical errors, parameter errors, and permission errors; Preprocessing step S2: Extract the core entities in the interface error information, wherein the core entities include module information, function information, call stack information, and / or parameter information where the error occurred, and identify the semantic function of the core entities in the current error scenario; convert the preprocessed interface error information into a candidate semantic vector sequence containing contextual semantics; and perform weighted enhancement processing on the position of the core entities in the candidate semantic vector sequence based on the semantic function of the core entities in the current error scenario to obtain the first semantic vector sequence.

[0137] Optionally, when the processor 402 generates the second semantic vector sequence based on the entities and relationships between entities in the first knowledge base, it specifically performs the following: structural representation of the entities and relationships between entities in the first knowledge base to obtain multiple triples; each triple includes any entity in the first knowledge base, the relationship between the entity and other entities, and the entity's attributes; using a knowledge graph embedding algorithm, the multiple triples are converted into multiple low-dimensional dense vectors to form a second semantic vector set, and a hierarchical index structure is constructed for the second semantic vector set, wherein the hierarchical index structure uses entity type as the first-level index and the relationship type between entities as the second-level index.

[0138] Optionally, when the processor 402 calculates the first similarity between the first semantic vector sequence and the second semantic vector sequence, and determines the first entity and the relationship between the first entities that match the interface error information from the first knowledge base based on the first similarity and a preset first threshold, it specifically performs the following: based on the hierarchical index structure, it performs a preliminary matching between the first semantic vector sequence and the second semantic vector sequence to obtain a set of candidate entities related to the error type in the second semantic vector sequence; for the candidate entity set, it calculates the multi-dimensional similarity between the first semantic vector sequence and the second semantic vector corresponding to each candidate entity, the multi-dimensional similarity including semantic similarity, structural similarity and contextual similarity; based on the multi-dimensional similarity, it filters out the first entity and the relationship between the first entities that match the interface error information from the candidate entity set.

[0139] Optionally, when the processor 402 uses the target repair scheme among the plurality of candidate repair schemes to repair the interface of the target application, it specifically performs the following: displays the plurality of candidate repair schemes to the target user for the target user to select a scheme, determines the target repair scheme in response to the selection operation, and uses the target repair scheme to repair the interface of the target application; or, sequentially deploys the plurality of candidate repair schemes to the test environment, calls a preset test case set to test the plurality of candidate repair schemes to obtain test result data, and determines the target repair scheme from the plurality of candidate repair schemes based on the test result data.

[0140] Optionally, the processor 402 is further configured to: generate training samples based on the target repair scheme, the interface error information, and the repair effect data, wherein the repair effect data includes: changes in the response status codes of the interface before and after repair, error reproduction rate, and anomaly elimination rate of associated service links; perform structured annotation on the training samples, wherein the structured annotation includes: mapping relationship labels between the interface error information and the target repair scheme, and validity labels of key repair steps in the target repair scheme; and input the structured annotated training samples into the error analysis model to perform incremental training on the error analysis model.

[0141] Furthermore, such as Figure 4 As shown, the electronic device also includes other components such as a display 404, a power supply component 405, and an audio component 406. Figure 4 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 4 The components shown.

[0142] This application also provides an electronic device, including: a memory and a processor; wherein the memory is used to: store one or more computer instructions; and the processor is used to execute the one or more computer instructions to: perform the steps in the interface repair method.

[0143] This application also provides a computer-readable storage medium that, when executed by a processor, enables the processor to implement the steps in the interface repair method.

[0144] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, enables the processor to implement the steps in the interface repair method.

[0145] In this embodiment, interface error information during the runtime of the target application can be obtained. This error information is input into an error analysis model, which is connected to a multi-dimensional knowledge base, including a first knowledge base at the problem dimension, a second knowledge base at the service dimension, and a third knowledge base at the code dimension. The error analysis model semantically aligns the interface error information with the entities and relationships between entities in the first knowledge base to obtain interface problem information. It then semantically aligns the interface problem information with the entities and relationships between entities in both the first and second knowledge bases to obtain a first repair strategy at the service level and a second repair strategy at the code level. Based on the first and second repair strategies, multiple candidate repair schemes are output for the interface error situation. Finally, the target repair scheme from among the multiple candidate repair schemes is used to repair the interface of the target application. In this way, the error analysis model can generate repair schemes for interface error situations efficiently and accurately based on a multi-dimensional knowledge base.

[0146] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0147] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.

[0148] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0149] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0150] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

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

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

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

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

[0155] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0156] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0157] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0158] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0159] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An interface repair method, characterized in that, include: Obtain the interface error information of the target application at runtime; The interface error information is input into an AI-based error analysis model, which is connected to a multi-dimensional knowledge base. The multi-dimensional knowledge base includes at least: a first knowledge base based on the problem dimension, a second knowledge base based on the service dimension, and a third knowledge base based on the code dimension; In the error analysis model, the interface error information is semantically aligned with the entities and relationships between entities in the first knowledge base to obtain interface problem information that matches the interface error information; the interface problem information is semantically aligned with the entities and relationships between entities in the first knowledge base and the second knowledge base respectively to obtain a first repair strategy at the service level and a second repair strategy at the code level; and multiple candidate repair schemes for the interface error situation are output according to the first repair strategy and the second repair strategy. The target application is repaired by using the target repair scheme from among the multiple candidate repair schemes.

2. The method according to claim 1, characterized in that, In the error analysis model, the interface error information is semantically aligned with the entities and relationships between entities in the first knowledge base to obtain interface problem information matching the interface error information, including: The interface error message is converted into a first semantic vector sequence containing contextual semantics; Based on the entities and relationships between entities in the first knowledge base, a second semantic vector sequence is generated; Calculate the first similarity between the first semantic vector sequence and the second semantic vector sequence, and determine the first entity and the relationship between the first entities that match the interface error information from the first knowledge base based on the first similarity and a preset first threshold; Based on the first entity and the relationship between the first entities, interface problem information matching the interface error information is generated.

3. The method according to claim 2, characterized in that, The interface error message is converted into a first semantic vector sequence containing contextual semantics, including: The interface error information is preprocessed as follows: Preprocessing step S1: Identify the error statement structure and logical connectors in the interface error information, and label the interface error information with error types based on preset error type classification rules. The error types include syntax errors, logical errors, parameter errors, and permission errors. Preprocessing step S2: Extract the core entities in the interface error information. The core entities include module information, function information, call stack information, and / or parameter information where the error occurred, and identify the semantic function of the core entities in the current error scenario. The preprocessed interface error information is converted into a sequence of candidate semantic vectors containing contextual semantics; Based on the semantic function of the core entity in the current error reporting scenario, the position of the core entity in the candidate semantic vector sequence is weighted and enhanced to obtain the first semantic vector sequence.

4. The method according to claim 3, characterized in that, Based on the entities and relationships between entities in the first knowledge base, a second semantic vector sequence is generated, including: The entities and relationships between entities in the first knowledge base are represented in a structured manner to obtain multiple triples; each triple includes any entity in the first knowledge base, the relationship between the entity and other entities, and the attributes of the entity; Using a knowledge graph embedding algorithm, the multiple triples are converted into multiple low-dimensional dense vectors to form a second semantic vector set. A hierarchical index structure is then constructed for the second semantic vector set, with entity type as the first-level index and the relationship type between entities as the second-level index.

5. The method according to claim 4, characterized in that, Calculate the first similarity between the first semantic vector sequence and the second semantic vector sequence, and based on the first similarity and a preset first threshold, determine the first entity and the relationship between the first entities that match the interface error information from the first knowledge base, including: Based on the hierarchical index structure, the first semantic vector sequence and the second semantic vector sequence are initially matched to obtain a set of candidate entities related to the error type in the second semantic vector sequence; For the candidate entity set, calculate the multi-dimensional similarity between the first semantic vector sequence and the second semantic vector corresponding to each candidate entity. The multi-dimensional similarity includes semantic similarity, structural similarity, and contextual similarity. Based on the multi-dimensional similarity, the first entity and the relationship between the first entities that match the interface error information are selected from the candidate entity set.

6. The method according to any one of claims 1-5, characterized in that, Using the target repair scheme from the plurality of candidate repair schemes, the target application is repaired via interface repair, including: The system presents multiple candidate repair solutions to the target user for selection, determines the target repair solution in response to the selection, and uses the target repair solution to repair the interface of the target application; or, The multiple candidate repair schemes are deployed to the test environment in sequence, and the preset test case set is called to test the multiple candidate repair schemes to obtain test result data. The target repair scheme is determined from the multiple candidate repair schemes based on the test result data.

7. The method according to any one of claims 1-5, characterized in that, Also includes: Based on the target repair plan, the interface error information, and the repair effect data, training samples are generated. The repair effect data includes: changes in the response status code of the interface before and after repair, error reproduction rate, and anomaly elimination rate of related service links. The training samples are structured and labeled, and the structured label includes: a mapping relationship label between the interface error information and the target repair scheme, and a validity label for the key repair steps in the target repair scheme; The structured labeled training samples are input into the error analysis model to perform incremental training on the error analysis model.

8. An electronic device, characterized in that, include: A memory and a processor; wherein the memory is configured to: store one or more computer instructions; and the processor is configured to execute the one or more computer instructions to: perform the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-7.

10. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, causes the processor to perform the steps of the method according to any one of claims 1-7.

Images