Interface dependency relationship analysis and automated testing method, device and storage medium

Abstract

This application discloses an interface dependency parsing and automated testing method, device, and storage medium, comprising: extracting the minimum path set of the target medical business scenario from the interface call sequence diagram based on the target medical business scenario; using the minimum path set as the test path, parsing the data dependency relationship of each interface in the test path, extracting data flow rules to generate test data; calling the interfaces of the test path according to the test data to generate integrity verification results; comparing the integrity verification results with the expected behavior of the interface call sequence diagram to locate abnormal test nodes; and identifying changes in the interface dependency relationship of abnormal test nodes. This application automatically constructs and dynamically updates the interface call sequence diagram from real call logs through a time sequence pattern mining algorithm, replacing manual dependency analysis. When business logic changes, the test path and data flow rules are re-extracted to ensure that the test plan is updated synchronously with the business, thereby reducing the maintenance cost of test scripts.

Description

Technical Field

[0001] This application relates to the field of medical information technology, and in particular to a method, device and storage medium for interface dependency resolution and automated testing. Background Technology

[0002] In the field of healthcare information systems, hospitals typically deploy multiple business subsystems, such as hospital information systems, laboratory information systems, image archiving and communication systems, and electronic medical record systems. These subsystems interact with each other through interfaces, jointly supporting core medical business processes such as outpatient services, inpatient services, laboratory tests, and examinations. These interface calls do not occur in isolation but follow a specific business logic sequence, forming a complex interface call chain. For example, a typical outpatient process involves multiple steps, including registration, prescription issuance, payment, laboratory tests, and report return. Each step corresponds to different interface calls, and the output data of upstream interfaces often serves as the input parameters for downstream interfaces, creating a tight data dependency relationship between interfaces. Therefore, testing healthcare information system interfaces requires not only verifying the functional correctness of individual interfaces but also ensuring the correct execution and complete data transmission of the entire call chain in the business scenario.

[0003] In the practice of interface testing, clarifying the dependencies between interfaces is a core step in the test preparation phase. Currently, this clarification is mainly done manually by testers based on their understanding of the business processes, and the results are coded into fixed scripts or configuration files.

[0004] Once the medical business logic changes—for example, adding a medical insurance settlement interface after the payment process, or adjusting the call order between test results and report returns—testers have to manually re-examine dependencies and modify test scripts. For large medical institutions with hundreds or thousands of interfaces, such changes can occur frequently, resulting in a huge workload for maintaining test scripts and slow response times, making it difficult to keep up with the pace of business iteration. Even if some solutions attempt to organize interface testing based on application scenarios, the determination of dependencies still relies on manual methods, lacking the ability to automatically analyze interface call logs to dynamically parse and update dependencies, thus failing to address the update problem at its root.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a method, device and storage medium for interface dependency resolution and automated testing, which aims to solve the technical problems of high maintenance costs and inability to dynamically adapt to business changes caused by manual dependency sorting in medical information system interface testing.

[0007] To achieve the above objectives, this application proposes an interface dependency resolution and automated testing method, the method comprising: Historical interface call logs are collected, and the logs are divided into segments using a preset time window to identify target call sequences with call frequencies exceeding a preset threshold. An interface call sequence diagram is constructed using interfaces as nodes and the call relationships within the target call sequence as directed edges, with call frequency as the edge weight. A preset medical business process template is obtained, and each node in the interface call sequence diagram is matched with a semantic role in the template. Based on the matching results, each node is labeled with its corresponding business semantic role, resulting in a semantically labeled interface call sequence diagram. Based on the selected target medical business scenario, extract the minimum set of paths that cover the complete business flow of the target medical business scenario from the interface call sequence diagram; The minimum path set is used as the test path. The data dependency relationship between each interface in the test path is parsed to extract the data flow rules. Test data is generated based on the data flow rules. Call the interfaces of the test path according to the test data, verify the response data of each interface, and generate integrity verification results; The integrity verification result is compared with the expected behavior of the interface call sequence diagram, and the abnormal test node is located based on the comparison result. Identify changes in interface dependencies in the abnormal test nodes, and update the interface call sequence diagram based on the changes in interface dependencies; The step of extracting the minimum set of paths covering the complete business flow of the selected target medical business scenario from the interface call sequence diagram includes: Based on the target medical business scenario, determine all the required semantic role nodes needed to complete the target medical business scenario; In the interface call sequence diagram, with the inclusion of all the required semantic role nodes as a constraint, the shortest directed path from the starting semantic role node to the ending semantic role node is calculated by a path search algorithm. The shortest directed path is taken as the minimum set of paths that cover the complete business flow of the target medical business scenario.

[0008] In one embodiment, the step of parsing the data dependencies between interfaces in the test path and extracting data flow rules includes: Locate each group of adjacent interfaces with a direct calling relationship in the test path, and obtain the response parameter set of the predecessor interface and the request parameter set of the successor interface in the adjacent interfaces; Compare the parameter names and parameter labels in the response parameter set and the request parameter set, and create a mapping relationship between the output parameters and the input parameters based on the comparison results; The mapping relationships of the adjacent interfaces are integrated to generate data flow rules that cover the test path.

[0009] In one embodiment, the step of generating test data based on the data flow rules includes: Based on the data flow rules, identify the request parameters and constraints of the initial interface in the test path, and generate initial request data that meets the constraints; The initial interface is invoked through the initial request data, and the business entity identifier to be transmitted is extracted from the response data of the initial interface. The business entity identifier is matched with the mapping relationship in the data flow rules to determine the business entity identifier based on the target parameter field in the next interface request; Assign the business entity identifier to the target parameter field, and generate the complete request data for the next interface by combining the constraints of the next interface; Traverse all adjacent interfaces in the test path, repeatedly perform the business entity identifier extraction and target parameter field assignment operations until a test dataset covering the entire path and satisfying the upstream and downstream data dependencies is generated.

[0010] In one embodiment, the step of verifying the response data of each interface and generating an integrity verification result includes: For each response message returned by the interface, verify the response status code, existence, data type and value range of the key business fields of the response message, and generate field-level verification records based on the verification results; For adjacent interfaces with direct data dependencies, verify whether the request parameters of the downstream interface in the adjacent interface are the corresponding fields of the response message of the upstream interface, and generate a data transmission verification record based on the verification result. Integrate the field-level verification records and the data transmission verification records to generate a structured integrity verification result.

[0011] In one embodiment, the step of comparing the integrity verification result with the expected behavior of the interface call sequence diagram, and locating the abnormal test node based on the comparison result, includes: Extract the response pattern characteristics of each interface node under historical normal call behavior from the interface call sequence diagram; The difference between the actual response behavior of each interface in the integrity verification result and the corresponding historical response pattern characteristics is calculated. If the result of the difference calculation exceeds a preset deviation threshold, the interface node will be marked as an abnormal test node.

[0012] In one embodiment, the step of identifying interface dependency changes in the abnormal test node includes: Analyze the abnormal information of the abnormal test nodes; If the abnormal information is determined to be a call relationship not recorded in the interface call sequence diagram, or a call relationship existing in the interface call sequence diagram that was not triggered in this test, it is determined that the interface dependency relationship has changed.

[0013] Furthermore, to achieve the above objectives, this application also proposes an interface dependency resolution and automated testing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the interface dependency resolution and automated testing method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the interface dependency resolution and automated testing method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application extracts a minimum set of paths covering the complete business flow of a selected target medical business scenario from an interface call sequence diagram. Using this minimum set of paths as test paths, it analyzes the data dependencies between interfaces within each test path to extract data flow rules and generates test data based on these rules. The application then calls the interfaces of the test path according to the test data, verifies the response data of each interface, and generates an integrity verification result. The integrity verification result is compared with the expected behavior of the interface call sequence diagram, and abnormal test nodes are located based on the comparison result. Changes in interface dependencies within the abnormal test nodes are identified, and the interface call sequence diagram is updated based on these changes.

[0016] Through the above technical means, while maintaining the stability of multi-screen synchronization, the cross-slice alignment accuracy and interaction flexibility are significantly improved. The technical problems of field of view drift and scale mismatch under the conditions of inconsistent physical scale, inconsistent attitude coordinate system and fixed control source of existing numerical replication synchronization are solved. The technical leap of multi-screen interface dependency relationship parsing and automated testing is realized from numerical replication to physical scale alignment, from blind coordinate system to attitude adaptive compensation, and from fixed broadcast source to dynamic control source switching. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the interface dependency resolution and automated testing method of this application; Figure 2 This is a detailed process diagram based on step S10 in the first embodiment; Figure 3 This is a detailed process diagram based on step S20 in the first embodiment; Figure 4 This is a schematic diagram of another detailed process based on step S20 in the first embodiment; Figure 5 This is a detailed schematic diagram of step S30 in the first embodiment; Figure 6 This is a detailed schematic diagram of step S40 based on the first embodiment; Figure 7 This is a detailed process diagram based on step S50 in the first embodiment; Figure 8 This is a flowchart illustrating the second embodiment of the interface dependency resolution and automated testing method of the present invention; Figure 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the interface dependency resolution and automated testing method in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] In the field of interface testing for medical information systems, dependency mapping is often done manually by testers based on their understanding of the business processes, and the results are coded into fixed scripts. This approach can achieve basic interface test coverage at a relatively low implementation cost in stable environments where the number of interfaces is limited and the business logic remains unchanged over a long period. However, this approach essentially employs a "static coding, manual maintenance" dependency management paradigm.

[0023] First, the definition of dependencies is tightly coupled with test scripts. When medical business logic changes, testers must manually re-examine the change chain and modify the scripts one by one. For large medical institutions with hundreds or thousands of interfaces, this maintenance method is slow and prone to oversights. Second, the static coding of dependencies isolates testing activities from the medical business scenario. Testing often degenerates into verifying independent fields of individual interfaces. Even if all individual interface tests pass, it cannot guarantee the correct execution of the complete "registration, prescription, payment, and medication dispensing" business loop. Third, test data preparation is scattered across various test cases. There is a lack of a unified data management mechanism between interface tests. Cross-interface process tests struggle to obtain consistent and reusable data, leading to prominent data silos. Even when some solutions attempt to organize tests based on application scenarios, the determination of dependencies still relies on manual methods, lacking the ability to automatically analyze interface call logs to dynamically parse and update dependencies.

[0024] A comprehensive analysis reveals that the core dilemma faced by the aforementioned technical approaches lies in the fact that while the testing method, which relies on manually identifying dependencies and using static scripts, is simple to implement and has a low learning curve, its characteristics of dependency definition being disconnected from business changes, test scenarios being separated from real business flows, and test data being isolated from cross-interface requirements, fundamentally contradict the inherent requirements of medical information systems for dynamic adaptation of dependencies, scenario-based coverage of business flows, and consistency of cross-interface data. This makes it impossible to simultaneously achieve dynamic updates, scenario-based coverage, and unified data management while maintaining test accuracy.

[0025] Based on the aforementioned shortcomings, this application proposes a method for dynamic resolution and automated testing of interface dependencies in medical information systems. This method addresses the core pain points of high maintenance costs and insufficient scenario coverage under business change conditions caused by manually sorting dependencies. It constructs an automated testing system through the coordinated efforts of dynamically building interface call sequence diagrams, semantic annotation of business scenarios, and automatic extraction of data flow rules. This system enables dynamic resolution of dependencies, scenario-based generation of test paths, and unified management of test data. Specifically, the method automatically constructs interface call sequence diagrams from real call logs using a sequence pattern mining algorithm, replacing manual sorting. Semantic role annotation is applied to sequence diagram nodes based on medical business scenario definitions, upgrading interface testing from single-point verification to business flow verification. The method extracts the minimum coverage path from the sequence diagram according to the target scenario and parses the data mapping rules between upstream and downstream interfaces, driving the generation of test data that satisfies dependency constraints. During execution, field-level responses and data transmission integrity are dually verified, and the result analysis automatically distinguishes between interface function anomalies and dependency changes.

[0026] Through the above-mentioned technical means, this application significantly reduces maintenance costs and improves business scenario coverage while maintaining test accuracy. It solves the technical problems of high maintenance costs and insufficient coverage caused by manually sorting out dependencies under conditions of slow response to business changes, fragmented test scenarios and scattered test data. It realizes the technical leap of medical information system interface testing from static coding to dynamic parsing, from single interface verification to business flow closed-loop verification, and from data silos to dependency-driven unified generation.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] Based on this, embodiments of this application provide a method for interface dependency resolution and automated testing, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the interface dependency resolution and automated testing method of this application. In this embodiment, the interface dependency resolution and automated testing method includes steps S10-S60: Step S10: Based on the selected target medical business scenario, extract the minimum set of paths that cover the complete business flow of the target medical business scenario from the interface call sequence diagram; In the daily operation of a healthcare information system, API calls do not occur randomly but strictly follow a specific business process sequence. For example, a typical outpatient dispensing process involves four core steps: registration, doctor's prescription, outpatient payment, and pharmacy dispensing. Each step corresponds to one or more API calls, and the triggering of subsequent APIs depends on the successful execution of preceding APIs. Therefore, to effectively test such business processes, it is necessary to take a holistic approach and obtain a complete call chain that connects all necessary steps.

[0029] To achieve the above objectives, the first step is to obtain the target medical business scenario selected by the testers based on the current testing requirements. This target medical business scenario is input in the form of natural language or predefined scenario labels, such as "outpatient payment and medication dispensing process" or "sample receipt to report push process." This target medical business scenario clearly defines the scope of business activities to be covered in this test, and its core is to indicate which business steps are necessary to complete the scenario. Taking "outpatient payment and medication dispensing process" as an example, the necessary business steps in this scenario are registration, prescription issuance, payment, and medication dispensing, in that order.

[0030] After identifying the target healthcare business scenario, the minimum set of paths covering the complete business flow of that scenario is extracted from a pre-built interface call sequence diagram. This interface call sequence diagram is a directed graph structure with interfaces as nodes and the call relationships between interfaces as directed edges. Each node has been semantically labeled, meaning each interface node is assigned a clear business semantic label, such as registration interface, invoice issuance interface, payment interface, and medication dispensing interface. This semantic role labeling establishes a mapping bridge between the technical interface identifiers in the interface call sequence diagram and the business activities that are understandable to business personnel.

[0031] The core processing logic for extracting the minimum path set is as follows: Based on the target medical business scenario, determine the set of all mandatory semantic role nodes required to complete the target medical business scenario. Under the constraint of taking the starting semantic role node of the scenario as the starting point and the ending semantic role node as the ending point, perform path search based on the semantically annotated interface call sequence graph. During the search, traverse all possible paths from the starting node to the ending node in the interface call sequence graph, and use whether the semantic role nodes contained in the path completely cover all mandatory semantic role nodes as the filtering condition. Among all candidate paths that meet the coverage condition, further optimize based on path length, eliminating those paths that contain redundant jumps or repeatedly pass through the same business link, and finally retaining one or more paths that can cover all mandatory business links with the shortest call chain.

[0032] Taking the aforementioned "outpatient payment and medication dispensing process" as an example, the interface call sequence diagram may contain multiple paths starting from the registration interface and ultimately reaching the medication dispensing interface. One path might directly jump to medication dispensing after registration, but this path lacks the two mandatory steps of prescription issuance and payment, thus failing to meet the coverage condition. Another path might sequentially go through registration, prescription issuance, payment, medical insurance settlement, and medication dispensing. Although it covers all mandatory steps, the medical insurance settlement step is not mandatory in this scenario, resulting in redundant nodes. By traversing and comparing all candidate paths, the final minimum set of paths selected is the shortest and most complete call chain: registration interface to prescription issuance interface, prescription issuance interface to payment interface, and payment interface to medication dispensing interface.

[0033] This minimum set of paths is the test path used in subsequent steps. It clearly defines the order of interface calls in this test and also indicates the data transfer relationship between adjacent interfaces, providing a structured path skeleton for subsequent data dependency resolution and test data generation.

[0034] Step S20: Use the minimum path set as the test path, parse the data dependency relationship between each interface in the test path to extract data flow rules, and generate test data based on the data flow rules; Using the minimum path set as the test path, the data dependencies between interfaces within the test path are analyzed to extract data flow rules, and test data is generated based on these rules. The obtained minimum path set clarifies the interfaces that need to be called sequentially in this test and their calling order. However, the calling order alone is insufficient to support the actual test execution, because the interfaces in the medical business process are not independent of each other; the output data of upstream interfaces often directly constitutes the required input parameters of downstream interfaces. For example, the patient identifier and visit serial number returned after a successful registration interface call are crucial parameters that the subsequent prescription interface must carry when submitting medical orders; similarly, the prescription identifier and cost details returned by the prescription interface are the basis for the payment interface's settlement operation. Therefore, to ensure the test can proceed smoothly, the data dependencies between the aforementioned interfaces must be fully analyzed before test execution.

[0035] First, the aforementioned minimum path set is used as the test path. The data dependencies between interfaces within this test path are analyzed one by one, and data flow rules are extracted accordingly. The analysis begins with examining each group of adjacent interfaces in the test path that have a direct call relationship. For the predecessor interface, its response data structure definition is obtained, including metadata information such as field names, data types, and meanings of each field in the response message. For the successor interface, its request parameter structure definition is obtained, similarly including parameter names, data types, and constraints such as whether each parameter is required.

[0036] After acquiring the aforementioned metadata, a mapping relationship is established between the response fields of the predecessor interface and the request parameters of the successor interface by comparing them. This comparison process is not a simple name match, but rather a comprehensive application of various methods, including semantic similarity calculation of field names, consistency verification of data types, and pre-defined parameter tag matching rules. For example, although the "Patient Identifier" field in the registration interface response and the "Patient Primary Key" parameter in the invoicing interface request are not entirely identical in name, semantic tag matching can identify that they point to the same business entity. Similarly, an accurate mapping relationship can be established between the "Medical Visit Serial Number" field in the registration interface response and the "Medical Visit Sequence Number" parameter in the invoicing interface request.

[0037] The process iterates through all adjacent interface pairs in the test path, integrating the established mapping relationships to form a complete data flow rule covering the entire test path. This data flow rule clearly defines how test data flows and is transmitted between interfaces: which parameters need to be provided with initial values ​​externally when the test starts, which parameters can be extracted from the response of the upstream interface and automatically populated into the request of the downstream interface, and which parameters need to be recalculated or transformed based on the return result of the upstream.

[0038] After the data flow rules are extracted, the test data generation phase begins. The generation process proceeds sequentially according to the interface order in the test path. First, the request parameters of the first interface in the test path are identified. Based on the data flow rules, it is determined which parameters are initial parameters—those that cannot be obtained from any upstream interface and need to be actively generated. For these initial parameters, initial test data that meets the requirements is generated based on their data type, value range, format constraints, and other conditions.

[0039] After calling the first interface using the initial test data and obtaining its response data, the business entity identifiers that need to be reused in subsequent interfaces are extracted from the response data. Based on the mapping relationships established in the data flow rules, these business entity identifiers are assigned to the corresponding parameter fields of the next interface request. Combined with the interface's own constraints on the other parameters, the complete request data for that interface is generated. For example, the patient identifier and medical record number extracted from the registration interface response are automatically filled into the request parameters of the invoice issuance interface. Meanwhile, parameters unrelated to the upstream, such as the medical order type and drug code required by the invoice issuance interface, are independently generated by the system according to their respective constraint rules.

[0040] The above process proceeds interface by interface along the test path. Each time an interface call is completed and a response is received, the data that needs to be passed downstream is extracted, assigned to the corresponding parameters of subsequent interfaces according to the mapping rules, and any other necessary parameters are generated, until the request data for the last interface is ready. Through this step-by-step extraction, dynamic filling, and on-demand generation method, the final test dataset ensures that the same business entity identifier remains consistent across all interfaces in the entire test path, thus meeting the data continuity requirements of cross-interface testing.

[0041] Step S30: Call the interface of the test path according to the test data, verify the response data of each interface, and generate an integrity verification result; After the test path and data dependency rules are ready, and the test data that meets the dependency constraints has been generated, the actual automated test execution phase begins. The test execution process strictly follows the interface call order defined in the test path, that is, starting from the starting interface of the test path, a call is initiated using the generated request data, and after obtaining a response, the next interface is called, until the terminating interface at the end of the path has been called.

[0042] For each interface in the test path, multi-dimensional response data verification is performed. The first verification dimension is field-level validation of the response message returned by the interface. This validation process first checks the protocol layer status of the response, including whether the status code indicates a successful call and whether the structure of the response message conforms to the interface specification definition. Next, according to the predefined response field rules of the interface, the existence of key business fields is verified one by one, that is, to confirm whether the response message contains all expected business fields. On this basis, the data type and value range of each key field are verified. For example, it is confirmed that the patient name field is a string and its length does not exceed the preset limit; the value of the payment amount field is within a reasonable business range and its precision meets the requirements; and the format of the timestamp field conforms to the standard time expression specification. If any of the above field-level validations fails, it will be recorded as a validation failure item for the corresponding interface.

[0043] The second verification dimension verifies the integrity of data transmission between interfaces. Based on the established mapping relationship, data consistency is checked for each group of adjacent interfaces during execution. Specifically, after the current interface call is completed and a response is obtained, the field values ​​that need to be passed down according to the data flow rules are extracted from the response, and these field values ​​are compared with the input parameter values ​​of the corresponding fields in the request parameters used when calling the next interface. For example, after the registration interface call is completed, the patient's serial number returned in its response is recorded; when the subsequent order placement interface call is executed, the patient's serial number value in the order placement interface request parameters is verified to be completely consistent with the previously recorded value. If they are consistent, the data transmission of that group of adjacent interfaces is considered complete; if there is a deviation or missing data, the exception is recorded as a data transmission integrity verification failure.

[0044] Based on the combined results of the multi-dimensional verifications, a structured integrity verification result was generated for this test. This integrity verification result records in detail the verification status of each interface in the test path, including whether the interface call was successful, details of the passed and failed items of field-level verification, the link-by-link results of data transmission integrity verification, and performance data such as the response time of each interface.

[0045] During test execution, interface call failures are inevitable. To address this, an automatic retry mechanism is built-in. When an interface call fails due to network timeout, temporary service unavailability, or other reasons, it is not immediately considered a final failure. Instead, multiple retries are automatically initiated according to a preset number of retries and retry intervals. If the interface call succeeds within the specified number of retries, subsequent interfaces continue execution, and the number of retries and the final successful result are recorded. If all retries fail, the interface is marked as a failure node, its request parameters, response error codes, and exception information are recorded, and the failure information is written into the integrity verification result. For subsequent interfaces after the failure node, since upstream data may not have been successfully generated or returned, they are marked as interfaces skipped due to preceding failures, and the reason for skipping is noted in the integrity verification result. Through this meticulous execution recording and multi-level verification mechanism, the integrity verification result provides a complete data foundation for subsequent anomaly analysis and localization.

[0046] Step S40: Compare the integrity verification result with the expected behavior of the interface call sequence diagram, and locate the abnormal test node based on the comparison result; After the automated test is completed, a structured integrity verification result is obtained, detailing the entire test execution process. This verification result reflects the actual performance of each interface in this test; however, the recorded failure or exception information only presents the surface phenomena and cannot yet determine whether these exceptions are caused by occasional external factors or actually point to system defects or substantial changes in interface dependencies. To distinguish between these different situations and achieve precise location, the integrity verification result is systematically compared with the expected behavior implied in the interface call sequence diagram.

[0047] The API call sequence diagram is constructed based on a large amount of historical API call logs. Its directed edges not only represent the call relationships between APIs, but also include behavioral statistics such as call frequency, average response time, and distribution of common response status codes. These statistical features, derived from historical data, constitute a quantitative description of the expected behavior patterns of each API node under normal business scenarios. The comparative analysis shown uses the historical statistical features as a reference benchmark.

[0048] During the comparison process, the historical normal behavior characteristics of each interface node covered by the test path were first extracted from the interface call sequence diagram. These characteristics included the frequency of the interface being called in historical calls, the distribution of its successful response status codes, the average response time range under different concurrency conditions, and the typical data transmission patterns between the interface and its adjacent interfaces. Subsequently, the above historical normal behavior characteristics were compared item by item with the integrity verification results generated by this test execution.

[0049] For comparing API call success rates, check whether each API was successfully called during this test. If an API in the test path is recorded as a failed call in the integrity verification results, but this API has a high historical call frequency and stable successful responses in the API call sequence diagram, then this failure is considered an abnormal deviation, and this API will be marked as an abnormal test node. Conversely, if an API is successfully called, but its response time far exceeds the upper limit of the historical average response time range, this also constitutes a behavioral deviation and may also be marked as an abnormal test node with degraded response performance.

[0050] The comparison of inter-interface call relationships verifies whether the actual order of interface calls during this test matches the call relationships recorded in the interface call sequence diagram. A directed edge between two nodes in the interface call sequence diagram indicates a stable call relationship between them in historical business operations. If a call jump not recorded in the interface call sequence diagram occurs during this test, or if a call relationship that originally existed in the interface call sequence diagram is not triggered in this test, it indicates a deviation between the actual execution of the test path and the historical behavior pattern. The corresponding node will be marked as a test node with abnormal call relationships.

[0051] After summarizing all the abnormal test nodes marked in the above comparison process, an abnormal test node set is formed. Each abnormal test node is then appended with information about its deviation type and degree, such as whether it belongs to call failure deviation, response time deviation, or call relationship deviation, as well as the specific numerical value of the deviation. By systematically comparing the actual test execution results with historical behavior baselines, this method automatically and accurately filters out truly abnormal or potentially risky problem nodes from massive test logs. This clearly defines the scope of root cause analysis for the next stage, avoiding the significant waste of manpower and time from blindly searching through all test logs.

[0052] Step S50: Identify changes in interface dependency relationships in the abnormal test nodes, and update the interface call sequence diagram based on the changes in interface dependency relationships.

[0053] By comparing the integrity verification results with the expected behavior of the interface call sequence diagram, the abnormal test nodes in this test have been successfully located and their deviation types have been preliminarily classified. However, the occurrence of abnormal test nodes may stem from a variety of different reasons, such as functional defects in the tested interface code itself, network fluctuations in the test environment causing interface call timeouts, or actual design changes in the interface call chain of the business system. Different types of causes correspond to completely different responsible parties and handling processes. If the root cause of the anomaly cannot be accurately identified, subsequent troubleshooting and repair work will be difficult to carry out efficiently.

[0054] In the aforementioned abnormal test nodes, it is necessary to identify anomalies caused by changes in interface dependencies. These changes refer to structural alterations in the interface call chain of the business system, such as additions, deletions, or reordering. These changes cause the dependencies described in the original interface call sequence diagram to no longer match the actual situation. The primary step in this identification process is to conduct an in-depth analysis of the failure modes of the abnormal test nodes.

[0055] When an abnormal test node is marked as a failed call, a thorough examination of the call chain preceding the failed interface call is conducted. If the failed interface is found to be called in the current test path, but this call relationship does not exist as a directed edge in the original interface call sequence graph—meaning the current test triggered a call path not found in the historical logs—it can be determined as a newly added call relationship. For example, in the aforementioned outpatient payment and dispensing process, if a new call to the medical insurance settlement interface is added after the payment interface, and the original interface call sequence graph does not contain a directed edge from the payment interface to the medical insurance settlement interface, then this node is not included in the test path. The actual business system automatically triggers the medical insurance settlement call after payment is completed, causing the upstream data received by the subsequent dispensing interface in the test to be inconsistent with expectations, thus triggering an anomaly. By comparing the existing directed edges in the failed link, the call to the medical insurance settlement interface is identified as a newly added call relationship.

[0056] When an abnormal test node exhibits a deviation in the call relationship, meaning the comparison results indicate that a directed edge that originally existed in the interface call sequence diagram was not triggered in this test, the execution trajectory of this test path needs further examination. If this untriggered call relationship does not reappear in multiple repeated tests, and the timestamps of the corresponding historical call logs are concentrated in an earlier time period, it indicates that the call relationship may have been abandoned or replaced in the actual business process. Such cases will be judged as deleting the call relationship.

[0057] When an abnormal test node consistently fails data transmission integrity verification across multiple rounds of testing, and the failures are concentrated between two interfaces that were originally in a call relationship, but the actual call order of these two interfaces in the current test path is reversed or inconsistent with the previous order, it is determined that the call order has been changed. For example, if the original sequence of calling the report generation interface first and then the report push interface has been changed to push first and then generate, causing the push interface to be triggered before the generation is completed and thus unable to obtain valid data.

[0058] The identification results of the aforementioned interface dependency changes will be categorized and summarized into structured change records containing the change type, involved interface nodes, discovery time, and associated anomaly information. Based on these change records, the interface call sequence diagram will be updated in a targeted manner: for newly added call relationships, corresponding directed edges will be added to the sequence diagram and their weights will be initialized; for deleted call relationships, the corresponding directed edges will be marked as invalid or removed from the diagram; for changes in call order, the direction of the relevant directed edges will be adjusted or the topological order of the involved nodes will be rearranged. After the update is completed, the system will synchronously trigger an automatic refresh mechanism for the test path, using the updated interface call sequence diagram as the new baseline to ensure that the dependency descriptions used in subsequent test executions are consistent with the actual business system.

[0059] Furthermore, you can also view Figure 2 , Figure 2 This is a detailed process diagram based on step S10 in the first embodiment. Figure 2 The step of extracting the minimum set of paths covering the complete business flow of the selected target medical business scenario from the interface call sequence diagram includes S11~S13: Step S11: Based on the target medical business scenario, determine all the required semantic role nodes needed to complete the target medical business scenario; Step S12: In the interface call sequence diagram, with all the required semantic role nodes as constraints, the shortest directed path from the starting semantic role node to the ending semantic role node is calculated by a path search algorithm. Step S13: Use the shortest directed path as the minimum set of paths that covers the complete business flow of the target medical business scenario.

[0060] In the semantically annotated interface call sequence diagram, each interface node has been assigned a clear business semantic role label, such as registration interface, invoice issuance interface, payment interface, and medication dispensing interface. This semantic annotation enables the system to understand the structure of the interface call sequence diagram at the business level, thus allowing testers to directly select test targets using business language. However, a complete medical business scenario often involves multiple business steps, each of which may correspond to multiple candidate interface nodes in the diagram, and there may be multiple different call paths from the starting step to the ending step. Therefore, a systematic method is needed to automatically extract the call chain from the diagram that can fully cover all necessary steps of the target scenario and has the shortest path length.

[0061] The first step in the extraction process is to determine all the mandatory semantic role nodes required to complete the selected target medical business scenario. The target medical business scenario is selected by the testers before the test begins, such as "outpatient payment and medication dispensing process" or "sample reception to report push process." This target scenario defines the scope of business activities expected to be covered in this test through a business semantic description. The description of the target scenario is parsed and mapped to a pre-defined medical business process template, thereby determining all the business activity nodes corresponding to this scenario in the template. Taking the "outpatient payment and medication dispensing process" as an example, the mandatory activity nodes corresponding to this scenario are, in order, "registration," "invoice issuance," "payment," and "medication dispensing." These four business activities are indispensable links in completing the closed loop of the outpatient payment and medication dispensing business; the absence of any one of them will result in an incomplete business flow. These four business activity nodes constitute the set of mandatory semantic role nodes for this scenario. It is worth noting that the determination of mandatory semantic role nodes does not concern itself with how many interface nodes each role corresponds to in the interface call sequence diagram, but only with which semantic roles must be covered at the business level for this scenario.

[0062] After determining the set of required semantic role nodes, the path search phase begins. The search operation unfolds within the semantically annotated interface call sequence diagram, with the inclusion of all required semantic role nodes as the core constraint. First, the starting and ending semantic role nodes for the target scenario are located in the interface call sequence diagram. The starting semantic role node corresponds to the first business activity in the business process, such as the "registration" role in the "outpatient payment and dispensing process"; the ending semantic role node corresponds to the last business activity in the business process, such as the "dispensing" role. It's important to note that the starting or ending semantic role may correspond to multiple interface nodes in the interface call sequence diagram. For example, there may be multiple interfaces with the "registration" semantic role, each corresponding to different departments or different registration methods. All interface nodes corresponding to the starting semantic role are included in the candidate starting node set, and all interface nodes corresponding to the ending semantic role are included in the candidate ending node set.

[0063] Subsequently, a path search algorithm is used to search for paths between the aforementioned candidate start node set and candidate end node set. The path search algorithm traverses all possible paths from each candidate start node to each candidate end node in the interface call sequence graph. For each candidate path found, the semantic role labels of all nodes traversed by the path are checked to determine whether the union of these semantic roles completely covers all the required semantic role nodes for the target scenario. If a candidate path is missing a required semantic role—for example, a path directly jumping from the registration node to the dispensing node lacks corresponding nodes for the required roles of "invoice issuance" and "payment"—then the path does not meet the coverage condition and is eliminated. Among all candidate paths that meet the complete coverage condition, further selection is made based on path length. Path length is measured by the number of directed edges contained in the path; fewer edges indicate a shorter call chain. All candidate paths that meet the coverage condition are sorted by length, and the path with the fewest edges is selected as the final result. If there are multiple paths of the same length that are all the shortest, the path with the largest sum of edge weights is selected based on the weight information of the directed edges in the interface call sequence diagram. This is because edge weights represent the frequency of historical calls, and higher weights mean that the call chain is more stable and reliable in actual business operations.

[0064] Through the above search and filtering process, the shortest directed path is determined as the minimum set of paths covering the complete business flow of the target medical business scenario. This minimum path set is presented as an ordered sequence of interface nodes. The first node in the sequence is the specific interface node corresponding to the starting semantic role, the last node is the specific interface node corresponding to the ending semantic role, and the intermediate nodes correspond to the specific interface nodes of other required semantic roles in the target scenario. This minimum path set also clarifies the directed call relationships between the nodes, providing a precise path skeleton for subsequent test path definition, data dependency resolution, and test data generation.

