Interface automation testing method, device, equipment and storage medium

Abstract

The embodiment of the present application provides an interface automation testing method, device, equipment and storage medium, which belongs to the field of testing technology. The method includes obtaining a test case set sent by a server that is in communication with the execution end; the test case set is issued by the server when it detects that the execution end is in an idle state; determining the target test case from the test case set according to the preset task rules; obtaining the operating system type and the general process corresponding to the target test case; executing the multiple execution steps included in the target test case in sequence according to the execution order set in the general process; in the execution process of each execution step, determining the difference interface corresponding to the currently executed execution step according to the operating system type; performing interface testing on the device to be debugged through the difference interface to obtain the interface test result. The embodiment of the present application can realize unified management of the interface testing process for different operating systems, and improve the convenience of management and maintenance of the testing process.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to an interface automation testing method, device, equipment and storage medium. Background Art

[0002] As software systems continue to expand in scale, the necessity and difficulty of software system testing to ensure delivery quality are self-evident. The limitations of traditional manual testing are also becoming increasingly apparent. Automated testing technology can overcome many of these issues. Therefore, interface automation testing is often used to automate user interface test cases. This primarily involves two phases: recording test case scripts and executing them. During the execution phase, the test case script data is executed on the execution side, and a report on the test results is output. However, for different operating systems, separate projects are typically built to adapt the execution of user interface test cases for each operating system. Consequently, data recording (such as screenshots, logs, and fault tolerance) throughout the execution process, all requiring separate, independent workflows, from startup to execution, requires inefficient management and maintenance of the user interface testing process. Summary of the Invention

[0003] The main purpose of the embodiments of the present application is to propose an interface automation testing method, device, equipment and storage medium, aiming to achieve unified management of the interface testing process for different operating systems and improve the convenience of management and maintenance of the testing process.

[0004] To achieve the above objectives, a first aspect of an embodiment of the present application provides an interface automation testing method, which is applied to an execution end. The method includes:

[0005] Obtaining a test case set sent by a server in communication with the execution end; wherein the test case set is sent by the server when it detects that the execution end is in an idle state;

[0006] Determine a target test case from the test case set according to a preset task rule;

[0007] Obtaining an operating system type and a general process corresponding to the target test case;

[0008] Execute the multiple execution steps of the target test case in sequence according to the execution order set in the general process;

[0009] During the execution of each of the execution steps, determining the difference interface corresponding to the currently executed execution step according to the operating system type;

[0010] An interface test is performed on the device to be debugged through the difference interface to obtain an interface test result.

[0011] In some embodiments, performing an interface test on the device to be tested through the difference interface to obtain an interface test result includes:

[0012] Obtaining the execution result corresponding to the difference interface;

[0013] When the execution result indicates that the execution step fails, obtaining a preset positioning element list;

[0014] Selecting the first positioning element from the positioning element list as the abnormal positioning element;

[0015] Performing control location processing on the execution result through the exception location element to obtain control location data;

[0016] When the control locating data does not locate the abnormal control, reselecting a second locating element from the locating element list to update the abnormal locating element, and re-performing control locating processing on the execution result using the updated abnormal locating element;

[0017] When all positioning elements in the positioning element list have been traversed or the control positioning data has been positioned at an abnormal control, stopping the control positioning process;

[0018] An interface test result is obtained according to the execution result and the control positioning data.

[0019] In some embodiments, when the control location data has located an abnormal control, after performing control location processing, the method further includes:

[0020] Matching the control location data with a preset interference list to determine whether there are interference factors;

[0021] When the interference factor exists, re-calling the difference interface to perform interface testing on the device to be tested;

[0022] In the process of re-calling the difference interface to perform interface testing on the device to be tested, the dialog box popped up by the interference factor is eliminated through the operation instruction read from the configuration file.

[0023] In some embodiments, performing an interface test on the device to be tested through the difference interface to obtain an interface test result further includes:

[0024] When the execution result indicates that the execution step fails, the display page currently displayed on the device to be debugged is switched to the network page corresponding to the execution step through a multi-window switching mechanism.

[0025] In some embodiments, performing an interface test on the device to be tested through the difference interface to obtain an interface test result further includes:

[0026] When the target test case is an original ecological case, detecting the communication status with the difference interface, and when the communication status indicates connection jitter, restarting the test platform executing the target test case;

[0027] When the target test case is an embedded network page, the window switching state of the browser control corresponding to the target test case is detected, and when the window switching state indicates a switching abnormality, the driver of the browser control is restarted.

[0028] To achieve the above-mentioned purpose, a second aspect of an embodiment of the present application provides an interface automation testing method, which is applied to a server, wherein the server is communicatively connected to at least one execution terminal, and the method includes:

[0029] Determining whether the execution end is in an idle state;

[0030] When the execution end is in an idle state, determining a test case set to be tested from a preset planned case set;

[0031] The test case set is sent to the execution end, so that the execution end executes any one of the methods described in the first aspect.

[0032] In some embodiments, at least one target test case in the planned test case set is obtained by the following steps:

[0033] Obtain a recorded use case, and decompose the recorded use case into steps to obtain a use case step set that corresponds one-to-one to the recorded use case;

[0034] The Json fields corresponding to each use case step in the use case step set are associated and combined to obtain the target test case.

[0035] To achieve the above objectives, a third aspect of an embodiment of the present application provides an interface test management device, the device comprising:

[0036] A receiving module, configured to obtain a test case set sent by a server in communication with the execution terminal; wherein the target test case is sent by the server when the server detects that the execution terminal is in an idle state;

[0037] A determination module, which determines a target test case currently being executed from the test case set according to an execution task corresponding to the test case set;

[0038] A general process acquisition module is used to obtain the operating system type and the general process corresponding to the target test case;

[0039] An execution module, configured to sequentially execute the multiple execution steps included in the target test case according to the execution order set in the general process;

[0040] The differentiation processing module is used to determine the difference interface corresponding to the currently executed execution step according to the operating system type during the execution process of each execution step and perform interface testing on the device to be debugged through the difference interface to obtain the interface test result.

[0041] To achieve the above-mentioned purpose, the fourth aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, the memory stores a computer program, and the processor implements the method described in the first aspect or the method described in the second aspect when executing the computer program.

[0042] To achieve the above-mentioned purpose, the fifth aspect of an embodiment of the present application proposes a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, it implements the method described in the first aspect or the method described in the second aspect.

[0043] The interface automation testing method, device, equipment and storage medium proposed in the present application detect the idle state of the execution end through the server to determine whether to issue the test case set, thereby realizing unified management of all test cases to be tested. At the same time, by setting a general process that is unrelated to the system type of the device to be tested for each target test case and combining it with the differential interface execution steps that are strongly related to the system type of the device to be tested, it is possible to perform interface testing on devices to be tested of different system types through the same target test case on the same execution end. At this point, the test development engineer only needs to maintain a set of test cases and differential interfaces related to the system, which makes management and maintenance more convenient. Therefore, compared with related technologies, the method of the embodiment of the present application can realize unified management of the interface testing process for different operating systems, thereby improving the convenience of management and maintenance of the testing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a flowchart of an automated interface testing method applied to an execution terminal provided in an embodiment of the present application;

[0045] Figure 2 This is a schematic diagram of an application scenario of an interface automation testing method applied to an execution end provided in an embodiment of the present application;

[0046] Figure 3 This is a schematic diagram of the execution process of a target test case in the interface automation testing method applied to the execution end provided by an embodiment of the present application;

[0047] Figure 4 yes Figure 1 Flowchart of step S600 in FIG.

[0048] Figure 5 This is a schematic diagram of a process for processing interference factors in an interface automation testing method applied to an execution end provided by an embodiment of the present application;

[0049] Figure 6 This is a schematic diagram of multiple windows in the interface automation testing method applied to the execution end provided in an embodiment of the present application;

[0050] Figure 7 This is a flow chart of an automated interface testing method for a server provided in an embodiment of the present application;

[0051] Figure 8 This is a schematic diagram of the structure of the interface automation testing device provided in an embodiment of the present application;

[0052] Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0054] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0056] First, let’s analyze some of the terms used in this application:

[0057] React Native (RN) is a cross-platform mobile application development framework open-sourced by Facebook in April 2015. It's a derivative of Facebook's previously open-source UI framework, React, for native mobile platforms. It currently supports both iOS and Android platforms. React Native provides a fully consistent development experience based on JavaScript and React for building native applications. It packages the page layout design and business code for users to download and install. Updates to the page layout or changes to business logic require modifying the front-end content, upgrading the package, and republishing to use the latest version.

[0058] WebView, a WebKit-based engine, parses DOM elements and displays HTML page controls, similar to how a browser displays pages. It displays pages by loading HTML files. To update the page layout or change business logic, you only need to modify the HTML code or JavaScript file (if obtained from the server, as soon as the new file is deployed).

[0059] JSON (JavaScript Object Notation, JS) is a lightweight data exchange format. Based on a subset of ECMAScript (the JS specification developed by the European Computer Society), it uses a text format that is completely independent of the programming language to store and represent data. Its simplicity and clear hierarchical structure make JSON an ideal data exchange language. It is easy for humans to read and write, as well as for machines to parse and generate, and significantly improves network transmission efficiency.

[0060] Appium is an open source test automation framework that can be used for native, hybrid, and mobile web application testing. It uses the WebDriver protocol to drive iOS, Android, and Windows applications.

[0061] As software systems continue to expand in scale, the necessity and difficulty of software system testing to ensure delivery quality are self-evident. The limitations of traditional manual testing are also becoming increasingly apparent. Automated testing technology can overcome many of these issues. Therefore, interface automation testing is often used to automate user interface test cases. This primarily involves two phases: recording test case scripts and executing them. During the execution phase, the test case script data is executed on the execution side, and a report on the test results is output. However, for different operating systems, separate projects are typically built to adapt the execution of user interface test cases for each operating system. Consequently, data recording (such as screenshots, logs, and fault tolerance) throughout the execution process, all requiring separate, independent workflows, from startup to execution, requires inefficient management and maintenance of the user interface testing process.

[0062] Based on this, the embodiments of the present application provide an interface automation testing method, apparatus, device and storage medium, which aim to achieve unified management of interface testing processes for different operating systems and improve the convenience of management and maintenance of the testing process.

[0063] The interface automation testing method provided in the embodiment of the present application relates to the field of testing technology. The interface automation testing method provided in the embodiment of the present application can be applied to a terminal, can be applied to a server side, or can be software running in a terminal or a server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server side can be configured as an independent physical server, or as a server cluster or distributed system composed of multiple physical servers, or as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the interface automation testing method, etc., but is not limited to the above forms.

[0064] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0065] Figure 1 This is an optional flowchart of the interface automation testing method provided in the embodiment of the present application. Figure 1 The method may include but is not limited to steps S100 to S600.

[0066] Reference Figure 1 As shown, according to the first aspect of the embodiment of the present application, an interface automation testing method is proposed, which is applied to the execution end and includes:

[0067] Step S100: Acquire a test case set sent by a server in communication with the execution end; wherein the test case set is sent by the server when it detects that the execution end is in an idle state.

[0068] It's important to note that by detecting whether the execution terminal is idle before issuing a test case set, the execution terminal can be effectively utilized. For example, a high-performance execution terminal can execute more test cases, ensuring that all test cases are covered in the shortest possible time, resulting in higher execution efficiency. Furthermore, test case sets are managed and issued by the server, allowing multiple execution terminals to be managed by a single server, making the testing process more convenient to maintain.

[0069] It should be noted that, since there are multiple execution terminals, and the multiple execution terminals are not related to each other, concurrent execution of multiple execution terminals can be achieved.

[0070] It should be noted that there are two types of idle states: one in which no test cases are currently being executed on the execution end, and the other in which no test cases are currently being executed on at least one device under test connected to the execution end. For example, if the execution end is connected to multiple devices under test, the system first determines whether any test cases are currently being executed on the execution end. If so, it then determines whether each connected device under test is currently being tested, ultimately determining whether the state is idle. This approach maximizes resource utilization, ensuring that all required test cases are tested in the shortest possible time.

[0071] Step S200: Determine a target test case from a test case set according to preset task rules.

[0072] It should be noted that the task rules define the order in which the test case sets are executed, and each test case set contains at least one test case.

[0073] It should be noted that after the current target test case is executed, the next target test case is determined according to the task rules and the following steps are executed.

[0074] Step S300: Obtain the operating system type and the general process corresponding to the target test case.

[0075] It should be noted that the operational procedures for implementing the same functions of the same application on different operating systems are mostly consistent. The general process defines the common operational procedures for the same function on different operating systems, such as the execution order of each type of control, reference relationships, etc.

[0076] Step S400: Execute the multiple execution steps included in the target test case in sequence according to the execution order set in the general process.

[0077] It should be noted that each target test case can be broken down into multiple steps based on the general process. For example, in the case of a target test case for testing a text box, the test process typically involves selecting the text box, inputting, and verifying. In this case, the test case is broken down into corresponding steps based on this general operation.

[0078] Step S500: During the execution of each execution step, the difference interface corresponding to the currently executed execution step is determined according to the operating system type.

[0079] It should be noted that different interfaces are the system interfaces that trigger the same functional steps under different operating systems. For example, for the text box selection step, it is necessary to call an interface that captures the mouse click position on the page to determine whether the text box is selected. Different operating systems have different interfaces, resulting in different interfaces.

[0080] Step S600: Perform an interface test on the device to be tested through a difference interface to obtain an interface test result.

[0081] Therefore, according to the above-mentioned embodiment of the present application, at least the following effects are achieved: the server detects the idle state of the execution end to determine whether to issue the test case set, thereby realizing unified management of all test cases to be tested. At the same time, by setting a general process that is unrelated to the system type of the device to be tested for each target test case and executing the execution steps in combination with the difference interface that is strongly related to the system type of the device to be tested, it is possible to perform interface testing on devices to be tested of different system types through the same target test case at the same execution end. At this point, the test development engineer only needs to maintain a set of test cases and the difference interface related to the system, which makes management and maintenance more convenient. Therefore, compared with the related art, the method of the embodiment of the present application can realize unified management of the interface testing process for different operating systems, thereby improving the convenience of management and maintenance of the testing process.

[0082] It's important to note that because a common process manages the execution order of target test cases across different systems, it can be compatible with multiple models running in parallel. Therefore, a single execution terminal can be connected to multiple models, allowing multiple models to concurrently execute the same target test case, resulting in higher test case coverage. This also reduces the difficulty of test environment deployment. When deploying the test environment, one only needs to consider the efficiency of the execution terminal and the number of devices available for testing.

[0083] It should be noted that, on the execution side, a concurrent mechanism can be used to process multiple devices to be tested concurrently. For example, the same test case set can be used to concurrently test multiple devices to improve the reliability of the test results.

[0084] For example, refer to Figure 2 As shown, the server is connected to multiple execution terminals, and each execution terminal performs use case tests on at least one or more devices to be tested. Specifically, for execution terminal 1, execution terminal 1 is used to perform use case tests on device 1 to be tested and device 2 to be tested. When the server detects that execution terminal 1 has not performed use case tests on device 2 to be tested, it will send the use cases that have not been executed in device 2 to be tested. At this time, execution terminal 1 receives the test case set and executes the test case set. It should be noted that the server sending can be triggered by the user's initiative or by the rules set in the server. If the server detects that execution terminal 1 is in an idle state, it will prompt the tester to send the test case set in the operation interface, and the tester will send the test case set according to the actual business needs. Therefore, in this way, as many test case sets as possible can be executed on the execution terminal with high execution efficiency, thereby making the test case coverage higher.

[0085] For example, refer to Figure 3 As shown, take the execution end 1 as an example to perform the same target test case on the device 1 to be debugged and the device 2 to be debugged. Assume that the target test case includes 3 execution steps, and the execution order is Figure 3 As shown, when executing step 1, for device 1 to be tested, the difference interface 1 matching the device 1 to be tested will be called to execute the test content of step 1. For device 2 to be tested, the difference interface 2 matching the device 2 to be tested will be called to execute the test content of step 1.

[0086] It is understandable that referring to Figure 4 As shown, step S600, performing an interface test on the device to be tested through a difference interface to obtain an interface test result, includes:

[0087] Step S601: Obtain the execution result corresponding to the difference interface.

[0088] Step S602: When the execution result indicates that the execution step fails, a preset positioning element list is obtained.

[0089] Step S603: Select the first locating element from the locating element list as the abnormal locating element.

[0090] Step S604: perform control location processing on the execution result through the exception location element to obtain control location data.

[0091] Step S605: When the control positioning data does not locate the abnormal control, reselect a second positioning element from the positioning element list to update the abnormal positioning element, and re-perform control positioning processing on the execution result using the updated abnormal positioning element.

[0092] When all positioning elements in the positioning element list have been traversed or the control positioning data has been positioned on an abnormal control, the control positioning process is stopped.

[0093] Step S606: Obtain interface test results based on the execution results and control location data.

[0094] It should be noted that for interface testing, each difference interface corresponds to the operation of at least one control, such as a text box or a button. In related technologies, only one control positioning method is usually recorded. When positioning fails based on this positioning method, the analysis will not continue. Therefore, positioning failure is prone to occur. By setting a positioning element list and providing multiple positioning methods, the positioning method can be flexibly switched to improve the positioning success rate. The positioning element list records a variety of positioning elements used to find controls. For each control, its positioning element includes one or more of id, name, class name, Xpath, Accessibility ID, and android uiautomator. At this time, due to the use of multiple positioning factors, the abnormal location can be quickly located. At the same time, in some embodiments, after determining the abnormal location, the cause of the abnormality will be attributed and classified to predict the fault factor, helping test developers to locate and repair the problem faster.

[0095] It is understandable that referring to Figure 5 As shown, when the control location data has located the abnormal control, after the control location processing is performed, the method further includes:

[0096] Step S701: Match the control location data with a preset interference list to determine whether there are interference factors.

[0097] Interference factors refer to pop-ups triggered by non-functional processes during the test process. Specifically, such as a permission confirmation pop-up window, in some embodiments, after executing a certain step, a permission confirmation pop-up window will pop up. Since the click-to-confirm operation is not set in the test case, it will cause it to be unable to jump to the next page, which in turn causes the execution step to fail. In practice, the permission confirmation pop-up window may be generated by the system, and whether it is generated is related to the system configuration of the device to be tested or the permission setting of the application to be verified. It is not triggered by the current functional process. Therefore, the operation of the permission confirmation pop-up window is not included in the execution step of the test case. If the permission confirmation pop-up window is set as an interference factor in the interference list, it can be determined that the execution step is not a real failure. In other embodiments, interference factors also include dynamic pop-ups, such as news pop-ups or link pop-ups, etc.

[0098] It should be noted that the interference list defines a variety of interference factors. Interference factors can be obtained by summarizing the results of historical test case failures, or manually set based on pre-judgment in the system pop-up window. In this regard, the embodiments of this application do not restrict the specific content of the interference factors. Those skilled in the art can generate an interference list based on actual application conditions or historical experience.

[0099] It should be noted that, in some embodiments, the interference list can be configured through a Json file. When applied, the Json file is loaded to realize dynamic configuration of interference factors. In other embodiments, it can also be directly solidified in the program, or dynamically configured through other configuration file formats, and this embodiment of the application does not limit this. For the embodiment of the present application, it is preferred to adopt the Json file configuration method to lower the threshold requirements of testers, achieve more efficient maintenance of test projects and improve the convenience of maintenance.

[0100] It should be noted that after the target test case completes all steps, the execution log and screenshots of each step will be uploaded to the server. The server will send them to the test developers related to the use case in the form of email or other text forms, and the test developers will follow up on the results to form a complete closed loop for problem handling.

[0101] Step S702: When there is an interference factor, re-call the difference interface to perform interface testing on the device to be debugged.

[0102] It should be noted that, in some embodiments, when the display execution fails, you can choose to directly end the execution of the target test case. At this time, after locating the presence of interference factors, the target case is re-called to realize the re-calling of the difference interface to perform interface testing on the device to be tested. In other embodiments, when the display execution fails, when it is determined that there are interference factors, the failed execution steps are directly repeated to re-call the difference interface to test the device to be tested. In this regard, the embodiment of the present application does not limit the method of re-calling the difference interface. Those skilled in the art can selectively set it according to the needs of the project.

[0103] Step S703: In the process of re-calling the difference interface to perform interface testing on the device to be debugged, the dialog box popped up by the interference factor is eliminated through the operation instruction read from the configuration file.

[0104] Therefore, by introducing a fault-tolerant mechanism and removing interference caused by other operations, the reliability of the control positioning results can be greatly improved.

[0105] It is understood that the interface test of the device to be debugged is performed through the difference interface, and the interface test results obtained also include:

[0106] When the execution result indicates that the execution step fails, the display page currently displayed on the device to be debugged is switched to the network page corresponding to the execution step through the multi-window switching mechanism.

[0107] It should be noted that when testing a target test case, each execution step will generate a web page, and at this time, there will be multiple windows displaying the content. Similarly, for each device to be debugged, multiple target test cases will be executed and multiple windows will be generated. The specific target test case or execution step corresponding window that the displayed display page switches to is determined by the current handle. Figure 6 As shown, when the current handle is the handle of tag 1, the displayed page shows the content of tag 1. When the current handle is the handle of tag 2, the displayed page shows the content of tag 2. Therefore, when the current handle does not correspond to the actual failed step, it increases the difficulty of positioning. Through the multi-window switching mechanism, the current handle is switched to the network page corresponding to the failed execution step. At this time, the page content corresponding to the failed execution step can be automatically and quickly intercepted without human intervention, and the positioning efficiency of the use case is higher.

[0108] It should be noted that the multi-window switching mechanism uses the handle of the web page corresponding to the failed step as the current handle, thereby making the web page the display page being displayed. Since the multi-window switching mechanism belongs to the conventional operation of handle operation in this field, the embodiment of this application will not be described in detail.

[0109] It is understood that the interface test of the device to be debugged is performed through the difference interface, and the interface test results obtained also include:

[0110] When the target test case is a native test case, the communication status with the difference interface is detected. If the communication status indicates connection jitter, the test platform executing the target test case is restarted.

[0111] When the target test case is an embedded network page, the window switching state of the browser control corresponding to the target test case is detected, and when the window switching state indicates a switching abnormality, the driver of the browser control is restarted.

[0112] It should be noted that the "native use case" refers to an interface use case for testing functional points in page development using React Native. The "embedded web page" refers to an interface use case for testing functional points in page development using H5. In some embodiments, the "embedded web page" specifically refers to an interface use case for testing functional points in page development using Webview.

[0113] It should be noted that when developing terminal applications, a hybrid development of React Native and H5 is usually adopted. In some embodiments, H5 is displayed using a browser control (such as Webview). In actual applications, in hybrid development applications, there are problems such as H5 page switching being unstable and not stable enough when running on multiple devices in parallel. Specifically, such problems include being unable to switch or not being displayed for a long time after switching. At this time, the target test case cannot continue to execute and the execution is displayed as failed. Therefore, by restarting the browser control when a window switching anomaly is detected, the restarted browser control is reloaded to reduce the probability of failure of the target test case.

