Large model-based interface verification and testing method, device, medium and product

Abstract

The embodiment of the application relates to the information technology field, and discloses an interface verification and testing method, equipment, medium and product based on a large model, the method comprising: acquiring an interface document to be tested, using a first large model to analyze the interface document, constructing a test request parameter based on a request parameter definition, and obtaining a real-time response message by calling a real interface; using a second large model to perform semantic comparison on a response example in document structure information and the real-time response message, obtaining a corrected interface document; using a third large model to compare a parameter constraint condition in the corrected interface document with a verification logic in a business logic code segment, and generating a logic verification passing result; and based on the corrected interface document and the logic verification passing result, using a fourth large model to generate a Mock rule and an automatic test case script, thereby reducing the maintenance cost and false positive rate of the automatic test script, and improving the automatic test efficiency.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method, device, medium and product for interface verification and testing based on a large model. Background Technology

[0002] As software system architecture increasingly evolves towards microservices and agile development models, interface testing has become a crucial step in ensuring software delivery quality. In a typical testing process, testers usually write test cases or configure mock services based on interface documentation (such as Swagger, YAPI, or Word documents) provided by the development department, aiming to simulate upstream and downstream dependencies and verify business logic.

[0003] However, in actual software engineering practice, existing interface testing processes face significant challenges. First, developers often struggle to keep documentation up-to-date during rapid iterations, causing interface documentation to lag behind actual code changes. Generating test cases or mock services directly based on outdated interface documentation easily leads to numerous errors and false failures during test script runtime, increasing the cost for testers to troubleshoot.

[0004] Furthermore, API documentation typically only describes surface-level information such as field names and data types, failing to fully disclose the deep validation logic hidden in the backend code, such as non-null constraints under specific states or numerical ranges limited by hard-coded configurations. Traditional test generation tools cannot detect these implicit constraints at the code level, resulting in generated test cases that often have insufficient coverage or fail basic backend validation.

[0005] Meanwhile, most existing mock tools are based on static rule matching and lack state memory capabilities. For example, when testing consecutive scenarios where "creating an order" is followed immediately by "querying an order," traditional mocks cannot pass the "created" data to the "query" interface, making it impossible to verify complex business flow logic. Summary of the Invention

[0006] One objective of this application is to provide an interface verification and testing method, device, medium, and product based on a large model, at least to solve the technical problems in the prior art where test cases are unusable due to inconsistencies between interface documentation and actual business logic, and where traditional Mock services lack state maintenance capabilities, resulting in insufficient coverage of business scenarios.

[0007] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0008] This application provides an interface verification and testing method based on a large model, the method comprising:

[0009] Obtain the interface document to be tested, parse the interface document using the first major model, extract and generate standardized document structure information, which includes at least request parameter definitions and response examples;

[0010] Based on the defined request parameters, test request parameters are constructed, and real-time response messages are obtained by calling a real interface.

[0011] The second major model is used to perform a semantic comparison between the response examples in the document structure information and the real-time response message. If there is a difference, the interface document structure information is updated according to the real-time response message to obtain the corrected interface document.

[0012] Locate and obtain the backend business logic code fragment corresponding to the interface based on the service identifier of the interface;

[0013] The third model is used to compare the parameter constraints in the revised interface document with the validation logic in the business logic code snippet; if they are found to be consistent, a logic validation pass result is generated.

[0014] Based on the revised interface documentation and the logical verification results, the fourth model is used to generate Mock rules and automated test case scripts.

[0015] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0016] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0017] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0018] Compared with related technologies, the solution provided in this application firstly breaks away from the traditional one-way process of testing that relies solely on documentation, introducing two key steps: dynamic correction driven by real interfaces and reverse consistency verification of code logic. On one hand, documentation is corrected by calling real interfaces to obtain real-time response messages, eliminating errors caused by documentation lag. On the other hand, by locating and extracting backend business logic code, a large model is used to analyze whether the verification logic in the code conflicts with the documentation definition. This dual-cleaning mechanism ensures that the subsequently generated Mock rules and test cases are built based on high-fidelity information, significantly reducing the maintenance cost and false positive rate of automated test scripts.

[0019] Secondly, unlike existing static rule-based mock services, this application utilizes a large model to identify read / write dependencies between interfaces and constructs mock logic that includes runtime state storage. When testing write-type interfaces, it automatically stores business data; when testing read-type interfaces, it retrieves data from the storage space and constructs a dynamic response. This design endows the mock service with context memory capabilities, enabling automated testing of complex business flows such as CRUD operations, thereby solving the problem of traditional mock data being rigid and unable to simulate real business state flows.

[0020] Furthermore, this application can accurately locate and extract corresponding business logic code snippets from the database or configuration center. Compared to traditional full code scanning, this approach is more lightweight and focused, specifically targeting parameter validation and data processing logic. Combined with the semantic analysis capabilities of large models, this solution can discover undefined implicit constraints in documents, thereby identifying potential logical defects in advance during the test design phase.

[0021] Finally, by introducing a feedback loop mechanism during the test execution phase, this application enables the automatic aggregation of exception logs, script source code, and interface documentation when tests fail, and utilizes a large model for root cause classification. The system can not only distinguish between script errors and interface defects as the source of the failure, but also automatically generate a corrected script and trigger retries when the defect is determined to be a script logic defect. This mechanism achieves unattended and self-healing automated testing, significantly improving the stability and execution efficiency of the CI / CD pipeline. Attached Figure Description

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

[0023] Figure 1A flowchart illustrating an interface verification and testing method based on a large model, provided as an exemplary embodiment of this disclosure;

[0024] Figure 2 A flowchart illustrating another interface verification and testing method based on a large model, provided as an exemplary embodiment of this disclosure;

[0025] Figure 3 An exemplary structural diagram of the electronic device provided for some embodiments of this application. Detailed Implementation

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

[0027] Figure 1 A flowchart illustrating an exemplary embodiment of this disclosure provides a method for interface verification and testing based on a large model, the method comprising:

[0028] S101. Obtain the interface document to be tested, parse the interface document using the first major model, extract and generate standardized document structure information, which includes at least request parameter definitions and response examples.

[0029] Specifically, such as Figure 2 In practical applications, the API documentation to be tested is typically in unstructured or semi-structured formats such as PDF, Word, Markdown, or HTML. First, these files are read using a built-in document loader, and their format type is identified. This text is then input into a primary model (such as a finely tuned GPT-4 or DeepSeek). This model utilizes its natural language understanding capabilities to extract the core metadata of the API from the messy documentation and convert it into a structured JSON object conforming to a preset quality standard metamodel. This structured information explicitly includes at least the definitions of request parameters (such as field names, types, and required fields) and response examples (such as success and failure message examples), establishing baseline data for subsequent validation processes.

[0030] S102. Construct test request parameters based on the defined request parameters, and obtain real-time response messages by calling the actual interface.

[0031] S103. Using the second major model, perform a semantic comparison between the response examples in the document structure information and the real-time response message. If there is a difference, update the interface document structure information according to the real-time response message to obtain the corrected interface document.

[0032] Specifically, since static documentation often lags behind code changes, the parsed document structure is not directly trusted. Based on the request parameter definitions extracted in step S101, one or more sets of test request parameters (Payload) are constructed. After obtaining the real-time response message returned by the actual interface, the second major model is invoked. The second major model performs semantic-level comparison and analysis between the response examples in the documentation and the real-time response message. If significant differences are found (for example, the documentation defines a field as an integer, but the actual return is a string; or the actual return contains additional key fields not defined in the documentation), the system will automatically update and complete the original document structure information based on the data structure of the real-time response message, thereby generating a corrected interface documentation that is consistent with the runtime state.

[0033] S104. Locate and obtain the backend business logic code fragment corresponding to the interface based on the service identifier of the interface.

[0034] S105. Using the third major model, compare the parameter constraints in the revised interface document with the verification logic in the business logic code snippet; if the two are determined to be consistent, generate a logic verification pass result.

[0035] Specifically, after document cleaning is completed, steps S104 and S105, the code logic consistency verification stage, are entered. Based on the service ID in the interface document, the system locates the relevant business logic using a pre-defined interface code mapping relationship. The service ID is then used to retrieve the corresponding value logic configuration record from the backend management platform's database, extracting the associated business logic implementation code. To prevent the large model from being interfered with by irrelevant code, the extracted code is sliced, filtering out non-business code such as log printing and monitoring points, retaining only parameter validation logic (such as if statements) and data processing logic fragments. Subsequently, a structured prompt containing document parameter constraints and code validation logic is constructed and input into the third large model. The third large model acts as the logical judgment, analyzing whether the conditional judgments in the code fragments strictly cover the type constraints and value ranges defined in the document. Only when the two logics are determined to be consistent will a result indicating that the logic validation has passed be generated; otherwise, the risk point will be marked and an exception message may be generated.

[0036] S106. Based on the revised interface document and the logical verification results, generate Mock rules and automated test case scripts using the fourth model.

[0037] Specifically, finally, step S106, the automated generation and testing phase, is executed. Based on the revised interface documentation obtained from the previous steps (ensuring accurate data structures) and the passed logic verification results (ensuring accurate business rules), the fourth model is invoked to generate the final deliverables. During the generation of mock rules, the fourth model analyzes the business semantic relationships between interfaces and parses the scenario definitions in the mock rules (including normal, abnormal, and boundary scenarios), extracts the expected status codes and response bodies, and automatically generates automated test case scripts (such as Python Pytest scripts or Postman collections) containing complete assertion logic. These scripts can be directly integrated into the CI / CD pipeline to achieve regression testing and continuous monitoring of the interfaces.

[0038] It should be noted that the "first major model," "second major model," "third major model," and "fourth major model" mentioned in the claims and embodiments of this application do not necessarily refer to four physically isolated or architecturally completely independent large language models. In actual deployment, they can be the same general-purpose major model (such as GPT-4 or Claude-3.5), which can be reused in a time-sharing manner through different system prompts or contexts; they can also be multiple dedicated major models fine-tuned for different tasks (such as specially fine-tuned major models); or they can be different parameter versions of the same basic model.

[0039] In a preferred embodiment, the present invention employs a multi-agent collaborative architecture based on a large-scale model application development platform (such as the open-source platform Dify) to achieve the aforementioned closed-loop process. The system does not use a single linear script for control, but rather constructs an orchestration workflow comprising multiple dedicated agents. Each agent is assigned a specific persona, toolset, and model configuration, and these are interconnected and data flows are managed through Dify's workflow orchestration engine. The specific configuration is as follows:

[0040] Document parsing agent (corresponding to the first main model): This agent is configured as a "senior document analyst". It is bound to a document parsing tool (such as a PDF parser) and configured with a large model that excels at long text understanding (such as Claude-3-Opus). Its task is to receive the raw document and output standardized document structure information.

[0041] Interface Correction Agent (corresponding to the second major model): This agent is configured as an "API debugging expert." It integrates HTTP request tools (such as the Requests library) and JSON comparison tools. Dify sends the parsed document to it, which autonomously calls the actual API and uses a large model with strong reasoning capabilities (such as GPT-4o) to compare response differences and output the corrected document.

[0042] Code auditing agent (corresponding to the third major model): This agent is configured as a "code security auditor." It connects to a database query tool and can retrieve business code based on service identifiers. This agent is configured with a large programming model (such as DeepSeek-Coder) that excels at code understanding, focusing on analyzing conflicts between logical branches and document constraints in code snippets.

[0043] Test-generating agent (corresponding to the fourth major model): This agent is configured as a "QA engineer". It receives accurate data cleaned by the preceding agent and uses a model skilled in logical reasoning to generate mock rules and Pytest scripts.

[0044] In Dify's orchestration canvas, the aforementioned agents are connected through nodes and variables. The system employs a model routing strategy, routing simple document extraction tasks to low-cost models and complex code logic verification tasks to high-inference-capability models. This optimizes system performance and response speed while maintaining verification accuracy. This multi-agent collaborative model avoids the attention distraction or instruction forgetting issues that occur when a single model handles extremely long and complex contexts.

[0045] In the above embodiments, by constructing a three-way verification closed loop of "documentation-real interface-code," the technical challenges of outdated interface documentation and distorted mock data are effectively solved. By calling the real interface to obtain real-time response messages and dynamically correcting the documentation, the discrepancy between the documentation and the actual operating state is eliminated, ensuring the accuracy of the test generation basis. Service identifiers are used to accurately locate and extract backend business logic code, and the consistency between the code implementation and the documentation definition is verified through reverse comparison using a large model, enabling the early detection of hidden logical defects during the test design phase. Furthermore, based on the corrected interface documentation and logic verification results, automated test case scripts are automatically generated, greatly improving the stability and execution efficiency of the CI / CD pipeline.

[0046] Furthermore, in one embodiment, before parsing the interface document using the first large model, a document preprocessing step is also included:

[0047] Automatically identify the file format of the interface documentation;

[0048] If the file format is PDF, a layout-aware text extraction strategy is used to restore the document's layout structure and text flow.

[0049] If the file format is CSV, the structured parsing engine will automatically infer the data type of the columns and handle delimiter ambiguity.

[0050] The preprocessed text data is input into the first large model.

[0051] Specifically, considering the diverse sources and heterogeneous formats of the interface documents to be tested, an intelligent document preprocessing step is introduced before parsing the interface documents using the first large model to improve the accuracy of subsequent large model parsing. First, an automatic file format identification step is performed. In this step, the file extension (such as .pdf or .csv) is not relied upon to determine the format; instead, the actual MIME type of the file is determined by reading the binary signature (Magic Number) in the file header, thus avoiding parsing failures due to incorrect file extensions.

[0052] When a PDF file is identified, a layout-aware text extraction strategy is employed. Since PDF files are essentially a set of coordinate-based drawing instructions, directly extracting text often leads to misaligned multi-column layouts or lost table data. An integrated parsing engine (such as a custom library based on pdfminer or PyMuPDF) analyzes the boundary coordinates of each text block on the page. Based on the vertical and horizontal distances of the text blocks, the logical reading order of the document is reconstructed, intelligently identifying and preserving paragraph structure, table row and column relationships, and heading levels. This strategy effectively restores the document's layout structure and text flow, ensuring that the input to the large model is semantically coherent text paragraphs, rather than a jumbled stream of characters.

[0053] When a CSV (comma-separated values) file format is detected, the structured parsing engine is activated. Because CSV files lack metadata, they often suffer from inconsistent delimiters (such as using semicolons or tabs) or ambiguous data types. The parsing engine first performs a heuristic scan of the first few lines of the file, automatically inferring and handling delimiter ambiguities by statistically analyzing the frequency of different characters. Subsequently, the engine analyzes the data distribution of each column, automatically inferring the data type (e.g., distinguishing between a purely numeric "Amount" column and a "ID Number" column, which, although composed of numbers, should be treated as a string). Finally, this cleaned, reconstructed, and type-labeled text data is uniformly encapsulated into a standard context format understandable by the larger model and input into the first main model for subsequent interface information extraction.

[0054] Furthermore, in one embodiment, multiple large models are used to collaboratively process the interface document.

[0055] Specifically, this embodiment constructs a multi-model collaborative processing approach to address the issues of diverse and complex interface documentation. A multi-model collaborative processing system can be built using a Python asynchronous microservice architecture (FastAPI + Uvicorn) and deployed via Docker containerization technology to ensure resource isolation and runtime environment independence between different test tasks. When a user logs into the system and starts a "new interface test task," the system initializes the multi-model scheduling center, dynamically loading and managing the inference interfaces of multiple Large Language Models (LLMs). These models each have their own specializations; for example, OpenAIChatGPT is used for high-precision general semantic understanding, the locally deployed DeepSeek-Coder model focuses on deep parsing of code logic, ByteDance's large model (Doubao) excels at fine-grained structured extraction of Chinese documents, and Alibaba's QwQ model is used for complex mathematical expressions and logical derivations. To achieve efficient collaboration, each model accesses the system through a unified LLM adapter pattern. The scheduling center can automatically route requests to the optimally matched model for processing based on the specific type of the current task (such as document parsing, code verification, or test case generation). In addition, the system automatically clears the temporary storage area (such as Redis cache) before each task starts to ensure the purity and independence of the test task data.

[0056] When a user uploads documents in formats such as images, PDF, DOCX, TXT, or CSV, the system first initiates an automatic recognition process, dynamically determining the document type using a pre-defined parsing strategy mapping table. For image format input, the system directly calls a multimodal large model (such as GPT-4o) for end-to-end visual semantic understanding. For other non-image formats, the system uses an integrated document extractor for intelligent processing: if recognized as PDF, the parser employs a layout-aware text extraction strategy, prioritizing the use of the pdfminer.six library to reconstruct the text flow and layout structure. If parsing fails or content is missing, it automatically reverts to the PyPDF2 library for supplementary extraction, ensuring content integrity. If recognized as DOCX, the parser extracts paragraph, table, and style metadata by traversing the document object model, fully preserving the document's logical hierarchy. If recognized as CSV, the structured data parsing engine automatically infers column data types and handles delimiter ambiguity. For TXT format, the system uses an adaptive encoding reading mechanism to dynamically determine the text encoding format for lossless reading.

[0057] In the above embodiments, not only are multiple underlying parsing tools (such as PyPDF2, pandas, etc.) integrated, but a unified framework for self-format recognition and self-selection of parsing strategies is also innovatively constructed. This design breaks through the limitations of existing technologies that typically require manual pre-conversion of formats or manual specification of parsing methods, realizing an automated "upload and parse" process. Through the dynamic loading and routing mechanism of parsing strategies, the system can seamlessly connect traditional NLP models with cutting-edge multimodal models, significantly improving the system's compatibility and robustness to documents from different sources and generated by different tools, greatly reducing the cost of manual intervention, and laying a high-quality data foundation for subsequent automated testing processes.

[0058] Furthermore, in one embodiment, the inference parameters of the first large model are configured such that the temperature coefficient is set to a preset low threshold to suppress the randomness of model generation;

[0059] Construct a structured semantic prompt template aligned with preset quality standards. The template explicitly defines the interface overview, request parameter metadata, nested response example structure, and error code list that the output results must include.

[0060] The prompt template embeds an example of converting non-standard text to standard JSON format. The few-shot learning mechanism guides the first large model to complete the missing hierarchical structure in the original document or correct illegal syntax, and finally outputs standardized document structure information.

[0061] Specifically, in a preferred embodiment, document standardization processing based on a large language model is performed on the unstructured or semi-structured text data obtained after document parsing in step S101. To overcome the potential output randomness or format illusion problems that may occur when the general large model is freely generated, this embodiment does not adopt the traditional free-response question-and-answer calling method, but instead constructs a structured prompt control mechanism oriented towards the interface document domain. When calling the first large model for inference, the model's temperature coefficient is strictly set to a low value (e.g., 0.2) to significantly suppress the model's creative divergence and ensure that the output results maintain a high degree of determinism and stability across multiple calls.

[0062] Furthermore, a structured semantic prompt template, strictly aligned with the interface document metamodel, is used to construct input instructions. This template is not a simple text request, but explicitly defines four core fields that the output must contain, along with strict data type constraints: interface overview (String type), request parameters (Array type, containing metadata such as name, type, and required), response example (Object type, containing nested success and data structures), and error code (Array type). Semantic constraints conforming to the ISO / IEC 25010 software quality standard are embedded in the prompts, such as requiring "request_id" to exist or requiring the "required" field to be a boolean value. Through this strong pre-emptive format constraint, the system can guide the general large model to output standardized JSON objects that conform to machine-readable standards.

[0063] Furthermore, to address common non-standard descriptions or ambiguous expressions in the original document (e.g., missing the complete JSON structure only through the text description "Return Example: {'code':200,'data':…}"), this embodiment introduces a few-shot learning strategy in the prompt words. Several sets of "non-standard text to standard JSON" conversion examples are pre-set to guide the model to learn how to identify and automatically complete missing structural levels (such as automatically adding missing root nodes or correcting illegal JSON syntax).

[0064] In the above embodiments, the semantic understanding-based completion mechanism can handle highly fragmented input without complex regular expressions or hard-coded rule engines, achieving end-to-end automation of "standardization upon upload." Actual testing shows that this method reduces the manual correction rate of documents to below 15%, significantly outperforming traditional rule matching schemes.

[0065] Furthermore, in one embodiment, updating the interface document structure information based on the real-time response message to obtain a corrected interface document further includes:

[0066] It provides a visual review interface and supports two correction paths: Path 1: In response to the user's manual editing command on the review interface, after verifying the format legality of the modified content using the built-in validator, it directly updates the interface document structure information to obtain the corrected interface document.

[0067] Path 2: In response to user-inputted custom test parameters, a real interface call is triggered, and the field differences between the document response example and the real-time response message are compared using the second major model to generate natural language correction suggestions; in response to the user's instruction to adopt the correction suggestions, the data structure in the real-time response message is automatically synchronized to the interface document structure information to obtain the corrected interface document.

[0068] Specifically, to address the potential for subtle deviations in documents automatically generated by large models, a dual-path correction mechanism involving human and machine collaboration was introduced in the document correction stage. This includes a visual human review interface with a left-right split comparison view: the left side displays the original or preliminarily parsed standardized document (StandardizedDoc), while the right side displays the suggested results generated by the large model or the real-time interface response, automatically highlighting the differences between the two.

[0069] To address discrepancies, the system employs two parallel correction paths to balance flexibility and accuracy. Path 1 (Manual Intervention Mode): Suitable for fine-tuning scenarios. Users can directly edit the "Response Example" field on the interface. To prevent human error (such as missing quotation marks or parentheses), the editor incorporates a real-time JSON Schema validator. If a formatting error is detected, saving is immediately blocked, and a correction prompt is displayed. Path 2 (Data-Driven Mode): Suitable for structural correction scenarios. Users input custom test parameters (e.g., {"user_id": "1001"}) on the interface. The system then calls the actual external interface via the API gateway. After obtaining the actual response (e.g., {"code":200, "data": {"user": "John"}}), the second model executes discrepancy analysis logic (e.g., recognizing that the document defines `user_id` but actually returns `user`), and generates a natural language suggestion: "Field mismatch detected; it is recommended to update `example.data` to the actual response structure." Users simply need to click the "Accept" button, and the system will automatically populate the document with the data structure of the actual response, ultimately generating a verified document (VerifiedDoc) that is completely consistent with the real environment. This mechanism is the first to incorporate runtime data from external interfaces into the document verification loop, effectively solving the common problem of outdated documents in the industry.

[0070] In one embodiment, the step of locating and obtaining the backend business logic code fragment corresponding to the interface based on the service identifier of the interface specifically includes:

[0071] The service identifier is used to query the pre-defined interface code mapping relationship to determine the storage location of the business logic corresponding to the interface;

[0072] Retrieve the business logic implementation code of the interface from the storage location;

[0073] Identify and extract code snippets containing parameter validation logic or data processing logic from the business logic implementation code, and use them as the backend business logic code snippets.

[0074] Furthermore, in one embodiment, the business logic is stored in a relational database; the business logic implementation code is scripting language code or dynamic rule code stored in the relational database.

[0075] Specifically, the unique service identifier (Service ID, such as "SVC_PAY_001") extracted from the interface document can be used as an index key to query the pre-defined interface code mapping relationship. In this embodiment, this mapping relationship is maintained in a relational database (such as MySQL or PostgreSQL) of a backend management platform. By executing an SQL query, the business logic storage location corresponding to the service identifier can be precisely located in the configuration table. This storage location typically points to a specific field in the database (such as rule_content or script_body), which stores the actual running business logic implementation code in the form of long text (CLOB / Text). The business logic implementation code is usually written in scripting languages ​​such as Groovy, Aviator, and QLExpress, or is dynamic rule code based on a domain-specific language (DSL). This storage method allows developers to dynamically adjust business rules without restarting the service.

[0076] For example, the system first parses the corrected interface documentation (e.g., VerifiedDoc.txt) to identify and extract the unique identifier of the interface within the system—the basic service code (e.g., 1229123). Unlike traditional static search methods based on code repository file paths (e.g., directly searching for .java files in GitLab), this embodiment targets a dynamically configurable business architecture. In this architecture, the data source retrieval logic written by developers does not exist as statically compiled files, but is configured in the backend management platform as Groovy script code or dynamic rules, and persistently stored as hard-coded data in a MySQL database. Therefore, the system calls a pre-built dedicated query interface, sending the basic service code (1229123) as an index key to the backend management platform. This interface performs a database query operation in the backend, directly and accurately retrieving and returning the Groovy value retrieval logic code string corresponding to the service code from the configuration table in the MySQL database. Subsequently, the system parses the obtained Groovy code, extracting key logic segments involving parameter validation and data processing, which serve as the basis for subsequent consistency comparison with the documentation.

[0077] In the above embodiments, a dynamic mapping mechanism based on service identifiers enables precise location and retrieval of business logic code stored on non-file system platforms. Especially in low-code platforms or dynamic rule engine scenarios, this solution can directly extract dynamic scripts such as Groovy or Aviator from the database, effectively solving the technical challenge of traditional static code scanning failing to cover hot-update business rules, ensuring consistency between the verification target and the actual running logic. Simultaneously, by introducing code slicing and cleaning techniques, non-business interference code such as log printing and monitoring points can be intelligently removed using syntax analysis or regular expression scanning, retaining only the core verification and data processing logic. This process not only significantly reduces the token consumption cost of large models but also eliminates irrelevant noise interference with model inference, thereby significantly improving the accuracy and robustness of logical consistency comparison.

[0078] In one embodiment, the step of comparing the parameter constraints in the revised interface document with the validation logic in the business logic code snippet using the third major model specifically includes:

[0079] Extract the parameter definition information from the revised interface document, as well as the backend business logic code snippets;

[0080] The parameter definition information is combined with the backend business logic code snippet to construct a consistency verification prompt word;

[0081] The consistency verification prompt is input into the third model, which analyzes the logical statements in the backend business logic code snippet and outputs the consistency judgment result between the code logic and the document definition.

[0082] Specifically, a dedicated prompt template is constructed, which takes the structured requirements from the document (e.g., "data value location is response.data.score"), the extracted code snippets, and the actual returned messages as contextual input to the third language model. This prompt template not only requires the model to understand the syntax of the code but also explicitly requires the model to output structured JSON data conforming to a preset schema. This JSON data must contain a consistency field (a boolean value indicating whether it is consistent) and a reason field (a natural language explanation describing the basis for judgment or details of conflict). The purpose of introducing the actual returned messages is to allow the large model to assist in verifying whether the data extraction path (JSON path) in the code matches the actual message structure, thereby achieving end-to-end verification from the data source to code processing.

[0083] For example, in a validation process targeting the user ID parameter, the following logic is implemented using the prompt words:

[0084] Please analyze the following code logic and determine if it is consistent with the documentation:

[0085] Documentation requirement: The parameter user_id must be a number of type int.

[0086] Code snippet: if (user_id != null && !user_id.matches("\\d+")) { throw newIllegalArgumentException();}

[0087] LLM output: {"consistency": "yes", "reason": "Code validation rules match document requirements"}.

[0088] In the above embodiments, the third model can deeply analyze the conditional statements in the code (such as if statements and regular expression matching) to determine whether they strictly cover the type constraints and value range constraints defined in the documentation. If the model returns "no" for consistency, the system will parse the reason field to generate an exception ticket, prompting the developers that there may be omissions in the code implementation (e.g., the documentation requires positive integers, but the code does not perform symbol verification); if the two are determined to be consistent, a logic verification pass result (LogicVerified.json) is generated as the benchmark for generating high-confidence test cases subsequently.

[0089] Furthermore, in one embodiment, the consistency verification prompt is established through a template, which includes a fixed instruction portion and a dynamic variable portion;

[0090] The parameter definitions in the revised interface document are used as the first variable, and the backend business logic code snippet is used as the second variable. These are then filled into the corresponding positions of the prompt word template.

[0091] The third major model is instructed to analyze the conditional statements in the code snippet, determine whether they cover the parameter type constraints and value range constraints defined in the document, and output JSON format data containing the consistency determination result and the reason for the determination.

[0092] Specifically, for the code logic verification using the third major model described in step S105, a dynamic construction mechanism based on structured prompt word templates is adopted. To ensure the focus of the large model's inference and the standardization of the output format, a standardized prompt word framework is predefined. This framework consists of a "fixed instruction part" and a "dynamic variable part." The fixed instruction part clarifies the model's role definition (e.g., "You are a senior code audit expert"), task objective ("Compare the consistency between the document definition and the code implementation"), and output constraints ("Must return JSON data that conforms to the schema definition"). When performing the verification task, the parameter definition information in the corrected interface document is first extracted, including field name, data type, required field, and value range (e.g., "age field, type Integer, range 18-60"), and encapsulated as the first variable (Variable A). At the same time, the system obtains the backend business logic code snippet extracted and cleaned in step S104 (e.g., a code block containing if (age < 18 || age > 60) throw new Exception(...)) and encapsulates it as the second variable (Variable B). The system uses string interpolation or template engine technology to dynamically fill the corresponding slots in the prompt word template with these two variables, synthesizing a complete contextual input stream. Then, it instructs a third model to perform deep semantic analysis on the input code snippet. The model not only focuses on the syntactic correctness of the code, but more importantly, it analyzes conditional statements (such as if-else branches and switch-case structures), assertions, and regular expression matching logic. The model checks each validation logic in the code to ensure it strictly covers the parameter type constraints and value range constraints defined in the documentation. For example, if the documentation requires "phone numbers to be 11 digits," but the code only validates "not empty" but not "length" or "number format," the model will determine it as inconsistent. Finally, based on preset output instructions, the model generates JSON-formatted data containing the consistency judgment result (consistency field, valued as true or false) and detailed judgment reasons (reason field, such as "the code lacks validation logic for phone number length"). This structured output can be directly parsed by downstream systems for automatically generating test reports or triggering defect management processes.

[0093] In this embodiment, the dynamic construction mechanism of structured prompt word templates significantly improves the stability and automation level of code logic verification. By deconstructing prompt words and forcing the model to output standard JSON data, inference illusions are effectively suppressed, obstacles to natural language result parsing are eliminated, and automated integration of results is facilitated. Utilizing a large model to accurately analyze complex conditional judgments, assertions, and regular expression logic can identify implicit constraints in documents, thereby discovering logical omissions (such as missing length checks) that are difficult to detect with traditional static scanning, greatly improving the defect detection rate. Finally, the output of verification results containing detailed reasoning provides developers with intuitive repair guidance, achieving left-shift testing and intercepting potential logical defects during the development phase, significantly reducing later repair costs.

[0094] In one embodiment, obtaining a real-time response message by calling a real external interface specifically includes:

[0095] Test requests are forwarded via an API gateway to isolate the test environment from the production environment.

[0096] During the call process, intercept and mask request headers or response fields containing sensitive information to ensure that only de-sensitized messages used for structural comparison are obtained.

[0097] Specifically, when calling real external interfaces, HTTP requests are not sent directly to the production environment URL. Instead, all test requests are directed to a pre-built API gateway (such as a cluster built on Kong, Nginx, or Spring Cloud Gateway). This API gateway acts as a secure isolation boundary between the test and production environments, configured with strict routing rules. When a request is received from the test system, the gateway first verifies the legitimacy of the request source (e.g., by checking specific X-Test-Source request headers), and then forwards the request to the real external interface through a dedicated encrypted channel (such as an mTLS mutual authentication channel). This architecture ensures physical or logical isolation between the test and production networks, preventing test traffic from causing unexpected interference to production operations (e.g., false positives for DDoS attacks). During the call process, the API gateway integrates sensitive information interception and de-identification middleware. When the real interface returns a response message, this middleware performs a real-time scan before the message is returned to the test system. The system has a pre-built rule base for identifying Personally Identifiable Information (PII), including but not limited to regular expressions (for identifying ID card numbers, bank card numbers, and mobile phone numbers) and keyword matching lists (for identifying sensitive fields such as password, token, and secret). Once sensitive data is detected in the Body or Header of the response message, the middleware will immediately perform a blocking operation, such as replacing the mobile phone number with 138****0000 or replacing the token value with [MASKED].

[0098] After the above processing, the message finally transmitted to the second model for semantic comparison is a de-identified message. Since the second model's main task is to verify the structural consistency of the document (e.g., whether fields exist, whether data types are correct, and whether nesting levels match), rather than verifying specific user data values, the de-identification operation does not affect the accuracy of the verification. For example, the main model can still determine that "the phone number field exists and is a string type," thus completing the structural verification while strictly meeting the requirements of data compliance and privacy protection.

[0099] In one embodiment, the step of generating Mock rules and automated test case scripts using the fourth major model specifically includes:

[0100] Based on the response examples in the revised interface documentation, the fourth model is used to infer and extend the generation of Mock rules, which include at least normal response scenarios, abnormal response scenarios, and boundary value scenarios.

[0101] Parse the scenario definitions in the Mock rules and extract the expected response status code, expected response body field value, and expected error message for each scenario;

[0102] Based on the extracted expected information, corresponding assertion logic code is automatically generated. The assertion logic code is used to verify whether the actual test response meets expectations.

[0103] Specifically, the first step involves retrieving the dynamically modified API documentation (VerifiedDoc) from the previous steps and extracting standardized response examples. While the documentation typically provides only a static example of a "success" state (e.g., HTTP 200 OK), the fourth model leverages its powerful semantic reasoning and scenario expansion capabilities to generate multi-dimensional business scenario rules based on this single example. Specifically, the model infers normal response scenarios (e.g., successful returns for users with different permissions), abnormal response scenarios (e.g., 400 errors due to missing parameters, 401 errors due to authentication failure), and boundary value scenarios (e.g., the maximum number of pages in a paginated query, or extremely large numerical inputs) based on parameter types. The model outputs these inference results as structured Mock rule configuration files (e.g., YAML or JSON format), explicitly defining the triggering conditions (Request Matchers) and simulated responses (Response Templates) for each scenario. Subsequently, the parsing engine is activated to reverse-engineer the generated Mock rules. The parsing engine iterates through each scenario definition in the configuration file, extracting the expected behavioral metrics for that scenario. These metrics primarily include the expected response status code, key field values ​​in the response body (such as data.id and data.status), and expected error messages for abnormal scenarios. This step aims to transform the simulated behavior in the mock configuration into verification standards for test cases.

[0104] Based on the extracted expected information, the system automatically constructs the corresponding assertion logic code using a code generation template. The system automatically matches the optimal assertion operator based on the type of the extracted value: for status codes, it generates equality assertions (e.g., `assertresponse.status_code == 200`); for specific business fields, it generates value comparison assertions (e.g., `assertresponse.json().get("code") == 0`); and for ambiguous error messages, it generates inclusion assertions (e.g., `assert "Invalid Parameter" in response.text`). Finally, this assertion logic is encapsulated in automated test scripts (e.g., Python Pytest or Java JUnit scripts). This generation method ensures strict consistency between mock behavior and test assertions, eliminating common assertion omissions or hard-coding errors when manually writing test scripts, achieving accurate verification of "what is mocked is what is tested."

[0105] Furthermore, in one embodiment, generating the Mock service configuration using the fourth major model includes:

[0106] The Mock rules are converted into configuration files that conform to preset specifications. These configuration files can be manually adjusted in an editor. During the manual adjustment process, the syntax of the configuration files is validated in real time.

[0107] Specifically, to balance the efficiency of automated generation with the flexibility of manual intervention, this embodiment introduces a "generation-editing-validation" workflow in the Mock configuration generation stage. After the fourth model inference completes the multi-dimensional Mock rules, instead of storing them in an invisible intermediate format, a serialization engine is used to convert these abstract rules into text configuration files conforming to industry-standard specifications, such as YAML or JSON. This format choice facilitates machine parsing for starting the Mock service while also ensuring good readability, making it easy for testers to understand the rule details. Subsequently, an integrated visual code editor (e.g., built on the Monaco Editor or CodeMirror kernel) is provided in the front-end test management interface. Users can directly view the generated configuration files in this editor and make secondary adjustments according to actual testing needs, such as fine-tuning the Mock return values ​​of specific fields, modifying the simulated network latency (Delay), or adding triggering conditions for specific scenarios. To prevent manual modifications from introducing syntax errors that could cause the Mock service to fail to start, the editor has a built-in real-time syntax validation mechanism. This mechanism is based on predefined schema constraints (such as JSON Schema or YAML Schema) and performs background comparison as the user types the code. Once an indentation error, key-value type mismatch (such as changing an integer field to a string), or illegal character is detected, the editor will immediately mark the error message (such as a red wavy line) at the corresponding line number, forcing the user to fix the syntax problem before saving the configuration. This mechanism ensures that even if the user manually intervenes in the configuration, the file finally delivered to the Mock engine for execution is still syntactically sound and logically compliant, thus guaranteeing the stability of the testing service.

[0108] In one embodiment, the step of generating Mock rules and automated test case scripts using the fourth model further includes:

[0109] The fourth major model is used to analyze the revised interface document to identify multiple related interfaces that have data interaction logic or state dependency relationships.

[0110] Based on the dependencies between the associated interfaces, a Mock rule containing runtime state storage is constructed;

[0111] During the execution of the Mock rule, in response to a request for the first interface in the associated interfaces, the business data in the request is extracted and updated to the runtime state storage;

[0112] In response to a request for the second interface in the associated interfaces, the corresponding business data is retrieved from the runtime state storage based on the request parameters of the second interface, and a response message is constructed.

[0113] Specifically, regarding the step of generating Mock rules in step S106, this embodiment further introduces a stateful Mock service construction mechanism to support the consistency testing of complex business chains. Traditional Mock tools are usually based on stateless static rules, meaning that regardless of previous operations, the response to the same request is always fixed. This makes it impossible to verify business scenarios that depend on context data, such as "create first, then query" or "modify first, then verify". To overcome this limitation, the fourth model can be used to perform deep semantic analysis on the corrected interface documents, automatically identifying the data interaction logic or state dependencies between interfaces. For example, the model will identify that the "user registration interface" (first interface) is a data write operation, while the "user information query interface" (second interface) is a data read operation, and the two are logically related through "user ID" or "phone number".

[0114] Based on the identified dependencies, the fourth model automatically constructs service logic containing runtime state storage when generating mock rules. This storage space is typically implemented as a lightweight in-memory database or a global key-value map, used to temporarily store business entity objects during the lifecycle of the mock service. The generated mock scripts are no longer simple hard-coded returns, but instead contain dynamic data processing logic code.

[0115] Specifically, during operation, when the Mock service receives a request for the first interface (e.g., creating an order), its internal logic intercepts the request, parses the request body (Payload) or URL parameters, extracts key business data (e.g., order amount, product name), and updates this data, along with a system-generated unique identifier (e.g., order number), to the runtime state storage space. Subsequently, when the Mock service receives a request for the second interface (e.g., querying an order), it does not directly return preset dead data. Instead, based on the association key in the request parameters (e.g., order number), it retrieves the corresponding business data from the runtime state storage space in real time. If the retrieval is successful, the system dynamically assembles a response message using the retrieved data, thus returning data completely identical to the "create" operation; if the retrieval fails, it simulates returning a "data does not exist" error response.

[0116] In this embodiment, when generating Mock rules through the fourth model, service logic containing runtime state storage is automatically constructed, thereby giving the Mock service context memory capability, enabling it to realistically simulate the business flow logic of the real backend, thus supporting automated scripts to perform deeper logic verification.

[0117] In one embodiment, after the step of generating Mock rules and automated test case scripts using the fourth major model, the method further includes:

[0118] Execute the automated test case script and monitor the execution status in real time;

[0119] If an assertion failure or runtime exception is captured, the current exception log, the source code of the automated test case script, and the corrected interface documentation are automatically aggregated to build a fault diagnosis context.

[0120] The fault diagnosis context is input into a large model for root cause classification.

[0121] If the root cause is determined to be a script logic defect, then a corrected test case script is generated using the large model and retry execution is triggered.

[0122] If the root cause is determined to be an interface implementation defect, a defect report containing fault location information is generated.

[0123] Specifically, after generating mock rules and automated test case scripts using the fourth major model, an intelligent test execution monitoring and self-healing mechanism is introduced. The system integrates an automated test execution engine (such as a Runner based on Jenkins or GitLab CI) responsible for loading and running the generated test scripts. During execution, the system monitors the execution status of each test case in real time through a listener. When the monitoring system detects an assertion failure or runtime exception, it does not directly mark the task as failed and terminate it, but immediately triggers the fault diagnosis process. The system automatically aggregates three types of key information to construct a fault diagnosis context: first, the current exception log information, including the complete error stack trace and the actual response message; second, the source code of the test case script that caused the error, precisely locating the line of assertion code that failed; and third, the corrected interface documentation fragment upon which the test case is based. This three-dimensional context of "log + code + documentation" provides a complete basis for judgment for the major model. The system then inputs this fault diagnosis context into the fourth major model for root cause analysis. The fourth major model can then perform reasoning based on the contextual logic:

[0124] If the root cause is determined to be a script logic defect (e.g., the large model discovers that the interface documentation allows a status code of 201, but the script assertion hardcodes it as 200; or there is an error in the extraction of the JSON path in the script), the system will instruct the large model to generate a corrected test case code snippet, automatically replacing the erroneous logic in the original script, and immediately triggering a retry of the test case. This process achieves "self-healing" of the test script, correcting false errors caused by generation deviations without manual intervention.

[0125] If the root cause is determined to be an interface implementation defect (e.g., the script logic is completely consistent with the documentation definition, but the actual interface returns a 500 internal error or returns data in a format that does not conform to the agreement), the system confirms that this is a genuine software bug. At this point, the system will automatically extract the fault scene information, generate a defect report containing request parameters, response messages, and a comparison of expected and actual results, and can further automatically push it to a defect management system (such as Jira) via API.

[0126] In the above embodiments, a multi-dimensional fault diagnosis context is constructed by automatically aggregating exception logs, script source code, and interface documentation. A large model is used to achieve accurate root cause classification, effectively identifying and eliminating "false failures" caused by script logic errors, thus preventing testers from wasting time on invalid issues. Furthermore, in the face of non-substantive business failures, unattended self-recovery is achieved, ensuring the continuity and stability of the CI / CD pipeline. For real interface implementation defects, fault scene information is automatically extracted and standardized defect reports are generated. This not only accelerates the process of developers reproducing and locating bugs but also establishes an automated closed loop from problem discovery to feedback, significantly improving the quality and efficiency of software delivery.

[0127] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0128] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0129] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0130] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0131] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0132] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0133] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0134] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0135] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0136] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by 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 memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0137] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet through an Internet service provider).

[0138] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0139] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

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

[0141] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for interface verification and testing based on a large model, characterized in that, The method includes: Obtain the interface document to be tested, parse the interface document using the first major model, extract and generate standardized document structure information, which includes at least request parameter definitions and response examples; Based on the defined request parameters, test request parameters are constructed, and real-time response messages are obtained by calling a real interface. The second major model is used to perform a semantic comparison between the response examples in the document structure information and the real-time response message. If there is a difference, the interface document structure information is updated according to the real-time response message to obtain the corrected interface document. Locate and obtain the backend business logic code fragment corresponding to the interface based on the service identifier of the interface; The third model is used to compare the parameter constraints in the revised interface document with the validation logic in the business logic code snippet; if they are found to be consistent, a logic validation pass result is generated. Based on the revised interface documentation and the logical verification results, the fourth model is used to generate Mock rules and automated test case scripts. The generation of Mock rules and automated test case scripts using the fourth major model includes: The fourth model is based on the business semantic associations between interfaces in the revised interface document, and parses the scenario definitions in the Mock rules to extract the expected status codes and response bodies, generating automated test case scripts containing complete assertion logic.

2. The method according to claim 1, characterized in that, The step of locating and obtaining the backend business logic code fragment corresponding to the interface based on the service identifier of the interface specifically includes: The service identifier is used to query the pre-defined interface code mapping relationship to determine the storage location of the business logic corresponding to the interface; Retrieve the business logic implementation code of the interface from the storage location; Identify and extract code snippets containing parameter validation logic or data processing logic from the business logic implementation code, and use them as the backend business logic code snippets.

3. The method according to claim 1, characterized in that, The step of comparing the parameter constraints in the revised interface document with the validation logic in the business logic code snippet using the third major model specifically includes: Extract the parameter definition information from the revised interface document, as well as the backend business logic code snippets; The parameter definition information is combined with the backend business logic code snippet to construct a consistency verification prompt word; The consistency verification prompt is input into the third model, which analyzes the logical statements in the backend business logic code snippet and outputs the consistency judgment result between the code logic and the document definition.

4. The method according to claim 1, characterized in that, The process of obtaining real-time response messages by calling the actual interface specifically includes: Test requests are forwarded via an API gateway to isolate the test environment from the production environment. During the call process, intercept and mask request headers or response fields containing sensitive information to ensure that only de-sensitized messages used for structural comparison are obtained.

5. The method according to claim 1, characterized in that, The steps for generating Mock rules and automated test case scripts using the fourth major model specifically include: Based on the response examples in the revised interface documentation, the fourth model is used to infer and extend the generation of Mock rules, which include at least normal response scenarios, abnormal response scenarios, and boundary value scenarios. Parse the scenario definitions in the Mock rules and extract the expected response status code, expected response body field value, and expected error message for each scenario; Based on the extracted expected information, corresponding assertion logic code is automatically generated. The assertion logic code is used to verify whether the actual test response meets expectations.

6. The method according to claim 1, characterized in that, The steps for generating Mock rules and automated test case scripts using the fourth major model also include: The fourth major model is used to analyze the revised interface document to identify multiple related interfaces that have data interaction logic or state dependency relationships. Based on the dependencies between the associated interfaces, a Mock rule containing runtime state storage is constructed; During the execution of the Mock rule, in response to a request for the first interface in the associated interfaces, the business data in the request is extracted and updated to the runtime state storage; In response to a request for the second interface in the associated interfaces, the corresponding business data is retrieved from the runtime state storage based on the request parameters of the second interface, and a response message is constructed.

7. The method according to claim 1, characterized in that, Following the step of generating Mock rules and automated test case scripts using the fourth major model, the method further includes: Execute the automated test case script and monitor the execution status in real time; If an assertion failure or runtime exception is captured, the current exception log, the source code of the automated test case script, and the corrected interface documentation are automatically aggregated to build a fault diagnosis context. The fault diagnosis context is input into the fourth major model for root cause classification; If the root cause is determined to be a script logic defect, then the fourth major model is used to generate a corrected test case script and trigger a retry execution. If the root cause is determined to be an interface implementation defect, a defect report containing fault location information is generated.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images