Interface testing methods, apparatus, storage media and electronic devices

Abstract

This disclosure relates to an interface testing method, apparatus, storage medium, and electronic device. The method includes: acquiring an interface testing configuration file, which includes preset test rules for comparing interface return values ​​and interface data stored in a database of a benchmark system and a system under test; initiating interface call requests and database data query requests to the benchmark system and the system under test according to the preset test rules, and comparing the return values ​​returned by the benchmark system and the system under test in response to the interface call requests and database data query requests to obtain interface return value comparison results and interface data stored in a database comparison results; determining whether the interface function of the system under test is correct based on the interface return value comparison results, and determining whether the interface return values ​​of the system under test are correctly stored in the database based on the interface data stored in the database comparison results. Using this method, the accuracy of interface testing results can be improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of automation testing, in particular, to an interface testing method and device, a storage medium and an electronic device. BACKGROUND

[0002] Since interface testing has the advantages of low cost and high return, more and more testers begin to test the system interface. At the same time, more and more tools and frameworks for interface testing are also emerging.

[0003] In the related art, the interface testing method is specifically as follows: two different versions of system instances to be compared are set, a sending module is used to send the same request to the two systems to be compared, and then the results output by the two systems to be compared are compared to generate a Diff test report. Although this method can test whether the interfaces of the two systems to be compared are connected, it cannot accurately determine whether the interface functions of the two systems to be compared are correct. SUMMARY

[0004] This summary is provided to introduce a selection of concepts, which will be described with greater specificity in the detailed description section. This summary is not intended to identify key or essential features of the claimed technology, nor is it intended to limit the scope of the claimed technology.

[0005] In a first aspect, the present disclosure provides an interface testing method, comprising: obtaining an interface testing configuration file, wherein the interface testing configuration file comprises a preset testing rule for comparing interface return values and interface database drop data of a reference system and a system to be tested, the preset testing rule is used to verify whether the interface function of the system to be tested is correct, and whether the interface return value of the system to be tested can be correctly dropped into the database, wherein the system to be tested is a system upgraded from the reference system; initiating an interface calling request and a database drop data query request to the reference system and the system to be tested according to the preset testing rule, and comparing the return values returned by the reference system and the system to be tested in response to the interface calling request and the database drop data query request to obtain an interface return value comparison result and an interface database drop data comparison result; determining whether the interface function of the system to be tested is correct according to the interface return value comparison result, and determining whether the interface return value of the system to be tested is correctly dropped into the database according to the interface database drop data comparison result.

[0006] In a second aspect, the present disclosure provides an interface testing device, comprising: an obtaining module configured to obtain an interface testing configuration file, the interface testing configuration file comprising preset testing rules for comparing interface return values and interface database drop data of a reference system and a system to be tested, the preset testing rules being used to verify whether the interface function of the system to be tested is correct and whether the interface return values of the system to be tested can be correctly dropped into a database, wherein the system to be tested is a system upgraded from the reference system; a calling module configured to initiate an interface calling request and a database drop data query request to the reference system and the system to be tested according to the preset testing rules, and compare return values returned by the reference system and the system to be tested in response to the interface calling request and the database drop data query request to obtain an interface return value comparison result and an interface database drop data comparison result; and an executing module configured to determine whether the interface function of the system to be tested is correct according to the interface return value comparison result, and determine whether the interface return values of the system to be tested are correctly dropped into the database according to the interface database drop data comparison result.

[0007] In a third aspect, the present disclosure provides a computer readable medium having stored thereon a computer program, which, when executed by a processing device, implements the steps of the method of the first aspect of the present disclosure.

[0008] In a fourth aspect, the present disclosure provides an electronic device, comprising: a storage device having stored thereon a computer program; and a processing device configured to execute the computer program in the storage device to implement the steps of the method of the first aspect of the present disclosure.

[0009] The above technical solution can achieve at least the following technical effects:

[0010] By obtaining an interface testing configuration file, initiating an interface calling request and a database drop data query request to a reference system and a system to be tested according to preset testing rules in the interface testing configuration file, comparing return values returned by the reference system and the system to be tested in response to the interface calling request and the database drop data query request, and obtaining an interface return value comparison result and an interface database drop data comparison result, whether the interface function of the system to be tested is correct can be determined according to the interface return value comparison result, and whether the interface return values of the system to be tested are correctly dropped into a database can be determined according to the interface database drop data comparison result. Therefore, by using the method of the present disclosure, whether the interface function of the system to be tested is correct can be determined more accurately according to the interface return value comparison result and the interface database drop data comparison result.

[0011] Other features and advantages of the present disclosure will be described in detail in the following detailed description section. BRIEF DESCRIPTION OF DRAWINGS

[0012] The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings. The same or similar components have the same or similar reference numbers regardless of the drawing in which they are depicted. It should be understood that the drawings are not necessarily to scale, with emphasis instead being placed upon illustrating the principles of the embodiments of the present disclosure. In the drawings:

[0013] Figure 1 is a flowchart of an interface testing method according to an exemplary disclosed embodiment of the present disclosure.

[0014] Figure 2 is a schematic diagram of a preset comparison rule according to an exemplary disclosed embodiment of the present disclosure.

[0015] Figure 3 is a block diagram of an interface testing apparatus according to an exemplary disclosed embodiment of the present disclosure.

[0016] Figure 4 is a block diagram of an electronic device according to an exemplary disclosed embodiment of the present disclosure. DETAILED DESCRIPTION

[0017] Embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. While several embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and fully convey the scope of the present disclosure to those skilled in the art. It should be understood that the drawings and the embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure.

[0018] It should be understood that each step recited in the method embodiments of the present disclosure can be executed in different orders and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the steps shown. The scope of the present disclosure is not limited in this respect.

[0019] The term "comprising" and variations thereof as used herein are used inclusively, i.e., "comprising, but not limited to." The term "based on" is "based, at least in part, on." The term "one embodiment" means "at least one embodiment." The term "another embodiment" means "at least one additional embodiment." The term "some embodiments" means "at least some embodiments." Related definitions are given below in the description of the application.

[0020] It should be noted that the terms "first", "second", and the like used in the present disclosure are merely used to distinguish different devices, modules, or units, and do not imply the order or interdependence of the functions performed by these devices, modules, or units.

[0021] It should be noted that the modification of "one" and "multiple" mentioned in the present disclosure is illustrative rather than restrictive, and those skilled in the art should understand that "one or more" should be understood unless the context clearly indicates otherwise.

[0022] The names of the messages or information exchanged between the plurality of devices in the embodiments of the present disclosure are only for illustrative purposes, and are not intended to limit the scope of the messages or information.

[0023] In order to make the ordinary skilled person in the art more easily understand the technical solutions of the present disclosure, the related concepts involved in the present disclosure will be explained simply first.

[0024] The reference system is a long-term stable system, and the interface function provided externally can operate normally, which can be understood as a system that has been tested and has no obvious defects.

[0025] The system to be tested is an upgraded version of the system after the performance optimization, architecture upgrade, and internal reconstruction of the reference system, and the interfaces and interface functions of the reference system and the system to be tested are consistent. However, since the internal system of the system to be tested has changed (i.e. upgraded), the system to be tested is an unstable system, and it is necessary to retest whether the interface functions of the system to be tested are consistent with the interface functions of the reference system and whether the interfaces can operate normally.

[0026] The idempotency problem refers to the fact that the results of a user's request or multiple requests for the same operation are consistent and will not have side effects due to multiple requests. It can be understood that the user initiates multiple identical requests, and the system executes the processing logic based on the first request, obtains the result and stores the result. For requests after the first request in multiple identical requests, the system does not execute the processing logic but directly feeds back the result of the first request stored.

[0027] The technical solutions of the present disclosure will be described in detail in the embodiments below.

[0028] Figure 1 is a flowchart of an interface test method according to an exemplary disclosed embodiment of the present disclosure, as Figure 1 shown, the method comprises the following steps:

[0029] S11, an interface test configuration file is obtained, the interface test configuration file comprises a preset test rule for comparing the interface return value and the interface database data of the reference system and the system to be tested, the preset test rule is used to verify whether the interface function of the system to be tested is correct, and to verify whether the interface return value of the system to be tested can be correctly stored in the database, wherein the system to be tested is a system upgraded from the reference system.

[0030] The interface test configuration file can be a system file or a script file. The specific form of the interface test configuration file is not limited in the disclosure.

[0031] S12, according to the preset test rule, an interface call request and a database query request are initiated to the reference system and the system to be tested, and the return values returned by the reference system and the system to be tested in response to the interface call request and the database query request are compared to obtain an interface return value comparison result and an interface database data comparison result.

[0032] Optionally, the interface call request is initiated to the reference system and the system to be tested according to the preset test rule, comprising:

[0033] According to the interface test rule in the preset test rule, a first input parameter for calling a first interface of the system to be tested is obtained, and an interface call request is initiated to the first interface according to the first input parameter to obtain a test return value of the first interface; a first target field in the first input parameter is replaced to obtain a second input parameter; an interface call request is initiated to a second interface of the reference system according to the second input parameter to obtain a reference return value of the second interface, wherein the first interface and the second interface have the same function, and the system to be tested and the reference system use the same database.

[0034] The first input parameter includes at least one field. For example, the first input parameter can include a user ID field, a user name field, a user ID card number field, and the like, and a random number field, a fixed value field, a variable value field, and a request value field. The source of the first input parameter can be a preset data in a configuration file, a part of the output data of the previous logical interface of the first interface, data constructed by a preset manner according to a part of the output data of the previous logical interface of the first interface, or user input data. The disclosure does not make specific limitations.

[0035] In an implementable embodiment, the first target field is at least one of the random number field, the fixed value field, and the variable value field in the first input parameter.

[0036] For example, when the first target field is the random number field, if the random number in the first input parameter is 5, the random number 5 in the first input parameter can be replaced by 6 to obtain the second input parameter with the value of the random number field being 6.

[0037] It should be noted that the first input parameter and the second input parameter can obtain the same or partially same interface return value by calling the interface of the same function. Among them, the part that needs to be the same in the two interface return values can be understood as the function return value of the interface. And it is easy to understand that the first target field in the present disclosure is the value that does not affect / change the function return value of the interface, and the first target field can be understood as a non-computational parameter that does not affect the computational function of the interface.

[0038] Taking the business of querying the loan limit as an example, it is assumed that the same credit information should correspond to the same loan limit. Then, user A calls the loan limit query interface in the to-be-tested system according to the first input parameter including the ID of user A to obtain the interface return value a including the loan limit; at the same time, user B calls the loan limit query interface in the benchmark system according to the second input parameter including the ID of user B to obtain the interface return value b including the loan limit. If the credit of user A in the first input parameter is the same as the credit of user B in the second input parameter, that is, the first target field "ID of user A" in the first input parameter is replaced by "ID of user B" to obtain the second input parameter, then the part corresponding to the loan limit in the interface return value a and the interface return value b should be the same. However, the values other than the loan limit in the interface return value a and the interface return value b (such as user ID, user gender, etc.) can be different.

[0039] Further, the comparison of the return values returned by the benchmark system and the to-be-tested system in response to the interface call request to obtain the interface return value comparison result can include the following steps: performing field comparison on the test return value and the benchmark return value to obtain the interface return value comparison result.

[0040] It should be noted here that in the implementation process of calling the second interface of the benchmark system according to the second input parameter to obtain the benchmark return value, since the name (function) of the first interface of the to-be-tested system is the same as that of the second interface of the benchmark system, the first interface of the to-be-tested system corresponds to the same interface response model as the second interface of the benchmark system. Among them, the interface response model defines four parts of content: status code, description information, return parameter (the return parameter part defines zero or more interface return parameters), and exclusion parameter. In the case where the name (function) of the first interface of the to-be-tested system is the same as that of the second interface of the benchmark system, the first interface and the second interface correspond to the same interface response model, and in the case where the first interface and the second interface correspond to the same interface response model, the field names of the test return value and the benchmark return value obtained by the present disclosure are the same, but the specific values corresponding to each field name can be different or the same.

