Automatic interface testing method and device, equipment and storage medium

Abstract

The invention discloses an automatic interface testing method and device, equipment and a storage medium, and relates to the technical field of interface test.The method comprises the steps that an interface calling request generated by a flow chart platform based on a flow chart case is responded, and the interface calling request carries interface calling parameters; performing case matching in a preset case database based on the interface calling parameters; obtaining target callback data of the current calling interface based on a case matching result; and in the verification execution stage, target callback data is obtained through the flow chart platform, and test result verification is performed based on the target callback data. The callback data of the interface can be obtained through the flow chart platform in the verification execution stage, and the test result verification is performed based on the callback data, so that the interface callback and verification can be separated, and the problems that the callback data of the native API of the client cannot be directly captured by an automatic test method in the prior art, and the test efficiency is high are solved. And instant verification cannot be carried out.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of interface testing, in particular to an interface automatic testing method, device, equipment and storage medium. BACKGROUND

[0002] In the field of software testing, automatic testing is the core means to ensure application quality. The current mainstream automatic testing scheme mainly focuses on HTTP interface, and the core logic is to simulate client requests, capture the instant response data (such as JSON or XML format) returned by the server, and perform result verification based on preset assertion rules.

[0003] With the rapid development of mobile ecology, the testing demand of client native API (Application Programming Interface) is increasingly prominent. However, client native API usually needs to be called in a real machine or simulator where APP (Application) has been installed, and the result is returned through asynchronous callback. The traditional automatic testing method cannot naturally process such asynchronous events, resulting in the inability to perform instant verification. SUMMARY

[0004] The main purpose of the present application is to provide an interface automatic testing method, device, equipment and storage medium, which aims to solve the technical problem that the automatic testing method in the prior art cannot directly capture the callback data of the client native API, resulting in the inability to perform instant verification.

[0005] To achieve the above purpose, the present application provides an interface automatic testing method, which comprises:

[0006] In response to the interface call request generated by the flowchart platform based on the flowchart case, the interface call request carries interface call parameters;

[0007] Case matching is performed in a preset case database based on the interface call parameters, and a case matching result is obtained;

[0008] Target callback data of the current call interface is obtained based on the case matching result;

[0009] In the verification execution stage, the target callback data is obtained through the flowchart platform, and the test result verification is performed based on the target callback data.

[0010] In an embodiment, the step of responding to the interface call request generated by the flowchart platform based on the flowchart case further comprises:

[0011] The user configuration node and the node type corresponding to the user configuration node are determined according to the user configuration information.

[0012] A flowchart example is generated based on the user configuration node and the node type;

[0013] The flowchart case is parsed using a flowchart platform to extract the interface call parameters from the flowchart case.

[0014] The flowchart platform generates an interface call request based on the interface call parameters.

[0015] In one embodiment, the step of performing case matching in a preset case database based on the interface call parameters to obtain case matching results includes:

[0016] The task name, interface name, and parameter configuration of the current calling task are determined based on the interface call parameters.

[0017] The task name, the interface name, and the parameter configuration are compared with test cases in the preset case database.

[0018] The case matching results for the currently invoked task are generated based on the joint comparison results.

[0019] In one embodiment, the step of obtaining the target callback data of the currently invoked interface based on the case matching result includes:

[0020] If the case matching result is a failure, a target test case is generated based on the interface call parameters;

[0021] The target test cases are stored in the preset case database to obtain the first updated case database;

[0022] Based on the interface call parameters, case matching is performed in the first updated case database;

[0023] When a match is successful, retrieve the target callback data for the currently invoked interface from the callback data repository.

[0024] In one embodiment, before the step of performing case matching in the first updated case database based on the interface call parameters, the method further includes:

[0025] The target callback data is associated with the interface call parameters and stored in the callback data repository.

[0026] In one embodiment, the step of obtaining the target callback data of the currently invoked interface based on the case matching result includes:

[0027] If the case matching result is a successful match, then obtain the matching test case;

[0028] Determine whether the callback data corresponding to the matching test case exists in the callback data repository;

[0029] If it exists, retrieve the callback data from the callback data repository and determine the callback data as the target callback data for the current calling interface.

[0030] In one embodiment, after the step of determining whether callback data corresponding to the matching test case exists in the callback data repository, the method further includes:

[0031] If it does not exist, then obtain the interface call auxiliary parameters of the currently invoked task;

[0032] The matching test case is updated by calling the auxiliary parameters based on the interface to obtain the updated test case;

[0033] The current API call is executed to obtain the target callback data, and the target callback data is associated with the API call parameters and stored in the callback data repository.

[0034] The preset case database is updated based on the updated test cases to obtain a second updated case database;

[0035] Based on the interface call parameters, case matching is performed in the second updated case database;

[0036] Upon successful matching, the target callback data is retrieved from the callback data repository.

[0037] Furthermore, to achieve the above objectives, this application also proposes an automated interface testing device, the device comprising:

[0038] The request and response module is used to respond to the interface call request generated by the flowchart platform based on the flowchart case, wherein the interface call request carries interface call parameters;

[0039] The case matching module is used to perform case matching in a preset case database based on the interface call parameters and obtain case matching results;

[0040] The data acquisition module is used to obtain the target callback data of the currently called interface based on the case matching result;

[0041] The interface testing module is used to obtain the target callback data through the flowchart platform during the verification execution phase, and to verify the test results based on the target callback data.

[0042] In addition, to achieve the above objectives, this application also proposes an automated interface 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 automated interface testing method described above.

[0043] 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 automated testing method described above.

[0044] This application provides an automated interface testing method. It discloses a method for responding to an interface call request generated by a flowchart platform based on flowchart cases, with the request carrying interface call parameters. The method involves matching cases in a preset case database based on the interface call parameters to obtain matching results; obtaining the target callback data of the currently called interface based on the matching results; and, during the verification execution phase, obtaining the target callback data through the flowchart platform and verifying the test results based on the target callback data. Compared to existing automated testing methods that typically rely on the immediate return results of HTTP interfaces for verification, and cannot perform immediate verification of asynchronously returned client-native API callback data, this invention can obtain the callback data of the currently called interface based on the case matching results, and then obtain this callback data through the flowchart platform during the subsequent verification execution phase, and perform test result verification based on the callback data. This allows for the separation of interface callback and verification, thereby solving the technical problem that existing automated testing methods cannot directly capture the callback data of the client-native API, resulting in the inability to perform immediate verification. Attached Figure Description

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

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

[0047] Figure 1 This is a flowchart illustrating an embodiment of the interface automated testing method of this application.

[0048] Figure 2 This is a diagram showing the automated data flow in the interface automation testing method of this application.

[0049] Figure 3 This is an example of a task execution webpage in the interface automation testing method of this application. Figure 1 ;

[0050] Figure 4 This is an example of a task execution webpage in the interface automation testing method of this application. Figure 2 ;

[0051] Figure 5 This is an example of a task execution webpage in the interface automation testing method of this application. Figure 3 ;

[0052] Figure 6 This is a flowchart illustrating Embodiment 2 of the interface automated testing method of this application;

[0053] Figure 7 This is a flowchart illustrating Embodiment 3 of the interface automated testing method of this application;

[0054] Figure 8 This is a schematic diagram of the module structure of the interface automated testing device according to an embodiment of this application;

[0055] Figure 9 This is a schematic diagram of the hardware operating environment involved in the interface automated testing method in this application embodiment.

[0056] 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

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

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

[0059] The main solution of this application embodiment is as follows: responding to the interface call request generated by the flowchart platform based on the flowchart case, the interface call request carries the interface call parameters; performing case matching in the preset case database based on the interface call parameters to obtain the case matching result; obtaining the target callback data of the currently called interface based on the case matching result; and in the verification execution phase, obtaining the target callback data through the flowchart platform and performing test result verification based on the target callback data.

[0060] Because existing automated testing methods typically rely on the immediate return results of HTTP interfaces for verification, they cannot perform immediate verification of client-native APIs that return asynchronous callback data.

[0061] This application provides a solution that can obtain the callback data of the currently called interface based on the case matching result, and obtain the callback data through the flowchart platform in the subsequent verification execution stage, and perform test result verification based on the callback data. This allows the interface callback and verification to be separated, thereby solving the technical problem in the existing automated testing methods that cannot directly capture the callback data of the client's native API, resulting in the inability to perform real-time verification.

[0062] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone; or an electronic device, automated testing platform, or interface automated testing system that includes an automated testing platform, etc. The following description uses an interface automated testing system (hereinafter referred to as the system) as an example to illustrate this embodiment and the following embodiments.

[0063] Based on this, this application provides an automated interface testing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the interface automated testing method in this application.

[0064] In this embodiment, the automated interface testing method includes steps S10 to S40:

[0065] Step S10: In response to the interface call request generated by the flowchart platform based on the flowchart case, the interface call request carries interface call parameters.

[0066] It should be noted that the aforementioned flowchart platform can be a visualization platform used to draw flowcharts; correspondingly, the aforementioned flowchart case can be a graphical representation defined in the flowchart platform to describe an automated testing process. It can be a complete test scenario, containing multiple nodes and the connections between them. These nodes and connections define the execution path and logic of the test. In this embodiment, a flowchart case can consist of a flowchart name, a node list, and a connection list. The flowchart name can be the name that identifies the flowchart case; the node list can be a collection of all nodes in the flowchart; and the connection list can be a collection of connections between nodes.

[0067] It should be understood that the aforementioned interface call request can be a request used to instruct the system to initiate a native API call to the client, carrying interface call parameters. In this embodiment, the interface call parameters can be parameters that need to be entered when calling the native API to the client, such as task name, interface name, and call configuration.

[0068] In practical applications, users can draw business test logic into a graphical process by dragging and dropping nodes, connecting lines, and configuring parameters within a web page, generating flowchart examples. The flowchart platform can then parse these examples into structured data and provide interfaces for integration with downstream automation systems. During subsequent automated testing, the system can use the flowchart platform to parse the nodes in the flowchart examples, extract the interface call parameters, and generate interface call requests based on these parameters.

[0069] Furthermore, before step S10, the method further includes: determining the user configuration node and the node type corresponding to the user configuration node based on the user configuration information; generating a flowchart case based on the user configuration node and the node type; parsing the flowchart case through the flowchart platform to extract the interface call parameters in the flowchart case; and generating an interface call request based on the interface call parameters through the flowchart platform.

[0070] It should be noted that the above user configuration information can be the specific parameters that testers configure for each node in the flowchart platform. These parameters define the behavior and attributes of the node, such as "taskName": "UserAuthFlow", "apiName": "requestCameraAuth", "quality": "high", "timeout": 5000, "expected": {"success": true, "errorCode": 0}, etc. This embodiment does not impose any restrictions on this.

[0071] It should be understood that the aforementioned user configuration node can be a node object instantiated from user configuration information in the flowchart platform. In this embodiment, the user configuration node can be represented as a draggable and connectable graphical element in the flowchart. Correspondingly, the aforementioned node type can be a label used to determine the behavior of the node during the parsing phase, such as a start node, end node, conditional branch node, interface call node, assertion verification node, etc. This embodiment does not impose any restrictions on this. In practical applications, after the system determines the user configuration node and its corresponding node type, it can use the flowchart platform to encapsulate each node and its corresponding node type into a JSON object, thereby generating a flowchart example.

[0072] In practical applications, the system can parse flowchart cases through the flowchart platform, traverse each node in the flowchart case in sequence, and determine the interface call nodes. For each interface call node, the platform can extract its corresponding interface call parameters and generate an interface call request based on the interface call parameters.

[0073] Step S20: Perform case matching in the preset case database based on the interface call parameters to obtain case matching results.

[0074] It should be noted that the aforementioned preset test case database can be a database used to store automated test cases. An automated test case can be a graphical representation describing an automated testing process; it can be a complete test scenario containing multiple nodes and the connections between them. These nodes and connections define the execution path and logic of the test. In this embodiment, automated test cases can be automatically generated by the flowchart platform based on the nodes in the user-drawn flowchart and persisted to the preset test case database. Subsequently, the task execution end makes an interface call, and the flowchart platform obtains the callback data and compares it with its expected result, thereby completing the closed loop of automated testing for the entire client API.

[0075] It is understood that the above case matching results can be the specific matching results obtained after searching for corresponding cases in the preset case database based on the interface call parameters (task name, interface name, call configuration). In this embodiment, the case matching results can include three scenarios: matching failure, matching success with callback data, and matching success without callback data. Matching failure can be the case where the interface call parameters do not have a corresponding record in the preset case database; matching success with callback data can be the case where the interface call parameters have a matching case in the preset case database, and the case has stored the callback data returned by the client API (such as call result, error code, return value, etc.); matching success without callback data can be the case where the interface call parameters have a matching case in the preset case database, but the client API callback data has not yet been stored (possibly because the API has not been executed or the callback has not been completed).

[0076] Further, step S20 includes: determining the task name, interface name, and parameter configuration of the current calling task based on the interface call parameters; performing a joint comparison between the task name, interface name, and parameter configuration and test cases in a preset case database; and generating a case matching result for the current calling task based on the joint comparison result.

[0077] It should be understood that the aforementioned current invocation task can be a specific invocation action of the system to a certain client native API, that is, an execution node instance in the flowchart example; the aforementioned task name can be a string used to uniquely identify a complete test scenario, which is used in the flowchart platform to distinguish different test processes and ensure that the callback data and execution status of each test scenario can be correctly associated; the aforementioned interface name can be a string used to identify the client native API to be called, which is used in the flowchart platform to determine the specific API call and ensure that the task execution end can correctly execute the API call; the aforementioned invocation configuration can be the specific parameters of the API call, which define the behavior of the API call, such as input parameters, timeout, environment configuration, etc.

[0078] In practical applications, after obtaining the task name, interface name, and parameter configuration, the system can use the triple "task name + interface name + parameter configuration" as a composite primary key, and accurately match the same field in the preset case database using SQL (or in-memory hash table) to obtain the composite comparison result. Finally, the system can determine three cases based on the composite comparison result: whether the case is hit or not, and whether there is already a callback result, and thus output the case matching result of the currently called task.

[0079] Step S30: Obtain the target callback data of the currently called interface based on the case matching result.

[0080] It should be noted that the aforementioned currently invoked interface can be the client's native API being tested; correspondingly, the aforementioned target callback data can be the original result returned and stored in the database after the current invoked interface is executed, including: call result, error code, return value, etc., where the call result is used to indicate whether the interface call was successful; the error code is used to indicate the reason for the interface call failure; and the return value is used to indicate the specific data returned by the interface call.

[0081] In this embodiment, if the case matching result is a failure, it means that the callback data cannot be obtained directly at present. In this case, the current calling interface can be called to obtain the target callback data of the current calling interface and store it in the database. Then, a new case can be created so that case matching can be performed again in the future. After successful matching, the target callback data can be retrieved from the database. If the case matching result is a successful match and callback data exists, the target callback data of the current calling interface can be retrieved directly from the database. If the case matching result is a successful match but no callback data exists, the current calling interface can be called to obtain the target callback data of the current calling interface and store it in the database. Then, the matched case can be updated. After the update is completed, matching can be performed again, and the target callback data can be retrieved from the database when the match is successful.

[0082] Step S40: During the verification execution phase, the target callback data is obtained through the flowchart platform, and the test results are verified based on the target callback data.

[0083] In practical applications, after the system obtains the target callback data of the currently called interface, it can compare the assertion conditions written in the flowchart example with the target callback data item by item. If all assertions pass, the verification passes; if any assertion fails, the verification fails. Finally, the comparison result is written to the execution record of the flowchart example.

[0084] In the specific implementation, refer to Figure 2 , Figure 2 This is a diagram showing the automated data flow in the interface automation testing method of this application. For example... Figure 2 As shown, users can draw business test logic into a graphical process by dragging and dropping nodes, connecting lines, and configuring parameters within a web page, generating flowchart cases. The flowchart platform then parses these cases to determine the client's native API call interface name, parameter names, and expected results. Based on this information, it generates test cases and automation scripts, which are then batch-debugged. During automated testing, the system can access the HTTP interaction interface through the built-in components of the unified automated testing platform to obtain parameters such as the call interface name and parameter names. Based on these parameters, it generates automated test cases for the client's native API. The automated test cases are then executed periodically by the platform or manually by the user, obtaining callback data from the client's native API and storing it in the callback database. Subsequently, during execution result verification, the flowchart platform retrieves the client's native API callback data from the callback database through the HTTP interaction interface and performs automated verification based on this data. Finally, the execution result is written back after verification using the built-in components. Notably, the generation of automated test cases and the acquisition of callback data can use the same interface, eliminating the need to modify the scripts.

[0085] In practical applications, refer to Figure 3 , Figure 3 This is an example of a task execution webpage in the interface automation testing method of this application. Figure 1 In this embodiment, the system can perform routine maintenance on client API automation cases, such as... Figure 3 As shown, in this application, for each client API automation case, the system can display its corresponding case number, interface name, case parameters, expected result, execution result, execution time, and operation buttons on the task execution webpage. Simultaneously, users can query client API automation cases by group information, test task information, and case number (via...). Figure 3The system implements a query button and deletes abnormal client API automation cases via a delete button. Additionally, it can re-examine failed client API automation cases and manage the batch execution range of managed client API automation cases. Furthermore, refer to... Figure 4 and 5 , Figure 4 This is an example of a task execution webpage in the interface automation testing method of this application. Figure 2 , Figure 5 This is an example of a task execution webpage in the interface automation testing method of this application. Figure 3 .like Figure 4 and 5 As shown in this application, users can also execute client API automation cases on mobile terminals. For example, during the actual execution of a cmblapi task, users can query client API automation cases by group and task reading status, and execute client API automation cases by execution status. During task execution, users can choose to execute all cases with one click. Finally, when the task is completed, the system can print the callback results of the client API automation cases and store them in the database through the interface, then prompt the user about the task execution and show the user the task execution results (such as whether the task is completed, the number of tasks executed, etc.).

[0086] In this embodiment, the system can also provide a functional webpage for recording the call assets of manual testing. The recorded call assets can be copied with one click and used for drawing flowcharts, achieving an organic combination of manual testing and automated testing, thereby improving the efficiency of building flowcharts related to client APIs.

[0087] This embodiment provides an automated interface testing method. The method discloses responding to an interface call request generated by a flowchart platform based on flowchart cases, with the request carrying interface call parameters; performing case matching in a preset case database based on the interface call parameters to obtain case matching results; obtaining the target callback data of the currently called interface based on the case matching results; and, during the verification execution phase, obtaining the target callback data through the flowchart platform and verifying the test results based on the target callback data. Compared to existing automated testing methods that typically rely on the immediate return results of HTTP interfaces for verification, and cannot perform immediate verification of asynchronously returned client-native API callback data, this embodiment can obtain the callback data of the currently called interface based on the case matching results, and then obtain this callback data through the flowchart platform during the subsequent verification execution phase, and perform test result verification based on the callback data. This allows for the separation of interface callback and verification, thereby solving the technical problem that existing automated testing methods cannot directly capture the callback data of the client-native API, resulting in the inability to perform immediate verification.

[0088] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6 , Figure 6 This is a flowchart illustrating Embodiment 2 of the interface automated testing method of this application.

[0089] In this embodiment, step S30 further includes steps S301 to S304:

[0090] Step S301: If the case matching result is a failure, then generate a target test case based on the interface call parameters.

[0091] It should be understood that the aforementioned target test case can be a newly generated complete test case record based on the interface call parameters. In this embodiment, if there is no test case matching the interface call parameters in the preset test case database, the test case matching result can be determined as a matching failure. At this time, the system can generate a brand new test case record based on these interface call parameters to obtain the aforementioned target test case.

[0092] Step S302: Store the target test case in the preset case database to obtain the first updated case database.

[0093] It is understandable that the aforementioned first updated case database can be the case database obtained after storing the target test cases in the preset case database. In practical applications, after the system generates a new test case based on the interface call data, it can insert the newly generated test case into the preset case database to update the preset case database, thereby obtaining the first updated case database.

[0094] Step S303: Perform case matching in the first updated case database based on the interface call parameters.

[0095] Step S304: When a match is successful, retrieve the target callback data of the currently invoked interface from the callback data repository.

[0096] In practical applications, if the system does not find a record matching the task name, interface name, and parameter configuration in the preset case database, it cannot directly obtain the callback data. In this case, the system can call the client's native API within the mobile terminal app and store the callback data in the callback storage. However, since the system is unaware of this call, it needs to automatically create a new test case based on the interface call parameters, including initialization case configuration and expected result fields, and store the newly created test case in the preset case database. During the subsequent verification and execution phase, the system can re-match the interface call parameters with the updated preset case database. If the case matches successfully, the system can then query the callback storage again to obtain the callback data matching the newly created case, thus obtaining the aforementioned target callback data.

[0097] Furthermore, before step S304, the method further includes: performing a call to the current interface to obtain target callback data; and associating the target callback data with the interface call parameters and storing it in the callback data repository.

[0098] In this embodiment, if the system does not find a record matching the task name, interface name, and parameter configuration in the preset case database, it cannot directly obtain the callback data. In this case, the system can call the client's native API within the mobile terminal APP to obtain the target callback data of the client's native API, and store the target callback data and interface call parameters in the callback storage terminal so that the target callback data can be directly obtained from the callback storage terminal for verification in the future.

[0099] In this embodiment, if the case matching result is a failure, a target test case is generated based on the interface call parameters; the target test case is stored in a preset case database to obtain a first updated case database; case matching is performed in the first updated case database based on the interface call parameters; when a match is successful, the target callback data of the currently called interface is obtained from the callback data repository. Since this embodiment can automatically generate new cases and add them to the preset case database based on the interface call parameters when no matching case is found, it can ensure that new testing requirements can be quickly incorporated into the scope of automated testing without manual intervention, thereby improving the efficiency of case construction.

[0100] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 , Figure 7 This is a flowchart illustrating Embodiment 3 of the interface automation testing method in this application.

[0101] In this embodiment, step S30 further includes steps S311 to S313:

[0102] Step S311: If the case matching result is a successful match, then obtain the matching test case.

[0103] It should be understood that the aforementioned matching test cases can be test cases that match the interface call parameters in the preset case database. In this embodiment, if the task name, interface name, and parameter configuration in the interface call parameters have corresponding records in the preset case database, it indicates that the case matching is successful. At this time, the system can extract the test cases that successfully match the interface call parameters from the preset case database to obtain the aforementioned matching test cases.

[0104] Step S312: Determine whether the callback data corresponding to the matching test case exists in the callback data repository.

[0105] It is understood that the aforementioned callback data repository can be a database used to store the original results (i.e., callback data) returned after the execution of the client's native API. In this embodiment, by storing the callback data of the client's native API in the callback data repository, the callback data generated by the mobile device in real time but unable to be synchronously transmitted can be stored in the repository first, so that the callback data can be directly retrieved from the callback data repository for verification during the subsequent verification phase, thus achieving the separation of client API callback and verification.

[0106] Step S313: If it exists, retrieve the callback data from the callback data repository and determine the callback data as the target callback data for the current calling interface.

[0107] In practical applications, when a case match is successful, the system can further check whether the callback result of the client's native API already exists in the callback data repository. If it does, the system can directly extract the callback data from the callback data repository and determine the callback data as the target callback data for the current API call.

[0108] Furthermore, after step S312, the method further includes: if the interface call auxiliary parameters of the current calling task are not present, obtaining the interface call auxiliary parameters; updating the matching test case based on the interface call auxiliary parameters to obtain the updated test case; updating the preset case database based on the updated test case to obtain the second updated case database; performing case matching in the second updated case database based on the interface call parameters; and obtaining the target callback data of the current calling interface from the callback data repository when the matching is successful.

[0109] It should be noted that the above-mentioned auxiliary parameters for interface calls can be other information in the automated test case besides the main interface call parameters (such as task name, interface name, and call configuration). They can be used to support the management and execution of the test process, but do not directly participate in the interface call itself. For example, execution time, execution status, version information, and other additional configurations. This embodiment does not impose any restrictions on this.

[0110] It should be understood that the aforementioned second updated case database can be the case database obtained by storing the updated test cases into the preset case database. In practical applications, after the system updates the matching test cases based on the non-core parameters of the currently invoked task, it can insert the updated test cases into the preset case database to update the preset case database, thereby obtaining the second updated case database.

[0111] In practical applications, if the interface call parameters have corresponding records in the preset case database, but the corresponding callback data does not exist in the callback data repository (i.e., the callback result has not yet been generated, such as when the client API call is incomplete), the system can update the interface call auxiliary parameters in the test case using the currently called interface to update the test case and obtain an updated test case. The core parameters in the test case (task name, interface name, call parameters) remain unchanged. Then, the system can call the currently called interface to generate the target callback data for that interface and store it in the callback data repository. This allows for direct retrieval of the target callback data for verification during subsequent checks. By updating the matching test case using interface call auxiliary parameters, the system ensures that the same business scenario can be accurately matched to the same case record in any environment and at any time, thereby improving the accuracy of case matching and ultimately enhancing the accuracy of interface call verification.

[0112] In this embodiment, if the case matching result is successful, a matching test case is obtained; it is determined whether there is callback data corresponding to the matching test case in the callback data repository; if there is, the callback data is obtained from the callback data repository and the callback data is determined as the target callback data of the current calling interface; since this embodiment can directly obtain the callback data of the current calling interface from the callback data repository when the interface call parameters match the test case in the preset case database and there is a callback result, the instant verification of the interface call can be realized, which improves the efficiency of interface call verification.

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

[0114] This application also provides an automated interface testing device; please refer to [reference needed]. Figure 8 The automated interface testing device includes:

[0115] Request response module 10 is used to respond to an interface call request generated by the flowchart platform based on a flowchart example, wherein the interface call request carries interface call parameters;

[0116] Case matching module 20 is used to perform case matching in a preset case database based on the interface call parameters and obtain case matching results;

[0117] Data acquisition module 30 is used to acquire the target callback data of the currently called interface based on the case matching result;

[0118] The interface testing module 40 is used to obtain the target callback data through the flowchart platform during the verification execution phase, and to verify the test results based on the target callback data.

[0119] The interface automated testing device provided in this application, employing the interface automated testing method in the above embodiments, can solve the technical problem that existing automated testing methods cannot directly capture callback data from the client's native API, resulting in the inability to perform real-time verification. Compared with the prior art, the beneficial effects of the interface automated testing device provided in this application are the same as those of the interface automated testing method provided in the above embodiments, and other technical features in the interface automated testing device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0120] This application provides an automated interface 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 perform the automated interface testing method in Embodiment 1 above.

[0121] The following is for reference. Figure 9The diagram illustrates a structural schematic of an interface automated testing device suitable for implementing embodiments of this application. The interface automated testing device in these embodiments 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), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The interface automation 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.

[0122] like Figure 9 As shown, the interface automation testing equipment 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 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the interface automation testing equipment. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the interface automation test equipment to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows interface automation test equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0123] 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 read-only memory 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.

[0124] The interface automated testing equipment provided in this application, employing the interface automated testing method in the above embodiments, can solve the technical problems of interface automated testing. Compared with the prior art, the beneficial effects of the interface automated testing equipment provided in this application are the same as those of the interface automated testing method provided in the above embodiments, and other technical features of this interface automated testing equipment are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

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

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

[0127] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the interface automation testing method in the above embodiments.

[0128] 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 systems or 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 fibers, 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 used by or in conjunction with an instruction execution system or device. 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.

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

[0130] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the interface automated testing device, the interface automated testing device: responds to an interface call request generated by the flowchart platform based on flowchart cases, the interface call request carrying interface call parameters; performs case matching in a preset case database based on the interface call parameters to obtain case matching results; obtains the target callback data of the currently called interface based on the case matching results; and during the verification execution phase, obtains the target callback data through the flowchart platform and performs test result verification based on the target callback data.

[0131] 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++, as well as 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).

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, 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 a 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 a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

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

[0134] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described automated interface testing method. This solves the technical problem in existing automated testing methods that cannot directly capture callback data from the client's native API, thus preventing real-time verification. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the automated interface testing method provided in the above embodiments, and will not be elaborated upon here.

[0135] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An automated interface testing method, characterized in that, The method includes: In response to an interface call request generated by the flowchart platform based on a flowchart example, the interface call request carries interface call parameters; Based on the interface call parameters, a case match is performed in a preset case database to obtain the case match result; Based on the case matching results, obtain the target callback data for the currently invoked interface; During the verification execution phase, the target callback data is obtained through the flowchart platform, and the test results are verified based on the target callback data.

2. The method as described in claim 1, characterized in that, Before the step of responding to the interface call request generated by the flowchart platform based on the flowchart case, the method further includes: Determine the user configuration node and the node type corresponding to the user configuration node based on the user configuration information; A flowchart example is generated based on the user configuration node and the node type; The flowchart case is parsed using a flowchart platform to extract the interface call parameters from the flowchart case. The flowchart platform generates an interface call request based on the interface call parameters.

3. The method as described in claim 1, characterized in that, The step of performing case matching in a preset case database based on the interface call parameters to obtain case matching results includes: The task name, interface name, and parameter configuration of the current calling task are determined based on the interface call parameters. The task name, the interface name, and the parameter configuration are compared with test cases in the preset case database. The case matching results for the currently invoked task are generated based on the joint comparison results.

4. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining the target callback data of the currently called interface based on the case matching result includes: If the case matching result is a failure, a target test case is generated based on the interface call parameters; The target test cases are stored in the preset case database to obtain the first updated case database; Based on the interface call parameters, case matching is performed in the first updated case database; When a match is successful, retrieve the target callback data for the currently invoked interface from the callback data repository.

5. The method as described in claim 4, characterized in that, Before the step of performing case matching in the first updated case database based on the interface call parameters, the method further includes: Execute the call to the currently invoked interface and obtain the target callback data; The target callback data is associated with the interface call parameters and stored in the callback data repository.

6. The method as described in claim 3, characterized in that, The step of obtaining the target callback data of the currently called interface based on the case matching result includes: If the case matching result is a successful match, then obtain the matching test case; Determine whether the callback data corresponding to the matching test case exists in the callback data repository; If it exists, retrieve the callback data from the callback data repository and determine the callback data as the target callback data for the current calling interface.

7. The method as described in claim 6, characterized in that, After the step of determining whether callback data corresponding to the matching test case exists in the callback data repository, the method further includes: If it does not exist, then obtain the interface call auxiliary parameters of the currently invoked task; The matching test case is updated by calling the auxiliary parameters based on the interface to obtain the updated test case; The current API call is executed to obtain the target callback data, and the target callback data is associated with the API call parameters and stored in the callback data repository. The preset case database is updated based on the updated test cases to obtain a second updated case database; Based on the interface call parameters, case matching is performed in the second updated case database; Upon successful matching, the target callback data is retrieved from the callback data repository.

8. An automated interface testing device, characterized in that, The device includes: The request and response module is used to respond to the interface call request generated by the flowchart platform based on the flowchart case, wherein the interface call request carries interface call parameters; The case matching module is used to perform case matching in a preset case database based on the interface call parameters and obtain case matching results; The data acquisition module is used to obtain the target callback data of the currently called interface based on the case matching result; The interface testing module is used to obtain the target callback data through the flowchart platform during the verification execution phase, and to verify the test results based on the target callback data.

9. An automated interface testing device, characterized in that, The device includes: 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 automated testing method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the interface automated testing method as described in any one of claims 1 to 7.

Images