Interface test method and device, electronic equipment and storage medium
By automatically generating test class files, the problem of Thrift server-side interface testing relying on client-side tools is solved, enabling more efficient interface testing and allowing testers to freely modify test cases.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- TENCENT TECHNOLOGY (SHENZHEN) CO LTD
- Filing Date
- 2020-06-05
- Publication Date
- 2026-06-12
Smart Images
Figure CN113760687B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to an interface testing method, apparatus, electronic device, and storage medium. Background Technology
[0002] Thrift is an interface description language and binary communication protocol used to define and create cross-language services. Thrift is used as an RPC (Remote Procedure Call Protocol) framework. The Thrift server provides interfaces for clients to call to implement corresponding functions. How to test the Thrift server interface is a crucial issue.
[0003] In related technologies, testers use client tools provided by developers to make simple calls to the Thrift server interface to ensure its correctness.
[0004] When testing Thrift server interfaces, the above techniques require developers to provide client tools, resulting in significant limitations and low testing efficiency in interface testing. Summary of the Invention
[0005] This application provides an interface testing method, apparatus, electronic device, and storage medium, which can reduce the limitations of interface testing and improve testing efficiency. The technical solution is as follows:
[0006] On the one hand, an interface testing method is provided, the method comprising:
[0007] Obtain the interface description language file corresponding to the server-side interface to be tested;
[0008] Based on the interface description language file, a client file is generated using a target protocol tool. The client file is used to indicate the interaction logic between the client and the server interface.
[0009] Read the data contained in the interface description language file and generate a dictionary. The dictionary uses a target data structure to store the data contained in the interface description language file.
[0010] Based on the client file and the dictionary, a test class file is generated, which is used to test the calling function of the server interface.
[0011] On the one hand, an interface testing device is provided, the device comprising:
[0012] The acquisition module is used to acquire the interface description language file corresponding to the server interface to be tested.
[0013] A generation module is used to generate a client file based on the interface description language file using a target protocol tool. The client file is used to indicate the interaction logic between the client and the server interface.
[0014] The generation module is also used to read the data contained in the interface description language file and generate a dictionary. The dictionary uses a key-value pair data structure to store the data contained in the interface description language file.
[0015] The generation module is also used to generate a test class file based on the client file and the dictionary, and the test class file is used to test the calling function of the server interface.
[0016] In one possible implementation, the interface description language file contains the interface service class name, function name and corresponding parameter name, and the target data structure is a key-value pair data structure.
[0017] The generation module is used for:
[0018] Read the interface description language file to obtain the interface service class name, function name and corresponding parameter name in the interface description language file;
[0019] A dictionary is generated by using the interface service class name in the interface description language file as the key and the function name and corresponding parameter name as the value of the key-value pair.
[0020] In one possible implementation, the generation module is used to:
[0021] The character between the service type and the first symbol is used as the interface service class name;
[0022] Obtain the string within the second symbol corresponding to the service type, and using the third symbol as a delimiter, extract the characters before the fourth symbol from each line of the string as the function name;
[0023] Extract the characters within the fifth symbol from the line containing the function name, and use the sixth symbol as a separator to extract each parameter name from the characters within the fifth symbol as the parameter name corresponding to the function name.
[0024] In one possible implementation, the generation module is used to:
[0025] Iterate through the interface service class names that are keys in the dictionary, and query the client file based on the iterated interface service class names;
[0026] In response to the existence of the interface service class name in the client file, the parameter name as the value of the key-value pair in the dictionary is obtained;
[0027] Based on the parameters indicated by the obtained parameter names, the corresponding functions are generated, resulting in the test class file.
[0028] In one possible implementation, the device further includes:
[0029] The modification module is used to modify the test class file in response to the modification command of the test class file.
[0030] In one possible implementation, the interface description language file includes comment information;
[0031] The device further includes:
[0032] The deletion module is used to traverse the lines in the interface description language file and delete the comment information contained in the interface description language file.
[0033] In one possible implementation, the deletion module is used to traverse the lines in the interface description language file and delete lines containing the seventh symbol and lines containing the eighth symbol whose first character is a tab.
[0034] On one hand, an electronic device is provided, the electronic device including one or more processors and one or more memories, the one or more memories storing at least one piece of program code, the program code being loaded and executed by the one or more processors to implement the above-described interface testing method.
[0035] On the one hand, a computer-readable storage medium is provided, wherein at least one piece of program code is stored in the computer-readable storage medium, the at least one piece of program code being loaded and executed by a processor to implement the above-described interface testing method.
[0036] The beneficial effects of the technical solutions provided in this application include at least the following:
[0037] By using the interface description language file corresponding to the server interface to be tested, the target protocol tool automatically generates the client file. Since the client file is used to indicate the interaction logic between the client and the server interface, it can be combined with a dictionary that stores the data in the interface description language file using the target data structure to automatically generate test class files for testing the calling function of the server interface. The whole process does not rely on the developer to provide the client tool, allowing testers to modify the test class files according to their own needs to test the calling function of the server interface, reducing the limitations of interface testing and improving testing efficiency. Attached Figure Description
[0038] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0039] Figure 1 This is a schematic diagram of the implementation environment of an interface testing method provided in an embodiment of this application;
[0040] Figure 2 This is a flowchart of an interface testing method provided in an embodiment of this application;
[0041] Figure 3 This is a flowchart of an interface testing method provided in an embodiment of this application;
[0042] Figure 4 This is a schematic diagram of an interface description language file provided in an embodiment of this application;
[0043] Figure 5 This is a schematic diagram of the structure of an interface testing device provided in an embodiment of this application;
[0044] Figure 6 This is a schematic diagram of the structure of a server provided in an embodiment of this application;
[0045] Figure 7 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. Detailed Implementation
[0046] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0047] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.
[0048] To facilitate understanding of the technical solutions in the embodiments of this application, some terms involved in the embodiments of this application will be explained below:
[0049] Interface Description Language (IDL) is a computer language used to describe the interfaces of software components. IDL describes interfaces in a neutral way, enabling objects running on different platforms and programs written in different languages to communicate with each other. For example, one component might be written in C++, and another in Java. IDL is commonly used for remote software invocation.
[0050] Thrift is an interface description language and binary communication protocol used to define and create cross-language services. It is used as an RPC framework. Through a code generation engine, it integrates a software stack to create seamless, cross-platform, high-performance services at varying levels, supporting languages such as C++, C#, Python, and Java.
[0051] Figure 1 This is a schematic diagram of the implementation environment of an interface testing method provided in an embodiment of this application. See also... Figure 1 The implementation environment may include electronic device 101 and server 102.
[0052] Electronic device 101 can be a server, or a terminal device such as a smartphone, tablet, laptop, desktop computer, smart speaker, or smartwatch, but is not limited to these. Electronic device 101 runs a test class file, which is used to test the calling function of the server interface.
[0053] Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Server 102 runs a server-side program, which can refer to a program that provides interface services.
[0054] Electronic device 101 and server 102 can be connected directly or indirectly via wired or wireless communication, and this application does not impose any restrictions on this.
[0055] Electronic device 101 can refer to one of a plurality of electronic devices. This embodiment uses electronic device 101 as an example for illustration only.
[0056] Those skilled in the art will understand that the number of the aforementioned electronic devices can be more or less. For example, there may be only one electronic device, or there may be dozens or hundreds, or even more, in which case other electronic devices may also be included in the aforementioned implementation environment. This application does not limit the number or type of electronic devices.
[0057] Figure 2 This is a flowchart illustrating an interface testing method provided in an embodiment of this application. The method is executed by an electronic device; see [link to relevant documentation]. Figure 2 The method may include:
[0058] 201. Obtain the interface description language file corresponding to the server interface to be tested.
[0059] The interface description language file can be an IDL file.
[0060] 202. Based on the interface description language file, use the target protocol tool to generate a client file, which is used to indicate the interaction logic between the client and the server interface.
[0061] The target protocol tool can be a Thrift tool, that is, a tool that comes with the Thrift protocol itself.
[0062] 203. Read the data contained in the interface description language file and generate a dictionary. The dictionary uses the target data structure to store the data contained in the interface description language file.
[0063] 204. Based on the client file and the dictionary, generate a test class file, which is used to test the calling function of the server interface.
[0064] The method provided in this application automatically generates a client file using a target protocol tool based on the interface description language file corresponding to the server interface to be tested. Since the client file is used to indicate the interaction logic between the client and the server interface, a dictionary storing the data in the interface description language file using a target data structure can be used to automatically generate a test class file for testing the calling function of the server interface. The entire process does not rely on the developer to provide client tools, allowing testers to modify the test class file according to their own needs to test the calling function of the server interface, reducing the limitations of interface testing and improving testing efficiency.
[0065] The above Figure 2 The flowchart shown is the basic flowchart of the embodiment of this application. The detailed flowchart of the embodiment of this application will be described below based on this basic flowchart.
[0066] Figure 3This is a flowchart illustrating an interface testing method provided in an embodiment of this application. The method is executed by an electronic device; see [link to relevant documentation]. Figure 3 The method may include:
[0067] 301. Electronic devices obtain the interface description language file corresponding to the server interface to be tested.
[0068] In this context, the server-side interface refers to the interface provided by the Thrift server, which can be called by clients. The interface description language file can also be called a Thrift file, such as health.thrift. In one possible implementation, this interface description language file contains the interface service class name, function name, and corresponding parameter names, as well as comment information.
[0069] See Figure 4 , Figure 4 This is a schematic diagram of an interface description language file provided in an embodiment of this application, such as... Figure 4 As shown, the interface description language file includes the service interface health parameter name, which includes comment information 401, interface service class name 402, function name (method name) 403 and corresponding parameter name 404.
[0070] This interface description language file can be written by developers for the server-side interface to be tested. After obtaining the interface description language file, testers can store it in a target folder, such as the srcThrift folder. Correspondingly, electronic devices can retrieve the interface description language file from this target folder.
[0071] 302. The electronic device generates a client file based on the interface description language file using the target protocol tool. The client file is used to indicate the interaction logic between the client and the server interface.
[0072] The target protocol tool can be a Thrift tool, which is a tool that comes with the Thrift protocol and has the function of generating client files based on interface description language files.
[0073] When using this target protocol tool, electronic devices can determine the interaction logic between the client and server interfaces based on the data in the interface description language file, and generate client files based on this interaction logic.
[0074] 303. Electronic devices should remove the comment information contained in the interface description language file.
[0075] Electronic devices can traverse the lines in the interface description language file, delete the comment information contained in the interface description language file, and generate an interface description language file without comment information.
[0076] In one possible implementation, the electronic device traverses the lines in the interface description language file and deletes the comment information contained in the file. This includes traversing the lines in the interface description language file and deleting lines containing the seventh symbol and lines containing the eighth symbol whose first character is a tab. By deleting lines in the interface description language file that match the characteristics of the comment information, the efficiency of comment information deletion can be improved.
[0077] The seventh symbol can be an asterisk (*). The eighth symbol can be a double forward slash " / / ".
[0078] Electronic devices can iterate through each line of the interface description language file, ignoring lines containing... The line containing " / / " is checked, and it is determined whether the first character of the line containing " / / " is a tab character. If it is a tab character, it is ignored. After excluding the above two cases, an interface description language file without comment information is generated.
[0079] It should be noted that step 303 is an optional step. Since the comment information contained in the interface description language file may be the same as the interface service class name or function name, deleting the comment information can avoid the comment information interfering with the process of recognizing the content of the interface description language file.
[0080] 304. The electronic device reads the data contained in the interface description language file and generates a dictionary. The dictionary uses the target data structure to store the data contained in the interface description language file.
[0081] Electronic devices can read interface description language files, identify the interface service class names, function names, and corresponding parameter names (which can be one or more) contained within, and generate a dictionary (map). This dictionary can be represented as follows:
[0082] {Interface service class name: {function name 1: no parameters or empty / one or more parameters}, function name 2: no parameters or empty / one or more parameters}
[0083] In one possible implementation, the target data structure is a key-value pair data structure. The electronic device reads the data contained in the interface description language file and generates a dictionary, including: reading the interface description language file to obtain the interface service class name, function name, and corresponding parameter name in the interface description language file; using the interface service class name in the interface description language file as the key of the key-value pair, and the function name and corresponding parameter name as the value of the key-value pair, to generate a dictionary.
[0084] When an electronic device reads an interface description language file, it can identify the interface service class names, function names, and corresponding parameter names contained within. It then stores this data using a key-value pair data structure, forming a dictionary. Storing data from the interface description language file using a key-value pair data structure facilitates quick and easy retrieval of the required data.
[0085] In one possible implementation, the electronic device reads the interface description language file to obtain the interface service class name, function name, and corresponding parameter names from the file. This includes: extracting the characters between the service type and the first symbol as the interface service class name; extracting the string within the second symbol corresponding to the service type, using the third symbol as a delimiter, and extracting the characters before the fourth symbol from each line of this string as the function name; extracting the characters within the fifth symbol from the line containing the function name, using the sixth symbol as a delimiter, and extracting each parameter name from the characters within the fifth symbol as the parameter names corresponding to the function name. By leveraging the characteristics of the interface service class name, function name, and corresponding parameter names in the interface description language file, the interface service class name, function name, and corresponding parameter names can be obtained quickly and accurately.
[0086] The service type is "service". The first character can be a left curly brace "{", the second symbol can be a curly brace "{}", the third symbol can be a right parenthesis ")", the fourth symbol can be a greater than sign ">", the fifth symbol can be a parenthesis "()", and the sixth symbol can be a comma ",".
[0087] The electronic device can extract the characters between "service" and "{" as the interface service class name; it can also extract the string within "{}" in "service", using ")" as a separator, and then check each line for the presence of ">". If it does, the character before the ">" is taken as the function name; otherwise, the line is ignored. When extracting the function name, the electronic device can also distinguish whether there is a return value. Within the function line, after extracting the characters within "()", the electronic device uses "," as a comma to extract the parameter names. Finally, based on the extracted interface service class name, function name, and parameter names, the electronic device can generate a dictionary with key-value pairs.
[0088] It should be noted that the embodiments of this application only use the step of generating the client file as step 302 and the step of generating the dictionary as step 304 as examples for illustration, and do not limit the order of steps 302 and 304.
[0089] 305. The electronic device generates a test class file based on the client file and the dictionary. This test class file is used to test the calling function of the server interface.
[0090] The electronic device can reference the client file generated in step 303, traverse the dictionary generated in step 304, and generate a test class file. In one possible implementation, step 305 may include: traversing the interface service class names used as keys in the dictionary, querying the client file based on the traversed interface service class names; in response to the existence of the traversed interface service class name in the client file, obtaining the parameter names used as values in the dictionary; generating the corresponding function based on the parameters indicated by the obtained parameter names, thus obtaining the test class file. Since the dictionary uses the target data structure to store the data contained in the interface description language file, traversing the dictionary can quickly obtain the interface service class names, and then quickly obtain the corresponding parameter names to generate functions, improving the generation efficiency of the test class file.
[0091] The electronic device can iterate through the keys in the dictionary, which are the interface service class names. It searches for the interface service class name in the client file based on the key. If the name is found, it retrieves the value corresponding to the key in the dictionary. This value is the parameter name of the function name corresponding to the interface service class name. Then, based on the parameter name, it generates the corresponding function and obtains the test class file.
[0092] By referencing the client file generated based on the interface description language file, and traversing the dictionary, test class files are automatically generated, which can then be freely modified by testers.
[0093] Steps 301 to 305 are the process of automatically generating test class files based on the interface description language file. The test class file can be a python genThrift.py file, which can also be called a Thrift client or a Thrift client class tool.
[0094] After generating the test class file, the electronic device can store the test class file in the test directory. For example, the electronic device can generate a test class file named testmaster_state.py in the test directory.
[0095] 306. Electronic device display test files.
[0096] After generating the test class file, the electronic device can display it to testers. This test class file includes references to client files and the logic for calling server-side interfaces. The logic for calling the client-side interfaces constitutes the test cases. After reviewing the test class file, testers can determine whether to modify the test cases based on their needs.
[0097] The electronic device can display the test class file directly after it is generated, or it can display the test class file in response to a display instruction received from the device.
[0098] 307. The electronic device responds to the modification instruction of the test class file and modifies the test class file.
[0099] If testers want to modify the test class files, such as refining the test cases, they can trigger a modification command on their electronic device. This command can carry modification information, and the electronic device will modify the test class files accordingly. The modified test class files can then test not only the basic functionality of the server-side interface but also its exception handling, concurrent operation, and thread safety.
[0100] It should be noted that steps 306 and 307 are optional. By providing the ability to modify test class files, testers can freely modify the test class files according to their own needs, thus improving the flexibility of interface testing.
[0101] In some possible embodiments, after generating the test class file, the electronic device can directly execute the subsequent step 308, or, after executing step 306, if no modification instruction is received, it can directly execute the subsequent step 308.
[0102] 308. Electronic devices run this test class file.
[0103] Electronic devices can run this test class file, view the parameters and usage methods in the test class file, and execute the test cases in the test class file according to the usage methods to test the calling function of the server interface.
[0104] Electronic devices can use Python tools, such as testMasterStateService.py, to execute test cases in test class files, including calling server interfaces, receiving response information returned by server interfaces, and determining test results based on response information.
[0105] If the tester does not modify the test class file and the electronic device does not execute step 307, then in step 308 the electronic device can run the test class file generated in step 305. If the tester modifies the test class file, that is, the electronic device executes step 307, then in step 308 the electronic device can run the modified test class file in step 307.
[0106] The technical solutions provided in this application do not require or rely on developers, can eliminate client-side code development issues, and testers can refine the test cases in the generated test class files according to actual needs.
[0107] The method provided in this application automatically generates a client file using a target protocol tool based on the interface description language file corresponding to the server interface to be tested. Since the client file is used to indicate the interaction logic between the client and the server interface, a dictionary storing the data in the interface description language file using a target data structure can be used to automatically generate a test class file for testing the calling function of the server interface. The entire process does not rely on the developer to provide client tools, allowing testers to modify the test class file according to their own needs to test the calling function of the server interface, reducing the limitations of interface testing and improving testing efficiency.
[0108] Figure 5 This is a schematic diagram of the structure of an interface testing device provided in an embodiment of this application. (Refer to...) Figure 5 The device includes:
[0109] Module 501 is used to obtain the interface description language file corresponding to the server interface to be tested.
[0110] The generation module 502 is used to generate a client file based on the interface description language file using the target protocol tool. The client file is used to indicate the interaction logic between the client and the server interface.
[0111] The generation module 502 is also used to read the data contained in the interface description language file and generate a dictionary, which uses a target data structure to store the data contained in the interface description language file.
[0112] The generation module 502 is also used to generate a test class file based on the client file and the dictionary. The test class file is used to test the calling function of the server interface.
[0113] In one possible implementation, the interface description language file contains the interface service class name, function name, and corresponding parameter name, and the target data structure is a key-value pair data structure.
[0114] The generation module 502 is used for:
[0115] Read the interface description language file to obtain the interface service class name, function name and corresponding parameter name in the interface description language file;
[0116] Generate a dictionary by using the interface service class name in the interface description language file as the key and the function name and corresponding parameter name as the value of the key-value pair.
[0117] In one possible implementation, the generation module 502 is used for:
[0118] The character between the service type and the first symbol is used as the name of the interface service class.
[0119] Get the string within the second symbol corresponding to the service type, and using the third symbol as a delimiter, extract the characters before the fourth symbol from each line of the string as the function name;
[0120] Extract the characters within the fifth symbol from the line containing the function name. Using the sixth symbol as a separator, extract each parameter name from the characters within the fifth symbol as the parameter names corresponding to the function name.
[0121] In one possible implementation, the generation module 502 is used for:
[0122] Iterate through the dictionary for the names of the interface service classes that are keys in the key-value pairs, and then perform a query in the client file based on the name of the interface service class that is found.
[0123] In response to the existence of the interface service class name in the client file, retrieve the parameter name as the value of the key-value pair in the dictionary;
[0124] Based on the parameters indicated by the obtained parameter names, the corresponding functions are generated, resulting in the test class file.
[0125] In one possible implementation, the device further includes:
[0126] The modification module is used to modify the test class file in response to modification commands.
[0127] In one possible implementation, the interface description language file includes annotation information;
[0128] The device also includes:
[0129] The delete module is used to traverse the lines in the interface description language file and delete the comment information contained in the interface description language file.
[0130] In one possible implementation, the deletion module is used to traverse the lines in the interface description language file and delete lines containing the seventh symbol and lines containing the eighth symbol whose first character is a tab.
[0131] In this embodiment, a client file is automatically generated using a target protocol tool based on the interface description language file corresponding to the server interface to be tested. Since the client file is used to indicate the interaction logic between the client and the server interface, a dictionary storing the data in the interface description language file using a target data structure can be used to automatically generate a test class file for testing the calling function of the server interface. The entire process does not rely on the developer to provide client tools, allowing testers to modify the test class file according to their own needs to test the calling function of the server interface, reducing the limitations of interface testing and improving testing efficiency.
[0132] It should be noted that the interface testing device provided in the above embodiments is only illustrated by the division of the above functional modules during interface testing. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the interface testing device and the interface testing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.
[0133] The electronic device in the above embodiments can be a server.
[0134] Figure 6 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 600 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 601 and one or more memories 602. The memories 602 store at least one line of program code, which is loaded and executed by the processors 601 to implement the methods provided in the various method embodiments described above. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated upon here.
[0135] The electronic device in the above embodiments can be a terminal.
[0136] Figure 7This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. The terminal 700 can be: a smartphone, tablet computer, MP3 player (Moving Picture Experts Group Audio Layer III), MP4 player (Moving Picture Experts Group Audio Layer IV), laptop computer, or desktop computer. The terminal 700 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.
[0137] Typically, terminal 700 includes one or more processors 701 and one or more memories 702.
[0138] Processor 701 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 701 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 701 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 701 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 701 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.
[0139] The memory 702 may include one or more computer-readable storage media, which may be non-transitory. The memory 702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 702 is used to store at least one instruction, which is executed by the processor 701 to implement the interface testing method provided in the method embodiments of this application.
[0140] In some embodiments, the terminal 700 may also optionally include a peripheral device interface 703 and at least one peripheral device. The processor 701, memory 702, and peripheral device interface 703 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 703 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 704, a display screen 705, a camera assembly 706, an audio circuit 707, and a power supply 709.
[0141] Peripheral device interface 703 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 701 and memory 702. In some embodiments, processor 701, memory 702 and peripheral device interface 703 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 701, memory 702 and peripheral device interface 703 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.
[0142] The radio frequency (RF) circuit 704 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 704 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 704 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 704 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 704 can communicate with other terminals through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 704 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.
[0143] Display screen 705 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 705 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 701 for processing. In this case, display screen 705 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 705, serving as the front panel of terminal 700; in other embodiments, there may be at least two display screens 705, respectively disposed on different surfaces of terminal 700 or in a folded design; in still other embodiments, display screen 705 may be a flexible display screen, disposed on a curved or folded surface of terminal 700. Furthermore, display screen 705 may be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. Display screen 705 may be made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).
[0144] The camera assembly 706 is used to acquire images or videos. Optionally, the camera assembly 706 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 706 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.
[0145] The audio circuit 707 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting the sound waves into electrical signals that are input to the processor 701 for processing, or input to the radio frequency circuit 704 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each located at a different part of the terminal 700. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert the electrical signals from the processor 701 or the radio frequency circuit 704 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 707 may also include a headphone jack.
[0146] The power supply 709 is used to power the various components in the terminal 700. The power supply 709 can be AC power, DC power, a disposable battery, or a rechargeable battery. When the power supply 709 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.
[0147] In some embodiments, the terminal 700 further includes one or more sensors 710. The one or more sensors 710 include, but are not limited to: an acceleration sensor 711, a gyroscope sensor 712, a pressure sensor 713, an optical sensor 715, and a proximity sensor 716.
[0148] Accelerometer 711 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by terminal 700. For example, accelerometer 711 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 701 can control display screen 705 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 711. Accelerometer 711 can also be used for games or for acquiring user motion data.
[0149] The gyroscope sensor 712 can detect the orientation and rotation angle of the terminal 700. The gyroscope sensor 712, in conjunction with the accelerometer sensor 711, can collect the user's 3D movements on the terminal 700. Based on the data collected by the gyroscope sensor 712, the processor 701 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.
[0150] The pressure sensor 713 can be disposed on the side bezel of the terminal 700 and / or the lower layer of the display screen 705. When the pressure sensor 713 is disposed on the side bezel of the terminal 700, it can detect the user's grip signal on the terminal 700, and the processor 701 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 713. When the pressure sensor 713 is disposed on the lower layer of the display screen 705, the processor 701 can control the operable controls on the UI interface based on the user's pressure operation on the display screen 705. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.
[0151] An optical sensor 715 is used to collect ambient light intensity. In one embodiment, the processor 701 can control the display brightness of the display screen 705 based on the ambient light intensity collected by the optical sensor 715. Specifically, when the ambient light intensity is high, the display brightness of the display screen 705 is increased; when the ambient light intensity is low, the display brightness of the display screen 705 is decreased. In another embodiment, the processor 701 can also dynamically adjust the shooting parameters of the camera assembly 706 based on the ambient light intensity collected by the optical sensor 715.
[0152] The proximity sensor 716, also known as a distance sensor, is typically located on the front panel of the terminal 700. The proximity sensor 716 is used to detect the distance between the user and the front of the terminal 700. In one embodiment, when the proximity sensor 716 detects that the distance between the user and the front of the terminal 700 is gradually decreasing, the processor 701 controls the display screen 705 to switch from a screen-on state to a screen-off state; when the proximity sensor 716 detects that the distance between the user and the front of the terminal 700 is gradually increasing, the processor 701 controls the display screen 705 to switch from a screen-off state to a screen-on state.
[0153] Those skilled in the art will understand that Figure 7 The structure shown does not constitute a limitation on terminal 700, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.
[0154] In an exemplary embodiment, a computer-readable storage medium storing at least one line of program code is also provided, such as a memory storing at least one line of program code, which is loaded and executed by a processor to implement the interface testing method in the above embodiments. For example, the computer-readable storage medium may be read-only memory (ROM), random access memory (RAM), compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.
[0155] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by hardware related to program instructions. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.
[0156] The above are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. An interface testing method, characterized in that, The method includes: Obtain the interface description language file corresponding to the server-side interface to be tested; Based on the interface description language file, a client file is generated using a target protocol tool. The client file is used to indicate the interaction logic between the client and the server interface. The target protocol tool is a tool that comes with the Thrift protocol. Read the data contained in the interface description language file and generate a dictionary. The dictionary uses a target data structure to store the data contained in the interface description language file. The target data structure is a key-value pair data structure. Iterate through the interface service class names that are keys in the dictionary, and query the client file based on the iterated interface service class names; In response to the existence of the interface service class name in the client file, the parameter name as the value of the key-value pair in the dictionary is obtained; Based on the parameters indicated by the obtained parameter names, a corresponding function is generated to obtain a test class file. The test class file is used to test the calling function of the server interface. The test class file is run to execute the test cases in the test class file. The method further includes: In response to the modification instruction of the test class file, the test class file is modified to refine the test cases in the generated test class file; the modified test class file is then run.
2. The method according to claim 1, characterized in that, The interface description language file also contains function names; The step of reading the data contained in the interface description language file and generating a dictionary includes: Read the interface description language file to obtain the interface service class name, function name and corresponding parameter name in the interface description language file; A dictionary is generated by using the interface service class name in the interface description language file as the key and the function name and corresponding parameter name as the value of the key-value pair.
3. The method according to claim 2, characterized in that, The step of reading the interface description language file to obtain the interface service class name, function name, and corresponding parameter name in the interface description language file includes: The character between the service type and the first symbol is used as the interface service class name; Obtain the string within the second symbol corresponding to the service type, and using the third symbol as a delimiter, extract the characters before the fourth symbol from each line of the string as the function name; Extract the characters within the fifth symbol from the line containing the function name, and use the sixth symbol as a separator to extract each parameter name from the characters within the fifth symbol as the parameter name corresponding to the function name.
4. The method according to claim 1, characterized in that, The interface description language file contains comment information; Before reading the data contained in the interface description language file and generating the dictionary, the method further includes: Iterate through the lines in the interface description language file and delete the comment information contained in the interface description language file.
5. The method according to claim 4, characterized in that, The step of traversing the lines in the interface description language file and deleting the comment information contained in the interface description language file includes: Iterate through the lines in the interface description language file and delete lines containing the seventh symbol and lines containing the eighth symbol whose first character is a tab.
6. An interface testing device, characterized in that, The device includes: The acquisition module is used to acquire the interface description language file corresponding to the server interface to be tested. The generation module is used to generate a client file based on the interface description language file using a target protocol tool. The client file is used to indicate the interaction logic between the client and the server interface. The target protocol tool is a tool that comes with the Thrift protocol. The generation module is further configured to read the data contained in the interface description language file and generate a dictionary, wherein the dictionary uses a target data structure to store the data contained in the interface description language file; the target data structure is a key-value pair data structure. The generation module is further configured to traverse the interface service class names that are keys in the dictionary, and query the client file based on the traversed interface service class names; in response to the existence of the traversed interface service class names in the client file, obtain the parameter names that are values in the dictionary; generate corresponding functions based on the parameters indicated by the obtained parameter names, and obtain a test class file, which is used to test the calling function of the server interface; The module is used to perform the following steps: run the test class file and execute the test cases in the test class file; The device further includes: The modification module is used to modify the test class file in response to the modification command of the test class file, and refine the test cases in the generated test class file. The module used to perform the following steps: run the modified test class file.
7. The apparatus according to claim 6, characterized in that, The interface description language file also contains function names; The generation module is used for: Read the interface description language file to obtain the interface service class name, function name and corresponding parameter name in the interface description language file; A dictionary is generated by using the interface service class name in the interface description language file as the key and the function name and corresponding parameter name as the value of the key-value pair.
8. The apparatus according to claim 7, characterized in that, The generation module is used for: The character between the service type and the first symbol is used as the interface service class name; Obtain the string within the second symbol corresponding to the service type, and using the third symbol as a delimiter, extract the characters before the fourth symbol from each line of the string as the function name; Extract the characters within the fifth symbol from the line containing the function name, and use the sixth symbol as a separator to extract each parameter name from the characters within the fifth symbol as the parameter name corresponding to the function name.
9. The apparatus according to claim 6, characterized in that, The interface description language file contains comment information; The device further includes: The deletion module is used to traverse the lines in the interface description language file and delete the comment information contained in the interface description language file.
10. The apparatus according to claim 9, characterized in that, The deletion module is used for: Iterate through the lines in the interface description language file and delete lines containing the seventh symbol and lines containing the eighth symbol whose first character is a tab.
11. An electronic device, characterized in that, The electronic device includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, the program code being loaded and executed by the one or more processors to implement the interface testing method as described in any one of claims 1 to 5.
12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the interface testing method as described in any one of claims 1 to 5.