Interface automated testing method, device, equipment and storage medium

Abstract

The present application relates to an interface automation testing method, device, equipment and storage medium, and relates to the field of software testing technology, and aims to solve the problem that some test data are time-sensitive, so developers need to rewrite test cases to test again after each test data update, and generally there are many interfaces to be tested, and repeatedly writing test cases leads to a significant decrease in test efficiency. The technical problem includes: obtaining time-sensitive scenario data in the historical records of the interface to be tested, and generating a test database based on the acquired time-sensitive scenario data; when the interface to be tested needs to be tested, generating an automatic test case; injecting the time-sensitive scenario data in the test database into the automatic test case and loading it; outputting the test return value of the automatic test case in different test environments; comparing the test return value with the expected test changes and outputting the comparison result. The present application has the effect of significantly improving the efficiency of automated testing.

Description

Technical Field

[0001] The present application relates to the field of software testing, and in particular to an interface automation testing method, device, equipment and storage medium. Background Art

[0002] Interface automation testing refers to the process of automatically testing the interface call process to be tested during the code modification process of the interface provided by the system backend to verify whether the interface logic function is correct, thereby improving regression test coverage and test efficiency.

[0003] During the interface release process, the interface will be tested in the development environment in advance. After the test passes, the interface will be installed in the pre-release environment for transition testing, and after the test passes, it will be released to the production environment for use. During the interface testing process, developers generally manually write test cases with test messages, enter them into the test framework to execute the test cases, and use the test framework to simulate the process of calling the interface to be tested. During this process, the interfaces to be tested deployed in the production environment and the pre-release environment are called separately to obtain the return values ​​corresponding to different environments and compare them with the expected changes, thereby generating a test report for the test.

[0004] During the above-mentioned interface testing process, the inventors found that the above-mentioned technology has at least the following problems: since some test data are time-sensitive, developers need to rewrite the test cases and test again each time the test data is updated. However, there are generally many interfaces to be tested, and repeatedly writing test cases leads to a significant decrease in testing efficiency. Summary of the invention

[0005] In order to improve the problem of decreased testing efficiency caused by frequent manual writing of test cases, the present application provides an interface automation testing method, device, equipment and storage medium.

[0006] In the first aspect, the present application provides an interface automation testing method, which adopts the following technical solution:

[0007] An interface automation testing method, comprising:

[0008] Obtaining time-sensitive scenario data from the historical records of the interface to be tested, and generating a test database based on the acquired time-sensitive scenario data;

[0009] When the interface to be tested needs to be tested, automatic test cases are generated;

[0010] Injecting the timeliness scenario data in the test database into the automatic test case and loading it;

[0011] Output the test return value of the automatic test case in different test environments;

[0012] The test return value is compared with the expected test variation and the comparison result is output.

[0013] By adopting the above technical solution, by acquiring the timeliness scenario data in the production environment, the most realistic test database with timeliness can be obtained, and automatic test cases are automatically generated during testing and the timeliness scenario data in the test database are injected into the automatic test cases, so that the automatic test cases carry timeliness parameters, and when the automatic test cases are executed, the interface to be tested can be called based on the timeliness parameters, so as to obtain a timely return value; since the automatic test cases are automatically written and the acquired timeliness scenario data is automatically injected into the automatic test cases for execution, the process of manually screening and selecting timeliness parameters to be written into the automatic test cases is saved, and the test efficiency of the interface to be tested is significantly improved under the premise of ensuring timeliness.

[0014] In a specific implementation scheme, the acquiring of timeliness scenario data in a production environment and generating a test database according to the acquired timeliness scenario data include:

[0015] Regularly obtain the scenario data contained in the history records of the interface to be tested;

[0016] Clean the data and extract timely scene data;

[0017] The timeliness scenario data is labeled according to a preset classification standard, and the historical data corresponding to the labeled data in the test database is replaced.

[0018] By adopting the above technical solution, the timely scenario data that meets the conditions in the scenario data in the production environment can be quickly cleaned out through data cleaning, and invalid parameters in the scenario data can be eliminated, making the timely scenario data concise and effective, thereby improving the testing efficiency of the test case.

[0019] In a specific possible implementation scheme, the periodic acquisition of the scenario data contained in the history records of the interface to be tested includes:

[0020] Get the validity time of the validity parameters of the interface to be tested;

[0021] At intervals of the time limit, the scenario data included in the historical records of the interface to be tested is obtained.

[0022] By adopting the above technical solution, since the timeliness parameters have their own corresponding duration, when the duration is missed, the timeliness parameters lose their timeliness and become invalid parameters. Therefore, it is necessary to re-acquire the scene data once every time the timeliness parameters of the timeliness parameters of the interface to be tested are met, and update them to the test database in real time, so as to maintain the timeliness and validity of the timeliness parameters in the test database.

[0023] In a specific implementation scheme, the test environment includes at least a production environment and a pre-release environment, and the outputting of the test results of the automatic test cases in different test environments includes:

[0024] Obtain data sources for the production environment and the pre-release environment;

[0025] If the two data sources are consistent, the automatic test case is tested in the production environment and the pre-release environment, and the test return value is output;

[0026] If the two data sources are inconsistent, create a download environment with the same data source as the production environment;

[0027] The automatic test cases are tested in the production environment and the load environment, and the test return values ​​are output.

[0028] By adopting the above technical solution, since the production environment needs to be used at all times, the developers may not establish the same data source for the pre-release environment as the production environment when testing the pre-release environment. Therefore, during the testing process, the test results may be affected by inconsistent data sources. Therefore, before starting the test, the data sources of the production environment and the pre-release environment are obtained in advance and compared. If they are consistent, the interface to be tested in the production environment and the pre-release environment can be directly tested and the return value can be output. If the data sources are inconsistent, it is necessary to establish a load environment consistent with the production environment data source for testing, thereby eliminating the impact of the data source on the test results, making the test results for software logic more credible.

[0029] In a specific implementation scheme, establishing a download environment having the same data source as the production environment includes:

[0030] Randomly remove one of the servers in the production environment;

[0031] The interface to be tested is installed on the excluded server.

[0032] By adopting the above technical solution, since the production environment often has a large number of servers forming a server cluster, one server is removed from the production environment and the interface to be tested is installed on the server to become a down-load environment, so that the down-load environment must have the same data source as the production environment. Therefore, the down-load environment with the same data source as the production environment can be established quickly and efficiently.

[0033] In a specific implementation scheme, the generating of automatic test cases includes:

[0034] Get the properties of the interface to be tested and generate the original request message;

[0035] According to the original request message, write a corresponding data retrieval script to obtain time-sensitive scenario data;

[0036] The data retrieval script and the original request message are configured as an automatic test case.

[0037] By adopting the above technical solution, in the process of producing automatic test cases, some non-time-sensitive parameters can be automatically configured by automatically generating original request messages, thereby optimizing the time for configuring parameters and improving the efficiency of generating automatic test cases; on the other hand, by writing data retrieval scripts into automatic test cases, the time-sensitive data in the test database can be automatically retrieved when the automatic test cases are executed, thereby further improving the degree of test automation and test efficiency.

[0038] In a specific possible implementation scheme, injecting the timeliness scenario data in the test database into the automatic test case and loading it includes:

[0039] Execute the data retrieval script to retrieve the time-sensitive scenario data;

[0040] The timeliness scenario data is added to the original request message.

[0041] By adopting the above technical solution, when the automatic test case contains a data retrieval script, if the automatic test case is executed, the data retrieval script is executed first, the timeliness parameters are retrieved from the test database in advance, and then added to the original request message, so that the original request message has the timeliness at the current time. Therefore, while ensuring timeliness, it can reduce the time for manual repetitive writing of test cases, and significantly improve the efficiency of automatic testing.

[0042] In a second aspect, the present application provides an interface automation testing device, which adopts the following technical solution:

[0043] An interface automation testing device, comprising:

[0044] A database generation module is used to obtain time-sensitive scenario data from the historical records of the interface to be tested, and to generate a test database based on the obtained time-sensitive scenario data;

[0045] The test case generation module is used to generate automatic test cases when the interface to be tested needs to be tested;

[0046] A data injection module, used to inject and load the time-sensitive scenario data in the test database into the automatic test case;

[0047] An automatic test module, used to output the test results of the automatic test cases in different test environments; and

[0048] The result output module is used to compare the test result with the expected test change and output the comparison result.

[0049] By adopting the above technical scheme, the timeliness scenario data in the production environment is obtained through the database generation module, and the most realistic test database with timeliness can be obtained; during testing, the test case generation module can automatically generate automatic test cases and inject the timeliness scenario data into the automatic test cases through the data injection module, so that the automatic test cases carry timeliness parameters, and when the automatic test cases are executed, the interface to be tested can be called based on the timeliness parameters, so as to obtain a timely return value; because the automatic test cases are automatically written and the acquired timeliness scenario data is automatically injected into the automatic test cases for execution, the process of manual screening and selection of timeliness parameters to be written into the automatic test cases is saved, and the test efficiency is significantly improved under the premise of ensuring timeliness.

[0050] In a third aspect, the present application provides a computer device, which adopts the following technical solution: it includes a memory and a processor, and the memory stores a computer program that can be loaded by the processor and execute any of the above-mentioned interface automation testing methods.

[0051] In a fourth aspect, the present application provides a computer-readable storage medium, which adopts the following technical solution: storing a computer program that can be loaded by a processor and execute any of the above-mentioned interface automation testing methods.

[0052] In summary, the present application includes at least one of the following beneficial technical effects:

[0053] 1. By acquiring the timeliness scenario data in the production environment, the most realistic test database with timeliness can be obtained. During the test, automatic test cases are automatically generated and the timeliness scenario data is injected into the automatic test cases, so that the automatic test cases carry timeliness parameters. When the automatic test cases are executed, the interface to be tested can be called based on the timeliness parameters, thereby obtaining a timeliness return value. Since the automatic test cases are automatically written and the acquired timeliness scenario data is automatically injected into the automatic test cases for execution, the process of manual screening and selecting timeliness parameters to be written into the automatic test cases is saved, and the test efficiency is significantly improved under the premise of ensuring timeliness.

[0054] 2. Since the production environment often has a large number of servers forming a server cluster, a server is removed from the production environment and the interface to be tested is installed on the server to become the download environment, so that the download environment must have the same data source as the production environment. Therefore, the download environment with the same data source as the production environment can be established quickly and efficiently, thereby eliminating the impact of the data source on the test results, making the test results for software logic more credible;

[0055] 3. In the process of producing automatic test cases, by automatically generating original request messages, some parameters that are not time-sensitive can be automatically configured, thereby optimizing the time for configuring parameters and improving the efficiency of generating automatic test cases; on the other hand, by writing data retrieval scripts into automatic test cases, the time-sensitive data in the test database can be automatically retrieved when the automatic test cases are executed, thereby further improving the degree of test automation and test efficiency. While ensuring timeliness, it can reduce the time for manual repetitive writing of test cases, significantly improving the efficiency of automatic testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 This is a flow chart of an interface automation testing method in an embodiment of the present application;

[0057] Figure 2 yes Figure 1 Flow chart of detailed processing of step 101;

[0058] Figure 3 yes Figure 1 Flow chart of detailed processing of step 103;

[0059] Figure 4 It is a structural block diagram of an interface automation testing device in an embodiment of the present application.

[0060] Explanation of the accompanying drawings: 401, database generation module; 402, test case generation module; 403, data injection module; 404, automatic testing module; 405, result output module. DETAILED DESCRIPTION

[0061] The following is combined with Figure 1-4 This application is described in further detail.

[0062] The embodiment of the present application discloses an interface automation testing method, which is applied to an automation testing host. The automation testing host is based on an automation testing framework, and for an interface to be tested provided by a system backend, such as an API interface, the automation testing case is input into the automation testing framework for automation testing, thereby verifying the logical correctness of the modified interface to be tested. Figure 1 , the interface automation testing method specifically includes:

[0063] Step 101: Acquire timeliness scenario data in the history records of the interface to be tested, and generate a test database according to the acquired timeliness scenario data.

[0064] Among them, the timeliness scenario data in the historical records of the interface to be tested comes from the timeliness scenario data in the production environment. The production environment refers to the environment in which the current interface to be tested is located after it is put into use. For example, the server cluster installed after the travel order interface is put into use is the production environment. When the travel order interface is called, data is obtained from the server cluster, and the data generated by the call of the interface to be tested is stored on the server cluster. At this time, the user can directly access the server corresponding to the production environment; at the same time, the data generated by the user calling the interface to be tested is also stored on the server corresponding to the production environment. The host screens out the timeliness scenario data in the historical records generated by the interface to be tested on the server corresponding to the production environment, and saves it to a separate database, thereby generating a test database that stores timeliness scenario data.

[0065] Step 102: When the interface to be tested needs to be tested, an automatic test case is generated.

[0066] During the specific implementation process, when the host needs to test the interface to be tested, it automatically generates automatic test cases according to preset rules. The content of the automatic test cases includes test objectives, test environment, input data, test steps and expected results. The automatic test cases are automatically run through the test framework. After the automatic test cases are entered into the test framework, the test framework can automatically execute the automatic test cases, so that the return value of the interface to be tested can be obtained by calling the interface to be tested.

[0067] Step 103: inject the timeliness scenario data in the test database into the automatic test case and load it.

[0068] In the specific implementation process, after the host generates the automatic test case, the automatic test case includes timeliness parameters and non-timeliness parameters, and the non-timeliness parameters are automatically configured and generated by the host; when executing the automatic test case, the host can obtain timeliness scenario data from the test database and inject it into the automatic test case, thereby adding the parameters that need to be time-sensitive in the automatic test case, so that the automatic test case can have timeliness attributes when calling the interface to be tested to pass parameters. For example, when calling the interface for the travel order to be tested, the replaced timeliness parameter can be the query timestamp corresponding to the user ID, and the query time node can be calculated by querying the timestamp. The method of injecting timeliness scenario data can be data query and parameter passing, calling the interface or other methods, as long as the appropriate timeliness scenario data can be found from the test database and added to the automatic test case.

[0069] Step 104: output the test return values ​​of the automatic test cases in different test environments.

[0070] During the specific implementation process, after the host injects real-time scenario data into the automatic test case, the automatic test case is tested in the production environment and the pre-release environment, and the test return values ​​in the production environment and the pre-release environment can be obtained. The test return value in the production environment is used as a reference value, and the test return value in the pre-release environment is used as a value to be compared.

[0071] Optionally, in order to save the time of calling the interface to be tested, you can also choose to record the return value corresponding to the production environment as a reference value when obtaining the time-sensitive scenario data in the history record of the interface to be tested, and use the test return value in the pre-release environment as the value to be compared. However, considering the storage cost, the above method of placing the automatic test case in the production environment to obtain the reference value is selected as the preferred implementation method.

[0072] Step 105, compare the test return value with the expected test change and output the comparison result.

[0073] In the specific implementation process, after obtaining the test return values ​​under different test environments, the host compares the test return values ​​under different test environments with the expected test changes and outputs the comparison results. Among them, different test environments include at least a production environment and a pre-release environment, and the pre-release environment can be an environment in which the interface to be tested is about to be released. If the calling logic of the interface to be tested changes, for example, a field for the current time is added to the time of the order to be traveled, then the expected test change is whether the return value of the interface to be tested in the pre-release environment is compared with the return value of the interface to be tested in the production environment. Whether the calling logic of the interface to be tested is normal can be determined by comparing the return value in the pre-release environment with the return value in the production environment; if the field for the current time is added, the output test passes; otherwise, the output test fails. If the call result of the interface to be tested is modified, the expected test change can be whether the return value of the interface to be tested in the pre-release environment is modified at the modified call result relative to the return value of the interface to be tested in the production environment. At this time, by comparing the return value in the pre-release environment with the return value in the production environment, if the change between the return value in the pre-release environment and the return value in the production environment meets the expected test change, the output test passes; otherwise, the output test fails.

[0074] For example, the interface to be tested can be a pending travel order interface. The process of calling the travel order interface is to query the pending travel order data of a certain user at the current time. For example, user Zhang San queried the pending travel order on January 1, 2022. At this time, under the current query timestamp, the time of the pending travel order is a flight order from Fuzhou to Shijiazhuang on March 1, 2022. If the query timestamp is April 1, 2022, at this time, the order is an invalid order. Therefore, the timeliness parameter of the data can be the query timestamp (January 1, 2022) associated with the user ID (Zhang San), and the validity period of the timeliness parameter is 2 months. Now assume that a quick entry for recommending return tickets is added to the ticket order page for non-round-trip ticket orders. The expected test changes are: compared with the return value in the pre-release environment and the production environment, a quick entry for recommending return tickets is added to the ticket order page. At this time, January 1, 2022 associated with user Zhang San is injected into the automatic test case as the timeliness scenario data, and the automatic test case is executed. If the return value adds a quick entry for recommending return tickets on the ticket order page, the test passes; otherwise, the test fails.

[0075] Optionally, you can obtain the timeliness scenario data in the production environment through data cleaning. Figure 2 , the processing of step 101 may be as follows:

[0076] Step 201: regularly obtain scenario data contained in the history records of the interface to be tested.

[0077] In the specific implementation process, the host generates an automatic acquisition task to obtain the scenario data contained in the history records of the interface to be tested from the server connected to the production environment. For example, the host obtains the scenario data generated by the ticket order query from the hive table corresponding to the travel order interface to be tested. The scenario data includes user ID, timestamp, number of records per page, current page number, main applet version, etc.; and the hive table refers to mapping the structured travel order data to be tested into a database table, and provides complete SQL query functions to facilitate querying the contents of the database table.

[0078] Step 202, clean the data and extract time-sensitive scene data;

[0079] In the specific implementation process, after the host obtains the scene data regularly, it cleans the data. The host automatically generates a data cleaning task, sets the cleaning frequency through the scheduled task in the data cleaning task, and then performs data cleaning to extract the timeliness scene data that meets the timeliness of the interface to be tested from the scene data. Among them, the data cleaning process can be obtained from the hive table through SQL statements, and then the obtained scene data is cleaned and written into a dedicated test data hive table for subsequent calls. For example, the data cleaning process in the above-mentioned travel order interface can be: cleaning out the user ID and the corresponding timestamp.

[0080] Step 203: label the timeliness scenario data according to a preset classification standard, and replace the historical data corresponding to the labeled data in the test database.

[0081] In the specific implementation process, after the host cleans the scene data, it labels the time-sensitive scene data according to the preset classification standards, and then replaces the historical data corresponding to the labeled labels in the test database, so that the test database always saves the latest time-sensitive data. The preset classification standards include order types, scene types, etc. For example, all domestic air ticket orders are labeled with domestic air ticket order labels, classified, and the data corresponding to the classification of domestic air ticket orders in the test database is replaced.

[0082] Optionally, since the time-sensitive data has a certain validity period, it is necessary to keep updating at certain intervals to ensure that the data in the test database is time-sensitive during the interface automation test. Therefore, correspondingly, the processing of step 201 can be as follows:

[0083] Get the validity time of the validity parameters of the interface to be tested;

[0084] In the specific implementation process, before the host needs to obtain the scene data contained in the interface history record, it pre-acquires the timeliness of the timeliness parameters of the interface to be tested, that is, the duration of the timeliness data. For example, the timeliness of the order to be paid is only 15 minutes, and the timeliness of the order to be traveled can be the time difference between the query time and the departure time. However, the timeliness of most data can be relaxed to one day, so the timeliness can be used as the basis for the subsequent update frequency calculation.

[0085] Interval aging time, obtain the scenario data contained in the history record of the interface to be tested.

[0086] In the specific implementation process, there is generally only one timeliness parameter for the interface to be tested. To facilitate uniform acquisition, the timeliness period is selected as one day. At each time interval of the host, the scene data generated by the interface to be tested in the production environment is obtained. The scene data generated by the interface to be tested within the past timeliness period is obtained. For example, the scene data of all interface calls in the past day are obtained from the hive table of the interface to be tested for the travel order.

[0087] Optionally, the host can automatically generate automatic test cases based on the properties of the interface to be tested. Figure 3 , step 102 may include the following processing:

[0088] Step 301, obtain the properties of the interface to be tested and generate an original request message.

[0089] In the specific implementation process, after the host generates the test database, before the test is needed for the interface to be tested, the functional attributes of the interface to be tested are obtained in advance. The functional attributes can be the functions implemented by the interface to be tested during the calling process, such as: domestic air ticket orders, travel orders, etc. According to the attributes of the interface to be tested, the template of the original request message can be retrieved from the preset template library to generate the original request message. In the process of generating the original request message, the host will directly configure the parameters that do not need to consider timeliness. For example, the page size parameter in the above-mentioned travel order interface, that is, the number of orders per page, uses the default value of 30; another example is the main applet version number, which is automatically configured according to the attributes of the current interface to be tested.

[0090] Step 302: According to the original request message, a corresponding data retrieval script is written to obtain time-sensitive scenario data.

[0091] In the specific implementation process, after obtaining the properties of the interface to be tested, the host can generate a data retrieval script based on the properties of the interface to be tested. If the interface to be tested does not have timeliness parameters, a corresponding data retrieval script can be written. If the interface to be tested has timeliness parameters, that is, according to the properties of the timeliness parameters, a data retrieval script is written to retrieve the timeliness parameters in the test database.

[0092] Step 303: configure the data retrieval script and the original request message into an automatic test case.

[0093] In the specific implementation process, after the host has written the data retrieval script, it configures the data retrieval script and the original request message into an automatic test case. When the automatic test framework executes the automatic test case, the timeliness parameters in the test database can be retrieved through the data retrieval script.

[0094] Optionally, after the host has written the data retrieval script, the timeliness scenario data in the test database is subsequently injected into the automatic test case and loaded for processing, which may include the following processing:

[0095] Execute the data retrieval script to retrieve time-sensitive scenario data.

[0096] In the specific implementation process, after the host generates the automatic test case, the automatic test framework executes the automatic test case. At this time, the data retrieval script is executed in advance to retrieve the time-sensitive scenario data from the test database.

[0097] Add the time-sensitive scenario data to the original request message.

[0098] In the specific implementation process, after obtaining the time-sensitive scenario data with timeliness, the host adds the timeliness scenario data to the original request message, so that the original request message has timeliness, and the data obtained when the interface is called through the original request message is also time-sensitive. At the same time, the host copies the automatic test cases according to the number of items of the obtained timeliness scenario data, so that the number of automatic test cases matches the number of items of the timeliness scenario data.

[0099] Optionally, in order to eliminate the interference of inconsistent data sources on the test results, step 104 may include the following processing:

[0100] Get the data sources for the production and staging environments.

[0101] In a specific implementation process, after generating an automatic test case, the host obtains the data sources of the production environment and the pre-release environment to be tested. The method of obtaining the data source includes querying the environment name or URL of the data source.

[0102] If the two data sources are consistent, the automatic test cases will be tested in the production environment and the pre-release environment, and the test return values ​​will be output.

[0103] In the specific implementation process, after obtaining the data sources of the production environment and the pre-release environment, the host compares the data sources of the production environment with those of the pre-release environment. If the two data sources are consistent, the host will load the automatic test cases in the production environment and the pre-release environment for testing, and compare the test return values ​​in the production environment and the pre-release environment to verify the test results.

[0104] If the two data sources are inconsistent, create a download environment with the same data source as the production environment.

[0105] In the specific implementation process, if the two data sources are inconsistent, it is necessary to eliminate the impact of inconsistent data sources on the test results. Therefore, the host needs to establish a download environment with the same data source as the production environment. There are many ways to establish a download environment, such as borrowing the data source of the production environment or creating a test environment with a data source that is consistent with the data source of the production environment as the download environment, as long as the data source of the download environment and the production environment can be guaranteed to be consistent.

[0106] The automated test cases are tested in the production environment and the load environment, and the test return values ​​are output.

[0107] In the specific implementation process, after the host establishes a down-load environment with the same data source as the production environment, the interface to be tested is pre-installed in the down-load environment, and then the return values ​​of the interface to be tested in the production environment and the down-load environment are output respectively. At this time, the test return values ​​of the production environment and the down-load environment are compared, which is convenient for comparison with the test results.

[0108] Optionally, the process of establishing the download environment may be implemented by selecting a server in the production environment. Accordingly, the process of establishing the download environment having the same data source as the production environment may specifically include the following processing:

[0109] Randomly remove one of the servers in the production environment.

[0110] In the specific implementation process, the production environment is generally deployed on a server cluster, so there may be a temporarily idle server or a server with low usage rate. When the data source of the host in the production environment is inconsistent with the data source of the pre-release environment, a server in the production environment is randomly removed, so that the real online request cannot access the server, which can greatly reduce the probability of failure of the real online request. In order to minimize the impact on the normal operation of the production environment, the removed servers are preferentially selected as idle servers or servers with low usage rate.

[0111] The interface to be tested is installed on the excluded server.

[0112] In the specific implementation process, after the host removes a server from the production environment, the interface to be tested is installed on the removed server. In this way, the load environment and the production environment can have a consistent data source. In this way, the impact of inconsistent data sources on test results can be eliminated, thereby improving the credibility of the test.

[0113] Optionally, the state of the data source may be verified before testing the interface to be tested. Accordingly, the following processing may be included before step 102:

[0114] Generate a test message for the interface to be tested and compare the return value with the expected result to verify the status of the data source.

[0115] In the specific implementation process, before testing the interface to be tested, the host automatically generates a test message for calling the interface to be tested. At this time, the host automatically executes the test message in the production environment and the pre-release environment through the automatic testing framework to call the interface to be tested. At this time, two return values ​​will be obtained, and the return values ​​will be compared with the expected results respectively. If they are consistent with the expected results, the data source is normal; otherwise, the data source may be abnormal, and the data source needs to be checked.

[0116] Based on the same technical concept, the present application also discloses an interface automation testing device. Figure 4 , the device comprises:

[0117] The database generation module 401 is used to obtain timeliness scenario data in the history records of the interface to be tested, and generate a test database according to the obtained timeliness scenario data;

[0118] The test case generation module 402 is used to generate automatic test cases when the interface to be tested needs to be tested;

[0119] The data injection module 403 is used to inject and load the time-sensitive scenario data in the test database into the automatic test case;

[0120] An automatic test module 404, used to output test results of automatic test cases in different test environments; and

[0121] The result output module 405 is used to compare the test result with the expected test variation and output the comparison result.

[0122] Optionally, the database generation module is specifically used for:

[0123] Regularly obtain the scenario data contained in the history records of the interface to be tested;

[0124] Clean the data and extract timely scene data;

[0125] Label the timeliness scenario data according to the preset classification standards and replace the historical data corresponding to the labeled labels in the test database.

[0126] Optionally, the database generation module can also be used to:

[0127] Get the validity time of the validity parameters of the interface to be tested;

[0128] Interval aging time, obtain the scenario data contained in the history record of the interface to be tested.

[0129] Optionally, the automatic test module is specifically used to:

[0130] Obtain data sources for the production environment and the pre-release environment;

[0131] If the two data sources are consistent, the automatic test cases are tested in the production environment and the pre-release environment, and the test return values ​​are output;

[0132] If the two data sources are inconsistent, create a download environment with the same data source as the production environment;

[0133] The automated test cases are tested in the production environment and the load environment, and the test return values ​​are output.

[0134] Optionally, the automated testing module can also be used to:

[0135] Randomly remove one of the servers in the production environment;

[0136] The interface to be tested is installed on the excluded server.

[0137] Optionally, the test case generation module is specifically used to:

[0138] Get the properties of the interface to be tested and generate the original request message;

[0139] According to the original request message, write the corresponding data retrieval script to obtain the time-sensitive scenario data;

[0140] Configure the data retrieval script into the original request message to form an automatic test case.

[0141] Optionally, the data injection module is specifically used for:

[0142] Execute the data retrieval script to retrieve the time-sensitive scenario data;

[0143] Add the time-sensitive scenario data to the original request message.

[0144] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example for illustration. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0145] The present application also discloses a computer device, referring to Figure 3The computer device includes a memory and a processor, and the memory stores a computer program that can be loaded by the processor and execute an interface automation testing method as described above.

[0146] Based on the same technical concept, an embodiment of the present application also discloses a computer-readable storage medium, including various steps in the above-mentioned interface automation testing method process that can be implemented when loaded and executed by a processor.

[0147] Computer-readable storage media include, for example, various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0148] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories, random access memories, magnetic disks or optical disks.

[0149] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. An interface automation testing method, characterized in that: The method comprises: Obtaining time-sensitive scenario data from the historical records of the interface to be tested, and generating a test database based on the acquired time-sensitive scenario data; When the interface to be tested needs to be tested, automatic test cases are generated; Injecting the timeliness scenario data in the test database into the automatic test case and loading it; Output the test return value of the automatic test case in different test environments; comparing the test return value with the expected test change and outputting the comparison result; The timeliness scenario data in the history record of the interface to be tested is derived from the timeliness scenario data in the production environment, where the production environment refers to the environment in which the current interface to be tested is located after it is put into use; Acquire time-sensitive scenario data in a production environment, and generate a test database based on the acquired time-sensitive scenario data, including: regularly acquiring scenario data contained in the historical records of the interface to be tested; cleaning the data and extracting time-sensitive scenario data; labeling the time-sensitive scenario data according to a preset classification standard, and replacing the historical data corresponding to the labeled labels in the test database, so that the test database always stores the latest time-sensitive data; The test environment includes at least a production environment and a pre-release environment, and the outputting of the test return values ​​of the automatic test cases in different test environments includes: obtaining data sources of the production environment and the pre-release environment; if the two data sources are consistent, the automatic test cases are carried in the production environment and the pre-release environment for testing, and the test return values ​​are output; if the two data sources are inconsistent, a down-load environment having the same data source as the production environment is established; the automatic test cases are carried in the production environment and the down-load environment for testing, and the test return values ​​are output; The establishment of the down-load environment having the same data source as the production environment includes: randomly removing one of the servers in the production environment; installing the interface to be tested on the removed server; The output of the test return value of the automatic test case under different test environments includes: after injecting real-time scenario data into the automatic test case, testing the automatic test case in a production environment and a pre-release environment, and obtaining the test return values ​​in the production environment and the pre-release environment, using the test return value in the production environment as a reference value, and the test return value in the pre-release environment as a value to be compared.

2. The interface automation testing method according to claim 1, characterized in that: The step of periodically obtaining the scene data contained in the history records of the interface to be tested includes: Get the validity time of the validity parameters of the interface to be tested; At intervals of the time limit, the scenario data included in the historical records of the interface to be tested is obtained.

3. The interface automation testing method according to claim 1, characterized in that: The generating of automatic test cases comprises: Get the properties of the interface to be tested and generate the original request message; According to the original request message, write a corresponding data retrieval script to obtain time-sensitive scenario data; The data retrieval script and the original request message are configured as an automatic test case.

4. The interface automation testing method according to claim 3, characterized in that: The injecting and loading the timeliness scenario data in the test database into the automatic test case includes: Execute the data retrieval script to retrieve time-sensitive scenario data; The timeliness scenario data is added to the original request message.

5. An interface automation testing device, characterized in that: The device comprises: A database generation module (401) is used to obtain time-effectiveness scenario data in the history records of the interface to be tested, and to generate a test database according to the obtained time-effectiveness scenario data; A test case generation module (402) is used to generate automatic test cases when the interface to be tested needs to be tested; A data injection module (403) is used to inject and load the time-sensitive scenario data in the test database into the automatic test case; An automatic test module (404), used to output the test return value of the automatic test case under different test environments; and A result output module (405), used to compare the test return value with the expected test change and output the comparison result; The timeliness scenario data in the history record of the interface to be tested is derived from the timeliness scenario data in the production environment, where the production environment refers to the environment in which the current interface to be tested is located after it is put into use; Acquire time-sensitive scenario data in a production environment, and generate a test database based on the acquired time-sensitive scenario data, including: regularly acquiring scenario data contained in the historical records of the interface to be tested; cleaning the data and extracting time-sensitive scenario data; labeling the time-sensitive scenario data according to a preset classification standard, and replacing the historical data corresponding to the labeled labels in the test database, so that the test database always stores the latest time-sensitive data; The test environment includes at least a production environment and a pre-release environment, and the outputting of the test return values ​​of the automatic test cases in different test environments includes: obtaining data sources of the production environment and the pre-release environment; if the two data sources are consistent, the automatic test cases are carried in the production environment and the pre-release environment for testing, and the test return values ​​are output; if the two data sources are inconsistent, a down-load environment having the same data source as the production environment is established; the automatic test cases are carried in the production environment and the down-load environment for testing, and the test return values ​​are output; The establishment of the down-load environment having the same data source as the production environment includes: randomly removing one of the servers in the production environment; installing the interface to be tested on the removed server; The output of the test return value of the automatic test case under different test environments includes: after injecting real-time scenario data into the automatic test case, testing the automatic test case in a production environment and a pre-release environment, and obtaining the test return values ​​in the production environment and the pre-release environment, using the test return value in the production environment as a reference value, and the test return value in the pre-release environment as a value to be compared.

6. A computer device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executes the method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that: A computer program is stored which can be loaded by a processor and execute the method according to any one of claims 1 to 4.

Images