Interface testing method and device, and electronic equipment

Abstract

The application discloses an interface testing method and device and electronic equipment. The method comprises the following steps: converting an unstructured interface document into structured interface information, wherein the interface document comprises at least one interface and an interface example corresponding to each interface; analyzing a request in an interface example corresponding to a to-be-tested interface according to the interface information to obtain a request analysis result, wherein the to-be-tested interface is any one of the at least one interface; generating a request object according to the interface information and the request analysis result; generating a test case and a corresponding assertion according to the request object; and testing the to-be-tested interface according to the test case and the assertion to obtain a test result. The application realizes automatic analysis of interface documents of different sources and different formats, automatically generates test cases and assertions, improves test reliability, improves test efficiency in complex test scenarios, and is less prone to errors.

Description

Technical Field

[0001] This application belongs to the field of intelligent testing technology, and in particular relates to an interface testing method, apparatus and electronic device. Background Technology

[0002] Social e-commerce encompasses complex interfaces related to products, inventory, orders, after-sales service, payment, refunds, promotions, events, influencer content, live streaming, risk control, and third-party service providers, with inconsistent sources and formats for the interface documentation.

[0003] In related technologies, when testing interfaces, information is extracted from the interface documentation using "regular expressions + keyword matching" and tests are conducted using manually written test templates. However, if the document format changes (for example, by adding fields such as live streaming orders, cross-store discounts, or risk control grayscale), the information extraction will fail, resulting in low test reliability. Summary of the Invention

[0004] The purpose of this application is to provide an interface testing method, apparatus, and electronic device to solve the problem of low testing reliability in related technologies.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide an interface testing method, comprising: converting an unstructured interface document into structured interface information, wherein the interface document includes at least one interface and an interface example corresponding to each interface; parsing a request in the interface example corresponding to the interface to be tested according to the interface information to obtain a request parsing result; wherein the interface to be tested is any one of the at least one interface; generating a request object according to the interface information and the request parsing result; generating test cases and corresponding assertions according to the request object; and testing the interface to be tested according to the test cases and the assertions to obtain a test result.

[0006] Secondly, embodiments of this application provide an interface testing apparatus, comprising: a conversion module for converting unstructured interface documents into structured interface information, wherein the interface documents include at least one interface and an interface example corresponding to each interface; a parsing module for parsing requests in the interface examples corresponding to the interface to be tested based on the interface information, thereby obtaining a request parsing result; wherein the interface to be tested is any one of the at least one interface; a first generation module for generating a request object based on the interface information and the request parsing result; a second generation module for generating test cases and corresponding assertions based on the request object; and a testing module for testing the interface to be tested based on the test cases and the assertions, thereby obtaining a test result.

[0007] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect of this application.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: In this embodiment of the application, unstructured interface documents are converted into structured interface information during interface testing. The interface document includes at least one interface and an interface example corresponding to each interface. The requests in the interface examples corresponding to the interface to be tested are parsed based on the interface information to obtain request parsing results. A request object is generated based on the interface information and the request parsing results. Test cases and corresponding assertions are generated based on the request object. The interface to be tested is then tested based on the test cases and assertions to obtain test results. This embodiment of the application achieves automatic parsing of interface documents from different sources and in different formats, and automatically generates test cases and assertions, improving test reliability. It also enhances testing efficiency in complex testing scenarios and reduces the likelihood of errors. Attached Figure Description

[0009] 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: Figure 1 A flowchart illustrating an interface testing method provided in one embodiment of this application; Figure 2 A flowchart illustrating batch testing and concurrent throttling provided for one embodiment of this application; Figure 3 A schematic diagram of the overall process of an interface testing method provided for another embodiment of this application; Figure 4 A schematic diagram of an interface testing device provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0010] 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.

[0011] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, "and / or" in this application indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship. It should be noted that all data involved in this application was obtained with the user's authorization.

[0012] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0013] Figure 1 This is a flowchart illustrating an interface testing method provided in one embodiment of this application. Figure 1 As shown, the interface testing method of this application embodiment may specifically include the following steps: S101, convert the unstructured interface document into structured interface information, wherein the interface document includes at least one interface and an interface example corresponding to each interface.

