Interface testing method, device, equipment and storage medium

Abstract

The present application provides an interface testing method, device, equipment and storage medium, the method obtains the code of the interface to be tested; uses a branch traversal method to determine all business scenarios of the interface to be tested, wherein each branch corresponds to a business scenario; performs feature extraction processing on the code to obtain the feature value of each branch; performs screening processing in a preset database corresponding to the interface to be tested according to the feature value of each branch to obtain a value space; generates a request message for testing the interface to be tested according to the value space. The test data is taken from the current environment, and only the screening conditions of the test data need to be given, and the script can construct the request message by itself, without the need to maintain the test data itself, so as to achieve complete separation of code and data, with high test efficiency and low cost. At the same time, compared with the random automatic generation of test data or data-driven testing methods, the test data combines the characteristics of the interface to be tested, and the accuracy of the interface test is high.

Description

Technical Field

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

[0002] Interface testing usually involves sending a request message to the interface and verifying whether the received return message meets expectations. In order to ensure test coverage, it is necessary to construct request messages for different business scenarios for the same interface and verify them separately. However, systems with complex business have the following characteristics: a large number of interfaces; a large amount of interactive data; complex associations between interfaces, often with chain-like or mesh-like dependencies; and many branch versions, with different versions corresponding to different test environments and large data differences. This brings great difficulties to the construction of request messages.

[0003] The current interface testing methods mainly include the following: The first is to adopt a data-driven approach, where test data designed in advance for different test cases is stored in a file or database, and the preset test data is read when the test script is executed. The second is to use a random automatic generation of test data.

[0004] However, in a data-driven way, the test data designed in advance for different test cases are stored in files or databases, and the preset test data will be read when the test script is executed. The problem with this method is that for the above-mentioned complex system, on the one hand, when testing the downstream interface, it is often necessary to construct the upstream interface data first, and then call the upstream interface to ensure that the constructed downstream interface data is available. If the number of scenarios to be tested for the downstream interface is N, in order to cover all scenarios, a series of upstream interfaces often need to prepare test data for scenarios that are far greater than N in total. In addition, different data often need to be prepared for different test environments, and the storage and maintenance costs of data rise sharply with the complexity of the system. On the other hand, the test data is limited to the preset range, the data is relatively solidified, and the stock data in each environment database cannot be fully utilized for testing (the data of the test environment is often synchronized from production, and the data samples are extremely valuable). The method of randomly automatically generating test data is adopted. Because most interfaces in complex systems have business relevance, for most fields of the request message, completely randomly generated data cannot pass the business logic verification, and only a small part of the data can be randomly generated. The application effect of this method is not obvious in complex systems

[0005] The data-driven testing method used in the prior art to implement complex testing has low efficiency and high cost; while the testing method that randomly generates test data has low accuracy in test results. Summary of the invention

[0006] The present application provides an interface testing method, device, equipment and storage medium, so as to solve the technical problems in the prior art that the data-driven testing method used to implement complex testing is inefficient and costly; and the testing method that randomly generates test data has low accuracy of test results.

[0007] In a first aspect, the present application provides an interface testing method, comprising:

[0008] Get the code of the interface to be tested;

[0009] Using a branch traversal method, determine all business scenarios of the interface to be tested, wherein each branch corresponds to a business scenario;

[0010] Performing feature extraction processing on the code to obtain a feature value of each branch;

[0011] According to the characteristic value of each branch, screening is performed in a preset database corresponding to the interface to be tested to obtain a value space;

[0012] A request message for testing the interface to be tested is generated according to the value space.

[0013] Here, an embodiment of the present application provides an interface testing method suitable for complex systems. For the interfaces in the complex system, feature extraction processing can be performed on the code of each interface to obtain feature values. According to the feature values, qualified data is screened from the database of the current environment to form a value space, and then the request message of this test scenario is constructed according to the value space. For different interfaces, the test data is taken from the current environment. Only the screening conditions of the test data need to be given, and the script can construct the request message by itself. There is no need to maintain the test data itself, thereby achieving complete separation of code and data. The testing method is simple to implement, and there is no need to prepare a large amount of test data in advance. The testing efficiency is high and the cost is low. At the same time, compared with the method of randomly and automatically generating test data, the test data combines the characteristics of the interface to be tested, and the accuracy of the interface test is high.

[0014] Optionally, generating a request message for testing the interface to be tested according to the value space includes:

[0015] When constructing a request message, for a query interface, a piece of data is randomly selected from the value space to construct the request message;

[0016] For the interface that adds new operations to the database table, first determine the value space in the database based on the characteristic values ​​of each scenario, and randomly select a piece of data from the same scenario, replace the non-repeated fields with random numbers or specific values ​​that meet the conditions, and construct a new request message;

[0017] For interfaces that update or delete database tables, based on the principle of not consuming the original data in the environment, the newly added interface will be called first, or directly inserted into the database to generate one or more data that meet the characteristics of the scenario to be tested, and then the update or deletion operation will be performed on the newly added data.

[0018] Optionally, performing feature extraction processing on the code to obtain a feature value of the interface to be tested includes:

[0019] Extracting the judgment statement in the code;

[0020] According to the judgment statement, a characteristic value of the interface to be tested is determined.

[0021] Among them, the embodiment of the present application can extract the judgment conditions in the code branch of each interface as feature values, which is equivalent to taking the test data from the current environment in the test environment of each branch version, and fitting the business logic of the interface during testing, further improving the accuracy and comprehensiveness of the interface test.

[0022] Optionally, extracting the judgment statement in the code includes:

[0023] According to the preset annotation, the judgment statement in the code is extracted.

[0024] Optionally, performing screening processing in a preset database corresponding to the interface to be tested according to the characteristic value to obtain a value space includes:

[0025] Performing screening in a preset database corresponding to the interface to be tested to obtain all data that meets the characteristic value;

[0026] All the data satisfying the characteristic value are determined as a value space.

[0027] Here, the embodiment of the present application can first find out all the data that meets the verification conditions (i.e., characteristic values) given in a certain branch from the database table, frame the value space, and facilitate determining the request message that conforms to the business logic through the value space, thereby further improving the accuracy of the interface test.

[0028] Optionally, generating a request message for testing the interface to be tested according to the value space includes:

[0029] Obtain a piece of random data in the value space;

[0030] A test message is constructed according to the random data.

[0031] Among them, randomly selecting data to generate messages can reduce the impact of other factors on the test results, further improve the accuracy of interface testing, reduce the complexity of testing, and improve testing efficiency.

[0032] Optionally, after generating a request message for testing the interface to be tested according to the value space, the method further includes:

[0033] An interface test is performed on the interface to be tested according to the request message.

[0034] In a second aspect, an embodiment of the present application provides an interface testing device, including:

[0035] Acquisition module, used to obtain the code of the interface to be tested;

[0036] The branch determination module is used to determine all business scenarios of the interface to be tested by means of branch traversal, wherein each branch corresponds to a business scenario.

[0037] A feature extraction module is used to perform feature extraction processing on the code to obtain a feature value of each branch;

[0038] A screening module, used for performing screening processing in a preset database corresponding to the interface to be tested according to the characteristic value of each branch to obtain a value space;

[0039] A generating module is used to generate a request message for testing the interface to be tested according to the value space.

[0040] Optionally, the feature extraction module is specifically used for:

[0041] When constructing a request message, for query interfaces, a piece of data is randomly selected from the value space to construct a request message; for interfaces that perform new operations on database tables, the value space is first determined in the database based on the characteristic values ​​of each scenario, and a random piece of data is randomly selected from the same scenario data, and the non-repeated fields are replaced with random numbers or specific values ​​that meet the conditions to construct a new request message; for interfaces that will update or delete database tables, in accordance with the principle of not consuming the original data in the environment, the new interface will be called first, or directly inserted into the database to generate one or more data that meet the characteristics of the scenario to be tested, and then the new data will be updated or deleted.

[0042] Optionally, the feature extraction module is specifically used for:

[0043] Extracting the judgment statement in the code;

[0044] According to the judgment statement, a characteristic value of the interface to be tested is determined.

[0045] Optionally, the feature extraction module is further specifically used for:

[0046] According to the preset annotation, the judgment statement in the code is extracted.

[0047] Optionally, the screening module is specifically used for:

[0048] Performing screening in a preset database corresponding to the interface to be tested to obtain all data that meets the characteristic value;

[0049] All the data satisfying the characteristic value are determined as a value space.

[0050] Optionally, the generating module is specifically used for:

[0051] Obtain a piece of random data in the value space;

[0052] A test message is constructed according to the random data.

[0053] Optionally, after the generating module generates a request message for testing the interface to be tested according to the value space, the apparatus further comprises:

[0054] The testing module is used to perform an interface test on the interface to be tested according to the request message.

[0055] In a third aspect, the present application provides an interface testing device, comprising: at least one processor and a memory;

[0056] The memory stores computer-executable instructions;

[0057] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the interface testing method described in the first aspect and various possible designs of the first aspect.

[0058] In a fourth aspect, the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer execution instructions. When a processor executes the computer execution instructions, the interface testing method described in the first aspect and various possible designs of the first aspect is implemented.

[0059] In a fifth aspect, the present invention provides a computer program product, including a computer program, which, when executed by a processor, implements the interface testing method described in the first aspect and various possible designs of the first aspect.

[0060] The interface testing method, apparatus, equipment and storage medium provided by the present application, wherein the method targets interfaces in a complex system, can perform feature extraction processing on the code of each interface to obtain feature values, filter qualified data from the database of the current environment according to the feature values, form a value space, and then construct the request message of this test scenario according to the value space. For different interfaces, the test data is taken from the current environment. Only the screening conditions of the test data need to be given, and the script can construct the request message by itself. There is no need to maintain the test data itself, thus achieving complete separation of code and data. The testing method is simple to implement, and there is no need to prepare a large amount of test data in advance. The testing efficiency is high and the cost is low. At the same time, compared with the method of randomly and automatically generating test data, the test data combines the characteristics of the interface to be tested, and the accuracy of the interface test is high. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0062] Figure 1 A schematic diagram of the structure of a complex system provided in an embodiment of the present application;

[0063] Figure 2 A schematic diagram of an interface test system architecture provided in an embodiment of the present application;

[0064] Figure 3 A flowchart of an interface testing method provided in an embodiment of the present application;

[0065] Figure 4 A schematic diagram of the structure of an interface testing device provided in an embodiment of the present application;

[0066] Figure 5 A schematic diagram of the structure of an interface testing device provided in an embodiment of the present application.

[0067] The above drawings show clear embodiments of the present disclosure, which will be described in more detail below. These drawings and text descriptions are not intended to limit the scope of the present disclosure in any way, but to illustrate the concepts of the present disclosure to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0068] The exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0069] The terms "first", "second", "third", and "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products, or devices.

