Interface testing method and device and electronic equipment

Abstract

The invention provides an interface testing method and device and electronic equipment, and relates to the technical field of computers, in particular to the technical fields of artificial intelligence, natural languages, large models, deep learning and the like. According to the specific implementation scheme, interface test requirement information and an interface document of a to-be-tested interface are obtained; wherein the interface document records interface information; according to the interface information, determining a corresponding target knowledge point from a pre-established application programming interface (API) knowledge point library; wherein the target knowledge point comprises a target historical test case for code reconstruction and a target historical test point, and the target historical test point is generated by adopting a large language model (LLM) based on the target historical test case; based on the interface test demand information, the target knowledge point and the interface document, a large language model LLM is adopted to generate a test case of the to-be-tested interface; and executing the test case of the to-be-tested interface to obtain a test result of the to-be-tested interface.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of artificial intelligence, natural language processing, large models, and deep learning, and especially to an interface testing method, apparatus, and electronic device. Background Technology

[0002] Interface test cases are the core of software testing. They systematically cover various input scenarios and boundary conditions of the interface, proactively identifying potential logical errors, parameter validation defects, or exception handling vulnerabilities. This ensures that the interface functionality meets the expectations of the requirements document, while also verifying its stability, compatibility, and performance, ultimately guaranteeing the reliability of the entire system and the user experience. However, when testing interfaces, the generation of test cases still suffers from poor quality. Summary of the Invention

[0003] This disclosure provides an interface testing method, apparatus, and electronic device.

[0004] According to one aspect of this disclosure, an interface testing method is provided, the method comprising: obtaining interface testing requirement information and interface documentation for an interface to be tested; wherein the interface documentation records interface information; determining corresponding target knowledge points from a pre-established application programming interface (API) knowledge point library based on the interface information; wherein the target knowledge points include target historical test cases and target historical test points for code reconstruction, the target historical test points being generated using a Large Language Model (LLM) based on the target historical test cases; generating test cases for the interface to be tested using the LLM based on the interface testing requirement information, the target knowledge points, and the interface documentation; and executing the test cases for the interface to be tested to obtain test results for the interface to be tested.

[0005] According to another aspect of this disclosure, an interface testing apparatus is provided, the apparatus comprising: an acquisition module, configured to acquire interface testing requirement information and interface documentation of an interface to be tested; wherein the interface documentation records interface information; a determination module, configured to determine corresponding target knowledge points from a pre-established application programming interface (API) knowledge point library based on the interface information; wherein the target knowledge points include target historical test cases for code reconstruction and target historical test points, the target historical test points being generated based on the target historical test cases using a Large Language Model (LLM); a generation module, configured to generate test cases for the interface to be tested using the LLM based on the interface testing requirement information, the target knowledge points, and the interface documentation; and an execution module, configured to execute the test cases for the interface to be tested to obtain test results for the interface to be tested.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the interface testing method proposed above in this disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided that stores computer instructions for causing a computer to execute the interface testing method proposed above in this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the interface testing method proposed above in this disclosure.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a schematic diagram based on the first embodiment of the present disclosure; Figure 2 This is a schematic diagram according to the second embodiment of the present disclosure; Figure 3 This is a schematic diagram according to the third embodiment of the present disclosure; Figure 4 This is a schematic diagram of the intelligent testing platform provided in this disclosure; Figure 5 This is a schematic diagram according to the fourth embodiment of the present disclosure; Figure 6 This is a block diagram of an electronic device used to implement the interface testing method of the embodiments of this disclosure. Detailed Implementation

[0011] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0012] In related technologies, information retrieval techniques are typically used when generating test cases during the interface testing process. Specifically, vectorization techniques are used to convert user input and content from the knowledge base into vector form. Then, similarity calculations are performed to identify the most relevant knowledge fragments. Next, these retrieved relevant knowledge fragments are used as contextual information and combined with the user input to construct an enhanced input context. This context serves as the input to the generated test case model, thereby improving the accuracy of the generated test cases.

[0013] However, this RAG (Retrieval-Augmented Generation)-based test case generation method faces numerous challenges when applied to building RAG indexes for relevant test codebases (such as QA test codebases). Test codebases typically employ a layered architecture, encompassing a lower-level framework layer (providing basic support for system operation), a tool layer (encapsulating common functions and reusable components), and a test case layer (describing specific test scenarios and assertion logic). Complex dependencies and calling relationships exist between these layers. In this context, a single code slicing method struggles to comprehensively capture contextual information, potentially leading to test cases lacking executability. Furthermore, test point information is often scattered across different modules of the test codebase; simply extracting this information in isolation makes it difficult to form complete and effective test knowledge, which significantly limits the effectiveness of automated test case generation.

[0014] To address at least one of the aforementioned problems, this disclosure proposes an interface testing method, apparatus, and electronic device.

[0015] This disclosure presents an interface testing method, apparatus, and electronic device.

[0016] Figure 1 This is a schematic diagram based on the first embodiment of the present disclosure. It should be noted that the interface testing method of the present disclosure can be applied to an interface testing device, which can be configured in an electronic device so that the electronic device can perform interface testing functions.

[0017] Among them, electronic devices can be any device with computing capabilities, such as personal computers (PCs), mobile terminals, servers, etc. Mobile terminals can be, for example, in-vehicle devices, mobile phones, tablets, personal digital assistants, wearable devices, smart speakers, servers, server clusters, and other hardware devices with various operating systems, touch screens and / or displays.

[0018] The interface testing device can also be software within an electronic device, such as resource recommendation software. The following embodiments use an electronic device as an example for illustration.

[0019] like Figure 1 As shown, this interface testing method may include the following steps: Step 101: Obtain the interface test requirements information and interface documentation for the interface to be tested; the interface documentation records the interface information.

[0020] The interface to be tested can be used to indicate the software interface whose functionality, performance, and security need to be verified, such as an API interface (e.g., RESTful API, gRPC interface, HTTP interface, etc.).

[0021] It should be noted that the number of interfaces to be tested can be one or more, and this disclosure does not impose any restrictions on this.

[0022] Among them, the interface testing requirements information can be used to indicate a set of detailed information on the verification requirements and judgment criteria that the interface to be tested needs to meet in terms of functionality, performance, security, reliability, and other dimensions.

[0023] The interface documentation specifies the requirements and format for calling the interface, and may contain interface information, including but not limited to: interface name, interface path, interface version number, interface type, request method, request header, request parameters (including parameters in the request body), return parameter description (including the return structure), etc.