[0114] Note that the test platform can be Appium. Communication status is represented by the socket connection state. Socket connection jitter can lead to information loss, increasing the probability of test case failure. Restarting the test platform disconnects the current connection to the device under test and re-establishes the socket, increasing the probability of a stable connection to the device under test.

[0115] Therefore, by providing an error analysis mechanism to detect the execution environment, the probability of use case failure caused by the stability of the execution environment can be reduced.

[0116] To achieve the above purpose, refer to Figure 7 As shown, the second aspect of the embodiment of the present application proposes an interface automation testing method, which is applied to a server, and the server is communicatively connected to at least one execution terminal. The method includes:

[0117] Step S801: Determine whether the execution end is in an idle state.

[0118] Step S802: When the execution end is in an idle state, a test case set to be tested is determined from a preset planned case set.

[0119] It should be noted that the idle state means that there is no test case being executed on the execution end, or there is a device to be debugged on the execution end but no related test case is being executed.

[0120] It should be noted that the planned test case set is the complete set of test cases. The server allocates test case sets based on the idle status of the execution terminals, ensuring that all execution terminals are in an execution state, thereby improving the coverage of the planned test case set and the reliability of the test results.

[0121] Step S803: Send the test case set to the execution end, so that the execution end executes the interface automation test method applied to any one of the execution ends.

[0122] Therefore, the server detects the idle state of the execution end to determine whether to issue the test case set, thereby realizing unified management of all test cases to be tested. At the same time, by setting a general process that is independent of the system type of the device to be tested for each target test case and executing the execution steps in combination with the differential interface that is strongly related to the system type of the device to be tested, it is possible to perform interface testing on devices to be tested of different system types through the same target test case at the same execution end. At this point, the test development engineer only needs to maintain a set of test cases and differential interfaces related to the system, which makes management and maintenance more convenient. Therefore, compared with the related art, the method of the embodiment of the present application can realize unified management of the interface testing process for different operating systems, thereby improving the convenience of management and maintenance of the testing process.

[0123] It can be understood that at least one target test case in the planned use case set is obtained through the following steps: obtaining a recorded use case, and decomposing the recorded use case into steps to obtain a use case step set that corresponds one to one with the recorded use case; associating and combining the Json fields corresponding to each use case step in the use case step set to obtain the target test case.

[0124] It should be noted that the association combination means referencing the Json fields corresponding to each use case step in the target test case. Therefore, when the location information of the Json field corresponding to step 1 in a target test case changes, other target test cases that reference the Json field will change accordingly.

[0125] It should be noted that by recording a use case, breaking it down into steps, and combining the corresponding JSON fields for each step, the target use case can be generated. This approach lowers the barrier to entry for testers. During maintenance, you can quickly locate the case requiring maintenance by querying the steps.

[0126] It should be noted that since each step corresponds to a Json field, and the target use case is combined based on the steps, when modifying or querying, the query can be based on the steps. Similarly, since it is an associated combination, when there are multiple target use cases sharing the same step, the positioning information of the Json field corresponding to the shared step changes, which can cause the corresponding multiple target use cases to change accordingly. For example, taking the Json field corresponding to one of the click controls as an example, the Json field corresponding to the click control is as follows:

[0127]

[0128] When the above-mentioned Json field is used in the steps of multiple target test cases, when the positioning information in the Json field, such as "accessibilityID", changes, the multiple target test cases are also updated accordingly.

[0129] The following describes the method for interface automation testing of the embodiment of the present application with a specific embodiment. Figures 1 to 7 As shown:

[0130] The server periodically performs idle state detection on execution end 1, execution end 2, and execution end 3; when it is detected that no use case is being executed on execution end 2, the test case set is sent to execution end 2 with reference to step S802 and step S803. After execution end 2 receives the test case set with reference to step S100, it determines the target test case with reference to step S200, determines the general process with reference to step S300, and executes each execution step in the target test case in sequence with reference to step S400. For each execution step, when the device to be tested 3 is tested with the target test case, the difference interface will be determined according to the system type of the device to be tested 3 with reference to step S500, so that the execution end 2 can call the corresponding function point in the execution step through the difference interface. During the execution of each execution step, if the socket connection of the device to be tested 3 is unstable or the window switching is unstable, the Appium or Webview driver will be restarted accordingly. During the execution of each execution step, refer to Figure 4 As shown, when the execution step fails, multiple positioning methods are performed through the preset positioning element list. At the same time, refer to Figure 5 As shown, after the abnormal position is determined, the control positioning data and the interference list are matched to determine whether there are interference factors. When there are interference factors, the operation instructions loaded through the Json file are used to eliminate the pop-up dialog box of the interference factor, and the execution step is re-executed. Similarly, for the device to be tested 4, when it needs to execute the same target test case as the device to be tested 3, the device to be tested 3 and the device to be tested 4 can be processed concurrently. It should be noted that when the execution step fails, the network page corresponding to the failed execution step will be switched to the current display page through the multi-window switching mechanism. At this time, the current display page can be quickly screenshoted for positioning confirmation. At the same time, Figure 4 The result of the control location data classification, the screenshot, and the corresponding execution log are sent to the corresponding test developer via email.

[0131] Therefore, refer to Figures 1 to 7This automated UI testing method eliminates the need to maintain separate projects for Android and iOS platforms. Instead, the entire process, from startup to execution and result reporting, can be completed within a unified project, simplifying management and maintenance. It also optimizes the stability of concurrent execution on multiple devices under test. When executing both H5 and Native cases, it addresses stability issues caused by driver switching, effectively reducing the failure rate of cases affected by stability. It also addresses key features such as permission pop-ups and dynamic pop-ups as interference factors, making them configurable in JSON files for easier management and maintenance. When an execution step fails, multiple methods are combined to locate the corresponding abnormal control. When one method fails, another is switched to another, improving the success rate of the target test case. Improvements have also been made to analyze and address exceptions encountered during case execution. By capturing screenshots of each execution step and categorizing the exceptions thrown during execution, test developers can more quickly and accurately locate and fix issues. After all test cases have completed execution, execution logs and screenshots are uploaded to the backend and emailed to the relevant test developers. Through their follow-up processing, a complete closed loop of problem handling is formed.

[0132] See also Figure 8 The present application also provides an interface test management device that can implement the above-mentioned interface automated testing method applied to the execution end. The device includes:

[0133] The receiving module 100 is used to obtain a test case set sent by a server in communication with the execution end; wherein the target test case is sent by the server when it detects that the execution end is in an idle state;

[0134] Determining module 200, determining the target test case currently being executed from the test case set according to the execution task corresponding to the test case set;

[0135] The general process acquisition module 300 is used to obtain the operating system type and the general process corresponding to the target test case;

[0136] An execution module 400 is configured to sequentially execute the multiple execution steps of the target test case according to the execution order set in the general process;

[0137] The differentiation processing module 500 is used to determine the difference interface corresponding to the currently executed execution step according to the operating system type during the execution process of each execution step and perform interface testing on the device to be debugged through the difference interface to obtain the interface test result.

[0138] The specific implementation of the interface test management device is basically the same as the specific embodiment of the interface automatic testing method applied to the execution end mentioned above, and will not be repeated here.

[0139] The present application also provides an electronic device comprising a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned automated interface testing method for an execution terminal or the automated interface testing method for a server. The electronic device can be any intelligent terminal, including a tablet computer and an in-vehicle computer.

[0140] See also Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is shown. The electronic device includes:

[0141] The processor 901 can be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0142] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program codes are stored in the memory 902, and the processor 901 calls and executes the interface automation testing method applied to the execution end or the interface automation testing method applied to the server in the embodiments of this application;

[0143] Input / output interface 903, used to implement information input and output;

[0144] Communication interface 904, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0145] Bus 905 , which transmits information between various components of the device (e.g., processor 901 , memory 902 , input / output interface 903 , and communication interface 904 );

[0146] The processor 901 , the memory 902 , the input / output interface 903 and the communication interface 904 are connected to each other in communication within the device via a bus 905 .

[0147] An embodiment of the present application also provides a storage medium, which is a computer-readable storage medium and stores a computer program. When the computer program is executed by a processor, it implements the above-mentioned interface automation testing method applied to the execution end or the interface automation testing method applied to the server.

[0148] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0149] The interface automation testing method, interface test management device, electronic device and storage medium provided in the embodiment of the present application detect the idle state of the execution end by the server to determine whether to issue the test case set, thereby realizing unified management of all test cases to be tested. At the same time, by setting a general process that is unrelated to the system type of the device to be tested for each target test case and combining it with the differential interface execution steps that are strongly related to the system type of the device to be tested, it is possible to perform interface testing on devices to be tested of different system types through the same target test case on the same execution end. At this time, the test development engineer only needs to maintain a set of test cases and differential interfaces related to the system, which makes management and maintenance more convenient. Therefore, compared with the related art, the method of the embodiment of the present application can realize unified management of the interface testing process for different operating systems, and improve the convenience of management and maintenance of the testing process.

[0150] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0151] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0152] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0153] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

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

[0155] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the above-mentioned units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

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

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

