Dubbo interface automatic test method, device, equipment and medium
By configuring the registration center address and interface information to generate a generalized call request, parsing Kafka messages and generating a test report, the dependency problem of Dubbo interface testing is solved and efficient automated testing is achieved.
Patent Information
- Application Number
- CN202510737989.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-04
- Publication Date
- 2025-09-19
AI Technical Summary
The existing Dubbo interface testing tool needs to rely on the JAR package provided by the service provider, which leads to high testing complexity and low efficiency, and time-consuming and labor-intensive service interface changes.
Configure the registration center address and service interface information through the page, generate generalized call parameters, use the Dubbo generalized API to generate call requests, parse the Kafka messages released by DevOps, trigger the test plan and compare the response results to generate a test report.
It reduces test complexity, improves test independence and flexibility, enables testers to quickly respond to service interface changes, and improves test efficiency.
Smart Images
Figure CN120670299A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of software testing technology, and in particular to a Dubbo interface automatic testing method, device, equipment and medium. Background Art
[0002] Microservice architecture has become mainstream in modern software development. As a widely used distributed service framework, automated testing of Dubbo's interfaces is particularly important. However, with the increasing number of microservices and increasing business complexity, Dubbo interface testing faces many challenges.
[0003] Existing tools typically require service providers to provide API JAR files. Testers must rely on the JAR files provided by the development team to conduct testing. This dependency not only increases testing complexity but can also limit testing progress to development progress. Furthermore, when service interfaces change, testers must re-obtain the JAR files and update the test environment, a time-consuming and labor-intensive process that significantly impacts testing efficiency. Summary of the Invention
[0004] The purpose of the embodiments of the present application is to propose a Dubbo interface automatic testing method, device, equipment and medium to improve the efficiency of Dubbo interface testing.
[0005] In order to solve the above technical problems, the embodiment of the present application provides a Dubbo interface automatic testing method, including:
[0006] Configure the registration center address and service interface information on the page to generate generalized call parameters;
[0007] Encapsulate the method name, input parameter type and parameter value in the generalized call parameter to generate a generalized call request;
[0008] The Kafka message published by DevOps is parsed based on the generalized call request, the associated test plan is triggered and executed, and the actual response result of the test plan is compared with the expected result to generate a test report.
[0009] In order to solve the above technical problems, the embodiment of the present application provides a Dubbo interface automatic testing device, including:
[0010] The generalized call parameter generation module is used to generate generalized call parameters by configuring the registration center address and service interface information on the page;
[0011] A generalized call request generation module is used to encapsulate the method name, input parameter type and parameter value in the generalized call parameters to generate a generalized call request;
[0012] The test plan execution module is used to parse the Kafka message released by DevOps based on the generalized call request, trigger the associated test plan and execute it, and compare the actual response results of the test plan with the expected results to generate a test report.
[0013] To solve the above technical problems, a technical solution adopted by the present invention is: to provide a computer device, including one or more processors; a memory for storing one or more programs, so that one or more processors can implement any one of the above-mentioned Dubbo interface automatic testing methods.
[0014] To solve the above technical problems, a technical solution adopted by the present invention is: a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements any one of the above-mentioned Dubbo interface automatic testing methods.
[0015] The embodiment of the present invention provides a method, device, equipment and medium for automatic testing of Dubbo interfaces. The method comprises: configuring the registration center address and service interface information through a page to generate generalized call parameters; encapsulating the method name, input parameter type and parameter value in the generalized call parameters to generate a generalized call request; parsing the Kafka message published by DevOps based on the generalized call request, triggering the associated test plan and executing it, and comparing the actual response results of the test plan with the expected results to generate a test report. The embodiment of the present invention adopts the Dubbo generalized API, so that testers do not need to introduce the JAR package of the business method. They only need to configure the registration center address and interface information to conduct testing. This not only reduces the complexity of the test, but also improves the independence and flexibility of the test, so that testers can respond quickly when the service interface changes, thereby helping to improve the efficiency of Dubbo interface testing. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0017] Figure 1 This is a flowchart of the implementation of the Dubbo interface automatic testing method provided in the embodiment of the present application;
[0018] Figure 2 This is a flowchart for implementing the first sub-process in the Dubbo interface automatic testing method provided in an embodiment of the present application;
[0019] Figure 3This is a flowchart of the process in the Dubbo interface automatic testing method provided by another embodiment of the present application;
[0020] Figure 4 This is a flowchart of the automated smoke test provided by an embodiment of the present application;
[0021] Figure 5 This is a flowchart for implementing the second sub-process in the Dubbo interface automatic testing method provided in an embodiment of the present application;
[0022] Figure 6 This is a flowchart for implementing the third sub-process in the Dubbo interface automatic testing method provided in an embodiment of the present application;
[0023] Figure 7 This is a flowchart for implementing the fourth sub-process in the Dubbo interface automatic testing method provided in an embodiment of the present application;
[0024] Figure 8 This is a schematic diagram of the Dubbo interface automatic testing device provided in an embodiment of the present application;
[0025] Figure 9 It is a schematic diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of the application are for the purpose of describing specific embodiments only and are not intended to limit this application. The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.
[0027] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0028] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.
[0029] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.
[0030] It should be noted that the Dubbo interface automatic testing method provided in the embodiment of the present application is generally executed by a server, and accordingly, the Dubbo interface automatic testing device is generally configured in the server.
[0031] See also Figure 1 , Figure 1 A specific implementation of the Dubbo interface automatic testing method is shown.
[0032] It should be noted that the method of the present invention is not limited to the method of Figure 1 The process sequence shown is limited to the following steps:
[0033] S1: Configure the registration center address and service interface information through the page to generate generalized call parameters.
[0034] Specifically, the subscription registration center has low flexibility, and the telnet api can use commons-net to implement telnet connection, which requires a relatively high development cost compared to the generalized API. However, the Dubbo generalized API has simple encapsulation without losing flexibility, so the embodiment of the present application adopts the Dubbo generalized API for encapsulation processing, and assertions and variable extractions are uniformly processed by encapsulating various functions in the java language. The invoke method of the Dubbo generalized API does not need to introduce the business method jar package to call the dubbo interface. The test only needs to configure the registration center address, and fill in the interface fully qualified name method name and input parameter type and parameter value information of the implementation class on the use case details page. The server parses the configuration registration center address, encapsulates the page data into 3 parameters, and calls the genericService.$invoke(param.getMethodName(), param.getArgTypes(), param.getArgObjects()) method to send the dubbo request, which solves the problem of not having to rely on the service provider to provide the jar package.
[0035] In the embodiment of the present application, the registration center address and service interface information are configured on the page to generate generalized call parameters.
[0036] See also Figure 2 , Figure 2 A specific implementation of step S1 is shown, which is described in detail as follows:
[0037] S11: providing a registration center address input box on the page to obtain the registration center address of Zookeeper or Nacos input by the user.
[0038] Specifically, on the configuration page, design an input box that allows users to enter the address of the registry center. This input box can be a text box, in which users can enter the address of the Zookeeper or Nacos registry center. After the user enters the address, the system can perform a simple format validation to ensure that the entered address conforms to the address format requirements of Zookeeper or Nacos. For example, the address of Zookeeper is usually `host:port`, while the address of Nacos is usually `http: / / host:port`.
[0039] S12: Obtain the fully qualified interface name, method name, parameter type list and parameter value of the Dubbo service input by the user to obtain the service interface information.
[0040] Specifically, an input box is provided on the page where the user can enter the fully qualified interface name of the Dubbo service (that is, the complete interface name including the package name). For example: `com.example.DemoService`. Another input box is provided where the user can enter the method name to be called. For example: `sayHello`. This application also provides an input box or drop-down menu where the user can enter or select a list of parameter types for the method. The parameter type can be a basic Java type (such as `int`, `String`, etc.) or a custom type (such as `com.example.User`). Multiple parameter types can be separated by commas. For example: `java.lang.String,int`. This application provides an input box where the user can enter the parameter value of the method. The parameter values should correspond one-to-one to the types in the parameter type list and can be separated by commas. For example: `"Hello",123`.
[0041] S13: Generate the generalized call parameters based on the registration center address and the service interface information.
[0042] Specifically, based on the information entered by the user in steps S11 and S12, the system assembles the registry center address and service interface information into the parameters required for the generalized call. These parameters typically include: the registry center address (such as the address of Zookeeper or Nacos), the fully qualified interface name, the method name, the parameter type list, and the parameter value. Furthermore, embodiments of the present application can generate a generalized call request object that contains all the necessary information and can be used for generalized calls in Dubbo.
[0043] See also Figure 3 and Figure 4 , Figure 3 A specific implementation method before step S1 is shown. Figure 4This is a flowchart of the automated smoke test provided by the embodiment of the present application, which is described in detail as follows:
[0044] S1A: When receiving the Jenkins configuration service startup, call the http interface of the automated testing platform.
[0045] Specifically, before implementing step S1, the embodiment of the present application requires a smoke test. Therefore, when the service configured by Jenkins is started, the system automatically triggers the call of the HTTP interface of the automated testing platform. The interface provided by the automated testing platform is called through an HTTP request to notify the platform that the current service has been started and is ready for smoke testing. The HTTP request contains some basic metadata, such as the service name and environment information, which is used to identify the currently started service.
[0046] S1 B: Report the deployed application code, application name, and environment code information through the http interface.
[0047] Specifically, when calling the HTTP interface, the system reports the following key information: application code, application name, and environment code. The application code uniquely identifies the current application (e.g., `APP001`). The application name is the name of the current application (e.g., `UserService`). The environment code identifies the currently deployed environment (e.g., `DEV` for development environment, `TEST` for test environment).
[0048] S1 C: According to the application code and the environment code, determine whether smoke test configuration is enabled in the automated testing platform and associate and report a test plan of the application code and the environment code.
[0049] Specifically, after receiving the reported information, the automated testing platform will check the following based on the application code and the environment code: (1) whether the smoke test configuration is enabled in the environment; (2) whether there is a test plan associated with the application code and the environment code. If there is an associated test plan, the platform will further obtain detailed information about the test plan, including test cases, execution order, etc. If the smoke test configuration is enabled and an associated test plan exists, the process proceeds to step S1D. If the smoke test configuration is not enabled or there is no associated test plan, the process ends and the smoke test is not performed.
[0050] S1 D: If yes, call the plan execution interface to execute the smoke test plan.
[0051] Specifically, if the conditions are met (i.e., the smoke test configuration is enabled and an associated test plan exists), the automated testing platform will call its internal plan execution interface to trigger the execution of the smoke test plan. The test execution process is as follows: the platform will execute the test cases in the order specified in the test plan. Test cases may include interface testing, functional verification, performance checks, etc. After the test execution is completed, the platform will generate a test report and feedback the results to Jenkins or related systems. If the test fails, the platform may trigger an alarm or notify relevant personnel.
[0052] The embodiment of the present application realizes the automation of the entire process from service startup to automated smoke testing. This approach can significantly improve testing efficiency, ensure that core functions can be quickly verified after each service deployment, and reduce manual intervention and errors.
[0053] S2: Encapsulate the method name, input parameter type and parameter value in the generalized call parameter to generate a generalized call request.
[0054] Specifically, the method name, input parameter type, and parameter value in the generic call parameters are encapsulated to generate a generic call request, which is used to call the Dubbo service. The generic call request is GenericService.$invoke.
[0055] See also Figure 5 , Figure 5 A specific implementation of step S2 is shown, which is described in detail as follows:
[0056] S21: Convert the method name into a string format and use it as the first parameter of the $invoke() method.
[0057] Specifically, extract the method name from the generalized call parameters. Treat the method name as a string and use it as the first parameter of the `$invoke()` method.
[0058] S22: Convert the input parameter type list into a string array format as the second parameter of the $invoke() method.
[0059] Specifically, extract the input parameter type list from the generalized call parameters; convert the input parameter type list into a string array format, where each element is a fully qualified name of a parameter type.
[0060] S23: Convert the parameter value list into an object array format as the third parameter of the $invoke() method.
[0061] Specifically, a parameter value list is extracted from the generalized call parameters and converted into an object array format, where each element is a Java object corresponding to the parameter value.
[0062] S24: Call the GenericService.$invoke() method, pass the method name, the input parameter type and the parameter value to the Dubbo framework, and generate the generalized call request.
[0063] Specifically, Dubbo provides the `GenericService` interface to support generic invocation. Therefore, calling the GenericService.$invoke() method passes the method name, input parameter type, and parameter value to the Dubbo framework to generate the generic invocation request. The Dubbo framework generates a generic invocation request based on the passed parameters and sends the request to the target service. After the target service executes, it returns the result to the caller.
[0064] This embodiment of the application encapsulates the user-entered generalized call parameters (method name, input parameter type, parameter value) into the format required by the Dubbo framework and calls the `GenericService.$invoke()` method to generate a generalized call request. This approach simplifies the implementation of generalized calls, allowing users to complete service calls by simply providing the necessary parameters without having to worry about the underlying details.
[0065] S3: Parse the Kafka message published by DevOps based on the generalized call request, trigger the associated test plan and execute it, compare the actual response result of the test plan with the expected result, and generate a test report.
[0066] See also Figure 6 , Figure 6 A specific implementation of step S3 is shown, which is described in detail as follows:
[0067] S31: Subscribe to the Kafka message queue to listen to DevOps publishing events and obtain the Kafka message.
[0068] Specifically, we subscribe to the Kafka message queue and listen for event messages published by the DevOps platform. Kafka messages are published in JSON format and contain information such as the application code, environment code, and deployment version. We use a Kafka consumer to continuously monitor the message queue and immediately trigger subsequent processes upon receiving a new published event.
[0069] S32: Parse the content of the Kafka message to extract application code, environment code and deployment version information.
[0070] Specifically, the Kafka message content is parsed to extract the application code, environment code, and deployment version information. The application code identifies the published application (e.g., APP001). The environment code identifies the published environment (e.g., DEV for a development environment). The deployment version identifies the published version number (e.g., 1.0.0). The parsed information is stored in memory or a database for subsequent use.
[0071] S33: Obtaining a test plan associated with the automated testing platform according to the application code and the environment code.
[0072] Specifically, based on the parsed application code and environment code, the automated testing platform is checked to see if there is an associated test plan. A test plan typically includes the following information: a list of test cases, expected result configuration, execution order, and dependencies. If an associated test plan exists, the process proceeds to step S34. If not, the process ends.
[0073] S34: Triggering the execution of the Dubbo service call through the generalized call request to trigger the execution of the associated test plan.
[0074] Specifically, the generalized call request generated in step S2 is used to trigger a Dubbo service call. The automated testing platform executes the tests sequentially according to the order of the test cases in the test plan. Each test case calls the Dubbo service and obtains the actual response result.
[0075] S35: Compare the actual response result of the test plan with the expected result, and generate the test report.
[0076] See also Figure 7 , Figure 7 A specific implementation of step S35 is shown, which is described in detail as follows:
[0077] S351: Extract the actual response result of the Dubbo interface call and convert the actual response result into JSON format.
[0078] Specifically, obtain the actual response result from the Dubbo service call and convert the actual response result into JSON format for subsequent processing.
[0079] S352: Use the JSONPath expression to extract the value of the target field from the actual response result to obtain the target value.
[0080] Specifically, based on the user-configured JSONPath expression, the target field value is extracted from the actual response result to obtain the target value. The extracted target value is stored as a variable for subsequent comparison.
[0081] S353: Determine whether the target value matches the expected result configured by the user, and obtain a matching result.
[0082] S354: Generate the test report according to the matching result.
[0083] Specifically, the user pre-configures the expected results. If the target value matches the expected result, the test is marked as passed. If the target value does not match the expected result, the test is marked as failed. The matching results are stored in the test report. The test report includes the test case name, actual response result, expected result, and matching result (pass / fail). The test report can be generated in HTML, JSON, or PDF format. The test report is stored in the file system or database. The test results are sent to relevant personnel via email, message notification, etc.
[0084] Specifically, the embodiments of this application automate the entire process from monitoring DevOps release events, triggering and executing test plans, to generating test reports. This approach can significantly improve testing efficiency, ensure that core functions can be quickly verified after each release, and reduce manual intervention and errors.
[0085] In a specific embodiment, input boxes corresponding to the project, use case set, use case and test plan are provided in a visual page of an automated testing platform, and users can enter the corresponding information on the page. The automated testing platform also provides a page and input box corresponding to the newly added registration center. The registration center supports zookeeper and nacos. Users can fill in the registration center name and address and click OK to save. The registration center name will not be repeated under the same project. The automated testing platform also provides API testing Use Case Set Create a new use case set corresponding page and input box. Among them, the new use case set pop-up box field description:
[0086] Use Case Set Name: The name of the use case set for the same project cannot be repeated, and it is a required field. Use Case Set Type: The drop-down options are dubbo and api2.0 (http interface), and they are required. Environment: Select from the drop-down menu. Click the environment configuration option in the drop-down menu to add a new environment configuration. The environment configuration can be understood as a public variable at the project level and can be obtained through ${variable name}. It is not required. Custom Variables: Variables at the use case set level. They can be obtained through ${variable name} and are not required.
[0087] The automated testing platform also provides a test case set viewing page. Users can click the View button on the test case set list page to view the test case set added in step 2. After filling in the test case information, the user clicks Save. After saving, refresh the list and click the Debug button to view the test case execution results. Users can also add assertions using the jsonPattern, using the ${R.XXX} format. The automated testing platform also provides a results viewing page. Users can click Debug to view execution results and assertion variable extraction results. The automated testing platform also provides pages and functions for creating test plans, executing test plans, and viewing execution results and reports.
[0088] In an embodiment of the present application, the registration center address and service interface information are configured on a page to generate generalized call parameters; the method name, input parameter type, and parameter value in the generalized call parameters are encapsulated to generate a generalized call request; the Kafka message released by DevOps is parsed based on the generalized call request, the associated test plan is triggered and executed, and the actual response results of the test plan are compared with the expected results to generate a test report. By adopting the Dubbo generalized API, the embodiment of the present invention does not need to introduce the JAR package of the business method. The tester only needs to configure the registration center address and interface information to perform the test. This not only reduces the complexity of the test, but also improves the independence and flexibility of the test, allowing the tester to respond quickly when the service interface changes, thereby helping to improve the efficiency of Dubbo interface testing.
[0089] Please refer to Figure 8 , as a response to the above Figure 1 The present application provides an embodiment of a Dubbo interface automatic testing device. Figure 1 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.
[0090] like Figure 8 As shown, the Dubbo interface automatic testing device of this embodiment includes: a generalized call parameter generation module 41, a generalized call request generation module 42 and a test plan execution module 43, wherein:
[0091] The generalized call parameter generation module 41 is used to generate generalized call parameters by configuring the registration center address and service interface information on the page;
[0092] A generalized call request generating module 42 is used to encapsulate the method name, input parameter type and parameter value in the generalized call parameters to generate a generalized call request;
[0093] The test plan execution module 43 is used to parse the Kafka message released by DevOps based on the generalized call request, trigger the associated test plan and execute it, and compare the actual response result of the test plan with the expected result to generate a test report.
[0094] Furthermore, the generalized call parameter generation module 41 includes:
[0095] A registration center address input unit is used to provide a registration center address input box in the page to obtain the registration center address of Zookeeper or Nacos input by the user;
[0096] A service interface information acquisition unit is used to obtain the fully qualified interface name, method name, parameter type list and parameter value of the Dubbo service input by the user to obtain the service interface information;
[0097] A parameter generating unit is used to generate the generalized call parameters based on the registration center address and the service interface information.
[0098] Furthermore, the generalized call request generation module 42 includes:
[0099] A first conversion unit is used to convert the method name into a string format as the first parameter of the $invoke() method;
[0100] A second conversion unit is used to convert the input parameter type list into a string array format as the second parameter of the $invoke() method;
[0101] A third conversion unit is used to convert the parameter value list into an object array format as the third parameter of the $invoke() method;
[0102] The parameter passing unit is used to call the GenericService.$invoke() method, pass the method name, the input parameter type and the parameter value to the Dubbo framework, and generate the generalized call request.
[0103] Furthermore, the test plan execution module 43 includes:
[0104] A Kafka message acquisition unit is used to obtain the Kafka message by subscribing to the Kafka message queue and listening to the DevOps publishing event;
[0105] A content parsing unit, configured to parse the content of the Kafka message to extract application code, environment code, and deployment version information;
[0106] A test plan acquisition unit, configured to acquire a test plan associated with the automated test platform according to the application code and the environment code;
[0107] A plan execution unit, configured to trigger the execution of a Dubbo service call through the generalized call request, so as to trigger the execution of the associated test plan;
[0108] A test report generating unit is used to compare the actual response result of the test plan with the expected result and generate the test report.
[0109] Furthermore, the test report generating unit includes:
[0110] An actual response result extraction unit is used to extract the actual response result of the Dubbo interface call and convert the actual response result into JSON format;
[0111] The target value extraction unit is used to extract the value of the target field from the actual response result using a JSONPath expression to obtain the target value;
[0112] A matching unit, configured to determine whether the target value matches the expected result configured by the user, and obtain a matching result;
[0113] A report generating unit is used to generate the test report according to the matching result.
[0114] Furthermore, before the generalized call parameter generation module 41, the following steps are also included:
[0115] The interface calling module is used to call the http interface of the automated testing platform when receiving the Jenkins configuration service startup.
[0116] A deployment module, configured to report the deployed application code, application name, and environment code information through the http interface;
[0117] a judgment unit, configured to judge whether a smoke test configuration is enabled in the automated testing platform according to the application code and the environment code, and to associate and report a test plan of the application code and the environment code;
[0118] The smoke test plan unit is used to call the plan execution interface to execute the smoke test plan if yes.
[0119] In an embodiment of the present application, the registration center address and service interface information are configured on a page to generate generalized call parameters; the method name, input parameter type, and parameter value in the generalized call parameters are encapsulated to generate a generalized call request; the Kafka message released by DevOps is parsed based on the generalized call request, the associated test plan is triggered and executed, and the actual response results of the test plan are compared with the expected results to generate a test report. By adopting the Dubbo generalized API, the embodiment of the present invention does not need to introduce the JAR package of the business method. The tester only needs to configure the registration center address and interface information to perform the test. This not only reduces the complexity of the test, but also improves the independence and flexibility of the test, allowing the tester to respond quickly when the service interface changes, thereby helping to improve the efficiency of Dubbo interface testing.
[0120] To solve the above technical problems, the present application also provides a computer device. Figure 9 , Figure 9 This is a basic structural block diagram of the computer device in this embodiment.
[0121] The computer device 5 includes a memory 51, a processor 52, and a network interface 53 that are interconnected through a system bus. It should be noted that Figure 9 Only a computer device 5 having three components, memory 51, processor 52, and network interface 53, is shown. However, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead. It should be understood by those skilled in the art that a computer device herein is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.
[0122] Computer devices can be desktop computers, laptops, PDAs, cloud servers, etc. Computer devices can interact with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.
[0123] The memory 51 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, magnetic disk, optical disk, etc. In some embodiments, the memory 51 can be an internal storage unit of the computer device 5, such as the hard disk or memory of the computer device 5. In other embodiments, the memory 51 can also be an external storage device of the computer device 5, such as a plug-in hard disk equipped on the computer device 5, a smart memory card (SMC), a secure digital (SD) card, a flash memory card, etc. Of course, the memory 51 can also include both the internal storage unit of the computer device 5 and its external storage devices. In this embodiment, the memory 51 is generally used to store the operating system and various application software installed on the computer device 5, such as the program code of the Dubbo interface automatic testing method. In addition, the memory 51 can also be used to temporarily store various types of data that have been output or are about to be output.
[0124] In some embodiments, the processor 52 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 52 is generally used to control the overall operation of the computer device 5. In this embodiment, the processor 52 is used to execute program code stored in the memory 51 or process data, such as executing the program code of the Dubbo interface automatic testing method described above to implement various embodiments of the Dubbo interface automatic testing method.
[0125] The network interface 53 may include a wireless network interface or a wired network interface. The network interface 53 is generally used to establish a communication connection between the computer device 5 and other electronic devices.
[0126] The present application also provides another embodiment, namely, providing a computer-readable storage medium, which stores a computer program. The computer program can be executed by at least one processor to enable the at least one processor to perform the steps of the above-mentioned Dubbo interface automatic testing method.
[0127] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of each embodiment of the present application.
[0128] Obviously, the embodiments described above are only some of the embodiments of the present application, rather than all of the embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present application specification and the accompanying drawings, directly or indirectly used in other related technical fields, is also within the scope of protection of the present application.
Claims
1. A Dubbo interface automatic testing method, characterized in that: include: Configure the registration center address and service interface information on the page to generate generalized call parameters; Encapsulate the method name, input parameter type and parameter value in the generalized call parameter to generate a generalized call request; The Kafka message published by DevOps is parsed based on the generalized call request, the associated test plan is triggered and executed, and the actual response result of the test plan is compared with the expected result to generate a test report.
2. The Dubbo interface automatic testing method according to claim 1, characterized in that: The page configuration registration center address and service interface information generates generalized call parameters, including: A registration center address input box is provided on the page to obtain the registration center address of Zookeeper or Nacos entered by the user; Obtain the fully qualified interface name, method name, parameter type list and parameter value of the Dubbo service input by the user to obtain the service interface information; The generalized call parameters are generated based on the registration center address and the service interface information.
3. The Dubbo interface automatic testing method according to claim 1, characterized in that: The method name, input parameter type and parameter value in the service interface information are encapsulated to generate a generalized call request, including: Convert the method name into a string format and use it as the first parameter of the $invoke() method; Convert the input parameter type list into a string array format as the second parameter of the $invoke() method; Convert the parameter value list into an object array format and use it as the third parameter of the $invoke() method; Call the GenericService.$invoke() method, pass the method name, the input parameter type and the parameter value to the Dubbo framework, and generate the generalized call request.
4. The Dubbo interface automatic testing method according to claim 1, characterized in that: The Kafka message published by DevOps is parsed based on the generalized call request, the associated test plan is triggered and executed, and the actual response result of the test plan is compared with the expected result to generate a test report, including: Subscribe to the Kafka message queue to listen to DevOps publishing events and obtain the Kafka messages; Parsing the content of the Kafka message to extract application code, environment code, and deployment version information; Obtaining a test plan associated with the automated testing platform according to the application code and the environment code; Triggering the execution of a Dubbo service call through the generalized call request to trigger the execution of the associated test plan; The actual response result of the test plan is compared with the expected result to generate the test report.
5. The Dubbo interface automatic testing method according to claim 4, characterized in that: The comparing the actual response result of the test plan with the expected result to generate the test report includes: Extract the actual response result of the Dubbo interface call and convert the actual response result into JSON format; Use JSONPath expression to extract the value of the target field from the actual response result to obtain the target value; Determine whether the target value matches the expected result configured by the user, and obtain a matching result; The test report is generated according to the matching result.
6. The Dubbo interface automatic testing method according to any one of claims 1 to 5, characterized in that: Before configuring the registration center address and service interface information through the page to generate generalized call parameters, the method further includes: When receiving the Jenkins configuration service startup, call the http interface of the automated testing platform, Report the deployed application code, application name, and environment code information through the http interface; According to the application code and the environment code, determining whether smoke test configuration is enabled in the automated testing platform and associating and reporting a test plan of the application code and the environment code; If so, call the plan execution interface to execute the smoke test plan.
7. A Dubbo interface automatic testing device, characterized in that: include: The generalized call parameter generation module is used to generate generalized call parameters by configuring the registration center address and service interface information on the page; A generalized call request generation module is used to encapsulate the method name, input parameter type and parameter value in the generalized call parameters to generate a generalized call request; The test plan execution module is used to parse the Kafka message released by DevOps based on the generalized call request, trigger the associated test plan and execute it, and compare the actual response results of the test plan with the expected results to generate a test report.
8. The Dubbo interface automatic testing device according to claim 7, characterized in that: The generalized call parameter generation module includes: A registration center address input unit is used to provide a registration center address input box in the page to obtain the registration center address of Zookeeper or Nacos input by the user; A service interface information acquisition unit is used to obtain the fully qualified interface name, method name, parameter type list and parameter value of the Dubbo service input by the user to obtain the service interface information; A parameter generating unit is used to generate the generalized call parameters based on the registration center address and the service interface information.
9. A computer device, characterized in that: The method comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the Dubbo interface automatic testing method according to any one of claims 1 to 6 is implemented.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the Dubbo interface automatic testing method according to any one of claims 1 to 6.