[0070] Complex systems generally have the following characteristics: (1) There are many system interfaces. (2) The amount of data exchanged between interfaces is large, which is reflected in the large number of fields contained in the interface request and return messages. (3) The associations between interfaces are complex, that is, there are upstream and downstream logical relationships between interfaces. In the business process, the dependency relationship of interfaces is chain-like or mesh-like. For example, Figure 1 A structural diagram of a complex system provided for this application, such as Figure 1As shown in the figure, the complex system includes multiple interfaces (interfaces a, b, c, d, m, n, f, h, etc., where the number and structure of interfaces are only for illustration), and each interface includes multiple branches (branches 1-b1, 1-b2, 1-b3, 1-b4, 1-b5, 1-b6, 1-b7, 1-b88, etc., where the number and structure of branches are only for illustration, b1, b2, b3, b4, b5, b6, b7, b8 are all positive integers, and the values ​​can be determined according to the actual situation). That is, after the output data of one or more upstream interfaces are stored in the corresponding database table, the downstream interface has a data source. For example, only after the order interface is called to generate an order can the query interface be called to view the order status. Because the different branches of each interface represent different business scenarios in actual applications, all branches should be covered as much as possible in the test. (4) The system has many branch versions. For example, the system needs to be deployed by province, and most functions are the same between different provinces, but a small number of functions are different, that is, they are divided into different branch versions. To ensure quality, it is often necessary to build test environments for different branches. The database data of each environment is usually synchronized from the respective production database. As a result, the data of different environments are quite different.

[0071] There are mainly the following methods for current interface testing: (1) Data-driven approach. Test data designed in advance for different test cases is stored in a file or database, and the preset test data is read when the test script is executed. The problem with this approach is that, for the above-mentioned complex system, on the one hand, when testing the downstream interface, it is often necessary to first construct the upstream interface data and then call the upstream interface to ensure that the constructed downstream interface data is available. If the number of scenarios to be tested for the downstream interface is N (N is an arbitrary positive integer), then in order to cover all scenarios, a series of upstream interfaces often need to prepare test data for scenarios that are far greater than N in total. Different data often need to be prepared for different test environments, and the storage and maintenance costs of data increase sharply with the complexity of the system. On the other hand, the test data is limited to a preset range, and the data is relatively fixed, and the stock data in each environment database cannot be fully utilized for testing (the data of the test environment is often synchronized from production, and the data samples are extremely valuable). (2) Random automatic generation of test data is adopted. Because most interfaces in complex systems have business relevance, for most fields of the request message, completely randomly generated data cannot pass the business logic verification, and only a small part of the data can be randomly generated. This method is not effective in complex systems.

[0072] In order to solve the above problems, the present application provides an interface testing method, device, equipment and storage medium. The embodiment of the present application proposes a method for automatically constructing interface test data in multiple environments for a system with highly coupled services. The method automatically filters data that meets each business scenario from the current environment through business feature values ​​and constructs request messages, thereby realizing the full-scenario traversal test of any interface in a complex business chain and the need for one set of scripts to be applicable to multiple environments. In this method, the test data for different interfaces is taken from the current environment. Only the screening conditions for the test data need to be given, and the script can construct the request message by itself without maintaining the test data itself.

[0073] For systems with highly coupled businesses, the interface testing method automatically filters and constructs test data through business feature values, realizing the need for full-scenario traversal testing of any interface in a complex business chain.

[0074] Optional, Figure 2 A schematic diagram of an interface test system architecture provided in this application. Figure 2 In the above architecture, the above architecture includes at least one of a data acquisition device 201, a processing device 202 and a display device 203.

[0075] It is understandable that the structure illustrated in this application does not constitute a specific limitation on the architecture of the interface test system. In other feasible implementations of this application, the above architecture may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently, which can be determined according to the actual application scenario and is not limited here. Figure 2 The components shown may be implemented in hardware, software, or a combination of software and hardware.

[0076] In a specific implementation process, the data acquisition device 201 may include an input / output interface and may also include a communication interface. The data acquisition device 201 may be connected to the processing device via the input / output interface or the communication interface.

[0077] The processing device 202 can target different interfaces, and the test data is taken from the current environment. It only needs to give the screening conditions of the test data, and the script can construct the request message by itself without maintaining the test data itself.

[0078] The display device 203 may also be a touch display screen or a screen of a terminal device, which is used to receive user instructions while displaying the above content to achieve interaction with the user.

[0079] It should be understood that the above-mentioned processing device can be implemented by a processor reading instructions in a memory and executing the instructions, or it can be implemented by a chip circuit.

[0080] In addition, the network architecture and business scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided by this application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided by this application are also applicable to similar technical problems.

[0081] The technical solution of this application is described in detail below:

[0082] Optionally, Figure 3 The following is a flowchart of an interface testing method provided by this application. The execution subject of this application can be Figure 2 The specific execution subject can be determined according to the actual application scenario. Figure 3 As shown, the method comprises the following steps:

[0083] S301: Obtain the code of the interface to be tested.

[0084] S302: Determine all business scenarios of the interface to be tested by using a branch traversal method.

[0085] Among them, each branch corresponds to a business scenario.

[0086] S303: Perform feature extraction processing on the code to obtain a feature value of each branch.

[0087] Optionally, feature extraction processing is performed on the code to obtain feature values ​​of the interface to be tested, including: extracting judgment statements in the code; and determining the feature values ​​of the interface to be tested according to the judgment statements.

[0088] Among them, the present application can extract the judgment conditions in the code branch of each interface as feature values, which is equivalent to taking the test data from the current environment in the test environment of each branch version, and fitting the business logic of the interface during testing, further improving the accuracy and comprehensiveness of the interface test.

[0089] Optionally, the judgment statement in the code may be extracted through user input.

[0090] Optionally, extracting the judgment statement in the code includes: extracting the judgment statement in the code according to a preset annotation.

[0091] Optionally, the preset annotations here may be pre-stored in the database after receiving the user's input, or may be automatically saved and generated.

[0092] Optionally, the preset annotation can receive user input and be updated in real time.

[0093] Among them, the preset annotations here can be determined according to actual conditions, and this application does not make specific restrictions.

[0094] In a possible implementation, for example, the method definition of the controller layer in the code is automatically detected, annotations such as "@GetMapping", "@PostMapping", and "@PutMapping" are found, and each if judgment branch therein is automatically extracted.

[0095] In a possible implementation, the judgment condition in each interface code branch is extracted as a feature value. For example, if a branch judgment condition of the interface is if (parameter1 ==: "aa" and parameter2 = "bb"), the feature value is parameter1 == "aa" and parameter2 = "bb". After that, according to the feature value, the data that meets the condition is filtered from the database of the current environment to form a value space, and then a piece of data is randomly selected in the value space to construct the request message of this test scenario.

[0096] This is equivalent to taking the test data from the current environment in the test environment of each branch version. By simply giving the screening conditions for the test data, the script can construct the request message by itself without maintaining the test data itself, thus achieving complete separation of code and data.

[0097] S304: According to the characteristic value of each branch, a screening process is performed in a preset database corresponding to the interface to be tested to obtain a value space.

[0098] The preset database here is a database corresponding to the current environment of the interface to be tested.

[0099] Optionally, according to the characteristic value, a screening process is performed in a preset database corresponding to the interface to be tested to obtain a value space, including:

[0100] Perform screening in the preset database corresponding to the interface to be tested to obtain all data that meet the characteristic values;

[0101] All data satisfying the characteristic values ​​are determined as the value space.

[0102] Here, the application can first find out all the data that meets the verification conditions (i.e., characteristic values) given in a certain branch from the database table, frame the value space, and facilitate determining the request message that conforms to the business logic through the value space, thereby further improving the accuracy of the interface test.

[0103] S305: Generate a request message for testing the interface to be tested according to the value space.

[0104] Among them, according to the value space, a request message for testing the interface to be tested is generated, including:

[0105] When constructing a request message, for query interfaces, a piece of data is randomly selected from the value space to construct a request message; for interfaces that perform new operations on database tables, the value space is first determined in the database based on the characteristic values ​​of each scenario, and a random piece of data is randomly selected from the same scenario data, and the non-repeated fields are replaced with random numbers or specific values ​​that meet the conditions to construct a new request message; for interfaces that will update or delete database tables, in accordance with the principle of not consuming the original data in the environment, the new interface will be called first, or directly inserted into the database to generate one or more data that meet the characteristics of the scenario to be tested, and then the new data will be updated or deleted.

[0106] Among them, the specific value that meets the conditions can be determined according to actual conditions, and the embodiments of the present application do not impose specific restrictions on this.

[0107] Optionally, a request message for testing the interface to be tested is generated according to the value space, including:

[0108] Get a random data in the value space;

[0109] Construct a test message based on random data.

[0110] Among them, randomly selecting data to generate messages can reduce the impact of other factors on the test results, further improve the accuracy of interface testing, reduce the complexity of testing, and improve testing efficiency.

[0111] Optionally, after generating a request message for testing the interface to be tested according to the value space, the method further includes:

[0112] Perform interface test on the interface to be tested according to the request message.

[0113] The present application provides an interface testing method suitable for complex systems. For the interfaces in the complex system, feature extraction processing can be performed on the code of each interface to obtain feature values, and qualified data can be screened from the database of the current environment according to the feature values ​​to form a value space, and then the request message of this test scenario is constructed according to the value space. For different interfaces, the test data is taken from the current environment. Only the screening conditions of the test data need to be given, and the script can construct the request message by itself. There is no need to maintain the test data itself, thereby achieving complete separation of code and data. The testing method is simple to implement, and there is no need to prepare a large amount of test data in advance. The testing efficiency is high and the cost is low. At the same time, compared with the method of randomly and automatically generating test data, the test data combines the characteristics of the interface to be tested, and the accuracy of the interface test is high.

[0114] When constructing a request message, we first find all data that meets the given verification condition (i.e., feature value) in a branch from the database table, define the value space, and then randomly select a piece of data from this value space to construct the request message. Each branch is constructed in this way, and traversing all branches is equivalent to traversing all scenarios.

[0115] For each interface of a complex system, the request message is determined in combination with the scenario of the interface, without the need to test the entire system; the technical effect that this protection point can achieve is a simple test method, high test efficiency and low cost. For an interface, the characteristic value is filtered according to the judgment conditions of the interface, so as to obtain test data that is more suitable for the interface; the technical effect that this protection point can achieve is high test accuracy.

[0116] In a possible implementation, for each interface of a complex system, the interface testing method is as follows:

[0117] 1: First get the code of the interface to be tested;

[0118] 2: Use branch traversal to determine all business scenarios of the interface to be tested.

[0119] 3: Determine the characteristic value of the scenario based on the judgment statement of each branch. For example, if the judgment condition of a branch of the interface is if (parameter1 == "aa" and parameter2 = "bb"), then the characteristic value is parameter1 == "aa" and parameter2 = bb".

[0120] 4: When constructing a request message, we will first find all data that meets the given verification condition (i.e., feature value) in a branch from the database table, define the value space, and then randomly select a piece of data from this value space to construct the request message. Each branch is constructed in this way, and traversing all branches is equivalent to traversing all scenarios.

[0121] 5: When constructing a request message, for query interfaces, randomly select a piece of data in the value space to construct a request message; for interfaces that will perform new operations on database tables, first query all existing data in the database according to the characteristic values ​​of each scene (determine the value space), and randomly select a piece of data in the same scene data, replace the non-repeated fields with random numbers or specific values ​​that meet the conditions, and construct a new request message. For interfaces that will update or delete database tables, in accordance with the principle of not consuming the original data in the environment, first call the new interface (or directly insert it into the database) to generate one or more data that meet the characteristics of the scene to be tested, and then update or delete the new data.

[0122] Figure 4 A schematic diagram of the structure of an interface testing device provided in this application, such as Figure 4 As shown, the device of the present application includes: an acquisition module 401, a branch determination module 402, a feature extraction module 403, a screening module 404 and a generation module 405. The interface test device here can be the above-mentioned processing device, the processor itself, or a chip or integrated circuit that implements the function of the processor. It should be noted here that the division of the acquisition module 401, the branch determination module 402, the feature extraction module 403, the screening module 404 and the generation module 405 is only a division of logical functions, and the two can be physically integrated or independent.