[0041] Since the second input parameter is obtained by replacing the first target field in the first input parameter, the first input parameter and the second input parameter are different, but the first input parameter and the second input parameter can obtain the same or partially same interface return value by calling the interface of the same function. It can be easily understood that, since the first interface of the to-be-tested system and the second interface of the benchmark system have the same function, the benchmark return value obtained and the test return value obtained should have at least part (that is, all or part) of the same value of all fields under the condition that the first interface of the to-be-tested system and the second interface of the benchmark system can normally operate. On the contrary, if the benchmark return value and the test return value are different in all fields, it indicates that the interface of the to-be-tested system does not operate normally, that is, there is a defect (under the premise that the interface of the default benchmark system has no defect). Therefore, in the present disclosure, the benchmark return value can be used to verify the test return value to determine whether the interface of the to-be-tested system operates normally.

[0042] One possible implementation of the field comparison of the test return value and the benchmark return value to obtain the interface return value comparison result is that part or all of the fields in the test return value and the benchmark return value can be compared to obtain the interface return value test result (interface return value comparison result) of the to-be-tested system.

[0043] The part or all of the fields in the test return value and the benchmark return value can be referred to as to-be-compared fields, which are function values obtained after the interface executes the function logic processing. The function value is used to reflect whether the data processing of the interface is accurate (that is, whether the function of the interface meets the expectation).

[0044] In addition, since the first input parameter and the second input parameter are different, the idempotency problem caused by repeatedly requesting the same data in the same database between the to-be-tested system and the benchmark system according to two completely same input parameters can be avoided, so that the test return value obtained is the test return value obtained by the to-be-tested system by executing the processing logic, rather than the stored historical benchmark return value, or the benchmark return value obtained is the real benchmark return value obtained by the benchmark system by executing the processing logic, rather than the stored historical test return value. It can be easily understood that, if the benchmark return value is the stored historical test return value, or the test return value is the stored historical benchmark return value, it will not have the meaning of verifying the test return value by the benchmark return value because the to-be-tested system and / or the benchmark system do not execute the system processing logic.

[0045] The first target field in the first input parameter is replaced to obtain a second input parameter, and the first interface of the to-be-tested system and the second interface of the benchmark system are respectively called according to the first input parameter and the second input parameter to obtain the test return value and the benchmark return value, which ensures that the test return value and the benchmark return value are real values after the system processing logic is executed, rather than historical stored values, and further ensures that the benchmark return value has a checking significance on the test return value. In detail, the first interface of the to-be-tested system is called according to the first input parameter to obtain the test return value. The first target field in the first input parameter is replaced to obtain the second input parameter, and the second interface of the benchmark system is called according to the second input parameter to obtain the benchmark return value. This way can avoid the idempotency problem caused by repeatedly requesting the same data in the same database between different systems according to two completely same input parameters, so that the test return value and the benchmark return value obtained are real values after the system processing logic is executed, rather than inaccurate historical stored values without executing the system processing logic. Further, the test return value and the benchmark return value obtained after actually executing the system processing logic can obtain an interface return value comparison result that accurately reflects whether the current to-be-tested system has defects. Therefore, by using the method of the present disclosure, the accuracy of the interface return value comparison result can be improved, and further the accuracy of the interface test result can be improved.

[0046] It is worth explaining that complete interface testing not only checks whether the interface can be connected, but also checks various combined scenarios, abnormal scenarios, input parameter legality, validity and boundary values, etc. That is, in actual interface test operations, not only whether the interface return value is correct should be checked, but also whether the database information corresponding to the interface is accurate should be checked.

[0047] In a possible implementation, a database storage data query request is initiated to the benchmark system and the to-be-tested system according to a preset test rule, and return values returned by the benchmark system and the to-be-tested system for responding to the database storage data query request are compared to obtain an interface database storage data comparison result.

[0048] S13, according to the interface return value comparison result, determine whether the interface function of the to-be-tested system is correct, and according to the interface database storage data comparison result, determine whether the interface return value of the to-be-tested system is correctly stored in the database.

[0049] The interface return value comparison result represents whether the to-be-compared fields in the test return value and the benchmark return value are the same, and according to the conclusion of whether the to-be-compared fields in the test return value and the benchmark return value are the same, it can be determined whether the interface function of the to-be-tested system is correct. Wherein, in the case that the to-be-compared fields in the test return value and the benchmark return value are the same, it is determined that the interface function of the to-be-tested system is correct. In the case that the to-be-compared fields in the test return value and the benchmark return value are not the same, it is determined that the interface function of the to-be-tested system is incorrect.

[0050] The interface falling database data comparison result represents whether the test falling database data corresponding to the test return value is same as the benchmark falling database data corresponding to the benchmark return value. According to the result of whether the test falling database data corresponding to the test return value is same as the benchmark falling database data corresponding to the benchmark return value, it can be determined whether the interface return value of the system to be tested is correctly fallen. In the case that the test falling database data corresponding to the test return value is same as the benchmark falling database data corresponding to the benchmark return value, it is determined that the interface return value of the system to be tested is correctly fallen. In the case that the test falling database data corresponding to the test return value is not same as the benchmark falling database data corresponding to the benchmark return value, it is determined that the interface return value of the system to be tested is not correctly fallen.

[0051] By adopting this method, the interface test configuration file is acquired, and the interface calling request and the falling database data query request are initiated to the benchmark system and the system to be tested according to the preset test rule in the interface test configuration file. The return value returned by the benchmark system and the system to be tested for responding to the interface calling request and the falling database data query request is compared to obtain the interface return value comparison result and the interface falling database data comparison result. According to the interface return value comparison result, it can be determined whether the interface function of the system to be tested is correct. Moreover, according to the interface falling database data comparison result, it can be determined whether the interface return value of the system to be tested is correctly fallen. According to the result of whether the interface function of the system to be tested is correct and the result of whether the interface return value of the system to be tested is correctly fallen, the complete interface test result of the system to be tested can be generated. Therefore, by adopting this method of the present disclosure, it can be more accurately determined whether the interface function of the system to be tested is correct according to the interface return value comparison result and the interface falling database data comparison result.

[0052] In an implementable embodiment, the test return value includes an interface status code. Before the first target field in the first input parameter is replaced to obtain the second input parameter, the method includes: determining whether the interface of the system to be tested is in a normal state according to the interface status code; and the replacing the first target field in the first input parameter to obtain the second input parameter includes: replacing the first target field in the first input parameter to obtain the second input parameter in the case that it is determined that the interface of the system to be tested is in the normal state.

[0053] An interface status code (resultCode) describes the result of a request sent by a client to a server and is defined in the interface response model. Using the interface status code, users can determine whether the server processed the request normally or encountered an error. For example, an interface status code 404 indicates that the requested webpage does not exist. As another example, an interface status code 200 indicates that the server successfully returned the requested webpage. Therefore, the interface status code (resultCode) can be used to determine whether the interface of the system under test is in a normal state. Specifically, determining whether the interface of the system under test is in a normal state based on the interface status code can be implemented as follows: if the interface status code is within a preset range, the interface of the system under test is determined to be in a normal state.

[0054] It should be understood that after calling the interface of the system under test according to the first input parameter and obtaining the test return value, if the status code in the test return value indicates that the interface of the system under test is abnormal, it means that the interface of the system under test has a defect (bug). If the subsequent steps of comparing the test return value and the baseline return value are continued when the interface of the system under test is determined to have a defect, the comparison result of the interface return value will be unreliable. That is, it is meaningless to obtain an incorrect result by comparing the incorrect test return value with the baseline return value. Therefore, one feasible implementation is to replace the first target field in the first input parameter to obtain the second input parameter after determining that the interface of the system under test is in a normal state.

[0055] By employing this method, when the interface status code of the system under test is determined to be in a normal state based on the test return value, executing steps S12 to S13 above avoids the problem of obtaining erroneous and meaningless comparison results by comparing incorrect test return values ​​with the baseline return value. Therefore, this method of the present disclosure, when obtaining correct test return values ​​and baseline return values, can obtain correct interface return value comparison results based on the correct test return values ​​and baseline return values, improving the effectiveness of interface test results and avoiding the problem of invalid verification.

[0056] Furthermore, by using this method, when the interface status code of the system under test is determined to be in a normal state based on the test return value, the above steps S12 to S13 can also avoid the problem of drawing the same conclusion based on the comparison between the incorrect test return value and the baseline return value, and then mistakenly believing that the interface of the system under test is defect-free based on the same conclusion.

[0057] In one feasible implementation, the interface test configuration file further includes the response model of each interface, and the step of comparing the test return value and the baseline return value to obtain the interface return value comparison result includes:

[0058] If the return parameter in the response model corresponding to the first interface is not empty, the fields corresponding to the return parameter in the test return value and the benchmark return value are compared to obtain the interface return value comparison result; if the return parameter of the first interface is empty, all fields in the test return value and the benchmark return value are compared to obtain the interface return value comparison result.

[0059] Specifically, when the return parameters in the interface response model corresponding to the interface of the system under test include preset return fields, the preset return fields in the test return value and the benchmark return value are compared; when the return parameters are empty, all fields in the test return value and the benchmark return value are compared.

[0060] The interface response model, or response model / structure, can include the interface status code parameter resultCode, the return parameter response_include (which controls which fields / parameters are returned), and the exclusion parameter response_exclude (which controls which fields / parameters are not returned).

[0061] For example, suppose the default return fields are sum, para1, para2, add, innerOrderNo, and id. If the response_include in the interface response model corresponding to the test return value and the baseline return value includes sum, para1, para2, add, innerOrderNo, and id, then the test return value and the baseline return value also include the sum, para1, para2, add, innerOrderNo, and id fields. In this case, the sum, para1, para2, add, innerOrderNo, and id fields in the test return value and the baseline return value can be compared. Conversely, if the response_include in the interface response model corresponding to the test return value and the baseline return value is empty, then all fields in the test return value and the baseline return value can be compared.

[0062] Another feasible implementation is to compare all fields in the test return value and the benchmark return value when response_include is a predefined cross character and response_exclude is a predefined space character in the interface response model.

[0063] For example, the response model can be as follows: Figure 2 The response model shown.

[0064] Using this approach, you can freely set which fields to be compared should be included in the return value of the interface according to business needs and the functions of the interface.

[0065] Because a complete interface test not only verifies whether the interface can be invoked, but also verifies various combined scenarios, abnormal scenarios, the legality, validity, and boundary values ​​of input parameters, etc., in actual interface testing operations, it is necessary not only to verify whether the interface return value is correct, but also to verify whether the database information corresponding to the interface is accurate. Therefore, in this disclosure, one feasible implementation method, the step of initiating a database query request to the benchmark system and the system under test according to the preset test rules includes:

[0066] If the interface function of the system under test is determined to be correct based on the comparison results of the interface return values, the database is queried according to the query keywords in the test return value and the benchmark return value based on the database query rules in the preset test rules, so as to obtain the test data and the benchmark data corresponding to the test return value.

[0067] Accordingly, the step of comparing the return values ​​returned by the benchmark system and the system under test in response to the data query request to obtain the interface data comparison result includes: comparing the test data and the benchmark data to obtain the interface data comparison result.

