Equipment distributed test method, system and device, terminal equipment and storage medium

Abstract

The invention is applicable to the technical field of intelligent terminals, and provides an equipment distributed test method, system and device, terminal equipment and a storage medium, the method is applied to a test server, and the method comprises the following steps: receiving a test execution instruction; according to a predefined declarative configuration file, dynamically loading connection parameters of the plurality of embedded devices, and concurrently establishing connection with the plurality of embedded devices; a test execution instruction is sent to the connected embedded equipment, and the corresponding embedded equipment is triggered to pull the test program from the central software package warehouse and execute the test program locally; when the communication connection with the embedded device is normal, receiving test result data returned by each embedded device in real time, and when the communication connection with the embedded device is interrupted and the communication connection is recovered, actively obtaining the test result data from the local storage of the embedded device; and aggregating all the received test result data to generate a test report. According to the invention, the overall test efficiency in a large-scale test scene can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent terminals, and in particular to a device distributed testing method, system, device, terminal device and storage medium. BACKGROUND

[0002] Embedded devices have been widely used in many key fields such as automotive electronics, industrial control, smart home, etc. Such devices often need to meet strict requirements such as real-time performance and high reliability, and put forward very high standards for the comprehensiveness and accuracy of testing. With the explosive growth of the number and types of devices, traditional manual testing has been difficult to adapt to the testing needs of large-scale embedded devices due to its low efficiency, insufficient coverage and susceptibility to subjective factors, and automated testing has become the mainstream development direction of the industry. Especially under the promotion of Internet of Things technology, distributed concurrent testing mode has gradually emerged, which can simultaneously test and verify multiple devices, greatly improving testing efficiency, and the combination with continuous integration or continuous deployment process has become an important trend of technological development. However, the current embedded device distributed concurrent automated testing scheme has not effectively solved the overall reliability and efficiency problem in large-scale multi-device testing scenarios.

[0003] In the embedded device distributed concurrent automated testing, how to balance the multi-protocol adaptation flexibility, testing program deployment efficiency, connection stability and result reliability to improve the overall testing efficiency in large-scale testing scenarios is a technical problem that needs to be solved. SUMMARY

[0004] The embodiments of the present application provide a device distributed testing method, system, device, terminal device and storage medium, which can balance the multi-protocol adaptation flexibility, testing program deployment efficiency, connection stability and result reliability in embedded device distributed concurrent automated testing, and improve the overall testing efficiency in large-scale testing scenarios.

[0005] In a first aspect, the embodiments of the present application provide a device distributed testing method applied to a test server, comprising: receiving a test execution instruction; dynamically loading connection parameters of a plurality of embedded devices according to a predefined declarative configuration file, and concurrently establishing connections with the plurality of embedded devices; sending a test execution instruction to the embedded devices that have established connections, the test execution instruction being used to trigger the corresponding embedded devices to pull a test program from a central software package repository and execute locally; The test result data of the embedded devices is acquired in a dual-mode manner, including: receiving the test result data returned by each embedded device in real time when the communication connection with the embedded device is normal, and actively acquiring the test result data from the local storage of the embedded device when the communication connection with the embedded device is interrupted and the communication connection is restored. All the received test result data is aggregated to generate a test report.

[0006] In a possible implementation manner of the first aspect, the connection parameters of the plurality of embedded devices are dynamically loaded according to the predefined declarative configuration file, and the connection with the plurality of embedded devices is established in parallel, including: The declarative configuration file is loaded, and the connection protocol type and detailed parameters of each embedded device are dynamically defined in the declarative configuration file; The corresponding protocol connection object is created according to the connection protocol type and detailed parameters; The created protocol connection object is driven to establish a parallel connection with the corresponding embedded device based on the connection strategy in the declarative configuration file.

[0007] In a possible implementation manner of the first aspect, the central software package warehouse stores test program software packages customized for different device architectures; and the embedded device is triggered to pull the test program from the central software package warehouse, including: The embedded device is triggered to call a local software package management client to pull and install the corresponding test program software package from the central software package warehouse.

[0008] In a possible implementation manner of the first aspect, the test result data is actively acquired from the local storage of the embedded device, including: The operation of reconnecting the embedded device is performed after the test execution period ends; The test result data is pulled from a predetermined storage path on the embedded device after the communication connection is restored.

[0009] In a possible implementation manner of the first aspect, the test report is generated, including: The aggregated test result data is parsed to identify the execution state of each test case in the test result data; A visual report containing a test overview and case details is generated based on the identified execution state of the test case.

[0010] In a possible implementation manner of the first aspect, the environment parameters during test execution are recorded before the test report is generated; The environment parameters are integrated into the test report.

[0011] In a second aspect, the embodiments of the present application provide a device distributed test system, comprising a test server and a plurality of embedded devices, wherein: The test server is configured to receive a test execution instruction, dynamically load connection parameters of the plurality of embedded devices according to a predefined declarative configuration file, establish connections with the plurality of embedded devices concurrently, send the test execution instruction to the embedded devices with which the connections have been established, acquire test result data of the embedded devices in a dual mode, aggregate all received test result data, and generate a test report. The embedded devices are configured to receive a test execution instruction from the test server, pull a test program from a central software package repository and execute the test program locally in response to the test execution instruction, and when a communication connection with the embedded devices is normal during test execution, return test result data to the test server in real time, and when the communication connection with the embedded devices is interrupted, store the test result data locally and allow the test server to actively acquire the test result data stored locally after the communication connection is restored.

[0012] In a third aspect, the embodiments of the present application provide a device distributed test apparatus applied to a test server, comprising: An instruction receiving unit is configured to receive a test execution instruction. A device connection unit is configured to dynamically load connection parameters of a plurality of embedded devices according to a predefined declarative configuration file, and establish connections with the plurality of embedded devices concurrently. An instruction sending unit is configured to send a test execution instruction to the embedded devices with which the connections have been established, the test execution instruction being used to trigger the corresponding embedded devices to pull a test program from a central software package repository and execute the test program locally. A result acquiring unit is configured to acquire test result data of the embedded devices in a dual mode, including receiving test result data returned in real time by each of the embedded devices when a communication connection with the embedded devices is normal, and actively acquiring test result data from local storage of the embedded devices when the communication connection with the embedded devices is interrupted and the communication connection is restored. A report generating unit is configured to aggregate all received test result data and generate a test report.

[0013] In a fourth aspect, the embodiments of the present application provide a terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the device distributed test method of the first aspect when executing the computer program.

[0014] In a fifth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the device distributed test method according to the first aspect.

[0015] In a sixth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device executes the device distributed test method according to the first aspect.

[0016] In the embodiment of the present application, in terms of multi-protocol adaptation flexibility, after receiving the test execution instruction, the test server first dynamically loads the connection parameters according to the predefined declarative configuration file, and establishes a connection with the plurality of embedded devices in parallel. The declarative configuration mode does not need to modify the core code of the server to adapt to the connection requirements of different devices, avoiding the cumbersome operation of separately developing interfaces for each protocol in the traditional scheme, and can quickly compatible with the communication protocols of multiple types of embedded devices, providing a flexible adaptation basis for large-scale distributed concurrent testing. In terms of test program deployment efficiency, the test server sends a test execution instruction to the embedded devices that have established a connection, triggering the embedded devices to actively pull the test program from the central software package repository and execute it locally, replacing the traditional way of manually transferring or burning the test program, reducing the cost of manual intervention, and at the same time realizing the unified management and dynamic update of the test program, especially adapting to the program iteration requirements in large-scale device testing scenarios, significantly improving the cross-device deployment efficiency. In terms of connection stability and result reliability, the test result data of the embedded devices is obtained in a dual-mode manner, that is, when the communication connection is normal, the test result data returned by each embedded device in real time is received, ensuring the real-time of the test results in normal scenarios, and when the communication connection is interrupted, the results are actively obtained from the local storage of the embedded devices after the communication connection is restored, completely avoiding the loss of test results caused by unstable connection, and there is no need to re-execute the complete test due to interruption, which greatly reduces the time loss of large-scale testing. Finally, by aggregating all the test result data to generate a test report, the step of manually summarizing the scattered results is saved, realizing the automatic integration and standardized presentation of the test results, and further improving the analysis efficiency of the test results. The present application scheme can effectively balance multi-protocol adaptation flexibility, test program deployment efficiency, connection stability and result reliability in embedded device distributed concurrent automated testing, and significantly improve the overall test efficiency in large-scale testing scenarios. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0018] Figure 1 is a system architecture diagram of a device distributed test system provided by the embodiments of the present application; Figure 2 is an implementation flowchart of a device distributed test method provided by the embodiments of the present application; Figure 3 is a specific implementation flowchart of step S202 in the device distributed test method provided by the embodiments of the present application; Figure 4 is a specific implementation flowchart of the active acquisition of test result data in the device distributed test method provided by the embodiments of the present application; Figure 5 is a specific implementation flowchart of step S205 in the device distributed test method provided by the embodiments of the present application; Figure 6 is a structural block diagram of a device distributed test apparatus provided by the embodiments of the present application; Figure 7 is a schematic diagram of a terminal device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0019] In the following description, specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. However, persons skilled in the art will understand that the present application can be practiced without these specific details. In other instances, well-known systems, methods, circuits, and devices are not shown or described in detail in order to avoid obscuring the description of the present application.

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

[0021] It should also be understood that the term "and / or" used in the specification and the appended claims of the present application means any combination of one or more of the associated listed items and all possible combinations thereof, and includes these combinations.

[0022] As used in the specification and the appended claims, the term "if' can be interpreted as meaning "when" or "once" or "in response to a determination" or "in response to detecting" depending on the context. Similarly, the phrase "if it is determined" or "if [a described condition or event] is detected" can be interpreted as meaning "once it is determined" or "in response to a determination" or "once [a described condition or event] is detected" or "in response to detecting [a described condition or event]" depending on the context.

[0023] In addition, in the description of the present application and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0024] In the present application, the reference "one embodiment" or "some embodiments" and the like means that the specific features, structures or characteristics described in connection with the embodiment are included in one or more embodiments of the present application. Therefore, the statements "in one embodiment", "in some embodiments", "in other some embodiments", "in further some embodiments" and the like appearing in different places in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "include", "contain", "have" and their variants mean "include but not limited to", unless otherwise specifically emphasized.

[0025] By way of example and not limitation, the device distributed test method provided by the embodiments of the present application is applicable to various types of terminal devices that need to perform device distributed test, and the terminal devices can specifically include mobile phones, tablet computers, wearable devices, notebook computers, ultra-mobile personal computers (UMPC), desktop computers and servers, etc. The embodiments of the present application do not make any limitation on the specific type of terminal device.

[0026] By way of example and not limitation, the device distributed test system provided by the embodiments of the present application is applicable to distributed concurrent automated testing of multi-protocol, multi-architecture embedded devices.

[0027] Figure 1 The system architecture diagram of the device distributed test system provided by the embodiments of the present application is shown, which is described in detail as follows: for the convenience of description, only the part related to the embodiments of the present application is shown.

[0028] Referring to Figure 1 , the device distributed test system includes a test server 1 and a plurality of embedded devices 2, wherein: A test server 1 is configured to receive test execution instructions, dynamically load connection parameters of a plurality of embedded devices 2 according to a predefined declarative configuration file, and concurrently establish connections with the plurality of embedded devices 2, and send the test execution instructions to the embedded devices 2 with which the connections have been established.

[0029] An embedded device 2 is configured to receive test execution instructions from the test server 1, and in response to the test execution instructions, pull a test program from a central software package repository and execute the test program locally.

[0030] The test server 1 is configured to acquire test result data of the embedded device 2 in a dual-mode manner.

[0031] The embedded device 2 is configured to, during test execution, when a communication connection with the embedded device 2 is normal, real-time return test result data to the test server 1, and when the communication connection with the embedded device 2 is interrupted, store the test result data locally, and allow the test server 1 to actively acquire the test result data stored locally after the communication connection is restored.

[0032] The test server 1 is configured to aggregate all received test result data and generate a test report.

[0033] The test server 1 is a logically core control and coordination entity, and is usually deployed on a personal computer, a server, a cloud, or a continuous integration server. The test server 1 undertakes key functions such as test process triggering, device connection management, test execution instruction issuing, result acquisition and aggregation, report generation, and the like, and the hardware selection thereof needs to meet the performance requirements of large-scale concurrent testing. The embedded device 2 is a test object of a test system, and needs to have the capabilities of receiving test instructions, pulling and executing test programs, processing and feeding back test results.

[0034] In a possible implementation, the types of the embedded device 2 cover the fields of automotive electronics, industrial control, smart home, and the like. The hardware architecture and the operating system of the embedded device 2 differ due to different application scenarios.

[0035] In a possible implementation, the test server 1 and the embedded device 2 can adopt network protocol connection, serial communication connection, or special debugging interface connection.

[0036] In a possible implementation, for a plurality of embedded devices 2 tested simultaneously, the test server 1 can evaluate and determine the connection mode of the embedded device 2 according to the type of the embedded device 2, the available physical interface, and the supported software protocol. The connection modes of different embedded devices 2 can be different under the same test batch.

[0037] In the embodiments of the present application, the test server 1 and the embedded device 2 cooperatively implement distributed testing of the device. The traditional automatic testing framework usually adopts a mode of distributing test scripts to devices in real time and monitoring the execution by a central node, which has problems such as high load of the master node, strong network dependency, test interruption or result loss caused by unstable connection, and high coupling degree of test triggering and execution, thereby affecting the efficiency and reliability of large-scale distributed testing. In the embodiments of the present application, after receiving the test execution instruction, the test server 1 concurrently establishes connections with the plurality of embedded devices 2, dynamically loads the connection parameters of the plurality of embedded devices 2 according to a predefined declarative configuration file, concurrently establishes connections with the plurality of embedded devices 2, and sends the test execution instruction to the embedded devices 2 that have established the connections. After receiving the test instruction, the embedded devices 2 pull the test program from the central software package warehouse and execute locally. When the communication connection is normal, the embedded devices 2 return the test result data to the test server 1 in real time, and the test server 1 passively acquires the test result data. When the communication connection is interrupted, the test server 1 actively acquires the test result data from the local storage of the embedded devices 2 after the communication connection is restored, thereby completely avoiding the loss of test results caused by unstable connection, without the need to re-execute the complete test due to interruption, and greatly reducing the time loss of large-scale testing. Finally, the test server 1 aggregates all the received test result data to generate a test report, realizes the automatic integration and standardized presentation of the test results, and further improves the analysis efficiency of the test results.

[0038] Figure 2 An implementation process of a device distributed testing method provided by the embodiments of the present application is shown. In the embodiments, the execution subject of the process is the test server 1 shown in the figure, and the method process includes steps S201 to S205. The specific implementation principles of each step are as follows: Figure 1 Step S201: Receive a test execution instruction.

[0039] The test execution instruction is a start signal initiated by an external device (such as a continuous integration system) for triggering the entire distributed testing process.

[0040] The test execution instruction is the only entrance of the entire testing process, which is transmitted through a predefined interface specification to ensure that instructions from different sources can be correctly recognized by the system.

[0041] In a possible implementation, the trigger sources of the test execution instruction include manual clicking of a “build task” by a tester through a continuous integration platform (such as Jenkins).

[0042] In a possible implementation, the trigger sources of the test execution instruction include automatic triggering according to a preset timing task (such as 2 a.m. every day). ​

[0043] The test execution instruction contains structured instructions with specific triggering logic, and the instruction content contains structured data such as test task identification, device group information to be tested, test case set number, etc. The test server receives the test execution instruction as the starting link of the entire test process, without manual operation of each device. Compared with the traditional test that needs to configure the starting parameters of multiple devices respectively, the embodiment of the present application can start large-scale testing of the entire distributed test cluster through a single test execution instruction, effectively reducing the cost of manual intervention and providing a unified triggering basis for subsequent multi-device concurrent testing.

[0044] Step S202: Dynamically load the connection parameters of the plurality of embedded devices according to the predefined declarative configuration file, and concurrently establish connections with the plurality of embedded devices.

[0045] The predefined declarative configuration file is a structured file used to centrally define all embedded device connection rules. Unlike the traditional test framework in which protocol logic is hard-coded into the core code, the declarative configuration file in the embodiment of the present application adopts a format that is easy to read and write, and can describe the connection requirements of different embedded devices through text configuration without modifying the core program of the test server. The declarative configuration file only describes the target state of device connection (such as protocol type, address parameter) but does not specify the specific connection execution process. In a possible implementation, the declarative configuration file is written in a structured format such as YAML or JSON.

[0046] Dynamically loading the connection parameters of the plurality of embedded devices is the process of the test server parsing the configuration file and preparing connection resources. The dynamic loading process does not require 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 testing, only the configuration file needs to be modified and saved, and the test server will automatically apply the new parameters when loading, avoiding the cumbersome process of modifying the code and redeploying in the traditional hard-coded manner.

[0047] Concurrently establishing connections with the plurality of embedded devices is the process of the test server using multi-thread / multi-process resources to simultaneously initiate connection requests to multiple devices.

[0048] As a possible implementation of the present application, Figure 3 A specific implementation process of step S202 in the device distributed test method provided by the embodiment of the present application is shown, and the details are as follows: A1: Load the declarative configuration file, which dynamically defines the connection protocol type and detailed parameters of each embedded device.

[0049] 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.

[0050] 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.

[0051] 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.

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

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] In a possible implementation, the connection strategy includes batch connection by device group or connection by protocol type, and the connection protocol further includes a fault tolerance rule: setting a connection timeout retry mechanism. For example, a group batch strategy of "connecting 10 devices in each batch with an interval of 5 seconds" or a protocol grouping strategy of "connecting serial port protocol devices first and then connecting network protocol devices" is defined in the declarative configuration file, and a fault tolerance rule of "15 seconds of single connection timeout and 2 retries after timeout" is set.

[0058] For example, according to the connection strategy in the configuration file (such as initiating connection in batches by device group, each group containing 10 devices to avoid network congestion caused by too many single connections), the protocol connection object created by the driver initiates a connection request to the corresponding embedded device at the same time.

[0059] In the embodiments of the present application, a unified source of multi-device connection information is provided through a declarative configuration file, then protocol connection objects are created based on the configuration information to realize unified adaptation of multiple protocols, and concurrent connection is driven through a connection strategy to realize efficient and stable connection of multiple devices.

[0060] In a possible implementation, the test server also records the connection status (success / failure) of each embedded device in real time, and marks the reason for the connection failure (such as device power failure or IP address error) to facilitate subsequent troubleshooting and ensure that the connection result is traceable.

[0061] Step S203: sending a test execution instruction to the embedded device that has established a connection, the test execution instruction being used to trigger the corresponding embedded device to pull a test program from a central software package warehouse and execute locally.

[0062] The embedded device that has established a connection is the device that has established a stable communication connection in step S202. The test server sends a test execution instruction to the embedded device that has established a connection, and the purpose is to deliver a trigger signal of "pulling a test program and executing locally" to the embedded device, rather than directly carrying a test program to the embedded device.

[0063] The central software package warehouse is a centralized software storage and distribution server. As a possible implementation of the present application, the central software package warehouse stores test program software packages customized for different device architectures. In a possible implementation, the test program software 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 and executable software units, and are stored in categories according to device architecture, while supporting version management. For example, a deb package of a test program compiled based on the ARMv7 instruction set can be provided for an embedded device of ARMv7 architecture, and a corresponding version of the test program deb package can be provided for an embedded device of x86_64 architecture, to ensure that the test program can run efficiently on the target device natively.

[0064] After the test server sends the test execution instruction to the embedded device that has established a connection, the embedded device calls its local software package management client to pull and install its corresponding test program software package from the central software package warehouse. The test execution instruction includes a warehouse path and a program identifier, and the embedded device responds to the test execution instruction by automatically calling the pre-installed software package management client (APT client), retrieving and pulling the corresponding test program software package from the central software package warehouse according to the warehouse path and program identifier in the instruction. During the pulling process, the APT client automatically identifies and installs library files (such as the "libserial-dev" library for serial communication and the "log4cplus" library for log processing) that the test program depends on. Only different versions of test program software packages need to be managed in the central warehouse, and the device can obtain the specified version as needed without manual intervention in dependency configuration. After the program is installed, the embedded device starts the test program through the system's native service management mechanism, and the execution process of the test program is completely completed independently on the device locally and does not depend on continuous communication with the test server. Therefore, even if there is a short network outage during execution, the test program can continue to run, ensuring that the test process does not be interrupted.

[0065] In the embodiments of the present application, the test server sends test execution instructions to the connected embedded devices in batches, ensuring that multiple devices can respond synchronously. At the same time, the test execution instruction triggers the embedded device to pull the test program locally and execute it locally, which can completely decouple the test program and the test framework core. By using the original and mature package management system of the device, standardized packaging, centralized version management, and automatic deployment of the test program are achieved. The embedded device can obtain a test program suitable for its own architecture as needed, significantly improving the deployment efficiency and cross-platform compatibility of the test program.

[0066] Step S204: acquiring the test result data of the embedded device in a dual-mode manner, including: receiving the test result data returned by each embedded device in real time when the communication connection with the embedded device is normal, and actively acquiring the test result data from the local storage of the embedded device when the communication connection with the embedded device is interrupted and the communication connection is restored.

[0067] The dual-mode manner refers to an adaptive mechanism in which the test server intelligently selects different data transmission modes according to the real-time network connection state. The first mode is that the test server acquires the test result data returned by each embedded device in real time in a passive receiving manner when the communication connection between the test server and the embedded device is normal. The second mode is that the test server acquires the test result data from the local storage of the embedded device in an active acquisition manner when the communication connection between the test server and the embedded device is interrupted and the communication connection is restored.

[0068] The test server continuously monitors the communication link state of each embedded device. When the communication connection is stable, the embedded device pushes the structured test result data to the test server through the established communication channel immediately after the test program is executed. When the communication connection is interrupted, the test program on the embedded device side does not terminate, but continues to run until completion, and the generated test result data is stored in the local storage of the device. When the connection is restored, the test server actively reconnects the disconnected embedded device and acquires the complete test result data from the local storage of the embedded device.

[0069] For example, when the communication connection is normal, the embedded device returns the test result data in JSON format to the test server in real time. The test result data includes test case ID, execution time, execution state (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, a real-time result table in a MySQL database, to ensure real-time results. When the communication connection is detected to be interrupted (for example, the SSH connection is disconnected due to network fluctuations in an industrial field, or the serial port connection is interrupted due to loose serial port lines), the embedded device automatically stores the test result data in the local storage path. The test server actively acquires the test result data from the local storage of the embedded device when the communication connection is restored.

[0070] In the embodiment of the application, the test result data of the embedded device is acquired in a dual-mode manner, ensuring continuous test execution and avoiding the time cost of repeated testing.

[0071] As a possible implementation of the application, Figure 4A specific implementation process of the device distributed testing method provided by the embodiment of the application is shown, and is described in detail as follows. B1: after the end of the test execution period, the operation of reconnecting the embedded device is performed. The test execution period refers to the time period from the issuance of the test execution instruction to the preset test completion time point. For example, after detecting the interruption of the device connection, the test server waits for a fixed time interval, and then initiates a reconnection request automatically by using the original connection parameters and protocol objects. If the connection fails, multiple attempts are made according to the exponential backoff strategy.

[0072] B2: after the communication connection is restored, the test result data is pulled from the predetermined storage path on the embedded device. The predetermined storage path is a predefined standardized file path. If the embedded device detects the interruption of the connection during the test execution process, the test result data is persistently stored in the predetermined storage path.

[0073] In a possible implementation, the test server sends a heartbeat packet to the connected embedded device to detect the communication connection state at regular time intervals. If the response of the embedded device is not received for a continuous specified number of times (for example, 3 times), it is determined that the communication connection is interrupted.

[0074] In a possible implementation, the test server activates a special result recovery module. The module reuses the connection configuration information of the protocol adaptation engine and the device, actively reconnects the device, and obtains the complete test result data from the predetermined storage path.

[0075] In the embodiment of the application, the reconnection is performed after the end of the test execution period, which can ensure the integrity of the test process, avoid the problem that the frequent initiation of the connection request occupies the device resources and interferes with the normal execution of the test program, reuse the existing connection parameters and protocol objects, save the process of reanalyzing the configuration file and creating the protocol object, shorten the time consumption of the reconnection, ensure that the connection parameters are consistent with the initial connection, reduce the risk of connection failure caused by parameter change, pull the result from the predetermined path, ensure that the test data of the interrupted device is not lost, and improve the reliability and efficiency of the result acquisition in the distributed test scenario.

[0076] Step S205: aggregate all the received test result data, and generate a test report.

[0077] In the embodiments of the present application, the aggregated test result data includes test result data of different embedded devices in this connection test, specifically including structured data returned by the embedded device in real time when the communication connection is normal and structured data recovered from the local storage of the disconnected embedded device by the test server after the communication connection is interrupted. The test server collects test result data from different embedded devices by aggregation, and uniformly arranges and stores these test result data, and generates a test report through a test result analysis and visualization tool.

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

[0079] As a possible implementation manner of the present application, Figure 5 A specific implementation process of the device distributed test method step S205 provided by the embodiments of the present application is shown, and is described in detail as follows: C1: Analyzing the aggregated test result data to identify the execution state of each test case in the test result data.

[0080] The test result data contains key information of each test case: test case unique identifier (case ID), execution timestamp, associated device model and architecture, detailed execution log, original state marker, etc. By analyzing the aggregated test result data, the execution state of each test case in the test result data is identified. The execution state of the test case includes pass, failure and skip.

[0081] C2: Generating a visual report containing test overview and case details based on the identified execution state of the test case.

[0082] The test overview presents the overall test situation, covering test task name, total number of devices participating in the test and type distribution, total number of cases, number and proportion of cases in each state, total test duration, etc. macro information; the case details are classified and displayed according to device type or test module, including execution log, execution duration, firmware version of associated device, etc. In a possible implementation manner, the failed cases are also labeled with error types.

[0083] Based on the identified execution state of the test case, combined with device information, execution duration, error log and other auxiliary information in the aggregated test result data, a visual report containing test overview and case details is generated, ensuring that the report content completely corresponds to the actual test result without missing key data.

[0084] In a possible implementation, the generated test report is a visual report. For example, the test server uses the test result processing capability of pytest and the data model of the allure report framework to centrally analyze, classify and count the collected result data, and automatically generates a structured allure test report based on the analyzed result data. The report provides visual information such as detailed test execution profiles, use case details, logs, screenshots (if any), and the like. For example, the report homepage is a test overview that displays test task names, total number of use cases, pass rate, test duration, and environment parameter summary. The report detail page displays the execution of each test case according to device grouping. Clicking on a failed use case allows viewing of complete logs and error screenshot links.

[0085] In a possible implementation, before generating the test report, the environment parameters during test execution are recorded; and the environment parameters are integrated into the test report. The environment parameters are key environmental information that affects the validity and reproducibility of test results during test execution.

[0086] In a possible implementation, the environment parameters include test server environment parameters, embedded device environment parameters, and dynamic environment parameters during test execution. The server environment parameters include the operating system version, test framework version, and database version of the test server. The embedded device environment parameters include the hardware architecture, device firmware version, and operating system version of the embedded device. The dynamic environment parameters during test execution include the test start time, test end time, network bandwidth during test, and serial communication baud rate. After analyzing the test result data, the test server generates a final test report according to the analysis result and all environment parameters corresponding to the current test task. The integration of environment parameters improves the traceability of the report, facilitating subsequent reproduction and analysis of problems.

[0087] As can be seen from the above, in the multi-protocol adaptation flexibility aspect, in the embodiment of the application, after receiving the test execution instruction, the test server first loads the connection parameters according to the predefined declarative configuration file, and establishes a connection with the plurality of embedded devices simultaneously. The declarative configuration mode does not need to modify the core code of the server to adapt to the connection requirements of different devices, avoiding the cumbersome operation of separately developing interfaces for each protocol in the traditional scheme, and can quickly compatible with the communication protocols of multiple types of embedded devices, providing a flexible adaptation basis for large-scale distributed concurrent testing. In terms of test program deployment efficiency, the test server sends a test execution instruction to the embedded devices that have established a connection, triggering the embedded devices to actively pull the test program from the central software package repository and execute it locally, replacing the traditional way of manually transferring or burning the test program, reducing the cost of manual intervention, while realizing the unified management and dynamic updating of the test program, especially adapting to the program iteration requirements in large-scale device testing scenarios, significantly improving the cross-device deployment efficiency. In terms of connection stability and result reliability, the test result data of the embedded device is obtained in a dual-mode manner, that is, when the communication connection is normal, the test result data returned by each embedded device in real time is received, ensuring the real-time of the test result in normal scenarios, and when the communication connection is interrupted, the result is actively obtained from the local storage of the embedded device after the communication connection is restored, completely avoiding the loss of test results caused by unstable connection, without the need to re-execute the complete test due to interruption, greatly reducing the time loss of large-scale testing. Finally, by aggregating all the test result data to generate a test report, the step of manually summarizing the scattered results is saved, realizing the automatic integration and standardized presentation of the test results, further improving the analysis efficiency of the test results. The scheme of the application can effectively balance the multi-protocol adaptation flexibility, test program deployment efficiency, connection stability and result reliability in the distributed concurrent automated testing of embedded devices, and significantly improve the overall testing efficiency in large-scale testing scenarios.

[0088] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the application.

[0089] Corresponding to the device distributed testing method described in the above embodiment, Figure 6 The structure block diagram of the device distributed testing apparatus provided by the embodiment of the application is shown, only the part related to the embodiment of the application is shown for the convenience of description.

[0090] Referring to Figure 6 The device distributed testing apparatus comprises an instruction receiving unit 61, a device connection unit 62, an instruction sending unit 63, a result obtaining unit 64, and a report generating unit 65, wherein: The instruction receiving unit 61 is configured to receive a test execution instruction. The device connection unit 62 is configured to dynamically load connection parameters of a plurality of embedded devices according to a predefined declarative configuration file, and establish connections with the plurality of embedded devices in parallel; The instruction sending unit 63 is configured to send test execution instructions to the embedded devices that have established connections, where the test execution instructions are used to trigger the corresponding embedded devices to pull test programs from a central software package repository and execute locally; The result obtaining unit 64 is configured to obtain test result data of the embedded devices in a dual-mode manner, including: when the communication connection with the embedded devices is normal, receiving test result data that is returned by each embedded device in real time, and when the communication connection with the embedded devices is interrupted, actively obtaining test result data from local storage of the embedded devices when the communication connection is restored; The report generating unit 65 is configured to aggregate all received test result data and generate a test report.

[0091] As a possible implementation of the present application, the device connection unit 62 is specifically configured to: Load the declarative configuration file, where the declarative configuration file dynamically defines connection protocol types and detailed parameters of each embedded device; Create corresponding protocol connection objects according to the connection protocol types and detailed parameters; Drive the created protocol connection objects to establish concurrent connections with the corresponding embedded devices based on a connection strategy in the declarative configuration file.

[0092] As a possible implementation of the present application, the central software package repository stores test program software packages customized for different device architectures; and the triggering of the corresponding embedded devices to pull test programs from the central software package repository includes: Triggering the embedded devices to call local software package management clients to pull and install corresponding test program software packages from the central software package repository.

[0093] As a possible implementation of the present application, the result obtaining unit 64 is specifically configured to: After a test execution period ends, reconnect the embedded devices; After the communication connection is restored, pull test result data from a predetermined storage path on the embedded devices.

[0094] As a possible implementation of the present application, the report generating unit 65 is specifically configured to: Parse the aggregated test result data to identify execution states of each test case in the test result data; Based on the identified execution status of the test cases, a visual report containing a test overview and case details is generated.

[0095] As a possible implementation of the present application, the report generation unit 65 is further configured to: record environment parameters at the time of test execution before generating the test report; integrate the environment parameters into the test report.

[0096] As can be seen from the above, in the embodiments of the present application, in terms of multi-protocol adaptation flexibility, after receiving the test execution instruction, the test server first dynamically loads the connection parameters according to the predefined declarative configuration file, and establishes a connection with the plurality of embedded devices simultaneously. This declarative configuration mode does not require modification of the core code of the server to adapt to the connection requirements of different devices, avoiding the cumbersome operation of separately developing interfaces for each protocol in the traditional scheme, and can quickly compatible with the communication protocols of multiple types of embedded devices, providing a flexible adaptation basis for large-scale distributed concurrent testing. In terms of test program deployment efficiency, the test server sends a test execution instruction to the embedded devices that have established a connection, triggering the embedded devices to actively pull the test program from the central software package repository and execute it locally, replacing the traditional method of manually transferring or burning the test program, reducing the cost of manual intervention, and at the same time realizing the unified management and dynamic updating of the test program, especially adapting to the program iteration requirements in large-scale device testing scenarios, significantly improving the cross-device deployment efficiency. In terms of connection stability and result reliability, the test result data of the embedded devices is obtained in a dual-mode manner, that is, when the communication connection is normal, the test result data is received in real time from each embedded device, ensuring the real-time performance of the test results in normal scenarios, and when the communication connection is interrupted, the results are actively obtained from the local storage of the embedded devices after the communication connection is restored, completely avoiding the loss of test results caused by unstable connection, without the need to re-execute the complete test due to interruption, greatly reducing the time loss of large-scale testing. Finally, by aggregating all the test result data to generate a test report, the step of manually summarizing the scattered results is saved, realizing the automatic integration and standardized presentation of the test results, and further improving the analysis efficiency of the test results. The present application scheme 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 the overall testing efficiency in large-scale testing scenarios.

[0097] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units, since based on the same concept as the method embodiments of the present application, the specific functions and the resulting technical effects can be referred to the method embodiments part, which will not be repeated here.

[0098] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of any one of the device distributed test methods shown in the above method embodiments. Figures 2 to 5 The steps of any one of the device distributed test methods shown in the above method embodiments.

[0099] The embodiment of the present application further provides a terminal device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of any one of the device distributed test methods shown in the above method embodiments when executing the computer program. Figures 2 to 5 The steps of any one of the device distributed test methods shown in the above method embodiments.

[0100] The embodiment of the present application further provides a computer program product, which, when executed on a terminal device, causes the terminal device to implement the steps of any one of the device distributed test methods shown in the above method embodiments. Figures 2 to 5 The steps of any one of the device distributed test methods shown in the above method embodiments.

[0101] Figure 7 is a schematic diagram of a terminal device provided by an embodiment of the present application. As shown in the figure, Figure 7 the terminal device 7 of the embodiment comprises a processor 70, a memory 71, and a computer program 72 stored in the memory 71 and executable on the processor 70. The processor 70 implements the steps of the device distributed test method embodiments described above when executing the computer program 72, for example, the steps S201 to S205 shown in the figure. Figure 2 Or, the processor 70 implements the functions of the modules / units in the above device embodiments when executing the computer program 72, for example, the functions of the instruction receiving unit 61 to the report generating unit 65 shown in the figure. Figure 6

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

[0103] The terminal device 7 can include, but is not limited to, the processor 70 and the memory 71. Those skilled in the art can understand that, Figure 7 is only an example of the terminal device 7 and does not constitute a limitation on the terminal device 7, and can include more or fewer components than the illustration, or combine certain components, or different components, for example, the terminal device 7 can also include an input / output device, a network access device, a bus, etc.

[0104] ​The processor 70 can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0105] The memory 71 can be an internal storage unit of the terminal device 7, such as a hard disk or a 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, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. Further, the memory 71 can also include both the internal storage unit and the external storage device 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.

[0106] It should be noted that the information interaction, execution process, etc. between the above apparatuses / units, since based on the same concept as the method embodiments of the present application, the specific functions and the brought technical effects can be referred to the method embodiments part, and will not be repeated here.

[0107] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is exemplified, and in actual application, the above-mentioned functions can be completed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiments can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit, and the integrated unit can be realized in the form of hardware or in the form of software function unit. In addition, the specific names of each functional unit and module are only for easy distinction, and do not limit the protection scope of the present application. The specific working process of the unit and module in the system can refer to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0108] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the present application can implement all or part of the processes in the above-mentioned embodiment methods, which can be completed by instructing related hardware through a computer program. The computer program can be stored in a computer readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by a processor. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium at least includes any entity or device capable of carrying the computer program code to the device / terminal equipment, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium. For example, U disk, mobile hard disk, magnetic disk or optical disk, etc. In some jurisdictions, according to legislation and patent practice, the computer readable medium cannot be an electrical carrier signal and a telecommunication signal.

[0109] In the above embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0110] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A device distributed testing method, characterized by, The application is applied to a test server, and comprises the following steps: receiving a test execution instruction; loading connection parameters of a plurality of embedded devices according to a predefined declarative configuration file, and establishing connections with the plurality of embedded devices in parallel; sending a test execution instruction to the embedded devices with which the connections have been established, the test execution instruction being used to trigger the corresponding embedded devices to pull a test program from a central software package warehouse and execute it locally; obtaining test result data of the embedded devices in a dual-mode manner, including receiving test result data returned by the embedded devices in real time when a communication connection with the embedded devices is normal, and actively obtaining test result data from local storage of the embedded devices when the communication connection with the embedded devices is interrupted and the communication connection is restored; aggregating all the received test result data and generating a test report.

2. The method of claim 1, wherein, The step of loading connection parameters of a plurality of embedded devices according to a predefined declarative configuration file and establishing connections with the plurality of embedded devices in parallel comprises the following steps: loading the declarative configuration file, the declarative configuration file dynamically defining a connection protocol type and detailed parameters of each embedded device; creating a corresponding protocol connection object according to the connection protocol type and detailed parameters; driving the created protocol connection object to establish a concurrent connection with the corresponding embedded device based on a connection strategy in the declarative configuration file.

3. The method of claim 1, wherein, The central software package warehouse stores test program software packages customized for different device architectures. The step of triggering the corresponding embedded devices to pull a test program from a central software package warehouse comprises the following steps: triggering the embedded devices to call a local software package management client thereof to pull and install a corresponding test program software package from the central software package warehouse.

4. The method of claim 1, wherein, The step of actively obtaining test result data from local storage of the embedded devices comprises the following steps: performing an operation of reconnecting the embedded devices after a test execution period ends; pulling test result data from a predetermined storage path on the embedded devices after the communication connection is restored.

5. The method of claim 1, wherein, The step of generating a test report comprises the following steps: analyzing aggregated test result data to identify an execution state of each test case in the test result data; generating a visual report containing a test overview and case details based on the identified execution state of the test case.

6. The method according to any one of claims 1 to 5, characterized in that, Before generating a test report, environmental parameters during test execution are recorded. The environmental parameters are integrated into the test report.

7. A device distributed test system, characterized by, The application comprises a test server and a plurality of embedded devices, and wherein: the test server is used to receive a test execution instruction, load connection parameters of a plurality of embedded devices according to a predefined declarative configuration file, establish connections with the plurality of embedded devices in parallel, send a test execution instruction to the embedded devices with which the connections have been established, obtain test result data of the embedded devices in a dual-mode manner, aggregate all the received test result data, and generate a test report. The embedded device is configured to receive a test execution instruction from the test server, pull a test program from a central software package warehouse and perform locally in response to the test execution instruction, and transmit test result data to the test server in real time when a communication connection with the embedded device is normal during test execution, and store the test result data locally when the communication connection with the embedded device is interrupted, and allow the test server to actively acquire the test result data stored locally after the communication connection is restored.

8. A device distributed test apparatus, characterized by, The application is applied to a test server, and comprises: An instruction receiving unit is configured to receive a test execution instruction. A device connection unit is configured to dynamically load connection parameters of a plurality of embedded devices according to a predefined declarative configuration file, and establish connections with the plurality of embedded devices in parallel. An instruction sending unit is configured to send a test execution instruction to the embedded devices that have established connections, and the test execution instruction is used to trigger the corresponding embedded devices to pull a test program from a central software package warehouse and perform locally. A result acquiring unit is configured to acquire test result data of the embedded devices in a dual-mode manner, including receiving test result data transmitted in real time by each embedded device when a communication connection with the embedded device is normal, and actively acquiring test result data from local storage of the embedded device when the communication connection with the embedded device is interrupted and the communication connection is restored. A report generating unit is configured to aggregate all received test result data and generate a test report.

9. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the device distributed test method of any one of claims 1 to 6.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the device distributed test method of any one of claims 1 to 6.

Images