A multi-device parallel production and measurement control method and device, equipment and storage medium

Abstract

The application provides a kind of multi-device parallel production test control method and device, equipment and storage medium, belong to industrial automation test technical field.The method comprises: according to the test configuration information of current batch test, the tool active test item chain table and device self-test item set commonly used to each device under test are generated;After establishing communication connection with multiple devices under test, each tool active test item is sequentially executed, and the device self-test item set is issued to each device under test to execute device self-test and report self-test result asynchronously;In response to a preset trigger event, a unified completion judgment result is obtained by executing unified completion judgment;When the current batch test meets the test end condition, the unreported self-test item of each device under test is determined according to the device self-test item set and the reported self-test item set of each device under test, and the state compensation of the test result of unreported self-test item is carried out.The embodiments of the application can improve the accuracy of multi-device parallel test process and the integrity of test result.

Description

Technical Field

[0001] This application relates to the field of industrial automation testing technology, and in particular to a multi-device parallel production testing control method, apparatus, equipment, and storage medium. Background Technology

[0002] In industrial production lines, testing tools typically need to perform production tests on multiple devices simultaneously. The testing process usually includes two types of tasks: one type is test items actively controlled by the PC-based testing tool, and the other type is device self-test items executed autonomously by the devices themselves, with results periodically reported. Current technology, when performing parallel production testing on multiple devices, usually involves the testing tool sequentially executing the PC-based active test items and the device self-test items using a single main thread or simple multi-threading. The device self-test results are periodically reported back to the PC, which receives and parses the reported data in real time to update the test status of the corresponding device. After the testing process is complete, a test report is generated based on the received reported results.

[0003] However, since the tool's proactive test items and the device's self-test items are intertwined in the same execution process, the PC needs to frequently interrupt the current test to handle the asynchronous reports from the devices. Moreover, the asynchronous reports from multiple devices are submitted at different times, making it difficult for the system to accurately determine whether all test items for all devices have been completed. This can easily lead to premature termination or indefinite waiting, affecting the accuracy of the multi-device parallel testing process and thus the completeness of the test results. Summary of the Invention

[0004] The main objective of this application is to propose a multi-device parallel production test control method, apparatus, device, and storage medium, which can improve the accuracy of the multi-device parallel test process and thus improve the completeness of the test results.

[0005] To achieve the above objectives, a first aspect of this application proposes a multi-device parallel production and testing control method, the method comprising: Obtain the test configuration information for the current batch of tests, and generate a tool active test necklace list and a device self-test item set shared by all devices under test in the current batch of tests based on the test configuration information. The tool active test necklace list contains multiple tool active test items arranged in a preset execution order, and the device self-test item set contains multiple device self-test items executed and reported by the device under test. After establishing a communication connection with multiple devices under test, the active test items of the tool in the active test necklace list are executed sequentially, and the set of device self-test items is sent to each device under test so that each device under test can perform device self-test and asynchronously report self-test results; In response to a preset trigger event in the testing process, a unified completion judgment operation is performed to obtain a unified completion judgment result. The unified completion judgment operation is used to determine whether the current batch of tests meets the test termination conditions or does not meet the test termination conditions. When the unified completion judgment result indicates that the current batch of tests meets the test end conditions, the unreported self-test items of each device under test are determined according to the difference between the set of self-test items of the device and the set of self-test items reported by each device under test, and the test results of the unreported self-test items are compensated for.

[0006] To achieve the above objectives, a second aspect of this application provides a multi-device parallel production and testing control device, the device comprising: The collection construction module is used to obtain the test configuration information of the current batch of tests, and generate a tool active test necklace list and a device self-test item set shared by each device under test in the current batch of tests based on the test configuration information. The tool active test necklace list contains multiple tool active test items arranged in a preset execution order, and the device self-test item set contains multiple device self-test items executed and reported by the device under test. The test item execution module is used to establish a communication connection with multiple devices under test, execute each of the tool active test items in the tool active test necklace list in sequence, and send the device self-test item set to each device under test so that each device under test can perform device self-test and asynchronously report self-test results; The judgment module is used to respond to preset trigger events in the test process, perform a unified completion judgment operation, and obtain a unified completion judgment result. The unified completion judgment operation is used to determine whether the current batch of tests meets the test end conditions or does not meet the test end conditions. The status compensation module is used to determine the unreported self-test items of each device under test based on the difference between the set of self-test items of the device and the set of self-test items reported by each device under test when the unified completion judgment result indicates that the current batch of tests meets the test end conditions, and to perform status compensation on the test results of the unreported self-test items.

[0007] To achieve the above objectives, a third aspect of the present application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in any one of the embodiments of the first aspect.

[0008] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of the embodiments of the first aspect.

[0009] The multi-device parallel production testing control method, apparatus, device, and storage medium proposed in this application eliminate the frequent interruptions and state management difficulties caused by the interleaved execution of the two types of tests in traditional solutions by splitting the test process into two parallel paths: tool-initiated test chain execution and device self-test asynchronous reporting. This makes the main test process logic clear and controllable. By unifying the judgment operation, the system can accurately determine the test end time in complex scenarios of multi-device asynchronous reporting, avoiding missed tests due to premature termination and process deadlock due to infinite waiting, thus improving the determinism of the test process. Through the incomplete item compensation mechanism based on difference set, the system performs state compensation for the test results of unreported self-test items at the end of the test, fundamentally eliminating the problem of missing results in the test report and ensuring the integrity and availability of test result data. Therefore, this application embodiment constructs a complete closed-loop control process from configuration generation to result completion, which can effectively improve the accuracy of multi-device parallel testing processes in the field of multi-device parallel production testing, thereby improving the integrity of test results. Attached Figure Description

[0010] Figure 1 This is a flowchart of a multi-device parallel production measurement control method provided in an embodiment of this application; Figure 2 This is the first flowchart of the sequential execution of the active test items of the tools provided in the embodiments of this application; Figure 3 yes Figure 2 A flowchart of step S220 in the process; Figure 4 This is the second flowchart of the multi-device parallel production and testing control method provided in the embodiments of this application; Figure 5 This is the third flowchart of the multi-device parallel production and testing control method provided in the embodiments of this application; Figure 6 yes Figure 1 A flowchart of step S130 in the process; Figure 7 This is a schematic diagram of a multi-device parallel production and testing control device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0012] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., used in the specification, claims, and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0013] In industrial production lines, testing tools typically need to perform production tests on multiple devices simultaneously. The testing process usually includes two types of test tasks: one type is test items actively controlled by the PC-based testing tools, such as device login, device type acquisition, system version acquisition, video stream detection, image detection, SN verification, unique ID acquisition, current testing, LED testing, time calibration, channel switching, etc.; the other type is device self-test items executed automatically by the device itself and periodically reporting the results, such as WiFi testing, 4G testing, GPIO testing, audio testing, SD card testing, USB testing, FPC testing, adapter testing, charging function testing, discharging function testing, battery level detection, battery voltage detection, and battery temperature detection, etc.

[0014] In existing technologies, when performing parallel production testing on multiple devices, active test items from the PC and self-test items from the device are typically integrated into the same test flow. These are executed sequentially using a single main thread or a simple multi-threaded approach. Device self-test results are periodically reported back to the PC, which receives and parses the reported data in real time to update the test status of the corresponding device. After the test flow is completed, a test report is generated based on the received reports.

[0015] However, the existing solutions described above have at least the following technical problems in multi-device parallel testing scenarios: (1) Coupling of process control leads to low execution efficiency and difficulty in state management. The existing solution intertwines the tool's active test items and the device's self-test items in the same execution process. When the PC executes the active test items, it needs to be frequently interrupted to handle the asynchronous reporting of the device, which makes process management complicated. At the same time, the reporting time of the self-test results reported by multiple devices is different. It is difficult for the system to accurately determine whether all test items of all devices have been completed, which can easily lead to premature termination or infinite waiting.

[0016] (2) Duplicate data reporting leads to resource waste and result contamination. The device adopts a periodic reporting mechanism, and the test results of the same test item may be carried repeatedly in multiple rounds of reporting. The existing solution lacks effective deduplication processing, and performs parsing and result refresh operations for each report, which not only wastes computing resources, but may also lead to the final test results being overwritten by old data or duplicated statistics.

[0017] (3) Lack of a complete timeout protection mechanism in abnormal scenarios. When a device fails to report data for a long time due to faults, communication interruptions, or other reasons, the existing system may fall into an infinite waiting state. At the same time, there is a lack of unified coordination and management among global test timeout, single device reporting timeout, and single test item execution timeout. The timeout protection at each level is independent or even missing, which makes the system behavior unpredictable in abnormal scenarios.

[0018] (4) Asynchronous tasks cannot be effectively included in the final completion judgment. For time-consuming operations such as 4G card query and Bluetooth search, if the existing solution is executed synchronously, it will block the main process. If it is executed asynchronously, the result is difficult to be included in the comprehensive judgment logic of test completion, which is prone to the problem of timing disorder when the main process has ended but the asynchronous task has not yet been completed.

[0019] (5) Incomplete test results. When a test is forcibly terminated due to timeout or anomaly, some self-test items of some devices may not have been reported. The existing solution does not handle this situation in special way, and the final test report may contain "not tested" or missing result items, making it impossible to distinguish between the two states of "device did not perform test" and "device performed test but failed".

[0020] (6) Hard-coded test procedures lead to high maintenance costs. The test procedures for different board types, work orders and fixture types are different. Existing solutions usually write the test procedures into the test program in a hard-coded manner. Every time the procedure is changed, the code needs to be modified, recompiled and deployed, which results in high maintenance costs and is easy to introduce new defects.

[0021] Therefore, there is an urgent need to propose a multi-device parallel production test control scheme that can decouple and execute tool-based proactive testing and equipment self-testing in parallel, and has the ability to make unified completion judgments, prevent duplicate processing, provide multi-level timeout protection, and compensate for incomplete items.

[0022] Based on this, embodiments of this application provide a multi-device parallel production test control method and apparatus, device and storage medium, which can improve the accuracy of the multi-device parallel test process, thereby improving the completeness of the test results.

[0023] This application's embodiments can acquire and process relevant data based on artificial intelligence (AI) technology. AI is the theory, methods, technology, and application system that uses digital computers or computers-controlled machines to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results. Basic AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing technology, operating / interactive systems, and mechatronics. AI software technologies mainly include computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0024] The multi-device parallel production testing control method provided in this application relates to the field of industrial automation testing technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms; the software can be an application implementing the multi-device parallel production testing control method, but is not limited to the above forms.

[0025] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network personal computers (PCs), minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0026] Please see Figure 1 , Figure 1 This is a flowchart of a multi-device parallel production and testing control method provided in an embodiment of this application. In some embodiments of this application, Figure 1 The method described below may include, but is not limited to, steps S110 to S140. Figure 1 These four steps will be explained in detail.

[0027] Step S110: Obtain the test configuration information for the current batch of tests, and generate a tool active test necklace list and a device self-test item set shared by all devices under test in the current batch of tests based on the test configuration information. The tool active test necklace list contains multiple tool active test items arranged in a preset execution order, and the device self-test item set contains multiple device self-test items executed and reported by the device under test. Step S120: After establishing a communication connection with multiple devices under test, execute each tool active test item in the tool active test necklace list in sequence, and send the device self-test item set to each device under test so that each device under test can perform device self-test and asynchronously report self-test results. Step S130: In response to the preset trigger event in the test process, perform a unified completion judgment operation to obtain a unified completion judgment result; Step S140: When the unified completion judgment result indicates that the current batch of tests meets the test end conditions, the unreported self-test items of each device under test are determined according to the difference between the set of self-test items of the equipment and the set of self-test items reported by each device under test, and the test results of the unreported self-test items are compensated for.

[0028] In step S110 of some embodiments, the current batch test refers to a complete execution instance of a production test task. In actual production lines, test fixtures typically contain multiple workstations (e.g., 8, 12, or 16 workstations). Each batch of tests can simultaneously connect to multiple devices under test, and these devices are uniformly controlled by the same test tool instance within the same time period, constituting a batch. Test configuration information refers to a set of data describing which test items should be executed in the current batch of tests, in what order, and the parameters of each test. Test configuration information can be stored on the PC in the form of configuration files or database records. The configuration information includes at least key fields such as board type identifier, work order identifier, and fixture type, and may also include parameters such as timeout threshold, number of retries, and whether to force execution for each test item. The tool-initiated test chain refers to an ordered execution sequence of test items actively initiated and controlled by the PC-side test tool. This chain is implemented in the form of a linked list in data structures. Each test item in the tool-initiated test chain is encapsulated as an independent node object, and the nodes are linked through pointers or references to form a linked storage structure. The order of the linked list determines the execution order of the test items. Unlike ordinary arrays or lists, linked lists allow for the dynamic insertion of new nodes during execution without rebuilding the entire sequence. Tool-initiated test items include, but are not limited to: device login, obtaining device type, obtaining system version, video stream detection, image detection, SN verification, unique ID acquisition, current testing, LED testing, time calibration, channel switching, etc., which are initiated by the PC and await responses. The preset execution order refers to the order in which the tool-initiated test items are executed. This order is specified by the order field in the test configuration information or can be automatically determined based on the dependencies between test items. For example, device login must be executed before obtaining device type and system version, and image detection typically needs to be executed after login is complete and video stream is successfully acquired. The preset execution order ensures the correct execution sequence between dependent test items.

[0029] A device self-test set refers to a collection of test items that need to be executed by the device under test (DUT) itself, rather than initiated by the PC. Device self-test items are stored in a set data structure. The elements in the set do not need to be ordered, as the device may execute multiple self-test items in parallel; the reporting order is irrelevant to the execution order. Device self-test items include, but are not limited to: WiFi detection, 4G detection, General Purpose Input / Output (GPIO) detection, audio detection, SD card detection, USB detection, Flexible Printed Circuit Board (FPC) detection, adapter detection, charging function detection, discharging function detection, battery level detection, battery voltage detection, and battery temperature detection—tests that are executed by the device itself and whose results are reported back periodically.

[0030] In some specific embodiments, the step of generating a tool active test necklace table and a set of device self-test items shared by all devices under test in the current batch of tests based on the test configuration information may include, but is not limited to, the following steps: Read board type identification information and work order identification information from the test configuration information; Based on the board type identification information and work order identification information, an initial test item list is obtained by matching from the pre-configured test item mapping table. The initial test item list includes combined test items, tool active test items, and equipment self-test items. For combined test items, the combined test items are broken down into multiple sub-test items, and the sub-test items are used as device self-test items; All tool active test items are arranged in a preset order to obtain a tool active test necklace table, and a device self-test item set is constructed based on all device self-test items.

[0031] The board type identification information is a code representing the model or product model of the hardware circuit board of the device under test (DUT). This information is typically encoded in the device's barcode or QR code, and is entered into the system by the operator after scanning it with a barcode scanner. The board type identification information determines which test items should be performed. Different board types have different hardware configurations (e.g., some board types support 4G modules, while others do not), resulting in different test item lists. The work order identification information is a code representing the order number of the current production batch. It is used to distinguish test tasks from different batches and to trace the correspondence between test results and production orders. The same board type may execute different subsets of test items under different work orders; for example, a day shift work order may perform full testing, while a night shift work order may only perform sampling testing. The pre-configured test item mapping table is a mapping table pre-stored in a configuration file or database, used to retrieve the corresponding test item list based on the board type identification and work order identification. The test item mapping table can be pre-established by test engineers based on product specifications and maintenance experience during system deployment or test process design, rather than being dynamically generated at runtime. The test item mapping table supports flexible updates. When a product is upgraded and new test items are added, you only need to modify the test item list for the corresponding board type in the mapping table, without changing the core test program.

[0032] A combined test item refers to a test project that logically comprises multiple sub-functions. At the business semantic level, it is considered a whole; however, at the test implementation level, it contains multiple atomic sub-test items that can be executed, judged, and recorded independently. For example, power management testing is a combined test item. Logically, it represents that the device's power management function is normal, but in actual testing, it needs to test multiple independent sub-items such as adapter insertion detection, charging function, discharging function, power reading, battery voltage measurement, and battery temperature measurement. The division of combined test items depends on business semantics, not technical implementation. As long as a test item is defined as a whole in the requirements document, even if it contains multiple sub-test steps, it is considered a combined test item. A sub-test item is the smallest test unit that is independently executable and judgeable, extracted from a combined test item. The extracted sub-test items are completely consistent with ordinary device self-test items in terms of data structure, also having a name, execution logic (executed by the device), test status (pass / fail), and corresponding result processing function. For example, power management testing can be broken down into six sub-test items: adapter testing, charging function, discharging function, power level detection, battery voltage, and battery temperature. Each sub-test item exists as an independent element in the device's self-test item set. After the breakdown, the original combined test items no longer participate in the testing process as independent test items.

[0033] Understandably, this application embodiment can read board type identification information and work order identification information from the test configuration information. This information can come from manual input by the operator, barcode scanning by a barcode scanner, or automatic acquisition from the MES system. Using the board type identification information and work order identification information as a joint index, a matching search is performed in the pre-configured test item mapping table to obtain an initial test item list. The initial test item list contains combined test items, tool-initiated test items, and device self-test items. The initial test item list is traversed, and a splitting operation is performed on each identified combined test item. The basic basis for the splitting operation is a predefined splitting rule table, replacing the combined test item with its corresponding set of sub-test items. These sub-test items are added to the device self-test item queue as device self-test items. The original combined test item itself is removed from the test item list and no longer exists as an independent execution or reporting item. Furthermore, all tool-initiated test items (tool-initiated test items in the initial list plus non-combined device self-test items) are arranged in a preset order to construct a tool-initiated test item chain table. The system incorporates all device self-test items (device self-test items in the initial list plus atomic sub-test items generated by splitting) into the device self-test item set.

[0034] In the above embodiments, this application, through a configurable test item generation mechanism, transforms the switching of test processes for different board types and work orders from modifying code and redeploying to modifying configuration files or mapping table entries, thereby reducing the technical threshold and maintenance costs of test process changes. Simultaneously, the decomposition of combined test items refines the collection and statistics of test results from the combined level to the atomic sub-item level, effectively improving the accuracy of multi-device parallel testing processes and thus enhancing the completeness of test results.

[0035] In step S120 of some embodiments, sequential execution refers to the process where the PC executes each test item sequentially from front to back according to the node arrangement order of the tool's proactive test chain. Sequential execution is the opposite of parallel execution. At any given time, the PC executes only one proactive test item, and only proceeds to the next item after the current test item is completed. This sequentiality ensures that test items with sequential dependencies will not fail or produce abnormal results due to disordered execution timing. It should be noted that sequential execution here only refers to the sequential relationship between proactive test items and does not affect the parallel execution characteristic of device self-test items on the device. Asynchronous reporting refers to the process where, after completing a self-test item, the device under test does not wait for the PC to actively query or request it, but instead actively sends the test results to the PC in the form of a message. The timing of asynchronous reporting is determined by the device itself. The device can report immediately after each self-test item is completed, or it can report periodically at fixed time intervals, or it can report uniformly after all self-test items are completed. After the PC issues the self-test command, it continues to execute other tasks (such as the next tool's active test item). The device's result reporting and the PC's main process are parallel but asynchronous in time.

[0036] It is understood that the test control system of this application embodiment can establish communication connections with multiple devices under test (DUTs). The method of establishing the communication connection depends on the communication interface type of the DUT. For example, for devices with network interfaces, a connection can be established through the TCP / IP protocol; for devices with serial ports, a connection can be established through RS232 or RS485. In actual production lines, Ethernet or Wi-Fi connections are typically used. Each DUT automatically registers with the PC and obtains an IP address after startup. After the connection is established, the system executes each test item in the tool's active test necklace list sequentially, starting from the head node of the list, executing the test action encapsulated in the current node, and advancing to the next node through a callback mechanism after completion, until all nodes have been executed. During sequential execution, the PC sends test instructions to the device, waits for and receives the response from the device, determines whether the test has passed or failed based on the response, and records the test results. At the same time, the system issues the set of device self-test items to each DUT in the form of instructions. This issuance action can be executed immediately after the device successfully logs in, or it can be executed in the early stages of the tool's active test necklace list execution. After receiving the self-test instructions, the device automatically performs each self-test and periodically reports the results back to the PC. The system does not block and wait for the device's self-test results while executing the tool's proactive tests.

[0037] Please see Figure 2 , Figure 2 This is a flowchart illustrating the sequential execution of various tool active test items provided in the embodiments of this application. In some embodiments of this application, the steps for sequentially executing each tool active test item in the tool active test necklace table may include, but are not limited to, the following steps: Step S210: Determine the head node of the necklace table actively tested by the tool as the current execution node, and execute the test action encapsulated by the current execution node to obtain the test execution result. The test action includes execution logic and callback processing function. Step S220: Call the callback processing function to determine the next node to be executed in the sequence of active test items of the tool, and update the current execution node to the next node to be executed; Step S230: Execute the updated test action encapsulated in the next currently executing node to obtain the test execution result, until all nodes in the tool's active test item sequence have been executed or the termination condition is met.

[0038] In step S210 of some embodiments, in the linked list data structure, the head node refers to the first node in the linked list. In the tool active test linked list, the head node encapsulates the first tool active test item to be executed. During the execution of the linked list state machine, the node currently executing a test action is called the current execution node. In this embodiment, the current execution node can be identified by maintaining a pointer or reference to a linked list node. At the start of execution, the pointer points to the head node; each time execution progresses to the next node, the pointer is updated to point to the next node. The current execution node clearly indicates which test stage the test process is currently in. A test action refers to an executable operation unit encapsulated in a linked list node. Each test action is a self-contained execution unit containing all the elements required to execute a complete tool active test item. Test actions are implemented as objects, function closures, or callable classes. A test action includes two parts: execution logic and callback handling functions. When a test action is executed, the PC sends the corresponding test command to the device under test, waits for the device to return a response, determines whether the test passes based on the response, and records the test result. Test actions can also include retry logic and exception handling logic (such as how to handle timeouts). Execution logic is the core functional code of a test action, defining what the test item does and how it does it. Execution logic includes the communication protocol between the PC and the device under test, the assembly method of test instructions, the parsing method of response messages, and the rules for determining whether the test passes or fails.

[0039] In step S220 of some embodiments, the callback function is a function called after the test action is completed. It processes the execution result of the test action and determines the next step in the test process. The callback function receives the test execution result (pass / fail and specific data) as input parameters. Then, it determines the next node to be executed in the linked list based on the test execution result. In simple scenarios (without dynamic insertion), the callback function directly returns the next node of the current node (i.e., the next item in the original linked list order). In scenarios requiring dynamic insertion, the callback function can determine whether a new test item needs to be inserted based on the execution result before returning the next node. If so, it modifies the linked list structure before determining the next node. The callback function can also perform auxiliary operations related to the test result, such as writing the test result to a log or updating the interface display. It should be noted that when the test action is encapsulated, its execution logic and callback function are encapsulated together, making each test item node a self-contained execution unit. A node to be executed refers to the next linked list node to be executed and processed by the state machine after the current execution node is completed. Determining the node to be executed is the core output of the callback function. The callback function passes the information of the node to be executed to the main loop of the state machine via a return value or reference, and the state machine updates the pointer to the currently executing node accordingly. In normal sequential execution without dynamic insertion, the node to be executed is the next node after the current node (i.e., the node pointed to by the `next` pointer in the linked list). In a dynamic insertion scenario, the node to be executed may be a newly inserted node (if the new node is inserted after the current node and before the original next node), or it may remain the original next node (if no new node has been inserted or the new node has been processed in an earlier stage).

[0040] In step S230 of some embodiments, the termination condition refers to a special situation that causes the early termination of the linked list execution. The termination condition differs from normal completion (the next pointer of the tail node in the linked list is null); it is an early termination triggered by abnormal or special circumstances. Termination conditions include, but are not limited to: global total test timeout (the entire batch test time exceeds a preset limit), user-manual termination (operator clicks the stop button), and fatal errors (such as a complete interruption of communication between the PC and all devices). When the termination condition is met, the linked list state machine stops advancing nodes, ceases executing remaining unexecuted test items, and the test process jumps directly from the execution phase to the completion judgment phase.

[0041] Understandably, before sequential execution begins, the linked list state machine needs to determine which node to start from. The head node typically encapsulates the first proactive test item to be executed in the test process. When the user triggers test initiation, the system automatically performs this initialization operation. After determining the current execution node, the system enters an execution loop, executing the test actions encapsulated in the current execution node, i.e., sending specific instructions to the device under test, receiving responses, determining pass / fail based on the responses, and recording the results to obtain the test execution result. The test execution result includes whether the test passed and key data generated during the test. After the test actions of the current execution node are completed, the system calls a callback function. The callback function receives the test execution result as a parameter and determines the next node to be executed in the proactive test linked list based on the result. The updated test actions encapsulated in the current execution node are then executed again to obtain a new test execution result, and the above process is repeated. When the loop terminates, it indicates that the proactive test process has been completed or has been forcibly terminated, and the system subsequently triggers a unified completion judgment operation.

[0042] Please see Figure 3 , Figure 3 This is a flowchart of step S220 provided in an embodiment of this application. In some embodiments of this application, step S220 may specifically include, but is not limited to, the following steps: Step S310: Obtain the device type information and process status information of the current test phase of the device under test; Step S320: Based on the test execution results, device type information and process status information, perform new test item detection to determine whether it is necessary to insert new test items into the tool's active test necklace table; Step S330: If it is necessary to insert a new test item into the tool's active test necklace table, insert the generated new test item node between the current execution node and the next node to be executed, and update the node link relationship of the tool's active test necklace table. Step S340: Call the callback processing function to determine the next node to be executed in the tool's active test necklace table based on the updated node link relationship.

[0043] In step S310 of some embodiments, device type information refers to data describing the classification attributes of the device under test, such as model, board type, and hardware version. Device type information is obtained during the device login phase by reading device registers or querying device type commands. Device type information includes, but is not limited to: board name, product series, hardware version number, firmware version number, and a list of supported hardware modules. Process status information refers to data describing the current execution stage of the test process, the current test node, and the contextual position of that node within the entire test process. Process status information includes, but is not limited to: the name or identifier of the current execution node, the index of the current execution node in the linked list, a list of completed test items, and the current process stage identifier. Device type information describes what the object being tested is, while process status information describes which step the test process has reached. Using them together allows for precise determination of whether a new test item should be inserted at the current position.

[0044] In step S320 of some embodiments, the addition of a test item detection is a decision-making process used to determine whether an additional test item needs to be inserted into the tool's active test chain table after the current test node is completed and before the next test node is executed. The detection process makes a logical judgment based on three input parameters: the execution result of the current test node (success / failure and specific value), the device type information of the current device under test, and the process status information of the current test phase. The detection rules can be predefined in the configuration file or hard-coded in the callback handling function. The detection result is one of two values: whether insertion is needed or not.

[0045] In step S330 of some embodiments, the newly added test item node refers to a linked list node that is dynamically generated at runtime and encapsulates the newly added test action. The newly added test item node is completely identical in data structure to the original static nodes in the linked list, also containing execution logic and callback processing functions, and also participating in the advancement process of the linked list state machine as an executable unit. The newly added test item node can be generated by copying and instantiating it from a preset test item template library based on the detection results, or it can be dynamically created through a factory function. Multiple newly added test items may be inserted simultaneously in a single detection, such as inserting channel switching first, and then inserting image re-inspection after channel switching.

[0046] Node linking refers to the pointing relationships established between nodes in a linked list through pointers or references. In a singly linked list, each node contains a pointer to the next node (usually named the `next` pointer), and the value of this pointer determines the order in which the linked list is traversed. Node linking determines the execution order of test items. Starting from the node pointed to by the `next` pointer of the currently executing node, the state machine traverses the pointer chain sequentially. When inserting a new test item node, the node linking needs to be updated: the `next` pointer of the currently executing node is modified to point to the first newly added node, and the `next` pointer of the last newly added node is modified to point to the original next node, thus achieving the effect that the new node is executed after the current node and before the original next node.

[0047] It should be noted that if it is determined that no new test item needs to be inserted, the node generation and insertion operations are skipped, and the node link relationships remain unchanged. Regardless of whether insertion is performed, the system eventually needs to determine the next node to be executed so that the state machine can continue to advance.

[0048] In step S340 of some embodiments, after the insertion operation is completed, the system calls a callback function, which determines the next node to be executed based on the updated or unchanged node link relationship. Specifically, the callback function returns the node pointed to by the next pointer of the currently executing node. If a new node has been inserted, the next pointer points to the first newly added node, so the newly added node becomes the next node to be executed. If no new node has been inserted, the next pointer points to the original next node, and the execution process proceeds normally. In actual production line testing, the dynamic insertion mechanism can be used in various scenarios: if a channel needs to be switched after image detection (e.g., to check if the multi-channel video input of the device is normal), a channel switching test item is inserted after the first image detection is completed, and an image re-inspection test item is inserted after the channel switching is completed to verify whether the second image is normal. For example, to test whether the device has Bluetooth capability, the device can simultaneously insert a test item to check whether it has channel switching (dual-camera) capability to perform channel switching testing, reducing the complexity of manual configuration.

[0049] In the above embodiments, this application introduces a runtime dynamic insertion mechanism, enabling the tool to proactively adjust the execution path of the test necklace table based on the actual results and states during the testing process. This dynamism overcomes the limitations of traditional hard-coded processes where the test path is fixed and subsequent tests cannot be adjusted based on intermediate results. It eliminates the need to write and maintain a separate set of test process code for each scenario, greatly improving the flexibility and maintainability of the test process.

[0050] Please see Figure 4 , Figure 4This is another flowchart of the multi-device parallel production test control method provided in this application embodiment. In some embodiments of this application, after the set of device self-test items is distributed to each device under test so that each device under test can perform device self-test and asynchronously report self-test results, the multi-device parallel production test control method provided in this application embodiment may further include, but is not limited to, the following steps: Step S410: Maintain a corresponding device context for each logged-in device under test. The device context includes device identification information, a set of parsed self-test items, and a device self-test completion flag. Step S420: Receive self-test result messages periodically reported by each device under test, and determine the corresponding device context based on the device identification information carried in the self-test result messages; Step S430: Parse multiple device self-test items and the test status of each device self-test item from the self-test result message; Step S440: Match the parsed self-test items of each device based on the parsed self-test item set, determine the reporting status of each parsed self-test item, and update the parsed self-test item set based on the reporting status. Step S450: After all device self-test items of each device under test have been recorded to the corresponding parsed self-test item set, the device self-test completion flag of the device context is set to the completed state.

[0051] In step S410 of some embodiments, the device context is an independent data container maintained by the PC for each logged-in device under test, used to store all status information and intermediate data of the device throughout the entire testing process. The maintenance of the device context spans the entire test lifecycle, from creation and initialization upon successful device login, to continuous updates during the test, and finally to persistent storage or archiving at the end of the test. The device context includes device identification information, a set of parsed self-test items, a device self-test completion flag (used to indicate whether the device has completed all self-tests), as well as device login status, device model information, execution results of each test item, handles or references to communication connections, etc. The device context is created after successful device login and destroyed or archived at the end of the test.

[0052] Device identification information is a data field that uniquely distinguishes different devices under test (DUTs). It can be the device's MAC address, IP address, serial number, QR code scan result, workstation number, etc. The parsed self-test item set is a field in the device context used to record the set of all device self-test items that the device has successfully parsed and processed. The parsed self-test item set is empty when the device context is initialized. As the device periodically reports and parses, the elements in the set gradually increase, supporting duplicate detection. When the name of a self-test item already exists in this set, it indicates that the result of that item has been processed, and the currently reported duplicate result should be ignored. The device self-test completion flag is a Boolean status field in the device context used to indicate whether the DUT has completed the testing and reporting of all device self-test items. When the size of the parsed self-test item set in the device context is equal to the size of the device self-test item set in the current batch test configuration, it means that the device has reported all self-test items, and the flag is set to "completed" (true).

[0053] In step S420 of some embodiments, the PC can receive self-test result messages periodically reported by each device under test. The self-test result message is a data packet sent by the device under test to the PC, containing the execution results of the device's self-test items. The self-test result message can be in XML, JSON, Protobuf, or other structured data formats. When the message arrives, the PC performs preliminary parsing, reads the device identification information field, and then searches for a context instance matching the identifier in the device contexts of all logged-in devices. If a corresponding device context is found, the message is handed over to the processing logic corresponding to that context for further parsing; if no context is found (e.g., the device reported a self-test result before logging in), the message is discarded or temporarily stored in a processing queue.

[0054] In step S430 of some embodiments, the PC can parse multiple device self-test items and the test status of each device self-test item from the self-test result message. The parsing process depends on the data format used in the message. The system performs anti-duplicate processing on each parsed self-test item: using the name of the self-test item as the query key, it searches and matches in the set of parsed self-test items in the corresponding device context.

[0055] In step S440 of some embodiments, the reporting status refers to the processing status determined after the matching operation for each parsed self-test item. There are two reporting statuses: reported status and first-time reporting status. When the self-test item name already exists in the set of parsed self-test items, it indicates that the result of that item has been recorded, and the current reporting result should be ignored. When the self-test item name does not yet exist in the set of parsed self-test items, it indicates that the result of that item has arrived for the first time, and the current reporting result should be processed and recorded. Determining the reporting status can effectively prevent duplicate reporting.

[0056] In step S450 of some embodiments, after all self-test items of each device under test have been recorded to the corresponding parsed self-test item set, the system sets the device self-test completion flag of the device context to the completed state. Specifically, after the PC adds a self-test item to the parsed self-test item set each time, it checks whether the size of the current set is equal to the size of the device self-test item set in the configuration information. If they are equal, it indicates that the device has reported and parsed all the self-test items required by the configuration, and at this time, the device self-test completion flag of the device is set to completed (true). If the set size has not yet reached the expected value, the completion flag is kept incomplete (false). It should be noted that in a multi-threaded concurrent processing scenario, the setting operation of this flag may face a race condition: two threads may simultaneously attempt to set the completion flag of the same device to completed. To solve this problem, embodiments of this application can use atomic comparison swap operations to ensure that the flag setting process is thread-safe. The specific implementation of the atomic comparison swap operation is as follows: obtain the current value of the device self-test completion flag, determine whether the current value is incomplete, if so, atomically update the flag to complete, if the current value is not incomplete (i.e., it has been set to complete by other threads), then abandon this state transition operation.

[0057] In the above embodiments, this application can completely isolate test data between multiple devices by independently maintaining the device context of each device, thus avoiding result crosstalk. The reporting anti-duplicate mechanism implemented through the parsed self-test item set automatically ignores duplicate test item results in periodic reporting, avoiding resource waste and data pollution caused by repeated parsing and refreshing. The automatic setting of the device self-test completion flag provides an accurate and reliable data source for subsequent unified completion judgment.

[0058] Please see Figure 5 , Figure 5 This is another flowchart of the multi-device parallel production test control method provided in the embodiments of this application. In some embodiments of this application, after establishing a communication connection with multiple devices under test and sequentially executing each tool active test item in the tool active test necklace list, the multi-device parallel production test control method provided in the embodiments of this application may further include, but is not limited to, the following steps: Step S510: Set a single device reporting timeout timer for each logged-in device under test. When the device self-test completion flag of the device under test is incomplete, refresh the single device reporting timeout timer of the device under test after receiving a valid self-test result message reported by the device under test. Step S520: If the single-device reporting timeout timer of any device under test times out, set the device self-test completion flag of the device under test to the completed state, mark all unreported device self-test items of the device under test as failed, and perform a unified completion judgment operation. Step S530: Set a global total test timeout timer for the current batch of tests. If the global total test timeout timer expires, end the current batch of tests and perform result compensation processing. Step S540: Set a single test item execution timeout timer for each tool active test item. If the execution time of any tool active test item exceeds the time threshold of the corresponding single test item execution timeout timer, skip the current tool active test item and execute the next tool active test item in the tool active test necklace table.

[0059] In step S510 of some embodiments, the single-device reporting timeout timer is a timer independently set for each logged-in device under test, used to monitor the continuous reporting interval of the device's self-test results. Each device's timer runs independently and does not affect others. The purpose of this timer is to detect whether a device is disconnected. If a device does not send any self-test result message within a preset time interval, it is determined that the device may have malfunctioned (crash, power outage, communication interruption, etc.). Refreshing refers to resetting the single-device reporting timeout timer. When the system receives a valid self-test result message from a device, it resets the device's reporting timeout timer to its initial value and restarts the timing. Refreshing essentially resets the timer, equivalent to sending a signal to the timer. A valid self-test result message refers to a self-test result message that is structurally complete, correctly formatted, can be successfully parsed by the PC, and has legal content. The conditions for determining whether a message is valid include: the message format conforms to the convention (complete XML or JSON structure), all necessary fields are present (at least device identification information and at least one self-test item), and no abnormalities occur during the parsing process. If the message format is incorrect (such as an unclosed tag or a JSON syntax error), an exception is thrown during parsing, or the message does not contain any self-test items, the message is deemed invalid and the system will not use it as the basis for refreshing the timer.

[0060] In step S520 of some embodiments, timeout refers to the moment when the timer countdown reaches zero. When the timeout timer for a single device's report expires, it means that the device has not sent any valid self-test result message within the preset time. In this case, the system determines that the device may have malfunctioned and cannot wait indefinitely for the device to report. After the timeout event is triggered, the system executes the timeout processing logic: forcibly sets the device's self-test completion flag to the completed state, marks all unreported device self-test items of the device as failed, and then triggers a unified completion judgment operation. All unreported device self-test items refer to all self-test items that the device has configured but have not yet been recorded in the parsed self-test item set when the single device's report timeout occurs. Unreported device self-test items can be obtained by the difference operation between the device self-test item set and the parsed self-test item set. These unreported items are uniformly marked as failed due to timeout, avoiding the loss of some test item results due to device malfunction.

[0061] In step S530 of some embodiments, the global total test timeout timer is a timer set for the entire current batch test to monitor the total test time of the entire batch. This timer starts when the batch test begins, and its timeout is a final safety gate. When it times out, regardless of the specific status of each device or the step the tool actively tests the chain of events to which it has been executed, the system must forcibly terminate the current batch test to prevent infinite waiting due to abnormal conditions.

[0062] In step S540 of some embodiments, the single test item execution timeout timer is a timer set separately for each tool active test item in the tool active test chain list, used to monitor the execution duration of a single test item. This timer starts when the test action begins execution, i.e., before the execution logic, and the countdown duration is preset in the test configuration. Each tool active test item can have a different timeout threshold; for example, login may take 5 seconds, and image detection may take 10 seconds. The purpose of this timer is to prevent a single test item from failing to complete for an extended period due to reasons such as device unresponsiveness or communication blockage, which could cause the entire chain list state machine to freeze. The time threshold is the preset countdown duration of the single test item execution timeout timer, in milliseconds or seconds.

[0063] Understandably, after a device successfully logs in, the system creates an independent single-device reporting timeout timer for that device, sets a preset timeout period, and starts it. While the device's self-test completion flag is in the incomplete state, the system continuously monitors the device's message reception. If a valid self-test result message is received from the device, a refresh operation is performed. This refresh operation is repeated after each valid report, ensuring that a normally functioning device will never trigger a timeout. If the device does not send any valid messages within the preset time, the timer countdown resets to zero, triggering a timeout event. After the timeout, the system determines that the device has malfunctioned, forcibly sets the device's self-test completion flag to the completed state, marks all unreported self-test items for the device as failed, and then performs a unified completion judgment operation. At the start of the current batch of tests, the system starts a global total test timeout timer, setting a preset global timeout period (e.g., 5 minutes). During the test, this timer continues to count down, unaffected or refreshed by any events (such as reports, device login, test item completion, etc.). If the timer countdown reaches zero, the system immediately forces the termination of the current batch of tests, regardless of the unified completion judgment result, whether any devices have not yet completed self-testing, or whether the tool's active test chain has been completed. After the forced termination, the system directly enters the result compensation processing flow to perform state compensation for incomplete items. During the sequential execution of the tool's active test chain, a single test item execution timeout timer is started at the beginning of each test action. This timer continuously monitors the execution duration during the test action's execution. If the timer times out, the system skips the current tool-initiated test item, meaning it no longer waits for its completion and directly enters the callback processing stage to determine the next node to be executed and proceed. It should be noted that skipping the current item means that the test result of that item is recorded as a failure, and the state machine continues to execute the next item in the chain, avoiding the entire process from being stalled due to a single item being stuck.

[0064] In the above embodiments, this application implements a three-level timeout protection mechanism (single device reporting timeout, global test timeout, and single test item execution timeout) to provide complete time monitoring and protection for the testing process at three levels. Single device reporting timeout ensures that a single device malfunction will not affect the entire batch; global test timeout ensures that the entire test will not proceed indefinitely; and single test item execution timeout ensures that a single test item getting stuck will not block the entire linked list from progressing. These three levels of timeouts are progressive and complementary, jointly ensuring that the multi-device parallel production testing system can still complete as expected under various abnormal scenarios, significantly improving the system's robustness and adaptability to industrial environments.

[0065] In step S130 of some embodiments, the unified completion judgment operation is used to determine whether the current batch of tests meets or does not meet the test completion conditions. The system responds to preset trigger events occurring in the test process and executes the unified completion judgment operation. Preset trigger events include: completion of the tool's active test necklace list (partial completion of active testing), completion of parsing of the self-test result message of any device under test (a device may have new progress), single device reporting timeout (a device may have malfunctioned), global total test timeout (security gate triggered), and asynchronous task completion (background task completed). When any of the above events occurs, the system calls the unified completion judgment function. This function performs three checks: checks the execution status of the tool's active test necklace list (whether it has been fully executed), checks the device self-test completion flag of each logged-in device (whether all are in a completed state), and checks whether there are any asynchronous waiting items that have not yet met the completion conditions (such as an ongoing 4G card query task or a Bluetooth scan that has not yet completed). If all three checks are satisfied, the current batch of tests is deemed to have met the test termination conditions, resulting in a positive unified completion judgment. If any one check is not satisfied, the current batch of tests is deemed to have not met the test termination conditions, resulting in a negative unified completion judgment. The system then continues to wait for the next preset trigger event.

[0066] Please see Figure 6 , Figure 6 This is a flowchart of step S130 provided in an embodiment of this application. In some embodiments of this application, step S130 may specifically include, but is not limited to, the following steps: Step S610: Check the execution status of the active test necklace watch by the inspection tool and obtain the first inspection result; Step S620: Traverse all logged-in devices under test, check the device self-test completion flag of each logged-in device under test, and obtain the second check result; Step S630: Check if there are any asynchronous waiting items that have not yet met the completion conditions, and obtain the third check result; Step S640: Based on the first inspection result, the second inspection result, and the third inspection result, determine the unified completion judgment result.

[0067] In step S610 of some embodiments, an event is generated internally by the system when the tool actively tests the chain list state machine and completes the execution of all nodes, that is, traversing to the tail node of the chain list and the next pointer returned by the callback function of the tail node is null. This event indicates that the testing work of the PC-side active control part has been completed. The first check result refers to the result value obtained by checking the execution status of the tool actively tests the chain list, indicating whether the tool's active testing process has been completed or not. Specifically, the current pointer value of the chain list state machine is read. If the current pointer is null and the tail node has been marked as completed, it indicates that the chain list has been completed, and the first check result is yes; otherwise, it is no.

[0068] In step S620 of some embodiments, the self-test result message parsing completion event indicates an event generated internally by the system after the PC successfully receives and fully parses a self-test result message reported by a device under test. This event indicates that the latest batch of self-test results for that device has been received and processed by the system. The second check result is the result value obtained by traversing all logged-in devices under test and checking the self-test completion flag of each device, indicating that the self-test of all devices has been marked as completed or that there are devices that have not completed the self-test. The system traverses all logged-in devices under test and checks the device self-test completion flag in the device context of each device one by one. If the flag of all devices is completed (true), the second check result is yes; if the flag of any device is not completed (false), the second check result is no.

[0069] In step S630 of some embodiments, the asynchronous task completion event indicates an event generated internally by the system when an asynchronous task started in the background (such as a 4G card information query thread or a Bluetooth device search thread) completes execution and notifies the main process. This event indicates that a previously started time-consuming asynchronous task has returned a result. The third check result refers to the result value obtained by checking whether there are any asynchronous waiting items that have not yet met the completion conditions, indicating whether there are any incomplete asynchronous waiting items or whether there are incomplete asynchronous waiting items. An asynchronous waiting item refers to an asynchronous task instance that has been started but not yet finished in the current test process, and whose completion is required to determine the end of the test. Asynchronous waiting items include, but are not limited to: an instance of a 4G card information query thread that is currently executing, an instance of a Bluetooth device search thread that is currently running, and other time-consuming operations started in the background whose results must be included in the final completion judgment.

[0070] In step S640 of some embodiments, a unified completion judgment result is determined based on the first, second, and third check results. If all three are true, i.e., the active test process is complete, all device self-tests are complete, and there are no incomplete asynchronous waiting items, then the current batch is determined to meet the test termination conditions, the current batch test ends, and the system enters the termination processing flow. If any of the three are false, such as the active test process not yet being completed, or a device self-test not being completed, or there are still asynchronous tasks being executed, then the current batch is determined not to meet the test termination conditions, and the system continues to wait for the next preset trigger event.

[0071] In the above embodiments, by clearly defining the types of preset trigger events and the specific inspection steps for unified completion judgment, the three inspection dimensions cover three different completion states: active process, device self-test, and asynchronous task. If any dimension is not completed, the end will not be triggered, ensuring the accuracy and completeness of the test end judgment.

[0072] It should be noted that when the completion condition or forced termination condition is met, the system stops all timers, performs compensation for unfinished items, and enters either the manual confirmation process or the automatic test completion process depending on the fixture type.

[0073] In step S140 of some embodiments, when the unified completion judgment result indicates that the current batch of tests meets the test termination conditions, the system enters the result compensation processing stage. Specifically, the set of device self-test items generated in the test configuration stage can be obtained first as the expected set of self-test items for each device. Then, for each device under test, the system obtains the set of reported self-test items from its device context as the actual reported set for that device. The system performs a difference operation on the expected set and the actual set to obtain the set of unreported self-test items for that device. For example, if the expected set is {WiFi, 4G, GPIO, audio, SD card, USB, adapter, charging, discharging, battery level, battery voltage, battery temperature}, and the actual reported set for a certain device is {WiFi, 4G, GPIO, audio, SD card, USB, adapter, charging}, then the difference set is {discharging, battery level, battery voltage, battery temperature}, indicating that these four self-test items of the device have not been reported. The system iterates through each self-test item in the set of unreported self-test items, calls the corresponding failure termination function for that self-test item, records the test result as "failure," and writes it to the device's final test report. After status compensation, each device's test report contains the results (pass or fail) of all test items, with no items marked "untested" or with missing results.

[0074] For example, taking the automated production testing of an 8-station IPC camera as an example, the multi-device parallel production testing control method provided in this application embodiment may specifically include the following steps: 1. The operator scans the QR codes of 8 devices, the system parses the model and initializes the device context for each workstation.

[0075] 2. The system logs into multiple devices, and devices that successfully log in enter the testing process.

[0076] 3. The system generates a tool test list and a set of device self-test items based on the current board type and configuration.

[0077] 4. The tool test necklace table sequentially executes the tool's active test items, such as obtaining device type, system version, video preview, SN verification, unique ID acquisition, image detection, and current detection.

[0078] 5. The system sends self-test items to the device, including WiFi, 4G, GPIO, audio, SD card, power management, and battery.

[0079] 6. The device performs self-tests and periodically reports the results via XML.

[0080] 7. On the PC side, XML is parsed by device, and duplicate test items are filtered out through the parsed collection.

[0081] 8. Each device maintenance has an independent reporting timeout timer. The timer is refreshed after each valid report if the device maintenance is not completed.

[0082] 9. If a device fails to report within the timeout period, the device will only be marked as failed, without affecting other devices from continuing the test.

[0083] 10. If the global test times out, the system will forcibly terminate the test and perform result compensation.

[0084] A unified completion judgment is triggered after asynchronous tasks such as 11.4G card query and Bluetooth search are completed.

[0085] 12. Before the test ends, the system will automatically compensate for any unreported self-test items as failure results.

[0086] 13. In the case of an automated fixture, the system automatically issues a test completion command; in the case of a manual or pneumatic fixture, the system proceeds to the next manual step.

[0087] The multi-device parallel production testing control method provided in this application is equivalent to providing a tool for multi-device parallel production testing, and the technical effects it can produce are as follows: (1) Efficiency Improvement: The tool's proactive testing and the device's self-test are executed in complete parallel, eliminating the serial waiting time in the traditional solution where proactive testing waits for self-test reports and self-test reports interrupt proactive testing, significantly shortening the average test time for multiple device batches. This improves the efficiency of parallel production testing of multiple devices and reduces the overall test time.

[0088] (2) Process determinism: Through the sequential execution driven by the linked list state machine and the precise determination of the unified completion judgment, the direction and end time of the test process are changed from uncertain to predictable, thus avoiding process management chaos.

[0089] (3) Data integrity: Through the dual mechanisms of parsed set anti-duplication and difference set compensation, it is ensured that each test item of each device has a clear pass or fail judgment, and the report has no blanks or untested items.

[0090] (4) System robustness: The three-level timeout protection mechanism implements time watchdog protection at three levels: single item, single device, and global. No fault at any level will cause the system to wait indefinitely, ensuring that the test can still be completed normally under various abnormal scenarios.

[0091] (5) Flexibility of process: The combination of dynamic insertion at runtime and configuration generation makes the test process both predefined and adjustable at runtime, which can flexibly adapt to various board types, work orders, fixture types and various branch requirements generated during the test process.

[0092] (6) Ease of maintenance: The test process exists in the form of configuration rather than code. When the production line switches product models or adjusts test items, only the configuration file or mapping table needs to be modified. There is no need to modify the core test program, recompile and deploy, which reduces maintenance costs and technical threshold.

[0093] Therefore, the embodiments of this application provide a combination of "tool test necklace table state machine + device self-test asynchronous reporting + anti-duplicate parsing for each device + single device reporting timeout + global total test timeout + unified judgment of asynchronous task completion + compensation for incomplete items", which achieves comprehensive technical effects such as precise and controllable test process, complete and reliable test results, robust and efficient system operation, and flexible and convenient production line switching. It can be widely applied to automated production testing scenarios of IPC cameras, 4G / WiFi security equipment, battery-equipped equipment and multi-station fixtures.

[0094] Please see Figure 7 This application also provides a multi-device parallel production testing control device 700, which includes: The collection construction module 710 is used to obtain the test configuration information of the current batch of tests, and generate a tool active test necklace list and a device self-test item set shared by all devices under test in the current batch of tests based on the test configuration information. The tool active test necklace list contains multiple tool active test items arranged in a preset execution order, and the device self-test item set contains multiple device self-test items executed and reported by the device under test. The test item execution module 720 is used to establish a communication connection with multiple devices under test, execute each tool active test item in the tool active test necklace list in sequence, and send the device self-test item set to each device under test so that each device under test can perform device self-test and asynchronously report self-test results; The judgment module 730 is used to respond to preset trigger events in the test process, perform a unified completion judgment operation, and obtain a unified completion judgment result. The unified completion judgment operation is used to determine whether the current batch of tests meets the test termination conditions or does not meet the test termination conditions. The status compensation module 740 is used to determine the unreported self-test items of each device under test based on the difference between the set of self-test items of the device and the set of self-test items reported by each device under test when the unified completion judgment result indicates that the current batch of tests meets the test end conditions, and to perform status compensation on the test results of the unreported self-test items.

[0095] It should be noted that the multi-device parallel production test control device provided in this application embodiment is used to implement the multi-device parallel production test control method provided in the above embodiment, and the specific implementation process corresponds to the multi-device parallel production test control method in the above embodiment. It can be referred to the aforementioned multi-device parallel production test control method, and will not be repeated here.

[0096] This application also provides an electronic device (i.e., a computer device), which includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it can implement any of the multi-device parallel production and testing control methods described in the above embodiments. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0097] Please see Figure 8 , Figure 8 This illustration shows the hardware structure of an electronic device according to another embodiment, the electronic device comprising: The processor 810 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 820 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 820 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 820 and called and executed by the processor 810 using the multi-device parallel production and testing control method of the embodiments of this application. The input / output interface 830 is used to implement information input and output; The communication interface 840 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 950 transmits information between various components of the device (e.g., processor 810, memory 820, input / output interface 830, and communication interface 840); The processor 810, memory 820, input / output interface 830 and communication interface 840 are connected to each other within the device via bus 950.

[0098] This application also provides a computer-readable storage medium storing a computer program for causing a computer to execute the multi-device parallel production and testing control method described in the above embodiments.

[0099] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0100] This invention also provides a computer program product that stores program instructions. When executed by a computer, the program instructions cause the computer to implement the multi-device parallel production and testing control method described in any of the above embodiments.

[0101] It should be noted that any software tools or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0102] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0103] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0104] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0106] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0107] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

[0109] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0112] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A multi-device parallel production measurement control method, characterized in that, The method includes: Obtain the test configuration information for the current batch of tests, and generate a tool active test necklace list and a device self-test item set shared by all devices under test in the current batch of tests based on the test configuration information. The tool active test necklace list contains multiple tool active test items arranged in a preset execution order, and the device self-test item set contains multiple device self-test items executed and reported by the device under test. After establishing a communication connection with multiple devices under test, the active test items of the tool in the active test necklace list are executed sequentially, and the set of device self-test items is sent to each device under test so that each device under test can perform device self-test and asynchronously report self-test results; In response to a preset trigger event in the testing process, a unified completion judgment operation is performed to obtain a unified completion judgment result. The unified completion judgment operation is used to determine whether the current batch of tests meets the test termination conditions or does not meet the test termination conditions. When the unified completion judgment result indicates that the current batch of tests meets the test end conditions, the unreported self-test items of each device under test are determined according to the difference between the set of self-test items of the device and the set of self-test items reported by each device under test, and the test results of the unreported self-test items are compensated for.

2. The method according to claim 1, characterized in that, The active test items in the active test necklace table are executed sequentially, including: The tool actively tests the head node of the necklace table, which is then identified as the current execution node. The test action encapsulated by the current execution node is then executed to obtain the test execution result. The test action includes execution logic and callback processing functions. The callback function is invoked to determine the next node to be executed in the sequence of active test items of the tool, and the current execution node is updated to the next node to be executed. The updated test action encapsulated in the next currently executing node is executed to obtain the test execution result, until all nodes in the tool's active test item sequence are executed or the termination condition is met.

3. The method according to claim 2, characterized in that, The invocation of the callback function to determine the next node to be executed in the tool's active test necklace table includes: Obtain the device type information and process status information of the current test phase of the device under test; Based on the test execution results, the device type information, and the process status information, a new test item is detected to determine whether it is necessary to insert a new test item into the tool's active test necklace table. If it is necessary to insert a new test item into the tool's active test necklace table, insert the generated new test item node between the current execution node and the next node to be executed, and update the node link relationship of the tool's active test necklace table; The callback function is invoked to determine the next node to be executed in the tool's active test necklace table based on the updated node link relationship.

4. The method according to claim 1, characterized in that, After distributing the set of device self-test items to each device under test for self-testing and asynchronous reporting of self-test results, the method further includes: For each logged-in device under test, a corresponding device context is maintained. The device context includes device identification information, a set of parsed self-test items, and a device self-test completion flag. Receive self-test result messages periodically reported by each of the devices under test, and determine the corresponding device context based on the device identification information carried in the self-test result messages; Multiple device self-test items and the test status of each device self-test item are parsed from the self-test result message; Based on the set of parsed self-test items, each of the parsed device self-test items is matched to determine the reporting status of each of the parsed device self-test items, and the set of parsed self-test items is updated based on the reporting status. Once all the device self-test items of each device under test have been recorded to the corresponding set of parsed self-test items, the device self-test completion flag of the device context is set to the completed state.

5. The method according to claim 4, characterized in that, After establishing communication connections with multiple devices under test, and sequentially executing each of the tool active test items in the tool active test necklace list, the method further includes: Set a single device reporting timeout timer for each logged-in device under test. When the device self-test completion flag of the device under test is incomplete, refresh the single device reporting timeout timer of the device under test after receiving a valid self-test result message reported by the device under test. If the single device reporting timeout timer of any of the devices under test expires, the device self-test completion flag of the device under test is set to the completed state, and all unreported device self-test items of the device under test are marked as failed, and a unified completion judgment operation is performed. Set a global total test timeout timer for the current batch of tests. If the global total test timeout timer expires, end the current batch of tests and perform result compensation processing. A single test item execution timeout timer is set for each of the tool's active test items. If the execution time of any of the tool's active test items exceeds the time threshold of the corresponding single test item execution timeout timer, the current tool's active test item is skipped, and the next tool's active test item in the tool's active test necklace list is executed.

6. The method according to claim 5, characterized in that, The preset trigger events include at least one of the following events: the tool actively tests the necklace table execution completion event, the self-test result message parsing completion event of any device under test, the single device reporting timeout event, the global total test timeout event, and the asynchronous task completion event; The unified completion judgment operation, which responds to a preset trigger event in the testing process, and obtains a unified completion judgment result, includes: The execution status of the tool actively testing the necklace table is checked to obtain the first check result; Iterate through all logged-in devices under test, check the device self-test completion flag of each logged-in device under test, and obtain the second check result; Check if there are any asynchronous wait items that have not yet met the completion conditions, and obtain the third check result; Based on the first inspection result, the second inspection result, and the third inspection result, a unified completion judgment result is determined.

7. The method according to claim 1, characterized in that, The step of generating a tool active test necklace table and a set of device self-test items shared by all devices under test in the current batch of tests based on the test configuration information includes: Read the board type identification information and work order identification information from the test configuration information; Based on the board type identification information and work order identification information, an initial test item list is obtained by matching from the pre-configured test item mapping table. The initial test item list includes combined test items, tool active test items, and equipment self-test items. For the combined test item, the combined test item is broken down into multiple sub-test items, and the sub-test items are used as device self-test items; All the tool active test items are arranged in a preset order to obtain a tool active test necklace table, and a device self-test item set is constructed based on all the device self-test items.

8. A multi-device parallel production measurement control device, characterized in that, The device includes: The collection construction module is used to obtain the test configuration information of the current batch of tests, and generate a tool active test necklace list and a device self-test item set shared by each device under test in the current batch of tests based on the test configuration information. The tool active test necklace list contains multiple tool active test items arranged in a preset execution order, and the device self-test item set contains multiple device self-test items executed and reported by the device under test. The test item execution module is used to establish a communication connection with multiple devices under test, execute each of the tool active test items in the tool active test necklace list in sequence, and send the device self-test item set to each device under test so that each device under test can perform device self-test and asynchronously report self-test results; The judgment module is used to respond to preset trigger events in the test process, perform a unified completion judgment operation, and obtain a unified completion judgment result. The unified completion judgment operation is used to determine whether the current batch of tests meets the test end conditions or does not meet the test end conditions. The status compensation module is used to determine the unreported self-test items of each device under test based on the difference between the set of self-test items of the device and the set of self-test items reported by each device under test when the unified completion judgment result indicates that the current batch of tests meets the test end conditions, and to perform status compensation on the test results of the unreported self-test items.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images