Automatic interface testing method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of automatic testing of financial and medical scenes, and discloses an automatic interface testing method and device, computer equipment and a storage medium, and the method comprises the steps: obtaining all interface requests and response data triggered when a front-end interface is operated through a proxy gateway; then aggregating the discrete requests into a sequential sequence based on a user session ID, and identifying a dynamic parameter dependency relationship multiplexed by a subsequent interface; therefore, a user behavior path graph can be constructed, nodes in the graph represent interfaces, and directed edges represent calling sequences and data circulation; extracting a core path from the atlas and automatically converting the core path into an executable test script, wherein the script integrates dynamic parameter transfer logic; after the test is executed, if failure is caused by interface change, root cause diagnosis is carried out in combination with change information, and the script is automatically repaired by using effective data in the new recorded traffic, so that the self-healing of the test case is realized. According to the invention, the generation and maintenance cost of the test case is obviously reduced.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology in financial and medical scenarios, and in particular to an interface automated testing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the rapid development of FinTech and HealthTech, the business logic of web and mobile applications is becoming increasingly complex, and the frequency of system iterations is accelerating significantly. In financial scenarios, processes such as insurance application and loan approval involve multiple interfaces and dynamic parameter transmission; in medical scenarios, processes such as electronic medical record retrieval, test report generation, online consultation and prescription issuance also rely on complex interface calls and data flow.

[0003] Currently, the commonly used interface automation testing methods in the industry (such as those based on tools like JMeter and pytest) heavily rely on testers manually writing and maintaining test scripts. This traditional model has revealed many inherent flaws in practice: First, in the high-frequency iteration process of financial and medical businesses, frequent interface changes require test scripts to be continuously updated synchronously, resulting in a huge workload, high error rates, and high costs. Second, writing high-quality test scripts not only requires testers to have programming skills but also a deep understanding of complex business logic (such as the call order and data dependencies between multiple interfaces), resulting in high talent thresholds and high team training costs. Third, manually designed test cases usually focus on preset "main paths" and "normal scenarios," making it difficult to fully cover the complex, non-linear, and marginal behavioral paths generated by real user operations, resulting in many hidden defects going undetected during the testing phase and high system stability risks. Finally, existing testing tools lack adaptive and intelligent diagnostic capabilities, failing to automatically detect interface changes, dynamically repair scripts, or intelligently locate the root cause of test failures, leading to low regression testing efficiency, heavy reliance on human experience for problem localization, and slow response times.

[0004] Therefore, there is an urgent need in this field for a new type of automated interface testing solution that can fundamentally reduce the threshold for test case generation and maintenance, intelligently simulate real user behavior, and have self-healing and deep diagnostic capabilities, in order to overcome the above-mentioned shortcomings of existing technologies. Summary of the Invention

[0005] The purpose of this invention is to provide an interface automated testing method, apparatus, device, and storage medium, which aims to solve the problems of high maintenance cost of interface automated test cases, high skill requirements for testers, and difficulty in covering complex behavior paths of real users in the prior art.

[0006] In a first aspect, embodiments of the present invention provide an automated interface testing method, comprising: By deploying a proxy gateway between the client and the server, all interface requests and corresponding response data triggered by user interface operations are acquired and stored in real time to form raw traffic logs; The raw traffic logs are cleaned, and discrete interface requests are aggregated into a sequence of interface calls with temporal relationships based on user session identifiers. By using pattern matching and data flow analysis techniques, the dynamic parameter dependencies between different interfaces within the interface call sequence are automatically identified. Based on the interface call sequence and dynamic parameter dependency relationship, a user behavior path graph is constructed with interfaces as nodes and the call and data flow relationship between interfaces as directed edges; Extract at least one complete path from the user behavior path graph and convert it into an executable test script that includes the interface call order and dynamic parameter passing logic; The executable test script is executed, and based on the test report generated during the execution process, combined with interface change information, the root cause intelligent diagnosis of test failure cases is performed. Based on the results of intelligent diagnosis, and utilizing the effective information in the newly acquired traffic data, the test scripts are automatically repaired or updated to correct or update faulty parameters or logic, thereby enabling the test cases to self-heal.

[0007] Secondly, embodiments of the present invention provide an automated interface testing device, comprising: The acquisition unit is used to acquire and store all interface requests and corresponding response data triggered by user interface operations in real time through a proxy gateway deployed between the client and the server, forming raw traffic logs; The processing unit is used to perform data cleaning on the raw traffic logs and aggregate discrete interface requests into a sequence of interface calls with temporal relationships based on user session identifiers. The analysis unit is used to automatically identify the dynamic parameter dependencies between different interfaces within the interface call sequence through pattern matching and data flow analysis techniques. The construction unit is used to construct a user behavior path graph based on the interface call sequence and dynamic parameter dependency relationship, with interfaces as nodes and the call and data flow relationship between interfaces as directed edges; The extraction and transformation unit is used to extract at least one complete path from the user behavior path graph and transform it into an executable test script containing the interface call order and dynamic parameter passing logic. The execution unit is used to execute the executable test script and, based on the test report generated during the execution process and combined with interface change information, perform root cause intelligent diagnosis of test failure cases. The repair and update unit is used to automatically repair or update the invalid parameters or logic in the test script based on the results of intelligent diagnosis and the effective information in the newly acquired traffic data, so as to realize the self-healing of test cases.

[0008] Thirdly, embodiments of the present invention provide a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the interface automated testing method described in the first aspect above.

[0009] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the interface automation testing method described in the first aspect.

[0010] In the aforementioned automated interface testing method, apparatus, equipment, and storage medium, a proxy gateway deployed between the client and server acquires and stores all interface requests and corresponding response data triggered by user interface operations in real time, forming raw traffic logs. The raw traffic logs are cleaned, and discrete interface requests are aggregated into a temporally ordered interface call sequence based on user session identifiers. Dynamic parameter dependencies between different interfaces within the interface call sequence are automatically identified using pattern matching and data flow analysis techniques. Based on the interface call sequence and dynamic parameter dependencies, a user behavior path graph is constructed, with interfaces as nodes and the call and data flow relationships between interfaces as directed edges. At least one complete path is extracted from the user behavior path graph and converted into an executable test script containing the interface call order and dynamic parameter passing logic. The executable test script is executed, and based on the test report generated during execution and combined with interface change information, root cause intelligent diagnosis is performed on failed test cases. Based on the results of the intelligent diagnosis, valid information from newly acquired traffic data is used to automatically repair or update invalid parameters or logic in the test script, achieving self-healing of test cases. In this invention, for the application of automated interface testing in financial and medical scenarios, a fully intelligent closed-loop process for automated interface testing is achieved, significantly reducing the cost of test case generation and maintenance. By acquiring real user behavior in real time and automatically constructing path graphs, it can cover complex financial and medical business scenarios (such as the multi-step process of insurance application, multi-modal data fusion analysis in medical diagnosis, etc.), improving test coverage and accuracy. The self-healing mechanism ensures that test scripts are automatically updated with system iterations, making it particularly suitable for the high-frequency iteration business environment of the financial and medical industries, effectively ensuring system stability and quality. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment for the interface automated testing method provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating an interface automated testing method provided in an embodiment of the present invention. Figure 3 A schematic block diagram of an interface automated testing device provided in an embodiment of the present invention; Figure 4 A schematic diagram of a computer device is provided for an embodiment of the present invention; Figure 5 Another structural schematic diagram of a computer device is provided for an embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The automated interface testing method provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. A proxy gateway deployed between the client and server acquires and stores all interface requests and corresponding response data triggered by user interface operations in real time, forming raw traffic logs. The raw traffic logs are cleaned, and discrete interface requests are aggregated into a temporally ordered sequence of interface calls based on user session identifiers. Through pattern matching and data flow analysis, dynamic parameter dependencies between different interfaces within the call sequence are automatically identified. Based on the call sequence and dynamic parameter dependencies, a user behavior path graph is constructed, with interfaces as nodes and the call and data flow relationships between interfaces as directed edges. At least one complete path is extracted from the user behavior path graph and converted into an executable test script containing the interface call order and dynamic parameter passing logic. The executable test script is executed, and based on the test reports generated during execution and interface change information, root cause intelligent diagnosis is performed on failed test cases. Based on the results of the intelligent diagnosis, and utilizing effective information from newly acquired traffic data, invalid parameters or logic in the test script are automatically repaired or updated, achieving self-healing of test cases. In this invention, for the application of automated interface testing in financial and medical scenarios, a fully intelligent closed-loop process for automated interface testing is achieved, significantly reducing the cost of test case generation and maintenance. By acquiring real user behavior in real time and automatically constructing path graphs, it can cover complex financial and medical business scenarios (such as multi-step processes in insurance application, multi-modal data fusion analysis in medical diagnosis, etc.), improving test coverage and accuracy. The self-healing mechanism ensures that test scripts are automatically updated with system iterations, making it particularly suitable for the high-frequency iteration business environment of the financial and medical industries, effectively ensuring system stability and quality. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0015] Please see Figure 2 As shown, Figure 2 This is a flowchart illustrating the interface automated testing method provided in an embodiment of the present invention.

[0016] like Figure 2 As shown, the method includes steps S201 to S207.

[0017] S201. By deploying a proxy gateway between the client and the server, all interface requests and corresponding response data triggered by user interface operations are acquired and stored in real time to form raw traffic logs.

[0018] Step S201 uses a proxy gateway (such as a customized one based on Mitmproxy) deployed between the user's browser and the backend server to obtain all interface requests and response data triggered by the user when performing insurance operations on the front-end interface in real time, in order to form raw traffic logs.

[0019] For example, in financial scenarios, when a user fills in insurance information, submits health declarations, and ultimately generates an order, the proxy gateway records complete traffic logs for interfaces such as login, premium calculation, health verification, and order creation. In medical scenarios, when a doctor queries a patient's historical medical records, issues test requests, and generates medical orders through the electronic medical record system, the proxy gateway records complete traffic logs for interfaces such as patient information query, test item selection, and medical order submission.

[0020] S202. Perform data cleaning on the raw traffic logs and aggregate discrete interface requests into a sequence of interface calls with temporal relationships based on user session identifiers.

[0021] Step S202 aims to automate the preprocessing of the raw traffic logs obtained in step S201. Specifically, data cleaning is first performed to remove invalid or erroneous data, and then the originally scattered interface requests are integrated into an interface call sequence arranged in chronological order based on user session identifiers, providing a structured data foundation for subsequent analysis.

[0022] In one embodiment, step S202 includes: Preprocess the raw traffic logs to filter out requests for static resources and requests with incorrect HTTP status codes; Based on session ID or user ID, multiple interface requests belonging to the same user session are categorized. Based on the timestamp of each interface request, requests within the same session are sorted in chronological order to form an interface call sequence.

[0023] In this embodiment, by refining data cleaning and session aggregation, the accuracy and reliability of the interface call sequence can be improved, the interference of noisy data on test analysis can be avoided, the test cases can be generated based on pure user behavior data, the realism and coverage of the test scenario can be enhanced, and the false alarms caused by data errors can be reduced.

[0024] For example, in a bank loan approval system, when a user applies for a loan through a client, the raw traffic logs obtained by the proxy gateway may contain a large number of static resource requests or erroneous requests (such as image loading failures). This embodiment first cleanses the logs, filtering out these irrelevant requests and retaining only business interface data. Next, based on the user ID or session ID, multiple interface requests (such as authentication, credit limit inquiry, risk control assessment, and contract generation) from the same user within a single loan application session are categorized and ordered chronologically to construct a structured interface call sequence. For instance, the system ensures that the risk control assessment interface is called after authentication, thereby accurately reflecting the user's actual operation path.

[0025] For example, in a medical appointment registration system, when a patient registers through a client, the raw traffic logs obtained by the proxy gateway may contain a large number of static resource requests or erroneous requests. This embodiment first cleans the logs, filtering out these irrelevant requests and retaining only the business interface data. Next, based on the patient ID or session ID, multiple interface requests (such as department query, doctor scheduling selection, patient information confirmation, and registration submission) from the same patient in a single registration session are categorized and ordered chronologically, constructing a structured interface call sequence to ensure that the doctor scheduling query interface is called before patient information confirmation, accurately reflecting the user's actual operation path.

[0026] S203. Through pattern matching and data flow analysis techniques, the dynamic parameter dependencies between different interfaces within the interface call sequence are automatically identified.

[0027] Step S203 aims to achieve automatic identification of interface dependencies and real-time detection of changes, thereby improving the intelligence and adaptability of testing.

[0028] In one embodiment, step S203 includes: Traverse the API call sequence and select the response body of the preceding API and the request body of the subsequent API in turn. The response body and request body are structured and compared with data items to identify specific data items that will be reused in subsequent interface requests. For each set of identified dynamic parameter dependencies, establish mapping rules to extract data values ​​from the source interface response and inject them into the target interface request; For each interface in the API call sequence, feature extraction is performed. The features include URL pattern, request method, parameter name and type structure, in order to generate a baseline profile of the interface. The newly acquired interface information is continuously compared with the stored baseline interface profiles, and the system automatically identifies and outputs information on newly added interfaces, interface parameter changes, or obsolete interfaces.

[0029] In this embodiment, pattern matching and data flow analysis techniques are used to accurately capture the hidden dynamic parameter dependencies between different interfaces. Furthermore, structured parsing and data item comparison ensure the accuracy and completeness of dependency identification. The data mapping rules established in this embodiment provide reliable data transmission during automated testing, enabling test scripts to flexibly adapt to changes in interface parameters. Simultaneously, by extracting interface features and generating benchmark profiles, a dynamic monitoring system is constructed, capable of detecting any changes at the interface level in real time, including the addition of new interfaces, parameter adjustments, or interface obsolescence. This allows for timely adjustments to testing strategies, ensuring the comprehensiveness and timeliness of testing.

[0030] For example, in an online payment transaction scenario, the system analyzes the user's API call sequence from login to payment completion. Through pattern matching and data flow analysis, the system identifies that the sessionId in the login API response is reused in the request header of subsequent payment APIs, and that the riskLevel value returned by the risk control API is used to adjust payment limits. Simultaneously, the system generates a baseline profile for each API, including URL pattern, request method, and parameter structure. When a new mandatory parameter, merchantCode, is added to the payment API, the system immediately detects this change by continuously comparing the old and new profiles and outputs a change report for subsequent diagnostics.

