Service system interface test method, system and device and storage medium

Abstract

The invention provides a business system interface test method, system and device and a storage medium, and relates to the field of automatic testing, a preset interface test case corresponding to a to-be-tested business system is operated, a call function corresponding to the preset interface test case and a request parameter corresponding to the preset interface test case are obtained, and the call function corresponding to the preset interface test case and the request parameter corresponding to the preset interface test case are obtained according to the request parameter; a request configuration module in a preset interface request library of a to-be-tested service system and a request test module corresponding to the calling function are called through the calling function, the request configuration module classifies requests corresponding to preset interface test cases to obtain request types, and when the request types are preset static data query requests, the request test module sends the requests to the to-be-tested service system. And according to the request parameter, obtaining first test data corresponding to the request parameter from preset static cache data of the to-be-tested service system, and according to the first test data, generating a test result of the preset interface test case. The test efficiency is improved and the test cost is reduced.

Description

Technical Field

[0001] The present application relates to the field of automated testing technology, and in particular to a business system interface testing method, system, device and storage medium. Background Art

[0002] The essence of interface testing is to simulate the front end, send one or a group of requests to the back-end interface, such as the REST interface, in the order of business or business flow logic, and then interact with the system to be tested to achieve operation simulation and achieve the purpose of testing the system function. During the entire test process, the automated test system will interact a lot with the back-end interface of the system to be tested. During the interaction process, the time and data of the request and response are the most important factors affecting the time cost and storage space cost of the entire automated test.

[0003] In the prior art, the script calls the interface request library in the automated test library to request the API interface of the system under test. After the system under test receives the request, the background starts to execute the business logic and returns the result data to the automation framework through the response of the request, so that the script completes the operation of the system under test once. This method corresponds to a longer test time, reduces the efficiency of automated testing, and increases the cost of storing data due to the large number of requests. Summary of the invention

[0004] The purpose of the present invention is to provide a business system interface testing method, system, device and storage medium to address the technical problems of low efficiency and high cost of automated testing in the prior art.

[0005] To achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0006] In a first aspect, an embodiment of the present application provides a business system interface testing method, the method comprising:

[0007] Run the preset interface test case corresponding to the business system to be tested, obtain the calling function corresponding to the preset interface test case, and the request parameters corresponding to the preset interface test case;

[0008] According to the request parameters, through the calling function, calling the request configuration module in the preset interface request library of the business system to be tested and the request test module corresponding to the calling function;

[0009] The request configuration module classifies the requests corresponding to the preset interface test cases to obtain request types;

[0010] When the request type is a preset static data query request, the request test module obtains first test data corresponding to the request parameter from preset static cache data of the business system to be tested according to the request parameter;

[0011] Generate a test result of the preset interface test case based on the first test data.

[0012] Optionally, the method further comprises:

[0013] If the first test data is not obtained from the preset static cache data, the request test module queries the first test data from the service system to be tested according to the request parameter, and caches the first test data as the preset static cache data; or,

[0014] If the first test data is not obtained from the preset static cache data, the request test module queries the first test data from the business system to be tested according to the request parameters when the preset cache update policy corresponding to the preset static cache data is triggered, and caches the first test data as the preset static cache data.

[0015] Optionally, the method further comprises:

[0016] Through the request test module, when the request type is a preset dynamic data query request, according to the request parameters, a preset monitoring subsystem is called to perform log monitoring on the business system to be tested;

[0017] If the request test module receives a monitoring stop response from the preset monitoring subsystem, a query request is sent to the business system to be tested according to the request parameter to obtain second test data corresponding to the request parameter;

[0018] Generate a test result of the preset interface test case based on the second test data.

[0019] Optionally, the request parameters include: business request parameters and log monitoring parameters;

[0020] The calling of a preset monitoring subsystem to perform log monitoring on the business system to be tested according to the request parameters includes:

[0021] According to the log monitoring parameters, calling the preset monitoring subsystem to perform log monitoring on the business system to be tested;

[0022] The querying, from the business system to be tested, second test data corresponding to the request parameter according to the request parameter includes:

[0023] According to the service request parameters, test data corresponding to the service request parameters are queried from the service system to be tested as the second test data.

[0024] Optionally, the classifying the request parameters by the request configuration module to obtain the request type further includes:

[0025] Run the request configuration module, match the request parameters according to multiple preset request classification rules, and if the request parameters match one or more of the multiple preset request classification rules, determine that the request type is a request type that successfully matches the preset request classification rules.

[0026] Optionally, the method further comprises:

[0027] When the request parameter does not match any of the plurality of preset request classification rules, the request configuration module determines that the request parameter is a request that fails to match the rule, and triggers the request test module to query the third test data corresponding to the request parameter from the business system to be tested according to the request parameter;

[0028] Generate a test result of the preset interface test case based on the third test data.

[0029] Optionally, each preset request classification rule includes: a matching condition and a request type;

[0030] The running of the request configuration module to match the request parameters according to a plurality of preset request classification rules includes:

[0031] Running the request configuration module to match the request parameters according to a plurality of preset matching conditions;

[0032] If the request parameter matches one or more matching conditions, the request type is determined to be a request type corresponding to the matching condition.

[0033] In a third aspect, an embodiment of the present application provides an interface testing system, including: a testing framework, a plurality of request interface libraries; each request interface library includes: a request configuration module, and at least one request testing module;

[0034] The test framework is used to run the preset interface test case corresponding to the business system to be tested, obtain the calling function corresponding to the preset interface test case, and the request parameters corresponding to the preset interface test case, and call the request configuration module in the preset interface request library of the business system to be tested and the request test module corresponding to the calling function through the calling function according to the request parameters;

[0035] The request configuration module is used to classify the request parameters to obtain the request type;

[0036] The request test module is used to obtain first test data corresponding to the request parameter from the preset static cache data of the business system to be tested according to the request parameter when the request type is a preset static data query request;

[0037] The test framework is also used to generate the test result of the preset interface test case according to the first test data.

[0038] In a third aspect, an embodiment of the present application provides a computer device, comprising: a storage medium and a processor, wherein the storage medium stores a computer program executable by an interface testing system, and when the processor executes the computer program, it implements the business system interface testing method described in any one of the first aspects above.

[0039] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is read and executed, the business system interface testing method described in any one of the first aspects above is implemented.

[0040] Compared with the prior art, this application has the following beneficial effects:

[0041] The present application provides a business system interface testing method, system, device and storage medium. By running a preset interface test case corresponding to the business system to be tested, a calling function corresponding to the preset interface test case and a request parameter corresponding to the preset interface test case are obtained. According to the request parameter, a request configuration module in a preset interface request library of the business system to be tested and a request test module corresponding to the calling function are called by calling the function. The request configuration module classifies the request corresponding to the preset interface test case to obtain the request type. When the request type is a preset static data query request, the request test module obtains the first test data corresponding to the request parameter from the preset static cache data of the business system to be tested according to the request parameter. According to the first test data, a test result of the preset interface test case is generated. The present application can directly obtain test data from the cache data when the request type is a preset static data query request, without requesting and responding to the system to be tested. Therefore, the efficiency of automated testing is improved, the duration of automated testing is reduced, the number of requests is reduced, and the cost of storing data is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0043] Figure 1 A schematic diagram of the structure of an existing interface automation test system provided in an embodiment of the present application;

[0044] Figure 2 A schematic diagram of the structure of an interface testing system provided in an embodiment of the present application;

[0045] Figure 3 A flowchart of a business system interface testing method provided in an embodiment of the present application;

[0046] Figure 4 A schematic diagram of an interface test interaction provided in an embodiment of the present application;

[0047] Figure 5 A schematic diagram of the structure of another interface testing system provided in an embodiment of the present application;

[0048] Figure 6 A flowchart of another method for testing a business system interface provided in an embodiment of the present application;

[0049] Figure 7 A schematic diagram of another interface test interaction provided in an embodiment of the present application;

[0050] Figure 8 A flowchart of another method for testing a business system interface provided in an embodiment of the present application;

[0051] Fig. 9 A flowchart of another business system interface testing method provided in an embodiment of the present application;

[0052] Fig.10 A schematic diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations.

[0054] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for protection, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present application.

[0055] In the description of the present invention, the terms “first”, “second”, “third”, etc., if used, are only used to distinguish the descriptions and should not be understood as indicating or implying relative importance.

[0056] It should be noted that, in the absence of conflict, the features in the embodiments of the present invention may be combined with each other.

[0057] Automated testing refers to the use of an automated testing system to simulate user operations on the system under test to verify the functions and business logic of the system under test. An automated testing system usually consists of a test framework and a test library.

