Automatic terminal testing system, equipment and method based on three-axis driving and medium

Abstract

The invention provides an automatic terminal testing system, device and method based on three-axis driving and a medium. The testing system comprises computer equipment, a three-axis driving system and a testing operation terminal. The computer equipment is respectively in communication connection with the three-axis driving system and the test operation terminal; a regional space for accommodating target equipment to be tested is reserved in the three-axis driving system, and the regional space is arranged in a range which can be reached by each axis of the three-axis driving system. And the computer equipment outputs an accurate motion control instruction to the three-axis driving system, and sends an interface operation instruction to the test operation terminal by virtue of Appium service, an ADB command and the like, so that the automatic test of the target equipment is completed. Therefore, the method has the remarkable effects of high test result accuracy, high automation degree, greatly improved reliability and high practicability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automation testing, in particular to an automatic terminal testing system based on three-axis driving, equipment, method and medium. BACKGROUND

[0002] In the production testing or daily operation process of terminal equipment, the traditional testing method still highly depends on manual operation to complete the whole process execution. The tester needs to manually turn on the target device first, record the exclusive number of each device one by one, and then click all the working modes of the terminal in turn according to the preset process to complete the calibration operation. Although this kind of operation has a fixed process, it is highly repetitive, consumes a lot of manpower and time cost throughout the process, and is difficult to meet the efficiency requirements of large-scale terminal testing.

[0003] The inherent limitations of manual operation can easily lead to a decline in testing accuracy. During the process of repeatedly clicking on various modes of the terminal, the tester is prone to fatigue due to long-term repetitive mechanical movements, which may cause omissions or errors in operation. Such errors not only lead to a single test failure, but also may leave potential problems due to incorrect operation, affecting the judgment of the actual performance of the terminal equipment and causing additional pressure on subsequent quality control.

[0004] The collection and processing of error logs also have obvious shortcomings. In the traditional mode, error logs need to be actively reported and sorted by manual operation, which not only further increases the labor input, but also has the risk of log loss. Incomplete or delayed submission of logs will directly prolong the problem troubleshooting cycle, making it difficult for technicians to locate the root cause of terminal failure, affecting the efficiency of problem solving, and indirectly increasing the operation and maintenance cost of terminal equipment and the risk of market deployment. SUMMARY

[0005] In view of the above-mentioned shortcomings of the prior art, the purpose of the present application is to provide an automatic terminal testing system based on three-axis driving, equipment, method and medium, which solves the technical problems of high labor cost, low accuracy and long problem troubleshooting cycle caused by manual clicking in existing terminal testing.

[0006] To achieve the above-mentioned purposes and other related purposes, the first aspect of the present application provides an automatic terminal testing system based on three-axis driving, comprising: a computer device, a three-axis driving system, and a test operation terminal; the computer device is communicatively connected with the three-axis driving system and the test operation terminal; the three-axis driving system reserves a region space for accommodating a target device to be tested, and the region space is within the reach of each axis of the three-axis driving system;

[0007] The computer device controls each axis of the three-axis driving system to move to a target device to be tested according to specified motion parameters by a pre-written programming language instruction script, so as to obtain target device information; the computer device controls an interface operation of a test operation terminal based on the target device information, so that the test operation terminal establishes a communication connection with the target device; the computer device controls the interface operation of the test operation terminal, so that the test operation terminal sequentially executes test steps on the target device; and the computer device generates a corresponding test report according to test results uploaded by the test operation terminal, and controls the three-axis driving system to switch to an initial state.

[0008] In some embodiments of the first aspect of the application, after each test operation is performed, the three-axis driving system automatically returns to a preset mechanical origin in response to a zeroing instruction sent by the computer device.

[0009] In some embodiments of the first aspect of the application, after receiving the zeroing instruction, a drive motor of each axis of the three-axis driving system moves at a low speed in a direction close to a limit switch; when a preset origin mark is detected by an origin sensor on each axis, a signal is fed back to the computer device, the drive motor of the axis stops rotating, and the current position is defined as zero coordinates.

[0010] In some embodiments of the first aspect of the application, the computer device controls the interface operation of the test operation terminal based on the target device information, which includes: the computer device drives the test operation terminal to open a test APP according to the target device information through an automatic instruction, marks a current interface to confirm an operation reference, then switches to a device setting interface, completes connection configuration with the target device to be tested, and finally outputs a state feedback of successful connection.

[0011] In some embodiments of the first aspect of the application, the computer device controls the interface operation of the test operation terminal, so that the test operation terminal sequentially executes test steps on the target device, which includes: the test operation terminal is switched back from the setting interface to the test APP interface, and before formal test operation, a preset logic needs to be completed for basic function configuration; the basic function configuration includes version parameter setting and test mode initialization; the interface of the test operation terminal is switched to a terminal test interface, a type list is traversed and all modes capable of automatic test are extracted, and terminal tests are performed on all modes one by one.

[0012] In some embodiments of the first aspect of the application, after the automatic test operation is completed, the computer device summarizes execution results of all test modes, including test states, time consumption data, key parameter configurations and log association information corresponding to failure modes of each mode, and generates a structured test report through a preset report template.

[0013] In some embodiments of the first aspect of this application, the computer device establishes a communication connection with the three-axis drive system through a preset signal interface; the preset signal interface is an interface based on pulse signals and direction signals; the computer device establishes a communication connection with the test operation terminal through automated instructions; the automated instructions include Appium services and / or ADB commands.

[0014] To achieve the above and other related objectives, a second aspect of this application provides an automated terminal testing method based on a three-axis drive, applied to a computer device in the automated terminal testing system provided in the first aspect of this application; the computer device establishes communication connections with both the three-axis drive system and the test operation terminal; the testing method includes: controlling each axis of the three-axis drive system to move to the target device under test according to specified motion parameters using a pre-written programming language instruction script to obtain target device information; controlling the test operation terminal to perform interface operations based on the target device information to establish a communication connection between the test operation terminal and the target device; controlling the test operation terminal to perform interface operations to sequentially execute test steps on the target device; generating a corresponding test report based on the test results uploaded by the test operation terminal, and controlling the three-axis drive system to switch to an initial state.

[0015] To achieve the above and other related objectives, a third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the automated terminal testing method based on three-axis drive.

[0016] To achieve the above and other related objectives, a fourth aspect of this application provides a computer program product comprising computer program code, which, when executed on a computer, enables the computer to implement the automated terminal testing method based on three-axis drive.

[0017] To achieve the above and other related objectives, a fifth aspect of this application provides a computer device, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the automated terminal testing method based on three-axis drive.

[0018] As described above, the automated terminal testing system, equipment, method, and medium based on three-axis drive of this application have the following beneficial effects:

[0019] 1. High test accuracy: All test modes can achieve full-process loop coverage, with no missed test nodes and no error judgments. The accuracy of test results is close to 100%, which can provide accurate data support for subsequent problem localization and optimization.

[0020] 2. High degree of automation: Significantly reduces the cost of manual intervention, decreasing repetitive operations by more than 90% compared to traditional manual testing. Operators only need to trigger code execution commands, and the system can automatically complete the entire testing process, including terminal connection, test case execution, and result verification, saving manpower and time efficiently.

[0021] 3. Significantly Improved Reliability: Logs are uploaded in real time during testing, with a near 100% success rate, ensuring complete retention of key test data and operation records. There is no risk of log loss or corruption, providing a stable and reliable basis for test traceability and issue review.

[0022] 4. High practicality: Its application scenarios are not limited to terminal testing scenarios, and it has extremely strong versatility. It can be flexibly adapted to various click operation scenarios that require repetitive execution and have cumbersome processes (such as software functional regression testing, multi-scenario repeated verification, etc.), effectively improving cross-scenario work efficiency. Attached Figure Description

[0023] Figure 1 The diagram shown is a structural schematic of an automated terminal testing system based on a three-axis drive, according to one embodiment of this application.

[0024] Figure 2 The diagram shown is a flowchart of an automated terminal testing method based on three-axis drive in one embodiment of this application.

[0025] Figure 3 The diagram shown is a flowchart of an automated terminal testing method based on three-axis drive in one embodiment of this application.

[0026] Figure 4 The diagram shown is a structural schematic of a computer device according to an embodiment of this application. Detailed Implementation

[0027] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0028] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:

[0029] <1> Appium is an open-source mobile application automation testing framework that supports automated testing of native applications, hybrid applications, and mobile web pages on platforms such as iOS and Android. It achieves cross-platform compatibility based on the WebDriver protocol, allowing developers to write test scripts in multiple programming languages ​​to manipulate and verify the behavior of mobile application interface elements.

[0030] <2> ADB (Android Debug Bridge) is a set of command-line tools provided by the Android system for debugging and managing Android devices (such as mobile phones and tablets). It establishes communication between a computer and an Android device via a USB data cable or wireless connection, enabling remote control of the device.

[0031] <3> GPIO (General Purpose Input / Output) ports are general-purpose interfaces on a chip. They can be configured by software to operate in input or output mode, enabling digital signal interaction with external devices (such as sensors, LEDs, etc.), and are widely used in embedded systems and microcontroller development.

[0032] <4> A dedicated motion control card is a hardware device used for precise control of mechanical motion, typically plugged into a computer motherboard or embedded system. It receives control commands and outputs pulse, analog, and other signals to drive motors (such as stepper motors and servo motors) to achieve precise control of parameters such as speed, position, and acceleration. It is commonly found in CNC machine tools, robots, and other equipment.

[0033] <5> Python scripting is a collection of executable instructions written in the Python programming language, with the .py file extension. It achieves specific functions through concise syntax, can be run directly without compilation, and is commonly used in scenarios such as automated testing, data processing, and system maintenance. It can quickly call various libraries and modules to complete tasks.

[0034] <6> The `random` module is a utility module in the Python standard library used to generate random numbers. It provides various functions for generating random integers, floating-point numbers, and random sequences, such as `random.randint()` which generates integers within a specified range, and `random.choice()` which randomly selects elements from a sequence. These functions are widely used in scenarios such as simulation testing and data sampling.

[0035] <7> An SDK (Software Development Kit) is a collection of development tools provided for a specific software framework, hardware platform, or operating system. It typically includes API interfaces, library files, development documentation, sample code, etc., helping developers quickly integrate functionality and simplify the development process. For example, an SDK for mobile app development can enable the integration of functions such as payment and maps.

[0036] <8> pyserial (serial communication library) is a third-party library in Python used to implement serial communication. It provides a concise interface that supports data transmission and reception between a computer's serial port (such as RS232, RS485) and external devices (such as sensors, microcontrollers, and industrial controllers). It is commonly used in embedded system debugging, hardware device control, and other scenarios.

[0037] <9> A stepper motor is an electromechanical actuator that converts electrical pulse signals into angular or linear displacement. Each time it receives a pulse signal, it rotates a certain distance at a fixed angle (step angle), providing precise and controllable motion. Positioning can be achieved without feedback, making it suitable for equipment requiring precise motion control.

[0038] To facilitate understanding of the embodiments of this application, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1 A schematic diagram of an automated terminal testing system based on three-axis drive is shown in an embodiment of the present invention.

[0039] The automated terminal testing system based on three-axis drive includes: a computer device 11, a three-axis drive system 12, and a test operation terminal 13. The three-axis drive system 12 has a reserved area to accommodate the target device to be tested, and this area is within the reach of each axis of the three-axis drive system 12. The computer device 11 establishes a communication connection with the three-axis drive system 12 through a preset signal interface, and establishes a communication connection with the test operation terminal 13 through automated commands.

[0040] Computer device 11 is the core control unit of the entire automated testing process, undertaking core functions such as instruction generation, process scheduling, and data processing. Through pre-set programming language scripts such as Python, it outputs precise motion control commands (such as speed, distance, and zeroing signals for each axis) to the three-axis drive system 12. Simultaneously, it sends interface operation commands (such as launching the app, switching interfaces, and setting parameters) to the test operation terminal 13 via automated commands (such as ADB commands or Appium services). At the same time, computer device 11 receives real-time operational status feedback from the three-axis drive system 12 (such as whether it has reached its position or whether it has triggered limit switches) and test result data from the test operation terminal 13, completing log recording, anomaly detection, and test report generation. It is the central core component coordinating the efficient collaborative work of all components.

[0041] The three-axis drive system 12 is the execution unit for realizing automated mechanical operation. It consists of three independent motion axes (X, Y, and Z, corresponding to a Cartesian coordinate system), stepper motors, motor drivers, and mechanical transmission structures (such as lead screws and guide rails). Each motion axis is driven by a dedicated stepper motor, which precisely controls the linear motion of each axis by receiving pulse signals (the number of pulses corresponds to the movement distance, and the pulse frequency corresponds to the movement speed) and direction signals sent by the computer device 11. Its core function is to replace manual physical operations, such as precisely pressing the power button of the target device or triggering specific physical buttons. Through the standardized execution of mechanical actions, it ensures the consistency of operation and positional accuracy, providing physical motion support for automated testing. It is worth noting that the stepper motor is only an example motor type used in this test scenario. In actual applications, it can be flexibly replaced with other motors, such as servo motors, brushless DC motors, and brushed DC motors, depending on the requirements of accuracy, load, and speed. This application does not limit this.

[0042] The test operation terminal 13 is the target object of automated testing, typically referring to an electronic device with an interactive interface, such as mobile phones, tablets, smartwatches, and industrial handheld terminals. As the test carrier, it needs to have the application to be tested (APP) installed and respond to remote operation commands sent by the computer device through the Appium service to complete a series of preset test procedures (such as launching the APP, switching settings interfaces, and performing functional tests). Simultaneously, the test operation terminal will feed back the status information during the test process (such as whether the application started normally and whether the operation was executed successfully) and test results to the computer device for subsequent result analysis and log recording. It is the core carrier for verifying the effectiveness of the application's functions.

[0043] The signal interface between the computer device 11 and the three-axis drive system 12 is a hardware connection channel for command transmission and status feedback between the two. Its core function is to convert the control signals (such as motion commands) output by the computer device 11 into electrical signals that the three-axis drive system 12 can recognize, while simultaneously feeding back the operating status of the three-axis device (such as position, fault information, etc.) to the computer device. For example, the signal interface between the computer device 11 and the three-axis drive system 12 can be an interface based on pulse signals and direction signals. For instance, the computer device 11 sends pulse signals to the stepper motor drivers of each axis through GPIO (General Purpose Input / Output) ports or a dedicated motion control card. The number of pulses corresponds to the movement distance, the pulse frequency corresponds to the movement speed, and the direction signal distinguishes between forward and reverse rotation through high and low levels, thereby achieving independent control of the X, Y, and Z axes. This method has clear timing and is suitable for simple point-to-point control.

[0044] In the embodiments of this application, the testing process of the automated terminal testing system based on three-axis drive is as follows:

[0045] Step 1. The computer device 11 controls each axis of the three-axis drive system 12 to move to the target device to be tested according to the specified motion parameters through a pre-written programming language instruction script, so as to obtain the target device information.

[0046] The programming language instruction script is the core carrier for the computer device 11 to execute control logic. It is typically written in a specific programming language and contains code files with explicit instructions. Its core function is to convert requirements such as movement distance and speed into control signals that the three-axis drive system 12 can recognize. For example, the programming language instruction scripts that can be used in this embodiment include, but are not limited to, Python scripts, C / C++ scripts, and Java scripts. Python scripts have concise syntax and a rich library of third-party libraries, making them well-suited for automation scenarios; C / C++ scripts have strong real-time performance, suitable for scenarios with extremely high requirements for control precision and response speed; Java scripts have excellent cross-platform compatibility, suitable for integration with large-scale automated testing frameworks. Taking Python scripts as an example: by calling pyserial (serial communication library) or the SDK (software development kit) corresponding to the motion control card, code containing specific parameters such as X-axis movement of 50mm and speed of 200mm / s, and Y-axis movement of 30mm and speed of 15mm / s can be written to define the motion trajectory of the three axes.

[0047] Computer device 11 acts as the instruction sender. After running the pre-written programming language script, it converts the motion parameters (motion distance, speed, etc.) in the script into pulse signals and direction signals. The number of pulses directly corresponds to the motion distance (e.g., 1000 pulses correspond to 10mm of movement distance; the specific ratio is determined by the mechanical parameters of the three-axis drive system), the pulse frequency corresponds to the motion speed (the higher the pulse transmission frequency, the faster the axis moves), and the direction signal controls the direction of axis movement (e.g., forward or reverse movement). These signals are transmitted to the three-axis drive system 12 through preset signal interfaces (e.g., GPIO ports, dedicated motion control cards, etc.).

[0048] The three-axis drive system 12, acting as the actuator, consists of three independent motion axes (X, Y, and Z) and corresponding stepper motors and drivers. Upon receiving a signal from the computer device 11, the stepper motors on each axis rotate precisely according to instructions. Through mechanical structures such as lead screws and guide rails, the rotation is converted into linear motion, driving the end effector (such as a pressing head for triggering the device, or a barcode scanning module for reading device information) to move to the target device under test. For example, it can precisely move to the QR code area of ​​the target device and read basic information such as the device number and model through the onboard barcode scanning module; or it can move to a specific physical button position on the target device and trigger it, causing the device to output its own information. Ultimately, this achieves automated acquisition of the target device information, realizing standardized and accurate information collection without manual intervention.

[0049] In some preferred embodiments, each axis of the three-axis drive system 12 undergoes a zeroing calibration after completing the current operation for future use. Specifically, after completing a test operation, such as precisely pressing the device or reading device information, the X, Y, and Z axes of the three-axis drive system 12 automatically return to a preset mechanical origin. Calibration ensures that the position reference of each axis is consistent, providing a precise starting position for the next operation.

[0050] For example, the zeroing calibration process is as follows: After the computer device 11 sends a zeroing command, the stepper motors of each axis of the three-axis drive system 12 move at low speed in the direction closest to the limit switch. Simultaneously, the system monitors the signals from the origin sensors (such as photoelectric switches or mechanical limit switches) on the axes in real time. When a sensor on a certain axis detects a preset origin marker (such as a mechanical stop or optical positioning point), it immediately sends a signal back to the computer device 11, and the motor on that axis stops rotating. At this time, the system defines the current position as the zero coordinate and updates the reference value of the internal position counter. If there are minor positional deviations in the axes during previous operations, such as displacement errors caused by mechanical transmission backlash or pulse signal loss, the zeroing process corrects these deviations through precise positioning by the origin sensors, ensuring that the actual physical position of each axis is completely consistent with the coordinates recorded internally by the computer. In this way, by eliminating accumulated errors through a unified origin reference, problems such as inaccurate pressing or information reading failures due to positional offsets are avoided during subsequent operations, ensuring consistent positional accuracy for each operation.

[0051] In some preferred embodiments, this application also considers the following specific problems that may exist in actual automated testing scenarios: First, when manually placing the test terminal, millimeter-level offsets are prone to occur, and the three-axis drive system is prone to issues such as missed presses and incorrect presses when moving along the preset trajectory, requiring repeated adjustments and affecting efficiency. Second, mechanical transmission gaps, temperature changes, and other factors can lead to error accumulation, which can reduce positioning accuracy or even interrupt testing over long-term use. Finally, different terminal models have significant differences in appearance and button layout, and traditional fixed trajectories require separate scripting, resulting in high adaptation costs and difficulty in meeting batch testing needs. To address these issues, a visual recognition and reinforcement learning dynamic adjustment module is introduced. By sensing the environment in real time and autonomously correcting parameters, the above problems are solved, improving the system's anti-interference capability and versatility.

[0052] Specifically, a machine vision camera is deployed on the end effector or test fixture of the three-axis drive system. After the computer equipment starts the test process, it first controls the camera to acquire real-time images of the placed target device, capturing feature information such as the physical contour and edge baseline of the target device. The computer equipment compares the real-time acquired images with a preset standard model of the target device (including ideal key coordinates, edge positions, etc.), and calculates the offset between the actual position and the ideal position of the target device (e.g., X-axis offset 2.3mm, Y-axis offset 1.5mm, rotation angle 3°, etc.) using feature point matching algorithms (such as SIFT algorithm, ORB algorithm, etc.), while simultaneously identifying the real-time coordinates of the keys. A reinforcement learning model is pre-deployed in the computer equipment. The reinforcement learning model receives the position deviation data and the target key coordinates, and combines them with the mechanical performance parameters of the three-axis drive system (such as maximum acceleration, motion speed limit, etc.) to quickly iteratively calculate the optimal motion path from the current origin to the target key, including the motion sequence of the X, Y, and Z axes, the motion distance correction value of each axis, and acceleration / deceleration nodes, ensuring that the path is both efficient and complies with the mechanical motion limits.

[0053] Next, the computer equipment converts the optimal path parameters output by the AI ​​model into pulse and direction signals, which are then sent to the drivers of each axis of the three-axis drive system via a signal interface. This drives the stepper motors to move according to the corrected parameters (e.g., adjusting the number of X-axis pulses to compensate for horizontal offset, and adjusting the Z-axis pulse frequency to control the descent speed), ultimately enabling the end effector to precisely reach the target button position. After each operation, the system records the actual motion parameters (e.g., commanded distance, actual distance reached), environmental data (e.g., temperature, humidity), and deviation values ​​(e.g., a 0.2mm error caused by mechanical transmission backlash), storing them in a historical database. The reinforcement learning model is periodically trained on the data to summarize error patterns (e.g., for every 5°C increase in temperature, the X-axis error increases by 0.05mm), and actively generates compensation parameters during the zeroing calibration process: for example, adding an extra 0.2mm of pulses to the zeroing command to offset the problem of incomplete zeroing caused by lead screw backlash, ensuring the long-term stability of the origin position. When the target device model is changed, the camera automatically collects the feature information of the new terminal. The system does not need to rewrite the fixed trajectory script. It only needs to obtain the new button coordinates through visual recognition. The AI ​​model can directly generate a motion path adapted to the new terminal based on the mechanical characteristics learned in the past, realizing the function of one deployment and multiple terminals.

[0054] Understandably, the SIFT (Scale-Invariant Feature Transform) algorithm is an image feature extraction algorithm that can stably identify unique local feature points from images of different scales, rotations, and lighting conditions, making it suitable for target matching and location localization. The ORB (Oriented FAST and Rotated BRIEF) algorithm is a high-efficiency feature detection and matching algorithm that combines FAST corner detection and BRIEF descriptors. It boasts fast computation speed and is suitable for scenarios with high real-time requirements (such as rapid terminal location identification). Reinforcement learning models are AI models that learn through trial and error by interacting with the environment. They can optimize decisions based on historical operational data (such as correcting three-axis motion parameters) and gradually improve task completion accuracy.

[0055] Step 2. Based on the target device information, the computer device 11 controls the test operation terminal 13 to perform interface operations so that the test operation terminal 13 establishes a communication connection with the target device.

[0056] Based on the target device information obtained in step 1 above, the test operation terminal 13 is driven to open the test APP through automated instructions (such as ADB commands, Appium scripts, etc.), and the current interface is marked to confirm the operation benchmark; then the device settings interface is switched to complete the connection configuration with the target device to be tested, and finally the connection success status feedback is output to ensure that the test object is in a communicable state.

[0057] Step 3. The computer device 11 controls the test operation terminal 13 to perform interface operations, so that the test operation terminal 13 sequentially executes the test steps for the target device.

[0058] Based on step 2 above, the computer device 11 switches the test operation terminal 13 from the settings interface back to the test APP interface. Before the formal test operation, it is necessary to complete the basic function configuration according to the preset logic, such as version parameter settings, test mode initialization, etc., and adjust the application to the initial state that meets the test requirements, so as to prepare for the subsequent core test steps.

[0059] To make this process easier to understand, this application uses a real-world testing scenario as an example: Assume the test terminal 13 is an Android phone, and the device to be tested is a functional verification app for a certain terminal device. The computer device 11 will use a combination of Appium scripts and ADB commands to complete interface switching and basic configuration. First, the computer device 11 uses the Appium call to switch_to.window() method or the ADB command "adb shell am start -n package_name / test_app_main_Activity_name" to quickly switch the phone from the settings interface (previously accessed to complete device connection) back to the test app interface, ensuring that the focus of operation returns to the test device. Then, the basic configuration is executed according to the preset logic: For example, for version parameter settings, the script will locate the "Version Selection" dropdown box in the app, automatically click and select the preset target test version (such as V2.3.1), which must be compatible with the hardware of the terminal to be tested; for test mode initialization, the script will find the "Test Type" option, check "Fully Automatic Mode", and at the same time disable the redundant log output function (to avoid irrelevant logs occupying storage and affecting test efficiency). These automated configurations allow the test app to break free from its initial default state and accurately match the requirements of this test, laying a stable foundation for subsequent entry into the terminal test interface and traversal of test modes.

[0060] Furthermore, after completing the basic function configuration, the computer device 11 switches the interface of the test operation terminal 13 to the terminal test interface, traverses the type list and extracts all modes that can be automated, and performs terminal tests on each mode one by one.

[0061] Specifically, automated scripts are used to perform batch traversal and full-process verification of test modes, replacing manual completion of repetitive and standardized testing operations. Computer device 11 first locates the terminal test interface of the test app through the Appium service, identifies and traverses the type list in the interface (such as network testing, performance testing, functional verification, etc.), and extracts all test modes that can be automatically executed through preset filtering rules (such as marking with an "automation support" label or conforming to specific naming conventions), excluding modes requiring manual intervention to ensure process continuity. For each filtered test mode, the script automatically executes the test according to preset logic: for parameter items requiring numerical input in the mode (such as bandwidth threshold, test duration, etc.), random numbers within the parameter range are generated using a random number generation function in a programming language (such as Python's random module) and automatically filled in, avoiding the monotony of test scenarios caused by fixed input; for mode input items such as dropdown selections and checkboxes, element positioning technology (such as XPath, ID positioning, etc.) is used to automatically match preset options and complete the filling. During test execution, the system monitors the status of the results displayed on the interface in real time (such as whether a "test successful" message is displayed, whether the return code is 0, etc.). If the current test mode is successful, it will automatically switch to the next testable mode to continue execution. If a failure occurs (such as functional abnormality, no response, etc.), the log upload mechanism will be triggered immediately. The log content will include key information such as the current test mode type, the timestamp of the failure, the test operation terminal model, and relevant parameter configurations to ensure that the problem is traceable, while not interrupting the test process of other modes, thus achieving efficient and comprehensive batch test verification.

[0062] Step 4. The computer device 11 generates a corresponding test report based on the test results uploaded by the test operation terminal 13, and controls the three-axis drive system 12 to switch to the initial state.

[0063] After completing the automated testing operation, computer device 11 summarizes the execution results of all test modes, including the test status (success / failure) of each mode, time consumption data, key parameter configuration, and log association information corresponding to the failure mode. It generates a structured test report through a preset report template (such as HTML or PDF format). The report clearly presents core indicators such as test coverage, pass rate, and failure point distribution, providing testers with an intuitive overview of the results.

[0064] Furthermore, the computer device 11 drives the test operation terminal (such as a mobile phone or smart device) to switch back to its initial state before testing via automated commands: for example, closing the test APP and clearing the temporary cache via ADB commands, disconnecting from peripherals, and restoring the device settings to default parameters (such as network mode, brightness settings, etc.); simultaneously, it controls the three-axis drive system to complete the final zeroing calibration, ensuring that the mechanical structure returns to its origin and avoiding positional deviations that could affect subsequent use. At the same time, the computer device 11 also sends a zeroing command to the three-axis drive system 12, driving the stepper motors of the X, Y, and Z axes to move in tandem, returning to the system's preset mechanical origin position, completing position calibration and state reset, providing a unified and accurate starting reference for the next test, and ensuring the consistency and reliability of subsequent operations.

[0065] This series of operations automates the entire testing process, creating a complete closed loop that includes device wake-up, test execution, result recording, report generation, and state restoration. This ensures the traceability of test results and provides a standardized initial environment for the next test, enabling process reuse and efficient connection without manual intervention.

[0066] To facilitate a better understanding of the technical solutions provided in this application by those skilled in the art, the technical solutions of this invention are applied to a smartphone terminal calibration test scenario below, as an example to aid understanding. The test process is as follows:

[0067] Step 1: First, connect the computer device to the signal interface of the three-axis drive system to ensure a stable communication link. Then, run the preset Python script, which accurately sends the WiFi enable command to the controller of the three-axis drive system. After receiving the WiFi enable command, the controller drives the three-axis mechanical structure to move according to the preset trajectory, accurately triggering the WiFi hardware switch of the target device, completing the initialization of the target device's WiFi function, and preparing for subsequent wireless communication.

[0068] Step 2: Start the Appium service and complete the parameter configuration to ensure the service is in a normal listening state. The previously run Python script establishes a stable wireless connection with the target phone through the communication interface provided by the Appium service, automatically completing the device's WiFi pairing and connection verification. After a successful connection, the script will automatically locate and open the terminal APP to be tested, and complete a series of basic operations such as APP launch, permission granting, and skipping the welcome page according to the preset test process, finally accurately navigating to the mode selection interface, waiting for subsequent test instructions.

[0069] Step 3: The script enters the core testing phase, executing sequentially according to two preset test modes: "Simplified Mode" and "Fully Mechanized." In each mode, the script automatically loops through all function buttons corresponding to all calibration types, triggering the calibration process by simulating manual clicks. For different types of calibration requirements, the script automatically fills in appropriate parameter values ​​(such as standard values, limit values, boundary values, etc.) in the corresponding input boxes based on a preset test case library, and monitors system feedback information in real time during the calibration process. By comparing preset thresholds with actual results, it intelligently determines whether the current calibration operation is successful.

[0070] Step 4: Establish a robust exception handling mechanism during the testing process: If the calibration result meets the preset success criteria (e.g., the system prompts "calibration complete" or the feedback value is within the acceptable range), the script will automatically skip the current calibration item and continue to execute the next type of calibration operation; if calibration failure is detected (e.g., the system prompts "calibration error", the feedback value is abnormal, or there is no response after timeout), the script will immediately capture the exception information, automatically record the failure time, calibration type, current parameters, and other key data, and report them to the log system. At the same time, the fault tolerance mechanism will be triggered to ensure that the overall testing process is not interrupted and to continue executing subsequent calibration tasks, ensuring that the test coverage is not affected.

[0071] Step 5: After all calibration tests in both "Simplified Mode" and "Fully Mechanized" modes have been completed, the script will automatically start the log generation program. The log content will comprehensively cover all key information throughout the test, including test start and end times, device model, WiFi connection status, execution results of each calibration item, parameter configuration, and anomaly details. The generated test logs will be saved to a designated folder on the computer according to a unified naming convention (e.g., "Test Date - Device Model - Test Mode - Log Version"). The log format supports direct reading by subsequent data analysis tools, facilitating testers' subsequent error tracing, problem localization, and test result review.

[0072] Figure 2 A flowchart illustrating an automated terminal testing method based on a three-axis drive, as described in an embodiment of this application, is presented. It should be understood that the automated terminal testing method of this application is applied to the computer device in the above system embodiment; the computer device establishes a communication connection with both the three-axis drive system and the test operation terminal. The specific testing method is as follows:

[0073] Step S21: Using a pre-written programming language instruction script, control each axis of the three-axis drive system to move to the target device under test according to the specified motion parameters in order to obtain information about the target device.

[0074] Step S22: Based on the target device information, control the test operation terminal to perform interface operations so that the test operation terminal establishes a communication connection with the target device.

[0075] Step S23: Control the test operation terminal to perform interface operations, so that the test operation terminal executes the test steps of the target device in sequence.

[0076] Step S24: Generate a corresponding test report based on the test results uploaded by the test operation terminal, and control the three-axis drive system to switch to the initial state.

[0077] It should be understood that the specific process of each module performing the above-mentioned steps has been described in detail in the above method embodiments, and will not be repeated here for the sake of brevity.

[0078] Figure 3 A flowchart illustrating an automated terminal testing method based on three-axis drive is shown in another embodiment of this application. In this embodiment, the method execution process is as follows:

[0079] 01. Begin.

[0080] The testing process officially started, and the system automatically initialized the test environment, including checking the connection status between the computing device and the three-axis drive system, the configuration of the Python runtime environment, and the readiness of the Appium service, to ensure that the communication links between the components are unobstructed and to lay the foundation for subsequent operations.

[0081] 02. Start the three-axis device. The Python code sends commands to the three axes. X and Y control the position, and Z controls the distance the button is pressed.

[0082] The three-axis drive system is started and a self-test is completed to confirm that the motion accuracy and limit functions of the X, Y, and Z axes are normal. Then, the preset Python control code is run, which sends precise motion commands to the three-axis controller: through the coordinated movement of the X and Y axes, the robotic arm is positioned directly above the physical control button of the target device; then, the linear motion of the Z axis controls the distance the button is pressed (such as simulating different pressing pressures), thereby triggering the hardware switch of the device.

[0083] 03. Should the target device be started and the device number obtained?

[0084] After the system triggers the button, it monitors in real time whether the target device has started successfully (e.g., by checking the device indicator light status, connection signal feedback, etc.) and attempts to automatically obtain the device's unique identifier (device number). This step requires verifying the legality and validity of the device number's format to ensure the accuracy of subsequent communication and control.

[0085] 04. No, error handling, press the button again.

[0086] If the target device fails to start or the device number cannot be obtained, error handling is immediately triggered. The computer outputs specific error information (such as device not responding, incorrect device number format, etc.) and automatically records the failure time and trigger parameters. Subsequently, the Python code resends instructions to the three-axis drive system to control the three axes to execute the button press operation again, retrying up to N times (N is configurable). If it still fails, the process is paused and manual intervention is prompted.

[0087] 05. Yes, use Python + Appium to automate the operation of the mobile phone and open the app on the terminal to be tested.

[0088] Once the device successfully boots up and the device ID is valid, the computer uses a Python script to call the Appium service to establish a stable, automated communication connection with the mobile phone (supporting USB or WiFi connection modes). After a successful connection, the script automatically unlocks the phone screen, handles pop-up permission requests, accurately locates and opens the target device's app, and completes the app launch initialization.

[0089] 06. Control the phone to connect to the device by obtaining the device number.

[0090] The script uses the previously obtained target device ID as a key parameter and automatically fills it into the device connection module of the mobile app, triggering a connection request. The computer device monitors the connection status in real time. If a connection timeout or failure occurs, it will automatically retry the connection process (such as resending the connection command or refreshing the device list) until the mobile phone and the target device establish stable communication.

[0091] 07. Perform basic terminal testing settings, such as device number input and version update.

[0092] After a successful connection, the script enters the basic setup phase of terminal testing, automatically enters the device number in the specified location of the APP to complete the binding, checks and triggers the APP version update (if a new version is available, it automatically confirms the update and waits for the installation to complete), and configures the basic parameters required for testing (such as default test mode values, log storage path, etc.) to ensure that the test environment meets the preset standards.

[0093] 08. Determine if the terminal test interface has been reached?

[0094] After completing the basic settings, the system uses image recognition or element localization technology to determine whether the current APP interface has jumped to the main interface of the terminal test (such as recognizing characteristic elements such as the interface title and core test buttons). If the target interface characteristics are not recognized, it is determined that the test interface has not been reached.

[0095] 09. No, reset the basic settings.

[0096] If the terminal test interface is not reached, the computer device will automatically revert to the basic setup steps and re-execute operations such as device number input and version check. At the same time, it will record abnormal interface jump information (such as the name of the currently displayed interface and the feature elements that were not found) for subsequent troubleshooting.

[0097] 10. Yes, identify all terminal test types to prevent omissions.

[0098] After successfully entering the terminal test interface, the script automatically identifies all test types (such as calibration tests, functional tests, performance tests, etc.) contained in the current interface by traversing the interface element tree, and generates a list of test types. At the same time, it checks for any missing test items by comparing them with the preset test type library to ensure that all required test categories are covered.

[0099] 11. Determine the type of input field.

[0100] For each test type involving interactive controls, the script focuses on identifying the attribute characteristics of the input box (such as element labels, input restriction rules, etc.) to accurately determine whether it is a numeric input box or a text input box, providing a basis for subsequent automatic input operations.

[0101] 12. If it is a number input box, fill in a number randomly.

[0102] If the input box is identified as a number, the script will randomly generate a test value within the preset legal value range (such as 0-100, -50 to 50, etc.) according to the test case rules, and automatically fill it into the input box. At the same time, it will check whether the input value meets the format requirements (such as decimal places, integer range) to ensure the validity of the input.

[0103] 13. If it is a text input box, automatically fill in the text.

[0104] If the text input box is recognized, the script retrieves suitable content (such as strings with fixed formats, randomly generated letter combinations, etc.) from the preset text library, automatically fills it into the input box, and supports the input of special characters (such as punctuation marks, spaces, etc.) to simulate real-world usage scenarios.

[0105] 14. Perform tests according to the identified terminal test type, input box, and switch type.

[0106] Based on the identified list of test types, input box attributes, and on / off controls (such as checkboxes and toggle switches) in the interface, the script executes tests sequentially according to a preset test order: it simulates click operations to switch the state of the on / off controls, and triggers the execution logic of the corresponding test type by combining the auto-fill content of the input boxes, and records the operation trajectory and system feedback in real time.

[0107] 15. Was the test successful?

[0108] After each test is completed, the system automatically determines whether the test was successful by monitoring feedback information from the app (such as a "test successful" pop-up, result status code, progress bar completion indicator, etc.). The determination logic supports custom rule configuration (such as multi-condition combination judgment) to ensure the accuracy of the results.

[0109] 16. If it fails, report the error log and store it in the folder.

[0110] If the test fails, the script immediately captures the failure details (including test type, operation steps, input parameters, system error messages, failure time, etc.), generates a structured error log, and automatically stores it in the specified folder according to the naming rule of "test date - device number - test type". The log also includes screenshots or screen recordings (optional configuration) to facilitate problem tracing.

[0111] 17. Success! Proceed to the next step.

[0112] If the test result is determined to be successful, the system records the success identifier and key parameters (such as execution time, output result value, etc.), and proceeds to the execution flow of the next test item in sequence to ensure test continuity.

[0113] 18. Have all categories been completed?

[0114] Upon completion of each test, the system updates the test progress list and verifies in real time whether all identified test types have been covered. The verification logic includes checking for unexecuted items and marking the status (success / failure) of executed items to ensure that no test categories are missed.

[0115] 19. Yes, generate a summary log and save it in the folder.

[0116] Once all test types have been executed (regardless of success or failure), the script automatically summarizes the entire process data, generating a summary log that includes total test duration, number of successful tests, number of failed tests, key parameter statistics, and anomaly analysis. The summary log, along with the previous error log, is archived in a designated folder and can be exported to Excel or PDF format for easy review and analysis by testers.

[0117] 20. No, continue testing to avoid vulnerabilities (go back to 14).

[0118] If any test types are not completed, the computer device will trigger a continuation test process, automatically returning to the test execution step (step 14) and continuing to execute according to the remaining test type list until all categories are completed, thus avoiding test vulnerabilities caused by process interruption.

[0119] 21. Did the tester click "Stop"?

[0120] Throughout the testing process, the computer equipment monitors in real time whether the tester clicks the "Stop" button via the control interface. This monitoring mechanism uses a polling method to ensure timely response to manual intervention commands.

[0121] 22. No, continue testing (back to 10).

[0122] If no "stop" command is detected, the computer device determines that a repeat test is required to verify the stability of the results, and automatically returns to the test type identification step (step 10) to re-execute the full process test (the number of retests can be configured or an infinite loop can be performed until a stop command is received).

[0123] 23. Yes, the end.

[0124] When the tester clicks the "Stop" button, the computer immediately terminates the current test operation, saves all generated log files, releases the Appium connection and triaxial device resources, and finally outputs the message "Test terminated" to the console, officially ending the process.

[0125] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" mean examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner. In the embodiments of this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships, for example, A and / or B, which can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can be represented as: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single or multiple.

[0126] Figure 4 This is a schematic block diagram of a computer device provided in an embodiment of this application. Figure 4As shown, the computer device includes at least one processor 401, a memory 402, at least one network interface 403, and a user interface 405. The various components in the device are coupled together via a bus system 404. It is understood that the bus system 404 is used to implement communication between these components. In addition to a data bus, the bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 4 The general will label all buses as bus systems.

[0127] The user interface 405 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0128] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0129] In this embodiment of the invention, the memory 402 is used to store various types of data to support the operation of the electronic terminal 400. Examples of this data include: any executable program for operation on the electronic terminal 400, such as the operating system 4021 and application programs 4022; the operating system 4021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 4022 may contain various applications, such as a media player, browser, etc., for implementing various application services. The automatic testing method provided in this embodiment of the invention can be included in the application program 4022.

[0130] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0131] In an exemplary embodiment, the electronic terminal 400 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0132] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the above-described automatic testing method.

[0133] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to perform the above-described method.

[0134] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0135] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0136] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0137] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0138] The units described as separate components may or may not be physically separate. 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0139] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0140] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs, etc.).

[0141] If a function is implemented as 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 this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0143] In summary, this application provides an automated terminal testing system, equipment, method, and medium based on three-axis drive, which has significant advantages such as high accuracy of test results, high degree of automation, greatly improved reliability, and strong practicality. Therefore, this application effectively overcomes the various shortcomings of the prior art and has high industrial application value.

[0144] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. An automated terminal testing system based on three-axis drive, characterized in that, The application relates to a three-axis driving-based automatic terminal test system. The computer device is communicatively connected with the three-axis driving system and the test operation terminal; the three-axis driving system reserves a region space for accommodating a target device to be tested, and the region space is located within the reach of each axis of the three-axis driving system; The computer device controls each axis of the three-axis driving system to move to the target device to be tested according to specified motion parameters through a pre-written programming language instruction script, so as to obtain target device information; The computer device controls the test operation terminal to perform interface operation based on the target device information, so that the test operation terminal is communicatively connected with the target device; The computer device controls the test operation terminal to perform interface operation, so that the test operation terminal sequentially executes test steps on the target device; The computer device generates a corresponding test report according to test results uploaded by the test operation terminal, and controls the three-axis driving system to switch to an initial state. After each test operation is performed, the three-axis driving system automatically returns to a preset mechanical origin in response to a zero reset instruction sent by the computer device.

2. The automated terminal testing system based on three-axis drive according to claim 1, characterized in that, After receiving the zero reset instruction, the driving motor of each axis of the three-axis driving system moves at a low speed in the direction close to the limit switch; when the origin sensor on each axis detects a preset origin mark, the driving motor of the axis stops rotating, and the current position is defined as zero coordinates.

3. The automated terminal testing system based on three-axis drive according to claim 2, characterized in that, The computer device controls the test operation terminal to perform interface operation based on the target device information, which includes:

4. The automated terminal testing system based on three-axis drive according to claim 1, characterized in that, The computer device drives the test operation terminal to open a test APP and mark the current interface to confirm the operation reference through an automatic instruction according to the target device information; subsequently, the test operation terminal is switched to a device setting interface to complete connection configuration with the target device to be tested, and finally outputs a state feedback of successful connection. The computer device controls the test operation terminal to perform interface operation, so that the test operation terminal sequentially executes test steps on the target device, which includes:

5. The automated terminal testing system based on three-axis drive according to claim 1, wherein, The test operation terminal is switched back from the setting interface to the test APP interface, and before formal test operation, preset logic needs to be completed for basic function configuration; the basic function configuration includes version parameter setting and test mode initialization; The interface of the test operation terminal is switched to a terminal test interface, type list is traversed, all modes capable of automatic test are extracted, and terminal test is performed on all modes one by one. After the automatic test operation is completed, the computer device summarizes the execution results of all test modes, including test states, time consumption data, key parameter configurations and log association information corresponding to failure modes, and generates a structured test report through a preset report template.

6. The automated terminal testing system based on three-axis drive according to claim 1, wherein, The computer device and the three-axis driving system are communicatively connected through a preset signal interface; the preset signal interface is an interface based on pulse signals and direction signals. ​ ​ The computer device establishes a communication connection with the test operation terminal through an automatic instruction; the automatic instruction includes an Appium service and / or an ADB command.

8. A method for automated terminal testing based on three-axis drive, characterized in that, The computer device is applied to the automatic terminal test system in claim 1; the computer device establishes a communication connection with a three-axis driving system and a test operation terminal; and the test method includes: Through a pre-written programming language instruction script, each axis of the three-axis driving system is controlled to move to a target device to be tested according to specified motion parameters, so as to obtain target device information; Based on the target device information, the test operation terminal is controlled to perform interface operation, so that the test operation terminal establishes a communication connection with the target device; The test operation terminal is controlled to perform interface operation, so that the test operation terminal sequentially executes test steps on the target device; According to test results uploaded by the test operation terminal, a corresponding test report is generated, and the three-axis driving system is controlled to switch to an initial state.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a processor to implement the automatic terminal test method based on three-axis driving in claim 8.

10. A computer device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program comprises instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1-9. The processor executes the computer program to implement the automatic terminal test method based on three-axis driving in claim 8.

Images