[0031] For example, in the medical test report query process, the system analyzes the sequence of interface calls from the doctor logging into the system to retrieving the patient's test report. Through pattern matching and data flow analysis, the system identifies that the token in the login interface response is reused in the request header of the subsequent report query interface, and that the patientId returned by the patient information query interface is used in the test report query interface. Simultaneously, the system generates a baseline profile for each interface, including the URL pattern, request method, and parameter structure. When the report query interface adds a required parameter, `departmentCode`, the system immediately detects this change by continuously comparing the old and new profiles and outputs a change report for subsequent diagnosis.

[0032] S204. Based on the interface call sequence and dynamic parameter dependency relationship, construct a user behavior path graph with interfaces as nodes and the call and data flow relationship between interfaces as directed edges.

[0033] Step S204 aims to visually represent the user's operational trajectory and data flow within the software system. This diagram not only helps testers quickly understand the interaction logic between interfaces but also provides crucial information for subsequent test case design.

[0034] In one embodiment, step S204 includes: Using each independent interface as a node, and based on the temporal relationship of the interface call sequence, create directed edges in the directed graph to connect these nodes; Dynamic parameter dependencies are labeled on directed edges to characterize the data flow between interfaces; The frequency of different paths in historical traffic data is statistically analyzed, and the paths in the graph are weighted and classified according to a preset frequency threshold to distinguish between core business paths and edge testing paths.

[0035] In this embodiment, each independent interface is abstracted as a node in a graph structure. Then, based on the order of interface calls analyzed from traffic data, directed connections are established between these nodes, thus visually representing the call flow between interfaces. To enrich the information dimensions of the graph, the system also marks the dynamic parameter dependencies identified in previous steps on the connections. For example, it marks that a certain parameter is extracted from the response of the source node and injected into the request of the target node, so that the graph can not only show the call order but also clearly express the data flow path between different interfaces. Based on this, by statistically analyzing the frequency of various path sequences in historical traffic data, different paths are assigned weights. According to a preset frequency threshold, frequently occurring paths can be automatically marked as core business paths, while low-frequency, unconventional paths are marked as edge testing paths, achieving automated classification and importance differentiation of paths.

[0036] This embodiment introduces a graph theory model to transform discrete interface call sequences into structured, visualized path graphs, greatly improving the understandability and manageability of test scenarios. Frequency-based weighting and classification of paths enables intelligent allocation of test resources, prioritizing the stability of core business processes while ensuring coverage of edge anomaly scenarios, thus achieving a strategic optimization of both the breadth and depth of test coverage.

[0037] For example, in the insurance claims processing workflow, a behavior path graph is constructed based on user actions. Nodes include interfaces such as reporting a claim, uploading documents, reviewing, and calculating claims. Directed edges represent the call order and data flow (e.g., the review interface requires the file ID of the upload interface). The system analyzes the frequency of different paths in historical traffic, marking high-frequency paths (e.g., "reporting a claim → uploading → reviewing → calculating") as core business paths and low-frequency paths (e.g., users repeatedly modifying documents) as edge paths. For instance, in auto insurance claims, core paths cover the standard process, while edge paths simulate abnormal user actions, enhancing the comprehensiveness of testing.

[0038] For example, in the medical electronic medical record archiving process, a behavior path graph is constructed based on doctor operation data. Nodes in the graph include interfaces such as medical record query, diagnosis entry, test result association, and medical record archiving. Directed edges represent the call order and data flow (e.g., the archiving interface requires the reportId of the test result association interface). The system statistically analyzes the frequency of different paths in historical traffic, marking high-frequency paths (e.g., "medical record query → diagnosis entry → test result association → archiving") as core business paths and low-frequency paths (e.g., doctors repeatedly modifying diagnostic information) as edge paths. For instance, in outpatient medical record archiving, the core path covers the standard process, while the edge path simulates doctors repeatedly correcting operations, enhancing the comprehensiveness of the test.

[0039] S205. Extract at least one complete path from the user behavior path graph and convert it into an executable test script that includes the interface call order and dynamic parameter passing logic.

[0040] Step S205 aims to transform the abstract paths in the user behavior path graph into concrete, executable test scripts. These executable test scripts not only include the order of interface calls to ensure the test process follows actual business logic, but also record in detail the logic for passing dynamic parameters, simulating the flow and changes of data in real-world scenarios.

[0041] In one embodiment, step S205 includes: From the user behavior path graph, select at least one complete path from the starting node to the ending node based on the path weight or testing strategy; Based on the order of interface nodes in the path and the dynamic parameter dependencies of directed edges, a test script framework containing the correct interface call order and dynamic parameter passing logic is generated. By analyzing the data characteristics of key interfaces in the path in historical successful responses, intelligent assertion rules for verifying the legality of response data are automatically summarized and generated. The intelligent assertion rules are integrated into the corresponding locations in the test script framework to form a complete executable test script.

[0042] This embodiment defines the transformation process from a path graph to an executable test script. Specifically, firstly, based on a preset strategy (such as prioritizing testing high-weight paths or covering all types of paths), one or more complete paths from the starting interface to the ending interface are selected from the constructed user behavior path graph. Next, the system automatically generates a test script framework based on the order of nodes in the path and the parameter dependency information marked on the connecting edges. This framework precisely defines the call order of the interfaces and embeds the logic for dynamic parameter passing, ensuring that critical data such as authentication tokens can be correctly transmitted between interfaces. Finally, to verify the correctness of the interface responses, the system analyzes the data characteristics exhibited by the key interfaces in the path in all historical successful responses, such as the stable existence of specific fields, the fixedness of data types, or the reasonable range of values. Based on these characteristics, the system automatically summarizes and generates corresponding assertion rules, integrates them into the appropriate location in the script, and finally forms a complete, independently runnable, and self-verifying automated test case.

[0043] This embodiment not only automates script structure generation, but more importantly, it generates intelligent assertions by analyzing historical data. This significantly reduces reliance on manually written verification rules and improves the accuracy and coverage of assertions. The test cases generated by this method more closely reflect the actual behavior of the system and can effectively uncover deep-seated defects caused by data anomalies.

[0044] For example, in the credit card application process, the system extracts a complete path from the user behavior path graph (e.g., "identity verification → credit assessment → credit limit approval → application submission") and automatically converts it into a test script. The script integrates the API call order and dynamic parameter passing (e.g., the score value returned by the credit assessment API is used for credit limit approval). Simultaneously, the system analyzes historical successful response data and discovers that the credit limit approval API response always includes an `approvalStatus` field with a boolean value. Therefore, it automatically generates intelligent assertion rules to verify the existence and type correctness of this field.

[0045] For example, in online medical consultation services, the system extracts a complete path from the user behavior path graph (e.g., "patient login → symptom description → intelligent triage → doctor consultation → prescription issuance") and automatically converts it into a test script. The script integrates the interface call order and dynamic parameter passing (e.g., the deptId returned by the triage interface is used by the doctor consultation interface). Simultaneously, the system analyzes historical successful response data and finds that the prescription issuance interface response always contains a prescriptionId field with a string value. Therefore, it automatically generates intelligent assertion rules to verify the existence and correct format of this field.

[0046] S206. Execute the executable test script and, based on the test report generated during execution and combined with interface change information, perform root cause intelligent diagnosis of test failure cases.

[0047] Step S206 aims to accurately pinpoint the root cause of test failure through intelligent analysis technology.

[0048] In one embodiment, step S206 includes: Run the test execution engine to execute test scripts in batches, and collect status codes, response times and response body information generated during the execution process to generate an initial test report; For test cases marked as failed in the report, extract their error codes and error descriptions; Associate and match error messages with interface change information; If a match is successful, a high-confidence diagnostic report will be automatically generated and output, clearly indicating the failed test cases, the changed interfaces involved, and the specific changes.

[0049] In this embodiment, after running test scripts in batches, the test execution engine collects the execution results of each test case, including status codes, response times, and detailed response body content, and summarizes them to generate an initial test report. For test cases marked as failed in the report, the system automatically extracts their error codes and descriptions. Simultaneously, the system performs association matching and rule reasoning with this error information against a real-time maintained interface change information database. For example, if the error message indicates "Missing necessary parameter X," and the change database records "Interface Y adds required parameter X," the system can determine the association between the two through pattern matching. Once a match is successful, the system automatically generates a high-confidence diagnostic report, which clearly indicates which test case failed, which interface the failure occurred on, and the specific interface change as the root cause.

[0050] This embodiment directly links test failures to system changes, changing the traditional inefficient method of relying on testers to manually compare logs and change records. It can output root cause analysis in seconds, greatly shortening the troubleshooting and repair cycle and improving the overall efficiency of regression testing.

[0051] S207. Based on the results of intelligent diagnosis, utilize the effective information in the newly acquired traffic data to automatically repair or update the invalid parameters or logic in the test script, thereby achieving self-healing of test cases.

[0052] Step S207 aims to improve the adaptability and stability of test scripts through automation.

[0053] In one embodiment, step S207 includes: Analyze the diagnostic report to pinpoint the specific interface that caused the test script to fail and the missing or invalid parameters; Extract the correct request parameters and values ​​for a specific interface from newly recorded successful interface traffic for the same business scenario; Using the extracted correct parameters and values, the system automatically replaces or supplements the corresponding faulty locations in the original test script, thus completing the repair and update of the test script.

[0054] In this embodiment, after receiving the intelligent diagnostic results generated in the aforementioned steps, the system parses the results to pinpoint the specific interface causing the test failure and the missing or malfunctioning parameter. Subsequently, the system moves to newly recorded and stored successful interface traffic data to find successful request instances for that specific interface under the same business scenario. From these instances, the correct request parameters and their valid values ​​are extracted. Finally, the extracted correct parameters and values ​​are automatically used to replace or supplement the corresponding failure points in the original test script, thereby completing the repair and update of the test script, enabling it to adapt to system changes and pass the test on the next execution.

[0055] This embodiment achieves closed-loop automation of test and maintenance work, which is key to reducing maintenance costs. This embodiment enables the test suite to self-evolve and adapt to system changes, maintaining its effectiveness and relevance without manual intervention. It is suitable for development environments with frequent iterations and provides stable and reliable automated testing assurance for continuous integration / continuous delivery processes.

[0056] As can be seen, the above solution achieves a fully intelligent closed-loop process for automated interface testing in financial and healthcare scenarios, significantly reducing the cost of test case generation and maintenance. By acquiring real user behavior in real time and automatically constructing path graphs, it can cover complex financial and healthcare business scenarios (such as multi-step processes in insurance application and multimodal data fusion analysis in medical diagnosis), improving test coverage and accuracy. The self-healing mechanism ensures that test scripts are automatically updated with system iterations, making it particularly suitable for the high-frequency iteration business environment of the financial and healthcare industries, effectively ensuring system stability and quality.

[0057] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0058] In one embodiment, an automated interface testing device is provided, which corresponds one-to-one with the automated interface testing methods described in the above embodiments. For example... Figure 3As shown, the automated interface testing device includes an acquisition unit 301, a processing unit 302, an analysis unit 303, a construction unit 304, an extraction and conversion unit 305, an execution unit 306, and a repair and update unit 307. Detailed descriptions of each functional module are as follows: The acquisition unit 301 is used to acquire and store all interface requests and corresponding response data triggered by user interface operations in real time through a proxy gateway deployed between the client and the server, forming raw traffic logs; The processing unit 302 is used to clean the raw traffic logs and aggregate discrete interface requests into a sequence of interface calls with temporal relationships based on the user session identifier. Analysis unit 303 is used to automatically identify the dynamic parameter dependencies between different interfaces within an interface call sequence through pattern matching and data flow analysis techniques; Building unit 304 is used to construct a user behavior path graph based on the interface call sequence and dynamic parameter dependency relationship, with interfaces as nodes and the call and data flow relationship between interfaces as directed edges; Extraction and transformation unit 305 is used to extract at least one complete path from the user behavior path graph and transform it into an executable test script containing the interface call order and dynamic parameter passing logic. The execution unit 306 is used to execute executable test scripts and, based on the test reports generated during the execution process and combined with interface change information, perform root cause intelligent diagnosis of test failure cases. Repair and update unit 307 is used to automatically repair or update invalid parameters or logic in test scripts based on the results of intelligent diagnosis and the effective information in newly acquired traffic data, so as to realize the self-healing of test cases.

[0059] In one embodiment, the processing unit 302 is specifically used for: Preprocess the raw traffic logs to filter out requests for static resources and requests with incorrect HTTP status codes; Based on session ID or user ID, multiple interface requests belonging to the same user session are categorized. Based on the timestamp of each interface request, requests within the same session are sorted in chronological order to form an interface call sequence.

[0060] In one embodiment, the analysis unit 303 is specifically used for: Traverse the API call sequence and select the response body of the preceding API and the request body of the subsequent API in turn. The response body and request body are structured and compared with data items to identify specific data items that will be reused in subsequent interface requests. For each set of identified dynamic parameter dependencies, establish mapping rules to extract data values ​​from the source interface response and inject them into the target interface request; For each interface in the API call sequence, feature extraction is performed. The features include URL pattern, request method, parameter name and type structure, in order to generate a baseline profile of the interface. The newly acquired interface information is continuously compared with the stored baseline interface profiles, and the system automatically identifies and outputs information on newly added interfaces, interface parameter changes, or obsolete interfaces.

[0061] In one embodiment, the construction unit 304 is specifically used for: Using each independent interface as a node, and based on the temporal relationship of the interface call sequence, create directed edges in the directed graph to connect these nodes; Dynamic parameter dependencies are labeled on directed edges to characterize the data flow between interfaces; The frequency of different paths in historical traffic data is statistically analyzed, and the paths in the graph are weighted and classified according to a preset frequency threshold to distinguish between core business paths and edge testing paths.

[0062] In one embodiment, the extraction and conversion unit 305 is specifically used for: From the user behavior path graph, select at least one complete path from the starting node to the ending node based on the path weight or testing strategy; Based on the order of interface nodes in the path and the dynamic parameter dependencies of directed edges, a test script framework containing the correct interface call order and dynamic parameter passing logic is generated. By analyzing the data characteristics of key interfaces in the path in historical successful responses, intelligent assertion rules for verifying the legality of response data are automatically summarized and generated. The intelligent assertion rules are integrated into the corresponding locations in the test script framework to form a complete executable test script.

