CN112905458B - Interface automatic contract testing method and device - Google Patents

Interface automatic contract testing method and device Download PDF

Info

Publication number
CN112905458B
CN112905458B CN202110170928.4A CN202110170928A CN112905458B CN 112905458 B CN112905458 B CN 112905458B CN 202110170928 A CN202110170928 A CN 202110170928A CN 112905458 B CN112905458 B CN 112905458B
Authority
CN
China
Prior art keywords
contract
service
interface
request
interface data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110170928.4A
Other languages
Chinese (zh)
Other versions
CN112905458A (en
Inventor
韩靖
暨光耀
张洁芳
林秋玲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Industrial and Commercial Bank of China Ltd ICBC
Original Assignee
Industrial and Commercial Bank of China Ltd ICBC
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Industrial and Commercial Bank of China Ltd ICBC filed Critical Industrial and Commercial Bank of China Ltd ICBC
Priority to CN202110170928.4A priority Critical patent/CN112905458B/en
Publication of CN112905458A publication Critical patent/CN112905458A/en
Application granted granted Critical
Publication of CN112905458B publication Critical patent/CN112905458B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to computer technology, in particular to an interface automation contract testing method and a testing device, wherein the testing method comprises the following steps: analyzing the contract text according to a preset contract text format to obtain interface data; determining the IP of a service provider to be connected and a port corresponding to the locally subscribed service according to the detected interface full class name in the interface data; establishing connection with the service provider according to the IP and the port corresponding to the service and sending a test request; receiving return information sent by a service provider for the test request; and carrying out contract test according to the test request and the return information. The invention solves the problem that DUBBO service interfaces lack contract test framework support and are difficult to develop, and provides the DUBBO service contract test method which is simple to realize and low in implementation cost.

Description

Interface automatic contract testing method and device
Technical Field
The invention relates to the computer technology, in particular to an automated contract testing method and device for DUBBO interfaces.
Background
Under the micro-service architecture system, each service is mutually dependent through API call. Contract testing is one such behavior: and generating a file containing the input data and the expected return data from the interface consumer perspective, namely a contract file, and according to the contract, the interface provider inputs the input data in the file to obtain a return value and compares the return value with the expected output to finish one-time testing for verifying the communication accuracy of the two parties. The contract file is used as a carrier for changing the interface information, and the contract test ensures that the influence of modification of an interface provider or a consumer on the other party can be perceived.
Dubbo is a high-performance, lightweight Java RPC framework of the aleba open source, and one of the core capabilities is the invocation of the interface-oriented method. Based on this, the framework can abstract both roles of service Provider (Provider) and service Consumer (Consumer). When the service provider starts, registering a release service with the registration center to wait for consumption; when the service consumer starts, the service consumer registers the service consumption with the registration center, and after the IP port of the provider registered on the registration center is obtained, a long connection is established with the address of the provider, further request data is sent to the address, return data is obtained, and the call of a service interface is completed once.
And Dubbo the validity and correctness of the call between the consumer and provider interfaces requires contractual test assurance. In the current use process of Dubbo frames, if a certain service needs to be called, explicit registration is needed in a consumer xml configuration file, and meanwhile, the objects of the interfaces are locally instantiated to perform calling or testing, indiscriminate calling cannot be performed on different Dubbo interfaces, and flexible playback of contract files cannot be realized to perform contract testing.
Disclosure of Invention
The invention relates to a computer technology, in particular to an interface automation contract testing method with simple realization and low implementation cost, which comprises the following steps:
Analyzing the contract text according to a preset contract text format to obtain interface data;
Determining the IP of a service provider to be connected and a port corresponding to the locally subscribed service according to the detected interface full class name in the interface data;
establishing connection with the service provider according to the IP and the port corresponding to the service and sending a test request;
receiving return information sent by a service provider for the test request;
And carrying out contract test according to the test request and the return information.
In an embodiment, the parsing the contract text according to a preset contract text format to obtain interface data includes:
and reading the contract text, and analyzing the key value of the contract text according to the interface data parameters set based on the contract text format to obtain the interface data corresponding to the interface data parameters.
In an embodiment, determining the IP of the service provider to be connected and the port corresponding to the locally subscribed service according to the detected interface full class name in the interface data includes:
traversing all child nodes under the dubbo node of the registry for releasing the service to obtain a target node matched with the full class name of the tested interface;
and acquiring the IP of the service provider and the port corresponding to the service from the service node under the target node.
In an embodiment, the test request includes: request ID and actual output value; the return information includes: response ID and return value;
performing contract testing according to the testing request and the returned information, including:
matching the request ID corresponding to the response ID;
updating the actual output value of the test request corresponding to the matched request ID by using the return value;
Judging whether the updated actual output value is consistent with an expected output value in the interface data;
If the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
The invention also provides an interface automation contract testing device, which comprises:
the analysis module is used for analyzing the contract text according to a preset contract text format to obtain interface data;
The port determining module is used for determining the IP of the service provider to be connected and the port corresponding to the locally subscribed service according to the detected interface full class name in the interface data;
The connection establishment module is used for establishing connection with the service provider according to the IP and the port corresponding to the service and sending a test request;
The information receiving module is used for receiving return information sent by the service provider for the test request;
and the testing module is used for performing contract testing according to the testing request and the return information.
In an embodiment, the parsing module is specifically configured to:
and reading the contract text, and analyzing the key value of the contract text according to the interface data parameters set based on the contract text format to obtain the interface data corresponding to the interface data parameters.
In one embodiment, the port determination module includes:
The node matching unit is used for traversing all child nodes under the dubbo node of the registry for releasing the service to obtain a target node matched with the full class name of the tested interface;
and the information acquisition unit is used for acquiring the IP of the service provider and the port corresponding to the service from the service node under the target node.
In an embodiment, the test request includes: request ID and actual output value; the return information includes: response ID and return value;
the test module comprises:
An information matching unit, configured to match a request ID corresponding to the response ID;
The data updating unit is used for updating the actual output value of the test request corresponding to the matched request ID by using the return value;
The result judging unit is used for judging whether the updated actual output value is consistent with the expected output value in the interface data; if the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
The contract test method of the invention defines a contract text format of DUBBO contract test, and invents a DUBBO contract test mode developed based on the format; finding out the IP and the port of the regulated service by traversing the registration center node, and directly initiating access; the method simulates DUBBO a bottom call principle, connects the IP and the port of the service, directly sends and receives the message conforming to DUBBO coding and decoding rules, realizes the indiscriminate call of the service by a unified method, overcomes the limitation that a DUBBO framework needs to manually add consumer configuration and instantiates a specific called service object to complete the call, and enables DUBBO contract test to be possible.
Drawings
In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a step diagram of an interface automated contract testing method provided by the invention.
Fig. 2 is a DUBBO architecture flow diagram.
Fig. 3 is a block diagram of the interface automated contract testing apparatus provided by the present invention.
Fig. 4 is a block diagram of another interface automated contract testing apparatus provided by the present invention.
Fig. 5 is a block diagram of another interface automated contract testing apparatus provided by the present invention.
Fig. 6 is a block diagram of another interface automated contract testing apparatus provided by the present invention.
Fig. 7 is a schematic structural diagram of an electronic device according to the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
As shown in fig. 1, the automated contract testing method for DUBBO interfaces provided by the present invention includes:
Step S102, analyzing the contract text according to a preset contract text format to obtain interface data. Wherein, before step S102, step S101 may further include: setting a contract text format, wherein the contract text format comprises interface data parameters required by the contract test.
The Interface data parameters in the preset contract text format include the Interface name of the whole class of the tested Interface, the Method name, version number Version, input data of json format, and expected Output of json format, for example, as follows:
Interface＝com.fizzbuzz.test.service.FizzBuzz
Method＝calculate
Version＝1.0.1
Input＝[{“java.lang.Integer”:“15”}]
Output＝fizzbuzz
And step S104, determining the IP of the service provider to be connected and the port corresponding to the locally subscribed service according to the detected interface full class name in the interface data.
Referring to fig. 2, the dubbo architecture can abstract two roles of service Provider (Provider) and service Consumer (Consumer) as well as Registry (Registry), monitoring center (Monitor) that counts the number of service calls and the time of call. The service provider publishes the service provided by the service provider to the registry, and the service consumer subscribes the required service to the registry. The specific calling process comprises the following steps: when the service provider starts, registering the service provided by the service provider with the registration center; when the service consumer starts, subscribing the service required by the consumer to the registration center; the registry returns a list of addresses of service providers to the consumer.
And step S106, establishing connection with the service provider according to the IP and the port corresponding to the service and sending a test request. The test request comprises interface data such as a tested interface full class name, a method name, an interface version number, input parameters, expected output values and the like which are obtained by analyzing contract texts.
Specifically, the method for generating the test request comprises the following steps: first, a Contract class is encapsulated, which includes requestId, interface, method, version, inputParams, expectedOutput, actualOutput attributes, and expectedOutput and actualOutput are checked using the ISSATISFIED method. And then reading the contract text, and analyzing key-value (key-value) according to interface data parameters set based on the contract text format to obtain interface data such as the whole class name of the tested interface, the method name, the interface version number, the input parameters, the expected output value and the like. These data correspond one-to-one to the Contract-class attributes INTERFACE, METHOD, VERSION, INPUTPARAMS, EXPECTEDOUTPUT, respectively. The parsing module 411 generates Contract objects based on Contract classes and interface data, and since interface data corresponding to attributes requestId and actualOutput are not included in interface data, attributes requestId and actualOutput in Contract objects are null at initialization. The Request object is subsequently generated, the Request id is registered again, and the actual return value actualOutput is registered again after the call is completed.
Then, generating a test request according to the interface data, specifically creating a com. Alibaba. Dubbo. Remoting. Exchange. Request object according to Contract objects, including the following steps:
(1) Map object INTERFACEMAP is initialized according to the interface and version attributes of Contract objects, for example as follows:
//eg：com.fizzbuzz.test.service.FizzBuzz
interfaceMap.put(“path”,contract.getInterface())；
interfaceMap.put(“version”,contract.getVersion())；//eg:1.0.1
(2) According to the inputParams attribute of the Contract object, initialize Class <? The > Object PARAMTYPES and Object paramValues are exemplified as follows:
(3) Object rpcInvocation is initialized RpcInvocation with the method attributes of Contract objects, INTERFACEMAP, PARAMTYPES, and paramValues objects, for example as follows:
RpcInvocationrpcInvocation＝new RpcInvocation(contract.getMethod(),paramTypes,
paramValues,interfaceMap)；
(4) The com.alibaba.dubbo.remoting.exchange.request object request is created at rpcInvocation, for example as follows:
Request request＝new Request()；
request.setTwoWay(true)；
request.setData(rpcInvocation)；
(5) The requestId field of the Contract object registers the id attribute of the request object and adds the Contract object to the contact.
contract.setID(req.getId())；
Contract.contracts.add(contract)；
Step S108, receiving return information sent by a service provider for the test request;
and step S110, performing contract test according to the test request and the return information.
The execution subject of the interface automation contract testing method shown in fig. 1 is a service consumption end, and may be a computer, a mobile terminal, and the like.
As can be seen from the flow shown in fig. 1, the automatic interface contract testing method of the embodiment determines the interface data parameters required by the contract test by setting the contract format text, and implements the DUBBO contract testing mode developed based on the format, thereby implementing the indiscriminate calling of the service, overcoming the limitation that the DUBBO framework needs to manually add consumer configuration, instantiating the specific called service object to complete the calling, and enabling the DUBBO contract test to be possible.
In one embodiment, in step S102, the following steps are specifically: and reading the contract text, and analyzing the key value of the contract text according to the interface data parameters set based on the contract text format to obtain the interface data corresponding to the interface data parameters. In this step, firstly, the contract text needs to be read, and based on the interface data parameters set in the format of the contract text, the key value analysis is performed on the contract text, so as to obtain the data corresponding to the interface data parameters, namely the interface data. The interface data includes at least: the interface to be tested is composed of a full class name, a method name, an interface version number, input parameters and expected output values.
In an embodiment, step S104 may specifically include: traversing all child nodes under the dubbo node of the registry for releasing the service to obtain a target node matched with the full class name of the tested interface; and acquiring the IP of the service provider and the port corresponding to the service from the service node under the target node.
The service consumer is connected with a registry of the service provider for publishing the locally subscribed service, and traverses all child nodes under the registry dubbo node to obtain a target node matched with the full class name of the tested interface; and reading the content of the service node under the target node, acquiring the IP of the service provider and the port corresponding to the service, and calling the address list of the service provider. The address list includes information such as IP, port, interface name, method name, etc.
In one embodiment, the test requests in step S106 to step S110 further include a request ID and an actual output value; the return information comprises a response ID and a return value; the contract test according to the test request and the return information specifically comprises the following steps:
matching the request ID corresponding to the response ID;
updating the actual output value of the test request corresponding to the matched request ID by using the return value;
Judging whether the updated actual output value is consistent with an expected output value in the interface data;
If the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
In step S106, the service consumer establishes a connection with the service provider based on the IP of the service provider and the port corresponding to the service determined in step S104 in the foregoing embodiment and sends a test request. The test request comprises a request ID and an actual output value in addition to the full class name, the method name, the interface version number, the input parameters and the expected output value of the tested interface obtained by analyzing the contract text. When the test request is sent, the actual output value is empty, and the service provider needs to be updated after receiving the return information of the service provider.
Specifically, in order to establish a connection with a service provider, an org.jboss.netty.bootstrapping.clientootstrap object ClientBootstrap needs to be created and initialized first. The method comprises the following specific steps:
(1) An org.jboss.netty.channel.socket.nio.nioclientsocketchannel factor object channelFactory is created, for example as follows:
ChannelFactorychannelFactory＝new
NioClientSocketChannelFactory(Executors.newCachedThreadPool(newNamedThreadFactory("NettyClientBoss",true)),
Executors.newCachedThreadPool(new NamedThreadFactory("NettyClientWorker",true)),Constants.DEFAULT_IO_THREADS);
(2) Creating an org.jboss.netty.bootstrap.clientootstrap object with channelFactory objects, and setting an option, wherein KEEPALIVE, TCPNODELAY is true, and connectTimeoutMillis is a default timeout. Examples are as follows:
ClientBootstrap bootstrap＝new ClientBootstrap(channelFactory)；
bootstrap.setOption("keepAlive",true)；
bootstrap.setOption("tcpNoDelay",true)；
bootstrap.setOption("connectTimeoutMillis",Constants.DEFAULT_TIMEOUT)；
(3) The PipelineFactory attribute of the channelFactory object is set as the implementation class of the ChannelPipelineFactory interface, a GETPIPELINE method is realized, a decoder and an encoder are specified to be a codec conforming to the encoding rule of the dubbo protocol, and a handler is a custom com. Examples are as follows:
After the org.jboss.netty.boottrap.clientootstrap object boottrap is created and initialized, the contract execution module can establish connection with the service provider. Specifically, the IP and the port where the service provider is located, that is, url transmitted by the contract preprocessing module 41 are connected by using bootstrapping, and the org. Examples are as follows:
ChannelFuture future＝bootstrap.connect(new
InetSocketAddress(NetUtils.filterLocalHost(url.getHost()),url.getPort()))；
Channel channel＝future.getChannel()；
then, a test request is sent through the established connection channel, specifically: send Dubbo Request to the service provider in channels and wait for a period of time to receive the return information. Examples are as follows:
ChannelFuture future = channel. The// message is a request
future.await(Constants.DEFAULT_TIMEOUT)；
In step S108, the service provider sends a return message for the test request sent by the service consumer, and the service consumer parses the return message to obtain a response ID and a return value.
In step S110, the service consumer identifies a response ID in the return information, matches the request ID of the test request for which the return information is directed, and updates the actual output value in the test request corresponding to the request ID with the return value in the return information; and comparing and judging whether the updated actual output value is consistent with the expected output value. If the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
Specifically, the method comprises the steps of customizing MYHANDLER, realizing a com. Examples are as follows:
It can be understood that when receiving a test request, the service provider can generate a unique corresponding return ID according to the request ID of the test request, where the return ID may be a ciphertext obtained by encrypting the request ID, and when receiving the return information, the service consumer identifies the return ID and decrypts the return ID, thereby obtaining the unique corresponding request ID; the returned ID can also contain the same identification information as the request ID of the test request, and the service consumer can be matched with the unique corresponding request ID through the identification information; the return ID may also be the same as the request ID. In summary, it is sufficient to match a unique request ID based on the return ID.
The invention provides an automatic contract testing method of a DUBBO interface of a DUBBO service contract testing method, which is simple to realize and low in implementation cost, and solves the problems that a DUBBO service interface lacks support of a contract testing framework and is difficult to develop. The contract test method defines a contract text format of DUBBO contract test, invents a DUBBO contract test mode developed based on the format, realizes the indiscriminate calling of services by a unified method, overcomes the limitation that a DUBBO framework needs to manually add consumer configuration and instantiates a specific called service object to complete the calling, and enables DUBBO contract test to be possible.
Based on the same inventive concept, the embodiment of the present application further provides an interface automation contract testing device, which can be used to implement the method described in the above embodiment, as described in the following embodiment. Because the principle of the interface automation contract testing device for solving the problem is similar to that of the interface automation contract testing method, the implementation of the interface automation contract testing device can refer to the implementation of the interface automation contract testing method, and the repetition is not repeated. As used below, the term "unit" or "module" may be a combination of software and/or hardware that implements the intended function. While the system described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.
The invention also provides an interface automation contract testing device, as shown in fig. 3, the system comprises:
The parsing module 31 is configured to parse the contract text according to a preset contract text format to obtain interface data.
And the port determining module 32 is configured to determine, according to the full class name of the tested interface in the interface data, an IP of the service provider to be connected and a port corresponding to the locally subscribed service.
And the connection establishment module 33 is configured to establish a connection with the service provider according to the IP and the port corresponding to the service and send a test request.
And the information receiving module 34 is configured to receive return information sent by the service provider for the test request. The specific steps are as follows: after the connection establishment module 33 sends the test request through the established connection channel, it waits for a period of time, and the information receiving module 34 receives the return information.
And the testing module 35 is configured to perform a contract test with the return information according to the test request.
In one embodiment, the parsing module 31 is specifically configured to:
and reading the contract text, and analyzing the key value of the contract text according to the interface data parameters set based on the contract text format to obtain the interface data corresponding to the interface data parameters.
In an embodiment, as shown in fig. 4, the port determining module 32 is specifically configured to determine an IP of a service provider to be connected and a port corresponding to a service subscribed by a service consumer, where the port determining module 32 includes:
The node matching unit 321 is configured to subscribe a service required by the user to the registry, specifically connect a zookeeper of the service registration, traverse all sub-nodes under the dubbo node in the zookeeper, and each sub-node corresponds to a service name; matching the Interface to a target node corresponding to the subscribed service according to the full class name of the tested Interface;
The information obtaining unit 322 is configured to read the content of the service node providers under the target node, obtain the IP of the service provider and the port corresponding to the service from the content, and call the address list of the service provider, that is, the url data packet. An example of an address list for a service provider may be referred to in fig. 3, among others.
The method and the device have the advantages that the sequence of generating the test request and acquiring the IP of the service provider and the port corresponding to the locally subscribed service can be exchanged, namely, the test request can be generated first, then the IP and the port of the service provider can be acquired, and the IP and the port of the service provider can be acquired first to generate the test request.
The test Request corresponds to a Request object in this example, and the IP of the service provider and the port corresponding to the service correspond to an address list of the service provider in this example, that is, url data packet.
In one embodiment, as shown in fig. 5 and 6, the test module 35 includes:
and an information matching unit 351, configured to match the request ID corresponding to the response ID.
And the data updating unit 352 is configured to update the actual output value of the test request corresponding to the matched request ID by using the return value.
It can be understood that when receiving a test request, the service provider can generate a unique corresponding return ID according to the request ID of the test request, where the return ID may be a ciphertext obtained by encrypting the request ID, and when receiving the return information, the service consumer identifies the return ID and decrypts the return ID, thereby obtaining the unique corresponding request ID; the returned ID can also contain the same identification information as the request ID of the test request, and the service consumer can be matched with the unique corresponding request ID through the identification information; the return ID may also be the same as the request ID. In summary, it is sufficient to match a unique request ID based on the return ID.
A result judging unit 353 for judging whether the updated actual output value is consistent with the expected output value in the interface data; if the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
Specifically, the result determination unit 353 compares and determines whether expectedOutput and actrualOutput in the updated Contract object agree, and if so, the contract test passes, and otherwise the contract test does not pass.
The invention solves the problem that DUBBO service interfaces lack contract test framework support and are difficult to develop, and provides the DUBBO service contract test device which is simple to realize and low in implementation cost. The contract testing device can realize the functions of defining the contract text format of DUBBO contract testing and carrying out DUBBO contract testing based on the format; finding out the IP and the port of the regulated service by traversing the registration center node, and directly initiating access; the method simulates DUBBO a bottom call principle, connects the IP and the port of the service, directly sends and receives the message conforming to DUBBO coding and decoding rules, realizes the indiscriminate call of the service by a unified method, overcomes the limitation that a DUBBO framework needs to manually add consumer configuration and instantiates a specific called service object to complete the call, and enables DUBBO contract test to be possible.
The embodiment of the present application further provides a specific implementation manner of an electronic device including the interface automated contract testing apparatus in the foregoing embodiment, referring to fig. 7, and the electronic device 700 specifically includes:
A central processing unit (processor) 710, a memory (memory) 720, communication modules (Communications) 730, an input unit 740, an output unit 750, and a power supply 760.
The memory (memory) 720, communication module (communication) 730, input unit 740, output unit 750, and power supply 760 are respectively connected to the central processing unit (processor) 710. The central processor 710 may call a computer program stored in the memory 720, and when the central processor 710 executes the computer program, all the steps in the interface automation contract testing method in the above embodiment are implemented.
Embodiments of the present application also provide a computer storage medium storing a computer program executable by a processor. The computer program, when executed by the processor, implements any of the interface automated contract testing methods provided by the present application.
It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the present specification embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description embodiments may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the embodiments of the present specification.
In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction. The foregoing is merely an example of an embodiment of the present disclosure and is not intended to limit the embodiment of the present disclosure. Various modifications and variations of the illustrative embodiments will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the embodiments of the present specification, should be included in the scope of the present specification as defined in the claims.

Claims (10)

1. An interface automated contract testing method, for use with a service consumer, the method comprising:
Analyzing the contract text according to a preset contract text format to obtain interface data; the contract text format comprises interface data parameters required by contract test, and the interface data corresponds to the interface data parameters;
Determining the IP of a service provider to be connected and a port corresponding to the locally subscribed service according to the tested interface full class name in the interface data and the dubbo node of the registry; the service provider issues the service in the registry, the dubbo node comprises a target node matched with the full class name of the tested interface, and a service node under the target node comprises the IP and a port corresponding to the service;
establishing connection with the service provider according to the IP and the port corresponding to the service and sending a test request;
receiving return information sent by a service provider for the test request;
And carrying out contract test according to the test request and the return information.
2. The method for automatically testing an interface contract according to claim 1, wherein the parsing the contract text according to a preset contract text format to obtain interface data includes:
and reading the contract text, and analyzing the key value of the contract text according to the interface data parameters set based on the contract text format to obtain the interface data corresponding to the interface data parameters.
3. The method of claim 2, wherein determining the IP of the service provider to be connected and the port corresponding to the locally subscribed service according to the full class name of the tested interface in the interface data and the dubbo node of the registry comprises:
traversing all child nodes under the dubbo node of the registry for releasing the service to obtain a target node matched with the full class name of the tested interface;
and acquiring the IP of the service provider and the port corresponding to the service from the service node under the target node.
4. A method of automated contract testing of interfaces according to any of claims 2-3, wherein the test request includes: request ID and actual output value; the return information includes: response ID and return value;
performing contract testing according to the testing request and the returned information, including:
matching the request ID corresponding to the response ID;
updating the actual output value of the test request corresponding to the matched request ID by using the return value;
Judging whether the updated actual output value is consistent with an expected output value in the interface data;
If the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
5. An interface automated contract testing apparatus configured at a service consumer, the apparatus comprising:
the analysis module is used for analyzing the contract text according to a preset contract text format to obtain interface data; the contract text format comprises interface data parameters required by contract test, and the interface data corresponds to the interface data parameters;
the port determining module is used for determining the IP of the service provider to be connected and the port corresponding to the locally subscribed service according to the full class name of the tested interface in the interface data and the dubbo node of the registry; the service provider issues the service in the registry, the dubbo node comprises a target node matched with the full class name of the tested interface, and a service node under the target node comprises the IP and a port corresponding to the service;
The connection establishment module is used for establishing connection with the service provider according to the IP and the port corresponding to the service and sending a test request;
The information receiving module is used for receiving return information sent by the service provider for the test request;
and the testing module is used for performing contract testing according to the testing request and the return information.
6. The interface automation contract testing device of claim 5, wherein the parsing module is specifically configured to:
and reading the contract text, and analyzing the key value of the contract text according to the interface data parameters set based on the contract text format to obtain the interface data corresponding to the interface data parameters.
7. The interface automation contract testing device of claim 6, wherein the port determination module comprises:
The node matching unit is used for traversing all child nodes under the dubbo node of the registry for releasing the service to obtain a target node matched with the full class name of the tested interface;
and the information acquisition unit is used for acquiring the IP of the service provider and the port corresponding to the service from the service node under the target node.
8. The interface automated contract testing apparatus of any one of claims 6-7, wherein the test request includes: request ID and actual output value; the return information includes: response ID and return value;
the test module comprises:
An information matching unit, configured to match a request ID corresponding to the response ID;
The data updating unit is used for updating the actual output value of the test request corresponding to the matched request ID by using the return value;
The result judging unit is used for judging whether the updated actual output value is consistent with the expected output value in the interface data; if the contract tests are consistent, prompting that the contract tests are passed; if the contract tests are inconsistent, prompting that the contract tests are not passed.
9. An electronic device, comprising:
A central processor, a memory, a communication module, the central processor being operable to invoke a computer program stored in the memory, the central processor implementing the interface automation contract testing method according to any of claims 1-4 when executing the computer program.
10. A computer storage medium storing a computer program, wherein the computer program when executed by a processor implements the interface automation contract testing method according to any one of claims 1-4.
CN202110170928.4A 2021-02-08 2021-02-08 Interface automatic contract testing method and device Active CN112905458B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110170928.4A CN112905458B (en) 2021-02-08 2021-02-08 Interface automatic contract testing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110170928.4A CN112905458B (en) 2021-02-08 2021-02-08 Interface automatic contract testing method and device

Publications (2)

Publication Number Publication Date
CN112905458A CN112905458A (en) 2021-06-04
CN112905458B true CN112905458B (en) 2024-05-07

Family

ID=76123999

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110170928.4A Active CN112905458B (en) 2021-02-08 2021-02-08 Interface automatic contract testing method and device

Country Status (1)

Country Link
CN (1) CN112905458B (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103064788A (en) * 2012-12-24 2013-04-24 清华大学 Web service modeling and test method based on interface semantic contract model
CN108694120A (en) * 2017-04-12 2018-10-23 北京京东尚科信息技术有限公司 The method and apparatus of testing service component
CN110764996A (en) * 2019-09-06 2020-02-07 平安普惠企业管理有限公司 Contract testing method, system, storage medium and terminal equipment
CN110888800A (en) * 2019-10-18 2020-03-17 平安普惠企业管理有限公司 Service interaction function test method, device, storage medium and test system
CN111159025A (en) * 2019-12-23 2020-05-15 武汉联影医疗科技有限公司 Application program interface testing method and device, computer equipment and storage medium
CN111459801A (en) * 2020-03-09 2020-07-28 江苏苏宁物流有限公司 RSF remote service interface function test method, module, computer equipment and storage medium

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103064788A (en) * 2012-12-24 2013-04-24 清华大学 Web service modeling and test method based on interface semantic contract model
CN108694120A (en) * 2017-04-12 2018-10-23 北京京东尚科信息技术有限公司 The method and apparatus of testing service component
CN110764996A (en) * 2019-09-06 2020-02-07 平安普惠企业管理有限公司 Contract testing method, system, storage medium and terminal equipment
CN110888800A (en) * 2019-10-18 2020-03-17 平安普惠企业管理有限公司 Service interaction function test method, device, storage medium and test system
CN111159025A (en) * 2019-12-23 2020-05-15 武汉联影医疗科技有限公司 Application program interface testing method and device, computer equipment and storage medium
CN111459801A (en) * 2020-03-09 2020-07-28 江苏苏宁物流有限公司 RSF remote service interface function test method, module, computer equipment and storage medium

Also Published As

Publication number Publication date
CN112905458A (en) 2021-06-04

Similar Documents

Publication Publication Date Title
US10999380B2 (en) Method and apparatus of interworking M2M and IoT devices and applications with different service layers
US8656417B2 (en) Interface for telecommunication services using uniform resource identifiers
US20160227346A1 (en) Service Layer Resource Propagation Across Domains
Wu et al. OneM2M-based IoT protocol integration
KR20190065372A (en) Service layer resource management for general interworking and scalability
JP2007511018A (en) Method and apparatus for composing software
US8707329B2 (en) Open framework system for heterogeneous computing and service integration
WO2023142911A1 (en) Service processing method and device
US20240089343A1 (en) Service layer-based methods to enable efficient analytics of iot data
US20190349267A1 (en) Intelligent information adapter generation for service management
US8782470B2 (en) Generation of test data for web service-based test automation and semi-automated test data categorization
CN105871911A (en) Service calling engine, method and system
KR20190061060A (en) Profile-based content and services
CN112905458B (en) Interface automatic contract testing method and device
CN113806216A (en) Interface test method, device, medium and equipment
CN116233217B (en) Page jump method and device based on route, electronic equipment and storage medium
WO2023029881A1 (en) Device control method and apparatus
CN107911442B (en) Receiving response interface interaction method and device, computer equipment and storage medium
CN113709177B (en) Method for processing message and external call gateway
Zilhão et al. A Modular Tool for Benchmarking loT Publish-Subscribe Middleware
CN115456446A (en) Configuration-based service flow processing method and device
CN110262912B (en) Calling method and device for procedure call gRPC
CN114327823A (en) Method, system, terminal and storage medium for calling resources of micro-service cluster
Michlmayr et al. End-to-end support for QoS-aware service selection, invocation and mediation in VRESCo
Johansson et al. Comparative Study of REST and gRPC for Microservices in Established Software Architectures

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant