Multi-device collaborative automated testing method and apparatus

Abstract

The application provides a kind of multi-device cooperative automation test method and device, it is related to data processing technical field, comprising: display visual test sequence configuration interface;Response to the first selection operation for device configuration information, obtain target device type, and based on the first mapping relationship of preset, dynamically update the available action list of action configuration information corresponding to target device type;Response to the second selection operation for action configuration information, obtain target action type, and based on the second mapping relationship of preset, dynamically update the parameter prompt information of parameter configuration information corresponding to target action type;Response to test execution instruction, parse each test step in test sequence, by the unified calling interface of pre-construction, each test step is converted into the bottom control instruction of corresponding physical test equipment;Send bottom control instruction to corresponding physical test equipment, to control corresponding physical test equipment to execute test operation.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a multi-device collaborative automated testing method and apparatus. Background Technology

[0002] As automotive electronic products and systems become increasingly complex, automated testing has become a crucial means of ensuring product quality and improving testing efficiency. In complex real-world automated testing scenarios, it is often necessary to coordinate and control multiple different types of heterogeneous testing equipment simultaneously, such as vehicle infotainment systems, power supply systems, audio analysis equipment, and communication equipment.

[0003] Most existing automated testing solutions are based on scripting or specific testing frameworks, requiring testers to have certain programming skills and master complex programming syntax. More seriously, test equipment from different manufacturers often uses completely different low-level control interfaces and communication protocols. This fragmented device control leads to a separation between device actions and parameter configuration. When configuring test sequences, testers not only cannot intuitively see the execution logic of the test steps, but also need to tediously look up and memorize the parameter formats of various devices, making configuration errors highly likely.

[0004] Therefore, how to reduce the configuration threshold and integration difficulty of multi-device collaborative testing is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] This invention provides a multi-device collaborative automated testing method and apparatus to address the problem of reducing the configuration threshold and integration difficulty of multi-device collaborative testing in the prior art.

[0006] This invention provides a multi-device collaborative automated testing method, comprising: Display a visual test sequence configuration interface; wherein, the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information and parameter configuration information; In response to a first selection operation on the device configuration information, the target device type is obtained, and the list of available actions corresponding to the action configuration information of the target device type is dynamically updated based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; In response to a second selection operation on the action configuration information, the target action type is obtained, and the parameter prompt information of the parameter configuration information corresponding to the target action type is dynamically updated based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; In response to the test execution command, the test steps in the test sequence are parsed, and each test step is converted into the underlying control command of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format and returns a unified format execution result; The underlying control command is sent to the corresponding physical test device to control the corresponding physical test device to perform test operations.

[0007] According to a multi-device collaborative automated testing method provided by the present invention, before converting each test step into the underlying control instructions of the corresponding physical test device through a pre-built unified calling interface, the method further includes: Obtain the original control protocols of various heterogeneous test devices; Each of the original control protocols is encapsulated into a corresponding unified controller object; wherein the unified controller object shields the differences between the original control protocols and provides the unified calling interface to the outside world; Establish a third mapping relationship between the device type identifier and the unified controller object; wherein, the third mapping relationship is the correspondence between the device type identifier and the unified controller object instance; The process of converting each test step into the underlying control instructions of the corresponding physical test equipment through a pre-built unified calling interface includes: Based on the target device type and the third mapping relationship in each of the test steps, obtain the corresponding unified controller object; The execution method corresponding to the target action type in the unified controller object is invoked, and the object parameters in the test step are passed to the execution method to generate the underlying control instruction.

[0008] According to the present invention, a multi-device collaborative automated testing method is provided, wherein the heterogeneous testing devices include at least two of the following: mobile terminal devices, programmable power supply devices, audio analysis devices, bus communication devices, and serial communication devices; The original control protocol of the mobile terminal device is the debug bridging protocol; the original control protocol of the programmable power supply device is the programmable instrument standard command protocol; the original control protocol of the audio analysis device is the component object model interface; the original control protocol of the bus communication device is the dynamic link library interface; and the original control protocol of the serial communication device is the serial port communication protocol.

[0009] According to a multi-device collaborative automated testing method provided by the present invention, the display of a visual test sequence configuration interface includes: The test sequence is presented in a table format in the visual test sequence configuration interface; each row in the table corresponds to one test step. In each row of the table, a first selection control is displayed for configuring the device configuration information, a second selection control is displayed for configuring the action configuration information, and an input control is displayed for configuring the parameter configuration information; The parameter prompt information for dynamically updating the parameter configuration information corresponding to the target action type includes: Obtain the default value of the parameter and the placeholder prompt text corresponding to the target action type from the second mapping relationship; update the initial input value of the input control in the corresponding row of the table to the default value of the parameter, and update the background prompt of the input control to the placeholder prompt text.

[0010] According to a multi-device collaborative automated testing method provided by the present invention, the response to a first selection operation based on the device configuration information includes: Listen for the index change signal of the first selection control; When the index change signal is triggered, obtain the source control that triggered the index change signal; Traverse all rows in the table, identify the row containing the source control as the target row, and perform the update operation of the list of available actions in the target row.

[0011] According to a multi-device collaborative automated testing method provided by the present invention, the step of sending the underlying control command to the corresponding physical test device to control the corresponding physical test device to perform test operations includes: In a worker thread independent of the main interface thread, the underlying control instructions corresponding to each test step are executed sequentially according to the order of the test sequence. During the execution of the underlying control instructions by the worker thread, real-time log information is generated; wherein, the real-time log information includes test progress information and single-step execution result information; Through the signal communication mechanism between the worker thread and the main interface thread, the real-time log information is transmitted from the worker thread to the main interface thread, and the test execution monitoring area is updated in the main interface thread; wherein, the signal communication mechanism includes: sending a progress update signal carrying message content and log level before executing each test step, sending a step completion signal carrying step number and success status after executing each test step, and sending a test completion signal carrying overall success status after all test sequences have been executed.

[0012] According to a multi-device collaborative automated testing method provided by the present invention, the step of updating the test execution monitoring area in the main thread of the interface includes: Obtain the log level identifier corresponding to the real-time log information; wherein, the log level identifier includes at least error level, warning level, success level, and information level; The visual display style is matched based on the log level identifier; wherein, different log level identifiers correspond to different color identifiers and prefix identifiers; The real-time log information is rendered in the test execution monitoring area according to the visual display style obtained by matching.

[0013] The multi-device collaborative automated testing method provided by the present invention further includes: In response to the instruction to adjust the order of the test steps, obtain the current position of the currently selected step and the adjustment direction indicating whether to move it up or down; Calculate the target position based on the adjustment direction, and determine whether the target position is within the valid range of the test sequence; If the target location is within the valid range, the data of the test steps corresponding to the current location and the test steps corresponding to the target location are swapped in the device configuration information, the action configuration information, and the parameter configuration information, and the selection status is updated to the test steps corresponding to the target location.

[0014] According to a multi-device collaborative automated testing method provided by the present invention, the method further includes, simultaneously with or before displaying the visual test sequence configuration interface: The test case management interface is displayed, which presents multiple test cases with checkboxes; each test case is associated with an independent list of test steps, which is stored in a data dictionary with the test case name as the key. In response to test case creation or switching instructions, the test step list corresponding to the current test case is saved to the data dictionary, and a new blank test step list is created from the data dictionary or the test step list corresponding to the selected test case is loaded to the visual test sequence configuration interface. When responding to the test execution command, the system obtains the target test case set in which the check control is selected, loads the test step list corresponding to the target test case set sequentially from the data dictionary, concatenates them into a global test sequence to be executed, and repeatedly executes the global test sequence according to a preset number of loops.

[0015] The present invention also provides a multi-device collaborative automated testing device, comprising the following modules: The display module is used to display a visual test sequence configuration interface; wherein, the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information and parameter configuration information; The first update module is used to respond to a first selection operation on the device configuration information, obtain the target device type, and dynamically update the list of available actions of the action configuration information corresponding to the target device type based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; The second update module is used to respond to a second selection operation on the action configuration information, obtain the target action type, and dynamically update the parameter prompt information of the parameter configuration information corresponding to the target action type based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; The parsing module is used to respond to test execution instructions, parse each test step in the test sequence, and convert each test step into the underlying control instructions of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format, and returns a unified format execution result. The testing module is used to send the underlying control commands to the corresponding physical testing device to control the corresponding physical testing device to perform test operations.

[0016] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multi-device collaborative automated testing method as described above.

[0017] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-device collaborative automated testing method as described above.

[0018] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the multi-device collaborative automated testing method as described above.

[0019] This invention provides a multi-device collaborative automated testing method and apparatus. By displaying a visual test sequence configuration interface and presenting test steps containing device configuration information, action configuration information, and parameter configuration information, testers can intuitively configure test sequences without writing code. Through cascading dynamic updates between device type and available action list, and action type and parameter prompts based on preset first and second mapping relationships, incompatible configurations between devices and actions, as well as input errors in parameter formats, are effectively avoided, reducing the probability of test configuration errors and improving configuration efficiency. By constructing a unified calling interface that shields the differences in underlying communication protocols between different physical test devices, the test steps configured by the user in the visual interface are automatically converted into underlying control commands for the corresponding physical devices. This achieves unified collaborative control of multiple heterogeneous test devices, thereby lowering the technical threshold and operational complexity of multi-device collaborative automated testing and improving the efficiency and accuracy of the entire test sequence process from configuration to execution. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the multi-device collaborative automated testing method provided by the present invention; Figure 2 This is a schematic diagram of the overall system architecture in one embodiment of the present invention; Figure 3 This is a schematic diagram of a test sequence table structure in one embodiment of the present invention; Figure 4 This is a schematic diagram of the multi-device collaborative automated testing device provided by the present invention; Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0023] Figure 1This is a flowchart illustrating the multi-device collaborative automated testing method provided by the present invention, as shown below. Figure 1 As shown, the method includes the following: Step 110: Display the visual test sequence configuration interface; wherein the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information and parameter configuration information; In this application, the computer's processor presents a visual test sequence configuration interface to the user via a display device. This visual test sequence configuration interface refers to an interface constructed using a graphical user interface, allowing users to directly configure the test process through visual interaction. Unlike traditional test configuration methods based on script programming or command-line text editing, this visual test sequence configuration interface uses graphical controls (such as selection controls, input controls, button controls, etc.) to carry test configuration information, enabling users to define and arrange test sequences without writing program code.

[0024] A test sequence is an ordered set of at least one test step arranged in a predetermined order. The test sequence defines the complete execution flow of automated testing, where the test steps have a clear sequential execution relationship.

[0025] For example, a typical test sequence may include several ordered test steps such as: connecting the power supply; setting the voltage; starting the application under test; performing audio acquisition; and disconnecting the device.

[0026] Each of the test steps is the smallest configuration unit in the test sequence, representing a complete device operation. Each test step contains configuration information in three dimensions: device configuration information, action configuration information, and parameter configuration information.

[0027] Device configuration information refers to the type identifier of the target device operated in the current test step. This device configuration information is used to specify the physical test equipment that needs to be controlled in the current test step.

[0028] Physical testing equipment can include, but is not limited to, various types of testing instruments or devices under test, such as mobile terminal devices, programmable power supply devices, audio analysis devices, bus communication devices, and serial communication devices.

[0029] For example, when the device configuration information is configured as a certain type of mobile terminal device, it means that the current test step will perform an operation on that type of mobile terminal device.

[0030] Action configuration information refers to the specific type of operation to be performed on the selected device in the current test step. Different types of physical test devices typically support different sets of actions.

[0031] For example, for mobile terminal devices, available actions may include launching an application, stopping an application, clicking on interface elements, swiping the screen, pressing buttons, and taking screenshots; for programmable power supply devices, available actions may include connecting to the device, setting the voltage, setting the output switch, and reading the current. The action configuration information is selected from the set of available actions corresponding to the device configuration information.

[0032] Parameter configuration information refers to the specific parameter values ​​or operation objects required when the selected action in the current test step is executed. The content and format of the parameter configuration information are related to the selected action type.

[0033] For example, when the action configuration information is to set the voltage, the parameter configuration information can be a specific voltage value; when the action configuration information is to start an application, the parameter configuration information can be the application's package name identifier.

[0034] Step 120: In response to the first selection operation for the device configuration information, obtain the target device type, and dynamically update the list of available actions for the action configuration information corresponding to the target device type based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; In this application, when a user performs a first selection operation on the device configuration information of a certain test step, such as selecting a certain device type, the processor obtains the selected target device type and dynamically updates the list of available actions of the action configuration information of the test step based on the pre-configured first mapping relationship.

[0035] The first mapping relationship is a pre-established correspondence between device types and available actions, stored in memory using data structures such as dictionaries and mapping tables.

[0036] Dynamic updates refer to the system changing the list of available actions in real time after the user completes the device type selection, clearing the original action options and loading available actions that match the new device type.

[0037] For example, the available actions for mobile terminal devices include: connecting to the device, launching the application, stopping the application, clicking on an element, swiping up, swiping down, and button operations; The available actions for programmable power supply devices include: connecting to power, setting voltage, turning on output, turning off output, and reading current. When a user switches the device type from a mobile terminal device to a programmable power supply device, the action list is automatically updated to the corresponding content to avoid the user selecting incompatible actions.

[0038] Step 130: In response to the second selection operation for the action configuration information, obtain the target action type, and dynamically update the parameter prompt information of the parameter configuration information corresponding to the target action type based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; In this application, when a user performs a second selection operation on the action configuration information of a certain test step, such as selecting a certain action type, the processor obtains the selected target action type and dynamically updates the parameter prompt information in the parameter configuration information of that test step based on a pre-configured second mapping relationship. The second mapping relationship is a pre-established correspondence between action types and parameter prompt information.

[0039] Parameter prompts can include guidance such as parameter format descriptions, parameter value ranges, default values, and parameter usage descriptions, allowing users to input parameters correctly without having to memorize the parameter formats for each action.

[0040] For example, when selecting to set the voltage, the parameter area automatically displays a formatted prompt indicating the voltage value range (e.g., <1.0-20.0>); when selecting "Launch Application", the application package name is automatically displayed (e.g., <package name, such as com.example.app>).

[0041] Step 140: Respond to the test execution command, parse each test step in the test sequence, and convert each test step into the underlying control command of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format, and returns a unified format execution result; When the processor receives a test execution command triggered by the user, such as clicking the start test button, it reads the device configuration information, action configuration information and parameter configuration information of each test step in the order of the test sequence, and converts them into low-level control commands that can be recognized and executed by the corresponding physical test device through a pre-built unified call interface.

[0042] In multi-device collaborative scenarios, different types of physical test devices typically employ different underlying communication protocols, such as debug bridging protocols, programmable instrument standard command protocols, component object model interfaces, and dynamic link library interfaces. These protocols differ significantly in terms of communication methods, command formats, data encoding, and return value structures.

[0043] The core function of the unified API is to shield the differences in underlying communication protocols between different physical testing devices, provide a consistent calling format, and return execution results in a unified format, such as structured data containing boolean values ​​indicating successful execution and result descriptions. Upper-level callers do not need to understand the underlying protocol details of each device; they can control any type of device simply through the unified calling format.

[0044] Figure 2 This is a schematic diagram of the overall system architecture in one embodiment of the present invention, as shown below. Figure 2 As shown, the system comprises, from top to bottom, a visual configuration interface layer, a unified device control interface layer, a device protocol adaptation layer, and a physical device layer. The unified call interface is located in the unified device control interface layer, providing a consistent calling format to the upper layers and shielding the lower layers from the protocol differences between different devices.

[0045] Step 150: Send the underlying control command to the corresponding physical test device to control the corresponding physical test device to perform test operations.

[0046] The processor sends the generated low-level control instructions to the corresponding physical test equipment through the corresponding communication channels, such as the general serial bus interface, network interface, serial port, etc.

[0047] After receiving the instruction, the physical testing equipment performs the corresponding test operation according to the instruction content and returns the execution result to the processor through the communication channel.

[0048] The processor completes the parsing, conversion, transmission, and reception processes one by one according to the order of the test sequence, thereby realizing the coordinated control of multiple physical test devices and completing the automated test process defined by the entire test sequence.

[0049] In this invention, the technical threshold for automated testing is lowered through a visual interface and dynamic update mechanism, enabling testers without a programming background to independently configure test sequences. On the other hand, the intelligent association between devices, actions, and parameters reduces configuration errors. At the same time, the unified calling interface simplifies the integration complexity of multi-device collaborative testing, enabling the system to control various heterogeneous test devices using different underlying protocols in a consistent manner.

[0050] Optionally, before converting each test step into the underlying control instructions of the corresponding physical test equipment through a pre-built unified calling interface, the method further includes: Obtain the original control protocols of various heterogeneous test devices; Each of the original control protocols is encapsulated into a corresponding unified controller object; wherein the unified controller object shields the differences between the original control protocols and provides the unified calling interface to the outside world; Establish a third mapping relationship between the device type identifier and the unified controller object; wherein, the third mapping relationship is the correspondence between the device type identifier and the unified controller object instance; The process of converting each test step into the underlying control instructions of the corresponding physical test equipment through a pre-built unified calling interface includes: Based on the target device type and the third mapping relationship in each of the test steps, obtain the corresponding unified controller object; The execution method corresponding to the target action type in the unified controller object is invoked, and the object parameters in the test step are passed to the execution method to generate the underlying control instruction.

[0051] In this application, heterogeneous test equipment refers to various types of test equipment that employ different underlying communication protocols and control command formats. The original control protocol is a specific protocol or interface specification natively used by each device, and different manufacturers or different types of devices differ in communication methods, command syntax, parameter encoding methods, and return value formats.

[0052] The processor obtains the original control protocols of various heterogeneous test devices that it needs to support by reading pre-configured device drivers, protocol library files, interface definition files, etc.

[0053] Then, each original control protocol is encapsulated into a corresponding unified controller object. The unified controller object is a controller entity built through software encapsulation for each heterogeneous test device.

[0054] Each unified controller object internally contains the protocol implementation logic necessary for communication with the corresponding physical test equipment, such as establishing connections, sending commands, and parsing returned data. Externally, it shields these protocol differences, exposing a set of uniformly formatted control methods, i.e., a unified calling interface. All methods provided by the unified controller object use a consistent calling format, such as uniform method signatures and parameter passing methods, and all return execution results in a uniform format.

[0055] Next, a third mapping relationship is established between device type identifiers and unified controller objects. This third mapping relationship binds the type identifier of each device to its corresponding unified controller object instance, and stores it in memory in the form of a dictionary, hash table, or mapping table, so that the corresponding controller instance can be quickly located based on the device type identifier during test execution.

[0056] In an embodiment of the present invention, the main controller, such as the HuController class, creates a corresponding controller instance for each device type during initialization and saves the controller instance as an attribute of the main controller.

[0057] During test execution, the controller is retrieved using methods such as the get_controller method, which searches for and returns the corresponding controller instance based on the device type identifier. The mapping relationship is achieved through conditional judgment.

[0058] All controller methods return a uniform format, such as a tuple containing a success status boolean value and a message description string (success:bool, message:str).

[0059] During test execution, the specific conversion process involves first obtaining the corresponding unified controller object based on the target device type and the third mapping relationship in the test step. The processor extracts the target device type from the current test step and searches for a matching unified controller object instance in the third mapping relationship.

[0060] Secondly, the execution method corresponding to the target action type in the unified controller object is called, and the object parameters in the test steps are passed to the method to generate the underlying control instructions.

[0061] The processor determines the target action type of the current test step, locates the corresponding execution method in the unified controller object, passes the parameter configuration information as object parameters, and the execution method generates low-level control instructions based on the parameters and the original control protocol specification and sends them to the physical test equipment.

[0062] In this application, modular isolation of the control logic of different devices is achieved. The control logic of each device is encapsulated in its own controller for easy maintenance. At the same time, when adding a new device type, only the corresponding unified controller object needs to be created without modifying the existing logic, which improves the maintainability and scalability of the system and simplifies the integration process of multi-device collaborative testing.

[0063] Optionally, the heterogeneous testing equipment includes at least two of the following: mobile terminal equipment, programmable power supply equipment, audio analysis equipment, bus communication equipment, and serial communication equipment; The original control protocol of the mobile terminal device is the debug bridging protocol; the original control protocol of the programmable power supply device is the programmable instrument standard command protocol; the original control protocol of the audio analysis device is the component object model interface; the original control protocol of the bus communication device is the dynamic link library interface; and the original control protocol of the serial communication device is the serial port communication protocol.

[0064] In this application, mobile terminal devices refer to intelligent terminals based on mobile operating systems, such as in-vehicle infotainment systems (Android car infotainment systems), tablet computers, and smartphones. Their original control protocol is the Debug Bridge protocol (ADB, Android Debug Bridge protocol). Through this protocol, the corresponding unified controller object can perform control operations such as connecting devices, starting / stopping applications, clicking interface elements, swiping the screen, pressing buttons, and taking screenshots.

[0065] Programmable power supply devices, such as the ITECH series of programmable power supplies, are power instruments that support programmable control of output voltage and current.

[0066] Its original control protocol is the Standard Commands for Programmable Instruments (SCPI).

[0067] Through this protocol, the corresponding unified controller object can perform operations such as connecting to power supply, setting voltage, controlling output switches, reading voltage and current, and recording data logs.

[0068] Audio analysis equipment, such as professional audio analyzers like the APx586 and APx525, uses a Component Object Model (COM) interface as its original control protocol. Through this interface, the corresponding unified controller object can perform operations such as connecting devices, opening test projects, collecting and analyzing data, and configuring signal paths and signal generators.

[0069] Bus communication devices, such as the Zhouligong CAN bus adapter and other bus protocol communication devices, use a dynamic link library interface (DLL) as their original control protocol.

[0070] By calling the dynamic link library provided by the manufacturer, the corresponding unified controller object can perform operations such as connecting to CAN devices, sending CAN messages, sending messages in a loop, stopping sending, and disconnecting.

[0071] Serial communication devices, such as power amplifier controllers and sensor modules connected via serial ports, use a serial port communication protocol as their original control protocol.

[0072] Through this protocol, the corresponding unified controller object can perform operations such as opening the serial port, sending / receiving serial port data, power amplifier control, and testing delay.

[0073] The device protocol adaptation layer corresponds to the debug bridging protocol, the programmable instrument standard command protocol, the component object model interface, the dynamic link library interface, and the serial port communication protocol, respectively.

[0074] At the physical device layer, there are corresponding actual hardware such as Android vehicle infotainment systems, programmable power supplies, APx586 / APx525 audio analyzers, and Zhouligong CAN devices.

[0075] By covering the aforementioned heterogeneous devices and protocols, the system can collaboratively control physical test devices using completely different underlying communication protocols within a unified framework, significantly reducing the integration complexity of multi-device collaborative testing and the learning cost for testers.

[0076] Optionally, the display of the visual test sequence configuration interface includes: The test sequence is presented in a table format in the visual test sequence configuration interface; each row in the table corresponds to one test step. In each row of the table, a first selection control is displayed for configuring the device configuration information, a second selection control is displayed for configuring the action configuration information, and an input control is displayed for configuring the parameter configuration information; The parameter prompt information for dynamically updating the parameter configuration information corresponding to the target action type includes: Obtain the default value of the parameter and the placeholder prompt text corresponding to the target action type from the second mapping relationship; update the initial input value of the input control in the corresponding row of the table to the default value of the parameter, and update the background prompt of the input control to the placeholder prompt text.

[0077] In this application, the visual test sequence configuration interface presents the test sequence in a table format. The table is a two-dimensional table control with a row and column structure, where each row corresponds to a test step, and the rows are arranged in a top-to-bottom order, which is the execution order of the test steps.

[0078] In an embodiment of the present invention, the table is implemented using the QTableWidget component and is equipped with properties such as alternating row color and row selection mode to improve readability.

[0079] In this application, each row of the table contains three control areas: The first selection control is used to configure device information. It has preset options for various device types supported by the system, such as customer vehicle infotainment systems, ITECH power supplies, APx586, APx525, computer hosts, and ZLG CAN. Users select the target device type from the preset options by operating the first selection control.

[0080] The second selection control is used to configure action settings. The list of options in the second selection control changes dynamically based on the selected value of the first selection control; it is initially empty and updates after the device type is selected.

[0081] The input control is used to configure parameter information. Users complete the configuration by typing specific parameter content into the input control.

[0082] Figure 3 This is a schematic diagram of a test sequence table structure in one embodiment of the present invention, as shown below. Figure 3 As shown, the table contains three columns: execution device, execution action, and execution object.

[0083] For example, in one row of the table, the first selection control displays the customer's vehicle infotainment system, the corresponding second selection control displays the connected vehicle infotainment system, and the corresponding input control displays the click coordinate information; in another row, the first selection control displays the ITECH power supply, the second selection control displays the voltage setting, and the input control displays 14.0.

[0084] After the user clicks the "New Step" button, the system inserts a new row at the end of the table and creates corresponding controls for the three columns of that row.

[0085] The system also provides a method for obtaining test sequence data, which involves traversing all rows of the table, extracting the device type, action type, and parameter information for each row, and organizing it into structured data for test execution.

[0086] When dynamically updating parameter prompts, the processor obtains the default parameter values ​​and placeholder prompt text corresponding to the target action type from the second mapping relationship.

[0087] The default parameter value is a pre-configured default parameter value that is automatically filled into the input control when the user does not actively enter it.

[0088] For example, the default value of the voltage action parameter is set to 14.0, the default value of the test delay action parameter is 3, which means 3 seconds, and the default value of the output action parameter is True.

[0089] Placeholder text is guide text displayed in a light color or semi-transparent manner in the input control. It is not used as an actual parameter value in the test execution, but is used to indicate the parameter format or value range.

[0090] For example, the placeholder text for voltage can be set to <1.0-20.0>, prompting the user to enter a voltage value between 1.0 and 20.0; the placeholder text for starting an application can be <package name, such as com.example.app>; and the placeholder text for sending a CAN message can be <message ID, data, type>.

[0091] The processor updates the initial input value of the corresponding row input control to the default parameter value and updates the background prompt of the input control to placeholder prompt text.

[0092] In this application, by automatically filling in the default values ​​of parameters and updating the placeholder prompt text in real time, the amount of manual input is reduced on the one hand, and the user is guided to enter the parameters correctly on the other hand, which effectively reduces the error rate of parameter configuration and improves the configuration efficiency.

[0093] Optionally, the response to the first selection operation of the device configuration information includes: Listen for the index change signal of the first selection control; When the index change signal is triggered, obtain the source control that triggered the index change signal; Traverse all rows in the table, identify the row containing the source control as the target row, and perform the update operation of the list of available actions in the target row.

[0094] In this application, the processor detects changes in device type by listening to the index change signal of the first selection control.

[0095] The index change signal is a notification signal automatically emitted by the first selection control when its currently selected item changes (such as the currentIndexChanged signal), carrying the changed option index information.

[0096] Since each row in the table contains an independent first selection control, the processor pre-registers to listen for index change signals of all first selection controls, so that any change in the selected item in any row can be captured instantly.

[0097] When an index change signal is triggered, the processor obtains the source control that triggered the signal—that is, the specific first select control instance that emitted the signal.

[0098] In this embodiment of the invention, the source control is determined by the signal sender identifier (such as obtaining the control reference of the signal sender using the sender() method).

[0099] The processor then iterates through all rows in the table, identifying the rows containing the source control as target rows. Specifically, it examines each row for the embedded first selection control, identifying the rows that match the source control as target rows.

[0100] After determining the target row, the processor clears the original options of the second selection control in the target row according to the currently selected target device type and the first mapping relationship, and loads a new list of available actions that match the target device type.

[0101] In this application, by using the source control positioning and line-by-line traversal matching method described above, the device type change of each test step only affects its own action list and will not interfere with other lines, thus ensuring the independence and accuracy of the configuration of multiple test steps.

[0102] Optionally, the underlying control command is sent to the corresponding physical test device to control the corresponding physical test device to perform test operations, including: In a worker thread independent of the main interface thread, the underlying control instructions corresponding to each test step are executed sequentially according to the order of the test sequence. During the execution of the underlying control instructions by the worker thread, real-time log information is generated; wherein, the real-time log information includes test progress information and single-step execution result information; Through the signal communication mechanism between the worker thread and the main interface thread, the real-time log information is transmitted from the worker thread to the main interface thread, and the test execution monitoring area is updated in the main interface thread. The signal communication mechanism includes: sending a progress update signal carrying message content and log level before executing each test step; sending a step completion signal carrying step number and success status after executing each test step; and sending a test completion signal carrying overall success status after all test sequences have been executed.

[0103] In this application, the main thread of the interface is responsible for graphics rendering and user interaction response, while the worker thread is an independently created background thread specifically used to perform test operations.

[0104] The test execution logic is placed in a separate worker thread to avoid blocking the main UI thread due to long test execution times. This ensures that the user interface remains responsive during test execution, allowing users to view logs and perform stop operations. The worker thread executes each low-level control instruction sequentially according to the test sequence, waiting for the result of each step before proceeding to the next.

[0105] The worker thread generates real-time log information during execution, including test progress information and single-step execution result information.

[0106] The worker thread and the main interface thread communicate with each other via a signal communication mechanism to exchange real-time log information. After receiving the signal, the main interface thread updates the display content of the test execution monitoring area.

[0107] Signal communication mechanisms specifically include three signal types: A progress update signal is sent before each test step, carrying a message content and log level. The message content describes the step to be executed, and the log level indicates the importance of the message, such as information level or warning level. Based on this, the main thread of the interface displays a prompt indicating the start of the step in the test execution monitoring area.

[0108] A step completion signal is sent after each test step, carrying the step number and success status. The step number is the sequence number of the current step in the test sequence, and the success status is a boolean value indicating whether the execution was successful. The main thread of the interface updates the execution result display of the corresponding step accordingly.

[0109] The test completion signal is sent after all test sequences have been executed, carrying an overall success status and a boolean value indicating whether all steps were executed successfully. The main thread of the interface displays the final result of the entire test process based on this signal.

[0110] In this embodiment of the invention, the worker thread inherits from the thread base class (such as the QThread class) and is created as the AutoTestThread worker thread class.

[0111] After the main thread creates worker threads, it connects three signals to their corresponding handler functions: the progress update signal to the log display update function, the step completion signal to the step completion handler function, and the test completion signal to the test completion handler function. In addition, worker threads provide a stop method. By setting a running status flag (such as is_running=False), the worker thread can exit execution during the loop check, and the main thread can call it at any time to stop the test.

[0112] By employing the above methods, test execution and interface interaction are decoupled, ensuring smooth interface response while providing real-time monitoring and feedback capabilities for test progress and results, and supporting the mid-test stop.

[0113] Optionally, updating the test execution monitoring area in the main thread of the interface includes: Obtain the log level identifier corresponding to the real-time log information; wherein, the log level identifier includes at least error level, warning level, success level, and information level; The visual display style is matched based on the log level identifier; wherein, different log level identifiers correspond to different color identifiers and prefix identifiers; The real-time log information is rendered in the test execution monitoring area according to the visual display style obtained by matching.

[0114] In this application, after the main thread of the interface receives the real-time log information, it first obtains the corresponding log level identifier.

[0115] Log level identifiers include at least four levels: Error level (ERROR), indicating serious issues such as test step execution failure, device communication anomalies, and parameter errors; Warning level (WARNING), indicating potential issues that, while not affecting continued execution, require user attention; Success level (SUCCESS), indicating successful test step execution; and Information level (INFO), indicating general prompts such as test process progress and step commencement.

[0116] In some implementations, the log level identifier may further include extended levels such as debug level and importance level.

[0117] The processor matches the corresponding visual display style based on the log level identifier. Different log levels correspond to different color identifiers and prefix identifiers: Color coding is used to render log text with specific font colors, achieving visual differentiation. For example, red corresponds to error levels, orange to warning levels, green to success levels, and blue to information levels.

[0118] The prefix identifier is a fixed format string added before the log text to identify the log level at the textual level.

[0119] For example, error level corresponds to the [Error] prefix, warning level corresponds to the [Warning] prefix, success level corresponds to the [Success] prefix, and information level corresponds to the [Information] prefix.

[0120] The processor renders real-time log information in the test execution monitoring area according to a matching visual display style. Specifically, the log text is prefixed with an identifier, and the corresponding font color is set before being appended to the test execution monitoring area. Each log also includes a precise timestamp, facilitating test process traceability and problem localization.

[0121] Optionally, it also includes: In response to the instruction to adjust the order of the test steps, obtain the current position of the currently selected step and the adjustment direction indicating whether to move it up or down; Calculate the target position based on the adjustment direction, and determine whether the target position is within the valid range of the test sequence; If the target location is within the valid range, the data of the test steps corresponding to the current location and the test steps corresponding to the target location are swapped in the device configuration information, the action configuration information, and the parameter configuration information, and the selection status is updated to the test steps corresponding to the target location.

[0122] In this application, the sequence adjustment instruction is an instruction triggered by the user through the adjustment control in the operation interface, provided that the user has selected the row containing a certain test step in the table.

[0123] The adjustment direction is either upward or downward: upward movement means moving the current step one position forward in the test sequence, and downward movement means moving one position backward.

[0124] The processor calculates the target position based on the adjustment direction: if it is an upward movement, the target position is the current position minus one; if it is a downward movement, the target position is the current position plus one.

[0125] Then determine whether the target position is within the valid range of the test sequence, that is, the legal position interval from the first line to the last line.

[0126] If the operation exceeds the valid range, such as moving up when the current line is already in the first row or moving down when the current line is already in the last row, no operation will be performed, and a prompt message may be sent to the user.

[0127] If the target location is within the valid range, the processor swaps the data in the device configuration information, action configuration information, and parameter configuration information of the current location and the target location.

[0128] Specifically, swap the current selected index of the two rows of first selection controls, swap the current selected index of the two rows of second selection controls, and swap the text content and placeholder text of the two rows of input controls.

[0129] After the swap is completed, the selected state is updated to the test step corresponding to the target position, so that the user can visually see that the selected step has moved one position with the adjustment direction, and the interface immediately displays the adjustment result.

[0130] In this application, testers can flexibly adjust the order of test steps with just a simple button operation, without editing code or configuration files. The adjustment process is intuitive, efficient and less prone to errors.

[0131] Optionally, the process may include, simultaneously with or before, displaying the visual test sequence configuration interface: The test case management interface is displayed, which presents multiple test cases with checkboxes; each test case is associated with an independent list of test steps, which is stored in a data dictionary with the test case name as the key. In response to test case creation or switching instructions, the test step list corresponding to the current test case is saved to the data dictionary, and a new blank test step list is created from the data dictionary or the test step list corresponding to the selected test case is loaded to the visual test sequence configuration interface. When responding to the test execution command, the system obtains the target test case set in which the check control is selected, loads the test step list corresponding to the target test case set sequentially from the data dictionary, concatenates them into a global test sequence to be executed, and repeatedly executes the global test sequence according to a preset number of loops.

[0132] In this application, the processor displays a test case management interface simultaneously with or before displaying the visual test sequence configuration interface. The test case management interface is a graphical interface area specifically designed for managing multiple test cases, displaying multiple test cases with checkboxes.

[0133] Each test case represents an independent test scenario or test task. The checkbox is used to indicate whether the test case is selected for subsequent batch execution. The test case management interface also provides a select all checkbox, supporting one-click selection or deselection of all test cases.

[0134] Each test case is associated with an independent list of test steps, and each list of test steps is stored in a data dictionary with the test case name as the key.

[0135] The data dictionary organizes data in key-value pairs, using test case names as keys and corresponding lists of test steps as values, enabling fast mapping and retrieval of names to test step lists. Different test cases can contain different numbers and contents of test steps, which are independent of each other.

[0136] In response to a test case creation command, such as when a user clicks the "Create New Test Case" button, the processor first saves the list of test steps for the currently edited test case to the corresponding key-value pair in the data dictionary. Then, it creates a blank list of test steps in the data dictionary with the new test case name as the key, clears the table in the visual test sequence configuration interface for the user to configure steps for the new test case, and adds a new test case entry in the test case management interface.

[0137] In response to a switching command, such as when a user clicks on another test case entry, the processor saves the test step list of the current test case to the data dictionary, loads the test step list corresponding to the selected test case from the data dictionary, and populates the table in the visual test sequence configuration interface with the device configuration information, action configuration information, and parameter configuration information of each loaded test step for the user to view and edit. Users can also enter edit mode by double-clicking the test case name to rename the test case.

[0138] When responding to a test execution command, the processor traverses all test cases in the test case management interface and obtains the set of target test cases in which the check control is selected. This set may contain one or more selected test cases.

[0139] The processor loads the test step list of each target test case from the data dictionary according to the order of the test cases in the target test case set, and assembles them into a global test sequence to be executed. The global test sequence contains all the test steps of all selected test cases, and the execution order is as follows: first, all the steps of the first selected test case are executed, then all the steps of the second selected test case are executed, and so on.

[0140] The processor further executes the global test sequence repeatedly according to a preset number of loops. The number of loops is preset by the user; for example, if it is set to 3, the global test sequence will be executed three times. This is suitable for scenarios that require repeated verification of the test process, such as stability testing and stress testing.

[0141] In this application, the test case data is isolated from each other and managed independently, while supporting batch selection and cyclic execution, which significantly improves the test organization efficiency and execution flexibility in complex test scenarios, and makes it easier for testers to flexibly combine different test cases to meet diverse test needs.

[0142] The multi-device collaborative automated testing apparatus provided by the present invention is described below. The multi-device collaborative automated testing apparatus described below and the multi-device collaborative automated testing method described above can be referred to in correspondence.

[0143] Figure 4 This is a schematic diagram of the multi-device collaborative automated testing device provided by the present invention, as shown below. Figure 4 As shown, it includes: The display module 410 is used to display a visual test sequence configuration interface; wherein, the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information and parameter configuration information; The first update module 420 is used to respond to a first selection operation on the device configuration information, obtain the target device type, and dynamically update the list of available actions of the action configuration information corresponding to the target device type based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; The second update module 430 is used to respond to a second selection operation for the action configuration information, obtain the target action type, and dynamically update the parameter prompt information of the parameter configuration information corresponding to the target action type based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; The parsing module 440 is used to respond to test execution instructions, parse each test step in the test sequence, and convert each test step into the underlying control instructions of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format to the outside world, and returns a unified format execution result; The test module 450 is used to send the underlying control commands to the corresponding physical test device to control the corresponding physical test device to perform test operations.

[0144] In this application, a visual test sequence configuration interface is displayed, presenting test steps containing device configuration information, action configuration information, and parameter configuration information. This allows testers to configure test sequences intuitively without writing code. By implementing cascading dynamic updates between device type and available action list, and action type and parameter prompts based on preset first and second mapping relationships, incompatible configurations between devices and actions, as well as input errors in parameter formats, are effectively avoided, reducing the probability of test configuration errors and improving configuration efficiency. Furthermore, by constructing a unified calling interface that masks the differences in underlying communication protocols between different physical test devices, the test steps configured by the user in the visual interface are automatically converted into underlying control commands for the corresponding physical devices. This achieves unified collaborative control of multiple heterogeneous test devices, thereby reducing the technical threshold and operational complexity of multi-device collaborative automated testing and improving the efficiency and accuracy of the entire test sequence process from configuration to execution.

[0145] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 5 As shown, the electronic device may include: a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, the communications interface 520, and the memory 530 communicate with each other through the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute a multi-device collaborative automated testing method, which includes: displaying a visual test sequence configuration interface; wherein the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information, and parameter configuration information; In response to a first selection operation on the device configuration information, the target device type is obtained, and the list of available actions corresponding to the action configuration information of the target device type is dynamically updated based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; In response to a second selection operation on the action configuration information, the target action type is obtained, and the parameter prompt information of the parameter configuration information corresponding to the target action type is dynamically updated based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; In response to the test execution command, the test steps in the test sequence are parsed, and each test step is converted into the underlying control command of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format and returns a unified format execution result; The underlying control command is sent to the corresponding physical test device to control the corresponding physical test device to perform test operations.

[0146] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, 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 described in the various embodiments of the present invention. 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.

[0147] On the other hand, the present invention also provides a computer program product, the computer program product including a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, the computer program being executed by a processor, the computer being able to execute the multi-device collaborative automated testing method provided by the above methods, the method including: displaying a visual test sequence configuration interface; wherein, the visual test sequence configuration interface presents a test sequence, the test sequence including at least one test step, the test step including device configuration information, action configuration information and parameter configuration information; In response to a first selection operation on the device configuration information, the target device type is obtained, and the list of available actions corresponding to the action configuration information of the target device type is dynamically updated based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; In response to a second selection operation on the action configuration information, the target action type is obtained, and the parameter prompt information of the parameter configuration information corresponding to the target action type is dynamically updated based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; In response to the test execution command, the test steps in the test sequence are parsed, and each test step is converted into the underlying control command of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format and returns a unified format execution result; The underlying control command is sent to the corresponding physical test device to control the corresponding physical test device to perform test operations.

[0148] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When executed by a processor, the computer program is implemented to perform the multi-device collaborative automated testing method provided by the above methods. The method includes: displaying a visual test sequence configuration interface; wherein the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information, and parameter configuration information. In response to a first selection operation on the device configuration information, the target device type is obtained, and the list of available actions corresponding to the action configuration information of the target device type is dynamically updated based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; In response to a second selection operation on the action configuration information, the target action type is obtained, and the parameter prompt information of the parameter configuration information corresponding to the target action type is dynamically updated based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; In response to the test execution command, the test steps in the test sequence are parsed, and each test step is converted into the underlying control command of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format and returns a unified format execution result; The underlying control command is sent to the corresponding physical test device to control the corresponding physical test device to perform test operations.

[0149] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0150] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-device collaborative automated testing method, characterized in that, include: Display a visual test sequence configuration interface; wherein, the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information and parameter configuration information; In response to a first selection operation on the device configuration information, the target device type is obtained, and the list of available actions corresponding to the action configuration information of the target device type is dynamically updated based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; In response to a second selection operation on the action configuration information, the target action type is obtained, and the parameter prompt information of the parameter configuration information corresponding to the target action type is dynamically updated based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; In response to the test execution command, the test steps in the test sequence are parsed, and each test step is converted into the underlying control command of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format and returns a unified format execution result; The underlying control command is sent to the corresponding physical test device to control the corresponding physical test device to perform test operations.

2. The multi-device collaborative automated testing method according to claim 1, characterized in that, Before converting each test step into the underlying control instructions of the corresponding physical test equipment through a pre-built unified calling interface, the method further includes: Obtain the original control protocols of various heterogeneous test devices; Each of the original control protocols is encapsulated into a corresponding unified controller object; wherein the unified controller object shields the differences between the original control protocols and provides the unified calling interface to the outside world; Establish a third mapping relationship between the device type identifier and the unified controller object; wherein, the third mapping relationship is the correspondence between the device type identifier and the unified controller object instance; The process of converting each test step into the underlying control instructions of the corresponding physical test equipment through a pre-built unified calling interface includes: Based on the target device type and the third mapping relationship in each of the test steps, obtain the corresponding unified controller object; The execution method corresponding to the target action type in the unified controller object is invoked, and the object parameters in the test step are passed to the execution method to generate the underlying control instruction.

3. The multi-device collaborative automated testing method according to claim 2, characterized in that, The heterogeneous testing equipment includes at least two of the following: mobile terminal equipment, programmable power supply equipment, audio analysis equipment, bus communication equipment, and serial communication equipment; The original control protocol of the mobile terminal device is the debug bridging protocol; the original control protocol of the programmable power supply device is the programmable instrument standard command protocol; the original control protocol of the audio analysis device is the component object model interface; the original control protocol of the bus communication device is the dynamic link library interface; and the original control protocol of the serial communication device is the serial port communication protocol.

4. The multi-device collaborative automated testing method according to claim 1, characterized in that, The display and visualization test sequence configuration interface includes: The test sequence is presented in a table format in the visual test sequence configuration interface; each row in the table corresponds to one test step. In each row of the table, a first selection control is displayed for configuring the device configuration information, a second selection control is displayed for configuring the action configuration information, and an input control is displayed for configuring the parameter configuration information; The parameter prompt information for dynamically updating the parameter configuration information corresponding to the target action type includes: Obtain the default value of the parameter and the placeholder prompt text corresponding to the target action type from the second mapping relationship; update the initial input value of the input control in the corresponding row of the table to the default value of the parameter, and update the background prompt of the input control to the placeholder prompt text.

5. The multi-device collaborative automated testing method according to claim 4, characterized in that, The response to the first selection operation of the device configuration information includes: Listen for the index change signal of the first selection control; When the index change signal is triggered, obtain the source control that triggered the index change signal; Traverse all rows in the table, identify the row containing the source control as the target row, and perform the update operation of the list of available actions in the target row.

6. The multi-device collaborative automated testing method according to claim 1, characterized in that, Sending the underlying control command to the corresponding physical test device to control the corresponding physical test device to perform test operations, including: In a worker thread independent of the main interface thread, the underlying control instructions corresponding to each test step are executed sequentially according to the order of the test sequence. During the execution of the underlying control instructions by the worker thread, real-time log information is generated; wherein, the real-time log information includes test progress information and single-step execution result information; Through the signal communication mechanism between the worker thread and the main interface thread, the real-time log information is transmitted from the worker thread to the main interface thread, and the test execution monitoring area is updated in the main interface thread. The signal communication mechanism includes: sending a progress update signal carrying message content and log level before executing each test step; sending a step completion signal carrying step number and success status after executing each test step; and sending a test completion signal carrying overall success status after all test sequences have been executed.

7. The multi-device collaborative automated testing method according to claim 6, characterized in that, The step of updating the test execution monitoring area in the main thread of the interface includes: Obtain the log level identifier corresponding to the real-time log information; wherein, the log level identifier includes at least error level, warning level, success level, and information level; The visual display style is matched based on the log level identifier; wherein, different log level identifiers correspond to different color identifiers and prefix identifiers; The real-time log information is rendered in the test execution monitoring area according to the visual display style obtained by matching.

8. The multi-device collaborative automated testing method according to claim 1, characterized in that, Also includes: In response to the instruction to adjust the order of the test steps, obtain the current position of the currently selected step and the adjustment direction indicating whether to move it up or down; Calculate the target position based on the adjustment direction, and determine whether the target position is within the valid range of the test sequence; If the target location is within the valid range, the data of the test steps corresponding to the current location and the test steps corresponding to the target location are swapped in the device configuration information, the action configuration information, and the parameter configuration information, and the selection status is updated to the test steps corresponding to the target location.

9. The multi-device collaborative automated testing method according to claim 1, characterized in that, Simultaneously with or before displaying the visual test sequence configuration interface, the following is also included: The test case management interface is displayed, which presents multiple test cases with checkboxes; each test case is associated with an independent list of test steps, which is stored in a data dictionary with the test case name as the key. In response to test case creation or switching instructions, the test step list corresponding to the current test case is saved to the data dictionary, and a new blank test step list is created from the data dictionary or the test step list corresponding to the selected test case is loaded to the visual test sequence configuration interface. When responding to the test execution command, the system obtains the target test case set in which the check control is selected, loads the test step list corresponding to the target test case set sequentially from the data dictionary, concatenates them into a global test sequence to be executed, and repeatedly executes the global test sequence according to a preset number of loops.

10. A multi-device collaborative automated testing device, characterized in that, include: The display module is used to display a visual test sequence configuration interface; wherein, the visual test sequence configuration interface presents a test sequence, the test sequence includes at least one test step, and the test step includes device configuration information, action configuration information and parameter configuration information; The first update module is used to respond to a first selection operation on the device configuration information, obtain the target device type, and dynamically update the list of available actions of the action configuration information corresponding to the target device type based on a preset first mapping relationship; wherein, the first mapping relationship is the correspondence between device type and available actions; The second update module is used to respond to a second selection operation on the action configuration information, obtain the target action type, and dynamically update the parameter prompt information of the parameter configuration information corresponding to the target action type based on a preset second mapping relationship; wherein, the second mapping relationship is the correspondence between action type and parameter prompt information; The parsing module is used to respond to test execution instructions, parse each test step in the test sequence, and convert each test step into the underlying control instructions of the corresponding physical test device through a pre-built unified calling interface; wherein, the unified calling interface shields the differences in underlying communication protocols between different physical test devices, provides a consistent calling format, and returns a unified format execution result. The testing module is used to send the underlying control commands to the corresponding physical testing device to control the corresponding physical testing device to perform test operations.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the multi-device collaborative automated testing method as described in any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-device collaborative automated testing method as described in any one of claims 1 to 9.

Images