Interface testing method and device, storage medium and computer equipment

Abstract

The invention discloses an interface testing method and device, a storage medium and computer equipment, and relates to the technical field of financial science and technology and the technical field of digital medical treatment. The method comprises the steps of obtaining an interface definition file of a target interface; performing file analysis on the interface definition file, determining interface definition metadata, and performing service semantic analysis on the interface definition file; based on the interface definition metadata and the business semantic analysis result, constructing an inter-service calling topological graph of the target interface, and based on the inter-service calling topological graph, generating an interface test case of the target interface; determining test data generation basis information of the target interface, constructing a test data knowledge graph based on the test data generation basis information, and determining interface test data based on the test data knowledge graph; and generating a test script of the target interface based on the interface test case and the interface test data, and testing the target interface based on the test script.

Description

Technical Field

[0001] This invention relates to the fields of financial technology and digital healthcare technology, and in particular to an interface testing method, apparatus, storage medium, and computer equipment. Background Technology

[0002] Currently, with the widespread application of microservice architecture, cloud-native technologies, and continuous delivery (CI / CD) models, APIs have become the core interaction carrier in modern software systems, such as the API for querying medical insurance information in hospitals and the API for querying car rental information in car rental companies. To ensure interface quality, it is necessary to test the application's interfaces.

[0003] Currently, API testing is typically done by manually writing test scripts. However, this method is time-consuming and labor-intensive, and due to varying skill levels or oversights among technical personnel, errors can occur in the test scripts, thus affecting the effectiveness of API testing. Summary of the Invention

[0004] This invention provides an interface testing method, apparatus, storage medium, and computer equipment, which mainly improves the testing efficiency and accuracy of interfaces.

[0005] According to a first aspect of the present invention, an interface testing method is provided, comprising: In response to a test signal from the target interface, obtain the interface definition file of the target interface; The interface definition file is parsed, and based on the parsing result, the interface definition metadata of the target interface is determined. The interface definition file is then parsed to obtain the business semantic parsing result. The interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface. Based on the interface definition metadata and the business semantic parsing results, the service of the target interface and the calling relationship between the service are determined. Based on the calling relationship between the service, the service calling topology graph of the target interface is constructed. Based on the service calling topology graph, interface test cases of the target interface are generated. In this case, the service is a node in the service calling topology graph, and the calling relationship is an edge between the nodes in the service calling topology graph. The test data generation basis information of the target interface is determined. Based on the test data generation basis information, a test data knowledge graph is constructed. Based on the test data knowledge graph, the interface test data of the target interface is determined. The test data generation basis information includes the environmental de-identification data of the production environment to which the target interface belongs, the database structured description information, the cache dependency rule information, and the business logic constraint information. Based on the interface test cases and the interface test data, a test script for the target interface is generated, and the target interface is tested based on the test script.

[0006] According to a second aspect of the present invention, an interface testing apparatus is provided, comprising: The acquisition unit is used to acquire the interface definition file of the target interface in response to the test signal of the target interface; The parsing unit is used to parse the interface definition file, determine the interface definition metadata of the target interface based on the parsing result, and perform business semantic parsing on the interface definition file to obtain the business semantic parsing result. The interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface. The generation unit is used to determine the service of the target interface and the calling relationship between the service based on the interface definition metadata and the business semantic parsing result; construct the service call topology graph of the target interface based on the service and the calling relationship between the service; and generate interface test cases of the target interface based on the service call topology graph. In this case, the service is used as a node in the service call topology graph, and the calling relationship is used as an edge between the nodes in the service call topology graph. The determining unit is used to determine the test data generation basis information of the target interface, construct a test data knowledge graph based on the test data generation basis information, and determine the interface test data of the target interface based on the test data knowledge graph. The test data generation basis information includes the environmental de-identification data of the production environment to which the target interface belongs, the database structured description information, the cache dependency rule information, and the business logic constraint information. The testing unit is used to generate a test script for the target interface based on the interface test cases and the interface test data, and to test the target interface based on the test script.

[0007] According to a third aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described interface testing method.

[0008] According to a fourth aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described interface testing method.

[0009] According to the interface testing method, apparatus, storage medium, and computer equipment provided by this invention, compared with the current method of manually writing test scripts to test interfaces, this invention improves the comprehensiveness of information acquisition in the interface definition file by combining file parsing and semantic parsing. This enhances the accuracy of test case construction based on the file parsing and semantic parsing results. Simultaneously, by automatically parsing the interface definition file, extracting metadata and business semantic information, and using this information to infer service call relationships and generate test cases, this intelligent processing method reduces the analysis and judgment work of testers on complex interface logic, making testing faster. By parsing the interface definition file, determining the service call relationships between the interface and constructing the service call topology graph, it can more comprehensively consider the interaction between interfaces, thereby generating test cases covering more scenarios. By constructing a test data knowledge graph based on test data generation information, it can comprehensively consider various factors such as production environment anonymized data, database structured description information, cache dependency rule information, and business logic constraint information, generating more comprehensive and diverse test data and improving test coverage. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart of an interface testing method provided by an embodiment of the present invention is shown; Figure 2 This invention provides a flowchart of another interface testing method according to an embodiment of the invention. Figure 3 This diagram illustrates the structure of an interface testing device according to an embodiment of the present invention. Figure 4 This invention provides a schematic diagram of the structure of another interface testing device according to an embodiment of the invention. Figure 5 A schematic diagram of the physical structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation

[0011] The present invention will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0012] Currently, manually writing test scripts to test interfaces is time-consuming and labor-intensive. Furthermore, due to varying skill levels or oversights among technical personnel, errors in test scripts can occur, thus affecting the effectiveness of interface testing.

[0013] To address the above problems, embodiments of the present invention provide an interface testing method, such as... Figure 1 As shown, the method includes: 101. In response to the test signal of the target interface, obtain the interface definition file of the target interface.

[0014] In the embodiments of this invention, within the development or testing environment of a medical system or car rental system, for example, when developers complete the code for an information query interface and submit it to the version control system, or when testers need to test the interface according to the test plan, a test signal can be triggered through the test management platform. For instance, a tester selects the test task for the information retrieval interface on the test management platform and clicks the "Execute Test" button. The test management platform then sends a test signal containing an interface identifier to the interface testing system. Upon receiving the test signal, the interface testing system first parses the interface identifier information in the signal. Then, based on the pre-configured interface definition file storage path (which could be a local file system path, code repository address, or configuration management database address, etc.), it locates and retrieves the interface definition file corresponding to the interface identifier. For the information retrieval interface, its interface definition file may be an OpenAPI specification (OAS) file. The interface definition file is a document or file used to precisely describe the specifications and details of a software interface.

[0015] 102. Perform file parsing on the interface definition file. Based on the file parsing results, determine the interface definition metadata of the target interface, and perform business semantic parsing on the interface definition file to obtain the business semantic parsing results.

[0016] The interface definition metadata includes at least one of the following: parameter types, constraints, response structure, and comment text of the target interface.

[0017] In this embodiment of the invention, a parsing tool, such as a JSON parser, is selected to parse the interface definition file, read its contents, and parse it into a computer-processable data structure. Specifically, the file is opened, its contents are read as a string, and then functions such as `json.loads()` are used to convert the string into a dictionary-type data structure. From the parsed data structure, the parts related to the interface parameters are located, and the data type (i.e., parameter type) of each parameter is determined by accessing the corresponding key-value pairs. Constraints can be obtained from the parameter definitions; for example, the `query_type` parameter may be limited to selected values ​​from preset values ​​such as `["real - time", "daily - k"]`. These constraints are usually reflected in fields such as `enum` and `pattern` in the parameter definition. These fields are parsed to determine the constraints. Response structure information is stored in the `responses` section of the data structure. By parsing the fields under the corresponding status codes in the `responses`, the structure of the response body and the types of each field are determined. Comment text generally exists in the form of a `description` field in various parts of the interface definition, such as an overall interface description, parameter description, and response description. The parsed data structure is traversed, and the contents of all `description` fields are collected. These comment texts help in understanding the functionality and usage of the interface.

[0018] Furthermore, the collected interface definition files' comment text is analyzed in depth to understand the meaning and role of the interfaces in business operations such as financial transactions. For example, the overall interface comment text clearly shows that the information query interface is designed to provide users with real-time or historical market data for renting vehicles, helping them make rental decisions. Relevant business rules are extracted by combining parameters and response structures. For instance, different values ​​of the `query_type` parameter determine the different types of data returned by the interface; fields in the response structure reveal the calculation and display rules for current prices, etc. These business rules are crucial for correctly using the interface and understanding the data it returns. The results of the business semantic analysis are systematically organized to form a business semantic analysis report. The report may include the main business functions of the interface, the involved business entities, business rules (such as data query rules and data calculation rules), and the relationships between business entities. This invention improves the comprehensiveness of information retrieval from interface definition files by combining file parsing and semantic parsing. This enhances the accuracy of test case construction based on the parsing and semantic parsing results. Furthermore, by automatically parsing the interface definition files, extracting metadata and business semantic information, and using this information to infer service call relationships and generate test cases, this intelligent processing method reduces the workload of testers in analyzing and judging complex interface logic, making testing faster.

[0019] 103. Based on the interface definition metadata and business semantic parsing results, determine the service and service call relationships of the target interface. Based on the service and service call relationships, construct the service call topology graph of the target interface. Based on the service call topology graph, generate interface test cases for the target interface. In this graph, services are nodes in the service call topology graph, and call relationships are edges between nodes.

[0020] For an embodiment of the present invention, taking the testing of a hotel booking interface on an online travel platform as an example, the interface definition file corresponding to the hotel booking interface of the online travel platform, after parsing, yields detailed interface definition metadata and business semantic analysis results. The interface definition metadata clarifies the parameter types of the hotel booking interface, such as check-in date (date type), check-out date (date type), hotel ID (string type), etc.; constraints, such as the check-in date cannot be later than the check-out date; the response structure, including information such as whether the booking was successful, the booking number, and the hotel name; and comment text, which explains the interface functions. The business semantic analysis results reveal the role of this interface in the hotel booking business, involving business entities and processes such as user services (obtaining user information), hotel information services (obtaining detailed hotel information), and payment services. Based on the interface definition metadata and business semantic analysis results, services related to the hotel booking interface are identified. Besides the services corresponding to the hotel booking interface itself, these include user services (responsible for user authentication and information acquisition), hotel information services (providing information such as hotel room types, prices, and facilities), payment services (processing payment for bookings), and inventory services (managing hotel room inventory). The call relationships between these services are analyzed. For example, when a user initiates a hotel booking request, the hotel booking service first calls the user service to verify the user's identity and permissions; then it calls the hotel information service to obtain detailed information about the selected hotel and room type; next, after the user confirms the booking, it calls the payment service to perform the payment operation; after successful payment, the hotel booking service calls the inventory service to update the hotel room inventory. In this way, the call order and dependencies of each service in the business process are clearly defined. Each identified service is treated as a node in the service call topology graph, and the call relationships between services are represented as edges between nodes. For example, the user service, hotel information service, payment service, inventory service, and hotel booking service are each treated as a node, and the edge from the user service to the hotel booking service represents the call relationship between the hotel booking service and the user service. The call relationships between other services are also represented by edges in a similar way. Then, based on the above nodes and the edges between nodes, the service call topology graph is constructed. Finally, based on the service call topology graph, test cases are generated considering the normal business process. For example, simulating a normal hotel booking scenario, the user inputs a valid check-in date, check-out date, and hotel ID. The test verifies that the hotel booking service correctly calls the user service to verify user information, the hotel information service to retrieve hotel details, the payment service to complete payment, and finally the inventory service to update inventory, returning a successful booking message and booking number. The test also analyzes potential anomalies in the topology diagram and generates corresponding test cases.For example, when user service verification fails (user does not exist or insufficient permissions), the hotel booking service should return a corresponding error message; when payment service payment fails, the hotel booking service should roll back the previous operation, not update inventory, and inform the user of the booking failure. Corresponding test cases can also be designed for abnormal situations such as the hotel information service being unable to obtain hotel information or the inventory service failing to update inventory. Boundary value test cases are generated based on the constraints in the interface definition metadata. For example, the case where the check-in and check-out dates are the same day, or the booking situation when the hotel room inventory is 0. Simultaneously, special cases are considered, such as the handling mechanism when a service call fails due to network interruption, and corresponding test cases are designed for verification. The test cases in this embodiment of the invention cover positive flow, negative boundary, and security injection scenarios (such as XSS injection, JSON injection, SQL injection, command line injection, unauthorized access, etc.). Compared with the traditional rule-driven approach, this method significantly improves test case coverage and risk detection capabilities, meeting the strict control requirements of APIs at the financial data security level. This invention, through parsing the interface definition file, determines the service calls between the interface and the service call topology, and constructs a service call topology graph. This allows for a more comprehensive consideration of the interactions between interfaces, thereby generating test cases that cover more scenarios.

[0021] 104. Determine the basis information for generating test data for the target interface. Based on the basis information for generating test data, construct a test data knowledge graph. Based on the test data knowledge graph, determine the interface test data for the target interface. The basis information for generating test data includes the environmental anonymization data of the production environment to which the target interface belongs, the database structured description information, the cache dependency rule information, and the business logic constraint information.

[0022] For this embodiment of the invention, taking the testing of the medical insurance information query interface as an example, the following steps are taken to obtain anonymized data from the production environment: The production environment of the medical insurance information query interface stores a large amount of real medical insurance data, but for data security and privacy protection considerations, it is necessary to obtain anonymized data. For example, basic information of insured persons, medical insurance payment records, medical insurance reimbursement records, etc., are exported from the production database of the medical insurance system, and anonymized. Anonymization methods may include partially masking or replacing the names of insured persons with random strings, retaining the first and last few digits of the ID number, and replacing the middle with specific characters, etc. In this way, anonymized data that retains data characteristics while protecting personal privacy is obtained, serving as one of the important bases for generating test data. Collecting database structure description information: Understanding the database structure involved in the medical insurance information query interface is key to generating accurate test data. The structural information of relevant tables in the database is collected, including table names, field names, field types, field lengths, whether nullables are allowed, primary key and foreign key constraints, etc. For example, the insured person information table might contain fields such as "Insured Person ID (primary key, integer type)," "Name (string type, length not exceeding 50)," "ID Number (string type, length 18)," and "Insurance Status (enumeration type, such as normal, suspended, terminated)." This structured descriptive information helps determine the format and value range of the test data. Clearly define cache dependency rules: In the medical insurance system, caching technology may be used to improve query performance. It is necessary to clearly define the dependency rules between the medical insurance information query interface and the cache. For example, some commonly used medical insurance policy information or basic information of insured persons may be cached for a certain period. When querying this information, the interface may first retrieve the data from the cache; if it does not exist in the cache or has expired, it will query the database and update the cache. Understanding these cache dependency rules helps to consider the impact of caching when generating test data, such as designing test cases to verify whether the cache update mechanism is correct. Organize business logic constraints: The medical insurance information query interface involves complex business logic constraints. For example, insured individuals can only query their own medical insurance information, requiring verification of the match between the identity information in the query request and the insured individual's information; queries of medical insurance reimbursement records may be limited by conditions such as time range and reimbursement type; medical insurance policies may differ in different regions, leading to variations in query results. Reviewing these business logic constraints ensures that the generated test data meets the requirements of actual business scenarios.

[0023] Furthermore, the various elements in the test data generation information are used as nodes and edges in the knowledge graph. For example, "insured persons," "medical insurance policies," "reimbursement records," and "caching rules" are used as nodes, and the relationships between them are used as edges. For instance, there is an "applicable" relationship between "insured persons" and "medical insurance policies," a "generation" relationship between "insured persons" and "reimbursement records," and a "dependency" relationship between "medical insurance information query interface" and "caching rules." Then, using a knowledge graph building tool such as Neo4j, the specific data from the collected test data generation information is populated into the knowledge graph based on the defined nodes and edges. For example, specific insured person information is used as an attribute of the "insured persons" node, and specific clauses of the medical insurance policy are used as attributes of the "medical insurance policy" node. In this way, a test data knowledge graph with a clear structure and well-defined relationships is constructed, intuitively displaying the connections between various elements.

[0024] Furthermore, the generation of test data for normal scenarios involves generating test data based on the test data knowledge graph, simulating normal medical insurance information query scenarios. For example, generating valid insured person identity information (generating a valid ID number and name based on the database's structured description information and anonymized environmental data), along with corresponding query conditions (such as querying reimbursement records within a specific time range). Based on cache dependency rules, considering the existence and expiration of the cache, test cases are designed to verify the query performance and accuracy of the interface under normal caching conditions. Simultaneously, based on business logic constraints, the generated test data ensures that the generated test data conforms to the rule that insured persons can only query their own information. The generation of test data for abnormal scenarios involves analyzing potential anomalies in the test data knowledge graph and generating corresponding test data. For example, generating invalid identity information (such as an incorrect ID number format or a non-existent insured person ID) to verify the interface's ability to handle illegal input; simulating cache failures (such as cache server downtime) to test the interface's query functionality and performance without caching; and designing test data that violates business rules based on business logic constraints, such as querying other insured persons' medical insurance information, to verify the interface's security and access control mechanisms. Boundary value test data generation: Based on the database structured description information and business logic constraint information, boundary values ​​are determined and test data is generated. For example, for a query time range, data is generated for boundary conditions such as start time equal to end time, start time earlier than the earliest time supported by the system, and end time later than the current time, to test the interface's processing capability under boundary conditions. This embodiment of the invention constructs a test data knowledge graph based on the test data generation criteria information, which can comprehensively consider factors such as anonymized production environment data, database structured description information, cache dependency rules, and business logic constraint information to generate more comprehensive and diverse test data, thereby improving test coverage.

[0025] 105. Based on the interface test cases and interface test data, generate test scripts for the target interface, and test the target interface based on the test scripts.

[0026] In this embodiment of the invention, test scripts for the target interface are generated based on interface test cases and interface test data, using relevant libraries and frameworks. These test scripts cover various test scenarios, including normal functional testing, exception testing, and boundary value testing. For example, there are scripts for querying correct order numbers, as well as scripts for querying empty order numbers or incorrectly formatted order numbers. A test environment is then set up to ensure it can handle a large number of interface requests. Simultaneously, test client devices are prepared, which can be multiple computers or mobile devices with different configurations to simulate different user scenarios. In the interface testing tool, relevant parameters of the test environment are configured, such as the interface URL address and request header information (such as authentication information). These parameters are ensured to match the actual test environment. For example, if the order query interface requires authentication, a correct authentication token needs to be added to the request header. The test scripts are executed one by one in the order of the test script set. Each test script sends a request to the target interface, carrying corresponding request parameters. For example, a normal order query script sends a request containing a valid order number; an exception order query script sends a request containing an invalid order number. During the execution of each test script, the interface testing tool automatically records the interface's response results, including the response status code, response time, and returned data content. It can also record any anomalies encountered during testing and preliminary judgments of the test results. For example, if the interface returns a status code of 200 but the returned data lacks certain expected fields, this situation needs to be recorded for subsequent analysis. The interface testing method in this embodiment of the invention employs automation, which improves the efficiency and accuracy of interface testing.

[0027] According to the interface testing method provided by this invention, compared with the current method of manually writing test scripts to test interfaces, this invention improves the comprehensiveness of information acquisition in the interface definition file by combining file parsing and semantic parsing. This improves the accuracy of test case construction based on the file parsing and semantic parsing results. Simultaneously, by automatically parsing the interface definition file, extracting metadata and business semantic information, and using this information to infer service call relationships and generate test cases, this intelligent processing method reduces the work of testers in analyzing and judging complex interface logic, making testing faster. By parsing the interface definition file, determining the service call relationships between the interface and constructing a service call topology graph, it can more comprehensively consider the interaction between interfaces, thereby generating test cases covering more scenarios. By constructing a test data knowledge graph based on test data generation information, it can comprehensively consider factors such as anonymized production environment data, database structured description information, cache dependency rule information, and business logic constraint information, generating more comprehensive and diverse test data and improving test coverage.

[0028] Furthermore, to better illustrate the above process of testing the interface, as a refinement and extension of the above embodiments, this embodiment of the invention provides another interface testing method, such as... Figure 2 As shown, the method includes: 201. In response to the test signal of the target interface, obtain the interface definition file of the target interface.

[0029] Specifically, upon receiving a test signal for the target interface, the interface definition file for that interface is retrieved from the database.

[0030] 202. Perform file parsing on the interface definition file. Based on the file parsing results, determine the interface definition metadata of the target interface, and perform business semantic parsing on the interface definition file to obtain the business semantic parsing results.

[0031] Specifically, the interface definition file is parsed to extract information such as parameter types, constraints, response structure, and comment text. Simultaneously, the interface definition file undergoes business semantic analysis to understand its business logic, such as order creation or balance deduction.

[0032] 203. Based on the interface definition metadata and business semantic parsing results, determine the services of the target interface and the calling relationships between the services. Based on the calling relationships between services, construct the service calling topology graph of the target interface. Based on the service calling topology graph, generate interface test cases for the target interface. In this graph, services are nodes in the service calling topology graph, and calling relationships are edges between nodes in the service calling topology graph.

[0033] In this embodiment of the invention, based on the interface definition metadata and business semantic parsing results, the service of the target interface and the calling relationship between the service are determined. Based on the calling relationship between the service and the service, a service call topology diagram of the target interface is constructed. Then, interface test cases for the interface are generated based on this service call topology diagram. Therefore, step 203 specifically includes: determining the calling information of each business process corresponding to the target interface; identifying the critical path corresponding to the key business process in the service call topology diagram based on the calling information, wherein the calling information includes at least one of calling frequency, calling time, and calling success rate; determining alternative paths corresponding to the critical path as abnormal branches, and identifying the calling dependency relationship between services in the service call topology diagram; determining the interface type of the target interface, and determining the test template visualization generation specification requirements corresponding to the interface type; inputting the critical path, the abnormal branch, the calling dependency relationship, and the test template visualization generation specification requirements into a preset test case generation model to generate test cases for the target interface, wherein the preset test case generation model is pre-constructed based on a sample dataset with test case labels.

[0034] Specifically, to improve the test case generation accuracy of the preset test case generation model, it is first necessary to train and construct the preset test case generation model. Based on this, the method includes: constructing a preset initial test case generation model; obtaining a sample dataset, wherein the sample dataset includes a service call topology diagram corresponding to sample interfaces with standard test case labels and test template visualization generation specification requirements, from which critical paths, abnormal branches, and call dependencies can be parsed from the service call topology diagram; dividing the sample dataset into a training set and a test set, using the training set to train the preset initial test case generation model, and using the test set to test the trained preset initial test case generation model; finally, the trained preset initial test case generation model that meets the test conditions is used as the preset test case generation model. Specifically, in the model training process, firstly, the preset initial test case generation model is constructed, and secondly, the sample dataset is obtained. Ensure that the dataset contains all necessary files. Convert the data to a format that the preset initial test case generation model can understand, and finally train and test the model. Specifically, the dataset can be divided first: using random or specific strategies (such as stratified sampling) to divide the sample dataset into a training set and a test set. The model is then trained again using the training set, and tested using the test set to evaluate its performance on unseen data. Precision, recall, and other metrics on the test set are calculated and recorded. If the model performance does not meet requirements, the training phase can be returned for further iterations or adjustments. This process yields a model that generates pre-defined test cases that meet the requirements.

[0035] Furthermore, for example, in a medical insurance information management system, specialized data collection tools, such as distributed tracking systems and performance monitoring tools, can be deployed. These tools can be integrated into various service components of the system to capture and record service calls in real time. Taking the medical insurance information query interface as an example, this interface may involve multiple related business processes, such as basic information query for insured persons, medical insurance reimbursement record query, and medical insurance payment record query. Data collection probes are installed in each relevant service component to ensure comprehensive collection of call information. The data collection tools will record in detail the call information of each business process to the medical insurance information query interface, specifically covering the following aspects: Call frequency: Statistics on the number of times each business process calls the medical insurance information query interface within a specific time period (such as hourly or daily). For example, during the peak period of monthly medical insurance reimbursement, the call frequency of the medical insurance reimbursement record query business to the query interface will increase significantly; while at other times, the call frequency of the basic information query business for insured persons may be relatively stable. Call time: Record the time spent on each call to the medical insurance information query interface, the complete time interval from initiating the call request to receiving the response result. Call time may be affected by various factors, such as database query efficiency, network latency, and system load. For example, when the amount of medical insurance information in the database is large, the query operation may take longer. Call success rate: This is the percentage of successfully completed calls out of the total number of calls. If the medical insurance information query interface experiences a failure at some point, such as a network outage or system upgrade, some calls will fail, thus reducing the success rate. By analyzing the trend of call frequency changes, we can understand the usage of different business processes at different times; by analyzing the distribution of call time, we can identify the call steps with longer processing times, providing a basis for optimizing system performance. For each business process, a comprehensive score is calculated based on its call frequency, call time, and call success rate. For example, business processes with higher call frequency are given higher weight, and business processes with longer call times and lower success rates are given more attention. In the inter-service call topology diagram, the path with the highest comprehensive score is identified as the critical path along the call path of the business process. Taking the medical insurance reimbursement record query business process as an example, if there is a path with a high call frequency, relatively long processing time, and a critical success rate in the path from the user initiating the query to finally obtaining the reimbursement record, then this path is the critical path of that business process. For the identified critical path, analyze its potential alternative paths. Alternative paths are those that are not frequently used under normal circumstances but can serve as replacements when the critical path fails. For example, in the critical path of medical insurance information query, if a critical service component (such as the medical insurance data storage service) fails, the system may automatically switch to another backup data storage service to complete the query operation. The path containing this backup data storage service is the abnormal branch.Based on the code logic and configuration files between services, the direct dependencies between services are determined. For example, the medical insurance information query interface service explicitly calls the user authentication service in its code to verify user identity, indicating that the query interface service depends on the user authentication service. Further, the interface type of the target interface is determined, such as a RESTful interface or a SOAP interface. Simultaneously, the requirements for the visual generation specification of the test template are obtained, which includes specifications for generating test cases. Finally, the determined critical path, exception branches, call dependencies, and the visual generation specification requirements of the test template are input into the test case generation model. The model performs comprehensive analysis and processing based on this information to generate test cases for the medical insurance information query interface.

[0036] 204. Determine the basis information for generating test data for the target interface, construct a test data knowledge graph based on the test data generation basis information, and determine the interface test data for the target interface based on the test data knowledge graph.

[0037] Based on the anonymized environmental data, structured database description information, cache dependency rules, and business logic constraints of the production environment to which the target interface belongs, a test data knowledge graph is constructed. Then, based on this knowledge graph, the interface test data for the target interface needs to be determined. Therefore, step 204 specifically includes: determining the initial interface test data for the target interface based on the test data knowledge graph; inputting the initial interface test data and the anonymized environmental data into a preset test data generation model to generate test data, obtaining the interface test data to be tested for the target interface; and using a preset diffusion model to test the interface test data. The process involves: performing semantic validation on the test data of the interface to be tested, and semantically correcting the test data of the interface to be tested that fails the semantic validation; obtaining semantically corrected test data of the interface to be tested based on preset business rules; performing logical consistency validation on the semantically corrected test data of the interface to be tested, and logically correcting the test data of the interface to be tested that fails the logical consistency validation; identifying sensitive data in the logically corrected test data of the interface to be tested, and de-identifying the sensitive data; finally, using the de-identified test data of the interface to be tested as the interface test data of the target interface.

[0038] Specifically, to improve the data generation accuracy of the preset test data generation model, it is first necessary to train and construct the preset test data generation model. Based on this, the method includes: constructing a preset initial test data generation model; obtaining a sample test dataset, wherein the sample test dataset includes initial interface test data of sample interfaces with test data labels and environmental desensitization data of the production environment to which the sample interfaces belong; dividing the sample test dataset into a training set and a test set, using the training set to test the preset initial test data generation model, and using the test set to test the trained preset initial test data generation model, and finally using the trained preset initial test data generation model that meets the test conditions as the preset test data generation model.

[0039] Furthermore, taking the testing of the medical insurance information query interface as an example, the functional requirements of the interface are first clarified. For example, the interface needs to be able to query the basic medical insurance information, medical insurance reimbursement records, and medical insurance payment records of insured individuals based on their ID card numbers. Based on these requirements, relevant entities and relationships are located in the test data knowledge graph. Data related to the target interface requirements is extracted from the test data knowledge graph as initial interface test data. For example, to test the function of querying basic medical insurance information based on ID card numbers, multiple nodes of insured individuals of different age groups and different medical insurance types are selected from the knowledge graph, and their ID card numbers, names, medical insurance types, and other attribute information are extracted as initial test data. To test the function of querying medical insurance reimbursement records, nodes of insured individuals with reimbursement records are selected, and information related to their reimbursement records, such as reimbursement time, reimbursement amount, and reimbursement items, are extracted as initial test data. In the test environment of the medical insurance information management system, some anonymized real-world environment data is collected, such as simulated medical institution information and medical insurance policy adjustment data. This anonymized environment data can simulate various situations in the actual operating environment, providing a more realistic background for the generation of test data. For example, data on the charging standards of simulated medical institutions at different levels and the differences in medical insurance policies in different regions are collected. Initial interface test data and anonymized environmental data are input into a pre-set test data generation model. The model processes and generates data according to pre-set rules or learned patterns to obtain the test data for the target interface. For example, based on the initial basic information of the insured person and simulated medical insurance policy adjustment data, test data on the insured person's medical insurance reimbursement records under different policies are generated. Further, a diffusion model is pre-set. This model, trained on a large amount of medical insurance information-related text data, can understand and recognize semantic information in medical insurance information. For example, the model can recognize semantic content such as reimbursement conditions and reimbursement scope in medical insurance policy texts, as well as the meaning of various data in medical insurance information query results. Semantic verification and correction: The test data for the interface to be tested is input into the pre-set diffusion model. The model performs semantic analysis on the test data to check whether the data conforms to the semantic specifications of medical insurance information. For example, it checks whether the reimbursement amount is within a reasonable range, whether the reimbursement items conform to the reimbursement scope stipulated by the medical insurance policy, and whether the basic information of the insured person is complete and logical. If semantic errors are found in the data, the model will mark them. For test data of interfaces that fail semantic validation, semantic correction is performed using a pre-defined diffusion model. The model modifies the erroneous data appropriately based on learned semantic knowledge and contextual information. Logical consistency validation and correction: A series of pre-defined business rules are defined based on the business logic of the medical insurance information management system.For example, the rule "An insured person can only be in one medical insurance status (such as employed, retired, etc.) at a time" will be used to perform logical consistency checks on the semantically corrected test data of the interface to be tested according to preset business rules. This checks whether the data meets the requirements of the business rules and whether there are any logical contradictions. For the test data of the interface to be tested that fails the logical consistency check, logical correction will be performed according to preset business rules. For example, if it is found that the insured person's medical insurance status is inconsistent with their age and employment status, it will be corrected to the correct medical insurance status according to the actual situation; if the reimbursement amount exceeds the total medical expenses, the reimbursement amount will be adjusted to a reasonable value that does not exceed the total medical expenses. Anonymization: Sensitive data will be identified in the logically corrected test data of the interface to be tested. Sensitive data in medical insurance information includes the insured person's ID number, name, contact information, bank card number, health status, etc. The identified sensitive data will be anonymized to protect the privacy and information security of the insured person. Anonymization methods include data replacement, data encryption, data masking, etc. The anonymized test data of the interface to be tested will be used as the interface test data of the target interface. These test data not only meet the business requirements and semantic specifications of the medical insurance information management system, but also protect the sensitive information of insured persons, and can be used to conduct comprehensive and effective testing of the medical insurance information query interface.

[0040] 205. Generate test scripts for the target interface based on interface test cases and interface test data.

[0041] In this embodiment of the invention, after determining the interface test cases and interface test data of the target interface, it is necessary to generate the interface test script based on the interface test cases and interface test data. Based on this, step 205 specifically includes: inputting the interface test data into a large model for parameter prediction to obtain the test variables, request parameters, and assertion information required to generate the test script; and generating the test script of the target interface according to preset syntax rules based on the interface test cases, the test variables, the request parameters, and the assertion information.

[0042] Specifically, based on the characteristics of the interface and testing requirements, a suitable large-scale model should be selected for parameter prediction. For example, a large language model with powerful natural language processing capabilities and deep learning algorithms, such as the GPT series or BERT series, can be chosen. The pre-processed interface test data is encapsulated according to the input format required by the large-scale model and then input into it. When interacting with the large-scale model, prompts can be used to guide the model in parameter prediction. For example, for test data of a medical insurance information query interface, the prompt can be set to "Based on the following test data of the medical insurance information query interface, predict the test variables, request parameters, and assertion information required to generate the test script." After receiving the input data and prompts, the large-scale model will use its internal knowledge and algorithms to analyze and process the data, and output the prediction results. Combining the interface test cases and the test variables, request parameters, and assertion information predicted by the large-scale model, the test script for the target interface is generated according to preset syntax rules. The preset syntax rules can be determined based on the testing framework and programming language used, and can include how to define test functions, how to set request headers, how to send requests, and how to perform assertions.

[0043] Furthermore, to improve the testing quality of the interface, it is also necessary to perform quality checks and improvements on the test scripts. Based on this, the method includes: determining the root cause of the target interface test, wherein the root cause includes the modified code of the target interface; performing code structure analysis on the modified code, and based on the code structure analysis results, determining the code change elements of the modified code, and determining the data flow and control flow of the modified code, wherein the code change elements include at least one of adding a method, modifying a method, and calling an interface; based on the code change elements, the data flow, and the control flow, determining uncovered code branches in the modified code that are not covered by the test script; determining the predicted risk of the uncovered code branches under untested conditions, and based on the predicted risk, determining whether the test script needs to be repaired; if so, repairing the test script based on the uncovered code branches; otherwise, prohibiting the repair of the test script.

[0044] Specifically, in the medical insurance information management system, when testing the medical insurance information query interface, the root cause of the test must first be identified. In this embodiment, the root cause is set as the modified code of the target interface. For example, due to adjustments in medical insurance policies, the backend code of the medical insurance information query interface has been modified accordingly to adapt to the new policy requirements, such as changes in the reimbursement ratio calculation method and the expansion of the scope of queried information. This modified code is the root cause of this test, and subsequent testing will revolve around this modified code to ensure that the interface can still provide medical insurance information query services normally and accurately after the changes. The modified code is then analyzed to construct an abstract syntax tree. An abstract syntax tree is a data structure that represents the structure of code in a tree-like form, clearly showing the relationships between various elements in the code. For example, in the modified code of the medical insurance information query interface, the abstract syntax tree can show the hierarchical structure of elements such as classes, methods, and variables, as well as their calling relationships. Based on the code structure analysis results, the changed code elements are identified, and the data flow in the changed code—that is, the process of data transmission and change within the code—is analyzed. The control flow of the changed code—that is, the execution order and conditional branches—is determined. Based on the identified changed code elements, data flow, and control flow, a comprehensive analysis of the changed code is conducted to identify code branches not covered by the test scripts. For example, if a new method for handling special medical insurance situations is added, and existing test scripts do not include test cases for this method, then the code branch containing this method is an uncovered code branch. The anticipated risks of uncovered code branches under untested conditions are assessed from multiple dimensions, including functional integrity risk, data accuracy risk, and system stability risk. For example, if an uncovered code branch involves the calculation of medical insurance reimbursement amounts, its lack of testing may lead to errors in reimbursement calculations, thus affecting functional integrity and data accuracy. If an uncovered code branch has performance issues when processing large amounts of data, it may affect system stability. Based on the risk assessment results, the anticipated risks are classified into different levels, such as high risk, medium risk, and low risk. For example, uncovered code branches that could lead to serious errors in medical insurance reimbursement amounts or system crashes are classified as high-risk; branches that might affect the normal use of some functions but will not cause serious consequences are classified as medium-risk; and branches with minor impact on the system are classified as low-risk. If the predicted risk of an uncovered code branch is high or medium, then the test script needs to be fixed. This is because high and medium risk mean that the branch may seriously affect the functionality, data accuracy, or system stability of the medical insurance information query interface, and the test script must be fixed to increase test coverage for that branch to ensure the quality of the interface. If the predicted risk of an uncovered code branch is low, then fixing the test script is prohibited.Because low risk means that the branch has a smaller impact on the system, fixing the test script may incur unnecessary costs and workload.

[0045] 206. When the target interface consists of multiple interfaces to be tested in the target application, determine the corresponding modified code, interface call data, and modification documents for the target application.

[0046] The target application can be an application in any scenario, such as various applications in the medical scenario or various applications in the financial scenario.

[0047] 207. Based on the changed code, determine the degree of code impact of the code change on each interface to be tested; based on the interface call data, determine the interface call popularity of each interface to be tested; based on the changed documentation, determine the degree of documentation impact of the document change on each interface to be tested.

[0048] 208. Based on the impact of the code, the popularity of the API call, and the impact of the documentation, determine the API test priority for each API to be tested, and call the test script to perform API tests on the corresponding API based on the API test priority.

[0049] Specifically, code change acquisition: After code updates or functional improvements are made to the target application (taking the medical insurance information management system as an example), it is necessary to acquire the changed code through a version control system (such as Git). For example, when the development team optimizes the medical insurance information query module, some code files involving data query and processing are modified. Through the commit records and difference comparison functions of the version control system, it is possible to accurately identify which code files have been changed, and the specific content of the changes, including added, modified, or deleted lines of code. These changed codes are extracted to form a set of changed codes, so as to analyze the degree of impact of code changes on each interface under test. Interface call parameter acquisition: Interface call data reflects the frequency and situation of each interface in actual use. Interface call data, such as call time, call source (such as front-end page, other systems, etc.), call parameters, and call results, can be collected by deploying logging tools on the server side of the medical insurance information management system. Change document acquisition: Change documents are detailed descriptions of changes to the target application, including descriptions of functional changes, business process changes, and data structure changes. During the development of the medical insurance information management system, the development team will write corresponding change documents to record the specific content and scope of impact of each change. Furthermore, based on the acquired modified code, the degree of code impact on each interface under test is analyzed. For example, code dependency analysis tools can be used to determine the relationship between the modified code and the interface under test. If the modified code file is a data processing module that the medical insurance information query interface depends on, then the code impact on that interface is relatively high; conversely, if the modified code is not directly related to the interface, then the code impact is relatively low. Simultaneously, based on the collected interface call data, the number of calls to each interface under test within a certain period is counted. The more calls, the higher the corresponding call popularity. At the same time, the degree of document impact on each interface under test is analyzed. If the modification document explicitly indicates that the function, business process, or data structure of a certain interface has changed, then the document impact on that interface is relatively high. Furthermore, to comprehensively consider the impact of code impact, interface call popularity, and document impact on interface testing priority, corresponding weight coefficients need to be set for each factor. The size of the weight coefficients can be adjusted according to the actual situation. Based on the set weight coefficients, the code impact score, interface call popularity score, and document impact score are weighted and summed to obtain the priority score for each interface under test. Based on the calculated priority scores, all interfaces to be tested are sorted, with higher-scoring interfaces having higher priority and lower-scoring interfaces having lower priority. Finally, according to the determined interface testing priority, pre-prepared test scripts are called sequentially to test the corresponding interfaces.This invention, by testing interfaces according to test priorities, can reasonably allocate test resources, avoid resource congestion, and ensure the stable operation of the test system.

[0050] Furthermore, after testing the interface, if the test results indicate that the interface is abnormal, it is necessary to locate the root cause of the abnormality to facilitate subsequent operation and maintenance. Based on this, the method includes: obtaining the test logs of the target interface during the testing process; performing structured parsing on the test logs, and determining the key event sequence information in the test logs based on the structured parsing results, wherein the key event sequence information includes at least one of the following: request ID of the key event, processing time, exception stack information, upstream and downstream call chain information, and database connection exception information; inputting the key event sequence information into a preset exception detection model for exception detection to obtain the exception detection result of the target interface; obtaining a target abnormal interface case that matches the exception detection result from a preset abnormal interface case knowledge base, and locating the root cause of the exception of the target interface based on the exception root cause of the target abnormal interface case.

[0051] The preset anomaly detection model is trained on a sample dataset consisting of key event sequence information from sample interfaces labeled with anomaly results. The preset anomaly interface case knowledge base stores anomaly cases for various interfaces. Each case includes a description of the anomaly, the anomaly detection result, the root cause analysis, and a solution. For example, a case might be described as: the anomaly is that the medical insurance information query interface returns empty data; the anomaly detection result is a database query anomaly; the root cause is that the database connection pool is exhausted; and the solution is to increase the size of the database connection pool.

[0052] Specifically, obtain the test logs of the target interface during the testing process. For example, taking the medical insurance information query interface as an example, define key events based on the business characteristics and testing requirements of the medical insurance information query interface. Key events may include interface request initiation, database query operation, interface response return, and exception occurrence. For example, when the medical insurance information query interface receives a query request, this is a key event; when the interface sends a query statement to the database and obtains the query result, this is also a key event; if an exception occurs during the interface processing, such as database connection exception or data format error, it also belongs to a key event. Extract key event sequence information from the structured parsed log data. According to the definition of key events, search for relevant records in the log data and extract the request ID, processing time, exception stack information, upstream and downstream call chain information, database connection exception information, etc., of the key events. For example, for a medical insurance information query request, extract its request ID, record the processing time of each key event in the entire processing process from request initiation to interface response return; if an exception occurs during this process, extract the exception stack information; if the interface calls other services or databases, extract the upstream and downstream call chain information and database connection exception information. The extracted key event sequence information is integrated to form a complete key event sequence. This key event sequence information from the medical insurance information query interface is then input into a trained anomaly detection model. The model judges the input data based on the learned feature distribution and outputs anomaly detection results. The anomaly detection results are matched with cases in the anomaly interface case knowledge base, using methods such as keyword matching and similarity calculation. For example, if the anomaly detection result is "database query anomaly," cases containing the keyword "database query anomaly" are searched in the knowledge base, or the similarity between the anomaly detection result and the anomaly detection results in the cases is calculated. The case with the highest similarity is selected as the target anomaly interface case, and finally, the root cause of the anomaly in the target anomaly interface case is taken as the root cause of the anomaly in the target interface. This embodiment of the invention enables rapid intervention to fix problems and prevent further spread of anomalies that could lead to system crashes by promptly locating the root cause of interface anomalies.

[0053] According to another interface testing method provided by this invention, compared with the current method of manually writing test scripts to test interfaces, this invention improves the comprehensiveness of information acquisition in the interface definition file by combining file parsing and semantic parsing. This improves the accuracy of test case construction based on the file parsing and semantic parsing results. Simultaneously, by automatically parsing the interface definition file, extracting metadata and business semantic information, and using this information to infer service call relationships and generate test cases, this intelligent processing method reduces the work of testers in analyzing and judging complex interface logic, making testing faster. By parsing the interface definition file, determining the service call relationships between the interface and constructing a service call topology graph, it is possible to more comprehensively consider the interaction between interfaces, thereby generating test cases covering more scenarios. By constructing a test data knowledge graph based on test data generation information, it is possible to comprehensively consider various factors such as production environment anonymized data, database structured description information, cache dependency rule information, and business logic constraint information, generating more comprehensive and diverse test data and improving test coverage.

[0054] Furthermore, as Figure 1 In specific implementation, embodiments of the present invention provide an interface testing device, such as... Figure 3 As shown, the device includes: an acquisition unit 31, a parsing unit 32, a generation unit 33, a determination unit 34, and a testing unit 35.

[0055] The acquisition unit 31 can be used to acquire the interface definition file of the target interface in response to the test signal of the target interface.

[0056] The parsing unit 32 can be used to parse the interface definition file, determine the interface definition metadata of the target interface based on the parsing result, and perform business semantic parsing on the interface definition file to obtain the business semantic parsing result. The interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface.

[0057] The generation unit 33 can be used to determine the service of the target interface and the calling relationship between the service based on the interface definition metadata and the business semantic parsing result, construct the inter-service calling topology graph of the target interface based on the calling relationship between the service, and generate interface test cases of the target interface based on the inter-service calling topology graph, wherein the service is a node in the inter-service calling topology graph and the calling relationship is an edge between the nodes in the inter-service calling topology graph.

[0058] The determining unit 34 can be used to determine the test data generation basis information of the target interface, construct a test data knowledge graph based on the test data generation basis information, and determine the interface test data of the target interface based on the test data knowledge graph. The test data generation basis information includes the environmental de-identification data of the production environment to which the target interface belongs, the database structured description information, the cache dependency rule information, and the business logic constraint information.

[0059] The test unit 35 can be used to generate a test script for the target interface based on the interface test cases and the interface test data, and to test the target interface based on the test script.

[0060] In specific application scenarios, in order to generate interface test cases for the target interface, such as... Figure 4 As shown, the generation unit 33 includes a first determination module 331 and a use case generation module 332.

[0061] The first determining module 331 can be used to determine the call information of each business process corresponding to the target interface, and based on the call information, identify the critical path corresponding to the key business process in the service call topology diagram. The call information includes at least one of call frequency, call time, and call success rate.

[0062] The first determining module 331 can also be used to determine the alternative path corresponding to the critical path as an abnormal branch, and to identify the call dependency relationship between services in the service call topology graph.

[0063] The first determining module 331 can also be used to determine the interface type of the target interface and determine the test template visualization generation specification requirements corresponding to the interface type.

[0064] The test case generation module 332 can be used to input the critical path, the abnormal branch, the call dependency relationship, and the test template visualization generation specification requirements into the preset test case generation model to generate test cases and obtain the interface test cases of the target interface. The preset test case generation model is pre-constructed based on a sample dataset with test case tags.

[0065] In specific application scenarios, in order to determine the interface test data of the target interface, the determining unit 34 includes a second determining module 341, a data generation module 342, a semantic verification module 343, a logical verification module 344, and a desensitization module 345.

[0066] The second determining module 341 can be used to determine the initial interface test data of the target interface based on the test data knowledge graph.

[0067] The data generation module 342 can be used to input the initial interface test data and the environmental desensitization data into a preset test data generation model to generate test data and obtain the test data of the target interface to be tested.

[0068] The semantic verification module 343 can be used to perform semantic verification on the test data of the interface to be detected using a preset diffusion model, and to perform semantic correction on the test data of the interface to be detected that fails the semantic verification, so as to obtain the semantically corrected test data of the interface to be detected.

[0069] The logic verification module 344 can be used to perform logical consistency verification on the semantically corrected interface test data to be tested based on preset business rules, and to perform logical correction on the interface test data to be tested that fails the logical consistency verification, so as to obtain the logically corrected interface test data to be tested.

[0070] The desensitization module 345 can be used to identify sensitive data in the logically corrected test data of the interface to be tested, and to desensitize the sensitive data, and finally use the desensitized test data of the interface to be tested as the interface test data of the target interface.

[0071] In specific application scenarios, in order to test the target interface, the test unit 35 includes a third determination module 351 and a test module 352.

[0072] The third determining module 351 can be used to determine the modified code, interface call data, and modified documents corresponding to the target application when the target interface is multiple interfaces to be tested in the target application.

[0073] The third determining module 351 can also be used to determine the degree of code impact of the code change on each of the interfaces to be tested based on the changed code, to determine the interface call popularity of each of the interfaces to be tested based on the interface call data, and to determine the degree of document impact of the document change on each of the interfaces to be tested based on the changed document.

[0074] The testing module 352 can be used to determine the interface testing priority of each interface to be tested based on the degree of influence of the code, the popularity of the interface call, and the degree of influence of the document, and to call the test script to perform interface testing on the corresponding interface to be tested based on the interface testing priority.

[0075] In specific application scenarios, in order to locate the root cause of abnormal test results of the interface, the device also includes a root cause localization unit 36.

[0076] The root cause localization unit 36 ​​can be used to acquire test logs of the target interface during the testing process; perform structured parsing on the test logs, and based on the structured parsing results, determine the key event sequence information in the test logs, wherein the key event sequence information includes at least one of the following: request ID of the key event, processing time, exception stack information, upstream and downstream call chain information, and database connection exception information; input the key event sequence information into a preset exception detection model for exception detection, and obtain the exception detection result of the target interface; acquire a target exception interface case that matches the exception detection result from a preset exception interface case knowledge base, and locate the exception root cause of the target interface based on the exception root cause of the target exception interface case.

[0077] In specific application scenarios, in order to verify and repair the test script for test coverage, the device also includes a script repair unit 37.

[0078] The script repair unit 37 can be used to determine the root cause of the test of the target interface, wherein the root cause includes the modified code of the target interface; perform code structure analysis on the modified code, and based on the code structure analysis result, determine the code change elements of the modified code, and determine the data flow and control flow of the modified code, wherein the code change elements include at least one of adding a method, modifying a method, and calling an interface; based on the code change elements, the data flow, and the control flow, determine the uncovered code branches in the modified code that are not covered by the test script; determine the predicted risk of the uncovered code branches under untested conditions, and based on the predicted risk, determine whether the test script needs to be repaired; if so, repair the test script based on the uncovered code branches; otherwise, prohibit repairing the test script.

[0079] In specific application scenarios, in order to generate test scripts for the target interface, the test unit 35 further includes a prediction module 353 and a script generation module 354.

[0080] The prediction module 353 can be used to input the interface test data into a large model for parameter prediction, and obtain the test variables, request parameters, and assertion information required to generate the test script.

[0081] The script generation module 354 can be used to generate a test script for the target interface based on the interface test cases, the test variables, the request parameters, and the assertion information, according to preset syntax rules.

[0082] It should be noted that other corresponding descriptions of the functional modules involved in the interface testing device provided in this embodiment of the invention can be found in [reference needed]. Figure 1 The corresponding description of the method shown will not be repeated here.

[0083] Based on the above, Figure 1 Correspondingly, this embodiment of the invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the following steps: responding to a test signal of a target interface, obtaining an interface definition file of the target interface; parsing the interface definition file, determining the interface definition metadata of the target interface based on the parsing result, and performing business semantic parsing on the interface definition file to obtain a business semantic parsing result, wherein the interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface; determining the service of the target interface and the call relationship between the services based on the interface definition metadata and the business semantic parsing result, and constructing the service of the target interface based on the call relationship between the services. The system generates an inter-service call topology graph. Based on this graph, it generates interface test cases for the target interface, where each service is a node in the graph and the call relationships are edges between nodes. It then determines the basis information for generating test data for the target interface, constructs a test data knowledge graph based on this information, and determines the interface test data for the target interface based on this knowledge graph. This test data generation basis information includes anonymized environment data of the production environment to which the target interface belongs, database structured description information, cache dependency rules, and business logic constraints. Finally, based on the interface test cases and the interface test data, it generates test scripts for the target interface and tests the target interface using these scripts.

[0084] Based on the above, Figure 1 The method shown and as Figure 3 The embodiment of the device shown in the invention also provides a physical structure diagram of a computer device, such as... Figure 5As shown, the computer device includes: a processor 41, a memory 42, and a computer program stored on the memory 42 and executable on the processor. Both the memory 42 and the processor 41 are mounted on a bus 43. When the processor 41 executes the program, it performs the following steps: in response to a test signal of a target interface, it acquires the interface definition file of the target interface; it parses the interface definition file, determines the interface definition metadata of the target interface based on the parsing result, and performs business semantic parsing on the interface definition file to obtain a business semantic parsing result. The interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface; based on the interface definition metadata and the business semantic parsing result, it determines the calling relationship between the services of the target interface and the services, and based on the services and the calling relationship between the services... The system identifies the call relationships between services and constructs an inter-service call topology graph for the target interface. Based on this graph, it generates interface test cases for the target interface, where each service is a node in the graph and the call relationships are edges between nodes. The system then determines the basis information for generating test data for the target interface, constructs a test data knowledge graph based on this information, and determines the interface test data for the target interface based on this knowledge graph. This test data generation basis information includes anonymized environment data of the production environment to which the target interface belongs, database structured description information, cache dependency rules, and business logic constraints. Finally, based on the interface test cases and the interface test data, it generates test scripts for the target interface and tests the target interface using these scripts.

[0085] Through the technical solution of this invention, the combination of file parsing and semantic parsing of interface definition files improves the comprehensiveness of information retrieval from these files. This enhances the accuracy of test case construction based on the parsing and semantic parsing results. Furthermore, by automatically parsing the interface definition files, extracting metadata and business semantic information, and using this information for reasoning to determine service call relationships and generate test cases, this intelligent processing method reduces the workload of testers in analyzing and judging complex interface logic, making testing faster. By parsing the interface definition files, determining the service call relationships between interfaces, and constructing a service call topology graph, the interaction between interfaces can be considered more comprehensively, thereby generating test cases covering more scenarios. Finally, by constructing a test data knowledge graph based on test data generation information, it comprehensively considers factors such as anonymized production environment data, structured database description information, cache dependency rules, and business logic constraints, generating more comprehensive and diverse test data and improving test coverage.

[0086] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0087] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An interface testing method, characterized in that, include: In response to a test signal from the target interface, obtain the interface definition file of the target interface; The interface definition file is parsed, and based on the parsing result, the interface definition metadata of the target interface is determined. The interface definition file is then parsed to obtain the business semantic parsing result. The interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface. Based on the interface definition metadata and the business semantic parsing results, the service of the target interface and the calling relationship between the service are determined. Based on the calling relationship between the service, the service calling topology graph of the target interface is constructed. Based on the service calling topology graph, interface test cases of the target interface are generated. In this case, the service is a node in the service calling topology graph, and the calling relationship is an edge between the nodes in the service calling topology graph. The test data generation basis information of the target interface is determined. Based on the test data generation basis information, a test data knowledge graph is constructed. Based on the test data knowledge graph, the interface test data of the target interface is determined. The test data generation basis information includes the environmental de-identification data of the production environment to which the target interface belongs, the database structured description information, the cache dependency rule information, and the business logic constraint information. Based on the interface test cases and the interface test data, a test script for the target interface is generated, and the target interface is tested based on the test script.