[0014] In this embodiment, the interface testing method is implemented by an interface testing device, which can be installed in an electronic device. This electronic device can be a terminal device or a server. The terminal device can be a mobile phone, tablet computer, desktop computer, laptop, in-vehicle device, etc.; the server can be a standalone server or a server cluster composed of multiple servers. In the social e-commerce field, this interface testing device can be installed in a social e-commerce business platform.

[0015] It receives unstructured interface documents from various sources and formats, such as PDF, Word, Markdown, operation wiki, and platform announcements, uploaded by users. These documents include Application Programming Interface (API) documents.

[0016] By parsing unstructured API documents, they are transformed into structured API information, such as API Info data structures, thus achieving automatic conversion from unstructured to structured API information. API Info refers to the API's metadata, which describes the API's basic attributes.

[0017] The interface documentation may include, but is not limited to, at least one interface and an interface example for each interface. The at least one interface in the interface documentation may be at least one interface of a device, or all interfaces of all devices.

[0018] It's worth noting that after receiving unstructured API documentation uploaded by users, the system can perform integrity checks on the documentation, persist it, register a corresponding file identifier with a workflow tool (such as an LLM large model workflow tool), and trigger a document parsing workflow containing the LLM large model based on that file identifier. The document parsing workflow integrates a terminology dictionary from the social e-commerce domain to parse the content of the API documentation.

[0019] As a feasible implementation method, the step S101 of "converting unstructured interface documents into structured interface information" may specifically include the following steps: performing semantic parsing on the interface documents, extracting the interface description from the interface documents, and identifying the business domain corresponding to the interface documents and the required parameters in the interface documents; and standardizing the interface description, business domain, and required parameters into structured interface information.