[0123] Among them, the acquisition module is used to obtain the code of the interface to be tested;

[0124] The branch determination module is used to determine all business scenarios of the interface to be tested by branch traversal, where each branch corresponds to a business scenario.

[0125] The feature extraction module is used to perform feature extraction processing on the code to obtain the feature value of each branch;

[0126] A screening module is used to perform screening processing in a preset database corresponding to the interface to be tested according to the characteristic value of each branch to obtain a value space;

[0127] The generation module is used to generate a request message for testing the interface to be tested according to the value space.

[0128] Optionally, the feature extraction module is specifically used for:

[0129] When constructing a request message, for a query interface, a piece of data is randomly selected from the value space to construct the request message;

[0130] For the interface that adds new operations to the database table, first determine the value space in the database based on the characteristic values ​​of each scenario, and randomly select a piece of data from the same scenario, replace the non-repeated fields with random numbers or specific values ​​that meet the conditions, and construct a new request message;

[0131] For interfaces that update or delete database tables, based on the principle of not consuming the original data in the environment, the newly added interface will be called first, or directly inserted into the database to generate one or more data that meet the characteristics of the scenario to be tested, and then the update or deletion operation will be performed on the newly added data.

[0132] Optionally, the feature extraction module is specifically used for:

[0133] Extract the judgment statements in the code;

[0134] According to the judgment statement, the characteristic value of the interface to be tested is determined.

[0135] Optionally, the feature extraction module is further specifically used for:

[0136] Extract judgment statements in the code based on preset annotations.

[0137] Optionally, the screening module is specifically used for:

[0138] Perform screening in the preset database corresponding to the interface to be tested to obtain all data that meet the characteristic values;

[0139] All data satisfying the characteristic values ​​are determined as the value space.

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

[0141] Get a random data in the value space;

[0142] Construct a test message based on random data.

[0143] Optionally, after the generation module generates a request message for testing the interface to be tested according to the value space, the apparatus further includes:

[0144] The test module is used to perform interface test on the interface to be tested according to the request message.

[0145] In order to implement the above method, the present disclosure also provides an interface testing device.

[0146] refer to Figure 5 , which shows a schematic diagram of the structure of an interface test device 500 suitable for implementing the present disclosure, and the interface test device 500 may be a terminal device or a server. The terminal device may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (Portable Android Devices, PADs), portable multimedia players (PMPs), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The interface testing device shown is only an example and should not bring any limitation to the function and scope of use of the present disclosure.

[0147] like Figure 5As shown, the interface test device 500 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 to a random access memory (RAM) 503. Various programs and data required for the operation of the interface test device 500 are also stored in the RAM 503. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0148] Typically, the following devices may be connected to the I / O interface 505: input devices 506 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 508 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 509. The communication devices 509 may allow the interface test device 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5 The interface testing apparatus 500 is shown with various devices, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0149] In particular, according to the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such a case, the computer program can be downloaded and installed from the network through the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of the present disclosure are executed.

[0150] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0151] The computer-readable medium may be included in the interface testing device; or may exist independently without being assembled into the interface testing device.

[0152] The computer-readable medium carries one or more programs. When the one or more programs are executed by the interface testing device, the interface testing device executes the method shown above.

[0153] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0154] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the various systems, methods and computer program products disclosed herein. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0155] The units described in the present disclosure may be implemented by software or hardware. The name of a unit does not limit the unit itself in some cases. For example, the first acquisition unit may also be described as a "unit for acquiring at least two Internet Protocol addresses".

[0156] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0157] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0158] The interface testing device of the present application can be used to execute the technical solutions in the above-mentioned methods of the present application. Its implementation principles and technical effects are similar and will not be repeated here.

[0159] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement any of the above-mentioned interface testing methods.

[0160] The present application also provides a computer program product, including a computer program, which is used to implement any of the above-mentioned interface testing methods when executed by a processor.

[0161] In the several provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the devices described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0162] In addition, each functional unit in the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0163] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and are to be regarded as exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0164] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. An interface testing method, It is characterized in that include: Get the code of the interface to be tested; Using a branch traversal method, determine all business scenarios of the interface to be tested, where each branch corresponds to a business scenario; Performing feature extraction processing on the code to obtain a feature value of each branch; According to the characteristic value of each branch, screening is performed in a preset database corresponding to the interface to be tested to obtain a value space; Generating a request message for testing the interface to be tested according to the value space; The step of generating a request message for testing the interface to be tested according to the value space includes: When constructing a request message, for a query interface, a piece of data is randomly selected from the value space to construct the request message; For the interface that adds new operations to the database table, first determine the value space in the database according to the characteristic value of each scene, and randomly select a piece of data from the same scene, replace the non-repeated field content with a random number or a specific value that meets the conditions, and construct a new request message; For the interface that will update or delete the database table, call the new interface to generate one or more data that meet the characteristics of the scenario to be tested, and update or delete the newly added data; or For interfaces that update or delete database tables, directly insert one or more pieces of data that meet the characteristics of the scenario to be tested into the database, and perform update or delete operations on the inserted data.

2. The method according to claim 1, It is characterized in that The performing feature extraction processing on the code to obtain a feature value of each branch includes: Extracting the judgment statement in the code; According to the judgment statement, a characteristic value of the interface to be tested is determined.

3. The method according to claim 2, It is characterized in that The extracting the judgment statement in the code includes: According to the preset annotation, the judgment statement in the code is extracted.

4. The method according to claim 1, It is characterized in that The filtering process is performed in the preset database corresponding to the interface to be tested according to the characteristic value of each branch to obtain the value space, including: Performing screening in a preset database corresponding to the interface to be tested to obtain all data that meets the characteristic value; All the data satisfying the characteristic value are determined as a value space.

5. The method according to claim 1, It is characterized in that The step of generating a request message for testing the interface to be tested according to the value space includes: Obtain a piece of random data in the value space; A test message is constructed according to the random data.

6. The method according to any one of claims 1 to 5, It is characterized in that After generating a request message for testing the interface to be tested according to the value space, the method further includes: An interface test is performed on the interface to be tested according to the request message.

7. An interface testing device, It is characterized in that include: Acquisition module, used to obtain the code of the interface to be tested; A branch determination module, used to determine all business scenarios of the interface to be tested by means of branch traversal, wherein each branch corresponds to a business scenario; A feature extraction module is used to perform feature extraction processing on the code to obtain a feature value of each branch; A screening module, used for performing screening processing in a preset database corresponding to the interface to be tested according to the characteristic value of each branch to obtain a value space; A generating module, used for generating a request message for testing the interface to be tested according to the value space; The generation module is specifically used to construct a request message. For a query interface, a piece of data is randomly selected from the value space to construct a request message; for an interface that performs a new operation on a database table, a value space is first determined in the database according to the characteristic value of each scene, and a piece of data in the same scene is randomly selected, and the non-repeated field content is replaced with a random number or a specific value that meets the conditions to construct a new request message; for an interface that will perform an update or delete operation on a database table, a new interface will be called first to generate one or more data that meet the characteristics of the scene to be tested, and then an update or delete operation is performed on the new data; or, for an interface that will perform an update or delete operation on a database table, one or more data that meet the characteristics of the scene to be tested is directly inserted into the database, and then an update or delete operation is performed on the inserted data.

8. An interface testing device, It is characterized in that include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the interface testing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the interface testing method according to any one of claims 1 to 6 when executed by a processor.

10. A computer program product comprising a computer program, It is characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images