[0024] In this embodiment of the disclosure, interface testing requirement information of the interface to be tested can be obtained. For example, interface testing requirement information can be obtained in response to user (e.g., tester) input operations; wherein, the forms of input operations include, but are not limited to: keyboard input, voice input, file upload / import, touch screen input, etc.

[0025] In this embodiment of the disclosure, the interface documentation for the interface to be tested can be obtained. For example, developers can upload the completed interface documentation to the same documentation platform, and testers can retrieve and download the corresponding version of the interface documentation from the project directory or interface module; alternatively, developers can design and maintain interface documentation in an interface management tool, and testers can directly view and export the documentation for the interface to be tested through the tool's access control, and so on.

[0026] Step 102: Based on the interface information, determine the corresponding target knowledge points from the pre-established API (Application Programming Interface) knowledge point base.

[0027] The target knowledge points may include target historical test cases and target historical test points for code reconstruction. Target historical test points are generated using LLM (Large Language Model) based on the target historical test cases. Test points, also known as test items, test verification points, test checks, or validation points, are specific verification items or check dimensions used to verify whether the functionality, performance, security, compatibility, and other dimensions of the corresponding interface meet the requirements. It should be noted that in practical applications, target knowledge points may include other categories, and this disclosure does not impose any restrictions on this.

[0028] LLM can be used to analyze historical test cases of a target and generate corresponding test points.

[0029] Among them, the target historical test cases are code obtained by refactoring and rewriting related test code.

[0030] The API knowledge point base is pre-established and can store target knowledge points. In this embodiment of the disclosure, target knowledge points matching the interface information can be determined from the pre-established API knowledge point base based on the interface information.

[0031] For example, if the API knowledge point base includes multiple historical test cases of code reconstruction, and any historical test case has a corresponding historical test interface, the API knowledge point base can be queried according to the interface path and request method in the interface information to determine the historical test interface corresponding to the combination of interface path and request method. The historical test case corresponding to the historical test interface is determined as the target historical test case. LLM can be used to analyze the target historical test case to generate the test point corresponding to the historical test interface, and the test point is used as the target historical test point.

[0032] Step 103: Based on the interface testing requirements, target knowledge points, and interface documentation, use LLM to generate test cases for the interface to be tested.

[0033] LLM can also be used to generate test cases.

[0034] It should be noted that the number of test cases generated for the interface to be tested can be, but is not limited to, one, and this disclosure does not impose any restrictions on this.

[0035] In one example, interface testing requirements, target knowledge points, and interface documentation can be input into the LLM, and test cases for the interface to be tested can be obtained in response to the LLM's output.

[0036] Step 104: Execute the test cases for the interface to be tested and obtain the test results for the interface to be tested.

[0037] The test results may include, but are not limited to: response status code, response time, response body, etc.

[0038] The interface testing method of this disclosure involves obtaining interface testing requirements information and the interface documentation of the interface to be tested; wherein the interface documentation records interface information; based on the interface information, determining the corresponding target knowledge points from a pre-established application programming interface (API) knowledge point library; wherein the target knowledge points include target historical test cases and target historical test points for code reconstruction, and the target historical test points are generated based on the target historical test cases using a Large Language Model (LLM); based on the interface testing requirements information, target knowledge points, and interface documentation, using LLM, generating test cases for the interface to be tested; executing the test cases for the interface to be tested to obtain the test results for the interface to be tested. Therefore, by constructing a structured API knowledge point library from pre-constructed target historical test cases and target historical test points generated based on LLM, the reuse and inheritance of test knowledge are realized, avoiding the inefficiency of repeatedly designing test cases in interface testing. At the same time, by matching target knowledge points with interface information in the interface documentation as an index and combining actual interface testing requirements, targeted test cases are generated with the powerful semantic understanding and logical reasoning capabilities of LLM. This not only improves the adaptability of test cases to the interface under test, but also improves the coverage and rationality of test cases, effectively reducing the cost and time investment of manually writing test cases. In addition, by directly executing the generated test cases and outputting test results, the efficiency and accuracy of interface testing can be improved.

[0039] like Figure 2 As shown, this disclosure also proposes an interface testing method. Figure 2 The diagram is based on a second embodiment of this disclosure. The interface testing method may include the following steps: Step 201: Obtain the interface testing requirements and the interface documentation for the interface to be tested; the interface documentation records the interface information.

[0040] Step 202: Based on the interface information, determine the corresponding target knowledge points from the pre-established Application Programming Interface (API) knowledge point base.

[0041] It should be noted that the execution process of steps 201 to 202 can refer to the execution process of any embodiment of this disclosure, and will not be repeated here.

[0042] Step 203: In response to the input operation on the configuration page, obtain the configuration information corresponding to at least one of the configuration items in the request header and request body of the interface to be tested.

[0043] The configuration page can be a visual interactive interface used to interact with users and configure relevant data.

[0044] Input operations refer to the interactive behaviors performed by the user on the configuration page. These interactive behaviors may include, but are not limited to: entering text, selecting drop-down options, checking checkboxes, editing text, and clicking the "Confirm Configuration" button.

[0045] Both the request header and the request body can be components of the request structure of the interface to be tested.

[0046] The configuration items in the request header can be used to configure parameters that conform to the interface protocol or business rules, defining the preconditions for the server to process the request to ensure that the request can be received, parsed and authorized by the server. For example, they can include the request body format, authentication token, received data format, etc. This disclosure does not impose any restrictions on this.

[0047] The configuration items in the request body can be standardized configurations for dimensions such as format, processing rules, validation logic, security constraints, and business adaptation, which define the methods by which the server receives, parses, and processes data.

[0048] It should be noted that this disclosure does not impose any restrictions on the configuration items of the request header or the request body, and these can be configured as needed.

[0049] In any embodiment of this disclosure, the configuration information corresponding to the configuration items in the request header includes at least one of the following: a unique key field, a unique key value, an enabled status, and an operation attribute; the configuration information corresponding to the configuration items in the request body includes at least one of the following: a unique key field, a file name, an enabled status, and an operation attribute.

[0050] Among them, the unique key field can be used to uniquely identify the field name of the corresponding configuration item; Among them, the unique key value can be used to indicate the value corresponding to the unique key field. For example, if the unique key field is "username", its corresponding unique key value is "xiaoming1".

[0051] The enabled status can include enabled, disabled, etc.

[0052] The file corresponding to the file name can be used to assign values ​​to the corresponding unique key fields.

[0053] The operation attribute can be used to indicate the editable operations of the corresponding configuration item. The editable operations can include, but are not limited to, saving, deleting, modifying, etc.

[0054] As an example, users can configure the request header of the interface to be tested on the configuration page using the "Add TOKEN" button. Each configuration item in the request header can include a key (referred to as a unique key field in this disclosure), a value (referred to as a unique key-value pair in this disclosure), an enabled status, and operation options (referred to as operation attributes in this disclosure). Users can also configure the request body on the configuration page using the "Add Test Data" button. Each configuration item in the request body can include a key, a file_name (referred to as the file name in this disclosure), an enabled status, and operation options. The execution body of this disclosure can query the uploaded file based on the file_name and retrieve the value corresponding to the key from the file indicated by the file_name.

[0055] Therefore, by collecting request header and / or request body configuration items, LLM can provide more concrete parameter dimensions that are closer to the actual call logic of the interface to generate test cases. Compared with the general interface information input method, this method uses the configuration attribute information of the request header and request body as key input factors, enabling LLM to identify the interface constraints (such as authentication rules, data transmission format, function activation conditions, and operational constraints), and thus generate standard test cases. This effectively avoids the problem of low test case quality caused by missing parameter configurations (such as insufficient coverage and scenario distortion). At the same time, this structured configuration item design not only ensures the completeness and standardization of test parameters, but also allows testers to flexibly adjust the configuration content according to the characteristics of different interfaces, enhancing the adaptability and accuracy of the generated test cases. This makes the generated test cases both universal based on historical knowledge points and customized to specific interface configurations, which helps to improve the accuracy and effectiveness of interface testing.

[0056] It should be noted that steps 202 and 203 can be executed in parallel or sequentially. This disclosure only illustrates that step 202 is executed before step 203. In practical applications, step 202 can be executed after step 203, etc. This disclosure does not impose any restrictions on this.

[0057] Step 204: Using LLM, generate test cases for the interface to be tested based on the interface testing requirements, target knowledge points, configuration information, and interface documentation.

[0058] As an example, the interface test requirements, target knowledge points, configuration information corresponding to at least one of the configuration items in the request header and request body of the interface to be tested, and the interface documentation can be input into the LLM and the test cases of the interface to be tested can be obtained by responding to the output of the LLM.

[0059] In any embodiment of this disclosure, LLM is used to design test points based on interface testing requirements information to obtain target test points; LLM is also used to generate test cases for the interface to be tested based on the target test points, target knowledge points, configuration information and interface documentation.

[0060] It should be noted that the explanation of the test points in any embodiment of this disclosure is also applicable to this embodiment, and will not be repeated here.

[0061] In this embodiment of the disclosure, interface test requirement information can be input into the LLM to design test points based on the interface test requirement information, and the target test points can be obtained according to the output of the LLM. The target test points, target knowledge points, configuration information corresponding to at least one of the configuration items of the request header and request body of the interface to be tested, and the interface document can be input into the LLM, and the test cases of the interface to be tested can be obtained in response to the output of the LLM.

[0062] Therefore, by first designing test points separately based on the interface testing requirements, the LLM can focus on requirement decomposition and test dimension extraction, outputting target test points in core directions (such as covering functional verification, performance benchmarking, exception handling, and compatibility adaptation), avoiding the problem of unclear test focus caused by the mixing of requirements and knowledge when directly generating test cases. Subsequently, guided by the target test points, and combining historical testing experience, request header and request body configuration information, and technical details of the interface documentation, the LLM is driven to generate test cases that match the interface to be tested. This ensures that the test cases correspond to clear test objectives, reduces redundant design through the reuse of historical knowledge points, and makes the test case parameters more closely match the actual interface call scenario by leveraging the constraints of configuration information, thereby improving the coverage and effectiveness of the generated test cases and further enhancing the testing effectiveness and accuracy of the interface to be tested.

[0063] It is understandable that there may be errors in the design of the target test points. Therefore, in any embodiment of this disclosure, target test points may be displayed; in response to the first editing operation, the target test points are edited to update the target test points.

[0064] The first editing operation includes, but is not limited to: adding, deleting, modifying, etc.

[0065] In one example, pre-designed target test points can be displayed. When a user performs an editing operation on a target test point, the target test point can be edited in response to that editing operation, thereby updating the target test point.

[0066] Therefore, visually displaying the generated target test points allows users to instantly understand them and easily edit any erroneous ones. Furthermore, editing the target test points effectively compensates for any deficiencies, improving their accuracy and effectiveness. This, in turn, enhances the accuracy and effectiveness of the generated test cases and increases the flexibility of the interface testing methods.

[0067] Step 205: Execute the test cases for the interface to be tested and obtain the test results for the interface to be tested.

[0068] The interface testing method of this disclosure, in response to input operations on the configuration page, obtains configuration information corresponding to at least one configuration item in the request header and request body of the interface to be tested; it employs LLM to generate test cases for the interface to be tested based on interface testing requirements, target knowledge points, configuration information, and interface documentation. Thus, by obtaining configuration information for the request header, request body, and other configuration items of the interface to be tested from the configuration page, it provides a more accurate and relevant reference for LLM-generated test cases. Compared to test case generation methods that rely solely on interface documentation and historical target knowledge points, this method combines manually configured personalized requirements with accumulated historical testing knowledge. Leveraging the multi-dimensional information fusion capabilities of LLM, it can generate highly adaptable test cases covering boundary conditions, abnormal scenarios, and business-specific rules, effectively addressing the pain point of traditional test cases struggling to balance general scenarios and customized needs. Simultaneously, the visual configuration page operation mode lowers the technical threshold for testers, allowing them to define test parameters without writing complex code, thus improving the flexibility and ease of use of test case generation.

[0069] like Figure 3 As shown, this disclosure also proposes an interface testing method. Figure 3 The diagram is based on a third embodiment of this disclosure. The interface testing method may include the following steps: Step 301: Scan the target codebase to identify at least one entry point function for interface testing.

[0070] The target codebase can be, for example, a QA (Quality Assurance) test codebase, also known as a QA test code repository.

[0071] The entry point function can be used to indicate the function that initiates the interface request. It is the starting point function in interface testing. For example, the test function that calls the login interface can be the entry point function.

[0072] In this embodiment of the disclosure, the target code can be scanned to identify at least one entry point function used for interface testing. It should be noted that this disclosure does not limit the number of identified entry point functions.

[0073] As an example, when identifying entry point functions, the first step is to locate the test case files. For instance, test case files can be found in relevant directories based on file characteristics. For example, test case files might be stored in directories like `tests` or those with the prefix `test_`, with filenames like `test_*.py`. Based on these file characteristics, the test case files can be identified. Next, the entry point functions within the test case files can be identified. For example, the `pytest` command (e.g., `pytest --cllect-only`) can be used to quickly list all executable test functions starting with `test_` in the test case files, which can then be used as entry point functions. Alternatively, an AST (Abstract Syntax Tree) script can be used to traverse the syntax structure of the test case files, locate all function definition nodes starting with `def test_`, extract the function names and their locations, and use these as the test entry point functions.

[0074] Step 302: For any entry point function, perform dependency analysis on the entry point function to obtain the corresponding dependencies.

[0075] In this embodiment of the disclosure, for any entry point function, dependency analysis can be performed on the entry point function to obtain the dependencies corresponding to the entry point function.

[0076] Dependencies may include, but are not limited to: module dependencies (import dependencies), function call dependencies, class dependencies, data file dependencies (or configuration file dependencies), global dependencies (or context dependencies), etc.

[0077] Among these, module dependencies include external modules or modules within the project that can be imported using import, from ... import ...

[0078] Function call dependencies can be used to indicate other functions that are called directly or indirectly in the corresponding entry point function, such as page object methods, utility functions (e.g., data generation, logging, configuration reading functions), helper functions (setup, teardown, or custom assertions), data loading functions (e.g., functions that read data from files or databases), and so on.

[0079] Among them, class dependency can be used to indicate the classes and methods instantiated or called in the corresponding entry point function, such as page class, service class, data model class, utility class, etc.

[0080] Among them, data file dependencies can be used to indicate the external data files, configuration files, environment variables, etc. that the corresponding entry point function depends on. For example, it can be a test data file in JSON (JavaScript Object Notation) format or YAML (YAML Ain't Markup Language) format.

[0081] Global dependencies can be used to indicate the global state or test context that may be dependent on, such as fixtures defined in conftest.py.

[0082] Step 303: Rebuild the code based on the dependencies to obtain the historical test cases corresponding to the entry point function.

[0083] As an example, dependencies can be combined to obtain the code for the test cases (referred to as historical test cases in this disclosure) corresponding to the entry point function.

[0084] As an example, dependencies can be filtered to retain only the necessary ones; additional dependencies can be added; then, the retained and added dependencies can be combined to build a minimum runnable project, and the historical test cases corresponding to the entry point function can be obtained, that is, the historical test cases after code reconstruction.

[0085] Step 304: Use LLM to parse the historical test cases to obtain the historical test interface information and historical test points corresponding to the historical test cases.

[0086] The historical test interface information may include, but is not limited to: URI (Uniform Resource Identifier), request method, interface parameters, etc.

[0087] Among them, historical test points can be the test points of the corresponding historical test interfaces.

[0088] As an example, historical test cases can be input into an LLM (Library Management System) to parse the historical test cases and determine the test interface corresponding to the historical test cases (referred to as the historical test interface in this disclosure), as well as the historical test interface information and historical test points of the historical test interface.

[0089] Step 305: Based on historical test cases, historical test interface information, and historical test points, construct an API knowledge point base.

[0090] As an example, a structured data storage method can be adopted when building an API knowledge point base. Specifically, a unique identifier (such as a Unique Resource Identifier URI or a unique interface name) corresponding to a historical test interface can be selected as the key of the data record. Using this key as an index, various types of information related to that historical test interface, including but not limited to historical test information, historical test points, and historical test cases corresponding to these test points, are all stored as attribute information associated with this key.

[0091] It can be understood that historical test cases may correspond to multiple historical test interfaces. Therefore, in any embodiment of this disclosure, when a historical test case corresponds to multiple historical test interfaces, LLM is used to analyze the execution logic of the historical test case to determine the dependencies between the multiple historical test interfaces; based on the dependencies between the multiple historical test interfaces, the historical test cases, and the historical test interface information and historical test points of each historical test interface, a topology graph is constructed; and based on the topology graph, an API knowledge point base is generated.

[0092] The dependency types in a dependency relationship can include, but are not limited to: data dependency, state dependency, prerequisite operation dependency, hierarchical dependency, etc.

[0093] It is understandable that there can be dependencies between historical test interfaces. As an example, the historical test interfaces are "User Login Interface", "User Information Interface", and "User Address Interface". The dependency chain formed by the dependencies between these historical test interfaces can be: User Login Interface → User Information Interface → User Address Interface.

[0094] In this embodiment of the disclosure, historical test cases can be input into an LLM (Limited Language Management) to analyze the execution logic of the historical test cases. In response to the output of the LLM, the historical test interfaces corresponding to the historical test cases and the dependencies between the historical test interfaces can be obtained.

[0095] In this embodiment of the disclosure, a topology graph can be constructed based on the dependencies between multiple historical test interfaces, historical test cases, and historical test interface information and historical test points of each historical test interface.

[0096] As an example, multiple nodes in the topology graph are constructed based on multiple historical test interfaces; based on the dependencies between multiple historical test interfaces, at least one directed edge is constructed in the topology graph to connect different nodes; the directed acyclic graph determined by the set of nodes and the set of edges is defined as the topology graph.

[0097] The node attribute information can include the corresponding historical test interface information, historical test points, and historical test cases.

[0098] Therefore, by encapsulating single-interface test knowledge by nodes and characterizing interface dependency logic by directed edges, scattered historical test experience is transformed into a structured directed acyclic knowledge network. This not only intuitively presents the call chain and data flow relationship of multiple interfaces, but also avoids the risk of circular dependencies. At the same time, it provides a traceable and searchable related knowledge carrier for the API knowledge point library, improves the reuse efficiency of historical test experience in complex integration scenarios, and provides a knowledge support foundation for test case generation.

[0099] Therefore, in this embodiment of the disclosure, a topology graph can be used as the data storage structure for the API knowledge point base, thereby constructing the API knowledge point base. For example, using a topology graph as the data storage carrier, historical test interface information, test points, test cases, and inter-interface dependencies can be structurally integrated to construct the API knowledge point base.

[0100] Therefore, by analyzing the execution logic of historical test cases using LLM, the relationships between multiple historical test interfaces (such as call order, data transfer, dependency triggering, etc.) can be effectively identified. This effectively solves the problem of low efficiency and error-proneness in manually sorting out dependencies in multi-interface testing scenarios. Based on the identified dependencies, a topology map is constructed by combining historical test cases, test information of each interface, and test points. This transforms scattered interface testing knowledge into a visual and traceable network of relationships, clearly presenting the upstream and downstream logic, data flow paths, and test coverage dimensions between interfaces. Finally, an API knowledge point library is generated based on this topology map. This library not only contains test knowledge for single interfaces but also integrates the association rules for collaborative testing of multiple interfaces, achieving an upgrade from "single-point knowledge" to "associative knowledge network." This construction method allows subsequent testing of new interfaces to reuse historical testing experience for single interfaces and accurately match the test logic in multi-interface linkage scenarios, effectively covering the integration testing needs between interfaces and improving the completeness and rationality of interface test case generation in complex business scenarios.

[0101] It should be noted that this disclosure does not impose any restrictions on the data storage structure used in the API knowledge point base.

[0102] Step 306: Obtain the interface test requirements information and interface documentation for the interface to be tested; the interface documentation records the interface information.

[0103] Step 307: Based on the interface information, determine the corresponding target knowledge points from the pre-established Application Programming Interface (API) knowledge point base.

[0104] It should be noted that the execution process of steps 306 to 307 can refer to the execution process of any embodiment of this disclosure, and will not be described in detail here.

[0105] The target knowledge points include the target historical test cases and target historical test points for code reconstruction.

[0106] As one possible implementation, the target historical test interface that matches the interface information can be determined from the historical test interfaces in the API knowledge point base based on the interface information; the historical test cases corresponding to the target historical test interface can be determined as target historical test cases, and the historical test points corresponding to the target historical test interface can be determined as target historical test points.

[0107] As an example, the API knowledge base can be queried based on the URI in the interface information to determine the historical test interface corresponding to the URI in the interface information, and the historical test interface can be identified as the target historical test interface. The historical test cases in the attribute information of the target historical test interface can be identified as the target historical test cases, and the historical test points in the attribute information of the target historical test interface can be identified as the target historical test points.

[0108] As another example, when storing API knowledge point data in a topology graph structure, the target node corresponding to the interface information can be queried based on the interface information; the target knowledge point can be determined based on the attribute information of the target node. For example, the historical test cases in the attribute information of the target node can be determined as the target historical test cases, and the historical test points in the attribute information of the target node can be determined as the target historical test points.

[0109] Therefore, by matching interface information with historical test interfaces in the API knowledge point library, the target historical test cases and test points can be quickly located and extracted, avoiding the inefficiency of blindly searching historical assets in traditional testing.

[0110] Optionally, in any embodiment of this disclosure, the target knowledge point may further include historical test interface information in the attribute information of the target historical test interface.

[0111] Step 308: Based on the interface testing requirements, target knowledge points, and interface documentation, use LLM to generate test cases for the interface to be tested.

[0112] Step 309: Execute the test cases for the interface to be tested and obtain the test results for the interface to be tested.

[0113] It should be noted that the execution process of step 306 can refer to the execution process of any embodiment of this disclosure, and will not be described in detail here.

[0114] In any embodiment of this disclosure, test cases for the interface to be tested are shown; in response to a second edit operation, the test cases are edited to update the test cases.

[0115] The second editing operation may include, but is not limited to, deletion, modification, etc.

[0116] For example, after the generated test cases for the interface to be tested are displayed on the user interface, the user can check the generated test cases. After determining that an update is needed, the user can perform a second editing operation on the test cases to edit them, thereby updating the test cases.

[0117] Therefore, by providing visual display and editing functions for test cases, a dual guarantee mechanism of intelligent generation and manual calibration is constructed. This not only leverages the efficiency of LLM in generating test cases by combining historical knowledge points and configuration information, but also empowers relevant personnel with the final decision-making authority over the generated test cases. This facilitates the correction of any deviations or omissions that may occur during the LLM generation process, thereby improving the accuracy and effectiveness of the generated test cases and further enhancing the accuracy and effectiveness of interface testing.

[0118] In any embodiment of this disclosure, knowledge is extracted from the test cases of the interface to be tested to obtain new knowledge points; based on the new knowledge points, the API knowledge point base is updated.

[0119] As an example, if the interface under test passes the test, knowledge can be extracted from the test cases of the interface to be tested to obtain new knowledge points; based on the new knowledge points, the API knowledge point library can be updated. For example, the target test points, interface information, configuration information, and corresponding test cases of the interface to be tested can be saved to the API knowledge point library.

[0120] Therefore, a self-updating mechanism for the API knowledge point base was constructed. By extracting knowledge from newly generated and verified test cases of the interfaces to be tested, new knowledge points are extracted, breaking through the static limitation of traditional knowledge point bases that only rely on historical assets. The API knowledge point base is updated in real time based on new knowledge points, which not only enriches the coverage of the API knowledge point base, but also continuously accumulates the testing experience and business logic of new interfaces, so that the knowledge point base can be continuously iterated and optimized as the testing work progresses. This self-updating mode allows subsequent interface tests to reuse the latest test knowledge, improves the accuracy and adaptability of intelligent test case generation, and provides sustainable knowledge support for long-term large-scale interface testing.

[0121] In any embodiment of this disclosure, during the test task of executing test cases for the interface to be tested, the task information of the test task is obtained and displayed.

[0122] The task information may include at least one of the following: task status, task progress, and execution result. The task information can be set or added according to actual needs, and this disclosure does not impose any restrictions on it.

[0123] The task status can include, but is not limited to: pending execution, executing, completed, failed, canceled, paused, waiting, etc.

[0124] Task progress can be used to indicate the degree of task completion. For example, it can be represented by 0%-100% to show the overall progress of the test task, or by the task stage in which the test task is located, or by the ratio of the time used to the total estimated time, and so on.

[0125] The execution result may include, but is not limited to: return value (the direct return result of a function or method), output file, status code, error message, etc.

[0126] Therefore, the task information of the test task is visualized so that users can understand the real-time progress of the test task.

[0127] In any embodiment of this disclosure, task information for the test tasks of the test cases can also be saved.

[0128] In any embodiment of this disclosure, if the test task of a saved historical test case is not completed, the historical test case can be continued to be executed in response to the user's breakpoint resume operation on the historical test case.

[0129] The interface testing method of this disclosure involves scanning the target codebase to identify at least one entry point function for interface testing; performing dependency analysis on any entry point function to obtain its corresponding dependencies; reconstructing the code based on the dependencies to obtain historical test cases corresponding to the entry point function; using LLM to parse the historical test cases to obtain historical test interface information and historical test points of the historical test interfaces corresponding to the historical test cases; and constructing an API knowledge point base based on the historical test cases, historical test interface information, and historical test points of the historical test interfaces. Therefore, scanning and dependency analysis of the entry point functions in the target codebase allows for the reconstruction of historical test cases corresponding to these functions from the underlying code logic. This not only maintains the integrity and accuracy of historical test cases but also avoids omissions or errors when manually compiling them. Furthermore, leveraging the powerful parsing capabilities of LLM, structured historical test interface information and test points are extracted from these historical test cases, transforming unstructured test cases into indexable and reusable knowledge units. Finally, an API knowledge point library is built based on these standardized knowledge units. This not only enables the digital accumulation of historical testing experience, addressing the pain points of scattered and difficult-to-reuse historical testing experience in traditional interface testing, but also gives the knowledge point library the ability to accurately match interface information, providing high-quality historical reference data for the intelligent generation of subsequent new interface test cases.

[0130] To clearly illustrate the interface testing methods disclosed herein, the following explanation is provided with examples.

[0131] As an example, the interface testing method disclosed herein is applied to an intelligent testing platform, which is a system that combines intelligent agents and knowledge point management, such as... Figure 4 As shown, the intelligent testing platform may include a functional testing module 410, a test data module 420, a knowledge point management module 430, a test project information management module 440, a historical task module 450, and an intelligent agent 460; wherein: The functional testing module 410 provides a user interaction page for generating test cases, facilitating dialogue and operation between the user and the intelligent agent. This user interaction page may include a user command input component, a history component, and a task progress component. The user command input component can be used to obtain interface test requirements information and interface documentation for the interface to be tested; the history component can be used to view historical test cases; and the task progress component can be used to view the task progress of relevant test tasks.

[0132] The test data module 420 can include a configuration page for configuring request headers and / or request bodies to obtain configuration information for configuration items.

[0133] For example, users can configure API request headers by clicking the "Add TOKEN" button on the platform's configuration page. Each configuration item in the request header can include a key, value, enable / disable status, and operation options (referred to as operation attributes in this disclosure). The enable / disable status can be toggled on / off via a button, and operation options can be saved and deleted. It should be noted that this configuration provides a standardized solution to address the issue of calculating a token in the interface request header, ensuring that each request carries correct authentication information and avoiding test failures due to large models being unable to generate dynamic tokens.

[0134] For example, the platform's configuration page provides users with a convenient request body configuration function. Users can simply click the "Add Test Data" button to start the request body configuration process. In the request body configuration phase, each configuration item has rich attributes, covering key, file_name (referred to as the file name in this disclosure), enabled status, and operation options. Among these, file_name plays a crucial role; the platform can accurately read the file that matches the user's uploaded file based on this file name, and thus obtain the value corresponding to the key. It should be noted that the issue of dynamic data input in the request body provides a highly configurable and flexible solution. Even if the large model itself lacks certain specific information, the system can still accurately fill in the dynamic data with this module when generating test cases, ensuring the completeness and accuracy of the generated test cases.

[0135] The knowledge point management module 430 can be used to extract knowledge points from the QA test code library and maintain and manage the extracted knowledge points, including: 1. Knowledge point extraction Complete historical test cases are extracted from the QA test codebase using techniques such as codebase content retrieval, test case filtering, dependency analysis, and code reconstruction. The historical test cases are then parsed using an LLM (Local Management Model) within the agent to extract key interface information (referred to as historical test interface information in this disclosure) of the corresponding historical test interfaces, such as URI, request method, and interface parameters. The execution flow of the historical test cases is analyzed using the LLM within the agent to identify dependencies and historical test points between historical test interfaces. This key interface information and its dependencies are stored in a graph database. In the graph structure, each node represents an interface instance, containing detailed information (such as URI, request method, parameter list, historical test points, and historical test cases). Directed edges between nodes describe the call order, dependencies, or data flow of historical test interfaces. For example, the output of an upstream interface may serve as the input of a downstream interface, or the execution of an interface may depend on the result of a preceding interface.

[0136] 2. Knowledge Point Maintenance The knowledge point management module 430 can display API knowledge points in a visual format, including test cases, test points, requirement documents, request methods, request paths, and so on.

[0137] The knowledge point management module 430 can provide manual maintenance functions for knowledge points, supporting editing operations such as adding, deleting, and modifying knowledge points.

[0138] Optionally, during the test task execution phase, the knowledge point management module 430 will automatically update or add new API knowledge points based on the generated test cases to ensure the timeliness and accuracy of the knowledge base.

[0139] The intelligent agent 460 can respond to user-inputted test requirements (referred to as interface test requirement information in this disclosure) and interface documents, read configuration information from the test data module, and design test points based on the user-inputted test requirements to obtain requirement points (referred to as target test points in this disclosure); extract API test knowledge points (referred to as target knowledge points in this disclosure) that match the interface information from the knowledge point management module according to the interface information in the interface document; use LLM to generate test cases for the interface to be tested based on API test knowledge points, configuration information, user-inputted interface documents and requirement points; and debug or modify the test cases for the interface to be tested.

[0140] The intelligent agent 460 can also display the execution status and dynamic changes of the test tasks corresponding to the test cases of the interface under test in real time, making it easier for users to track and manage the test progress.

[0141] Test Project Information Management 440: Primarily manages the basic information of registered projects (such as module name, test case address, CI pipeline information, etc.); Historical Task Module 450: This module primarily manages information about tasks executed on the platform. This information includes generated test cases, regression tests, report queries, task status, and more.

[0142] The intelligent testing platform disclosed herein has at least the following functions: 1. Knowledge point and test data configuration function: Users can manually carry out configuration work on the platform, and the system will dynamically read relevant information and perform precise filtering based on the specific configuration status.

[0143] 2. QA code library parsing and API knowledge graph construction function: With the help of static code analysis technology, the QA test code library is deeply analyzed, and then the calling relationship between interfaces is constructed into a clear knowledge graph.

[0144] 3. Test case generation and knowledge point update function: In the test case generation process, the platform will automatically call the data of the knowledge point management module, embed the prompt words into it, automatically save the generated test cases, and update the knowledge points in sync.

[0145] 4. Visual Front-End Page Display and Modification Functionality: A dedicated visual front-end page is provided for displaying and modifying the knowledge point graph. The knowledge point management page displays and allows modification of the interface knowledge graph. Through this page, users can obtain detailed information about the URI, methods, parameters, test points, and other attributes of each interface.

[0146] The intelligent testing platform disclosed herein has at least the following advantages: 1. Effectively solves the problem of dynamic configuration. In traditional scenarios where large models are used for test case generation, a key shortcoming is the lack of dynamic computing power and real-time information acquisition capabilities. This makes it difficult to generate accurate configuration content when generating request headers and request bodies. The intelligent testing platform disclosed here innovatively integrates a knowledge point management module with intelligent agent technology to achieve automated configuration management. This mechanism ensures that the generated test cases have high accuracy and good usability in terms of configuration, effectively overcoming the limitations of traditional methods.

[0147] 2. Improve test case generation efficiency This platform has established a comprehensive system for the automatic updating and management of knowledge points. Supported by this system, the intelligent agent can access the latest and most complete background knowledge in real time during the test case generation process. This not only avoids repetitive work caused by outdated knowledge but also allows the intelligent agent to perform efficient reasoning and generation based on the latest knowledge, thereby improving the efficiency of test case generation and shortening the testing cycle.

[0148] 3. Comprehensively enhance the flexibility and accuracy of testing. This platform employs a combination of manual configuration and automated updates, providing exceptional flexibility for testing. Testers can flexibly adjust manual configurations according to different testing scenarios and needs; simultaneously, the system's automated update mechanism promptly captures and integrates changing information, ensuring that knowledge points remain up-to-date. This dual safeguard allows the system to easily adapt to ever-changing testing requirements, and while maintaining flexibility, it rigorously ensures the high accuracy of generated test cases, providing solid support for the reliability of test results.

[0149] In summary, integrating this system offers significant advantages in the process of generating automated test cases for API interfaces using large-scale models. Through deep integration of a knowledge point management mechanism, this system can automatically generate test cases that are both efficient and accurate. These generated automated test cases possess strong adaptability, fully meeting the personalized needs presented during the execution of different business interfaces. For example, the system can accurately handle complex scenarios such as adding authentication information to interface requests or dynamic changes in the request body. Furthermore, the system has an automatic knowledge base update function, promptly updating relevant knowledge and information to the knowledge base after test cases are generated. This ensures that test cases remain highly consistent with the latest business logic, providing strong support for the accuracy and reliability of API interface testing. It can be applied to various software development projects, especially those requiring frequent updates and iterations, improving the efficiency and accuracy of test case generation.

[0150] To implement the above embodiments, this disclosure also provides an interface testing apparatus. For example... Figure 5 As shown, Figure 5 This is a schematic diagram according to the fourth embodiment of the present disclosure. The interface testing device 500 may include: an acquisition module 501, a determination module 502, a generation module 503, and an execution module 504.

[0151] The acquisition module 501 is used to acquire the interface testing requirements information and interface documentation of the interface to be tested; the interface documentation records the interface information.

[0152] The determination module 502 is used to determine the corresponding target knowledge points from the pre-established application programming interface (API) knowledge point library based on the interface information. The target knowledge points include the target historical test cases and target historical test points for code reconstruction. The target historical test points are generated based on the target historical test cases using the Large Language Model (LLM).

[0153] The generation module 503 is used to generate test cases for the interface to be tested based on the interface test requirements, target knowledge points, and interface documentation, using LLM.

[0154] Execution module 504 is used to execute the test cases of the interface to be tested and obtain the test results of the interface to be tested.

[0155] In one possible implementation of this disclosure, the generation module 503 is configured to: in response to an input operation on the configuration page, obtain configuration information corresponding to at least one configuration item in the request header and request body of the interface to be tested; and use LLM to generate test cases for the interface to be tested based on interface test requirement information, target knowledge points, configuration information, and interface documentation.

[0156] In one possible implementation of this disclosure, the configuration information corresponding to the configuration item in the request header includes at least one of the following: a unique key field, a unique key value, an enabled status, and an operation attribute; wherein, the operation attribute is used to indicate the editable operation of the corresponding configuration item; the configuration information corresponding to the configuration item in the request body includes at least one of the following: a unique key field, a file name, an enabled status, and an operation attribute; wherein, the file name corresponds to a file used to assign a value to the corresponding unique key field.

[0157] In one possible implementation of this disclosure, the generation module 503 is used to: design test points based on interface test requirement information using LLM to obtain target test points; and generate test cases for the interface to be tested using LLM based on the target test points, target knowledge points, configuration information, and interface documentation.

[0158] In one possible implementation of this disclosure, the interface testing apparatus 500 may further include: The first display module is used to display the target test points.

[0159] The first editing module is used to edit the target test point in response to the first editing operation, so as to update the target test point.

[0160] In one possible implementation of this disclosure, the interface testing apparatus 500 may further include: The scanning module is used to scan the target codebase to identify at least one entry point function for interface testing.

[0161] The analysis module is used to perform dependency analysis on any entry point function to obtain the corresponding dependencies.

[0162] The rebuild module is used to rebuild the code based on dependencies and obtain the historical test cases corresponding to the entry point function.

[0163] The parsing module is used to parse historical test cases using LLM to obtain historical test interface information and historical test points corresponding to the historical test cases.

[0164] The building module is used to construct an API knowledge point base based on historical test cases, historical test interface information, and historical test points.

[0165] In one possible implementation of this disclosure, the construction module is configured to: in response to multiple historical test interfaces corresponding to historical test cases, analyze the execution logic of the historical test cases using LLM to determine the dependencies between the multiple historical test interfaces; construct a topology graph based on the dependencies between the multiple historical test interfaces, historical test cases, and historical test interface information and historical test points of each historical test interface; and generate an API knowledge point base based on the topology graph.

[0166] In one possible implementation of this disclosure, the construction module is configured to: construct multiple nodes in a topology graph based on multiple historical test interfaces; wherein the node attribute information of the nodes includes corresponding historical test interface information, historical test points, and historical test cases; construct at least one directed edge in the topology graph to connect different nodes based on the dependency relationships between the multiple historical test interfaces; and determine the directed acyclic graph determined by the set of nodes formed by each node and the set of edges formed by each directed edge as the topology graph.

[0167] In one possible implementation of this disclosure, the determining module 502 is configured to: determine a target historical test interface that matches the interface information from the historical test interfaces in the API knowledge point library based on the interface information; determine the historical test cases corresponding to the target historical test interface as target historical test cases; and determine the historical test points corresponding to the target historical test interface as target historical test points.

[0168] In one possible implementation of this disclosure, the interface testing apparatus 500 may further include: The second display module is used to display the test cases for the interface to be tested.

[0169] The second editing module is used to edit test cases in response to the second editing operation, so as to update the test cases.

[0170] In one possible implementation of this disclosure, the interface testing apparatus 500 may further include: The extraction module is used to extract knowledge from the test cases of the interface to be tested, and obtain new knowledge points.

[0171] The update module is used to update the API knowledge point base based on new knowledge points.

[0172] In one possible implementation of this disclosure, the interface testing apparatus 500 may further include: The processing module is used to obtain and display the task information of the test task when executing the test cases of the interface to be tested; wherein the task information includes at least one of the following: task status, task progress, and execution result.

[0173] The interface testing apparatus of this disclosure acquires interface testing requirements information and interface documentation for the interface to be tested; wherein the interface documentation records interface information; based on the interface information, it determines corresponding target knowledge points from a pre-established application programming interface (API) knowledge point library; wherein the target knowledge points include target historical test cases and target historical test points for code reconstruction, and the target historical test points are generated based on the target historical test cases using a Large Language Model (LLM); based on the interface testing requirements information, target knowledge points, and interface documentation, it generates test cases for the interface to be tested using a Large Language Model (LLM); and executes the test cases for the interface to be tested to obtain the test results for the interface to be tested. Therefore, by constructing a structured API knowledge point library from pre-constructed target historical test cases and target historical test points generated based on LLM, the reuse and inheritance of test knowledge are realized, avoiding the inefficiency of repeatedly designing test cases in interface testing. At the same time, by matching target knowledge points with interface information in the interface documentation as an index and combining actual interface testing requirements, targeted test cases are generated with the powerful semantic understanding and logical reasoning capabilities of LLM. This not only improves the adaptability of test cases to the interface under test, but also improves the coverage and rationality of test cases, effectively reducing the cost and time investment of manually writing test cases. In addition, by directly executing the generated test cases and outputting test results, the efficiency and accuracy of interface testing can be improved.

[0174] The collection, storage, use, processing, transmission, provision, and disclosure of users' personal information are all conducted with the consent of the users and comply with relevant laws and regulations, and do not violate public order and good morals.

[0175] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0176] Figure 6 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0177] like Figure 6As shown, device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage unit 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0178] Multiple components in device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of monitors, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0179] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as interface testing methods. For example, in some embodiments, the interface testing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the interface testing method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform interface testing methods by any other suitable means (e.g., by means of firmware).

[0180] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0181] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0182] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0183] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) 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, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0184] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0185] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0186] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0187] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An interface test method characterized by, The method comprises: obtaining interface test requirement information and interface documents of an interface to be tested; wherein the interface documents record interface information; determining corresponding target knowledge points from a pre-established application programming interface (API) knowledge point library according to the interface information; wherein the target knowledge points include target historical test cases for code reconstruction and target historical test points generated based on the target historical test cases using a large language model (LLM); generating test cases for the interface to be tested using the LLM based on the interface test requirement information, the target knowledge points, and the interface documents; executing the test cases for the interface to be tested to obtain test results for the interface to be tested.

2. The method of claim 1, wherein, The method comprises: in response to an input operation on a configuration page, obtaining configuration information corresponding to configuration items of at least one of request headers and request bodies of the interface to be tested; generating test cases for the interface to be tested using the LLM based on the interface test requirement information, the target knowledge points, the configuration information, and the interface documents.

3. The method of claim 2, wherein: the configuration information corresponding to the configuration items of the request headers includes at least one of a unique key field, a unique key value, an enable state, and an operation attribute; wherein the operation attribute is used to indicate an editable operation of the corresponding configuration item; the configuration information corresponding to the configuration items of the request bodies includes at least one of a unique key field, a file name, an enable state, and an operation attribute; wherein the file name corresponding to the file is used to assign a value to the corresponding unique key field.

4. The method of claim 2, wherein, The method comprises: using the LLM to perform test point design based on the interface test requirement information to obtain target test points; using the LLM to generate test cases for the interface to be tested based on the target test points, the target knowledge points, the configuration information, and the interface documents.

5. The method of claim 4, wherein, After the step of using the LLM to perform test point design based on the interface test requirement information to obtain target test points, the method further comprises: displaying the target test points; in response to a first editing operation, editing the target test points to update the target test points.

6. The method of claim 1, wherein, The construction process of the API knowledge point library comprises the following steps: scanning a target code library to identify at least one entry point function for interface testing; for any entry point function, performing dependency analysis on the entry point function to obtain corresponding dependencies; performing code reconstruction based on the dependencies to obtain historical test cases corresponding to the entry point function; and The LLM is used to parse the historical test case to obtain historical test interface information and historical test points of a historical test interface corresponding to the historical test case; The API knowledge point library is constructed according to the historical test case, the historical test interface information and the historical test points of the historical test interface.

7. The method of claim 6, wherein, The API knowledge point library is constructed according to the historical test case, the historical test interface information and the historical test points of the historical test interface. In response to the historical test case corresponding to multiple historical test interfaces, the execution logic of the historical test case is analyzed by using the LLM to determine the dependency relationship between the multiple historical test interfaces; A topology graph is constructed according to the dependency relationship between the multiple historical test interfaces, the historical test case and the historical test interface information and the historical test points of each historical test interface; The API knowledge point library is generated according to the topology graph.

8. The method of claim 7, wherein, The API knowledge point library is constructed according to the historical test case, the historical test interface information and the historical test points of the historical test interface. Based on the multiple historical test interfaces, multiple nodes in the topology graph are constructed; wherein the node attribute information of the node includes corresponding historical test interface information, historical test points and historical test cases; Based on the dependency relationship between the multiple historical test interfaces, at least one directed edge in the topology graph for connecting different nodes is constructed; A directed acyclic graph determined by a node set composed of each node and an edge set composed of each directed edge is determined as the topology graph.

9. The method of claim 6, wherein, The target knowledge point corresponding to the interface information is determined from a pre-established application programming interface (API) knowledge point library according to the interface information. The target historical test case corresponding to the target historical test interface is determined as the target historical test case, and the historical test point corresponding to the target historical test interface is determined as the target historical test point. The method further comprises:

10. The method of any one of claims 1-9, wherein, The test case of the interface to be tested is displayed; In response to a second editing operation, the test case is edited to update the test case. The method further comprises:

11. The method of any one of claims 1-9, wherein, Knowledge extraction is performed on the test case of the interface to be tested to obtain new knowledge points; The API knowledge point library is updated based on the new knowledge points. The method further comprises:

12. The method of any one of claims 1-9, wherein, In the execution of the test task of the test case of the interface to be tested, task information of the test task is obtained and displayed; wherein the task information includes at least one of the following: task state, task progress and execution result. The device comprises:

13. An interface testing device, wherein, An acquisition module is configured to acquire interface test requirement information and an interface document of an interface to be tested; wherein the interface document records interface information. ​ A determining module is configured to determine a corresponding target knowledge point from a pre-established application programming interface (API) knowledge point library according to the interface information; the target knowledge point includes a target historical test case for code reconstruction and a target historical test point generated based on the target historical test case by using a large language model (LLM); A generating module is configured to generate a test case of the interface to be tested by using the LLM based on the interface test requirement information, the target knowledge point, and the interface document; An executing module is configured to execute the test case of the interface to be tested to obtain a test result of the interface to be tested.

14. An electronic device, comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 12.

15. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1 to 12.

16. A computer program product comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 12.

Images