CN117539746A - Interface automatic test method, system, electronic equipment and storage medium - Google Patents
Interface automatic test method, system, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN117539746A CN117539746A CN202311183322.XA CN202311183322A CN117539746A CN 117539746 A CN117539746 A CN 117539746A CN 202311183322 A CN202311183322 A CN 202311183322A CN 117539746 A CN117539746 A CN 117539746A
- Authority
- CN
- China
- Prior art keywords
- test
- interface
- target
- initial
- micro
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000010998 test method Methods 0.000 title claims abstract description 33
- 238000012360 testing method Methods 0.000 claims abstract description 473
- 238000013101 initial test Methods 0.000 claims abstract description 164
- 238000000034 method Methods 0.000 claims abstract description 35
- 230000004044 response Effects 0.000 claims description 25
- 238000004590 computer program Methods 0.000 claims description 12
- 238000004806 packaging method and process Methods 0.000 claims description 12
- 230000008569 process Effects 0.000 claims description 7
- 238000012423 maintenance Methods 0.000 abstract description 10
- 238000010586 diagram Methods 0.000 description 12
- 239000000243 solution Substances 0.000 description 11
- 238000004891 communication Methods 0.000 description 10
- 238000011161 development Methods 0.000 description 6
- 230000002159 abnormal effect Effects 0.000 description 4
- 230000008878 coupling Effects 0.000 description 4
- 238000010168 coupling process Methods 0.000 description 4
- 238000005859 coupling reaction Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The embodiment of the application provides an interface automatic test method, an interface automatic test system, electronic equipment and a storage medium, wherein the method comprises the following steps: acquiring and responding to an interface test request, and determining at least one target test interface of a target micro-service program from a preset test scenario class; if the target test interface is located in one of the preset initial test interface sets, determining a corresponding target test code class for the target test interface from a plurality of preset initial test code classes, wherein the preset initial test interface set comprises a plurality of initial test interfaces, and each initial test code class is used for testing the initial test interfaces corresponding to the initial test interface; injecting the target test code class into the test script to obtain a target test script; and automatically testing the target micro-service program according to the target test script and preset test data to obtain a test result. The method and the device can reduce code redundancy of the micro service interface test and reduce maintenance difficulty of the micro service interface test.
Description
Technical Field
The present disclosure relates to the field of interface testing technologies, and in particular, to an interface automation testing method, system, electronic device, and storage medium.
Background
With the continuous development of the internet and the continuous improvement of the demands of people for service functions, the conventional single architecture cannot meet various complex application programs, so that the application of the micro-service architecture is generated and becomes a mainstream architecture gradually. Before the development of a micro-service architecture is completed, various aspects of tests need to be carried out on the micro-service architecture, and the micro-service interface test is one of the very important tests, and defects (Bug) can be exposed in advance through the interface test, so that the development and the generation of the micro-service architecture are quickened.
The micro service architecture includes a plurality of micro services, and usually, for the interface test of each different micro service, one interface test case needs to be written, however, different micro services may include the same interface, repeated interface test code writing makes the micro service interface test case redundant, and once the micro service interface is changed, a large number of interface cases need to be modified at the same time, which causes difficulty in maintenance of the micro service interface test.
Disclosure of Invention
The main purpose of the embodiments of the present application is to provide an automatic testing method, system, electronic device and storage medium for interfaces, which can reduce code redundancy of micro service interface testing and reduce maintenance difficulty of micro service interface testing.
To achieve the above object, a first aspect of an embodiment of the present application proposes an interface automation test method, including: acquiring an interface test request, and determining at least one target test interface of a target micro-service program from a preset test script class in response to the interface test request; if the target test interface is located in one of preset initial test interface sets, determining a corresponding target test code class for the target test interface from a plurality of preset initial test code classes, wherein the preset initial test interface set comprises a plurality of initial test interfaces, and each initial test code class is used for testing the initial test interfaces corresponding to the initial test interfaces one by one; injecting the target test code class into a test script corresponding to the target micro-service program to obtain a target test script; and automatically testing the target micro-service program according to the target test script and preset test data to obtain a test result.
In some embodiments, the method is applied to a client, the client is in communication connection with a server, and the server runs the target micro-service program; the automatic test is carried out on the target micro-service program according to the target test script and preset test data to obtain a test result, and the automatic test comprises the following steps: acquiring a test execution instruction; responding to the test execution instruction, executing the target test script, and packaging corresponding preset test data into a test request of at least one target test interface based on the target test code class in the execution process, and sending the test request to the server side; and receiving response data returned by the server, asserting the response data based on the target test code class, and obtaining a test result according to the asserting result.
In some embodiments, the method further comprises: if the target test interface is not in the preset initial test interface set, configuring a corresponding new test code class for the target test interface, and updating the initial test code class according to the new test code class; and injecting the new test code class into the test script corresponding to the target micro-service program, and automatically testing the target micro-service program based on the test script.
In some embodiments, the determining at least one target test interface of the target micro-service program from the preset test scenario class includes: analyzing the test script class to obtain a micro-service name and an interface name; determining a target micro service program according to the micro service name; and determining a target test interface of the target micro-service program according to the interface name.
In some embodiments, the initial test code class is obtained by the steps comprising: acquiring the interface name of each initial test interface, and determining that the initial test code class corresponding to the same interface name is the same; acquiring interface parameters of an initial test interface corresponding to the same interface name; and generating an initial test code class according to the interface parameters.
In some embodiments, the generating an initial test code class according to the interface parameters includes: acquiring at least one initial request, packaging tool and assertion statement; and packaging the interface parameters, the initial request and the assertion statement by using the packaging tool to obtain an initial test code class, wherein the initial test code class is used for injecting a corresponding test script.
In some embodiments, the asserting the response data based on the target test code class, obtaining a test result according to the asserting result, includes: acquiring a target expected result; obtaining an assertion result according to the response data and the target test code class; and comparing the assertion result with the target expected result to obtain a test result.
To achieve the above object, a second aspect of the embodiments of the present application proposes an interface automation test system, the system comprising: the system comprises an acquisition module, a test module and a test module, wherein the acquisition module is used for acquiring an interface test request, and determining at least one target test interface of a target micro-service program from a preset test script class in response to the interface test request; the determining module is used for determining a target test code class corresponding to the target test interface from a plurality of preset initial test code classes if the target test interface is positioned in one of preset initial test interface sets, wherein the preset initial test interface set comprises a plurality of initial test interfaces, and each initial test code class is used for testing the initial test interfaces corresponding to the initial test interface; the test module is used for injecting the target test code class into a test script corresponding to the target micro-service program to obtain a target test script; and the result module is used for automatically testing the target micro-service program according to the target test script and preset test data so as to obtain a test result.
To achieve the above object, a third aspect of the embodiments of the present application provides an electronic device, where the electronic device includes a memory and a processor, where the memory stores a computer program, and the processor implements the method for automatically testing an interface according to the embodiment of the first aspect when the processor executes the computer program.
To achieve the above object, a fourth aspect of the embodiments of the present application proposes a storage medium, which is a computer-readable storage medium, storing a computer program, where the computer program is executed by a processor to implement the method for automated testing of an interface according to the embodiment of the first aspect.
The interface automatic test method, the system, the electronic equipment and the storage medium provided by the embodiment of the application can be applied to the interface automatic test system. The interface automatic test method comprises the following steps: acquiring an interface test request, and determining at least one target test interface of a target micro-service program from a preset test script class in response to the interface test request; if the target test interface is located in a preset initial test interface set, determining a corresponding target test code class for the target test interface from a plurality of preset initial test code classes, wherein the preset initial test interface set comprises a plurality of initial test interfaces, each initial test code class is used for testing the initial test interfaces corresponding to the initial test interface, namely, each initial test interface is preset with a corresponding initial test code class, and the initial test code classes corresponding to the same initial test interfaces are the same, so that redundancy of the same code is avoided, and when the same initial test interfaces generate test change and code maintenance is needed, only one test code class is needed to be maintained, and the difficulty of code maintenance is reduced; then, the target test code class is injected into a test script corresponding to the target micro-service program to obtain a target test script; and automatically testing the target micro-service program according to the target test script and preset test data to obtain a test result. It can be understood that the test data and the test script are separated, and when the test is executed, the test data and the test script are combined, so that the redundancy of the test code is further reduced.
Drawings
Fig. 1 is an application scenario schematic diagram of an interface automation test system provided in an embodiment of the present application;
FIG. 2 is an alternative flow chart of an interface automation test method provided by an embodiment of the present application;
FIG. 3 is a schematic diagram of a test scenario of an automated interface testing method according to an embodiment of the present disclosure;
fig. 4 is a schematic diagram of a test service scenario of the interface automation test method provided in the embodiment of the present application;
FIG. 5 is a schematic diagram of a conventional automated test method for an automated test method for interfaces according to an embodiment of the present application;
FIG. 6 is a schematic diagram of an alternative automated interface test method provided by an embodiment of the present application;
FIG. 7 is a flow chart of one implementation of step S104 in FIG. 2;
FIG. 8 is another alternative flow chart of an interface automated test method provided by an embodiment of the present application;
FIG. 9 is a flow chart of one implementation of step S101 in FIG. 2;
FIG. 10 is a flow chart of yet another alternative method for automated testing of interfaces provided by embodiments of the present application;
FIG. 11 is a flow chart of one implementation of step S503 in FIG. 10;
FIG. 12 is a flow chart of one implementation of step S203 in FIG. 7;
FIG. 13 is a functional block diagram of an automated test of interfaces provided by an embodiment of the present application;
Fig. 14 is a schematic hardware structure of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.
It should be noted that although functional block division is performed in a device diagram and a logic sequence is shown in a flowchart, in some cases, the steps shown or described may be performed in a different order than the block division in the device, or in the flowchart. The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of the present application only and is not intended to be limiting of the present application.
First, several nouns referred to in this application are parsed:
Micro services, also known as micro service architecture, is an architecture and organization method for software development. It divides a single application into a group of small services, and the services are coordinated and matched with each other to provide the final value for the user. Each service runs in its independent process, and the services communicate with each other using a lightweight communication mechanism (typically HTTP-based RESTful API), it being understood that the features of the micro-service architecture enable it to support rapid, frequent and reliable delivery of large complex applications.
Interface test, wherein, the interface is a series of declarations of the method, is a set of method characteristics, is a specification and definition of a group of behaviors, and is used for external data interaction with the interface according to a agreed format. The interface test is a test for testing interfaces between components of a system, and is mainly used for detecting interaction points between external systems and between subsystems, wherein the key points of the interface test are to check the exchange, transmission, control and management processes of data, the mutual dependence relationship between the systems and the like, and simulate the sending and receiving of http requests through a tool.
With the continuous development of the internet and the continuous improvement of the demands of people for service functions, the conventional single architecture cannot meet various complex application programs, so that the application of the micro-service architecture is generated and becomes a mainstream architecture gradually. Before the development of a micro-service architecture is completed, various aspects of tests need to be carried out on the micro-service architecture, and the micro-service interface test is one of the very important tests, and defects (Bug) can be exposed in advance through the interface test, so that the development and the generation of the micro-service architecture are quickened.
The micro service architecture includes a plurality of micro services, and usually, for the interface test of each different micro service, one interface test case needs to be written, however, different micro services may include the same interface, repeated interface test code writing makes the micro service interface test case redundant, and once the micro service interface is changed, a large number of interface cases need to be modified at the same time, which causes difficulty in maintenance of the micro service interface test.
Based on the above, the interface automation test method, the system, the electronic device and the storage medium provided by the embodiment of the application, the interface automation test method can be applied to the interface automation test system. The interface automatic test method comprises the following steps: acquiring an interface test request, and determining at least one target test interface of a target micro-service program from a preset test script class in response to the interface test request; if the target test interface is located in a preset initial test interface set, determining a corresponding target test code class for the target test interface from a plurality of preset initial test code classes, wherein the preset initial test interface set comprises a plurality of initial test interfaces, each initial test code class is used for testing the initial test interfaces corresponding to the initial test interface, namely, each initial test interface is preset with a corresponding initial test code class, and the initial test code classes corresponding to the same initial test interfaces are the same, so that redundancy of the same code is avoided, and when the same initial test interfaces generate test change and code maintenance is needed, only one test code class is needed to be maintained, and the difficulty of code maintenance is reduced; then, the target test code class is injected into a test script corresponding to the target micro-service program to obtain a target test script; and automatically testing the target micro-service program according to the target test script and preset test data to obtain a test result. It can be understood that the test data and the test script are separated, and when the test is executed, the test data and the test script are combined, so that the redundancy of the test code is further reduced.
The embodiment of the application provides an interface automation test method, an interface automation test system, an electronic device and a storage medium, and specifically, the following embodiment is used for explaining, and first describes the interface automation test system in the embodiment of the application.
As shown in fig. 1, fig. 1 is a schematic application scenario of an interface automation test system provided in an embodiment of the present application, where an interface automation test system includes a client 11 and a server 12, where the server 12 includes a plurality of micro-service programs, and the client 11 can determine a target micro-service program from the plurality of micro-service programs of the server 12, and can receive response data returned by the server 12, and execute, by executing, on a target test interface, an interface automation test method provided in the present application to obtain a test result. Alternatively, the client 11 includes a plurality of micro-service programs, and at this time, the interface automation test method proposed in the present application is executed on the client 11 to obtain a test result. It should be noted that, the number of server sides 12 communicatively connected to the client 11 may be specifically set according to the actual needs of the operator, and the embodiment of the present application is not specifically limited herein.
Based on this, the interface automation test method in the embodiment of the present application may be illustrated by the following embodiment.
In the embodiments of the present application, when related processing is required to be performed according to related interface data, such as interface information, interface behavior data, interface history data, and the like, permission or consent of the related user is obtained first. Moreover, the collection, use, processing, etc. of such data would comply with relevant laws and regulations. In addition, when the embodiment of the application needs to acquire the sensitive personal information of the relevant user, the independent permission or independent consent of the relevant user is acquired through a popup window or a jump to a confirmation page or the like, and after the independent permission or independent consent of the relevant user is explicitly acquired, the necessary interface related data for enabling the embodiment of the application to normally operate is acquired.
As shown in fig. 2, fig. 2 is an optional flowchart of an interface automation test method provided in an embodiment of the present application, where the method in fig. 2 may include, but is not limited to, steps S101 to S104.
Step S101, an interface test request is obtained, and at least one target test interface of a target micro-service program is determined from a preset test script class in response to the interface test request;
In some embodiments, a client is communicatively coupled to a server that runs a target microservice program and a test tool that tests the target microservice program runs on the client.
In some embodiments, the get interface test request may be obtained from a test instruction issued by the test tool. For example, if the interface test of the target micro-service program is performed on the test tool IDEA, a test instruction may be issued by clicking a start execution button of the IDEA to obtain an interface test request at the client. When the client acquires the interface test request, the target test interface of the target micro-service program is started to be tested.
In some embodiments, after the interface test request is obtained, the tester may input relevant information of the target micro-service program to determine a test scenario class corresponding to the target micro-service program.
In some embodiments, the relevant test information of the target micro-service program may be a micro-service name or a micro-service serial number, etc. Illustratively, if the input micro-service serial number is 001, it may be determined that the target micro-service program is a commodity micro-service, and a commodity test scenario class corresponding to the commodity micro-service is determined from at least one preset test scenario class.
In some embodiments, the test scenario class may be obtained by configuring a test class name of a target test code class required by the corresponding micro service, where the test class name may be obtained by input of a related operator, or may be obtained by reading data according to a pre-stored test scenario class of each micro service.
In some embodiments, the test scenario class may include one or more target micro-services to be tested. When the test script class characterizes one target micro-service program, the client can determine a plurality of target micro-service programs to be tested by receiving the test script class one by one; when the test scenario class characterizes the plurality of target micro-service programs, the client may determine the plurality of target micro-service programs to be tested by parsing the test scenario class.
Fig. 3 is a schematic diagram of a test scenario of an automatic interface testing method according to an embodiment of the present application, which includes two test scenario classes, that is, target microservices to be tested, one is a commodity microservice test scenario class (Commodity Microservices), the other is an order microservice test scenario class (Order Microservices), and taking the commodity microservice test scenario class as an example, and further includes a plurality of microservice test interfaces OpenService (commodit), getServiceInfo (commodit), etc., it is determined that OpenService (commodit), getServiceInfo (commodit) are target test interfaces corresponding to the commodity microservice test scenario class. In particular, the order microservice test script class also comprises a special interface GetOrderInfo, wherein the special interface indicates that the special interface is not matched with any initial test interface, and a new test code class needs to be generated.
In some embodiments, a sequence exists between the target microservices corresponding to the test scenario, and a sequence exists between the target test interfaces in the target microservices, so that the automatic test of the interfaces is executed according to the sequences represented by the target microservices and the target test interfaces.
Step S102, if the target test interface is located in a preset initial test interface set, determining a corresponding target test code class for the target test interface from a plurality of preset initial test code classes, wherein the preset initial test interface set comprises a plurality of initial test interfaces, and each initial test code class is used for testing the initial test interfaces corresponding to the initial test interfaces one by one;
in some embodiments, the set of initial test interfaces includes at least one initial test interface, and the same initial test interface may be located in only one target microservice program, or may be located in a plurality of different target microservices programs. For the latter case described above, the target microserver program a illustratively includes a target test interface a, and the target microserver program B also includes a target test interface a, the visual test interface a corresponding to the initial test interface a in the initial test interface set.
In some embodiments, the initial test interfaces included in the initial test interface set and the target micro-service program corresponding to each initial test interface may be set according to actual situations, which is not limited in this embodiment.
In some embodiments, before the interface test starts, the related operator may preset an initial test interface according to the specific situation of the micro service, and set the same preset initial test code class for the same initial test interface, that is, only one initial test code class needs to be written for the same initial test interface.
Illustratively, the micro service a includes interfaces a, B, c, the micro service B includes interfaces a, B, d, and the interface a in the micro service a and the interface a in the micro service B are the same interfaces, and the interface B in the micro service a and the interface B in the micro service B are the same interfaces, so that the initial test interface may be determined to be the interface Aa, ab, ac, ba, bb, bd, and the interface Aa and the interface Ba correspond to the same initial test code i, and the interface Ab and the interface Bb correspond to the same initial test code ii, and then the initial test codes may be obtained to be the initial test codes i, ii, iv, and iv.
In some embodiments, after the target test code class corresponding to the target micro-service program is obtained, relevant parameter setting may be performed for the target test code class, where the relevant parameter may be a test environment parameter or test data corresponding to a test script.
It should be noted that, since only one initial test code class is required to be written for multiple identical initial test interfaces, the redundancy of codes is greatly reduced, and when the initial test code class needs to be changed, only one initial test code class is required to be modified, and the codes of each identical initial test interface are not required to be modified, so that the difficulty of code maintenance is greatly reduced.
Step S103, injecting the target test code class into the test script corresponding to the target micro-service program to obtain a target test script;
in some embodiments, each target micro-service program includes a corresponding test script, a target test code is injected into the test script, and test data is configured for the test script, so that an automated test of the target micro-service program can be executed, and a test result is obtained.
In some embodiments, because the parameter transmission format and the parameter return format of the same initial test interface are fixed, a test script with uniform format can be set for each target micro service program according to the parameter transmission format and the parameter return format, so that the repeated writing of the same test script by related operators is avoided, and the efficiency of testing the micro service interface is improved.
Step S104, automatically testing the target micro-service program according to the target test script and preset test data to obtain a test result.
In some embodiments, the test data is separated from the initial test code class, and the extracted test data may be placed in a data warehouse, such as an Excel data table or a related database, or the test data may be deposited using a separate test class.
In some embodiments, when executing the target test code class, the corresponding test data is configured for the target test code class to implement the interface test and obtain the test result.
In some embodiments, the types of test data may be multiple, for example, the test data may include normal data, boundary data, and abnormal data, and multiple different test data may be generated according to the execution logic of the target test code class, where the boundary data is critical value data, the normal data is data within a critical value, and the abnormal data is data outside a critical value, and multiple different test data may be configured for one target test code class to test multiple different data conditions.
It should be noted that the type of the test data and the specific data value may be set according to the specific situation, and the embodiment of the present application is only described in a preferred situation, and is not limited in particular.
As shown in fig. 4, fig. 4 is a schematic diagram of a test service scenario of an interface automation test method provided in an embodiment of the present application, where three micro services 1, 2 and 3 to be tested are included, and in the example of the micro service 1, a plurality of target test interfaces 1 to x to be tested are included, and a plurality of test scenarios to be tested exist in each target test interface, based on which, a conventional interface test method and an interface automation test method provided in the present application are respectively shown in fig. 5 and 6. Fig. 5 is a schematic diagram of a conventional automated test of the method for testing an interface according to the embodiment of the present application, where for the test scenario in fig. 4, the conventional automated test performs code writing for each scenario under each interface, that is, even if the same interface exists in each micro service, multiple sets of codes need to be written, thereby creating redundancy of test codes, and, if the relevant change occurs in the interface 1, all the test codes about the interface 1 of the micro service 1 to the micro service 3 need to be modified, which makes maintenance of the codes difficult. Fig. 6 is an optional automatic interface test schematic diagram of an automatic interface test method provided in the embodiment of the present application, where initial test codes of multiple identical interfaces are written as one, and as class1 in fig. 6 corresponds to the tested interface 1 in fig. 4, since both micro service 1 and micro service 2 need to test interface 1, only the micro service 1 and micro service 2 need to be configured with a target test code class1, and the target test code class is injected into a preset test script, and then, according to configuration of test data, a test case after specific parameter instantiation is obtained, and the test case is executed, so as to implement automatic interface test.
It should be noted that, the conventional automatic interface test mixes the object test code class, the test data and the test script together, resulting in too strong coupling of the test case, so that when testing a plurality of object test interfaces, only a plurality of sets of test codes can be repeatedly written, thereby causing redundancy of the test codes. Compared with the traditional interface automation test, the method separates the target test code class, the test data and the test script, determines the target test code class according to the script class, writes only one set of initial test code class for the same initial test interface, determines the target test code class from a plurality of initial test code classes, injects the target test code class into the test script, finally realizes the automation test of the interface through the parameter instantiation of the test data, and can be compared and known through the scene examples.
As shown in fig. 7, fig. 7 is a flowchart of one implementation of step S104 in fig. 2, and in some embodiments, step S104 may include steps S201 to S203:
Step S201, obtaining a test execution instruction;
in some embodiments, the client is able to determine to perform an interface auto-test based on the acquired test execution instructions, which may be issued by a test initiation component in a client test tool, such as IntelliJ IDEA.
Step S202, responding to a test execution instruction, executing a target test script, and packaging corresponding preset test data into a test request of at least one target test interface based on a target test code class in the execution process, and sending the test request to a server side;
in some embodiments, when the client receives the test execution instruction, the test script can be executed, specifically, the target test code class and the corresponding test data are packaged into a test request, the test request is sent to the server, the server tests the target micro-service program according to the received test request, and response data is returned to the client.
And step S203, response data returned by the server side is received, the response data is asserted based on the target test code class, and a test result is obtained according to the asserted result.
In some embodiments, the client can receive response data returned by the server, assert the response data through an assertion statement in the target test code class to obtain an assertion result, and obtain a test result according to the assertion result.
In some embodiments, the assertion statement may be an asserter statement.
As shown in fig. 8, fig. 8 is another optional flowchart of an interface automation test method provided in an embodiment of the present application, where the method in fig. 8 may include, but is not limited to, steps S301 to S302.
Step S301, if the target test interface is not in the preset initial test interface set, configuring a new test code class corresponding to the target test interface, and updating the initial test code class according to the new test code class;
in some embodiments, if the target test interface does not belong to one of any initial test interfaces in the initial test interface set, which indicates that the target test interface is a newly added test interface, a new test code class needs to be configured for the target test interface, and the initial test code class is updated according to the new test code class.
Illustratively, the micro service a includes interfaces a, B, C, the micro service B includes interfaces a, B, d, the micro service C includes an interface e, the initial test interface includes an interface Aa, ab, ac, ba, bb, bd, the initial test codes are i, ii, iv, and it can be found that the interface e does not belong to one of the initial test interfaces, so that a new test code class needs to be written for the interface e to obtain a new test code class v, and the initial test code class is updated with the new test code class v to obtain updated initial test code classes i, ii, iv, v.
Step S302, the new test code class is injected into the test script corresponding to the target micro-service program, and the automatic test is performed on the target micro-service program based on the test script.
In some embodiments, when a new test code class is required for interface testing, the new test code class is injected into a test script corresponding to the target micro-service program, similar to the target test code class, to perform an automated test according to the test script after the injection of the test code class.
In some embodiments, since the initial test code class is updated, the test script also needs to be updated, and if only a portion of the target test interfaces in the test script class do not belong to any initial test interface, the test script is updated according to the portion of the target test interfaces; if all the target test interfaces in the test scenario class do not belong to any initial test interface, a new test script needs to be constructed.
As shown in fig. 9, fig. 9 is a flowchart of one implementation of step S101 in fig. 2, and in some embodiments, step S101 may include steps S401 to S403:
step S401, analyzing the test script class to obtain a micro-service name and an interface name;
In some embodiments, the acquired test scenario class may be parsed to determine the target micro-service program and the target test interface that need to be tested.
Step S402, determining a target micro service program according to the micro service name;
illustratively, as shown in fig. 3, the acquired test scenario class is parsed to obtain micro-service names of Commodity and Order, and then the target micro-service program to be tested is determined to be a Commodity micro-service program and an Order micro-service program.
Step S403, determining a target test interface of the target micro-service program according to the interface name.
Illustratively, as shown in fig. 3, taking a commodity micro-service as an example, if the interface names are OpenService and GetServiceInfo, determining that the target test interface under the commodity micro-service program is an open service interface and an acquire service quota interface.
As shown in fig. 10, fig. 10 is a flowchart of yet another alternative method for automated testing of interfaces provided in an embodiment of the present application, where the method in fig. 10 may include, but is not limited to, steps S501 to S503.
Step S501, obtaining the interface names of all initial test interfaces, and determining that the initial test code classes corresponding to the same interface names are the same;
In some embodiments, multiple identical initial test interfaces need only write one initial test code class. In order to write the initial test code class, firstly, the interface names of all the initial test interfaces are required to be acquired, the acquired interface names are divided, and the initial test code class corresponding to the initial test interfaces with the same interface name is determined to be the same.
Illustratively, the micro service a includes interfaces a, B, and c, the micro service B includes interfaces a, B, and d, the initial test interface is interface Aa, ab, ac, ba, bb, bd, and it is determined that the initial test interface Aa and the initial test interface Ba are the same test interface (actually, the interfaces a and A, B are only used for differentiating micro services), the initial test code classes corresponding to the initial test interface Aa and the initial test interface Ba are the same, and the initial test code classes corresponding to the initial test interface Ab and the initial test interface Bb are the same.
Step S502, obtaining interface parameters of an initial test interface corresponding to the same interface name;
in some embodiments, to write the initial test code class, it is necessary to obtain interface parameters associated with the initial test interface, where the interface parameters may include an interface name, path parameters, header parameters, and the like.
Step S503, generating initial test code class according to the interface parameters.
In some embodiments, an initial test code class may be generated based on the acquired interface parameters of the plurality of identical initial test interfaces.
As shown in fig. 11, fig. 11 is a flowchart of one implementation of step S503 in fig. 10, and in some embodiments, step S503 may include steps S601 to S602:
step S601, at least one initial request, packaging tool and assertion statement are obtained;
in some embodiments, the initial request may be get, post, put, delete or the like, the package tool may be an automated test tool such as restAssured, requests or the like, and the assertion statement may be an assert statement.
Step S602, packaging the interface parameters, the initial request and the assertion statement by using a packaging tool to obtain an initial test code class, wherein the initial test code class is used for injecting a corresponding test script.
In some embodiments, according to the acquired interface parameters, the interface parameters and the initial request may be encapsulated by an encapsulation tool, meanwhile, where appropriate, for example, after a certain execution logic is finished, an assertion statement is inserted and encapsulated together, after the interface parameters, the initial request and the assertion statement are all encapsulated, an initial test code class is obtained, when the initial test code class is determined to be a target test code class, the initial test code class may be injected into a corresponding test script, and the test script can configure test data to execute an interface automation test.
As shown in fig. 12, fig. 12 is a flowchart of one implementation of step S203 in fig. 7, and in some embodiments, step S203 may include steps S701 to S703:
step S701, obtaining a target expected result;
in some embodiments, the target desired result may be input by an operator, or may be automatically calculated based on configured test data.
Step S702, according to response data and the target test code class, obtaining an assertion result;
in some embodiments, after the client receives the response data returned by the server, since the target test code class is packaged with the assertion statement, the received response data can be compared with the target expected result according to the assertion statement to obtain the assertion result.
And step 703, comparing the asserted result with the target expected result to obtain a test result.
In some embodiments, if the assertion result does not match the target expected result, then it is determined that the test result characterizes the target micro-server as abnormal, otherwise, it is indicated that the target micro-server is not abnormal.
Illustratively, the predicate statement is asserts_code= 200, "request failed, state code not 200", which is used to verify if the value of the response_status_code is 200. If the result response_code of the assertion is not consistent with the target expected result 200, i.e. the result_code is not equal to 200, the assertion fails, then the assertion statement triggers an exception and a custom error message "request failure, status code not 200" is printed, indicating that the corresponding target micro-server has an exception.
It should be noted that, by adding the assertion statement, it is possible to effectively check whether the data returned by the interface meets the expectations, and confirm whether the system works as expected.
As shown in fig. 13, fig. 13 is a schematic diagram of functional modules of an interface automation test provided in an embodiment of the present application, and the embodiment of the present application further provides an interface automation test system, which may implement the above-mentioned interface automation test method, where the interface automation test system includes:
an obtaining module 801, configured to obtain an interface test request, and determine at least one target test interface of a target micro-service program from a preset test scenario class in response to the interface test request;
a determining module 802, configured to determine, from a plurality of preset initial test code classes, a target test code class corresponding to the target test interface if the target test interface is located in one of preset initial test interface sets, where the preset initial test interface set includes a plurality of initial test interfaces, and each initial test code class is used for testing an initial test interface corresponding to one of the initial test interfaces;
the test module 803 is configured to inject the target test code class into a test script corresponding to the target micro-service program to obtain a target test script;
And a result module 804, configured to automatically test the target micro service program according to the target test script and preset test data, so as to obtain a test result.
The specific implementation manner of the interface automatic test system is basically the same as the specific embodiment of the interface automatic test method, and will not be described herein. On the premise of meeting the requirements of the embodiment of the application, the interface automation test system can also be provided with other functional modules so as to realize the interface automation test method in the embodiment.
The embodiment of the application also provides electronic equipment, which comprises a memory and a processor, wherein the memory stores a computer program, and the processor realizes the interface automatic test method when executing the computer program. The electronic equipment can be any intelligent terminal including a tablet personal computer, a vehicle-mounted computer and the like.
As shown in fig. 14, fig. 14 is a schematic hardware structure of an electronic device provided in an embodiment of the present application, where the electronic device includes:
the processor 901 may be implemented by a general purpose CPU (central processing unit), a microprocessor, an application specific integrated circuit (ApplicationSpecificIntegratedCircuit, ASIC), or one or more integrated circuits, etc. for executing related programs to implement the technical solutions provided by the embodiments of the present application;
The memory 902 may be implemented in the form of read-only memory (ReadOnlyMemory, ROM), static storage, dynamic storage, or random access memory (RandomAccessMemory, RAM). The memory 902 may store an operating system and other application programs, and when the technical solutions provided in the embodiments of the present disclosure are implemented by software or firmware, relevant program codes are stored in the memory 902, and the processor 901 invokes the method for performing the automated test method for an interface in the embodiments of the present disclosure;
an input/output interface 903 for inputting and outputting information;
the communication interface 904 is configured to implement communication interaction between the device and other devices, and may implement communication in a wired manner (e.g. USB, network cable, etc.), or may implement communication in a wireless manner (e.g. mobile network, WIFI, bluetooth, etc.);
a bus 905 that transfers information between the various components of the device (e.g., the processor 901, the memory 902, the input/output interface 903, and the communication interface 904);
wherein the processor 901, the memory 902, the input/output interface 903 and the communication interface 904 are communicatively coupled to each other within the device via a bus 905.
The embodiment of the application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program realizes the interface automatic test method when being executed by a processor.
The memory, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs as well as non-transitory computer executable programs. In addition, the memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory optionally includes memory remotely located relative to the processor, the remote memory being connectable to the processor through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The embodiments described in the embodiments of the present application are for more clearly describing the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application, and as those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.
It will be appreciated by those skilled in the art that the technical solutions shown in the drawings do not constitute limitations of the embodiments of the present application, and may include more or fewer steps than shown, or may combine certain steps, or different steps.
The above described apparatus embodiments are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, i.e. may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
Those of ordinary skill in the art will appreciate that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof.
The terms "first," "second," "third," "fourth," and the like in the description of the present application and in the above-described figures, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
It should be understood that in this application, "at least one" means one or more, and "a plurality" means two or more. "and/or" for describing the association relationship of the association object, the representation may have three relationships, for example, "a and/or B" may represent: only a, only B and both a and B are present, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b or c may represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", wherein a, b, c may be single or plural.
In the several embodiments provided in this application, it should be understood that the disclosed systems and methods may be implemented in other ways. For example, the system embodiments described above are merely illustrative, e.g., the division of the above elements is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described above as separate components may or may not be physically separate, and components shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including multiple instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the various embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing a program.
Preferred embodiments of the present application are described above with reference to the accompanying drawings, and thus do not limit the scope of the claims of the embodiments of the present application. Any modifications, equivalent substitutions and improvements made by those skilled in the art without departing from the scope and spirit of the embodiments of the present application shall fall within the scope of the claims of the embodiments of the present application.
Claims (10)
1. An automated interface testing method, the method comprising:
acquiring an interface test request, and determining at least one target test interface of a target micro-service program from a preset test script class in response to the interface test request;
if the target test interface is located in a preset initial test interface set, determining a corresponding target test code class for the target test interface from a plurality of preset initial test code classes, wherein the preset initial test interface set comprises a plurality of initial test interfaces, and each initial test code class is used for testing the initial test interfaces corresponding to the initial test interfaces one by one;
injecting the target test code class into a test script corresponding to the target micro-service program to obtain a target test script;
and automatically testing the target micro-service program according to the target test script and preset test data to obtain a test result.
2. The automated interface testing method of claim 1, applied to a client, the client communicatively coupled to a server, the server running the target microservice program;
the automatic test is carried out on the target micro-service program according to the target test script and preset test data to obtain a test result, and the automatic test comprises the following steps:
acquiring a test execution instruction;
responding to the test execution instruction, executing the target test script, and packaging corresponding preset test data into a test request of at least one target test interface based on the target test code class in the execution process, and sending the test request to the server side;
and receiving response data returned by the server, asserting the response data based on the target test code class, and obtaining a test result according to the asserting result.
3. The method of automated interface testing of claim 1, further comprising:
if the target test interface is not in the preset initial test interface set, configuring a corresponding new test code class for the target test interface, and updating the initial test code class according to the new test code class;
And injecting the new test code class into the test script corresponding to the target micro-service program, and automatically testing the target micro-service program based on the test script.
4. The method of claim 1, wherein the determining at least one target test interface of the target micro-service program from the preset test scenario class comprises:
analyzing the test script class to obtain a micro-service name and an interface name;
determining a target micro service program according to the micro service name;
and determining a target test interface of the target micro-service program according to the interface name.
5. The method of automated interface testing of claim 1, wherein the initial test code class is obtained by:
acquiring the interface name of each initial test interface, and determining that the initial test code class corresponding to the same interface name is the same;
acquiring interface parameters of an initial test interface corresponding to the same interface name;
and generating an initial test code class according to the interface parameters.
6. The method of automated interface testing according to claim 5, wherein generating an initial test code class based on the interface parameters comprises:
Acquiring at least one initial request, packaging tool and assertion statement;
and packaging the interface parameters, the initial request and the assertion statement by using the packaging tool to obtain an initial test code class, wherein the initial test code class is used for injecting a corresponding test script.
7. The method according to claim 2, wherein said asserting the response data based on the object test code class, and obtaining a test result according to the asserting result, comprises:
acquiring a target expected result;
obtaining an assertion result according to the response data and the target test code class;
and comparing the assertion result with the target expected result to obtain a test result.
8. An interface automated test system, the system comprising:
the system comprises an acquisition module, a test module and a test module, wherein the acquisition module is used for acquiring an interface test request, and determining at least one target test interface of a target micro-service program from a preset test script class in response to the interface test request;
the determining module is used for determining a target test code class corresponding to the target test interface from a plurality of preset initial test code classes if the target test interface is positioned in one of preset initial test interface sets, wherein the preset initial test interface set comprises a plurality of initial test interfaces, and each initial test code class is used for testing the initial test interfaces corresponding to the initial test interface;
The test module is used for injecting the target test code class into a test script corresponding to the target micro-service program to obtain a target test script;
and the result module is used for automatically testing the target micro-service program according to the target test script and preset test data so as to obtain a test result.
9. An electronic device comprising a memory storing a computer program and a processor implementing the interface automation test method of any one of claims 1 to 7 when the computer program is executed by the processor.
10. A computer readable storage medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the interface automation test method of any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311183322.XA CN117539746A (en) | 2023-09-13 | 2023-09-13 | Interface automatic test method, system, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311183322.XA CN117539746A (en) | 2023-09-13 | 2023-09-13 | Interface automatic test method, system, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117539746A true CN117539746A (en) | 2024-02-09 |
Family
ID=89781359
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311183322.XA Pending CN117539746A (en) | 2023-09-13 | 2023-09-13 | Interface automatic test method, system, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117539746A (en) |
-
2023
- 2023-09-13 CN CN202311183322.XA patent/CN117539746A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11467952B2 (en) | API driven continuous testing systems for testing disparate software | |
| US10698797B2 (en) | Mobile application program testing method, server, terminal, and storage medium | |
| WO2018120721A1 (en) | Method and system for testing user interface, electronic device, and computer readable storage medium | |
| CN107526676B (en) | Cross-system test method and device | |
| CN108628748B (en) | Automatic test management method and automatic test management system | |
| US10331439B2 (en) | Source code transfer control method, computer program therefor, and recording medium therefor | |
| CN111240973B (en) | Equipment testing method and system based on simulation and readable storage medium | |
| CN110765018B (en) | Automatic interface testing method and equipment | |
| CN105302722B (en) | CTS automatic testing method and device | |
| CN113760704A (en) | Web UI (user interface) testing method, device, equipment and storage medium | |
| CN110119350B (en) | Software development kit testing method, device and equipment and computer storage medium | |
| CN110659202A (en) | Client automatic testing method and device | |
| CN109977012B (en) | Joint debugging test method, device, equipment and computer readable storage medium of system | |
| CN112241360A (en) | Test case generation method, device, equipment and storage medium | |
| CN111881014A (en) | System test method, device, storage medium and electronic equipment | |
| CN109739704A (en) | A kind of interface test method, server-side and computer readable storage medium | |
| CN101800672B (en) | Equipment detection method and equipment | |
| CN114816980A (en) | Automatic testing device and method for embedded communication system | |
| CN107203373B (en) | Interface control acquiring method, interface control testing method, interface control acquiring device and interface control testing device | |
| CN117539746A (en) | Interface automatic test method, system, electronic equipment and storage medium | |
| CN112131127B (en) | Interface testing method, device and system and electronic equipment | |
| CN112015715A (en) | Industrial Internet data management service testing method and system | |
| CN112698974A (en) | Fault injection test method, device and storage medium | |
| CN113434405B (en) | Method and device for determining test file, storage medium and electronic device | |
| CN113094251B (en) | Method and device for testing embedded system, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |