CN111338944A - Remote Procedure Call (RPC) interface test method, device, medium and equipment - Google Patents

Abstract

The disclosure relates to a Remote Procedure Call (RPC) interface test method, a device, a medium and equipment, wherein the method comprises the following steps: acquiring an entry file corresponding to a service to be tested of the RPC interface, wherein the entry file comprises a plurality of methods of the service to be tested; parsing the syntax of the entry file to obtain a dependency relationship representation among a plurality of methods contained in the entry file; acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship expression, wherein the target method is a method to be tested in a plurality of methods of the service to be tested; and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object. Therefore, the client can be generated without compiling in advance, and the time consumed by interface testing and the occupation of storage resources can be effectively saved.

Description

Remote Procedure Call (RPC) interface test method, device, medium and equipment

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, a medium, and a device for testing a Remote Procedure Call (RPC) interface.

Background

In the related art, when a server interface is tested, an RPC (Remote Procedure call protocol) interface needs to be tested based on an RPC request created by an interface definition. In the prior art, a pre-compiling generation client is usually needed, so that a request is initiated at the pre-generated client to test an interface. However, the time spent on compiling the generated client in advance is large, the storage occupation is large, and the maintenance of the generated client in advance is not convenient.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In a first aspect, the present disclosure provides a Remote Procedure Call (RPC) interface testing method, including:

acquiring an entry file corresponding to a service to be tested of the RPC interface, wherein the entry file comprises a plurality of methods of the service to be tested;

parsing the syntax of the entry file to obtain a dependency relationship representation among a plurality of methods contained in the entry file;

acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship expression, wherein the target method is a method to be tested in a plurality of methods of the service to be tested;

and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object.

In a second aspect, the present disclosure provides a Remote Procedure Call (RPC) interface testing apparatus, the apparatus comprising:

the RPC interface comprises a first acquisition module and a second acquisition module, wherein the first acquisition module is used for acquiring an entry file corresponding to a service to be tested of the RPC interface, and the entry file comprises a plurality of methods of the service to be tested;

the analysis module is used for carrying out syntax analysis on the entry file to obtain a dependency relationship expression among a plurality of methods contained in the entry file;

a second obtaining module, configured to obtain, according to the dependency relationship representation, an interface definition file corresponding to a target method in the service to be tested, where the target method is a method to be tested in the multiple methods of the service to be tested;

and the creating module is used for creating a client object in the memory based on the interface definition file corresponding to the target method so as to test the target method based on the client object.

In a third aspect, the present disclosure provides a computer readable medium having stored thereon a computer program which, when executed by a processing apparatus, performs the steps of the method of the first aspect.

In a fourth aspect, the present disclosure provides an electronic device comprising:

a storage device having a computer program stored thereon;

processing means for executing the computer program in the storage means to carry out the steps of the method of the first aspect.

In the technical scheme, the entry file corresponding to the service to be tested of the RPC interface is obtained, syntax analysis is carried out on the entry file, and dependency relationship expression among a plurality of methods contained in the entry file is obtained; acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship representation; and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object. Therefore, according to the technical scheme, the client object is created in the memory based on the interface definition file, and the client can be generated without compiling in advance, so that the time consumed by interface testing and the occupation of storage resources can be effectively saved. In addition, the client object can be directly read from the memory without creating an additional client process for communication, so that the complexity of the interface test is effectively simplified, and the test efficiency and accuracy can be improved.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numbers refer to the same or similar elements. It should be understood that the drawings are schematic and that elements and features are not necessarily drawn to scale.

In the drawings:

FIG. 1 is a flow diagram of a Remote Procedure Call (RPC) interface testing method provided according to one embodiment of the present disclosure;

FIG. 2 is a flow diagram of an exemplary embodiment of obtaining an interface definition file corresponding to a target method in a service to be tested according to a dependency representation, provided in accordance with an embodiment of the present disclosure;

FIG. 3 is a block diagram of a Remote Procedure Call (RPC) interface testing apparatus provided according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of an electronic device provided according to an embodiment of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order, and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "include" and variations thereof as used herein are open-ended, i.e., "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Relevant definitions for other terms will be given in the following description.

It should be noted that the terms "first", "second", and the like in the present disclosure are only used for distinguishing different devices, modules or units, and are not used for limiting the order or interdependence relationship of the functions performed by the devices, modules or units.

It is noted that references to "a", "an", and "the" modifications in this disclosure are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that "one or more" may be used unless the context clearly dictates otherwise.

The names of messages or information exchanged between devices in the embodiments of the present disclosure are for illustrative purposes only, and are not intended to limit the scope of the messages or information.

As described in the background section above, the applicant has found through research that, in the prior art, when testing an RPC interface, a large number of clients are generated to be tested by compiling in advance based on each method of a service to be tested in the RPC interface, such as creating a client using thrift-gen. The client side comprises a method needing to be tested and a method not needing to be tested. And when the RPC interface is tested based on a pre-generated client, an additional process needs to be created to enable the client to interact with the testing platform, so that the consumption of time and memory is high. Based on this, the applicant provides the following technical scheme to effectively reduce the occupation of time and memory when the RPC interface test is performed.

Fig. 1 is a flowchart illustrating a remote procedure call RPC interface testing method according to an embodiment of the present disclosure. As shown in fig. 1, the method includes:

in S11, a portal file corresponding to the service to be tested of the RPC interface is obtained, where the portal file includes a plurality of methods of the service to be tested.

The entry file may be an Import file corresponding to the RPC interface, and the entry file may be specified by service personnel, for example, an absolute path of the entry file is specified, so that the position of the entry file may be determined by the absolute path, and the entry file may be obtained. The entry file contains a plurality of methods of the service to be tested, and the methods of the service to be tested can be imported based on the entry file.

In S12, the entry file is parsed to obtain a representation of the dependency relationship between the methods included in the entry file.

The syntax parser can parse the entry file, and the syntax parser can output the dependency relationship of each method therein by performing dependency syntax analysis, that is, obtain the dependency relationship representation. The dependency parsing is a common method in the art, and is not described herein again.

In S13, according to the dependency relationship expression, an interface definition file corresponding to a target method in the service to be tested is obtained, where the target method is a method to be tested in the plurality of methods of the service to be tested.

The RPC Interface is usually created by using an IDL (Interface description language), and the Interface definition file corresponding to the method is the IDL file corresponding to the IDL Interface definition file, where the IDL file is used to describe relevant information of the Interface, such as a return value, a parameter, a name, and the like. Based on the interface definition file, information of the corresponding method can be obtained, so that the method can be tested.

In an embodiment, the target method may be all methods in the RPC interface, and at this time, the corresponding interface definition file may be obtained according to each method to be tested. In another embodiment, the target method may be a partial method in an RPC interface, and in this embodiment, only the interface definition file corresponding to the method to be tested needs to be obtained, and for a method that does not need to be tested in the RPC interface, the interface definition file corresponding to the method does not need to be obtained, so that the number of the interface definition files can be effectively reduced, resource waste caused by obtaining unnecessary interface definition files is avoided, the files are imported as required, and the interface testing efficiency is improved.

In S14, a client object is created in the memory based on the interface definition file corresponding to the target method, so that the target method is tested based on the client object.

After the interface definition file corresponding to the target method is obtained, the interface definition file can be imported into the test platform, so that the client object can be created in the memory through nodeJS in the test platform. In the related art, each method in the service to be tested needs to be compiled to generate a file, i.e., a local client. When the interface test is performed, the local client needs to create a process so as to interact with the test platform to realize the test. In the present disclosure, an object is only required to be created in the memory according to the method to be tested, and the object is used for initiating a connection and analysis request, that is, the client object. Because the client object is created in the memory, when the target method is tested according to the client object, additional client processes and execution files do not need to be created, the client object initiation request can be directly read from the memory for testing, for example, the client object can carry an object identifier initiation request, so that the interface is tested by recording the delay, wherein the testing based on the initiation request is a common choice in the field, and is not described herein again.

In the technical scheme, the entry file corresponding to the service to be tested of the RPC interface is obtained, syntax analysis is carried out on the entry file, and dependency relationship expression among a plurality of methods contained in the entry file is obtained; acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship representation; and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object. Therefore, according to the technical scheme, the client object is created in the memory based on the interface definition file, and the client can be generated without compiling in advance, so that the time consumed by interface testing and the occupation of storage resources can be effectively saved. In addition, the client object can be directly read from the memory without creating an additional client process for communication, so that the complexity of the interface test is effectively simplified, and the test efficiency and accuracy can be improved.

Optionally, the dependency relationship is expressed as an Abstract Syntax Tree (AST), in S13, according to the dependency relationship expression, an exemplary embodiment of obtaining an interface definition file corresponding to a target method in the service to be tested is as follows, as shown in fig. 2, and this step may include:

in S21, the identity of each dependency file required to execute the target method is determined according to an abstract syntax tree generated according to the dependency relationship of the respective methods of the service to be tested.

The manner of generating the abstract syntax tree is the prior art, and is not described herein again. In this step, the abstract syntax tree is used to represent the dependency relationship among the methods of the service to be tested, so that the dependency files of the target method can be quickly determined based on the tree structure of the abstract syntax tree. Illustratively, the dependency file may be a description file of the interface/method on which the target method is dependent when executed. For example, if the target method a needs to execute the method B, and the method B needs to execute the method C, the dependent files of the target method a are the description files corresponding to the methods A, B, C, respectively.

It should be noted that the description file of the target method itself also belongs to one of its corresponding dependent files. Based on the abstract syntax tree, each dependent file required by the target method can be quickly positioned based on the dependency relationship among the methods, and further the identification of the dependent file is obtained. Wherein the identity of each dependent file may be determined recursively based on the abstract syntax tree.

In S22, an interface definition file corresponding to the target method is obtained according to the identifier of each dependent file.

In one embodiment, the corresponding file may be pulled from the GIT repository based on the identification of each dependent file. The GIT warehouse is an open-source distributed version control system, and can effectively process the version management of projects from very small to very large at high speed. The staff can submit the written interface file to the GIT warehouse, so that each interface definition file can be acquired from the GIT warehouse, and the version control of the interface definition file is facilitated.

Optionally, in another embodiment, in S22, according to the identifier of the dependency file, an exemplary implementation manner of obtaining the interface definition file corresponding to the target method is as follows, and the step may include:

and querying the identification of the dependent file from a cache system. The cache system may be coupled to a test platform for performing RPC interface test, or may be independent of the test platform, which is not limited in this disclosure. Optionally, the cache system may be a system based on a distributed cache, for example, a Redis database, so that consistency of file versions can be achieved based on synchronization of the distributed cache, and technical support is provided for accuracy of interface testing.

If the identifier is found, and the version information of the dependent file is the same as the version information of the file corresponding to the identifier in the cache system, determining the file corresponding to the identifier in the cache system as the interface definition file corresponding to the target method.

By way of example, if the identifier is queried from the cache system, it indicates that the dependent file corresponding to the identifier is stored in the cache system. Since the version of the dependent file is controlled, in order to ensure that the version of the dependent file is the latest version, the latest version number of the dependent file may be determined as the version information of the dependent file when the dependent file is determined.

Wherein, the version information of the dependent file can be updated when the GIT warehouse is updated. For example, after the worker updates the interface code, the worker submits the updated file to the GIT repository, and at this time, the GIT repository may update the version information of the dependent file at the same time during updating, that is, the version information of the newly submitted file is determined as the version information of the dependent file.

In another embodiment, it is also possible to periodically request the latest version information of each file from the GIT repository, and determine the requested version information as the version information of the corresponding dependent file.

Therefore, when the identifier is queried from the cache system, it is necessary to determine whether the version information of the file corresponding to the identifier in the cache system is the same as the version information of the dependent file, that is, whether the file corresponding to the identifier in the cache system is the latest version. If the two are the same, the file in the cache system is the latest version, and the file can be directly read from the cache system, so that the file pulling time is saved, and the test efficiency is improved.

And if the identification is not inquired, requesting a file corresponding to the identification from a GIT (distributed version control system) warehouse, and determining the file corresponding to the requested identification as an interface definition file corresponding to the target method.

In this embodiment, if the identifier is not queried, it indicates that the dependent file does not exist in the cache system, and at this time, a request to the GIT repository is required to pull the dependent file from the GIT repository. The submission and the pulling of the file through the GIT repository can be performed through related commands in the prior art, such as commit commands, which are not described herein again.

In the above technical solution, when obtaining an interface definition file corresponding to a target method, first determining whether a file of a corresponding version exists in a cache system, and if so, directly obtaining the file from the cache system; if not, a pull file may be requested from the GIT repository. Therefore, according to the technical scheme, when the interface definition file corresponding to the target method is obtained, the cache system can be read preferentially, the file pulling efficiency can be improved, the pressure of the GIT warehouse can be effectively reduced, and meanwhile the consistency of the file version can be ensured.

Optionally, in S22, according to the identifier of the dependency file, another exemplary implementation manner of obtaining the interface definition file corresponding to the target method is as follows, and the step may further include:

and if the identifier is inquired and the version information of the dependent file is different from the version information of the file corresponding to the identifier in the cache system, requesting the file corresponding to the identifier from the GIT warehouse and determining the requested file corresponding to the identifier as the interface definition file corresponding to the target method.

As described above, if the version information of the dependent file is different from the version information of the file corresponding to the identifier in the cache system, it indicates that the file corresponding to the identifier in the cache system is not the latest version, and at this time, the file corresponding to the identifier needs to be requested from the GIT repository, so as to avoid the influence of the file version error on the interface test.

And updating the file corresponding to the identifier in the cache system according to the file corresponding to the identifier requested from the GIT warehouse.

As an example, the file corresponding to the identifier in the cache system may be deleted directly and the file corresponding to the identifier requested from the GIT repository may be saved in the cache system to implement the replacement update. As another example, delta updates may be made by comparing the identified corresponding file requested from the GIT repository to the identified corresponding file in the caching system.

Therefore, by the technical scheme, the accuracy of the interface definition file corresponding to the target method can be ensured, so that the accuracy of the interface test is ensured, the real-time version of each file in the cache system can be ensured, and the problems that a client is difficult to maintain and update untimely in the prior art can be effectively solved. Meanwhile, the files are obtained based on the cache system, so that the cache and the file pulling are separated from a command line, a client does not need to be locally deployed, the method can be deployed in a cloud clustering manner, and the application range of the method is effectively widened.

Optionally, after the step of obtaining the interface definition file corresponding to the target method in the service to be tested at S13, the method may further include:

and if the interface definition file does not exist in the cache system, storing the interface definition file, the identifier corresponding to the interface definition file and the version information into the cache system.

As an example, when the interface definition file is acquired for the first time, since no interface definition file is stored in the cache system at this time, the acquired interface definition file and the corresponding identifier and version information thereof may be directly stored in the cache system at this time.

As another example, when the interface definition file is obtained after the first time, it may be determined whether the obtained interface definition file is in a cache system, and if not, the obtained interface definition file and its corresponding identifier and version information may be stored in the cache system. For example, when the identifier is not queried in the cache system, the obtained interface definition file and the identifier and version information corresponding to the interface definition file may be directly stored in the cache system after the file corresponding to the identifier is requested from the distributed version control system GIT repository.

According to the technical scheme, the interface definition file, the identification and the version information corresponding to the interface definition file are stored in the cache system, so that the file can be obtained from the cache system, the real-time performance and the comprehensiveness of the file in the cache system can be ensured, the pressure on a GIT (general information technology) warehouse during file pulling is effectively relieved, and the efficiency of interface testing is improved.

The present disclosure also provides a remote procedure call RPC interface testing apparatus, as shown in fig. 3, theapparatus 10 includes:

a first obtainingmodule 100, configured to obtain an entry file corresponding to a service to be tested of the RPC interface, where the entry file includes multiple methods of the service to be tested;

theparsing module 200 is configured to perform syntax parsing on the entry file to obtain a dependency relationship representation among a plurality of methods included in the entry file;

a second obtainingmodule 300, configured to obtain, according to the dependency relationship representation, an interface definition file corresponding to a target method in the service to be tested, where the target method is a method to be tested in the multiple methods of the service to be tested;

a creatingmodule 400, configured to create a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object.

Optionally, the dependency relationship is represented as an abstract syntax tree, and the second obtaining module includes:

a determining submodule, configured to determine, according to the abstract syntax tree, an identifier of each dependent file required for executing the target method, where the abstract syntax tree is generated according to a dependency relationship of each method of the service to be tested;

and the obtaining submodule is used for obtaining the interface definition file corresponding to the target method according to the identification of each dependency file.

Optionally, the obtaining sub-module includes:

the query submodule is used for querying the identifier of the dependent file from the cache system;

a second determining submodule, configured to determine, if the identifier is found, and the version information of the dependent file is the same as the version information of the file corresponding to the identifier in the cache system, the file corresponding to the identifier in the cache system as the interface definition file corresponding to the target method;

and the first request submodule is used for requesting a file corresponding to the identifier from a distributed version control system (GIT) warehouse if the identifier is not inquired, and determining the file corresponding to the requested identifier as an interface definition file corresponding to the target method.

Optionally, the obtaining sub-module further includes:

a second request submodule, configured to, if the identifier is found, and the version information of the dependent file is different from the version information of the file corresponding to the identifier in the cache system, request the file corresponding to the identifier from the GIT repository, and determine the file corresponding to the identifier that is found as the interface definition file corresponding to the target method;

and the updating submodule is used for updating the file corresponding to the identifier in the cache system according to the file corresponding to the identifier requested from the GIT warehouse.

Optionally, the apparatus further comprises:

and the storage module is used for storing the interface definition file, the identifier corresponding to the interface definition file and the version information to the cache system if the interface definition file does not exist in the cache system after the second acquisition module acquires the interface definition file corresponding to the target method in the service to be tested.

Optionally, the cache system is a distributed cache based system.

Referring now to FIG. 4, a block diagram of anelectronic device 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, a digital broadcast receiver, a PDA (personal digital assistant), a PAD (tablet computer), a PMP (portable multimedia player), a vehicle terminal (e.g., a car navigation terminal), and the like, and a stationary terminal such as a digital TV, a desktop computer, and the like. The electronic device shown in fig. 4 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. 4,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 theRAM 603, various programs and data necessary for the operation of theelectronic apparatus 600 are also stored. Theprocessing device 601, theROM 602, and theRAM 603 are connected to each other via abus 604. An input/output (I/O)interface 605 is also connected tobus 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.;output devices 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 acommunication device 609. The communication means 609 may allow theelectronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 4 illustrates anelectronic 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.

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 carried on a non-transitory computer readable medium, the computer program containing program code for performing the method illustrated by 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 theROM 602. The computer program, when executed by theprocessing device 601, performs the above-described functions defined in the methods of the embodiments of the present disclosure.

It should be noted that the computer readable medium in the present disclosure can 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 the present 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 contrast, in the present disclosure, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, either 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.

In some embodiments, the clients, servers may communicate using any currently known or future developed network protocol, such as HTTP (HyperText transfer protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communications network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed network.

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 an entry file corresponding to a service to be tested of the RPC interface, wherein the entry file comprises a plurality of methods of the service to be tested; parsing the syntax of the entry file to obtain a dependency relationship representation among a plurality of methods contained in the entry file; acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship expression, wherein the target method is a method to be tested in a plurality of methods of the service to be tested; and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object. .

Computer program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including but not limited to 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 modules described in the embodiments of the present disclosure may be implemented by software or hardware. The name of a module does not in some cases form a definition of the module itself, for example, the first obtaining module may also be described as a "module that obtains a portal file corresponding to a service to be tested of the RPC interface".

The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), systems on a chip (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on 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.

Example 1 provides a remote procedure call, RPC, interface testing method, according to one or more embodiments of the present disclosure, including:

acquiring an entry file corresponding to a service to be tested of the RPC interface, wherein the entry file comprises a plurality of methods of the service to be tested;

parsing the syntax of the entry file to obtain a dependency relationship representation among a plurality of methods contained in the entry file;

acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship expression, wherein the target method is a method to be tested in a plurality of methods of the service to be tested;

and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object.

According to one or more embodiments of the present disclosure, example 2 provides the method of example 1, where the dependency relationship is represented as an abstract syntax tree, and obtaining an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship representation includes:

determining the identification of each dependent file required for executing the target method according to the abstract syntax tree, wherein the abstract syntax tree is generated according to the dependency relationship of each method of the service to be tested;

and acquiring an interface definition file corresponding to the target method according to the identifier of each dependency file.

According to one or more embodiments of the present disclosure, example 3 provides the method of example 2, where the obtaining, according to the identifier of the dependency file, the interface definition file corresponding to the target method includes:

querying the identification of the dependent file from a cache system;

if the identifier is inquired, and the version information of the dependent file is the same as that of the file corresponding to the identifier in the cache system, determining the file corresponding to the identifier in the cache system as an interface definition file corresponding to the target method;

and if the identification is not inquired, requesting a file corresponding to the identification from a GIT (distributed version control system) warehouse, and determining the file corresponding to the requested identification as an interface definition file corresponding to the target method.

Example 4 provides the method of example 3, wherein the obtaining an interface definition file corresponding to the target method according to the identifier of the dependency file further includes:

if the identifier is inquired and the version information of the dependent file is different from the version information of the file corresponding to the identifier in the cache system, requesting the file corresponding to the identifier from a GIT (trusted information technology) warehouse and determining the requested file corresponding to the identifier as an interface definition file corresponding to the target method;

and updating the file corresponding to the identifier in the cache system according to the file corresponding to the identifier requested from the GIT warehouse.

Example 5 provides the method of example 1, wherein, after the step of obtaining the interface definition file corresponding to the target method in the service to be tested, the method further includes:

and if the interface definition file does not exist in the cache system, storing the interface definition file, the identifier corresponding to the interface definition file and the version information into the cache system.

Example 6 provides the method of any of examples 3-5, wherein the caching system is a distributed cache-based system, according to one or more embodiments of the present disclosure.

Example 7 provides a remote procedure call, RPC, interface testing apparatus, according to one or more embodiments of the present disclosure, the apparatus comprising:

the RPC interface comprises a first acquisition module and a second acquisition module, wherein the first acquisition module is used for acquiring an entry file corresponding to a service to be tested of the RPC interface, and the entry file comprises a plurality of methods of the service to be tested;

the analysis module is used for carrying out syntax analysis on the entry file to obtain a dependency relationship expression among a plurality of methods contained in the entry file;

a second obtaining module, configured to obtain, according to the dependency relationship representation, an interface definition file corresponding to a target method in the service to be tested, where the target method is a method to be tested in the multiple methods of the service to be tested;

and the creating module is used for creating a client object in the memory based on the interface definition file corresponding to the target method so as to test the target method based on the client object.

Example 8 provides the apparatus of example 7, wherein the dependency relationships are represented as an abstract syntax tree, and the second obtaining module includes:

a determining submodule, configured to determine, according to the abstract syntax tree, an identifier of each dependent file required for executing the target method, where the abstract syntax tree is generated according to a dependency relationship of each method of the service to be tested;

and the obtaining submodule is used for obtaining the interface definition file corresponding to the target method according to the identification of each dependency file.

Example 9 provides the apparatus of example 8, wherein the acquisition submodule comprises:

the query submodule is used for querying the identifier of the dependent file from the cache system;

a second determining submodule, configured to determine, if the identifier is found, and the version information of the dependent file is the same as the version information of the file corresponding to the identifier in the cache system, the file corresponding to the identifier in the cache system as the interface definition file corresponding to the target method;

and the first request submodule is used for requesting a file corresponding to the identifier from a distributed version control system (GIT) warehouse if the identifier is not inquired, and determining the file corresponding to the requested identifier as an interface definition file corresponding to the target method.

Example 10 provides the apparatus of example 9, wherein the acquisition submodule further includes:

a second request submodule, configured to, if the identifier is found, and the version information of the dependent file is different from the version information of the file corresponding to the identifier in the cache system, request the file corresponding to the identifier from the GIT repository, and determine the file corresponding to the identifier that is found as the interface definition file corresponding to the target method;

and the updating submodule is used for updating the file corresponding to the identifier in the cache system according to the file corresponding to the identifier requested from the GIT warehouse.

Example 11 provides the apparatus of example 7, wherein the apparatus further comprises:

and the storage module is used for storing the interface definition file, the identifier corresponding to the interface definition file and the version information to the cache system if the interface definition file does not exist in the cache system after the second acquisition module acquires the interface definition file corresponding to the target method in the service to be tested.

Example 12 provides the apparatus of any one of examples 9-11, wherein the caching system is a distributed cache-based system, according to one or more embodiments of the present disclosure.

Example 13 provides a computer readable medium having stored thereon a computer program that, when executed by a processing apparatus, performs the steps of a remote procedure call, RPC, interface test method, in accordance with one or more embodiments of the present disclosure.

Example 14 provides, in accordance with one or more embodiments of the present disclosure, an electronic device, comprising:

a storage device having a computer program stored thereon;

and the processing device is used for executing the computer program in the storage device so as to realize the steps of the remote procedure call RPC interface test method.

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 disclosure herein is not limited to the particular combination of features described above, but also encompasses other embodiments in which any combination of the features described above or their equivalents does not depart from the spirit of the disclosure. For example, the above features and (but not limited to) the features disclosed in this disclosure having similar functions are replaced with each other to form the technical solution.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Claims (10)

1. A Remote Procedure Call (RPC) interface test method is characterized by comprising the following steps:

acquiring an entry file corresponding to a service to be tested of the RPC interface, wherein the entry file comprises a plurality of methods of the service to be tested;

parsing the syntax of the entry file to obtain a dependency relationship representation among a plurality of methods contained in the entry file;

acquiring an interface definition file corresponding to a target method in the service to be tested according to the dependency relationship expression, wherein the target method is a method to be tested in a plurality of methods of the service to be tested;

and creating a client object in a memory based on the interface definition file corresponding to the target method, so as to test the target method based on the client object.

2. The method according to claim 1, wherein the dependency representation is an abstract syntax tree, and the obtaining an interface definition file corresponding to a target method in the service to be tested according to the dependency representation comprises:

determining the identification of each dependent file required for executing the target method according to the abstract syntax tree, wherein the abstract syntax tree is generated according to the dependency relationship of each method of the service to be tested;

and acquiring an interface definition file corresponding to the target method according to the identifier of each dependency file.

3. The method according to claim 2, wherein the obtaining the interface definition file corresponding to the target method according to the identifier of the dependency file comprises:

querying the identification of the dependent file from a cache system;

if the identifier is inquired, and the version information of the dependent file is the same as that of the file corresponding to the identifier in the cache system, determining the file corresponding to the identifier in the cache system as an interface definition file corresponding to the target method;

and if the identification is not inquired, requesting a file corresponding to the identification from a GIT (distributed version control system) warehouse, and determining the file corresponding to the requested identification as an interface definition file corresponding to the target method.

4. The method according to claim 3, wherein the obtaining an interface definition file corresponding to the target method according to the identifier of the dependency file further comprises:

if the identifier is inquired and the version information of the dependent file is different from the version information of the file corresponding to the identifier in the cache system, requesting the file corresponding to the identifier from a GIT (trusted information technology) warehouse and determining the requested file corresponding to the identifier as an interface definition file corresponding to the target method;

and updating the file corresponding to the identifier in the cache system according to the file corresponding to the identifier requested from the GIT warehouse.

5. The method according to claim 1, wherein after the step of obtaining the interface definition file corresponding to the target method in the service to be tested, the method further comprises:

and if the interface definition file does not exist in the cache system, storing the interface definition file, the identifier corresponding to the interface definition file and the version information into the cache system.

6. The method of any of claims 3-5, wherein the caching system is a distributed cache based system.

7. A Remote Procedure Call (RPC) interface testing apparatus, the apparatus comprising:

the RPC interface comprises a first acquisition module and a second acquisition module, wherein the first acquisition module is used for acquiring an entry file corresponding to a service to be tested of the RPC interface, and the entry file comprises a plurality of methods of the service to be tested;

the analysis module is used for carrying out syntax analysis on the entry file to obtain a dependency relationship expression among a plurality of methods contained in the entry file;

a second obtaining module, configured to obtain, according to the dependency relationship representation, an interface definition file corresponding to a target method in the service to be tested, where the target method is a method to be tested in the multiple methods of the service to be tested;

and the creating module is used for creating a client object in the memory based on the interface definition file corresponding to the target method so as to test the target method based on the client object.

8. The apparatus of claim 7, wherein the dependency is represented as an abstract syntax tree, and wherein the second obtaining module comprises:

a first determining submodule, configured to determine, according to the abstract syntax tree, an identifier of each dependent file required to execute the target method, where the abstract syntax tree is generated according to a dependency relationship of each method of the service to be tested;

and the obtaining submodule is used for obtaining the interface definition file corresponding to the target method according to the identification of each dependency file.

9. A computer-readable medium, on which a computer program is stored, characterized in that the program, when being executed by processing means, carries out the steps of the method of any one of claims 1 to 6.

10. An electronic device, comprising:

a storage device having a computer program stored thereon;

processing means for executing the computer program in the storage means to carry out the steps of the method according to any one of claims 1 to 6.

Images