[0020] Specifically, the document parsing workflow performs semantic parsing on the content of the interface document, extracting the interface description (such as interface identifier, interface function description, request method, request Uniform Resource Identifier (URL), parameter definition, and response structure (i.e., return value structure, etc.) from the interface document, and identifying the corresponding business domain (such as product, inventory, order, after-sales, payment, refund, promotion, activity, influencer content, live streaming, and risk control, etc.) of the interface, and annotating the interface with business domains. It can also identify the required parameters in the interface document (such as minimum stock keeping unit (SKU), activity ID, influencer ID, live streaming ID, store ID, trace ID, and product main image or video file parameters, etc.), and standardize the above interface description, business domain, and required parameters into structured interface information.

[0021] Structured interface information may include, but is not limited to, the following: interface identifier, request method, request URL, request header definition, request body structure, response structure, classification labeling information of the business domain to which the interface belongs, and the set of required parameters for the interface.

[0022] S102, based on the interface information, parse the request in the interface example corresponding to the interface to be tested, and obtain the request parsing result.

[0023] In this embodiment, the requests (e.g., cURL requests) in the interface examples corresponding to the interface to be tested in the interface document are parsed based on the structured interface information obtained in step S101 to obtain the request parsing results. Multiple request formats, such as JSON, Form-Data, and multipart, are supported.

[0024] As a feasible implementation, step S102 may specifically include the following steps: parsing the request in the interface example of the interface to be tested according to the interface information, extracting the request information in the interface example of the interface to be tested and identifying the file parameters in the interface example of the interface to be tested to form a request parsing result.

[0025] Specifically, the structured interface information obtained in step S101 can be used to parse the requests in the interface example corresponding to the interface to be tested, extract the request information (such as HTTP request method, request URL, query parameters, request header and request body content) in the interface example of the interface to be tested, and identify the file parameters (such as binary parameters such as product main image or video) in the interface example of the interface to be tested.

[0026] S103, Generate a request object based on the interface information and the request parsing result.

[0027] In this embodiment of the application, a structured executable request object, such as an HTTP request object, is generated based on the interface information obtained in step S101 and the request parsing result obtained in step S102.

[0028] As a feasible implementation method, step S103 may specifically include the following steps: performing parameter fusion processing and parameter completion processing sequentially based on interface information and request parsing results to obtain fused parameters; extracting interface address, authentication information and call constraints based on interface information and request parsing results; constructing a request object, which includes fused parameters, interface address, authentication information and call constraints.

[0029] Specifically, a parameter fusion engine can be established based on the interface information obtained in step S101 and the request parsing result obtained in step S102. The parameter fusion engine performs parameter fusion processing on the interface information and request parsing result according to the priority rule of "user input first, document default second, and example cURL last," and automatically completes parameters such as dynamic tokens and timestamps to obtain fused parameters. The fused parameters are used to represent the set of interface request parameters processed by the parameter fusion engine, and may include query parameters, request body parameters, and file parameters. Their parameter values ​​are obtained by fusing user input, default parameters defined in the interface document, and parameters in the interface example according to a preset priority rule.

[0030] It can also extract the interface address, authentication information, and call constraints based on the interface information and request parsing results. Among these: The interface address is used to represent the request method and the corresponding request URL of the interface. The request method and request URL are derived from the interface definition information in the interface information obtained by parsing the interface documentation or the example request URL in the request parsing result of the interface example.

[0031] Authentication information is used to characterize the request fields corresponding to the interface authentication mechanism. Specifically, it may include the access token field and gateway signature field required by Open Authorization 2.0 (OAuth 2.0) or JWT (JSON Web Token) authentication mechanisms. These fields originate from the interface authentication description information parsed from the interface documentation and the cURL request content in the request parsing result of the interface example. JWT is an open standard (RFC 7519) for transmitting information over a network. It is a lightweight, self-contained token commonly used to transmit identity information between clients and servers.

[0032] Call constraints are used to characterize the constraints that must be followed during the API call process. Specifically, they may include the rate limiting strategy and risk control constraints corresponding to the API. The rate limiting strategy and risk control constraints are derived from the description information of API call constraints in the API information obtained by parsing the API documentation and the constraint characteristics reflected in the request parsing results of the API example.

[0033] S104, Generate test cases and corresponding assertions based on the request object.

[0034] In this embodiment, test cases are generated based on the structured HTTP request object generated in step S103. It should be noted that parameter combination strategies can cover required parameters, optional parameters, enumerated boundary values, numerical boundary values, and multi-format, multi-size test scenarios for file upload interfaces, generating test cases for abnormal scenarios such as authentication failure and rate limiting triggering. Corresponding assertions are configured for each test case, thus forming a set of directly executable interface test cases.

[0035] As a feasible implementation, the above step of "generating assertions corresponding to test cases based on the request object" may specifically include the following steps: generating a four-level assertion chain corresponding to the test cases based on the request object. The four-level assertion chain includes basic assertions, structural assertions, business assertions, and security assertions. Specifically: basic assertions are used to verify the response status code and time consumption threshold. Structural assertions are used to verify the existence and type of JSON fields. Business assertions are used to verify that inventory is not less than zero, price is not less than zero, order and payment status are consistent, promotion validity period, number of live stream viewers, and risk control interception flags. Security assertions are used to verify the anonymization of sensitive information and permission isolation.

[0036] S105, test the interface to be tested according to the test cases and assertions, and obtain the test results.

[0037] In this embodiment of the application, the interface to be tested can be tested individually or in batches based on the test cases generated in step S104; the actual response of the interface to be tested is verified against the expected rules based on assertions to obtain the test results.

[0038] It should be noted that failed test cases can also be categorized according to types such as missing parameters, authentication failure, rate limiting triggering, risk control interception, data constraint violation, server-side anomaly, and network timeout, generating structured test results that include test case identifier, execution status, response status code, response time, and assertion failure details.

[0039] Furthermore, the interface testing method of this application embodiment may also include the following steps: during the testing process of the interface to be tested, the test requests in the requests of the interface example of the interface to be tested are scheduled based on the preset maximum concurrency. Specifically, during the testing of the interface to be tested, test requests can be scheduled by initializing a concurrency pool and configuring the maximum concurrency to ensure that the number of test requests executed at the same time does not exceed the maximum concurrency.

[0040] Furthermore, the interface testing method in this application embodiment may also include the following steps: during the testing process of the interface to be tested, when rate limiting is detected, an exponential backoff retry mechanism is triggered to dynamically adjust the interval of test requests.

[0041] Specifically, during the testing of the interface to be tested, the HTTP 429 rate limiting response can be monitored in real time, and an exponential backoff retry mechanism can be triggered when rate limiting is detected to dynamically adjust the interval of test requests, so that the interface test can adaptively throttle within the preset query-per-second (QPS) range to avoid triggering online risk control strategies.

[0042] In addition, the interface testing method of this application embodiment may also include the following steps of generating and storing test reports: performing statistical analysis on the testing process of the interface to be tested based on the test results to obtain statistical analysis results; generating a test report based on the statistical analysis results; and storing the test report.

[0043] Specifically, based on the structured test results, the following statistical analysis can be performed on the testing process of the interface to be tested: calculate the total number of interface tests, test pass rate, average response time and Top-N slow interfaces, and classify and statistically analyze the test results according to the reasons for failure. At the same time, statistical analysis of interface test coverage and pass rate can be performed by business domain, and failed interfaces can be clustered according to URL, parameters and error type to assist in root cause location.

[0044] Based on statistical analysis results, it can generate text-format test reports for manual review, as well as JSON-format test reports for continuous integration or continuous delivery system calls. Test reports can also be persistently stored in a report repository to record generation time, test batch identifier, and execution environment, thus forming a traceable interface testing audit chain and achieving automatic closed-loop of the interface testing process.

[0045] Figure 2 This is a flowchart illustrating the batch testing and concurrent throttling process in an embodiment of this application, as shown below. Figure 2 As shown, the specific steps include: S201, Generate a batch test queue.

[0046] S202, initialize the concurrent pool and configure the maximum number of concurrent connections.

[0047] S203, set the throttling strategy.

[0048] S204, invokes an HTTP test request.

[0049] S205, Determine if rate limiting is detected. If yes, proceed to step S206. If no, proceed to step S207.

[0050] S206, trigger the exponential backoff retry mechanism. And continue to execute step S204.

[0051] S207, Statistical analysis of the testing process based on the test results.

[0052] S208 generates a test report based on the statistical analysis results.

[0053] To clearly describe the flow of the interface testing method in the embodiments of this application, the following is combined with... Figure 3 The overall flow of the interface testing method according to the embodiments of this application is described in detail. For example... Figure 3 As shown, the interface testing method of this application embodiment includes the following steps: S301, Users select to upload API documentation to the front end.

[0054] S302, the frontend sends the API documentation to the interface layer.

[0055] S303, the interface layer saves and validates the API documentation. If the file format is valid, proceed to step S304. If the file format is invalid, proceed to step S319.

[0056] S304, the service layer uploads the API documentation to the workflow and registers the corresponding file identifier.

[0057] S305, the service layer runs the workflow. If the workflow executes successfully, proceed to step S306. If the workflow fails, proceed to step S315.

[0058] S306, the workflow returns the parsed results to the service layer.

[0059] S307, the service layer converts the parsed results into structured interface information.

[0060] S308, the service layer returns an API list to the interface layer, which includes structured interface information for multiple interfaces.

[0061] S309, the interface layer returns the API list to the front end.

[0062] S310: The frontend returns an API list to the user.

[0063] S311, the user selects an interface for testing.

[0064] S312, the frontend sends the test request to the test interface.

[0065] S313, the test interface returns the test results to the front end.

[0066] S314, the front end displays the test results to the user.

[0067] S315, the workflow returns an error message to the service layer.

[0068] S316, the service layer passes error information to the interface layer.

[0069] S317, the interface layer returns an error status to the front end.

[0070] S318, the front end displays error messages to the user.

[0071] S319, the service layer returned a format error to the interface layer.

[0072] S320, the interface layer returns a 400 error to the front end.

[0073] S321, the front end displays a formatting error message to the user.

[0074] In summary, the interface testing method of this application automatically parses interface documents from different sources and in different formats, and automatically generates test cases and assertions, improving test reliability. It also enhances testing efficiency in complex testing scenarios and is less prone to errors. The LLM workflow, combined with a social e-commerce terminology dictionary, achieves zero-rule, highly robust extraction of unstructured documents, maintaining a recall rate of over 96% even after format changes. Through parameter fusion and parameter completion, it automatically integrates user input parameters, dynamic tokens, and timestamps, improving test coverage. A four-level assertion chain covers over 95% of high-frequency defect scenarios, further improving test coverage. The concurrency pool and backoff retry mechanism adaptively throttle within 10,000 QPS, ensuring test speed while avoiding triggering online risk control strategies, resulting in a test noise rate of <1%. The test report is structured and auditable, facilitating problem localization and retesting.

[0075] Figure 4 This is a schematic diagram of an interface testing device provided in one embodiment of this application. Figure 4 As shown, the interface testing device 400 of this application embodiment may specifically include: a conversion module 401, a parsing module 402, a first generation module 403, a second generation module 404, and a testing module 405. Wherein: The conversion module 401 is used to convert unstructured interface documents into structured interface information. The interface documents include at least one interface and an interface example corresponding to each interface.

[0076] The parsing module 402 is used to parse the request in the interface example corresponding to the interface to be tested based on the interface information, and obtain the request parsing result; the interface to be tested is any one of at least one interface.

[0077] The first generation module 403 is used to generate a request object based on the interface information and the request parsing result.

[0078] The second generation module 404 is used to generate test cases and corresponding assertions based on the request object.

[0079] Test module 405 is used to test the interface to be tested based on test cases and assertions, and obtain test results.

[0080] In this embodiment of the application, the specific process by which each module and unit in the interface testing device implements its function can be found in the relevant descriptions in the above-mentioned interface testing method embodiments, and will not be repeated here.

[0081] In summary, the interface testing device of this application embodiment automatically parses interface documents from different sources and in different formats, and automatically generates test cases and assertions, improving test reliability. It also enhances testing efficiency in complex testing scenarios and is less prone to errors. The LLM workflow, combined with a social e-commerce terminology dictionary, achieves zero-rule, highly robust extraction of unstructured documents, maintaining a recall rate of over 96% even after format changes. Through parameter fusion and parameter completion, it automatically integrates user input parameters, dynamic tokens, and timestamps, improving test coverage. A four-level assertion chain covers over 95% of high-frequency defect scenarios, further improving test coverage. The concurrency pool and backoff retry mechanism adaptively throttle within 10,000 QPS, ensuring testing speed while avoiding triggering online risk control strategies, resulting in a test noise rate of <1%. The test report is structured and auditable, facilitating problem localization and retesting.

[0082] This application also provides an electronic device. For example... Figure 5 As shown, the electronic device 500 includes: a processor 501, a memory 502, and a program or instructions stored in the memory 502 and executable on the processor 501. When the program or instructions are executed by the processor 501, they implement the steps of the interface testing method as described in any of the above embodiments.

[0083] The electronic device in this application embodiment automatically parses interface documents from different sources and in different formats, and automatically generates test cases and assertions, improving test reliability. It also enhances testing efficiency in complex testing scenarios and reduces the likelihood of errors. The LLM workflow, combined with a social e-commerce terminology dictionary, achieves zero-rule, highly robust extraction of unstructured documents, maintaining a recall rate of over 96% even after format changes. Through parameter fusion and parameter completion, it automatically integrates user input parameters, dynamic tokens, and timestamps, improving test coverage. A four-level assertion chain covers over 95% of high-frequency defect scenarios, further improving test coverage. The concurrency pool and backoff retry mechanism adaptively throttle within 10,000 QPS, ensuring test speed while avoiding triggering online risk control strategies, resulting in a test noise rate of <1%. The test report is structured and auditable, facilitating problem localization and retesting.

[0084] This application also proposes a readable storage medium storing one or more computer programs, the one or more computer programs including instructions, which, when executed by a processor in an electronic device including multiple applications, enable the processor in the electronic device to perform the various steps of the above-described interface testing method embodiments.

[0085] The readable storage medium in this application embodiment enables automatic parsing of interface documents from different sources and in different formats, and automatically generates test cases and assertions, improving test reliability and efficiency in complex testing scenarios, while also reducing the likelihood of errors. The LLM workflow, combined with a social e-commerce terminology dictionary, achieves zero-rule, highly robust extraction of unstructured documents, maintaining a recall rate of over 96% even after format changes. Through parameter fusion and parameter completion, it automatically integrates user input parameters, dynamic tokens, and timestamps, improving test coverage. A four-level assertion chain covers over 95% of high-frequency defect scenarios, further enhancing test coverage. The concurrency pool and backoff retry mechanism adaptively throttle within 10,000 QPS, ensuring test speed while avoiding triggering online risk control strategies, resulting in a test noise rate of <1%. The test report is structured and auditable, facilitating problem localization and retesting.

[0086] It should be understood that the training and prediction processes of the AI ​​models involved in the various embodiments of this specification all adhere to multiple legal and compliant principles, including legal data sources, compliant data content, compliant data governance, compliant training objectives and schemes, compliant training processes, compliant training environments and tools, and compliant ethical verification of training results, and comply with the requirements of Article 5 of the Patent Law. Among them: Data source legitimacy: All datasets used for AI model training were obtained through legal means, covering three categories: publicly authorized data, data authorized by partners, and self-collected compliant data. Publicly authorized data comes from compliant data sources following open-source licenses such as Apache 2.0, with complete copyright attribution and authorization scope clearly marked, and no unauthorized open-source code or data reuse. Data authorized by partners has been subject to formal data usage agreements, clearly defining the scope, duration, and confidentiality obligations, and possessing a complete authorization chain. For self-collected data involving personal information, strict informed consent procedures have been followed, and anonymization processes (including but not limited to field masking, feature anonymization, and differential privacy technology applications) have been implemented to remove personally identifiable information, fully complying with the requirements of relevant laws and regulations such as the "Interim Measures for the Administration of Generative Artificial Intelligence Services" and the "Personal Information Protection Law."

[0087] Data content compliance: The AI ​​model's dataset undergoes multiple screenings and cleaning processes to remove all content that may violate social morality or harm public interests, and also excludes any instances of illegal acquisition or use of genetic resources. For data in sensitive fields (such as healthcare and finance), an additional privacy-preserving computation module (including federated learning and secure multi-party computation technologies) ensures that the data is "usable but not visible," avoiding compliance risks during the original data transmission process and ensuring that the data application scenarios and uses comply with public order and good morals and industry regulatory requirements.

[0088] Data governance norms: A complete data traceability system is established during the AI ​​model training process to automatically record the source, collection time, annotation process, cleaning rules, and permission allocation of training data, generating traceable compliance reports to ensure that the data is verifiable throughout its entire lifecycle. The dataset annotation process for AI models is completed by a professional human R&D team, clearly defining the proportion of human creative contributions and avoiding reliance on AI-generated data that has not undergone substantial human modification, thus meeting the examination requirements for "human main contributions" in AI patent applications.

[0089] Training objectives and plans are compliant: The AI ​​model training focuses on semantic parsing, and the training scheme and final output do not violate any mandatory provisions of laws or administrative regulations, do not harm the public interest or the legitimate rights and interests of others, and do not pose any potential risk of being used for illegal activities, infringing on privacy, or disrupting public safety. It strictly adheres to the ethical principle of "intelligent for good".

[0090] Training process compliance: A closed-loop training framework is adopted to ensure compliance and controllability of the training process. The specific process is as follows: First, training samples are obtained through compliant data sources. After the aforementioned data cleaning and desensitization, they are input into the neural network model to generate preliminary training results. Second, an expert system is introduced to verify the preliminary results. Based on preset rules and human expert experience, the feasibility of the results is evaluated, and outputs that may pose ethical risks or compliance hazards are corrected (such as removing decision-making logic that violates public order and good morals, and adjusting model parameters that do not comply with safety regulations). Finally, the loss function weights are dynamically optimized based on expert system feedback to strengthen the model's learning of compliant results, avoid overfitting errors or non-compliant labels, and form a closed-loop control of "data input - model training - expert verification - parameter optimization - result feedback" to ensure that the entire training process complies with A5 ethical review requirements.

[0091] Training environment and tool compliance: AI model training is implemented using nationally licensed chips and a compliant training platform. All open-source frameworks and components used in the training process have obtained their corresponding licenses, and copyright statements and patent citation information are fully retained, with no instances of infringement or reuse. The training environment is built using virtual devices (containers / virtual machines) with fixed random seeds and initial parameter configurations to ensure the reproducibility of the training process. Furthermore, through access control and operation log recording, risks such as data leakage and parameter tampering during training are prevented, ensuring the security and compliance of the training process.

[0092] Training results ethical verification compliance: After the model is trained, it undergoes additional third-party ethical compliance assessment and algorithm filing review to verify that the model output does not violate social morality or harm public interests. For potentially sensitive scenarios (such as public services and intelligent decision-making), a special result verification mechanism is established to ensure that the model always complies with Article 5 of the Patent Law and relevant laws and regulations in practical applications.

[0093] In summary, the data and training process used in the AI ​​model of this specification strictly comply with the relevant provisions of Article 5 of the Patent Law and the Patent Examination Guidelines (2023 Edition), and there are no violations of laws, social ethics, public interests, or illegal use of genetic resources. It fully meets the compliance requirements for patent authorization.

[0094] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0095] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0096] 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-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0097] 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.