[0058] In the prior art, a large number of web applications and web-based systems adopt a front-end and back-end separation architecture. Users operate the front-end, which converts the user's operation into corresponding request parameters and initiates a request to the specified interface of the back-end. After receiving the request, the back-end starts to process the business logic, implements the function, and responds to the front-end with the corresponding result. For this type of system under test, automated testing usually uses interface testing to perform testing.

[0059] The essence of interface testing is to simulate the front end, send one or a group of requests to the back end interface, such as the REST interface, in the order of business or business flow logic, and then interact with the system to be tested to realize operation simulation and achieve the purpose of testing system functions.

[0060] During the entire testing process, the automated testing system will interact extensively with the back-end interface of the system under test. During the interaction, the time and data of requests and responses are the most important factors affecting the time cost and storage space cost of the entire automated testing.

[0061] The interface automation test system architecture in the prior art mainly includes an automation test framework and an automation test library, which are used to perform automation testing on the system to be tested. Figure 1 A schematic diagram of the structure of an existing interface automation test system provided in an embodiment of the present application is shown in FIG. Figure 1As shown, the automated testing framework is used to run the test script. The test script calls the interface request library in the automated testing library (for example, the Python "requests library" for the REST interface) to request the API (Application Programming Interface) interface of the system to be tested. After the system to be tested receives the request, the background starts to execute the business logic and returns the result data to the automated testing library through the response to the request, and then returns it to the automated testing framework, so that the test script completes an operation on the system to be tested.

[0062] In the above test process, there are technical problems such as long test time, low automated test efficiency, and a large number of requests, which leads to increased data storage costs. In order to solve this problem, the solution of this application provides an interface testing system. Figure 2 A schematic diagram of the structure of an interface testing system provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the interface test system includes: a test framework, multiple request interface libraries, each request interface library is used to make a request response to the corresponding system to be tested. Each request interface library includes: a request configuration module and at least one request test module.

[0063] The test framework can also be referred to as an automated test framework, which is used to run automated tests. When running an interface test case, the automated test framework will call the interface request library by way of function call to implement requests and access to the system to be tested, wherein the system to be tested can also be referred to as the business system to be tested. In an embodiment of the present application, the test framework is used to run the preset interface test case (preset test script) corresponding to the business system to be tested, obtain the call function corresponding to the preset interface test case, and the request parameters corresponding to the preset interface test case, and according to the request parameters, call the request configuration module in the preset interface request library of the business system to be tested and the request test module corresponding to the call function by calling the function.

[0064] The automation framework calls the "interface request library", which is usually implemented in the form of functions. The parameters of the function contain all the information required to communicate with the "API interface" of the system under test. For example, a common data query request requires an "interface address", such as the REST protocol URL; "interface parameters", such as the PAYLOAD part of the REST protocol; and "response data filtering conditions". If the response data format is JSON, and its data is: {"result":"success","code":"200"}, then when you need to get the value "success", you need to pass in parameters such as "result", where "result" is the response data filtering condition. The request configuration module needs to set rules to match the parameters to identify specific requests.

[0065] The preset interface request library may also be referred to as an interface request library, which can provide the automated test script with the ability to send requests, including but not limited to data query requests.

[0066] The request configuration module is used to classify the request parameters and obtain the request type, that is, the request configuration module is used to configure the basis for distinguishing the request type. Before the request test module initiates a request to the system under test, the request configuration module will be called to classify the request parameters. In an embodiment of the present application, the request type can be a static data query request, that is, the request query data corresponding to the request parameter is data that does not change during the entire test life cycle, such as device identification, device name, etc.

[0067] The request test module may also be referred to as a request module, which is used to obtain first test data corresponding to the request parameters from preset static cache data of the business system under test according to the request parameters when the request type is a preset static data query request (static data query request).

[0068] In an embodiment of the present application, the preset static cache data may be pre-stored in a data cache in an interface request library.

[0069] The automated testing framework is further used to generate a test result of a preset interface test case according to the first test data. For example, the first test data can be compared with a preset test expectation. If they are the same, the test result is a success, and if they are different, the test result is a failure.

[0070] In the above Figure 2 Based on the embodiment of the interface testing system, a business system interface testing method is also provided in the solution of the present application. The following explains a business system interface testing method provided in the embodiment of the present application through specific examples. Figure 3 A flow chart of a business system interface testing method provided in an embodiment of the present application is shown as follows: Figure 3 As shown, the method includes:

[0071] S301, running a preset interface test case corresponding to the business system to be tested, obtaining a calling function corresponding to the preset interface test case, and a request parameter corresponding to the preset interface test case.

[0072] Before the test starts, the tester manually configures the classification rules in the request configuration module.

[0073] At the beginning of the test, the automated testing framework in the automated testing system runs the preset interface test case of the system to be tested, and obtains the calling function corresponding to the preset interface test case. The calling function can be a query request function, or a function for obtaining the request parameters corresponding to the preset interface test case. The request parameters can be a Uniform Resource Locator (URL), business request data, etc.

[0074] S302, calling a request configuration module in a preset interface request library of the business system to be tested and a request test module corresponding to the calling function by calling a function according to request parameters.

[0075] For example, the automated testing framework calls a request module in an interface request library to send a query request, and the request module calls a request configuration module to classify requests corresponding to preset interface test cases.

[0076] S303, the request configuration module classifies the requests corresponding to the preset interface test cases to obtain request types.

[0077] The request configuration module pre-stores the classification rules manually configured by the tester. Therefore, the request corresponding to the preset interface test case can be classified according to the classification rules and the request sampling parameters to obtain the request type corresponding to the request.

[0078] In an embodiment of the present application, the request type may include a preset static data query request, a preset dynamic data query request, etc.

[0079] S304 , when the request type is a preset static data query request, the request test module obtains first test data corresponding to the request parameter from preset static cache data of the business system to be tested according to the request parameter.

[0080] If the request type is a preset static data query request, the request module queries the data cache according to the request parameters, and if the data cache contains test data corresponding to the request parameters, the test data is used as the first test data.

[0081] S305: Generate a test result of a preset interface test case according to the first test data.

[0082] For example, the automated testing framework may compare the first test data with the preset test data, and if they are the same, the automated testing result is that the test is successful.

[0083] A business system interface testing method provided by the present application can directly obtain test data from cached data when the request type is a preset static data query request, without the need to request and respond to the system under test. Therefore, the efficiency of automated testing is improved, the duration of automated testing is reduced, the number of requests is reduced, and the cost of storing data is reduced.

[0084] In the above Figure 3 Based on the business system interface testing method shown, the embodiment of the present application also provides another implementation method of the business system interface testing method. Optionally, the above method also includes:

[0085] If the first test data is not obtained from the preset static cache data, the first test data is queried from the service system to be tested according to the request parameters through the request test module, and the first test data is cached as the preset static cache data.

[0086] Specifically, if there is no first test data in the data cache, a query request is sent to the system under test and the response data is cached. When the request module needs to send the request again, the first test data in the data cache is directly called. After processing, it is returned to the automated testing framework for use, and no query request is sent to the system under test.

[0087] In another achievable method, if the first test data is not obtained from the preset static cache data, the request test module queries the first test data from the business system to be tested according to the request parameters when the preset cache update policy corresponding to the preset static cache data is triggered, and caches the first test data as the preset static cache data.

[0088] Specifically, if there is no first test data in the data cache and the cache needs to be updated according to the cache strategy, a query request is sent to the system under test, and the response data is cached so that the first test data in the data cache is directly returned at the next request.

[0089] A business system interface testing method provided in an embodiment of the present application, if the first test data does not exist in the preset static cache data, it is necessary to send a query request to the system under test to cache the response data, so that the first test data in the data cache can be directly obtained at the next request without sending a query request to the system under test, thereby improving the efficiency of automated testing.

[0090] Above Figure 1In the existing interface automation test system, for the test script, it is necessary to obtain the data of the system to be tested during the test process, so a large number of query data requests will be sent. Taking an automated test case of a network management system as an example, the automatic script needs to implement the "normal addition of equipment and successful online" service test, and the query request needs to be sent as follows: after adding the device through the interface, send a "device information" query request to query the device ID or device name; use the device ID or name obtained in the above step to send a "device status" query request to obtain the current device "online status" and use it for inspection.

[0091] Due to the separation of front-end and back-end architecture of the system under test, and the limitation of the logic processing speed of back-end code and business, the system adopts a large amount of asynchronous business processing logic. For example, in the above use case, after the device is online, the web system will not wait for the device to be successfully online before returning the result of the add request, but will immediately return the addition success after the addition is successful. The online result of the device needs to be obtained by continuously calling the query interface.

[0092] Therefore, the value of the "online status" data mentioned above will continue to change as the background business is processed. Therefore, a single query request cannot accurately obtain the final result of the background processing. The script usually uses a polling method to repeatedly request the online status of the specified device until the online status becomes expected or times out. Figure 4 A schematic diagram of an interface test interaction provided in an embodiment of the present application, such as Figure 4 As shown in the figure, in the test process, the test library of the automated test system actually sent at least one "device information" query + n "device online status" query requests to the system under test. It can be seen that in the current business-based interface automated testing, a large number of requests will be used for querying data operations, which will lead to two serious problems.

[0093] The first problem is that the request response time greatly increases the test time. For query requests that return a large amount of data, especially queries such as device information or topology information, since the background needs to obtain a large amount of data from the database or cache, there is a very high time cost. Some interface responses may even reach seconds, which greatly prolongs the automated testing time. At the same time, since there is often data isolation between use cases, the request results of a use case cannot usually be reused in multiple use cases. For example, the "device ID" query mentioned above, even if the same data is obtained in different test scripts, it will cause a large number of repeated queries due to the isolation of data in the test script environment, and the overall test time. The polling query of asynchronous services will send multiple requests, further extending the test time.

[0094] The second problem is the growth of test log volume. As described in the first problem, since a large amount of data will be returned, each query will write a large amount of data to the automated test log, especially for polling queries of asynchronous services, which will generate query data multiple times, greatly wasting the storage space of the automated test system.

[0095] Most speed optimizations based on interface query requests are usually based on the perspective of use. This kind of optimization is often achieved by caching the response data of the query, such as the solution mentioned in patent CN109684358A "Method and Device for Data Query", which optimizes the return speed of a single request through a two-level cache method and reduces the request time. However, this type of solution cannot be applied to automated testing systems, because at the same time point, the data obtained from the cache and the data obtained from the background of the system to be tested may have inaccurate test results due to differences in the cache cycle, especially for complex asynchronous business tests. At the same time, the problem of too many test logs generated by asynchronous business due to rotation training has not been well solved.

[0096] As for automated testing systems, optimization is more often considered from the perspective of automatic script writing, such as extracting global variables to save reusable data; increasing the training cycle, reducing the number of times the training calls the interface request library, etc. However, this kind of optimization often leads to an increase in the complexity of automated script writing. When writing use cases, in addition to considering business logic, you must also consider script coding and calling, such as when to use global variables and when you need to request a query again. When the business logic or test data structure changes, resulting in a change in the way global variables are used, the script needs to be readjusted, which is costly. And there is no good optimization for request response speed.

[0097] Therefore, in the above Figure 2 Based on the embodiment of the interface testing system, the solution of the present application further provides another interface testing system. The following explains another interface testing system provided in the embodiment of the present application through specific examples. Figure 5 A schematic diagram of another interface testing system provided in an embodiment of the present application is shown in FIG. Figure 5 As shown, the interface test system also includes: a monitoring subsystem.

[0098] The monitoring subsystem includes a log monitoring module and an API interface that interacts with the request module. The monitoring subsystem is used to monitor the data and status of the system under test.

[0099] The monitoring subsystem can run independently on a separate server or on the server of the system under test, and its form includes but is not limited to software programs, containers, etc.

[0100] The request module can trigger the monitoring subsystem to monitor specific logs of the system under test, and respond to the monitoring request when the monitoring is completed.

[0101] Among them, the log monitoring module implements log monitoring of the system under test. The log monitoring module is triggered by the API interface. During operation, the log monitoring module sets the monitoring parameters (log name, monitoring stop conditions, etc.) according to the parameters passed by the API interface, and then starts to monitor the specific log content of the system under test. Once the stop condition is met, it immediately returns to the request module.

[0102] The API interface is used to receive monitoring requests from the request module, call the log monitoring module for processing, wait for the monitoring to end and respond to the monitoring request.

[0103] In the embodiment of the present application, the request module needs to implement API interface communication of the system to be tested and the monitoring subsystem at the same time, and the communication methods can be consistent or different. For example, the API interfaces can all use the REST protocol, and the request module needs to implement the REST protocol communication interaction process through the Python "requests" library.

[0104] exist Figure 5 On the basis of the other interface testing system shown, the solution of the present application also provides another business system interface testing method. The following explains another business system interface testing method provided in the embodiment of the present application through specific examples. Figure 6 A flow chart of another business system interface testing method provided in an embodiment of the present application is shown as follows: Figure 6 As shown, the method includes:

[0105] S601 , through the request test module, when the request type is a preset dynamic data query request, the preset monitoring subsystem is called according to the request parameters to perform log monitoring on the business system to be tested.

[0106] The preset dynamic data query request means that the data queried by the request is asynchronous business status data, such as device online status, configuration delivery results, etc.

[0107] If the request type is a preset dynamic data query request, before sending a query request to the system under test, the request module needs to first send a monitoring request to the API interface of the monitoring subsystem and block it, and then send a query to the system under test after a response or timeout.

[0108] In the embodiment of the present application, after the monitoring subsystem receives the request, the log monitoring module starts monitoring and stops monitoring when the monitoring stop condition (such as log name matching) is met. The monitoring parameters used by the log monitoring module are pre-configured in the request configuration module.

[0109] S602: If the request test module receives a monitoring stop response from the preset monitoring subsystem, a query request is sent to the business system to be tested according to the request parameters to obtain second test data corresponding to the request parameters.

[0110] When the log monitoring module in the monitoring subsystem detects the monitoring stop condition (such as when there is a log matching the log name), the monitoring is stopped, and the monitoring subsystem responds to the previous request to the request module.

[0111] After the request module obtains the monitoring stop response, it sends a query request to the business system to be tested according to the request parameters to obtain the second test data corresponding to the request parameters.

[0112] S603: Generate a test result of a preset interface test case according to the second test data.

[0113] The embodiment of the present application provides a method for testing the interface of a business system. The interface request library obtains the communication method and related monitoring parameters with the sub-monitoring system from the request configuration module, and communicates with the monitoring subsystem in a synchronous business manner, that is, the interface request module will be blocked before receiving the response sent back by the monitoring subsystem, unless the request times out. The interface request library does not rely on the response result of the monitoring subsystem. Once the blocking ends (regardless of normal response or timeout), a real query request will be issued to the system under test to ensure that the request data result finally returned is reliable.

[0114] Figure 7 A schematic diagram of another interface test interaction provided in an embodiment of the present application, such as Figure 7 As shown in the figure, in the test process, taking the request to query the online status of the device as an example, the process is transformed from round-robin training.

[0115] During the entire request process, since all test methods are implemented by the test library, the automated script logic is not affected. For requests that cannot be optimized, the test library can automatically identify and obtain data according to the normal communication process. For query requests, the test library can automatically cache reusable data. At the same time, for asynchronous business status data, the actual query number will be reduced to one. Since the results of log monitoring do not affect the actual query request, the reliability and correctness of the test data are guaranteed while reducing the query number.

[0116] exist Figure 6 On the basis of the other business system interface testing method shown, another business system interface testing method is also provided in the solution of the present application. The following explains another business system interface testing method provided in the embodiment of the present application through specific examples.

[0117] The request parameters include: business request parameters and log monitoring parameters. The above step S601 calls the preset monitoring subsystem to perform log monitoring on the business system to be tested according to the request parameters, including:

[0118] According to the log monitoring parameters, the preset monitoring subsystem is called to perform log monitoring on the business system under test. The log monitoring parameters may be log names, log monitoring stop conditions, etc.

[0119] At this time, the above step S602, according to the request parameters, queries the second test data corresponding to the request parameters from the business system to be tested, including:

[0120] According to the service request parameters, test data corresponding to the service request parameters are queried from the service system to be tested as second test data.

[0121] exist Figure 3 Based on the business system interface testing method shown, another business system interface testing method is also provided in the solution of the present application. The following is an explanation of another business system interface testing method provided by the embodiment of the present application through a specific example. The above step S303 includes:

[0122] Run the request configuration module to match the request parameters according to multiple preset request classification rules. If the request parameters match one or more of the multiple preset request classification rules, determine that the request type is a request type that successfully matches the preset request classification rules.

[0123] On this basis, Figure 8 A flow chart of another business system interface testing method provided in an embodiment of the present application is shown as follows: Figure 8 As shown, the method also includes:

[0124] S801, when a request parameter does not match multiple preset request classification rules, the request configuration module determines that the request parameter is a request that fails to match the rule, and triggers the request test module to query the third test data corresponding to the request parameter from the business system to be tested according to the request parameter.

[0125] If no corresponding item is matched in the request configuration module, the request type is determined to be other requests, and the request is sent to the system under test and the response is processed according to the normal interaction process.

[0126] S802: Generate a test result of a preset interface test case according to the third test data.

[0127] A business system interface testing method provided by an embodiment of the present application realizes the processing of other requests except static data query requests and dynamic data query requests.

[0128] On the basis of the above-mentioned another business system interface testing method, the solution of the present application further provides another business system interface testing method. The following is an explanation of another business system interface testing method provided in the embodiment of the present application through specific examples. Fig. 9 A flow chart of another business system interface testing method provided in an embodiment of the present application is shown as follows: Fig. 9 As shown, each request classification rule includes: matching conditions and request types, running the request configuration module, matching request parameters according to multiple preset request classification rules, including:

[0129] S901, running a request configuration module to match request parameters according to a plurality of preset matching conditions.

[0130] In the embodiment of the present application, the rules of the request configuration module are implemented as follows:

[0131] a. A rule consists of two parameters: "matching condition" and "request type".

[0132] b. "Matching conditions" use request features to distinguish one or more requests. Request features include but are not limited to "interface address", such as the URL address of the REST interface, which can be written as "https: / / .* / # / bdnctrl / device / .*" using regular expressions; "response data filtering conditions", such as xpath that can match XML format response data, key in JSON data format, etc. "Matching conditions" can be a single feature above, or a logical combination of multiple features.

[0133] c. "Request type": mark the request type, and the "request module" will handle it differently according to the marked type. For different types: i. Static data query: When set to this type, you can also configure the cache refresh strategy (optional), including but not limited to: refresh time, whether manual refresh is supported, cache location, etc. ii. Dynamic data query: When specified as this type of data, you also need to configure the following information for "monitoring subsystem" communication and settings: monitoring subsystem "API interface" address; log name; monitoring stop condition (when this condition is met, the monitoring subsystem stops log monitoring and returns a response. Content includes but is not limited to timeout period, filtering keywords, filtering logic, etc.); method of connecting to the system to be tested (content includes but is not limited to local connection, remote protocol type, IP address, user, password, etc.).

[0134] S902: If the request parameter matches one or more of the matching conditions, determine the request type as a request type corresponding to the matching condition.

[0135] In summary Figure 5-Figure 9In the embodiment shown, the present invention mainly solves the technical problems of long test time and low efficiency from the following four aspects:

[0136] First, current automatic test scripts are basically written based on backend business logic. The difference is that synchronous business only needs to be sent once, while asynchronous business needs to be trained in rotation. However, in any case, the automated "interface test library" needs to be called to generate multiple real requests during the entire test cycle. However, the purpose of calling the "interface test library" is essentially to obtain the backend business data of the system to be tested. Therefore, as long as the source and method of the "interface test library" to obtain data are reliable, the automatic script can be tested without training in rotation or even sending requests to the interface of the system to be tested.

[0137] Secondly, in order to achieve reliable data sources and methods, the interface test library needs to design different acquisition processes and logics for different data types. Therefore, when the interface test library is called, it needs to classify the query requests to be sent according to the type of data being queried to adapt to different business scenarios. Based on this, there are mainly two business scenarios that can be optimized based on data types.

[0138] Third, in automated testing, the data of each test case is often independent of each other, and a lot of data will be queried repeatedly, such as querying "device name" or "device ID". This type of data will not change at all during the entire test life cycle. When obtaining it, you only need to query the backend of the system under test once, and then cache the data. When the system under test recognizes the same query call, it can read it directly from the cache.

[0139] Fourthly, for the status data of asynchronous services, such as configuration delivery status, equipment online status, etc., since the data will change with the business process, the ideal situation is to send a query request immediately after the expected status appears in the backend of the system to be tested, and verify the response data. To achieve this query, a notification method can be implemented, that is, the backend of the system to be tested, after actually processing the asynchronous business, actively notifies the automation equipment to query, ensuring the reliability of the data while no longer relying on polling queries.

[0140] Fig.10 A schematic diagram of a computer device provided in an embodiment of the present application, which may be a computing device with computing processing capabilities.

[0141] The computer device includes: a processor 1001 , a storage medium 1002 , and a bus 1003 . The processor 1001 and the storage medium 1002 are connected via the bus 1003 .

[0142] The storage medium 1002 is used to store computer programs executable by the interface test system, and the processor 1001 calls the program stored in the storage medium 1002 to execute the above method embodiment. The specific implementation method and technical effect are similar and will not be repeated here.

[0143] Optionally, the present invention also provides a program product, such as a computer-readable storage medium, comprising a program, which is used to execute the above method embodiment when executed by a processor.

[0144] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. 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 is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0145] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0146] In addition, each functional unit in each embodiment of the present invention 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-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0147] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to perform some steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (English: Read-Only Memory, abbreviated: ROM), random access memory (English: Random Access Memory, abbreviated: RAM), disk or optical disk and other media that can store program codes.

[0148] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A business system interface testing method, characterized in that: The method comprises: Run the preset interface test case corresponding to the business system to be tested, obtain the calling function corresponding to the preset interface test case, and the request parameters corresponding to the preset interface test case; According to the request parameters, through the calling function, calling the request configuration module in the preset interface request library of the business system to be tested and the request test module corresponding to the calling function; The request configuration module classifies the requests corresponding to the preset interface test cases to obtain request types; When the request type is a preset static data query request, the request test module obtains first test data corresponding to the request parameter from preset static cache data of the business system to be tested according to the request parameter; Generate a test result of the preset interface test case based on the first test data.

2. The business system interface testing method according to claim 1, characterized in that: The method further comprises: If the first test data is not obtained from the preset static cache data, the request test module queries the first test data from the service system to be tested according to the request parameter, and caches the first test data as the preset static cache data; or, If the first test data is not obtained from the preset static cache data, the request test module queries the first test data from the business system to be tested according to the request parameters when the preset cache update policy corresponding to the preset static cache data is triggered, and caches the first test data as the preset static cache data.

3. The business system interface testing method according to claim 1, characterized in that: The method further comprises: Through the request test module, when the request type is a preset dynamic data query request, according to the request parameters, a preset monitoring subsystem is called to perform log monitoring on the business system to be tested; If the request test module receives a monitoring stop response from the preset monitoring subsystem, a query request is sent to the business system to be tested according to the request parameter to obtain second test data corresponding to the request parameter; Generate a test result of the preset interface test case based on the second test data.

4. The business system interface testing method according to claim 3, characterized in that: The request parameters include: business request parameters and log monitoring parameters; The calling of a preset monitoring subsystem to perform log monitoring on the business system to be tested according to the request parameters includes: According to the log monitoring parameters, calling the preset monitoring subsystem to perform log monitoring on the business system to be tested; The querying, from the business system to be tested, second test data corresponding to the request parameter according to the request parameter includes: According to the service request parameters, test data corresponding to the service request parameters are queried from the service system to be tested as the second test data.

5. The business system interface testing method according to claim 1, characterized in that: The classifying the request parameters by the request configuration module to obtain the request type also includes: Run the request configuration module, match the request parameters according to multiple preset request classification rules, and if the request parameters match one or more of the multiple preset request classification rules, determine that the request type is a request type that successfully matches the preset request classification rules.

6. The business system interface testing method according to claim 5, characterized in that: The method further comprises: When the request parameter does not match any of the plurality of preset request classification rules, the request configuration module determines that the request parameter is a request that fails to match the rule, and triggers the request test module to query the third test data corresponding to the request parameter from the business system to be tested according to the request parameter; Generate a test result of the preset interface test case based on the third test data.

7. The business system interface testing method according to claim 5, characterized in that: Each preset request classification rule includes: matching conditions and request type; The running of the request configuration module to match the request parameters according to a plurality of preset request classification rules includes: Running the request configuration module to match the request parameters according to a plurality of preset matching conditions; If the request parameter matches one or more matching conditions, the request type is determined to be a request type corresponding to the matching condition.

8. An interface testing system, characterized in that: include: Testing framework, multiple request interface libraries; Each request interface library includes: a request configuration module, and at least one request test module; The test framework is used to run the preset interface test case corresponding to the business system to be tested, obtain the calling function corresponding to the preset interface test case, and the request parameters corresponding to the preset interface test case, and call the request configuration module in the preset interface request library of the business system to be tested and the request test module corresponding to the calling function through the calling function according to the request parameters; The request configuration module is used to classify the request parameters to obtain the request type; The request test module is used to obtain first test data corresponding to the request parameter from the preset static cache data of the business system to be tested according to the request parameter when the request type is a preset static data query request; The test framework is also used to generate the test result of the preset interface test case according to the first test data.

9. A computer device, characterized in that: include: A storage medium and a processor, wherein the storage medium stores a computer program executable by an interface testing system, and the processor implements the business system interface testing method described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is read and executed, the business system interface testing method described in any one of claims 1 to 7 is implemented.

Images