An ATE test code structured sample construction method, device and equipment

Abstract

The application discloses an ATE test code structured sample construction method and device and equipment, and relates to the technical field of data processing. The method comprises the following steps: performing multi-layer function semantic division on an ATE test program source file to obtain a multi-layer function semantic division result, at least comprising: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code and result judgment output layer code; performing differential extraction based on the multi-layer function semantic division result: extracting chip hardware context information from the hardware resource declaration layer code, extracting system configuration in the system configuration layer code into a system framework template, taking each test interface function in the test interface function layer code as a segmentation object to obtain a test sample unit or a test item fragment; and performing structured extraction on the test sample unit or the test item fragment to construct a structured sample, so that the automatic semantic layering, accurate boundary positioning and structured sample construction of the ATE test code are realized.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus and equipment for constructing structured samples of ATE test code. Background Technology

[0002] Automated testing of integrated circuits, also known as Automated Test Equipment (ATE) testing, is a core component of the post-packaging quality assurance system for chips.

[0003] As chip integration continues to increase, the number of test items is growing dramatically. A complete test program source file often contains hundreds of test functions and tens of thousands of lines of code, making manual maintenance extremely costly. Therefore, the traditional approach of having test engineers write a complete set of test programs for each functional module of a specific chip on a dedicated ATE platform to achieve chip testing and verification can no longer meet current business needs.

[0004] Currently, the application of large-scale model technology in test program development, with the automatic generation of chip test code through models becoming an industry trend, is gaining momentum. However, chip ATE test code has unique domain structure characteristics: it is not a flat collection of functions, but rather a hierarchical semantic structure with test interface functions as its skeleton—the hardware resource declaration layer and system configuration layer are located outside the test interface functions, while the hardware state control layer and result judgment output layer are nested inside the test interface functions, interdependent with the test logic. General code processing methods fail to recognize this domain structure. Furthermore, the significant differences in coding styles among different test engineers mean that models cannot directly learn and reuse chip test code in batches, requiring manual annotation of training samples. However, generating training samples through manual annotation is time-consuming, labor-intensive, and involves a huge workload.

[0005] The existing common sample construction method is code segmentation based on abstract syntax trees. However, this common method has the following limitations when applied to ATE test code: First, the common method only divides the hierarchy according to the type of syntax node (function, class, logic block), and cannot distinguish the functional semantic differences between 'hardware resource declaration' and 'test logic' in ATE test code, resulting in the loss of hardware context information after segmentation. Second, the output of the common method is only a code retrieval unit, lacking semantic annotation fields such as hardware operation sequence annotation, parameter structured description, and result identifier required for model training, and cannot be directly used for fine-tuning training of large language models. Third, the common method splits parent and child blocks based on information density (such as the number of tokens), and cannot identify the test boundaries defined by specific semantic API calls (such as test result writing functions and parameter binding functions) in ATE test code, resulting in the destruction of the integrity of test logic. Summary of the Invention

[0006] This invention provides a method, apparatus, and device for constructing structured samples of ATE test code. By performing five-layer functional semantic division and adaptive two-layer segmentation on the ATE test program source file, it achieves fully automated conversion of unstructured ATE test code into structured semantic samples, solving the technical problem of insufficient available training samples in existing models.

[0007] In a first aspect, embodiments of the present invention provide a method for constructing structured samples of ATE test code, the method comprising: The ATE test program source file is divided into multiple functional semantic layers to obtain the multi-layer functional semantic layer division result. The multi-layer functional semantic layer division result includes at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment and output layer code. Among them, the hardware state control layer code and the result judgment and output layer code are embedded inside the test interface function layer code. Differential extraction is performed based on the results of the multi-layer functional semantic division: chip hardware context information is extracted from the hardware resource declaration layer code, system configuration in the system configuration layer code is extracted as a system framework template, and each test interface function in the test interface function layer code is used as a segmentation object to obtain test sample units or test item fragments. The test sample units or test item fragments are extracted in a structured manner to construct structured samples; The structured sample includes at least: The main body of the code includes the original code content of the code corresponding to the test sample unit or test item fragment, as well as the hardware state control layer code and result judgment output layer code embedded within it; The context field, independent of the code body, contains the chip hardware context information that is bound by an index; The semantic annotation field is extracted from the hardware state control layer code, the result judgment output layer code, and the parameter binding statements in the test interface function.

[0008] Secondly, embodiments of the present invention provide an apparatus for constructing structured samples of ATE test code, the apparatus comprising: The semantic segmentation module is used to perform multi-level functional semantic segmentation on the ATE test program source file to obtain multi-level functional semantic segmentation results. The multi-level functional semantic segmentation results include at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment output layer code. Among them, the hardware state control layer code and the result judgment output layer code are embedded inside the test interface function layer code. The information extraction module is used to perform differential extraction based on the multi-layer functional semantic division results: extract chip hardware context information from the hardware resource declaration layer code, extract the system configuration in the system configuration layer code as a system framework template, and obtain test sample units or test item fragments by taking each test interface function in the test interface function layer code as the segmentation object. The sample construction module is used to extract the structure of the test sample unit or test item fragment and construct a structured sample. The structured sample includes at least: The main body of the code includes the original code content of the code corresponding to the test sample unit or test item fragment, as well as the hardware state control layer code and result judgment output layer code embedded within it; The context field, independent of the code body, contains the chip hardware context information that is bound by an index; The semantic annotation field is extracted from the hardware state control layer code, the result judgment output layer code, and the parameter binding statements in the test interface function.

[0009] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the ATE test code structured sample construction method according to any embodiment of the present invention.

[0010] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute the ATE test code structured sample construction method described in any embodiment of the present invention.

[0011] Fifthly, embodiments of the present invention also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the ATE test code structured sample construction method according to any embodiment of the present invention.

[0012] The technical solution of this invention involves performing multi-layer functional semantic partitioning on the ATE test program source file to obtain a multi-layer functional semantic partitioning result. This result includes at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment and output layer code. The hardware state control layer code and result judgment and output layer code are embedded within the test interface function layer code. Based on the multi-layer functional semantic partitioning result, differentiated extraction is performed: chip hardware context information is extracted from the hardware resource declaration layer code, and the system configuration in the system configuration layer code is extracted as a system framework template for testing. Each test interface function in the test interface function layer code is used as a segmentation object to obtain test sample units or test item fragments. The test sample units or test item fragments are then structurally extracted to construct structured samples. These structured samples include at least: a code body containing the original code content of the corresponding test sample unit or test item fragment, as well as the embedded hardware state control layer code and result judgment output layer code; a context field, independent of the code body, containing chip hardware context information bound by an index; and a semantic annotation field, extracted from the hardware state control layer code, result judgment output layer code, and parameter binding statements in the test interface functions. Using this method, automated and accurate structural parsing of ATE test program source files and fully automated conversion of unstructured ATE test code into structured semantic samples are achieved. Specifically, by performing multi-layered functional semantic partitioning on the ATE test program source files, precise separation of test program code according to functional semantics and accurate identification and boundary marking of the semantic layer code within the test interface functions are achieved. This overcomes the shortcomings of general code analysis methods, which can only identify syntactic units such as functions and classes but cannot distinguish the functional semantic differences between "hardware declarations" and "test logic," resulting in the loss of hardware context in the segmented fragments. Furthermore, by using each test interface function as the smallest segmentation unit for test code segmentation, automatic identification and accurate boundary positioning of test interface functions are achieved, reducing manual analysis costs and improving code structuring efficiency. By constructing structured samples with clear structure, complete semantics, and executability based on the code body and corresponding context fields and semantic annotation fields, the subsequent intelligent processing flow is effectively supported. It also ensures the structural separation of training data and generation conditions, enabling the subsequent model to focus on test logic learning without being affected by hardware constraints and specific platform initialization modes. Moreover, the model learns the mapping relationship between hardware conditions and test logic during the training phase, thereby improving the effectiveness, accuracy, and executability of automated code generation.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0015] Figure 1 A flowchart illustrating a method for constructing structured samples of ATE test code provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the adaptive segmentation of test interface functions in an ATE test code structured sample construction method provided in an embodiment of the present invention. Figure 3 This is a flowchart illustrating the process of obtaining structured samples in a method for constructing structured samples of ATE test code provided in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating the principle of a method for constructing structured samples of ATE test code provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a structured sample construction device for ATE test code provided in an embodiment of the present invention; Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

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

[0018] The innovation of this invention lies in elevating test code in the ATE domain from "general code chunking at the syntax level" to "domain-structured sample construction at the semantic level." Through four major technical steps—five-layer functional semantic layering, precise DUT_API positioning, adaptive segmentation with preset line number thresholds and domain markers, and a three-layer decoupling strategy of "context fields - system framework templates - structured samples"—it achieves fully automated conversion of ATE test code into structured semantic samples. Among these, the three-layer decoupling strategy ensures the structural separation of training data and generation conditions, allowing the model to focus on learning test logic without being disturbed by the specific initialization mode of the platform.

[0019] Innovation Point 1: A Dedicated Five-Layer Functional Semantic Layering Model for ATE Testing A five-layer functional semantic layering framework for ATE test code is proposed (L1 hardware resource declaration layer code, L2 system configuration layer code, L3 test interface function layer code, L4 hardware state control layer code, and L5 result judgment and output layer code). This framework deconstructs tens of thousands of lines of complex test code hierarchically according to functional semantics rather than syntactic structure, achieving a leap from "syntactic parsing" to "semantic understanding".

[0020] Innovation Point Two: Precise Boundary Location Using DUT_API Functions as the Smallest Segmentation Unit This invention defines DUT_API type functions (interface functions in the ATE platform that identify direct interaction with the DUT) as the smallest functional unit and segmentation benchmark for test code. Traditional methods use files or general functions as the granularity of division, which cannot identify the functional boundaries of truly independent test items in the ATE test code. This invention automatically identifies the boundaries of test interface functions through the DUT_API naming convention, achieving precise positioning from "code-level division" to "test item-level division".

[0021] Innovation Point 3: An adaptive two-layer segmentation mechanism based on the coordination of preset row number thresholds and domain markers. An adaptive two-layer segmentation strategy for ATE test code is proposed: The first layer uses a preset line count threshold (T=200 lines) as a coarse screening condition to trigger a second layer of fine segmentation for excessively long test interface functions; the second layer utilizes three types of boundary markers unique to the ATE domain: comment markers (P1), SetTestResult call anchors (P2), and PARAM_BIND parameter anchors (P3) to identify the semantic boundaries of test items within the test interface functions, and generates semantically complete TestItemChunks according to the rule "from P1 to the nearest P2". This mechanism avoids the destruction of test logic integrity by fixed line count segmentation and solves the problem that overly fine segmentation cannot map independent test functions.

[0022] Innovation Point 4: A three-layer decoupling strategy for ATE test code: "context fields - system framework templates - structured samples". A differentiated utilization strategy for the layered parsing results of ATE test code is proposed—a three-layer decoupling of "context fields - system framework templates - structured samples": The L1 layer hardware resource declaration code is parsed into structured chip context fields (chip_context), serving as hardware constraints for structured samples. These, along with L3+L4+L5 (test interface function layer + hardware state control layer + result judgment and output layer), constitute standardized training samples, enabling the model to learn the mapping relationship between hardware conditions and test logic during the training phase. The L2 layer system initialization configuration is independently stored in the framework template library, not participating in model training, but only injected as a system framework template during code generation, ensuring the integrity of the generated code during runtime. This strategy achieves structural decoupling between training data and generation conditions—the model focuses on learning test logic generation capabilities (L3+L4+L5), the system configuration (L2) is guaranteed correctness by the template library, and the hardware environment (L1) serves as a conditional constraint guiding generation. Each layer performs its function, avoiding model overfitting to platform-specific initialization patterns while ensuring the integrity and executability of the generated code.

[0023] Specifically, embodiments of the present invention provide a method for constructing structured samples of ATE test code. Figure 1 This is a flowchart of a method for constructing structured samples of ATE test code according to an embodiment of the present invention. The embodiment of the present invention is applicable to scenarios of training sample construction, especially to scenarios of constructing structured samples for ATE testing. The method can be executed by an ATE test code structured sample construction device, which can be implemented in the form of software and / or hardware, and optionally, by an electronic device, preferably a mobile terminal, desktop computer, laptop computer, or server.

[0024] The core idea of ​​this invention is to propose a dedicated five-layer semantic hierarchical model for the ATE testing field, which deconstructs tens of thousands of lines of mixed test code hierarchically according to functional semantics rather than syntactic structure, thereby achieving a leap from "syntactic parsing" to "semantic understanding".

[0025] like Figure 1 As shown, the ATE test code structured sample construction method provided in this embodiment of the invention may specifically include: S101. Perform multi-level functional semantic division on the ATE test program source file to obtain the multi-level functional semantic division result; the multi-level functional semantic division result includes at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment output layer code; wherein, the hardware state control layer code and the result judgment output layer code are embedded inside the test interface function layer code.

[0026] The ATE test program source file can be understood as the original script file used for automated testing of a single chip under test (DUT). It can be written by test engineers using the ATE-specific programming language and includes ATE-specific semantics such as hardware operations, timing control, and frequency settings. Different types of test code within the ATE test program source file, including hardware declarations, system initialization, test logic, and hardware operations, are mixed within the global scope and hardware application programming interface (API) calls. The code lacks natural hierarchical boundaries and is typically quite large, often tens of thousands of lines long. The hardware resource declaration layer code can be considered to be located in the global area of ​​the ATE test program source file and is used to define the hardware resources required for chip testing. The system configuration layer code can be considered to be related to global system initialization and the basic configuration of the ATE test platform, providing system configuration-related context information for test code generation. The test interface function layer code can be understood as a collection of test interface functions that directly interact with the DUT (e.g., the chip under test); within each test interface function, there are also subdivided hardware state control layer code and result judgment and output layer code. The hardware state control layer code can be considered as the code related to all hardware state control operations; the result judgment and output layer code can be considered as the code related to test result judgment and data output operations.

[0027] In this embodiment, instead of hierarchically structuring the ATE test program source file based on its syntax, the source file is semantically layered according to the business functions performed by the test code. This splits the ATE test program source file, which contains mixed test code, into multiple independent layers: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment and output layer code, thus distinguishing between global configuration and test execution logic. For example, using the L790LDA chip: the hardware resource declaration layer code includes 8 relay channel mappings; the system configuration layer code includes initialization functions and relay initial OFF configuration; and the test interface function layer code includes 206 test interface functions (such as DUT_API type functions). Next, the hardware state control layer code and result judgment and output layer code embedded within each test interface function can be further identified according to functional semantics. The chip model mentioned above is only an example; this embodiment does not limit the chip model and can be selected based on requirements, such as the L7915 chip or a PMIC chip.

[0028] Optionally, one implementation of performing multi-level functional semantic division on the ATE test program source file to obtain hardware resource declaration layer code can be described as follows: Scan the ATE test program source file and identify hardware resource declaration statements by using the spatial location criterion "located before the first DUT_API"; wherein, the hardware resource declaration statements include at least one or more of the following types: channel declaration statements containing channel identifier keywords; relay declaration statements containing relay identifier keywords; power supply declaration statements containing power supply identifier keywords; instrument instantiation statements containing instrument type identifier keywords; and the set of all identified hardware resource declaration statements is determined as the hardware resource declaration layer code.

[0029] In this embodiment, pre-defined identification keywords can be used based on testing domain knowledge. Hardware resource declaration statements can be identified through pre-defined identification keywords and pattern matching, thereby improving the accuracy of obtaining hardware resource declaration layer code. For example, channel declaration statements can be identified through pattern matching using channel identification keywords such as "Connect" and "Channel," relay declaration statements can be identified through pattern matching using relay identification keywords such as "Relay," and power declaration statements can be identified through pattern matching using power identification keywords such as "DCVS" and "VI."

[0030] For example, the hardware resource declaration layer code may include: pin-channel binding declaration statements, such as StsSetModuleToSite(); relay macro definition declaration statements, such as K1~Kn, THB_Kn; global variable declaration statements, such as adresult array, flag bit, trim_code buffer; and instrument instantiation statements, such as FOVI / FPVI / QTMU+ / ACSM+ / DIO / CBIT.

[0031] Alternatively, another implementation of performing multi-level functional semantic partitioning on the ATE test program source file to obtain the hardware resource declaration layer code can be described as follows: inputting the ATE test program source file into a trained semantic recognition model, obtaining the hardware resource declaration statements output by the semantic recognition model, and integrating the hardware resource declaration statements to obtain the hardware resource declaration layer code.

[0032] Optionally, one implementation method for performing multi-level functional semantic division on the ATE test program source file to obtain system configuration layer code can be described as follows: identify the system-level initialization code in the ATE test program source file, including system parameter settings (such as function calls such as "SetSystemParam"), calibration operations (such as function calls such as "Calibration"), global variable initialization, etc.; integrate all system-level initialization code to obtain system configuration layer code.

[0033] For example, the system configuration layer code may include: function call statements that characterize the mapping from hardware modules to test sites, such as HardWareCfg(); function call statements that characterize instrument initialization before the test process, such as InitBeforeTestFlow(); function call statements that characterize the reset of the safety state after the test process, such as InitAfterTestFlow(); function call statements that characterize the hardware protection processing of failed sites, such as SetupFailSite(); and function call statements that characterize resource management during program loading / unloading, such as UserLoad() / UserExit().

[0034] Optionally, one implementation of performing multi-level functional semantic partitioning on the ATE test program source file to obtain the test interface function layer code can be described as follows: Identify all function definitions in the ATE test program source file, and based on a preset function naming prefix feature, label the test interface functions that directly interact with the device under test (e.g., the chip under test), thereby obtaining the test interface function layer code. For example, using "DUT_" as the preset function naming prefix feature, the obtained test interface functions are of type DUT_API.

[0035] For example, the test interface functions in the test interface function layer code may include connectivity test functions (such as open / short circuit test, contact detection, and continuity test), leakage current test functions (such as input leakage current test and output leakage current test), AC parameter test functions (such as output voltage accuracy test and quiescent current test), DC timing test functions (such as frequency test and load cycle test), functional logic test functions (such as undervoltage lockout test, enable test, protection function test, and logic test), tuning test functions (such as from measurement test before tuning to programming test and then to verification test after modification), and characteristic test functions (such as on-resistance test, efficiency test, and current limiting test).

[0036] In this embodiment, one implementation method for performing multi-level functional semantic division on the ATE test program source file to obtain the hardware state control layer code and the result judgment output layer code can be described as follows: perform multi-level functional semantic division on the ATE test program source file, identify the hardware state control operation statements and result judgment and output statements inside each of the test interface functions; obtain the hardware state control layer code based on the hardware state control operation statements, and obtain the result judgment output layer code based on the result judgment and output statements.

[0037] The hardware status control operation statements include at least relay switching operation statements, range switching operation statements, and mode switching operation statements, and the result judgment and output statements include at least test result judgment statements, result recording statements, and data output operation statements.

[0038] For example, after obtaining the test interface function layer code, hardware state control operation statements can be identified within each test interface function according to functional semantics. These statements include relay switching statements (such as "SetRelay"), range switching statements (such as "SetRange"), and mode switching statements. The identified hardware state control operation statements and / or statements related to these operations are then identified as the hardware state control layer code. Furthermore, result judgment and output statements can be identified within each test interface function according to functional semantics. These statements include test result judgment (such as "SetTestResult", "Pass / Fail"), result recording (such as "LogResult"), and data output statements. The identified result judgment and output statements are then identified as the result judgment and output layer code. The hardware state control layer code and the result judgment and output layer code are embedded within the test interface function layer code and do not exist independently.

[0039] For example, the hardware state control layer code may include: relay state management statements, such as cbit.SetOn(); instrument mode switching statements, such as FV (Force Voltage); dynamic range switching statements, such as FOVI_1V→FOVI_10V→FOVI_40V; AWG waveform configuration statements, such as trigger settings; and DIO digital communication statements, such as pattern loading.

[0040] For example, the result judgment output layer code may include: parameter binding statements, condition judgment statements, unit conversion statements, test result judgment statements (such as "SetTestResult"), and data output statements.

[0041] As an optional embodiment, before performing multi-level functional semantic partitioning on the ATE test program source file and obtaining the multi-level functional semantic partitioning result, optimization may be performed including: performing at least one of the following on the ATE test program source file: unified character encoding conversion, removing invalid characters, and removing redundant comments; and establishing a row index structure for the ATE test program source file.

[0042] In this embodiment, upon receiving the ATE test program source file, character encoding detection and unified conversion can be performed to ensure consistency in character encoding during subsequent processing, thereby eliminating parsing interference caused by differences in engineer coding styles. Invalid characters and redundant comments can also be removed, while meaningful comments (especially test item identifier comments) are retained to reduce interference from invalid code. Furthermore, a unique line number index can be assigned to each line of code in the ATE test program source file for quick location of various marker statements, test item identifier comments, and parameter binding statements, providing a foundation for the aforementioned multi-layered functional semantic division and subsequent test interface function segmentation and structured sample construction operations.

[0043] S102. Differentiated extraction based on multi-layer functional semantic segmentation results: Extract chip hardware context information from the hardware resource declaration layer code, extract system configuration from the system configuration layer code as a system framework template, and obtain test sample units or test item fragments by taking each test interface function in the test interface function layer code as the segmentation object.

[0044] In this embodiment, for the hardware resource declaration layer code, standardized hardware description data such as chip model, pin mapping, and instrument resources are extracted to form chip hardware context information; for the system configuration layer code, the system configuration is extracted and independently encapsulated to form a system framework template; for the test interface function layer code, each test interface function is treated as a processing object, and segmentation is determined based on the size of the function body code. If no segmentation is determined, the entire test interface function is directly used as a test sample unit; if segmentation is determined, the multiple code fragments obtained after segmenting the test interface function are used as test item fragments, and each test item fragment corresponds to a test item in the chip testing task.

[0045] S103. Perform structured extraction on the test sample unit or test item fragment to construct a structured sample; the structured sample includes at least: the code body, which contains the original code content of the code corresponding to the test sample unit or test item fragment and the hardware state control layer code and result judgment output layer code embedded within it; the context field, independent of the code body, which contains chip hardware context information bound by index association; and the semantic annotation field, which is extracted based on the hardware state control layer code, the result judgment output layer code, and the parameter binding statements in the test interface function.

[0046] In this embodiment, after obtaining the test sample unit or test item fragment, multi-dimensional structured semantic extraction and standardized encapsulation are performed to generate structured samples that can be directly used for subsequent automated analysis. The structured sample can be considered as the final output standardized sample used for model training, comprising three parts: code body, context fields, and semantic annotation fields. The code body can be considered as the original code carrier of the structured sample, constituting the core logical body of the structured sample. It stores the complete original code of the test sample unit or test item fragment, including all hardware state control layer code and result judgment output layer code within the test sample unit or test item fragment. The context fields can be understood as fields independent of the code body, used to provide the hardware resource background corresponding to the code body. For example, based on a pre-built row index structure, the chip hardware context information associated with the code body can be obtained through the index, and context fields can be formed based on the chip hardware context information.

[0047] In this embodiment, the semantic annotation field can be considered as a field used to supplement the missing business information in the main code. Optionally, the semantic annotation field includes at least the operation category set and hardware operation identifier sequence obtained based on the hardware state control layer code, the result identification information obtained based on the result judgment output layer code, and the parameter information obtained based on the parameter binding statement in the test interface function. For example, in addition to fields such as the operation category set, hardware operation identifier sequence, result identification information, and parameter information, the semantic annotation field may also include fields such as structured sample identifier (e.g., ID), the test type, etc., and may also include a source field to record the source of the structured sample for source tracing and localization. Optionally, the semantic annotation field may also be persistently stored.

[0048] In this embodiment, after the structured samples are constructed, they can be stored and used for subsequent model training, so that the model can learn intelligent processing capabilities related to chip testing by learning from the structured samples, such as the ability to automatically generate executable target test code based on chip testing requirements.

[0049] The ATE test code structured sample construction method provided in this embodiment of the invention realizes automated and accurate structure parsing of ATE test program source files, as well as fully automated conversion of unstructured ATE test code into structured semantic samples. Specifically, by performing multi-layered functional semantic partitioning on the ATE test program source files, precise separation of test program code according to functional semantics and accurate identification and boundary marking of the semantic layer code within the test interface functions are achieved. This overcomes the shortcomings of general code analysis methods, which can only identify syntactic units such as functions and classes but cannot distinguish the functional semantic differences between "hardware declarations" and "test logic," resulting in the loss of hardware context in the segmented fragments. Furthermore, by using each test interface function as the smallest segmentation unit for test code segmentation, automatic identification and accurate boundary positioning of test interface functions are achieved, reducing manual analysis costs and improving code structuring efficiency. By constructing structured samples with clear structure, complete semantics, and executability based on the code body and corresponding context fields and semantic annotation fields, the subsequent intelligent processing flow is effectively supported. It also ensures the structural separation of training data and generation conditions, enabling the subsequent model to focus on test logic learning without being affected by hardware constraints and specific platform initialization modes. Moreover, the model learns the mapping relationship between hardware conditions and test logic during the training phase, thereby improving the effectiveness, accuracy, and executability of automated code generation.

[0050] As a first optional embodiment of the present invention, based on the above embodiments, the method can be further optimized to include: the system framework template is independent of the structured sample storage and is not included in the code body; during the code generation stage, the system framework template is injected as framework information into the code generation process and used in conjunction with the code body and context fields in the structured sample to ensure the integrity of the generated code during runtime.

[0051] The code generation stage can be understood as the stage where the model generates code based on structured samples. For example, it can be the downstream application stage after training is completed, that is, the stage where the model automatically generates code to meet the needs of chip testing business after training based on structured samples.

[0052] It should be noted that the system framework template is extracted from the system configuration layer code. In this embodiment, the identification of the system configuration layer code includes: identifying non-test interface functions whose function bodies end before the start of the first test interface function as system configuration layer code.

[0053] In this embodiment, the system framework template is not included in the structured samples. It only participates in the code generation stage to provide the required context, but does not participate in the learning process during model training. This setting decouples the core logic of the test items from the global hardware constraints, ensures the reusability of the samples, and solves the problem of missing pre-run configuration in the generated code. This avoids the model from overfitting to the platform-specific initialization mode and ensures the integrity and executability of the generated code, providing support for the reuse of structured samples across test platforms and automated code generation.

[0054] As one implementation, the system framework template and the structured sample are stored separately. When the same model of chip is deployed on different ATE test platforms, the code body, context fields and semantic annotation fields in the structured sample remain unchanged, and only the system framework template corresponding to the target ATE test platform is replaced, so as to realize the cross-platform reuse of the structured sample between different ATE test platforms.

[0055] The target ATE test platform can be understood as an automated test device that performs chip testing.

[0056] It is known that different manufacturers and models of ATE test platforms have their own exclusive system initialization logic, underlying driver configuration, etc. Therefore, when the same chip under test needs to be tested on multiple different models and manufacturers of ATE test platforms, the only difference is the system framework template related to the underlying system initialization configuration of the device.

[0057] Based on this, in this embodiment, the structured samples unrelated to the ATE test platform do not need to be regenerated, while the system framework template related to the ATE test platform needs to be switched according to the ATE test platform. Therefore, the system framework template and the structured samples are stored separately. When switching ATE test platforms to test the same chip, the structured samples corresponding to the chip remain unchanged, and only the system framework template matching the target ATE test platform after the switch is replaced.

[0058] The above-described technical solution in this embodiment decouples the system framework template strongly related to the ATE test platform and the structured samples strongly related to the chip, thereby decoupling the test logic from the platform configuration. This balances the model training effect with the ability to adapt to multiple platforms, reduces the workload of repeatedly building structured samples, and improves the efficiency of sample data reuse.

[0059] As a second optional embodiment of the present invention, based on the above embodiments, the step of obtaining test sample units or test item fragments by taking each test interface function in the test interface function layer code as the segmentation object can be optimized as follows: The test interface functions that directly interact with the device under test are identified from the test interface function layer code by using function naming prefix features. Each test interface function is taken as the smallest functional unit, and the code is segmented based on the size of the function body to obtain test sample units or test item fragments.

[0060] The function naming prefix can be understood as a pre-agreed, standardized sequence of characters at the beginning of the function name. It serves as the basis for distinguishing between chip-interaction-specific test interface functions and ordinary auxiliary functions. Specifically, in the ATE test program source file, test interface functions that directly interact with the device under test (DUT) will be uniformly configured with a unique naming prefix, while other functions, such as utility functions and general auxiliary functions, will not carry this prefix. The DUT can be considered the chip being tested, i.e., the test object of the ATE test program source file.

[0061] In this embodiment, as one implementation, the test interface functions that directly interact with the device under test can be identified from the test interface function layer code using function naming prefix features. Each test interface function is taken as the smallest functional unit, and the code is segmented based on the function body size to obtain test sample units or test item fragments. This can be further optimized as follows: A1. Scan the test interface function layer code, identify functions with preset naming prefixes, and determine the identified functions as test interface functions that directly interact with the device under test.

[0062] In this embodiment, the function can be accurately located by recognizing the preset naming prefix, and the function range can be confirmed by tracing the curly braces from the beginning of the function to obtain the complete code block, i.e., the test interface function.

[0063] For example, if DUT_ is used as the preset naming prefix, the selected test interface function can be a function of type DUT_API, and the test interface function serves as the basic unit for subsequent adaptive segmentation.

[0064] A2. For each test interface function, obtain the number of lines of code corresponding to that test interface function.

[0065] In this embodiment, for each test interface function, the number of lines of code corresponding to the test interface function can be used as the code size of the function body, providing a quantitative basis for the segmentation decision.

[0066] A3. If the number of lines of code is less than or equal to a preset line count threshold, then the test interface function will be used as a test sample unit.

[0067] In this embodiment, the number of lines of code in the test interface function is compared with a preset line count threshold. If the number of lines of code is less than or equal to the preset line count threshold, it indicates that the logic of the test interface function is relatively simple. Therefore, it can be directly regarded as a complete test sample unit for subsequent structured feature extraction without further segmentation.

[0068] It should be noted that this embodiment employs an adaptive two-layer segmentation mechanism based on a preset line count threshold and domain markers. The adaptive two-layer segmentation strategy for ATE test code is as follows: The first layer uses a preset line count threshold (T=200 lines) as a coarse screening condition, triggering a second layer of fine segmentation for excessively long test interface functions; the second layer utilizes three types of boundary markers unique to the ATE domain—annotation marker (P1), SetTestResult call anchor (P2), and PARAM_BIND parameter anchor (P3)—to identify the semantic boundaries of test items within the function, generating semantically complete TestItem Chunks according to the rule "from P1 to the nearest P2". This mechanism avoids the destruction of test logic integrity by fixed line count segmentation and solves the problem that overly fine segmentation cannot map independent test functions. The specific processing flow is shown in the following embodiment.

[0069] For example, the preset row count threshold can be 200 rows. This embodiment does not limit this and can be flexibly set based on actual needs or experience.

[0070] A4. If the number of lines of code is greater than the preset line number threshold, the test interface function is divided according to the segment start semantic marker and segment end semantic marker in the test interface function to obtain multiple test item segments, and each test item segment corresponds to a test item in the chip test task.

[0071] The segment start semantic marker includes the location of the test item identifier comment or the parameter binding statement within the test interface function, and the segment end semantic marker includes the location of the test result determination statement within the test interface function. The segment start semantic marker can be understood as the code location within the test interface function that marks the starting boundary of an independent test item. The segment end semantic marker can be considered as the boundary location within the test interface function representing the completion of a single test item, and can be fixed at the line containing the test result determination statement.

[0072] In this embodiment, if the number of lines of code exceeds a preset line count threshold, it indicates that the test interface function is a complex function. Therefore, test item boundary markers, namely the segment start semantic marker and the segment end semantic marker, can be identified within it. Fine-grained segmentation is then performed according to the rules from the segment start semantic marker to the line preceding the most recent segment start semantic marker, generating semantically complete test item segments. It should be noted that the most recent segment start semantic marker can refer to the starting position of the next test item segment; in this embodiment, it can also be the execution of rules from the segment start semantic marker to the segment end semantic marker to generate semantically complete test item segments.

[0073] Optionally, one implementation of dividing the test interface function based on the segment start semantic marker and segment end semantic marker in the test interface function to obtain multiple test item segments can be specifically described as follows: A41. Identify all test item identifiers, annotations, parameter binding statements, and test result determination statements in the test interface function, and determine the location of each test result determination statement as a semantic marker for the end of a segment.

[0074] In this embodiment, test item identifier annotations can be understood as standardized comment text added by engineers when writing code, specifically used to mark the beginning of a new chip test item, for example, / / Test Item: XXX. Parameter binding statements can be considered as code statements used to bind parameters required for chip testing, such as the PARAM_BIND function call location. Test result determination statements can be considered as execution statements related to test result determination (pass / fail), output, and storage, and can naturally serve as the end boundary of a single test item, such as the SetTestResult function call location.

[0075] A42. For each segment end semantic marker, determine the target interval corresponding to the segment end semantic marker.

[0076] The target interval can be understood as a continuous range of code defined forward from a semantic marker at the end of a segment. Each semantic marker at the end of a segment uniquely corresponds to an independent target interval, which contains all the code of the complete single test item.

[0077] Optionally, one implementation of determining the target interval corresponding to the segment end semantic marker can be described as follows: when there are no other segment end semantic markers before the segment end semantic marker, the target interval is formed based on the segment end semantic marker and the starting position of the test interface function; when there are other segment end semantic markers before the segment end semantic marker, the target interval is formed based on the segment end semantic marker and the next row of the preceding segment end semantic marker that satisfies a first condition; wherein, the first condition includes being closest to the segment end semantic marker and located before the segment end semantic marker.

[0078] In this embodiment, for each segment end semantic marker, if there are no other segment end semantic markers before it, the starting line of the entire test interface function is determined as the starting point of the target interval, forming the target interval with the segment end semantic marker. If there are other segment end semantic markers before it, the line following the nearest preceding segment end semantic marker is selected as the starting point of the target interval, forming the target interval with the segment end semantic marker. This setting ensures that all target intervals are non-overlapping and interconnected, completely covering the entire test interface function and avoiding code omissions and interval overlap issues.

[0079] A43. If a test item identifier annotation exists within the target interval, the location of the test item identifier annotation is taken as the corresponding segment start semantic marker, and the test interface function is divided according to the segment start semantic marker and the segment end semantic marker to obtain a test item segment.

[0080] In this embodiment, for each target interval, it is first determined whether there is a test item identifier annotation. If there is, the location of the test item identifier annotation is used as the segment starting point, that is, the segment start semantic marker point. All the code covered from the segment start semantic marker point to the segment end semantic marker point constitutes a test item segment.

[0081] A44. If there is no test item identifier annotation but there is a parameter binding statement, take the position of the parameter binding statement in the target interval as the corresponding segment start semantic marker point, and divide the test interface function according to the segment start semantic marker point and the segment end semantic marker point to obtain a test item segment.

[0082] In this embodiment, after determining that no test item identifier annotation exists, it further determines whether a parameter binding statement exists within the target interval. If it does, the location of the parameter binding statement is used as the segment starting point, i.e., the segment start semantic marker point. Combined with the segment end semantic marker point, the test interface function is divided to obtain a test item segment. This setting ensures that the starting position of the test logic can still be accurately located even when no test item identifier annotation exists.

[0083] A45. If there are neither test item identifiers nor parameter binding statements within the target interval, the starting position of the target interval is taken as the corresponding segment start semantic marker, and the test interface function is divided according to the segment start semantic marker and the segment end semantic marker to obtain a test item segment.

[0084] In this embodiment, if there are neither test item identifiers nor parameter binding statements within the target interval, the starting position of the target interval is directly used as the segment starting point. This setting ensures compatibility with non-standard test code without any markings, guaranteeing that the solution is universally applicable to all project code.

[0085] A46. Summarize the test item fragments to obtain multiple test item fragments corresponding to the test interface function.

[0086] The above-described technical solution in this embodiment automatically identifies test interface functions by pre-setting a naming prefix, accurately filtering irrelevant functions and providing precise positioning for achieving code-level segmentation to test item-level segmentation. Using a preset line count threshold as a coarse screening condition, it distinguishes between test interface functions that can directly constitute test sample units and longer test interface functions that require fine segmentation based on the line count of the corresponding code, thus achieving differentiated processing of long and short functions and balancing parsing efficiency and sample granularity. Then, it utilizes three types of boundary markers unique to the ATE domain: the location of test item identification comments, the location of parameter binding statements, and the location of test result judgment statements. The system identifies the semantic boundaries of test items within the test interface function, namely the semantic markers at the beginning and end of the segment. The test result judgment statement serves as the unified endpoint for segmentation. The interval isolation mechanism prevents code overlap and omissions. Simultaneously, the test interface function is adaptively divided according to the rule from the semantic marker at the beginning of the segment to the nearest semantic marker at the end of the segment, resulting in multiple semantically complete test item segments. This effectively solves the problem of difficult sample granularity control. It avoids the destruction of test logic integrity by fixed-line segmentation, solves the problem that overly fine segmentation cannot map independent test functions, and achieves reasonable control of sample size.

[0087] To better understand the technical solutions provided by the above optional embodiments, specific examples are given here. Example 1: For the ATE test program source file corresponding to the L790LDA negative voltage LDO chip, after performing multi-level functional semantic division on the ATE test program source file, the test interface function layer code is obtained. The test interface function DUT_API int Peak_Current() in the test interface function layer code can be identified by the preset naming prefix DUT_API. The scope of the test interface function is confirmed by tracing the curly braces from the start position of the test interface function, extracting the complete code block, and determining the line number of the code block corresponding to the test interface function. When the number of lines is 51 and the preset line number threshold is 200, since the number of lines is less than the preset line number threshold, the entire code block corresponding to the test interface function is directly taken as a test sample unit. The test interface function can embed hardware state control layer code containing relay operation control statements (such as cbit.SetOn(K1) / cbit.SetOff(K1)) and voltage excitation application statements (such as FOVI.ForceVoltage(-23.0)), as well as result judgment output layer code containing output measurement statements (such as FOVI.MeasureVoltage()) and result reporting statements (such as pV00->SetTestResult()).

[0088] Example 2: For the ATE test program source file corresponding to the PMIC chip, after performing multi-level functional semantic division on the ATE test program source file, the test interface function layer code is obtained. The Charge test interface function with the preset naming prefix DUT_API can be identified in the test interface function layer code. The scope of the test interface function is confirmed by tracing the curly braces from the start position of the test interface function, extracting the complete code block, and determining the line number of the corresponding code block. When the number of lines is 3143 and the preset line number threshold is 200, since the number of lines exceeds the preset line number threshold, the test interface function is further finely divided based on the initial segmentation.

[0089] In the fine segmentation process, approximately 30 test item boundaries within the test interface function are first identified using three types of markers. These three types of markers are: P1 markers representing the location of test item identifier comments, P2 markers representing the location of parameter binding statements, and P3 markers representing the location of test result determination statements. P1 markers are determined based on the locations of the 30 identified test item identifier comments, such as / / 5)I_CC1.5A--- and / / 6)I_CC1A---; P2 markers are determined based on the identified parameter binding statements; and P3 markers are determined based on the identified test result determination statements (such as the 33 SetTestResult function call locations).

[0090] The test interface functions are divided according to three types of markers. Taking the test item segment corresponding to the I_CC1.5A test item as an example, the test item segment contains about 136 lines of code, involving preceding hardware operations (VIN.Set, BATT.Set, etc.), test execution (BATT_SYSFR.MeasureVI, etc.), test writing (I_CC1p5A->SetTestResult), and parameter control identifiers, etc., and is bound to complete chip context information.

[0091] The Charger test interface function was ultimately segmented into approximately 30 appropriately granular test item fragments. Each test item fragment maintained semantic integrity and independence, and the segmentation accuracy was significantly better than that of a fixed-line-count segmentation scheme. Through the above processing, the test code in the PMIC chip's corresponding ATE test program source file can be converted into a set of clearly structured semantic code fragments, laying the foundation for providing accurate structured input to the subsequent automated analysis model of ATE test code.

[0092] To better understand the technical solution, an implementation example of adaptive splitting for test interface functions is given here. Figure 2This is a flowchart illustrating the adaptive segmentation of test interface functions in a method for constructing structured ATE test code samples according to an embodiment of the present invention. Figure 2 As shown, the adaptive segmentation logic can be described as follows: S21. Extract test interface functions with preset naming prefixes and create a list of test interface functions.

[0093] S22. For each test interface function in the list of test interface functions, count the number of lines of code corresponding to the function body of the test interface function.

[0094] S23. Determine whether the number of lines of code is greater than the preset line number threshold. If not, proceed to step S24. If yes, proceed to steps S25 to S28.

[0095] S24. Treat the test interface function directly as a test sample unit and end the segmentation process.

[0096] S25. Identify the location of test item identifier comments in the test interface function.

[0097] S26. Identify the location of parameter binding statements in the test interface function.

[0098] S27. Identify the location of the test result determination statement in the test interface function.

[0099] S28. Based on the three types of positions, determine the starting semantic marker and ending semantic marker of the segment, and divide the test interface function according to the rule from the starting semantic marker to the ending semantic marker of the segment to obtain multiple test item segments, and end the segmentation process.

[0100] Understandably, if the number of lines of code exceeds a preset threshold, steps S25, S26, and S27 can be executed in parallel or sequentially; the execution order is not restricted here. In the case of sequential execution, the execution order of the three steps can be flexibly determined based on needs.

[0101] As a third optional embodiment of the present invention, based on the above embodiments, the structured extraction of the test sample unit or test item fragment to construct a structured sample can be specified as the following steps: B1. For each test sample unit or test item segment, generate hardware state control information corresponding to the test sample unit or test item segment according to the hardware state control layer code. The hardware state control information includes a hardware operation identifier sequence and a corresponding operation category set. The operation category set includes at least relay control category, excitation application category, time delay category, measurement category and / or result reporting category.

[0102] Hardware state control information can be understood as standardized structured data generated from parsing hardware operation code within a single test sample unit or test item fragment. This data uniformly records the execution order and operation type of all hardware operations within the fragment, eliminating semantic recognition barriers caused by the free-flowing style of the original code and clarifying the hardware state control requirements that need to be implemented during model learning and code generation. The hardware operation identifier sequence can be understood as a sequence formed by arranging hardware operation identifiers according to the actual execution order of the code, used to completely reconstruct the hardware operation execution sequence in the test process. The operation category set can be considered as a set containing operation categories, which can be obtained by classifying hardware operation identifiers according to their business functions.

[0103] In this embodiment, each test sample unit or test item fragment undergoes syntax parsing to identify all hardware state control layer code contained within it, such as hardware operation statements for relays, excitation, and measurement. Next, hardware operation application programming interface (API) calls are identified from the identified hardware state control layer code, and function identifiers, parameter lists, and execution order are extracted. A hardware operation identifier sequence is generated according to the actual code execution flow. Then, a pre-established mapping rule between hardware operation APIs and operation categories is obtained. Based on preset operation categories (including relay control, excitation application, delay, measurement, and result reporting categories determined by function), each hardware operation API in the hardware operation identifier sequence is categorized to obtain an operation category set. Hardware state control information corresponding to the test sample unit or test item fragment is generated based on the hardware operation identifier sequence and the operation category set, realizing the transformation from fine-grained hardware operation APIs to the engineering semantic stage.

[0104] B2. Based on the results, determine the output layer code and obtain the result identification information corresponding to the test sample unit or test item fragment. The result identification information includes the test item name, result variable, judgment condition, and site information.

[0105] In this embodiment, each test sample unit or test item fragment is parsed to identify all result judgment output layer code contained within the test sample unit or test item fragment. Specific function call nodes, such as the SetTestResult call node, are located within the result judgment output layer code. Test item names, result variables, and judgment conditions (threshold boundaries, comparison logic) are extracted. Optionally, in multi-site scenarios, site information such as site number and corresponding result mapping can also be extracted synchronously. Result identification information is formed based on the extracted content to support the subsequent model learning of judgment rules for various test logics.

[0106] B3. Obtain parameter information based on the parameter binding statements in the test sample unit or test item fragment. The parameter information includes parameter name, parameter type, and parameter value range.

[0107] In this embodiment, parameter binding statements, such as StsGetParam and PARAM_BIND, can be identified from each test sample unit or test item fragment. The parameter name, parameter type, and parameter value range can be extracted and categorized into input parameters, output parameters, or configuration parameters according to their scope and flow, forming a structured parameter list. This provides parameter information to support the subsequent model in mastering parameter configuration specifications under different test scenarios and avoiding the generation of target test code with out-of-bounds or incorrect types of parameters.

[0108] B4. The test sample unit or test item fragment is used as the code body, the chip hardware context information is used as the context field, and the hardware state control information, the result identification information and the parameter information are used as semantic annotation fields. The chip hardware context information includes at least the chip model, pin mapping and instrument resources.

[0109] In this embodiment, the test sample unit or test item fragment is directly used as the main code body to retain the original code syntax, which embeds the corresponding hardware state control layer code and result judgment output layer code. Next, structured chip hardware context information such as chip model, pin mapping, and instrument resources can be extracted from the hardware resource declaration layer code as context fields for the test sample unit or test item fragment, providing a complete chip hardware background. Then, the extracted information can be integrated to generate a standardized structured description, which may include fields such as test sample unit or test item fragment identifier, test type, hardware state control information, result identifier information, and parameter information, serving as machine-readable semantic tags corresponding to the test sample unit or test item fragment, and can be persistently stored in a structured sample library.

[0110] B5. Based on the code body, context fields, and semantic annotation fields, combined with a preset structured template, obtain a structured sample.

[0111] In this embodiment, the obtained code body, context fields, and semantic annotation fields can be encapsulated and integrated according to the preset structured template format and index association rules, thereby eliminating the format differences caused by different codes, different chips, and different engineers, so as to support batch reading and learning of the model.

[0112] In one scenario, structured samples can be in JSON format. Based on this, for example, a pre-defined structured template can be represented as: / / JSON format, structured template { "sample_id": "Unique identifier", "source": {"file": "source file", "original_function": "original function name"}, "chip": {"model": "chip model", "category": "chip type", "sites": number of sites, "pins": {}}, "code": "The complete code corresponding to the test sample unit or test item fragment", "labels": { "test_category": "Automatically inferred test type", "pattern_type": "Automatically inferred pattern type", "composition": ["stage combination"], "operation_sequence": ["operation sequence"], "instruments": ["instruments used"], "quality_score": "Quality score" } }

[0113] It is known that the test sample unit may be very simple, containing very few lines of code, and may not contain hardware state control layer code, result judgment and output layer code, and / or parameter binding statements. Based on this, in this embodiment, before performing structured extraction on the test sample unit or test item fragment, it can be determined what information the test sample unit contains, thereby matching it with the structured extraction operation for the corresponding dimension, and directly assigning empty results for other dimensions. Alternatively, structured extraction can be performed directly on the test sample unit or test item fragment; if information for that dimension does not exist, the output is empty.

[0114] The above-described technical solution in this embodiment constructs structured samples based on the code body, context fields, and semantic annotation fields in conjunction with a preset structured template. This provides clearly structured and semantically complete samples for subsequent automated analysis and processing of ATE test code, effectively supporting the subsequent intelligent processing flow. At the same time, it decouples the core logic of the test item from global hardware constraints, completes the conversion from unstructured code text to structured semantic data, and ensures the reusability of the samples and the executability and accuracy of the generated code.

[0115] To better understand the technical solution, an implementation example of obtaining structured samples is given here. The method of obtaining structured samples based on test sample units is the same as the method of obtaining structured samples based on test item fragments. Here, we take test item fragments as an example. Figure 3 This is a schematic diagram illustrating the process of obtaining structured samples in a method for constructing structured samples of ATE test code according to an embodiment of the present invention. Figure 3 As shown, the execution logic for obtaining structured samples can be described as follows: S31. Obtain test item fragments.

[0116] S32. Extract all hardware application interface calls from the test item fragment based on the hardware state control layer code, and arrange them in the execution order to obtain a hardware operation identifier sequence.

[0117] S33. Classify each hardware application programming interface in the hardware operation identifier sequence into its corresponding operation category to obtain an operation category set. The operation category set shall include at least: relay control category, excitation application category, time delay category, measurement category, and result reporting category.

[0118] S34. Based on the result, determine the output layer code and obtain the result identification information corresponding to the test item fragment. The result identification information includes the test item name, result variable, and judgment condition.

[0119] S35. Obtain parameter information based on the parameter binding statements in the test item fragment.

[0120] S36. Generate structured samples based on test item fragments, chip hardware context information, hardware operation identifier sequences, operation category sets, result identifier information, and parameter information.

[0121] S37, Output structured samples.

[0122] S38. Store the structured samples in the structured sample library.

[0123] Figure 4 This is a schematic diagram illustrating the principle of a method for constructing structured samples of ATE test code provided in an embodiment of the present invention. Figure 4 As shown, the method first performs multi-layer functional semantic division on the obtained ATE test program source file to obtain hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment output layer code. Among them, the hardware state control layer code and the result judgment output layer code are embedded inside the test interface function layer code.

[0124] Then, the system configuration in the system configuration layer code is extracted into a system framework template, and the system framework template is stored independently of the structured sample and is not included in the code body. Only during the code generation stage, the system framework template is injected as framework information into the code generation process and used in conjunction with the code body and context fields in the structured sample to ensure the integrity of the generated code during runtime.

[0125] Furthermore, chip hardware context information is extracted from the hardware resource declaration layer code, and each test interface function in the test interface function layer code is adaptively segmented based on a preset line count threshold to obtain test sample units or test item fragments. The adaptive segmentation logic can be described as follows: if the number of lines of code corresponding to the test interface function is less than or equal to the preset line count threshold, then the test interface function is used as a test sample unit; if the number of lines of code corresponding to the test interface function is greater than the preset line count threshold, then the test interface function is divided to obtain multiple test item fragments. Next, the test sample units or test item fragments are extracted in a structured manner, and the corresponding chip hardware context information is bound by index association to construct structured samples. The structured samples are then saved and output so that they can be used as training samples for model training.

[0126] Figure 5 This is a schematic diagram of a structured sample construction device for ATE test code provided in an embodiment of the present invention. Figure 5 As shown, the device includes: a semantic segmentation module 51, an information extraction module 52, and a sample construction module 53.

[0127] The semantic segmentation module 51 is used to perform multi-level functional semantic segmentation on the ATE test program source file to obtain multi-level functional semantic segmentation results. The multi-level functional semantic segmentation results include at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment output layer code. The hardware state control layer code and result judgment output layer code are embedded inside the test interface function layer code. Information extraction module 52 is used to perform differential extraction based on the multi-layer functional semantic division results: extract chip hardware context information from the hardware resource declaration layer code, extract system configuration in the system configuration layer code as a system framework template, and obtain test sample units or test item fragments by taking each test interface function in the test interface function layer code as the segmentation object. The sample construction module 53 is used to perform structured extraction on the test sample unit or test item fragment to construct a structured sample; The structured sample includes at least: The main body of the code includes the original code content of the code corresponding to the test sample unit or test item fragment, as well as the hardware state control layer code and result judgment output layer code embedded within it; The context field, independent of the code body, contains the chip hardware context information that is bound by an index; The semantic annotation field is extracted from the hardware state control layer code, the result judgment output layer code, and the parameter binding statements in the test interface function.

[0128] The ATE test code structured sample construction device provided in this embodiment of the invention realizes automated and accurate structure parsing of ATE test program source files, as well as fully automated conversion of unstructured ATE test code into structured semantic samples, thereby efficiently providing sufficient usable training samples for the model. Specifically, by performing multi-layered functional semantic partitioning on the ATE test program source files, precise separation of test program code according to functional semantics and accurate identification and boundary marking of the semantic layer code within the test interface functions are achieved. This overcomes the shortcomings of general code analysis methods, which can only identify syntactic units such as functions and classes but cannot distinguish the functional semantic differences between "hardware declarations" and "test logic," resulting in the loss of hardware context in the segmented fragments. Furthermore, by using each test interface function as the smallest segmentation unit for test code segmentation, automatic identification and accurate boundary positioning of test interface functions are achieved, reducing manual analysis costs and improving code structuring efficiency. By constructing structured samples with clear structure, complete semantics, and executability based on the code body and corresponding context fields and semantic annotation fields, the subsequent intelligent processing flow is effectively supported. It also ensures the structural separation of training data and generation conditions, enabling the subsequent model to focus on test logic learning without being affected by hardware constraints and specific platform initialization modes. Moreover, the model learns the mapping relationship between hardware conditions and test logic during the training phase, thereby improving the effectiveness, accuracy, and executability of automated code generation.

[0129] Furthermore, the system framework template is independent of the structured sample storage and is not included in the main code body; During the code generation phase, the system framework template is injected as framework information into the code generation process and used in conjunction with the code body and context fields in the structured sample to ensure the runtime integrity of the generated code.

[0130] Furthermore, the semantic segmentation module 51 can specifically be used for: The ATE test program source file is divided into multiple functional semantics to identify the hardware state control operation statements and result judgment and output statements inside each test interface function. The hardware state control layer code is obtained based on the hardware state control operation statement, and the result judgment output layer code is obtained based on the result judgment and output statement; The hardware status control operation statements include at least relay switching operation statements, range switching operation statements, and mode switching operation statements, and the result judgment and output statements include at least test result judgment statements, result recording statements, and data output operation statements.

[0131] Furthermore, the information extraction module 52 may specifically include: The function extraction and segmentation module is used to identify test interface functions that directly interact with the device under test from the test interface function layer code by using function naming prefix features. Each test interface function is used as the smallest functional unit, and segmentation is performed based on the size of the function body code to obtain test sample units or test item fragments.

[0132] Furthermore, the function extraction and slicing module may specifically include: The function identification unit is used to scan the test interface function layer code, identify functions with preset naming prefixes, and determine the identified functions as test interface functions that directly interact with the device under test. The scale determination unit is used to obtain the number of lines of code corresponding to each test interface function; A test sample unit is used to determine the test interface function as a test sample unit if the number of lines of code is less than or equal to a preset line number threshold. The test item fragment determination unit is used to divide the test interface function according to the fragment start semantic marker and fragment end semantic marker in the test interface function if the number of lines of code is greater than a preset line number threshold, thereby obtaining multiple test item fragments, each test item fragment corresponding to a test item in the chip test task; The segment start semantic marker includes the location of the test item identifier annotation or the parameter binding statement in the test interface function, and the segment end semantic marker includes the location of the test result determination statement in the test interface function.

[0133] Furthermore, the test item fragment determination unit may specifically include: The identification subunit is used to identify all test item identifiers, annotations, parameter binding statements, and test result determination statements in the test interface function, and to determine the position of each test result determination statement as a semantic marker point for the end of the segment. The interval determination subunit is used to determine the target interval corresponding to the end semantic marker of each segment for each segment end semantic marker. The first partitioning subunit is used to, if there is a test item identifier annotation in the target interval, take the position of the test item identifier annotation as the corresponding segment start semantic marker point, and partition the test interface function according to the segment start semantic marker point and the segment end semantic marker point to obtain a test item segment; The second division subunit is used to divide the test interface function into a test item segment if there is no test item identifier annotation but there is a parameter binding statement, by taking the position of the parameter binding statement in the target interval as the corresponding segment start semantic marker point, and dividing the test interface function according to the segment start semantic marker point and the segment end semantic marker point. The third division subunit is used to divide the test interface function into a test item segment if there is neither a test item identifier annotation nor a parameter binding statement in the target interval. The summarization subunit is used to summarize each of the test item fragments to obtain multiple test item fragments corresponding to the test interface function.

[0134] Furthermore, the interval determination sub-unit can specifically be used for: When there are no other segment end semantic markers before the segment end semantic marker, the target interval is formed based on the segment end semantic marker and the starting position of the test interface function. When there are other segment end semantic markers before the segment end semantic marker, the target interval is formed based on the segment end semantic marker and the next row of the preceding segment end semantic marker that satisfies the first condition. The first condition includes being closest to the semantic marker of the end of the segment and being located before the semantic marker of the end of the segment.

[0135] Furthermore, the sample construction module 53 can specifically be used for: For each test sample unit or test item segment, hardware state control information corresponding to the test sample unit or test item segment is generated according to the hardware state control layer code. The hardware state control information includes a hardware operation identifier sequence and a corresponding operation category set. The operation category set includes at least relay control category, excitation application category, time delay category, measurement category and / or result reporting category. Based on the results, the output layer code is determined to obtain the result identification information corresponding to the test sample unit or test item fragment. The result identification information includes the test item name, result variable, judgment condition, and site information. Based on the parameter binding statements in the test sample unit or test item fragment, parameter information is obtained, including parameter name, parameter type and parameter value range; The test sample unit or test item fragment is used as the code body, the chip hardware context information is used as the context field, and the hardware state control information, the result identification information and the parameter information are used as semantic annotation fields. The chip hardware context information includes at least the chip model, pin mapping and instrument resources. A structured sample is obtained by combining the code body, context fields, and semantic annotation fields with a preset structured template.

[0136] Furthermore, the device also includes a preprocessing module, which can specifically be used for: Before performing multi-level functional semantic partitioning on the ATE test program source file and obtaining the multi-level functional semantic partitioning result, at least one of the following is performed on the ATE test program source file: unified character encoding conversion, removal of invalid characters, and removal of redundant comments; Establish the line index structure of the ATE test program source file.

[0137] Furthermore, the semantic segmentation module 51 can specifically be used for: Scan the ATE test program source file and identify hardware resource declaration statements through pattern matching; The hardware resource declaration statement includes at least one or more of the following types: The channel declaration statement contains the channel identifier keyword; The relay declaration statement includes the relay identification keyword; Power declaration statements, including power identification keywords; The instrument instantiation statement contains the instrument type identifier keyword; The set of all identified hardware resource declaration statements is determined as the hardware resource declaration layer code.

[0138] Furthermore, the system framework template and the structured sample are stored separately. When the same model of chip is deployed on different ATE test platforms, the code body, context fields and semantic annotation fields in the structured sample remain unchanged, and only the system framework template corresponding to the target ATE test platform is replaced, so as to realize the cross-platform reuse of the structured sample between different ATE test platforms.

[0139] The ATE test code structured sample construction device provided in this embodiment of the invention can execute the ATE test code structured sample construction method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0140] Figure 6 A schematic diagram of an electronic device 60 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0141] like Figure 6 As shown, the electronic device 60 includes at least one processor 61 and a memory, such as a read-only memory (ROM) 62 and a random access memory (RAM) 63, communicatively connected to the at least one processor 61. The memory stores computer programs executable by the at least one processor. The processor 61 can perform various appropriate actions and processes based on the computer program stored in the ROM 62 or loaded from storage unit 68 into the RAM 63. The RAM 63 can also store various programs and data required for the operation of the electronic device 60. The processor 61, ROM 62, and RAM 63 are interconnected via a bus 64. An input / output (I / O) interface 65 is also connected to the bus 64.

[0142] Multiple components in electronic device 60 are connected to I / O interface 65, including: input unit 66, such as keyboard, mouse, etc.; output unit 67, such as various types of monitors, speakers, etc.; storage unit 68, such as disk, optical disk, etc.; and communication unit 69, such as network card, modem, wireless transceiver, etc. Communication unit 69 allows electronic device 60 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0143] Processor 61 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 61 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 61 performs the various methods and processes described above, such as the ATE test code structured sample construction method.

[0144] In some embodiments, the ATE test code structured sample construction method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 68. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 60 via ROM 62 and / or communication unit 69. When the computer program is loaded into RAM 63 and executed by processor 61, one or more steps of the ATE test code structured sample construction method described above can be performed. Alternatively, in other embodiments, processor 61 can be configured to execute the ATE test code structured sample construction method by any other suitable means (e.g., by means of firmware).

[0145] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0146] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on 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.

[0147] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0148] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for constructing structured samples of ATE test code, characterized in that, include: The ATE test program source file is divided into multiple functional semantics to obtain the results of the multi-level functional semantics division. The multi-layer functional semantic partitioning result includes at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment and output layer code; wherein, the hardware state control layer code and the result judgment and output layer code are embedded inside the test interface function layer code; Differential extraction is performed based on the results of the multi-layer functional semantic division: chip hardware context information is extracted from the hardware resource declaration layer code, system configuration in the system configuration layer code is extracted as a system framework template, and each test interface function in the test interface function layer code is used as a segmentation object to obtain test sample units or test item fragments. The test sample units or test item fragments are extracted in a structured manner to construct structured samples; The structured sample includes at least: The main body of the code includes the original code content of the code corresponding to the test sample unit or test item fragment, as well as the hardware state control layer code and result judgment output layer code embedded within it; The context field, independent of the code body, contains the chip hardware context information that is bound by an index; The semantic annotation field is extracted from the hardware state control layer code, the result judgment output layer code, and the parameter binding statements in the test interface function.

2. The method according to claim 1, characterized in that, The method further includes: The system framework template is independent of the structured sample storage and is not included in the main code body; During the code generation phase, the system framework template is injected as framework information into the code generation process and used in conjunction with the code body and context fields in the structured sample to ensure the integrity of the generated code during runtime.

3. The method according to claim 1, characterized in that, The ATE test program source file is divided into multiple functional semantic layers to obtain the hardware state control layer code and the result judgment and output layer code, including: The ATE test program source file is divided into multiple functional semantics to identify the hardware state control operation statements and result judgment and output statements inside each test interface function. The hardware state control layer code is obtained based on the hardware state control operation statement, and the result judgment output layer code is obtained based on the result judgment and output statement; The hardware status control operation statements include at least relay switching operation statements, range switching operation statements, and mode switching operation statements, and the result judgment and output statements include at least test result judgment statements, result recording statements, and data output operation statements.

4. The method according to claim 1, characterized in that, The step of obtaining test sample units or test item fragments by segmenting each test interface function in the test interface function layer code includes: The test interface functions that directly interact with the device under test are identified from the test interface function layer code by using function naming prefix features. Each test interface function is taken as the smallest functional unit, and the code is segmented based on the size of the function body to obtain test sample units or test item fragments.

5. The method according to claim 4, characterized in that, The process involves identifying test interface functions that directly interact with the device under test from the test interface function layer code using function naming prefix features. Each test interface function is then used as the smallest functional unit, and the code is segmented based on the function body size to obtain test sample units or test item fragments, including: Scan the test interface function layer code, identify functions with preset naming prefixes, and determine the identified functions as test interface functions that directly interact with the device under test; For each test interface function, obtain the number of lines of code corresponding to that test interface function; If the number of lines of code is less than or equal to a preset line count threshold, the test interface function will be used as a test sample unit. If the number of lines of code is greater than a preset line number threshold, the test interface function is divided according to the segment start semantic marker and segment end semantic marker in the test interface function to obtain multiple test item segments, each test item segment corresponding to a test item in the chip test task; The segment start semantic marker includes the location of the test item identifier annotation or the parameter binding statement in the test interface function, and the segment end semantic marker includes the location of the test result determination statement in the test interface function.

6. The method according to claim 5, characterized in that, The test interface function is divided according to the segment start semantic marker and segment end semantic marker in the test interface function to obtain multiple test item segments, including: Identify all test item identifiers, comments, parameter binding statements, and test result determination statements in the test interface function, and determine the location of each test result determination statement as a semantic marker point for the end of a segment. For each segment end semantic marker, determine the target interval corresponding to the segment end semantic marker; If a test item identifier annotation exists within the target interval, the location of the test item identifier annotation is taken as the corresponding segment start semantic marker, and the test interface function is divided according to the segment start semantic marker and the segment end semantic marker to obtain a test item segment; If there is no test item identifier annotation but there is a parameter binding statement, the position of the parameter binding statement in the target interval is taken as the corresponding segment start semantic marker point, and the test interface function is divided according to the segment start semantic marker point and the segment end semantic marker point to obtain a test item segment; If there are neither test item identifiers nor parameter binding statements within the target interval, the starting position of the target interval is taken as the corresponding segment start semantic marker, and the test interface function is divided according to the segment start semantic marker and the segment end semantic marker to obtain a test item segment; By summarizing the various test item fragments, multiple test item fragments corresponding to the test interface function are obtained.

7. The method according to claim 6, characterized in that, Determining the target interval corresponding to the semantic marker point at the end of the segment includes: When there are no other segment end semantic markers before the segment end semantic marker, the target interval is formed based on the segment end semantic marker and the starting position of the test interface function. When there are other segment end semantic markers before the segment end semantic marker, the target interval is formed based on the segment end semantic marker and the next row of the preceding segment end semantic marker that satisfies the first condition. The first condition includes being closest to the semantic marker of the end of the segment and being located before the semantic marker of the end of the segment.

8. The method according to claim 1, characterized in that, The step of extracting the structured data from the test sample units or test item fragments to construct structured samples includes: For each test sample unit or test item segment, hardware state control information corresponding to the test sample unit or test item segment is generated according to the hardware state control layer code. The hardware state control information includes a hardware operation identifier sequence and a corresponding operation category set. The operation category set includes at least relay control category, excitation application category, time delay category, measurement category and / or result reporting category. Based on the results, the output layer code is determined to obtain the result identification information corresponding to the test sample unit or test item fragment. The result identification information includes at least the test item name, result variable, judgment condition, and site information. Based on the parameter binding statements in the test sample unit or test item fragment, obtain parameter information, which includes at least parameter name, parameter type and parameter value range; The test sample unit or test item fragment is used as the code body, the chip hardware context information is used as the context field, and the hardware state control information, the result identification information and the parameter information are used as semantic annotation fields. The chip hardware context information includes at least the chip model, pin mapping and instrument resources. A structured sample is obtained by combining the code body, context fields, and semantic annotation fields with a preset structured template.

9. The method according to claim 1, characterized in that, Before performing multi-level functional semantic partitioning on the ATE test program source file to obtain the multi-level functional semantic partitioning results, the following steps are also included: Perform at least one of the following on the ATE test program source file: character encoding uniform conversion, removal of invalid characters, and removal of redundant comments; Establish the line index structure of the ATE test program source file.

10. The method according to claim 1, characterized in that, The ATE test program source file is divided into multiple functional semantic layers to obtain the hardware resource declaration layer code, including: Scan the ATE test program source file and identify hardware resource declaration statements through pattern matching; The hardware resource declaration statement includes at least one or more of the following types: The channel declaration statement contains the channel identifier keyword; The relay declaration statement includes the relay identification keyword; Power declaration statements, including power identification keywords; The instrument instantiation statement contains the instrument type identifier keyword; The set of all identified hardware resource declaration statements is determined as the hardware resource declaration layer code.

11. The method according to claim 2, characterized in that, Also includes: The system framework template and the structured sample are stored separately. When the same model of chip is deployed on different ATE test platforms, the code body, context fields and semantic annotation fields in the structured sample remain unchanged, and only the system framework template corresponding to the target ATE test platform is replaced, so as to realize the cross-platform reuse of the structured sample between different ATE test platforms.

12. An apparatus for constructing structured samples of ATE test code, characterized in that, include: The semantic segmentation module is used to perform multi-level functional semantic segmentation on the ATE test program source file to obtain the multi-level functional semantic segmentation result. The multi-layer functional semantic partitioning result includes at least: hardware resource declaration layer code, system configuration layer code, test interface function layer code, hardware state control layer code, and result judgment and output layer code; wherein, the hardware state control layer code and the result judgment and output layer code are embedded inside the test interface function layer code; The information extraction module is used to perform differential extraction based on the multi-layer functional semantic division results: extract chip hardware context information from the hardware resource declaration layer code, extract the system configuration in the system configuration layer code as a system framework template, and obtain test sample units or test item fragments by taking each test interface function in the test interface function layer code as the segmentation object. The sample construction module is used to extract the structure of the test sample unit or test item fragment and construct a structured sample. The structured sample includes at least: The main body of the code includes the original code content of the code corresponding to the test sample unit or test item fragment, as well as the hardware state control layer code and result judgment output layer code embedded within it; The context field, independent of the code body, contains the chip hardware context information that is bound by an index; The semantic annotation fields are extracted from the hardware state control layer code, the result judgment output layer code, and the parameter binding statements in the test interface function.

13. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the ATE test code structured sample construction method according to any one of claims 1-11.

Images