WO2025035656A1 - 服务接口的自动化测试方法和装置、电子设备 - Google Patents

服务接口的自动化测试方法和装置、电子设备 Download PDF

Info

Publication number
WO2025035656A1
WO2025035656A1 PCT/CN2023/137113 CN2023137113W WO2025035656A1 WO 2025035656 A1 WO2025035656 A1 WO 2025035656A1 CN 2023137113 W CN2023137113 W CN 2023137113W WO 2025035656 A1 WO2025035656 A1 WO 2025035656A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
test
service interface
attribute
tested
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2023/137113
Other languages
English (en)
French (fr)
Inventor
杨广强
张云龙
阮宜龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Corp Ltd
Original Assignee
China Telecom Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Corp Ltd filed Critical China Telecom Corp Ltd
Publication of WO2025035656A1 publication Critical patent/WO2025035656A1/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present disclosure is based on an application with CN application number 202311017101.5 and filing date August 11, 2023, and claims priority.
  • the disclosure content of the CN application is hereby introduced into the present disclosure as a whole.
  • 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.
  • the service interface of a software system defines the communication protocol and data interaction method between the software system and external systems or other modules, which enables effective communication and data sharing between different systems or modules.
  • a software system such as Dubbo
  • the service interface of a software system defines the communication protocol and data interaction method between the software system and external systems or other modules, which enables effective communication and data sharing between different systems or modules.
  • the existing technology usually uses manual testing methods to test service interfaces, or, in the existing automated testing methods of service interfaces, the test data is maintained in a specific class (such as the @DataProvider class) so that the test data is coupled with the test script.
  • an automated testing method for a service interface comprising: constructing a target testing method and a data object to be tested using a service interface testing class, wherein the target testing method comprises: constructing a target annotation, the target annotation comprises 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 comprises a test case of the service interface, the second attribute is used to obtain a target type of the data object to be tested, the target type is determined by a serialization protocol of a service framework; and the data object to be tested and the test case are tested using the target testing method to obtain a test result.
  • the target testing method comprises: constructing a target annotation, the target annotation comprises 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 comprises a test case of the service interface, the second attribute is used to obtain
  • the automated testing method for a service interface further includes: using a service interface test class to call a preprocessing method to preprocess a test environment for the service interface.
  • 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.
  • 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; and passing the test case and the data object to be tested to the target test method to execute the target test method to obtain a test result.
  • determining the test case of the target data file includes: obtaining the 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 the test case.
  • 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.
  • executing a target test method to obtain a test result includes: obtaining a return value of a service interface during execution of the target test method; parsing the return value to obtain a 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 a test result.
  • 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.
  • the automated testing method for the service interface further includes: using the service interface test class to call a listening interface of a target listener to listen to the execution process of the target test method; and recording the execution process.
  • the target test method in response to determining that the target test method is executed abnormally through the execution process, is processed using a preset abnormality solution.
  • an automated testing device for a service interface 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 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, and the target type is determined by a serialization protocol of the service framework; a testing module, used to use the target test method to test the data object and the test case to obtain a test result.
  • a construction module used to use a 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
  • the automated testing device for the 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.
  • the automated testing of the service interface further includes: an updating module for determining whether the target test method includes the target annotation; in response to the target test method not including the target annotation, using the service interface test class Build a target annotation for the target test method to obtain an updated target test method.
  • 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 to obtain the test results.
  • the above-mentioned test module is also 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.
  • the test module is further used 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.
  • 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.
  • 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.
  • the automated testing device for the service interface further includes: a monitoring module, which is used to call the monitoring interface of the target listener using the service interface test class to monitor the execution process of the target test method; and record the execution process.
  • the monitoring module is used to process the target test method using a preset exception solution in response to determining that the target test method is executed abnormally through the execution process.
  • a 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.
  • an electronic device comprising: at least one processor; and 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 of the service interface involved in any one of the above embodiments.
  • a computer program including computer instructions, wherein When the computer instructions are executed by a processor, the method described in any of the above embodiments is implemented.
  • FIG1 is a flow chart of an automated testing method for a service interface according to an embodiment of the present disclosure
  • FIG2 is a schematic diagram of an optional automated testing process of a service interface according to an embodiment of the present disclosure
  • FIG3 is a structural block diagram of an optional automated testing device for a service interface according to an embodiment of the present disclosure
  • FIG4 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure.
  • FIG. 5 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure
  • FIG. 6 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure.
  • FIG. 7 is a structural block diagram of yet another optional automated testing device for a service interface 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 the logical order is shown in the flowchart, in some cases, different steps can be performed. The steps are performed in the order shown or described herein.
  • the inventors have noticed that the prior art usually uses manual testing methods to test service interfaces, or in the existing automated testing methods for service interfaces, the test data is maintained in a specific class (such as the @DataProvider class), so that the test data is coupled with the test script, resulting in the need to write a large amount of repeated code. That is, the existing service interface testing methods have poor reusability and maintainability, and the repeated work leads to high testing costs and low testing efficiency.
  • the present disclosure provides an automated testing solution for a service interface to at least solve 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 testing method, high testing cost, and low testing efficiency.
  • FIG1 is a flow chart of an automated testing method for a service interface according to an embodiment of the present disclosure. As shown in FIG1 , the embodiment shown in FIG1 may at least include the following implementation steps, that is, the technical solution implemented by steps S101 to S102.
  • Step S101 constructing 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 the target data file, the target data file includes 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;
  • Step S102 Use the target test method to test the data object and the test case to obtain the test result.
  • the service interface may be a Dubbo interface.
  • Dubbo is a distributed service framework developed in Java and can be used for distributed service governance.
  • 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.
  • 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 reporting and other functions.
  • Test framework also provides multiple annotations and configuration options to facilitate the writing and management of test cases.
  • the above target annotation can be constructed by the service interface test class.
  • the service interface test class is used to add the above first attribute and the above second attribute to the target annotation so that the test data (target data file, data object to be tested, etc.) can be obtained through the attributes of the target annotation.
  • the type of the above target data file can be But not limited to: XML, JSON.
  • 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, and the input parameter object can be a Java object.
  • the input parameter object can contain the parameters required to call the Dubbo interface.
  • the parameters required by the Dubbo interface may 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.
  • the serialization protocol of the above service framework can be used to convert the service interface object into a byte stream.
  • its serialization protocol can be the Hessian serialization protocol.
  • 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 comprises: constructing a target annotation, the target annotation comprises 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 comprises a test case of the service interface, the second attribute is used to obtain a target type of the data object to be tested, the target type is determined by a 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 a test result, and 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 test efficiency of the target test method and reducing the test cost of the service interface, thereby solving the technical problem that the test method of the service
  • the automated testing method for the service interface further includes:
  • Step S103 using the service interface test class to call a preprocessing method to preprocess the test environment of the service interface.
  • the above 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, 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.
  • FIG. 2 is a schematic diagram of an optional automated testing process for a service interface according to an embodiment of the present disclosure.
  • the service interface test class mentioned above, named AutoInterfaceTest the service interface test class mentioned above, named AutoInterfaceTest
  • AutoInterfaceTestData a target annotation
  • AutoTestStart preprocessing method preprocess the test environment of the service interface.
  • the automated testing method for the service interface further includes:
  • Step S1041 determining whether the target test method contains a target annotation
  • Step S1042 in response to the target test method not including the target annotation, constructing the target annotation for the target test method using the service interface test class to obtain an updated target test method.
  • the service interface test class can be scanned by Java reflection to check whether 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 an updated test method, and then the updated test method is used to test the test data.
  • step S102 the target test method is used to test the data object and the test case to obtain the test result, including:
  • Step S1011 obtaining the first attribute and the second attribute of the target annotation by using a preset reflection method
  • Step S1012 determining a test case of the target data file based on the first attribute
  • Step S1013 determining the data object to be tested based on the second attribute
  • 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.
  • the above 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.
  • class information such as class properties, methods, constructors
  • the above 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.
  • step S1022 based on the first attribute, the target data file is determined.
  • Test cases including:
  • Step S1021 using the first attribute to obtain the path of the target data file
  • Step S1022 reading the target data file according to the path
  • Step S1023 parse the target data file to obtain a test case.
  • a data file in JSON format is pre-written.
  • a JSON data structure can be defined, including a JSON object of request input and a JSON object of expected results.
  • the JSON object of expected results can be used to compare with the JSON object of request input to determine whether the JSON object of request input of the service interface is tested successfully.
  • 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.
  • 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.
  • 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.
  • step S1023 determining the data object to be tested based on the second attribute includes:
  • Step S1031 using the second attribute to obtain the target type of the data object to be tested;
  • Step S1032 parsing the target type to obtain a first parsing result
  • Step S1033 deserialize the first parsing result to obtain a data object to be tested.
  • the target type of the above 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 above first parsing result may include, but is not limited to: the type of the data object to be tested, 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, JSONObject.
  • the first attribute and the second attribute of the target annotation are obtained by Java reflection. Further, on the one hand, whether the path of the target data file obtained by the first attribute is empty can be used to determine whether the target data file exists. 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. Use JsonPath to parse the target data file to obtain a set of test cases.
  • step S1024 executing the target test method to obtain the test result includes:
  • Step S1051 during the execution of the target test method, obtaining the return value of the service interface
  • Step S1052 parsing the returned value to obtain the test value of the data object to be tested
  • Step S1053 assert the test value of the data object to be tested and the field value of the expected data object to obtain a test result.
  • the return value of the above service interface may include but is not limited to: the data type of the data object to be tested, the object of reference type (such as collection object, Map object), and the abnormal information of the service interface.
  • the test value of the above data object to be tested may be the field value of the data object to be tested.
  • the automated testing method for the service interface further includes:
  • 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.
  • the target data file 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 automated testing of the service interface.
  • 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 automated testing of the service interface.
  • the automated testing method for the service interface further includes:
  • Step S1071 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
  • Step S1072 recording the execution process
  • Step S1073 in response to determining that the target test method is executed abnormally through the execution process, the target test method is processed using a preset abnormality solution.
  • the above target listener can be a listener based on the TestNG test framework, and the above listening interface can be an ITestListener 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.
  • 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 execute, 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 execute, forcing the subsequent test processes of the current test case to continue to execute).
  • the core processing class AutoInterfaceTest can be used to call the ITestListener interface of TestNG.
  • the monitoring interface monitors the entire process of automated testing of the service interface and records the monitoring results of each process.
  • the corresponding exception solution for the test process is queried and called from the target storage location of the test system to promptly handle the abnormal problems of the test process and improve the efficiency of automated testing of the service interface.
  • JSON files as the carrier of test data improves the maintainability and management efficiency of test data.
  • an interactive processing device for a video ring back tone system is also provided, and the device is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made are not repeated here.
  • a “module” is a combination of software and/or hardware that can implement a predetermined function.
  • the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.
  • 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:
  • a construction module 301 is 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, 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 includes 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;
  • the testing module 302 is used to test the data objects and test cases to be tested using the target testing method to obtain the test results.
  • 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.
  • 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.
  • FIG. 5 is a structural block diagram of another optional automated testing device for a service interface according to an embodiment of the present disclosure.
  • the device includes, in addition to all the modules shown in FIG. 4 , further including:
  • the new module 304 is used to determine whether the target test method contains the target annotation; in response to the target test method not containing the target annotation, construct the target annotation for the target test method using the service interface test class to obtain an updated target test method.
  • 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.
  • the test module 302 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.
  • the test module 302 is further used to: obtain the 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the device in addition to all the modules shown in Figure 6, the device also includes: a monitoring module 306, which is used to call the monitoring interface of the target listener using the service interface test class to monitor the execution process of the target test method; record the execution process; in response to determining that the target test method is executed abnormally through the execution process, use a preset exception solution to process the target test method.
  • a monitoring module 306 which is used to call the monitoring interface of the target listener using the service interface test class to monitor the execution process of the target test method; record the execution process; in response to determining that the target test method is executed abnormally through the execution process, use a preset exception solution to process the target test method.
  • the above modules can be implemented by 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.
  • a storage medium is further provided, the storage medium including a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute any one of the aforementioned automated testing methods for the service interface.
  • the above storage medium may be configured as a program for performing the following steps:
  • Step S1 using 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;
  • Step S2 Use the target test method to test the data object and the test case to obtain the test result.
  • the above-mentioned storage medium may include but is not limited to: U disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), mobile hard disk, magnetic disk or optical disk and other media that can store computer programs.
  • ROM read-only memory
  • RAM random access memory
  • mobile hard disk magnetic disk or optical disk and other media that can store computer programs.
  • an electronic device including: at least one processor; and 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 any one of the aforementioned service interface automated testing methods.
  • the processor may be configured as a program for performing the following steps:
  • Step S1 using 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;
  • Step S2 Use the target test method to test the data object and the test case to obtain the test result.
  • the disclosed technical content can be implemented in other ways.
  • the device embodiments described above are only exemplary.
  • the division of the units can be a logical function division.
  • Another point is that The mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, units or modules, which may be electrical or in other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
  • each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
  • 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.
  • the computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present disclosure.
  • the aforementioned storage medium includes: U disk, read-only memory (ROM), random access memory (RAM), mobile hard disk, disk or optical disk, etc., various media that can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开提供了一种服务接口的自动化测试方法和装置、电子设备。服务接口的自动化测试方法方法包括：利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。

Description

服务接口的自动化测试方法和装置、电子设备
相关申请的交叉引用
本公开是以CN申请号为202311017101.5，申请日为2023年8月11日的申请为基础，并主张其优先权，该CN申请的公开内容在此作为整体引入本公开中。
技术领域
本公开涉及自动化测试技术领域，特别涉及一种服务接口的自动化测试方法和装置、电子设备。
背景技术
软件系统的服务接口(如Dubbo)定义了软件系统与外部系统或者其他模块之间的通信协议和数据交互方式，能够使得不同系统或者模块之间进行有效的通信和数据共享。随着软件系统的复杂性不断提升，对服务接口进行高效、准确的测试十分必要。目前，现有技术通常采用人工测试方法对服务接口进行测试，或者，现有的服务接口的自动化测试方法中，将测试数据维护在特定类(如@DataProvider类)中，使得测试数据与测试脚本耦合。
发明内容
根据本公开实施例的一个方面，提供了一种服务接口的自动化测试方法，包括：利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。
在一些实施例中，服务接口的自动化测试方法还包括：利用服务接口测试类调用预处理方法，对服务接口的测试环境进行预处理。
在一些实施例中，服务接口的自动化测试方法还包括：确定目标测试方法是否包含目标注解；响应于目标测试方法未包含目标注解，利用服务接口测试类为目标测试方法构建目标注解，得到更新后的目标测试方法。
在一些实施例中，利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果，包括：利用预设反射方式获取目标注解的第一属性和第二属性；基于第一属性，确定目标数据文件的测试用例；基于第二属性，确定待测数据对象；将测试用例和待测数据对象传递至目标测试方法，以执行目标测试方法，得到测试结果。
在一些实施例中，基于第一属性，确定目标数据文件的测试用例，包括：利用第一属性获取目标数据文件的路径；根据路径，读取目标数据文件；对目标数据文件进行解析，得到测试用例。
在一些实施例中，基于第二属性，确定待测数据对象，包括：利用第二属性获取待测数据对象的目标类型；对目标类型进行解析，得到第一解析结果；对第一解析结果进行反序列化，得到待测数据对象。
在一些实施例中，执行目标测试方法，得到测试结果，包括：在目标测试方法执行过程中，获取服务接口的返回值；对返回值进行解析，得到待测数据对象的测试值；对待测数据对象的测试值与预期数据对象的字段值进行断言，得到测试结果。
在一些实施例中，服务接口的自动化测试方法还包括：响应于目标数据文件的路径为空，确定目标数据文件存在异常，生成目标数据文件的异常反馈信息。
在一些实施例中，服务接口的自动化测试方法还包括：利用服务接口测试类调用目标监听器的监听接口，监听目标测试方法的执行过程；记录执行过程。
在一些实施例中，响应于通过执行过程确定目标测试方法执行异常，利用预设异常解决办法对目标测试方法进行处理。
根据本公开实施例的另一方面，还提供了一种服务接口的自动化测试装置，包括：构建模块，用于利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；测试模块，用于利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。
在一些实施例中，服务接口的自动化测试装置还包括：预处理模块，用于利用服务接口测试类调用预处理方法，对服务接口的测试环境进行预处理。
在一些实施例中，服务接口的自动化测试还包括：更新模块，用于确定目标测试方法是否包含目标注解；响应于目标测试方法未包含目标注解，利用服务接口测试类 为目标测试方法构建目标注解，得到更新后的目标测试方法。
在一些实施例中，上述测试模块还用于：利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果，包括：利用预设反射方式获取目标注解的第一属性和第二属性；基于第一属性，确定目标数据文件的测试用例；基于第二属性，确定待测数据对象；将测试用例和待测数据对象传递至目标测试方法，以执行目标测试方法，得到测试结果。
在一些实施例中，上述测试模块还用于：利用第一属性获取目标数据文件的路径；根据路径，读取目标数据文件；对目标数据文件进行解析，得到测试用例。
在一些实施例中，上述测试模块还用于：利用第二属性获取待测数据对象的目标类型；对目标类型进行解析，得到第一解析结果；对第一解析结果进行反序列化，得到待测数据对象。
在一些实施例中，上述测试模块还用于：在目标测试方法执行过程中，获取服务接口的返回值；对返回值进行解析，得到待测数据对象的测试值；对待测数据对象的测试值与预期数据对象的字段值进行断言，得到测试结果。
在一些实施例中，服务接口的自动化测试装置还包括：生成模块，用于响应于目标数据文件的路径为空，确定目标数据文件存在异常，生成目标数据文件的异常反馈信息。
在一些实施例中，服务接口的自动化测试装置还包括：监听模块，用于利用服务接口测试类调用目标监听器的监听接口，监听目标测试方法的执行过程；记录执行过程。
在一些实施例中，监听模块用于响应于通过执行过程确定目标测试方法执行异常，利用预设异常解决办法对目标测试方法进行处理。
根据本公开实施例的又一方面，还提供了一种存储介质，其特征在于，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行上述任意一实施例涉及的服务接口的自动化测试方法。
根据本公开实施例的又一方面，还提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行上述任意一实施例涉及的服务接口的自动化测试方法。
根据本公开实施例的另一方面，提供一种计算机程序，包括计算机指令，其中所 述计算机指令被处理器执行时实现如上述任一实施例所述的方法。
附图说明
此处所说明的附图用来提供对本公开的进一步理解，构成本公开的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：
图1是根据本公开实施例的一种服务接口的自动化测试方法的流程图；
图2是根据本公开实施例的一种可选的服务接口的自动化测试流程的示意图；
图3是根据本公开实施例的一种可选的服务接口的自动化测试装置的结构框图；
图4是根据本公开实施例的另一种可选的服务接口的自动化测试装置的结构框图；
图5是根据本公开实施例的又一种可选的服务接口的自动化测试装置的结构框图；
图6是根据本公开实施例的又一种可选的服务接口的自动化测试装置的结构框图；
图7是根据本公开实施例的又一种可选的服务接口的自动化测试装置的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本公开方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
根据本公开实施例，提供了一种服务接口的自动化测试方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同 于此处的顺序执行所示出或描述的步骤。
发明人注意到，现有技术通常采用人工测试方法对服务接口进行测试，或者，现有的服务接口的自动化测试方法中，将测试数据维护在特定类(如@DataProvider类)中，使得测试数据与测试脚本耦合，导致需要编写大量的重复代码。即，现有的服务接口的测试方法其可复用性与可维护性差、重复劳动导致测试成本高、测试效率低。
据此，本公开提供一种服务接口的自动化测试方案，以至少解决现有技术提供的服务接口的测试方法将测试数据与测试脚本耦合导致测试方法的可复用性差、测试成本高、测试效率低的技术问题。
图1是根据本公开实施例的一种服务接口的自动化测试方法的流程图，如图1所示，上述图1所示的实施例可以至少包括如下实施步骤，即可以是步骤S101至步骤S102所实现的技术方案。
步骤S101，利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；
步骤S102，利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。
本公开提供的技术方案中，服务接口可以是Dubbo接口，此处需要说明的是，Dubbo是Java开发的一个分布式服务框架，可以用于分布式服务治理。
上述步骤S101至步骤S102提供的技术方案中，服务接口测试类可以用于控制服务接口的自动化测试的整个过程，其控制过程包括但不限于：实现数据驱动、筛选和调用测试方法、编写和调用测试用例、调用其他功能接口(如监听接口)以辅助自动化测试过程。此处还需要说明的是，该服务接口测试类可以是基于测试下一代(Test Next Generation，TestNG)测试框架的测试类，TestNG可以支持并发测试、参数化测试、测试套件、测试依赖、测试结果报告等功能，该测试框架还提供了多个注解和配置选项，便于编写和管理测试用例。上述目标注解可以由该服务接口测试类构建，同时，利用该服务接口测试类为该目标注解添加上述第一属性和上述第二属性，以通过该目标注解的属性能够获取测试数据(目标数据文件、待测数据对象等)。
上述步骤S101至步骤S102提供的技术方案中，上述目标数据文件的类型可以是 但不限于：XML，JSON。此处需要说明的是，本公开提供的服务接口的自动化测试方法可以使用JSON格式的数据文件，JSON格式的数据文件作为数据驱动，其可扩展性和可维护性强。上述待测数据对象可以是服务接口的入参对象，该入参对象可以是Java对象，在Dubbo接口的自动化测试过程中，该入参对象可以包含调用Dubbo接口需要的参数，Dubbo接口需要的参数可以包括但不限于：服务接口名、服务版本号、服务方法名、服务方法的参数类型、服务方法的参数值。
上述步骤S101至步骤S102提供的技术方案中，上述服务框架的序列化协议可以用于将服务接口对象转换为字节流，当服务框架为Dubbo时，其序列化协议可以是Hessian序列化协议。
在本公开实施例中，先利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定，再利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果，通过为目标测试方法构建能够获取目标数据文件和待测数据对象的目标注解，达到了使测试方法与测试数据分离的目的，从而实现了提高目标测试方法的可复用性与测试效率、降低服务接口的测试成本的技术效果，进而解决了现有技术提供的服务接口的测试方法将测试数据与测试脚本耦合导致测试方法的可复用性差、测试成本高、测试效率低技术问题。
下面对本公开上述实施例的上述方法进行进一步介绍。
在一种可选的实施例中，服务接口的自动化测试方法还包括：
步骤S103，利用服务接口测试类调用预处理方法，对服务接口的测试环境进行预处理。
上述步骤S103提供的技术方案中，上述预处理方法可以是TestNG测试框架中的OnTestStart方法，该方法可以在测试方法执行之前进行预处理操作，预处理操作可以包括但不限于：初始化测试环境(如创建数据库链接、加载配置文件、启动服务)，准备测试数据(如将测试数据插入至数据库、创建临时文件)，设置测试上下文(如设置全局变量、注入依赖)。此处还需要说明的是，预处理方法可以减少测试方法中的重复代码，提高测试效率、提升测试方法的可维护性。
以下结合图2对上述方法进行进一步说明。
图2是根据本公开实施例的一种可选的服务接口的自动化测试流程的示意图，如图2所示，在对服务接口进行自动化测试时，先使用自动化测试过程的核心处理类(上述服务接口测试类，命名为AutoInterfaceTest)构建目标注解(@AutoTestData)，并为该目标注解增加第一属性value和第二属性clazz，接着，使用OnTestStart预处理方法对服务接口的测试环境进行预处理。
在一种可选的实施例中，服务接口的自动化测试方法还包括：
步骤S1041，确定目标测试方法是否包含目标注解；
步骤S1042，响应于目标测试方法未包含目标注解，利用服务接口测试类为目标测试方法构建目标注解，得到更新后的目标测试方法。
依然如图2所示，在利用预处理方法对服务接口的测试环境进行预处理之后，可以通过Java反射的方式扫描服务接口测试类，以检验测试方法是否包含目标注解，当测试方法包含目标注解时，使用该测试方法对测试数据进行自动化测试；当测试方法未包含目标注解时，使用服务接口测试类为该测试方法构建目标注解，并为目标注解添加第一属性和第二属性，从而得到更新后的测试方法，进而使用更新后的测试方法对测试数据进行测试。
在一种可选的实施例中，在步骤S102中，利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果，包括：
步骤S1011，利用预设反射方式获取目标注解的第一属性和第二属性；
步骤S1012，基于第一属性，确定目标数据文件的测试用例；
步骤S1013，基于第二属性，确定待测数据对象；
步骤S1014，将测试用例和待测数据对象传递至目标测试方法，以执行目标测试方法，得到测试结果。
上述步骤S1011至步骤S1014提供的技术方案中，上述预设反射方式可以是Java反射，此处需要说明的是，Java反射可以在自动化测试过程中动态获取和操作数据，包括但不限于：获取类的信息(如类的属性、方法、构造函数)，动态创建对象，动态调用方法，动态访问属性。上述测试结果可以用于确定服务接口的功能是否正常，测试结果可以包括但不限于：服务接口是否成功调用、服务接口的响应时间、服务接口的返回结果、服务接口在不同负载下的性能表现(如吞吐量)、服务接口在不同环境与不同版本下的兼容性。
在一种可选的实施例中，在步骤S1022中，基于第一属性，确定目标数据文件的 测试用例，包括：
步骤S1021，利用第一属性获取目标数据文件的路径；
步骤S1022，根据路径，读取目标数据文件；
步骤S1023，对目标数据文件进行解析，得到测试用例。
本公开提供的技术方案中，在对服务接口进行自动化测试前，预先编写JSON格式的数据文件，在该数据文件中，可以定义JSON数据结构，包括请求入参的JSON对象、预期结果的JSON对象，此处需要说明的是，预期结果的JSON对象可以用于与请求入参的JSON对象进行比对，以确定服务接口的请求入参的JSON对象是否测试成功。此处还需要说明的是，JSON数据结构可以是JSON对象数组的格式，一个JSON对象可以作为一条测试用例，一个JSON对象数组文件可以包括一个测试接口对应的多个测试用例。还可以了解到的是，目标数据文件的存储位置可以是：本地文件系统中的预设路径、类路径下的预设目录、数据库、远程文件系统。
本公开提供的技术方案中，对目标数据文件进行解析，得到的测试用例可以包括以下数据：服务接口的名称、服务接口的版本号、服务接口中定义的方法的名称和参数列表、每个方法的参数类型、每个方法的返回值类型。
在一种可选的实施例中，在步骤S1023中，基于第二属性，确定待测数据对象，包括：
步骤S1031，利用第二属性获取待测数据对象的目标类型；
步骤S1032，对目标类型进行解析，得到第一解析结果；
步骤S1033，对第一解析结果进行反序列化，得到待测数据对象。
上述步骤S1031至步骤S1033提供的技术方案中，上述待测数据对象的目标类型可以是待测数据对象的类类型(即class类型)，此处需要说明的是，待测数据对象的目标类型也可以由服务框架的序列化协议确定。上述第一解析结果可以包括但不限于：待测数据对象的类型、待测数据对象的数据结果，此处还需要说明的是，待测数据对象的类型可以是但不限于：JSON，待测对象的数据结构可以是但不限于：Map、List、JSONObject。
依然如图2所示，本公开提供的技术方案中，在确定测试方法包含目标注解后，通过Java反射的方式获取目标注解的第一属性和第二属性，进一步地，一方面，可以根据第一属性获取的目标数据文件的路径是否为空，确定是否存在目标数据文件，当目标数据文件的路径非空时，确定目标数据文件存在，进一步地，读取目标数据文件， 使用JsonPath对目标数据文件进行解析，得到测试用例的集合。另一方面，在通过Java反射的方式获取目标注解的第一属性和第二属性后，生成代理服务引用，以对目标测试方法进行初始化操作(如确保测试方法支持Dubbo服务的调用)，接着，使用JsonPath先对第二属性获取的待测数据对象的目标类型进行解析，再将解析结果进行反序列化，以得到测试方法对象(即待测数据对象)。
在一种可选的实施例中，在步骤S1024中，执行目标测试方法，得到测试结果，包括：
步骤S1051，在目标测试方法执行过程中，获取服务接口的返回值；
步骤S1052，对返回值进行解析，得到待测数据对象的测试值；
步骤S1053，对待测数据对象的测试值与预期数据对象的字段值进行断言，得到测试结果。
上述步骤S1051至步骤S1053提供的技术方案中，上述服务接口的返回值可以包括但不限于：待测数据对象的数据类型、引用类型的对象(如集合对象、Map对象)、服务接口的异常信息。上述待测数据对象的测试值可以是待测数据对象的字段值。
依然如图2所示，本公开提供的技术方案中，在获取到测试用例的集合后，遍历集合中的每个测试用例，再通过Java反射的方式调用包含反序列化后的待测数据对象的测试方法，以将当前测试用例与测试方法绑定，进一步地，执行绑定后的测试方法，并获取测试方法执行过程中服务接口的返回值，接着，可以使用JsonPath先解析服务接口的返回值得到待测数据对象的字段值(测试值)，再将待测数据对象的字段值与预期数据对象的字段值进行准确性断言，也即，比较待测数据对象的字段值与预期数据对象的字段值是否一致，当二值一致时，可以确定服务接口的功能正常，反之，确定服务接口的功能异常。以及，在对每个测试用例测试结束后，记录当前测试用例的执行结果。此处需要说明的是，由于不同的测试用例对应的待测数据对象不同，因此，在每次确定测试用例后，均需要通过反射调用测试方法将当前测试用例与包含对应待测数据对象的测试方法绑定。
依然如图2所示，本公开提供的技术方案中，在对每个测试用例测试结束后，判断目标数据文件解析得到的测试用例的集合是否为空，当测试用例的集合为非空时，对利用反射调用的测试方法对下一个测试用例进行测试；当测试用例的集合为空时，确定服务接口的自动化测试过程结束。
在一种可选的实施例中，服务接口的自动化测试方法还包括：
步骤S106，响应于目标数据文件的路径为空，确定目标数据文件存在异常，生成目标数据文件的异常反馈信息。
依然如图2所示，当通过第一属性获取的目标数据文件的路径为空时，确定目标数据文件异常，此时，生成目标数据文件的异常反馈信息(如在显示设备上显示“文件不存在”)，以避免服务接口的自动化测试进程长时间卡顿或异常退出，从而提升了服务接口的测试方法的灵活性、提高了服务接口的自动化测试效率。
在一种可选的实施例中，服务接口的自动化测试方法还包括：
步骤S1071，利用服务接口测试类调用目标监听器的监听接口，监听目标测试方法的执行过程；
步骤S1072，记录执行过程；
步骤S1073，响应于通过执行过程确定目标测试方法执行异常，利用预设异常解决办法对目标测试方法进行处理。
上述步骤S1071至步骤S1073提供的技术方案中，上述目标监听器可以是基于TestNG测试框架的监听器，上述监听接口可以是ITestListener接口。此处需要说明的是，在对Dubbo接口进行自动化测试过程中，ITestListener接口可以监听测试方法执行过程中的多种事件，包括但不限于：onStart事件，在测试方法执行开始时触发的事件(如初始化操作)；onFinish事件，在测试方法执行结束时触发的事件(如清理操作)；onTestStart事件，在测试方法执行之前触发的事件(如预处理操作)；onTestSuccess事件，测试方法执行成功时触发的事件，可以记录或处理测试方法执行成功的测试结果；onTestFailure事件，测试方法执行失败时触发的事件，可以记录或处理测试方法执行失败的测试结果。
上述步骤S1071至步骤S1073提供的技术方案中，上述预设异常解决办法可以由技术人员预先设置并存储于测试系统的目标存储位置，该预设异常解决办法可以包括但不限于：记录异常日志、生成并抛出异常通知或异常报警信息、重试测试方法、跳过一个或多个测试流程(如多个测试用例中某个测试用例的测试流程异常且无法继续执行时，跳过当前测试用例的测试流程并执行下一个测试用例的测试流程)、强制执行测试流程(如多个测试用例中某个测试用例的测试流程异常且可以继续执行时，强制继续执行当前测试用例的后续测试流程)。
依然如图2所示，本公开提供的技术方案中，在对服务接口进行自动化测试之前，可以使用核心处理类AutoInterfaceTest调用TestNG的ITestListener接口，使用该 监听接口对服务接口的自动化测试全流程进行监听，并记录每个流程的监听结果。当监听到某个测试流程异常时，从测试系统的目标存储位置查询并调用该测试流程对应的异常解决办法，以及时处理测试流程的异常问题、提高服务接口的自动化测试效率。
通过本公开提供的上述可选实施例，可以达到的技术效果为：
(1)构建包含目标注解标记的测试方法，使得测试方法和测试数据分离，提高了测试方法的可复用性与可维护性，提高了测试效率，降低了测试成本；
(2)通过对目标数据文件中的动态参数进行绑定，便于灵活修改请求入参对象的参数，进一步提高了测试效率，同时，提高了测试结果的准确性；
(3)使用反射机制动态调用测试方法，提升了执行测试用例的灵活性；
(4)使用JSON文件作为测试数据的载体，提高了测试数据的可维护性和管理效率。
在本实施例中，还提供了一种视频彩铃系统的交互处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，属于“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图3是根据本公开实施例的一种可选的服务接口的自动化测试装置的结构框图，如图3所示，该装置包括：
构建模块301，用于利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；
测试模块302，用于利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。
在一些实施例中，图4是根据本公开实施例的另一种可选的服务接口的自动化测试装置的结构框图，如图4所示，该装置除包括图3所示的所有模块外，还包括：预处理模块303，用于利用服务接口测试类调用预处理方法，对服务接口的测试环境进行预处理。
在一些实施例中，图5是根据本公开实施例的又一种可选的服务接口的自动化测试装置的结构框图，如图5所示，该装置除包括图4所示的所有模块外，还包括：更 新模块304，用于确定目标测试方法是否包含目标注解；响应于目标测试方法未包含目标注解，利用服务接口测试类为目标测试方法构建目标注解，得到更新后的目标测试方法。
在一些实施例中，上述测试模块302还用于：利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果，包括：利用预设反射方式获取目标注解的第一属性和第二属性；基于第一属性，确定目标数据文件的测试用例；基于第二属性，确定待测数据对象；将测试用例和待测数据对象传递至目标测试方法，以执行目标测试方法，得到测试结果。
在一些实施例中，上述测试模块302还用于：利用第一属性获取目标数据文件的路径；根据路径，读取目标数据文件；对目标数据文件进行解析，得到测试用例。
在一些实施例中，上述测试模块302还用于：利用第二属性获取待测数据对象的目标类型；对目标类型进行解析，得到第一解析结果；对第一解析结果进行反序列化，得到待测数据对象。
在一些实施例中，上述测试模块302还用于：在目标测试方法执行过程中，获取服务接口的返回值；对返回值进行解析，得到待测数据对象的测试值；对待测数据对象的测试值与预期数据对象的字段值进行断言，得到测试结果。
在一些实施例中，图6是根据本公开实施例的又一种可选的服务接口的自动化测试装置的结构框图，如图6所示，该装置除包括图5所示的所有模块外，还包括：生成模块305，用于响应于目标数据文件的路径为空，确定目标数据文件存在异常，生成目标数据文件的异常反馈信息。
在一些实施例中，图7是根据本公开实施例的又一种可选的服务接口的自动化测试装置的结构框图，如图7所示，该装置除包括图6所示的所有模块外，还包括：监听模块306，用于利用服务接口测试类调用目标监听器的监听接口，监听目标测试方法的执行过程；记录执行过程；响应于通过执行过程确定目标测试方法执行异常，利用预设异常解决办法对目标测试方法进行处理。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
在本实施例中，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行前述任意一项服务接口的自动化测试方法。
在一些实施例中，在本实施例中，上述存储介质可以被设置为用于执行以下步骤的程序：
步骤S1，利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；
步骤S2，利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。
在一些实施例中，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。
在本实施例中，还提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行前述任意一项服务接口的自动化测试方法。
在一些实施例中，在本实施例中，上述处理器可以被设置为用于执行以下步骤的程序：
步骤S1，利用服务接口测试类构建目标测试方法以及待测数据对象，其中，目标测试方法包括：构建目标注解，目标注解包括第一属性和第二属性，待测数据对象为服务接口的入参对象，第一属性用于获取目标数据文件的路径，目标数据文件包含服务接口的测试用例，第二属性用于获取待测数据对象的目标类型，目标类型由服务框架的序列化协议确定；
步骤S2，利用目标测试方法对待测数据对象和测试用例进行测试，得到测试结果。
上述本公开实施例序号仅仅为了描述，不代表实施例的优劣。
在本公开的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本公开所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所 显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本公开的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本公开原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本公开的保护范围。

Claims (14)

  1. 一种服务接口的自动化测试方法，包括：
    利用服务接口测试类构建目标测试方法以及待测数据对象，其中，所述目标测试方法包括：构建目标注解，所述目标注解包括第一属性和第二属性，所述待测数据对象为服务接口的入参对象，所述第一属性用于获取目标数据文件的路径，所述目标数据文件包含所述服务接口的测试用例，所述第二属性用于获取所述待测数据对象的目标类型，所述目标类型由服务框架的序列化协议确定；
    利用所述目标测试方法对所述待测数据对象和所述测试用例进行测试，得到测试结果。
  2. 根据权利要求1所述的自动化测试方法，还包括：
    利用所述服务接口测试类调用预处理方法，对所述服务接口的测试环境进行预处理。
  3. 根据权利要求2所述的自动化测试方法，还包括：
    确定所述目标测试方法是否包含所述目标注解；
    响应于所述目标测试方法未包含所述目标注解，利用所述服务接口测试类为所述目标测试方法构建所述目标注解，得到更新后的目标测试方法。
  4. 根据权利要求1-3中任一项所述的自动化测试方法，其中，利用所述目标测试方法对所述待测数据对象和所述测试用例进行测试，得到所述测试结果，包括：
    利用预设反射方式获取所述目标注解的所述第一属性和所述第二属性；
    基于所述第一属性，确定所述目标数据文件的所述测试用例；
    基于所述第二属性，确定所述待测数据对象；
    将所述测试用例和所述待测数据对象传递至所述目标测试方法，以执行所述目标测试方法，得到所述测试结果。
  5. 根据权利要求4所述的自动化测试方法，其中，基于所述第一属性，确定所述目标数据文件的所述测试用例，包括：
    利用所述第一属性获取所述目标数据文件的所述路径；
    根据所述路径，读取所述目标数据文件；
    对所述目标数据文件进行解析，得到所述测试用例。
  6. 根据权利要求4所述的自动化测试方法，其中，基于所述第二属性，确定所述待测数据对象，包括：
    利用所述第二属性获取所述待测数据对象的所述目标类型；
    对所述目标类型进行解析，得到第一解析结果；
    对所述第一解析结果进行反序列化，得到所述待测数据对象。
  7. 根据权利要求4所述的自动化测试方法，其中，执行所述目标测试方法，得到所述测试结果，包括：
    在所述目标测试方法执行过程中，获取服务接口的返回值；
    对所述返回值进行解析，得到所述待测数据对象的测试值；
    对所述待测数据对象的所述测试值与预期数据对象的字段值进行断言，得到所述测试结果。
  8. 根据权利要求1-7中任一项所述的自动化测试方法，还包括：
    响应于所述目标数据文件的路径为空，确定所述目标数据文件存在异常，生成所述目标数据文件的异常反馈信息。
  9. 根据权利要求1-8中任一项所述的自动化测试方法，还包括：
    利用所述服务接口测试类调用目标监听器的监听接口，监听所述目标测试方法的执行过程；
    记录所述执行过程。
  10. 根据权利要求9所述的自动化测试方法，还包括：
    响应于通过所述执行过程确定所述目标测试方法执行异常，利用预设异常解决办法对所述目标测试方法进行处理。
  11. 一种服务接口的自动化测试装置，包括：
    构建模块，用于利用服务接口测试类构建目标测试方法以及待测数据对象，其中，所述目标测试方法包括：构建目标注解，所述目标注解包括第一属性和第二属性，所述待测数据对象为服务接口的入参对象，所述第一属性用于获取目标数据文件的路径，所述目标数据文件包含所述服务接口的测试用例，所述第二属性用于获取所述待测数据对象的目标类型，所述目标类型由服务框架的序列化协议确定；
    测试模块，用于利用所述目标测试方法对所述待测数据对象和所述测试用例进行测试，得到测试结果。
  12. 一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1至10中任意一项所述服务接口的自动化测试方法。
  13. 一种电子设备，包括：
    至少一个处理器；以及
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1至10中任意一项所述服务接口的自动化测试方法。
  14. 一种计算机程序，包括计算机指令，其中所述计算机指令被处理器执行时实现如权利要求1-10中任一项所述的方法。
PCT/CN2023/137113 2023-08-11 2023-12-07 服务接口的自动化测试方法和装置、电子设备 Pending WO2025035656A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202311017101.5A CN116955203A (zh) 2023-08-11 2023-08-11 服务接口的自动化测试方法
CN202311017101.5 2023-08-11

Publications (1)

Publication Number Publication Date
WO2025035656A1 true WO2025035656A1 (zh) 2025-02-20

Family

ID=88452985

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/137113 Pending WO2025035656A1 (zh) 2023-08-11 2023-12-07 服务接口的自动化测试方法和装置、电子设备

Country Status (2)

Country Link
CN (1) CN116955203A (zh)
WO (1) WO2025035656A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116955203A (zh) * 2023-08-11 2023-10-27 中国电信股份有限公司 服务接口的自动化测试方法
CN117234944B (zh) * 2023-11-09 2024-01-30 天津华来科技股份有限公司 一种基于pytest的接口自动化测试方法
CN120670325B (zh) * 2025-08-21 2025-11-25 武汉达安科技有限公司 拼接场景道路合理性校核方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020119422A1 (zh) * 2018-12-15 2020-06-18 深圳壹账通智能科技有限公司 测试数据的加载方法、装置、计算机设备及存储介质
CN111459821A (zh) * 2020-04-01 2020-07-28 汇通达网络股份有限公司 一种基于TestNG的软件自动化单元测试方法
CN111881024A (zh) * 2020-07-13 2020-11-03 广联达科技股份有限公司 一种接口测试脚本的确定方法、装置、设备及存储介质
CN116955203A (zh) * 2023-08-11 2023-10-27 中国电信股份有限公司 服务接口的自动化测试方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020119422A1 (zh) * 2018-12-15 2020-06-18 深圳壹账通智能科技有限公司 测试数据的加载方法、装置、计算机设备及存储介质
CN111459821A (zh) * 2020-04-01 2020-07-28 汇通达网络股份有限公司 一种基于TestNG的软件自动化单元测试方法
CN111881024A (zh) * 2020-07-13 2020-11-03 广联达科技股份有限公司 一种接口测试脚本的确定方法、装置、设备及存储介质
CN116955203A (zh) * 2023-08-11 2023-10-27 中国电信股份有限公司 服务接口的自动化测试方法

Also Published As

Publication number Publication date
CN116955203A (zh) 2023-10-27

Similar Documents

Publication Publication Date Title
WO2025035656A1 (zh) 服务接口的自动化测试方法和装置、电子设备
US8438418B2 (en) Simplifying automated software maintenance of data centers
CN112148610A (zh) 测试用例执行方法、装置、计算机设备和存储介质
Ghoshal et al. Provenance from log files: a BigData problem
US9652353B2 (en) Monitoring business transaction failures involving database procedure calls
CN108459962A (zh) 代码规范性检测方法、装置、终端设备及存储介质
CN114840489A (zh) 数据库版本更迭方法及装置、存储介质及电子装置
CN115658529A (zh) 用户页面的自动化测试方法以及相关设备
CN114115838A (zh) 一种基于分布式组件和云平台的数据交互方法及系统
CN114422564A (zh) 访问数据审计溯源方法、装置、计算机设备及存储介质
CN114003269A (zh) 组件处理方法、装置、电子设备及存储介质
CN116244186A (zh) 一种操作系统测试管理方法、装置与计算设备
CN112416803A (zh) 一种自动化测试方法和装置
US10585678B2 (en) Insertion of custom activities in an orchestrated application suite
CN110704025A (zh) 编码规范工具的生成方法和装置、存储介质、电子设备
CN112069082A (zh) 一种自动化测试方法及系统
CN111381989A (zh) 微服务链路生成方法、装置、服务器及存储介质
CN115437903A (zh) 接口测试方法、装置、设备、存储介质及程序
CN118838850A (zh) 一种微服务持续集成的场景自动化持续测试的方法及系统
CN118331886A (zh) 项目测试方法、计算机装置、存储介质和程序
CN114490530B (zh) 一种批量转联机文件处理方法和装置
CN117493179A (zh) 流量录制回放方法、装置、存储介质及电子设备
CN116048962A (zh) 测试报告生成方法、装置、计算机设备和存储介质
CN115237889A (zh) 数据库切换方法及装置、存储介质、计算机设备
CN121354649B (zh) 固态硬盘测试方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23949073

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE