CN112540915B - Interface testing method, device and system - Google Patents
Interface testing method, device and system Download PDFInfo
- Publication number
- CN112540915B CN112540915B CN202011378396.5A CN202011378396A CN112540915B CN 112540915 B CN112540915 B CN 112540915B CN 202011378396 A CN202011378396 A CN 202011378396A CN 112540915 B CN112540915 B CN 112540915B
- Authority
- CN
- China
- Prior art keywords
- test
- interface
- function
- dependent
- calling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the application provides an interface testing method, device and system. In some embodiments of the application, a call request carrying a test parameter is obtained; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; and calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result. Through the technical scheme, even if complex dependency relationships and call relationships are involved in the test process of the target interface function, the test user can be helped by using the context to better complete the test work of the target interface function, and the test requirement of the interface multiple call relationships can be met.
Description
Technical Field
The present application relates to the field of network device testing technologies, and in particular, to an interface testing method, device, and system.
Background
With the development of network operating system componentization development technology, more and more systems are divided into several functionally cohesive components, and interaction between components is performed, for example, through a C-language programming interface (C programming language Application Program Interface, CAPI). When a system is newly built or upgraded, the relevant components in the system need to be tested.
In the prior art, due to the complex call relationship among the components, when testing the call interface, the test of various conditions such as various exception handling, compatibility, boundary handling and the like needs to be fully considered. However, in the process of testing by a tester in face of a complex calling relationship, the problem of inaccurate test results due to incomplete consideration may occur; or because the calling relation and the dependency relation between the interfaces are complex, the testing efficiency of the testers is low.
Disclosure of Invention
The application provides an interface testing method, device and system, which are used for simplifying the testing task of an interface with a complex calling relationship and improving the testing efficiency.
In a first aspect, an embodiment of the present application provides an interface testing method, where the method includes:
Acquiring a calling request carrying test parameters;
if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address;
generating function call information based on the test parameters and the first context construct;
and calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result.
In a second aspect, an embodiment of the present application provides another method for testing an interface, where the method includes:
generating a calling request containing test parameters based on a preset test case and test data;
Sending the call request to test equipment so that the test equipment analyzes the call request, if the preset test case contains a context address, analyzing to obtain the context address, and constructing function call information according to a first context corresponding to the context address and the test parameter;
Receiving an execution result fed back by the test equipment; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function call information.
In a third aspect, an embodiment of the present application provides an interface testing apparatus, including:
the acquisition module is used for acquiring a call request carrying the test parameters;
the acquisition module is further configured to acquire a corresponding first context based on the context address if the context address is obtained by resolving the call request;
the generating module is used for generating function call information based on the test parameters and the first context structure;
And the generating module is also used for calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result.
In a fourth aspect, an embodiment of the present application provides another interface testing apparatus, where the method includes:
the generating module is used for generating a calling request containing test parameters based on a preset test case and test data;
The sending module is used for sending the calling request to the testing equipment so that the testing equipment analyzes the calling request, if the preset test case contains a context address, the context address is obtained through analysis, and function calling information is constructed according to a first context corresponding to the context address and the test parameter;
The receiving module is used for receiving the execution result fed back by the test equipment; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function call information.
In a fifth aspect, an embodiment of the present application provides an interface test system, the system including: test background and test equipment;
The test equipment is used for acquiring a call request carrying test parameters; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; calling a target interface function to execute a test based on the function calling information, and generating and feeding back an execution result;
The test background is used for generating a call request containing test parameters based on a preset test case and test data; sending the call request to test equipment so that the test equipment analyzes the call request, if the preset test case contains a context address, analyzing to obtain the context address, and constructing function call information according to a first context corresponding to the context address and the test parameter; and receiving an execution result fed back by the test equipment.
In some embodiments of the present application, there may be relatively complex call relationships and dependencies due to the target interface function when testing the target interface function. In the test process, a call request carrying test parameters is obtained; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; and calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result. Through the embodiment, even if complex dependency relationships and call relationships are involved in the test process of the target interface function, the test user can be helped by using the context to better complete the test work of the target interface function, and the test requirement of the interface multiple call relationships can be met.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:
FIG. 1 is a flow chart of a method for testing an interface according to an embodiment of the present application;
FIG. 2 is a schematic diagram of an interface test based on a set-up interface according to an embodiment of the present application;
FIG. 3 is a schematic diagram of interface testing based on an acquired interface according to an embodiment of the present application;
Fig. 4 is a schematic diagram of an interface test based on a registration type interface according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a configuration of a dependent interface implementation form selection according to an embodiment of the present application;
FIG. 6 is a flowchart illustrating another method for testing an interface according to an embodiment of the present application;
FIG. 7a is a schematic diagram of an interface testing system according to an embodiment of the present application;
FIG. 7b is a schematic diagram illustrating an interface test system according to an embodiment of the present application;
FIG. 8 is a schematic workflow diagram of a test execution framework according to an embodiment of the present application;
FIG. 9 is a schematic diagram illustrating the operation of the interface call proxy service provided by an embodiment of the present application;
fig. 10 is a schematic structural diagram of an interface testing device according to an embodiment of the present application;
fig. 11 is a schematic structural diagram of an interface testing device according to an embodiment of the present application.
Detailed Description
In order to further remove the objects, technical solutions and advantages of the present application, the following description will fully describe the technical solutions of the present application with reference to the specific embodiments of the present application and the corresponding drawings. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise, the "plurality" generally includes at least two, but does not exclude the case of at least one.
The words "if", as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination" or "in response to a detection", depending on the context. Similarly, the phrase "if determined" or "if detected (stated condition or event)" may be interpreted as "when determined" or "in response to determination" or "when detected (stated condition or event)" or "in response to detection (stated condition or event), depending on the context.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a product or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such product or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a commodity or system comprising such elements.
The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.
In practical applications, the network operating system mostly adopts a componentized development mode, and when testing, each component and an interface (for example, a C-language programming interface, abbreviated as CAPI) included in the component need to be tested. During normal operation of the component, the interfaces in the component have a calling relationship with many interfaces or components. When testing, only typical testing can be performed, and it is difficult to comprehensively cover boundary processing, exception handling, compatibility and external dependency relationships. Therefore, the inventor provides a technical scheme capable of meeting the requirements of testing complex context and dependency of component interfaces.
Fig. 1 is a flow chart of a method for testing an interface according to an embodiment of the present application. The subject of execution of the method may be a test device. As can be seen from fig. 1, the method comprises the steps of:
101: and acquiring a call request carrying the test parameters.
102: And if the calling request is analyzed to obtain the context address, acquiring a corresponding first context based on the context address.
103: Function call information is generated based on the test parameters and the first context construct.
104: And calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result.
When the test equipment performs interface test, a call request which is sent by a test background and aims at the tested interface, namely the target interface function, is obtained. The call request includes a test parameter, and in some cases, a context address may be included in the call request.
In practical application, multiple calls may be required to output a final result in the process of testing the target interface function, and in the process of multiple calls, the execution result of the previous step may be used as the relevant parameter of the next step, namely the first context and the second context in the application. Thus, when the target interface function is called, it can be known whether the acquisition context is required by parsing the call request. For example, if the context address is obtained by parsing, the corresponding first context is found according to the context address. The first context is structured into function call information in combination with other relevant parameters, such as data type definitions, interface definitions, etc., to perform subsequent test work based on the function call information.
If the call request is parsed to contain no context address, then no available context is indicated. Therefore, when generating the function call information, the function call information is directly generated based on the data type definition, the interface definition, and the like.
In some test cases, if a second context is included in the execution result, the second context is stored locally.
If the second context is included in the execution result obtained in the process of testing the target interface function, the second context can be stored locally so as to be used continuously in the current or subsequent test process, and thus the test requirement of the target interface function with complex context calling relationship can be met. In addition, the saved context may also be applied to the testing of other interface functions. If the execution result after the execution of the test does not contain other contexts, the execution result is not saved.
In one or more embodiments of the present application, the calling a target interface function to perform a test based on the function call information includes: acquiring an operation address of the target interface function based on the test parameters; and according to the running address and the test parameter, sending function call information to the target interface function to execute the test.
And acquiring the running address of the target interface function based on the test parameters. And further, according to the operation address and the test parameters, function call information is sent to the target interface function. In the test process, the tested component or the test avatar can be dynamically loaded through the interface proxy service to obtain the interface function which can be called and is provided by the tested component or the test avatar, wherein the interface function can be a target interface function or an interface function corresponding to a dependent interface. And executing the corresponding target interface function related test step based on the running address and the test parameter corresponding to the called interface function.
The interface proxy service execution process may use abstract, easy-to-use scripted programming. For example, the number of the cells to be processed,
test_case_string_concat
${result}Invoke_CAPI"string_concat""Hello""World"
Should_Be_Equat "HelloWorld" $ { result } in the script example described above:
test_case_string_conf is the test case name;
invoke_caps is a key for invoking interface caps;
"string_concat" is the name of the CAPI under test, and the function of the CAPI is to splice strings;
"Hello" is the first test parameter of the CAPI under test;
"World" is the second test parameter of the CAPI under test;
The $ { result } is the execution result of the CAPI under test;
"Hello World" is the expected result;
The should_be_equal is a key used to check if the result is consistent with expectations, mark the use case as successful if consistent, and mark the use case as failed if inconsistent.
It should be noted that, in the process of interacting with the test background, the test device needs to be assisted by an adaptation layer (for example, an interface call proxy client IIPC), so that the test device with different types of target interface functions can be docked. One implementation of the adaptation layer is illustrated below:
Wherein, an invoke_CAPI method is implemented using a Python module:
1) The first test parameter is the function name of the CAPI target interface function.
2) The second test parameter is a variable test parameter, i.e., any number of test parameters may follow the name to accommodate any type of CAPI.
3) The name and all test parameters are stitched into a request, using space separation.
4) Interaction between IIPC and IIPS is via redis database (other interaction means may be used).
5) The IIPC issues a call request to IIPS over the capi_ REQUST channel.
6) IIPC subscribes to call replies from IIPS over CAPI_RESULT channel.
7) And returning an execution result.
In one or more embodiments of the present application, the sending function call information to the target interface function to perform a test according to the operation address and the test parameter includes: if the target interface function depends on the external relation to execute the test, determining a dependent interface of a test proxy with a dependent relation with the target interface function based on the function call information; and executing the call flow of the dependent interface based on the interface type of the dependent interface so as to test the target interface function.
The test flows aiming at different target interface functions may not be identical, and in some cases, function call information may be sent to the target interface functions by the test background, and in some cases, function call information may be sent to the test proxy by the test background. In the following embodiments, the respective cases will be illustrated, and the detailed description will not be repeated here.
In practical application, the tested component includes objective interface functions to be tested and various other related functions for assisting in completing the objective interface function test. The tested component is used for receiving the function call information and determining a dependent interface with a dependent relation with the test avatar; and calling the dependent interface according to the function calling information.
In practical applications, some objective interface functions may need to call a system interface or an external interface, or artificially created test conditions under test conditions may be satisfied by relying on interfaces. Specifically, after receiving the function call request, a dependency interface in the test avatar for providing a dependency relationship for the test procedure is determined according to the function call request.
In one or more embodiments of the present application, at least one interface type corresponding to the dependent interface is determined according to a data flow direction relationship between the tested component and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface; and calling the dependent interface according to the calling flow of the at least one interface type.
For ease of understanding, the process of testing dependent interfaces based on three interface types is illustrated below.
Fig. 2 is a schematic diagram of performing an interface test based on a set-up interface according to an embodiment of the present application. As shown in fig. 2, first, a test execution framework TEF in the test background sends test parameters (e.g., invoke_capi key) to the component under test, calling a target interface function under test (CAPI) provided by the component under test CUT. After the tested component receives the call request, the CAPI is normally processed according to the preset execution logic of the tested component. And after the processing is finished, continuously calling the setting type interface provided by the test stand TD, and providing test parameters for the setting type interface. The test stand stores the test parameters and notifies the test background that the receiving and storing of the test parameters are completed. Furthermore, the test execution framework TEF sends an invoke_CAPI keyword to the test avatar, calls a control interface of the test avatar to obtain test parameters provided by the test avatar, returns the test parameters (the test parameters represent execution results) to the test background, and then compares the received execution results with expected data by the test background to judge whether the received execution results are consistent with expected data. If the target interface function is consistent, the target interface function test is successful, otherwise, if the target interface function test is inconsistent, the target interface function test is failed, and related staff is required to be informed to check and process the errors.
Fig. 3 is a schematic diagram of an interface test based on an acquired interface according to an embodiment of the present application. As shown in fig. 3, the test background sends test parameters to the test stand, injects specified data into the acquisition interface of the test stand, and notifies the test background that the test parameters are received and stored. Furthermore, the test background sends invoke_CAPI keywords to the tested component, invokes the tested target interface function provided by the tested component CUT, invokes the acquisition type interface of the test proxy through the tested component, and further feeds back the saved test parameters to the tested component through the acquisition type interface. The tested component processes according to the preset processing logic after receiving the test parameters, and feeds back the execution result to the test background, and the test background compares the received execution result with the expected result to judge whether the execution result is consistent. If the test results are consistent, the test of the target interface function is successful, and if the test results are inconsistent, the test of the target interface function is failed.
Fig. 4 is a schematic diagram of an interface test based on a registration type interface according to an embodiment of the present application. As shown in fig. 4, the test background sends an invoke_capi key to the component under test, invoking the CAPI under test provided by the component under test CUT. After the tested component receives the call request, the CAPI is normally processed according to preset execution logic of the tested component. And after the processing is finished, calling a registration type interface provided by the test proxy TD, and providing test parameters for the registration type interface. The test proxy TD stores event processing functions of the tested component corresponding to the test parameters and informs the test background that the test parameters are received and stored. Furthermore, the test background sends an invoke_CAPI key word to the test avatar, calls a control interface trigger event provided by the test avatar, and calls an event processing function of the tested component back to the test avatar. And after the tested component receives the event processing function, carrying out event processing according to a preset processing logic. And after the tested component is processed, sending the finished notification information to the test background. The test background sends a processing result (namely an execution result) corresponding to the acquired event processing function to the tested component. And the test background compares the received processing result with the expected result and judges whether the processing result is consistent with the expected result. If the target interface function is consistent, the target interface function test is successful, otherwise, if the target interface function test is inconsistent, the target interface function test is failed, and related staff is required to be informed to check and process the errors.
In practical applications, the test avatar is further configured to: selecting at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; and calling the dependent interface according to the at least one implementation form.
The original implementation described herein may be understood as an internal invocation of the actual dependent component implementation, and the wrapped implementation may be understood as wrapping the original implementation, allowing some additional related processing to be performed before and after invocation of the original implementation.
For ease of understanding, the following illustrates the dependency interface invocation procedure for three implementations.
Fig. 5 is a schematic structural diagram of implementation form selection of a dependent interface according to an embodiment of the present application. As can be seen from fig. 5, a selection interface is included in the test avatar to provide a selection of dependent interfaces, which selection can be selectively controlled as desired. When the tested component calls the dependent interface, the tested component calls according to the selection result of the selection interface, and the tested component can call the original implementation, the coverage implementation and the package implementation. If the original implementation is selected, the original implementation can be loaded and invoked directly by testing the avatar. For overlay and parcel implementations, the selection of the dependent interface may be controlled directly or indirectly by the calling device. In the technical scheme of the application, the three implementation modes can be switched according to the requirement of the test case during operation.
Based on the same thought, the embodiment of the application also provides another interface testing method. The method can be used in a test background. Fig. 6 is a flowchart of another interface testing method according to an embodiment of the present application. As can be seen from fig. 6, the method comprises:
601: and generating a calling request containing the test parameters based on the preset test case and the test data.
602: And sending the call request to test equipment so that the test equipment analyzes the call request, if the preset test case contains a context address, analyzing to obtain the context address, and constructing function call information according to a first context corresponding to the context address and the test parameter.
603: Receiving an execution result fed back by the test equipment; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function call information.
In practical applications, the call request is generated based on the preset test case and the test data, and when the call request is parsed, some of the call request can be parsed to the context address, and some of the call request cannot be parsed to the context address, because whether the context address is set as a parameter when the test case is set. For ease of understanding, the following specifically illustrates that, for example, when defining the test case a, the context address B is preset to be used as a parameter of the test case a, and then after a call request is generated based on the test case and the test data, the context address may be resolved based on the call request. It is easy to understand that, if the context address B is not used as a parameter in the test case a, the context address cannot be obtained after the call request is resolved, and the first context cannot be obtained.
For ease of understanding, the structure and operation of the test background are illustrated below. The test background comprises: the test case library comprises a plurality of usable test cases, test data and a plurality of data required by the test; the case execution module is used for determining the test cases in the test case library and target data in the test data according to the test configuration data; and sending out the calling request according to the determined test case and the target data.
In one or more embodiments of the present application, after receiving the execution result fed back by the test device, as described in step 603, the method further includes: acquiring a preset result; comparing the preset result with the execution result; when the preset result is consistent with the execution result, the test result is a passing test; and when the preset result is inconsistent with the execution result, the test result is a test failure.
After the test is performed and the execution result is output, it is determined whether the test for the target interface function is successful based on the execution result. Specifically, the preset result may be preset in the test background. After receiving the execution result fed back by the test equipment, comparing the preset result with the execution result, and if the preset result is consistent with the execution result, indicating that the test result passes the test. Otherwise, if the preset result is inconsistent with the execution result, the test fails. In practical application, the test result can be sent to the display device by the test background again, and then the user can directly see the test result of the target interface function through the display device.
In one or more embodiments of the present application, the specific implementation of step 601 includes, may include: and carrying out format conversion and encapsulation on the test cases and/or the test data in the character string format, and generating a call request containing test parameters so as to adapt the call request to the test equipment.
In practical application, when testing the target interface function, the test equipment where the target interface function is located can provide various interface types, and the data types required by interface call are also various. The test requirements of many different types of interfaces can be met by the adaptation layer. Specifically, the data format in the call request sent to the adaptation layer by the test background is a character string, and the adaptation layer filters and formats the character string so as to package the character string; it should be noted that, when packaging, it is determined according to the requirements of the test equipment or the objective interface function.
Based on the above embodiments, it can be known that when the target interface function is tested, there may be a relatively complex call relationship and dependency relationship due to the target interface function. In the test process, a call request carrying test parameters is obtained; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; and calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result. Through the embodiment, even if complex dependency relationships and call relationships are involved in the test process of the target interface function, the test user can be helped by using the context to better complete the test work of the target interface function, and the test requirement of the interface multiple call relationships can be met.
Based on the same thought, the embodiment of the application provides an interface test system. Fig. 7a is a schematic structural diagram of an interface testing system according to an embodiment of the present application. As can be seen from fig. 7a, the system comprises: a test background 7a1 and a test device 7a2;
the test device 7a1 is configured to obtain a call request carrying a test parameter; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; calling a target interface function to execute a test based on the function calling information, and generating and feeding back an execution result;
The test background 7a2 is configured to generate a call request including a test parameter based on a preset test case and test data; sending the call request to test equipment so that the test equipment analyzes the call request, if the preset test case contains a context address, analyzing to obtain the context address, and constructing function call information according to a first context corresponding to the context address and the test parameter; receiving an execution result fed back by the test equipment
For ease of understanding, the specific configuration of the interface test system is specifically illustrated below. Referring to fig. 7b, fig. 7b is a schematic structural diagram illustrating an interface test system according to an embodiment of the present application. As can be seen from fig. 7b, the test execution framework TEF (Test Execution Framework), the interface call agent IIPC (Interface Invoke Proxy Client), the test cases, and the test data are included in the test background 7a 1. The test equipment 7a2 includes an interface call proxy service IIPS (Interface Invoke Proxy Service), a tested component CUT (Component Under Test), a test proxy TD (Test Double), a type definition, and an interface CAPI definition. Specifically, CUT: component Under Test, the component under test, contains the CAPI's target file. TD: test Double, test avatar, provides CUT dependent external CAPI. IIPS: INTERFACE INVOKE PROXY SERVICE, the interface invokes a proxy service responsible for invoking CAPI of the CUT. IIPC, interface call agent client, function as adaptation layer, responsible for interfacing TEF and IIPS. TEF: test Execution Framework, a test execution framework supporting keyword driving. CAPI definition: the definition of the target interface function to be tested comprises a target file, a name, a return value type, the number of test parameters and a test parameter type to which the CAPI belongs. Type definition: CAPI to be tested uses a definition of the data type. Test cases: TEF script to implement test logic. Test data: the test data used by the test case can be written in the TEF script or read in from the outside.
For ease of understanding, the operation of the test execution framework TEF is illustrated below. Fig. 8 is a schematic workflow diagram of a test execution framework according to an embodiment of the present application. From fig. 8, it can be seen that the steps are as follows:
and loading the test parameters, generating a test parameter table, loading the test cases and generating a test case table by the test data. Further, determining test cases in the test case library and target data in the test data according to the test configuration data through the case execution module; and sending a call request according to the determined test case and the target function. In addition, after the execution result of the test cases is output, if all the test cases are executed, a test case report is output. In the process of executing the test case specifically, the interface is required to call proxy service, the interface calls proxy clients and the like to complete in a matched manner.
The specific role of the interface in invoking proxy services is illustrated below. Fig. 9 is a schematic diagram illustrating an operation procedure of an interface call proxy service according to an embodiment of the present application. As can be seen from fig. 9, the analysis result obtained after the call request is analyzed may obtain the target test parameter and/or the context address. If the context address is not obtained after the analysis, the test parameters corresponding to the objective function are directly constructed based on the objective test parameters. If the preset test case contains the context address, the context address is obtained by analysis, and the interface call proxy service is required to extract the corresponding context from the local storage according to the context address. It should be noted that, in the interface call proxy service, a type definition and an interface definition are also predefined, where all custom data types used by the target interface function are defined in the type definition, and one implementation manner of the type definition may be, for example, XML format; the interface definition defines the library, name, return value type, number of test parameters and test parameter type to which the target interface function belongs, and one implementation of the interface definition may be in XML format, for example. Before parsing the call request, the type definition and the interface definition are also required to be parsed respectively, and a type definition table and an interface definition table are output. Further, a test parameter construction is performed based on the extracted context, type definition table, and interface definition table.
In the using process, an interface call proxy service obtains the running address of the target interface function based on the test parameters; and sending function call information to the tested component or the test proxy according to the running address and the test parameter. In the test process, the interface call proxy service dynamically loads the tested component or the test proxy to acquire a callable interface function provided in the tested component or the test proxy, wherein the interface function can be a target interface function or an interface function corresponding to a dependent interface. And executing the corresponding target interface function related test step based on the running address and the test parameter corresponding to the target interface function.
Based on the same thought, the embodiment of the application also provides an interface testing device. Fig. 10 is a schematic structural diagram of an interface testing device according to an embodiment of the present application. As can be seen from fig. 10, the device comprises:
an obtaining module 101, configured to obtain a call request carrying a test parameter;
The obtaining module 101 is further configured to obtain, if the context address is obtained by parsing the call request, a corresponding first context based on the context address;
A generating module 102, configured to generate function call information based on the test parameter and the first context configuration;
the generating module 102 is further configured to invoke a target interface function to perform a test based on the function call information, and generate and feed back an execution result.
Optionally, the generating module 102 is further configured to store the second context locally if the execution result includes the second context.
Optionally, the generating module 102 is further configured to obtain an operation address of the target interface function based on the test parameter; and according to the running address and the test parameter, sending function call information to the target interface function to execute the test.
Optionally, the generating module 102 is further configured to determine, based on the function call information, a dependent interface of a test proxy having a dependency relationship with the target interface function if the target interface function depends on an external relationship to perform a test;
and executing the call flow of the dependent interface based on the interface type of the dependent interface so as to test the target interface function.
Optionally, the generating module 102 is further configured to determine at least one interface type corresponding to the dependent interface according to a data flow direction relationship between the target interface function and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface;
and calling the dependent interface according to the calling flow of the at least one interface type.
Optionally, the generating module 102 is further configured to select at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; and calling the dependent interface according to the at least one implementation form.
Based on the same thought, the embodiment of the application also provides another interface testing device. The execution subject of the execution device of the interface test may be an execution device. Fig. 11 is a schematic structural diagram of an interface testing device according to an embodiment of the present application. As can be seen from fig. 11, the device comprises:
the generating module 111 is configured to generate a call request including the test parameters based on the preset test case and the test data.
And the sending module 112 is configured to send the call request to a test device, so that the test device analyzes the call request, if the preset test case includes a context address, the call request is analyzed to obtain the context address, and function call information is constructed according to a first context corresponding to the context address and the test parameter.
A receiving module 113, configured to receive an execution result fed back by the test device; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function call information.
The receiving module 113 is further configured to obtain a preset result; comparing the preset result with the execution result; when the preset result is consistent with the execution result, the test result is a passing test; and when the preset result is inconsistent with the execution result, the test result is a test failure.
The generating module 111 is further configured to format-convert and package the test case and/or the test data in a character string format, and generate a call request including a test parameter, so that the call request is adapted to the test device.
Based on the above embodiments, it can be known that when the target interface function is tested, there may be a relatively complex call relationship and dependency relationship due to the target interface function. In the test process, a call request carrying test parameters is obtained; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; and calling a target interface function to execute the test based on the function calling information, and generating and feeding back an execution result. Through the embodiment, even if complex dependency relationships and call relationships are involved in the test process of the target interface function, the test user can be helped by using the context to better complete the test work of the target interface function, and the test requirement of the interface multiple call relationships can be met.
It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, etc., such as Read Only Memory (ROM) or flash memory (flashRAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transitorymedia), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.
Claims (9)
1. An interface testing method, suitable for use in a test apparatus, the method comprising:
Acquiring a calling request carrying test parameters;
if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address;
generating function call information based on the test parameters and the first context construct;
Calling a target interface function to execute a test based on the function calling information, and generating and feeding back an execution result; in the process of executing the test, the target interface function executes the test depending on the external relation, and at least one interface type corresponding to the dependent interface is determined according to the data flow direction relation between the target interface function and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface; calling the dependent interface according to the call flow of the at least one interface type;
The method for calling the target interface function to execute the test based on the function calling information specifically comprises the following steps: acquiring an operation address of the target interface function based on the test parameters; according to the operation address and the test parameters, function call information is sent to the target interface function; in the test process, dynamically loading a tested component or a test proxy through an interface proxy service to obtain an interface function which can be called and is provided by the tested component or the test proxy, wherein the interface function is a target interface function or an interface function corresponding to a dependent interface, and further, executing a corresponding target interface function related test step based on an operation address and test parameters corresponding to the called interface function;
Wherein the tested component comprises target interface functions to be tested and various other related functions for assisting in completing the test of the target interface functions; the tested component is used for receiving the function call information and determining a dependent interface with a dependent relation with the test avatar; calling the dependent interface according to the function calling information;
Wherein, invoking the dependent interface specifically includes: selecting at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; and calling the dependent interface according to the at least one implementation form.
2. The method of claim 1, wherein generating and feeding back the execution result comprises:
And if the execution result contains a second context, storing the second context locally.
3. The method of claim 1, wherein said sending function call information to a target interface function to perform a test according to said run address and said test parameters comprises:
If the target interface function depends on the external relation to execute the test, determining a dependent interface of a test proxy with a dependent relation with the target interface function based on the function call information;
and executing the call flow of the dependent interface based on the interface type of the dependent interface so as to test the target interface function.
4. An interface testing method, suitable for use in a test background, the method comprising:
generating a calling request containing test parameters based on a preset test case and test data;
Sending the call request to test equipment so that the test equipment analyzes the call request, if the preset test case contains a context address, analyzing to obtain the context address, and constructing function call information according to a first context corresponding to the context address and the test parameter;
Receiving an execution result fed back by the test equipment; the execution result is generated after the test equipment calls a target interface function to execute a test through the function call information; in the process of executing the test, the target interface function executes the test depending on the external relation, and at least one interface type corresponding to the dependent interface is determined according to the data flow direction relation between the target interface function and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface; calling the dependent interface according to the call flow of the at least one interface type;
The method for calling the target interface function to execute the test based on the function calling information specifically comprises the following steps: acquiring an operation address of the target interface function based on the test parameters; according to the operation address and the test parameters, function call information is sent to the target interface function; in the test process, dynamically loading a tested component or a test proxy through an interface proxy service to obtain an interface function which can be called and is provided by the tested component or the test proxy, wherein the interface function is a target interface function or an interface function corresponding to a dependent interface, and further, executing a corresponding target interface function related test step based on an operation address and test parameters corresponding to the called interface function;
Wherein the tested component comprises target interface functions to be tested and various other related functions for assisting in completing the test of the target interface functions; the tested component is used for receiving the function call information and determining a dependent interface with a dependent relation with the test avatar; calling the dependent interface according to the function calling information;
Wherein, invoking the dependent interface specifically includes: selecting at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; and calling the dependent interface according to the at least one implementation form.
5. The method of claim 4, further comprising, after receiving the execution result fed back by the test device:
Acquiring a preset result;
Comparing the preset result with the execution result;
When the preset result is consistent with the execution result, the test result is a passing test;
And when the preset result is inconsistent with the execution result, the test result is a test failure.
6. The method of claim 4, wherein generating a call request including test parameters based on the preset test cases and the test data comprises:
And carrying out format conversion and encapsulation on the test cases and/or the test data in the character string format, and generating a call request containing test parameters so as to adapt the call request to the test equipment.
7. An interface testing apparatus, the apparatus comprising:
the acquisition module is used for acquiring a call request carrying the test parameters;
the acquisition module is further configured to acquire a corresponding first context based on the context address if the context address is obtained by resolving the call request;
the generating module is used for generating function call information based on the test parameters and the first context structure;
the generating module is also used for calling a target interface function to execute a test based on the function calling information, and generating and feeding back an execution result; in the process of executing the test, the target interface function executes the test depending on the external relation, and at least one interface type corresponding to the dependent interface is determined according to the data flow direction relation between the target interface function and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface; calling the dependent interface according to the call flow of the at least one interface type;
The method for calling the target interface function to execute the test based on the function calling information specifically comprises the following steps: acquiring an operation address of the target interface function based on the test parameters; according to the operation address and the test parameters, function call information is sent to the target interface function; in the test process, dynamically loading a tested component or a test proxy through an interface proxy service to obtain an interface function which can be called and is provided by the tested component or the test proxy, wherein the interface function is a target interface function or an interface function corresponding to a dependent interface, and further, executing a corresponding target interface function related test step based on an operation address and test parameters corresponding to the called interface function;
Wherein the tested component comprises target interface functions to be tested and various other related functions for assisting in completing the test of the target interface functions; the tested component is used for receiving the function call information and determining a dependent interface with a dependent relation with the test avatar; calling the dependent interface according to the function calling information;
Wherein, invoking the dependent interface specifically includes: selecting at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; and calling the dependent interface according to the at least one implementation form.
8. An interface testing apparatus, the apparatus comprising:
the generating module is used for generating a calling request containing test parameters based on a preset test case and test data;
The sending module is used for sending the calling request to the testing equipment so that the testing equipment analyzes the calling request, if the preset test case contains a context address, the context address is obtained through analysis, and function calling information is constructed according to a first context corresponding to the context address and the test parameter;
The receiving module is used for receiving the execution result fed back by the test equipment; the execution result is generated after the test equipment calls a target interface function to execute a test through the function call information; in the process of executing the test, the target interface function executes the test depending on the external relation, and at least one interface type corresponding to the dependent interface is determined according to the data flow direction relation between the target interface function and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface; calling the dependent interface according to the call flow of the at least one interface type;
The method for calling the target interface function to execute the test based on the function calling information specifically comprises the following steps: acquiring an operation address of the target interface function based on the test parameters; according to the operation address and the test parameters, function call information is sent to the target interface function; in the test process, dynamically loading a tested component or a test proxy through an interface proxy service to obtain an interface function which can be called and is provided by the tested component or the test proxy, wherein the interface function is a target interface function or an interface function corresponding to a dependent interface, and further, executing a corresponding target interface function related test step based on an operation address and test parameters corresponding to the called interface function;
Wherein the tested component comprises target interface functions to be tested and various other related functions for assisting in completing the test of the target interface functions; the tested component is used for receiving the function call information and determining a dependent interface with a dependent relation with the test avatar; calling the dependent interface according to the function calling information;
Wherein, invoking the dependent interface specifically includes: selecting at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; and calling the dependent interface according to the at least one implementation form.
9. An interface testing system, the system comprising: test background and test equipment;
the test equipment is used for acquiring a call request carrying test parameters; if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address; generating function call information based on the test parameters and the first context construct; calling a target interface function to execute a test based on the function calling information, and generating and feeding back an execution result; in the process of executing the test, the target interface function executes the test depending on the external relation, and at least one interface type corresponding to the dependent interface is determined according to the data flow direction relation between the target interface function and the dependent interface; wherein the interface types include: setting a type interface, an acquisition type interface and a registration type interface; calling the dependent interface according to the call flow of the at least one interface type;
The method for calling the target interface function to execute the test based on the function calling information specifically comprises the following steps: acquiring an operation address of the target interface function based on the test parameters; according to the operation address and the test parameters, function call information is sent to the target interface function; in the test process, dynamically loading a tested component or a test proxy through an interface proxy service to obtain an interface function which can be called and is provided by the tested component or the test proxy, wherein the interface function is a target interface function or an interface function corresponding to a dependent interface, and further, executing a corresponding target interface function related test step based on an operation address and test parameters corresponding to the called interface function;
Wherein the tested component comprises target interface functions to be tested and various other related functions for assisting in completing the test of the target interface functions; the tested component is used for receiving the function call information and determining a dependent interface with a dependent relation with the test avatar; calling the dependent interface according to the function calling information;
Wherein, invoking the dependent interface specifically includes: selecting at least one implementation form corresponding to the dependent interface based on the call flow of the dependent interface; wherein, the implementation form includes: original implementation, overlay implementation and parcel implementation; invoking the dependent interface according to the at least one implementation form
The test background is used for generating a call request containing test parameters based on a preset test case and test data; sending the call request to test equipment so that the test equipment analyzes the call request, if the preset test case contains a context address, analyzing to obtain the context address, and constructing function call information according to a first context corresponding to the context address and the test parameter; and receiving an execution result fed back by the test equipment.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011378396.5A CN112540915B (en) | 2020-11-30 | 2020-11-30 | Interface testing method, device and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011378396.5A CN112540915B (en) | 2020-11-30 | 2020-11-30 | Interface testing method, device and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112540915A CN112540915A (en) | 2021-03-23 |
| CN112540915B true CN112540915B (en) | 2024-07-19 |
Family
ID=75016561
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011378396.5A Active CN112540915B (en) | 2020-11-30 | 2020-11-30 | Interface testing method, device and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112540915B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113254112B (en) * | 2021-04-29 | 2024-07-26 | 杭州天谷信息科技有限公司 | Method and system for associating request with interface |
| CN117931610B (en) * | 2022-10-13 | 2025-11-04 | 腾讯科技（深圳）有限公司 | Application testing methods, apparatus, electronic devices and storage media |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107329861A (en) * | 2017-06-12 | 2017-11-07 | 北京奇安信科技有限公司 | A kind of multiplex roles method of testing and device |
| CN108021496A (en) * | 2016-10-28 | 2018-05-11 | 腾讯科技（深圳）有限公司 | Thread-data processing method and processing device |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9740543B1 (en) * | 2016-10-27 | 2017-08-22 | Red Hat, Inc. | Multi-endpoint method implementation |
| CN110489325A (en) * | 2019-07-09 | 2019-11-22 | 微民保险代理有限公司 | Vehicle insurance data test method, apparatus, test platform and vehicle insurance test macro |
| CN111045921A (en) * | 2019-10-12 | 2020-04-21 | 平安普惠企业管理有限公司 | Automated interface testing method, device, computer equipment and storage medium |
-
2020
- 2020-11-30 CN CN202011378396.5A patent/CN112540915B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108021496A (en) * | 2016-10-28 | 2018-05-11 | 腾讯科技（深圳）有限公司 | Thread-data processing method and processing device |
| CN107329861A (en) * | 2017-06-12 | 2017-11-07 | 北京奇安信科技有限公司 | A kind of multiplex roles method of testing and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112540915A (en) | 2021-03-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111399853B (en) | Templated deployment method for machine learning model and custom operator | |
| US7305659B2 (en) | Handling parameters in test scripts for computer program applications | |
| US7552422B2 (en) | Test case inheritance controlled via attributes | |
| CN111158741B (en) | Method and device for monitoring dependency relationship change of service module on third party class library | |
| CN112540915B (en) | Interface testing method, device and system | |
| CN111026080A (en) | Hardware-in-loop test method and device for controller | |
| US7340725B1 (en) | Smart test attributes and test case scenario in object oriented programming environment | |
| CN108038039A (en) | The method and micro services system of record log | |
| CN110502428A (en) | Code test method, device, computer equipment and storage medium | |
| CN111176653B (en) | Program compiling and packaging method and device, electronic equipment and storage medium | |
| CN103197947A (en) | Script processing method and device | |
| CN111240987B (en) | Method and device for detecting migration program, electronic equipment and computer readable storage medium | |
| CN110147313B (en) | Log output method and device | |
| CN114791884A (en) | Test environment construction method and device, storage medium and electronic equipment | |
| US7010454B1 (en) | Test services provider | |
| CN118227212A (en) | Method and device for determining model running environment, storage medium and electronic equipment | |
| CN117389660A (en) | Method and system for detecting jar packet homonymy | |
| CN117171037A (en) | Patch testing method and device based on heterogeneous cloud platform | |
| CN112015658B (en) | A method and device for generating software integration test cases | |
| CN111367796B (en) | Application program debugging method and device | |
| CN116340159A (en) | Regression test case recommendation method, system, equipment and storage medium | |
| CN117520139A (en) | Interface testing method, system, electronic equipment and storage medium | |
| US7082376B1 (en) | State full test method executor | |
| US20240403201A1 (en) | Software test system and software test method | |
| CN117493162B (en) | Data verification method, system, equipment and storage medium for interface test |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |