CN113688025A - Interface test method, device, equipment and storage medium - Google Patents

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

Info

Publication number
CN113688025A
CN113688025A CN202111045953.6A CN202111045953A CN113688025A CN 113688025 A CN113688025 A CN 113688025A CN 202111045953 A CN202111045953 A CN 202111045953A CN 113688025 A CN113688025 A CN 113688025A
Authority
CN
China
Prior art keywords
data
interface
test
tested
parameter data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111045953.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.)
China United Network Communications Group Co Ltd
Original Assignee
China United Network Communications Group 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 China United Network Communications Group Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202111045953.6A priority Critical patent/CN113688025A/en
Publication of CN113688025A publication Critical patent/CN113688025A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application provides an interface testing method, an interface testing device, interface testing equipment and a storage medium. According to the method, when a test instruction sent by terminal equipment is received, parameter data are obtained from a local database, wherein the parameter data comprise test data and login state data, the login state data are generated after a login interface is requested, then the parameter data are transmitted to a tested interface, the tested interface is tested according to the parameter data, a test result is obtained, and finally the test result is sent to the terminal equipment. The method can reduce the workload of testers; the efficiency and the accuracy rate of interface pressure measurement are improved.

Description

Interface test method, device, equipment and storage medium
Technical Field
The present application relates to communications technologies, and in particular, to an interface testing method, apparatus, device, and storage medium.
Background
In order to ensure that the system can operate accurately and stably, performance test is usually performed on a service scene of the system. The interface is used as a bridge for realizing communication between each system and each module, so that when a service scene of the system is tested, the most important thing is to test the service interface, for example, the performance of the service interface is tested, and the performance test of the service interface can help a user to find potential risks and performance bottlenecks of the service system in time.
In the related art, many service interfaces can be requested successfully on the premise of login, so that when the performance of the service interface in the login state is pressed, the login interface is requested first, and the acquired login state data can be transmitted to the service interface to be tested, so that the performance pressing of the service interface is realized.
However, in the above method for performing pressure measurement on the service interface in the login state, the login interface needs to be called first to obtain login state data each time the service interface is pressure-measured, so that the pressure measurement efficiency of the service interface is low.
Disclosure of Invention
In order to solve the problems in the prior art, the application provides an interface testing method, device, equipment and storage medium, which can not only reduce resource consumption, but also reduce testing time and improve testing efficiency, and can also focus on a target tested interface and improve result accuracy.
In one aspect, the present application provides an interface testing method applied to a terminal device, including:
when a test instruction sent by terminal equipment is received, parameter data are obtained from a local database, the parameter data comprise test data and login state data, and the login state data are data generated after a login interface is requested;
transmitting the parameter data to the tested interface so as to test the tested interface according to the parameter data to obtain a test result;
and sending the test result to the terminal equipment.
In a possible implementation manner, the testing the interface to be tested according to the parameter data to obtain a test result includes:
calling service data related to the tested interface from a local database;
and testing the tested interface according to the parameter data and the service data to obtain a test result.
In a possible implementation manner, before acquiring the service data related to the interface under test, the method further includes:
determining the execution logic of the interface to be tested;
and storing the service data related to the tested interface into a local database according to the execution logic.
In a possible implementation manner, before acquiring parameter data from a local database when a test instruction sent by a terminal device is received, the method further includes:
acquiring test data;
calling a login interface according to the test data to generate login state data;
and generating parameter data according to the test data and the login state data, and storing the parameter data into a local database.
In one possible implementation, obtaining test data includes:
receiving a request message which is sent by terminal equipment and used for generating test data, wherein the request message comprises first quantity and type information;
a first amount of test data is randomly generated based on the type information.
In one possible implementation, the method further includes:
and after a preset time period after the test result is output, deleting the parameter data in the local database.
In a possible implementation manner, the testing the interface to be tested according to the parameter data to obtain a test result includes:
and testing the tested interface according to the parameter data according to the number of the pre-configured concurrent threads to obtain a test result.
In a second aspect, an embodiment of the present application further provides an interface testing apparatus, including:
the acquisition module is used for acquiring parameter data from a local database when a test instruction sent by the terminal equipment is received, wherein the parameter data comprises test data and login state data, and the login state data is data generated after a login interface is requested;
the processing module is used for transmitting the parameter data to the tested interface so as to test the tested interface according to the parameter data to obtain a test result;
and the sending module is used for sending the test result to the terminal equipment.
In a possible implementation manner, the processing module is specifically configured to: calling service data related to the tested interface from a local database;
and testing the tested interface according to the parameter data and the service data to obtain a test result.
In a possible implementation manner, the processing module is specifically configured to: determining the execution logic of the interface to be tested;
and storing the service data related to the tested interface into a local database according to the execution logic.
In a possible implementation manner, the obtaining module is further configured to obtain test data;
the processing module is also used for calling a login interface according to the test data so as to generate login state data;
and the processing module is also used for generating parameter data according to the test data and the login state data and storing the parameter data into a local database.
In a possible implementation manner, the obtaining module is specifically configured to: receiving a request message which is sent by terminal equipment and used for generating test data, wherein the request message comprises first quantity and type information;
a first amount of test data is randomly generated based on the type information.
In a possible implementation manner, the processing module is further configured to delete the parameter data in the local database after a preset time period after the test result is output.
In a possible implementation manner, the processing module is further configured to test the interface to be tested according to the parameter data according to the number of the concurrent threads configured in advance, so as to obtain a test result.
In a third aspect, an embodiment of the present application further provides a terminal device, where the terminal device may include a processor and a memory; wherein,
a memory for storing processor-executable instructions;
and the processor is used for reading the computer program stored in the memory and executing the interface testing method in any one of the possible implementation manners of the first aspect according to the computer program in the memory.
In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, where a computer-executable instruction is stored in the computer-readable storage medium, and when the processor executes the computer-executable instruction, the interface testing method in any one of the possible implementation manners of the first aspect is implemented.
According to the interface testing method, the device, the equipment and the storage medium, when a testing instruction sent by the terminal equipment is received, parameter data are obtained from a local database, the parameter data comprise testing data and login state data, the login state data are data generated after the interface is requested to be logged in, then the parameter data are transmitted to the interface to be tested, the interface to be tested is tested according to the parameter data, a testing result is obtained, and the testing result is sent to the terminal equipment. The logging-on state data generated after the user requests the logging-on interface once and the test data are directly combined to generate the parameter data, the parameter data are transmitted into the tested service interface to be tested for pressure testing, the problem that the logging-on state data can be obtained only by calling the logging-on interface when the tested interface is tested every time is solved, and therefore the service interface and the logging-on interface are separated when pressure testing is executed, all focuses of pressure testing are placed on the service interface, workload of testing tasks is reduced, and efficiency of pressure testing of the service interface is improved.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.
Fig. 1 is a system architecture diagram of an interface testing method according to an embodiment of the present application;
fig. 2 is a schematic flowchart of an interface testing method according to an embodiment of the present application;
FIG. 3 is a schematic view of a universal pressure measurement pin configuration;
fig. 4 is a schematic structural diagram of an interface testing apparatus according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of a terminal device according to an embodiment of the present application.
With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The interface testing method provided by the embodiment of the application can be applied to a scene of performing pressure testing on the service interface in the system, and particularly can be applied to a scene of performing performance pressure testing on the service interface in a login state. The performance pressure test of the service interface in the login state refers to that a large number of concurrent requests are carried out on the service interface through a large amount of service parameter data and associated service data in the tested system, and finally returned results of all the requests and whether the state of the tested system meets expectations are analyzed. Generally, before a certain system is brought on line, in order to ensure the normal operation of the system and facilitate the discovery of defects and problems existing in the system in advance, each service interface in the system is firstly subjected to pressure measurement, and then brought on line after the pressure measurement is passed. In addition, during normal operation or maintenance of the system, it may often be necessary to perform pressure measurement on the performance of the service interface.
Taking the example of performing pressure measurement on a service interface which requests to submit an order after selecting and purchasing a commodity to be purchased in a shopping Application program (APP) in a shopping system, a user can submit an order after selecting and purchasing a required commodity only in a state that the user logs in. When a large number of users log in and submit orders at the same time, the server needs to ensure that the service interface of each user submitting the order is stable and accurate to return the request result. Therefore, it is essential for the APP to stably run to perform performance bottleneck and existing potential risk analysis by performing medium-voltage measurement on the order submitting business interface before the APP is online or regularly maintained.
Fig. 1 is a system architecture diagram of an interface testing method according to an embodiment of the present application, as shown in fig. 1, the system includes a terminal device 11 that can perform data communication with a server 12, and a user can perform configuration of a pressure measurement script and parameters through the terminal device 11. In some embodiments, the terminal device 11 may further randomly generate test data according to the information configured by the user, so as to perform a pressure test or a test on the interface under test. In addition, a database 13 is deployed in the server 12, wherein the database 13 may be a Redis database, an SQL database, or the like, and the database 13 stores parameter data, which includes test data and login state data.
It should be understood that the number of users, terminal devices 11, servers 12, and databases 13 in the system architecture described above is merely exemplary, and that greater or lesser quantities are within the scope of the present application. Also, in the above system, the terminal device 11 may be, for example, a personal computer, a server, a tablet, a mobile phone, a PDA, a notebook, or any other computing device with a networking function. The server 12 may be implemented using a single server or group of servers with greater processing power and greater security. And the networks used therebetween may include various types of wired and wireless networks such as, but not limited to: the internet, local area networks, WIFI, WLAN, cellular communication networks (GPRS, CDMA, 2G/3G/4G/5G cellular networks), satellite communication networks, and so forth.
The existing interface performance test method mainly adopts two schemes, one is to use an open source pressure test tool to develop and configure a performance test script, prepare test data according to the actual requirements of a service scene, then carry out pressure test by using a pressure test command execution script, and finally open a pressure test report for checking and analyzing; and the other is an independent research and development performance test platform which develops functions meeting the customized requirements so as to carry out performance tests of related services. The performance test platforms developed independently mainly include two types, one is secondary packaging and secondary development based on a mainstream open source tool, and the other is developed based on classes and methods provided by a development language. In an actual service scenario, most service interfaces need to ensure that a user can complete a successful request on the premise of login, and a successful request means that a tested system considers that the user has logged in, and the introduced service parameters and the associated service data in the system are correct, and then after executing relevant service logic, a correct response is returned to a requester. Therefore, when the pressure measurement script is executed to perform pressure measurement on the tested service interface, the login interface is required to be called first to obtain login state data of the user, and the login state data is transmitted as service parameter data of the tested interface.
However, in any of the above-described test methods, when the service interface is pressed, the login interface needs to be requested first, and after the login state data is acquired, the service interface needs to be requested, so that interface dependency exists. One method commonly adopted in the industry is to perform pressure measurement together with a login interface when a business interface is subjected to pressure measurement; and the other is that a tester can also develop a functional module to change the interface, so that the pressure test interface can be realized without authentication. However, changing the interface to the development function module is energy-consuming and time-consuming, and has low efficiency and large workload; and the logging interface is easy to become a performance bottleneck in a mode of pressure measurement together with the logging interface when the business interface is pressure-measured, so that the business interface cannot be really pressure-measured, the pressure measurement efficiency of the business interface is directly influenced, and the waste of system resources is caused.
The inventor discovers the reason causing the reduction of the pressure measurement efficiency of the service interface in the process of realizing the application, mainly because of the interface dependence condition of the login interface and the tested service interface, and based on the problems, the processing of the login interface and the tested service interface is separated in the application, so that the login interface is not required to be called again when the service interface is measured, only the pressure measurement performance of the service interface is analyzed, the pressure measurement performance of the service interface is analyzed in a real sense, and the pressure measurement efficiency of the service interface is directly improved.
Based on the above concept, an embodiment of the present application provides an interface testing method, in which when a test instruction sent by a terminal device is received, parameter data is obtained from a local database, where the parameter data includes test data and login state data, where the login state data is data generated after a login request to an interface is made, and then the parameter data is transmitted to a tested interface, so as to test the tested interface according to the parameter data, obtain a test result, and send the test result to the terminal device. When the tested interface is tested, the login state data can be directly obtained from the local database without calling the login interface to obtain the login state data, so that the dependency relationship between the login interface and the service interface can be relieved, the aim of only testing the tested service interface is fulfilled, and the efficiency of testing the service interface can be improved.
The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Fig. 2 is a schematic flowchart of an interface testing method according to an embodiment of the present application, where the interface testing method may be executed by any device that executes the interface testing method, and the device may be implemented by software and/or hardware. In this embodiment, the apparatus may be integrated in the server 12 as shown in fig. 1. As shown in fig. 2, the interface testing method provided in the embodiment of the present application includes the following steps:
step 201: when a test instruction sent by the terminal equipment is received, parameter data are obtained from a local database, the parameter data comprise test data and login state data, and the login state data are data generated after a login interface is requested.
In this step, the test instruction is used to instruct the server to test or pressure test the performance of the tested interface. When testing the tested service interface, the user can send a test instruction to the terminal device, and the terminal device sends the received test instruction to the server. The tested service interface is a service interface waiting for being tested and analyzed.
The local database is a database in the server, and when the pressure measurement tool is used for interface pressure measurement, data interaction with the local database is generated, for example: redis cache database, SQL database, etc., or other databases. The pressure measurement tool is a tool for helping testers to predict performances such as performance and stability of a business system under a simulated real scene, and the pressure measurement tool comprises the following components: LoadRunner, Apache meter, and other test tools for testing system performance.
Specifically, when receiving a test instruction sent by the terminal device, the server acquires parameter data from the local database, where the parameter data includes test data and login state data, and the login state data is data generated after the server calls a login interface through the test data. Illustratively, the login interface is an interface for a user to provide identity information to request access to resources within the system.
It should be understood that before parameter data is obtained from the local database, test data and login state data need to be generated, so that the parameter data generated according to the test data and login state data is saved in the local database. Illustratively, the server generates login state data by acquiring the test data and calling a login interface according to the test data, generates parameter data according to the test data and the login state data, and stores the parameter data in a local database.
Furthermore, the test data is a plurality of lines of information data generated under a simulated service scene, and each line represents user information. The test data mainly comprises two aspects of data, namely, transmission parameter data of the tested service interface and associated service data in the tested system. The test data can be automatically generated by calling a test data generation module in the server, and a plurality of rows of test data can be generated by default after the test data generation module is called, for example: and generating 1000 rows by default, wherein each row of data comprises a 15-bit random value consisting of a mobile phone number and random letters plus numbers.
Optionally, the user may also generate different test data according to actual test requirements. Illustratively, the server receives a request message for generating test data sent by the terminal device, where the request message includes the first amount and the type information, and then randomly generates the first amount of test data according to the type information.
Meanwhile, if the number of generated test data needs to be specified, the number only needs to be transmitted when the test data generation module is called. If random values of other digits need to be generated, only the number of the incoming digits is needed. If more random values need to be generated, only the value representing the random value number needs to be imported.
In addition, the tester may also add a type of test data to be generated in the list of test data generation methods according to company business or test requirements, where the type of test data is type information that is not included in the original test data, for example: contact phone, home address, whether married, etc. For a business system, test data generally consists of uniquely determined random values, so the test data generation method has universality. In the prior art, a tester needs to spend a long time before interface pressure testing to prepare test data, and manually increases or decreases the corresponding data quantity or type according to different service scenes and test requirements, so that the tester has no universality. Therefore, according to the mode of automatically generating the test data in the embodiment of the application, the number and the type information of the test data can be increased or reduced according to the actual requirements of the user, so that the problem of difficulty in preparing the test data can be solved, the pressure test efficiency of the service interface is indirectly improved, and the labor cost is reduced.
After the test data is obtained, the test data is used as a parameter of the login interface and the login interface is requested, so that login state data can be obtained, and the login state of the user is recorded in the data. If the login state data is in the valid period, representing that the user successfully logs in; otherwise, the login interface needs to be revisited to obtain the login state data.
Specifically, the acquisition mode of the login state data includes the following three modes: one is to obtain login state data through a check password; one is to obtain login state data by checking the short message verification code; and the other method is to acquire login state data of the business system by transmitting the existing third-party login state information.
In the process of testing the tested service interface, in order to simplify the login process, for the first login mode, only the test data and the login state data are combined to generate a corresponding correct password; for the second login mode, the login interface of the system needs to be modified to successfully log in without checking the verification code; for the third login method, the login interface of the system needs to be modified to allow the existing login state data to be simulated by passing in the unique id. Meanwhile, the modification of the system login interface is modified in the test environment, and the modification does not influence the business logic in the real production environment.
Furthermore, the test data contains a plurality of preset user information, and the test data and a plurality of users request the login interface to obtain the login state data combination in sequence to generate new parameter data. Wherein, the parameter data stores complete test data and login state data, such as: information such as a mobile phone number, a unique identifier id, a token, a cookie and the like.
After the parameter data is generated, the parameter data can be stored in a local database, and the parameter data is acquired from the local database when the pressure is executed so as to be transmitted to the tested interface.
In this embodiment, the parameter data generated according to the test data and the login state data may be stored in the local database, so that when the interface to be tested is tested, the login state data is obtained directly from the local database without calling the login interface every time, and thus the test efficiency may be improved.
Step 202: and transmitting the parameter data to the tested interface so as to test the tested interface according to the parameter data to obtain a test result.
In this step, the test result refers to a result obtained by performing a performance test on the service performance of the server and the pressure test performance of the interface to be tested through the pressure test script. Service capabilities include the performance of the server when the interface under test is pressed, for example: a memory of the server, a Central Processing Unit (CPU), and the like. The pressure measurement performance of the interface to be measured refers to the performance of the interface to be measured when the interface to be measured is subjected to pressure measurement, for example: response time of the interface under test, error rate, number of Transactions Per Second (TPS), and the like.
In a possible implementation manner, when the interface to be tested is tested according to the parameter data, the service data associated with the interface to be tested may be called from the local database, and the interface to be tested is tested according to the parameter data and the service data, so as to obtain a test result.
Specifically, the service data associated with the tested interface refers to some service data that must be provided before the tested interface is requested. For example: before the shopping APP submits payment, the commodities to be paid need to be added into the shopping cart, and the inventory of the commodities to be paid is not 0. Under the scene, the commodities in the shopping cart correspond to the associated service data of the tested interface.
After the server calls the service data related to the tested interface from the local database, the obtained parameter data and the service data can be transmitted to the tested interface together to test the tested interface, and the returned test result is received, so that whether the tested interface is in accordance with the expectation or not is analyzed according to the test result. The service data related to the tested interface is directly called from the local database, so that the phenomenon that the service data needs to be generated when the interface is tested every time is avoided, and the testing efficiency can be improved.
It can be understood that, in order to timely and accurately retrieve the service data related to the interface under test from the local database when the interface under test is tested, the service data needs to be stored in the local database in advance. For example, the execution logic of the interface under test may be predetermined, and the service data related to the interface under test may be stored in the local database according to the execution logic.
Specifically, the associated service data of the interface under test is inserted into the system cache or the database in advance by calling the data insertion module, where the associated service data is needed by the system under test when the interface under test is executed. The method comprises the following steps that identification id is superposed on associated service data through prefixes in a fixed format, the associated service data are changed into a cache data format which needs to be inserted into a tested service interface and are inserted into a system cache or a database, and the identification id is read from test data; the format of the cache data to be inserted is the format of the data required by the service interface to be tested, and generally, the prefixes of the cache data representing the same service meaning are all consistent. For example: the cached data format representing that the product has been added to the shopping cart is product _ in _ car _ xxx, where xxx is the identification id of the product and product _ in _ car is the prefix. Meanwhile, when the associated service data is inserted into the cache, the system can automatically set the expiration time of the cache, a tester can adjust the cache retention time according to the own needs, and the cache data after the expiration can be automatically cleaned, so that the memory space of the server is released, and the occupation of system resources is avoided.
Furthermore, if the associated service data is inserted into the database, firstly configuring the database and the table to be inserted and the SQL character string of the data to be inserted; if the associated service data is inserted into the system cache, the cached key to be inserted and the character string value corresponding to the value need to be configured first, and if a plurality of caches need to be inserted, a plurality of pairs of key-values need to be configured. When configuring the cache character string or the SQL character string, the test data automatically generated by calling the test data generation module must be combined or spliced, so that the data inserted into the system becomes effective test data. And the associated service data is inserted into a system cache or a database in advance so that when the tested interface is tested, the system can correctly process the request according to the expected logic.
Furthermore, when the tested interface is tested, the universal pressure measurement script configuration needs to be opened and operated by using a pressure measurement tool. The universal pressure test script is a script which is configured in advance by a developer and is used for performing pressure test.
Specifically, fig. 3 is a schematic diagram of testing an interface to be tested, as shown in fig. 3, before performing pressure testing, a tested interface to be tested needs to be configured in advance for a server, a request address url, a request parameter, a response parameter, an information header transmitted to the tested service interface by using two variables including token and cookie are configured in a pressure testing tool, values of the cookie and the token in the request header are respectively replaced by $ { cookie }, $ { token }, and the like, and finally a desired number of concurrent threads is configured. Wherein, the login state information is transmitted to the tested service interface by using the token and the cookie. The general pressure measurement script defaults to starting all concurrent threads within 1 second, and if the pressure of the test is required to be simulated to be gradually increased within a period of time, the general pressure measurement script can be configured to be started within 1 second, for example: the configuration was to start 10000 threads in 10 seconds. And after the configuration is finished, clicking to store, and finishing the configuration of the pressure measurement script.
Furthermore, after the test script is configured, the method of the pressure measurement script execution module can be called to run the pressure measurement script, and the tested interface is tested according to the quantity of the pre-configured concurrent threads and the parameter data to obtain a test result. In this method, a cmd or shell process is started, through which the command to start the test is executed. Wherein, cmd or shell process is the program of the basic function of the bottom layer in the system.
In this embodiment, the interface to be tested is tested according to the pre-configured multiple concurrent threads, and compared with the single-process testing mode, the testing efficiency can be improved by the mode.
Furthermore, the log generated in real time is output to a log file in the process of running the pressure measurement, the result information containing the pressure measurement is output as a report after the pressure measurement is finished, and the report is stored as a file with webpage form content. And the generated file after the pressure test is finished calls a report extraction module method to automatically start a browser and open the generated test report webpage file, so that a tester can analyze the pressure test performance of the tested service interface through the automatically opened result report.
Step 203: and sending the test result to the terminal equipment.
The test report is generated by a pressure test script execution module according to the tested service interface and contains test result information.
In this step, the test report generated after the execution of the pressure test script is returned to the terminal device for the tester to analyze the performance of the tested interface. And meanwhile, data clearing is realized according to the condition of the local database and the test requirement.
In the application, after the tester opens the universal pressure test script and configures the tested service interface information, the tester clicks the execution button, and the server can automatically and continuously call the test data generation module, the data insertion module, the parameter data generation module, open the universal pressure test script and call the pressure test script execution module and the report extraction module. The whole process from data preparation to test completion and test report viewing can be completed by one-key starting, so that the pressure test becomes easy, stable and efficient.
Furthermore, because a large amount of associated service data needs to be prepared in the system for performance testing, after each testing is completed, a large amount of dirty data is generated for the system or the database, waste of storage resources is caused, and unstable operation of the system is easily affected. In addition, in order to ensure that the tester has enough time to analyze the test, in a specific implementation process, the parameter data in the local database may be deleted after a preset time period after the test result is output.
The preset time period may be set according to actual conditions or experience, for example, the preset time period may be a day or 12 hours, and the specific value of the preset time period is not limited in this embodiment of the application.
Specifically, the data removal work is to remove the test data generated by the current pressure test in the database by calling a data removal module. The tester can autonomously select whether to start a data clearing work to clear the data according to the test requirements, the data storage state and other factors. If the database has no storage pressure or needs to retain data for subsequent test analysis or problem location, the data clearing module is not started, and when the test data is not needed, the data clearing module is executed independently to clear the data.
Further, the execution data clearing module needs to configure the connection string and table name of the connection database, and the delete statement to be executed. The condition in the delete statement is to concatenate the information of the parameter data file generated by the parameter data generation module, so that only the data resulting from the next pressure measurement is deleted.
In the embodiment, more humanized experience is provided for the testers by autonomously selecting data cleaning, and the pressure measurement efficiency is further improved.
According to the interface testing method provided by the embodiment of the application, when a testing instruction sent by the terminal equipment is received, the parameter data can be directly obtained from the local database, the parameter data comprise the testing data and the login state data, the parameter data are transmitted to the tested interface, the tested interface is tested according to the parameter data, a testing result is obtained, and finally the testing result is sent to the terminal equipment. The logging state data are directly obtained from the database, so that the logging state data and the test data are combined to generate parameter data, the parameter data are transmitted to the tested service interface for pressure test, the problem that the logging state data can be obtained only by calling the logging interface when the tested interface is tested every time is solved, the service interface is separated from the logging interface when pressure test is executed, all focuses of the pressure test are placed on the service interface, the workload of test tasks is reduced, and the pressure test efficiency of the service interface is improved.
Fig. 4 is a schematic structural diagram of an interface testing apparatus 40 according to an embodiment of the present application, for example, please refer to fig. 4, where the interface testing apparatus 40 may include:
the obtaining module 401 is configured to obtain parameter data from a local database when a test instruction sent by a terminal device is received, where the parameter data includes test data and login state data, and the login state data is data generated after a login interface is requested;
the processing module 402 is configured to transmit the parameter data to the interface to be tested, so as to test the interface to be tested according to the parameter data to obtain a test result;
a sending module 403, configured to send the test result to the terminal device.
In a possible implementation manner, the processing module 402 is specifically configured to: calling service data related to the tested interface from a local database;
and testing the tested interface according to the parameter data and the service data to obtain a test result.
In a possible implementation manner, the processing module 402 is specifically configured to: determining the execution logic of the interface to be tested;
and storing the service data related to the tested interface into a local database according to the execution logic.
In a possible implementation manner, the obtaining module 401 is further configured to obtain test data;
the processing module 402 is further configured to invoke a login interface according to the test data to generate login state data;
the processing module 402 is further configured to generate parameter data according to the test data and the login state data, and store the parameter data in the local database.
In a possible implementation manner, the obtaining module 401 is specifically configured to: receiving a request message which is sent by terminal equipment and used for generating test data, wherein the request message comprises first quantity and type information;
a first amount of test data is randomly generated based on the type information.
In a possible implementation manner, the processing module 402 is further configured to delete the parameter data in the local database after a preset time period after the test result is output.
In a possible implementation manner, the processing module 402 is further configured to test the interface to be tested according to the parameter data according to the number of the concurrent threads configured in advance, so as to obtain a test result. The interface testing apparatus 40 provided in this embodiment of the present application can execute the technical solution of the interface testing method in any embodiment, and the implementation principle and the beneficial effect thereof are similar to those of the interface testing method, and reference may be made to the implementation principle and the beneficial effect of the interface testing method, which is not described herein again.
Fig. 5 is a schematic structural diagram of a terminal device 50 according to an embodiment of the present application, for example, please refer to fig. 5, where the terminal device may include a processor 501 and a memory 502; wherein,
a memory 502 for storing a computer program.
The processor 501 is configured to read the computer program stored in the memory 502, and execute the technical solution of the interface testing method in any of the embodiments according to the computer program in the memory 502.
Alternatively, the memory 502 may be separate or integrated with the processor 501. When the memory 502 is a device separate from the processor 501, the terminal device may further include: a bus for connecting the memory 502 and the processor 501.
Optionally, this embodiment further includes: a communication interface that may be connected to the processor 501 through a bus. The processor 501 may control the communication interface to implement the above-described functions of acquisition and transmission of the terminal device.
The terminal device shown in the embodiment of the present application can execute the technical solution of the interface testing method in any embodiment, and the implementation principle and the beneficial effect of the terminal device are similar to those of the interface testing method, which can be referred to as the implementation principle and the beneficial effect of the interface testing method, and are not described herein again.
An embodiment of the present application further provides a computer-readable storage medium, where a computer execution instruction is stored in the computer-readable storage medium, and when a processor executes the computer execution instruction, the technical solution of the interface testing method in any embodiment is implemented, and an implementation principle and beneficial effects of the technical solution are similar to those of the interface testing method, and reference may be made to the interface implementation principle and the beneficial effects, which are not described herein again.
The embodiment of the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the technical solution of the interface testing method in any of the above embodiments is implemented, and the implementation principle and the beneficial effect of the computer program are similar to those of the interface testing method, which can be referred to as the implementation principle and the beneficial effect of the interface testing method, and are not described herein again.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, a division of a unit is merely a logical division, and an actual implementation may have another division, for example, a plurality of units or components may be combined or 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, devices or units, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network 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 application 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, or in a form of hardware plus a software functional unit.
The integrated module implemented in the form of a software functional module may be stored in a computer-readable storage medium. The software functional module is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a server, or a network device) or a processor (processor) to execute some steps of the methods according to the embodiments of the present application.
It should be understood that the Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the present invention may be embodied directly in a hardware processor, or in a combination of the hardware and software modules within the processor.
The memory may comprise a high-speed RAM memory, and may further comprise a non-volatile storage NVM, such as at least one disk memory, and may also be a usb disk, a removable hard disk, a read-only memory, a magnetic or optical disk, etc.
The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, the buses in the figures of the present application are not limited to only one bus or one type of bus.
The computer-readable storage medium may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.
Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims (10)

1. An interface testing method, comprising:
when a test instruction sent by terminal equipment is received, parameter data are obtained from a local database, the parameter data comprise test data and login state data, and the login state data are data generated after a login interface is requested;
transmitting the parameter data to a tested interface so as to test the tested interface according to the parameter data to obtain a test result;
and sending the test result to the terminal equipment.
2. The method of claim 1, wherein the testing the interface under test according to the parameter data to obtain a test result comprises:
calling service data related to the tested interface from the local database;
and testing the tested interface according to the parameter data and the service data to obtain a test result.
3. The method of claim 2, wherein prior to obtaining the traffic data associated with the tested interface, the method further comprises:
determining execution logic of the interface under test;
and storing the service data related to the tested interface into the local database according to the execution logic.
4. The method according to any one of claims 1-3, wherein before obtaining the parameter data from the local database upon receiving the test instruction sent by the terminal device, the method further comprises:
acquiring the test data;
calling the login interface according to the test data to generate login state data;
and generating the parameter data according to the test data and the login state data, and storing the parameter data into the local database.
5. The method of claim 4, wherein said obtaining said test data comprises:
receiving a request message which is sent by the terminal equipment and used for generating test data, wherein the request message comprises first quantity and type information;
and randomly generating the first quantity of test data according to the type information.
6. The method according to any one of claims 1-3, further comprising:
and deleting the parameter data in the local database after a preset time period after the test result is output.
7. The method according to any one of claims 1-3, wherein the testing the interface under test according to the parameter data to obtain a test result comprises:
and testing the tested interface according to the parameter data according to the number of the preset concurrent threads to obtain a test result.
8. An interface testing apparatus, comprising:
the acquisition module is used for acquiring parameter data from a local database when a test instruction sent by the terminal equipment is received, wherein the parameter data comprises test data and login state data, and the login state data is data generated after a login interface is requested;
the processing module is used for transmitting the parameter data to a tested interface so as to test the tested interface according to the parameter data to obtain a test result;
and the sending module is used for sending the test result to the terminal equipment.
9. A terminal device comprising a processor and a memory; wherein,
the memory to store the processor-executable instructions;
the processor is used for reading the computer program stored in the memory and executing the interface testing method of any one of the claims 1-7 according to the computer program in the memory.
10. A computer-readable storage medium having computer-executable instructions stored thereon, which when executed by a processor, implement the interface testing method of any one of claims 1-7.
CN202111045953.6A 2021-09-07 2021-09-07 Interface test method, device, equipment and storage medium Pending CN113688025A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111045953.6A CN113688025A (en) 2021-09-07 2021-09-07 Interface test method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111045953.6A CN113688025A (en) 2021-09-07 2021-09-07 Interface test method, device, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN113688025A true CN113688025A (en) 2021-11-23