2. The method according to claim 1, characterized in that, The step of generating interface test cases for the target interface based on the inter-service call topology includes: Determine the call information of each business process corresponding to the target interface, and based on the call information, identify the critical path corresponding to the key business process in the service call topology diagram. The call information includes at least one of call frequency, call time, and call success rate. The alternative paths corresponding to the critical path are identified as abnormal branches, and the call dependencies between services are identified in the service call topology graph. Determine the interface type of the target interface, and determine the test template visualization generation specification requirements corresponding to the interface type; The critical path, the abnormal branch, the call dependency relationship, and the test template visualization generation specification requirements are input into the preset test case generation model to generate test cases, thereby obtaining the interface test cases of the target interface. The preset test case generation model is pre-built based on a sample dataset with test case tags.

3. The method according to claim 1, characterized in that, The process of determining the interface test data for the target interface based on the test data knowledge graph includes: Based on the test data knowledge graph, the initial interface test data for the target interface is determined; The initial interface test data and the environmental desensitization data are input into a preset test data generation model to generate test data, thereby obtaining the test data of the target interface to be tested. The test data of the interface to be tested is semantically validated using a preset diffusion model, and the test data of the interface to be tested that fails the semantic validation is semantically corrected to obtain the semantically corrected test data of the interface to be tested. Based on preset business rules, the semantically corrected test data of the interface to be tested is subjected to logical consistency verification, and the test data of the interface to be tested that fails the logical consistency verification is logically corrected to obtain the logically corrected test data of the interface to be tested. Sensitive data in the interface test data to be tested after logical correction is identified, and the sensitive data is de-identified. Finally, the de-identified interface test data to be tested is used as the interface test data of the target interface.

4. The method according to claim 1, characterized in that, The testing of the target interface based on the test script includes: In the case where the target interface is multiple interfaces to be tested in the target application, determine the modified code, interface call data, and modification documents corresponding to the target application. Based on the changed code, determine the degree of code impact of the code change on each of the interfaces to be tested; based on the interface call data, determine the interface call popularity of each of the interfaces to be tested; based on the changed documentation, determine the degree of documentation impact of the document change on each of the interfaces to be tested. Based on the degree of influence of the code, the popularity of the interface calls, and the degree of influence of the documentation, the interface testing priority of each interface to be tested is determined, and based on the interface testing priority, the test script is called to perform interface testing on the corresponding interface to be tested.

5. The method according to claim 1, characterized in that, After testing the target interface based on the test script, the method further includes: Obtain the test logs of the target interface during the testing process; The test logs are subjected to structured parsing. Based on the structured parsing results, key event sequence information in the test logs is determined. The key event sequence information includes at least one of the following: request ID of the key event, processing time, exception stack information, upstream and downstream call chain information, and database connection exception information. The key event sequence information is input into a preset anomaly detection model for anomaly detection to obtain the anomaly detection result of the target interface; Obtain a target abnormal interface case that matches the abnormal detection result from the preset abnormal interface case knowledge base, and locate the abnormal root cause of the target interface based on the abnormal root cause of the target abnormal interface case.

6. The method according to claim 1, characterized in that, After generating the test script for the target interface based on the interface test cases and the interface test data, the method further includes: Determine the root cause of the target interface, wherein the root cause includes the modified code of the target interface; The modified code is subjected to code structure parsing. Based on the code structure parsing results, the code change elements of the modified code are determined, and the data flow and control flow of the modified code are determined. The code change elements include at least one of adding methods, modifying methods, and calling interfaces. Based on the code change elements, the data flow, and the control flow, identify the uncovered code branches in the changed code that are not covered by the test script; Determine the predicted risk of the uncovered code branch when it is not tested, and based on the predicted risk, determine whether the test script needs to be repaired. If so, repair the test script based on the uncovered code branch; otherwise, prohibit repairing the test script.

7. The method according to claim 1, characterized in that, Based on the interface test cases and the interface test data, a test script for the target interface is generated, including: The interface test data is input into a large model for parameter prediction to obtain the test variables, request parameters, and assertion information required to generate the test script. Based on the interface test cases, the test variables, the request parameters, and the assertion information, a test script for the target interface is generated according to preset syntax rules.

8. An interface testing device, characterized in that, include: The acquisition unit is used to acquire the interface definition file of the target interface in response to the test signal of the target interface; The parsing unit is used to parse the interface definition file, determine the interface definition metadata of the target interface based on the parsing result, and perform business semantic parsing on the interface definition file to obtain the business semantic parsing result. The interface definition metadata includes at least one of the parameter types, constraints, response structures, and comment text of the target interface. The generation unit is used to determine the service of the target interface and the calling relationship between the service based on the interface definition metadata and the business semantic parsing result; construct the service call topology graph of the target interface based on the service and the calling relationship between the service; and generate interface test cases of the target interface based on the service call topology graph. In this case, the service is used as a node in the service call topology graph, and the calling relationship is used as an edge between the nodes in the service call topology graph. The determining unit is used to determine the test data generation basis information of the target interface, construct a test data knowledge graph based on the test data generation basis information, and determine the interface test data of the target interface based on the test data knowledge graph. The test data generation basis information includes the environmental de-identification data of the production environment to which the target interface belongs, the database structured description information, the cache dependency rule information, and the business logic constraint information. The testing unit is used to generate a test script for the target interface based on the interface test cases and the interface test data, and to test the target interface based on the test script.

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

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images