Test method, apparatus, and storage medium for production tool

Abstract

The application discloses a production tool testing method, device and storage medium, relates to the technical field of testing, and the method comprises the following steps: a host computer responds to production line test scheduling instructions, matches corresponding test script packages according to model identification, analyzes test logic through a script parser, determines protocol interaction rules and result determination criteria, generates a test execution sequence, and then converts the test execution sequence into test interaction messages and issues the test interaction messages to a lower computer to be tested. The lower computer analyzes the messages, calls corresponding function modules to execute detection actions, generates test response data, and encapsulates the test response data in a predetermined format and returns the test response data. After receiving the data, the host computer completes verification according to the result determination criteria through the script parser, and outputs test results of the to-be-tested equipment. The script parser is used for decoupling production test protocol interaction logic, test business is separated from a back-end main program and independently maintained, the problem of low production efficiency of a production line is solved, multi-model expansion flexibility is improved, and the effect of efficient and stable operation and maintenance of the production line test is achieved.

Description

Technical Field

[0001] This application relates to the field of testing technology, and more particularly to a testing method, apparatus, and storage medium for production tools. Background Technology

[0002] In production line testing scenarios for electronic products such as video processors, the ability to flexibly adapt to testing protocols for multiple models and to rapidly iterate testing functions is directly related to production line efficiency and system maintenance costs.

[0003] In related technologies, production line testing is carried out by using a host computer production tool to connect with a unified backend service program. The backend service program centrally carries all the protocol interaction of the devices under test and the control logic of the auxiliary test devices. This method tightly couples the test item's sending and receiving parsing, protocol interaction and device control logic into the backend main program. When adding a new device under test, adjusting test cases, or iterating the device interaction protocol on the production line, it is necessary to modify the main program source code, perform a full compilation and arrange production line shutdown for deployment, resulting in low production line efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a testing method, equipment, and storage medium for production tools, aiming to solve the technical problem of low production efficiency in production lines.

[0006] To achieve the above objectives, this application proposes a testing method for production tools, the method comprising: Responding to production line test scheduling instructions, determine the corresponding test script package based on the model identifier of the device under test; The test logic within the test script package is parsed by the script parser to determine the protocol interaction rules and result judgment criteria for the test items, and to arrange and generate the test execution sequence. The test execution sequence is converted into a test interaction message adapted to the target communication channel and sent to the device under test on the lower-level machine; After receiving the test response data returned by the lower-level machine, the test response data is verified by the script parser according to the result judgment benchmark to obtain the test result of the device under test.

[0007] In one embodiment, in response to the production line test scheduling instruction, the device under test model identifier and test task range parameters of the production line test scheduling instruction are parsed, and the baseline query parameters are obtained. Based on the model identifier of the benchmark query parameters, initiate a model directory matching query to the test specification library to determine the target directory corresponding to the model identifier; Verify the validity of the test package release and its compatibility with the device version under the target directory, and output the resource location information of the script package that has passed the verification. The initial test package is determined according to the resource location information of the script package. The file integrity is verified and the script format compliance is checked on the initial test package to obtain a compliant test package. The compliance test package is restructured by re-indexing the directory according to the execution priority of the test items, generating the test script package that can be loaded and called by the script parser.

[0008] In one embodiment, the lexical semantics of the test script package are verified by the entry scheduling module of the script parser, and the test item branch structure and execution dependency relationship within the test script package are identified to obtain the script syntax parsing structure; The script syntax parsing structure is analyzed in depth for each test item to determine the protocol interaction rules, data verification rules and result judgment criteria corresponding to each test item, and to generate a test item metadata set. Based on the test item metadata set, and combined with the abnormal circuit breaker rules of the production line test process, the execution path is arranged to obtain the test execution link framework; The test execution sequence is obtained by binding the corresponding communication channel protocol adaptation entry and decision execution handle to the execution node in the test execution link framework and preloading the context.

[0009] In one embodiment, based on the test item metadata set and the exception circuit breaker rules, the prerequisite dependencies, execution priorities, and failure impact levels among the test items are determined; Based on the execution priority and the prerequisite dependencies, an initial test execution path is constructed according to the serial execution baseline, and an exception judgment branch node corresponding to the failure impact level is embedded after the test item node to generate the initial execution link; Configure corresponding jump targets and circuit breaker triggering conditions for the abnormal judgment branch nodes in the initial execution link according to the abnormal circuit breaker rules, and associate the continuous failure count and the whole machine retest triggering logic to obtain the preliminary framework of the execution link; The preliminary execution link framework is subjected to dependency closure verification and path reachability verification, redundant branches are eliminated and the state transfer format between nodes is unified to obtain the test execution link framework.

[0010] In one embodiment, the target communication channel type and protocol format constraints of the test execution sequence are parsed node by node, and the corresponding protocol adaptation rule template is matched to obtain a set of test instructions to be encapsulated with channel identifiers; According to the protocol adaptation rule template, the instructions in the test instruction set to be encapsulated are mapped and encapsulated according to the frame structure specification of the corresponding channel, and the message sequence identifier and integrity verification field are embedded to obtain the test interaction message set. Verify the compliance of the channel transmission of the test interaction message set. After the verification is passed, sort the messages according to the test execution sequence and channel bandwidth attributes, and generate a message queue to be sent in an orderly manner. The physical communication channel's sending interface is invoked, and the test interaction message is sent frame by frame to the device under test of the lower-level machine according to the order of the message queue to be sent.

[0011] In one embodiment, the test response data returned by the lower-level machine is received, unpacked and frame integrity verified according to the protocol specifications of the corresponding communication channel, and time alignment and deduplication are performed according to the message sequence identifier to obtain the original response data; The original response data is mapped and matched one by one with the test item nodes of the test execution sequence to determine the feature field to be verified and the result judgment benchmark corresponding to each test, and the data unit set to be verified is obtained by association. The script parser performs numerical threshold comparison, data format verification, and logical compliance judgment item by item according to the result judgment criteria of the data unit to be verified, and records abnormal fields and deviation values ​​to obtain a single judgment result set. The individual judgment results of the test items are summarized, and the overall test conclusion is calculated by combining the abnormal circuit breaker rules of the production line test with the test item level weight, so as to obtain the test result of the equipment under test.

[0012] In one embodiment, a test interaction message sent by a host computer is received; The test interaction message is parsed according to the unified protocol specification, and the corresponding functional module of the test interaction message is called to perform the detection action of the specified test item to obtain the test response data. The test response data is encapsulated in a pre-defined general format and then sent back to the host computer so that the test results can be determined by the host computer's script parser.

[0013] In one embodiment, the test interaction message is decapsulated, frame integrity is verified, and command validity is checked according to the unified protocol specification to obtain a valid test command; Based on the test item identifier of the valid test instruction, the corresponding functional module is matched in the locally pre-stored functional module mapping table, and the current device operating status and the execution admission conditions of the test item are verified to generate a functional execution instruction. According to the function execution instruction, drive the corresponding function module to perform the detection action of the specified test item; During the execution of the detection action, status data and result parameters during the detection process are collected, and the status data and result parameters are subjected to validity filtering and outlier removal to obtain the original test dataset; The original test dataset is mapped and formatted according to a preset data structure, and the corresponding test item identifier and execution status code are associated to obtain the test response data.

[0014] In addition, to achieve the above objectives, this application also proposes a testing device for production tools, the testing device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the testing method for production tools as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the testing method for the production tool as described above.

[0016] This application provides a testing method for production tools, comprising: responding to production line test scheduling instructions and determining the corresponding test script package based on the model identifier of the device under test (DUT); using a script parser to parse the test logic within the test script package to determine the protocol interaction rules and result judgment criteria for the test items and arranging them to generate a test execution sequence; then converting the test execution sequence into test interaction messages adapted to the target communication channel and sending them to the DUT on the lower-level machine; finally, the script parser verifies the test response data returned by the lower-level machine according to the result judgment criteria and obtains the test results of the DUT. This protocol decoupling architecture solves the problems of traditional production testing architectures. The protocol interaction logic of the device under test is embedded in the backend service main program, which leads to the main program becoming increasingly bloated as the number of test items and device models increases. This results in difficulties in maintaining the stacked branches due to protocol differences among multiple device models. Adding or modifying test items requires modifying the main program and recompiling and deploying it. This causes technical problems such as low production line testing iteration efficiency and high upgrade risks. This paper improves the independent maintenance capability and expansion flexibility of multi-device production line testing specifications, clarifies the responsibility boundaries between the backend scheduling service and the test protocol interaction, reduces the upgrade and maintenance cost of the production line testing system, and achieves decoupling and separation of test business logic and main service program. This effectively improves the iteration efficiency of production line testing and the stability of system operation.

[0017] In summary, this application decouples the production test protocol interaction logic through a script parser, separates the test business from the backend main program for independent maintenance, solves the technical problem of low production line efficiency, improves the flexibility of multi-model expansion, and achieves efficient and stable operation and maintenance of production line testing. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the testing method for the production tool of this application; Figure 2 This is a flowchart of the script parsing process for this application; Figure 3 This is a flowchart illustrating the fourth embodiment of the testing method for the production tool of this application; Figure 4 This is a flowchart illustrating the seventh embodiment of the testing method for the production tool of this application; Figure 5 This is a system architecture diagram for this application; Figure 6 This is a flowchart illustrating the eighth embodiment of the testing method for the production tool of this application; Figure 7 This is a schematic diagram of the testing equipment for the production tools of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In related technologies, production line testing is carried out by using a host computer production tool to connect with a unified backend service program. The backend service program centrally carries all the protocol interaction of the devices under test and the control logic of the auxiliary test devices. This method tightly couples the test item's sending and receiving parsing, protocol interaction and device control logic into the backend main program. When adding a new device under test, adjusting test cases, or iterating the device interaction protocol on the production line, it is necessary to modify the main program source code, perform a full compilation and arrange production line shutdown for deployment, resulting in low production line efficiency.

[0024] This application provides a solution: First, in response to the production line test scheduling instruction, the corresponding test script package is determined according to the model identifier of the device under test. Then, the test logic in the test script package is parsed by a script parser to determine the protocol interaction rules and result judgment criteria of the test items, and a test execution sequence is generated. The test execution sequence is then converted into test interaction messages adapted to the target communication channel and sent to the device under test on the lower-level machine. Finally, after receiving the test response data returned by the lower-level machine, the test response data is verified by the script parser according to the result judgment criteria to obtain the test result of the device under test.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or a testing device for production tools capable of performing the above functions. The following description uses a testing device for production tools as an example to illustrate this embodiment and the subsequent embodiments.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] This application provides a testing method for production tools, applied to a host computer, with reference to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the testing method for the production tool of this application.

[0028] In this embodiment, the testing method for the production tool includes steps S10 to S40: Step S10: Respond to the production line test scheduling instruction and determine the corresponding test script package based on the model identifier of the device under test.

[0029] The production line test scheduling command is the core control command that triggers the production line test tasks for the device under test (DUT). The DUT's model identifier is a unique identifier used to distinguish different product models and correspond to different protocol interaction rules. The test script package is a collection of script files that independently encapsulates all test item interaction logic and judgment rules for the corresponding model. For example, the model identifier includes the product model code, hardware version number, and firmware version number; the test script package includes protocol interaction scripts, result judgment rule files, and test item dependency configuration files.

[0030] In this embodiment, the aforementioned production line test scheduling instructions can be triggered in five ways. First, workstation scanning triggers: when the device under test enters the test station, the scanning device reads the machine identification code and parses it to obtain the machine model identifier. The system automatically generates and issues a production line test scheduling instruction to initiate the full-scale production line test process for a single machine. Second, batch task triggers: when an entire batch of devices under test flows to the test section, the production management system generates and issues production line test scheduling instructions in batches according to the batch work order information to execute the assembly line test task for the entire batch of devices. Third, retest triggers: when the initial test of the equipment has non-conforming items requiring retesting, the test system automatically generates a targeted retest production line test scheduling instruction based on the initial test record, performing secondary test verification only on the non-conforming items. Fourth, manual triggers: testers select the machine model under test and the range of test items through the host computer operation interface, manually initiate a test request, and the system generates and issues a production line test scheduling instruction after receiving the request. Fifthly, production line linkage triggering: after the preceding assembly station completes equipment assembly and sends a completion signal, the testing station system automatically generates production line test scheduling instructions, preloads test resources, and shortens the waiting time at the station.

[0031] Once the production testing system receives the production line test scheduling instruction, it begins to parse the model identifier of the device under test and matches and locates the corresponding test script package.

[0032] For example, there are two ways to determine the corresponding test script package based on the device model identifier. The first is a full-scale matching and retrieval method from the cloud. Before the test task officially starts, the complete device model identifier parameters in the scheduling instruction are parsed, and a full-field matching query is initiated to the cloud test specification library to verify the version validity and release status of the corresponding device model script package. After confirmation, the entire set of test script packages is retrieved to the local machine, and file integrity verification and format compliance verification are completed simultaneously. After the verification passes, the scripts are stored in the local script resource pool. This method is logically stable and reliable, and the script version is unified and controllable, ensuring that the test rules are completely consistent with the latest specifications on the cloud.

[0033] The second method is local cache incremental verification. After receiving the scheduling command, the system first searches the local script cache pool to see if a historical script package for the corresponding model exists. If it exists, its version identifier is extracted and compared with the latest version on the cloud. If the versions match, the local cached resources are reused directly. If the versions differ, only the differing script files and configuration items are retrieved, and a complete, usable test script package is generated after the incremental update. This method can reduce the amount of data transferred to the cloud, shorten the pre-test startup time, and improve the efficiency of workstation test workflow.

[0034] In an exemplary scheme for determining the test script package, a local script cache index is first loaded. This index records the script version number, file list, and update time for all cached device models. Then, initial device matching is performed, comparing the device identifier in the command with the device code in the index to determine if a cached script package for the corresponding device model exists locally. If no corresponding cache exists locally, a full fetch request is initiated from the cloud test specification library. After downloading the complete test script package, file hash verification is performed. If the verification passes, the package is stored in the local cache, and the index is updated. If a corresponding cache exists locally, the version number of the cached script is extracted and compared with the latest version number on the cloud. If the versions match, it is marked as usable. If the versions do not match, the cloud version difference list is retrieved, the newly added and modified script files are fetched, the corresponding local files are replaced, and a full integrity verification is performed. If the verification passes, the version index is updated. Finally, the permissions of the test items within the script package are synchronously verified to match the test scope of this scheduling command. Test scripts exceeding the command scope are removed, ultimately generating a usable test script package that fully matches this task for subsequent script parsing and execution sequence generation.

[0035] Step S20: The test logic in the test script package is parsed by the script parser to determine the protocol interaction rules and result judgment criteria of the test items, and the test execution sequence is generated by arranging.

[0036] The script parser is the core processing unit used to interpret and execute test scripts, complete protocol logic conversion, and determine results. Protocol interaction rules describe the execution specifications for message interaction timing, encapsulation format, and transmission channels between the test item and the device under test. Result determination criteria are the standard basis used to verify device response data and determine whether a test item is qualified or not. The test execution sequence is a structured set of instructions arranged according to execution logic that can directly drive the test process. For example, protocol interaction rules include message frame structure, send / receive timing, and channel type; result determination criteria include numerical threshold ranges, status code definitions, and logical determination conditions.

[0037] Once the matched test script package is obtained, the script parser initiates the script parsing and execution sequence orchestration process.

[0038] For example, there are two implementation methods for script parsing and execution sequence generation. The first is line-by-line interpretation-based full parsing. After the parsing process starts, the script parser reads the script content line by line according to the writing order of the script file, parses the test logic line by line, extracts protocol interaction parameters and judgment rules. Each time a test item is parsed, the corresponding execution node is generated synchronously. After all test items are parsed, dependency analysis and path orchestration are performed uniformly, ultimately generating a complete test execution sequence. This method has intuitive parsing logic, strong script compatibility, and supports custom complex logic scripts.

[0039] The second method is pre-compiled node-based parsing. First, a full syntax scan is performed on the entire test script package, converting test items, branch conditions, and loop logic into standardized logical node units. Then, a logical topology graph is constructed based on the dependencies between nodes. Subsequently, the execution path of the topology graph is optimized and abnormal branches are supplemented according to the production line testing process specifications, ultimately generating a structured test execution sequence. This method can complete syntax verification and logic optimization in advance, resulting in higher execution efficiency, more comprehensive coverage of abnormal branches, and ensuring a stable and efficient testing process.

[0040] In an exemplary scheme for generating a test execution sequence, the script parser's entry scheduling module first loads the complete test script package, performs lexical and semantic pre-validation, identifies syntax errors and logical conflicts within the script, and after passing the pre-validation, decomposes the script into independent test item logical units. Then, it extracts the protocol interaction rules and result judgment benchmarks for each unit, generating a metadata node carrying complete rule parameters for each test item. Next, it loads the production line test exception circuit breaker rules, sorts out the pre-dependencies and execution priorities between each metadata node, builds an initial execution path according to the serial baseline, and embeds corresponding level exception judgment branches and circuit breaker jump nodes after each test item node. Then, it performs dependency loop verification and path reachability verification on the initial execution path, eliminates redundant branches, unifies the state transmission format between nodes, and binds the corresponding communication channel protocol adaptation entry to each execution node. Finally, it integrates to generate a structured test execution sequence containing normal execution paths, exception jump paths, and circuit breaker termination paths for subsequent message conversion and device interaction.

[0041] Step S30: Convert the test execution sequence into a test interaction message adapted to the target communication channel and send it to the device under test on the lower-level machine.

[0042] The target communication channel is the physical communication link between the host computer and the device under test (DUT) used to transmit test interaction messages. Test interaction messages are test instruction carriers encapsulated according to the target channel protocol specification and can be directly sent to the DUT. For example, the target communication channel includes a serial communication channel, a universal serial bus channel, and an Ethernet communication channel; the test interaction message includes an instruction header, test item identifier, parameter fields, and verification fields.

[0043] After generating the structured test execution sequence, the protocol adaptation and message delivery process is initiated to convert the execution sequence into interactive messages that the device under test can recognize and complete the delivery.

[0044] For example, there are two implementation methods for the test execution sequence to be converted into messages and sent. The first method is single-channel frame-by-frame encapsulation and sending. According to the node order of the test execution sequence, the protocol interaction parameters of each execution node are extracted one by one, matched with the protocol adaptation template corresponding to the target communication channel, and the field mapping and message encapsulation are completed according to the frame structure specification. After each encapsulated frame is sent to the device under test through the corresponding channel, the encapsulation and sending of the next node are executed synchronously after waiting for the device response. This method has controllable interaction timing and high single-link stability.

[0045] The second method is multi-channel parallel mapping and encapsulation. First, all nodes in the test execution sequence are grouped and categorized according to the target communication channel. Execution nodes on the same channel are arranged in execution order. Nodes on different channels initiate protocol adaptation and message encapsulation in parallel. After each channel independently completes message encapsulation, it is sent out sequentially according to its own timing requirements, with the execution progress between channels not interfering with each other. This method can fully utilize multi-channel communication capabilities, shorten the overall test interaction time, and improve test execution efficiency.

[0046] In an exemplary scheme for message conversion and delivery, the test execution sequence and protocol adaptation rule base for each communication channel are first loaded, and the target communication channel type and protocol format constraints corresponding to each execution node are parsed. Then, a corresponding protocol adaptation template is matched for each execution node, mapping the test instruction parameters and judgment threshold parameters within the node to the corresponding fields of the message according to the template specification. Message sequence identifiers and integrity verification fields are embedded synchronously to generate standard format interactive messages. Next, all generated interactive messages undergo channel transmission compliance verification, checking whether the message length, field format, and verification fields conform to the transmission specifications of the corresponding channel. Non-compliant messages are discarded and regenerated. After successful verification, messages are prioritized according to the test execution sequence and channel bandwidth attributes, generating an ordered queue of messages to be sent. Finally, the sending interface of the corresponding physical communication channel is invoked, and the test interactive messages are delivered frame by frame to the lower-level device under test according to the queue order. The message sending status and timestamp are recorded synchronously and sent back to the scheduling module for timing matching of subsequent response data.

[0047] Step S40: After receiving the test response data returned by the lower-level machine, the test response data is verified by the script parser according to the result judgment benchmark to obtain the test result of the device under test.

[0048] Test response data consists of the status data and result parameters returned by the device under test (DUT) after receiving the test interaction message, performing the corresponding detection actions, and then returning the data. Test results are the final conclusion regarding the pass / fail status of a test item, obtained after verifying the response data against a judgment criterion. For example, test response data includes device status codes, detection values, and operating parameters; test results include individual test conclusions, overall system test conclusions, and details of any anomalies.

[0049] After the device under test (DUT) sends back the test response data, the script parser initiates the response data verification and result determination process.

[0050] For example, there are two ways to implement response data verification and result determination. The first is frame-by-frame real-time determination. Upon receiving each frame of test response data, unpacking and field extraction are immediately performed, the result determination benchmark of the corresponding test item is matched, the pass / fail determination of the test item is completed in real time, and the single result is output. After the determination is completed, the next frame of test message is sent. This method has strong real-time determination and can adjust the subsequent test process in a timely manner based on the single result.

[0051] The second method is batch aggregation and judgment. It first continuously receives response data corresponding to all test items and temporarily stores it in a local cache. After all test interaction messages have been sent and all response data has been received, it uniformly performs unpacking, timing alignment, and verification judgment on all response data. It then batch generates individual conclusions for all test items and summarizes them to obtain the overall system test results. This method has a high degree of data processing centralization, which can reduce frequent switching of judgment logic and improve overall judgment processing efficiency.

[0052] In an exemplary scheme for response verification and result generation, the system first receives the original test response message returned by the lower-level machine. Unpacking and frame integrity verification are performed according to the protocol specifications of the corresponding communication channel. Timing alignment and deduplication are completed based on the message sequence identifier, outputting a structured set of original response data. Then, the original response data set is mapped and matched one by one with each test item node in the test execution sequence. The feature fields to be verified corresponding to each test item are extracted, and the preset result judgment benchmarks for that test item are synchronously associated, generating a set of data units to be verified with judgment constraints. Next, the script parser performs numerical threshold comparison, data format verification, and logical compliance judgment item by item based on the result judgment benchmarks bound to each data unit to be verified, synchronously recording abnormal fields and deviation values, generating a single judgment result set for each test item. Finally, the single judgment result sets of all test items are summarized, and the overall machine test conclusion is calculated by combining the anomaly circuit breaker rules of the production line test and the test item level weights. Standardized test result records are generated and synchronously fed back to the test scheduling module and the upper-level production tool, completing the entire production line test process.

[0053] Further, please refer to Figure 2 , Figure 2This is a flowchart of the script parsing process for this application. In the production line tool testing scenario, the script parser adopts a four-layer decoupled architecture consisting of an entry scheduling layer, a script parsing layer, a protocol adaptation layer, and an execution layer, enabling independent iteration of the test business logic and the underlying communication capabilities. The script content stored in the cloud is sent to the entry scheduling layer via the Transmission Control Protocol (TCP). The entry scheduling layer performs script file validity verification, test parameter parsing, and establishes the corresponding communication link based on the interface type of the device under test. The script parsing layer receives the structured script data output by the entry scheduling layer, performs lexical and semantic preprocessing and line-by-line interpretation and execution, and schedules the corresponding test process according to the test item dependency logic and execution order defined in the script. The protocol adaptation layer, based on the specific type of each test item in the script and the corresponding protocol specification, completes the packet encapsulation of downlink test commands and simultaneously unpacks and parses the execution fields of the uplink device response information, achieving complete decoupling between the test logic and the protocol format. The execution layer, as the underlying physical interaction unit, completes bidirectional data interaction with the device under test (DUT) via the corresponding physical communication channel. It can uniformly adapt to various communication channels such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Universal Serial Bus (USB), and serial ports. After all test items have been executed, the script parser finally returns the final judgment result of test pass or failure to the host production tool in the form of a standardized process exit code.

[0054] Second Embodiment This embodiment provides an exemplary scheme for determining a test script package. In this example, the model identifier of the device under test and the test task scope parameters in the production line test scheduling instruction are first parsed to generate benchmark query parameters. Then, based on the benchmark query parameters, model directory matching and script package version adaptation verification are completed. Finally, after file integrity verification and directory index reconstruction, a test script package that can be directly loaded and called by the script parser is generated. Step S10 includes steps A11 to A15: Step A11: Respond to the production line test scheduling instruction, parse the device under test model identifier and test task range parameters of the production line test scheduling instruction, and organize them to obtain the benchmark query parameters.

[0055] Step A12: Based on the model identifier of the benchmark query parameters, initiate a model directory matching query to the test specification library to determine the target directory corresponding to the model identifier.

[0056] Step A13: Verify the validity of the release of the test package in the target directory and its compatibility with the device version, and output the resource location information of the script package that has passed the matching verification.

[0057] Step A14: Determine the initial test package according to the script package resource location information, and perform file integrity verification and script format compliance verification on the initial test package to obtain a compliant test package.

[0058] Step A15: Reconstruct the directory index of the compliance test package according to the execution priority of the test items to generate the test script package that can be loaded and called by the script parser.

[0059] Test task scope parameters are scope constraints used to define the boundaries of this test execution and filter corresponding test items; they are a core component of the baseline query parameters. Examples include full-scale test identifier, specified test item list, retest item scope, and production workstation test permission scope. Baseline query parameters are a standardized set of retrieval parameters generated by integrating the device identifier and task scope, used to initiate a matching query to the test specification library; they serve as the input baseline for the script package matching process. Examples include full-scale device search fields, test scope filtering fields, and version verification baseline fields. The test specification library is a cloud-based resource library that centrally stores all device test script resources, version records, and release statuses; it is the unified storage and management carrier for test script packages. Examples include a cloud-distributed script resource library, a production line local specification cache library, and a version control configuration library. The target directory is a dedicated resource storage directory in the test specification library that corresponds one-to-one with the device identifier of the device under test; it is used to collect all test scripts and configuration files for the corresponding device. Examples include a device-specific script directory, a version branch subdirectory, and an auxiliary test configuration directory.

[0060] Release validity is a status attribute that characterizes whether a test package has been officially released and approved, and is in a production-ready state. It is used to filter out script package versions that are under testing or have been scrapped. Examples include officially released status, gray-scale release status, discontinued status, and pending approval status. Device version compatibility is a compatibility attribute that characterizes the compatibility between the test package version and the hardware and firmware version of the device under test. It is used to avoid test protocol interaction anomalies caused by version incompatibility. Examples include hardware version compatibility range, firmware version compatibility interval, and backward compatibility indicator. Script package resource location information are location parameters that mark the storage location, version number, and resource list of the target test package. They are used to accurately retrieve the corresponding test package files. Examples include cloud resource storage path, version unique identifier, and file list hash value. The initial test package is a set of raw test package files retrieved based on the resource location information, without verification processing. It is the object of subsequent compliance verification. Examples include the raw script file set, configuration file set, and resource description file. File integrity verification is a verification action that checks the completeness and data integrity of the initial test package files. It is used to exclude abnormal test packages that have experienced file loss or corruption during transmission. For example, file list completeness verification, file hash value verification, and compressed package integrity verification.

[0061] Script format compliance verification is a validation process that checks the syntax and field specifications of script files within the test package. It eliminates script files with syntax errors or formatting inconsistencies. Examples include script syntax compliance verification, field naming convention verification, and logical structure compliance verification. A compliant test package is a collection of test package files that have passed completeness and format verification and conform to production line test execution specifications. It is the object of directory index reconstruction. Test item execution priority is the execution order set according to the production line test process and test item dependencies, and it serves as the sorting basis for directory index reconstruction. Examples include basic communication test priority, functional test priority, performance test priority, and security verification priority. Directory index reconstruction is a process that reorders and indexes the test item scripts within the compliant test package according to execution priority, improving the loading and scheduling efficiency of the script parser.

[0062] In this example, when responding to a production line test scheduling instruction to generate baseline query parameters, the process can be performed using instruction message parsing. First, the message frame of the production line test scheduling instruction is decapsulated, and the model identifier field and test range field in the message body are extracted. After standardizing the extracted parameters, they are integrated to generate baseline query parameters in a unified format. Alternatively, a streaming instruction parsing method can be used, receiving scheduling instruction messages while parsing the corresponding parameter fields, verifying parameter validity, and accumulating and integrating the data to ultimately obtain complete baseline query parameters. This completes the collection and organization of query parameters.

[0063] After generating the baseline query parameters, the device model directory matching query process is initiated. Using the device model identifier field from the baseline query parameters as the search key, a precise matching query is launched to the test specification library. This process iterates through all device model directories in the specification library to locate the target directory that perfectly matches the device model identifier. Subsequently, for all test package versions in the target directory, the release validity and device model version compatibility are verified sequentially. Test packages that simultaneously meet the requirements of official release status and version compatibility covering the tested device version are selected, and the script package resource location information for the corresponding test package is output. Next, the initial test package is retrieved based on the resource location information. File integrity verification and script format compliance verification are performed on the initial test package sequentially, eliminating abnormal files with missing files or incorrect formats, resulting in a fully compliant test package. Finally, according to the preset test item execution priority rules, all test item scripts in the compliant test package are sorted and indexed, the directory index is reconstructed, and a test script package that can be directly loaded and called by the script parser is generated. In this way, through layered parameter parsing, matching verification and index reconstruction, the matching accuracy and loading execution efficiency of the test script package are improved, and production line test failures caused by version mismatch or file abnormalities are avoided.

[0064] For example, there are two ways to generate test script packages based on benchmark query parameters. The first is a centralized cloud-based full-scale matching verification. Based on the model identifier and test scope bound to the benchmark query parameters, a full-scale matching request is initiated directly from the parameter generation end to the cloud-based test specification library. The cloud specification library uniformly executes the entire process of directory matching, validity verification, and version adaptation verification. After successful verification, the complete initial test package is fully distributed to the production line testing end. After receiving the initial test package, the production line testing end performs integrity hash verification and format compliance verification file by file. After all verifications pass, the directory index is reconstructed according to the unified test item priority rules of the production line, and finally a standardized test script package is generated. This method adopts a centralized cloud-based management and full-scale distribution processing logic. All version verification and resource matching are uniformly executed in the cloud, ensuring the global consistency of script versions and effectively avoiding the problem of inconsistent script versions across different production lines.

[0065] The second method is edge-cached incremental matching verification. First, an edge specification cache library is deployed locally on the production line, pre-storing historical test script packages and version indexes for all commonly used models. Upon receiving the baseline query parameters, initial model directory matching and version pre-verification are performed in the local edge cache library. If the corresponding version exists locally and meets the validity requirements, the initial test package is directly retrieved from the local cache, and only a version consistency verification request is sent to the cloud. After confirming that the version has not changed, local verification and index reconstruction are directly performed. If the local cache version is outdated, only the differential incremental file is pulled from the cloud, and after incremental merging is completed locally, an initial test package is generated. Then, integrity verification, format verification, and index reconstruction are performed to finally obtain the test script package. This method uses edge cache pre-storage and incremental differential update processing logic. By pre-matching locally, it significantly reduces the amount of cloud data transmission and matching time, shortening the test startup pre-time and improving the efficiency of production line testing workflow.

[0066] In another implementation, the test specification library is deployed locally, stored in the production line's local configuration directory according to device type. Upon responding to the production line's test scheduling command, it first parses the device model identifier and test task scope parameters in the command and organizes them to obtain the baseline query parameters. Then, based on the device model identifier, it performs a device model directory matching query in the local configuration directory to determine the corresponding target directory. After verifying the release validity and device version compatibility of the test package in the target directory, it outputs the resource location information of the script package that has passed the matching verification. Subsequently, based on the location information, it retrieves the initial test package, obtains the compliant test package through file integrity verification and script format compliance verification, and finally reconstructs the directory index of the compliant test package according to the test item execution priority to generate a test script package that can be directly loaded and called by the local script parsing process.

[0067] Furthermore, in the mass production testing scenario of the video processor, after responding to the production line test scheduling instruction, the device under test (DUT) is identified as VP-6800, hardware version V2.1, and firmware version V1.3.5. The test task scope is full-scale factory functional testing, and standardized benchmark query parameters are generated. Based on the device identifier in the benchmark query parameters, a device directory matching query is initiated to the cloud test specification library to accurately locate the dedicated target directory corresponding to the VP-6800 model. The official release validity and device version compatibility of the V2.3 test package in the target directory are verified. After confirming its compatibility with the corresponding hardware and firmware versions, the resource location information of the script package that has passed the matching verification is output. According to the location information, an initial test package containing 32 functional test scripts is retrieved. File hash integrity verification and script syntax format compliance verification are performed sequentially. After removing one script with abnormal format, a compliant test package is obtained. Finally, the directory index is reconstructed according to the three-level execution priority of basic communication, core function, and performance index, generating a test script package that can be directly loaded and called by the script parser. This solution embeds all the protocol logic of the device under test into the device specification script. The backend service main program no longer expands continuously with the addition of test items. Adding 12 custom tests only requires updating the corresponding script files, without modifying the main program or recompiling and deploying. Each product is maintained separately with independent specification directories and script packages, ensuring that protocol differences between different models do not interfere with each other. Updating test items only requires replacing the corresponding script files in the cloud-based test package. Production lines can achieve hot updates by model, reducing model switching time by 80% compared to the original architecture. Meanwhile, the backend service focuses on assisting device scheduling and process control, with the script parser dedicated to handling device protocol interaction logic. Test engineers only need to write test scripts according to the device protocol specifications, without needing to participate in the code programming of the production tool's backend server, thus lowering the technical threshold for test iteration.

[0068] Third Embodiment Third Embodiment This embodiment provides an exemplary scheme for generating a test execution sequence. In this example, the lexical and semantic verification and logical structure recognition of the test script package are first completed by the entry scheduling module of the script parser to obtain the script syntax parsing structure. Then, the core rules of protocol interaction, data verification and result judgment are extracted by deep parsing of each test item to generate a metadata set. Subsequently, the execution path is arranged in combination with the production line abnormal circuit breaker rules to obtain the test execution link framework. Finally, the link nodes are bound with the adaptation entry and judgment handle and the context is preloaded to generate a test execution sequence that can directly drive the test process. Step S20 includes steps B11 to B14: Step B11: Verify the lexical semantics of the test script package through the entry scheduling module of the script parser, and identify the test item branch structure and execution dependency relationship within the test script package to obtain the script syntax parsing structure.

[0069] Step B12: Perform in-depth analysis of the script syntax parsing structure for each test item, determine the protocol interaction rules, data verification rules, and result judgment criteria corresponding to each test item, and generate a test item metadata set.

[0070] Step B13: Based on the test item metadata set, and combined with the abnormal circuit breaker rules of the production line test process, the execution path is arranged to obtain the test execution link framework.

[0071] Step B14: Bind the protocol adaptation entry and decision execution handle of the corresponding communication channel to the execution node in the test execution link framework, and preload the context to obtain the test execution sequence.

[0072] The entry scheduling module is the front-end processing unit in the script parser responsible for script loading, pre-verification, and process scheduling; it is the core of the script parsing process. Examples include the script loading unit, lexical verification unit, dependency analysis unit, and process scheduling unit. Lexical semantics are script attributes that characterize the writing style, logical syntax correctness, and semantic accuracy of test scripts; they are the core verification dimensions for script pre-verification. Examples include keyword spelling correctness, grammatical structure compliance, logical expression consistency, and parameter definition completeness. The test item branch structure is the multi-branch execution path structure within the test script, consisting of conditional judgments and loop logic; it is the core object for identifying the script's logical structure. Examples include conditional jump branches, exception handling branches, loop execution branches, and retest trigger branches. Execution dependencies are the pre-execution conditions and sequential execution constraints between different test items; they are the core basis for execution path orchestration. Examples include communication initialization pre-dependencies, parameter configuration pre-dependencies, functional testing pre- and post-dependencies, and security verification pre-dependencies.

[0073] The script syntax parsing structure is a standardized parsing product generated after lexical and semantic verification and structure recognition. It structurally represents the script logic and dependencies, and serves as an intermediate processing object for deep parsing of test item rules. Examples include abstract syntax tree structures, test item node topologies, dependency mapping tables, and branch logic structures. Protocol interaction rules define the execution specifications for message interaction timing, encapsulation formats, and transmission channels between test items and the device under test. They are the core basis for protocol adaptation and message generation. Examples include message frame structure rules, send / receive timing rules, channel matching rules, and parameter mapping rules. Data verification rules define the dimensions, methods, and anomaly judgment criteria for device response data verification. They are the execution basis for response data verification. Examples include field integrity verification rules, numerical range verification rules, format compliance verification rules, and checksum verification rules.

[0074] The test item metadata set is a structured collection of metadata that gathers all test item interactions, verifications, and judgment rules. It is the core input for execution path orchestration. Examples include test item attribute metadata, rule parameter metadata, dependency constraint metadata, and priority identifier metadata. Circuit breaker rules are pre-defined control rules in production line testing that terminate the test or redirect the process when a test exception reaches a trigger condition. They are used to avoid invalid testing and equipment risks. Examples include critical item failure circuit breaker rules, consecutive failure circuit breaker rules, communication exception circuit breaker rules, and timeout circuit breaker rules. The test execution link framework is an orchestrated test process topology framework that includes normal execution paths and exception branch paths. It is the basic carrier for binding execution nodes. Examples include the main execution link, exception branch link, circuit breaker termination link, and retest rollback link. Execution nodes are independent execution units corresponding to a single test item in the test execution link framework. They are the objects on which protocol adaptation and result judgment are mounted. Examples include test item execution nodes, condition judgment nodes, exception handling nodes, and process jump nodes.

[0075] The protocol adaptation entry point is a standardized interface for the execution node to connect to the protocol adaptation layer, used to decouple test logic from protocol encapsulation. Examples include Transmission Control Protocol (TCP) channel adaptation entry points, serial port channel adaptation entry points, Universal Serial Bus (USB) channel adaptation entry points, and User Datagram Protocol (UDP) channel adaptation entry points. The decision execution handle is bound to the execution node and used to invoke the result decision logic, directly triggering the result verification process for the corresponding test item. Examples include numerical comparison decision handles, state matching decision handles, logic verification decision handles, and timing verification decision handles. The context is a collection of prerequisite parameters, state data, and environment configuration information required during test execution; pre-loading this information can improve execution efficiency. Examples include device communication parameters, test environment configuration, historical execution states, and global variable parameters.

[0076] In this example, when processing the test script package through the script parser's entry scheduling module to obtain the script syntax parsing structure, a full load scan approach can be used. This involves loading all script files within the test script package into memory, performing lexical scanning and syntax verification line by line, and simultaneously identifying branch logic nodes and test item dependencies within the script to build a complete script syntax parsing structure. Alternatively, a streaming incremental parsing approach can be used. This involves reading the test script package file content while simultaneously performing segment-by-segment lexical and semantic verification, identifying test item boundaries and dependency constraints, and accumulating logical structures to obtain a complete script syntax parsing structure. This completes the pre-verification and structure parsing of the script.

[0077] After constructing the script syntax parsing structure, a deep parsing process for test items is initiated. For each test item node in the script syntax parsing structure, the corresponding protocol interaction rules, data verification rules, and result judgment benchmarks are extracted node by node, generating standardized metadata units for each test item. The metadata units of all test items are then aggregated to form a test item metadata set. Subsequently, the exception circuit breaker rules of the production line test process are loaded, the execution priority and dependency constraints in the test item metadata set are sorted out, the main execution path is built, and exception judgment branches and circuit breaker jump nodes are embedded. After the execution path is orchestrated, the test execution link framework is obtained. Finally, the corresponding protocol adaptation entry and judgment execution handle of the communication channel are matched and bound to each execution node in the link framework, and the global parameters and environment context required for test execution are preloaded synchronously. Finally, a structured test execution sequence is generated. In this way, through layered parsing, orchestration, and binding processing, the test logic and execution scheduling are decoupled, improving the execution efficiency and exception adaptation capability of the test sequence, and avoiding the problem of insufficient expansion flexibility caused by the solidification of test logic.

[0078] For example, there are two ways to generate test execution sequences through script syntax parsing structures. The first is a serial, node-by-node parsing and orchestration method. Based on the original writing sequence of the script syntax parsing structure, starting from the initial node, individual test item nodes are selected sequentially for deep parsing. Corresponding protocol interaction rules, data verification rules, and result judgment criteria are extracted, and single-test item metadata is generated and stored in a metadata set. After parsing each test item, its dependencies with parsed nodes are simultaneously determined, and the link topology is updated. After all test items are parsed, exception circuit breaker rules are uniformly loaded to supplement the link with exception branches and circuit breaker nodes, forming a test execution link framework. Subsequently, the binding of protocol adaptation entry points and judgment execution handles is completed node by node, and the corresponding context information is preloaded, ultimately generating a complete test execution sequence. This method employs a time-locked, node-by-node serial parsing and dynamic link accumulation processing logic. By parsing sequentially and building the link step by step, in accordance with the original script logic, the temporal consistency and dependency accuracy of the test logic are ensured.

[0079] The second approach involves parallel modular parsing and orchestration. First, the script syntax parsing structure is globally decomposed, dividing it into multiple independent parsing groups based on the functional category and dependency level of the test items. Cross-group dependency nodes and demarcation points are marked between groups, generating multiple parsing units without internal dependencies. Then, parallel deep parsing is simultaneously initiated for all parsing units, with each unit independently extracting the rules and benchmarks for the corresponding test items, generating a subset of group metadata. After all group parsing is complete, the metadata is uniformly aggregated to form a test item metadata set. Then, centralized path orchestration is performed based on global dependencies and exception circuit breaker rules to construct a complete test execution chain framework. Subsequently, protocol adaptation entry points and decision execution handles are bound to execution nodes in batches according to channel type, and common context information is preloaded in batches, ultimately generating a test execution sequence. This method employs global group decomposition and multi-module parallel parsing processing logic. By splitting the large script package into parallel processing units through pre-structural grouping, the total parsing and orchestration time is shortened, effectively improving script parsing efficiency and reducing test preparation time.

[0080] Furthermore, in the full-scale functional testing scenario of the video processor production line, the script parser's entry scheduling module loads a model test script package containing 36 functional test scripts, performs lexical and semantic verification file by file, and simultaneously identifies 8 conditional jump branch structures and 12 sets of pre- and post-execution dependencies of test items within the script, outputting a standardized script syntax parsing structure. Subsequently, the syntax parsing structure is deeply decomposed for each test item, determining the protocol interaction rules, data verification rules, and result judgment benchmarks for each test item. This includes 11 serial communication tests, 18 Ethernet protocol tests, and 7 USB interaction tests, which are then aggregated to generate a test item metadata set containing 36 sets of test item metadata. Based on this metadata set, and combined with the production line's preset abnormal circuit breaker rules of "a single failure of a key item triggers a retest, and two consecutive failures trigger a complete circuit breaker termination," the execution path is arranged to construct a test execution link framework containing 1 main execution link, 3 abnormal retest branch links, and 2 circuit breaker termination links. Finally, the corresponding communication channel protocol adaptation entry and judgment execution handle are bound to each execution node in the link framework, and execution context parameters such as device communication address, baud rate, and response timeout threshold are preloaded synchronously to generate a structured test execution sequence that can directly drive protocol interaction.

[0081] Fourth embodiment This embodiment provides an exemplary scheme for orchestrating a test execution chain framework. In this example, based on the test item metadata set and the circuit breaker rules for production line testing, the pre-dependencies, execution priorities, and failure impact levels between each test item are first determined. Then, an initial test execution path is built according to the serial execution baseline, and corresponding exception judgment branch nodes are embedded. Subsequently, jump targets and circuit breaker triggering conditions are configured for each exception branch, and continuous failure counts and whole-machine retest triggering logic are associated. Finally, redundant branches are eliminated through dependency loop verification and path reachability verification, and a unified state transmission format is achieved, resulting in a complete test execution chain framework. Please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the fourth embodiment of the testing method for the production tool of this application. Step B13 includes steps C11 to C14: Step C11: Based on the test item metadata set and the exception circuit breaker rules, determine the prerequisite dependencies, execution priorities, and failure impact levels among the test items.

[0082] Step C12: Based on the execution priority and the prerequisite dependency, construct an initial test execution path according to the serial execution baseline, and embed an exception judgment branch node corresponding to the failure impact level after the test item node to generate the initial execution link.

[0083] Step C13: Configure the corresponding jump target and circuit breaker triggering condition for the abnormal judgment branch node in the initial execution link according to the abnormal circuit breaker rules, and associate the continuous failure count and the whole machine retest triggering logic to obtain the preliminary framework of the execution link.

[0084] Step C14: Perform dependency loop verification and path reachability verification on the preliminary execution link framework, eliminate redundant branches and unify the state transfer format between nodes to obtain the test execution link framework.

[0085] Pre-dependencies are the sequential execution constraints between different test items, representing the necessary prerequisites for the completion and passing of a preceding test item to initiate a subsequent test item. They are the core sorting basis for constructing execution paths. For example, communication establishment testing is a prerequisite for all functional tests, parameter configuration testing is a prerequisite for performance testing, and basic functional testing is a prerequisite for advanced functional tests. Failure impact level is a graded identifier based on the degree of impact of test item failure on the overall system's passability, used to match the corresponding intensity of exception handling logic. For example, fatal failure level, severe failure level, general failure level, and minor failure level. The serial execution baseline is the benchmark execution mode in production line testing, executing test items sequentially from high to low priority. It is the basic framework for constructing the initial execution path. For example, single-channel serial test baseline, single-station item-by-item test baseline, and single-device full-item serial baseline. The initial test execution path is a serial path of test items containing only normal execution flow and without embedded exception branches. It is the basic carrier for subsequent supplementary exception logic. For example, the main path for full-item normal execution, the serial path for specified test items, and the special execution path for retest items.

[0086] A test item node is an independent execution unit corresponding to a single test item in the initial execution path, carrying the execution logic and output results of the test item. Examples include communication test nodes, functional verification nodes, performance testing nodes, and status reading nodes. An exception judgment branch node is a judgment unit embedded after the test item node, used to determine whether the test result is abnormal and trigger the corresponding branch logic. Examples include single test failure judgment nodes, timeout exception judgment nodes, communication interruption judgment nodes, and parameter out-of-bounds judgment nodes. The initial execution chain is the preliminary execution chain structure after embedding the exception judgment branch node, containing the normal execution path and basic exception judgment nodes, but without specific jump and circuit breaker logic configured. The jump target is the target node position for the process jump after the exception judgment branch is triggered, used to define the execution direction after an exception occurs. Examples include retest jump target, jump to the next test item target, system termination target, and rollback to the previous item target.

[0087] Circuit breaker trigger conditions are threshold conditions that force the cancellation of a test process. When these conditions are met, the current test process is terminated directly to avoid invalid execution. Examples include single failure trigger conditions for critical items, three consecutive test failures trigger conditions, continuous communication timeout trigger conditions, and failure to meet security standards trigger conditions. Consecutive failure counts are a counting mechanism used to count the number of consecutive failures of the same test and the cumulative number of failures of tests of the same category. It is the core basis for circuit breaker triggering. Examples include consecutive failure counts for a single test item, cumulative failure counts for tests in the same channel, and cumulative failure counts for the entire system test. The system retest trigger logic is the control logic that triggers the re-execution of all or part of the system's test items when the failure condition meets preset conditions, used to reduce the probability of false tests. Examples include single failure of a critical item triggering retesting, cumulative failures reaching a threshold triggering system retesting, and communication anomalies triggering link retesting. The preliminary execution link framework is the initial link structure after configuring the jump target, circuit breaker conditions, and retesting logic. It contains complete normal and abnormal execution logic and has not yet undergone validity verification and optimization.

[0088] Dependency loop verification is a verification action that performs loop verification on the dependencies of test items in the execution chain, used to check for logical errors such as circular dependencies and missing dependencies. Examples include pre-dependency loop verification, branch jump dependency verification, and retest chain dependency verification. Path reachability verification is a verification action that verifies the reachability of all branch paths in the chain, used to check for unreachable dead nodes and infinite loops that cannot be exited. Examples include normal path reachability verification, abnormal branch reachability verification, and circuit breaker-terminated path reachability verification. Redundant branches are redundant branch nodes in the chain that are repeated, invalid, or never triggered. Removing them simplifies the chain structure and improves execution efficiency. Examples include abnormal branches with repeated judgments, invalid branches with mutually exclusive conditions, and redundant jump branches with overlapping logic. Status transmission format is a unified format specification for transmitting execution status and test result data between adjacent nodes in the chain. A unified format ensures the consistency of data interaction between nodes. Examples include result status code format, parameter dictionary format, error message encapsulation format, and context transmission format.

[0089] The test execution link framework is a standardized test execution link structure that has been verified and optimized, and is structurally complete and logically self-consistent. It serves as the basic carrier for subsequent binding of adaptation entry points and generation of execution sequences.

[0090] In this example, when parsing test item attributes based on the test item metadata set and the exception circuit breaker rules, the process can be performed using metadata tag matching. First, all metadata units in the test item metadata set are traversed, and the pre-dependency tags, priority identifiers, and failure level tags for each test item are extracted. After tag matching and logical verification, the pre-dependency relationships, execution priority ranking, and failure impact level classifications of all test items are obtained. Alternatively, a dependency topology deduction method can be used. First, the root node test item without pre-dependencies is identified from all test items. Then, the dependency chain of subsequent test items is deduced layer by layer. Simultaneously, the corresponding failure impact level is matched in conjunction with the level requirements of the exception circuit breaker rules, ultimately obtaining the complete test item dependency, priority, and level attributes, thus completing the core attribute parsing of the test item.

[0091] After parsing the core attributes of the test items, the initial execution path construction process is initiated. Based on execution priority from high to low, and combined with the constraints of pre-dependencies, all test item nodes are sequentially connected according to the serial execution baseline to form the initial test execution path. Subsequently, after each test item node, a matching exception handling branch node is embedded based on the failure impact level of that test item, generating an initial execution chain containing both normal paths and exception handling nodes. Next, according to the exception circuit breaker rules, a corresponding jump target node and circuit breaker trigger threshold condition are configured for each exception handling branch node. Simultaneously, the continuous failure counting mechanism and the whole-machine retest trigger logic are associated with the corresponding decision branches, resulting in a preliminary framework of an execution chain with complete exception handling logic. Finally, a full-link dependency loop verification and path reachability verification were performed on the initial framework of the execution link. Issues such as circular dependencies and path deadlocks were investigated and corrected, and logically redundant invalid branches were eliminated. The data format for state transmission between all nodes was unified, resulting in a structurally standardized and logically self-consistent test execution link framework. Through layered attribute parsing, link construction, and verification optimization, the logical rigor and anomaly adaptability of the test execution link were improved, avoiding abnormal interruptions in production line testing caused by logical defects in the link.

[0092] For example, there are two ways to generate a test execution link framework from a test item metadata set. The first is a serial progressive link orchestration. Starting from the highest priority root test item node, the execution priority is arranged from highest to lowest. The pre-dependencies of each test item are checked one by one and connected to the serial execution baseline. For each connected test item node, an exception judgment branch node corresponding to the failure level is simultaneously embedded, and the jump target and circuit breaker trigger condition are configured for that branch, along with the corresponding counting and retesting logic. After all test item nodes are connected, dependency loop verification and path reachability verification are performed uniformly. Redundant branches generated during the construction process are removed, and the state transmission format is standardized, ultimately generating the test execution link framework. This method uses a node-by-node progressive construction and real-time branch configuration processing logic. Through serial orchestration that fits the priority order, it ensures the accuracy of test item dependencies and the matching degree of branch configuration.

[0093] The second approach is hierarchical clustering-based link orchestration. First, all test items are clustered into four levels based on their failure impact severity: critical, severe, general, and minor. Within each level, they are further divided into multiple independent dependency groups based on their pre-dependencies. Then, for each level, serial path construction and abnormal branch embedding within each group are executed in parallel, with the construction processes of different dependency groups within the same level not interfering with each other. After the link construction within all levels is completed, the links between levels are connected from highest to lowest severity. Circuit breaker triggering conditions and retesting logic are uniformly configured for abnormal branches across the entire link, forming a preliminary execution link framework. Finally, full-link dependency closed-loop verification, reachability verification, and redundant branch removal are performed centrally, and a unified node state transmission format is established to generate the final test execution link framework. This method employs hierarchical clustering and parallel construction within levels. By splitting the complex link into multiple parallel processing units through pre-level and dependency grouping, it shortens the total orchestration time.

[0094] In another implementation, there is no need to build a separate graph-based link orchestration engine. The link logic is constructed based on the native loop, conditional judgment, and result confirmation instructions in the test script file. First, the pre-dependencies, execution priorities, and failure impact levels of each test item are determined by combining the test item metadata set and the exception circuit breaker rules. Then, the test item nodes are connected in series according to the serial execution baseline to form an initial test execution path. By parsing the result confirmation instructions in the script, the corresponding level of exception judgment branch is embedded after the test item node. The loop instructions are used to configure the retest jump target and continuous failure count trigger rules for the exception branch. The circuit breaker rules are matched to the trigger logic of the whole machine retest to form a preliminary framework of the execution link. Finally, the dependency loop check and execution path validity verification of the link are completed by script syntax compliance verification. Redundant branches with repeated logic are eliminated and the state transmission format between each node is unified to obtain a test execution link framework that can be directly driven.

[0095] Furthermore, in the full-scale functional testing scenario of the video processor production line, based on the metadata set of test items containing 36 tests and the production line's preset anomaly circuit breaker rules, 12 sets of pre- and post-deployment relationships of test items were identified, and execution priorities were divided into four levels: core security, basic functions, performance indicators, and appearance indicators. Correspondingly, 6 critical, 10 severe, 15 general, and 5 minor failure impact levels were defined. Then, based on the execution priority and pre-deployment constraints, an initial test execution path was built along the serial execution baseline. An anomaly judgment branch node corresponding to the failure impact level was embedded after each test item node, generating an initial execution chain containing 36 main execution nodes and 36 judgment nodes. Next, according to the anomaly circuit breaker rules, corresponding jump targets and circuit breaker trigger conditions were configured for each anomaly judgment branch node. The logic of retesting after two consecutive failures in a single test, circuit breaker triggering for a single fatal failure, and triggering a full-machine retest after three cumulative severe failures was associated, resulting in a preliminary framework for the execution chain. Finally, full-link dependency closed-loop verification and path reachability verification were carried out on the preliminary framework. Two logically redundant duplicate decision branches were removed, and the state transmission format of status codes and parameter dictionaries between all nodes was unified, resulting in a logically consistent and structurally complete test execution link framework.

[0096] Fifth embodiment This embodiment provides an exemplary scheme for generating and sending test interaction messages. In this example, the target communication channel type and protocol format constraints of the test execution sequence are first parsed node by node. The corresponding channel's protocol adaptation rule template is matched to obtain a test instruction set to be encapsulated with a channel identifier. Then, according to the template, field mapping and message encapsulation are performed according to the frame structure specification of the corresponding channel, and message sequence identifiers and integrity verification fields are embedded to obtain a set of test interaction messages. Subsequently, the channel transmission compliance of the message set is verified, and a message queue to be sent is generated by sorting the message set according to the test execution sequence and channel bandwidth attributes. Finally, the physical communication channel sending interface is invoked to send the messages frame by frame to the lower-level device under test according to the queue order. Step S30 includes steps D11~D14: Step D11: parse the target communication channel type and protocol format constraints of the test execution sequence node by node, match the corresponding channel protocol adaptation rule template, and obtain the test instruction set to be encapsulated with channel identifier.

[0097] Step D12: According to the protocol adaptation rule template, the instructions in the test instruction set to be encapsulated are mapped and encapsulated according to the frame structure specification of the corresponding channel, and the message sequence identifier and integrity verification field are embedded to obtain the test interaction message set.

[0098] Step D13: Verify the channel transmission compliance of the test interaction message set. After the verification is passed, sort the messages according to the test execution sequence and channel bandwidth attributes to generate a message queue to be sent in an orderly manner.

[0099] Step D14: Retrieve the sending interface of the physical communication channel and send the test interaction message to the device under test of the lower-level machine frame by frame according to the order of the message queue to be sent.

[0100] The target communication channel type refers to the category of the physical communication link between the host computer and the device under test (DUT) for transmitting test commands. It is the core basis for matching protocol adaptation rules. Examples include Ethernet Transmission Control Protocol (TCP) channel, Ethernet User Datagram Protocol (UDP) channel, Universal Serial Bus (USB) channel, and Serial Communication Interface (SCI) channel. Protocol format constraints are the specifications for message structure, field length, and data format corresponding to the communication channel. They are the constraint standards for message encapsulation. Examples include frame header / tail format constraints, field length constraints, byte order constraints, and checksum position constraints. Protocol adaptation rule templates are predefined message encapsulation rule templates corresponding to each communication channel. They contain frame structure definitions and field mapping relationships, used to standardize the conversion of test commands to channel messages. Examples include TCP channel protocol templates, serial port Modbus protocol templates, and USB custom protocol templates. The channel identifier is a unique identifier field marking the communication channel to which the message belongs. It is used to distinguish between commands to be encapsulated from different channels, avoiding channel confusion. Examples include channel number identifier, interface name identifier, and protocol type identifier. The test command set to be encapsulated is a set of original test commands carrying the channel identifier that have not yet undergone protocol encapsulation; it is the input object for message encapsulation. A frame structure specification is a standard for the composition of message frames corresponding to a communication channel, defining the arrangement rules of the frame header, instruction field, data field, check field, and frame trailer. Examples include fixed-length frame structures, variable-length frame structures, and frame structures with address fields.

[0101] Field mapping is the process of mapping the instruction encoding, parameter data, and other content in the test command to the specified field positions in the message frame structure, ensuring accurate correspondence of message content. Message encapsulation is the process of assembling the test command content into a complete and transmittable message according to the frame structure specification, and is a core step in protocol adaptation. Message sequence identifier is a sequence number field embedded in the message, used to mark the transmission order of the messages, ensuring that the lower-level machine can process and align them in order after receiving them. Examples include frame sequence number field, serial number field, and packet count field. Integrity check field is a check data field embedded in the message, used by the lower-level machine to verify whether data corruption or loss has occurred during message transmission. Examples include cyclic redundancy check field, sum check field, and XOR check field. The test interaction message set is the collection of all test messages after encapsulation and check field embedding, and is the object of transmission compliance verification.

[0102] Channel transmission compliance refers to whether a message conforms to the transmission specifications of the corresponding communication channel, covering multiple verification dimensions such as length compliance, format compliance, and checksum compliance. Test execution sequence refers to the order in which each test item is executed, and is one of the core bases for message sending ordering. Channel bandwidth attributes are the transmission capacity attributes of the corresponding communication channel, such as transmission rate and maximum frame length, and are a reference for adjusting sending priority and sending rhythm. Sending priority is the order in which messages are sent, determined comprehensively by combining execution sequence and channel bandwidth to ensure efficient and sequential execution of the test process. The message queue to be sent is the message queue after compliance verification and priority sorting; it is the direct input object of the sending interface, and messages are sent sequentially according to the queue order. The physical communication channel sending interface is the hardware sending driver interface on the host computer side corresponding to each communication channel, used to execute the actual transmission of messages.

[0103] In this example, when parsing the test execution sequence node by node to match the test instruction set to be packaged, a full traversal matching method can be used. First, all nodes of the test execution sequence are loaded, and the channel type and protocol constraint parameters within each node are extracted. These parameters are then matched one by one with a pre-stored protocol adaptation rule template library. After matching, each instruction is marked with a corresponding channel identifier, and the resulting set of test instructions to be packaged is obtained. Alternatively, a streaming incremental parsing method can be used. This involves simultaneously reading the node data of the test execution sequence, parsing the channels and protocol constraints, matching the corresponding templates, and marking the channel identifiers, accumulating and generating the set of test instructions to be packaged. This completes the channel matching and aggregation of instructions.

[0104] After obtaining the test instruction set to be encapsulated, the message encapsulation process is initiated. Based on the protocol adaptation rule template corresponding to each instruction, field mapping is performed according to the frame structure specification of the corresponding channel. Instruction codes, test parameters, and other content are filled into the corresponding fields of the message. Simultaneously, an incremental message sequence identifier and a calculated integrity verification field are embedded. After all instructions are encapsulated, a set of test interaction messages is obtained. Subsequently, a frame-by-frame channel transmission compliance check is performed on the message set to investigate issues such as frame structure anomalies, field out-of-bounds errors, and verification errors. After passing the check, the messages are prioritized based on the test execution timing requirements and the bandwidth attributes of each channel, generating an ordered queue of messages to be sent. Finally, the sending interface of the corresponding physical communication channel is invoked, and the test interaction messages are sent frame by frame to the device under test on the lower-level machine according to the order of the message queue. This layered template matching, encapsulation verification, and ordered sending ensures the accuracy and timing consistency of message transmission, avoiding test anomalies caused by protocol mismatches and out-of-order transmission.

[0105] For example, there are two ways to convert the test execution sequence into messages and send them. The first is a single-channel serial frame-by-frame encapsulation and sending method. Based on the node order of the test execution sequence, each test instruction is extracted, matched with the corresponding protocol template to complete the single-frame message encapsulation, and the single-frame compliance verification is completed simultaneously. After the verification is passed, it is immediately sent to the device under test through the corresponding channel sending interface. The encapsulation and sending of the next frame is only started after receiving a confirmation response from the device. This method uses a serial processing logic of frame-by-frame encapsulation and real-time sending, which provides precise timing control, high single-link stability, and allows for real-time adjustment of the sending rhythm according to the device response, avoiding message accumulation and instruction conflicts.

[0106] The second method involves multi-channel parallel batch encapsulation and delivery. First, all nodes in the test execution sequence are grouped according to the target communication channel type. Instructions for the same channel are grouped together. Different channel groups simultaneously initiate batch message encapsulation and compliance verification. After each group independently completes the encapsulation and verification of its own group's messages, it generates a queue of messages to be sent for that channel based on the bandwidth attributes and execution timing of its channel. Subsequently, each channel initiates the sending process in parallel, independently delivering messages according to its respective queue order, with the execution progress between channels not interfering with each other. This method employs channel grouping and multi-channel parallel processing logic, fully utilizing multi-interface communication capabilities, shortening the overall message delivery time, and improving the execution efficiency of production line testing.

[0107] Furthermore, in the full-scale functional testing scenario of the video processor production line, the test execution sequence containing 36 execution nodes was parsed node by node. Three types of target communication channels—Ethernet TCP, RS232 serial port, and USB HID—and their corresponding protocol format constraints were identified. Dedicated protocol adaptation rule templates for each of the three channels were matched and retrieved, generating a set of 36 test instructions to be encapsulated, each carrying a corresponding channel identifier. Based on the protocol adaptation rule templates for each channel, the instructions to be encapsulated were mapped to fields and encapsulated according to the corresponding frame structure specifications. A 16-bit incremental message sequence identifier and a CRC16 integrity check field were embedded frame by frame, resulting in a set of test interaction messages containing 36 frames of standard format messages. After verifying the channel transmission compliance of all messages frame by frame and ensuring all messages passed, the transmission priority was sorted based on the test execution timing and the bandwidth attributes of each channel, generating an orderly queue of messages to be sent. Finally, the sending interface of the corresponding physical communication channel was retrieved, and the test interaction messages were sent frame by frame to the device under test on the lower-level machine according to the queue order.

[0108] Sixth Embodiment This embodiment provides an exemplary scheme for generating test results from verification test response data. In this example, the test response data returned by the lower-level machine is first received. Unpacking and frame integrity verification are performed according to the protocol specifications of the corresponding communication channel. Then, timing alignment and deduplication are performed based on the message sequence identifier to obtain the original response data. Subsequently, the original response data is mapped and matched one by one with the test item nodes of the test execution sequence. The verification feature fields of each test item are associated with the result judgment benchmark to generate a set of data units to be verified. Then, the script parser performs numerical threshold comparison, format verification, and logical judgment item by item according to the judgment benchmark, and records abnormal information to obtain a set of individual judgment results. Finally, all individual results are summarized, and the overall machine test conclusion is calculated by combining the production line test abnormality circuit breaker rules and the test item level weights to obtain the test results of the device under test. Step S40 includes steps E11~E14: Step E11: Receive the test response data returned by the lower-level machine, unpack and verify the frame integrity according to the protocol specifications of the corresponding communication channel, and perform timing alignment and deduplication according to the message sequence identifier to obtain the original response data.

[0109] Step E12: Map and match the original response data with the test item nodes of the test execution sequence one by one, determine the feature field to be verified and the result judgment benchmark corresponding to each test, and obtain the set of data units to be verified.

[0110] Step E13: The script parser performs numerical threshold comparison, data format verification, and logical compliance judgment on each item according to the result judgment criteria of the data unit to be verified, and records the abnormal fields and deviation values ​​to obtain a single judgment result set.

[0111] Step E14: Summarize the individual judgment result set of the test items, combine the abnormal circuit breaker rules of the production line test with the test item level weight to calculate the whole machine test conclusion, and obtain the test result of the device under test.

[0112] Frame integrity verification is a check that verifies the frame structure and check fields of a response message, used to detect data corruption, loss of bits, and packet errors during transmission. Examples include cyclic redundancy check, frame header / tail matching check, and message length check. Deduplication is the process of removing and retaining repeatedly received response messages with the same sequence identifier to avoid duplicate checks affecting the accuracy of the results. The original response data is a structured and valid set of response data obtained after unpacking, verification, alignment, and deduplication; it is the object of subsequent test item matching. The feature fields to be verified are the core parameter fields in the original response data used to determine whether a test item is qualified or not; they are the direct verification objects of the results. Examples include output voltage values, signal frequency values, status code fields, and function feedback flags.

[0113] The set of data units to be verified is a collection of verification units formed by binding and associating response feature fields with corresponding judgment benchmarks. It serves as the input object for the script parser to perform judgments. Numerical threshold comparison is a verification method that compares the actual value of the field to be verified with the threshold range in the judgment benchmark. It is used to determine whether numerical parameters are qualified. Examples include upper and lower limit threshold comparison, tolerance range comparison, and nominal value deviation comparison. Logical compliance judgment is a verification method that verifies whether the logical relationships and linkage states of the test results conform to the benchmark rules. It is used to determine whether logical functions are normal. Examples include state linkage logic judgment, condition triggering logic judgment, and timing logic judgment. Abnormal fields are fields determined to be non-compliant with benchmark requirements during the verification process, used to locate specific abnormal locations. Deviation values ​​are the difference between the actual value and the benchmark threshold, used to quantify the degree of abnormality and provide data support for subsequent analysis.

[0114] The individual judgment result set is a collection of pass / fail conclusions generated after verifying each test item individually. It includes anomaly details and deviation data and forms the basis for calculating the overall system test result. Test item level weights are weighting coefficients set according to the importance of each test item, used to weight and calculate the overall pass / fail rating of the entire system test. Examples include fatal item weights, severe item weights, general item weights, and minor item weights. The overall system test conclusion is the final conclusion on the overall system pass / fail status calculated by integrating all individual results, circuit breaker rules, and weights; it is the final output of the single-device test.

[0115] In this example, when receiving test response data from the lower-level machine to obtain the raw response data, it can be processed uniformly after full reception. First, all response messages in the current batch are received. Then, frame-by-frame unpacking and integrity verification are performed according to the protocol specifications. After successful verification, the entire data is sorted sequentially and duplicate messages are removed based on the message sequence identifier, ultimately resulting in well-organized raw response data. Alternatively, a streaming incremental processing method can be used, where frame-by-frame unpacking and integrity verification are performed while receiving response messages from the lower-level machine, and real-time alignment and deduplication are performed based on the sequence identifier, accumulating raw response data to complete the pre-processing and organization of the response data.

[0116] After obtaining the raw response data, the test item mapping and matching process is initiated. Each data point in the raw response data is matched one-to-one with the test item nodes in the test execution sequence. The feature fields to be verified in each response data point are extracted, and the preset result judgment benchmark for that test item is synchronously associated. A data unit to be verified, bound to verification data and judgment rules, is generated for each test item. All units are aggregated to form a set of data units to be verified. Subsequently, the script parser performs numerical threshold comparison, data format verification, and logical compliance judgment for each data unit to be verified, according to the bound result judgment benchmark. Abnormal fields that fail verification are simultaneously marked and recorded along with their corresponding deviation values. After all test items are verified, a single-item judgment result set is generated. Finally, the single-item judgment results of all test items are aggregated, and the abnormal circuit breaker rules of the production line test are used to determine whether to trigger circuit breaker termination. The overall pass rate of the entire machine is then calculated based on the test item level weights, ultimately generating the test results for the device under test, which include the overall machine conclusion and detailed information. This layered data cleaning, matching verification, and aggregation calculation improves the accuracy and standardization of test result judgment, avoiding test result errors caused by data misalignment and inconsistent rules.

[0117] For example, there are two ways to obtain test results from the verification test response data. The first is a serial frame-by-frame real-time judgment. According to the order of the test execution sequence, each frame of test response data is received and immediately unpacked, its integrity is checked, and its timing is aligned. After matching the result judgment benchmark of the corresponding test item, the single-item pass / fail judgment is completed in real time. The single-item result is output before starting the sending and receiving judgment of the next frame of test message. This method adopts a serial processing logic of receiving and judging frame by frame, which has strong real-time judgment. It can trigger abnormal branches and circuit breaker logic in real time according to the single-item judgment result, which can terminate invalid tests in a timely manner and improve the testing efficiency of abnormal devices.

[0118] The second method involves batch aggregation and centralized judgment. First, it continuously receives response data for all test items and temporarily stores it in a local cache. After all test interaction messages have been sent and all response data has been received, it uniformly performs unpacking, verification, and timing alignment deduplication of all data. Then, it batch-compiles test item mapping matching and item-by-item verification and judgment, generating a single judgment result set for all test items at once. Finally, it centrally aggregates and calculates the overall system test conclusion. This method uses a full-data reception and centralized judgment processing logic, reducing frequent switching of judgment logic, resulting in high data processing centralization. It allows for batch reuse of judgment calculation resources, improving overall judgment processing efficiency and adapting to the high-cycle testing needs of production lines.

[0119] Furthermore, during the verification and judgment process, the original message stream transmitted back from the lower-level machine is first captured by the receiving driver of the corresponding communication channel. The protocol parsing component is then called to disassemble the message header, data field, and verification field frame by frame according to the predefined frame structure rules. Simultaneously, the integrity verification algorithm is called to check the verification fields and eliminate abnormal frames with structural damage or verification failure. Then, the sequence identifier field in the message is extracted and compared with the sequence ledger of the sent messages one by one. The sequence is rearranged in ascending order of the sequence number, and redundant messages with duplicate sequence identifiers are discarded. The structured original response data is then output. Subsequently, using the unique identifier of the node in the test execution sequence as the association key, the original response data is matched one by one to the corresponding test item node. The pre-set list of fields to be verified is retrieved from the node metadata, and the corresponding field values ​​are located and extracted from the response data. At the same time, the pre-configured result judgment benchmark rules for the test item are attached. The field values ​​and benchmark rules are packaged into independent data units to be verified. All units are collected in the order of test item execution to form a set of data units to be verified. Next, the script parser's built-in judgment engine traverses the set of data units to be verified, executing three types of verification logic for each unit in sequence. For numerical fields, the threshold comparison operator is called to verify whether they fall within the upper and lower limits and tolerances specified by the benchmark. For format fields, the format verification operator is called to verify whether the data type, field length, and encoding rules meet the benchmark requirements. For logical fields, the logical judgment operator is called to verify whether the state linkage relationship and condition triggering logic meet the benchmark rules. During the verification process, fields that fail are marked as abnormal fields, and the deviation between the actual value and the benchmark threshold is calculated and recorded. After all verifications are completed, a single-item judgment result set containing a pass / fail indicator and abnormal details is output. Finally, the production line's preset abnormal circuit breaker rules are loaded first, and the single-item judgment result set is traversed to check whether there are any fatal failure items that trigger circuit breakers or whether the cumulative failure threshold is met. If a circuit breaker is triggered, the entire machine is directly marked as unqualified. If the circuit breaker is not triggered, the weight coefficients of each test item are retrieved, and a weighted calculation is performed on the individual results to obtain the overall pass rate of the whole machine. Finally, the overall machine conclusion, individual judgment details, abnormal field details and deviation statistics are integrated to generate standardized test results of the device under test and push them to the test scheduling module and production line data management system simultaneously.

[0120] Seventh Embodiment This application provides a testing method for production tools, applied to a lower-level machine, referring to... Figure 4 , Figure 4 This is a flowchart illustrating the seventh embodiment of the testing method for the production tool of this application.

[0121] In this embodiment, the testing method for the production tool includes steps F11 to F13: Step F11: Receive the test interaction message sent by the host computer.

[0122] In this embodiment, the reception of the aforementioned test interaction messages can be achieved through five modes. The first is single-channel resident detection reception, where the lower-level device consistently uses a single communication channel's receiving port, remaining in a detection state to capture single-frame or continuous-frame test interaction messages sent by the upper-level device in real time. This is suitable for mass production workstations with fixed interfaces and simple test scenarios. The second is multi-channel polling wake-up reception, where the lower-level device simultaneously uses multiple communication channels, polling and detecting the link status and message preamble of each channel according to a preset period. When a valid message preamble is detected, the complete receiving link of the corresponding channel is woken up to complete message reception. This is suitable for general-purpose devices under test that support multiple interfaces and is compatible with test station configurations on different production lines. The third is command-triggered on-demand reception, where the lower-level device is normally in a low-power standby state, retaining only the wake-up frame detection link. Upon receiving a test wake-up command frame sent by the upper-level device, the complete message receiving path is activated, and subsequent complete test interaction messages are received according to the agreed baud rate and frame format. This is suitable for production line testing of battery-powered devices under test, reducing standby power consumption. Fourthly, there is batch buffered continuous reception. The lower-level machine opens a dedicated message buffer queue, continuously receives multiple frames of test interaction messages sent by the upper-level machine, and temporarily stores them in the buffer area. After all messages in a single batch are received, they are submitted to the parsing module. This is suitable for batch testing scenarios with high clock speeds and multiple test items, reducing frequent switching between receiving and parsing. Fifthly, there is link verification-based trusted reception. Before receiving messages, the lower-level machine completes a link handshake and identity verification with the upper-level machine. After successful verification, a trusted transmission link is established. Only legitimate test interaction messages that have passed integrity verification are received, while illegal and tampered frames are discarded. This is suitable for equipment testing scenarios with high security requirements, preventing illegal commands from interfering with equipment operation.

[0123] Once the communication interface module of the lower-level machine captures the test interaction message, it initiates the message preprocessing and initial validity screening process to prepare for subsequent protocol parsing.

[0124] It should be noted that the above test interaction messages are initiated by the host computer in response to the production line test scheduling instructions. After matching the test script package of the corresponding model of the device under test, the script parser parses the test logic, determines the protocol interaction rules, and arranges and generates the test execution sequence. Then, it is converted into a standard message format adapted to the target communication channel and finally sent to the lower computer through the corresponding physical communication link to complete the reception.

[0125] Specifically, on the host computer side, the script parser first performs full logical parsing of the test script package, extracting the instruction parameters, interaction timing, and protocol constraints of each test item, and arranging them into a structured test execution sequence based on execution dependencies. Subsequently, the protocol adaptation unit matches the corresponding protocol rule template according to the target communication channel type for each test item, mapping the instructions in the execution sequence frame by frame into message content conforming to the frame structure specification, embedding message sequence identifiers and integrity verification fields, and generating standardized test interaction messages. Finally, the corresponding physical channel's send driver is called, and the messages are sent frame by frame sequentially through links such as transmission control protocols, universal serial buses, or serial communication interfaces. On the slave computer side, the corresponding communication interface continuously maintains a frame detection state. The hardware receive buffer captures the downlink data stream on the link in real time, locates the message start position by identifying preset frame header features, completes the reception of the entire frame data according to the agreed frame length and verification rules, verifies the matching of the frame header and frame tail, and temporarily stores it in the local receive buffer for subsequent parsing. This completes the end-to-end transmission process of the test interaction message from generation by the host computer to acquisition by the slave computer.

[0126] For example, there are two ways to implement the reception of test interaction messages. The first is interrupt-driven frame synchronization reception. After the message reception officially starts, the communication interface hardware triggers a reception interrupt when it detects the frame start signal. It receives message data byte by byte and writes it to the hardware receive buffer. After each complete message frame is received, a frame completion interrupt is triggered, notifying the main control module to read the message data and synchronously perform preliminary verification of the frame header and frame length. This method relies on hardware interrupts to achieve frame-level synchronization, which has strong real-time reception, low main control resource utilization, and is less prone to message loss. It can provide stable and reliable raw message input for subsequent parsing and is suitable for test scenarios with single-channel low-speed serial ports and high real-time requirements.

[0127] The second method is direct storage access (DMI) batch buffer reception. This involves pre-configuring the DMI channel of the communication interface, setting the starting address and capacity threshold of the message buffer, and then, upon initiating reception, directly transferring message data to the system memory buffer via hardware without requiring byte-by-byte intervention from the main controller. When the buffer data reaches the threshold or a frame end marker is received, the main controller then reads the entire batch of message data and performs batch initial verification. This method relies on hardware DMI to achieve batch data transfer, reducing the operating overhead of the main controller and supporting simultaneous reception of large volumes of messages from multiple channels.

[0128] Step F12: Parse the test interaction message according to the unified protocol specification, call the functional module corresponding to the test interaction message to perform the detection action of the specified test item, and obtain test response data.

[0129] The unified protocol specification is a pre-agreed message parsing rule between the host computer and the slave computer. It defines instruction encoding, field mapping, parameter format, and response rules, serving as a unified standard for message parsing and response encapsulation. A functional module is an independent execution unit within the slave computer that carries various hardware detection and functional verification capabilities. It corresponds one-to-one with each test item and is the entity that performs the testing actions. Examples include a power detection module, signal output detection module, storage function verification module, communication interface self-test module, and peripheral driver detection module. Test response data consists of the status, values, and results output by the functional module after performing the testing actions. It is the original result carrier transmitted back to the host computer. Examples include voltage and current detection values, function execution status codes, signal parameter indicators, and error codes.

[0130] Once the complete test interaction message is obtained, the message parsing and detection execution process is initiated. First, the message instructions are decomposed based on the unified protocol specification, and then the corresponding functional modules are scheduled to perform the detection.

[0131] For example, there are two implementation methods for message parsing and detection execution. The first is static mapping table-based instruction parsing and execution. A static mapping table of instruction codes and functional modules is pre-stored in non-volatile memory. When parsing a message, the instruction code field is extracted, and the corresponding functional module entry address and parameter format are directly matched by looking up the table. After extracting the test parameters according to the format, the corresponding functional module is directly called to execute the specified detection action. After the action is completed, the detection result data output by the module is read to generate test response data. This method relies on the fixed mapping table to achieve fast instruction matching, has simple and stable parsing logic, controllable execution latency, and extremely high execution reliability.

[0132] The second method is dynamic script-based instruction parsing and execution. The lower-level device has a built-in lightweight instruction parsing engine that supports loading accompanying micro-execution scripts from messages. It parses the detection steps, parameter thresholds, and logical branches within the script, dynamically scheduling the corresponding functional modules to execute detection actions according to the script-defined process. It supports multi-step linked detection, conditional branch retesting, and adaptive parameter adjustment. After execution, it assembles and generates test response data according to the field format defined in the script. This method does not rely on a fixed mapping table, and the test logic can be dynamically adjusted with the message delivery. Test items can be added or modified without upgrading the lower-level device firmware, reducing the firmware upgrade and maintenance costs for production line testing.

[0133] In an exemplary parsing and execution scheme, the frame structure definition and instruction encoding rules of the unified protocol specification are first loaded. The received test interaction message is then decomposed into a frame structure, extracting the frame header, instruction encoding field, parameter field, and verification field. Instruction validity is then checked to verify whether the instruction encoding is within the legal instruction set and whether the parameter length meets the specification requirements, eliminating illegal instruction frames. If a static mapping mode is used, the instruction-function mapping table is queried to locate the execution entry point of the corresponding functional module. The parsed parameters are then passed to the module to start detection, and a timeout is started simultaneously to prevent the module from abnormally freezing. If a dynamic script mode is used, the embedded script instruction segments in the message are extracted and sent to the lightweight parsing engine for line-by-line parsing. The corresponding functional modules are sequentially scheduled to perform step-by-step detection according to the script logic, supporting jumps to execution branches based on intermediate detection results. After all detection actions are completed, the raw detection data, status codes, and exception identifiers output by the functional modules are collected. Fields are then standardized according to the agreed data structure to generate standardized test response data, which is sent to the waiting-to-send buffer for subsequent encapsulation and return.

[0134] Step F13: The test response data is encapsulated in a pre-defined general format and sent back to the host computer so that the test result can be determined by the script parser of the host computer.

[0135] A common format is a pre-agreed response message encapsulation format between the upper and lower level computers. It uniformly defines the arrangement rules of frame structure, status fields, data fields, and check fields, ensuring that the upper level computer script parser can uniformly parse and judge the response. Examples include fixed-length response frame format, variable-length response format with identifier, and standard format of status code + data segment.

[0136] After the test response data is generated, the response message encapsulation and return process is started, and the original test data is encapsulated into a standard format message and then returned to the host computer.

[0137] For example, there are two implementation methods for response data encapsulation and feedback. The first is synchronous response-based real-time feedback. After each test action is completed and response data is generated, a single-frame response message is encapsulated according to a pre-defined general format and sent back to the host computer in real-time through the original communication channel. It then synchronously waits for the host computer's response confirmation. Only after receiving confirmation does it execute the parsing and testing of the next frame of test instructions. This method uses a question-and-answer synchronous interaction mechanism, with strict message timing correspondence, making it less prone to instruction and response misalignment. The host computer can determine the test results item by item, resulting in high interaction stability.

[0138] The second method is asynchronous batch aggregation and feedback. After the lower-level machine continuously executes multiple test actions and generates multiple sets of test response data, it aggregates and packages these multiple sets of response data sequentially into a single frame or a batch of multiple consecutive frames of response messages. These messages are then sent back to the upper-level machine when it is idle or after all tests in this batch are completed. The feedback process does not require waiting for the upper-level machine to respond frame by frame; it can be sent sequentially according to the sequence identifier. This method uses a batch aggregation asynchronous transmission mechanism, reducing the overhead of frequent message interaction, increasing the effective data ratio of the communication link, and shortening the overall test time, which can effectively improve the production line test cycle time.

[0139] In an exemplary encapsulation and return scheme, a frame structure template with a predefined general format is first loaded. Core fields such as status codes, detection values, and anomaly identifiers are extracted from the test response data. Mapping and filling are performed according to the field order and byte length specified in the template, and a sequence identifier field corresponding to the downlink message is embedded synchronously to ensure one-to-one matching of uplink and downlink messages. Subsequently, the message integrity check value is calculated and filled into the check field to generate a complete response message frame. If a synchronous response mode is used, a single-frame response message is sent to the sending buffer, immediately triggering the channel sending action and synchronously starting a timeout retransmission timer. If no confirmation is received from the host computer, a retransmission is performed after the timeout to ensure reliable message delivery. If an asynchronous batch mode is used, a single set of response data is temporarily stored in a batch cache queue. After all test items in this batch have been executed, the full response data is sequentially encapsulated into multiple consecutive frames and sent in batches at fixed intervals. A retransmission check mechanism is added during the sending process to ensure reliability. Finally, after all response messages are delivered to the host computer, the host computer's script parser performs item-by-item verification and determines the overall test results based on the result judgment criteria.

[0140] Further, please refer to Figure 5 , Figure 5This is the system architecture diagram for this application. In mass production testing scenarios for multi-model electronic devices, this solution adopts a novel protocol-decoupled testing architecture. Unlike the traditional integrated architecture of "production tools, backend servers, and devices under test / auxiliary devices," the new architecture adopts a separation of responsibilities model of "production tools, backend servers (directly controlling auxiliary devices), script parsers, and devices under test," decoupling all test items using different interaction protocols and transferring them to the script parser for processing. During runtime, the production tools on the host computer side first download the corresponding script specification package for the X model test project from the cloud. Then, they connect to the scheduling backend server and the script parser respectively via the Transmission Control Protocol (TCP). The backend server only undertakes the responsibilities of production line test process scheduling and auxiliary equipment management. It connects directly to the auxiliary equipment of the lower-level machine through other dedicated protocols to complete auxiliary test actions such as tooling linkage and power supply control. It no longer carries the protocol implementation logic of each model's device under test. The protocol message sending and receiving, response data verification, and test result judgment related to the device under test are all handled independently by the script parser. After loading the test script from the corresponding model specification directory, the script parser can complete bidirectional test interaction with the device under test on the lower-level machine through various communication channels such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Universal Serial Bus (USB), and serial port. It independently completes protocol adaptation, instruction encapsulation and issuance, response unpacking and parsing, and result compliance judgment. When adding or changing test items under this architecture, only the customized specifications (including script packages and test case files) of the corresponding model in the cloud need to be updated to complete the specification iteration. There is no need to modify the backend server main program and recompile and deploy. This realizes independent maintenance and hot release of test specifications for multiple models, clearly defines the responsibility boundaries of each module of the system, reduces the expansion and iteration cost of multi-model production line testing, and effectively improves the maintainability and expansion flexibility of the production line testing system.

[0141] Eighth embodiment This embodiment provides an exemplary scheme for parsing test interaction messages to generate test response data. In this example, the test interaction messages are first decapsulated, frame integrity checked, and command legality verified according to a unified protocol specification to obtain compliant and valid test commands. Then, based on the test item identifier of the valid test command, the corresponding functional module is matched, and the device operating status and execution access conditions are verified to generate an executable function execution command. Subsequently, the corresponding functional module is driven to execute the detection action of the specified test item. During execution, status data and result parameters are collected synchronously, and validity filtering and outlier removal are performed to obtain the original test dataset. Finally, according to a preset data structure, field mapping and format regularization are performed on the dataset, and the corresponding test item identifier and execution status code are associated to obtain standardized test response data. Please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the eighth embodiment of the testing method for the production tool of this application. Step F12 includes steps G11 to G15: Step G11: Perform message decapsulation, frame integrity verification, and instruction legality verification on the test interaction message according to the unified protocol specification to obtain a valid test instruction.

[0142] Step G12: Based on the test item identifier of the valid test instruction, match the corresponding functional module in the locally pre-stored functional module mapping table, verify the current device operating status and the execution admission conditions of the test item, and generate a functional execution instruction.

[0143] Step G13: Drive the corresponding functional module according to the function execution instruction to perform the detection action of the specified test item.

[0144] Step G14: During the execution of the detection action, collect the status data and result parameters during the detection process, and perform validity filtering and outlier removal on the status data and result parameters to obtain the original test dataset.

[0145] Step G15: Map fields and format the original test dataset according to the preset data structure, associate the corresponding test item identifier and execution status code, and obtain the test response data.

[0146] Message decapsulation is the process of disassembling test interaction messages according to the protocol frame structure, stripping auxiliary fields such as the frame header and checksum field, and extracting the core content of instructions and parameters. It is the fundamental step in message parsing. Instruction validity verification is the process of verifying whether the parsed instruction code and parameter range are within a preset set of valid instructions. This is used to filter illegal instructions and unauthorized operations, ensuring device operational security. Examples include instruction code range verification, parameter threshold verification, operation permission verification, and execution timing compliance verification. Valid test instructions are those that have passed all verifications and can be executed normally by the device. They include test item identifiers and operating parameters and are the core input driving the detection actions.

[0147] Test item identifiers are unique identification codes used to distinguish different test items and are the core index for matching functional modules with associated test results. Examples include power parameter test number, signal performance test number, storage function test number, and interface communication self-test number. The functional module mapping table is a pre-existing mapping data table on the lower-level machine, storing the correspondence between test item identifiers and functional module entry addresses, used for quickly locating test execution units. A functional module is a software functional unit in the lower-level machine that carries single-item testing capabilities and can be independently scheduled and executed. It corresponds to the hardware testing circuit or functional circuit and is the entity that performs the testing action. Examples include voltage and current sampling modules, signal indicator detection modules, storage read / write verification modules, and peripheral driver verification modules. Execution admission conditions are the device pre-state requirements that must be met to execute the corresponding test item, used to avoid device abnormalities caused by executing tests in incorrect states. Examples include power supply stability conditions, module initialization completion conditions, no safety alarm conditions, and pre-test item pass conditions. Function execution instructions are instructions that carry execution parameters and operating configurations and can directly drive the functional module to start testing; they are the scheduling carrier connecting the parsing logic and the execution module.

[0148] Testing actions are the specific execution actions performed by functional modules according to test requirements, such as hardware testing, functional verification, and parameter reading. They are the source of test results. Examples include multi-channel voltage sampling, signal frequency and accuracy testing, storage unit read / write verification, and peripheral interface connectivity verification. Status data is process data reflecting the module's operating status and the overall operating condition of the equipment during testing, used to determine whether the testing process was executed normally. Examples include module operating status codes, real-time power supply voltage, communication link status, and core component temperature values. Result parameters are the core values ​​and status parameters output after the testing actions are completed, used to determine whether the test items are qualified or not; they are the core content of the test results. Examples include output voltage accuracy, signal distortion parameters, read / write response time, and function execution success rate. Validity filtering is the processing action that filters noise and removes invalid data from the collected raw data, used to remove data fluctuations caused by acquisition interference and improve data reliability. Examples include moving average filtering, amplitude limiting filtering, median filtering, and Kalman filtering. Outlier removal is the process of identifying and removing outliers and abrupt changes in collected data that deviate from the normal range, thus avoiding misjudgments of test results due to occasional interference. Examples include Grubbs criterion removal, 3σ criterion removal, and adjacent data difference judgment removal. The original test dataset, after filtering and outlier removal, is a complete and valid collection of detection process data and result parameters, and is the object of subsequent formatting and processing.

[0149] The preset data structure is a predefined specification of the field composition, arrangement order, and data type of the test response data, used to ensure that the host computer script parser can uniformly parse and recognize it. Field mapping is the process of filling the parameters in the original test dataset into the specified fields of the preset data structure, achieving standardized data arrangement. Format standardization is the process of uniformly converting the data type, length, byte order, and encoding method to ensure that the response data conforms to the agreed format requirements. Execution status codes are coded fields that mark the execution status of test items, used to inform the host computer whether the test was completed normally, interrupted abnormally, or failed due to a timeout. Examples include execution success status codes, execution timeout status codes, parameter exception status codes, and hardware failure status codes.

[0150] The test response data is a complete response data that has been standardized and organized, carrying test item identifiers and execution status. It can be directly packaged and sent back to the host computer.

[0151] In this example, when processing test interaction messages according to the unified protocol specification to obtain valid test instructions, a static parsing method with full-frame loading can be used. First, the entire received single-frame test interaction message is loaded into the parsing buffer. Then, the frame header, length field, and checksum field are sequentially extracted according to the frame structure definition of the unified protocol specification. Frame integrity verification and the validity of instruction encoding and parameters are performed simultaneously. After all verifications pass, the valid test instruction is extracted. Alternatively, a streaming incremental parsing method can be used. While receiving the byte stream of the test interaction message, segment-by-segment parsing and verification are performed according to the protocol rules, while simultaneously identifying frame boundaries and instruction fields. Once the complete frame is received and all verifications pass, valid test instructions are accumulated and generated, thus completing the parsing and validity verification of the instructions.

[0152] After receiving a valid test instruction, the functional module matching and access verification process is initiated. The test item identifier is extracted from the valid test instruction, the locally stored functional module mapping table is retrieved, and the corresponding functional module entry point is located and matched. Simultaneously, the current device's operating status parameters are read and compared item by item with the preset execution access conditions for that test item. Upon successful verification, a functional execution instruction carrying the operating parameters is generated. Subsequently, the corresponding functional module is driven to initiate the detection action of the specified test item according to the functional execution instruction. Throughout the detection execution process, status data and result parameters are continuously collected at a fixed sampling period. Simultaneously, validity filtering is performed on the collected raw data to filter out acquisition noise and interference fluctuations. Then, sudden outliers and invalid data are removed through anomaly judgment rules, resulting in a complete raw test dataset. Finally, a preset response data structure template is loaded, and various parameters in the raw test dataset are mapped and filled according to field definitions. Simultaneously, the data format is standardized, and the corresponding test item identifier and the status code of this execution are associated and bound, ultimately generating standardized test response data. Through layered parsing, verification, execution, and standardization, the reliability of test instruction execution and the consistency of response data are improved, avoiding test result deviations caused by transmission interference and status anomalies.

[0153] For example, there are two ways to parse test interaction messages and generate test response data. The first is a fixed instruction set closed-loop execution method. A complete set of valid instructions and a mapping table of functional modules are pre-stored in local non-volatile storage. Upon receiving a test interaction message, full-field decapsulation and dual verification of integrity and validity are performed according to the fixed protocol specifications. Verification is only passed when the instruction completely matches the fixed instruction set. Subsequently, the corresponding fixed-address functional module is directly called to perform the detection action. The detection process performs fixed filtering and outlier removal according to preset sampling parameters. Finally, standard response data is generated according to a fixed data structure. This method uses a fully fixed instruction set and execution chain, ensuring stable logical closed-loop, fixed and controllable execution latency, strong anti-interference capability, and adaptability to production line testing scenarios with fixed models and mature testing processes in the mass production stage. It can guarantee the consistency and reliability of large-scale testing.

[0154] The second approach is a dynamically expandable flexible execution method. The lower-level machine has a built-in dynamically loadable instruction parsing engine and module scheduling framework. The functional module mapping table supports online updates and expansions. Upon receiving a test interaction message, the parsing engine can identify the extended instruction set and the configuration parameters embedded in the message, dynamically matching and loading the corresponding functional module. Simultaneously, based on the test configuration parameters carried in the message, it adaptively adjusts the execution parameters, sampling frequency, and filtering rules of the detection actions. It supports custom data fields and output formats, ultimately generating adapted test response data according to a pre-defined configurable data structure. This method employs a dynamically expandable flexible execution architecture, allowing for the addition of test items and adjustments to detection logic without updating the lower-level machine firmware. This reduces the iterative maintenance cost of the lower-level machine firmware and improves the adaptability and flexibility of the test solution.

[0155] Furthermore, the protocol parsing unit of the lower-level machine first performs field-by-field decapsulation of the test interaction messages in the received buffer according to the predefined unified protocol specification, sequentially stripping the frame header identifier, length field, and check field, and synchronously calling the preset check algorithm to complete the frame integrity check, discarding abnormal frames that fail the check. Then, it performs legality verification on the extracted instruction code and parameter fields, verifying whether the instruction belongs to a legal instruction set and whether the parameters fall within the preset value range. After all verifications pass, a structured valid test instruction is output. Subsequently, the test item identifier field carried in the valid test instruction is extracted, and the locally stored functional module mapping table is searched to match and locate the entry address and parameter loading rules of the functional module corresponding to the test item. At the same time, the current system running status, hardware initialization status, and execution results of the pre-dependent items of the current device are read and compared with the preset execution admission conditions of the test item. After confirming that the execution conditions are met, the test parameters are encapsulated according to the module interface requirements to generate a directly schedulable functional execution instruction. Next, the function execution command is sent to the control interface of the corresponding functional module, triggering the module to start the detection action of the specified test item, and simultaneously starting the execution timeout timer. The operating status of the control module is monitored in real time to ensure that the detection action is strictly executed according to the preset process and parameter requirements. Throughout the entire cycle of the detection action, real-time status data and final result parameters are continuously collected during the detection process according to the preset sampling frequency and sampling channel configuration. First, the original sampled data is filtered for validity using a preset filtering algorithm to eliminate acquisition noise and signal fluctuations. Then, outlier judgment rules are used to identify and remove abnormal values ​​and invalid sampling points that exceed the reasonable range. All valid data are then summarized and retained to form a complete original test dataset. Finally, a preset standardized response data structure template is loaded. Various status parameters and result values ​​in the original test dataset are mapped and formatted according to the field order, data type, and byte order defined in the template. The corresponding test item identifier and execution status code are simultaneously associated and bound. After data integrity verification, test response data with a unified format that can be directly used for encapsulation and return is output.