[0065] Furthermore, you can also view Figure 3 , Figure 3 This is a detailed process diagram based on step S20 in the first embodiment. Figure 3 The steps for parsing the data dependencies between interfaces in the test path and extracting data flow rules include S21~S23: Step S21: Locate each group of adjacent interfaces with a direct calling relationship in the test path, and obtain the response parameter set of the predecessor interface and the request parameter set of the successor interface in the adjacent interfaces. Step S22: Compare the parameter names and parameter labels in the response parameter set and the request parameter set, and create a mapping relationship between the output parameters and the input parameters based on the comparison results; Step S23: Integrate the mapping relationship of the adjacent interfaces to generate data flow rules covering the test path.

[0066] In this embodiment, the minimum set of paths is used as the test path, and the calling order of each interface within the test path is clearly defined. However, the calling order alone is insufficient to support the automatic generation of test data, because there are strict parameter passing relationships between medical business interfaces, and the return results of upstream interfaces directly constitute the required input items for downstream interfaces. If this data-level dependency relationship cannot be fully parsed, the subsequently generated test data will cause interface calls to fail due to missing or mismatched parameters. Therefore, before generating the aforementioned test data, it is necessary to systematically analyze the data dependencies within the test path and extract them into structured data flow rules.

[0067] To construct the aforementioned data flow rules, it is first necessary to locate adjacent interfaces with direct call relationships in each group within the test path. A direct call relationship refers to two interfaces that are adjacent in the call sequence of the test path and connected by a directed call edge, where the caller is the predecessor interface and the callee is the successor interface. Taking the test path corresponding to the outpatient payment and dispensing process as an example, the registration interface and the invoice issuance interface form a pair of adjacent interfaces, with the registration interface being the predecessor and the invoice issuance interface the successor; similarly, the invoice issuance interface and the payment interface form another pair of adjacent interfaces. Traversing the test path from the starting interface to the ending interface, all interface pairs satisfying the above adjacent conditions are marked one by one, serving as the basic analysis unit for data dependency resolution.

[0068] For each pair of adjacent interfaces, the response parameter set of the predecessor interface and the request parameter set of the successor interface are obtained. The response parameter set of the predecessor interface comes from the interface definition document or response message metadata of that interface, which records all field information returned by the interface after a successful call, including the field name, data type, field meaning description, and field tag. The request parameter set of the successor interface also comes from its interface definition, recording all parameter information expected to be received when the interface is called, including the parameter name, data type, whether it is required, and semantic tag of each parameter. Obtaining the above information provides a complete metadata foundation for establishing subsequent mapping relationships.

[0069] After obtaining the aforementioned response and request parameter sets, the two are compared to establish a mapping relationship between output and input parameters. This comparison process goes beyond simple string-level name matching; it employs multiple matching strategies to ensure the accuracy and comprehensiveness of the mapping. The first layer of matching strategy is parameter tag matching. It checks whether the field tags of the preceding interface's response parameters and the parameter tags of the subsequent interface's request parameters point to the same business concept. For example, if the preceding interface's response field tag is "patient identifier" and the subsequent interface's request parameter tag is "patient primary key," although the names are different, the business meanings indicated by the tags are consistent, thus establishing a mapping relationship. The second layer of matching strategy is semantic similarity matching. For parameters that fail to establish a mapping in the first layer of tag matching, the system calculates the semantic vector similarity of their names. When the similarity exceeds a preset threshold, they are determined to be the same business entity, and a mapping is established. The third-layer matching strategy is data type consistency verification. After completing name or label matching, it further verifies whether the data types of the predecessor output field and the successor input parameter are compatible. If the data types can be converted without loss of quality, the mapping relationship is valid; if the data types conflict and cannot be automatically converted, the mapping relationship is marked as a pending mapping requiring manual confirmation. Through the combined application of the above multi-layer matching strategies, a clear mapping relationship list from upstream output parameters to downstream input parameters is established for each pair of adjacent interfaces.

[0070] After establishing the mapping relationships between all adjacent interface pairs, these mapping relationships scattered across various groups of adjacent interfaces are integrated to form a complete data flow rule covering the entire test path. This data flow rule uses the interface call order of the test path as a timeline, describing the complete link of data transmission between interfaces: from which output field of which interface the data originates, in which input parameter of which subsequent interface the data is used, and whether the data requires type conversion or numerical transformation during transmission. The data flow rule also marks the source of each input parameter for each interface in the test path: which parameters are initial parameters, requiring external input at test startup; which parameters are transmitted parameters, their values ​​originating from a specified output field of a specified upstream interface; and which parameters are calculated parameters, their values ​​obtained by processing upstream data through specific conversion functions. Through this layer-by-layer analysis and systematic integration of data dependencies in the test path, the generated data flow rule provides precise parameter assignment paths and complete constraints for the automated generation of subsequent test data.

[0071] Furthermore, you can also view Figure 4 , Figure 4 This is a schematic diagram of another detailed process based on step S20 in the first embodiment. Figure 4 The steps for generating test data based on the data flow rules include S24~S28: Step S24: Based on the data flow rules, identify the request parameters and constraints of the initial interface in the test path, and generate initial request data that meets the constraints; Step S25: Invoke the initial interface through the initial request data, and extract the business entity identifier to be transmitted from the response data of the initial interface; Step S26: Match the business entity identifier with the mapping relationship in the data flow rule to determine the business entity identifier based on the target parameter field in the next interface request; Step S27: Assign the business entity identifier to the target parameter field, and generate the complete request data for the next interface in combination with the constraints of the next interface; Step S28: Traverse all adjacent interfaces in the test path and repeatedly perform the business entity identifier extraction and target parameter field assignment operations until a test dataset covering the entire path and satisfying the upstream and downstream data dependencies is generated.

[0072] After the data flow rules are extracted, the data source of each input parameter for each interface in the test path is clearly defined: it may be an initial parameter from external input, a parameter passed from a specified output field of a specified upstream interface, or a calculated parameter based on upstream data. The generation of test data involves generating complete request data that conforms to all parameter constraints for each interface sequentially, from the starting interface to the ending interface, according to the aforementioned data flow rules and the interface call order of the test path. During this process, it is ensured that the business entity identifier passed across interfaces remains consistent throughout the entire test path.

[0073] The first step in the generation process is to identify and process the initial interface in the test path. The initial interface is the first interface called in the test path; all input parameters of this interface are initial parameters and cannot be obtained from any upstream interface. Based on the constraints described in the data flow rules for each request parameter of this initial interface, parameter values ​​that meet the requirements are generated one by one. These constraints include: parameter data type requirements (e.g., string, integer, or floating-point); parameter format constraints (e.g., dates must conform to a specified year-month-day format, or encoding must conform to a specific encoding system); parameter value range constraints (e.g., numerical values ​​must be between a specified minimum and maximum value, or enumerated values ​​must be in a preset list of optional values); and parameter non-empty constraints (parameters marked as required cannot be empty). Combining these constraints, the corresponding data generation strategy is invoked to assign values ​​to each initial parameter, thereby generating the complete initial request data for the initial interface.

[0074] After obtaining the initial request data, the initial interface is invoked using this data, and the response data returned by the initial interface is received. From the response data, based on the mapping relationship established in the data flow rules, the business entity identifiers that need to be passed to subsequent interfaces are precisely extracted. These business entity identifiers are core identifiers in the medical business process, such as the patient identifier and visit serial number returned by the registration interface, the prescription identifier returned by the prescription issuance interface, and the settlement slip number returned by the payment interface. The common characteristic of these identifiers is that they are unique identifiers throughout the entire business process, and all subsequent steps must use the same identifier to ensure the consistency and traceability of business data.

[0075] After extracting the aforementioned business entity identifiers, they are matched against the pre-established mapping relationships in the data flow rules to determine the target parameter field corresponding to each business entity identifier in the next interface request. For example, the patient identifier extracted from the registration interface response, after matching according to the mapping relationship, is determined to have the patient primary key parameter as its corresponding target parameter field in the order placement interface request parameters; the extracted medical visit serial number is determined to have the medical visit sequence number parameter as its corresponding target parameter field in the order placement interface request. The purpose of this matching operation is to clarify the source of the value of each transmitted parameter in the next interface, thereby establishing a value assignment channel for data to flow from the predecessor interface to the successor interface.

[0076] After determining the target parameter field, an assignment operation is performed, assigning the specific value of the extracted business entity identifier to the corresponding target parameter field in the next interface request. After this assignment operation is completed, all fields belonging to the passed parameters in subsequent interfaces have obtained values; however, fields belonging to initial parameters or calculated parameters still need further generation. The constraints of the next interface itself are checked, and for parameters that have not been assigned values, values ​​conforming to their own constraints are generated in the same way as the initial interface parameters. The values ​​of these two types of parameters are then merged to form the complete request data for the next interface.

[0077] Following the above process, the interface calls proceed sequentially along the test path: The current interface is called to obtain the response; the business entity identifiers that need to be passed down are extracted from the response; these identifiers are matched and assigned to the corresponding parameter fields of the next interface; and the remaining necessary parameters for the next interface are supplemented to form the complete request data for the next interface. This cyclical operation of "extraction—matching—assignment—supplementation and generation" traverses all adjacent interfaces along the test path until the request data for the terminating interface at the end of the test path is successfully generated. Through this step-by-step extraction, dynamic filling, and on-demand supplementation and generation method, the final test dataset covers all interfaces on the test path and ensures that the same business entity identifier remains consistent across all interfaces along the entire test path, thus meeting the stringent requirements for data continuity and consistency in medical business scenario testing.

[0078] Furthermore, you can also view Figure 5 , Figure 5 This is a detailed process diagram based on step S30 in the first embodiment. Figure 5 The step of verifying the response data of each interface and generating an integrity verification result includes S31~S33: Step S31: For each response message returned by the interface, verify the response status code, existence, data type and value range of the key business fields of the response message, and generate a field-level verification record based on the verification results; Step S32: For adjacent interfaces with direct data dependencies, verify whether the request parameters of the downstream interface in the adjacent interface are the corresponding fields of the response message of the upstream interface, and generate a data transmission verification record based on the verification result. Step S33: Integrate the field-level verification record and the data transmission verification record to generate a structured integrity verification result.

[0079] During automated test execution, the interfaces were called one by one according to the test path, and the response data of each interface was obtained. However, obtaining the response data is only the first step in test execution. The more critical task is to systematically verify this response data to determine whether the actual performance of each interface meets expectations and whether the data transmission between interfaces is correct.

[0080] The first step in the verification process is to perform field-level validation on the response messages returned by each interface, generating field-level validation records. This validation unfolds layer by layer across three dimensions. The first dimension is response status code validation, checking whether the protocol layer status code returned by the interface falls within the expected range of success status codes or business-defined acceptable status codes. When the status code falls outside the expected range, such as returning an internal service error status code instead of the expected success status code, regardless of the response message body, this call to the interface is judged as having an abnormal status, and the abnormal status code and its corresponding standard status description text are recorded in the field-level validation record. The second dimension is the existence validation of key business fields. Based on the response field definition specifications of the interface, each response message is checked to see if it contains all the key business fields marked as being returned. For example, the response specification for the registration interface requires it to return the patient identifier field and the medical record number field. If either of these fields is missing in the actual response, it is recorded as a field missing anomaly. The third dimension is the validation of field data types and value ranges. Each field in the response message is verified item by item to ensure its actual data type matches the defined data type, and its specific value falls within the reasonable business range for that field. For example, if the definition of the payment amount field requires it to be a fixed-point decimal with a positive value, and the response returns a negative number or a string, it is recorded as a data type error or a value range error. The validation results of these three dimensions are recorded field by field and dimension by dimension, summarizing to form the field-level validation record for this interface.

[0081] The second step in the verification process is to perform data transmission integrity verification on each group of adjacent interfaces with direct data dependencies, generating data transmission verification records. Based on this, a mapping relationship between output and input parameters is established between adjacent interfaces, clarifying which output field of the upstream interface is responsible for providing a value for which input parameter of the downstream interface. Based on this mapping relationship, post-verification is performed on each group of adjacent interfaces during execution. The specific verification method is as follows: after completing the call to the current interface and obtaining its response data, the actual values ​​of each field that needs to be passed down according to the mapping relationship in the response are recorded; when a subsequent interface is called and completes its request transmission, the actual input parameter values ​​of the corresponding received fields in the request parameters of the subsequent interface are back-checked to see if they are completely consistent with the previously recorded upstream output values. Taking the registration interface and the order placement interface as an example, if the registration interface returns a patient visit serial number of value A, while the order placement interface's request parameter for the patient visit sequence number is value B, then A and B are compared. If they are equal, the data transmission link is considered complete, and a pass record is generated. If they are not equal or the downstream parameter is empty, the data transmission integrity check is considered to have failed, and the upstream output value, the downstream actual input parameter value, and the difference between the two are recorded in the data transmission verification record. This verification operation traverses all adjacent interface pairs with direct data dependencies along the test path, forming a data transmission verification record covering the entire path.

[0082] After completing the verification of the above two stages and obtaining the field-level verification records and data transmission verification records, these two types of records are integrated to generate a structured integrity verification result. The integration process is organized around the interface call order of the test path, generating an independent verification result entry for each interface node. This entry includes the overall status of whether the interface call was successful, details of whether each field-level verification passed or failed, and the verification result of the data transmission link between this interface and the upstream interface.

[0083] Furthermore, for interfaces that triggered the automatic retry mechanism during execution and ultimately succeeded or ultimately failed, this entry also includes a record of the number of retries and the status of each call during the retry process. The integrity verification results generated in the above manner record the verification execution status of each interface throughout the entire test process in a unified hierarchical structure, providing directly traceable structured data input for subsequent anomaly localization and analysis.

[0084] Furthermore, you can also view Figure 6 , Figure 6 This is a detailed process diagram based on step S40 in the first embodiment. Figure 6 The steps of comparing the integrity verification result with the expected behavior of the interface call sequence diagram and locating abnormal test nodes based on the comparison result include S41~S43: Step S41: Extract the response pattern features of each interface node under historical normal call behavior from the interface call sequence diagram; Step S42: Calculate the difference between the actual response behavior of each interface in the integrity verification result and the corresponding historical response pattern characteristics; Step S43: If the result of the difference calculation exceeds a preset deviation threshold, then the interface node is marked as an abnormal test node.

[0085] After generating the integrity verification results, a detailed structured dataset recording the actual performance of each interface in this test was obtained. However, this integrity verification result records the performance of a single test run, and failures or deviations may be caused by various factors: the tested system may have experienced a substantial interface functional abnormality or dependency change, or it may be an occasional phenomenon caused by external factors such as temporary network jitter or momentary resource shortage in the test environment. If these two different types of anomalies cannot be distinguished, directly investigating all anomaly records will consume a lot of manpower and yield very little result. Therefore, it is necessary to introduce a stable and reliable behavioral benchmark. By comparing the actual results with this benchmark, truly worthy anomaly nodes for in-depth analysis can be selected.

[0086] The above comparison first requires extracting behavioral benchmarks from the interface call sequence diagram. The interface call sequence diagram is constructed based on a large amount of historical interface call logs. The diagram not only records the directed call relationships between interfaces, but each interface node and each directed edge also includes behavioral characteristic information statistically derived from massive amounts of historical data. Feature extraction is performed on this interface call sequence diagram to obtain the response pattern characteristics of each interface node covered by the test path under historical normal call behavior. The extracted response pattern features specifically include: the distribution of status codes in successful responses during historical calls, i.e., which status codes frequently appear under normal conditions; the statistical range of response time consumption for this interface under different historical time periods and different concurrency conditions, including average consumption time and a reasonable upper limit for consumption fluctuation; and the return rate of key business fields in historical calls, i.e., the statistical value of the frequency of each required field appearing in a large number of historical successful responses. These features collectively characterize the stable behavioral pattern formed by this interface during long-term operation.

[0087] After obtaining the historical response pattern characteristics, the difference calculation phase begins. The actual response behavior of each interface in the above integrity verification results is compared item by item with the corresponding historical response pattern characteristics. This comparison operation includes a multi-dimensional difference quantification process. In the status code dimension, it checks whether the actual status code returned by the interface in this test belongs to the common set of historical successful response status codes for that interface. If an abnormal status code that rarely or never appeared in history is actually returned, this difference is quantified as a high deviation value. In the response time dimension, the actual response time of the interface in this test is compared with the historical average time and reasonable fluctuation limit of that interface. If the actual time exceeds a certain multiple of the historical limit, the deviation value for this dimension is quantified according to the excess ratio. In the field return rate dimension, the system compares the fields actually returned by the interface in this test with the set of required fields that the interface has consistently returned in the past. If there are missing consistently returned fields or newly added abnormal fields, the deviation value is quantified according to the number of missing or added fields.

[0088] Corresponding deviation thresholds are preset for each of the above dimensions. When the calculated difference of an interface in any dimension exceeds its corresponding deviation threshold, the interface is marked as an abnormal test node. For example, if the historical reasonable fluctuation limit for the response time of a payment interface is three seconds, but the response time of the interface in this test reaches ten seconds, the deviation value exceeds the preset time deviation threshold, then the interface is marked as an abnormal test node with degraded response performance. As another example, if two of the five key fields that an interface has historically returned stably are missing in this test, and the deviation value exceeds the preset field missing deviation threshold, then the interface is marked as a field missing abnormal test node. For all marked abnormal test nodes, the system records the specific dimension and deviation value of the deviation, compiling them into an abnormal test node list to precisely define the analysis scope for subsequent root cause analysis.

[0089] Furthermore, you can also view Figure 7 , Figure 7 This is a detailed process diagram based on step S50 in the first embodiment. Figure 7 The steps for identifying changes in interface dependencies in the abnormal test nodes include S51~S52: Step S51: Analyze the abnormal information of the abnormal test node; Step S52: If the abnormal information is determined to be a call relationship not recorded in the interface call sequence diagram, or a call relationship existing in the interface call sequence diagram is not triggered in this test, it is determined that the interface dependency relationship has changed.

[0090] By comparing the integrity verification results with the historical response pattern characteristics of the interface call sequence diagram, a batch of abnormal test nodes in this test have been successfully located. The root causes of these abnormal test nodes are diverse: they may stem from functional errors caused by code defects in the tested interface itself, from momentary anomalies in the external environment during test execution, or from substantial design changes in the structure of the business system's interface call chain. Among these various possible root causes, changes in interface dependencies have the highest priority and independent handling process due to their involvement in system architecture changes, the need to trigger synchronous updates of test paths and sequence diagrams, and the requirement for cross-team coordination. Therefore, from the located abnormal test nodes, exceptions caused by changes in interface dependencies were specifically identified to accurately distinguish them from other types of exceptions.

[0091] The identification process begins with an in-depth analysis of the anomaly information associated with each abnormal test node. The integrity verification results and the generated list of abnormal test nodes already contain detailed anomaly information for each node, including its actual execution status in this test, the error code and description returned upon failure, and the specific deviation dimension and value compared to historical behavior patterns. The system extracts key fields from this anomaly information for analysis in this step: the node's position in the test path, whether calls between the node and its upstream and downstream interfaces actually occurred, the error type attribution when the node's call failed, and whether a corresponding directed call edge exists at the node's position in the interface call sequence diagram.

[0092] After extracting the aforementioned anomaly information, the system proceeds to the judgment phase. The first judgment path involves checking whether the call relationship actually triggered by the anomaly node in this test exists in the interface call sequence diagram. If an anomaly node is successfully called, and the call chain between it and its downstream interface actually occurs in this test, but this call chain does not exist as a directed edge in the interface call sequence diagram—that is, this test triggered a call relationship that has never been observed before—the system determines that the anomaly belongs to an interface dependency change, and the change type is a new call relationship. Taking the previously mentioned outpatient payment and medication dispensing process as an example, if in this test, the payment interface actually calls the medical insurance settlement interface first, and then the medical insurance settlement interface calls the medication dispensing interface, but the interface call sequence diagram only records a directed edge from the payment interface to the medication dispensing interface, and there is no edge from the payment interface to the medical insurance settlement interface, nor is there an edge from the medical insurance settlement interface to the medication dispensing interface, then the call relationship between the payment interface and the medical insurance settlement interface is determined to be a new call relationship.

[0093] The second path for judgment is to check whether the call relationships recorded in the interface call sequence diagram were actually triggered in this test. If there is a directed edge between two nodes in the interface call sequence diagram, indicating a historically stable call relationship, but in this test, after executing along the test path to the upstream node, the downstream node was not called, and the call relationship corresponding to the directed edge did not actually occur, and this failure to occur is consistently reproduced in multiple rounds of testing, then the anomaly is determined to be a change in interface dependency, specifically a deletion of the call relationship or a replacement of the call chain. For example, if the interface call sequence diagram records a directed edge from an order opening interface to an approval interface, but in this test, after the order opening interface is called, it directly jumps to the payment interface, and the approval interface is never called, then the call relationship related to the approval interface is determined to be a deleted call relationship.

[0094] For abnormal nodes identified as having changed interface dependencies, a structured change record is generated, containing the change type, identifiers of the involved predecessor and successor interfaces, a discovery timestamp, and associated anomaly information. This change record serves as the direct input for triggering the aforementioned interface call sequence diagram update operation. For other abnormal nodes identified as not having changed dependencies, such as those caused by interface malfunctions or environmental fluctuations, the system marks them as other anomaly types and outputs corresponding anomaly reports for different responsible teams to handle. Through the layer-by-layer analysis and classification of anomaly information described above, this step achieves the ability to accurately extract interface dependency change events from numerous abnormal nodes, providing a reliable trigger source for the automated update of the interface call sequence diagram.

[0095] Furthermore, you can also view Figure 8 , Figure 8 This is a flowchart illustrating the second embodiment of the interface dependency resolution and automated testing method of the present invention, based on the shown... Figure 8 Before the step of extracting the minimum set of paths covering the complete business flow of the selected target medical business scenario from the interface call sequence diagram, steps S60~S90 are also included: Step S60: Collect historical interface call logs, and divide the historical interface call logs into segments through a preset time window to identify target call sequences whose call frequency exceeds a preset threshold; Step S70: Using the interface as the node, and the call relationship in the target call sequence as the directed edge, with the call frequency as the edge weight, construct the interface call sequence graph; Step S80: Obtain a preset medical business process template, and match each node in the interface call sequence diagram with the semantic roles in the medical business process template; Step S90: Label each node with its corresponding business semantic role based on the matching results to obtain the interface call sequence diagram with completed semantic labeling.

[0096] Before extracting the minimum path set from the API call sequence diagram based on the selected target medical business scenario, it is necessary to first construct the API call sequence diagram and label its semantic roles. The API call sequence diagram is the data foundation of the entire method, carrying the call relationships and behavioral characteristics between interfaces mined from historical operational data. Without the structured knowledge provided by this preliminary step, subsequent test path extraction, data flow rule parsing, and abnormal behavior comparison cannot be carried out.

[0097] The first step in constructing an API call sequence diagram is to collect historical API call logs. API call records generated over a past period are obtained from the API gateway or API management platform of the medical information system. Each log record includes fields such as source API identifier, target API identifier, call timestamp, request parameters, response status code, and response time. Since the API call volume of medical information systems is typically very large—for example, a medium-sized hospital may generate hundreds of thousands of call records in a month—these records contain both stable call sequences reflecting core business processes and occasional abnormal calls, test calls, or one-off data synchronization calls. Therefore, effective filtering and pattern recognition of these raw logs are necessary.

[0098] The collected historical interface call logs are divided along a time dimension using preset time windows, segmenting the continuous call flow into call sequence fragments within several time windows. These time windows are determined based on the typical duration of medical business processes. For example, an outpatient process, from registration to medication dispensing, is typically completed within one hour; therefore, the time window can be set to an appropriate length to cover the interface call chain within a single business session as completely as possible. Within each time window, the frequency of each interface call sequence is counted, and a sequence pattern mining algorithm is used to identify high-frequency call sequences whose frequency exceeds a preset threshold. This preset threshold filters out occasional and atypical call patterns, retaining only stable and frequently occurring call sequences from historical operation as the basis for subsequent sequence diagram construction. These retained high-frequency call sequences are the target call sequences, representing stable business call patterns formed by the medical information system over long-term operation.

[0099] After obtaining the target call sequence, the process moves to the construction phase of the interface call sequence graph. The construction process uses interfaces as nodes in the graph, with each interface included in the target call sequence corresponding to an independent node. The call relationship between adjacent interfaces in the target call sequence is abstracted as directed edges in the graph. The direction of the directed edge represents the relationship between the initiator and receiver of the call, i.e., from the source interface node to the target interface node. For example, if the target call sequence frequently shows a pattern of the registration interface calling the order opening interface, a directed edge is created in the interface call sequence graph from the registration interface node to the order opening interface node. Each directed edge is weighted with a corresponding call frequency. This weight directly reflects the activity and dependence of the call relationship in historical operations; edges with higher call frequencies are more prominent in the graph, indicating that the call chain is more critical in the business process. Through this method, all target call sequences are merged into a unified directed graph structure, namely the interface call sequence graph. This diagram not only preserves the sequential information of a single call sequence, but also naturally merges shared nodes and branching paths in multiple sequences, presenting a complete picture of the interface call relationships in the entire medical information system.

[0100] After the interface call sequence diagram is constructed, each node in the diagram still represents a technical interface identifier, such as an interface path or service name. This is not convenient for business testers to understand and select test scenarios. Therefore, it is necessary to label the nodes in the diagram with business semantic roles. First, obtain a preset medical business process template. This template defines the sequence of business activities in various medical business processes, as well as the semantic role name corresponding to each business activity. For example, a typical outpatient dispensing process template contains four activity nodes: "Registration," "Invoice Issuance," "Payment," and "Dispensing." These semantic roles describe the medical business activities themselves, rather than technical interface names, and therefore can be directly understood and operated by business personnel.

[0101] Subsequently, each node in the interface call sequence diagram is matched with the semantic roles in the aforementioned medical business process template. The matching process comprehensively utilizes multi-dimensional information, including the node's interface name, functional keywords contained in the interface path, and the types of medical business entities involved in the interface request parameters and response data, to calculate similarity with the business characteristics of each semantic role in the template. For example, if an interface's path contains the keyword "registration," and its request parameters and response data involve the creation of patient information and medical record numbers, then this interface has a high degree of matching with the "registration" semantic role. Through this multi-dimensional matching mechanism, each node in the call sequence diagram is associated with the most matching semantic role in the medical business process template.

[0102] After labeling each node with its corresponding business semantic role based on the matching results, the interface nodes, originally named only by technical identifiers, are given semantic tags that business personnel can understand, generating a semantically annotated interface call sequence diagram. This semantically annotated interface call sequence diagram integrates information from two perspectives: first, the technical interface call relationships and their frequency weights automatically discovered through data mining; and second, the business activity role tags assigned through semantic matching. It is this fusion of dual information that allows subsequent testers to directly select the target scenario using business language such as "outpatient payment and medication dispensing process," while the system can accurately locate the corresponding set of interface nodes in the diagram based on semantic tags and perform the minimum path extraction operation accordingly.

[0103] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the interface dependency resolution and automated testing methods of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0104] This application provides an interface dependency resolution and automated testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the interface dependency resolution and automated testing method in Embodiment 1 above.

[0105] The following is for reference. Figure 9 The diagram illustrates a structural schematic suitable for implementing an interface dependency resolution and automated testing device according to embodiments of this application. The interface dependency resolution and automated testing device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 9 The interface dependency resolution and automated testing equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0106] like Figure 9As shown, the interface dependency resolution and automated testing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the interface dependency resolution and automated testing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the interface dependency resolution and automation testing equipment to communicate wirelessly or wiredly with other devices to exchange data. Although various interface dependency resolution and automation testing equipment are shown in the figure, it should be understood that implementation or possession of all of them is not required. More or fewer may be implemented alternatively.

[0107] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0108] The interface dependency resolution and automated testing equipment provided in this application, employing the interface dependency resolution and automated testing method described in the above embodiments, can solve the technical problems of high maintenance costs and inability to dynamically adapt to business changes caused by manual dependency analysis in medical information system interface testing. Compared with the prior art, the beneficial effects of the interface dependency resolution and automated testing equipment provided in this application are the same as those of the interface dependency resolution and automated testing method provided in the above embodiments, and other technical features in this interface dependency resolution and automated testing equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0109] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0110] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0111] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon. The computer-readable program instructions are used to execute the interface dependency resolution and automated testing method in the above embodiments.

[0112] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be executed by instructions, used by devices, or used in conjunction with them. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0113] The aforementioned computer-readable storage medium may be included in the interface dependency resolution and automated testing equipment; or it may exist independently and not be assembled into the interface dependency resolution and automated testing equipment.

[0114] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the interface dependency resolution and automated testing device, the interface dependency resolution and automated testing device implements the technical content of the interface dependency resolution and automated testing method embodiment shown above.

[0115] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0117] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0118] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described interface dependency resolution and automated testing method. This solves the technical problems in interface testing of medical information systems where manual dependency analysis leads to high maintenance costs and an inability to dynamically adapt to business changes. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the interface dependency resolution and automated testing method provided in the above embodiments, and will not be elaborated upon here.

Claims

1. An interface dependency resolution and automated testing method, comprising: The interface dependency resolution and automated testing method includes the following steps: Historical interface call logs are collected, and the logs are divided into segments using a preset time window to identify target call sequences with call frequencies exceeding a preset threshold. An interface call sequence diagram is constructed using interfaces as nodes and the call relationships within the target call sequence as directed edges, with call frequency as the edge weight. A preset medical business process template is obtained, and each node in the interface call sequence diagram is matched with a semantic role in the template. Based on the matching results, each node is labeled with its corresponding business semantic role, resulting in a semantically labeled interface call sequence diagram. Based on the selected target medical business scenario, extract the minimum set of paths that cover the complete business flow of the target medical business scenario from the interface call sequence diagram; The minimum path set is used as the test path. The data dependency relationship between each interface in the test path is parsed to extract the data flow rules. Test data is generated based on the data flow rules. Call the interfaces of the test path according to the test data, verify the response data of each interface, and generate integrity verification results; The integrity verification result is compared with the expected behavior of the interface call sequence diagram, and the abnormal test node is located based on the comparison result. Identify changes in interface dependencies in the abnormal test nodes, and update the interface call sequence diagram based on the changes in interface dependencies; The step of extracting the minimum set of paths covering the complete business flow of the selected target medical business scenario from the interface call sequence diagram includes: Based on the target medical business scenario, determine all the required semantic role nodes needed to complete the target medical business scenario; In the interface call sequence diagram, with all the required semantic role nodes as constraints, the shortest directed path from the starting semantic role node to the ending semantic role node is calculated by a path search algorithm. The shortest directed path is taken as the minimum set of paths that cover the complete business flow of the target medical business scenario.

2. The interface dependency resolution and automated testing method of claim 1, wherein, The steps for parsing the data dependencies between interfaces in the test path and extracting data flow rules include: Locate each group of adjacent interfaces with a direct calling relationship in the test path, and obtain the response parameter set of the predecessor interface and the request parameter set of the successor interface in the adjacent interfaces; Compare the parameter names and parameter labels in the response parameter set and the request parameter set, and create a mapping relationship between the output parameters and the input parameters based on the comparison results; The mapping relationships of the adjacent interfaces are integrated to generate data flow rules that cover the test path.

3. The interface dependency resolution and automated testing method as described in claim 2, characterized in that, The steps for generating test data based on the data flow rules include: Based on the data flow rules, identify the request parameters and constraints of the initial interface in the test path, and generate initial request data that meets the constraints; The initial interface is invoked through the initial request data, and the business entity identifier to be transmitted is extracted from the response data of the initial interface. The business entity identifier is matched with the mapping relationship in the data flow rules to determine the business entity identifier based on the target parameter field in the next interface request; Assign the business entity identifier to the target parameter field, and generate the complete request data for the next interface by combining the constraints of the next interface; Traverse all adjacent interfaces in the test path, repeatedly perform the business entity identifier extraction and target parameter field assignment operations until a test dataset covering the entire path and satisfying the upstream and downstream data dependencies is generated.

4. The interface dependency resolution and automated testing method as described in claim 1, characterized in that, The step of verifying the response data of each interface and generating an integrity verification result includes: For each response message returned by the interface, verify the response status code, existence, data type and value range of the key business fields of the response message, and generate field-level verification records based on the verification results; For adjacent interfaces with direct data dependencies, verify whether the request parameters of the downstream interface in the adjacent interface are the corresponding fields of the response message of the upstream interface, and generate a data transmission verification record based on the verification result. Integrate the field-level verification records and the data transmission verification records to generate a structured integrity verification result.

5. The interface dependency resolution and automated testing method as described in claim 1, characterized in that, The steps of comparing the integrity verification result with the expected behavior of the interface call sequence diagram, and locating abnormal test nodes based on the comparison result, include: Extract the response pattern characteristics of each interface node under historical normal call behavior from the interface call sequence diagram; The difference between the actual response behavior of each interface in the integrity verification result and the corresponding historical response pattern characteristics is calculated. If the result of the difference calculation exceeds a preset deviation threshold, the interface node will be marked as an abnormal test node.

6. The interface dependency resolution and automated testing method as described in claim 1, characterized in that, The steps for identifying changes in interface dependencies in the abnormal test nodes include: Analyze the abnormal information of the abnormal test nodes; If the abnormal information is determined to be a call relationship not recorded in the interface call sequence diagram, or a call relationship existing in the interface call sequence diagram that was not triggered in this test, it is determined that the interface dependency relationship has changed.

7. An interface dependency resolution and automated testing device, characterized in that, The interface dependency resolution and automated testing device stores a computer program, which, when executed by a processor, implements the interface dependency resolution and automated testing method according to any one of claims 1-6.

8. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the interface dependency resolution and automated testing method according to any one of claims 1-6.

Images