Method and apparatus for automated testing of service interface, and electronic device

Abstract

The present disclosure provides a method and apparatus for automated testing of a service interface, and an electronic device. The method for automated testing of the service interface comprises: using a service interface test class to construct a target testing method and a data object under test, wherein the target testing method comprises: constructing a target annotation, the target annotation comprising a first attribute and a second attribute, the data object under test being an input parameter object of a service interface, the first attribute being used for acquiring the path of a target data file, the target data file comprising a test case for the service interface, the second attribute being used for acquiring a target type of the data object under test, and the target type being determined on the basis of a serialization protocol of a service framework; and using the target testing method to test the data object under test and the test case, so as to obtain a test result.

Description

Automated testing method and device for service interface, and electronic equipment

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This disclosure is based on and claims priority to an application with CN application number 202311017101.5 and filing date August 11, 2023. The disclosure content of this CN application is hereby incorporated into this disclosure as a whole. Technical Field

[0003] The present disclosure relates to the field of automated testing technology, and in particular to an automated testing method and device for a service interface, and an electronic device. Background Art

[0004] The service interface of a software system (such as Dubbo) defines the communication protocol and data interaction method between the software system and external systems or other modules, enabling effective communication and data sharing between different systems or modules. As the complexity of software systems continues to increase, efficient and accurate testing of service interfaces is essential. Currently, existing technologies typically use manual testing methods to test service interfaces. Alternatively, in existing automated testing methods for service interfaces, test data is maintained in a specific class (such as the @DataProvider class), coupling the test data with the test script.

[0005] Summary of the Invention

[0006] According to one aspect of an embodiment of the present disclosure, an automated testing method for a service interface is provided, including: constructing a target test method and a data object to be tested using a service interface test class, wherein the target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute, the data object to be tested is an input parameter object of the service interface, the first attribute is used to obtain the path of a target data file, the target data file contains a test case of the service interface, and the second attribute is used to obtain a target type of the data object to be tested, the target type is determined by the serialization protocol of the service framework; and the target test method is used to test the data object to be tested and the test case to obtain a test result.

[0007] In some embodiments, the automated testing method for the service interface further includes: using the service interface test class to call a preprocessing method to preprocess the test environment of the service interface.

[0008] In some embodiments, the automated testing method of the service interface also includes: determining whether the target test method contains a target annotation; in response to the target test method not containing a target annotation, using the service interface test class to construct a target annotation for the target test method to obtain an updated target test method.

[0009] In some embodiments, a target test method is used to test a data object to be tested and a test case to obtain a test result, including: obtaining a first attribute and a second attribute of a target annotation using a preset reflection method; determining a test case of a target data file based on the first attribute; determining a data object to be tested based on the second attribute; passing the test case and the data object to be tested to the target test method to execute the target test method and obtain a test result.

[0010] In some embodiments, determining a test case for a target data file based on a first attribute includes: obtaining a path of the target data file using the first attribute; reading the target data file according to the path; and parsing the target data file to obtain a test case.

[0011] In some embodiments, determining the data object to be tested based on the second attribute includes: obtaining a target type of the data object to be tested using the second attribute; parsing the target type to obtain a first parsing result; and deserializing the first parsing result to obtain the data object to be tested.

[0012] In some embodiments, executing the target test method to obtain the test result includes: obtaining the return value of the service interface during the execution of the target test method; parsing the return value to obtain the test value of the data object to be tested; and asserting the test value of the data object to be tested and the field value of the expected data object to obtain the test result.

[0013] In some embodiments, the automated testing method for the service interface further includes: in response to the path of the target data file being empty, determining that an abnormality exists in the target data file, and generating abnormality feedback information of the target data file.

[0014] In some embodiments, the automated testing method for a service interface further includes: using a service interface test class to call a listening interface of a target listener to listen to the execution process of a target test method; and recording the execution process.

[0015] In some embodiments, in response to determining that an execution exception occurs in the target test method during the execution process, the target test method is processed using a preset exception resolution method.

[0016] According to another aspect of an embodiment of the present disclosure, an automated testing device for a service interface is also provided, including: a construction module, used to use a service interface test class to construct a target test method and a data object to be tested, wherein the target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute, the data object to be tested is an input parameter object of the service interface, the first attribute is used to obtain the path of the target data file, the target data file contains a test case of the service interface, and the second attribute is used to obtain the target type of the data object to be tested, and the target type is determined by the serialization protocol of the service framework; a testing module, used to use the target test method to test the data object to be tested and the test case to obtain the test results.

[0017] In some embodiments, the automated testing apparatus for a service interface further includes: a preprocessing module configured to call a preprocessing method using a service interface test class to preprocess the test environment of the service interface.

[0018] In some embodiments, the automated testing of the service interface also includes: an update module for determining whether the target test method contains a target annotation; in response to the target test method not containing a target annotation, using the service interface test class to construct a target annotation for the target test method to obtain an updated target test method.

[0019] In some embodiments, the above-mentioned test module is also used to: use the target test method to test the data object and test case to obtain the test results, including: using a preset reflection method to obtain the first attribute and the second attribute of the target annotation; based on the first attribute, determine the test case of the target data file; based on the second attribute, determine the data object to be tested; pass the test case and the data object to be tested to the target test method to execute the target test method and obtain the test results.

[0020] In some embodiments, the above-mentioned test module is further used to: obtain the path of the target data file using the first attribute; read the target data file according to the path; and parse the target data file to obtain a test case.

[0021] In some embodiments, the test module is further configured to: obtain a target type of the data object to be tested using the second attribute; parse the target type to obtain a first parsing result; and deserialize the first parsing result to obtain the data object to be tested.

[0022] In some embodiments, the above-mentioned test module is also used to: obtain the return value of the service interface during the execution of the target test method; parse the return value to obtain the test value of the data object to be tested; assert the test value of the data object to be tested and the field value of the expected data object to obtain the test result.

[0023] In some embodiments, the automated testing device for the service interface further includes: a generation module for determining that an abnormality exists in the target data file in response to the path of the target data file being empty, and generating abnormality feedback information of the target data file.

[0024] In some embodiments, the automated testing device for the service interface further includes: a monitoring module configured to use the service interface test class to call the monitoring interface of the target listener to monitor the execution process of the target test method; and record the execution process.

[0025] In some embodiments, the monitoring module is configured to process the target test method using a preset exception solution in response to determining that an execution exception occurs in the target test method through the execution process.

[0026] According to another aspect of the embodiments of the present disclosure, a storage medium is further provided, characterized in that the storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the automated testing method of the service interface involved in any of the above embodiments.

[0027] According to another aspect of the embodiments of the present disclosure, an electronic device is also provided, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the automated testing method of the service interface involved in any of the above embodiments.

[0028] According to another aspect of an embodiment of the present disclosure, a computer program is provided, comprising computer instructions, wherein when the computer instructions are executed by a processor, the method as described in any one of the above embodiments is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0030] FIG1 is a flow chart of an automated testing method for a service interface according to an embodiment of the present disclosure;

[0031] FIG2 is a schematic diagram of an optional automated testing process for a service interface according to an embodiment of the present disclosure;

[0032] FIG3 is a structural block diagram of an optional automated testing device for a service interface according to an embodiment of the present disclosure;

[0033] FIG4 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure;

[0034] FIG5 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure;

[0035] FIG6 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure;

[0036] FIG7 is a structural block diagram of yet another optional automated testing device for a service interface according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0037] In order to enable those skilled in the art to better understand the solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the embodiments described are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present disclosure.

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

[0039] According to an embodiment of the present disclosure, a method embodiment of an automated testing method for a service interface is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0040] The inventors noted that existing techniques typically employ manual testing methods to test service interfaces. Alternatively, existing automated testing methods for service interfaces maintain test data in specific classes (such as the @DataProvider class), coupling the test data with the test scripts and requiring extensive repetitive code. Consequently, existing service interface testing methods suffer from poor reusability and maintainability, resulting in high testing costs and low testing efficiency due to repetitive work.

[0041] Accordingly, the present disclosure provides an automated testing solution for service interfaces to at least solve the technical problems that the service interface testing method provided by the prior art couples test data with test scripts, resulting in poor reusability of the testing method, high testing cost, and low testing efficiency.

[0042] Figure 1 is a flowchart of an automated testing method for a service interface according to an embodiment of the present disclosure. As shown in Figure 1 , the embodiment shown in Figure 1 may include at least the following implementation steps, that is, the technical solution implemented by steps S101 to S102.

[0043] Step S101: Use the service interface test class to construct a target test method and a data object to be tested. The target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute. The data object to be tested is an input parameter object of the service interface. The first attribute is used to obtain the path of the target data file, which contains the test case of the service interface. The second attribute is used to obtain the target type of the data object to be tested. The target type is determined by the serialization protocol of the service framework.

[0044] Step S102: testing the data object to be tested and the test case using the target test method to obtain the test result.

[0045] In the technical solution provided by the present disclosure, the service interface can be a Dubbo interface. It should be noted here that Dubbo is a distributed service framework developed in Java and can be used for distributed service governance.

[0046] In the technical solution provided by the above steps S101 to S102, the service interface test class can be used to control the entire process of automated testing of the service interface, and its control process includes but is not limited to: realizing data-driven, screening and calling test methods, writing and calling test cases, and calling other functional interfaces (such as listening interfaces) to assist the automated testing process. It should also be noted here that the service interface test class can be a test class based on the Test Next Generation (TestNG) test framework. TestNG can support concurrent testing, parameterized testing, test suites, test dependencies, test result reports and other functions. The test framework also provides multiple annotations and configuration options to facilitate the writing and management of test cases. The above-mentioned target annotation can be constructed by the service interface test class. At the same time, the service interface test class is used to add the above-mentioned first attribute and the above-mentioned second attribute to the target annotation so that test data (target data file, data object to be tested, etc.) can be obtained through the attributes of the target annotation.

[0047] In the technical solution provided by the above steps S101 to S102, the type of the above target data file can be but is not limited to: XML, JSON. It should be noted here that the automated testing method for the service interface provided by the present disclosure can use data files in JSON format. Data files in JSON format are data-driven and have strong scalability and maintainability. The above-mentioned data object to be tested can be an input parameter object of the service interface. The input parameter object can be a Java object. In the automated testing process of the Dubbo interface, the input parameter object can contain the parameters required to call the Dubbo interface. The parameters required by the Dubbo interface can include but are not limited to: service interface name, service version number, service method name, parameter type of the service method, and parameter value of the service method.

[0048] In the technical solution provided by the above steps S101 to S102, the serialization protocol of the above service framework can be used to convert the service interface object into a byte stream. When the service framework is Dubbo, its serialization protocol can be the Hessian serialization protocol.

[0049] In the embodiment of the present disclosure, a target test method and a data object to be tested are first constructed using a service interface test class, wherein the target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute, the data object to be tested is an input parameter object of the service interface, the first attribute is used to obtain the path of the target data file, the target data file contains a test case of the service interface, and the second attribute is used to obtain the target type of the data object to be tested, the target type is determined by the serialization protocol of the service framework, and then the target test method is used to test the data object to be tested and the test case to obtain the test results. By constructing a target annotation for the target test method that can obtain the target data file and the data object to be tested, the purpose of separating the test method from the test data is achieved, thereby achieving the technical effect of improving the reusability and testing efficiency of the target test method and reducing the testing cost of the service interface, thereby solving the technical problem that the service interface testing method provided by the prior art couples the test data with the test script, resulting in poor reusability of the test method, high testing cost, and low testing efficiency.

[0050] The above method of the above embodiment of the present disclosure is further introduced below.

[0051] In an optional embodiment, the automated testing method for the service interface further includes:

[0052] Step S103: Using the service interface test class to call a preprocessing method, preprocess the test environment of the service interface.

[0053] In the technical solution provided in step S103 above, the preprocessing method can be the OnTestStart method in the TestNG test framework, which can perform preprocessing operations before the test method is executed. The preprocessing operations can include but are not limited to: initializing the test environment (such as creating a database link, loading a configuration file, and starting a service), preparing test data (such as inserting test data into a database and creating a temporary file), and setting the test context (such as setting global variables and injecting dependencies). It should also be noted here that the preprocessing method can reduce duplicate code in the test method, improve test efficiency, and enhance the maintainability of the test method.

[0054] The above method is further described below with reference to FIG2 .

[0055] Figure 2 is a schematic diagram of an optional automated testing process for a service interface according to an embodiment of the present disclosure. As shown in Figure 2, when performing automated testing on a service interface, the core processing class of the automated testing process (the above-mentioned service interface test class, named AutoInterfaceTest) is first used to construct a target annotation (@AutoTestData), and the first attribute value and the second attribute clazz are added to the target annotation. Then, the OnTestStart preprocessing method is used to preprocess the test environment of the service interface.

[0056] In an optional embodiment, the automated testing method for the service interface further includes:

[0057] Step S1041, determining whether the target test method contains the target annotation;

[0058] Step S1042 : In response to the target test method not including the target annotation, a target annotation is constructed for the target test method using the service interface test class to obtain an updated target test method.

[0059] Still as shown in Figure 2, after preprocessing the test environment of the service interface using the preprocessing method, the service interface test class can be scanned by Java reflection to check whether the test method contains the target annotation. When the test method contains the target annotation, the test method is used to perform automated testing on the test data; when the test method does not contain the target annotation, the service interface test class is used to construct a target annotation for the test method, and the first attribute and the second attribute are added to the target annotation to obtain the updated test method, and then the updated test method is used to test the test data.

[0060] In an optional embodiment, in step S102, the target test method is used to test the data object and the test case to obtain the test results, including:

[0061] Step S1011, obtaining the first attribute and the second attribute of the target annotation using a preset reflection method;

[0062] Step S1012: determining a test case of the target data file based on the first attribute;

[0063] Step S1013, determining the data object to be tested based on the second attribute;

[0064] Step S1014: passing the test case and the data object to be tested to the target test method to execute the target test method and obtain the test result.

[0065] In the technical solution provided by the above steps S1011 to S1014, the above-mentioned preset reflection method can be Java reflection. It should be noted here that Java reflection can dynamically obtain and operate data during the automated testing process, including but not limited to: obtaining class information (such as class properties, methods, constructors), dynamically creating objects, dynamically calling methods, and dynamically accessing properties. The above-mentioned test results can be used to determine whether the function of the service interface is normal. The test results may include but are not limited to: whether the service interface is successfully called, the response time of the service interface, the return result of the service interface, the performance of the service interface under different loads (such as throughput), and the compatibility of the service interface in different environments and different versions.

[0066] In an optional embodiment, in step S1022, determining a test case of the target data file based on the first attribute includes:

[0067] Step S1021, using the first attribute to obtain the path of the target data file;

[0068] Step S1022, read the target data file according to the path;

[0069] Step S1023: parse the target data file to obtain a test case.

[0070] In the technical solution provided by the present invention, before the service interface is automatically tested, a data file in JSON format is pre-written. In the data file, a JSON data structure can be defined, including a JSON object of the request input parameter and a JSON object of the expected result. It should be noted here that the JSON object of the expected result can be used to compare with the JSON object of the request input parameter to determine whether the JSON object of the request input parameter of the service interface has been tested successfully. It should also be noted here that the JSON data structure can be in the format of a JSON object array, a JSON object can be used as a test case, and a JSON object array file can include multiple test cases corresponding to a test interface. It can also be understood that the storage location of the target data file can be: a preset path in the local file system, a preset directory under the class path, a database, or a remote file system.

[0071] In the technical solution provided by the present disclosure, the target data file is parsed, and the obtained test cases may include the following data: the name of the service interface, the version number of the service interface, the name and parameter list of the method defined in the service interface, the parameter type of each method, and the return value type of each method.

[0072] In an optional embodiment, in step S1023, determining the data object to be tested based on the second attribute includes:

[0073] Step S1031, using the second attribute to obtain the target type of the data object to be tested;

[0074] Step S1032, parsing the target type to obtain a first parsing result;

[0075] Step S1033: Deserialize the first parsing result to obtain a data object to be tested.

[0076] In the technical solutions provided in steps S1031 to S1033 above, the target type of the data object to be tested may be the class type (i.e., class type) of the data object to be tested. It should be noted that the target type of the data object to be tested may also be determined by the serialization protocol of the service framework. The first parsing result may include, but is not limited to, the type of the data object to be tested and the data result of the data object to be tested. It should be noted that the type of the data object to be tested may be, but is not limited to, JSON, and the data structure of the data object to be tested may be, but is not limited to, Map, List, or JSONObject.

[0077] Still as shown in FIG2 , in the technical solution provided by the present disclosure, after determining that the test method contains the target annotation, the first attribute and the second attribute of the target annotation are obtained by Java reflection. Furthermore, on the one hand, whether the target data file exists can be determined based on whether the path of the target data file obtained by the first attribute is empty. When the path of the target data file is not empty, it is determined that the target data file exists. Further, the target data file is read and the target data file is parsed using JsonPath to obtain a set of test cases. On the other hand, after obtaining the first attribute and the second attribute of the target annotation by Java reflection, a proxy service reference is generated to initialize the target test method (such as ensuring that the test method supports the call of the Dubbo service). Then, the target type of the data object to be tested obtained by the second attribute is first parsed using JsonPath, and the parsed result is deserialized to obtain the test method object (i.e., the data object to be tested).

[0078] In an optional embodiment, in step S1024, executing the target test method to obtain the test results includes:

[0079] Step S1051, during the execution of the target test method, obtaining the return value of the service interface;

[0080] Step S1052: Parse the returned value to obtain the test value of the data object to be tested;

[0081] Step S1053 , asserting the test value of the data object to be tested and the field value of the expected data object to obtain a test result.

[0082] In the technical solution provided by steps S1051 to S1053 above, the return value of the service interface may include, but is not limited to: the data type of the data object to be tested, reference type objects (such as collection objects, map objects), and service interface exception information. The test value of the data object to be tested may be a field value of the data object to be tested.

[0083] Still as shown in Figure 2, in the technical solution provided by the present disclosure, after obtaining the collection of test cases, traverse each test case in the collection, and then call the test method containing the deserialized data object to be tested by Java reflection to bind the current test case to the test method. Further, execute the bound test method and obtain the return value of the service interface during the execution of the test method. Then, you can use JsonPath to first parse the return value of the service interface to obtain the field value (test value) of the data object to be tested, and then make an accuracy assertion on the field value of the data object to be tested and the field value of the expected data object, that is, compare whether the field value of the data object to be tested is consistent with the field value of the expected data object. When the two values ​​are consistent, it can be determined that the function of the service interface is normal. Otherwise, it is determined that the function of the service interface is abnormal. And, after the test of each test case is completed, record the execution result of the current test case. It should be noted here that since different test cases correspond to different data objects to be tested, each time after determining the test case, it is necessary to call the test method by reflection to bind the current test case to the test method containing the corresponding data object to be tested.

[0084] Still as shown in Figure 2, in the technical solution provided by the present disclosure, after the test of each test case is completed, it is determined whether the set of test cases obtained by parsing the target data file is empty. When the set of test cases is not empty, the next test case is tested using the test method called by reflection; when the set of test cases is empty, it is determined that the automated testing process of the service interface is completed.

[0085] In an optional embodiment, the automated testing method for the service interface further includes:

[0086] Step S106 : In response to the path of the target data file being empty, determining that an abnormality exists in the target data file, and generating abnormality feedback information of the target data file.

[0087] Still as shown in Figure 2, when the path of the target data file obtained through the first attribute is empty, the target data file is determined to be abnormal. At this time, abnormal feedback information of the target data file is generated (such as displaying "file does not exist" on the display device) to avoid the automated testing process of the service interface from being stuck for a long time or exiting abnormally, thereby improving the flexibility of the testing method of the service interface and improving the efficiency of the automated testing of the service interface.

[0088] In an optional embodiment, the automated testing method for the service interface further includes:

[0089] Step S1071, using the service interface test class to call the target listener's monitoring interface to monitor the execution process of the target test method;

[0090] Step S1072, recording the execution process;

[0091] Step S1073 , in response to determining that the target test method has an execution exception through the execution process, the target test method is processed using a preset exception solution.

[0092] In the technical solution provided by the above steps S1071 to S1073, the above target listener can be a listener based on the TestNG test framework, and the above listening interface can be an ITestListener interface. It should be noted here that during the automated testing of the Dubbo interface, the ITestListener interface can monitor various events during the execution of the test method, including but not limited to: onStart event, an event triggered at the beginning of the test method execution (such as an initialization operation); onFinish event, an event triggered at the end of the test method execution (such as a cleanup operation); onTestStart event, an event triggered before the test method is executed (such as a preprocessing operation); onTestSuccess event, an event triggered when the test method is successfully executed, which can record or process the test results of the successful execution of the test method; onTestFailure event, an event triggered when the test method fails to execute, which can record or process the test results of the failed test method execution.

[0093] In the technical solution provided by the above steps S1071 to S1073, the above-mentioned preset exception solutions can be pre-set by technical personnel and stored in the target storage location of the test system. The preset exception solutions may include but are not limited to: recording exception logs, generating and throwing exception notifications or exception alarm information, retrying test methods, skipping one or more test processes (such as when the test process of a test case among multiple test cases is abnormal and cannot continue to be executed, skipping the test process of the current test case and executing the test process of the next test case), and forcing the execution of the test process (such as when the test process of a test case among multiple test cases is abnormal and can continue to be executed, forcing the subsequent test processes of the current test case to continue to be executed).

[0094] Still as shown in Figure 2, the technical solution provided by this disclosure uses the core processing class AutoInterfaceTest to call TestNG's ITestListener interface before performing automated testing on the service interface. This listener interface monitors the entire automated testing process of the service interface and records the monitoring results of each process. When an exception is detected in a test process, the corresponding exception solution is retrieved and called from the target storage location of the test system, thereby promptly handling the test process exception and improving the efficiency of automated testing of the service interface.

[0095] The technical effects that can be achieved through the above optional embodiments provided by the present disclosure are:

[0096] (1) Constructing test methods that include target annotation tags to separate test methods from test data, improving the reusability and maintainability of test methods, improving test efficiency, and reducing test costs;

[0097] (2) By binding the dynamic parameters in the target data file, it is convenient to flexibly modify the parameters of the requested input object, further improving the test efficiency and the accuracy of the test results;

[0098] (3) Using the reflection mechanism to dynamically call test methods improves the flexibility of executing test cases;

[0099] (4) Using JSON files as the carrier of test data improves the maintainability and management efficiency of test data.

[0100] In this embodiment, an interactive processing device for a video ringback tone system is also provided. This device is used to implement the above-mentioned embodiments and preferred implementations. Details already described are not repeated here. As used below, a "module" refers to a combination of software and / or hardware that can implement a predetermined function. Although the devices described in the following embodiments are preferably implemented using software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0101] FIG3 is a structural block diagram of an optional automated testing device for a service interface according to an embodiment of the present disclosure. As shown in FIG3 , the device includes:

[0102] Construction module 301 is used to construct a target test method and a data object to be tested using a service interface test class. The target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute. The data object to be tested is an input parameter object of the service interface. The first attribute is used to obtain the path of a target data file, which contains a test case for the service interface. The second attribute is used to obtain the target type of the data object to be tested. The target type is determined by the serialization protocol of the service framework.

[0103] The testing module 302 is used to test the data objects and test cases using the target testing method to obtain the test results.

[0104] In some embodiments, Figure 4 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure. As shown in Figure 4, in addition to all the modules shown in Figure 3, the device also includes: a preprocessing module 303, which is used to call a preprocessing method using a service interface test class to preprocess the test environment of the service interface.

[0105] In some embodiments, Figure 5 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure. As shown in Figure 5, in addition to all the modules shown in Figure 4, the device also includes: an update module 304, used to determine whether the target test method contains a target annotation; in response to the target test method not containing the target annotation, using the service interface test class to construct a target annotation for the target test method to obtain an updated target test method.

[0106] In some embodiments, the above-mentioned test module 302 is also used to: use the target test method to test the data object and test case to obtain the test results, including: using a preset reflection method to obtain the first attribute and the second attribute of the target annotation; based on the first attribute, determine the test case of the target data file; based on the second attribute, determine the data object to be tested; pass the test case and the data object to be tested to the target test method to execute the target test method to obtain the test results.

[0107] In some embodiments, the test module 302 is further configured to: obtain a path of a target data file using the first attribute; read the target data file according to the path; and parse the target data file to obtain a test case.

[0108] In some embodiments, the test module 302 is further configured to: obtain a target type of the data object to be tested using the second attribute; parse the target type to obtain a first parsing result; and deserialize the first parsing result to obtain the data object to be tested.

[0109] In some embodiments, the above-mentioned test module 302 is also used to: obtain the return value of the service interface during the execution of the target test method; parse the return value to obtain the test value of the data object to be tested; assert the test value of the data object to be tested and the field value of the expected data object to obtain the test result.

[0110] In some embodiments, Figure 6 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure. As shown in Figure 6, in addition to all the modules shown in Figure 5, the device also includes: a generation module 305, which is used to determine that there is an abnormality in the target data file in response to the path of the target data file being empty, and generate abnormal feedback information of the target data file.

[0111] In some embodiments, Figure 7 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure. As shown in Figure 7, in addition to all the modules shown in Figure 6, the device also includes: a monitoring module 306, which is used to use the service interface test class to call the monitoring interface of the target listener to monitor the execution process of the target test method; record the execution process; and in response to determining that the target test method has an execution exception through the execution process, use a preset exception solution to process the target test method.

[0112] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0113] In this embodiment, a storage medium is further provided. The storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute any of the aforementioned automated testing methods for the service interface.

[0114] In some embodiments, in this embodiment, the above-mentioned storage medium may be configured as a program for executing the following steps:

[0115] Step S1: Use the service interface test class to construct a target test method and a data object to be tested, wherein the target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute, the data object to be tested is an input parameter object of the service interface, the first attribute is used to obtain the path of the target data file, the target data file contains a test case of the service interface, and the second attribute is used to obtain the target type of the data object to be tested, and the target type is determined by the serialization protocol of the service framework;

[0116] Step S2: Use the target test method to test the data object and test case to obtain the test results.

[0117] In some embodiments, in this embodiment, the above-mentioned storage medium may include but is not limited to: USB flash drive, read-only memory (ROM), random access memory (RAM), mobile hard disk, magnetic disk or optical disk and other media that can store computer programs.

[0118] In this embodiment, an electronic device is also provided, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the automated testing method of any one of the aforementioned service interfaces.

[0119] In some embodiments, in this embodiment, the processor may be configured as a program for performing the following steps:

[0120] Step S1: Use the service interface test class to construct a target test method and a data object to be tested, wherein the target test method includes: constructing a target annotation, the target annotation includes a first attribute and a second attribute, the data object to be tested is an input parameter object of the service interface, the first attribute is used to obtain the path of the target data file, the target data file contains a test case of the service interface, and the second attribute is used to obtain the target type of the data object to be tested, and the target type is determined by the serialization protocol of the service framework;

[0121] Step S2: Use the target test method to test the data object and test case to obtain the test results.

[0122] The serial numbers of the above-mentioned embodiments of the present disclosure are for description only and do not represent the advantages or disadvantages of the embodiments.

[0123] In the above embodiments of the present disclosure, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0124] In the several embodiments provided in the present disclosure, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, 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 units or modules, which can be electrical or other forms.

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

[0126] In addition, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0127] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0128] The above is only a preferred embodiment of the present disclosure. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present disclosure. These improvements and modifications should also be regarded as within the scope of protection of the present disclosure.

Claims

1. An automated testing method for a service interface, comprising: Construct a target test method and a data object to be tested by using a service interface test class, wherein the target test method includes: constructing a target annotation, wherein the target annotation includes a first attribute and a second attribute, wherein the data object to be tested is an input parameter object of the service interface, wherein the first attribute is used to obtain a path of a target data file, wherein the target data file includes a test case of the service interface, and wherein the second attribute is used to obtain a target type of the data object to be tested, wherein the target type is determined by a serialization protocol of the service framework; The target test method is used to test the data object to be tested and the test case to obtain a test result.

2. The automated testing method according to claim 1, further comprising: The service interface test class is used to call a preprocessing method to preprocess the test environment of the service interface.

3. The automated testing method according to claim 2, further comprising: Determining whether the target test method contains the target annotation; In response to the target test method not including the target annotation, the target annotation is constructed for the target test method using the service interface test class to obtain an updated target test method.

4. The automated testing method according to any one of claims 1 to 3, wherein: Using the target test method to test the data object to be tested and the test case to obtain the test result includes: Acquire the first attribute and the second attribute of the target annotation by using a preset reflection method; Based on the first attribute, determining the test case of the target data file; Based on the second attribute, determining the data object to be tested; The test case and the data object to be tested are transferred to the target test method to execute the target test method and obtain the test result.

5. The automated testing method according to claim 4, wherein: Determining the test case of the target data file based on the first attribute includes: Acquire the path of the target data file using the first attribute; According to the path, read the target data file; The target data file is parsed to obtain the test case.

6. The automated testing method according to claim 4, wherein: Determining the data object to be tested based on the second attribute includes: Acquire the target type of the data object to be tested by using the second attribute; Parsing the target type to obtain a first parsing result; Deserialize the first parsing result to obtain the data object to be tested.

7. The automated testing method according to claim 4, wherein: Executing the target test method to obtain the test result includes: During the execution of the target test method, obtaining the return value of the service interface; Parsing the return value to obtain the test value of the data object to be tested; Asserting the test value of the data object to be tested and the field value of the expected data object to obtain the test result.

8. The automated testing method according to any one of claims 1 to 7, further comprising: In response to the path of the target data file being empty, it is determined that an abnormality exists in the target data file, and abnormality feedback information of the target data file is generated.

9. The automated testing method according to any one of claims 1 to 8, further comprising: Using the service interface test class to call the listening interface of the target listener to monitor the execution process of the target test method; The execution process is recorded.

10. The automated testing method according to claim 9, further comprising: In response to determining, through the execution process, that the target test method is executed abnormally, the target test method is processed using a preset abnormality solution.

11. An automated testing device for a service interface, comprising: A construction module, used to construct a target test method and a data object to be tested using a service interface test class, wherein the target test method includes: constructing a target annotation, wherein the target annotation includes a first attribute and a second attribute, wherein the data object to be tested is an input parameter object of the service interface, wherein the first attribute is used to obtain a path of a target data file, wherein the target data file includes a test case of the service interface, and wherein the second attribute is used to obtain a target type of the data object to be tested, wherein the target type is determined by a serialization protocol of the service framework; The test module is used to test the data object to be tested and the test case using the target test method to obtain a test result.

12. A storage medium comprising a stored program, wherein: When the program is running, the device where the storage medium is located is controlled to execute the automated testing method of the service interface described in any one of claims 1 to 10.

13. An electronic device, comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the automated testing method for the service interface described in any one of claims 1 to 10.

14. A computer program comprising computer instructions, wherein when the computer instructions are executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images