[0068] If the values ​​of the fields used to compare the test return value and the baseline return value (i.e., the fields to be compared) are consistent in the interface return value comparison results, it indicates that the interface of the system under test has been successfully tested and is functioning normally. However, in actual testing tasks, testers often encounter situations where the test return value of the interface of the system under test is correct, but the data written to the database through the interface of the system under test is incorrect. To solve this problem, this disclosure proposes that, if the values ​​of the fields used to compare the test return value and the baseline return value are consistent, the database can be queried according to preset query rules (i.e., database query rules) based on the query keywords in the test return value and the baseline return value, respectively, to obtain the test data and the baseline data corresponding to the test return value. Assuming the baseline system is stable (i.e., bug-free), the interface data comparison result of the system under test can be obtained by comparing the test data and the baseline data. The interface return value comparison result and the interface data comparison result are used together as the interface test result. This method achieves the goal of performing complete testing on the interface of the system under test and obtaining complete interface test results.

[0069] One possible scenario is that when writing data to the database via an interface, asynchronous data updates may occur due to objective reasons such as network latency. Therefore, one feasible implementation includes a preset query rule comprising a query latency time and a preset database query statement; the step of querying the database according to the preset query rule based on the query keywords in the test return value and the benchmark return value, respectively, to obtain test data corresponding to the test return value and benchmark data corresponding to the benchmark return value, includes:

[0070] When the query time determined by the query delay time is reached, the database is queried using the preset database query statement based on the query keywords in the test return value and the benchmark return value, respectively, to obtain the test data corresponding to the test return value and the benchmark data corresponding to the benchmark return value.

[0071] The query delay time is set according to the business logic corresponding to the API. For example, the query delay time can be set to N seconds. Then the query time will be the Nth second after the API returns the value.

[0072] The query keywords are one or more keywords used to compare the fields in the test return value and the benchmark return value.

[0073] The preset database query statement is a pre-defined SQL statement by the tester based on the business logic corresponding to the interface. It is used to retrieve the data stored in the database by combining query keywords.

[0074] In detail, upon reaching the query time determined by the query delay time N, the database is queried using preset database query statements based on the query keywords in the test return value and the baseline return value, respectively, to obtain the test data corresponding to the test return value and the baseline data corresponding to the baseline return value. If the test data and the baseline data are the same, it indicates that the process of the interface of the system under test writing data to the database is without defects (i.e., it meets the expected function).

[0075] By adopting this asynchronous method of comparing interface databases with interface return values, we can avoid the problem of obtaining inaccurate interface database test results based on data that has not yet been updated before the database is updated.

[0076] Optionally, the system under test has multiple interfaces, and the interface testing rules define the interface testing order among the multiple interfaces. Accordingly, if the first interface is not the first test interface in the interface testing order, obtaining the first input parameter for calling the first interface of the system under test includes: if the interface preceding the first interface has completed interface testing, using the second target field in the test return value of the preceding interface as the first input parameter of the first interface.

[0077] For the first test interface in the interface testing sequence, the first input parameter of the first test interface can be either the first input parameter entered by the user or the first input parameter pre-set in the preset test rules.

[0078] If the first interface is the first test interface in the non-interface test sequence, and the previous first interface has been tested, the second target field in the test return value of the previous first interface can be used as the first input parameter of the first interface.

[0079] The second target field is the field defined in the saveltem of the response model / structure corresponding to the test return value of the previous first interface.

[0080] It is easy to understand that a system can include multiple interfaces. In related technologies, when testing each interface of the system, testers need to input a parameter for each interface to perform the test, which results in very low interface testing efficiency.

[0081] To improve API testing efficiency, this disclosed method, assuming a certain business logic relationship exists between APIs, uses the second target field from the test return value of the previous API as the first input parameter for each API, provided the previous API has already been tested. This eliminates the need for testers to input a parameter for each API. By using the second target field from the previous API's test return value as the first input parameter of the current API, or by constructing the first input parameter based on the second target field from the previous API's test return value, automated API testing can be achieved, thus improving testing efficiency.

[0082] Figure 3 This is a block diagram of an interface testing apparatus according to an exemplary embodiment of the present disclosure, such as... Figure 3 As shown, the device 300 includes:

[0083] The acquisition module 310 is used to acquire the interface test configuration file. The interface test configuration file includes preset test rules for comparing the interface return values ​​and interface data stored in the database of the benchmark system and the system under test. The preset test rules are used to verify whether the interface function of the system under test is correct and whether the interface return value of the system under test can be correctly stored in the database. The system under test is the upgraded system of the benchmark system.

[0084] The calling module 320 is used to initiate interface call requests and data query requests to the benchmark system and the system under test according to the preset test rules, and compare the return values ​​returned by the benchmark system and the system under test in response to the interface call requests and the data query requests to obtain the interface return value comparison results and the interface data query comparison results.

[0085] The execution module 330 is used to determine whether the interface function of the system under test is correct based on the comparison result of the interface return value, and to determine whether the interface return value of the system under test is correctly stored in the database based on the comparison result of the data stored in the database.

[0086] In one possible implementation, the calling module 320 includes: an acquisition submodule, configured to acquire a first input parameter for calling a first interface of the system under test according to the interface test rules in the preset test rules, and initiate an interface call request to the first interface according to the first input parameter to obtain the test return value of the first interface; a replacement submodule, configured to replace a first target field in the first input parameter to obtain a second input parameter; a calling submodule, configured to initiate an interface call request to a second interface of the benchmark system according to the second input parameter to obtain the benchmark return value of the second interface, wherein the first interface and the second interface have the same function, and the system under test and the benchmark system use the same database; and a comparison submodule, configured to compare the fields of the test return value and the benchmark return value to obtain the interface return value comparison result.

[0087] In one possible implementation, the system to be tested has multiple interfaces, and the interface testing rules set the interface testing order among the multiple interfaces. Accordingly, if the first interface is not the first test interface in the interface testing order, the acquisition submodule is used to take the second target field in the test return value of the previous interface as the first input parameter of the first interface if the interface test of the previous interface has been completed.

[0088] In one possible implementation, the first target field is at least one of the random number field, fixed value field, and variable value field in the first input parameter.

[0089] In one possible implementation, the test return value includes an interface status code, and the calling module further includes a judgment submodule, used to determine whether the interface of the system under test is in a normal state based on the interface status code before replacing the first target field in the first input parameter to obtain the second input parameter; correspondingly, the replacement submodule is used to replace the first target field in the first input parameter to obtain the second input parameter if it is determined that the interface of the system under test is in a normal state.