[0063] In one embodiment, the execution unit 306 is specifically used for: Run the test execution engine to execute test scripts in batches, and collect status codes, response times and response body information generated during the execution process to generate an initial test report; For test cases marked as failed in the report, extract their error codes and error descriptions; Associate and match error messages with interface change information; If a match is successful, a high-confidence diagnostic report will be automatically generated and output, clearly indicating the failed test cases, the changed interfaces involved, and the specific changes.

[0064] In one embodiment, the repair and update unit 307 is specifically used for: Analyze the diagnostic report to pinpoint the specific interface that caused the test script to fail and the missing or invalid parameters; Extract the correct request parameters and values ​​for a specific interface from newly recorded successful interface traffic for the same business scenario; Using the extracted correct parameters and values, the system automatically replaces or supplements the corresponding faulty locations in the original test script, thus completing the repair and update of the test script.

[0065] Specific limitations regarding the interface automated testing device can be found in the limitations of the interface automated testing method described above, and will not be repeated here. Each module in the aforementioned interface automated testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0066] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of an interface automation testing method on the server side.

[0067] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the client side of an interface automation testing method.

[0068] In one embodiment, 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 computer program to perform the following steps: By deploying a proxy gateway between the client and the server, all interface requests and corresponding response data triggered by user interface operations are acquired and stored in real time to form raw traffic logs; The raw traffic logs are cleaned, and discrete interface requests are aggregated into a sequence of interface calls with temporal relationships based on user session identifiers. By using pattern matching and data flow analysis techniques, the dynamic parameter dependencies between different interfaces within an interface call sequence are automatically identified. Based on the interface call sequence and dynamic parameter dependency, a user behavior path graph is constructed with interfaces as nodes and the call and data flow relationship between interfaces as directed edges. Extract at least one complete path from the user behavior path graph and transform it into an executable test script that includes the interface call order and dynamic parameter passing logic; Execute executable test scripts and, based on the test reports generated during execution and combined with interface change information, perform root cause intelligent diagnosis of test failure cases; Based on the results of intelligent diagnosis, and utilizing the effective information in the newly acquired traffic data, the test scripts can be automatically repaired or updated to correct or update faulty parameters or logic, thus enabling test cases to self-heal.

[0069] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: By deploying a proxy gateway between the client and the server, all interface requests and corresponding response data triggered by user interface operations are acquired and stored in real time to form raw traffic logs; The raw traffic logs are cleaned, and discrete interface requests are aggregated into a sequence of interface calls with temporal relationships based on user session identifiers. By using pattern matching and data flow analysis techniques, the dynamic parameter dependencies between different interfaces within an interface call sequence are automatically identified. Based on the interface call sequence and dynamic parameter dependency, a user behavior path graph is constructed with interfaces as nodes and the call and data flow relationship between interfaces as directed edges. Extract at least one complete path from the user behavior path graph and transform it into an executable test script that includes the interface call order and dynamic parameter passing logic; Execute executable test scripts and, based on the test reports generated during execution and combined with interface change information, perform root cause intelligent diagnosis of test failure cases; Based on the results of intelligent diagnosis, and utilizing the effective information in the newly acquired traffic data, the test scripts can be automatically repaired or updated to correct or update faulty parameters or logic, thus enabling test cases to self-heal.

[0070] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0071] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0072] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0073] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. An interface automation testing method, characterized in that, include: By deploying a proxy gateway between the client and the server, all interface requests and corresponding response data triggered by user interface operations are acquired and stored in real time to form raw traffic logs; The raw traffic logs are cleaned, and discrete interface requests are aggregated into a sequence of interface calls with temporal relationships based on user session identifiers. By using pattern matching and data flow analysis techniques, the dynamic parameter dependencies between different interfaces within the interface call sequence are automatically identified. Based on the interface call sequence and dynamic parameter dependency relationship, a user behavior path graph is constructed with interfaces as nodes and the call and data flow relationship between interfaces as directed edges; Extract at least one complete path from the user behavior path graph and convert it into an executable test script that includes the interface call order and dynamic parameter passing logic; The executable test script is executed, and based on the test report generated during the execution process, combined with interface change information, the root cause intelligent diagnosis of test failure cases is performed. Based on the results of intelligent diagnosis, and utilizing the effective information in the newly acquired traffic data, the test scripts are automatically repaired or updated to correct or update faulty parameters or logic, thereby enabling the test cases to self-heal.

2. The interface automation testing method of claim 1, wherein: The step of cleaning the raw traffic logs and aggregating discrete interface requests into a temporally related sequence of interface calls based on user session identifiers includes: The original traffic logs are preprocessed to filter out requests for static resources and requests with incorrect HTTP status codes. Based on session ID or user ID, multiple interface requests belonging to the same user session are categorized. Based on the timestamp of each interface request, the requests within the same session are sorted in chronological order to form the interface call sequence.

3. The interface automation testing method of claim 1, wherein: The automatic identification of dynamic parameter dependencies between different interfaces within the interface call sequence using pattern matching and data flow analysis techniques includes: Traverse the interface call sequence and select the response body of the preceding interface and the request body of the subsequent interface in turn; The response body and request body are subjected to structured parsing and data item comparison to identify specific data items that will be reused in subsequent interface requests; For each set of identified dynamic parameter dependencies, establish mapping rules to extract data values ​​from the source interface response and inject them into the target interface request; For each interface in the interface call sequence, feature extraction is performed. The features include URL pattern, request method, parameter name and type structure, in order to generate a baseline profile of the interface. The newly acquired interface information is continuously compared with the stored baseline interface profiles, and the system automatically identifies and outputs information on newly added interfaces, interface parameter changes, or obsolete interfaces.

4. The interface automation testing method of claim 1, wherein: The process of constructing a user behavior path graph based on the interface call sequence and dynamic parameter dependencies, with interfaces as nodes and the call and data flow relationships between interfaces as directed edges, includes: Using each independent interface as a node, and based on the temporal relationship of the interface call sequence, a directed edge is created in the directed graph to connect the nodes; The dynamic parameter dependencies are labeled on the directed edges to characterize the data flow between interfaces; The frequency of different paths in historical traffic data is statistically analyzed, and the paths in the graph are weighted and classified according to a preset frequency threshold to distinguish between core business paths and edge testing paths.

5. The interface automation testing method of claim 1, wherein: The step of extracting at least one complete path from the user behavior path graph and converting it into an executable test script containing the interface call order and dynamic parameter passing logic includes: From the user behavior path graph, select at least one complete path from the starting node to the ending node according to the path weight or the testing strategy; Based on the order of interface nodes in the path and the dynamic parameter dependencies of directed edges, a test script framework containing the correct interface call order and dynamic parameter passing logic is generated. By analyzing the data characteristics of key interfaces in the path in historical successful responses, intelligent assertion rules for verifying the legality of response data are automatically summarized and generated. The intelligent assertion rules are integrated into the corresponding positions of the test script framework to form a complete executable test script.

6. The interface automation testing method of claim 1, wherein: The execution of the executable test script, and based on the test report generated during execution, combined with interface change information, to perform root cause intelligent diagnosis of test failure cases, includes: Run the test execution engine to execute the test scripts in batches, and collect the status codes, response times and response body information generated during the execution process to generate an initial test report; For test cases marked as failed in the report, extract their error codes and error descriptions; The error message is associated and matched with the interface change information; If a match is successful, a high-confidence diagnostic report will be automatically generated and output, which will clearly indicate the failed use cases, the changed interfaces involved, and the specific changes.

7. The interface automated testing method according to claim 3, characterized in that: The step of automatically repairing or updating faulty parameters or logic in the test script based on the results of intelligent diagnosis and utilizing valid information from newly acquired traffic data to achieve self-healing of test cases includes: Analyze the diagnostic report to pinpoint the specific interface that caused the test script to fail and the missing or invalid parameters; Extract the correct request parameters and values ​​of the specific interface from newly recorded successful interface traffic for the same business scenario; Using the extracted correct parameters and values, the system automatically replaces or supplements the corresponding faulty locations in the original test script, thus completing the repair and update of the test script.

8. An interface for automating a testing device, characterized by, include: The acquisition unit is used to acquire and store all interface requests and corresponding response data triggered by user interface operations in real time through a proxy gateway deployed between the client and the server, forming raw traffic logs; The processing unit is used to perform data cleaning on the raw traffic logs and aggregate discrete interface requests into a sequence of interface calls with temporal relationships based on user session identifiers. The analysis unit is used to automatically identify the dynamic parameter dependencies between different interfaces within the interface call sequence through pattern matching and data flow analysis techniques. The construction unit is used to construct a user behavior path graph based on the interface call sequence and dynamic parameter dependency relationship, with interfaces as nodes and the call and data flow relationship between interfaces as directed edges; The extraction and transformation unit is used to extract at least one complete path from the user behavior path graph and transform it into an executable test script containing the interface call order and dynamic parameter passing logic. The execution unit is used to execute the executable test script and, based on the test report generated during the execution process and combined with interface change information, perform root cause intelligent diagnosis of test failure cases. The repair and update unit is used to automatically repair or update the invalid parameters or logic in the test script based on the results of intelligent diagnosis and the effective information in the newly acquired traffic data, so as to realize the self-healing of test cases.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the interface automated testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the interface automation testing method as described in any one of claims 1 to 7.

Images