UI testing method, electronic device and storage medium
By detecting and reconnecting the connection status of the UI test tool in the client of the UI automation test tool, the repeated testing problem when UI element test fails is solved, improving the efficiency and accuracy of UI tests and reducing manual intervention.
Patent Information
- Application Number
- CN202110485718.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-04-30
- Publication Date
- 2024-12-24
- Estimated Expiration
- 2041-04-30
AI Technical Summary
In the existing UI testing methods, manual repeated tests are required when UI element testing fails, resulting in large workload and inefficient, and the connection problem cannot be quickly detected.
In the client of the UI automation testing tool, by detecting the connection status of the process and the instruction server, if the connection is abnormal, reconnect and retest the UI elements to reduce manual intervention and automatically troubleshoot connection problems.
It reduces the workload of UI testing, improves UI testing efficiency, saves computing resources and testing time, and avoids the necessity of manual repeated testing.
Smart Images

Figure CN113326183B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the field of testing, and in particular to a UI testing method, an electronic device and a storage medium. Background Art
[0002] User Interface (UI) is the medium for interaction and information exchange between the system and the user. It realizes the conversion between the internal form of information and the form acceptable to humans. User Interface Testing, or UI Testing, is used to test whether the layout of the functional modules of the user interface is reasonable, whether the overall style is consistent, and whether the placement of each control conforms to the customer's usage habits. More importantly, it should be easy to operate, easy to understand navigation, correct text in the interface, unified naming, beautiful page, perfect combination of text and pictures, etc.
[0003] In the relevant UI test, an automated testing tool is used to implement UI automated testing. The automated testing tool is provided with a command server and a client. By connecting the client and the command server, the test script imported by the client is transmitted to the command server through the connection interface. The command server locates and tests each UI element, and returns the location and test result message to the client.
[0004] However, the related UI testing methods have the following problems: in order to explore the reasons for the failure of UI element testing, testers can only manually repeat UI testing to find the reasons for the test failure, resulting in a large workload and low efficiency for UI testing. Summary of the invention
[0005] The purpose of the embodiments of the present invention is to provide a UI testing method, an electronic device and a storage medium to reduce the UI testing workload and improve the UI testing efficiency.
[0006] To solve the above technical problems, an embodiment of the present invention provides a UI testing method, which is applied to a client of a UI automated testing tool. The automated testing tool is provided with an instruction server and a client. The instruction server is connected to the client through a first port, and the instruction server is connected to a mobile UI testing tool through a second port. The client sends a test request to the instruction server. The instruction server sends a test instruction to the mobile UI testing tool according to the test request. The mobile UI testing tool receives the test instruction, performs a UI test according to the test instruction, and returns the UI test result to the server. The instruction server returns the received UI test result to the client. The method comprises: sending a test request for a UI element to the connected instruction server according to a test script, receiving a test result message indicating the UI test result returned by the instruction server, the test result message including any one of a test success message and a test failure message; after receiving the test failure message, checking whether the connection with the instruction server is normal; if the connection is normal, determining that the UI element test fails, and testing the next UI element; if the connection is abnormal, reconnecting with the instruction server and retesting the UI element.
[0007] An embodiment of the present invention also provides an electronic device, comprising: at least one processor; a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned UI testing method.
[0008] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, and the computer program implements the above-mentioned UI testing method when executed by a processor.
[0009] Compared with the prior art, in the implementation manner of the present invention, the client sends a test command of the UI element to the instruction server according to the test script, receives the test result message returned by the instruction server, and after receiving the test failure message returned by the instruction server, checks whether the connection with the instruction server is normal. If the connection is normal, it is determined that the UI element test has failed, and the next UI element is tested. If the connection is abnormal, reconnect to the instruction server and retest the UI element. Since the test code writing errors of the UI elements in the test script and the abnormality of the connection between the client of the automated testing tool and the instruction server may cause the UI element test to fail, therefore, when the test fails, the client reconnects and tests with the instruction server, which can automatically check whether the test failure is caused by the connection problem between the client and the instruction server. There is no need for testers to manually repeat the test and find the cause of the test failure, thereby reducing the workload of UI testing and improving the efficiency of UI testing.
[0010] In addition, checking whether the connection with the command server is normal includes: connecting with the pre-created detection process through a socket, and instructing the detection process to return the command server connection information; obtaining the connection information; judging whether the connection is normal according to the connection information; wherein the detection process is pre-established, used to start the command server, obtain the connection information, and send it to the client. The client connects with the pre-created detection process socket, and the detection process obtains the connection information and sends it to the client. When the connection between the client and the command server is abnormal, the client can be informed of the abnormal connection. The socket is a network-oriented inter-process communication method. As long as there is a network, it can cross any restrictions and realize inter-process communication in various situations. Using sockets for communication can ensure the reliability of the connection.
[0011] In addition, the connection information includes: whether the first port is in a listening state; judging whether the connection is normal according to the connection information, including: if the first port is in a listening state, judging that the connection is normal; if the first port is in an idle state, judging that the connection is abnormal; before reconnecting with the command server, it also includes: instructing the detection process to send a restart command server. By instructing the detection process to restart the command server when the connection port is in a connection abnormality, reconnecting with the command server and retesting the UI elements, the possibility of the client connecting to the command server normally after reconnection can be increased, the number of retests can be reduced, the workload of UI testing can be reduced, and the efficiency of UI testing can be improved.
[0012] In addition, after receiving the test result message returned by the command server, it also includes: recording the number of test failure messages received; before checking whether the connection with the server is normal, it also includes: confirming that the UI element has failed in the first test. The client only checks whether the connection with the command server is normal when the UI element fails in the first test. Since the probability that the client fails to connect to the command server twice in a row is low, therefore, when the UI element fails in the first test, checking whether the connection with the command server is normal can save computing resources and testing time, and improve UI testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.
[0014] Figure 1 is a flow chart of a UI testing method provided according to an embodiment of the present invention;
[0015] Figure 2is a flowchart of using a UI testing method to locate UI elements according to an embodiment of the present invention;
[0016] Figure 3 It is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present invention. DETAILED DESCRIPTION
[0017] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.
[0018] The embodiment of the present invention relates to a UI testing method, which is applied to a client. The specific process is as follows: Figure 1 As shown:
[0019] Step 101, sending a test request for a UI element to a connected instruction server according to a test script, and receiving a test result message indicating a UI test result returned by the instruction server, wherein the test result message includes any one of a test success message and a test failure message;
[0020] Step 102, after receiving the test failure message returned by the instruction server, check whether the connection with the instruction server is normal;
[0021] Step 103: if the connection is normal, determine that the UI element test fails and test the next UI element; if the connection is abnormal, reconnect to the instruction server and retest the UI element.
[0022] The UI testing method of this embodiment is applied to the client of UI automated testing software. The automated testing tool is provided with an instruction server and a client, the instruction server is connected to the client through a first port, the instruction server is connected to the mobile UI testing tool through a second port, the client sends a test request to the instruction server, the instruction server sends a test instruction to the mobile UI testing tool according to the test request, the mobile UI testing tool receives the test instruction, performs a UI test according to the test instruction, and returns the UI test result to the server, the instruction server returns the received UI test result to the client, and tests each UI element in turn. This embodiment takes the use of Appium, an automated testing software that supports multiple languages, as an example. Appium is an automated testing tool that supports native applications, web applications, and hybrid applications on iOS and Android platforms. Appium uses an instruction server-client (Client / Server, referred to as "C / S") structure, including an instruction server Server and a client Client. According to the different writing languages of the test script, the Appium client can be installed in different integrated development environments, such as IntelliJ IDEA, eclipse, etc., according to the different programming languages used. If the Python language is used to write the test script, i.e., the test code, the client can be installed in the Python language development environment PyCharm. The command server Appium-server is connected to Python-Appium-client, i.e. the client, through port 4723. The tester imports the test script into the client. The client sends the test command of the UI element to the command server according to the test script, receives the test result message returned by the command server, and tests each UI element in turn.
[0023] In the UI testing method of this embodiment, the client sends a test command of the UI element to the instruction server according to the test script, receives the test result message returned by the instruction server, and after receiving the test failure message returned by the instruction server, checks whether the connection with the instruction server is normal. If the connection is normal, it is determined that the UI element test has failed, and the next UI element is tested. If the connection is abnormal, reconnect to the instruction server and retest the UI element. Errors in the test code of the UI element in the test script and abnormalities in the connection between the client and the instruction server of the automated testing tool (for example, an error in the operation of the instruction server makes it impossible to fully obtain the request sent by the client) will cause the UI element test to fail. Therefore, when the test fails, the client reconnects and tests with the instruction server, which can automatically check whether the test failure is caused by the connection problem between the client and the instruction server. There is no need for testers to manually repeat the test and find the cause of the test failure, thereby reducing the workload of UI testing and improving the efficiency of UI testing.
[0024] The implementation details of the UI testing method of this embodiment are specifically described below. The following content is only provided for the convenience of understanding the implementation details and is not necessary for implementing this solution.
[0025] In step 101, the client needs to establish a connection with the command server in advance and log in to the command server. Taking Appium as an example, the Appium command server is an HTTP command server implemented based on Node.js, which is connected to the Appium client through a Web interface. During UI testing, the Appium client initiates a connection and the Appium command server accepts the connection. Specifically, the Appium client requests the Appium command server to create a session. After the session is created, the Appium client sends a request to the Appium command server via HTTP in this session. The Appium command server parses the request and returns a test result message to the Appium client through this session. Among them, after establishing a connection with the Appium client, the Appium command server listens to the UI element test request sent from the Appium client, and sends the UI element test request to a receiving program bootstrap.jar or bootstrap.js on the mobile phone. The receiving program converts this request into a command that the mobile UI test tool can execute the UI element test, and sends it to the mobile UI test tool for execution. Among them, bootstrap.jar is an application running on an Android phone, and bootstrap.js is an application running on an IOS phone. It plays the role of a TCP command server on the phone. This embodiment is explained by taking an Android phone as an example. When the Appium command server needs to run a command, the Appium command server will establish TCP communication with bootstrap.jar through port 4724, and send the command to bootstrap.jar. Bootstrap.jar listens to port 4724 to obtain the command sent by the Appium command server, and converts the command into a command that can be recognized by the mobile UI test tool UiAutomator and sends it to UiAutomator for execution. UiAutomator is the UI test tool for Android phones. Then, bootstrap.jar returns the execution result to the Appium command server, and then the Appium command server feeds back the execution result of the command, that is, the test result message of the test request sent by the Appium client, to the Appium client through an HTTP response, so that the Appium client can receive the test result message returned by the Appium command server. Among them, the test result message can be a test success or a test failure. Among them, the mobile UI test tool can be installed in a mobile device such as a mobile phone, or a virtual mobile device such as an Android virtual machine on a PC.
[0026] In step 102, after the Appium client receives the test failure message returned by the Appium command server, it immediately checks whether the connection with the command server is normal. For example, the communication between the Appium client and the Appium command server can be performed through shared memory or named pipes.
[0027] In one example, after receiving the test failure message returned by the command server, the Appium client also records the number of test failure messages of the UI element. The Appium client can use a test variable to record the number of test failure messages of the UI element. When the Appium client receives a test failure message of the current UI element, the value of the test variable increases by 1. When the tested UI element changes, the value of the test variable is also changed to 0, and the number of test failure messages is calculated for the new UI element. Before checking whether the connection with the command server is normal, the Appium client also confirms that this UI element has failed the test for the first time, that is, the value of the test variable is 1. If this UI element is not the first test failure, then the test of this UI element is determined to have failed.
[0028] In this embodiment, the Appium client only checks whether the connection with the Appium command server is normal when the UI element test fails for the first time. Since the probability that the Appium client fails to connect to the Appium command server for two consecutive times is low, checking whether the connection with the Appium command server is normal when the UI element test fails for the first time can save computing resources and testing time and improve UI testing efficiency.
[0029] In one example, the Appium client can also send a command to the Appium command server, instructing the Appium command server to check whether the connection is normal in a response manner. If the Appium command server responds within a preset time, it is determined that the connection between the Appium client and the Appium command server is normal; if the Appium command server does not respond within the preset time, it is determined that the connection between the Appium client and the Appium command server is abnormal.
[0030] In one example, the Appium client also connects to the pre-created detection process through a socket, and instructs the detection process to return the command server connection information; obtains the connection information; and determines whether the connection is normal based on the connection information; wherein the detection process is pre-established, used to start the command server, obtain the connection information, and send it to the client. For example, a User Datagram Protocol (UDP) connection can be established between the client and the detection process, and the client's socket sends a UDP datagram to the socket on the detection process side, indicating that the detection process returns the command server connection information. After the detection process receives the instruction from the client socket, it obtains the command server connection information and returns it to the client socket in the form of a UDP datagram. The connection information received by the Appium client determines whether the connection is normal based on the connection information, wherein the client's socket is pre-established, and its life cycle can be the same as that of the Appium client process, and the detection process side socket is pre-established, and its life cycle can be the same as that of the detection process, used to obtain the connection information and send it to the client's socket, and the detection process is still created and starts the command server.
[0031] Specifically, the command server connection information may be whether the connection port (default is port 4723) between the command server and the client is in a listening state. If the connection port is in a listening state, the Appium client determines that the connection between the command server and the client is normal; if the connection port is in an idle state, the Appium client determines that the connection between the command server and the client is abnormal.
[0032] In one example, when the Appium client is connected to a pre-created detection process through a socket, it creates a client socket connection with the server socket pre-created in the detection process; after determining that the UI element test has failed, or after reconnecting to the instruction server and retesting the UI element, the Appium client disconnects the client socket from the server socket and closes the client socket.
[0033] In this embodiment, the Appium client creates a client socket immediately, and closes the client socket after determining that the UI element test fails or reconnecting to the command server and retesting the UI element. That is, the client socket is created to connect to the server socket only when the Appium client and the Appium command server need to communicate, which can save communication resources.
[0034] In one example, the connection established between the client socket and the server socket is a Transmission Control Protocol (TCP) connection. The TCP connection uses a three-way handshake protocol to establish a connection, which can prevent incorrect connections. It is a connection-oriented, reliable connection method that can ensure the correctness of transmission.
[0035] In step 103, if the connection between the Appium client and the Appium command server is normal, the Appium client determines that the test of this UI element has failed and tests the next UI element. If the connection between the Appium client and the Appium command server is abnormal, the Appium client reconnects to the Appium command server and retests this UI element.
[0036] Specifically, the Appium client can close the created session, send a session creation request to the Appium command server again, create a new session, send a test request through the new session, and retest the UI element with the Appium command server. If the Appium client determines that the test of this UI element fails, the test code of this UI element can be marked in the Appium test script display interface so that the tester can quickly locate the error code.
[0037] In one example, the Appium client is connected to a pre-created detection process via a socket. The detection process is pre-established to start the Appium command server, obtain connection information, and send it to the Appium client. After the Appium client determines that the connection with the Appium command server is abnormal, it instructs the detection process to send a restart of the Appium command server.
[0038] In this embodiment, when the connection port is not in a connected state, the client socket is called to send a restart message to the server socket, instructing the server socket to notify the command server to restart, reconnect with the command server and retest the UI elements, that is, before reconnecting, the command server is also restarted, which can increase the possibility of normal connection between the client and the command server after reconnection, reduce the number of retests, reduce the workload of UI testing, and improve the efficiency of UI testing.
[0039] In one example, the test failure message may be an element positioning failure message, and determining that the UI element test fails specifically means determining that the positioning expression of this UI element is set incorrectly, and marking the positioning expression in the display interface of the test script, so that the tester can quickly locate the incorrect positioning expression, thereby improving the UI test efficiency.
[0040] An embodiment of the present invention uses the above UI testing method to locate UI elements, such as Figure 2 As shown, including:
[0041] Step 201, the client connects to the command server and logs in to the command server;
[0042] Step 202: The client sends a location request (i.e., a test request) of the UI element to be tested to the connected command server according to the test script, and receives a location result message (i.e., a test result message) returned by the command server;
[0043] Step 203-1, the client determines whether the positioning is successful according to the positioning result message, if the positioning is successful, execute step 203-1, if the positioning fails, execute step 204;
[0044] Step 203-2, after obtaining the next UI element to be tested, execute step 202 again;
[0045] Step 204, the client determines whether the positioning of this UI element fails for the first time. If it does not fail for the first time, step 207 is executed to locate the next UI element; if it fails for the first time, step 205 is executed;
[0046] Step 205-1, the client establishes a TCP client (ie, a client socket) and connects to a TCP server (ie, a server socket) created in a pre-created detection process;
[0047] Step 205-2, the detection process detects the status of port 4723 and sends it to the TCP client through the TCP server. If it is in the listening state, the connection between the client and the instruction server is normal, otherwise the connection is abnormal;
[0048] Step 205-3, the client obtains the message sent by the TCP server to the TCP client, disconnects the TCP client from the TCP server, and closes the TCP client.
[0049] Step 206, the client determines whether the connection between the instruction server and the client is normal. If the connection between the instruction server and the client is normal, the client executes step 207. If the connection between the instruction server and the client is abnormal, the client re-executes step 201.
[0050] Step 207: The client determines that the UI element positioning fails.
[0051] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.
[0052] The embodiment of the present invention also relates to an electronic device, such as Figure 3 As shown, it includes: at least one processor 301; a memory 302 that is communicatively connected to the at least one processor; wherein the memory 302 stores instructions that can be executed by the at least one processor 301, and the instructions are executed by the at least one processor 301 to execute the above-mentioned UI testing method.
[0053] The memory 302 and the processor 301 are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors 301 and the memory 302 together. The bus can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The information processed by the processor 301 is transmitted on a wireless medium via an antenna, and further, the antenna also receives information and transmits the information to the processor 301.
[0054] The processor 301 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management and other control functions. The memory 302 can be used to store information used by the processor when performing operations.
[0055] The embodiment of the present invention further relates to a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the above method embodiment is implemented.
[0056] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.
[0057] Those skilled in the art will appreciate that the above-mentioned embodiments are specific examples for implementing the present invention, and in actual applications, various changes may be made thereto in form and detail without departing from the spirit and scope of the present invention.
Claims
1. A UI testing method, characterized in that: A client of a UI automated testing tool is applied, the automated testing tool is provided with an instruction server and the client, the instruction server is connected to the client through a first port, the instruction server is connected to a mobile UI testing tool through a second port, the client sends a test request to the instruction server, the instruction server sends a test instruction to the mobile UI testing tool according to the test request, the mobile UI testing tool receives the test instruction, performs a UI test according to the test instruction, and returns a UI test result to the instruction server, the instruction server returns the received UI test result to the client, and the method includes: Send a test request for the UI element to a connected instruction server according to the test script, and receive a test result message indicating the UI test result returned by the instruction server, wherein the test result message includes any one of a test success message and a test failure message; After receiving the test failure message, checking whether the connection with the instruction server is normal; After receiving the test result message returned by the instruction server, the method further includes: recording the number of test failure messages received; Before checking whether the connection with the instruction server is normal, the method further includes: confirming that the UI element has failed the first test; If the connection is normal, determine that the UI element test fails, and test the next UI element; If the connection is abnormal, reconnect to the instruction server and retest the UI element; The step of checking whether the connection with the command server is normal includes: Connecting to a pre-created detection process via a socket, and instructing the detection process to return command server connection information; Acquire the connection information; According to the connection information, determining whether the connection is normal; The detection process is pre-established and used to start the instruction server, obtain the connection information, and send it to the client.
2. The UI testing method according to claim 1, characterized in that: The connection information includes: whether the first port is in a listening state; The determining whether the connection is normal according to the connection information includes: if the first port is in a listening state, determining that the connection is normal; if the first port is in an idle state, determining that the connection is abnormal; Before reconnecting with the instruction server, the method further includes: Instruct the detection process to send a restart instruction to the server.
3. The UI testing method according to claim 1, characterized in that: The detection process created in advance is connected via a socket, including: Creating a connection between the client socket and the server socket pre-created in the detection process; After determining that the UI element test fails, or after reconnecting with the instruction server and retesting the UI element, the method further includes: The client socket is disconnected from the server socket and the client socket is closed.
4. The UI testing method according to any one of claims 1 to 3, characterized in that: The test failure message includes: an element positioning failure message; The determining that the UI element test fails includes: It is determined that the positioning expression of the UI element is set incorrectly, and the positioning expression is marked in the display interface of the test script.
5. The UI testing method according to claim 1, characterized in that: Check whether the connection with the command server is normal, including: Sending a connection test message to the instruction server, wherein the connection test message instructs the instruction server to reply; If a reply message from the command server is received within a preset time, it is determined that the connection is normal; If no reply message from the instruction server is received within a preset time, it is determined that the connection is abnormal.
6. An electronic device, characterized in that: include: at least one processor; a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the UI testing method according to any one of claims 1 to 5.
7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the UI testing method according to any one of claims 1 to 5 is implemented.
Citation Information
Patent Citations
User interface automated testing method and related equipment
CN111538650A