[0090] In one possible implementation, the interface test configuration file further includes response models for each interface. Accordingly, the comparison submodule is used to compare the fields corresponding to the return parameters in the test return value and the benchmark return value when the return parameters in the response model corresponding to the first interface are not empty, to obtain the interface return value comparison result; and to compare all fields in the test return value and the benchmark return value when the return parameters of the first interface are empty, to obtain the interface return value comparison result.

[0091] In one possible implementation, the calling module 320 includes: a query submodule, configured to, when the interface function of the system under test is determined to be correct based on the comparison result of the interface return value, query the database according to the query keywords in the test return value and the benchmark return value respectively, based on the database query rules in the preset test rules, to obtain test database data corresponding to the test return value and benchmark database data corresponding to the benchmark return value; correspondingly, the comparison submodule is configured to compare the test database data and the benchmark database data to obtain the interface database data comparison result.

[0092] In one possible implementation, the database query rules include a query delay time and a preset database query statement; correspondingly, the query submodule is used to query the database using the preset database query statement based on the query keywords in the test return value and the benchmark return value when the query time determined according to the query delay time is reached, so as to obtain the test data corresponding to the test return value and the benchmark data corresponding to the benchmark return value.

[0093] The specific steps performed by each of the above modules have been described in detail in the method embodiments, and will not be repeated here.

[0094] The above technical solutions can achieve at least the following technical effects:

[0095] By obtaining the interface test configuration file and initiating interface call requests and database data query requests to the benchmark system and the system under test according to the preset test rules in the configuration file, the return values ​​returned by the benchmark system and the system under test for responding to the interface call requests and database data query requests are compared to obtain the interface return value comparison results and the interface database data comparison results. Based on the interface return value comparison results, it can be determined whether the interface function of the system under test is correct. Furthermore, based on the interface database data comparison results, it can be determined whether the interface return values ​​of the system under test are correctly stored in the database. Therefore, using this method, the correctness of the interface function of the system under test can be more accurately determined based on the interface return value comparison results and the interface database data comparison results.

[0096] The following is for reference. Figure 4 This diagram illustrates a structural schematic of an electronic device 400 suitable for implementing embodiments of the present disclosure. The terminal devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0097] like Figure 4 As shown, electronic device 400 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 402 or a program loaded from storage device 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of electronic device 400. Processing device 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0098] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic device 400 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4An electronic device 400 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0099] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs, such as configuration files. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from storage device 408, or installed from ROM 402. When the computer program is executed by processing device 401, it performs the functions defined in the methods of embodiments of this disclosure.

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

[0101] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0102] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0103] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes one or more of these programs, the electronic device causes the following actions: It calls the interface of the system under test according to a first input parameter to obtain a test return value; it replaces the first target field in the first input parameter to obtain a second input parameter; it calls the interface of a benchmark system according to the second input parameter to obtain a benchmark return value, wherein the system under test is an upgraded version of the benchmark system, and the system under test and the benchmark system use the same database; it compares some or all fields in the test return value and the benchmark return value according to a preset comparison rule to obtain the interface return value test result of the system under test; and it obtains the interface test result of the system under test based on the interface return value test result.

[0104] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0106] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules are not, in some cases, intended to limit the module itself.

[0107] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

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

[0109] According to one or more embodiments of this disclosure, Example 1 provides an interface testing method, comprising: obtaining an interface testing configuration file, the interface testing configuration file including preset test rules for comparing interface return values ​​and interface data stored in a database of a benchmark system and a system under test, the preset test rules being used to verify whether the interface function of the system under test is correct, and to verify whether the interface return value of the system under test can be correctly stored in the database, wherein the system under test is an upgraded version of the benchmark system; initiating interface call requests and database data query requests to the benchmark system and the system under test according to the preset test rules, and comparing the return values ​​returned by the benchmark system and the system under test for responding to the interface call requests and the database data query requests, to obtain interface return value comparison results and interface database data comparison results; determining whether the interface function of the system under test is correct based on the interface return value comparison results, and determining whether the interface return value of the system under test is correctly stored in the database based on the interface database data comparison results.

[0110] According to one or more embodiments of this disclosure, Example 2 provides the method of Example 1, wherein initiating an interface call request to the benchmark system and the system under test according to the preset test rules includes: obtaining a first input parameter for calling a first interface of the system under test according to the interface test rules in the preset test rules, and initiating an interface call request to the first interface according to the first input parameter to obtain a test return value of the first interface; replacing the first target field in the first input parameter to obtain a second input parameter; initiating an interface call request to a second interface of the benchmark system according to the second input parameter to obtain a benchmark return value of the second interface, wherein the first interface and the second interface have the same function, and the system under test and the benchmark system use the same database; comparing the return values ​​returned by the benchmark system and the system under test for responding to the interface call request to obtain an interface return value comparison result includes: performing a field comparison on the test return value and the benchmark return value to obtain the interface return value comparison result.

[0111] According to one or more embodiments of this disclosure, Example 3 provides the method of Example 2, wherein the system under test has multiple interfaces, and the interface testing rules define the interface testing order among the multiple interfaces. Accordingly, when the first interface is not the first test interface in the interface testing order, obtaining the first input parameter for calling the first interface of the system under test includes:

[0112] If the interface preceding the first interface has completed interface testing, the second target field in the test return value of the preceding interface is used as the first input parameter of the first interface.

[0113] According to one or more embodiments of this disclosure, Example 4 provides the method of Example 2, wherein the first target field is at least one of the random number field, fixed value field, and variable value field in the first input parameter.

[0114] According to one or more embodiments of this disclosure, Example 5 provides the method of Example 2, wherein the test return value includes an interface status code, and before replacing the first target field in the first input parameter to obtain the second input parameter, the method includes:

[0115] Determine whether the interface of the system under test is in a normal state based on the interface status code;

[0116] The step of replacing the first target field in the first input parameter to obtain the second input parameter includes:

[0117] If it is determined that the interface of the system under test is in a normal state, the first target field in the first input parameter is replaced to obtain the second input parameter.

[0118] According to one or more embodiments of this disclosure, Example 6 provides the method of Example 2, wherein the interface test configuration file further includes the response model of each interface, and the step of comparing the test return value and the baseline return value to obtain the interface return value comparison result includes:

[0119] If the return parameter in the response model corresponding to the first interface is not empty, the fields corresponding to the return parameter in the test return value and the benchmark return value are compared to obtain the interface return value comparison result.

[0120] If the return parameter of the first interface is empty, all fields of the test return value and the benchmark return value are compared to obtain the interface return value comparison result.

[0121] According to one or more embodiments of this disclosure, Example 7 provides the methods of Examples 2-6. The step of initiating a database data query request to the benchmark system and the system under test according to the preset test rules includes: if the interface function of the system under test is determined to be correct based on the comparison result of the interface return values, querying the database according to the query keywords in the test return value and the benchmark return value, respectively, based on the database query rules in the preset test rules, to obtain test database data corresponding to the test return value and benchmark database data corresponding to the benchmark return value; the step of comparing the return values ​​returned by the benchmark system and the system under test in response to the database data query request to obtain an interface database data comparison result includes: comparing the test database data and the benchmark database data to obtain the interface database data comparison result.

[0122] According to one or more embodiments of this disclosure, Example 8 provides the method of Example 7, wherein the database query rules include a query delay time and a preset database query statement; the step of querying the database based on the database query rules in the preset test rules, according to the query keywords in the test return value and the benchmark return value respectively, to obtain test data corresponding to the test return value and benchmark data corresponding to the benchmark return value, includes: when the query time determined according to the query delay time is reached, querying the database according to the query keywords in the test return value and the benchmark return value respectively, using the preset database query statement to obtain test data corresponding to the test return value and benchmark data corresponding to the benchmark return value.

[0123] According to one or more embodiments of this disclosure, Example 9 provides an interface testing apparatus, comprising an acquisition module for acquiring an interface testing configuration file, the interface testing configuration file including preset test rules for comparing interface return values ​​and interface data stored in a database of a benchmark system and a system under test, the preset test rules being used to verify whether the interface function of the system under test is correct and whether the interface return value of the system under test can be correctly stored in the database, wherein the system under test is an upgraded version of the benchmark system; a calling module for initiating interface call requests and database data query requests to the benchmark system and the system under test according to the preset test rules, and comparing the return values ​​returned by the benchmark system and the system under test for responding to the interface call requests and the database data query requests to obtain interface return value comparison results and interface database data comparison results; and an execution module for determining whether the interface function of the system under test is correct based on the interface return value comparison results, and determining whether the interface return value of the system under test is correctly stored in the database based on the interface database data comparison results.

[0124] According to one or more embodiments of this disclosure, Example 10 provides the apparatus of Example 9, wherein the calling module includes: an acquisition submodule, configured to acquire a first input parameter for calling a first interface of the system under test according to an interface test rule in the preset test rules, and initiate an interface call request to the first interface according to the first input parameter to obtain a test return value of the first interface; a replacement submodule, configured to replace a first target field in the first input parameter to obtain a second input parameter; a calling submodule, configured to initiate an interface call request to a second interface of the benchmark system according to the second input parameter to obtain a benchmark return value of the second interface, wherein the first interface and the second interface have the same function, and the system under test and the benchmark system use the same database; and a comparison submodule, configured to compare the fields of the test return value and the benchmark return value to obtain a comparison result of the interface return value.

[0125] According to one or more embodiments of this disclosure, Example 11 provides the apparatus of Example 10, wherein the system to be tested has multiple interfaces, and the interface testing rules set the interface testing order among the multiple interfaces. Accordingly, when the first interface is not the first test interface in the interface testing order, the acquisition submodule is used to use the second target field in the test return value of the previous interface as the first input parameter of the first interface when the interface testing of the previous interface has been completed.

[0126] According to one or more embodiments of the present disclosure, Example 12 provides the apparatus of Example 10, wherein the first target field is at least one of a random number field, a fixed value field, and a variable value field in the first input parameter.

[0127] According to one or more embodiments of this disclosure, Example 13 provides the apparatus of Example 10, wherein the test return value includes an interface status code, and the calling module further includes a judgment submodule, configured to determine whether the interface of the system under test is in a normal state based on the interface status code before replacing the first target field in the first input parameter to obtain the second input parameter; correspondingly, the replacement submodule is configured to replace the first target field in the first input parameter to obtain the second input parameter if it is determined that the interface of the system under test is in a normal state.

[0128] According to one or more embodiments of this disclosure, Example 14 provides the apparatus of Example 10, wherein the interface test configuration file further includes response models for each interface. Accordingly, the comparison submodule is configured to, when the return parameter in the response model corresponding to the first interface is not empty, compare the fields corresponding to the return parameter in the test return value and the benchmark return value to obtain the interface return value comparison result; and when the return parameter of the first interface is empty, compare all fields in the test return value and the benchmark return value to obtain the interface return value comparison result.

[0129] According to one or more embodiments of this disclosure, Example 15 provides the apparatus of Examples 10-14, wherein the calling module includes: a query submodule, configured to, when the interface function of the system under test is determined to be correct based on the comparison result of the interface return value, query the database according to the query keywords in the test return value and the benchmark return value respectively, based on the database query rules in the preset test rules, to obtain test database data corresponding to the test return value and benchmark database data corresponding to the benchmark return value; correspondingly, the comparison submodule is configured to compare the test database data and the benchmark database data to obtain the interface database data comparison result.

[0130] According to one or more embodiments of this disclosure, Example 16 provides the apparatus of Example 15, wherein the database query rules include a query delay time and a preset database query statement; accordingly, the query submodule is configured to, when the query time determined according to the query delay time is reached, query the database according to the query keywords in the test return value and the benchmark return value, respectively, through the preset database query statement, to obtain test data corresponding to the test return value and benchmark data corresponding to the benchmark return value.