Family

ID=78585577

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111045953.6A Pending CN113688025A (en) 2021-09-07 2021-09-07 Interface test method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN113688025A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114253846A (en) * 2021-12-17 2022-03-29 中国联合网络通信集团有限公司 Automatic test exception positioning method, device and equipment and readable storage medium
CN114745196A (en) * 2022-04-27 2022-07-12 广域铭岛数字科技有限公司 Interface testing method, system, electronic device and readable storage medium

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110221982A (en) * 2019-06-17 2019-09-10 深圳前海微众银行股份有限公司 Performance test methods, device, equipment and the readable storage medium storing program for executing of operation system
CN110297760A (en) * 2019-05-22 2019-10-01 平安普惠企业管理有限公司 Building method, device, equipment and the computer readable storage medium of test data
CN110727575A (en) * 2018-07-17 2020-01-24 腾讯科技(深圳)有限公司 Information processing method, system, device and storage medium
CN111581080A (en) * 2020-04-17 2020-08-25 上海中通吉网络技术有限公司 Method, device, equipment and storage medium for generating interface test data
CN112115058A (en) * 2020-09-25 2020-12-22 建信金融科技有限责任公司 Test method and device, test case generation method and device and test system
CN112463588A (en) * 2020-11-02 2021-03-09 北京健康之家科技有限公司 Automatic test system and method, storage medium and computing equipment

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110727575A (en) * 2018-07-17 2020-01-24 腾讯科技(深圳)有限公司 Information processing method, system, device and storage medium
CN110297760A (en) * 2019-05-22 2019-10-01 平安普惠企业管理有限公司 Building method, device, equipment and the computer readable storage medium of test data
CN110221982A (en) * 2019-06-17 2019-09-10 深圳前海微众银行股份有限公司 Performance test methods, device, equipment and the readable storage medium storing program for executing of operation system
CN111581080A (en) * 2020-04-17 2020-08-25 上海中通吉网络技术有限公司 Method, device, equipment and storage medium for generating interface test data
CN112115058A (en) * 2020-09-25 2020-12-22 建信金融科技有限责任公司 Test method and device, test case generation method and device and test system
CN112463588A (en) * 2020-11-02 2021-03-09 北京健康之家科技有限公司 Automatic test system and method, storage medium and computing equipment

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114253846A (en) * 2021-12-17 2022-03-29 中国联合网络通信集团有限公司 Automatic test exception positioning method, device and equipment and readable storage medium
CN114253846B (en) * 2021-12-17 2024-05-28 中国联合网络通信集团有限公司 Automatic test abnormality positioning method, device, equipment and readable storage medium
CN114745196A (en) * 2022-04-27 2022-07-12 广域铭岛数字科技有限公司 Interface testing method, system, electronic device and readable storage medium
CN114745196B (en) * 2022-04-27 2024-01-02 广域铭岛数字科技有限公司 Interface testing method, system, electronic device and readable storage medium

Similar Documents

Publication Publication Date Title
CN107122258B (en) Method and equipment for checking state code of test interface
US20130054792A1 (en) Cloud-based performance testing of functionality of an application prior to completion of development
CN107436844B (en) Method and device for generating interface use case aggregate
CN110377522B (en) Transaction scene testing method, device, computing equipment and medium
CN110659870A (en) Business audit test method, device, equipment and storage medium
CN113688025A (en) Interface test method, device, equipment and storage medium
US20200379865A1 (en) Distributed website load testing system running on mobile devices
CA3059719C (en) Payment processing method, device, medium and electronic device
CN111539775A (en) Application program management method and device
CN111523849A (en) Resource transaction auditing method and device and server
CN110515924A (en) Database manipulation logic verify method, apparatus, equipment and readable storage medium storing program for executing
CN109688109A (en) The verification method and device of identifying code based on client-side information identification
CN105184559A (en) System and method for payment
CN112579428B (en) Interface testing method, device, electronic equipment and storage medium
CN112380115A (en) Regression testing method and device, electronic equipment and storage medium
CN109992614B (en) Data acquisition method, device and server
CN116955148A (en) Service system testing method, device, equipment, storage medium and product
CN115408298A (en) Test method, device and system
CN115276968A (en) Third-party platform HTTP callback distribution method, system, electronic equipment and storage medium
CN114584500A (en) Asynchronous communication testing method and device and electronic equipment
CN114978970A (en) Data testing system, method, equipment and medium based on user-defined mock platform
CN112416750A (en) Application program boundary testing method and system
CN114428723A (en) Test system, system test method, related device and storage medium
CN113158146A (en) Script management method, script management platform, computing device and medium
CN112272125A (en) Method, system, terminal and storage medium for testing load balancing protocol

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20211123

RJ01 Rejection of invention patent application after publication