[0156] Ninth Embodiment This embodiment provides a testing system for production tools, including a host computer and a slave computer. The host computer includes a production tool scheduling module, a backend service module, a script parsing engine module, a multi-protocol communication adaptation module, and a local specification caching module. The slave computer includes two types of nodes: the device under test (DUT) node and the auxiliary device node. The DUT has a built-in device-side communication module, an instruction parsing and admission module, a function detection module group, a sampling data processing module, and a response data encapsulation module. The auxiliary device has a built-in tooling communication module, an execution control module, and a status feedback module.

[0157] When the production tool testing system is deployed and running, the production tool scheduling module, acting as the unified scheduling entry point for the host computer, responds to test scheduling instructions issued from the production line. It parses the device model identifier and test task scope parameters of the device under test, and first checks the local specification cache module to see if the corresponding version of the device model's test script package is stored. If no valid local cache exists, it initiates a matching query and full retrieval from the cloud-based test specification library. After obtaining the corresponding device model's test script package, it performs file integrity verification and format compliance verification. Once verification passes, it is stored in the local specification cache module for subsequent reuse. After completing script resource preparation, the production tool scheduling module issues test task instructions to the backend service module and script parsing engine module via the transmission control protocol link, clearly defining test process nodes and task boundaries. The backend service module is dedicated to the timing control, status synchronization, and auxiliary device scheduling responsibilities of the entire testing process, and does not handle any device-specific protocol interaction logic. Upon receiving the task instruction, the backend service module sends auxiliary equipment control instructions to the multi-protocol communication adaptation module. These instructions are then transmitted to the auxiliary equipment nodes of the lower-level machine via the corresponding dedicated communication channel. The tooling communication module receives and parses the instructions before sending them to the execution control module. This drives the tooling mechanism to sequentially complete preparatory actions such as positioning and clamping the device under test, connecting the communication interface, and powering on. After the actions are completed, the status feedback module sends back a tooling ready signal and the device's on-site status to the backend service module, completing the pre-test preparation process. Simultaneously, the script parsing engine module loads the corresponding model's test script package from the local specification cache module. It parses the test item logic, protocol interaction rules, data verification rules, and result judgment criteria line by line within the script, identifies the pre-dependencies and execution priorities of each test item, and combines these with the production line's preset exception circuit breaker rules to generate a structured test execution link framework. This framework binds the corresponding communication channel's protocol adaptation entry and judgment execution handle to each execution node, and after preloading context parameters, generates a directly schedulable test execution sequence. Subsequently, the script parsing engine module calls the multi-protocol communication adaptation module to map and encapsulate the test item instructions in the test execution sequence according to the target channel's protocol specifications, embed message sequence identifiers and integrity verification fields, generate standard test interaction messages, and sort them according to the test execution sequence and channel bandwidth attributes. Then, these messages are sequentially sent to the device under test node of the lower-level machine through the corresponding physical channels such as Transmission Control Protocol, User Datagram Protocol, Universal Serial Bus, and serial port.

[0158] After receiving test interaction messages through the device-side communication module, the instruction parsing and admission module performs message decapsulation, frame integrity verification, and instruction legality verification according to a unified protocol specification. Abnormal frames and illegal instructions are removed to obtain valid test instructions. Subsequently, the test item identifier is extracted from the valid test instructions, and the corresponding function detection module is matched against the locally stored function module mapping table. Simultaneously, the current device's operating status parameters are read and compared item by item with the preset execution admission conditions for that test item. Once the execution conditions are confirmed, a function execution instruction is generated, driving the corresponding function detection module to initiate the detection action of the specified test item. During the execution of the detection action, the sampling data processing module continuously collects real-time status data and final result parameters according to the preset sampling frequency and channel configuration. First, a preset filtering algorithm is used to perform validity filtering to remove acquisition noise and signal fluctuations. Then, outlier judgment rules are used to identify and remove abnormal values ​​and invalid sampling points that exceed reasonable ranges. All valid data are then summarized and retained to form the original test dataset. After the original test dataset is sent to the response data encapsulation module, field mapping and format regularization are completed according to the predefined standardized data structure, unifying data types, byte order, and encoding formats. The corresponding test item identifier and execution status code are synchronously associated and bound. After data integrity verification, standard test response data is generated and transmitted back to the host computer via the device-side communication module through the original communication channel. Upon receiving the test response data, the host computer's multi-protocol communication adaptation module performs preliminary frame verification and timing alignment before forwarding it to the script parsing engine module. The script parsing engine, according to the preset result judgment criteria within the script, performs numerical threshold comparison, data format verification, and logical compliance judgment on each item of the response data, synchronously recording abnormal fields and deviation values, and generating individual test results. If an exception circuit breaker rule is triggered during execution, subsequent test items are terminated, and the process jumps to the corresponding exception handling branch. After all test items are executed, the script parsing engine summarizes all individual results, calculates the overall system test conclusion based on the test item level weight, and sends the complete test results back to the production tool scheduling module and the backend service module. After receiving the test completion signal, the backend service module drives the auxiliary equipment to complete final reset actions such as power-off, unbinding, and material unloading, ultimately completing the full-process production line test of the entire device under test. This architecture decouples responsibilities, sinking all model-specific protocols and test logic to the script layer. The backend service only retains general scheduling and auxiliary equipment control capabilities. Adding or iterating test items only requires updating the cloud script package to complete the implementation, without modifying the backend main program or recompiling and deploying. This improves the scalability and maintainability of multi-model production line testing.

[0159] This application provides a testing device for production tools, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the testing method for production tools in the first embodiment described above.

[0160] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a testing device suitable for implementing the production tools of the embodiments of this application. The testing device for the production tools in the embodiments of this application may include, but is not limited to, mobile terminals such as automatic test equipment, in-circuit testers, functional testers, etc., and fixed terminals such as protocol analyzers, bit error rate testers, network protocol testers, etc. Figure 7 The testing equipment for the production tools shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0161] like Figure 7 As shown, the testing equipment for production tools may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the testing equipment for production tools. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the test equipment of the production tool to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a test equipment for a production tool with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented alternatively.

[0162] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0163] The testing equipment for production tools provided in this application, employing the testing method for production tools in the above embodiments, can solve the technical problem of low production line efficiency. Compared with the prior art, the beneficial effects of the testing equipment for production tools provided in this application are the same as those of the testing method for production tools provided in the above embodiments, and other technical features of the testing equipment for production tools are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0164] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0166] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the testing method of the production tool in the above embodiments.

[0167] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0168] The aforementioned computer-readable storage medium may be included in the testing equipment of the production tool; or it may exist independently and not assembled into the testing equipment of the production tool.

[0169] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the testing equipment of the production tool, the testing equipment of the production tool: responds to the production line test scheduling instruction, determines the corresponding test script package based on the model identifier of the device under test; parses the test logic within the test script package using a script parser, determines the protocol interaction rules and result judgment criteria for the test items, and arranges and generates a test execution sequence; converts the test execution sequence into test interaction messages adapted to the target communication channel and sends them to the device under test on the lower-level machine; after receiving the test response data returned by the lower-level machine, verifies the test response data according to the result judgment criteria using the script parser to obtain the test result of the device under test.

[0170] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0171] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0172] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0173] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the testing method of the aforementioned production tool, thereby solving the technical problem of low production line efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the testing method of the production tool provided in the above embodiments, and will not be repeated here.

[0174] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for testing production tools, characterized in that, Applied to a host computer, the method includes: Responding to production line test scheduling instructions, determine the corresponding test script package based on the model identifier of the device under test; The test logic within the test script package is parsed by the script parser to determine the protocol interaction rules and result judgment criteria for the test items, and to arrange and generate the test execution sequence. The test execution sequence is converted into a test interaction message adapted to the target communication channel and sent to the device under test on the lower-level machine; After receiving the test response data returned by the lower-level machine, the test response data is verified by the script parser according to the result judgment benchmark to obtain the test result of the device under test.

2. The testing method for production tools as described in claim 1, characterized in that, The step of responding to the production line test scheduling command and determining the corresponding test script package based on the model identifier of the device under test includes: In response to the production line test scheduling instruction, the device under test model identifier and test task range parameters of the production line test scheduling instruction are parsed, and the baseline query parameters are obtained. Based on the model identifier of the benchmark query parameters, initiate a model directory matching query to the test specification library to determine the target directory corresponding to the model identifier; Verify the validity of the test package release and its compatibility with the device version under the target directory, and output the resource location information of the script package that has passed the verification. The initial test package is determined according to the resource location information of the script package. The file integrity is verified and the script format compliance is checked on the initial test package to obtain a compliant test package. The compliance test package is restructured by re-indexing the directory according to the execution priority of the test items, generating the test script package that can be loaded and called by the script parser.

3. The testing method for production tools as described in claim 1, characterized in that, The steps of parsing the test logic within the test script package using a script parser, determining the protocol interaction rules and result judgment criteria for the test items, and arranging and generating the test execution sequence include: The script parser's entry scheduling module verifies the lexical semantics of the test script package and identifies the test item branch structure and execution dependencies within the test script package to obtain the script syntax parsing structure. The script syntax parsing structure is analyzed in depth for each test item to determine the protocol interaction rules, data verification rules and result judgment criteria corresponding to each test item, and to generate a test item metadata set. Based on the test item metadata set, and combined with the abnormal circuit breaker rules of the production line test process, the execution path is arranged to obtain the test execution link framework; The test execution sequence is obtained by binding the corresponding communication channel protocol adaptation entry and decision execution handle to the execution node in the test execution link framework and preloading the context.

4. The testing method for production tools as described in claim 3, characterized in that, The step of arranging execution paths based on the test item metadata set and the abnormal circuit breaker rules of the production line testing process to obtain the test execution link framework includes: Based on the test item metadata set and the exception circuit breaker rules, the prerequisite dependencies, execution priorities and failure impact levels among the test items are determined; Based on the execution priority and the prerequisite dependencies, an initial test execution path is constructed according to the serial execution baseline, and an exception judgment branch node corresponding to the failure impact level is embedded after the test item node to generate the initial execution link; Configure corresponding jump targets and circuit breaker triggering conditions for the abnormal judgment branch nodes in the initial execution link according to the abnormal circuit breaker rules, and associate the continuous failure count and the whole machine retest triggering logic to obtain the preliminary framework of the execution link; The preliminary execution link framework is subjected to dependency closure verification and path reachability verification, redundant branches are eliminated and the state transfer format between nodes is unified to obtain the test execution link framework.

5. The testing method for production tools as described in claim 1, characterized in that, The step of converting the test execution sequence into a test interaction message adapted to the target communication channel and sending it to the device under test on the lower-level machine includes: The target communication channel type and protocol format constraints of the test execution sequence are parsed node by node, and the corresponding protocol adaptation rule template is matched to obtain the test instruction set to be encapsulated with channel identifier; According to the protocol adaptation rule template, the instructions in the test instruction set to be encapsulated are mapped and encapsulated according to the frame structure specification of the corresponding channel, and the message sequence identifier and integrity verification field are embedded to obtain the test interaction message set. Verify the compliance of the channel transmission of the test interaction message set. After the verification is passed, sort the messages according to the test execution sequence and channel bandwidth attributes, and generate a message queue to be sent in an orderly manner. The physical communication channel's sending interface is invoked, and the test interaction message is sent frame by frame to the device under test of the lower-level machine according to the order of the message queue to be sent.

6. The testing method for production tools as described in claim 1, characterized in that, The step of receiving the test response data returned by the lower-level machine and then verifying the test response data according to the result judgment benchmark through the script parser to obtain the test result of the device under test includes: The test response data returned by the lower-level machine is received, and the data is unpacked and frame integrity is verified according to the protocol specifications of the corresponding communication channel. The data is then time-aligned and deduplicated according to the message sequence identifier to obtain the original response data. The original response data is mapped and matched one by one with the test item nodes of the test execution sequence to determine the feature field to be verified and the result judgment benchmark corresponding to each test, and the data unit set to be verified is obtained by association. The script parser performs numerical threshold comparison, data format verification, and logical compliance judgment item by item according to the result judgment criteria of the data unit to be verified, and records abnormal fields and deviation values ​​to obtain a single judgment result set. The individual judgment results of the test items are summarized, and the overall test conclusion is calculated by combining the abnormal circuit breaker rules of the production line test with the test item level weight, so as to obtain the test result of the equipment under test.

7. A testing method for production tools, characterized in that, Applied to a lower-level machine, the method includes: Receive test interaction messages sent by the host computer; The test interaction message is parsed according to the unified protocol specification, and the corresponding functional module of the test interaction message is called to perform the detection action of the specified test item to obtain the test response data. The test response data is encapsulated in a pre-defined general format and then sent back to the host computer so that the test results can be determined by the host computer's script parser.

8. The testing method for production tools as described in claim 7, characterized in that, The steps of parsing the test interaction message according to the unified protocol specification, calling the functional module corresponding to the test interaction message to perform the detection action of the specified test item, and obtaining the test response data include: According to the unified protocol specification, the test interaction message is decapsulated, frame integrity is verified, and command legality is checked to obtain a valid test command; Based on the test item identifier of the valid test instruction, the corresponding functional module is matched in the locally pre-stored functional module mapping table, and the current device operating status and the execution admission conditions of the test item are verified to generate a functional execution instruction. According to the function execution instruction, drive the corresponding function module to perform the detection action of the specified test item; During the execution of the detection action, status data and result parameters during the detection process are collected, and the status data and result parameters are subjected to validity filtering and outlier removal to obtain the original test dataset; The original test dataset is mapped and formatted according to a preset data structure, and the corresponding test item identifier and execution status code are associated to obtain the test response data.

9. A testing device for production tools, characterized in that, The testing equipment for the production tool includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the testing method for the production tool as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the testing method for the production tool as described in any one of claims 1 to 8.

Images