CN112540915A - Interface test method, device and system - Google Patents
Interface test method, device and system Download PDFInfo
- Publication number
- CN112540915A CN112540915A CN202011378396.5A CN202011378396A CN112540915A CN 112540915 A CN112540915 A CN 112540915A CN 202011378396 A CN202011378396 A CN 202011378396A CN 112540915 A CN112540915 A CN 112540915A
- Authority
- CN
- China
- Prior art keywords
- test
- interface
- context
- function
- 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.)
- Granted
Links
- 238000010998 test method Methods 0.000 title description 3
- 238000012360 testing method Methods 0.000 claims abstract description 457
- 238000000034 method Methods 0.000 claims abstract description 67
- 230000008569 process Effects 0.000 claims abstract description 36
- 238000010276 construction Methods 0.000 claims abstract description 13
- 230000001419 dependent effect Effects 0.000 claims description 43
- 238000004458 analytical method Methods 0.000 claims description 4
- 238000004806 packaging method and process Methods 0.000 claims description 4
- 238000006243 chemical reaction Methods 0.000 claims description 3
- 230000006870 function Effects 0.000 description 141
- 238000010586 diagram Methods 0.000 description 28
- 238000012545 processing Methods 0.000 description 20
- 238000004590 computer program Methods 0.000 description 7
- 230000006978 adaptation Effects 0.000 description 6
- 230000004044 response Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3692—Test management for test results analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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
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 present 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 construction; and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result. By the technical scheme, even if a complicated dependency relationship and a complex calling relationship are involved in the testing process of the target interface function, the testing user can be helped to better complete the testing work of the target interface function by utilizing the context, and the testing requirement of the interface multiple calling relationship can be met.
Description
Technical Field
The application relates to the technical field of network equipment testing, 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 a plurality of functional cohesive components, and interaction is performed between the components through a C programming language Application Program Interface (CAPI), for example. When a system is newly built or upgraded, relevant components in the system need to be tested.
In the prior art, due to the complex calling relationship among the components, when a calling interface is tested, tests of various conditions such as various exception handling, compatibility, boundary handling and the like need to be fully considered. However, when a tester faces a complex calling relationship to perform testing, problems of test missing and inaccurate test results due to incomplete consideration may occur; or the testing efficiency of the tester is low because the calling relationship and the dependency relationship between the interfaces are relatively complex.
Disclosure of Invention
The application provides an interface testing method, device and system in multiple aspects, and is used for simplifying testing tasks of interfaces with complex calling relations and improving testing efficiency.
In a first aspect, an embodiment of the present application provides an interface testing method, where the method includes:
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 construction;
and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result.
In a second aspect, an embodiment of the present application provides another interface testing method, 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 a test device so that the test device can analyze 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 parameters;
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 calling information.
In a third aspect, an embodiment of the present application provides an interface testing apparatus, where the apparatus includes:
the obtaining module is used for obtaining a calling request carrying the test parameters;
the obtaining module is further configured to obtain a corresponding first context based on the context address if the context address is obtained by analyzing the call request;
a generating module for generating function call information based on the test parameters and the first context construction;
the generating module is further configured to call a target interface function based on the function call information to perform a test, and generate and feed back an execution result.
In a fourth aspect, an embodiment of the present application provides another interface testing apparatus, where the method includes:
the generation 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 can analyze 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 testing parameters;
the receiving module is used for receiving the execution result fed back by the testing equipment; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function calling information.
In a fifth aspect, an embodiment of the present application provides an interface test system, where the system includes: testing background and testing 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 construction; 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 a test device so that the test device can analyze 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 parameters; and receiving the execution result fed back by the test equipment.
In some embodiments of the present application, when the target interface function is tested, there may be a relatively complex calling relationship and a relatively complex dependency relationship due to the target interface function. In the test process, obtaining 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 construction; and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result. By the embodiment, even if complex dependency and call relations are involved in the test process of the target interface function, the test user can be helped to better complete the test work of the target interface function by using the context, and the test requirement of the interface multiple call relation 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 application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic flowchart of a method for testing an interface according to an embodiment of the present disclosure;
fig. 2 is a schematic diagram of an interface test performed based on a setup interface according to an embodiment of the present disclosure;
fig. 3 is a schematic diagram of an interface test performed based on an acquisition-type interface according to an embodiment of the present application;
fig. 4 is a schematic diagram of an interface test performed based on a registration type interface according to an embodiment of the present application;
fig. 5 is a schematic structural diagram illustrating a form selection implemented by depending on an interface according to an embodiment of the present application;
fig. 6 is a schematic flowchart of another interface testing method according to an embodiment of the present application;
fig. 7a is a schematic structural diagram of an interface test system according to an embodiment of the present application;
FIG. 7b is a schematic diagram illustrating a structure of 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 disclosure;
fig. 9 is a schematic diagram illustrating an interface invoking proxy service working process according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of an interface testing apparatus according to an embodiment of the present application;
fig. 11 is a schematic structural diagram of an interface testing apparatus according to an embodiment of the present application.
Detailed Description
In order to further clarify the objects, technical solutions and advantages of the present application, the following detailed description of the present application with reference to specific embodiments thereof and accompanying drawings is provided for clarity and completeness of description. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present 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 the examples of the present invention and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, and "a plurality" typically includes at least two, but does not exclude the inclusion of at least one, unless the context clearly dictates otherwise.
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 phrases "if determined" or "if detected (a stated condition or event)" may be interpreted as "when determined" or "in response to a determination" or "when detected (a stated condition or event)" or "in response to a detection (a stated condition or event)", depending on the context.
It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a good 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 good or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a commodity or system that includes the element.
The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.
In practical application, a network operating system mostly adopts a componentized development mode, and when testing is performed, testing needs to be performed on each component and an interface (for example, a C language programming interface, abbreviated as CAPI) included in the component. During normal operation of the component, interfaces in the component have calling relationships with many interfaces or components. When the test is carried out, only typical test can be carried out, and the boundary processing, exception handling, compatibility and external dependency relationship are difficult to fully cover. Therefore, the inventor of the application provides a technical scheme capable of meeting the testing requirements of the complex context and dependency relationship of the component interface.
Fig. 1 is a schematic flowchart of a method for testing an interface according to an embodiment of the present disclosure. The execution subject of the method may be a test device. As can be seen from fig. 1, the method comprises the following steps:
101: and acquiring a call request carrying the test parameters.
102: and if the calling request is analyzed to obtain a context address, acquiring a corresponding first context based on the context address.
103: generating function call information based on the test parameters and the first context construction.
104: and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result.
When the interface test is carried out, the test equipment acquires a call request which is sent by a test background and aims at a tested interface, namely a target interface function. The call request includes test parameters, and in some cases, the call request may also include a context address.
In practical application, in the process of testing the target interface function, multiple calls may be required to output a final result, and in the multiple call process, an execution result of a previous step may be used as a relevant parameter of a next step, that is, a first context and a second context referred to in this application. Therefore, when the target interface function is called, whether the context needs to be acquired can be known by analyzing 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., in order to perform subsequent test work based on the function call information.
If the call request is parsed without a context address, then it is indicated that no context is available. 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 the execution result includes a second context, the second context is stored locally.
If the execution result obtained in the process of testing the target interface function contains the second context, the second context can be stored locally so as to be continuously used in the current or subsequent testing process, so that the testing requirement of the target interface function with a complex context calling relationship can be met. In addition, the saved context may also be applied to testing of other interface functions. And if the execution result after the test is executed does not contain other contexts, the context is not saved.
In one or more embodiments of the present application, the invoking a target interface function based on the function call information to perform a test includes: acquiring the running address of the target interface function based on the test parameters; and sending function calling information to the target interface function to execute the test according to the running address and the test parameter.
And acquiring the running address of the target interface function based on the test parameters. And further, sending function calling information to the target interface function according to the running address and the test parameters. In the testing process, the tested component or the test substitute can be dynamically loaded through the interface proxy service, and a callable interface function provided by the tested component or the test substitute is obtained, wherein the interface function can be a target interface function or an interface function corresponding to a dependent interface. And further executing the corresponding target interface function related test steps based on the running address and the test parameters corresponding to the called interface function.
The interface proxy service implementation may use abstract, easy-to-use scripting programming. For example,
test_case_string_concat
${result}Invoke_CAPI"string_concat""Hello""World"
should _ Be _ Equal "HelloWorld" $ { result } in the script example above:
test _ case _ string _ concat is the test case name;
invoke _ CAPI is a keyword and is used for calling an interface CAPI;
"string _ concat" is the measured CAPI name, the CAPI function is the concatenation string;
hello is the first test parameter of the tested CAPI;
"World" is the second test parameter of the tested CAPI;
$ result is the execution result of the measured CAPI;
hello World is the expected result;
the Should _ Be _ Equal is a key word and is used for checking whether the result is consistent with the expectation or not, if so, the use case is marked as successful, and if not, the use case is marked as failed.
It should be noted that, during the process of interacting with the test background, the test device needs to be assisted by an adaptation layer (for example, the interface call proxy client IIPC), so that the test device can interface different types of target interface functions. One implementation of the adaptation layer is illustrated below:
wherein, the Python module is used for realizing an Invoke _ CAPI method:
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 can follow the name to accommodate any type of CAPI.
3) The name and all test parameters are spliced into a request, separated by a space.
4) The IIPC and the IIPS interact through a redis database (other interaction modes can be used).
5) The IIPC issues a call request to the IIPS via the CAPI _ REQUST channel.
6) The IIPC subscribes from the IIPS through the CAPI _ RESULT channel to invoke the response.
7) And returning an execution result.
In one or more embodiments of the present application, the sending function call information to a target interface function according to the operation address and the test parameter to perform a test includes: if the target interface function depends on the external relation to execute the test, determining a dependent interface of the test substitute having the dependent relation with the target interface function based on the function calling information; and executing the calling process of the dependent interface to test the target interface function based on the interface type of the dependent interface.
The test flows for different target interface functions may not be completely the same, and in some cases, the test background may send the function call information to the target interface function first, and in some cases, the test background may send the function call information to the test avatar. In the following embodiments, the following description will be separately illustrated for different situations, and will not be repeated here.
In practical application, the tested component includes each target interface function to be tested and various other related functions for assisting in completing the test of the target interface function. The tested component is used for receiving the function calling information and determining a dependency interface which has a dependency relationship with the test avatar; and calling the dependent interface according to the function calling information.
In practical applications, some target 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 depending on the interface. Specifically, after receiving the function call request, a dependency interface for providing a dependency relationship for the test procedure in the test avatar 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: the method comprises the following steps of setting an interface, obtaining an interface and registering an interface; and calling the dependent interface according to the calling process of the at least one interface type.
For ease of understanding, the following describes an example of a process for testing a dependent interface based on three interface types.
Fig. 2 is a schematic diagram of performing an interface test based on a setup-type 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 a test parameter (e.g., Invoke _ CAPI key) to the component under test, and calls a target interface function under test (CAPI) provided by the component under test CUT. And after the tested component receives the call request, the CAPI processing is normally executed according to the preset execution logic of the tested component. And after the processing is finished, continuously calling a setting type interface provided by the test substitute TD, and providing test parameters for the setting type interface. The test avatar stores the test parameters and informs the test background that the receiving and storing of the test parameters are completed. Furthermore, the test execution framework TEF sends Invoke _ CAPI keywords to the test surrogate, calls a control interface of the test surrogate to acquire test parameters provided by the test surrogate, 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 the expected data. If the test result is consistent with the test result, the target interface function is successfully tested, otherwise, if the test result is inconsistent with the test result, the test result is failed, and related workers need to be informed to troubleshoot and process errors.
Fig. 3 is a schematic diagram of performing an interface test based on an acquisition-type interface according to an embodiment of the present application. As shown in fig. 3, the test background sends test parameters to the test avatar, injects specified data into the acquisition interface of the test avatar, and notifies the test background that the test parameters have been received and stored. And then, the test background sends Invoke _ CAPI keywords to the tested component, calls a tested target interface function provided by the tested component CUT, calls an acquisition type interface of the test substitute through the tested component, and then the test substitute feeds back the stored test parameters to the tested component through the acquisition type interface. And the tested component processes the test parameters according to the preset processing logic after receiving the test parameters, feeds the execution result back to the test background, compares the received execution result with an expected result by the test background and judges whether the execution result is consistent. If the test result is consistent with the target interface function test result, the target interface function test result is successful, and if the test result is inconsistent with the target interface function test result, the target interface function test result is failed.
Fig. 4 is a schematic diagram of performing 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 Invoke _ CAPI keywords to the tested component, and calls the tested CAPI provided by the tested component CUT. After the tested component receives the call request, the processing of CAPI is normally executed according to the preset execution logic of the tested component. After the processing is completed, the registered interface provided by the test avatar TD is called, and the test parameters are provided to the registered interface. And the test avatar TD stores the event processing function of the tested component corresponding to the test parameter and informs the test background that the test parameter is received and stored. And then, the test background sends an Invoke _ CAPI keyword to the test surrogate, calls a control interface trigger event provided by the test surrogate, and the test surrogate calls back an event processing function of the tested component. And after receiving the event processing function, the tested component processes the event according to the preset processing logic. And after the processing of the tested component is finished, the tested component sends finished notification information to the test background. And 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 expectation and judges whether the processing result is consistent with the expectation. If the test result is consistent with the test result, the target interface function is successfully tested, otherwise, if the test result is inconsistent with the test result, the test result is failed, and related workers need to be informed to troubleshoot and process errors.
In practical applications, the test avatar is also used for: selecting at least one implementation form corresponding to the dependent interface based on the calling process of the dependent interface; wherein, the realization form comprises: original implementation, overlay implementation, and wrapping implementation; and calling the dependent interface according to the at least one implementation form.
While the original implementation referred to herein may be understood as an internal invocation of the actual dependent component implementation, the wrapped implementation may be understood as a wrapping of the original implementation, allowing some additional related processing to occur before and after the original implementation is invoked.
For ease of understanding, the dependent interface call procedure for the three implementations is illustrated below.
Fig. 5 is a schematic structural diagram of implementing form selection depending on an 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 for the dependent interface, which selection can be selectively controlled as desired. When the tested component calls the dependent interface, calling is carried out according to the selection result of the selection interface, and calling can comprise original implementation, coverage implementation and package implementation. If the original implementation is selected, the original implementation can be loaded and invoked directly through a test avatar. For overlay implementations and package implementations, the selection of the dependent interface may then be controlled directly or indirectly by the invoking device. It should be noted that, in the technical solution of the present application, the three implementation forms can be switched to each other according to the requirements of the test case during operation.
Based on the same idea, the embodiment of the application also provides another interface testing method. The method can be used for testing the background. Fig. 6 is a schematic 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 a test device so that the test device can analyze 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 parameters.
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 calling information.
In practical applications, the call request is generated based on a preset test case and test data, and when the call request is analyzed, some call requests can be analyzed to a context address, and some call requests cannot be analyzed to the context address, because whether the context address is set as a parameter or not is determined when the test case is set. For convenience of understanding, the following specific example 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 generated based on the test case and the test data is generated, the context address can be obtained by analyzing 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 analyzed, 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 the target data in the test data according to the test configuration data; and sending the call 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 testing 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 pass test; and when the preset result is inconsistent with the execution result, the test result is 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. And 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 is a pass test. Otherwise, if the preset result is inconsistent with the execution result, the test fails. In practical application, the test result can be tested again and sent to the display device at the background, 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 procedure of step 601 includes, may include: and carrying out format conversion and packaging on the test case 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 a target interface function, the interface types provided by the testing equipment where the target interface function is located are various, and the data types required by interface calling 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, and then encapsulates the character string; it should be noted that, when packaging is performed, it needs to be determined according to the requirements of the test equipment or the target interface function.
Based on the above embodiments, when the target interface function is tested, there may be a relatively complex calling relationship and a relatively complex dependency relationship in the target interface function. In the test process, obtaining 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 construction; and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result. By the embodiment, even if complex dependency and call relations are involved in the test process of the target interface function, the test user can be helped to better complete the test work of the target interface function by using the context, and the test requirement of the interface multiple call relation can be met.
Based on the same idea, the embodiment of the application provides an interface test system. Fig. 7a is a schematic structural diagram of an interface test system according to an embodiment of the present application. As can be seen from fig. 7a, the system comprises: test background 7a1 and test equipment 7a 2;
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 construction; 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 test parameters based on a preset test case and test data; sending the call request to a test device so that the test device can analyze 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 parameters; receiving the execution result fed back by the test equipment
For the sake of understanding, the following specifically exemplifies a specific configuration of the interface test system. Specifically, reference may be made to fig. 7b, and fig. 7b is a schematic structural diagram illustrating an interface test system provided in an embodiment of the present application. As can be seen from fig. 7b, the test background 7a1 includes a test Execution framework tef (test Execution framework), an interface call Proxy client iipc (interface Invoke Proxy client), and a test case and test data. The side of the testing device 7a2 includes an interface call Proxy service iips (interface Invoke Proxy service), a component to be tested cut (component Under test), and a test substitute td (test double), a type definition, and an interface CAPI definition. Specifically, the CUT: component Under Test, the tested Component, contains CAPI target file. TD: test Double, Test avatar, provides CUT dependent external CAPI. IIPS: and the Interface Invoke Proxy Service is responsible for invoking CAPI of the CUT. And the IIPC, the interface calls the proxy client, plays a role of an adaptation layer and is responsible for butting the TEF and the IIPS. TEF: test Execution Framework, supporting keyword driven Test Execution Framework. CAPI defines: and 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 of the CAPI. Type definition: the CAPI to be tested uses the definition of the data type. Test case: a TEF script that implements test logic. Test data: the test data used by the test case may be written to the TEF script or read from the outside.
For ease of understanding, the working process 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 following steps are included:
and loading the test parameters and generating a test parameter table, and loading the test cases and the test data and generating a test case table. 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 calling request according to the determined test case and the target function. In addition, after the execution of the test cases is output, if all the test cases are executed, the test case report is output. In the process of executing the test case, the interface calls proxy service, the interface calls proxy clients and the like.
The specific role of the interface invoking proxy service is illustrated below. Fig. 9 is a schematic diagram illustrating an interface invoking proxy service working process according to an embodiment of the present application. As can be seen from fig. 9, the parsing result obtained by parsing the call request may obtain the target test parameter and/or the context address. And if the context address can not be obtained after the analysis, constructing the test parameter corresponding to the target function directly based on the target test parameter. And if the preset test case contains the context address, analyzing to obtain the context address, and requiring the interface to call the proxy service to extract the corresponding context from the local storage according to the context address. It should be noted that, a type definition and an interface definition are also predefined in the interface call proxy service, where the type definition defines all custom data types used by the target interface function, and an implementation manner of the type definition may be, for example, an XML format; the interface definition defines a library, a name, a return value type, the number of test parameters, and a test parameter type to which the target interface function belongs, and one implementation manner of the interface definition may be, for example, an XML format. Before parsing the call request, the type definition and the interface definition are also needed to be parsed respectively, and the type definition table and the interface definition table are output. And then, constructing test parameters based on the extracted context, the type definition table and the interface definition table.
In the using process, the interface calling proxy service acquires the running address of the target interface function based on the test parameter; and sending function calling information to the tested component or the test substitute according to the running address and the test parameters. In the testing process, the interface calling proxy service dynamically loads the tested component or the test substitute to acquire a callable interface function provided in the tested component or the test substitute, wherein the interface function can be a target interface function or an interface function corresponding to a dependent interface. And further executing the corresponding target interface function related test steps based on the running address and the test parameters corresponding to the target interface function.
Based on the same idea, the embodiment of the application further provides an interface testing device. Fig. 10 is a schematic structural diagram of an interface testing apparatus according to an embodiment of the present application. From fig. 10 it can be seen that 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, if the context address is obtained by analyzing the call request, obtain 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 construction;
the generating module 102 is further configured to invoke a target interface function to execute 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 to the local 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 sending function calling information to the target interface function to execute the test according to the running address and the test parameter.
Optionally, the generating module 102 is further configured to determine, based on the function call information, a dependent interface of a test substitute having a dependent relationship with the target interface function if the target interface function depends on an external relationship to perform a test;
and executing the calling process of the dependent interface to test the target interface function based on the interface type of the dependent interface.
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: the method comprises the following steps of setting an interface, obtaining an interface and registering an interface;
and calling the dependent interface according to the calling process 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 realization form comprises: original implementation, overlay implementation, and wrapping implementation; and calling the dependent interface according to the at least one implementation form.
Based on the same idea, the embodiment of the application also provides another interface testing device. The execution subject of the execution device of the interface test may be the execution device. Fig. 11 is a schematic structural diagram of an interface testing apparatus 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 a test parameter based on a preset test case and test data.
A sending module 112, configured to send the call request to a test device, so that the test device analyzes the call request, and if the preset test case includes a context address, the context address is obtained through analysis, 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 testing device; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function calling 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 pass test; and when the preset result is inconsistent with the execution result, the test result is test failure.
The generating module 111 is further configured to perform format conversion and packaging on the test case and/or the test data in the 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, when the target interface function is tested, there may be a relatively complex calling relationship and a relatively complex dependency relationship in the target interface function. In the test process, obtaining 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 construction; and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result. By the embodiment, even if complex dependency and call relations are involved in the test process of the target interface function, the test user can be helped to better complete the test work of the target interface function by using the context, and the test requirement of the interface multiple call relation can be met.
As will be appreciated by one skilled in the art, 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 flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
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 computer storage media 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 storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include transitory computer readable media (transmyedia) 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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.
Claims (12)
1. An interface testing method, adapted to test equipment, the method comprising:
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 construction;
and calling a target interface function based on the function calling information to execute the test, and generating and feeding back an execution result.
2. The method of claim 1, wherein the generating and feeding back execution results comprises:
and if the execution result contains a second context, storing the second context to the local.
3. The method of claim 1, wherein said invoking a target interface function based on said function call information to perform a test comprises:
acquiring the running address of the target interface function based on the test parameters;
and sending function calling information to the target interface function to execute the test according to the running address and the test parameter.
4. The method of claim 3, wherein sending function call information to a target interface function to perform a test according to the operation address and the test parameter comprises:
if the target interface function depends on the external relation to execute the test, determining a dependent interface of the test substitute having the dependent relation with the target interface function based on the function calling information;
and executing the calling process of the dependent interface to test the target interface function based on the interface type of the dependent interface.
5. The method of claim 4, wherein executing the dependent interface call flow based on the interface type of the dependent interface comprises:
determining at least one interface type corresponding to the dependent interface according to the data flow direction relation between the target interface function and the dependent interface; wherein the interface types include: the method comprises the following steps of setting an interface, obtaining an interface and registering an interface;
and calling the dependent interface according to the calling process of the at least one interface type.
6. The method of claim 5, wherein said invoking the dependent interface comprises:
selecting at least one implementation form corresponding to the dependent interface based on the calling process of the dependent interface; wherein, the realization form comprises: original implementation, overlay implementation, and wrapping implementation; and calling the dependent interface according to the at least one implementation form.
7. An interface testing method, adapted to 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 a test device so that the test device can analyze 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 parameters;
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 calling information.
8. The method of claim 7, wherein after receiving the execution result fed back by the testing device, further comprising:
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 pass test;
and when the preset result is inconsistent with the execution result, the test result is test failure.
9. The method of claim 7, wherein generating a call request including test parameters based on the predetermined test case and the test data comprises:
and carrying out format conversion and packaging on the test case 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.
10. An interface testing apparatus, the apparatus comprising:
the obtaining module is used for obtaining a calling request carrying the test parameters;
the obtaining module is further configured to obtain a corresponding first context based on the context address if the context address is obtained by analyzing the call request;
a generating module for generating function call information based on the test parameters and the first context construction;
the generating module is further configured to call a target interface function based on the function call information to perform a test, and generate and feed back an execution result.
11. An interface testing apparatus, the apparatus comprising:
the generation 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 can analyze 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 testing parameters;
the receiving module is used for receiving the execution result fed back by the testing equipment; and the execution result is generated after the test equipment calls a target interface function to execute the test through the function calling information.
12. An interface test system, the system comprising: testing background and testing 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 construction; 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 a test device so that the test device can analyze 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 parameters; and receiving the 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 true CN112540915A (en) | 2021-03-23 |
| CN112540915B 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) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113254112A (en) * | 2021-04-29 | 2021-08-13 | 杭州天谷信息科技有限公司 | Method and system for associating request and interface |
| CN113254112B (en) * | 2021-04-29 | 2024-07-26 | 杭州天谷信息科技有限公司 | Method and system for associating request with interface |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9740543B1 (en) * | 2016-10-27 | 2017-08-22 | Red Hat, Inc. | Multi-endpoint method implementation |
| 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 |
| 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 | 平安普惠企业管理有限公司 | Automatic interface testing method and device, computer equipment and storage medium |
-
2020
- 2020-11-30 CN CN202011378396.5A patent/CN112540915B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9740543B1 (en) * | 2016-10-27 | 2017-08-22 | Red Hat, Inc. | Multi-endpoint method implementation |
| 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 |
| 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 | 平安普惠企业管理有限公司 | Automatic interface testing method and device, computer equipment and storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113254112A (en) * | 2021-04-29 | 2021-08-13 | 杭州天谷信息科技有限公司 | Method and system for associating request and interface |
| CN113254112B (en) * | 2021-04-29 | 2024-07-26 | 杭州天谷信息科技有限公司 | Method and system for associating request with interface |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112540915B (en) | 2024-07-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20050251719A1 (en) | Test case inheritance controlled via attributes | |
| CN110704312B (en) | Method, device, computer equipment and storage medium for pressure test | |
| CN110727581B (en) | Crash positioning method and electronic equipment | |
| CN114691464A (en) | Interface testing method, computer equipment and computer readable storage medium | |
| CN107451058B (en) | Software development method and device | |
| US7340725B1 (en) | Smart test attributes and test case scenario in object oriented programming environment | |
| CN105404574B (en) | Smart card and mobile terminal consistency test method and device | |
| CN112579099A (en) | Code deployment method and device, storage medium and electronic equipment | |
| CN112286741A (en) | Hardware testing method and device, electronic equipment and storage medium | |
| CN114416545A (en) | Method and device for determining test code coverage rate and electronic equipment | |
| CN111240987B (en) | Method and device for detecting migration program, electronic equipment and computer readable storage medium | |
| CN112540915B (en) | Interface testing method, device and system | |
| CN116841653A (en) | Execution method and device of operation and maintenance job, processor and electronic equipment | |
| CN115757138A (en) | Method and device for determining script abnormal reason, storage medium and electronic equipment | |
| CN116340159A (en) | Regression test case recommendation method, system, equipment and storage medium | |
| CN114791884A (en) | Test environment construction method and device, storage medium and electronic equipment | |
| CN115357298A (en) | Calling method of third-party interface, processor and storage medium | |
| CN111176653B (en) | Program compiling and packaging method and device, electronic equipment and storage medium | |
| CN111367796B (en) | Application program debugging method and device | |
| CN114281427A (en) | Method and equipment for batch parameter configuration and verification | |
| CN112015658A (en) | Method and device for generating software integration test case | |
| CN110633214A (en) | Configuration method and device of internal test message | |
| US7082376B1 (en) | State full test method executor | |
| CN115858012B (en) | Program variable configuration method, device, electronic equipment and storage medium | |
| CN111324523B (en) | Data processing method and device |
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 |