[0131] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0132] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0133] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. An interface test method characterized by, The method comprises: obtaining an interface test configuration file, the interface test configuration file comprising preset test rules for comparing interface return values and interface database drop data of a benchmark system and a system to be tested, the preset test rules being used to verify whether the interface function of the system to be tested is correct and whether the interface return values of the system to be tested can be correctly dropped into the database, wherein the system to be tested is a system upgraded from the benchmark system; initiating an interface call request and a database drop data query request to the benchmark system and the system to be tested according to the preset test rules, and comparing return values returned by the benchmark system and the system to be tested in response to the interface call request and the database drop data query request to obtain an interface return value comparison result and an interface database drop data comparison result; determining whether the interface function of the system to be tested is correct according to the interface return value comparison result and determining whether the interface return values of the system to be tested are correctly dropped into the database according to the interface database drop data comparison result; wherein the step of initiating an interface call request to the benchmark system and the system to be tested according to the preset test rules comprises: obtaining a first input parameter for calling a first interface of the system to be tested according to an interface test rule in the preset test rules, and initiating an interface call request to the first interface according to the first input parameter to obtain a test return value of the first interface; replacing a first target field in the first input parameter to obtain a second input parameter; initiating an interface call request to a second interface of the benchmark system according to the second input parameter to obtain a benchmark return value of the second interface, wherein the first interface and the second interface have the same function, and the system to be tested and the benchmark system use the same database; the step of comparing return values returned by the benchmark system and the system to be tested in response to the interface call request to obtain an interface return value comparison result comprises: performing field comparison on the test return value and the benchmark return value to obtain the interface return value comparison result.

2. The method of claim 1, wherein, The interface of the system to be tested is multiple, and an interface test sequence among the multiple interfaces is set in the interface test rule. Correspondingly, in the case that the first interface is not the first test interface in the interface test sequence, the step of obtaining a first input parameter for calling a first interface of the system to be tested comprises: in the case that a previous interface of the first interface has completed interface test, a second target field in a test return value of the previous interface is taken as the first input parameter of the first interface.

3. The method of claim 1, wherein, The first target field is at least one of a random number field, a fixed value field and a variable value field in the first input parameter.

4. The method of claim 1, wherein, The test return value comprises an interface status code, and before the step of replacing the first target field in the first input parameter to obtain a second input parameter, the method comprises: determining whether the interface of the system to be tested is in a normal state according to the interface status code; the step of replacing the first target field in the first input parameter to obtain a second input parameter comprises: In a case where it is determined that the interface of the system to be tested is in a normal state, the first target field in the first input parameter is replaced to obtain the second input parameter.

5. The method of claim 1, wherein, The interface test configuration file further includes response models of respective interfaces, and the field comparison between the test return value and the reference return value to obtain the interface return value comparison result includes: In a case where the return parameter in the response model corresponding to the first interface is not empty, the fields corresponding to the return parameter in the test return value and the reference return value are compared to obtain the interface return value comparison result; In a case where the return parameter of the first interface is empty, all fields in the test return value and the reference return value are compared to obtain the interface return value comparison result.

6. The method according to any one of claims 1-5, characterized in that, The initiating of the database query request to the reference system and the system to be tested according to the preset test rule includes: In a case where it is determined that the interface function of the system to be tested is correct according to the interface return value comparison result, the database is queried according to the query keywords in the test return value and the reference return value based on the database query rule in the preset test rule to obtain test database drop data corresponding to the test return value and reference database drop data corresponding to the reference return value; The comparison of the return values returned by the reference system and the system to be tested for responding to the database drop data query request to obtain an interface database drop data comparison result includes: The test database drop data and the reference database drop data are compared to obtain the interface database drop data comparison result.

7. The method of claim 6, wherein, The database query rule includes a query delay time and a preset database query statement, and the querying of the database according to the query keywords in the test return value and the reference return value based on the database query rule in the preset test rule to obtain the test database drop data corresponding to the test return value and the reference database drop data corresponding to the reference return value includes: When a query time determined according to the query delay time is reached, the database is queried according to the query keywords in the test return value and the reference return value through the preset database query statement to obtain the test database drop data corresponding to the test return value and the reference database drop data corresponding to the reference return value.

8. An interface testing device, characterized by The interface test configuration file includes a preset test rule for comparing interface return values and interface database drop data of a reference system and a system to be tested, the preset test rule being used to verify whether an interface function of the system to be tested is correct and whether the interface return value of the system to be tested can be correctly dropped into a database, and the system to be tested is a system upgraded from the reference system. ​ The calling module is configured to initiate an interface calling request and a database query request to the benchmark system and the system to be tested according to the preset test rule, and compare the return values returned by the benchmark system and the system to be tested in response to the interface calling request and the database query request, to obtain an interface return value comparison result and an interface database data comparison result. The execution module is configured to determine whether the interface function of the system to be tested is correct according to the interface return value comparison result, and determine whether the interface return value of the system to be tested is correctly stored in the database according to the interface database data comparison result. The calling module comprises: The obtaining submodule is configured to obtain a first input parameter for calling a first interface of the system to be tested according to an interface test rule in the preset test rule, and initiate an interface calling request to the first interface according to the first input parameter, to obtain a test return value of the first interface. The replacing submodule is configured to replace a first target field in the first input parameter to obtain a second input parameter. The calling submodule is configured to initiate an interface calling request to a second interface of the benchmark system according to the second input parameter, to obtain a benchmark return value of the second interface, wherein the first interface and the second interface have the same function, and the system to be tested and the benchmark system use the same database. The comparison submodule is configured to compare the test return value and the benchmark return value in the field, to obtain the interface return value comparison result.

9. A computer readable medium having stored thereon a computer program, characterized in that The program is executed by the processing device to implement the steps of the method in any one of claims 1-7.

10. An electronic device, comprising: The processing device is configured to execute the computer program in the storage device to implement the steps of the method in any one of claims 1-7. ​ ​

Images