[0098] 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.

[0099] 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.

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

[0101] 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.

[0102] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change 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 versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic 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.

[0103] 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.

[0104] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0105] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0106] 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 testing method, characterized in that, include: Convert unstructured interface documents into structured interface information, wherein the interface document includes at least one interface and an interface example corresponding to each interface; Based on the interface information, the request in the interface example corresponding to the interface to be tested is parsed to obtain the request parsing result; The interface to be tested is any one of the at least one interfaces; A request object is generated based on the interface information and the request parsing result; Generate test cases and corresponding assertions based on the requested object; The interface to be tested is tested according to the test cases and assertions, and the test results are obtained.

2. The method according to claim 1, characterized in that, The process of converting unstructured interface documents into structured interface information includes: The interface document is semantically parsed, and the interface description in the interface document is extracted. The business domain corresponding to the interface document and the required parameters in the interface document are also identified. The interface description, the business domain, and the required parameters are standardized into structured interface information.

3. The method according to claim 1, characterized in that, The step of parsing the request in the interface example corresponding to the interface to be tested based on the interface information to obtain the request parsing result includes: Based on the interface information, the requests in the interface example of the interface to be tested are parsed, and the request information in the interface example of the interface to be tested and the file parameters in the interface example of the interface to be tested are identified to form the request parsing result.

4. The method according to claim 1, characterized in that, The step of generating a request object based on the interface information and the request parsing result includes: Based on the interface information and the request parsing result, parameter fusion processing and parameter completion processing are performed sequentially to obtain fused parameters; Based on the interface information and the request parsing result, extract the interface address, authentication information and call constraints; Construct the request object, which includes the fusion parameters, the interface address, the authentication information, and the call constraints.

5. The method according to claim 1, characterized in that, Generate assertions corresponding to the test case based on the request object, including: A four-level assertion chain corresponding to the test case is generated based on the request object. The four-level assertion chain includes basic assertions, structural assertions, business assertions, and security assertions.

6. The method according to claim 1, characterized in that, The step of testing the interface to be tested according to the test cases and the assertions to obtain test results includes: Perform single-interface testing or batch interface testing on the interface to be tested according to the test cases. The test results are obtained by verifying the actual response of the interface under test against the expected rules based on the assertion.

7. The method according to claim 6, characterized in that, Also includes: During the testing process of the interface to be tested, test requests in the requests of the interface example of the interface to be tested are scheduled based on the preset maximum concurrency. And / or, During the testing of the interface to be tested, when rate limiting is detected, an exponential backoff retry mechanism is triggered to dynamically adjust the interval of the test requests.

8. The method according to claim 1, characterized in that, Also includes: Based on the test results, the testing process of the interface to be tested is statistically analyzed to obtain the statistical analysis results; A test report is generated based on the statistical analysis results; Store the test report.

9. An interface testing device, characterized in that, include: A conversion module is used to convert unstructured interface documents into structured interface information, wherein the interface document includes at least one interface and an interface example corresponding to each interface; The parsing module is used to parse the requests in the interface example corresponding to the interface to be tested based on the interface information, and obtain the request parsing result; The interface to be tested is any one of the at least one interfaces; The first generation module is used to generate a request object based on the interface information and the request parsing result; The second generation module is used to generate test cases and corresponding assertions based on the request object; The testing module is used to test the interface to be tested according to the test cases and the assertions, and obtain the test results.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in any one of claims 1-8.

Images