Device distributed testing method, system, apparatus, terminal device and storage medium

Abstract

The application is suitable for the technical field of intelligent terminals, and provides a device distributed test method, system and device, terminal equipment and storage medium. The method is applied to a test server and includes the following steps: receiving a test execution instruction; dynamically loading connection parameters of multiple embedded devices according to a predefined declarative configuration file, and establishing connections with the multiple embedded devices concurrently; sending the test execution instruction to the embedded devices that have established the connections, triggering the corresponding embedded devices to pull test programs from a central software package warehouse and execute locally; when the communication connection with the embedded devices is normal, receiving test result data that is returned by the embedded devices in real time, when the communication connection with the embedded devices is interrupted, actively obtaining the test result data from local storage of the embedded devices when the communication connection is restored; and aggregating all the received test result data to generate a test report. The application can improve the overall test efficiency in a large-scale test scenario.

Description

Technical Field

[0001] This application relates to the field of smart terminal technology, and in particular to a distributed testing method, system, apparatus, terminal device, and storage medium for devices. Background Technology

[0002] Embedded devices are widely used in many key fields such as automotive electronics, industrial control, and smart homes. These devices often need to meet stringent requirements such as real-time performance and high reliability, placing extremely high demands on the comprehensiveness and accuracy of testing. With the surge in the number and types of devices, traditional manual testing, due to its low efficiency, insufficient coverage, and susceptibility to subjective factors, is no longer suitable for the testing needs of large-scale embedded devices. Automated testing has become the mainstream development direction in the industry. Especially driven by IoT technology, distributed concurrent testing modes are gradually emerging. These modes can simultaneously test and verify multiple devices, significantly improving testing efficiency, and their integration with continuous integration or continuous deployment processes has become an important trend in technological development. However, current distributed concurrent automated testing solutions for embedded devices have not yet effectively solved the overall reliability and efficiency issues in large-scale multi-device testing scenarios.

[0003] How to balance the flexibility of multi-protocol adaptation, the efficiency of test program deployment, the stability of connection and the reliability of results in distributed concurrent automated testing of embedded devices, so as to improve the overall testing performance in large-scale testing scenarios, is a key technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a distributed testing method, system, apparatus, terminal device, and storage medium for embedded devices. It can balance the flexibility of multi-protocol adaptation, the efficiency of test program deployment, the stability of connection, and the reliability of results in distributed concurrent automated testing of embedded devices, thereby improving the overall testing efficiency in large-scale testing scenarios.

[0005] In a first aspect, embodiments of this application provide a distributed device testing method, applied to a test server, comprising:

[0006] Receive test execution instructions;

[0007] Based on a predefined declarative configuration file, the connection parameters of multiple embedded devices are dynamically loaded, and connections are established concurrently with the multiple embedded devices.

[0008] Send a test execution command to the established embedded device. The test execution command is used to trigger the corresponding embedded device to pull the test program from the central software package repository and execute it locally.

[0009] Acquiring test result data of the embedded device in a dual-mode manner includes: when the communication connection with the embedded device is normal, receiving test result data transmitted back in real time by each of the embedded devices; when the communication connection with the embedded device is interrupted, actively retrieving test result data from the local storage of the embedded device when the communication connection is restored.

[0010] Aggregate all received test result data to generate a test report.

[0011] In one possible implementation of the first aspect, the step of dynamically loading connection parameters of multiple embedded devices according to a predefined declarative configuration file and concurrently establishing connections with the multiple embedded devices includes:

[0012] Load the declarative configuration file, which dynamically defines the connection protocol type and detailed parameters for each embedded device;

[0013] Create a corresponding protocol connection object based on the connection protocol type and detailed parameters;

[0014] Based on the connection strategy in the declarative configuration file, the driver establishes concurrent connections between the created protocol connection object and the corresponding embedded device.

[0015] In one possible implementation of the first aspect, the central software package repository stores test program software packages customized for different device architectures; triggering the corresponding embedded device to pull the test program from the central software package repository includes:

[0016] The embedded device is triggered to call its local package management client to pull and install the corresponding test program package from the central package repository.

[0017] In one possible implementation of the first aspect, actively retrieving test result data from the local storage of the embedded device includes:

[0018] After the test execution cycle ends, the embedded device is reconnected.

[0019] After the communication connection is restored, test result data is retrieved from a predetermined storage path on the embedded device.

[0020] In one possible implementation of the first aspect, generating the test report includes:

[0021] The aggregated test result data is parsed to identify the execution status of each test case in the test result data;

[0022] Based on the execution status of the identified test cases, a visual report containing a test overview and test case details is generated.

[0023] In one possible implementation of the first aspect, environmental parameters during test execution are recorded before generating the test report;

[0024] The environmental parameters are integrated into the test report.

[0025] Secondly, embodiments of this application provide a distributed device testing system, including a test server and multiple embedded devices, wherein:

[0026] The test server is used to receive test execution instructions; dynamically load connection parameters of multiple embedded devices according to a predefined declarative configuration file, and concurrently establish connections with the multiple embedded devices; send test execution instructions to the connected embedded devices; obtain test result data of the embedded devices in a dual-mode manner; aggregate all received test result data, and generate a test report;

[0027] The embedded device is configured to receive test execution instructions from the test server; in response to the test execution instructions, pull test programs from the central software package repository and execute them locally; during test execution, when the communication connection with the embedded device is normal, transmit test result data back to the test server in real time; when the communication connection with the embedded device is interrupted, store the test result data locally, and allow the test server to actively retrieve the locally stored test result data after the communication connection is restored.

[0028] Thirdly, embodiments of this application provide a distributed testing device for use on a testing server, comprising:

[0029] The instruction receiving unit is used to receive test execution instructions;

[0030] The device connection unit is used to dynamically load the connection parameters of multiple embedded devices according to a predefined declarative configuration file, and concurrently establish connections with the multiple embedded devices.

[0031] The instruction sending unit is used to send a test execution instruction to an embedded device that has established a connection. The test execution instruction is used to trigger the corresponding embedded device to pull the test program from the central software package repository and execute it locally.

[0032] The result acquisition unit is used to acquire test result data of the embedded device in a dual-mode manner, including: when the communication connection with the embedded device is normal, receiving test result data transmitted back in real time by each embedded device; when the communication connection with the embedded device is interrupted, actively acquiring test result data from the local storage of the embedded device when the communication connection is restored.

[0033] The report generation unit is used to aggregate all received test result data and generate a test report.

[0034] Fourthly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the device distributed testing method as described in the first aspect above.

[0035] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the device distributed testing method as described in the first aspect above.

[0036] Sixthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the device distributed testing method described in the first aspect above.

[0037] In this embodiment, regarding the flexibility of multi-protocol adaptation, after receiving the test execution command, the test server dynamically loads connection parameters according to a predefined declarative configuration file and concurrently establishes connections with the multiple embedded devices. This declarative configuration mode can adapt to the connection requirements of different devices without modifying the core server code, avoiding the cumbersome operation of developing separate interfaces for each protocol in traditional solutions. It can quickly achieve compatibility with the communication protocols of multiple types of embedded devices, providing a flexible adaptation foundation for large-scale distributed concurrent testing. Regarding the efficiency of test program deployment, the test server sends test execution commands to the connected embedded devices, triggering the embedded devices to actively pull the test program from the central software package repository and execute it locally. This replaces the traditional method of manually transmitting or burning test programs, reducing manual intervention costs and simultaneously realizing the efficiency of test program deployment. Unified management and dynamic updates, especially adaptable to the program iteration needs of large-scale device testing scenarios, significantly improve cross-device deployment efficiency. Regarding connection stability and result reliability, a dual-mode approach is used to acquire test result data from the embedded devices. When communication connections are normal, it receives real-time test result data from each embedded device, ensuring the real-time nature of test results in normal scenarios. When communication connections are interrupted, it proactively retrieves results from the local storage of the embedded devices after the connection is restored, completely avoiding test result loss due to connection instability. This eliminates the need to re-execute the complete test due to interruption, significantly reducing the time consumption of large-scale testing. Finally, by aggregating all test result data to generate a test report, the manual summarization of scattered results is eliminated, achieving automated integration and standardized presentation of test results, further improving the efficiency of test result analysis. This application's solution effectively balances multi-protocol adaptation flexibility, test program deployment efficiency, connection stability, and result reliability in distributed concurrent automated testing of embedded devices, significantly improving overall testing performance in large-scale testing scenarios. Attached Figure Description

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

[0039] Figure 1 This is a system architecture diagram of the distributed device testing system provided in the embodiments of this application;

[0040] Figure 2 This is a flowchart illustrating the implementation of the distributed device testing method provided in this application embodiment;

[0041] Figure 3This is a flowchart illustrating a specific implementation of step S202 in the distributed device testing method provided in this application embodiment;

[0042] Figure 4 This is a flowchart illustrating a specific implementation of the distributed device testing method provided in this application for actively acquiring test result data;

[0043] Figure 5 This is a flowchart illustrating a specific implementation of step S205 in the distributed device testing method provided in this application embodiment;

[0044] Figure 6 This is a structural block diagram of the distributed testing device for equipment provided in the embodiments of this application;

[0045] Figure 7 This is a schematic diagram of the terminal device provided in the embodiments of this application. Detailed Implementation

[0046] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0047] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0048] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0049] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0050] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0051] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0052] By way of example and not limitation, the device distributed testing method provided in this application is applicable to various types of terminal devices that need to perform device distributed testing. Specific terminal devices may include mobile phones, tablets, wearable devices, laptops, ultra-mobile personal computers (UMPCs), desktop computers, and servers, etc. This application does not impose any restrictions on the specific type of terminal device.

[0053] As an example and not a limitation, the distributed testing system for devices provided in this application is applicable to distributed concurrent automated testing of multi-protocol, multi-architecture embedded devices.

[0054] Figure 1 The system architecture diagram of the device distributed testing system provided in the embodiment of this application is shown, and is described in detail below: For ease of explanation, only the parts related to the embodiments of the present invention are shown.

[0055] Reference Figure 1 The distributed testing system for the device includes a test server 1 and multiple embedded devices 2, wherein:

[0056] Test server 1 is used to receive test execution instructions; dynamically load the connection parameters of multiple embedded devices 2 according to a predefined declarative configuration file, and concurrently establish connections with the multiple embedded devices 2; and send test execution instructions to the connected embedded devices 2.

[0057] Embedded device 2 is used to receive test execution instructions from test server 1; in response to the test execution instructions, it pulls test programs from the central software package repository and executes them locally.

[0058] Test server 1 is used to obtain test result data of embedded device 2 in a dual-mode manner.

[0059] Embedded device 2 is used to transmit test result data back to test server 1 in real time when the communication connection with embedded device 2 is normal during test execution; when the communication connection with embedded device 2 is interrupted, the test result data is stored locally, and the test server 1 is allowed to actively retrieve the test result data stored locally after the communication connection is restored.

[0060] Test server 1 is used to aggregate all received test result data and generate test reports.

[0061] Test Server 1 is a logical core control and coordination entity, typically deployed on a personal computer, server, cloud, or continuous integration server. Test Server 1 undertakes key functions such as test process triggering, device connection management, test execution command issuance, result acquisition and aggregation, and report generation. Its hardware selection must meet the performance requirements of large-scale concurrent testing. Embedded Device 2 is the test object of the test system and must have the ability to receive test commands, pull and execute test programs, and process and provide feedback on test results.

[0062] In one possible implementation, the embedded device 2 can be categorized into fields such as automotive electronics, industrial control, and smart homes. The hardware architecture and operating system of the embedded device 2 vary depending on the application scenario.

[0063] In one possible implementation, the test server 1 and the embedded device 2 can be connected via network protocol, serial communication, or a dedicated debugging interface.

[0064] In one possible implementation, for multiple embedded devices 2 being tested simultaneously, the test server 1 can evaluate and determine the connection method of the embedded devices 2 based on their type, available physical interfaces, and supported software protocols. Within the same test batch, different embedded devices 2 may have different connection methods.

[0065] In this embodiment, test server 1 and embedded device 2 collaborate to implement distributed testing of the device. Traditional automated testing frameworks typically use a central node to distribute test scripts to devices in real time and monitor their execution. This approach suffers from problems such as high load on the master node, strong network dependence, unstable connections leading to test interruptions or result loss, and excessive coupling between test triggering and execution, which affect the efficiency and reliability of large-scale distributed testing. In this embodiment, after receiving the test execution command, the test server 1 concurrently establishes connections with the multiple embedded devices 2. Based on a predefined declarative configuration file, it dynamically loads the connection parameters of the multiple embedded devices 2, concurrently establishes connections with them, and sends the test execution command to each connected embedded device 2. Upon receiving the test command, the embedded device 2 automatically pulls the test program from the central software package repository and executes it locally. When the communication connection is normal, the embedded device 2 transmits the test result data back to the test server 1 in real time. The test server 1 passively acquires the test result data. When the communication connection is interrupted, the test server 1 actively retrieves the test result data from the local storage of the embedded device 2 when the communication connection is restored. This completely avoids the loss of test results due to unstable connections and eliminates the need to re-execute the complete test due to interruption, significantly reducing the time loss of large-scale testing. Finally, the test server 1 aggregates all received test result data and generates a test report, achieving automated integration and standardized presentation of test results, further improving the efficiency of test result analysis.

[0066] Figure 2 The implementation flow of the device distributed testing method provided in this application embodiment is shown. In this embodiment, the execution entity of the flow is... Figure 1 The test server 1 shown below follows a method flow including steps S201 to S205. The specific implementation principles of each step are as follows:

[0067] Step S201: Receive test execution command.

[0068] Test execution commands are start signals initiated by external sources (such as continuous integration systems) to trigger the entire distributed testing process.

[0069] The test execution command serves as the sole entry point for the entire testing process. It is transmitted through a predefined interface specification to ensure that commands from different sources can be correctly recognized by the system.

[0070] In one possible implementation, the test execution command is triggered by the tester manually clicking "Build Task" through a continuous integration platform (such as Jenkins).

[0071] In one possible implementation, the triggering source for the test execution instruction includes: automatic triggering based on a preset timed task (such as 2 AM every day).

[0072] The test execution command is a structured instruction containing specific triggering logic. The command content includes structured data such as the test task identifier, the information of the device group under test, and the test case set number. Receiving the test execution command on the test server initiates the entire test process, eliminating the need for manual operation of each device individually. Compared to traditional testing, which requires configuring startup parameters for multiple devices separately, this embodiment can initiate large-scale testing of the entire distributed test cluster with a single test execution command, effectively reducing manual intervention costs and providing a unified triggering basis for subsequent multi-device concurrent testing.

[0073] Step S202: Based on the predefined declarative configuration file, dynamically load the connection parameters of multiple embedded devices and concurrently establish connections with the multiple embedded devices.

[0074] A predefined declarative configuration file is a structured file used to centrally define the connection rules for all embedded devices. Unlike traditional testing frameworks where protocol logic is hard-coded into the core code, the declarative configuration file in this embodiment uses an easy-to-read and easy-to-write format. It describes the connection requirements of different embedded devices simply through text configuration, without modifying the core program of the test server. This declarative configuration file only describes the target state of the device connection (such as protocol type and address parameters) without specifying the specific connection execution process. In one possible implementation, the declarative configuration file is written in a structured format such as YAML or JSON.

[0075] Dynamically loading connection parameters for multiple embedded devices is the process by which the test server parses the configuration file and prepares connection resources. The dynamic loading process requires no manual intervention and supports real-time reading of the latest content of the configuration file. If the IP address of a device is temporarily adjusted before the test, only the configuration file needs to be modified and saved. The test server can automatically apply the new parameters when loading, avoiding the cumbersome process of modifying code and redeploying required by the traditional hard-coded method.

[0076] Concurrently establishing connections with the multiple embedded devices is the process by which the test server utilizes multi-threaded / multi-process resources to simultaneously initiate connection requests to multiple devices.

[0077] As one possible implementation of this application Figure 3 A specific implementation flow of step S202 in the device distributed testing method provided in this application embodiment is shown below:

[0078] A1: Load the declarative configuration file, which dynamically defines the connection protocol type and detailed parameters for each embedded device.

[0079] Declarative configuration files dynamically define the connectivity attributes of each embedded device in a declarative rather than imperative manner. Specifically, the declarative configuration file defines the connectivity protocol type and detailed parameters for each embedded device. The protocol type explicitly specifies the communication protocol used by the device, such as Secure Shell (SSH), Telnet, and serial port protocols; the detailed parameters contain all the configuration parameters required for that communication protocol.

[0080] For example, for embedded devices using the SSH protocol, authentication information such as IP address, port number, login username, and encrypted password needs to be defined; for embedded devices using the serial port protocol, parameters such as device physical path, serial port baud rate, data bits, and stop bits need to be defined; and for embedded devices using the Telnet protocol, parameters such as IP address, port number, and connection timeout need to be defined.

[0081] The declarative configuration file approach decouples device connection information from system code. When adding a new embedded device or changing the protocol, only the corresponding entries need to be added or modified in the file, without recompiling the test server program. This greatly improves the flexibility of multi-protocol adaptation. At the same time, concurrent connection to embedded devices avoids the device waiting problem in traditional sequential connection, which can significantly improve connection efficiency in large-scale test scenarios.

[0082] A2: Create the corresponding protocol connection object based on the connection protocol type and detailed parameters.

[0083] In one possible implementation, a protocol connection object is created through a protocol adaptation engine. After parsing the connection protocol type and detailed parameters, the protocol adaptation engine dynamically instantiates a connection object that matches the protocol type through a reflection mechanism.

[0084] For example, when the configured protocol type is SSH, the system creates an SSHClient object and injects parameters such as IP address and port; when the configured protocol type is Serial, it creates a SerialClient object and configures the corresponding serial port parameters. Each protocol connection object encapsulates the communication logic and connection management functions of a specific protocol, providing a standardized interface for subsequent connection establishment.

[0085] A3: Based on the connection strategy in the declarative configuration file, drive the created protocol connection object to establish concurrent connections with the corresponding embedded device.

[0086] Connection strategies include predefined multi-device connection scheduling rules in the declarative configuration file. The purpose of connection strategies is to prevent the test server from overloading or becoming congested due to a large number of simultaneous connection requests. Connection strategies are defined through specific fields in the aforementioned declarative configuration file.

[0087] In one possible implementation, the connection strategy includes batch connection by device group or group connection by protocol type. The connection protocol also includes fault tolerance rules: setting a connection timeout retry mechanism. For example, a declarative configuration file defines a batching strategy of "connecting 10 devices per batch with a 5-second interval between batches" or a protocol grouping strategy of "prioritizing serial protocol devices and then connecting network protocol devices," while setting a fault tolerance rule of "15-second timeout for each connection, retrying twice after timeout."

[0088] For example, based on the connection strategy in the configuration file (such as initiating connections in batches by device group, with each group containing 10 devices to avoid network congestion caused by too many connections at once), the protocol connection object created by the driver simultaneously initiates connection requests to the corresponding embedded devices.

[0089] In this embodiment, a unified source of multi-device connection information is provided through a declarative configuration file. Then, a protocol connection object is created based on the configuration information to achieve unified adaptation of multiple protocols. Finally, concurrent connections are driven through a connection strategy to achieve efficient and stable connection of multiple devices.

[0090] In one possible implementation, the test server will also record the connection status (success / failure) of each embedded device in real time, and mark the reasons for the failed connection devices (such as device power failure, incorrect IP address) to facilitate subsequent troubleshooting and ensure that the connection results are traceable.

[0091] Step S203: Send a test execution command to the established embedded device. The test execution command is used to trigger the corresponding embedded device to pull the test program from the central software package repository and execute it locally.

[0092] The embedded device with an established connection is the device that establishes a stable communication connection in step S202. The test server sends a test execution command to the embedded device with an established connection. The purpose is to pass a trigger signal to the embedded device to "pull the test program and execute it locally", rather than directly carrying the test program to the embedded device.

[0093] The central software package repository is a centralized software storage and distribution server. As one possible implementation of this application, the central software package repository stores test program packages customized for different device architectures. In one possible implementation, the test program packages are pre-compiled and packaged according to the processor architecture (such as ARM, x86, MIPS) and operating system environment of the target embedded device, forming independent, executable software units, and stored according to device architecture, while supporting version management. For example, a test program deb package compiled based on the instruction set can be provided for ARMv7 architecture embedded devices, and a corresponding version of the test program deb package can be provided for x86_64 architecture embedded devices, ensuring that the test program can run natively and efficiently on the target device.

[0094] After the test server sends a test execution command to the established embedded device, it triggers the embedded device to call its local package management client to pull and install the corresponding test program package from the central package repository. The test execution command includes the repository path and program identifier. In response to the test execution command, the embedded device automatically calls its locally pre-installed package management client (APT client). According to the repository path and program identifier in the command, it retrieves and pulls the corresponding test program package from the central package repository. During the retrieval process, the APT client automatically identifies and installs the library files that the test program depends on (such as the "libserial-dev" library for serial communication and the "log4cplus" library for log processing). By simply managing different versions of the test program package in the central repository, the device can obtain the specified version as needed without manual intervention in dependency configuration. After the program is installed, the embedded device will start the test program through the system's native service management mechanism. The execution process of the test program is completed independently on the device itself and does not depend on continuous communication with the test server. Therefore, even if there is a brief network interruption during execution, the test program can continue to run, ensuring that the test process is not interrupted.

[0095] In this embodiment, the test server sends test execution commands to connected embedded devices in batches to ensure that multiple devices can respond synchronously. At the same time, the test execution commands trigger the embedded devices to locally pull and execute the test program, which can completely decouple the test program from the core of the test framework. By utilizing the device's native and mature package management system, standardized packaging, centralized version management and automated deployment of the test program are achieved. The embedded device can obtain the test program suitable for its own architecture as needed, which significantly improves the deployment efficiency and cross-platform compatibility of the test program.

[0096] Step S204: Obtain test result data of the embedded device in a dual-mode manner, including: when the communication connection with the embedded device is normal, receiving test result data transmitted back in real time by each embedded device; when the communication connection with the embedded device is interrupted, actively obtaining test result data from the local storage of the embedded device when the communication connection is restored.

[0097] The dual-mode approach refers to an adaptive mechanism where the test server intelligently selects different data transmission modes based on the real-time network connection status. In the first mode, when the communication connection between the test server and the embedded device is normal, the test server passively receives the test results data transmitted back in real-time by each embedded device. In the second mode, when the communication connection between the test server and the embedded device is interrupted, the test server actively retrieves the test results data from the local storage of the embedded device when the communication connection is restored.

[0098] The test server continuously monitors the communication link status with each embedded device. When the communication connection is stable, the embedded device immediately pushes the structured test result data to the test server through the established communication channel after the test program is completed. When the communication connection is interrupted, the test program on the embedded device will not terminate, but will continue to run until completion and persistently store the generated test result data in a predetermined directory on the device. After the connection is restored, the test server will actively reconnect to the disconnected embedded device and retrieve the complete test result data from the local storage of the embedded device.

[0099] For example, when the communication connection is normal, the embedded device will send test result data back to the test server in real time in JSON format. The test result data includes test case ID, execution time, execution status (initially marked as "in progress"), real-time log fragments, etc. The test result data received by the test server is stored in a designated database, for example, in a real-time result table in a MySQL database, to ensure the real-time nature of the results. When a communication connection interruption is detected (such as SSH connection loss due to network fluctuations in an industrial field, or serial port connection interruption due to a loose serial cable), the embedded device will automatically store the test result data in a predetermined local storage path. When the communication connection is restored, the test server will actively retrieve the test result data from the local storage of the embedded device.

[0100] In this embodiment, test result data of the embedded device is obtained through a dual-mode approach to ensure continuous test execution and avoid the time cost of repeated testing.

[0101] As one possible implementation of this application Figure 4This application illustrates a specific implementation flow of the device distributed testing method that actively retrieves test result data from the local storage of the embedded device, as detailed below:

[0102] B1: After the test execution cycle ends, perform the operation to reconnect the embedded device. The test execution cycle refers to the time period from the issuance of the test execution command to the preset test completion time. For example, after detecting a device connection interruption, the test server waits for a fixed time interval, and then automatically initiates a reconnection request using the original connection parameters and protocol object. If the connection fails, it will attempt multiple times according to an exponential backoff strategy.

[0103] B2: After the communication connection is restored, the test result data is retrieved from the predetermined storage path on the embedded device. The predetermined storage path is a predefined standardized file path. If the embedded device detects a connection interruption during test execution, it will persistently store the test result data in this predetermined storage path.

[0104] In one possible implementation, the test server periodically sends heartbeat packets to the connected embedded device to check the communication connection status. If no response is received from the embedded device for a specified number of consecutive times (e.g., 3 times), the communication connection is determined to be interrupted.

[0105] In one possible implementation, the test server activates a dedicated result retrieval module. This module reuses the connection configuration information of the protocol adaptation engine and the device to actively reconnect to the device and retrieve complete test result data from a predetermined storage path.

[0106] In this embodiment, reconnecting after the test execution cycle ends ensures the integrity of the test process, avoids the problem of frequent connection requests occupying device resources and interfering with the normal execution of the test program, reuses existing connection parameters and protocol objects, eliminates the process of re-parsing configuration files and creating protocol objects, shortens the reconnection time, and ensures that the connection parameters are consistent with the initial connection, reducing the risk of connection failure due to parameter changes. Retrieving results from a predetermined path ensures that test data of interrupted devices is not lost, and improves the reliability and efficiency of result acquisition in distributed testing scenarios.

[0107] Step S205: Aggregate all received test result data and generate a test report.

[0108] In this embodiment, the aggregated test result data includes test result data from different embedded devices during the connection test. Specifically, it includes structured data transmitted back in real time by the embedded devices when the communication connection is normal, and structured data retrieved by the test server from the local storage of the disconnected embedded devices after the communication connection is interrupted. The test server collects test result data from different embedded devices through aggregation, organizes and stores this test result data in a unified manner, and generates a test report through test result parsing and visualization tools.

[0109] By aggregating all received test result data, the manual summarization cost caused by the scattered storage of results in traditional testing is avoided, and the omissions during manual screening and copying of data are reduced.

[0110] As one possible implementation of this application Figure 5 A specific implementation flow of step S205 of the device distributed testing method provided in this application embodiment is shown below:

[0111] C1: Parse the aggregated test result data and identify the execution status of each test case in the test result data.

[0112] The test result data contains key information for each test case: a unique test case identifier (test case ID), execution timestamp, associated device model and architecture, detailed execution logs, and original status markers. By parsing the aggregated test result data, the execution status of each test case is identified. The execution status of a test case includes pass, fail, and skip.

[0113] C2: Based on the execution status of the identified test cases, generate a visual report that includes a test overview and test case details.

[0114] The test overview presents the overall test situation, covering macro-level information such as test task name, total number and type distribution of participating devices, total number of test cases, number and percentage of test cases in each state, and total test duration. Test case details are displayed categorized by device type or test module, including details such as execution logs, execution duration, and firmware version of associated devices. In one possible implementation, failed test cases will also be labeled with their error type.

[0115] Based on the execution status of the identified test cases, and combined with auxiliary information such as device information, execution time, and error logs from the aggregated test results data, a visual report containing a test overview and test case details is generated, ensuring that the report content fully corresponds to the actual test results and that no key data is omitted.

[0116] In one possible implementation, the generated test report is a visual report. For example, the test server utilizes pytest's test result processing capabilities and the Allure reporting framework's data model to centrally parse, classify, and statistically analyze the collected result data. Based on the parsed result data, a structured Allure test report is automatically generated. This report provides detailed test execution overviews, test case details, logs, screenshots (if any), and other visual information. For example, the report homepage is a test overview, displaying the test task name, total number of test cases, pass rate, test duration, and a summary of environment parameters. The report details page displays the execution status of each test case grouped by device; clicking on a failed test case allows viewing complete logs and error screenshot links.

[0117] In one possible implementation, environmental parameters during test execution are recorded before generating the test report; these environmental parameters are then integrated into the test report. Environmental parameters are key environmental information that affects the validity and reproducibility of test results during test execution.

[0118] In one possible implementation, the environmental parameters include test server environment parameters, embedded device environment parameters, and dynamic environment parameters during test execution. Server environment parameters include the operating system version, test framework version, and database version running on the test server; embedded device environment parameters include the hardware architecture, firmware version, and operating system version running on the embedded device; dynamic environment parameters during test execution include test start time, test end time, network bandwidth during the test, and serial communication baud rate. After parsing the test result data, the test server generates the final test report based on the parsed results and all environmental parameters corresponding to the current test task. The integration of environmental parameters improves the report's traceability and facilitates subsequent problem reproduction and analysis.

[0119] As can be seen from the above, in terms of the flexibility of multi-protocol adaptation in this embodiment, after receiving the test execution command, the test server first dynamically loads the connection parameters according to the predefined declarative configuration file and concurrently establishes connections with the multiple embedded devices. This declarative configuration mode can adapt to the connection requirements of different devices without modifying the core code of the server, avoiding the cumbersome operation of developing interfaces separately for each protocol in the traditional solution. It can quickly achieve compatibility with the communication protocols of multiple types of embedded devices, providing a flexible adaptation foundation for large-scale distributed concurrent testing. In terms of test program deployment efficiency, the test server sends the test execution command to the embedded device that has established a connection, triggering the embedded device to actively pull the test program from the central software package repository and execute it locally, replacing the traditional method of manually transmitting or burning the test program, reducing the cost of manual intervention, and realizing the test program deployment efficiency. The unified management and dynamic updating of the program, especially adaptable to the program iteration needs in large-scale device testing scenarios, significantly improves cross-device deployment efficiency. Regarding connection stability and result reliability, it acquires test result data from the embedded devices in a dual-mode approach: receiving real-time test result data from each embedded device when communication is normal, ensuring real-time test results in normal scenarios; and proactively retrieving results from the local storage of the embedded devices after communication is restored when communication is interrupted, completely avoiding test result loss due to connection instability and eliminating the need to re-execute the complete test due to interruption, significantly reducing the time loss in large-scale testing. Finally, by aggregating all test result data to generate a test report, the manual summarization of scattered results is eliminated, achieving automated integration and standardized presentation of test results, further improving the efficiency of test result analysis. This application's solution can effectively balance multi-protocol adaptation flexibility, test program deployment efficiency, connection stability, and result reliability in distributed concurrent automated testing of embedded devices, significantly improving overall testing performance in large-scale testing scenarios.

[0120] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0121] Corresponding to the distributed device testing method described in the above embodiments, Figure 6 A structural block diagram of the distributed testing apparatus provided in the embodiments of this application is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0122] Reference Figure 6 The distributed testing device includes: an instruction receiving unit 61, a device connection unit 62, an instruction sending unit 63, a result acquisition unit 64, and a report generation unit 65, wherein:

[0123] Instruction receiving unit 61 is used to receive test execution instructions;

[0124] The device connection unit 62 is used to dynamically load the connection parameters of multiple embedded devices according to a predefined declarative configuration file, and concurrently establish connections with the multiple embedded devices.

[0125] The instruction sending unit 63 is used to send a test execution instruction to an embedded device that has established a connection. The test execution instruction is used to trigger the corresponding embedded device to pull the test program from the central software package repository and execute it locally.

[0126] The result acquisition unit 64 is used to acquire the test result data of the embedded device in a dual-mode manner, including: when the communication connection with the embedded device is normal, receiving the test result data transmitted back in real time by each of the embedded devices; when the communication connection with the embedded device is interrupted, actively acquiring the test result data from the local storage of the embedded device when the communication connection is restored.

[0127] The report generation unit 65 is used to aggregate all received test result data and generate a test report.

[0128] As one possible implementation of this application, the device connection unit 62 is specifically used for:

[0129] Load the declarative configuration file, which dynamically defines the connection protocol type and detailed parameters for each embedded device;

[0130] Create a corresponding protocol connection object based on the connection protocol type and detailed parameters;

[0131] Based on the connection strategy in the declarative configuration file, the driver establishes concurrent connections between the created protocol connection object and the corresponding embedded device.

[0132] As one possible implementation of this application, the central software package repository stores test program software packages customized for different device architectures; triggering the corresponding embedded device to pull the test program from the central software package repository includes:

[0133] The embedded device is triggered to call its local package management client to pull and install the corresponding test program package from the central package repository.

[0134] As one possible implementation of this application, the result acquisition unit 64 is specifically used for:

[0135] After the test execution cycle ends, the embedded device is reconnected.

[0136] After the communication connection is restored, test result data is retrieved from a predetermined storage path on the embedded device.

[0137] As one possible implementation of this application, the report generation unit 65 is specifically used for:

[0138] The aggregated test result data is parsed to identify the execution status of each test case in the test result data;

[0139] Based on the execution status of the identified test cases, a visual report containing a test overview and test case details is generated.

[0140] As one possible implementation of this application, the report generation unit 65 is further configured to:

[0141] Record the environmental parameters during test execution before generating the test report;

[0142] The environmental parameters are integrated into the test report.

[0143] As can be seen from the above, in terms of the flexibility of multi-protocol adaptation in this embodiment, after receiving the test execution command, the test server first dynamically loads the connection parameters according to the predefined declarative configuration file and concurrently establishes connections with the multiple embedded devices. This declarative configuration mode can adapt to the connection requirements of different devices without modifying the core code of the server, avoiding the cumbersome operation of developing interfaces separately for each protocol in the traditional solution. It can quickly achieve compatibility with the communication protocols of multiple types of embedded devices, providing a flexible adaptation foundation for large-scale distributed concurrent testing. In terms of test program deployment efficiency, the test server sends the test execution command to the embedded device that has established a connection, triggering the embedded device to actively pull the test program from the central software package repository and execute it locally, replacing the traditional method of manually transmitting or burning the test program, reducing the cost of manual intervention, and realizing the test program deployment efficiency. The unified management and dynamic updating of the program, especially adaptable to the program iteration needs in large-scale device testing scenarios, significantly improves cross-device deployment efficiency. Regarding connection stability and result reliability, it acquires test result data from the embedded devices in a dual-mode approach: receiving real-time test result data from each embedded device when communication is normal, ensuring real-time test results in normal scenarios; and proactively retrieving results from the local storage of the embedded devices after communication is restored when communication is interrupted, completely avoiding test result loss due to connection instability and eliminating the need to re-execute the complete test due to interruption, significantly reducing the time loss in large-scale testing. Finally, by aggregating all test result data to generate a test report, the manual summarization of scattered results is eliminated, achieving automated integration and standardized presentation of test results, further improving the efficiency of test result analysis. This application's solution can effectively balance multi-protocol adaptation flexibility, test program deployment efficiency, connection stability, and result reliability in distributed concurrent automated testing of embedded devices, significantly improving overall testing performance in large-scale testing scenarios.

[0144] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0145] This application embodiment also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements... Figures 2 to 5 This represents the steps of any distributed testing method for a device.

[0146] This application embodiment also provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements... Figures 2 to 5This represents the steps of any distributed testing method for a device.

[0147] This application also provides a computer program product that, when run on a terminal device, causes the terminal device to execute the implementation of... Figures 2 to 5 This represents the steps of any distributed testing method for a device.

[0148] Figure 7 This is a schematic diagram of a terminal device provided in an embodiment of this application. For example... Figure 7 As shown, the terminal device 7 in this embodiment includes: a processor 70, a memory 71, and a computer program 72 stored in the memory 71 and executable on the processor 70. When the processor 70 executes the computer program 72, it implements the steps in the various device distributed testing method embodiments described above, for example... Figure 2 Steps S201 to S205 are shown. Alternatively, when the processor 70 executes the computer program 72, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 6 The functions of the instruction receiving unit 61 to the report generating unit 65 shown are as follows.

[0149] For example, the computer program 72 may be divided into one or more modules / units, which are stored in the memory 71 and executed by the processor 70 to complete this application. The one or more modules / units may be a series of computer-readable instruction segments capable of performing a specific function, which describe the execution process of the computer program 72 in the terminal device 7.

[0150] The terminal device 7 may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 7 This is merely an example of terminal device 7 and does not constitute a limitation on terminal device 7. It may include more or fewer components than shown, or combine certain components, or different components. For example, terminal device 7 may also include input / output devices, network access devices, buses, etc.

[0151] The processor 70 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0152] The memory 71 can be an internal storage unit of the terminal device 7, such as a hard disk or memory of the terminal device 7. The memory 71 can also be an external storage device of the terminal device 7, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal device 7. Furthermore, the memory 71 can include both internal and external storage units of the terminal device 7. The memory 71 is used to store the computer program and other programs and data required by the terminal device. The memory 71 can also be used to temporarily store data that has been output or will be output.

[0153] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0154] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0155] If the integrated unit 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0156] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0157] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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. Such 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 this application, and should all be included within the protection scope of this application.

Claims

1. A distributed testing method for devices, characterized in that, Applied to the test server, including: Receive test execution instructions; Load a predefined declarative configuration file, which dynamically defines the connection protocol type and detailed parameters for each embedded device; Create a corresponding protocol connection object based on the connection protocol type and detailed parameters; Based on the connection strategy in the declarative configuration file, the driver establishes concurrent connections between the created protocol connection object and the corresponding embedded device. The connection strategy includes batch connection by device group or group connection by protocol type, and includes fault tolerance rules for setting connection timeout retry mechanism. Send a test execution command to the established embedded device. The test execution command is used to trigger the corresponding embedded device to call its local package management client, pull and install its corresponding test program package from the central package repository. The central package repository stores test program packages customized for different device architectures, and automatically identifies and installs the library files that the test program depends on during the retrieval process. Acquiring test result data of the embedded device in a dual-mode manner includes: when the communication connection with the embedded device is normal, receiving test result data transmitted back in real time by each embedded device; when the communication connection with the embedded device is interrupted, actively retrieving test result data from the local storage of the embedded device when the communication connection is restored; wherein, the communication connection status with the embedded device is detected by periodically sending heartbeat packets to the embedded device. Aggregate all received test result data to generate a test report.

2. The method according to claim 1, characterized in that, The step of actively retrieving test result data from the local storage of the embedded device includes: After the test execution cycle ends, the embedded device is reconnected. After the communication connection is restored, test result data is retrieved from a predetermined storage path on the embedded device.

3. The method according to claim 1, characterized in that, The generated test report includes: The aggregated test result data is parsed to identify the execution status of each test case in the test result data; Based on the execution status of the identified test cases, a visual report containing a test overview and test case details is generated.

4. The method according to any one of claims 1 to 3, characterized in that, Record the environmental parameters during test execution before generating the test report; The environmental parameters are integrated into the test report.

5. A distributed testing system for equipment, characterized in that, This includes a test server and multiple embedded devices, among which: The test server is used to receive test execution instructions; load a predefined declarative configuration file, which dynamically defines the connection protocol type and detailed parameters of each embedded device; create corresponding protocol connection objects according to the connection protocol type and detailed parameters; drive the created protocol connection objects to establish concurrent connections with the corresponding embedded devices based on the connection strategy in the declarative configuration file, wherein the connection strategy includes batch connection by device group or group connection by protocol type, and includes fault tolerance rules for setting connection timeout retry mechanism; send test execution instructions to the embedded devices with established connections; obtain test result data of the embedded devices in a dual-mode manner, wherein the communication connection status with the embedded devices is detected by periodically sending heartbeat packets to the embedded devices; aggregate all received test result data and generate a test report; The embedded device is configured to receive test execution instructions from the test server; in response to the test execution instructions, it calls a local package management client to pull and install the corresponding test program package from the central package repository, wherein the central package repository stores test program packages customized for different device architectures, and automatically identifies and installs the library files that the test program depends on during the pulling process; during test execution, when the communication connection with the embedded device is normal, the test result data is transmitted back to the test server in real time; when the communication connection with the embedded device is interrupted, the test result data is stored locally, and the test server is allowed to actively retrieve the locally stored test result data after the communication connection is restored.

6. A distributed testing device for equipment, characterized in that, Applied to the test server, including: The instruction receiving unit is used to receive test execution instructions; The device connection unit is used to load a predefined declarative configuration file, which dynamically defines the connection protocol type and detailed parameters of each embedded device; create a corresponding protocol connection object according to the connection protocol type and detailed parameters; and drive the created protocol connection object to establish concurrent connections with the corresponding embedded device based on the connection strategy in the declarative configuration file. The connection strategy includes batch connection by device group or group connection by protocol type, and includes fault tolerance rules for setting connection timeout retry mechanism. The instruction sending unit is used to send test execution instructions to the established embedded device. The test execution instructions are used to trigger the corresponding embedded device to call its local package management client to pull and install its corresponding test program package from the central package repository. The central package repository stores test program packages customized for different device architectures, and automatically identifies and installs the library files that the test program depends on during the pulling process. The result acquisition unit is used to acquire test result data of the embedded device in a dual-mode manner, including: when the communication connection with the embedded device is normal, receiving test result data transmitted back in real time by each of the embedded devices; when the communication connection with the embedded device is interrupted, actively acquiring test result data from the local storage of the embedded device when the communication connection is restored, wherein the communication connection status with the embedded device is detected by periodically sending heartbeat packets to the embedded device; The report generation unit is used to aggregate all received test result data and generate a test report.

7. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the device distributed testing method as described in any one of claims 1 to 4.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the distributed device testing method as described in any one of claims 1 to 4.

Images