CN113704079A - Interface testing method and device based on Protobuf - Google Patents
Interface testing method and device based on Protobuf Download PDFInfo
- Publication number
- CN113704079A CN113704079A CN202010439135.3A CN202010439135A CN113704079A CN 113704079 A CN113704079 A CN 113704079A CN 202010439135 A CN202010439135 A CN 202010439135A CN 113704079 A CN113704079 A CN 113704079A
- Authority
- CN
- China
- Prior art keywords
- test
- interface
- data file
- tested
- test result
- 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.)
- Pending
Links
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
Abstract
The embodiment of the disclosure discloses a Protobuf-based interface testing method and device. One embodiment of the method comprises: acquiring a test data file matched with an interface to be tested, wherein the test data file conforms to a data definition in a preset Protobuf file, the test data file comprises at least one test case, and the test case comprises input parameters and expected output; transmitting the input parameters in the test data file into the interface to be tested, and generating a test result set corresponding to the input parameters, wherein the test result is in a binary form; deserializing the generated test result to generate a test result object; obtaining a value corresponding to the test result object; and generating result information representing whether the interface to be tested passes the test or not according to the comparison between the value corresponding to the test result object and the corresponding expected output. The embodiment improves the reusability of the test script and reduces the data transmission amount, thereby saving manpower and network resources.
Description
Technical Field
The embodiment of the disclosure relates to the technical field of computers, in particular to a method and a device for testing an interface based on Protobuf.
Background
With the development of computer technology, the interface automation test is also applied more and more. Existing interface automation test frameworks or tools such as postman, meter, and soap require interface test protocol files involving a large number of complex contents, and the large amount of data transfer also requires a large amount of network bandwidth and I/O resources.
Protobuf is widely applied to many projects by taking the advantages of cross-language, high performance, small message size after coding and the like as a high-performance coding framework of an open source. However, because the data interaction mode is performed in a binary mode, the data interaction mode cannot be connected with the existing interface automatic test framework or tool, and the high-performance automatic test of the interface cannot be realized.
Disclosure of Invention
The embodiment of the disclosure provides a Protobuf-based interface testing method and device.
In a first aspect, an embodiment of the present disclosure provides a Protobuf-based interface testing method, where the method includes: acquiring a test data file matched with an interface to be tested, wherein the test data file conforms to a data definition in a preset Protobuf file, the test data file comprises at least one test case, and the test case comprises input parameters and expected output; transmitting the input parameters in the test data file into an interface to be tested, and generating a test result set corresponding to the input parameters, wherein the test result is in a binary form; deserializing the generated test result to generate a test result object; obtaining a value corresponding to a test result object; and generating result information representing whether the interface to be tested passes the test or not according to the comparison between the value corresponding to the test result object and the corresponding expected output.
In some embodiments, the obtaining a test data file matching with the interface to be tested includes: acquiring an information set of a test data file, wherein the information of the test data file comprises a paging identifier in the test data file; acquiring an identifier of an interface to be tested, wherein the identifier comprises a class name of a script corresponding to the interface to be tested; and acquiring the test data file as a matched test data file according to the paging identifier in the test data file consistent with the class name of the script corresponding to the interface to be tested.
In some embodiments, the test case of the test data file further includes a method name, where the method name is used to characterize a function of an interface to be tested; and the transmitting the input parameter in the test data file to the interface to be tested to generate the test result corresponding to the input parameter, including: reading a test case in the test data file; selecting a test case from the test data file, and executing the following test steps: determining whether the method name of the selected test case meets a preset condition; responding to the determination satisfaction, transmitting the input parameters of the selected test case into an interface to be tested, generating a test result corresponding to the input parameters of the selected test case, and storing the generated test result into a preset test result set; determining whether the test data file has unselected test cases; in response to determining that the test case exists, the test case is re-selected from the test data file and the testing step continues.
In some embodiments, the obtaining a value corresponding to the test result object includes: in response to determining that the test result object is not empty, obtaining attributes of the test result object based on a reflection mechanism; an attribute value corresponding to the acquired attribute is acquired as a value corresponding to the test result object.
In some embodiments, the generating result information indicating whether the interface to be tested passes the test according to the comparison between the value corresponding to the test result object and the corresponding expected output includes: storing the obtained value corresponding to the test result object into a preset key value database; in response to determining that the obtained attribute value is consistent with the corresponding expected output, generating result information representing that the interface to be tested passes the test; in response to determining that the obtained attribute values are inconsistent with the corresponding expected outputs, generating result information characterizing that the interface to be tested fails the test.
In some embodiments, the method further comprises: and generating an interface test report according to the generated result information representing whether the interface to be tested passes the test, wherein the interface test report also comprises the method name, the number, the description information, the input parameter, the expected output, the test result and the information representing whether the interface to be tested is executed.
In a second aspect, an embodiment of the present disclosure provides a Protobuf-based interface testing apparatus, including: the device comprises a first obtaining unit, a second obtaining unit and a third obtaining unit, wherein the first obtaining unit is configured to obtain a test data file matched with an interface to be tested, the test data file conforms to a data definition in a preset Protobuf file, the test data file comprises at least one test case, and the test case comprises input parameters and expected output; the first generation unit is configured to transmit the input parameters in the test data file to an interface to be tested and generate a test result set corresponding to the input parameters, wherein the test result is in a binary form; a second generation unit configured to deserialize the generated test result and generate a test result object; a second acquisition unit configured to acquire a value corresponding to the test result object; and the third generation unit is configured to generate result information representing whether the interface to be tested passes the test or not according to the comparison between the value corresponding to the test result object and the corresponding expected output.
In some embodiments, the first obtaining unit includes: the information acquisition module is configured to acquire an information set of the test data file, wherein the information of the test data file comprises an identifier of a page in the test data file; the identification acquisition module is configured to acquire an identification of the interface to be tested, wherein the identification comprises a class name of a script corresponding to the interface to be tested; and the file acquisition module is configured to acquire the test data file as a matched test data file according to the identification of the paging in the test data file which is consistent with the class name of the script corresponding to the interface to be tested.
In some embodiments, the test case of the test data file further includes a method name, where the method name is used to characterize a function of an interface to be tested; and the first generation unit includes: the reading module is configured to read a test case in the test data file; a selection module configured to select a test case from the test data file; a test module configured to perform the following test steps: determining whether the method name of the selected test case meets a preset condition; responding to the determination satisfaction, transmitting the input parameters of the selected test case into an interface to be tested, generating a test result corresponding to the input parameters of the selected test case, and storing the generated test result into a preset test result set; determining whether the test data file has unselected test cases; in response to determining that the test case exists, the test case is re-selected from the test data file and the testing step continues.
In some embodiments, the second obtaining unit includes: an attribute acquisition module configured to acquire an attribute of the test result object based on the reflection mechanism in response to determining that the test result object is not empty; an attribute value acquisition module configured to acquire an attribute value corresponding to the acquired attribute as a value corresponding to the test result object.
In some embodiments, the third generating unit includes: the storage module is configured to store the acquired value corresponding to the test result object into a preset key value database; a first generation module configured to generate result information characterizing that the interface to be tested passes the test in response to determining that the obtained attribute values are consistent with the corresponding expected outputs; a second generation module configured to generate result information characterizing that the interface to be tested fails the test in response to determining that the obtained attribute values are inconsistent with the corresponding expected outputs.
In some embodiments, the apparatus further comprises: a fourth generation unit configured to: and generating an interface test report according to the generated result information representing whether the interface to be tested passes the test, wherein the interface test report also comprises the method name, the number, the description information, the input parameter, the expected output, the test result and the information representing whether the interface to be tested is executed.
In a third aspect, an embodiment of the present disclosure provides an electronic device, including: one or more processors; a storage device having one or more programs stored thereon; when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method as described in any implementation of the first aspect.
In a fourth aspect, embodiments of the present disclosure provide a computer-readable medium on which a computer program is stored, which when executed by a processor implements the method as described in any of the implementations of the first aspect.
According to the method and the device for testing the Protobuf-based interface, firstly, a test data file matched with the interface to be tested is obtained. And the test data file conforms to the data definition in the preset Protobuf file. The test data file includes at least one test case. The test cases include entries and expected outputs. And then, transmitting the input parameters in the test data file into an interface to be tested, and generating a test result set corresponding to the input parameters. Wherein the test result is in binary form. And then, deserializing the generated test result to generate a test result object. Next, a value corresponding to the test result object is acquired. And finally, generating result information representing whether the interface to be tested passes the test or not according to the comparison between the value corresponding to the test result object and the corresponding expected output. Therefore, the test data, the Protobuf file and the test script are isolated, the test script can be modified only by modifying the Protobuf file or the test data file when the interface Protobuf protocol changes or data is modified, the reusability of the test script is improved, and human resources are saved. Moreover, the data transmission amount is greatly reduced through the Protobuf coding, so that the network resources are saved.
Drawings
Other features, objects and advantages of the disclosure will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 is an exemplary system architecture diagram in which one embodiment of the present disclosure may be applied;
FIG. 2 is a flow diagram of one embodiment of a Protobuf-based interface testing method according to the present disclosure;
fig. 3 is a schematic diagram of an application scenario of a Protobuf-based interface testing method according to an embodiment of the present disclosure;
FIG. 4 is a flow diagram of yet another embodiment of a Protobuf-based interface testing method according to the present disclosure;
FIG. 5 is a schematic block diagram of one embodiment of a Protobuf-based interface testing apparatus according to the present disclosure;
FIG. 6 is a schematic structural diagram of an electronic device suitable for use in implementing embodiments of the present disclosure.
Detailed Description
The present disclosure is described in further detail below with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.
It should be noted that, in the present disclosure, the embodiments and features of the embodiments may be combined with each other without conflict. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
Fig. 1 illustrates an exemplary architecture 100 to which the Protobuf-based interface testing method or the Protobuf-based interface testing apparatus of the present disclosure may be applied.
As shown in fig. 1, the system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the terminal devices 101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
The terminal devices 101, 102, 103 interact with a server 105 via a network 104 to receive or send messages or the like. The terminal devices 101, 102, 103 may have various communication client applications installed thereon, such as a web browser application, a software development application, a search application, an instant messaging tool, a mailbox client, and the like.
The terminal apparatuses 101, 102, and 103 may be hardware or software. When the terminal devices 101, 102, 103 are hardware, they may be various electronic devices having a display screen and supporting code writing and debugging, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like. When the terminal apparatuses 101, 102, 103 are software, they can be installed in the electronic apparatuses listed above. It may be implemented as multiple pieces of software or software modules (e.g., software or software modules used to provide distributed services) or as a single piece of software or software module. And is not particularly limited herein.
The server 105 may be a server that provides various services, such as a server (e.g., Jenkins) that performs interface tests on code written on the terminal devices 101, 102, 103. The server can test the interface by using the test data file and generate result information representing whether the interface to be tested passes the test; and the generated result information can be fed back to the terminal equipment.
The server may be hardware or software. When the server is hardware, it may be implemented as a distributed server cluster formed by multiple servers, or may be implemented as a single server. When the server is software, it may be implemented as multiple pieces of software or software modules (e.g., software or software modules used to provide distributed services), or as a single piece of software or software module. And is not particularly limited herein.
It should be noted that the Protobuf-based interface testing method provided by the embodiment of the present disclosure is generally executed by the server 105, and accordingly, the Protobuf-based interface testing apparatus is generally disposed in the server 105.
It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
With continued reference to fig. 2, a flow 200 of one embodiment of a Protobuf-based interface testing method according to the present disclosure is shown. The interface testing method based on Protobuf comprises the following steps:
In this embodiment, an executing body (such as the server 105 shown in fig. 1) of the Protobuf-based interface testing method may obtain a test data file matched with an interface to be tested in a wired connection manner or a wireless connection manner. And the test data file conforms to the data definition in the preset Protobuf file. The structure of a data entity for data transmission using the Protobuf protocol is generally defined in the Protobuf file (. pb file). The test data file may include at least one test case. The test case may include entries and expected outputs. The entry may include data input to the interface under test. The expected output may include an expected result returned by the interface under test after receiving the entry. The test data files may include data files for testing various interfaces. The test data file matched with the interface to be tested can generally comprise a data file for testing the interface to be tested.
It should be noted that the Protobuf file may generate class codes of corresponding languages through Application Programming Interfaces (API) of different languages (e.g., C + +, Java, Python).
Specifically, the execution main body may obtain a test data file which is pre-stored locally and used for testing the interface to be tested, or may obtain a test data file which matches the interface to be tested from an electronic device (for example, a Git server or a terminal used by a tester) which is in communication connection with the execution main body. The test data file may include various types, such as excel, xml, csv, and the like.
In some optional implementation manners of this embodiment, the executing body may obtain the test data file matched with the interface to be tested by:
first, an information set of a test data file is obtained.
In these implementations, the execution subject may obtain the information set of the test data file through a wired connection manner or a wireless connection manner. The information of the test data file may include an identifier of a page in the test data file. As an example, the test data file may be an excel-type file, and the identifier of the page in the test data file may include a name of a sheet page.
And secondly, acquiring the identifier of the interface to be tested.
In these implementations, the execution main body may obtain the identifier of the interface to be tested in a wired connection manner or a wireless connection manner. Wherein, the identifier includes a class name (ClassName) of a script for implementing the function of the interface to be tested. The above-mentioned class name may be, for example, "markviewmenuseservicetest".
And thirdly, acquiring the test data file as a matched test data file according to the paging identifier in the test data file which is consistent with the class name of the script corresponding to the interface to be tested.
In these implementations, the execution subject may obtain the test data file as the matched test data file according to the identifier of the page in the test data file that is consistent with the class name of the script corresponding to the interface to be tested. As an example, the execution subject may obtain, as the matched test data file, a test data file in which a name of a sheet page of the test data file is consistent with a class name of a script corresponding to the interface to be tested.
In some optional implementation manners of this embodiment, the test case of the test data file may further include a method name (e.g., getMenu). The method names described above may be used to characterize the functionality of the interface to be tested.
In this embodiment, the execution subject may transmit the input parameter in the test data file obtained in step 201 to the interface to be tested, and then obtain the returned test result from the interface to be tested to form a test result set corresponding to the input parameter. Since the Protobuf protocol is based on a binary format, the test result is usually in the form of a binary sequence stream file.
In some optional implementation manners of this embodiment, based on the method name included in the test case in the test data file, the execution main body may transmit the entry in the test data file to the interface to be tested according to the following steps, and generate a test result corresponding to the entry:
firstly, reading a test case in a test data file.
In these implementations, the execution subject may read all test cases (which may be generally embodied as row data) in the test data file obtained in step 201.
Secondly, selecting a test case from the test data file, and executing the following test steps:
in these implementations, the execution agent may select a test case from the test file in various ways (e.g., randomly or sequentially), and execute the following steps S1-S4.
And S1, determining whether the method name of the selected test case meets the preset condition.
In these implementations, the execution subject may determine whether the method name of the selected test case satisfies a preset condition. The preset condition may include that the method name of the selected test case matches the interface to be tested. As an example, the execution subject may obtain a list of method names matching each interface to be tested in advance. In response to determining that the method name of the selected test case exists in the list of method names matching the interface to be tested, the execution subject may determine that the preset condition is satisfied. Optionally, the executing body may further obtain a method name list that is configured in advance and matches class names of scripts corresponding to the interfaces to be tested.
S2, responding to the determination and satisfaction, transmitting the input parameters of the selected test case into the interface to be tested, generating a test result corresponding to the input parameters of the selected test case, and storing the generated test result into a preset test result set.
In these implementations, in response to determining that the preset condition of step S1 is satisfied, the execution subject may transfer an entry of the selected test case into an interface to be tested, and obtain a returned test result from the interface to be tested. Then, the execution main body can store the obtained test result into a preset test result set.
And S3, determining whether the test data file has unselected test cases.
S4, responding to the determination of existence, reselecting the test case from the test data file, and continuing to execute the test step.
In these implementations, in response to determining that there are unselected test cases in the test data file, the execution subject may reselect a test case from the test data file, and re-execute the step S1.
Based on the optional implementation manner, the execution main body can traverse the test cases in the test data file to fully test the interface to be tested.
And 203, deserializing the generated test result to generate a test result object.
In this embodiment, the execution subject may perform deserialization on the test result generated in step 202, so as to generate a test result object. As an example, the execution body may deserialize the generated test result into a test result object by the parseFrom () method. The test result object is usually consistent with the language class code generated by the Protobuf file. For example, if the Protobuf file generates a class code of Java language, the test result object is a Java object.
In this embodiment, the execution subject may acquire a value (value) corresponding to the test result object generated in step 203. The value corresponding to the test result object is usually consistent with the data type in the test data file, i.e. is non-binary.
In this embodiment, according to a comparison between a value corresponding to a test result object and a corresponding expected output, the execution subject may generate result information representing whether the interface to be tested passes the test in various ways. Wherein the values and expected outputs corresponding to the test result objects generally correspond to the same arguments.
As an example, in response to determining that the value corresponding to the test result object obtained in step 204 is consistent with the corresponding expected output, the executing entity may generate result information characterizing the passing of the test by the interface to be tested. In response to determining that the value corresponding to the test result object obtained in step 204 is inconsistent with the corresponding expected output, the executing entity may generate result information characterizing that the interface to be tested fails the test.
In some optional implementation manners of this embodiment, the executing body may further generate an interface test report according to the generated result information indicating whether the interface to be tested passes the test. The interface test report may further include a method name, a serial number, description information, a reference, an expected output, a test result, and information indicating whether to execute the test case. In practice, the execution main body may obtain result information of each interface to be tested in a monitoring manner.
Based on the optional implementation manner, the execution subject may generate an interface test report while performing an interface test, so that visualization of a test result may be implemented.
With continued reference to fig. 3, fig. 3 is a schematic diagram of an application scenario of the Protobuf-based interface testing method according to an embodiment of the present disclosure. In the application scenario of fig. 3, a tester 301 may send an instruction 303 characterizing the start of an interface test to a Jenkins server 304 through a terminal 302. Jenkins server 304 may obtain a test data file 306 from Git server 305 that matches the interface to be tested. The Git server 305 generally stores a script of an interface to be tested written by a developer and a test data file written by a tester in advance. The Jenkins server 304 transmits the input parameters 3061 in the matched test data file 306 to the interface to be tested 307, and generates a test result 308 corresponding to the input parameters. Then, after the Jenkins server 304 may deserialize the test result 308 and generate the test result object 309, the Jenkins server 304 may obtain a value 310 corresponding to the test result object 309. Based on a comparison of the expected output 3062 corresponding to the entries 3061 and the obtained value 310 corresponding to the test result object 309, the Jenkins server 304 generates result information 311 characterizing whether the interface to be tested passes the test. Optionally, the Jenkins server 304 may further feed back, to the terminal device 302, the generated result information 311 indicating whether the interface to be tested passes the test.
At present, one of the prior arts generally uses the existing interface automation test framework or tool to execute the test script to test the interface, which results in the need to write the test script, protocol file and configure the test data in advance, and needs to occupy more network bandwidth and I/O resources. According to the method provided by the embodiment of the disclosure, the test data, the Protobuf file and the test script are isolated through the test data file conforming to the preset Protobuf file, and the test script is not required to be modified only by modifying the Protobuf file or the test data file when the interface Protobuf protocol changes or data is modified, so that the reusability of the test script is improved, and human resources are saved. Moreover, the data transmission amount is greatly reduced through the Protobuf coding, so that the network resources are saved.
With further reference to fig. 4, a flow 400 of yet another embodiment of a Protobuf-based interface testing method is shown. The process 400 of the Protobuf-based interface testing method includes the following steps:
And 403, deserializing the generated test result to generate a test result object.
In response to determining that the test result object is not empty, attributes of the test result object are obtained based on the reflection mechanism, step 404.
In this embodiment, in response to determining that the test result object generated in step 403 is not empty, the execution subject (e.g., the server 105 shown in fig. 1) of the Protobuf-based interface test method may obtain the attribute of the test result object based on a reflection mechanism. As an example, the test result object is a Java object, and the execution subject may obtain the class and parent class attributes of the test result object by using a reflection mechanism of Java.
In step 405, an attribute value corresponding to the acquired attribute is acquired as a value corresponding to the test result object.
In this embodiment, the execution agent may acquire an attribute value corresponding to the attribute acquired in step 404 as a value corresponding to the test result object. The attributes and attribute values of the objects are generally in one-to-one correspondence.
In some optional implementation manners of this embodiment, the executing body may further generate result information that characterizes whether the interface to be tested passes the test, by:
firstly, storing the obtained value corresponding to the test result object into a preset key value database.
And secondly, generating result information representing that the interface to be tested passes the test in response to the fact that the obtained attribute value is consistent with the corresponding expected output.
And thirdly, generating result information representing that the interface to be tested fails the test in response to the fact that the obtained attribute value is inconsistent with the corresponding expected output.
In some optional implementation manners of this embodiment, the executing body may further generate an interface test report according to the generated result information indicating whether the interface to be tested passes the test. The interface test report may further include a method name, a serial number, description information, a reference, an expected output, a test result, and information indicating whether to execute the test case.
As can be seen from fig. 4, the flow 400 of the Protobuf-based interface testing method in this embodiment embodies a step of obtaining the attribute of the test result object based on the reflection mechanism, and a step of obtaining an attribute value corresponding to the obtained attribute as a value corresponding to the test result object. Therefore, the scheme described in this embodiment can convert the output of the Protobuf code into a data format consistent with the expected output in the test data file by using a reflection mechanism, thereby realizing the link between the Protobuf code and the interface test, reducing the data transmission quantity of the interface test, and improving the performance of the interface test.
With further reference to fig. 5, as an implementation of the methods shown in the above-mentioned figures, the present disclosure provides an embodiment of a Protobuf-based interface testing apparatus, which corresponds to the method embodiment shown in fig. 2 or fig. 4, and which may be specifically applied to various electronic devices.
As shown in fig. 5, the Protobuf-based interface testing apparatus 500 provided in the present embodiment includes a first obtaining unit 501, a first generating unit 502, a second generating unit 503, a second obtaining unit 504, and a third generating unit 505. The first obtaining unit 501 is configured to obtain a test data file matched with an interface to be tested, where the test data file conforms to a data definition in a preset Protobuf file, the test data file includes at least one test case, and the test case includes input parameters and expected output; a first generating unit 502, configured to transmit an entry in a test data file to an interface to be tested, and generate a test result set corresponding to the entry, where the test result is in a binary form; a second generating unit 503 configured to deserialize the generated test result and generate a test result object; a second obtaining unit 504 configured to obtain a value corresponding to the test result object; and a third generating unit 505 configured to generate result information characterizing whether the interface to be tested passes the test according to a comparison of the value corresponding to the test result object and the corresponding expected output.
In the present embodiment, in the Protobuf-based interface test apparatus 500: the specific processing of the first obtaining unit 501, the first generating unit 502, the second generating unit 503, the second obtaining unit 504, and the third generating unit 505 and the technical effects thereof can refer to the related descriptions of step 201, step 202, step 203, step 204, and step 205 in the corresponding embodiment of fig. 2, respectively, and are not repeated herein.
In some optional implementation manners of this embodiment, the first obtaining unit 501 may include: an information acquisition module (not shown in the figure), an identification acquisition module (not shown in the figure), and a file acquisition module (not shown in the figure). The information acquisition module may be configured to acquire an information set of the test data file. The information of the test data file may include an identifier of a page in the test data file. The identifier obtaining module may be configured to obtain an identifier of the interface to be tested. The identifier may include a class name of a script corresponding to the interface to be tested. The file obtaining module may be configured to obtain the test data file as a matched test data file according to the identifier of the page in the test data file that is consistent with the class name of the script corresponding to the interface to be tested.
In some optional implementation manners of this embodiment, the test case of the test data file may further include a method name. The method names described above may be used to characterize the functionality of the interface to be tested. The first generating unit 502 may include: a reading module (not shown), a selecting module (not shown), and a testing module (not shown). The reading module can be configured to read a test case in the test data file. The selecting module may be configured to select a test case from the test data file. The test module described above may be configured to perform the following test steps: determining whether the method name of the selected test case meets a preset condition; responding to the determination satisfaction, transmitting the input parameters of the selected test case into an interface to be tested, generating a test result corresponding to the input parameters of the selected test case, and storing the generated test result into a preset test result set; determining whether the test data file has unselected test cases; in response to determining that the test case exists, the test case is re-selected from the test data file and the testing step continues.
In some optional implementations of the present embodiment, the second obtaining unit 504 may include an attribute obtaining module (not shown in the figure) and an attribute value obtaining module (not shown in the figure). The attribute obtaining module may be configured to, in response to determining that the test result object is not empty, obtain the attribute of the test result object based on a reflection mechanism. The attribute value acquisition module may be configured to acquire an attribute value corresponding to the acquired attribute as a value corresponding to the test result object.
In some optional implementations of the present embodiment, the third generating unit 505 may include an attribute storing module (not shown in the figure), a first generating module (not shown in the figure), and a second generating module (not shown in the figure). The storage module may be configured to store the obtained value corresponding to the test result object in a preset key value database. The first generating module may be configured to generate result information characterizing that the interface to be tested passes the test in response to determining that the obtained attribute value is consistent with the corresponding expected output. The second generating module may be configured to generate result information indicating that the interface to be tested fails the test in response to determining that the obtained attribute value is inconsistent with the corresponding expected output.
In some optional implementations of this embodiment, the Protobuf-based interface testing apparatus 500 may further include: a fourth generating unit (not shown in the figure) configured to: and generating an interface test report according to the generated result information which represents whether the interface to be tested passes the test. The interface test report may further include a method name, a serial number, description information, a reference, an expected output, a test result, and information indicating whether to execute the test case.
The apparatus provided by the foregoing embodiment of the present disclosure acquires, by using the first acquiring unit 501, a test data file matched with an interface to be tested. And the test data file conforms to the data definition in the preset Protobuf file. The test data file includes at least one test case. The test cases include entries and expected outputs. Then, the first generating unit 502 transmits the input parameters in the test data file to the interface to be tested, and generates a test result set corresponding to the input parameters. Wherein the test result is in binary form. Next, the second generation unit 503 deserializes the generated test result and generates a test result object. After that, the second acquisition unit 504 acquires a value corresponding to the test result object. Finally, the third generating unit 505 generates result information representing whether the interface to be tested passes the test according to the comparison between the value corresponding to the test result object and the corresponding expected output. Therefore, the test data, the Protobuf file and the test script are isolated, the test script can be modified only by modifying the Protobuf file or the test data file when the interface Protobuf protocol changes or data is modified, the reusability of the test script is improved, and human resources are saved. Moreover, the data transmission amount is greatly reduced through the Protobuf coding, so that the network resources are saved.
Referring now to FIG. 6, a schematic diagram of an electronic device (e.g., the server of FIG. 1) 600 suitable for use in implementing embodiments of the present disclosure is shown. The terminal device in the embodiments of the present disclosure may include, but is not limited to, a mobile terminal such as a mobile phone, a notebook computer, and the like, and a stationary terminal such as a digital TV, a desktop computer, and the like. The server shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
As shown in fig. 6, electronic device 600 may include a processing means (e.g., central processing unit, graphics processor, etc.) 601 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data necessary for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
Generally, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; an output device 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 6 illustrates an electronic device 600 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided. Each block shown in fig. 6 may represent one device or may represent multiple devices as desired.
In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication means 609, or may be installed from the storage means 608, or may be installed from the ROM 602. The computer program, when executed by the processing device 601, performs the above-described functions defined in the methods of embodiments of the present disclosure.
It should be noted that the computer readable medium described in the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In embodiments of the disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In embodiments of the present disclosure, however, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the foregoing.
The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: acquiring a test data file matched with an interface to be tested, wherein the test data file conforms to a data definition in a preset Protobuf file, the test data file comprises at least one test case, and the test case comprises input parameters and expected output; transmitting the input parameters in the test data file into an interface to be tested, and generating a test result set corresponding to the input parameters, wherein the test result is in a binary form; deserializing the generated test result to generate a test result object; obtaining a value corresponding to a test result object; and generating result information representing whether the interface to be tested passes the test or not according to the comparison between the value corresponding to the test result object and the corresponding expected output.
Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present disclosure may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor comprises a first acquisition unit, a first generation unit, a second acquisition unit and a third generation unit. For example, the first obtaining unit may be further described as a unit that obtains a test data file matched with the interface to be tested, where the test data file conforms to a data definition in a preset Protobuf file, the test data file includes at least one test case, and the test case includes an entry and an expected output.
The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above-mentioned features, but also encompasses other embodiments in which any combination of the above-mentioned features or their equivalents is made without departing from the inventive concept as defined above. For example, the above features and (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure are mutually replaced to form the technical solution.
Claims (10)
1. An interface testing method based on Protobuf comprises the following steps:
acquiring a test data file matched with an interface to be tested, wherein the test data file conforms to a data definition in a preset Protobuf file, the test data file comprises at least one test case, and the test case comprises input parameters and expected output;
transmitting the input parameters in the test data file into the interface to be tested, and generating a test result set corresponding to the input parameters, wherein the test result is in a binary form;
deserializing the generated test result to generate a test result object;
obtaining a value corresponding to the test result object;
and generating result information representing whether the interface to be tested passes the test or not according to the comparison between the value corresponding to the test result object and the corresponding expected output.
2. The method of claim 1, wherein said obtaining a test data file matching an interface to be tested comprises:
acquiring an information set of a test data file, wherein the information of the test data file comprises a paging identifier in the test data file;
acquiring an identifier of an interface to be tested, wherein the identifier comprises a class name of a script corresponding to the interface to be tested;
and acquiring the test data file as the matched test data file according to the paging identifier in the test data file consistent with the class name of the script corresponding to the interface to be tested.
3. The method of claim 2, wherein the test case of the test data file further comprises a method name, and the method name is used for characterizing the function of the interface to be tested; and
the transmitting the input parameters in the test data file to the interface to be tested to generate test results corresponding to the input parameters includes:
reading a test case in the test data file;
selecting a test case from the test data file, and executing the following test steps: determining whether the method name of the selected test case meets a preset condition; responding to the determination satisfaction, transmitting the input parameters of the selected test case into the interface to be tested, generating a test result corresponding to the input parameters of the selected test case, and storing the generated test result into a preset test result set; determining whether the test data file has unselected test cases;
in response to determining that there is a test case, reselecting a test case from the test data file, and continuing to perform the testing step.
4. The method of claim 1, wherein said obtaining a value corresponding to the test result object comprises:
in response to determining that the test result object is not empty, obtaining attributes of the test result object based on a reflection mechanism;
an attribute value corresponding to the acquired attribute is acquired as a value corresponding to the test result object.
5. The method of claim 4, wherein generating result information characterizing whether the interface under test passes the test based on a comparison of the value corresponding to the test result object and the corresponding expected output comprises:
storing the obtained value corresponding to the test result object into a preset key value database;
in response to determining that the obtained attribute values are consistent with the corresponding expected outputs, generating result information representing that the interface to be tested passes the test;
in response to determining that the obtained attribute values are inconsistent with the corresponding expected outputs, generating result information characterizing that the interface to be tested fails the test.
6. The method according to one of claims 1-5, wherein the method further comprises:
and generating an interface test report according to the generated result information representing whether the interface to be tested passes the test, wherein the interface test report also comprises the method name, the number, the description information, the input parameters, the expected output, the test result and the information representing whether the interface to be tested is executed.
7. An interface testing arrangement based on Protobuf includes:
the device comprises a first obtaining unit, a second obtaining unit and a third obtaining unit, wherein the first obtaining unit is configured to obtain a test data file matched with an interface to be tested, the test data file conforms to a data definition in a preset Protobuf file, the test data file comprises at least one test case, and the test case comprises input parameters and expected output;
the first generation unit is configured to transmit the input parameters in the test data file to the interface to be tested and generate a test result set corresponding to the input parameters, wherein the test result is in a binary form;
a second generation unit configured to deserialize the generated test result and generate a test result object;
a second acquisition unit configured to acquire a value corresponding to the test result object;
a third generating unit configured to generate result information characterizing whether the interface to be tested passes the test according to a comparison of a value corresponding to the test result object and a corresponding expected output.
8. The apparatus of claim 7, wherein the second obtaining unit comprises:
an attribute acquisition module configured to acquire an attribute of the test result object based on a reflection mechanism in response to determining that the test result object is not empty;
an attribute value acquisition module configured to acquire an attribute value corresponding to the acquired attribute as a value corresponding to the test result object.
9. An electronic device, comprising:
one or more processors;
a storage device having one or more programs stored thereon;
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-6.
10. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010439135.3A CN113704079A (en) | 2020-05-22 | 2020-05-22 | Interface testing method and device based on Protobuf |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010439135.3A CN113704079A (en) | 2020-05-22 | 2020-05-22 | Interface testing method and device based on Protobuf |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113704079A true CN113704079A (en) | 2021-11-26 |
Family
ID=78646060
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010439135.3A Pending CN113704079A (en) | 2020-05-22 | 2020-05-22 | Interface testing method and device based on Protobuf |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113704079A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117130945A (en) * | 2023-10-26 | 2023-11-28 | 中国证券登记结算有限责任公司 | Test method and device |
-
2020
- 2020-05-22 CN CN202010439135.3A patent/CN113704079A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117130945A (en) * | 2023-10-26 | 2023-11-28 | 中国证券登记结算有限责任公司 | Test method and device |
| CN117130945B (en) * | 2023-10-26 | 2024-02-09 | 中国证券登记结算有限责任公司 | Test method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111679990B (en) | Test data generation method and device, readable medium and electronic equipment | |
| CN109684188B (en) | Test method and device | |
| CN111338623B (en) | Method, device, medium and electronic equipment for developing user interface | |
| CN110232091B (en) | Method, system and apparatus for synchronizing data | |
| CN111400172B (en) | Program debugging method and device | |
| CN112631590B (en) | Component library generation method, device, electronic equipment and computer readable medium | |
| CN109582317B (en) | Method and apparatus for debugging hosted applications | |
| CN110619096A (en) | Method and apparatus for synchronizing data | |
| CN111694757A (en) | Application program testing method and device, electronic equipment and computer readable storage medium | |
| CN110879729A (en) | Channel configuration method and device for live broadcast room, readable medium and electronic equipment | |
| CN110489326B (en) | IDS-based HTTPAPI debugging method device, medium and equipment | |
| CN113704079A (en) | Interface testing method and device based on Protobuf | |
| CN111752644A (en) | Interface simulation method, device, equipment and storage medium | |
| CN111414154A (en) | Method and device for front-end development, electronic equipment and storage medium | |
| CN111209205A (en) | Configuration method and device and electronic equipment | |
| CN112306858A (en) | Test method and device and electronic equipment | |
| CN113468041A (en) | Interface comparison test method and device | |
| CN113407229A (en) | Method and device for generating offline script | |
| CN113157365B (en) | Program running method, program running device, electronic equipment and computer readable medium | |
| CN112688863B (en) | Gateway data processing method and device and electronic equipment | |
| CN117076302A (en) | Automatic test method and device, electronic equipment and storage medium | |
| CN115705193A (en) | Distributed compiling method, device, equipment and medium | |
| CN117710525A (en) | Label image generation method, information transmission method, device, equipment and medium | |
| CN115840692A (en) | Code overlay method, apparatus, device, computer readable medium and program product | |
| CN111737105A (en) | Display interface compatibility testing method and device, electronic equipment and medium |
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 |