[0160] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. An interface automation testing method, characterized in that: Applied to the execution end, the method includes: Obtaining a test case set sent by a server in communication with the execution end; wherein the test case set is sent by the server when it detects that the execution end is in an idle state; Determine a target test case from the test case set according to a preset task rule; Obtaining an operating system type and a general process corresponding to the target test case; Execute the multiple execution steps of the target test case in sequence according to the execution order set in the general process; During the execution of each of the execution steps, determining the difference interface corresponding to the currently executed execution step according to the operating system type; Performing an interface test on the device to be tested through the difference interface to obtain an interface test result; The step of performing an interface test on the device to be tested through the difference interface to obtain an interface test result includes: Obtaining the execution result corresponding to the difference interface; When the execution result indicates that the execution step fails, obtaining a preset positioning element list; Selecting the first positioning element from the positioning element list as the abnormal positioning element; Performing control location processing on the execution result through the exception location element to obtain control location data; When the control locating data does not locate the abnormal control, reselecting a second locating element from the locating element list to update the abnormal locating element, and re-performing control locating processing on the execution result using the updated abnormal locating element; When all positioning elements in the positioning element list have been traversed or the control positioning data has been positioned at an abnormal control, stopping the control positioning process; An interface test result is obtained according to the execution result and the control positioning data.

2. The method according to claim 1, characterized in that When the control location data has located the abnormal control, after performing control location processing, the method further includes: Matching the control location data with a preset interference list to determine whether there are interference factors; When the interference factor exists, re-calling the difference interface to perform interface testing on the device to be tested; In the process of re-calling the difference interface to perform interface testing on the device to be tested, the dialog box popped up by the interference factor is eliminated through the operation instruction read from the configuration file.

3. The method according to claim 1, characterized in that The performing of an interface test on the device to be tested through the difference interface to obtain an interface test result further includes: When the execution result indicates that the execution step fails, the display page currently displayed on the device to be debugged is switched to the network page corresponding to the execution step through a multi-window switching mechanism.

4. The method according to any one of claims 1 to 3, characterized in that The performing of an interface test on the device to be tested through the difference interface to obtain an interface test result further includes: When the target test case is an original ecological case, detecting the communication status with the difference interface, and when the communication status indicates connection jitter, restarting the test platform executing the target test case; When the target test case is an embedded network page, the window switching state of the browser control corresponding to the target test case is detected, and when the window switching state indicates a switching abnormality, the driver of the browser control is restarted.

5. An interface automation testing method, characterized in that: Applied to a server, the server being communicatively connected to at least one execution terminal, the method comprising: Determining whether the execution end is in an idle state; When the execution end is in an idle state, determining a test case set to be tested from a preset planned case set; The test case set is sent to the execution end, so that the execution end executes the method according to any one of claims 1 to 4.

6. The method according to claim 5, characterized in that At least one target test case in the planned test case set is obtained by the following steps: Obtain a recorded use case, and decompose the recorded use case into steps to obtain a use case step set that corresponds one-to-one to the recorded use case; The Json fields corresponding to each use case step in the use case step set are associated and combined to obtain the target test case.

7. A management device for interface testing, characterized in that: The device comprises: A receiving module, configured to obtain a test case set sent by a server in communication with the execution terminal; wherein the test case set is sent by the server when the server detects that the execution terminal is in an idle state; A determination module, which determines a target test case currently being executed from the test case set according to an execution task corresponding to the test case set; A general process acquisition module is used to obtain the operating system type and the general process corresponding to the target test case; An execution module, configured to sequentially execute the multiple execution steps included in the target test case according to the execution order set in the general process; A differentiation processing module is used to determine, during the execution of each of the execution steps, the difference interface corresponding to the currently executed execution step according to the operating system type and perform an interface test on the device to be debugged through the difference interface to obtain an interface test result; The step of performing an interface test on the device to be tested through the difference interface to obtain an interface test result includes: Obtaining the execution result corresponding to the difference interface; When the execution result indicates that the execution step fails, obtaining a preset positioning element list; Selecting the first positioning element from the positioning element list as the abnormal positioning element; Performing control location processing on the execution result through the exception location element to obtain control location data; When the control locating data does not locate the abnormal control, reselecting a second locating element from the locating element list to update the abnormal locating element, and re-performing control locating processing on the execution result using the updated abnormal locating element; When all positioning elements in the positioning element list have been traversed or the control positioning data has been positioned at an abnormal control, stopping the control positioning process; An interface test result is obtained according to the execution result and the control positioning data.

8. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and when the processor executes the computer program, it implements the interface automation testing method described in any one of claims 1 to 4, or the interface automation testing method described in any one of claims 5 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, it implements the interface automation testing method described in any one of claims 1 to 4, or the interface automation testing method described in any one of claims 5 to 6.

Images