CN111625464A - Interface test method and device, storage medium and processor - Google Patents

Interface test method and device, storage medium and processor Download PDF

Info

Publication number
CN111625464A
CN111625464A CN202010471168.6A CN202010471168A CN111625464A CN 111625464 A CN111625464 A CN 111625464A CN 202010471168 A CN202010471168 A CN 202010471168A CN 111625464 A CN111625464 A CN 111625464A
Authority
CN
China
Prior art keywords
test
interface
data
thread group
tested
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
Application number
CN202010471168.6A
Other languages
Chinese (zh)
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.)
Hangzhou Honyar Electrical Co Ltd
Putian Intelligent Lighting Institute Co Ltd
Original Assignee
Hangzhou Honyar Electrical Co Ltd
Putian Intelligent Lighting Institute Co Ltd
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 Hangzhou Honyar Electrical Co Ltd, Putian Intelligent Lighting Institute Co Ltd filed Critical Hangzhou Honyar Electrical Co Ltd
Priority to CN202010471168.6A priority Critical patent/CN111625464A/en
Publication of CN111625464A publication Critical patent/CN111625464A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • 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
    • 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

Abstract

The application provides a test method, a test device, a storage medium and a processor of an interface, wherein the test method comprises the following steps: generating a test case by adopting a Python Web framework, wherein test data of the test case comprises an interface path, JSON data and assertion data; adopting JMETER to establish a test plan, wherein the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking an interface path, JSON data and assertion data; and executing the test case according to the test plan to obtain a test result. In the test method, the test plan can directly take the interface path, the JSON data and the assertion data of the test case, so that the interface path, the JSON data and the assertion data can be directly modified when different interfaces are tested, one thread group can run a plurality of interfaces in the test process, and the interface test efficiency is improved.

Description

Interface test method and device, storage medium and processor
Technical Field
The present application relates to the field of software testing technologies, and in particular, to a method and an apparatus for testing an interface, a storage medium, and a processor.
Background
As network security issues become more and more important, data is usually encoded and a signature needs to be added to the data when requesting an interface in a network communication process, and how to apply a tool to test such an interface requiring user identity authentication becomes a necessary skill for a tester.
JMETER is a lightweight testing tool developed by Apache organization, and testers can test interfaces needing authentication by using a series of plug-ins (such as regular expressions, BeanShell preprocessing programs, BeanShell post processors and BeanShell samplers) of the JMETER tool.
Request parameters of the authentication interface consist of object and sign, wherein the object is service API request parameters, and API request fields (args1, args 2.) are spliced into a standard JSON format character string and are encoded by Base 64; sign signature, generated by object + randomKey (randomKey is random encryption salt issued by platform) through MD5 encryption.
The authentication interface test method provided by the prior art based on the scenario (taking the scenario of "create family, modify family information, delete family" as an example, the interface paths are "/createHome", "/updateHome", "/deleteHome", respectively, and the parameterized test is carried out by the CSV file when using the JMETER test) is as follows:
1. compiling a test case of the interface to be tested: (1) building JSON character strings needed by three interfaces of 'creating family, modifying family information and deleting family'; (2) since the beenshell sampler of the JMETER tool cannot directly recognize JSON data, a JSON conversion tool needs to be used to compress and escape JSON strings.
2. Interface testing was performed in JMETER: (1) adding a test plan; (2) adding a login interface thread group, and extracting a random encryption salt randomKey required by the signature; (3) adding a thread group of a scene to be detected; (4) adding three BeanShell samplers below the thread group, respectively importing compressed and escaped JSON data corresponding to three interfaces of 'creating a family, modifying family information and deleting the family' to generate interface request parameters, respectively generating object1, object2 and object3 through Base64 coding, and respectively generating signatures sign1, sign2 and sign3 by combining random encryption salt randomKey; (5) three http requests of ' create family ', modify family information and delete family ' are added, interface addresses are respectively filled in as '/createHome ', ' updateHome ', ' deleeHome ', incoming parameters are respectively filled in as { ' sign ': ' $ { sign1} ', ' object ': ' $ { object1} ', ' sign ': $ 2} ', ' object ': $ object2} ', ' sign ': ' $ $ 3} ', ' object ': and $ object3 }; (6) adding three assertions respectively; (7) a listener is added.
When the scene-based authentication interface is tested, a Beanshell sampler, an HTTP request and an assertion are respectively added to each interface to be tested in a JMETER, under the condition that the scene is complex and the number of the interfaces to be tested is large, more components need to be added, and the efficiency of interface testing is low.
The above information disclosed in this background section is only for enhancement of understanding of the background of the technology described herein and, therefore, certain information may be included in the background that does not form the prior art that is already known in this country to a person of ordinary skill in the art.
Disclosure of Invention
The present application mainly aims to provide a method and an apparatus for testing an interface, a storage medium, and a processor, so as to solve the problem of low efficiency of interface testing in the prior art.
In order to achieve the above object, according to an aspect of the present application, there is provided a method for testing an interface, including: generating a test case by adopting a Python Web framework, wherein test data of the test case comprises an interface path, JSON data and assertion data; adopting JMETER to establish a test plan, wherein the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data; and executing the test case according to the test plan to obtain a test result.
Further, generating a test case by adopting a Python Web framework comprises: inputting the test data on a Python Web page, wherein the test data also comprises a CSV file name, case file description, the number of test cases and assertion data; and generating a CSV file according to the test data to obtain the test case.
Further, a JMETER is adopted to establish a test plan, which comprises the following steps: establishing a directory of the test plan; adding an HTTP information manager, an HTTP request default value, a user-defined variable and a BeanShell preprocessing program in the directory; adding a login thread group in the directory, extracting incoming parameters through the login thread group and transmitting the incoming parameters to the interface thread group to be tested; and adding the interface thread group to be tested in the directory, and taking the test data and the incoming parameters through the interface thread group to be tested.
Further, adding the interface thread group to be tested in the directory further includes: add assertions and listeners.
Further, executing the test case according to the test plan to obtain a test result, including: executing the test case according to the test plan; determining whether the test case is successfully executed by adopting assertion; and viewing the test results by adopting a monitor, wherein the test results comprise a result tree and an aggregation report.
Further, extracting incoming parameters through the login thread group and transmitting the incoming parameters to the interface thread group to be tested, including: adding an HTTP request of a login interface; adding a regular expression and extracting the incoming parameters; and adding a BeansShell post processor, and setting the incoming parameters as global variables so that the incoming parameters are transmitted to the interface thread group to be tested.
Further, the step of taking the test data through the interface thread group to be tested includes: adding a Beanshell sampler, and taking the JSON data; and adding an HTTP request and extracting the interface path.
According to another aspect of the present application, there is provided a test apparatus of an interface, including: the device comprises a generating unit, a judging unit and a judging unit, wherein the generating unit is used for generating a test case by adopting a Python Web framework, and test data of the test case comprises an interface path, JSON data and assertion data; the processing unit is used for establishing a test plan by adopting JMETER, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data; and the test unit is used for executing the test case according to the test plan to obtain a test result.
According to yet another aspect of the present application, there is provided a storage medium comprising a stored program, wherein the program performs any one of the test methods.
According to yet another aspect of the application, a processor for running a program is provided, wherein the program is run to perform any one of the test methods.
According to the technical scheme, in the interface test method, firstly, a Python Web framework is adopted to generate a test case, and test data of the test case comprises an interface path, JSON data and assertion data; then, a JMETER is adopted to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking an interface path, JSON data and assertion data; and finally, executing the test case according to the test plan to obtain a test result. In the test method, the test plan can directly take the interface path, the JSON data and the assertion data of the test case, so that the interface path, the JSON data and the assertion data can be directly modified when different interfaces are tested, one thread group can run a plurality of interfaces in the test process, and the interface test efficiency is improved.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this application, illustrate embodiments of the application and, together with the description, serve to explain the application and are not intended to limit the application. In the drawings:
FIG. 1 shows a flow diagram of a method of testing an interface according to an embodiment of the application; and
fig. 2 shows a schematic diagram of a test setup of an interface according to an embodiment of the application.
Detailed Description
It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the disclosure. 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.
It is noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments according to the present application. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, and it should be understood that when the terms "comprises" and/or "comprising" are used in this specification, they specify the presence of stated features, steps, operations, devices, components, and/or combinations thereof, unless the context clearly indicates otherwise.
It will be understood that when an element such as a layer, film, region, or substrate is referred to as being "on" another element, it can be directly on the other element or intervening elements may also be present. Also, in the specification and claims, when an element is described as being "connected" to another element, the element may be "directly connected" to the other element or "connected" to the other element through a third element.
As mentioned in the background, the interface test in the prior art is inefficient, and in order to solve the above technical problems, the present application provides a method, an apparatus, a storage medium, and a processor for testing an interface.
Fig. 1 shows a flow chart of a testing method of an interface according to an embodiment of the application, which comprises the following steps, as shown in fig. 1:
step S101, generating a test case by adopting a Python Web framework, wherein test data of the test case comprises an interface path, JSON data and assertion data;
step S102, a JMETER is adopted to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data;
and step S103, executing the test case according to the test plan to obtain a test result.
In the interface test method, firstly, a Python Web framework is adopted to generate a test case, and test data of the test case comprises an interface path, JSON data and assertion data; then, a JMETER is adopted to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking an interface path, JSON data and assertion data; and finally, executing the test case according to the test plan to obtain a test result. In the test method, the test plan can directly take the interface path, the JSON data and the assertion data of the test case, so that the interface path, the JSON data and the assertion data can be directly modified when different interfaces are tested, one thread group can run a plurality of interfaces in the test process, and the interface test efficiency is improved.
It should be noted that the steps illustrated in the flowcharts of the figures may be performed in a computer system such as a set of computer-executable instructions and that, although a logical order is illustrated in the flowcharts, in some cases, the steps illustrated or described may be performed in an order different than presented herein.
In an actual testing process, since the beenshell sampler of JMETER cannot directly identify JSON data, the JSON data needs to be compressed and escaped, and the traditional method needs to complete data processing manually or by means of an external tool. In an embodiment of the present application, generating a test case using a Web framework of Python includes: inputting the test data on a Python Web page, wherein the test data also comprises a CSV file name, case file description and the number of test cases; and generating a CSV file according to the test data to obtain the test case. Specifically, a test case is generated by adopting a Python Web framework, namely test data is input and exported to generate a CSV file, such as a home.
In the test data of the CSV file, for example, the number of test cases can also be directly used, so that the data processing efficiency is improved, and the test efficiency is further improved.
In one embodiment of the present application, the establishing a test plan using JMETER includes: establishing a directory of the test plan; adding an HTTP information manager, an HTTP request default value, a user-defined variable and a BeanShell preprocessing program in the directory; adding a login thread group in the directory, extracting incoming parameters through the login thread group and transmitting the incoming parameters to the interface thread group to be tested; and adding the interface thread group to be tested in the directory, and taking the test data and the incoming parameters through the interface thread group to be tested. Specifically, an HTTP information manager, an HTTP request default, a user-defined variable, and a beans shell preprocessing program are added to the directory, incoming parameters of an interface to be authenticated, such as randomKey, token, and userid, are provided for testing, then a login thread group is added, the incoming parameters are extracted and transmitted to an interface thread group to be tested, the interface thread group to be tested is added, test data and the incoming parameters are used, a test case is executed, and the interface to be authenticated is tested.
It should be noted that, the interface to be tested adopts a post request mode, a request header corresponding to HTTP is input in the HTTP information manager, and the request header contains many useful information about the client environment and the request text, for example, the request header can declare the language used by the browser, the length of the request text, and the like; the HTTP request default value comprises a network protocol name, a server or IP address and a port number; the user-defined variables are variables that appear repeatedly in the input script, such as the directory of the CSV file of the test case, the input name is DATA, the value is F: \\ meter \ testcase, and the directory of the CSV file can be subsequently represented by $ { DATA }; the beenshell preprocessing program can generate repeated data used by the interface test by writing scripts according to the requirement of the post-test, for example, a MAC address, and the MAC address can be used as an incoming parameter extracted when the HTTP request is made.
It should be further noted that, in the process of adding the interface thread group to be tested, the number of use cases of the test cases may be used to control the thread number, for example, the thread number of the interface thread group to be tested is set to $ { __ CSVRead ($ { DATA } \ home.csv,1) }, so that the number of use cases in the home.csv file of the test cases is used to control the thread number.
In an embodiment of the present application, adding the above interface thread group to be tested further includes: add assertions and listeners. Specifically, the assertion may add a response assertion, select a response text, compare assertion DATA in a CSV file of the test case, determine whether the assertion is successful, and add a listener to feed back a test result, for example, when $ { __ CSVRead ($ { DATA } \ home.
It should be noted that, in the process of adding the login thread group, an assertion and a listener may also be added to feed back the operation result of the login thread group.
In an embodiment of the present application, executing the test case according to the test plan to obtain a test result includes: executing the test case according to the test plan; determining whether the test case is successfully executed by adopting assertion; and viewing the test results by adopting a monitor, wherein the test results comprise a result tree and an aggregation report. Specifically, the response text, that is, the request result of the interface is compared with the assertion data in the CSV file, and if the result is consistent, the test case is successfully executed, and if the result is inconsistent, the test case is unsuccessfully executed, and the listener may add a result tree and an aggregation report, and visually present the test result in a chart form.
In an embodiment of the present application, extracting incoming parameters through the login thread group and transmitting the incoming parameters to the interface thread group to be tested includes: adding an HTTP request of a login interface; adding a regular expression and extracting the incoming parameters; and adding a Beanshell post processor, and setting the incoming parameters as global variables so that the incoming parameters are transmitted to the interface thread group to be tested. Specifically, after an HTTP request of a login interface is added, dynamic data association is realized by adding a regular expression, so as to obtain corresponding dynamic data of a server, for example, randomKey, token and userid, as incoming parameters of an interface needing authentication, and the incoming parameters are set as global variables by adding a beans shell post processor, so as to realize cross-thread group transfer parameters, that is, the incoming parameters are transferred from the login thread group to an interface thread group to be tested, for example, a script setting randomKey as the global variables is $ { __ setProperty (randomKey, { randomKey }, true) }, and then $ { __ p randomKey } is used (__ p random domkey).
In an embodiment of the application, the step of using the test data and the incoming parameters through the interface thread group to be tested includes: adding a Beanshell sampler, and taking the JSON data; and adding an HTTP request and extracting the interface path. Specifically, a benshell sampler is added, JSON DATA of a CSV file of the test case is used to generate a request parameter, the request parameter is encoded, encrypted and the like, and a signature sign required by a request interface is generated, for example, JSON DATA in the home.csv file of the test case can be obtained by String JSON ═ __ eval ($ { __ CSVRead ($ { DATA } \ \ home.csv,1) }); adding an HTTP request, extracting an interface path of a CSV file of a test case, for example, passing through $ { __ CSVRead ($ { DATA } \ home.csv,0) } based on a scene of creating a home, modifying home information, and deleting the home, and may fetch an interface path of creating a home "/createHome", modifying home information "/updateHome", and deleting a home "/deleeHome", where the incoming parameters are { "sign": "$ { sign }", "" object "$ { object }" }.
The embodiment of the present application further provides a testing apparatus for an interface, and it should be noted that the testing apparatus for an interface of the embodiment of the present application may be used to execute the testing method for an interface provided in the embodiment of the present application. The following describes a test apparatus for an interface provided in an embodiment of the present application.
Fig. 2 is a schematic diagram of a testing apparatus of an interface according to an embodiment of the present application, as shown in fig. 2, the apparatus includes:
the generation unit 10 is configured to generate a test case by using a Python Web framework, where test data of the test case includes an interface path, JSON data, and assertion data;
a processing unit 20, configured to establish a test plan by using JMETER, where the test plan includes adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data, and the assertion data;
the test unit 30 is configured to execute the test case according to the test plan to obtain a test result.
In the interface test device, a generation unit generates a test case by adopting a Python Web framework, and test data of the test case comprises an interface path, JSON data and assertion data; the processing unit adopts JMETER to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking an interface path, JSON data and assertion data; and the test unit executes the test case according to the test plan to obtain a test result. In the testing device, the test plan can directly take the interface path, the JSON data and the assertion data of the test case, so that when different interfaces are tested, the interface path, the JSON data and the assertion data can be directly modified, one thread group can run a plurality of interfaces in the testing process, and the efficiency of interface testing is improved.
In an actual testing process, since the beenshell sampler of JMETER cannot directly identify JSON data, the JSON data needs to be compressed and escaped, and the traditional method needs to complete data processing manually or by means of an external tool. In an embodiment of the present application, the generating unit includes an input module and a generating module, where the input module is configured to input the test data on a Web page of Python, and the test data further includes a CSV file name, a case file description, a number of test cases, and assertion data; the generating module is used for generating a CSV file according to the test data to obtain the test case. Specifically, a test case is generated by adopting a Python Web framework, namely test data is input and exported to generate a CSV file, such as a home.
It should be noted that, in the test data of the CSV file, for example, the number of test cases and the assertion data may also be directly used, so as to improve the data processing efficiency and further improve the test efficiency.
In an embodiment of the present application, the processing unit includes a first processing module, a second processing module, and a third processing module, where the first processing module is configured to establish a directory of the test plan; adding an HTTP information manager, an HTTP request default value, a user-defined variable and a BeanShell preprocessing program in the directory; the second processing module is used for adding a login thread group in the directory, extracting incoming parameters through the login thread group and transmitting the incoming parameters to the interface thread group to be tested; the third processing module is configured to add the interface thread group to be tested to the directory, and use the test data and the incoming parameter through the interface thread group to be tested. Specifically, an HTTP information manager, an HTTP request default, a user-defined variable, and a beans shell preprocessing program are added to the directory, incoming parameters of an interface to be authenticated, such as randomKey, token, and userid, are provided for testing, then a login thread group is added, the incoming parameters are extracted and transmitted to an interface thread group to be tested, the interface thread group to be tested is added, test data and the incoming parameters are used, a test case is executed, and the interface to be authenticated is tested.
It should be noted that, the interface to be tested adopts a post request mode, a request header corresponding to HTTP is input in the HTTP information manager, and the request header contains many useful information about the client environment and the request text, for example, the request header can declare the language used by the browser, the length of the request text, and the like; the HTTP request default value comprises a network protocol name, a server or IP address and a port number; the user-defined variables are variables that appear repeatedly in the input script, such as the directory of the CSV file of the test case, the input name is DATA, the value is F: \\ meter \ testcase, and the directory of the CSV file can be subsequently represented by $ { DATA }; the beenshell preprocessing program can generate repeated data used by the interface test by writing scripts according to the requirement of the post-test, for example, a MAC address, and the MAC address can be used as an incoming parameter extracted when the HTTP request is made.
It should be further noted that, in the process of adding the interface thread group to be tested, the number of use cases of the test cases may be used to control the thread number, for example, the thread number of the interface thread group to be tested is set to $ { __ CSVRead ($ { DATA } \ home.csv,1) }, so that the number of use cases in the home.csv file of the test cases is used to control the thread number.
In an embodiment of the present application, the third processing module further includes a first processing sub-module, and the first processing sub-module is configured to add an assertion and a listener. Specifically, the assertion may add a response assertion, select a response text, compare assertion DATA in a CSV file of the test case, determine whether the assertion is successful, and add a listener to feed back a test result, for example, when $ { __ CSVRead ($ { DATA } \ home.
It should be noted that, in the process of adding the login thread group, an assertion and a listener may also be added to feed back the operation result of the login thread group.
In an embodiment of the application, the test unit includes a fourth processing module, a fifth processing module, and a sixth processing module, where the fourth processing module is configured to execute the test case according to the test plan; the fifth processing module is configured to determine whether the test case is successfully executed by using the assertion; the sixth processing module is configured to use a listener to view the test results, where the test results include a result tree and an aggregation report. Specifically, the response text, that is, the request result of the interface is compared with the assertion data in the CSV file, and if the result is consistent, the test case is successfully executed, and if the result is inconsistent, the test case is unsuccessfully executed, and the listener may add a result tree and an aggregation report, and visually present the test result in a chart form.
In an embodiment of the present application, the second processing module includes a second processing sub-module, a third processing sub-module, and a fourth processing sub-module, where the second processing sub-module is configured to add an HTTP request of a login interface; the third processing submodule is used for adding a regular expression and extracting the incoming parameters; the fourth processing submodule is used for adding a BeanShell post processor, and setting the incoming parameters as global variables, so that the incoming parameters are transmitted to the interface thread group to be tested. Specifically, after an HTTP request of a login interface is added, dynamic data association is realized by adding a regular expression, so as to obtain corresponding dynamic data of a server, for example, randomKey, token and userid, as incoming parameters of an interface needing authentication, and the incoming parameters are set as global variables by adding a beans shell post processor, so as to realize cross-thread group transfer parameters, that is, the incoming parameters are transferred from the login thread group to an interface thread group to be tested, for example, a script setting randomKey as the global variables is $ { __ setProperty (randomKey, { randomKey }, true) }, and then $ { __ p randomKey } is used (__ p random domkey).
In an embodiment of the present application, the third processing module includes a fifth processing submodule and a sixth processing submodule, where the fifth processing submodule is used for adding a BeanShell sampler and taking the JSON data; the sixth processing sub-module is configured to add an HTTP request and extract the interface path. Specifically, a benshell sampler is added, JSON DATA of a test case is used to generate a request parameter, the request parameter is encoded, encrypted and the like, and a signature sign required by a request interface is generated, for example, JSON DATA in a home.csv file of the test case can be obtained by String JSON ═ $ __ eval ($ { __ CSVRead ($ { DATA } \ \ home.csv,1) }); adding an HTTP request, extracting an interface path of a CSV file of a test case, for example, passing through $ { __ CSVRead ($ { DATA } \ home.csv,0) } based on a scene of creating a home, modifying home information, and deleting the home, and may fetch an interface path of creating a home "/createHome", modifying home information "/updateHome", and deleting a home "/deleeHome", where the incoming parameters are { "sign": "$ { sign }", "" object "$ { object }" }.
The control device comprises a processor and a memory, the generating unit, the processing unit, the testing unit and the like are stored in the memory as program units, and the processor executes the program units stored in the memory to realize corresponding functions.
The processor comprises a kernel, and the kernel calls the corresponding program unit from the memory. The kernel can be set to be one or more than one, and the problem of low efficiency of interface testing in the prior art is solved by adjusting kernel parameters.
The memory may include volatile memory in a computer readable medium, Random Access Memory (RAM) and/or nonvolatile memory such as Read Only Memory (ROM) or flash memory (flash RAM), and the memory includes at least one memory chip.
An embodiment of the present invention provides a storage medium, on which a program is stored, which when executed by a processor implements the above-described test method.
The embodiment of the invention provides a processor, which is used for running a program, wherein the program executes the test method when running.
The embodiment of the invention provides equipment, which comprises a processor, a memory and a program which is stored on the memory and can run on the processor, wherein when the processor executes the program, at least the following steps are realized:
step S101, generating a test case by adopting a Python Web framework, wherein test data of the test case comprises an interface path, JSON data and assertion data;
step S102, a JMETER is adopted to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data;
and step S103, executing the test case according to the test plan to obtain a test result.
The device herein may be a server, a PC, a PAD, a mobile phone, etc.
The present application further provides a computer program product adapted to perform a program of initializing at least the following method steps when executed on a data processing device:
step S101, generating a test case by adopting a Python Web framework, wherein test data of the test case comprises an interface path, JSON data and assertion data;
step S102, a JMETER is adopted to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data;
and step S103, executing the test case according to the test plan to obtain a test result.
In the above embodiments of the present invention, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
In the embodiments provided in the present application, it should be understood that the disclosed technology can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the above-described division of the units may be a logical division, and in actual implementation, there may be another division, for example, multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit may be stored in a computer-readable storage medium if it is implemented in the form of a software functional unit and sold or used as a separate product. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the above methods according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.
From the above description, it can be seen that the above-described embodiments of the present application achieve the following technical effects:
1) according to the interface test method, firstly, a Python Web framework is adopted to generate a test case, and test data of the test case comprises an interface path, JSON data and assertion data; then, a JMETER is adopted to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking an interface path, JSON data and assertion data; and finally, executing the test case according to the test plan to obtain a test result. In the test method, the test plan can directly take the interface path, the JSON data and the assertion data of the test case, so that the interface path, the JSON data and the assertion data can be directly modified when different interfaces are tested, one thread group can run a plurality of interfaces in the test process, and the interface test efficiency is improved.
2) In the interface testing device, a generating unit generates a test case by adopting a Python Web framework, and test data of the test case comprises an interface path, JSON data and assertion data; the processing unit adopts JMETER to establish a test plan, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking an interface path, JSON data and assertion data; and the test unit executes the test case according to the test plan to obtain a test result. In the testing device, the test plan can directly take the interface path, the JSON data and the assertion data of the test case, so that when different interfaces are tested, the interface path, the JSON data and the assertion data can be directly modified, one thread group can run a plurality of interfaces in the testing process, and the efficiency of interface testing is improved.
The above description is only a preferred embodiment of the present application and is not intended to limit the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims (10)

1. A method for testing an interface, comprising:
generating a test case by adopting a Python Web framework, wherein test data of the test case comprises an interface path, JSON data and assertion data;
adopting JMETER to establish a test plan, wherein the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data;
and executing the test case according to the test plan to obtain a test result.
2. The testing method according to claim 1, wherein generating test cases using a Web framework of Python comprises:
inputting the test data on a Python Web page, wherein the test data also comprises a CSV file name, case file description, the number of test cases and assertion data;
and generating a CSV file according to the test data to obtain the test case.
3. The method of claim 1, wherein creating a test plan using JMETER comprises:
establishing a directory of the test plan;
adding an HTTP information manager, an HTTP request default value, a user-defined variable and a BeanShell preprocessing program in the directory;
adding a login thread group in the directory, extracting incoming parameters through the login thread group and transmitting the incoming parameters to the interface thread group to be tested;
and adding the interface thread group to be tested in the directory, and taking the test data and the incoming parameters through the interface thread group to be tested.
4. The method according to claim 3, wherein adding the set of interface threads to be tested to the directory further comprises:
add assertions and listeners.
5. The method according to claim 4, wherein executing the test case according to the test plan to obtain a test result comprises:
executing the test case according to the test plan;
determining whether the test case is successfully executed by adopting assertion;
and viewing the test results by adopting a monitor, wherein the test results comprise a result tree and an aggregation report.
6. The method of claim 3, wherein extracting incoming parameters through the login thread group and passing the incoming parameters to the interface under test thread group comprises:
adding an HTTP request of a login interface;
adding a regular expression and extracting the incoming parameters;
and adding a BeansShell post processor, and setting the incoming parameters as global variables so that the incoming parameters are transmitted to the interface thread group to be tested.
7. The method of claim 3, wherein accessing the test data by the set of interface threads to be tested comprises:
adding a Beanshell sampler, and taking the JSON data;
and adding an HTTP request and extracting the interface path.
8. An apparatus for testing an interface, comprising:
the device comprises a generating unit, a judging unit and a judging unit, wherein the generating unit is used for generating a test case by adopting a Python Web framework, and test data of the test case comprises an interface path, JSON data and assertion data;
the processing unit is used for establishing a test plan by adopting JMETER, the test plan comprises adding an interface thread group to be tested, and the interface thread group to be tested is at least used for taking the interface path, the JSON data and the assertion data;
and the test unit is used for executing the test case according to the test plan to obtain a test result.
9. A storage medium, characterized in that the storage medium comprises a stored program, wherein the program performs the test method of any one of claims 1 to 7.
10. A processor, characterized in that the processor is configured to run a program, wherein the program is configured to execute the testing method according to any one of claims 1 to 7 when running.
CN202010471168.6A 2020-05-28 2020-05-28 Interface test method and device, storage medium and processor Pending CN111625464A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010471168.6A CN111625464A (en) 2020-05-28 2020-05-28 Interface test method and device, storage medium and processor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010471168.6A CN111625464A (en) 2020-05-28 2020-05-28 Interface test method and device, storage medium and processor

Publications (1)

Publication Number Publication Date
CN111625464A true CN111625464A (en) 2020-09-04

Family

ID=72259280

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010471168.6A Pending CN111625464A (en) 2020-05-28 2020-05-28 Interface test method and device, storage medium and processor

Country Status (1)

Country Link
CN (1) CN111625464A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112579446A (en) * 2020-12-10 2021-03-30 北京软通智慧城市科技有限公司 Interface testing method and device, electronic equipment and storage medium
CN113535557A (en) * 2021-07-14 2021-10-22 上海中通吉网络技术有限公司 JMeter-based assertion method and device
CN113656302A (en) * 2021-08-16 2021-11-16 杭州安恒信息技术股份有限公司 WAF rule automatic testing method, system, storage medium and terminal equipment

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112579446A (en) * 2020-12-10 2021-03-30 北京软通智慧城市科技有限公司 Interface testing method and device, electronic equipment and storage medium
CN113535557A (en) * 2021-07-14 2021-10-22 上海中通吉网络技术有限公司 JMeter-based assertion method and device
CN113656302A (en) * 2021-08-16 2021-11-16 杭州安恒信息技术股份有限公司 WAF rule automatic testing method, system, storage medium and terminal equipment

Similar Documents

Publication Publication Date Title
US10601866B2 (en) Discovering website phishing attacks
JP6559694B2 (en) Automatic SDK acceptance
US9185039B1 (en) Application testing through object level code inspection
CN111625464A (en) Interface test method and device, storage medium and processor
US10007776B1 (en) Systems and methods for distinguishing among human users and software robots
CN111163095B (en) Network attack analysis method, network attack analysis device, computing device, and medium
CN107241306B (en) Man-machine identification method, server, client and man-machine identification system
US20180322270A1 (en) Systems and methods for distinguishing among human users and software robots
CN103647652B (en) A kind of method for realizing data transfer, device and server
CN112527252A (en) Applet management method and device, applet platform, electronic device and medium
CN105554136B (en) Backup Data restoring method, apparatus and system
CN107911383A (en) A kind of cryptographic check method and apparatus
US11343357B2 (en) Systems and methods for autonomous program detection
WO2022093355A1 (en) Machine learning-based techniques for identifying deployment environments and enhancing security thereof
CN113742005A (en) Platform docking method and device
CN115016995A (en) Interface testing method, computer device and computer storage medium
US20220038447A1 (en) Systems and methods for autonomous program detection and management
CN113992353A (en) Login certificate processing method and device, electronic equipment and storage medium
CN113778704A (en) Interface calling method and device
US11019089B1 (en) Performing security assessments based on user credentials
CN111651766A (en) Unauthorized access testing method and device
CN111652625A (en) Authentication method and device, electronic equipment and computer readable storage medium
CN105530260B (en) A kind of setting method and device of the safety identification information for website
US11445003B1 (en) Systems and methods for autonomous program detection
US11765063B2 (en) System for creating randomized scaled testing

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