Interface testing method, system, device and electronic equipment

By storing pending code on the target test server and generating interface information, and automatically testing the calling interface of the back-end function, the problem of low interface testing efficiency in the existing technology is solved, and an efficient interface testing process is realized.

CN120179563BActive Publication Date: 2025-08-12CSC FINANCIAL CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202510606524.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-05-12
Publication Date
2025-08-12
Estimated Expiration
2045-05-12

AI Technical Summary

Technical Problem

In the prior art, multiple back-end functions are deployed in different servers, which leads to the need to determine the calling interface service address of each back-end function one by one during interface testing, resulting in low interface testing efficiency.

Method used

Select a target test server, store the pending code and generate interface information containing the target test server address and sub-function code storage path, automatically send test requests through the front-end page and judge the call result, avoiding manual determination of the service address.

Benefits of technology

It improves the overall efficiency of interface testing, reduces manual intervention, and automates the call interface testing of subfunction codes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120179563B_ABST
    Figure CN120179563B_ABST
Patent Text Reader

Abstract

The present invention provides an interface testing method, system, device, and electronic device, relating to the field of software testing technology. In the method, a target test server is selected; code to be processed is sent to the target test server, and the storage path of sub-function code in the code to be processed is obtained; interface information of a calling interface for calling the sub-function code is generated; the interface information includes the address of the target test server and the storage path of the sub-function code; the interface information is sent to a first terminal, and the first terminal generates a front-end page, which is displayed on a second terminal; a determination is made as to whether a call result obtained from a second terminal is the same as a preset call result, thereby obtaining a test result indicating whether the call interface is abnormal; the call result is the result returned to the second terminal by the target test server after calling the locally stored code to be processed based on the storage path in the test request sent by the second terminal. The present invention can improve the overall efficiency of interface testing.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to an interface testing method, system, device and electronic equipment. Background Art

[0002] A front-end page can be associated with multiple back-end functions. When a user triggers a back-end function in the front-end page displayed on the client, the client will send a service request to the server represented by the service address according to the service address in the calling interface of the back-end function. The server can implement the back-end function after receiving the service request.

[0003] However, when it is necessary to test the calling interfaces of multiple backend functions, since the multiple backend functions may be deployed in multiple different servers, developers are required to determine the service address in the calling interface of each backend function one by one according to the backend functions deployed in each server, resulting in low overall efficiency of interface testing. Summary of the Invention

[0004] The purpose of the embodiments of the present invention is to provide an interface testing method, system, device, and electronic device to improve the overall efficiency of interface testing. The specific technical solution is as follows:

[0005] In a first aspect, an embodiment of the present invention provides an interface testing method, applied to a master control server, the method comprising:

[0006] Select a target test server from multiple test servers;

[0007] Sending the code to be processed to the target test server so that the target test server stores the code to be processed, and obtaining a storage path of each sub-function code in the code to be processed in the target test server;

[0008] For each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code is generated; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server;

[0009] Sending the generated interface information to the first terminal, so that the first terminal generates a front-end page integrating a target function based on the received interface information, where the target function is implemented based on a sub-function code corresponding to the received interface information; and displaying the front-end page on the second terminal;

[0010] Determine whether the call result obtained from the second terminal is the same as the preset call result, and obtain a test result indicating whether the call interface of at least one sub-function code contained in the code to be processed is abnormal; wherein, the call result is the call result returned to the second terminal by the target test server when calling the locally stored code to be processed based on the storage path in the test request sent by the second terminal; the test request is sent in response to the triggering of the target function.

[0011] Optionally, before sending the code to be processed to the target test server so that the target test server stores the code to be processed, the method further includes:

[0012] For each sub-function code included in the code to be processed, determining whether a calling interface for calling the sub-function code needs to be tested, and obtaining a determination result of the sub-function code;

[0013] The sending the code to be processed to the target test server so that the target test server stores the code to be processed includes:

[0014] Sending the code to be processed and a determination result of at least one sub-function code contained in the code to be processed to the target test server, so that the target test server calls the at least one sub-function code contained in the code to be processed stored locally according to the determination result and the storage path in the test request, and returns the calling result to the second terminal.

[0015] Optionally, for each sub-function code included in the code to be processed, determining whether a calling interface for calling the sub-function code needs to be tested, and obtaining a determination result for the sub-function code includes:

[0016] For each sub-function code included in the code to be processed, if no sub-function code has been submitted before the code to be processed is submitted, determining that the determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested;

[0017] If a sub-function code has been submitted before the pending code is submitted, determine the currently effective sub-function code and the currently normal sub-function code; wherein the currently effective sub-function code is: a sub-function code for which the determination result indicates that the corresponding calling interface needs to be tested and the test result is not currently obtained; the currently normal sub-function code is: a sub-function code recorded in the current normal sub-function code library for which a test result has been obtained and the test result indicates that there is no abnormality;

[0018] If there is no sub-function code with the same storage path as the sub-function code among the currently effective sub-function codes and the sub-function codes without exception, it is determined that the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested;

[0019] and / or,

[0020] The method further comprises:

[0021] For each sub-function code in the code to be processed, if the test result of each sub-function code indicates no abnormality, the code to be processed is added to the current sub-function code library without abnormality to update the version of the current sub-function code library without abnormality.

[0022] Optionally, the interface information of the calling interface of a sub-function code further includes format sub-information indicating the format of the test request and the format of the calling result;

[0023] The method further includes: for each sub-function code included in the code to be processed, if, among the currently non-abnormal sub-function codes, there is no sub-function code having the same storage path as the sub-function code, and among the currently effective sub-function codes having the same storage path as the sub-function code, there is no sub-function code having the same format sub-information as that in the interface information of the sub-function code, determining a historical non-abnormal sub-function code in a historical non-abnormal sub-function code library;

[0024] If there is no sub-function code in the historical non-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code, then the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested;

[0025] If there is a sub-function code in the history of no-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code, a first number and a second number are determined; wherein the first number is: the number of sub-function codes in the history of no-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code; and the second number is: the number of sub-function codes in the history of no-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-data as that in the interface information of the currently effective sub-function code;

[0026] If the determined first number is smaller than the second number, the determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested.

[0027] In a second aspect, an embodiment of the present invention provides an interface testing method, which is applied to a target test server among multiple test servers, and includes:

[0028] Upon receiving a test request sent by the second terminal, the locally stored code to be processed is called based on the storage path in the test request; wherein, the storage path in the test request is the storage path of the sub-function code in the code to be processed in the target test server; the target test server stores the code to be processed sent by the master server, and the target test server is selected by the master server from multiple test servers; the test request is sent in response to the triggering of the target function integrated in the front-end page displayed by the second terminal; the front-end page is a front-end page integrated with the target function generated by the first terminal based on the interface information received from the master server; the target function is implemented based on the sub-function code corresponding to the received interface information; the received interface information includes: the address of the target test server and the storage path of the sub-function code in the target test server; and the call result is returned to the second terminal.

[0029] Optionally, calling the locally stored code to be processed based on the storage path in the test request includes: calling at least one sub-function code contained in the locally stored code to be processed according to the judgment result and the storage path in the test request; wherein, the judgment result is obtained by the main control server judging whether it is necessary to test the calling interface used to call the sub-function code for each sub-function code contained in the code to be processed.

[0030] In a third aspect, an embodiment of the present invention provides an interface testing system, which includes: a master control server and multiple test servers; the master control server is used to execute the interface testing method of the first aspect above; any one of the multiple test servers is used to execute the interface testing method of the second aspect above.

[0031] In a fourth aspect, an embodiment of the present invention provides an interface testing device, which is applied to a master control server, and the device includes: a selection module, which is used to select a target test server from a plurality of test servers;

[0032] a storage module, configured to send the code to be processed to the target test server so that the target test server stores the code to be processed, and obtain a storage path of each sub-function code in the code to be processed in the target test server;

[0033] A generating module, configured to generate, for each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server;

[0034] a first sending module, configured to send the generated interface information to a first terminal, so that the first terminal generates a front-end page integrating a target function based on the received interface information, wherein the target function is implemented based on a sub-function code corresponding to the received interface information; and the front-end page is displayed on a second terminal;

[0035] The first judgment module is used to determine whether the call result obtained from the second terminal is the same as the preset call result, and obtain a test result indicating whether the call interface of at least one sub-function code contained in the code to be processed is abnormal; wherein, the call result is the call result returned to the second terminal by the target test server when calling the locally stored code to be processed based on the storage path in the test request sent by the second terminal; the test request is sent in response to the triggering of the target function.

[0036] In a fifth aspect, an embodiment of the present invention provides an interface testing device, which is applied to a target test server among multiple test servers, and includes:

[0037] A calling module is used to call the locally stored pending code based on the storage path in the test request when receiving a test request sent by the second terminal; wherein the storage path in the test request is the storage path of the sub-function code in the pending code in the target test server; the target test server stores the pending code sent by the master server, and the target test server is selected by the master server from multiple test servers; the test request is sent in response to the triggering of the target function integrated in the front-end page displayed by the second terminal; the front-end page is a front-end page integrated with the target function generated by the first terminal based on the interface information received from the master server; the target function is implemented based on the sub-function code corresponding to the received interface information; the received interface information includes: the address of the target test server and the storage path of the sub-function code in the target test server; a return module is used to return the call result to the second terminal.

[0038] An embodiment of the present invention also provides an electronic device, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement the above-mentioned interface testing method when executing the program stored in the memory.

[0039] Beneficial effects of the embodiments of the present invention:

[0040] In an embodiment of the present invention, a target test server is selected from multiple test servers; the code to be processed is then stored on the target test server, specifically, the sub-function code within the code to be processed is deployed to the target test server; and interface information for invoking the sub-function code is generated. Because the interface information for each sub-function code includes the address of the target test server and the storage path of the sub-function code within the target test server, the interface information is sent to a first terminal. The first terminal can then generate a front-end page based on the received interface information. The front-end page can be displayed on a second terminal. When the target function on the front-end page is triggered on the second terminal, the second terminal can automatically send a test request to the target test server according to the address (i.e., the address of the target test server) in the interface information for the sub-function code corresponding to the target function, eliminating the need for manual determination of the target test server's address. Upon receiving the test request from the second terminal, the target test server invokes the locally stored sub-function code based on the storage path included in the test request and returns the invocation result to the second terminal, completing the process of triggering a back-end function response via the front-end page. Finally, the main control server determines whether the calling result obtained from the second terminal is the same as the preset calling result, and obtains a test result indicating whether the calling interface of at least one sub-function code included in the code to be processed is abnormal.

[0041] In an embodiment of the present invention, the sub-function code in the code to be processed is stored in the target test server selected by the machine, and interface information including the address of the target test server and the storage path of the sub-function code in the target test server is generated. Therefore, when testing the calling interface of each sub-function code, a test request can be sent to the address of the target test server. When calling the calling interface, the sub-function code stored locally on the target test server can be called based on the storage path in the test request, and the calling result can be returned, thereby avoiding manual determination of the service address in the calling interface of each back-end function one by one, completing the test of the calling interface of the sub-function code, and improving the overall efficiency of the interface test.

[0042] Of course, it is not necessary to achieve all of the advantages described above simultaneously in order to implement any product or method of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

[0044] Figure 1 A schematic diagram of a first interface testing system provided by an embodiment of the present invention;

[0045] Figure 2 A schematic diagram of a second interface testing system provided by an embodiment of the present invention;

[0046] Figure 3 A schematic diagram of a process for obtaining a determination result in the first interface testing method provided in an embodiment of the present invention;

[0047] Figure 4 A schematic diagram of a flow chart for obtaining a determination result in the second interface testing method provided in an embodiment of the present invention;

[0048] Figure 5 A schematic diagram illustrating the principle of an interface testing method provided by an embodiment of the present invention;

[0049] Figure 6 A schematic diagram of a flow chart of a first interface testing method provided in an embodiment of the present invention;

[0050] Figure 7 A schematic diagram of a flow chart of a second interface testing method provided in an embodiment of the present invention;

[0051] Figure 8 A schematic structural diagram of a first interface testing device provided by an embodiment of the present invention;

[0052] Figure 9 A schematic structural diagram of a second interface testing device provided by an embodiment of the present invention;

[0053] Figure 10 This is a schematic structural diagram of a first electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field based on the present invention are within the scope of protection of the present invention.

[0055] A single front-end page can involve the logic of multiple back-end functions, each implemented by its own code. The development of software involving front-end and back-end interaction can be assigned to different developers. For example, the development of the front-end page can be assigned to a front-end developer, while the development of each back-end function can be assigned to multiple back-end developers. This multi-person, parallel development approach can improve development efficiency and ensure timely delivery of development work.

[0056] For example, to provide service X to users, backend developer 1 can develop pending code (denoted by feature-1). This pending code implements function X1 and includes sub-function codes a and b. Sub-function code a corresponds to call interface A, and sub-function code b corresponds to call interface B. Sub-function codes a and b can be sub-functions of function X1. Backend developer 2 can develop pending code (denoted by feature-2) to implement function X2. This pending code includes sub-function codes c and d. Sub-function code c corresponds to call interface C, and sub-function code d corresponds to call interface D. Sub-function codes c and d can be sub-functions of function X2. A front-end developer can develop the front-end code for the front-end page (denoted by feature-fe). X1 and X2 are sub-functions of function X.

[0057] However, when it is necessary to test the calling interfaces of multiple back-end functions, since the multiple back-end functions may be deployed in multiple different servers, the servers are public servers for all developers, and the servers used for each test are not fixed. Accordingly, each test requires developers to determine the service address in the calling interface of each back-end function one by one according to the back-end functions deployed in each server, resulting in low overall efficiency of interface testing.

[0058] In order to improve the overall efficiency of interface testing, embodiments of the present invention provide an interface testing method, system, device, and electronic device.

[0059] The interface testing method provided in the embodiments of the present invention can be applied to a master control server. The master control server can detect and generate interface information for a call interface used to call a sub-function code, send the generated interface information to a first terminal, and obtain a call result from a second terminal. The target test server can receive a test request sent by the second terminal and return a call result to the second terminal. The master control server and the target test server can be the same device or different devices.

[0060] The first terminal can be a device used by developers, such as a desktop computer or laptop computer. Developers can develop front-end pages based on the received interface information on the first terminal, so that the first terminal generates the front-end pages. The second terminal can be a device used to display the developed front-end pages, such as a desktop computer or laptop computer. Developers can trigger the functions of sub-function codes in the front-end pages displayed on the second terminal to perform interface testing. The first terminal and the second terminal can be the same device or different devices.

[0061] An interface testing method provided by an embodiment of the present invention may include the following steps:

[0062] Select a target test server from multiple test servers;

[0063] Sending the code to be processed to the target test server so that the target test server stores the code to be processed, and obtaining the storage path of each sub-function code in the code to be processed in the target test server;

[0064] For each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code is generated; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server;

[0065] Sending the generated interface information to the first terminal, so that the first terminal generates a front-end page integrating a target function based on the received interface information, where the target function is implemented based on a sub-function code corresponding to the received interface information; and displaying the front-end page on the second terminal;

[0066] Determine whether a call result obtained from the second terminal is the same as a preset call result, and obtain a test result indicating whether a call interface of at least one sub-function code included in the code to be processed is abnormal; wherein the call result is a call result returned to the second terminal by the target test server by calling the locally stored code to be processed based on the storage path in the test request sent by the second terminal; the test request is sent in response to the triggering of the target function.

[0067] In an embodiment of the present invention, the sub-function code in the code to be processed is stored in the target test server selected by the machine, and interface information including the address of the target test server and the storage path of the sub-function code in the target test server is generated. Therefore, when testing the calling interface of each sub-function code, a test request can be sent to the address of the target test server. When calling the calling interface, the sub-function code stored locally on the target test server can be called based on the storage path in the test request, and the calling result can be returned, thereby avoiding manual determination of the service address in the calling interface of each back-end function one by one, completing the test of the calling interface of the sub-function code, and improving the overall efficiency of the interface test.

[0068] The following combination Figure 1 An interface testing system provided by an embodiment of the present invention is introduced. Figure 1 As shown, the interface test system includes: a master server 110, a first terminal 120, a second terminal 130, and a target test server 140. The process of the master server 110 interacting with the first terminal 120, the master server 110 interacting with the second terminal 130, and the second terminal 130 interacting with the target test server 140 may include steps S101-S109.

[0069] S101 : The control server 110 selects a target test server from a plurality of test servers.

[0070] It is understood that the development work of each back-end function can be assigned to different developers for processing. When a developer completes the development of the back-end function for which he or she is responsible, he or she can submit the pending code he or she has written to the code database. In order to test the calling interface for calling the sub-function code in the pending code, the master control server 110 can select a target test server for each pending code. Exemplarily, when the master control server 110 detects that a new pending code has been submitted to the code database, it selects a target test server from multiple test servers.

[0071] The pending code may include at least one sub-function code. Each sub-function code may implement one sub-function. In one implementation, the pending code may include more than one sub-function code. For example, the pending code may include 2, 3, or 4 sub-function codes. The sub-functions implemented by any two sub-function codes may be different. For example, sub-function code 1 may implement the function of obtaining student grades, and sub-function code 2 may implement the function of obtaining teacher salaries. In another implementation, the pending code may include only one sub-function code. That is, the pending code submitted by the developer only implements one function.

[0072] The calling interface of each sub-function code in the code to be processed is used to call the sub-function code. The code to be processed also includes an identifier for each sub-function code's calling interface. The interface information for the calling interface may include the address, port number, and storage path of the target test server. When developers write the sub-function code, they can pre-define the identifier for the sub-function code's calling interface. Later, when storing the sub-function code on the target test server, the target test server can establish a storage path containing the identifier and store the sub-function code in the established storage path. For example, developers can write the function name of the interface that calls the sub-function code and use the function name as the storage path in the interface information for the sub-function code. When writing the sub-function code, developers do not need to determine the address and port number in the interface information for the sub-function code's calling interface. The address and port number in the interface information are subsequently allocated by the master control server. The address in the interface information may be the Internet Protocol (IP) address of the target test server. The port number in the interface information for each calling interface indicates a network connection through the port represented by the port number.

[0073] The master server 110 can detect whether new pending code has been submitted to the code database. In one implementation, the server where the code database resides and the master server 110 are different devices. When new pending code is submitted, the server where the code database resides can send a signal to the master server 110 indicating that new pending code has been submitted, so that the master server 110 can detect that new pending code has been submitted to the code database. In another implementation, the server where the code database resides and the master server 110 are the same device. When the new pending code is stored in the code database, the master server 110 can detect that new pending code has been submitted to the code database. Upon detecting that new pending code has been submitted to the code database, the master server 110 can select a target test server from multiple servers.

[0074] The multiple test servers are public servers used by developers to conduct interface testing. In a first implementation, the master control server 110 can select a server that does not store any pending code as the target test server. In a second implementation, the master control server 110 can select the server with the largest remaining storage space as the target test server. In a third implementation, the master control server 110 can select any server from the multiple test servers as the target test server. In a fourth implementation, the master control server 110 can select the server with the least pending code as the target test server.

[0075] S102 : The main control server 110 sends the code to be processed to the target test server 140 , so that the target test server 140 stores the code to be processed and obtains the storage path of each sub-function code in the code to be processed in the target test server 140 .

[0076] It is understood that the master control server 110 can access the code database according to the preset code database address, obtain the code to be processed, and then send the code to be processed to the target test server 140, which stores the code to be processed. For example, the master control server 110 can copy the new code to be processed from the code database and send the copy result to the target test server 140, which can then store the received copy result, that is, store the new code to be processed. After the target test server 140 obtains the code to be processed, it can store the code to be processed and send the storage path of each sub-function code in the code to be processed on the target test server to the master control server.

[0077] S103 : The main control server 110 generates, for each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code.

[0078] It is understandable that the master server 110 can generate interface information of the calling interface for calling the sub-function code for each sub-function code in the code to be processed, and the generated interface information includes the address of the target test server and the storage path of the sub-function code in the target test server. Exemplarily, the master server 110 can generate an interface document containing the interface information of the calling interface of each sub-calling code. Specifically, the master server 110 can use the interface document generation component of the swagger class to generate the interface document. Developers can understand the interface information of each calling interface through the interface document, so as to accurately use the calling interface in the developed code.

[0079] S104 : The control server 110 sends the generated interface information to the first terminal 120 .

[0080] It is understood that the first terminal 120 is a device used by developers. The first terminal 120 can receive interface information sent by the master control server 110. Based on the interface information received by the first terminal 120, the developer can develop a front-end page that can call the sub-function code in the code to be processed. This allows the first terminal 120 to generate a front-end page that integrates the target function. The target function is implemented based on the sub-function code corresponding to the interface information. For each sub-function code, the interface information of the calling interface corresponds to the target function implemented based on the sub-function code. For example, the developer can develop a front-end page associated with the function represented by the sub-function code in the code to be processed. Specifically, the developer can write front-end code for the front-end page. The execution logic of the front-end code is to send a test request to the first terminal 120 when the function represented by the code to be processed is triggered. For example, the developer can write front-end code. The execution logic of the front-end code is such that when the function of viewing student grades on the page is triggered, the front-end code calls the calling interface for obtaining student grades and sends a request to the target test server 140 to obtain the student grades.

[0081] S105 : The second terminal 130 sends a test request to the target test server 140 .

[0082] It is understood that the second terminal 130 can display a front-end page generated by the first terminal 120. In one implementation, the first terminal 120 and the second terminal 130 are different devices. After a developer develops a front-end page on the first terminal 120, the first terminal 120 can send the front-end code of the front-end page to the second terminal 130. The second terminal 130 can receive the front-end code and display the front-end page based on the received front-end code. In another implementation, the first terminal 120 and the second terminal 130 are the same device. After a developer develops a front-end page on the first terminal 120, the first terminal 120 can directly display the developed front-end page.

[0083] Developers can trigger the target function on the front-end page of the second terminal 130. For example, the code to be processed contains multiple sub-function codes, and the front-end page is associated with each sub-function code. Developers can trigger the function of each sub-function code on the front-end page. For example, if there is a data view button on the front-end page, when the developer clicks the data view button, the function for obtaining the data represented by the sub-function code is triggered, and then the call interface of the sub-function code is called to send a test request to the target test server.

[0084] In one implementation, in a no-service architecture, each request sent by a terminal to a server is independent and does not depend on the information carried in other requests. The server's processing of each received request does not depend on the status of the previously received request, and the call interfaces invoked when sending each request do not affect each other. Each call interface is tested independently, and when calling each call interface, it is not affected by other call interfaces. In other words, in the test requests sent by the second terminal 130, each test request is sent by calling a call interface, and different test requests call different call interfaces.

[0085] In one implementation, the control server 110 may select a port (which may be referred to as port Px) from among the unoccupied ports as the port for interaction between the target test server 140 and the second terminal 130, and maintain the network connection established between the target test server 140 and the second terminal 130 through the port, that is, keep the port alive to ensure that the transmission of test requests and call results between the target test server 140 and the second terminal 130 is not interrupted.

[0086] The master control server 110 can select a port from unoccupied ports as the port of the calling interface (which can be called P1) for each sub-function code in the code to be processed. After the target test server 140 receives a test request for a sub-function code through port Px, it can pass the test request to port P1 to pass the test request to the calling interface of the sub-function code.

[0087] S106 : The target test server 140 calls the locally stored code to be processed based on the storage path in the test request sent by the second terminal 130 .

[0088] S107 : The target test server 140 returns a call result to the second terminal 130 .

[0089] It can be understood that the test request is sent by the second terminal 130 through the calling interface of the sub-function code. The test request can carry the address of the target test server 140 and the storage path of the sub-function code to be called in the target test server. The target test server 140 can call the locally stored sub-function code based on the storage path in the test request to obtain the calling result.

[0090] Exemplarily, the interface information for the calling interface also includes format sub-information indicating the format of the test request and the format of the call result. After generating the interface information for each sub-function code, the master control server 110 may store the interface information on the target test server 140. The second terminal 130 may generate a test request according to the test request format indicated by the format sub-information and send the test request to the target test server 140. After calling the locally stored sub-function code, the target test server 140 may obtain the execution result of the sub-function code. The target test server 140 then generates a call result including the execution result according to the call result format indicated by the format sub-information.

[0091] The format sub-information indicating the format of the test request can be referred to as an input parameter model. This information can include the data type of the data in the test request. For example, if the data type included in the format sub-information indicating the format of the test request is a string, then the data in the test request sent by the second terminal 130 is a string. The format sub-information indicating the format of the call result can be referred to as a response model. This information can indicate that the call result must include a run result and a response status code. The response status code indicates the processing result of the request. For example, a response status code of 404 indicates that the resource requested by the second terminal 130 was not found on the target test server 140, while a response status code of 500 indicates an internal error in the target test server. Developers can determine the cause of the exception based on the response status code and make adjustments. For example, if the response status code is 404, developers can check whether the sub-function code in the storage path of the target test server 404 is missing.

[0092] S108 , the control server 110 obtains a call result from the second terminal 130 .

[0093] S109 , the main control server 110 determines whether the calling result is the same as the preset calling result, and obtains a test result indicating whether the calling interface of at least one sub-function code included in the code to be processed is abnormal.

[0094] It is understood that after the second terminal 130 obtains the call result, it can send the obtained call result to the master server 110. After the master server 110 obtains the call result from the second terminal 130, it can determine whether the call result is the same as the preset call result of the code to be processed. The preset call result of the code to be processed includes the preset call result of each sub-function code. The preset call result of each sub-function code includes the execution result obtained after the sub-function code is executed and conforms to the call result format indicated by the format sub-information in the interface information of the calling interface of the sub-function code.

[0095] For each sub-function code in the code to be processed, if the test result of the sub-function code is the same as the preset call result of the sub-function code, a test result indicating that the call interface of the sub-function code contained in the code to be processed is normal can be obtained. If the test result of the sub-function code is different from the preset call result of the sub-function code, a test result indicating that the call interface of the sub-function code contained in the code to be processed is abnormal can be obtained.

[0096] In one implementation, if the test results of each sub-function code in the pending code indicate no abnormalities, the pending code is added to the current no-abnormal sub-function code library to update the version of the current no-abnormal sub-function code library. For example, the current no-abnormal sub-function code library contains sub-function codes 1 and 2, and the current no-abnormal sub-function code library version number is dev1. If the test results of the newly submitted sub-function codes 3 and 4 indicate no abnormalities, sub-function codes 3 and 4 are added to the no-abnormal sub-function code library to obtain the current no-abnormal sub-function code library containing sub-function codes 1, 2, 3, and 4, and the current no-abnormal sub-function code library version number is updated to dev2. At this time, the no-abnormal sub-function code library with version number dev1 and containing sub-function codes 1 and 2 can be called the historical no-abnormal sub-function code library.

[0097] In one implementation, if the test results of each sub-function code in the code to be processed indicate no abnormalities, the code to be processed is added to the current sub-function code library without abnormalities, and the code to be processed in the master server 110 is deleted, and the port of the calling interface of each sub-function code in the code to be processed is set to unoccupied to release the storage resources and port resources of the master server.

[0098] Among them, the code in the current non-abnormal sub-function code base does not need to be tested by the developers who developed the code to be processed, and can be put into use in subsequent actual projects or further tested by other testers.

[0099] If the test results of the sub-function codes in the code to be processed show abnormal test results, the developer who developed the code to be processed needs to check the sub-function code whose test results show abnormality and the interface information of the calling interface of the sub-function code to find the cause of the abnormality and make adjustments.

[0100] In one implementation, the master control server 110 can detect whether the identifier (e.g., name) of the newly submitted sub-function code is consistent with the identifier of the previously submitted sub-function code to determine whether the sub-function code is resubmitted. If the sub-function code is resubmitted, the master control server deletes the sub-function code stored in the sub-function code and sets the address and port of the calling interface of the sub-function code to the address and port of the newly submitted sub-function code. The sub-function code stored in the target test server is then replaced with the newly submitted sub-function code.

[0101] It is understandable that in interface joint debugging, developers need to test the usage of the calling interface of each sub-function code in the front-end running environment, and debug the calling interface and sub-function code to ensure that there are no abnormalities in the calling interface.

[0102] In an embodiment of the present invention, developers do not need to pay attention to service deployment details such as the address in the calling interface, and do not need to communicate with front-end developers to determine the address of the calling interface. Developers only need to develop and submit business code normally, and each calling interface can be automatically tested, reducing the labor cost required for testing.

[0103] In one embodiment, if Figure 2 As shown, in Figure 1 In the interface testing system shown, the main control server 110 may further execute step S201 , step S102 includes step S1021 , and step S106 includes step S1061 .

[0104] S201 : The main control server 110 determines, for each sub-function code included in the code to be processed, whether it is necessary to test the calling interface for calling the sub-function code, and obtains a determination result of the sub-function code.

[0105] It is understandable that, because each developer submits pending code at different times, the sub-function codes within the pending code submitted by each developer are tested in a sequential order. If the pending code submitted by each developer contains sub-function codes with identical interface information for the calling interface, to avoid repeated testing of the same calling interface, a determination can be made as each sub-function code in the newly submitted pending code is processed whether the calling interface for calling the sub-function code needs to be tested, thereby obtaining a determination result for the sub-function code.

[0106] For example, if, before testing the interface information of each sub-function code in the code to be processed, other interface information identical to the interface information has been uploaded, then it can be determined that the determination result indicates that it is not necessary to test the calling interface for calling the sub-function code. If, before testing the interface information of the sub-function code, no other interface information identical to the interface information has been uploaded, then it can be determined that the determination result indicates that it is necessary to test the calling interface for calling the sub-function code.

[0107] S1021 : The main control server 110 sends the code to be processed and the determination result of at least one sub-function code included in the code to be processed to the target test server 140 .

[0108] S1061 : The target test server 140 calls at least one sub-function code included in the locally stored code to be processed according to the determination result and the storage path in the test request.

[0109] It is understandable that, when the master control server 110 stores the code to be processed in the target test server 140, it also stores the determination result of at least one sub-function code contained in the code to be processed in the target test server 140. For each sub-function code in the code to be processed, when the target test server 140 receives a test request for calling the sub-function code, if the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested, the locally stored sub-function code is called according to the storage path carried in the test request; if the determination result of the sub-function code function indicates that the calling interface for calling the sub-function code does not need to be tested, the sub-function code is not called, and no call data is returned to the second terminal 130, that is, no subsequent processing is performed.

[0110] In the embodiment of the present invention, the target test server 140 can determine whether to perform subsequent processing based on the determination result, thereby avoiding repeated testing of the same interface information and reducing the waste of operating resources.

[0111] In one embodiment, in order to obtain the determination result, the main control server 110 can obtain the determination result based on whether there is other interface information that needs to be tested and is the same as the interface information before obtaining the test result of the sub-function code. Figure 3 As shown, step S201 executed by the control server 110 may include steps S2011 to S2013.

[0112] S2011, for each sub-function code included in the code to be processed, if no sub-function code has been submitted before the code to be processed is submitted, determine that the judgment result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested.

[0113] It is understood that the submitted sub-function code is the sub-function code submitted before the newly submitted pending code was submitted. If the code database does not contain the submitted sub-function code before the new pending code was submitted, that is, if there is no sub-function code with the same interface information as the calling interface of the sub-function code in the new pending code, then it can be determined that the determination result for each sub-function code included in the pending code indicates that the calling interface for calling the sub-function code needs to be tested.

[0114] S2012: If there is a sub-function code submitted before the code to be processed is submitted, determine the sub-function code that is currently in effect and the sub-function code that is currently normal.

[0115] Among them, the currently effective sub-function code is: the judgment result indicates that the corresponding calling interface needs to be tested, and the sub-function code has not yet obtained the test result; the currently normal sub-function code is: the sub-function code recorded in the current normal sub-function code library has obtained the test result, and the test result indicates that there is no abnormality.

[0116] It is understandable that if there is a sub-function code submitted before the pending code is submitted, it is not certain whether there is a sub-function code with the same interface information as the calling interface of the sub-function code in the new pending code. More information is needed to further determine.

[0117] In order to obtain more information, the main control server 110 may determine the currently effective sub-function codes and the currently normal sub-function codes.

[0118] The currently effective sub-function code belongs to the submitted sub-function code, but the currently effective sub-function code has a judgment result, and the judgment result indicates that the corresponding calling interface needs to be tested. The currently effective sub-function code has not yet obtained a test result, that is, the currently effective sub-function code has been determined to be tested. The sub-function code with no abnormalities at present is: the sub-function code that has obtained a test result and the test result indicates that there is no abnormality recorded in the current sub-function code library without abnormalities. The above embodiment has described how the sub-function codes in the current sub-function code library without abnormalities are specifically obtained. The sub-function codes in the current sub-function code library without abnormalities have all obtained test results, and the test results indicate that there are no abnormalities.

[0119] In the updating method of the non-abnormal sub-function code library, in addition to adding the to-be-processed codes with non-abnormal test results of each sub-function code to the current non-abnormal sub-function code library as described in the above embodiment, other updating methods may also exist.

[0120] In one implementation, a developer can delete a sub-function code in a current no-anomaly sub-function code library to update the version of the current no-anomaly sub-function code library. For example, the current no-anomaly sub-function code library contains sub-function codes 1 and 2, and the current no-anomaly sub-function code library version number is dev1. If the developer deletes sub-function code 1 from the no-anomaly sub-function code library, the current no-anomaly sub-function code library containing sub-function code 2 is obtained, and the current no-anomaly sub-function code library version number is updated to dev2. At this time, the no-anomaly sub-function code library with version number dev1 and containing sub-function codes 1 and 2 can be called the historical no-anomaly sub-function code library.

[0121] In another implementation, the developer can modify the sub-function code in the current no-abnormal sub-function code library to update the version of the current no-abnormal sub-function code library. For example, the current no-abnormal sub-function code library contains sub-function codes 1 and 2, and the current no-abnormal sub-function code library version number is dev1. If the developer modifies sub-function code 1 in the no-abnormal sub-function code library to sub-function code 11, the current no-abnormal sub-function code library containing sub-function codes 11 and 2 is obtained, and the current no-abnormal sub-function code library version number is updated to dev2. At this time, the no-abnormal sub-function code library with version number dev2 and containing sub-function codes 1 and 2 can be called the historical no-abnormal sub-function code library.

[0122] S2013: If there is no sub-function code with the same storage path as the sub-function code among the currently effective sub-function codes and the sub-function codes without exceptions, the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested.

[0123] It is understandable that the storage path and format sub-information in the interface information of a calling interface can be used together as the unique identifier of the calling interface. If the storage path and format sub-information of two calling interfaces are the same, then the two calling interfaces can be considered the same. If there is a difference in one of the storage path and format sub-information, then the two calling interfaces can be considered different. For example, if the storage path of calling interface A is 1 and the format sub-information is 1, and the storage path of calling interface B is 1 and the format sub-information is 2, then calling interfaces A and B are different; if the storage path of calling interface A is 1 and the format sub-information is data 1, and the storage path of calling interface B is 2 and the format sub-information is data 1, then calling interfaces A and B are different; if the storage path of calling interface A is 1 and the format sub-information is data 1, and the storage path of calling interface B is 1 and the format sub-information is data 1, then calling interfaces A and B are different;

[0124] If there is no sub-function code with the same storage path as the sub-function code among the currently effective sub-function codes and the sub-function codes without exceptions, it can be determined that there is no sub-function code identical to the sub-function code among the currently effective sub-function codes and the sub-function codes without exceptions, that is, there is no sub-function code with the same interface information as the calling interface of the sub-function code in the new code to be processed, and then the judgment result is determined to indicate that the calling interface used to call the sub-function code needs to be tested.

[0125] In one implementation, if a sub-function code having the same storage path as the sub-function code exists in both the currently effective sub-function code and the sub-function code without exception, no subsequent processing is performed.

[0126] In an embodiment of the present invention, the main control server 110 can accurately obtain a judgment result based on whether the sub-function code has the same interface information as the calling interface of the sub-function code in the new code to be processed, and then determine whether to perform subsequent processing based on the accurate judgment result. It can accurately determine the calling interface that needs to be tested, avoid testing the calling interface of repeated interface information, avoid missing the test of the calling interface that needs to be tested, reduce the waste of operating resources, and ensure the execution of the test for the calling interface that needs to be tested.

[0127] In one embodiment, based on the above embodiment, the main control server 110 can obtain the determination result by combining the storage path and the format sub-information. Figure 4 As shown, the control server 110 may further execute steps S401 - S404 .

[0128] S401, for each sub-function code included in the code to be processed, if there is no sub-function code with the same storage path as the sub-function code in the current sub-function code without exception, and there is no sub-function code with the same format sub-information as the interface information of the sub-function code in the currently effective sub-function code with the same storage path as the sub-function code, then determine the historical sub-function code without exception in the historical sub-function code library without exception.

[0129] It is understandable that if sub-function codes exist in the current non-abnormal sub-function code base, developers have two development methods when developing the code to be processed.

[0130] In the first development method, the developer can synchronize all sub-function codes in the current non-anomaly sub-function code library to the first terminal used by the developer, and develop based on the synchronized sub-function code to obtain new code to be processed. Since the obtained code to be processed is inherited from the current non-anomaly sub-function code library, the interface information of the inherited sub-function code has been tested, and thus the inherited code to be processed does not need to be tested.

[0131] In the second development method, developers can develop based on the sub-function codes in the historical non-abnormal sub-function code library to obtain new pending code. That is to say, the sub-function codes in the historical non-abnormal sub-function code library are rolled back as new pending code. There are very few sub-function codes in the historical non-abnormal sub-function code library that are identical to the sub-function codes in the current non-abnormal sub-function code library. Since it is unknown whether the calling interface of the sub-function code obtained by rolling back is suitable for the current front-end operating environment, the calling interface of the sub-function code obtained by rolling back needs to be retested. Since in the first method, most of the content in the new pending code is inherited from the current non-abnormal sub-function code library, compared with the second method, the number of sub-function codes in the current non-abnormal sub-function code library that are identical to the sub-function codes of the new pending code obtained by the first method is larger.

[0132] In step S401, if there is no sub-function code with the same storage path as the sub-function code in the sub-function code currently without exception, it can be determined that there is no calling interface identical to the calling interface of the sub-function code in the calling interface of the sub-function code currently without exception. If there is no sub-function code with the same format sub-information as the interface information of the sub-function code in the currently effective sub-function code with the same storage path as the sub-function code, it can be determined that there is no calling interface identical to the calling interface of the sub-function code in the calling interface of the currently effective sub-function code. At this point, it is necessary to further consider the impact of the development method used by the developer on the code to be processed.

[0133] The master control server 110 can determine the historical non-abnormal sub-function code in the historical non-abnormal sub-function code library. For example, the master control server 110 can determine a historical non-abnormal sub-function code library with a lower version than the current non-abnormal sub-function code library, and determine the historical non-abnormal sub-function code from the historical non-abnormal sub-function code library. For example, if the current non-abnormal sub-function code library has a version number of 2 and the historical non-abnormal sub-function code library has a version number of 1, the non-abnormal sub-function code library with version number 1 can be determined as the historical non-abnormal sub-function code library.

[0134] S402. If there is no sub-function code in the historical non-abnormal sub-function code that has the same storage path as the sub-function code and the same format sub-information as the interface information of the sub-function code, then the determination result of the sub-function code indicates that the calling interface used to call the sub-function code needs to be tested.

[0135] It can be understood that if there is no sub-function code in the historical non-abnormal sub-function code that has the same storage path as the sub-function code and the same format sub-information as the interface information of the sub-function code, that is to say, there is no calling interface in the historical non-abnormal sub-function code that is the same as the calling interface of the sub-function code, it can be determined that the judgment result indicates that the calling interface used to call the sub-function code needs to be tested.

[0136] S403: If there is a sub-function code in the historical non-abnormal sub-function code that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code, determine the first number and the second number.

[0137] Among them, the first number is: the number of sub-function codes that are identical to the format sub-information in the interface information of the sub-function code in the historical non-abnormal sub-function codes with the same storage path as the sub-function code; the second number is: the number of sub-function codes that are identical to the format sub-data in the interface information of the currently effective sub-function code in the historical non-abnormal sub-function codes with the same storage path as the sub-function code.

[0138] S404: If the determined first number is smaller than the second number, the determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested.

[0139] It is understandable that, based on step S401, it has been determined that the calling interface of the current sub-function code without exception and the sub-function code that has taken effect does not contain a calling interface identical to the calling interface of the sub-function code. At this time, if there is a sub-function code in the historical sub-function code without exception that has the same storage path as the sub-function code and the same format sub-information as the interface information of the sub-function code, it is also necessary to combine the number of calling interfaces identical to the sub-function code in the historical sub-function code without exception to determine the development method. In other words, it is not yet certain whether the sub-function code is obtained by falling back to the historical sub-function code without exception, and it is not yet certain whether the calling interface used to call the sub-function code needs to be tested.

[0140] In order to determine whether the sub-function code is obtained by falling back to a historical sub-function code without exception, the main control server 110 can determine the first number of sub-function codes with the same format sub-information as the interface information of the sub-function code in the historical sub-function code without exception that has the same storage path as the sub-function code; the first number is the number of calling interfaces of the historical sub-function code without exception that is the same as the calling interface of the sub-function code.

[0141] The master control server 110 can determine a second number of sub-function codes with the same format sub-data as the interface information of the currently effective sub-function code, from historical non-abnormal sub-function codes stored in the same path as the sub-function code. The calling interface of the currently effective sub-function code needs to be tested, and the currently effective sub-function code is obtained through a fallback method. In other words, because the number of sub-function codes obtained through the fallback method that are identical to the historical sub-function codes is relatively small, and the number of sub-function codes obtained through the synchronization method that are identical to the historical sub-function codes is relatively large, the second number reflects the number of historical calling interfaces that are identical to the calling interfaces of the sub-function codes obtained through the fallback method.

[0142] Taking the second number as the standard, if the first number is smaller than the second number, that is, the number of historical calling interfaces that is identical to the calling interface is smaller than the number of historical calling interfaces that is identical to the calling interface to be tested, it can be determined that the sub-function code is obtained by fallback, and the calling interface of the sub-function code obtained by fallback needs to be tested, thereby determining the judgment result indicating that the calling interface used to call the sub-function code needs to be tested.

[0143] If the first number is not less than the second number, it can be determined that the calling interface of the sub-function code is newly added or changed in the calling interface of the effective sub-function code. When the test of the calling interface of the effective sub-function code is completed, the calling interface of the sub-function code has essentially completed the test. Therefore, the test of the calling interface of the sub-function code can be ignored, and the sub-function code will not be processed subsequently.

[0144] In an embodiment of the present invention, the main control server 110 can combine the calling interface of the historical sub-function code and the characteristics of the sub-function code and its calling interface obtained by developing the sub-function code in different ways to accurately determine the judgment result. Subsequently, based on the accurate judgment result, it is determined whether to perform subsequent processing. The calling interface that needs to be tested can be accurately determined, and the testing of the calling interface of repeated interface information can be avoided. At the same time, the testing of the calling interface that needs to be tested can be avoided, and the waste of operating resources can be reduced to ensure the execution of the test for the calling interface that needs to be tested.

[0145] Figure 5A schematic diagram illustrating the principles of an interface testing method provided by an embodiment of the present invention.

[0146] Each backend developer can develop their own backend functionality, generate pending code, and then submit the resulting pending code to the code database. For example, Backend Developer 1 and Backend Developer 2 can submit code to the code database normally. The master control server can detect whether new pending code has been submitted to the code database by listening for new pending code submission events, i.e., listening for trigger events.

[0147] When the master server detects that new pending code has been submitted to the code database, it selects a target test server from multiple test servers. The master server can store each sub-function code in the pending code on the target test server. For each sub-function code in the pending code, the master server generates interface information for invoking the sub-function code. The generated interface information includes the address of the target test server and the storage path of the sub-function code on the target test server. In other words, the master server obtains the address available for deployment, notifies the service of the deployment result, and then executes the service deployment.

[0148] The target test server, also known as a dedicated test server, can process multiple pending codes. For example, the master control server can process pending codes for implementing function X and pending codes for implementing function Y. The pending codes for implementing function X may include sub-function codes for implementing sub-function X1, sub-function codes for implementing sub-function X2, and sub-function codes for implementing sub-function X3. The pending codes for implementing function Y may include sub-function codes for implementing function Y1.

[0149] The master control server can send the generated interface information to the first terminal, which is the device used by the front-end developer. The front-end developer can use the address of the target test server as the address for calling the interface to implement subsequent joint debugging. In other words, the joint debugging address is fixed.

[0150] Upon receiving a test request from a second terminal, the target test server invokes at least one sub-function code contained in the locally stored pending code based on the storage path carried in the test request, and returns the invocation result to the second terminal. The test request is sent by the second terminal in response to a triggering of a target function integrated into the front-end page displayed by the second terminal. The target function is implemented based on the sub-function code corresponding to the interface information received by the first terminal.

[0151] The main control server can obtain the calling result from the second terminal, and determine whether the calling result is the same as the preset calling result, and obtain a test result indicating whether the calling interface of at least one sub-function code included in the code to be processed is abnormal.

[0152] Figure 6 Schematic diagram of the flow of the first interface detection method provided by the embodiment of the present invention. Figure 6 As shown, the interface detection method is applied to the master control server and includes the following steps:

[0153] S601: Select a target test server from multiple test servers.

[0154] S602: Send the code to be processed to the target test server so that the target test server stores the code to be processed, and obtain the storage path of each sub-function code in the code to be processed in the target test server.

[0155] S603: For each sub-function code in the code to be processed, generate interface information of a calling interface for calling the sub-function code.

[0156] The generated interface information includes: the address of the target test server and the storage path of the sub-function code in the target test server.

[0157] S604: Send the generated interface information to the first terminal, so that the first terminal generates a front-end page integrating the target function based on the received interface information.

[0158] S605: Determine whether the calling result obtained from the second terminal is the same as the preset calling result, and obtain a test result indicating whether the calling interface of at least one sub-function code included in the code to be processed is abnormal.

[0159] The target function is implemented based on the sub-function code corresponding to the received interface information; the front-end page is displayed on the second terminal. The call result is the call result returned to the second terminal by the target test server after calling the locally stored pending code based on the storage path in the test request sent by the second terminal; the test request is sent in response to the triggering of the target function.

[0160] Figure 7 Schematic diagram of the flow of the second interface detection method provided by the embodiment of the present invention. Figure 7 As shown, the interface detection method is applied to a target test server among multiple test servers, and the method includes the following steps:

[0161] S701: When receiving a test request sent by a second terminal, calling a locally stored to-be-processed code based on a storage path in the test request.

[0162] Among them, the storage path in the test request is the storage path of the sub-function code in the code to be processed in the target test server; the target test server stores the code to be processed sent by the master server, and the target test server is selected by the master server from multiple test servers; the test request is sent in response to the triggering of the target function integrated in the front-end page displayed by the second terminal; the front-end page is a front-end page integrated with the target function generated by the first terminal based on the interface information received from the master server; the target function is implemented based on the sub-function code corresponding to the received interface information; the received interface information includes the address of the target test server and the storage path of the sub-function code in the target test server.

[0163] S702: Return the calling result to the second terminal.

[0164] In an embodiment of the present invention, the sub-function code in the code to be processed is stored in the target test server selected by the machine, and interface information including the address of the target test server and the storage path of the sub-function code in the target test server is generated. Therefore, when testing the calling interface of each sub-function code, a test request can be sent to the address of the target test server. When calling the calling interface, the sub-function code stored locally on the target test server can be called based on the storage path in the test request, and the calling result can be returned, thereby avoiding manual determination of the service address in the calling interface of each back-end function one by one, completing the test of the calling interface of the sub-function code, and improving the overall efficiency of the interface test.

[0165] Figure 8 This is a structural diagram of a first interface detection device provided by an embodiment of the present invention.

[0166] The interface detection device is applied to the main control server, such as Figure 8 As shown, the device includes:

[0167] A selection module 810 is configured to select a target test server from a plurality of test servers;

[0168] The storage module 820 is configured to generate, for each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server;

[0169] A generating module 830 is configured to generate, for each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server;

[0170] A first sending module 840 is configured to send the generated interface information to a first terminal, so that the first terminal generates a front-end page integrating a target function based on the received interface information, where the target function is implemented based on a sub-function code corresponding to the received interface information; and the front-end page is displayed on a second terminal;

[0171] The first judgment module 850 is used to determine whether the call result obtained from the second terminal is the same as the preset call result, and obtain a test result indicating whether the call interface of at least one sub-function code contained in the code to be processed is abnormal; wherein, the call result is the call result returned to the second terminal by the target test server calling the locally stored code to be processed based on the storage path in the test request sent by the second terminal; the test request is sent in response to the triggering of the target function.

[0172] Optionally, the device further includes:

[0173] A second judgment module is used to judge, for each sub-function code included in the code to be processed, whether it is necessary to test the calling interface for calling the sub-function code, and obtain a judgment result of the sub-function code;

[0174] The storage module 820 is specifically used to send the determination result of the code to be processed and at least one sub-function code contained in the code to be processed to the target test server, so that the target test server calls the at least one sub-function code contained in the locally stored code to be processed according to the determination result and the storage path in the test request, and returns the call result to the second terminal.

[0175] Optionally, the second judgment module includes:

[0176] a first determining unit configured to determine, for each sub-function code included in the code to be processed, if no sub-function code has been submitted before the code to be processed is submitted, whether a determination result of the sub-function code indicates that a test needs to be performed on a calling interface for calling the sub-function code;

[0177] The second determining unit is configured to determine, if a sub-function code that has been submitted exists before the code to be processed is submitted, a sub-function code that is currently in effect and a sub-function code that is currently free of exceptions; wherein the sub-function code that is currently in effect is a sub-function code for which a determination result indicates that a test of a corresponding calling interface is required and for which no test result has been obtained; and the sub-function code that is currently free of exceptions is a sub-function code that has obtained a test result recorded in a current free of exceptions sub-function code library and for which the test result indicates that there is no exception;

[0178] a third determining unit configured to, if no sub-function code having the same storage path as the sub-function code exists among the currently effective sub-function codes and the sub-function codes without exceptions, determine that a determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested;

[0179] The device further comprises:

[0180] The adding module is used to add the to-be-processed code to the current non-abnormal sub-function code library for each sub-function code in the to-be-processed code if the test result of each sub-function code indicates no abnormality, so as to update the version of the current non-abnormal sub-function code library.

[0181] Optionally, the interface information of the calling interface of a sub-function code further includes format sub-information indicating the format of the test request and the format of the calling result; the apparatus further includes:

[0182] A first determining module is configured to determine, for each sub-function code included in the code to be processed, a historical non-abnormal sub-function code in a historical non-abnormal sub-function code library if, among the currently non-abnormal sub-function codes, there is no sub-function code having the same storage path as the sub-function code, and among the currently effective sub-function codes having the same storage path as the sub-function code, there is no sub-function code having the same format sub-information as that in the interface information of the sub-function code;

[0183] a second determination module configured to determine that a determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested if there is no sub-function code having the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code among the historical non-abnormal sub-function codes;

[0184] A third determining module is configured to determine a first number and a second number if, among the historical non-abnormal sub-function codes, there is a sub-function code having the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code; wherein the first number is: the number of sub-function codes having the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code; and the second number is: the number of sub-function codes having the same storage path as the sub-function code and the same format sub-data as that in the interface information of the currently effective sub-function code;

[0185] The fourth determining module is configured to determine, if the determined first number is smaller than the second number, that the determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested.

[0186] Figure 9 This is a structural diagram of a second interface detection device provided by an embodiment of the present invention.

[0187] The interface detection device is applied to a target test server among multiple test servers, such as Figure 9 As shown, the device includes:

[0188] The calling module 910 is configured to call the locally stored pending code based on the storage path in the test request upon receiving a test request sent by the second terminal; wherein the storage path in the test request is the storage path of the sub-function code in the pending code in the target test server; the target test server stores the pending code sent by the master server, and the target test server is selected by the master server from multiple test servers; the test request is sent in response to a trigger of a target function integrated in a front-end page displayed by the second terminal; the front-end page is a front-end page integrated with the target function generated by the first terminal based on interface information received from the master server; the target function is implemented by the sub-function code corresponding to the received interface information; the received interface information includes: the address of the target test server and the storage path of the sub-function code in the target test server;

[0189] The returning module 920 is configured to return the calling result to the second terminal.

[0190] Optionally, the calling module 910 is specifically used to call at least one sub-function code contained in the locally stored code to be processed based on the judgment result and the storage path in the test request; wherein, the judgment result is obtained by the main control server determining whether it is necessary to test the calling interface used to call the sub-function code for each sub-function code contained in the code to be processed.

[0191] In an embodiment of the present invention, the sub-function code in the code to be processed is stored in the target test server selected by the machine, and interface information including the address of the target test server and the storage path of the sub-function code in the target test server is generated. Therefore, when testing the calling interface of each sub-function code, a test request can be sent to the address of the target test server. When calling the calling interface, the sub-function code stored locally on the target test server can be called based on the storage path in the test request, and the calling result can be returned, thereby avoiding manual determination of the service address in the calling interface of each back-end function one by one, completing the test of the calling interface of the sub-function code, and improving the overall efficiency of the interface test.

[0192] The embodiment of the present invention further provides an electronic device, such as Figure 10As shown, it includes a processor 1001 , a communication interface 1002 , a memory 1003 and a communication bus 1004 , wherein the processor 1001 , the communication interface 1002 , and the memory 1003 communicate with each other via the communication bus 1004 .

[0193] Memory 1003, used for storing computer programs;

[0194] The processor 1001 is configured to implement the above interface testing method when executing the program stored in the memory 1003 .

[0195] The communication bus mentioned in the electronic devices mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into address buses, data buses, control buses, etc. For ease of illustration, only a single thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0196] The communication interface is used for communication between the above electronic device and other devices.

[0197] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage. Alternatively, the memory may be at least one storage device located away from the processor.

[0198] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0199] In another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned interface testing methods are implemented.

[0200] In another embodiment of the present invention, a computer program product including instructions is provided, which, when executed on a computer, enables the computer to execute any one of the interface testing methods in the above embodiments.

[0201] In the above embodiments, all or part of the embodiments can be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in accordance with the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be magnetic media (e.g., floppy disk, hard disk, tape), optical media (e.g., DVD), or semiconductor media (e.g., solid-state disk (SSD)).

[0202] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0203] Each embodiment in this specification is described in a related manner. Similar portions between the embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so their description is relatively simple. For related portions, refer to the description of the method embodiments.

[0204] The above description is only a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention are included in the scope of protection of the present invention.

Claims

1. An interface testing method, characterized in that: Applied to a master control server, the method includes: Whenever a new code to be processed is detected in a code database, a target test server is selected from multiple test servers; the code in the code database is obtained by using a multi-person parallel development method; If a submitted sub-function code exists before the pending code is submitted, determine the currently effective sub-function code and the currently normal sub-function code; wherein the currently effective sub-function code is: a sub-function code for which the determination result indicates that the corresponding calling interface needs to be tested and the test result has not yet been obtained; the currently normal sub-function code is: a sub-function code recorded in the current normal sub-function code library for which a test result has been obtained and the test result indicates that there is no abnormality; if there is no sub-function code with the same storage path as the sub-function code among the currently effective sub-function code and the normal sub-function code, determine that the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested; Sending the code to be processed and the determination result of at least one sub-function code contained in the code to be processed to the target test server; obtaining the storage path of each sub-function code in the code to be processed in the target test server; For each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code is generated; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server; Sending the generated interface information to the first terminal, so that the first terminal generates a front-end page integrating a target function based on the received interface information, where the target function is implemented based on a sub-function code corresponding to the received interface information; and displaying the front-end page on the second terminal; Determine whether the call result obtained from the second terminal is the same as the preset call result, and obtain a test result indicating whether the call interface of at least one sub-function code contained in the code to be processed is abnormal; wherein, the call result is the call result returned to the second terminal by the target test server by calling at least one sub-function code contained in the locally stored code to be processed according to the determination result and the storage path in the test request; the test request is sent in response to the triggering of the target function.

2. The method according to claim 1, characterized in that The method further comprises: For each sub-function code included in the code to be processed, if no sub-function code has been submitted before the code to be processed is submitted, determining that the determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested; and / or, The method further comprises: For each sub-function code in the code to be processed, if the test result of each sub-function code indicates no abnormality, the code to be processed is added to the current sub-function code library without abnormality to update the version of the current sub-function code library without abnormality.

3. The method according to claim 2, characterized in that The interface information of the calling interface of a sub-function code also includes format sub-information indicating the format of the test request and the format of the calling result; The method further comprises: For each sub-function code included in the code to be processed, if there is no sub-function code with the same storage path as the sub-function code among the currently non-abnormal sub-function codes, and there is no sub-function code with the same format sub-information in the interface information of the sub-function code among the currently effective sub-function codes with the same storage path as the sub-function code, then determine a historical non-abnormal sub-function code in the historical non-abnormal sub-function code library; If there is no sub-function code in the historical non-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code, then the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested; If there is a sub-function code in the history of no-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code, a first number and a second number are determined; wherein the first number is: the number of sub-function codes in the history of no-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-information as that in the interface information of the sub-function code; and the second number is: the number of sub-function codes in the history of no-abnormal sub-function codes that has the same storage path as the sub-function code and the same format sub-data as that in the interface information of the currently effective sub-function code; If the determined first number is smaller than the second number, the determination result of the sub-function code indicates that a calling interface for calling the sub-function code needs to be tested.

4. An interface testing method, characterized in that: The method is applied to a target test server among multiple test servers, and the method includes: Upon receiving a test request sent by the second terminal, at least one sub-function code included in the locally stored code to be processed is called according to the determination result and the storage path in the test request; the storage path in the test request is the storage path of the sub-function code in the code to be processed in the target test server; the target test server stores the code to be processed sent by the master server, and the target test server is selected from multiple test servers by the master server whenever it detects that new code to be processed is submitted in the code database; the code in the code database is obtained using a multi-person parallel development method; the test request is sent in response to a trigger of a target function integrated in a front-end page displayed by the second terminal; the front-end page is a front-end page integrated with the target function generated by the first terminal based on the interface information received from the master server; the target function is implemented based on the sub-function code corresponding to the received interface information; the received interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server; The determination result is obtained according to the following steps: if a submitted sub-function code exists before the code to be processed is submitted, the master control server determines the sub-function code that is currently in effect and the sub-function code that is currently free of exceptions; wherein the sub-function code that is currently in effect is a sub-function code for which the determination result indicates that the corresponding calling interface needs to be tested and no test result has been obtained; the sub-function code that is currently free of exceptions is a sub-function code for which a test result has been obtained and the test result indicates that there is no exception, as recorded in the current free-of-exceptions sub-function code library; if there is no sub-function code with the same storage path as the sub-function code among the sub-function codes that are currently in effect and the sub-function codes without exceptions, determining that the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested; Return the call result to the second terminal.

5. An interface testing system, characterized in that: The system includes: a main control server and multiple test servers; The master control server is used to execute the method according to any one of claims 1 to 3 above; Any one of the multiple test servers is configured to execute the method according to claim 4.

6. An interface testing device, characterized in that: Applied to a master control server, the device includes: A selection module is configured to select a target test server from a plurality of test servers whenever a new code to be processed is detected in a code database where the code is obtained by a multi-person parallel development method; The second judgment module is used to determine the currently effective sub-function code and the currently normal sub-function code if a submitted sub-function code exists before the pending code is submitted; wherein the currently effective sub-function code is: a sub-function code for which the judgment result indicates that the corresponding calling interface needs to be tested and the test result has not yet been obtained; the currently normal sub-function code is: a sub-function code recorded in the current normal sub-function code library for which a test result has been obtained and the test result indicates that there is no abnormality; if there is no sub-function code with the same storage path as the sub-function code among the currently effective sub-function code and the normal sub-function code, it is determined that the judgment result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested; a storage module, configured to send the code to be processed and a determination result of at least one sub-function code contained in the code to be processed to the target test server; and obtain a storage path of each sub-function code in the code to be processed in the target test server; A generating module, configured to generate, for each sub-function code in the code to be processed, interface information of a calling interface for calling the sub-function code; wherein the generated interface information includes: the address of the target test server and the storage path of the sub-function code on the target test server; a first sending module, configured to send the generated interface information to a first terminal, so that the first terminal generates a front-end page integrating a target function based on the received interface information, wherein the target function is implemented based on a sub-function code corresponding to the received interface information; and the front-end page is displayed on a second terminal; The first judgment module is used to determine whether the call result obtained from the second terminal is the same as the preset call result, and obtain a test result indicating whether the call interface of at least one sub-function code contained in the code to be processed is abnormal; wherein, the call result is the call result returned to the second terminal by the target test server by calling at least one sub-function code contained in the locally stored code to be processed according to the judgment result and the storage path in the test request; the test request is sent in response to the triggering of the target function.

7. An interface testing device, characterized in that: The device is applied to a target test server among multiple test servers, and the device includes: A calling module, configured to, upon receiving a test request sent by a second terminal, call at least one sub-function code contained in a locally stored code to be processed according to a determination result and a storage path in the test request; the storage path in the test request is a storage path of the sub-function code in the code to be processed in the target test server; the target test server stores the code to be processed sent by the master control server, and the target test server is selected from a plurality of test servers whenever the master control server detects that a new code to be processed is submitted in a code database; the code in the code database is obtained using a multi-person parallel development method; the test request is sent in response to a trigger of a target function integrated in a front-end page displayed by the second terminal; the front-end page is a front-end page integrated with the target function generated by the first terminal based on interface information received from the master control server; the target function is implemented based on the sub-function code corresponding to the received interface information; the received interface information includes: the address of the target test server and the storage path of the sub-function code in the target test server; The determination result is obtained according to the following steps: if a submitted sub-function code exists before the code to be processed is submitted, the master control server determines the sub-function code that is currently in effect and the sub-function code that is currently free of exceptions; wherein the sub-function code that is currently in effect is a sub-function code for which the determination result indicates that the corresponding calling interface needs to be tested and no test result has been obtained; the sub-function code that is currently free of exceptions is a sub-function code for which a test result has been obtained and the test result indicates that there is no exception, as recorded in the current free-of-exceptions sub-function code library; if there is no sub-function code with the same storage path as the sub-function code among the sub-function codes that are currently in effect and the sub-function codes without exceptions, determining that the determination result of the sub-function code indicates that the calling interface for calling the sub-function code needs to be tested; The returning module is used to return the calling result to the second terminal.

8. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory for storing computer programs; A processor, configured to implement the method according to any one of claims 1 to 4 when executing a program stored in a memory.

Citation Information

Patent Citations

  • Interface testing method and device

    CN105099811A

  • Software testing method, device, server and system

    CN113760763A